本文发表已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。

Kubernetes 1.16：自定义资源、全面改进的指标和卷扩展

作者：Kubernetes 1.16 发布团队 | 2019 年 9 月 18 日，星期三

我们很高兴地宣布 Kubernetes 1.16 的发布，这是我们 2019 年的第三个版本！Kubernetes 1.16 包括 31 项增强功能：8 项增强功能迁移到稳定版，8 项增强功能处于 Beta 版，15 项增强功能处于 Alpha 版。

主要主题

自定义资源

CRD 作为 Kubernetes 可扩展性机制被广泛使用，并且自 1.7 版本以来一直可用作 Beta 版。1.16 版本标志着 CRD 毕业为通用可用性 (GA)。

改进的指标

Kubernetes 以前广泛使用全局指标注册表来注册要公开的指标。通过实现指标注册表，指标以更透明的方式注册。以前，Kubernetes 指标已被排除在任何类型的稳定性要求之外。

卷扩展

此版本中有许多与卷和卷修改相关的增强功能。CSI 规范中的卷调整大小支持正在转移到 Beta 版，这允许任何 CSI 规范卷插件可调整大小。

Kubernetes API 的重大更改

随着 Kubernetes API 的发展，我们将一些 API 资源提升为稳定，其他一些资源已重新组织到不同的组。我们按照 API 版本控制策略弃用旧版本的资源并提供新版本。

一个例子是 Deployment 资源。它在 1.6 中在 extensions/v1beta1 组下引入，并且随着项目的更改已提升到 extensions/v1beta2、apps/v1beta2，最后提升到 stable 并在 1.9 中移动到 apps/v1。

重要的是要注意，在此版本之前，项目尚未停止提供任何已弃用资源的先前版本。

这意味着与 Kubernetes API 交互的人员没有被要求迁移到任何已弃用 API 对象的新版本。

在 1.16 中，如果您向 API 服务器提交一个 Deployment 并将 extensions/v1beta1 指定为 API 组，它将被拒绝，并显示以下错误：

error: unable to recognize "deployment": no matches for kind "Deployment" in version "extensions/v1beta1"

通过此版本，我们在 Kubernetes API 的成熟度方面迈出了非常重要的一步，并且不再提供已弃用的 API。我们之前的帖子 1.16 中删除的已弃用 API：您需要了解的内容会告诉您更多信息，包括哪些资源受到影响。

其他增强功能

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

CRD 已成为 Kubernetes 生态系统中扩展的基础。它们最初是对 ThirdPartyResources 原型的彻底重新设计，在 Kubernetes API 演变的来之不易的经验教训被整合后，它们最终在 1.16 中以 apiextensions.k8s.io/v1 的形式达到了 GA。随着我们过渡到 GA，重点在于 API 客户端的数据一致性。

当您升级到 GA API 时，您会注意到以前的几个可选保护措施已变为必需和/或默认行为。诸如结构化模式、修剪未知字段、验证和保护 *.k8s.io 组之类的操作对于确保 API 的寿命非常重要，并且现在更难意外错过。默认值是 API 演变的另一个重要部分，并且该支持将默认在 CRD.v1 上启用。这些与 CRD 转换机制的结合足以构建稳定的 API，随着时间的推移而发展，就像本机 Kubernetes 资源在不破坏向后兼容性的情况下发生变化一样。

对 CRD API 的更新不会在此处结束。我们有针对诸如任意子资源、API 组迁移以及可能更有效的序列化协议等功能的想法，但此处的更改预计将是可选的，并且是对 GA API 中已有的内容的补充。祝您编写 Operator 愉快！

有关如何使用自定义资源的详细信息，请参见 Kubernetes 文档。

通过 Windows 增强功能打开大门

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

Active Directory 组托管服务帐户 (GMSA) 支持正在毕业为 Beta 版，并且某些在 Alpha 支持中引入的注释正在被弃用。GMSA 是一种特定类型的 Active Directory 帐户，它使 Windows 容器能够在网络上携带标识并与其他资源通信。Windows 容器现在可以获得对外部资源的身份验证访问权限。此外，GMSA 还提供自动密码管理、简化的服务主体名称 (SPN) 管理，以及将管理委派给多个服务器上的其他管理员的能力。

