EKS 1.23升级后GitLab Runner Pod长期处于Terminating状态求助

问题核心原因 #

EKS升级到1.23后，GitLab Runner（K8s执行器）Pod长期卡在Terminating状态，结合你观察到的现象，主要和K8s 1.23对Pod终止流程的API变更、GitLab Runner版本兼容性不足，以及集群节点状态同步异常有关。

分步排查与解决 #

1. 解析kubelet日志找具体报错 #

你提供的kubelet日志是关键，重点搜索以下关键词：

• PodSandbox
• termination
• foregroundDeletion
• container runtime error
  通常这类假死Pod的kubelet日志里会明确显示容器清理失败、沙箱资源未释放，或者kubelet与容器运行时（docker/containerd）通信异常的细节，这是定位根因的核心依据。

2. 升级GitLab Runner适配K8s 1.23 #

K8s 1.23废弃了一批旧API，GitLab Runner版本低于15.0的话，无法适配新的Pod终止逻辑。直接升级Runner到15.0及以上版本，该版本全面兼容K8s 1.23+的规范。

3. 调整Runner的Pod终止配置 #

修改GitLab Runner的config.toml，优化K8s执行器的终止相关参数：

• 缩短terminationGracePeriodSeconds至30s（默认值过长可能导致kubelet等待超时）
• 开启cleanupPods确保Runner主动清理终止Pod：

[[runners]]
  executor = "kubernetes"
  [runners.kubernetes]
    namespace = "gitlab-runner"
    terminationGracePeriodSeconds = 30
    cleanupPods = true

修改后重启GitLab Runner Pod生效。

4. 修复节点状态同步问题 #

部分Pod挂在已下线节点上，说明kube-controller-manager的节点垃圾回收未正常触发：

• 确认kube-controller-manager的参数：--node-monitor-grace-period=40s、--pod-eviction-timeout=5m（EKS 1.23默认值）
• 手动清理无效节点记录：

kubectl delete node <已下线节点名称>

节点在AWS控制台删除后，执行此命令可强制移除集群内的节点残留，关联的Terminating Pod会被自动清理。

5. 同步容器运行时与kubelet状态 #

底层Pod已消失但集群仍显示Terminating，是容器运行时与kubelet状态不同步导致：

• 重启kubelet服务：

systemctl restart kubelet

• 清理容器运行时的残留沙箱：

# 针对containerd
crictl ps -a | grep -E "Terminating|Exited" | awk '{print $1}' | xargs crictl rm
# 针对docker
docker ps -a | grep Exited | awk '{print $1}' | xargs docker rm

临时应急处理 #

如果上述步骤无法快速生效，可强制删除卡在Terminating状态的Pod：

kubectl delete pod <pod-name> -n <namespace> --grace-period=0 --force

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