Kubernetes Pod如何指定自定义命名空间下的ServiceAccount

serviceAccountName字段仅支持填写同命名空间下的ServiceAccount名称，不支持命名空间/名称的跨命名空间引用格式，这就是你看到RFC 1123格式校验报错的直接原因——斜杠/不属于该字段允许的合法字符。

Kubernetes中ServiceAccount是命名空间作用域资源，Pod只能绑定和自身同属一个命名空间的ServiceAccount，没有跨命名空间绑定SA的能力。你去掉前缀后找不到SA，本质是因为你的Deployment、Service资源都没有显式指定命名空间，默认被部署到default命名空间，自然找不到test-na命名空间下的test-k8-sa。

核心逻辑是让Deployment管理的Pod和目标ServiceAccount处于同一个命名空间，操作步骤如下：

• 提前确认自定义命名空间test-na已创建，且test-k8-sa确实存在于该命名空间下
• 给Deployment、Service的metadata段添加namespace: test-na字段，和ServiceAccount所在命名空间保持一致
• Pod spec下的serviceAccountName字段直接填写SA名称test-k8-sa即可，不需要加任何命名空间前缀

修正后的完整配置如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-scheduler
  namespace: test-na
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test-scheduler
  template:
    metadata:
      labels:
        app: test-scheduler
    spec:
      serviceAccountName: test-k8-sa
      nodeSelector:
        iam.gke.io/gke-metadata-server-enabled: "true"
      containers:
        - name: test-scheduler
          image: gcr.io/PROJECT_ID/IMAGE:TAG
          ports:
            - name: scheduler-port
              containerPort: 8002
              protocol: TCP
          env:
            - name: NAMESPACE
              value: test-scheduler
            - name: CONTAINER_NAME
              value: test-scheduler
---
apiVersion: v1
kind: Service
metadata:
  name: test-scheduler
  namespace: test-na
spec:
  selector:
    app: test-scheduler
  ports:
    - port: 8002
      protocol: TCP
      targetPort: scheduler-port 

• 执行kubectl apply时不需要额外加-n test-na参数，YAML中声明的metadata.namespace优先级最高
• Workload Identity的其余配置（K8s SA与GCP服务账号绑定、权限授予）不受本次修改影响，只要Pod和K8s SA处于正确命名空间即可正常工作
• 不要尝试通过手动挂载SA令牌的方式跨命名空间引用SA，这种操作违反Kubernetes权限模型，存在安全风险，也无法被GKE Workload Identity组件正确识别

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