上篇学习了Nodes的注册、维护，本篇学习关于控制面与节点间通信、控制器和控制器模式、租约、cgroupsv2、CRI运行时、垃圾回收等主题。如果不需要深入研究，只需要直接跳到最后总结部分。

节点与控制平面通信

节点到控制面

Kubernetes 采用的是中心辐/10射型（Hub-and-Spoke）API 模式。 所有从节点（或运行于其上的 Pod）发出的 API 调用都到 API 服务器。 其它控制面组件都没有可暴露的远程服
务。 API 服务器配置为在一个安全的 HTTPS 端口（通常为 443）上监听远程连接请求，节点和API 服务器之间通过TLS证书交互通信，并启用客户端身份认证和鉴权机制。

Pod到控制面

想要连接到 API 服务器的 Pod 可以使用Service Account安全地进行连接，当 Pod 被实例化时，Kubernetes 自动把公共根证书和一个有效的令牌注入到 Pod 里，同时有一个名为Kubernetes的Service（位于 default 名字空间中）配置了一个虚拟 IP 地址，用于（通过 kube-proxy）转发请求到 API 服务器的 HTTPS 端点。

控制面组件也通过安全端口与集群的 API 服务器通信。

综上，节点和Pod 到控制面连接的操作模式是安全的，能够在不可信的网络或公网上运行。

控制面到节点

从控制面（API 服务器）到节点有两种主要的通信路径。

• 从 API 服务器到集群中每个节点上运行的 kubelet 。
• 从 API 服务器通过它的代理功能连接到任何节点、Pod 或者服务。

API 服务器到 kubelet

从 API 服务器到 kubelet 的连接用于：

• 获取 Pod 日志
• 挂接（通过 kubectl）到运行中的 Pod
• 提供 kubelet 的端口转发功能

这些连接终止于 kubelet 的 HTTPS 末端。 默认情况下，API 服务器不检查 kubelet 的服务证书。这使得此类连接容易受到中间人攻击，在非受信网络或公开网络上运行也是不安全的。为了对这个连接进行认证，使用 --kubelet-certificate-authority 标志给 API 服务器提供一个根证书包，用于 kubelet 的服务证书。

如果无法实现这点，又要求避免在非受信网络或公共网络上进行连接，可在 API 服务器和 kubelet 之间使用 SSH 隧道。

最后，应该启用 Kubelet 认证/鉴权 来保护 kubelet API。

API 服务器到节点、Pod 和服务

从 API 服务器到节点、Pod 或服务的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密。 这些连接可通过给 API URL 中的节点、Pod 或服务名称添加前缀 https: 来运行在安全的 HTTPS 连接上。 不过这些连接既不会验证 HTTPS 末端提供的证书，也不会提供客户端证书。 因此，虽然连接是加密的，仍无法提供任何完整性保证。 这些连接 目前还不能安全地 在非受信网络或公共网络上运行。

SSH 隧道（废弃）

Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。 在这种配置下，API 服务器建立一个到集群中各节点的 SSH 隧道（连接到在 22 端口监听的 SSH 服务器） 并通过这个隧道传输所有到 kubelet、节点、Pod 或服务的请求。 这一隧道保证通信不会被暴露到集群节点所运行的网络之外。

说明：SSH 隧道目前已被废弃。除非你了解个中细节，否则不应使用。 Konnectivity 服务是 SSH 隧道的替代方案。

Konnectivity 服务

特性状态： Kubernetes v1.18 [beta]

作为 SSH 隧道的替代方案，Konnectivity 服务提供 TCP 层的代理，以便支持从控制面到集群的通信。 Konnectivity 服务包含两个部分：Konnectivity 服务器和 Konnectivity 代理， 分别运行在控制面网络和节点网络中。 Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。 启用 Konnectivity 服务之后，所有控制面到节点的通信都通过这些连接传输。

请浏览 Konnectivity 服务任务 在你的集群中配置 Konnectivity 服务。

控制器

