我们很高兴宣布Kubernetes 1.17的交付，这是2019年的第四次，也是最后一次发布！Kubernetes v1.17包含22个增强功能：14个增强功能已逐渐稳定，4个增强功能已进入beta版，4个增强功能已进入alpha版本。
主要议题
云提供商标签达到GA
作为v1.2中的beta功能添加，v1.17中达到GA。
Volume Snapshot移至Beta版
Kubernetes卷快照功能现在是Kubernetes v1.17中的beta版。它在Kubernetes v1.12中被引入为alpha，kubernetesv1.13中引入第二个alpha，并有了突破性的改变。
CSI迁移Beta版
容器存储接口（CSI）迁移基础架构的Kubernetesin-tree存储插件现在是Kubernetes v1.17中的beta版。CSI迁移在Kubernetes v1.14中作为Alpha版本引入。
云提供商标签达到GA
创建节点和卷时，将基于Kubernetes集群的底层云提供程序应用一组标准标签。节点将获取实例类型的标签。节点和卷都有两个标签，用于描述资源在云提供程序拓扑中的位置，通常按区域进行组织。
Kubernetes组件使用标准标签来支持某些功能。例如，调度程序将确保将pod与声明的卷放在同一个区域中；当调度某个Pod时，调度程序将优先考虑跨区域分布。您还可以使用pod规范中的标签来配置类似节点关联的内容。标准标签允许编写在不同云提供商之间可迁移的pod规范。
在这个版本中，这些标签已经可以普遍使用。Kubernetes组件已经更新，以填充GA和beta标签，并对两者做出反应。但是，如果您在pod规范中使用beta标签来实现节点关联性等功能，或者在自定义控制器中使用beta标签，我们建议您从一开始就将它们迁移到新的GA标签。你可以在这里找到新标签的文档：
node.kubernetes.io/instance-type
topology.kubernetes.io/region
topology.kubernetes.io/zone
Volume Snapshot移至Beta
Kubernetes Volume Snapshot功能现在是Kubernetes v1.17中的beta版。它在Kubernetes v1.12中作为Alpha引入，在Kubernetes v1.13中引入第二个Alpha版本，且具有了重大突破。
什么是Volume Snapshot（卷快照）？
许多存储系统（例如Google Cloud永久磁盘，Amazon Elastic Block Storage和许多本地存储系统）都可以创建持久卷的“快照”。快照表示卷的时间点副本。快照可用于设置新卷（预填充快照数据）或将现有卷还原到先前状态（由快照表示）。
为什么要将Volume Snapshot添加到Kubernetes？
Kubernetes卷插件系统已经提供了强大的抽象功能，可以自动配置，附加和安装块和文件存储。
所有这些特性都是为了支持Kubernetes的工作负载可移植性目标：Kubernetes旨在在分布式系统应用程序和基础集群之间创建一个抽象层，以便应用程序可以与它们所运行的集群的具体情况隔离，并且应用程序部署不需要“特定于集群”的知识。
Kubernetes Storage SIG将快照操作确定为许多有状态工作负载的关键功能。例如，数据库管理员可能希望在数据库操作之前对数据库卷进行快照。
通过提供一种在Kubernetes API中触发快照操作的标准方式，Kubernetes用户现在可以处理这样的用例，而不必使用Kubernetes API（并手动执行存储系统特定的操作）。
Kubernetes用户现在可以使用与群集无关的方式，将快照操作合并到他们的工具和策略中，并轻松知道它将在任意Kubernetes群集生效，而与基础存储无关。
此外，这些Kubernetes快照作为基本的构建块，可释放为Kubernetes开发高级企业级存储管理功能的能力：包括应用程序或集群级备份解决方案。
CSI迁移Beta版
为什么我们要将in-tree插件迁移到CSI？
在CSI之前，Kubernetes提供了功能强大的卷（volume）插件系统。这些批量插件是“in-tree插件”，这意味着它们的代码是核心Kubernetes代码的一部分，并随核心Kubernetes二进制文件一起发布。但是，向Kubernetes添加对新的卷插件的支持是一个挑战。想要向Kubernetes添加对其存储系统支持（甚至修复现有的volume插件中的bug）的供应商被迫与Kubernetes的发布过程保持一致。此外，第三方存储代码在核心Kubernetes二进制文件中引起可靠性和安全性问题，对于Kubernetes的维护者来说，测试和维护这些代码通常很困难(甚至在某些情况下是不可能的)。在Kubernetes中使用容器存储接口可以解决这些主要问题。
随着更多CSI驱动程序的创建和生产准备就绪，我们希望所有Kubernetes用户都能从CSI模型中受益。但是，我们不想通过破坏现有的通用存储API来强迫用户进行工作负载/配置的更改。前方的道路很明确-我们必须用CSI替换后端in-tree插件API。
通过CSI迁移，可以使用相应的CSI驱动程序替换现有的in-tree存储插件，例如kubernetes.io/gce-pd或kubernetes.io/aws-ebs。如果CSI迁移正常，Kubernetes最终用户应该不会注意到这一点。迁移后，Kubernetes用户可以继续使用现有接口依赖in-tree存储插件的所有功能。
当Kubernetes集群管理员更新集群以启用CSI迁移时，现有的有状态部署和工作负载将继续发挥作用；但是，在背后，Kubernetes将所有存储管理操作（以前都是指向in-tree驱动程序）的控制权交给了CSI驱动程序。
Kubernetes团队一直在努力确保存储API的稳定性，并确保平滑的升级体验。这涉及对所有现有功能和行为的细致考虑，以确保向后兼容和API稳定性。你可以把它想象成赛车在直道上加速时换轮子。
其他更新
稳定性毕业
Taint Node by Condition
Configurable Pod Process Namespace Sharing
ScheduleDaemonSet Pods by kube-scheduler
DynamicMaximum Volume Count
KubernetesCSI Topology Support
Provide Environment Variables Expansion in SubPathMount
Defaultingof Custom Resources
Move Frequent Kubelet Heartbeats To Lease Api
Break Apart The Kubernetes Test Tarball
Add Watch Bookmarks Support
Behavior-Driven Conformance Testing
Finalizer Protection For Service Loadbalancers
Avoid Serializing The Same Object Independently ForEvery Watcher
重要变化
· 添加IPv4 / IPv6双协议栈支持
其他重要特性
拓扑感知服务路由（Alpha）
RunAsUserName for Windows
可用性
Kubernetes 1.17可以在GitHub上下载。
发布团队
这一版本是经由数百个人的努力，技术和非技术人员都在贡献内容，才使得发布成为可能。特别感谢Guinevere Saenger领导的发布团队。发布团队中的35人协调了发布的各个方面，从文档到测试、验证和功能完整性。
随着Kubernetes社区的发展，我们的发布过程很好地展示了开源软件开发中的协作。Kubernetes得以持续快速吸引新用户。这种增长创造了一个积极的反馈周期，更多的贡献者提交代码，从而创建一个更加活跃的生态系统。到目前为止，Kubernetes已经有超过39000位个人贡献者，活跃社区超过66,000人。
接下来的文章，我们还将会对Kubernetes 1.17中的新特性 Volume Snapshot卷快照、CSI迁移等进行详细介绍，敬请关注！