Helm升级无法更新另一EKS集群中Deployment的问题求助

核心问题 #

Pod内运行时出现Kubernetes cluster unreachable: the server has asked for the client to provide credentials，本质是Pod中缺少针对EKS集群B的有效认证凭据：

• 本地运行时，你的环境已经配置好集群B的kubeconfig（包含集群地址、认证信息），但Pod内默认没有这个文件；
• Dockerfile中硬编码的AWS密钥可能未被正确用于生成集群B的认证配置，且这种方式本身不安全。

具体解决方案 #

1. 用IAM角色绑定ServiceAccount（IRSA）替代硬编码密钥 #

在EKS集群中，不要直接在镜像里写AWS密钥，而是通过**IRSA（IAM Roles for Service Accounts）**给Pod绑定有权限访问集群B的IAM角色：

• 先创建一个IAM角色，赋予它访问EKS集群B的权限：至少需要eks:DescribeCluster权限，以及操作集群B资源的对应权限；
• 在集群A中创建ServiceAccount，并通过IRSA绑定这个IAM角色（需要先配置集群A的OIDC提供商）；
• 修改你的Deployment，指定使用这个ServiceAccount：

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: your-app
  spec:
    template:
      spec:
        serviceAccountName: your-sa-name
        # ... 其他配置
  

2. 在Pod内生成集群B的有效kubeconfig #

修改helm.sh脚本，先通过AWS CLI生成集群B的kubeconfig，再执行Helm命令：

#!/bin/bash
# 生成集群B的kubeconfig到临时路径
aws eks update-kubeconfig --name <cluster-B-name> --region us-east-1 --kubeconfig /tmp/kubeconfig-clusterB
# 使用该kubeconfig执行Helm操作
helm upgrade --install <chartname> <chart-dir> --namespace plat --kubeconfig /tmp/kubeconfig-clusterB -f <chart-dir>/values.yaml

这个命令会自动基于Pod的IAM角色凭据生成集群B的认证配置，无需手动管理密钥。

3. 配置集群B的权限信任 #

编辑集群B的aws-auth ConfigMap，让绑定的IAM角色能访问集群B：

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::你的AWS账号ID:role/绑定的IAM角色名
      username: cluster-admin
      groups:
        - system:masters # 可根据需求调整为更细粒度的权限组

排查验证步骤 #

1. 进入Pod执行aws eks describe-cluster --name <cluster-B-name>，确认能获取集群B的信息，验证AWS权限；
2. 执行kubectl --kubeconfig /tmp/kubeconfig-clusterB get nodes，确认能正常访问集群B的资源；
3. 检查Pod的环境变量，确认没有残留的硬编码AWS密钥（IRSA会自动注入临时凭据，无需手动设置）。

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