在机器人技术和自动化领域，控制回路（Control Loop）是一个非终止回路，用于调节系统状态。

这是一个控制环的例子：房间里的温度自动调节器。

当你设置了温度，告诉了温度自动调节器你的期望状态（Desired State）。 房间的实际温度是当前状态（Current State）。 通过对设备的开关控制，温度自动调节器让其当前状态接近期望状态。

在 Kubernetes 中，控制器通过监控集群的状态，并致力于将当前状态转变为期望的状态。

控制器模式

一个控制器至少追踪一种类型的 Kubernetes 资源。这些对象 有一个代表期望状态的 spec 字段。 该资源的控制器负责确保其当前状态接近期望状态。

控制器可能会自行执行操作；在 Kubernetes 中更常见的是一个控制器会发送信息给 API 服务器来实现控制操作。

通过 API 服务器来控制

Job 控制器是一个 Kubernetes 内置控制器的例子。 内置控制器通过和集群 API 服务器交互来管理状态。

Job 是一种 Kubernetes 资源，它运行一个或者多个 Pod，来执行一个任务然后停止。 （一旦被调度了，对 kubelet 来说 Pod 对象就会变成了期望状态的一部分）。

在集群中，当 Job 控制器拿到新任务时，它会保证一组 Node 节点上的 kubelet 可以运行正确数量的 Pod 来完成工作。 Job 控制器不会自己运行任何的 Pod 或者容器。Job 控制器是通知 API 服务器来创建或者移除 Pod。 控制面中的其它组件根据新的消息作出反应（调度并运行新 Pod）并且最终完成工作。

创建新 Job 后，所期望的状态就是完成这个 Job。Job 控制器会让 Job 的当前状态不断接近期望状态：创建为 Job 要完成工作所需要的 Pod，使 Job 的状态接近完成。

控制器也会更新配置对象。例如：一旦 Job 的工作完成了，Job 控制器会更新 Job 对象的状态为 Finished。

（这有点像温度自动调节器指示灯，以此来告诉你房间的温度现在到你设定的值了）。

直接控制

相比 Job 控制器，有些控制器需要对集群外的一些东西进行修改。

例如，如果你使用一个控制回路来保证集群中有足够的节点，那么控制器就需要当前集群外的一些服务在需要时创建新节点。和外部状态交互的控制器从 API 服务器获取到它想要的状态，然后直接和外部系统进行通信并使当前状态更接近期望状态。（实际上有一个autoscaler控制器可以水平地扩展集群中的节点。）

重点是，控制器做出了一些变更以使得事物更接近你的期望状态，之后将当前状态报告给集群的 API 服务器。 其他控制回路可以观测到所汇报的数据的这种变化并采取其各自的行动。

在温度计的例子中，如果房间很冷，那么某个控制器可能还会启动一个防冻加热器。 就 Kubernetes 集群而言，控制面间接地与 IP 地址管理工具、存储服务、云驱动 APIs 以及其他服务协作，通过扩展 Kubernetes 来实现这点。

期望状态与当前状态

Kubernetes 采用了系统的云原生视图，并且可以处理持续的变化。

在任务执行时，集群随时都可能被修改，并且控制回路会自动修复故障。 这意味着很可能集群永远不会达到稳定状态。

只要集群中的控制器在运行并且进行有效的修改，整体状态的稳定与否是无关紧要的。

设计

控制器模式作为设计原则之一，Kubernetes 使用了很多控制器，每个控制器管理集群状态的一个特定方面。 最常见的一个特定的控制器使用一种类型的资源作为它的期望状态，控制器管理控制另外一种类型的资源向它的期望状态演化。 例如，Job 的控制器跟踪 Job 对象（以发现新的任务）和 Pod 对象（以运行 Job，然后查看任务何时完成）。 在这种情况下，新任务会创建 Job，而 Job 控制器会创建 Pod。

使用简单的控制器而不是一组相互连接的单体控制回路是很有用的。 控制器会失败，所以 Kubernetes 的设计正是考虑到了这一点。

运行控制器的方式

