2019年10月09号，星期一，我们很高兴宣布Kubernetes 1.17正式发布，这是2019年的第四次，也是最后一次发布！Kubernetes v1.17包含22个增强功能：14个增强功能已逐渐稳定，4个增强功能已进入beta版，4个增强功能已进入alpha版本。
主要内容
云厂商Lable达到通用性
作为v1.2中的beta功能添加，在v1.17中达到通用性。
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版本引入。
云厂商标签达到通用
创建节点和卷时，将基于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迁移等进行详细介绍，敬请关注！
