一文看懂Kubernetes v1.16！
Kubernetes 1.16 徽章
灵感源自阿波罗16号任务徽章
译者：小灵
技术校对：oilbeater
9月18日，Kubernetes v1.16重磅发布！这是2019年以来发布的第三个版本! Kubernetes 1.16包含31个增强功能：8个增强趋于稳定，8个进入beta版，15个在alpha版。
01
主题
1. Custom resources：CRD作为Kubernetes的扩展机制得到了广泛的使用，并且从1.7版本开始就已经在beta版中可用。1.16版本标志着CRDs正式进入通用可用性(GA)
2.Overhauled metrics：Kubernetes之前广泛使用一个全局metrics registry来注册要公开的metrics。通过实现metrics registry，metrics以更透明的方式注册。以前，Kubernetes metrics被排除在任何类型的稳定性需求之外。
3.Volume Extension：这个版本中有很多与Volume和Volume修改相关的增强功能。CSI规范中的Volume调整支持正在转向beta版，它允许任何CSI规范的Volume plugin都可以调整大小。
02
其他增强
自定义资源达到通用可用性
CRD已经成为Kubernetes生态系统扩展的基础。从重新设计第三方资源原型开始，最终在1.16中通过apiextensions.k8s.io/v1实现了GA，且整合了大量Kubernetes 发展过程中积累的API相关演化经验。当转换到GA时，我们的首要重点是API客户端的数据一致性。
当您升级到GA API时，您会注意到一些以前可选的护栏已经成为必需的或默认的行为。比如结构模式、删除未知字段、验证和保护*.k8.io组对于确保API的使用寿命非常重要，而且现在更难以意外遗漏。default是API演化的另一个重要部分，默认情况下，CRD.v1将启用该支持。这些以及CRD转换机制的组合足以构建随时间演变的稳定API，就像Kubernetes本地资源在不破坏向后兼容性的情况下发生了变化一样。
CRD API的更新不会就此结束。我们对任意子资源、API组迁移以及更高效的序列化协议等特性都有一些想法，但是这里的变化本质上是可选的，并且与GA API中已有的特性互补。
有关如何使用自定义资源的详细信息，请参阅Kubernetes文档。
利用Windows增强开启新的大门
Beta:增强Windows容器的工作负载标识选项
Active Directory Group Managed Service Account(GMSA)支持正在逐步升级到beta版，而在alpha版支持中的某些注释将被弃用。GMSA是一种特定类型的Active Directory帐户，允许Windows容器通过网络传输身份标识并与其他资源通信。Windows容器现在可以通过身份验证访问外部资源。此外，GMSA还提供了自动密码管理、简化的服务主体名称(SPN)管理以及跨多个服务器将管理委托给其他管理员的能力。
在alpha版本中，我们添加了对RunAsUserName的支持。RunAsUserName是一个字符串，指定windows中的windows标识(或用户名)来运行容器的入口点，它同时也是securityContext (WindowsSecurityContextOptions)新引入的windowsOptions组件的一部分。
Alpha：使用kubeadm改进设置和节点连接体验
引入对kubeadm的alpha支持，使Kubernetes用户能够轻松地将Windows工作节点加入（并重置）到现有集群，操作方式与Linux节点一样。用户可以使用kubeadm来准备和添加Windows节点到群集。操作完成后，该节点将处于Ready状态并能够运行Windows容器。此外，我们还将提供一组Windows的特定脚本，旨在配合节点添加的其它资源与CNI安装需求。
Alpha:引入对容器存储接口(CSI)的支持
引入对树外提供者的CSI插件支持，使Kubernetes集群中的Windows节点能够利用持久存储功能运行基于Windows的工作负载。这极大地扩展了Windows工作负载的存储选项，使用户能在FlexVolume和in-tree存储插件之外拥有新的选择。此功能通过主机OS代理实现，该代理支持代理容器在Windows节点上执行特权操作。
引入Endpoint切片
Kubernetes 1.16版本还包含一项令人兴奋的全新alpha功能：Endpoint切片。这为endpoint资源提供了一个可伸缩和可扩展的替代方案。在后端，这些资源在Kubernetes内部的网络路由中扮演着重要的角色。每个网络endpoint都在这些资源中受到追踪，kube-proxy利用如上endpoint生成代理规则，允许pod在Kubernetes中如此轻松地相互通信。
提供更强大的可扩展性
Endpoint切片的一个关键目标是为Kubernetes服务提供更强大的可扩展性。对于现有endpoint资源，单个资源必须包含表示与某项服务相关联的所有pod的网络endpoint。随着服务扩展至数千个pod，相应的endpoint资源变得非常大。如果简单地对服务添加或删除一个endpoint可能带来可观的成本。随着endpoint资源的更新，代码中与该endpoint相关的部分都需要获取一份关于该资源的完整副本。群集中的每个节点运行kube-proxy时，需要将副本发送到每个节点。在小范围内，这不是问题，但随着集群变大，影响会变得越来越明显。
比如，在一个拥有5,000个节点和1MB endpoint对象的集群中，任何更新都会导致大约5GB的传输（这足以填满一张DVD光盘）。考虑到endpoint在部署期间频繁滚动更新等事件，这将是一笔巨大的资源浪费。
使用endpoint切片，服务的网络endpoint可以拆分为多个资源，从而显着减少大规模更新所需的数据量。默认情况下，每个endpoint切片最多包含100个endpoint。
例如，我们拥有20,000个网络endpoint，分布在拥有5,000个节点的集群上。利用endpoint切片更新单个endpoint的效率会更高，因为每个endpoint仅包含网络endpoint总数的一小部分。相较于以往将大endpoint对象传输至各个节点的方式，现在我们只需要传输已经变更的小型endpoint切片。实际效果就是，现在更新操作的数据传输量仅相当于以往的约二百分之一。
endpoint切片的第二个主要目标，是提供一种在各种用例中具有高度可扩展性和实用性的资源。endpoint切片的一个关键添加还涉及新的拓扑属性。默认情况下，这将填充Kubernetes中使用的现有拓扑标签，用以指示region与zone等属性。当然，这个字段也可以填充自定义标签以及更专业的用例。
endpoint切片还实现了更大的地址类型灵活性。每个都包含一个地址列表。多地址初始用例同时支持具有IPv4和IPv6地址的双栈endpoint。
Kubernetes文档提供了有关endpoint切片的更多信息。作为Kubernetes 1.16中的alpha功能，默认情况下不会启用，但大家可以参阅说明文档了解如何在集群中启用他们。
03
其他值得注意的功能更新
-Topology Manager拓扑管理器是一种新的Kubelet组件，旨在协调资源分配决策，以提供优化的资源分配； -IPv4 / IPv6双栈可以将IPv4和IPv6地址分配给Pod和service； -Cloud Controller Manager Migration提供更多迁移扩展选项； -继续弃用extensions / v1beta1，apps / v1beta1和apps / v1beta2 API。这些扩展已在1.16中遭到淘汰！
相关链接：
https://kubernetes.io/blog/2019/09/18/kubernetes-1-16-release-announcement/