Azure DevOps部署K8s集群遇x509证书未知签发机构错误求助

一、先处理K8s版本不兼容问题 #

你的kubectl客户端版本v1.28.2和AKS服务端v1.21.9跨度太大（差了7个小版本），K8s官方要求客户端版本和服务端版本的差距不能超过1个小版本（比如客户端最多比服务端高1个minor版本），版本不匹配不仅会导致API调用异常，还可能放大证书验证类问题。

• 在Azure DevOps的部署流程里添加Kubernetes工具安装器任务，把kubectl版本指定为和服务端匹配的v1.21.9，或者最高v1.22.x（符合兼容规则）。
• 配置时在任务的Version spec字段直接填1.21.9，并确保这个工具安装任务在所有kubectl部署步骤之前执行。

二、修复x509证书验证失败问题 #

1. 更新kubeconfig凭证 #

• 登录Azure门户，找到你的AKS集群，点击左侧的连接，复制页面生成的最新kubeconfig内容。
• 去Azure DevOps的Kubernetes服务连接里，把旧的kubeconfig替换成刚复制的新内容；如果用的是Azure Resource Manager服务连接，直接重新授权一次，让它自动拉取最新的集群凭证（更推荐这种方式，避免手动配置出错）。
• 重点检查kubeconfig里的clusters[].cluster.certificate-authority-data字段，确保是最新的CA证书编码内容，别用过期或错误的旧数据。

2. 临时排查（生产环境禁用） #

如果想快速确认是不是证书本身的问题，可以在kubectl命令里加--insecure-skip-tls-verify参数跳过验证，比如：

kubectl apply -f your-deployment.yaml --insecure-skip-tls-verify

注意：这只是临时排查手段，会关闭TLS安全验证，绝对不能用于生产环境。

3. 重置AKS集群CA证书（如果证书过期或损坏） #

如果上述步骤没用，可能是集群CA证书过期或损坏，用Azure CLI重置凭证：

# 重置用户凭证
az aks get-credentials --resource-group <你的资源组名> --name <你的AKS集群名> --overwrite-existing

# 如果用服务主体认证，重置服务主体凭证
az aks update-credentials --resource-group <你的资源组名> --name <你的AKS集群名> --reset-service-principal --service-principal <SP-ID> --client-secret <SP-Secret>

重置后再重新获取kubeconfig更新到Azure DevOps里。

三、验证修复 #

重新运行Azure DevOps的部署流水线，检查是否还出现证书错误；同时确保服务连接有足够权限（至少需要AKS集群的Contributor或Kubernetes Cluster Admin权限）。

内容的提问来源于stack exchange，提问作者https.samurai