Kubernetes的第12个正式版本 蚌中之珠是什么？

作者 | 张磊

悄无声息地，Kubernetes 项目已经在 9 月末，迎来了它的第 12 个正式版本（即：1.0 及以后的版本）。

不过，相信你也已经感受到了，这次 Kubernetes 1.12 的发布变更记录里，似乎缺少了以往的激动人心。

事实上，当一个基础设施领域的开源项目进入平稳发展期之后，它的变更记录就不再是一个跟踪和观察这个社区进展的有效手段了。原因也很简单：

这个项目必然在做减法。很多在初期被塞进项目的特性，其实都已经被转移到了单独的库里。这个项目的组件，也在不断精简和实现界面化，以鼓励用户自行扩展和定制。

这个项目必然会更谨慎地添加新特性。其实，如果现在你要变更 Kubernetes 某个的 API，哪怕就改一个字段，被拒绝的概率也可以说是 100%。而新增加的 API，则基本上都会被建议用 CRD 实现。

当然，平稳发展，绝不意味着缓慢发展。在最近一次的统计中，Kubernetes 项目的 Velocity（活跃度）指标（comment、PR、commit、issues、author 活动的加权统计），依然高居全球第二位，仅次于 Linux 项目。

所以，在这样的背景下，解读这次 Kubernetes 1.12 新版本的发布，其实已经变成了一个“淘宝”的过程。那么，我们就不妨从 SIG-node 开始吧。

在 Kubernetes 1.12 中，SIG-node 全力推进的特性，叫作 RuntimeClass。

这个特性之所以比较”急“，就是因为像 Kata Containers 以及 gVisor 这样的、拥有“独立内核”的容器项目的陆续发布，已经把同时支持多种容器运行时（Container Runtime）的需求推到了台面上。而在以往使用 Kubernetes 时，你的 Pod 必须要带上一个 Annotation，来声明容器是要跑在 Kata Containers 里，还是 runC 里。这样的操作方式，不仅麻烦，而且非常不优雅。

相比之下，RuntimeClass 的作用，是在 Kubernetes 层面，以 API 的方式定义了 Runtime 的处理方式。

而 Pod，就只需要在定义里声明某个 RuntimeClass 的名字，比如 kata-containers，这个信息就会被 Kubernetes 通过 CRI 界面传递给 CRI 实现，比如 cri-containerd。然后，CRI 实现就会调用具体的 runtimeHandler，比如 Kata Containers，来运行容器。

然后，我们再看看 SIG-scheduling。

可能开发者们会比较清楚，Kubernetes 调度器部分的代码实现，其实非常混乱，充满了莫名其妙的耦合和不知所谓的“工厂”（这些“工厂”，当初应该是留给用户做扩展用的）。

有意思的是，由于 Kubernetes 项目的核心定位是编排而不是调度，所以 kube-scheduler 这个组件的受关注程度一直以来都比较低。这也就使得它成为了 Kubernetes 项目里，到目前为止唯一一个不受 RedHat 和 CoreOS“特殊关照”的核心组件。

这也就导致了，SIG-scheduling 其实现在有很多工作，都是在偿还之前欠下的“技术债”，比如在 Kubernetes 1.12 版本里：

仅通过对代码实现和数据结构的优化，就使得 Kubernetes 的调度器在某些场景下的性能提升了数十倍，吞吐量也大幅增加。

像 ImageLocalityPriority 这样基于镜像分布的调度策略，也是在这个版本中才默认被开启。

而 DaemonSet 的调度，也在这个版本里被 kube-scheduler 接管了过来，终于结束了 DaemonSet 要自己执行调度逻辑的尴尬局面。

而且，在接下来的一段时间里，kube-scheduler 还要经历更大规模的非功能性重构，旨在去除整个代码实现里的冗余和无意义的耦合。

当然，这些偿还“技术债”的工作，实际上也是在为 Kubernetes 调度器的下一次进化铺平道路。

可能你已经听说过，kube-scheduler 在 Kubernetes 1.12 版本后的重点发展方向，是“Framework 化”。这是一个非常重要的变革，它的设计可以简单的用下图描述：

可以看到，接下来 Kubernetes 的调度器将会在整个调度流程的各个关键步骤上，为用户暴露出界面，允许用户通过 Go 语言的二进制 Plugin 的方式（图中的 Plugin Hook），在界面处插入自定义的逻辑。而 kube-scheduler 本身，则会通过不断地做减法，在不影响现有功能的前提下，仅保留一个最小实现。

相信在不远的将来，就跟现在的 Container Runtime 一样，大多数用户的 Kubernetes 都将使用默认“调度器 + 插件”的方式，来取代自己编写或者 Fork 的自定义调度器。

同样动作比较大的，还有 SIG-storage。

