Kubernetes生态系统与演进路线

Kubernetes 的快速演进大大推进了云计算技术的发展，伴随着云原生计算基金会CNCF的诞生、云原生开源项目的孵化，逐渐演化成一个完整的云原生技术生态系统。

本文就来介绍一下Kubernetes与CNCF的关系、Kubernetes演进路线和Kubernetes开发模式。

01

Kubernetes与CNCF
云原生计算的特点是使用开源软件技术栈，将应用程序以微服务的形式进行发布和部署，并动态编排这些微服务，优化资源使用率，帮助软件开发人员更快地构建出色的产品，进而提升业务服务的快速迭代与创新价值。
Kubernetes作为CNCF的第一个开源项目，其智能的服务调度能力可以让开发人员在构建云原生应用时更加关注业务代码而不是烦琐的运维操作，Kubernetes可以在本地或云端运行，让用户不再担心基础设施被供应商或云提供商绑定。

围绕Kubernetes，CNCF设计了云原生技术的全景图，从云原生的层次结构和不同的功能维度上给出了云原生技术体系的全貌，帮助用户在不同的层面选择适合的软件和工具进行支持。

随着越来越多的开源项目在CNCF毕业，云原生技术的生态系统日趋完善，用户可以选择的工具也越来越丰富。经过了从 2014 年开源至今的快速发展，Kubernetes已经成为整个云原生体系的基石，在云原生技术全景图中，可以看到Kubernetes处于编排管理工具的核心位置，相当于云原生技术体系中操作系统的角色。

同时，CNCF为云原生技术如何在生产环境中落地提供了循序渐进的路线图，如图1所示。

图1 CNCF云原生技术路线图

CNCF现在在中国有近50个成员，中国还是CNCF项目的第三大贡献者（按贡献者和提交者计），仅次于美国和德国。

在CNCF于2020年年初发布的全球云原生调查报告中，84%的受访者在生产环境中使用容器，容器在生产环境中的使用已成为常态，并且在很大程度上改变了基于云的基础架构。

同时，针对中国的第三次云原生应用调查报备显示：49%的受访者在生产环境中使用容器，另有32%计划这样做，与一年前相比，这是一个显著的增长；同时，72%的受访者已经在生产环境中使用Kubernetes，大大高于一年前的40%。

图2显示了大规模生产环境中Kubernetes集群数量逐年增长的趋势。

图2 Kubernetes集群数量逐年增长的趋势

02

Kubernetes的演进路线
▊ Kubernetes与CNCF的容器标准化之路
在CNCF的生态中，围绕着Kubernetes的一个重要目标是制定容器世界的标准。迄今为止，已经在容器运行时、容器网络接口、容器存储接口三个方面制定了标准的接口规范。

◎ CRI（Container Runtime Interface）容器运行时接口。容器运行时（Container Runtime）是Kubernetes的基石，而Docker是我们最熟悉的容器运行环境。CNCF第一个标准化的符合OCI规范的核心容器运行时是Containerd，其来源于Docker在2017年的捐赠产物，关于CRI的详细说明请参考2.7节的说明。

◎ CNI（Container Network Interface）容器网络接口。网络提供商基于CNI接口规范提供容器网络的实现，可以支持各种丰富的容器网络管理功能，开源的实现包括Flannel、Calico、Open vSwitch等，关于CNI的详细说明请参考7.6节的说明。

◎ CSI（Container Storage Interface）容器存储接口。Kubernetes在1.9版本中首次引入CSI存储插件，并在随后的1.10版本中默认启用。CSI用于在Kubernetes与第三方存储系统间建立一套标准的存储调用接口，并将位于Kubernetes系统内部的存储卷相关的代码剥离出来，从而简化核心代码并提升系统的安全性，同时借助CSI接口和插件机制，实现各类丰富的存储卷的支持，赢得更多存储厂商的跟进。Kubernetes在1.12版本中又进一步实现了存储卷的快照（VolumeSnapshot）这一高级特性。

◎ API标准接口。我们再看一个Kubernetes标准化的例子，API Server之前的接口就是普通的RESTful接口，通过支持Swagger 1.2自动生成各种语言的客户端，方便开发者调用Kubernetes的API。从Kubernetes 1.4版本开始，API Server对代码进行了重构，引入了Open API规范，之后的Kubernetes 1.5版本能很好地支持由Kubernetes 源码自动生成其他语言的客户端代码。这种改动升级对于Kubernetes的发展、壮大很重要，它遵循了业界的标准，更容易对接第三方资源和系统，从而进一步扩大Kubernetes的影响力。