Kubernetes 内置一组控制器，运行在 kube-controller-manager 内。 这些内置的控制器提供了重要的核心功能。

Deployment 控制器和 Job 控制器是 Kubernetes 内置控制器的典型例子。 Kubernetes 允许你运行一个稳定的控制平面，这样即使某些内置控制器失败了，控制平面的其他部分会接替它们的工作。

你会遇到某些控制器运行在控制面之外，用以扩展 Kubernetes。 或者，如果你愿意，你也可以自己编写新控制器。 你可以以一组 Pod 来运行你的控制器，或者运行在 Kubernetes 之外。 最合适的方案取决于控制器所要执行的功能是什么。

租约（Lease）

分布式系统通常需要租约（Lease）；租约提供了一种机制来锁定共享资源并协调集合成员之间的活动。 在 Kubernetes 中，租约概念表示为 coordination.k8s.io API 组中的 Lease 对象，常用于类似节点心跳和组件级领导者选举等系统核心能力。

节点心跳

Kubernetes 使用 Lease API 将 kubelet 节点心跳传递到 Kubernetes API 服务器。 对于每个 Node，在 kube-node-lease 名字空间中都有一个具有匹配名称的 Lease 对象。 在此基础上，每个 kubelet 心跳都是对该 Lease 对象的 update 请求，更新该 Lease 的 spec.renewTime 字段。 Kubernetes 控制平面使用此字段的时间戳来确定此 Node 的可用性。

领导者选举

Kubernetes 也使用 Lease 确保在任何给定时间某个组件只有一个实例在运行。 这在高可用配置中由 kube-controller-manager 和 kube-scheduler 等控制平面组件进行使用，这些组件只应有一个实例激活运行，而其他实例待机。

API 服务器身份

特性状态： Kubernetes v1.26 [beta]

从 Kubernetes v1.26 开始，每个 kube-apiserver 都使用 Lease API 将其身份发布到系统中的其他位置。 虽然它本身并不是特别有用，但为客户端提供了一种机制来发现有多少个 kube-apiserver 实例正在操作 Kubernetes 控制平面。kube-apiserver 租约的存在使得未来可以在各个 kube-apiserver 之间协调新的能力。

你可以检查 kube-system 名字空间中名为 kube-apiserver-<sha256-hash> 的 Lease 对象来查看每个 kube-apiserver 拥有的租约。你还可以使用标签选择算符 apiserver.kubernetes.io/identity=kube-apiserver：

kubectl -n kube-system get lease -l apiserver.kubernetes.io/identity=kube-apiserver

NAME                                        HOLDER                                                                           AGE
apiserver-07a5ea9b9b072c4a5f3d1c3702        apiserver-07a5ea9b9b072c4a5f3d1c3702_0c8914f7-0f35-440e-8676-7844977d3a05        5m33s
apiserver-7be9e061c59d368b3ddaf1376e        apiserver-7be9e061c59d368b3ddaf1376e_84f2a85d-37c1-4b14-b6b9-603e62e4896f        4m23s
apiserver-1dfef752bcb36637d2763d1868        apiserver-1dfef752bcb36637d2763d1868_c5ffa286-8a9a-45d4-91e7-61118ed58d2e        4m43s

租约名称中使用的 SHA256 哈希基于 API 服务器所看到的操作系统主机名生成。 每个 kube-apiserver 都应该被配置为使用集群中唯一的主机名。 使用相同主机名的 kube-apiserver 新实例将使用新的持有者身份接管现有 Lease，而不是实例化新的 Lease 对象。 你可以通过检查 kubernetes.io/hostname 标签的值来查看 kube-apisever 所使用的主机名：

kubectl -n kube-system get lease apiserver-07a5ea9b9b072c4a5f3d1c3702 -o yaml

