Azure Pipeline传递KeyVault密钥至AKS部署的ASP.NET Core应用失败：密钥‘ccg-afarber-v3’未找到

首先，咱们直奔问题核心：你的Pod部署在ccg-afarber-v3命名空间，但你创建的Secret实际在default命名空间里，所以Kubernetes找不到它！

问题分析 #

你在Azure CLI任务里执行kubectl create secret generic ${{ parameters.Namespace }}的时候，没有指定--namespace参数，Kubernetes默认会把Secret创建在default命名空间中。而你的Deployment配置里明确指定了要从ccg-afarber-v3命名空间读取Secret，两者不匹配，自然就抛出了Error: secret "ccg-afarber-v3" not found的错误。

你可以先执行这个命令验证一下：

kubectl get secrets --namespace default

肯定能看到名为ccg-afarber-v3的Secret在里面。

解决方案 #

1. 修改Azure Pipeline中的Secret创建命令 #

更新你的AzureCLI@2任务里的inlineScript，在删除和创建Secret时都加上--namespace参数，指定目标命名空间：

az aks get-credentials --resource-group ccg-config --name ccg-config-cluster
# 删除时指定命名空间
kubectl delete secrets/${{ parameters.Namespace }} --namespace ${{ parameters.Namespace }}
# 创建时指定命名空间
kubectl create secret generic ${{ parameters.Namespace }} --namespace ${{ parameters.Namespace }} --from-literal=ApplicationInsightsInstrumentationKey=$(ApplicationInsightsInstrumentationKey)

2. 临时修复已创建的Secret（可选） #

如果不想重新跑Pipeline，也可以直接把default命名空间里的Secret复制到目标命名空间：

kubectl get secret ccg-afarber-v3 --namespace default -o yaml | kubectl apply --namespace ccg-afarber-v3 -f -

执行完这个命令后，重启你的Pod就能正常拉取Secret了。

3. 额外建议 #

以后创建Kubernetes资源时，尽量养成指定命名空间的习惯，避免跨命名空间的资源引用错误。也可以在Pipeline里加一步检查，确认Secret存在于目标命名空间后再执行部署任务，比如：

kubectl get secret ${{ parameters.Namespace }} --namespace ${{ parameters.Namespace }} || echo "Secret not found in target namespace"

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