翻译自 What happens when … Kubernetes edition!。我认为这篇文章写得生动有趣，且在关键位置都给出了有价值的链接，引导进一步的阅读学习，让我有了重读并翻译的冲动。

如果我希望往 Kubernetes 集群当中部署 nginx，我大概率会在命令行输入下面这样的命令并敲下回车键：

1

kubectl create deployment nginx --image=nginx --replicas=3

几秒之后，我应该能看到三个 nginx 的 pod 散布在集群的工作节点上。这很神奇！但这个过程背后究竟发生了什么？

关于 Kubernetes 的惊人的特点是，它通过用户友好的 API 处理工作负载的部署。其中的复杂性被简单的抽象隐藏起来。但为了充分理解它所提供的价值，了解其内部工作原理也是很有用的。本指南将引导您了解从客户端 kubectl 到 kubelet 的请求的完整生命周期，并在必要时链接到源代码（或者相关文档和博客）来进一步说明正在发生的事情。

这是一份不断修订的文档。如果您发现可以改进或重写的地方，欢迎贡献！

陈忠实先生花了六年时间著出《白鹿原》这部巨作，而我却前前后用了近两年时间才读完这部作品，实在惭愧。因为用的是“微信读书”读的电子书，阅读记录都有存储在其平台上，才能得知我原来在 2022 年看完《杀死一只知更鸟》之后就开启了《白鹿原》。然而，过去在学校因为事情众多难以聚焦到“读闲书”上，所以 2022 年的 2 月开启这部书的阅读，走入白鹿原的广袤天地之后就一度搁置。

直到 2023 年毕业工作后的某个瞬间，决定要重拾读书计划之后才想起在一年前的某个时间我曾读过这本书的三分之一。过去了这么长时间，我还能明确地记得我读到三分之一的节点是白灵和鹿兆海用掷铜钱的形式分别投身国共两党追求理想而愉快分别的场景，再次拾起此书时两人分别时欣喜的场景还历历在目，但后来的结局竟是如此，实在令人惋惜…

过去没有写读后感的习惯，最多在中学时因为看书中人物罹难后过于激动而在 QQ 空间发动态抒怀。但不得不说毕业后独居的生活给予了我更多的思考时间，让我能够在品读作品之余思索其中深意，感慨书中角色之悲壮或卑劣，也算是双面硬币里好的一面了。

向外输出是向内消化的高级姿态，我希望通过写出自己的感受加深自己对作品的理解。

开发动机

核心动力是我有学会一门系统级编程语言的梦想。所以计划用 Rust 为开发语言（手段）完成本科三年级计算机网络专业课上的 FTP 大作业（目标），学习 Rust 的同时巩固计网的基础知识。

虽然大一刚入学就开始接触 C/C++，但是对于当时没有任计算机知识何积累的我来说用这样的方式开始我的编程入门实在是颇为残忍。或许我当时连内存大小和磁盘容量都分不清，不知堆栈为何物，也搞不懂什么编译链接，让我去理解指针实在是有点为难。现在回过头来看，当时的教学顺序对零基础的学生来说是不太友好的：老师在讲指针结构的内存优化时我甚至还写不出像样的符合语法的程序，课程内容就自然也就无法很好地消化了。

如果由我来制定教学计划，我一定将最开始的编程入门课定为使用 Python 教学而不是 C/C++，在知道如何写出鲁棒、高效、优雅的代码前，先要做到能写代码，就好似学会跑步之前需要先学会走路；等学生们了解了计算机组成原理、操作系统等计算机基础知识之后（或同时），再教授 C/C++ 等较低层的、系统的编程语言了。话扯太远了，就此打住。

今天是2022年12月31日，2022年的最后一天，先给年初的自己说一声对不起：年初立的 Flag 基本没有一条是顺利达成的，我以为目标量化以后就可以逐项实现，但还是高估自己的执行力和时间充裕程度了。今年是我第二个本命年，本应过的虎虎生风，生龙活虎，但是现实没有我想象中那么精彩，但有一些事情还是值得记载。这一年我在专业上经历了迷茫，在情感上遇到波折，在工作上也遭遇了挑战，大环境上也在年底迎来了疫情政策的转折。我想对这一年做个小小的总结，也对明年做些展望和规划。

这篇博客其实是以一次公司内的技术分享为基础做的调研和总结归纳，包含了我自己很多不成熟的观点看法。这次分享主要是想向新同事介绍为什么我们选择在项目中大规模使用 GraphQL 而不是更传统更简单的 RESTful API。

GraphQL 是什么

在上一篇有关 GraphQL 的博客里，我简单地说明了 GraphQL 的定义及其大致用途，贴了官网链接就开始介绍我使用 GraphQL 的“更优雅的”方式，对 GraphQL 本身描述得并不多。这里又贴一下英文的定义：A query language for your API

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

划重点，它是一种查询语言和使数据可查询的运行时。作为一种语言，它有自己的语法，能够定义Type, Enum, Input, Fragment, Query, Mutation等元素，熟悉 Typescript 的朋友会对此感到亲切。而在前端开发中需要重点关注的是以下几个部分：

