Kubernetes 1.17：稳定性

由 Kubernetes 1.17 发布团队 |

我们很高兴宣布 Kubernetes 1.17 发布，这是我们 2019 年的第四个也是最后一个版本！Kubernetes v1.17 包含 22 项增强功能：14 项增强功能已毕业到稳定阶段，4 项迁移到 beta 阶段，还有 4 项进入 alpha 阶段。

主要主题

云提供商标签达到正式发布 (GA)

云提供商标签早在 v1.2 版本中就作为 beta 功能添加，在 v1.17 版本中达到了正式发布 (GA)。

Volume Snapshot 迁移到 Beta

Kubernetes Volume Snapshot 功能现已在 Kubernetes v1.17 中达到 beta 阶段。它在 Kubernetes v1.12 中作为 alpha 功能引入，并在 Kubernetes v1.13 中有了第二个包含重大变更的 alpha 版本。

CSI 迁移 Beta

Kubernetes 树内存储插件到容器存储接口 (CSI) 的迁移基础设施现已在 Kubernetes v1.17 中达到 beta 阶段。CSI 迁移是在 Kubernetes v1.14 中作为 alpha 功能引入的。

云提供商标签达到正式发布 (GA)

创建节点和卷时，会根据 Kubernetes 集群底层的云提供商应用一组标准标签。节点获得一个实例类型标签。节点和卷都会获得两个标签，描述资源在云提供商拓扑中的位置，通常组织为区域 (regions) 和可用区 (zones)。

标准标签被 Kubernetes 组件用于支持某些功能。例如，调度器会确保 Pod 被放置在其所请求卷所在的同一可用区；当调度属于某个部署的 Pod 时，调度器会优先将它们分散到不同的可用区。你也可以在 Pod 规范中使用这些标签来配置诸如节点亲和性等功能。标准标签允许你编写可在不同云提供商之间移植的 Pod 规范。

这些标签在此版本中正在达到正式发布 (GA)。Kubernetes 组件已更新，以填充 GA 和 beta 标签，并对两者都作出响应。但是，如果你在 Pod 规范中使用了 beta 标签来配置诸如节点亲和性等功能，或者在你的自定义控制器中使用了它们，我们建议你开始将其迁移到新的 GA 标签。你可以在这里找到新标签的文档。

Volume Snapshot 迁移到 Beta

Kubernetes Volume Snapshot 功能现已在 Kubernetes v1.17 中达到 beta 阶段。它在 Kubernetes v1.12 中作为 alpha 功能引入，并在 Kubernetes v1.13 中有了第二个包含重大变更的 alpha 版本。本文总结了 beta 版本中的变更。

什么是 Volume Snapshot？

许多存储系统（如 Google Cloud Persistent Disks、Amazon Elastic Block Storage 和许多本地存储系统）提供了创建持久卷“快照”的能力。快照代表了卷的时间点拷贝。快照可用于配置新卷（预填充快照数据）或将现有卷恢复到先前状态（由快照表示）。

为什么要将 Volume Snapshots 添加到 Kubernetes？

Kubernetes 卷插件系统已经提供了一个强大的抽象，自动化了块存储和文件存储的配置、连接和挂载。

支撑所有这些功能的是 Kubernetes 工作负载可移植性的目标：Kubernetes 旨在创建分布式系统应用和底层集群之间的抽象层，以便应用能够不依赖于其运行集群的具体细节，并且应用部署不需要“集群特定”的知识。

Kubernetes Storage SIG 将快照操作确定为许多有状态工作负载的关键功能。例如，数据库管理员可能想在开始数据库操作之前为数据库卷创建快照。

通过在 Kubernetes API 中提供触发快照操作的标准方式，Kubernetes 用户现在可以处理这样的用例，而无需绕过 Kubernetes API（并手动执行存储系统特定操作）。

取而代之的是，Kubernetes 用户现在能够以集群无关的方式将快照操作纳入他们的工具和策略中，并且放心地知道它将适用于任意 Kubernetes 集群，无论底层存储是什么。

此外，这些 Kubernetes 快照原语充当基本构建块，解锁了为 Kubernetes 开发高级企业级存储管理功能的能力，包括应用或集群级别的备份解决方案。

你可以在关于将 CSI 卷快照发布到 beta 的博客文章中阅读更多。

CSI 迁移 Beta

为什么我们将树内插件迁移到 CSI？

在 CSI 之前，Kubernetes 提供了一个强大的卷插件系统。这些卷插件是“树内”的，意味着它们的代码是 Kubernetes 核心代码的一部分，并随 Kubernetes 核心二进制文件一同发布。然而，向 Kubernetes 添加对新卷插件的支持具有挑战性。想要向 Kubernetes 添加对其存储系统支持（甚至修复现有卷插件中的 bug）的供应商，被迫与 Kubernetes 发布流程保持一致。此外，第三方存储代码导致了核心 Kubernetes 二进制文件中的可靠性和安全问题，并且对于 Kubernetes 维护者来说，这些代码通常难以（在某些情况下甚至不可能）测试和维护。在 Kubernetes 中使用容器存储接口 (CSI) 解决了这些主要问题。

随着更多 CSI 驱动被创建并变得生产就绪，我们希望所有 Kubernetes 用户都能享受到 CSI 模型的好处。然而，我们不想通过破坏现有的正式发布存储 API 来强制用户进行工作负载/配置更改。前进的道路很明确——我们将不得不使用 CSI 来替换“树内插件” API 的后端。什么是 CSI 迁移？

CSI 迁移工作使得能够使用相应的 CSI 驱动替换现有的树内存储插件，例如 kubernetes.io/gce-pd 或 kubernetes.io/aws-ebs。如果 CSI 迁移正常工作，Kubernetes 终端用户应该不会注意到差异。迁移后，Kubernetes 用户可以继续使用现有接口来依赖树内存储插件的所有功能。

当 Kubernetes 集群管理员更新集群以启用 CSI 迁移时，现有的有状态部署和工作负载将继续像往常一样运行；然而，在幕后，Kubernetes 会将所有存储管理操作（之前指向树内驱动）的控制权交给 CSI 驱动。

Kubernetes 团队一直在努力工作，以确保存储 API 的稳定性并实现平滑升级体验的承诺。这包括对所有现有功能和行为进行细致的统计，以确保向后兼容性和 API 稳定性。你可以将其想象成赛车在直道上飞驰时更换轮胎。

你可以在关于CSI 迁移到 beta 的博客文章中阅读更多。

其他更新

毕业到稳定 💯

主要变更

其他值得注意的功能

可用性

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

发布团队

此版本的发布得益于数百名贡献了技术和非技术内容的个人的共同努力。特别感谢由 Guinevere Saenger 领导的发布团队。发布团队的 35 名成员协调了发布的许多方面，从文档到测试、验证和功能完整性。

随着 Kubernetes 社区的发展，我们的发布流程展示了开源软件开发中协作的惊人示范。Kubernetes 继续快速获得新用户。这种增长创造了一个积极的反馈循环，更多贡献者提交代码，从而创造了一个更活跃的生态系统。截至目前，Kubernetes 已有超过 39,000 名个人贡献者，以及一个超过 66,000 人的活跃社区。

网络研讨会

加入 Kubernetes 1.17 发布团队的成员，在 2020 年 1 月 7 日学习了解此版本中的主要功能。请在此注册。

参与进来

参与 Kubernetes 的最简单方式是加入众多与你兴趣一致的特别兴趣小组 (SIGs) 之一。你有什么想向 Kubernetes 社区广播的吗？在我们的每周社区会议上，以及通过以下渠道表达你的声音。感谢你持续的反馈和支持。