Kubernetes 1.16 发布，一文读懂其重磅新特性！

iMike

发布于 2019-09-24 15:46:05

1.4K0

发布于 2019-09-24 15:46:05

美国时间 9 月 18 日，Kubernetes 迎来了 2019 年的第三个新版本 1.16。根据 Release Note 介绍，Kubernetes v1.16 由 31 个增强功能组成：8 个进入稳定，8 个进入 Beta，15 个进入 Alpha。

此次发行版源自数百名技术与非技术贡献者的共同努力，随着 Kubernetes 社区的不断发展，我们的发布过程也代表着开源软件开发协作领域的又一惊人成功。

Kubernetes 仍在不断获得新用户，快速成长本身则创造出积极反馈周期，吸引更多贡献者提交代码，最终建立起强大且极具活力的社区群体。截至目前，Kubernetes 拥有超过 32000 名个人贡献者，社区成员总量则超过 66000 人。

这里，我们整理了 Kubernetes 1.16 的亮点内容详细介绍给大家。

核心主题

Kubernetes 1.16 新版本中主要更新了以下几个核心内容。

Custom resources：CRD 是服务于一种新的资源类型，主要是对 Kubernetes 的一种扩展机制，目前已得到了广泛的使用。自 1.7 版本以来，CRD 已经在 Beta 版中可用。在 1.16 版本中，CRD 正式步入通用可用性（GA）。
Admission Webhook：Admission Webhooks 作为 Kubernetes 的扩展机制也被广泛使用，并且自 1.9 版本以来已经在 Beta 版中可用。在 1.16 版本中，Admission Webhook 也正式步入通用可用性（GA）。
Overhauled metrics：Kubernetes 之前广泛使用一个全局 Metrics Registry 来注册需要公开的各项指标。通过实现 Metrics Registry，Metrics 可以以更透明的方式注册。而在这之前，各类稳定性要求都禁止使用 Kubernetes Metrics 。
Volume Extension：新版本中有很多与 Volume 和 Volume 修改相关的增强功能。CSI 规范中的 Volume 调整支持正在转向 Beta 版，它允许任何 CSI 规范的 Volume Plugin 都可以调整大小。

其他增强

自定义资源达到通用可用性

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 中已有的特性互补。

利用 Windows 增强开启新的大门

Beta:增强 Windows 容器的工作负载标识选项

Active Directory Group Managed Service Account (GMSA) 支持正在逐步升级到beta版，而在 Alpha 版支持中的某些注释将被弃用。

GMSA 是一种特定类型的 Active Directory 帐户，允许 Windows 容器通过网络传输身份标识并与其他资源通信。

Windows 容器现在可以通过身份验证访问外部资源。此外，GMSA 还提供了自动密码管理、简化的服务主体名称 (SPN) 管理以及跨多个服务器将管理委托给其他管理员的能力。

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 功能，默认情况下不会启用，但大家可以参阅说明文档了解如何在集群中启用他们。