断断续续写前端项目也有好几年了，从大二接触 Javascript 和 Vue 时的兴奋，到接触小程序和 React 时的“渐入佳境”，再到这段时间的感到无比疲惫，我希望我在前端开发上大规模投入的阶段先暂告一段落了。为什么有这样的疲惫感呢？原因总结起来有以下几点：

1. 前端开发面临的大多不是技术问题，是产品问题或美学问题，最终目标是让用户满意；
2. 前端开发过于琐碎，需要处理的细枝末节极多，每个页面元素都有相应的状态需要管理；
3. 前端难于抽象，对应到用户上则表现为具体业务需求是千变万化的。

起因

「代码写了不测等于白写」我总是跟身边的朋友这样调侃。然而我们写前端项目时很难在代码层面进行测试，大部分函数都是基于事件响应，接收用户输入的参数，并对页面组件或数据产生一定副作用，Mock 起来很麻烦。所以前端项目的测试往往都是端到端测试，即模拟用户在页面上进行操作，测试路径越离奇越好，因为无法提前预知用户会如何使用，所以最好在测试时可劲儿造。

曾经还会想着用 Cypress 等自动化工具进行端到端测试，例如用代码定义【打开某页面–>拖拽滑动条至页面下方–>点击输入框使之获取焦点–>输入“Hello world”–>按下回车–>等待页面响应–>观察响应是否符合预期】这个过程，但只要遇到元素稍多的页面，编写测试用例的过程就会变得机械呆板。

如果组件足够小，内容够聚焦，那么测一下也不是不可以。因为想在不同的项目中复用同一套富文本编辑组件(体积比较大，且包含机器构建的 JS)，我把它单独提出来作为 NPM 包发布以便各个项目安装使用。这当中编码和测试都遇到了一些问题。

新年的元月已然过半，但直到现在我才能说我完成了上一年的工作。我一直在追求“忙的时候闲一点，闲的时候忙一点”的从容，这一年大部分时间是保持着这个状态的，让我非常欣慰。但是真正从学生身份蜕变成“开发者”“软件工程师”（或者“社畜”？其实即使是自嘲我也不太喜欢这个词），还是有着截然不同的感受和体会的。对于 2022 也有着无数的憧憬。

背景

Nginx 读作 engine x，是一个高性能的 HTTP 和反向代理服务器，还能用作邮件代理服务器或是通用的 TCP/UDP 代理服务器。有过后端程序部署经历的同学应该会有所了解，用 Nginx 能够很方便地完成反向代理、服务静态文件、实现负载均衡、接入 HTTPS 协议等任务。

根据官方文档里面写到的，除了提供静态文件服务、反向代理和负载均衡等功能之外，还提供以下包括单不限于若干个方面的支持：

1. FastCGI, uwsgi 之类服务器和反向代理服务器的缓存支持；
2. 以域名/IP 为基础的虚拟服务器、Keep-alive 和流水线链接的支持；
3. 访问日志、错误日志的输出和格式化，带缓存的日志写机制；
4. 3xx-5xx 错误码重定向，根据正则表达式重写 URI (Rewrite)；
5. 基于客户端地址的访问控制和函数调用；
6. HTTP referer 的验证、支持除了 GET 外的几种 HTTP 方法： PUT/DELETE/COPY/MOVE/MKCOL；
7. FLV/MP4 的流播放、响应限流、限制单点的并发连接数和请求数；
8. 等等…（上面只列了我读得懂的）

Nginx 的功能实在太多了，在这里全部列出来不太可能。一直以来我对 Nginx 都停留在“配置是什么，work 就行”的态度。因为这周程序部署时遇到的一点问题，上网搜了好多帖子、博客寻求解决方法那种捉襟见肘、有病乱投医的样子让我觉得很狼狈。借此为契机，决定周末看一下 Nginx 的官方文档。nginx 旧版的官网文档组织混乱，建议移步 Nginx Plus (Nginx 的商业版)官网。Nginx 和 Nginx Plus 的对比放在这里。

关于 GraphQL，它的官网(需要科学上网)是这样介绍的：

GraphQL 既是一种用于 API 的查询语言也是一个满足你数据查询的运行时。 GraphQL 对你的 API 中的数据提供了一套易于理解的完整描述，使得客户端能够准确地获得它需要的数据，而且没有任何冗余，也让 API 更容易地随着时间推移而演进，还能用于构建强大的开发者工具。

作为 RESTful API 的竞品，GraphQL 从开源之初就备受关注，一是因为它是由 Facebook 开源的项目，二是它挑战了 RESTful API 的地位，这是很关键的一点。RESTful API 利用 URI 的具体内容和请求方法来区分请求的资源或者方法，其中的资源 URI 容易与路由路径产生混淆和重复；资源数量达到一定的数目之后，如何给资源 URI 起名或许也是一件困难的事情。而 GraphQL 则鼓励开发者将所有需要请求的信息显式的写在请求体当中，精确到具体的字段，不多也不少。

我参与的几个项目都是用 GraphQL 作为 API 的基础，我总结出了一个在前端相对优雅地使用 GraphQL 的方法。这篇博客不讨论 GraphQL 的基本概念，主要介绍这个方法。（为省篇幅，这篇博客里面的代码均不做异常处理）