Pod 对象也能被淘汰么

原文：Could Kubernetes Pods Ever Become Deprecated?

作者：Martin Heinz

随着时间的推移，所有的软件项目都会加入新的功能和 API，与此相对地，也会有功能和 API 被移除。Kubernetes 这样的大型项目也并无不同，但是核心 API 的废弃和删除，始终有些含混，Kubernetes 中的核心对象或者说是 API，例如 Pod、Deployment 和 Service，是不是可以删除呢？如果答案是肯定的，那么该如何进行呢？

长话短说

GA 状态的核心 API，例如 v1 API 中的对象也是可能淘汰的。Kubernetes 中的的淘汰话题需要分为 API、CLI 以及 FeatureGate 这三个方面，每方面又会有自己的成熟阶段，例如 Alpha、Beta 或者 GA，这些成熟度的定义，就代表了在什么时间、什么条件下进行淘汰操作—— Pod 这样的东西也不能例外。因此本文尝试对这一问题进行进一步的探讨，看看过往的例子和一些未来的假设。

分而治之

不同的对象或功能有不同的规则，所以在讨论淘汰规则之前，首先对这些淘汰目标进行分类：

• REST 对象：这是绝大多数人最多打交道的东西，因此也是最引人关注的方向，这里包括了 Pod 或者 Deployment 这样的顶层对象，也包含了它们的成员字段，例如 containers、volumes 或者 env；另外还有一些常量，例如 imagePullPolicy 使用的 Always、IfNotPresent 等。
• CLI 和命令行参数：这一部分内容是针对客户端的。最容易想到的可能就是 kubectl，其实还包含了 kubelet、kube-apiserver 或者 kube-scheduler 及其子命令和选项等。
• 功能和行为：各种不同成熟度的试验特性是无法用 API 或者 CLI 来表达的，但是它们也应该有自己的淘汰过程和节奏。
• 指标：最后 Kubernetes 的各个组件还在 /metrics 端点中提供了大量指标。这些指标可能会在监控等系统中使用，因此也不能直接删除，而需要有一定的淘汰规则。

REST 对象

REST API 需要遵守一个普遍规则——官宣淘汰之时，API 版本至少要支持：

• GA：12 个月或者 3 次发版（取最长时间）
• Beta：9 个月或者 3 次发版（取最长时间）
• Alpha：0 次发版

看起来好像非常清晰，其实里面包含了很多其它（可能很难理解）的规则，所以我们先进入示例环节来进行澄清。假设有一个叫做 Task 的 API 对象（有趣的事实：这是 Pod 的原名，请参见 First Commit of Kubernetes）。这个对象处于 GA 状态，其 API 版本为 v1，淘汰需要经过什么过程呢？

Kubernetes 版本	API 版本	推荐	行为
X	v1	v1	此时 Task 对象处于 GA 状态，并没有进入淘汰周期
X+1	v2alpha1, v1	v1	引入 v2alpha1，宣布 Task 开始淘汰，此时 v2alpha1 中并不包含 Task
X+2	v2alpha2，v1	v1	用 v2alpha2 替代 v2alpha1
X+3	v2beta1, v1	v1	v2alpha2 被 v2beta1 替换
X+4	v2beta2、v2beta1、v1	v1	引入 v2beta2，v2beta1 依旧存在，但是开始淘汰
X+5	v2、v2beta2、v2beta1、v1	v1	引入 v2，包括首选使用的 v1 在内的所有其他版本进入淘汰周期
X+6	v2、v2beta2、v2beta1、v1	v2	没有移除任何 API，但是 v2 已经成为首选版本
X+7	v2、v2beta2、v1	v2	移除 v2beta1
X+8	v2、v1	v2	移除 v2beta2
X+9	v2、v1	v2	没有什么变化，按照规则，v1 必须继续存活一个版本
X+10	v2	v2	最终删除了 v1，其中的 Task 对象也宣告终结

从上表来看，如果在 v2alpha1 开始淘汰 Task 对象，就需要 9 个版本才能最终完成。读者需要注意的是，根据当下的发布节奏，每年发版三次，整个淘汰流程可能需要三年多。

有些对象虽然没进入 GA，但是用户已经将其视为 GA 并进行使用。例如 1.19 中才进入 GA 的 Ingress，或者 1.21 的 CronJob。这种 beta 甚至是 alpha 的版本，淘汰节奏就不会这么宽松了。要检查资源所属的分类，可以运行 kubectl api-resources | grep beta，读取所有集群中的所有 beta API 对象类型。

