多用户、多工作负载、5000 节点集群：Kubernetes 1.6 都有哪些看点？

相比于 2009 年就已经问世的 Mesos，诞生两年多 Kubernetes 项目表现不俗，在 GitHub、Stack Overflow、Slack 社区中广受欢迎。

概述

2017 年 3 月 29 日，Kubernetes 官方正式发布 Kubernetes 1.6 版本。Kubernetes 称在这套最新发行版高度关注规模化与自动化的需求，旨在帮助用户在单一集群之上部署面向多用户的多种工作负载。

新的版本将能够支持 5000 节点大规模集群，亦推出了动态存储配置机制的稳定版本。基于角色的访问控制（简称 RBAC：Role-based access control）机制、kubefed、kubeadm 以及多种其它计划调度功能亦迎来了其 beta 测试版本。同时，还添加智能化默认设置选项，旨在帮助用户凭借相关高度自动化能力实现开箱即用。

发布主管如何评价此次版本？ 难忘研发合作

Kubernetes 1.6 是由 CoreOS 管理发行版本，同时还有微软、红帽、Heptio、Mirantis 以及谷歌的参与。工作主管 Dan Gillespie 称这次跨企业领导与统筹层面带来了一系列首创性成就：第一款非谷歌发行版以及第一支由非谷歌成员作为主要构成的发布团队等等。

在此次研发过程中，Dan 称整个团队遇到的最大挑战是如何设计出一种更为高效的薄片测试方案。在之前的工作中，管理人员通过需要面对成百上千次薄片测试，即以极高频率进行测试、发现失败、进行调整并再次测试。考虑到整个发布团队中包含 26 支特别任务小组（简称 SIG）。

但是，不可能让每位成员皆面对同样的大规模重复任务。因此，项目组决定尝试一种新的方法。这一次，将各薄片分配至特定 SIG，旨在更好地立足整个技术社区进行责任划分与判断。这套方案效果出色 ; 解决薄片的过程如今更加易于管理。着眼于未来，发布团队必须考虑更多潜在需求以提供良好的问题解决办法，即保证“每个 SIG 验证小组与 SIG 节点各自面对 20 个薄片”，而非“作为整体项目，全部成员皆面对总计 260 个薄片”。

新版本哪里令我兴奋？

Kubernetes 1.6 是一套稳定版本，这意味着我们专注于提供大量较低级别的更新，从而优先提升用户体验，而非添加大量新功能。毕竟，稳定性才是 Kubernetes 能够在分布式系统编排方案中脱颖而出的最大优势。

此次发行版中最值得关注的更新当数对 Kubernetes 的基础内核作出的改进，其同时提升了可扩展性与可靠性。这一关键性步骤令 Kubernetes 成为一套更加高效的生产就绪型系统。

这套发行版中最令我个人感到兴奋的更新特性包括：默认启用 etcd v3、不再对单一容器运行时的直接依赖性、RBAC 进入 beta 测试阶段、StorageClass 对象自动配置。

新版本特性

规模与联动:

需要实现理想的规模化性能表现的企业用户请注意了，此次 Kubernetes 新版本提供的严格可扩展性 SLO 目前可支持 5000 节点（15 万 pod）集群。这意味着整体集群规模在 CoreOS 推出之 etcd v3 新版本的支持下迎来 150% 提升，非常适合用于部署搜索或者游戏等规模快速扩展且需要大规模集群的应用程序。

对于希望使用 5000 节点以上集群或者将 Kubernetes 扩展至多服务区乃至多云环境的用户，联动（federation）机制将允许大家将多个 Kubernetes 集群加以结合并通过单一 API 端点对其加以管理。在此次新版本中，kubefed 命令行工具已经正式进入 beta 测试阶段，其能够显著改进对内部集群的支持效果。目前 kubefed 能够自动配置 kube-dns 并将其添加至集群当中，同时为其传递各联动组件所需要的对应参数。

安全性与设置:

对于安全性较为关注的用户会发现，目前处于 beta 测试阶段的 RBAC 通过引入范围更广的系统组件默认角色迎来显著的安全性提升。1.6 版本中的默认 RBAC 策略可对控制面板组件、节点以及各控制器进行广泛的权限管理。RBAC 允许集群管理员选择性地对特定用户或者服务帐户进行细化控制，确保其仅能够以各命名空间为基础访问特定资源。由 1.5 版本升级至 1.6 版本的 RBAC 用户可查看相关指导资料（ https://kubernetes.io//docs/admin/authorization/rbac.md#upgrading-from-15）。