由于 CSI 的推进，SIG-storage 的很大一部分工作是，将现有的或者刚刚被添加的新的存储特性，移植到 CSI 上。所以，Kubernetes 中与存储相关的有不少的工作，实际上是由各个 Vendor（比如，rook.io、ScaleIO 等）自行完成的。

而这些存储部分的新特性，就包括了 Volume Topology。它为 Kubernetes 提供了 Volume 所在的 Zone、Rack 等拓扑结构信息，从而为 Kubernetes 调度器在调度时考虑 Data Locality 提供了依据。

实际上，过去一段时间，SIG-storage 一直在推进的内容，就是在调度器中加入对 Volume 的感知，进而实现了 PV 和 PVC 的“延迟绑定”。这对于需要在调度阶段就考虑全局 Volume 分布情况的场景非常重要，比如 Local Persistent Volume。而 Volume Topology 其实只是这个工作的一部分而已。

此外，SIG-storage 已经为 Volume 添加了新的 Snapshot（快照）API（也是通过 CRD 实现的），并且，同时在 CSI 里对其提供了支持。这就为将来用户备份和恢复数据卷提供了一个统一的操作界面和对应的 API 对象。

不难发现，现在 Kubernetes 的发展方向，已经不再是上线一个又一个的新特性，而是希望更多的特性和创新，发生在社区层面而不是项目层面。

所以，相比于发布一个“轰轰烈烈”的 1.12 版本，Kubernetes 项目的各位元老们，其实更加期待的是 Operator Framework、MetaController、Helm、rook.io、Knative 这样的第三方创新项目的成功。如果你到现在都还没听说过或者不了解这些项目的话，那就赶紧去一线社区补补课吧。

这也就意味着，接下来在 Kubernetes 的变更文档里“淘宝”的过程中，你应该格外留意那些与 Kubernetes API、可扩展性能力、可扩展性界面（CRI、CSI、DevicePlugin、CNI），以及 Sandbox 容器运行时（Kata Containers、gVisor）等相关的变更活动。这些内容，才是 Kubernetes 项目接下来发展的关键所在，也是 Kubernetes 项目发布里最值得关注的“蚌中之珠”。

当然了，作为 Kubernetes 的用户或者运维人员，你最应该额外关注的，还是变更文档里的“Action Required”和“Deprecations and removals”这两部分的内容。这样，像“Etcd V2 在 1.12 后将不再被支持”“kubeadm 高可用部署的进一步完善”“Heapster 正式退出历史舞台”等，需要你操作和善后的关键信息，才不会被遗漏。

可能你会有疑问，这次官方 Blog 里重点提到的 Kubelet TLS Bootstrap，又是怎么回事呢？

其实，这个特性的重要性恐怕并没有宣传中得那么高。

如果你用过 kubeadm 部署 Kubernetes 的话就会知道，在执行 kubeadm join 的时候，会用到一个自动生成的 Token。这是因为，kubeadm 需要使用这个 Token 发起请求访问 kube-apiserver，拿到 kube-apiserver 的访问授权信息，接下来 kubelet 启动时才能使用这些授权信息注册到 kube-apiserver 里。这就是 Bootstrap Token 的作用。而这个原先需要部署工具自己维护的功能，最近已经被实现在了 Kubernetes 中。

所以现在，kubelet 在第一次部署的时候，就可以直接使用 Bootstrap Token 启动并完成注册，从而大大简化了部署流程。

这也是我推荐你一定要了解和使用 kubeadm 的主要原因：

kubeadm 可以认为是现在 Kubernetes 唯一的“原生”部署工具。而也只有 kubeadm 的部署流程和设计思路，才可能被反推回 Kubernetes 项目本身。

写在最后

我是张磊，Kubernetes 社区的一位资深成员和项目维护者。

2012 年，我还在浙大读书的时候，就有幸组建了一个云计算与 PaaS 基础设施相关的科研团队，之后的几年，我全职在 Kubernetes 和 Kata Containers 社区从事上游开发工作，还有幸作为主要的研发人员和维护者之一，亲历了 Serverless Container 概念的诞生与崛起。

工作之余，我还发起和组织撰写了《Docker 容器与容器云》一书，受到了广大希望进阶容器技术的读者的好评。

今年，我又远赴西雅图，在微软研究院（MSR）云计算与存储研究组，专门从事基于 Kubernetes 的深度学习基础设施相关的研究工作。

可以说，这 6 年里，我参与和亲历了容器技术从“初出茅庐”到“尘埃落定”的全过程。

最近我在极客时间出品了“深入剖析 Kubernetes”的专栏。在专栏里，我会从容器诞生的背景开始，由浅入深给你讲清容器背后的技术本质与设计思想，结合著对核心特性的剖析与实践，加深你对容器技术的理解。

扫描下方的二维码，即可试读或订阅专栏。