一、问题出现
在Windows Docker Desktop 环境下使用Argo Workflows进行本地开发时，我遇到了两个非常典型的问题：
一是本地构建的私有镜像无法运行：
报错：task '...download-data' errored: failed to look-up entrypoint/cmd for image "p_f_downloader:latest",
you must either explicitly specify the command, or list the image's command in the index...
GET index.docker.io/v2/library/…:
UNAUTHORIZED: authentication required
二是工作流运行时报权限错误：
报错：Error (exit code 1): pods "pipe-flood-job-cmrjn-downloader-3284582872" is forbidden: User "system:serviceaccount:argo:default" cannot patch resource "pods" in API group "" in the namespace "argo"
二、解决问题一：本地镜像报错 UNAUTHORIZED
1．问题原因
Argo的默认执行器（Emissary）在启动容器前，必须知道镜像的启动命令（Entrypoint/CMD）。如果在YAML中没有显式写command，Argo就会尝试去Docker Registry（默认是Docker Hub）查询这个镜像的元数据信息。因为我的镜像是本地build的私有镜像，Docker Hub上根本不存在，或者需要权限，所以Argo去查询时就报了UNAUTHORIZED（未授权）或404。
2．问题解决
在YAML中显式指定command。只要告诉Argo启动命令是什么，它就不需要去联网查询镜像元数据了。 修改前（报错）：
- name: downloader
container:
image: p_f_downloader:latest
imagePullPolicy: IfNotPresent
# 缺少 command，Argo 会尝试联网查询
修改后（成功）：
- name: downloader
container:
image: p_f_downloader:latest
imagePullPolicy: IfNotPresent
# 显式指定命令，Argo 直接使用，不再联网查询
command: ["/app/downloader"]
三、解决问题二
1．问题原因
（1）Argo的机制
Argo Workflows运行时需要通过ServiceAccount与Kubernetes API进行交互（例如Patch Pod以更新状态、处理输出等）。
（2）默认权限
如果在YAML中没有指定，Argo会使用default ServiceAccount。这个默认账号在K8s中权限非常低，通常没有修改Pod（Patch）的权限。
2．问题解决
（1）创建RBAC配置文件
apiVersion: v1
kind: ServiceAccount
metadata:
name: argo-workflow-executor
namespace: argo
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: argo-workflow-executor-binding
namespace: argo
subjects:
- kind: ServiceAccount
name: argo-workflow-executor
namespace: argo
roleRef:
# 开发环境为了省事可以直接绑定 admin，生产环境建议用更细粒度的 Role
kind: ClusterRole
name: admin
apiGroup: rbac.authorization.k8s.io
（2）在Workflow YAML中引用
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: pipe-flood-job-
spec:
# 添加这一行，指定刚才创建的账号
serviceAccountName: argo-workflow-executor
entrypoint: pipe-flood-pipeline
# ...
