K8s Kubelet 垃圾回收机制

最新推荐文章于 2025-01-13 13:28:41 发布

王羲之的之

最新推荐文章于 2025-01-13 13:28:41 发布

阅读量2.6k

点赞数 27

CC 4.0 BY-SA版权

分类专栏： Kubernetes&Docker 文章标签： kubernetes kubelet 容器

本文链接：https://blog.csdn.net/ATYtian/article/details/133378543

本文详细介绍了Kubernetes Kubelet的垃圾回收机制，包括镜像和容器的回收流程、用户配置及实验验证。镜像回收在磁盘使用率超标时按LRU策略进行，容器回收则针对Pod容器进行，遵循特定的存活和死亡容器数量限制。Kubelet的回收动作不影响正在使用的资源，并且不会清理非Kubelet管理的容器。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

前言

Kubelet 垃圾回收（Garbage Collection）是一个非常有用的功能，它负责自动清理节点上的无用镜像和容器。Kubelet 每隔 1 分钟进行一次容器清理，每隔 5 分钟进行一次镜像清理（截止到 v1.15 版本，垃圾回收间隔时间还都是在源码中固化的，不可自定义配置）。如果节点上已经运行了 Kubelet，不建议再额外运行其它的垃圾回收工具，因为这些工具可能错误地清理掉 Kubelet 认为本应保留的镜像或容器，从而可能造成不可预知的问题。

一、镜像回收

Kubernetes 对节点上的所有镜像提供生命周期管理服务，这里的『所有镜像』是真正意义上的所有镜像，而不仅仅是通过 Kubelet 拉取的镜像。当磁盘使用率超过设定上限（HighThresholdPercent）时，Kubelet 就会按照 LRU 清除策略逐个清理掉那些没有被任何 Pod 容器（包括那些已经死亡的容器）所使用的镜像，直到磁盘使用率降到设定下限（LowThresholdPercent）或没有空闲镜像可以清理。此外，在进行镜像清理时，会考虑镜像的生存年龄，对于年龄没有达到最短生存年龄（MinAge）要求的镜像，暂不予以清理。

1.1、主体流程

image.png

如上图所示，Kubelet 对于节点上镜像的回收流程还是比较简单的，在磁盘使用率超出设定上限后：首先，通过 CRI 容器运行时接口读取节点上的所有镜像以及 Pod 容器；然后，根据现有容器列表过滤出那些已经不被任何容器所使用的镜像；接着，按照镜像最近被使用时间排序，越久被用到的镜像越会被排在前面，优先清理；最后，就按照排好的顺序逐个清理镜像，直到磁盘使用率降到设定下限（或者已经没有空闲镜像可以清理）。

需要注意的是，Kubelet 读取到的镜像列表是节点镜像列表，而读取到的容器列表却仅包括由其管理的容器（即 Pod 容器，包括 Pod 内的死亡容器）。因此，那些用户手动 run 起来的容器，对于 Kubelet 垃圾回收来说就是不可见的，也就不能阻止对相关镜像的垃圾回收。当然，Kubelet 的镜像回收不是 force 类型的回收，虽然会对用户手动下载的镜像进行回收动作，但如果确实有运行的（或者停止的任何）容器与该镜像关联的话，删除操作就会失败（被底层容器运行时阻止删除）。

1.2、用户配置

通过上面的分析，我们知道影响镜像垃圾回收的关键参数有：

image-gc-high-threshold：磁盘使用率上限，有效范围 [0-100]，默认 85

image-gc-low-threshold：磁盘使用率下限，有效范围 [0-100]，默认 80

minimum-image-ttl-duration：镜像最短应该生存的年龄，默认 2 分钟

1.3、实验环节

本节我们通过实验来验证镜像垃圾回收（基于 Kubelet 1.15 版本）。

实验前，需要配置 Kubelet 启动参数，降低磁盘使用率上限，以便能够直接触发镜像回收。

# vim /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
...
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS --image-gc-high-threshold=2 --image-gc-low-threshold=1
...

我们在 Kubelet 启动参数的最后追加了 --image-gc-high-threshold=2 --image-gc-low-threshold=1，这么低的配置，Kubelet 应该会一直忙于进行镜像回收了，生产环境可不能这么配置！

执行以下命令使得配置生效：

# systemctl daemon-reload
# systemctl restart kubelet

首先，看下本地都有哪些镜像：


root@shida-machine:~# docker images
REPOSITORY                           TAG                 IMAGE ID            CREATED             SIZE
k8s.gcr.io/kube-proxy                v1.14.4             5f2081c22306        6 days ago          82.1MB
k8s.gcr.io/kube-apiserver            v1.14.4             f3171d49fa9b        6 days ago          210MB
k8s.gcr.io/kube-controller-manager   v1.14.4             35f0904dc8fa        6 days ago          158MB
k8s.gcr.io/kube-scheduler            v1.14.4             ee080c083e45        6 days ago          81.6MB
calico/node                          v3.7.3              bf4ff15c9db0        4 weeks ago         156MB
calico/cni                           v3.7.3              1a6ade52d471        4 weeks ago         135MB
calico/kube-controllers              v3.7.3              283860d96794        4 weeks ago         46.8MB
k8s.gcr.io/coredns                   1.3.1               eb516548c180        6 months ago        40.3MB
k8s.gcr.io/etcd                      3.3.10              2c4adeb21b4f        7 months ago        258MB
k8s.gcr.io/pause                     3.1                 da86e6ba6ca1        19 months ago       742kB

接下来，我们运行一个 nginx 程序，让 Kubelet 自动拉取镜像。

root@shida-machine:~# kubectl run nginx --image=nginx
deployment.apps/nginx created
root@shida-machine:~# kubectl get deployment
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   1/1     1            1           62s
root@shida-machine:~# docker images
REPOSITORY                           TAG                 IMAGE ID            CREATED             SIZE
k8s.gcr.io/kube-proxy