Kubernetes 1.16: 自定义资源、重塑指标与卷扩展

我们很高兴地宣布 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 资源提升到 stable 阶段，其他一些则被重新组织到不同的组。我们根据 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 生态系统中扩展的基础。它们作为 ThirdPartyResources 原型的全新重新设计而启动，并在 1.16 版本中随 apiextensions.k8s.io/v1 最终达到 GA，这整合了从 Kubernetes API 演进中获得的宝贵经验。随着我们过渡到 GA，重点在于 API 客户端的数据一致性。

升级到 GA API 后，您会注意到一些之前可选的防护措施已成为必需和/或默认行为。诸如结构化 Schema、剪除未知字段、验证以及保护 *.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) 管理以及将管理委托给多个服务器上其他管理员的能力。

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

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

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

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

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

介绍 Endpoint Slices

Kubernetes 1.16 版本包含一个令人兴奋的新 Alpha 功能：EndpointSlice API。此 API 为 Endpoints 资源提供了一个可扩展且可伸缩的替代方案，该资源可追溯到 Kubernetes 的最初版本。在幕后，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 在集群中的每个节点上运行，因此需要将副本发送到每个节点。在小规模下，这不是问题，但随着集群变大，它变得越来越明显。

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

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

提供更强的可扩展性

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

关于 Endpoint Slices 的更多信息

EndpointSlices 是 Kubernetes 1.16 中的一个 Alpha 功能，默认不启用。Endpoints API 将继续默认启用，但我们正在努力将最大的 Endpoints 用户迁移到新的 EndpointSlice API。值得注意的是，Kubernetes 1.16 中的 kube-proxy 包含了对 EndpointSlices 的 Alpha 支持。

官方 Kubernetes 文档包含有关 EndpointSlices 的更多信息以及如何在集群中启用它们。此外，还有一个精彩的 KubeCon 演讲，提供了关于开发此 API 初衷的更多背景信息。

重要特性更新

• Topology Manager，一个新的 Kubelet 组件，旨在协调资源分配决策以提供优化的资源分配。
• IPv4/IPv6 双栈 使得可以为 Pods 和 Services 同时分配 IPv4 和 IPv6 地址。
• Cloud Controller Manager 迁移的扩展。

可用性

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

发布团队

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

随着 Kubernetes 社区的发展，我们的发布流程代表了开源软件开发中协作的惊人体现。Kubernetes 以快速的速度获得新用户。这种增长创造了一个积极的反馈循环，更多贡献者提交代码，从而形成一个更活跃的生态系统。迄今为止，Kubernetes 已有超过 32,000 名独立贡献者，活跃社区成员超过 66,000 人。

发布吉祥物

Kubernetes 1.16 发布徽章松散地受到了阿波罗 16 号任务徽章的启发。它代表了发布团队和社区的辛勤工作，并致敬我们在整个发布周期中共同面对的挑战和享受的美好时光。非常感谢 Microsoft 的 Ronan Flynn-Curran 创作了这件宏伟的作品。

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 故事

• ←上一篇
• 下一篇→