本地Minikube集群Argo Workflow对接MinIO存储报错排查

1. 检查Workflow Controller ConfigMap的端点格式 #

重点确认workflow-controller-configmap中artifactRepository的S3端点配置，绝对不能在URL后附加桶路径或其他后缀。正确配置示例：

artifactRepository:
  s3:
    endpoint: "http://minio-service.argo:9000"  # 仅保留协议、服务名/IP、端口
    bucket: "my-workflow-artifacts"  # 桶名单独配置，不要合并到端点
    accessKeySecret:
      name: minio-credentials
      key: accesskey
    secretKeySecret:
      name: minio-credentials
      key: secretkey
    insecure: true  # 本地MinIO未启用HTTPS时必须设为true

注意：若你用127.0.0.1作为端点，Argo Controller Pod在集群内部无法访问宿主机的127.0.0.1，需替换为Minikube节点IP（执行minikube ip获取）或集群内MinIO Service的DNS名称。

2. 核对Workflow YAML中的工件配置 #

如果Workflow单独指定了artifactRepository，需确保和全局Controller配置完全一致，禁止在端点中嵌入路径。示例：

spec:
  artifactRepository:
    s3:
      endpoint: "http://minio-service.argo:9000"
      bucket: "my-workflow-artifacts"
      insecure: true

3. 验证集群内MinIO服务可达性 #

进入Argo Controller Pod，用curl测试MinIO端点连通性：

kubectl exec -it <workflow-controller-pod-name> -n argo -- curl http://minio-service.argo:9000

若返回MinIO欢迎页面则说明端点正常；若不通，检查MinIO Service的标签选择器是否匹配Pod、端口映射是否正确。

4. 排除额外路径注入问题 #

若通过Ingress暴露MinIO，集群内部访问应直接使用Service地址，而非Ingress路径（S3客户端不支持端点带路径）。如需用Ingress，需确保Ingress规则无路径前缀，或调整为MinIO的路径兼容模式（不推荐）。

5. 确认MinIO部署状态 #

检查MinIO Pod运行日志，确认服务初始化完成：

kubectl logs <minio-pod-name> -n argo

同时用MinIO客户端mc验证桶是否存在：

mc alias set local http://<minio-endpoint> <access-key> <secret-key>
mc ls local

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