▊ Kubernetes安全机制的演进之路

除了标准化，Kubernetes的另一个演进目标就是提升系统的安全性。自1.3版本开始，Kubernetes都在加强系统的安全性，如下所述。

◎ 1.3版本：引入了Network Policy，Network Policy提供了基于策略的网络控制，用于隔离应用并减少攻击面，属于重要的基础设施方面的安全保障。

◎ 1.4版本：开始提供Pod安全策略功能，这是容器安全的重要基础。

◎ 1.5版本：首次引入了基于角色的访问控制RBAC（Role-Based Access Control）安全机制，RBAC后来成为Kubernetes API默认的安全机制，此外添加了对kubelet API访问的认证/授权机制。

◎ 1.6版本：升级RBAC安全机制至Beta版本，通过严格限定系统组件的默认角色，增强了安全保护。

◎ 1.7版本：新增节点授权器Node Authorizer和准入控制插件来限制kubelet对节点、Pod和其对象的访问，确保kubelet具有正确操作所需的最小权限集，即只能操作自身节点上的Pod实例及其他相关资源。在网络安全方面，Network Policy API也升至稳定版本。此外，在审计日志方面也增强了定制化和可扩展性，有助于管理员发现运维过程中可能存在的安全问题。

◎ 1.8版本：基于角色的访问控制RBAC功能正式升级至v1稳定版本，高级审计功能则升级至Beta版本。

◎ 1.10版本开始：增加External Credential Providers，通过调用外部插件（Credential Plugin）来获取用户的访问凭证，用来支持不在Kubernetes中内置的认证协议，如 LDAP、oAuth2、SAML等。此特性主要为了公有云服务商而增加。1.11版本继续改进；1.20版本引入了配套的kubelet image credential provider，用于动态获取镜像仓库的访问凭证。

◎ 1.14版本：由于允许未经身份验证的访问，所以Discovery API被从RBAC基础架构中删除，以提高隐私和安全性。

◎ 1.19版本：seccomp机制更新到GA阶段。

▊ Kubernetes扩展功能的演进之路

在Kubernetes的快速发展演进过程中，随着功能的不断增加，必然带来代码的极速膨胀，因此不断剥离一些核心代码并配合插件机制，实现核心的稳定性并具备很强的外围功能的扩展能力，也是Kubernetes的重要演进方向。

除了CRI、CNI、CSI等可扩展接口，还包括API资源的扩展、云厂商控制器的扩展等。

◎ Kubernetes从1.7版本开始引入扩展API资源的能力，使得开发人员在不修改Kubernetes核心代码的前提下可以对Kubernetes API进行扩展，仍然使用Kubernetes的语法对新增的API进行操作。Kubernetes提供了两种机制供用户扩展API：①使用CRD（Custom Resource Definition）自定义资源机制，用户只需定义CRD，并且提供一个CRD控制器，就能通过Kubernetes的API管理自定义资源对象；②使用API聚合机制，用户通过编写和扩展API Server，就可以对资源进行更细粒度的控制。

◎ 最早的时候，为了跟公有云厂商对接，Kubernetes在代码中内置了Cloud Provider接口，云厂商需要实现自己的Cloud Provider。Kubernetes核心库内置了很多主流云厂商的实现，包括AWS、GCE、Azure等，因为由不同的厂商参与开发，所以这些不同厂商提交的代码质量也影响到Kuberntes的核心代码质量，同时对Kubernetes的迭代和版本发布产生一定程度的影响。因此，在Kubernetes 1.6版本中引入了Cloud Controller Manager（CCM），目的就是最终替代Cloud Provider，将服务提供商的专用代码抽象到独立的cloud-controller-manager二进制程序中，cloud-controller-manager使得云供应商的代码和Kubernetes的代码可以各自独立演化。在后续的版本中，特定于云供应商的代码将由云供应商自行维护，并在运行Kubernetes时链接到cloud-controller-manager。

▊ Kubernetes自动化运维能力的演进之路

