GitLab CI/CD部署Helm至GKE遇令牌过期及square/go-jose加密错误

我来帮你一步步搞定这几个在GitLab CI/CD部署Helm到GKE时遇到的问题，都是实际操作里常踩的坑，咱们逐个解决：

你直接复制gcloud生成的kubeconfig到Runner里肯定会遇到令牌过期的问题——因为gcloud生成的默认令牌有效期只有1小时，而且不会自动刷新。正确的做法是在CI/CD流程中动态生成有效的kubeconfig，而不是硬编码静态文件，这时候就可以用到你提到的应用默认凭据（ADC）方案。

ADC是GCP用来让应用程序自动获取认证凭据的机制，在GitLab CI里用起来很清晰，步骤如下：

• 第一步：在GCP控制台创建一个服务账号，给它分配足够的权限来操作GKE集群（比如roles/container.developer，或者更精细的roles/container.clusterAdmin如果需要全权限），同时要确保这个账号有Helm部署所需的K8s权限（比如edit或者admin集群角色）。
• 第二步：下载这个服务账号的JSON密钥文件，然后把它添加到你的GitLab项目的CI/CD变量里：
  • 变量名可以设为GCP_SERVICE_ACCOUNT_KEY，类型选择File（这样GitLab会把它作为文件挂载到Runner容器里）。
• 第三步：在你的.gitlab-ci.yml里配置CI流程：

  deploy:
    image: google/cloud-sdk:alpine
    stage: deploy
    script:
      # 激活服务账号，自动配置ADC
      - gcloud auth activate-service-account --key-file="$GCP_SERVICE_ACCOUNT_KEY"
      # 动态获取GKE集群的有效kubeconfig
      - gcloud container clusters get-credentials your-cluster-name --zone your-cluster-zone --project your-gcp-project-id
      # 安装Helm（如果镜像自带可以跳过）
      - apk add --no-cache helm
      # 部署Helm Chart
      - helm upgrade --install your-release ./your-chart-directory --namespace your-namespace --create-namespace
  

  这样每次CI运行时，都会通过服务账号获取最新的有效令牌，完全避免了静态kubeconfig过期的问题。

这个错误一般和Dashboard的JWT签名密钥或者认证凭据有关，常见的解决方法有这几个：

• 重新生成Dashboard的签名密钥：
  有时候Dashboard的默认证书/密钥损坏或者过期，你可以删除现有的密钥然后重新部署：

  # 删除旧的Dashboard证书密钥
  kubectl delete secret kubernetes-dashboard-certs -n kubernetes-dashboard
  # 重新部署Dashboard（替换成和你的K8s版本兼容的版本）
  kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml
  

  重新部署后，Dashboard会自动生成新的签名密钥，这个问题大概率会解决。
• 检查认证凭据的有效性：
  如果你是用kubeconfig登录Dashboard，确保里面的用户令牌是最新的，没有格式错误（比如多余的换行、空格）。可以用kubectl create token命令生成一个临时令牌来测试：

  kubectl create token kubernetes-dashboard -n kubernetes-dashboard
  

  用这个新生成的令牌登录Dashboard，看看是否还报错。
• 检查版本兼容性：
  如果你的K8s版本比较新，而Dashboard版本太旧，也可能出现加密相关的兼容性问题。去Dashboard的官方文档确认你使用的版本和K8s版本匹配，然后升级或降级Dashboard到兼容版本。

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