大规模运行Argo Workflows时pod init阶段argo-exec镜像拉取失败如何解决

方案1：私有镜像仓库托管Argo相关镜像 #

• 完全可行，是大规模生产部署的标准推荐方案
• 操作流程：先将argoexec、workflow-controller、argo-server等所有依赖的Argo镜像同步到你的自有镜像仓库，之后修改workflow-controller的ConfigMap，配置executorImage字段值为私有仓库地址/argoexec:对应版本号，更新ConfigMap后重启workflow-controller Pod即可生效
• 额外收益：除解决限流问题外，还能提升镜像拉取速度、规避公网波动影响，同时满足合规场景下的镜像审计要求

方案2：配置Docker Hub认证身份拉取 #

• 短期过渡场景可行，不建议作为大规模部署的长期方案
• 操作流程：注册Docker Hub账号并生成个人访问令牌，在Kubernetes集群中创建Docker Registry类型的Secret，可选择两种配置方式：一是给Workflow绑定的ServiceAccount添加imagePullSecrets，二是在Controller ConfigMap中配置全局镜像拉取Secret
• 限制说明：认证后Docker Hub拉取配额仅从匿名的每6小时100次提升至每6小时200次，大规模调度场景下仍有触发限流的可能，无法彻底解决问题

方案3：调整镜像拉取策略 #

• 完全可行，是成本最低的优化方案，可配合私有镜像仓库方案达到最优效果
• 操作流程：Argo Workflows默认的executor镜像拉取策略为IfNotPresent，如果你的集群被特殊配置为Always会导致每次调度工作流都触发镜像拉取，修改Controller ConfigMap的executor.imagePullPolicy字段为IfNotPresent即可，只要节点本地已存在对应版本的argoexec镜像，就不会再发起公网拉取请求，从根源上减少限流触发概率
• 注意事项：如果镜像标签使用latest，即使配置IfNotPresent也可能触发拉取，建议所有Argo相关镜像固定使用明确的版本号

提示：所有修改Controller ConfigMap的操作建议先在测试集群验证，避免配置错误导致工作流调度异常

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