K8s中的垃圾回收

基于1.29

K8s的垃圾回收主要是以下的问题

  • 结束的Pod对象
  • 完结的Job对象
  • 无主对象，这类的对象的Owner不存在
  • 不再使用的容器和镜像
  • 不再使用的动态创建的PV对象，对应的StorageClass声明了回收策略Delete
  • 下列场景中被删除的Node
    • 控制器的集群
  • Node Lease对象

Pod对象垃圾回收

对于我阶段为Failed的Pod，对应的容器虽然已经停止，但是其资源对象依旧存在API Server，需要被Pod控制器或者运维人员手动删除

kube-controller-manager中有一个名为PodGC的组件专门负责自动清理“垃圾类”Pod

  • 孤儿Pod，绑定的Node已经不存在
  • 未调度就结束的Pod
  • 终结中的Pod，这类Pod满足，它们被绑定到NotReady的Node，该Node有一个污点node.kubernetes.io/out-of-service，并且NodeOutOfServiceVolumeDetach特性门控开启

对于孤儿Pod，如果它们的阶段不少终结阶段，则PodGC会把它们设置为Failed，此时，如果集群开启PodDisruption Conditions特性门控，则当PodGC清理垃圾Pod时，会为目标Pod增加一个值为DeleteionByPodGC的Pod DisurptionTarget Condition表明Pod是因为垃圾回收而被删除的

  • PodGC什么时候开始？当集群中的垃圾Pod超过kube-controller-manager参数设置的--termindated-pod-gc-threshold，默认值12500

Job对象的垃圾回收

在K8s v1.23中 Job对象的垃圾回收进入Stable阶段

K8s采用了类似TTL机制限制Job对象的生命周期

在Job对象中.spec.ttlSencondsAfterFinished的属性中设置合理的过期时间，然后K8s TTL Controller会等待Job对象的TTL时间结束，并自动回收该Job对象

无主对象的垃圾回收

K8s中的很多对象都有所属关系，对象的Owner标注了他们控制层和其他的依赖关系

  • Owner字段值呢作用于集群范畴的对象，如果被设置为命名空间的范围的对象，则会被认为是无法解析的Owner对象

容器和镜像的垃圾回收

kubelet进程负责清理容器和镜像垃圾，默认频率如下

  • 每俩分钟清理镜像垃圾
  • 每一分钟清理一次容器垃圾

kubelet清理会关注俩个指标

  • HighThresholdPercent阈值
  • Low ThresholdPercent阈值

1.29版本引入新特性，允许kubelet在磁盘还很充足的情况下，把一个长期未使用的镜像从本地删除，这个新特性需要开启ImageMaximumGCAge特性，还需要设置时间，需要在每个kubelet上设置

一般的，kubelet会先回收“死亡”最久的容器，kubelet基于下面的参数进行回收

  • MinAge：kubelte可回收的容器的最短生存时间，如果设置为0.禁止回收
  • MaxPerPodContainer：每个Pod允许的最大“死亡”容器数量
  • MaxContainers：集群中允许的最大“死亡”容器数量

kubelet只会回收自己创建的容器，不会回收其他应用创建的容器

PV对象的垃圾回收

v1.23中新增Alpha特性，PV deletion protection finalizer，对于那些动态创建的PV对象，如果他们对应的StorageClas声明了回收策略为delete，就会设置“删除保护”的Finalizer

  • kubernetes.io/pv-controller:添加K8s内置的PV对象上
  • External-provisioner.colume.kubernetes.io/finalizer：添加外部的CSI PV对象上

Node和Node Lease对象的垃圾回收

公有云、混合云汇总一般通过Cloud Controller Manager自动管理公有云中的Node，主要功能如下

  • 更新对应的Node信息
  • 给Node添加注解和标签
  • 获取Node得主机名和网络地址
  • 检查和验证Node的监控状态

如果K8s集群节点多，大量的Node心跳会加重API Server的压力，所以出现了需要更新和持久化对象Node Statue，但是Node Statue毕竟重，所以又出现了轻量的Node Lease实现高性能的心跳检查和Node状态更新

[root@hcss-ecs-5425 ~]# k get lease  -A
NAMESPACE         NAME                      HOLDER                                               AGE
default           example                   2                                                    59d
kube-node-lease   izbp1ebizftw2vpbpm737wz   izbp1ebizftw2vpbpm737wz                              60d
kube-node-lease   node                      node                                                 61d
kube-system       kube-controller-manager   hcss-ecs-5425_da03c316-f047-44f3-bd4d-05d8b56ae2ca   61d
kube-system       kube-schedul


[root@hcss-ecs-5425 ~]# k get lease  -n kube-node-lease izbp1ebizftw2vpbpm737wz -oyaml
apiVersion: coordination.k8s.io/v1
kind: Lease
metadata:
  creationTimestamp: "2024-11-08T16:21:11Z"
  name: izbp1ebizftw2vpbpm737wz
  namespace: kube-node-lease
  ownerReferences:
  - apiVersion: v1
    kind: Node
    name: izbp1ebizftw2vpbpm737wz
    uid: 6011ff47-12b4-4e30-9f16-d544fabdb380
  resourceVersion: "5061712"
  uid: de45f814-2625-437d-9083-322fafc530b2
spec:
  holderIdentity: izbp1ebizftw2vpbpm737wz
  leaseDurationSeconds: 40
  // Node最后一次更新的时间戳
  renewTime: "2024-12-23T14:37:37.747922Z"
[root@hcss-ecs-5425 ~]#