添加对 RunAsUserName 的支持作为 Alpha 版本。RunAsUserName 是一个字符串，用于指定 Windows 中运行容器入口点的 Windows 身份（或用户名），并且是安全上下文 (WindowsSecurityContextOptions) 新引入的 windowsOptions 组件的一部分。

Alpha 版：通过 kubeadm 改进设置和节点加入体验

引入对 kubeadm 的 Alpha 支持，使 Kubernetes 用户可以像对 Linux 节点一样轻松地将 Windows 工作节点加入（和重置）到现有集群。用户可以利用 kubeadm 来准备 Windows 节点并将其添加到集群。操作完成后，该节点将处于就绪状态并且能够运行 Windows 容器。此外，我们还将提供一组特定于 Windows 的脚本，以在将节点加入集群之前启用先决条件和 CNI 的安装。

Alpha 版：引入对容器存储接口 (CSI) 的支持

引入对树外提供程序的 CSI 插件支持，使 Kubernetes 集群中的 Windows 节点能够利用基于 Windows 的工作负载的持久存储功能。这大大扩展了 Windows 工作负载的存储选项，添加了 FlexVolume 和树内存储插件。此功能是通过主机操作系统代理实现的，该代理能够代表容器在 Windows 节点上执行特权操作。

引入端点切片

Kubernetes 1.16 的发布包括一个激动人心的新 Alpha 功能：EndpointSlice API。此 API 为 Endpoints 资源提供了一种可扩展且可扩展的替代方案，该资源可以追溯到 Kubernetes 的最初版本。在幕后，Endpoints 在 Kubernetes 内的网络路由中扮演着重要角色。每个服务端点都在这些资源中进行跟踪 - kube-proxy 使用它们来生成代理规则，这些规则允许 Pod 在 Kubernetes 中轻松地相互通信，并且许多入口控制器使用它们将 HTTP 流量直接路由到 Pod。

提供更高的可扩展性

EndpointSlices 的一个关键目标是为 Kubernetes 服务实现更高的可扩展性。使用现有的 Endpoints API，单个实例必须包含表示与服务匹配的所有 Pod 的网络端点。随着服务开始扩展到数千个 Pod，相应的 Endpoints 资源变得非常庞大。在这个规模上简单地添加或删除一个服务端点可能会非常耗费成本。随着 Endpoints 实例的更新，每个监视 Endpoints 的代码都需要发送资源的完整副本。由于 kube-proxy 在集群中的每个节点上运行，因此需要将副本发送到每个节点。在小规模上，这不是问题，但随着集群规模的增大，它会变得越来越明显。

Endpoints to Endpoint Slice

借助 EndpointSlices，服务的网络端点被分成多个实例，从而大大减少了大规模更新所需的数据量。默认情况下，EndpointSlices 每个限制为 100 个端点。

例如，让我们以一个在 5,000 个节点上分布有 10,000 个服务端点的集群为例。单个 Pod 更新将导致使用 Endpoints API 传输约 5GB（足以填满一张 DVD）。考虑到 Endpoints 在部署的滚动更新等事件期间可能会频繁更改，这一点变得越来越重要。相同的更新将通过 EndpointSlices 更加高效，因为每个更新仅包含服务端点总数的一小部分。不是将大的 Endpoints 对象传输到每个节点，而只是将已更改的小 EndpointSlice 传输过去。在此示例中，EndpointSlices 会将传输的数据量减少大约 100 倍。

	端点	端点切片
# 资源数	1	20k / 100 = 200
# 存储的网络端点数	1 20k = 20k*	200 100 = 20k*
每个资源的大小	20k const = ~2.0 MB*	100 const = ~10 kB*
监视事件数据传输	~2.0MB 5k = 10GB*	~10kB 5k = 50MB*

提供更大的可扩展性

EndpointSlices 的第二个目标是提供一种高度可扩展的资源，以便在各种用例中发挥作用。EndpointSlices 的关键新增功能之一是新的拓扑属性。默认情况下，此属性将填充整个 Kubernetes 中使用的现有拓扑标签，指示区域和可用区等属性。当然，对于更专业的用例，此字段也可以填充自定义标签。

