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

概述

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