apiVersion: coordination.k8s.io/v1
kind: Lease
metadata:
  creationTimestamp: "2023-07-02T13:16:48Z"
  labels:
    apiserver.kubernetes.io/identity: kube-apiserver
    kubernetes.io/hostname: master-1
  name: apiserver-07a5ea9b9b072c4a5f3d1c3702
  namespace: kube-system
  resourceVersion: "334899"
  uid: 90870ab5-1ba9-4523-b215-e4d4e662acb1
spec:
  holderIdentity: apiserver-07a5ea9b9b072c4a5f3d1c3702_0c8914f7-0f35-440e-8676-7844977d3a05
  leaseDurationSeconds: 3600
  renewTime: "2023-07-04T21:58:48.065888Z"

kube-apiserver 中不再存续的已到期租约将在到期 1 小时后被新的 kube-apiserver 作为垃圾收集。

你可以通过禁用 APIServerIdentity 特性门控来禁用 API 服务器身份租约。

工作负载

你自己的工作负载可以定义自己使用的 Lease。例如，可以运行自定义的控制器，让主要成员或领导者成员在其中执行其对等方未执行的操作。 定义一个 Lease，以便控制器副本可以使用 Kubernetes API 进行协调以选择或选举一个领导者。 如果你使用 Lease，良好的做法是为明显关联到产品或组件的 Lease 定义一个名称。 例如，如果你有一个名为 Example Foo 的组件，可以使用名为 example-foo 的 Lease。

如果集群操作员或其他终端用户可以部署一个组件的多个实例，则选择名称前缀并挑选一种机制（例如 Deployment 名称的哈希）以避免 Lease 的名称冲突。

你可以使用另一种方式来达到相同的效果：不同的软件产品不相互冲突。

关于 cgroup v2

在 Linux 上，cgroup（controller group，控制组）约束分配给进程的资源。

kubelet 和底层容器运行时都需要对接 cgroup 来强制执行为 Pod 和容器管理资源，这包括为容器化工作负载配置 CPU/内存请求和限制（cpu/memory requests and limits）。

Linux 中有两个 cgroup 版本：cgroup v1 和 cgroup v2。cgroup v2 是新一代的 cgroup API。

什么是 cgroup v2？

特性状态： Kubernetes v1.25 [stable]

cgroup v2 是 Linux cgroup API 的下一个版本， 提供了一个具有增强资源管理能力的统一控制系统。

cgroup v2 对 cgroup v1 进行了多项改进，例如：

• API 中单个统一的层次结构设计
• 更安全的子树委派给容器
• 更新的功能特性，例如压力阻塞信息（Pressure Stall Information，PSI）
• 跨多个资源的增强资源分配管理和隔离统一核算不同类型的内存分配（网络内存、内核内存等）考虑非即时资源变化，例如页面缓存回写

一些 Kubernetes 特性专门使用 cgroup v2 来增强资源管理和隔离。 例如，MemoryQoS 特性改进了内存 QoS 并依赖于 cgroup v2 。

使用要求：

• 操作系统发行版支持并启用 cgroup v2
• Linux 内核为 5.8 或更高版本
• 容器运行时支持 cgroup v2。例如：containerd v1.4+或 cri-o v1.20+
• kubelet 和容器运行时被配置为使用 systemd cgroup 驱动

使用 cgroup v2 的推荐方法是使用一个默认启用 cgroup v2 的 Linux 发行版。

• Container-Optimized OS（从 M97 开始）
• Ubuntu（从 21.10 开始，推荐 22.04+）
• Debian GNU/Linux（从 Debian 11 Bullseye 开始）
• Fedora（从 31 开始）
• Arch Linux（从 2021 年 4 月开始）
• RHEL 和类似 RHEL 的发行版（从 9 开始）

切换到 cgroup v2 时，用户体验应没有任何明显差异，除非用户直接在节点上或从容器内访问 cgroup 文件系统。

cgroup v2 使用一个与 cgroup v1 不同的 API，因此如果有任何应用直接访问 cgroup 文件系统，则需要将这些应用更新为支持 cgroup v2 的版本。例如：

