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，快快扫码抢购吧！）
还未添加个人签名 2019.10.21 加入
还未添加个人简介
评论