GKE环境下Argo Workflow执行成功后自动删除问题咨询

1. 排查Argo全局GC策略配置 #

首先检查Argo Workflows部署的控制器配置，执行命令获取配置内容：
kubectl get configmap workflow-controller-configmap -n <你的Argo部署命名空间> -o yaml
重点核对以下参数：

• workflowGC.strategy：默认值为OnWorkflowCompletion，代表工作流执行完成后触发GC
• workflowGC.successfulWorkflowHistoryLimit：成功工作流保留数量，设为0时成功工作流会被立即删除
• workflowGC.failedWorkflowHistoryLimit：失败工作流保留数量，官方默认值为10，若该参数在GKE环境被设置为极大值或未配置，就会出现失败工作流永久留存的情况

注意：通过GKE Marketplace、谷歌云托管Argo发行版安装的服务，会默认修改GC策略参数，和minikube使用官方YAML安装的默认配置不同，这是两类环境表现不一致的最常见原因。

2. 排查GKE集群级规则冲突 #

• 确认GKE集群是否开启了成本管理类插件、节点自动清理规则，部分插件会自动清理状态为Succeeded的Pod资源，对应成功执行的工作流Pod，但不会处理失败状态的工作负载，该逻辑和Argo自带GC无关
• 检查Argo控制器服务账号的权限配置，minikube环境默认会给Argo控制器绑定集群管理员权限，而GKE环境通常会做权限收敛，若控制器缺少工作流删除、Pod删除的RBAC权限，会导致失败工作流GC执行失败，资源无法被清理

3. 排查工作流实例级GC覆盖配置 #

检查你提交的工作流YAML是否单独配置了GC策略，部分CI/CD集成会根据环境变量，给GKE环境提交的工作流自动注入ttlStrategy配置：

• 若注入了ttlStrategy.successSecondsAfterFinished且值很小，成功工作流会到期自动删除
• 若未配置ttlStrategy.failureSecondsAfterFinished，失败工作流就不会触发TTL清理
  可执行命令查看已运行工作流的配置：kubectl get wf <失败工作流名称> -o yaml，核对spec.ttlStrategy和metadata.annotations下的GC相关配置。

4. 排查Argo控制器运行日志 #

直接查看Workflow Controller的运行日志，筛选GC相关报错：
kubectl logs -n <你的Argo部署命名空间> deploy/workflow-controller | grep gc
如果返回权限报错、APIServer调用超时类信息，可对应定位为GKE的APIServer限流、RBAC权限不足导致GC流程中断。

参考解决方案 #

• 若为全局GC配置问题，修改workflow-controller-configmap中的failedWorkflowHistoryLimit为预期值，例如设置为2即可仅保留最近2个失败工作流
• 若为RBAC权限问题，给Argo控制器的服务账号绑定包含workflows/delete、pods/delete权限的ClusterRole
• 若为GKE插件逻辑冲突，关闭对应插件的Pod自动清理功能，统一使用Argo自带的GC策略管理工作流生命周期

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