EndpointSlices 还包括对地址类型的更高灵活性。每个 EndpointSlice 都包含一个地址列表。多地址的初始用例是支持具有 IPv4 和 IPv6 地址的双栈端点。例如，这是一个简单的 EndpointSlice，展示了它的一种表示方式

apiVersion: discovery.k8s.io/v1alpha
kind: EndpointSlice
metadata:
  name: example-abc
  labels:
    kubernetes.io/service-name: example
addressType: IP
ports:
  - name: http
    protocol: TCP
    port: 80
endpoints:
  - addresses:
    - "10.1.2.3"
    - "2001:db8::1234:5678"
    topology:
      kubernetes.io/hostname: node-1
      topology.kubernetes.io/zone: us-west2-a

可用性

Kubernetes 1.16 可在 GitHub 上下载。要开始使用 Kubernetes，请查看这些交互式教程。您还可以使用 kubeadm 轻松安装 1.16。

发布团队

此版本的发布归功于数百位贡献技术和非技术内容的个人。特别感谢由微软首席项目经理 Lachlan Evenson 领导的发布团队。发布团队的 32 位成员协调了发布的许多方面，从文档到测试、验证和功能完整性。

随着 Kubernetes 社区的壮大，我们的发布流程展示了开源软件开发中令人惊叹的协作。Kubernetes 继续以惊人的速度获得新用户。这种增长创造了一个积极的反馈循环，更多的贡献者提交代码，创造了一个更充满活力的生态系统。迄今为止，Kubernetes 拥有超过 32,000 名个人贡献者和超过 66,000 人的活跃社区。

发布吉祥物

Kubernetes 1.16 的发布徽章的灵感来自阿波罗 16 号任务徽章。它代表了发布团队和社区的辛勤工作，是对我们在整个发布周期中作为团队分享的挑战和快乐时光的颂歌。非常感谢微软的 Ronan Flynn-Curran 创建了这个宏伟的作品。

Kubernetes 1.16 Release Mascot

Kubernetes 更新

项目速度

CNCF 继续改进 DevStats，这是一个雄心勃勃的项目，旨在可视化该项目中无数的贡献。K8s DevStats 说明了主要公司贡献者的贡献分解，以及从个人贡献者到拉取请求生命周期时间的令人印象深刻的预配置报告。过去一年，1,147 家不同的公司和超过 3,149 名个人每月为 Kubernetes 做出贡献。查看 DevStats，了解有关 Kubernetes 项目和社区整体速度的更多信息。

生态系统

为了提高生态系统的整体安全性，Kubernetes 项目领导层创建了安全审计工作组，以监督第一个第三方Kubernetes 安全审计。
Kubernetes 认证服务提供商 (KCSP) 计划已达到 100 家成员公司，从最大的跨国云、企业软件和咨询公司到小型初创公司不等。
发布了第一份Kubernetes 项目历程报告，展示了该项目的巨大增长。

KubeCon + CloudNativeCon

云原生计算基金会的旗舰会议将于 2019 年 11 月 18 日至 21 日在加利福尼亚州圣地亚哥举行，汇集了来自领先开源和云原生社区的采用者和技术专家。加入 Kubernetes、Prometheus、Envoy、CoreDNS、containerd、Fluentd、OpenTracing、gRPC、CNI、Jaeger、Notary、TUF、Vitess、NATS、Linkerd、Helm、Rook、Harbor、etcd、Open Policy Agent、CRI-O 和 TiKV，社区将齐聚四天，进一步推动云原生计算的教育和发展。立即注册！

网络研讨会

请于 2019 年 10 月 22 日加入 Kubernetes 1.16 发布团队成员，了解此版本的主要功能。请在此处注册。

参与其中

参与 Kubernetes 的最简单方法是加入与您的兴趣相符的许多特别兴趣小组 (SIG) 之一。有任何想向 Kubernetes 社区广播的内容吗？在我们的每周社区会议以及以下渠道中分享您的声音。感谢您一直以来的反馈和支持。

在 Twitter 上关注我们 @Kubernetesio，了解最新更新
在 Discuss 上加入社区讨论
在 Slack 上加入社区
在 Stack Overflow 上发布问题（或回答问题）
分享您的 Kubernetes 故事

Kubernetes 博客