Cilium执行helm delete时hubble-ui Pod陷入Terminating状态求解

问题背景 #

在AWS测试集群中部署了Cilium（已替换AWS CNI），使用Helm包v1.12.3，每当删除Cilium命名空间或执行helm delete时，hubble-ui Pod会陷入Terminating状态：

• Pod内的backend容器以退出码137终止
• 集群未给Pod/命名空间设置资源限制（spec.containers.[*].resources = {}），无额外错误提示
• 该问题在版本更新前已存在，直接导致CI流水线中断

原因分析 #

退出码137通常关联OOM，但无资源限制时，核心原因是容器未正确处理优雅终止信号：

1. 删除操作触发时，Kubernetes先向容器发送SIGTERM信号，要求优雅退出
2. 如果backend容器未监听该信号、没有实现清理逻辑，或者处理超时，Kubelet会在terminationGracePeriodSeconds后发送SIGKILL强制终止，对应退出码137
3. 同时，Cilium删除流程中核心组件（如cilium-agent）先被移除，可能提前切断hubble-ui的网络，导致backend容器无法完成退出前的必要操作（如关闭连接、同步数据），最终触发强制终止

优雅退出解决方案（无需清除finalizers） #

1. 配置容器的优雅终止信号处理 #

• 若使用自定义hubble-ui镜像，在启动脚本中添加SIGTERM捕获逻辑，实现清理流程：

  # 在容器启动脚本头部添加
  trap 'echo "SIGTERM received, starting cleanup..."; # 执行清理操作，比如关闭API端口、释放资源; exit 0' SIGTERM
  
  # 保持原启动命令在后台运行，等待信号
  /path/to/backend-start-command &
  wait $!
  

• 对于官方镜像，v1.12.x部分版本存在backend容器终止逻辑缺陷，可尝试升级到v1.13+的稳定版本（先在测试环境验证）

2. 延长终止宽限期 #

给hubble-ui Pod足够的时间完成退出，通过Helm values.yaml配置：

hubble:
  ui:
    deployment:
      terminationGracePeriodSeconds: 60 # 默认30秒，可根据实际清理时间调整

执行helm upgrade应用配置后，再测试删除流程。

3. 调整Cilium组件删除顺序 #

避免核心网络组件提前被删除导致hubble-ui断网：

• 先禁用hubble-ui，再删除Cilium：

  helm upgrade cilium cilium/cilium --version 1.12.3 --set hubble.ui.enabled=false --namespace cilium
  helm delete cilium --namespace cilium --wait
  

• 使用--wait参数确保Helm等待资源逐步删除完成

4. 检查并优化Pod的Finalizers #

• 查看hubble-ui Pod的finalizers配置：

  kubectl get pod <hubble-ui-pod-name> -n cilium -o jsonpath='{.metadata.finalizers}'
  

• 如果存在非必要的finalizers，通过Helm values禁用对应的控制器逻辑，确保删除时finalizers能被正常清理

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