AKS/K8s服务镜像、拉取策略及节点缓存镜像清理问题咨询

先直接说你提到的crictl rmi --prune的实际影响：
如果命令删掉了当前没运行、后续要用到的镜像，后果分两种情况：

• 对应镜像ImagePullPolicy不是Never：后续Pod调度到该节点启动时，kubelet会自动重新拉取镜像，只会造成Pod启动延迟升高、镜像仓库出口流量额外消耗，不会导致服务永久不可用
• 对应镜像ImagePullPolicy为Never：kubelet不会主动向镜像仓库发起拉取请求，节点本地缺失镜像时，Pod会一直卡在ErrImageNeverPull状态无法启动，必须手动将镜像重新导入节点才能恢复。

1. AKS/K8s节点上的镜像分类及对应场景 #

节点上存储的镜像基本可以分为三类：

• 系统核心组件镜像：包含kube-proxy、CoreDNS、集群CNI网络插件（Azure CNI、Calico等）、CSI存储插件、日志采集组件omsagent、Metrics Server等，这类镜像由AKS托管，全部运行在kube-system命名空间，支撑集群DNS、网络、存储、监控等核心能力，大部分以DaemonSet形式常驻所有节点，正常情况下一直有运行中的容器关联，很少会进入无引用的缓存状态。
• 用户业务镜像：用户自行部署的业务应用、中间件等工作负载对应的镜像，对应业务Pod运行场景，当工作负载缩容到0副本、Pod被驱逐调度到其他节点时，这类镜像会暂时留在节点缓存中，没有运行中的容器关联，后续Pod重新调度回该节点时可以直接使用，不需要重新拉取。
• 临时任务镜像：CronJob、一次性Job运行完成退出后留下的镜像，这类镜像只有下次对应任务被触发调度到该节点时才会再次用到，大部分时间都属于无运行容器关联的缓存状态。

2. 默认ImagePullPolicy规则及校验方法 #

K8s没有全局的默认ImagePullPolicy配置开关，默认规则完全和镜像标签绑定：

• 镜像标签为latest，或者未指定任何标签（默认会被解析为latest）时，默认拉取策略为Always：每次启动Pod都会和镜像仓库校验镜像摘要，拉取匹配标签的最新版本
• 镜像标签为明确的版本号（比如nginx:1.25.3、myapp:v2.1.0）时，默认拉取策略为IfNotPresent：节点本地存在对应镜像缓存时直接使用，不存在时才会向仓库发起拉取
• ImagePullPolicy: Never不属于任何场景下的默认值，必须用户显式配置才会生效，一般用于离线环境下手动导入节点的私有镜像，不会主动走仓库拉取流程。

校验策略是否被修改可以从两个层面入手：

• 工作负载层面：直接查看对应Pod、Deployment、DaemonSet、StatefulSet等资源的YAML配置，检查containers[].imagePullPolicy字段，只要该字段被显式赋值，就会覆盖默认规则
• 节点层面：AKS托管节点默认不会修改kubelet的镜像拉取逻辑，可以登录节点查看/var/lib/kubelet/config.yaml文件确认，kubelet本身没有提供修改全局默认拉取策略的配置项，只要没有自定义过节点启动配置，不需要担心默认规则被篡改。

3. 节点缓存镜像的官方推荐清理方案 #

crictl rmi --prune确实不属于生产环境推荐的清理方案，核心问题就是该命令仅判断执行瞬间是否有运行中的容器关联镜像，完全不感知K8s调度层面后续可能部署到节点的工作负载，会无差别删除所有临时无引用的镜像，带来不必要的拉取开销，甚至导致配置了Never拉取策略的工作负载启动失败。

AKS/原生K8s官方推荐的镜像清理方案是依赖kubelet内置的**镜像垃圾回收（Image GC）**机制，不需要额外开发清理服务：

• kubelet会持续监控节点磁盘使用率，默认当镜像所在磁盘分区使用率达到85%（高阈值）时，自动开始清理无运行容器关联的镜像，优先删除最长时间未被Pod引用的镜像，直到磁盘使用率降到80%（低阈值）后停止清理
• 该机制会基于镜像的历史使用记录做优先级排序，不会无差别删除所有无引用镜像，对业务的影响最小
• AKS托管节点默认已经开启该能力，不需要额外部署组件，如果默认阈值不符合需求，可以通过AKS节点配置自定义imageGCHighThresholdPercent和imageGCLowThresholdPercent参数调整触发清理的水位线。
• 如果确实有特殊的自定义清理需求，建议基于kubelet暴露的镜像使用指标做定向清理，不要直接执行全量prune操作。

内容的提问来源于stack exchange，提问作者SafiJunaid