• 一些第三方监控和安全代理可能依赖于 cgroup 文件系统。你要将这些代理更新到支持 cgroup v2 的版本。
• 如果以独立的 DaemonSet 的形式运行 cAdvisor 以监控 Pod 和容器， 需将其更新到 v0.43.0 或更高版本。
• 如果你部署 Java 应用程序，最好使用完全支持 cgroup v2 的版本：OpenJDK / HotSpot: jdk8u372、11.0.16、15 及更高的版本
• 如果你正在使用 uber-go/automaxprocs 包， 确保你使用的版本是 v1.5.1 或者更高。

识别 Linux 节点上的 cgroup 版本

cgroup 版本取决于正在使用的 Linux 发行版和操作系统上配置的默认 cgroup 版本。 要检查你的发行版使用的是哪个 cgroup 版本，请在该节点上运行 stat -fc %T /sys/fs/cgroup/ 命令：

stat -fc %T /sys/fs/cgroup/

对于 cgroup v2，输出为 cgroup2fs。

对于 cgroup v1，输出为 tmpfs。

容器运行时接口（CRI）

CRI 是一个插件接口，它使 kubelet 能够使用各种容器运行时，无需重新编译集群组件。

你需要在集群中的每个节点上都有一个可以正常工作的容器运行时，这样 kubelet 能启动 Pod 及其容器。

容器运行时接口（CRI）是 kubelet 和容器运行时之间通信的主要协议。

Kubernetes 容器运行时接口（Container Runtime Interface；CRI）定义了主要 gRPC 协议，用于节点组件 kubelet 和容器运行时之间的通信。

API

特性状态： Kubernetes v1.23 [stable]

当通过 gRPC 连接到容器运行时，kubelet 将充当客户端。运行时和镜像服务端点必须在容器运行时中可用，可以使用 --image-service-endpoint 命令行标志在 kubelet 中单独配置。

对 Kubernetes v1.29，kubelet 偏向于使用 CRI v1 版本。 如果容器运行时不支持 CRI 的 v1 版本，那么 kubelet 会尝试协商较老的、仍被支持的所有版本。 v1.29 版本的 kubelet 也可协商 CRI v1alpha2 版本，但该版本被视为已弃用。 如果 kubelet 无法协商出可支持的 CRI 版本，则 kubelet 放弃并且不会注册为节点。

升级

升级 Kubernetes 时，kubelet 会尝试在组件重启时自动选择最新的 CRI 版本。 如果失败，则将如上所述进行回退。如果由于容器运行时已升级而需要 gRPC 重拨，则容器运行时还必须支持最初选择的版本，否则重拨预计会失败，这需要重新启动 kubelet。

垃圾收集

垃圾收集（Garbage Collection）是 Kubernetes 用于清理集群资源的各种机制的统称。 垃圾收集允许系统清理如下资源：

• 终止的 Pod
• 已完成的 Job
• 不再存在属主引用的对象
• 未使用的容器和容器镜像
• 动态制备的、StorageClass 回收策略为 Delete 的 PV 卷
• 阻滞或者过期的 CertificateSigningRequest (CSR)
• 在以下情形中删除了的节点对象：当集群使用云控制器管理器运行于云端时；当集群使用类似于云控制器管理器的插件运行在本地环境中时。
• 节点租约对象

属主与依赖

Kubernetes 中很多对象通过属主引用 链接到彼此。属主引用（Owner Reference）可以告诉控制面哪些对象依赖于其他对象。 Kubernetes 使用属主引用来为控制面以及其他 API 客户端在删除某对象时提供一个清理关联资源的机会。 在大多数场合，Kubernetes 都是自动管理属主引用的。

属主关系与某些资源所使用的标签和选择算符不同。 例如，考虑一个创建 EndpointSlice 对象的 Service。 Service 使用标签来允许控制面确定哪些 EndpointSlice 对象被该 Service 使用。 除了标签，每个被 Service 托管的 EndpointSlice 对象还有一个属主引用属性。 属主引用可以帮助 Kubernetes 中的不同组件避免干预并非由它们控制的对象。

