Kubernetes集群API测试中镜像垃圾回收问题分析与解决方案

在Kubernetes集群API（Cluster API）项目的持续集成测试中，近期出现了一系列与镜像垃圾回收相关的测试失败问题。这些问题主要表现为在集群升级或迁移过程中，关键容器镜像被意外清理，导致webhook服务不可用。本文将深入分析问题根源，并介绍项目团队提出的解决方案。

问题现象

测试失败的主要表现为：

1. 在执行clusterctl move命令时出现webhook调用失败
2. 在扩展MachineDeployment时出现证书验证错误
3. 关键控制器Pod因镜像拉取失败而无法启动

错误日志显示，系统无法验证由未知CA签发的证书，以及无法拉取预加载的容器镜像。这些问题都指向同一个根本原因：测试环境中关键镜像被意外清理。

根本原因分析

通过深入调查，发现问题源于Kubernetes节点上的镜像垃圾回收机制。测试环境采用多层嵌套架构：

1. Prow节点（物理机/虚拟机层）

   • 运行containerd作为容器运行时
   • 托管测试Pod容器

2. 测试Pod内部（第一层容器）

   • 运行Docker in Docker（DinD）
   • 托管CAPD创建的集群节点

3. CAPD集群节点（第二层容器）

   • 运行独立的kubelet和containerd
   • 默认启用镜像垃圾回收

当宿主机磁盘使用率达到85%阈值时，kubelet的垃圾回收机制会自动清理"不活跃"的镜像。在测试场景中，这些被清理的镜像恰恰是集群运行所必需的核心组件镜像。

解决方案

项目团队提出了几种解决方案并最终确定了最佳实践：

1. 镜像标签固定方案

   • 使用containerd的镜像标签功能固定关键镜像
   • 技术限制：依赖特定containerd版本
   • 实现复杂，跨版本兼容性差

2. 调整垃圾回收阈值

   • 提高或禁用垃圾回收阈值
   • 风险：可能导致磁盘空间不足
   • 违反Kubernetes最佳实践

3. 完全禁用垃圾回收（采用方案）

   • 在CAPD节点创建时禁用镜像垃圾回收
   • 与kind项目保持一致性（kind已采用此方案）
   • 简单可靠，适合测试环境

实现细节

最终方案通过在CAPD节点创建时，在kubelet配置中显式禁用镜像垃圾回收：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
imageGCHighThresholdPercent: 100
imageGCLowThresholdPercent: 100

这种配置方式与kind项目保持了一致，确保测试环境中的关键镜像不会被意外清理。考虑到CAPD纯粹用于测试场景，这种方案既简单又可靠。

经验总结

这个案例提供了几个重要启示：

1. 测试环境需要特别关注资源隔离和稳定性
2. 跨层容器架构会放大垃圾回收的影响
3. 与生态项目保持一致性可减少维护成本
4. 测试专用组件可以采用与生产环境不同的配置策略

Cluster API团队通过这个问题，不仅解决了当前的测试稳定性问题，还为类似场景提供了可借鉴的解决方案。这种深入分析问题本质并借鉴生态经验的做法，值得在云原生测试实践中推广。