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 存储 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 迁移工作使替换现有的内部存储插件（如 kubernetes.io/gce-pd 或 kubernetes.io/aws-ebs）及其相应的 CSI 驱动程序成为可能。如果 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 社区广播一些内容吗？在我们的每周社区会议上，以及通过以下渠道分享您的声音。感谢您持续的反馈和支持。