在Kubernetes的快速发展演进过程中，架构和运维自动化、高级别的架构和运维自动化能力也是其坚持的核心目标，这也是Kubernetes最强的一面，同时是吸引众多IT人士的核心特性之一。

最早的ReplicaController/Deployment其实就是Kubernetes运维自动化能力的第一次对外展示，因为具备应用全生命周期自我自动修复的能力，所以这个特性成为Kubernetes最早的亮点之一。

再后来，HPA水平自动伸缩功能和集群资源自动扩缩容（Cluster Autoscaler）再次突破了我们所能想到的自动运维的上限。

接下来，与HPA互补的VPA（Pod垂直自动伸缩）功能又将集群运维自动化的水平提升到一个新的高度。

我们看到，从Deployment到HPA再到VPA的发展演进，是沿着Pod自动扩缩容的弹性计算能力的路线一步步演进、完善的，这也是超大规模集群的Kubernetes的核心竞争力的重要体现，未来会不断完善。

除了高级别的架构和运维自动化能力，Kubernetes在常规的运维自动化方面也丝毫没有放松，它在不断提升、演进。

我们以最常见的集群部署、停机检修、升级扩容这些常规运维工作为例来看看Kubernetes是怎么不断演进的。

（1）在集群部署方面，Kubernetes很早就开始研发一键式部署工具——kubeadm，kubeadm可谓Kubernetes历史上最久的组件之一，它于Kubernetes 1.4版本面世，直到Kubernetes 1.13版本时才达到GA阶段。正是有了kubeadm，Kubernetes的安装才变得更加标准化，并大大简化了大规模集群的部署工作量。不过在集群部署方面还存在另一个烦琐并耗费很多人工的地方，这就是每个节点上kubelet的证书制作。Kubernetes 1.4版本引入了一个用于从集群级证书颁发机构（CA）请求证书的API，可以方便地给各个节点上的kubelet进程提供TLS客户端证书，但每个节点上的kubelet进程在安装部署时仍需管理员手工创建并提供证书。Kubernetes在后续的版本中又实现了kubelet TLS Bootstrap这个新特性，基本解决了这个问题。

（2）在停机检修和升级扩容方面，Kubernetes先后实现了滚动升级、节点驱逐、污点标记等配套运维工具，努力实现业务零中断的自动运维操作。

此外，存储资源的运维自动化也是Kubernetes演进的一大方向。以PVC和StorageClass为核心的动态供给PV机制（Dynamic Provisioning）在很大程度上解决了传统方式下存储与架构分离的矛盾，自动创建了合适的PV并将其绑定到PVC上，拥有完善的PV回收机制，全程无须专业的存储管理人员，极大提升了系统架构的完整性。

03

Kubernetes的开发模式
最后，我们来说说Kubernetes的开发模式。Kubernetes社区是以SIG（Special Interest Group，特别兴趣小组）和工作组的形式组织起来的，目前已经成立的SIG小组有30个，涵盖了安全、自动扩缩容、大数据、AWS云、文档、网络、存储、调度、UI、Windows容器等方方面面，为完善Kubernetes的功能群策群力并共同开发。
Kubernetes的每个功能模块都由一个特别兴趣小组负责开发和维护，如图3所示。

图3 特别兴趣小组

有兴趣、有能力的读者可以申请加入感兴趣的SIG小组，并通过Slack聊天频道与来自世界各地的开发组成员开展技术探讨和解决问题。同时，可以参加SIG小组的周例会，共同参与一个功能模块的开发工作。

本文摘自《Kubernetes权威指南》一书，欢迎阅读此书来了解更多Kubernetes相关内容。

▊《Kubernetes权威指南（第5版）》

龚正，吴治辉，闫健勇 著

内容超详尽的K8s指南全新升级至K8s1.19

提供源码下载、勘误及读者群答疑

人人都想拥有的Kubernetes重磅级案头手册

本书总计12章，分别讲解Kubernetes的基本概念、实践指南、核心原理、开发指南、网络与存储、运维指南、新特性演进等内容。全书图文并茂、内容丰富、由浅入深、讲解全面，并围绕在生产环境中可能出现的问题，给出了大量典型案例，比如安全配置方案、网络方案、共享存储方案、高可用方案及Trouble Shooting技巧等，有很强的实战指导意义。

（京东满100减50，快快扫码抢购吧！）