REST 对象字段成员、常量以及对象结构，淘汰规则跟对象是一致的。也就是说，imagePullPolicy 中使用的 Always、IfNotPresent 和 Never 不会随机变化也不会从一节挪到另一节。

例如 PodSecurityPolicy 可能是近期的一个最大变化。这个 API 对象会从 v1beta1 转向 EOL，在 v1.21 中开始淘汰，在 v1.25 中被移除。详情可参见 KEP_2579。

另一个进行中的重要淘汰就是 selfLink 字段，这是 KEP-1164 中的一部分，这一变更的过程记录在 Github Issue 之中。

如果你有兴趣了解其它的淘汰过程，希望了解其中的逻辑关系以及整个流程，可以在 kubernetes/enhancements repository 搜索包含 deprecate 关键字的 KEP。

客户端和参数

和 REST 对象类似，kubectl 和 kubelet 的子命令及其参数也是有自己的淘汰策略的。

这部分的规则比前面的案例要简单，对于 kubectl 这样的面对客户的组件来说：

• GA：12 个月或者两次发版（取最长时间）
• Beta：3 个月或者 1 次发版（取最长时间）
• Alpha：0 次发版

对于 kubelet、kube-apiserver 或者 kube-scheduler 这样的面向管理员的组件：

• GA：12 个月或者两次发版（取最长时间）
• Beta：3 个月或者 1 次发版（取最长时间）
• Alpha：0 次发版

近期这方面的最知名案例应该算是 kubelet 中的 dockershim 了。在 KEP-2221 中讲到，在 v1.20 中设置淘汰，在 v1.24 中进行删除。

这方面的另一个显著目标就是 seccomp Profile 即将 GA，这一过程在 KEP-135 中进行跟进。这个特性并不会真正地对参数和 CLI 产生影响，但是它的 GA 过程会要求淘汰 kubelet 的 --seccomp-profile-root，详情请参见 SIG Node 文档。

所以这一节的淘汰过程是比较较宽松的，但是如果你正在自动化过程中使用 kubectl alpha，最好在升级集群和 CLI 之前检查一下它的淘汰情况。

Feature Gate

Kubernetes 每个版本中都会包含很多的实验性功能。这些功能被称为 Feature Gate，它们使用 Key/Value 形式的开关进行控制。

这些特性既然是用于试验的，其淘汰策略自然和其它的 Kubernetes 对象有所不同。随着特性的逐步成熟，它的 Feature Gate 也会发生变化。Alpha 阶段的功能，其 Feature Gate 会被缺省关闭；而 Beta 阶段的功能则会缺省打开；如果该功能进入 GA，对应的 Feature Gate 就不再需要了，会被淘汰，无法操作。

Alpha 功能可能随时消失；Beta 功能可能会在 1 次发版以后删除；进入 GA 的功能则会在两次发版后删除。

这方面的最好例子就是官方的 Feature Gate 列表。以其中包含的 AffinityInAnnotations 为例，它就是从 Alpha 淘汰的；而 BlockVolume、DryRun 或者 EndpointSlice 则已经进入了 GA。我还没有看到过有从 Beta 被淘汰的 Feature Gate。

如果打开了某些 Feature Gate，在集群升级之前一定要检查一下，防止一些特性因升级被删除。

指标

最后一个需要关注的就是监控指标，可能会有监控工具对指标进行聚合和消费，因此其淘汰过程也是需要多加小心的。和前面章节中的内容不同，指标只分成两类——稳定和 Alpha，声明淘汰之后，稳定指标可以在 3 次发版之后移除，Alpha 可以随时移除。

例如 rest_client_request_latency_seconds 就是一个值得观察的指标淘汰案例，这个过程在 v1.17 的版本说明里体现。

如果想要了解更多监控指标生命周期的问题，可以查看一下系统指标的相关文档。

结论

现今很多项目会采用“有破坏性的快速演进”方法来进行淘汰工作，其中往往会包含繁杂的手工操作，所以 Kubernetes 这样的大项目提出了如此深思熟虑的启用过程，让用户有时间来进行有计划的迁移，这是让人非常愉快的。

那么这篇文章的要点在哪里：

• 所有东西都可能淘汰？是的？
• 需要担心吗？显然不用。

看看淘汰的时间线长度，就知道无需担心突然袭击了。但是为长远计，应该检查版本说明，注意其中是否有你正在使用的 Alpha 功能。还应该阅读 淘汰 API 指南，其中会列出所有未来将要移除的 API 对象。最后要说明的是，外部供应商的 CRD 的生命周期是自行负责的，可能和官方策略并不一致。