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

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

由 Kubernetes 1.16 发布团队 | 2019 年 9 月 18 日星期三

我们很高兴地宣布 Kubernetes 1.16 发布，这是我们 2019 年的第三个版本！Kubernetes 1.16 包含 31 项增强功能：8 项增强功能进入稳定版，8 项增强功能进入测试版，15 项增强功能进入 Alpha 版。

主要主题

自定义资源

CRD 作为 Kubernetes 扩展机制被广泛使用，自 1.7 版本以来已提供测试版。1.16 版本标志着 CRD 达到普遍可用性 (GA)。

指标大修

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

卷扩展

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

Kubernetes API 的重大变更

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

一个例子是 Deployment 资源。它在 1.6 中以 extensions/v1beta1 组引入，随着项目的变化，被提升到 extensions/v1beta2、apps/v1beta2，最后在 1.9 中提升为 stable 并移至 apps/v1。

值得注意的是，直到此版本，该项目都没有停止提供任何已弃用资源的任何先前版本。

这意味着与 Kubernetes API 交互的人员 **不** 需要迁移到任何已弃用 API 对象的新版本。

在 1.16 中，如果您将 Deployment 提交到 API 服务器并指定 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 生态系统扩展的基础。它们最初是第三方资源原型的重新设计，在 1.16 中最终达到了 GA，版本为 apiextensions.k8s.io/v1，其中整合了 Kubernetes API 演进的来之不易的经验教训。随着我们过渡到 GA，重点是 API 客户端的数据一致性。

当您升级到 GA API 时，您会注意到之前的一些可选护栏已成为必需和/或默认行为。结构化模式、修剪未知字段、验证以及保护 *.k8s.io 组对于确保您的 API 的寿命至关重要，现在更难意外遗漏。默认是 API 演进的另一个重要部分，并且该支持将默认用于 CRD.v1。这些功能与 CRD 转换机制相结合，足以构建随时间演进的稳定 API，就像原生 Kubernetes 资源在不破坏向后兼容性的情况下发生变化一样。

CRD API 的更新不会就此结束。我们有关于任意子资源、API 组迁移以及可能更高效的序列化协议等功能的想法，但从这里开始的更改预计将是可选的，并且与 GA API 中已有的功能互补。祝您操作愉快！

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

通过 Windows 增强功能打开大门

Beta：增强 Windows 容器的工作负载身份选项

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

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

Alpha：使用 kubeadm 改进设置和节点加入体验

引入对 kubeadm 的 Alpha 支持，使 Kubernetes 用户能够以与 Linux 节点相同的方式轻松地将 Windows worker 节点加入（和重置）到现有集群。用户可以使用 kubeadm 准备并将 Windows 节点添加到集群。操作完成后，节点将处于“就绪”状态并能够运行 Windows 容器。此外，我们还将提供一套 Windows 特定的脚本，以便在节点加入集群之前安装先决条件和 CNI。

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

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

引入 Endpoint Slices

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

提供更高的可扩展性

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

Endpoints to Endpoint Slice

使用 EndpointSlices，Service 的网络端点被拆分为多个实例，显著减少了大规模更新所需的数据量。默认情况下，每个 EndpointSlice 限制为 100 个端点。

例如，我们假设一个集群有 10,000 个 Service 端点分布在 5,000 个节点上。单个 Pod 更新将导致使用 Endpoints API 传输大约 5GB 的数据（这足以装满一张 DVD）。考虑到在滚动更新 Deployment 等事件期间 Endpoints 更改的频率，这变得越来越重要。使用 EndpointSlices 进行相同的更新将更有效率，因为每个 EndpointSlice 只包含 Service 端点总数的一小部分。无需将一个大的 Endpoints 对象传输到每个节点，只需传输已更改的小 EndpointSlice。在此示例中，EndpointSlices 将使传输的数据量减少大约 100 倍。

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

提供更大的可扩展性

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

EndpointSlices 还为地址类型提供了更大的灵活性。每个都包含一个地址列表。多个地址的最初用例是支持 IPv4 和 IPv6 地址的双栈端点。例如，这是一个简单的 EndpointSlice，展示了如何表示一个 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

Cloud Native Computing Foundation 的旗舰会议将于 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 博客