Kubernetes 1.17：稳定

作者：Kubernetes 1.17 发布团队 |

我们很高兴地宣布Kubernetes 1.17的发布，这是我们2019年的第四个也是最后一个版本！Kubernetes v1.17包含22项增强功能：其中14项已升级到稳定版，4项正在进入beta版，另有4项正在进入alpha版。

主要主题

云提供商标签普遍可用

云提供商标签早在v1.2版本中作为beta功能添加，v1.17版本中已普遍可用。

卷快照进入Beta阶段

Kubernetes卷快照功能现已在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 功能引入。

云提供商标签普遍可用

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

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

这些标签在此版本中已达到普遍可用状态。Kubernetes组件已更新，可以填充 GA 和 beta 标签并对两者做出反应。然而，如果您在 pod 规格中使用 beta 标签来实现节点亲和性等功能，或者在自定义控制器中使用 beta 标签，我们建议您开始将其迁移到新的 GA 标签。您可以在此处找到新标签的文档

卷快照进入Beta阶段

Kubernetes 卷快照功能现已在 Kubernetes v1.17 中进入 beta 阶段。它在 Kubernetes v1.12 中作为 alpha 功能引入，在 Kubernetes v1.13 中发布了第二个带有重大更改的 alpha 版本。本文总结了 beta 版本中的更改。

什么是卷快照？

许多存储系统（例如 Google Cloud Persistent Disks、Amazon Elastic Block Storage 以及许多本地存储系统）都提供创建持久卷“快照”的功能。快照代表了卷的即时副本。快照可以用于供应新卷（预填充快照数据）或将现有卷恢复到之前的状态（由快照表示）。

为什么要将卷快照添加到 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 添加其存储系统支持（甚至修复现有卷插件中的错误）的供应商被迫与 Kubernetes 发布流程保持一致。此外，第三方存储代码导致核心 Kubernetes 二进制文件的可靠性和安全问题，而且这些代码通常难以（在某些情况下甚至不可能）由 Kubernetes 维护者进行测试和维护。在 Kubernetes 中使用容器存储接口解决了这些主要问题。

随着更多 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 最简单的方式是加入与您兴趣相符的众多特别兴趣小组（SIG）。有什么想向 Kubernetes 社区广播的吗？在我们的每周社区会议上，并通过以下渠道分享您的声音。感谢您持续的反馈和支持。