美国时间 12 月 9 日,Kubernetes 迎来了 2019 年的最后一个新版本 1.17。

根据博客介绍,Kubernetes v1.17 包含 22 个增强功能:14 个增强功能已进入稳定,4 个增强功能已进入 beta,4 个增强功能已进入 alpha。

Major Themes

新版本主要围绕以下主题:

1 云提供商标签达到一般可用性

自从在 v1.2 中作为 beta 特性被添加进 Kubernetes,在 v1.17 中,这一特性已达到一般可用性。

创建节点和 Volume 时,Kubernetes 会基于集群底层云提供商应用一组标准标签。节点获得实例类型的标签,节点和卷都获得两个标签,按 region 和 zone 描述资源在云提供商拓扑中的位置。

Kubernetes 组件使用标准标签来支持某些功能,例如调度程序会确保将 Pod 和它们声明的 Volume 放在相同的区域中;当调度属于某个部署的 Pod 时,调度程序会优先将它们分布在各个区域中。开发者还可以使用 Pod 规范中的标签来配置诸如节点亲和性之类的东西。标准标签允许开发者编写可在不同云提供商之间移植的 Pod 规范。

在 1.17 版本中,这些标签已经可以普遍使用。Kubernetes 组件已更新,以填充 GA 和 beta 标签并对二者都做出响应。但是,如果开发者在 Pod 规范中使用 beta 标签来实现诸如节点亲和性之类的功能,或者在自定义控制器中使用 beta 标签,建议你开始将其迁移到新的 GA 标签。

有关新标签的文档:

  • node.kubernetes.io/instance-type
  • topology.kubernetes.io/region
  • topology.kubernetes.io/zone

2 Volume Snapshot 进入 beta

Kubernetes Volume Snapshot 在 v1.17 中进入 beta。此前,它在 v1.12 中作为 Alpha 引入 Kubernetes,并曾在 v1.13 中迎来重大变化。

什么是 Volume Snapshot?

许多存储系统(如 Google Cloud Persistent Disks、Amazon Elastic Block Storage 和许多本地存储系统)都可以创建 Persistent Volume(持久卷)的“快照”。快照表示 Volume 的时间点副本,可用于设置新的 Volume(预填充快照数据)或将现有 Volume 还原到先前状态(由快照表示)。

为什么要将 Volume Snapshot 添加到 K8s?

Kubernetes Volume 插件系统提供强大的抽象功能,可以自动配置、附加和挂载块和文件存储。

这些功能都基于 Kubernetes 的工作负载可移植性:Kubernetes 的目标是在分布式系统应用程序和底层集群之间创建一个抽象层,以便应用程序可以不知道底层集群的具体情况,且在部署时不需要“特定于集群”的知识。

Kubernetes Storage SIG 将快照操作确定为许多有状态工作负载的关键功能。例如,在进行数据库操作之前,数据库管理员可能需要对数据库卷进行快照。通过提供一种在 Kubernetes API 中触发快照操作的标准方式,Kubernetes 用户现在可以轻松应对上述场景,而不必使用 Kubernetes API 手动执行针对存储系统的特定操作。

Kubernetes 用户现在被授权以与集群无关的方式,将快照操作合并到他们的工具和策略中,并且可以放心地知道它将针对任意的 Kubernetes 集群,而不需要在意底层存储是什么。

此外,这些 Kubernetes 快照原语是基本的构建块,可用于为 Kubernetes 开发高级的企业级存储管理功能,如应用程序级或集群级的备份解决方案。

3 CSI Migration 测试版

自从在 v1.14 中作为 alpha 版本被引入 Kubernetes,容器存储接口(CSI)迁移在 v1.17 已步入 beta。

为什么需要将 in-tree 插件迁移到 CSI?

在 CSI 之前,Kubernetes 提供了一套功能强大的 Volume 插件系统。这些插件是“in-tree 插件”,这意味着它们的代码是核心 Kubernetes 代码的一部分,并随核心 Kubernetes 二进制文件一起发布。