希望在物理或者云服务器上简化安全集群配置流程的用户则可使用另一款目前处于 beta 测试阶段的工具，即 kubeadm。Kubeadm 凭借着一组命令行标记得到了功能强化，同时亦迎来一整套包含 RBAC 设置、Bootstrap Token 系统以及强化 Certificates API 在内的基础功能集。

高级调度:

新版本添加了一整套强大且功能丰富的计划调度结构，能够更好地控制对各 pod 的具体调度工作，包括提供具体规则以将各 pod 限定至异构集群中的特定节点处，同时提供规则以跨越各节点、机架及区域等故障域对 pod 进扩展或者打包。

目前处于 beta 测试阶段的节点亲和 / 反亲和机制允许用户根据各节点标签将 pod 限定至特定节点。使用内置或者定制化节点标签，用户可以选定特定区域、主机名称、硬件架构、操作系统版本以及特定硬件等等。各计划调度规则可以强制要求或者推荐形式提供，具体取决于您希望以怎样的控制强度对计划调度加以管理。

另一项相关功能名为损坏与容错，其能够更为具体地表达规则以将 pod 从特定节点中排除出来。这项同样处于 beta 测试阶段的功能能够帮助用户轻松将特定节点集指定至特定用户组，或者通过排除不必要的 pod 以保留具备特殊硬件的节点供需要配合此类硬件之 pod 加以使用。

有时候，用户可能希望在单一服务之内的各 pod 间或者不同服务间进行协调调度（其在拓扑层面彼此相邻），例如优化南北或者东西向通信。或者，大家可能需要扩展某项服务的各 pod 以实现故障容错能力，抑或保证互相冲突的 pod 彼此分离或确保目标节点内只存在单一租户。目前处于 beta 测试阶段的 Pod 亲和与反亲和机制允许大家设置硬性或者软性要求，用以在任意拓扑结构之内（包括节点及区域等）对各 pod 进行对应扩展与打包。

最后，为了确保调度的最终灵活性，用户可以运行自定义型调度程序，而非被迫使用默认的 Kubernetes 调度程序。每项调度程序负责不同的 pod 分组。当前版本中的多调度程序同样处于 beta 测试阶段。

动态存储配置:

需要部署静态应用程序的用户将能够充分享受 Kubernetes 新版本中广泛提供的存储自动化功能。

自发展早期以来，Kubernetes 项目一直能够自动实现存储资源附加与分离、磁盘格式化、分卷挂载与卸下，同时可确保其随 pod 在各节点间的移动而无缝执行。另外，PersistentVolumeClaim（简称 PVC）与 PersistentVolume（简称 PV）对象则将存储请求由特定存储实现方案中解耦出来，使得 pod 规范能够在多种不同云及内部环境间往来移植。在新版本当中，StorageClass 与动态分卷配置机制迎来稳定版本，意味着用户能够在完全无需预配置的前提下自动根据需求创建并删除存储资源。

这一设计允许集群管理员在集群当中定义并公开多种存储形式，且各存储形式皆拥有自己的一组定制化参数。最终用户将不必因存储资源配置的复杂性与细微差别而分神，而可直接从多种存储选项当中进行选择。

在 Kubernetes 1.6 版本中，其迎来了一套内置默认设置，能够以完全自动化形式配置存储生命周期，从而帮助用户轻松处理应用程序。具体来讲，Kubernetes 默认为 AWS、Azure、GCP、OpenStack 以及 VMware vSphere 提供预安装系统定义 StorageClass 对象。这意味着 Kubernetes 用户在配合这些服务供应商时，将能够无需手动设置 StorageClass 对象即可享受由动态存储配置带来的便利。此次调整亦对各云环境上的 PVC 对象默认行为方式进行了变更。需要注意的是，其默认行为模式将各动态配置分卷设定为“delete”回收策略。这意味着一旦用户删除某 PVC，则与之对应的动态配置分卷亦会被自动删除，旨在确保用户无需执行额外的“清理”步骤。

另外，还扩大了所能够支持的存储选项范围：

• ScaleIO Kubernetes 分卷插件，用于使各 pod 能够无缝化访问并使用存储于 ScaleIO 分卷中的数据。
• Portworx Kubernetes 分卷插件，可利用 Portworx 作为 Kubernetes 集群的存储供应方。Portworx 能够将您的服务器容量汇总为资源池，从而将您的服务器或者云实例整合为融合型、高可用性计算与存储节点。
• 利用 COS 节点镜像在集群上支持 NFSv3、NFSv4 以及 GlusterFS。
• 支持用户写入 / 运行动态 PV 配置工具。
• 以 beta 测试形式支持持久性分卷挂载选项。

