我们很高兴宣布Kubernetes 1.17的交付,这是2019年的第四次,也是最后一次发布!Kubernetes v1.17包含22个增强功能:14个增强功能已逐渐稳定,4个增强功能已进入beta版,4个增强功能已进入alpha版本。
作为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迁移等进行详细介绍,敬请关注!
参考文档:
https://kubernetes.io/blog/
https://kubernetes.io/blog/page/2/
https://kubernetes.io/blog/page/3/
登录后评论
立即登录 注册