然而,向 Kubernetes 添加对新的 Volume 插件的支持具有挑战性。

首先,希望向 Kubernetes 添加对其存储系统支持的供应商需要被迫与 Kubernetes 的发布进度保持一致。其次,第三方存储代码在核心 Kubernetes 二进制文件中也容易引起可靠性和安全性问题,且这些代码对于运维人员来说通常很难测试和维护。在 Kubernetes 中使用 CSI 可以解决这些主要问题。

随着越来越多 CSI 驱动程序被开发出来并投入生产,Kubernetes 开发团队希望所有用户都能从 CSI 模型中受益。但是,团队不想通过破坏现有的通用存储 API 来迫使用户进行工作负载/配置更改,相反地,他们必须用 CSI 替换“in-tree 插件” API 的后端。

那么什么是 CSI Migration 呢?

CSI Migration 允许使用相应的 CSI 驱动程序替换现有 in-tree 存储插件,如

  • kubernetes.io/gce-pd 
  • kubernetes.io/aws-ebs 

如果 CSI Migration 工作正常,Kubernetes 终端用户不会注意到差异。迁移之后,开发者可以继续使用现有接口依赖于 in-tree 存储插件的所有功能。

当 Kubernetes 集群管理员更新集群以支持 CSI Migration 时,现有的有状态部署和工作负载将继续正常工作,但这时 Kubernetes 已经将所有的存储管理操作(以前针对 in-tree 驱动程序)都交给了 CSI 驱动程序。

Kubernetes 团队一直致力于确保存储 API 的稳定性,并承诺提供平滑的升级体验。这需要仔细考虑所有现有的特性和行为,以确保向后兼容性和 API 稳定性。你可以把它想象成赛车在直道上加速时换轮子。

其他重要更新

以下是 1.17 版本中其他值得关注的变化。

1 以下特性已步入稳定

  • 允许在一定条件下污染节点。它允许节点控制器根据其观察到的一些预定义条件来污染节点,和往常一样,用户可以通过在 Pod 中添加 tolerations 来忽视被污染的节点;
  • 可配置的 Pod 进程命名空间共享。用户可以通过在 PodSpec 中设置一个选项,来配置 Pod 中的容器以共享公共 PID 命名空间;
  • 使用 kube-scheduler 调度 DaemonSet Pods。开发者可以用 kube-scheduler 调度 DaemonSet Pod,这样做的优点是 DaemonSet 可以无视 Pod 优先级和抢占进行调度;
  • 动态最大 Volume 计数。添加了对每个节点最大 Volume 的动态和通用机制的支持;
  • Kubernetes CSI 拓扑支持
  • 在子路径 mount #559,提供环境变量扩展
  • 支持自定义资源的默认设置
  • 将频繁的 Kubelet 心跳移至 Lease API。Kubelet 在节点上创建并定期续订 Lease;节点生命周期控制器将此 Lease 视为运行状况信号;
  • 拆分 Kubernetes 测试压缩包。kubernetes-test.tar.gz 现在已弃用了包含所有平台的测试二进制文件的 mondo-tarball。现在测试二进制文件分布在特定于平台的 tarball 中;
  • 添加监控书签支持。添加对监控书签的支持以减少 kube-apiserver 的负载;
  • 行为驱动一致性测试。一致性行为是预先定义的,与验证行为的测试分开;
  • 服务负载均衡器的终结器保护。添加终结器保护,以确保在也删除相关 LB 之前,不完全删除服务资源;
  • 避免为每个监控程序独立地序列化相同的对象

2 一个主要变化

添加 IPv4/IPv6 双协议栈支持。即允许将 IPv4 和 IPv6 地址分配给 Pods 和服务。

3 其他显著变化

  • 服务的拓扑感知路由(Alpha)。即让 Service 可以实现就近转发,而不是所有 Endpoint 等概率转发;
  • Windows 的 RunAsUserName

更多内容,请见官方博客和 GitHub!

https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-release-announcement/

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.17.md#downloads-for-v1170