根据设计，系统不允许出现跨名字空间的属主引用。名字空间作用域的依赖对象可以指定集群作用域或者名字空间作用域的属主。 名字空间作用域的属主必须存在于依赖对象所在的同一名字空间。 如果属主位于不同名字空间，则属主引用被视为不存在，而当检查发现所有属主都已不存在时，依赖对象会被删除。集群作用域的依赖对象只能指定集群作用域的属主。 在 1.20 及更高版本中，如果一个集群作用域的依赖对象指定了某个名字空间作用域的类别作为其属主， 则该对象被视为拥有一个无法解析的属主引用，因而无法被垃圾收集处理。

在 1.20 及更高版本中，如果垃圾收集器检测到非法的跨名字空间 ownerReference， 或者某集群作用域的依赖对象的 ownerReference 引用某名字空间作用域的类别， 系统会生成一个警告事件，其原因为 OwnerRefInvalidNamespace，involvedObject 设置为非法的依赖对象。你可以通过运行 kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace 来检查是否存在这类事件。

级联删除

Kubernetes 会检查并删除那些不再拥有属主引用的对象，例如在你删除了 ReplicaSet 之后留下来的 Pod。当你删除某个对象时，你可以控制 Kubernetes 是否去自动删除该对象的依赖对象，这个过程称为级联删除（Cascading Deletion）。

级联删除有两种类型，分别如下：

• 前台级联删除
• 后台级联删除

你也可以使用 Kubernetes Finalizers 来控制垃圾收集机制如何以及何时删除包含属主引用的资源。

前台级联删除

在前台级联删除中，正在被你删除的属主对象首先进入 deletion in progress 状态。 在这种状态下，针对属主对象会发生以下事情：

• Kubernetes API 服务器将某对象的 metadata.deletionTimestamp 字段设置为该对象被标记为要删除的时间点。
• Kubernetes API 服务器也会将 metadata.finalizers 字段设置为 foregroundDeletion。
• 在删除过程完成之前，通过 Kubernetes API 仍然可以看到该对象。

当属主对象进入删除过程中状态后，控制器删除其依赖对象。控制器在删除完所有依赖对象之后，删除属主对象。这时，通过 Kubernetes API 就无法再看到该对象。

在前台级联删除过程中，唯一可能阻止属主对象被删除的是那些带有 ownerReference.blockOwnerDeletion=true 字段的依赖对象。

后台级联删除

在后台级联删除过程中，Kubernetes 服务器立即删除属主对象，控制器在后台清理所有依赖对象。 默认情况下，Kubernetes 使用后台级联删除方案，除非你手动设置了要使用前台删除，或者选择遗弃依赖对象。

被遗弃的依赖对象

当 Kubernetes 删除某个属主对象时，被留下来的依赖对象被称作被遗弃的（Orphaned）对象。 默认情况下，Kubernetes 会删除依赖对象。

未使用容器和镜像的回收

kubelet 会每五分钟对未使用的镜像执行一次垃圾收集，每分钟对未使用的容器执行一次垃圾收集。 你应该避免使用外部的垃圾收集工具，因为外部工具可能会破坏 kubelet 的行为，移除应该保留的容器。

要配置对未使用容器和镜像的垃圾收集选项，可以使用一个 配置文件，基于 KubeletConfiguration 资源类型来调整与垃圾收集相关的 kubelet 行为。

容器镜像生命周期

Kubernetes 通过其镜像管理器（Image Manager） 来管理所有镜像的生命周期， 该管理器是 kubelet 的一部分，工作时与 cadvisor 协同。 kubelet 在作出垃圾收集决定时会考虑如下磁盘用量约束：

• HighThresholdPercent
• LowThresholdPercent

磁盘用量超出所配置的 HighThresholdPercent 值时会触发垃圾收集， 垃圾收集器会基于镜像上次被使用的时间来按顺序删除它们，首先删除的是最近未使用的镜像。 kubelet 会持续删除镜像，直到磁盘用量到达 LowThresholdPercent 值为止。

容器垃圾收集

