Kubernetes 1.17稳定版正式发布


我们兴奋地宣布,Kubernetes 1.17已经正式与大家见面,这也是我们2019年以来第四次、也是最后一次进行版本发布!Kubernetes 1.17版本包含22项增强功能——其中14项增强功能已经迎来稳定版,4项增强功能进入beta阶段,另有4项增强功能进入alpha阶段。

核心主题

云服务供应商标签功能发布通用版本

作为1.2版本中的beta功能,此次1.17版正式推出云服务供应商标签的通用版本。

存储卷快照迎来Beta版

Kubernetes存储卷快照(Volume Snapshot)功能在Kubernetes 1.17中提供beta版。这项功能于1.12版中提供alpha版,并在1.13版中发布包含多项突破性调整的第二alpha版。

CSI迁移步入Beta版

用于容器存储接口(CSI)的Kubernetes入树存储插件CSI迁移基础设施如今正式迎来beta版本。CSI迁移最初以alpha版的形式登陆Kubernetes 1.14。

云服务供应商标签功能发布通用版本

在创建节点与存储卷时,我们可以根据Kubernetes集群的底层云服务供应商为其设定一系列标准标签。节点可匹配实例类型标签,节点与存储卷则可通过两项标签描述云服务供应商拓扑中的资源位置——通常表示为区域加可用区形式。

Kubernetes组件内使用的标准标签主要用于支持某些特定功能。例如,调度程序可以借此保证各Pod如存储卷的声明那样存在于同一可用区内;而当将某些Pod调度至特定部署方案中时,调度程序则会优先将各Pod分布在多个可用区之间。用户还可以利用Pod规范中的标签配置节点关联等关系。我们可以通过标准标签编写Pod规范,确保其能够在不同云服务供应商之间顺利迁移。

在新版本中,标签功能开始提供通用版本。Kubernetes组件已经更新完毕,可同时支持通用与beta两种标签形式。但是,如果大家在Pod规范中使用beta标签来实现诸如节点关联之类的功能,或者在自定义控制器中使用了beta标签,我们建议您尽快将其升级至新的通用标签版本。关于新标签的更多细节信息,请参阅以下说明文档:


存储卷快照迎来Beta版

Kubernetes存储卷快照功能在1.17版中迎来beta版。这项功能最早以alpha版的形式登陆Kubernetes 1.12,并在Kubernetes 1.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快照原语则充当基础构建块,可用于开发多种更高级的企业存储管理功能,包括应用程序或者集群级备份解决方案。

CSI迁移步入Beta版

为什么要为CSI提供迁移入树插件?

在CSI之前,Kubernetes就提供功能强大的存储卷插件系统。这些存储卷插件属于“入树”插件,意味着其代码属于Kubernetes核心代码的组成部分,随核心Kubernetes二进制代码一同提供。但是,这一机制提高了向Kubernetes中添加新的存储卷插件支持的难度。为了实现对自家存储系统的支持(或者修复现有存储卷插件中的bug),各供应商只能被迫与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稳定性不受影响。整个过程相当困难,几乎相当于为全速行驶的赛车更换轮胎。

其他更新

以下功能迎来稳定版:
  • 遵循条件的Taint Node
  • 可配置Pod进程命名空间共享
  • 通过kube-scheduler调度DaemonSet Pod
  • 动态最大存储卷数量
  • Kubernetes CSI 拓扑支持
  • 在SubPath Mount中提供环境变量扩展
  • 自定义资源定义
  • 移动高频Kubelet Heartbeats以释放API
  • 拆分 Kubernetes Test Tarball
  • 添加Watch Bookmarks支持
  • 行为驱动型一致性测试
  • 为服务负载均衡器提供中止器保护
  • 避免对各Watcher中的同一对象进行独立序列化


主要变更:
  • 添加IPv4/IPv6双协议栈支持


其他重要功能:
  • 服务路由拓扑感知(Alpha)
  • RunAsUserName for Windows


发布情况

Kubernetes 1.17目前已经通过GitHub开放下载。要了解如何使用Kubernetes,建议大家点击此处查看交互式教程。你也可以使用kubeadm快速安装1.17版本。

原文链接:Kubernetes 1.17: Stability

0 个评论

要回复文章请先登录注册