容器运行时接口、etcd v3 以及 Daemon 集更新:当用户无法直接与当前容器运行时或者 API 服务器数据存储区进行交互时，此三者将成为用户在 Kubernetes 内使用各项功能的实质性组件。因此，技术社区投入精力对这些功能以及其它一些系统组件进行了扩展。

• Docker-CRI 目前处于 beta 测试阶段，且在 kubelet 中默认启用。另外，对其它多种运行时的支持能力则以 alpha 测试形式提供，具体包括 cri-o、frakti 以及 rkt 等。
• API 服务器的默认后端存储已经在新集群内被升级为默认使用 etcd v3。如果您属于自 1.5 版本升级的集群用户，请注意规划数据迁移窗口以确保业务连续性。
• 由于 Kubelet 公开一项管理员可配置的节点分配功能以为系统守护进程预留计算资源，因此节点可靠性得到了提升。
• Daemon 集更新允许用户在守护程序集之上执行滚动更新。

Alpha 功能此次新版本主要关注对原有功能的成熟性提升，不过仍添加了多项 alpha 功能以支持项目发展路线图。

• 为其它小众云服务供应商提供云控制器管理器二进制代码支持，可用于测试各对应云服务供应商的工作流。
• 将节点问题与 tolerationSeconds 相结合以进行各 pod 回收，允许用户在出现问题时为绑定至某节点的 pod 设定持续时长。
• Pod 注入策略添加一项新的 API 资源 PodPreset，旨在将密码、分卷、分卷挂载乃至环境变量等信息注入至 pod 当中。
• 在 Horizontal Pod Autoscaler 中支持定制化指标变更与使用。
• 多英伟达 GPU 支持能力，但目前仅支持 Docker 运行时。

当然这一切只是今年我们发布的首套发行版中的部分特性。

Kubernetes 寄语

技术社区

这套发行版的成功发布离不开整个技术社区的卓越贡献。截至目前，Kubernetes 总计发布了来自 275 位作者的近 5000 条提交成果。为了让众多参与者团结在一起，Kubernetes 社区已经推出名为 K8sPort 的新计划，这套在线中心允许社区成员参与游戏化挑战并获得荣誉。

发布流程

这里首先要感谢 1.6 版本的发布团队（由 CoreOS 的 Dan Gillespie 负责领导），正是他们的努力才让这套新版本最终与大家见面。该发布团队正是 Kubernetes 社区对于社区治理工作作出之承诺的实际证明。Dan 是第一位非谷歌发布工作管理者，他和整支团队在整个版本开发流程（基于 1.5 版本发布管理者 Saad Ali 的工作成果，感谢）发现并记录各类知识成果、找出那些仍需要特殊权限方可执行的工具与进程，同时对各项任务进行优先级排序以改进 Kubernetes 的发布过程。这里，再次向整支队伍表达谢意。

用户采用情况

我们一直在密切关注 Kubernetes 的市场接纳情况，而各个行业及不同规模的企业也确实对 Kubernetes 给出了良好反馈。另外，Kubernetes 项目的用户来自全球各地，从美国田纳西州的初创企业到中国的财富五百强企业皆在其中。

• 作为中国规模最大的互联网企业之一，京东利用 Kubernetes 配合其 OpenStack 共同进行部署。京东方面目前已经将 20% 的自有应用程序迁移至 Kubernetes 之上，且每天运行之 pod 数量多达 2 万个。查看京东的更多 Kubernetes 设置情况（ http://blog.kubernetes.io/2017/02/inside-jd-com-shift-to-kubernetes-from-openstack.html）。
• 来自美国田纳西州的初创企业 Spire 公司此前曾遭遇公有云供应商服务中断，但其业务完全未受影响——这是因为 Kubernetes 能够将其工作负载迁移至其它服务区。“利用 Kubernetes，我们得以彻底告别恐慌——事实上，其自动应对流程启动后，我们油然而生一种敬畏之感。”

发布时间Kubernetes 1.6 目前已经可以在 GitHub 上（ https://github.com/kubernetes/kubernetes/releases/tag/v1.6.0）进行下载，亦可通过 get.k8s.io 获取。

参考文章

https://coreos.com/blog/kubernetes-1-6.html

http://blog.kubernetes.io/2017/03/kubernetes-1.6-multi-user-multi-workloads-at-scale.html