kubelet 会基于如下变量对所有未使用的容器执行垃圾收集操作，这些变量都是你可以定义的：

• MinAge：kubelet 可以垃圾回收某个容器时该容器的最小年龄。设置为 0 表示禁止使用此规则。
• MaxPerPodContainer：每个 Pod 可以包含的已死亡的容器个数上限。设置为小于 0 的值表示禁止使用此规则。
• MaxContainers：集群中可以存在的已死亡的容器个数上限。设置为小于 0 的值意味着禁止应用此规则。

除以上变量之外，kubelet 还会垃圾收集除无标识的以及已删除的容器，通常从最近未使用的容器开始。

当保持每个 Pod 的最大数量的容器（MaxPerPodContainer）会使得全局的已死亡容器个数超出上限 （MaxContainers）时，MaxPerPodContainers 和 MaxContainers 之间可能会出现冲突。 在这种情况下，kubelet 会调整 MaxPerPodContainer 来解决这一冲突。 最坏的情形是将 MaxPerPodContainer 降格为 1，并驱逐最近未使用的容器。 此外，当隶属于某已被删除的 Pod 的容器的年龄超过 MinAge 时，它们也会被删除。

说明：kubelet 仅会回收由它所管理的容器。

已完成 Job 的自动清理

特性状态： Kubernetes v1.23 [stable]

当你的 Job 已结束时，将 Job 保留在 API 中（而不是立即删除 Job）很有用，这样你就可以判断 Job 是成功还是失败。

Kubernetes TTL-after-finished 控制器提供了一种 TTL 机制来限制已完成执行的 Job 对象的生命期。TTL-after-finished 控制器假设 Job 能在执行完成后的 TTL 秒内被清理。一旦 Job 的状态条件发生变化表明该 Job 是 Complete 或 Failed，计时器就会启动；一旦 TTL 已过期，该 Job 就能被级联删除。 当 TTL 控制器清理作业时，它将做级联删除操作，即删除 Job 的同时也删除其依赖对象。Kubernetes 尊重 Job 对象的生命周期保证，例如等待 Finalizer。

动态制备的、StorageClass 回收策略为 Delete 的 PV 卷

对于支持 Delete 回收策略的卷插件，删除动作会将 PersistentVolume 对象从 Kubernetes 中移除，同时也会从外部基础设施中移除所关联的存储资产。 动态制备的卷会继承其 StorageClass 中设置的回收策略，该策略默认为 Delete。管理员需要根据用户的期望来配置 StorageClass；否则 PV 卷被创建之后必须要被编辑或者修补。

垃圾回收看起来有些杂乱，但这里主要是把不同资源放到了一起来说，其实单看每种资源，都有其各自的回收方式，因为资源特性不同、需求不同，所以回收方式也各自不同。

总结

本篇文章比较长，内容涉及控制面与节点间通信、租约、cgroupsv2、CRI运行时、垃圾回收等主题，补充整个Kubernetes的管理信息。

控制面与节点间通信：主要通过SSL，确保安全；

控制器模式：一个控制器至少追踪一种类型的 Kubernetes 资源。这些对象有一个代表期望状态的 spec 字段。 该资源的控制器负责确保其当前状态接近期望状态。

租约：租约提供了一种机制来锁定共享资源并协调集合成员之间的活动。 在 Kubernetes 中，常用于类似节点心跳和组件级领导者选举等系统核心能力。

cgroupv2：在 Linux 上，cgroup（controller group，控制组）约束分配给进程的资源，v2提供了很多改进，配置起来比较复杂，建议直接使用一个启用了cgroupv2的linux发行版。

CRI：容器运行时接口（CRI）是 kubelet 和容器运行时之间通信的主要协议，目前发布v1正式版本。

垃圾收集（Garbage Collection）是 Kubernetes 用于清理集群资源的各种机制的统称。 垃圾收集允许系统清理很多资源，每种资源都有其各自的回收方式，因为资源特性不同、需求不同，所以回收方式也各自不同。