通过Helm在AKS集群安装ingress-nginx控制器时遭遇Secret获取失败问题求助

我来帮你梳理下这个问题的排查方向，从你提供的日志来看，核心问题是nginx-ingress-ingress-nginx-admission-create这个Job的Pod无法获取对应的Secret——而实际上这个Secret根本没被创建出来，大概率是RBAC权限配置或者Job的ServiceAccount绑定出了问题。咱们一步步来：

1. 检查admission相关的RBAC权限配置 #

首先确认安装过程中创建的ServiceAccount、ClusterRole和ClusterRoleBinding是否正确配置了Secret相关的权限：

# 查看admission用的ClusterRole权限
kubectl describe clusterrole nginx-ingress-ingress-nginx-admission -n ingress-basic
# 查看ClusterRoleBinding是否绑定到了正确的ServiceAccount
kubectl describe clusterrolebinding nginx-ingress-ingress-nginx-admission -n ingress-basic

你需要在ClusterRole的权限列表里看到对secrets资源的get、create、update权限，如果没有这些权限，Job的Pod自然无法创建和读取Secret。

2. 确认Job使用的ServiceAccount是否正确 #

检查admission-create Job的定义，看它是否指定了正确的ServiceAccount：

kubectl describe job nginx-ingress-ingress-nginx-admission-create -n ingress-basic

查看spec.template.spec.serviceAccountName字段，它应该指向nginx-ingress-ingress-nginx-admission这个ServiceAccount。如果这个字段缺失，Pod会使用默认的default ServiceAccount，而默认账号通常没有操作Secret的权限，这就会导致报错。

3. 手动创建Secret并重新触发Job（临时解决方法） #

如果确认是权限问题导致Secret没创建出来，你可以手动生成这个Secret，然后重新运行Job：

# 生成admission webhook需要的证书和密钥
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=nginx-ingress-ingress-nginx-admission.ingress-basic.svc"
# 在ingress-basic命名空间下创建Secret
kubectl create secret tls nginx-ingress-ingress-nginx-admission --key tls.key --cert tls.crt -n ingress-basic
# 删除现有的失败Job，让Helm重新创建
kubectl delete job nginx-ingress-ingress-nginx-admission-create -n ingress-basic
# 重新执行Helm upgrade命令（带上你原来的所有参数）
helm upgrade nginx-ingress ingress-nginx/ingress-nginx ^
  --namespace ingress-basic ^
  --version 3.36.0 ^
  --set controller.replicaCount=2 ^
  --set controller.nodeSelector."kubernetes\.io/os"=linux ^
  --set controller.image.registry=%ACR_URL% ^
  --set controller.image.image=%CONTROLLER_IMAGE% ^
  --set controller.image.tag=%CONTROLLER_TAG% ^
  --set controller.image.digest="" ^
  --set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux ^
  --set controller.admissionWebhooks.patch.image.registry=%ACR_URL% ^
  --set controller.admissionWebhooks.patch.image.image=%PATCH_IMAGE% ^
  --set controller.admissionWebhooks.patch.image.tag=%PATCH_TAG% ^
  --set controller.admissionWebhooks.patch.image.digest="" ^
  --set defaultBackend.nodeSelector."kubernetes\.io/os"=linux ^
  --set defaultBackend.image.registry=%ACR_URL% ^
  --set defaultBackend.image.image=%DEFAULTBACKEND_IMAGE% ^
  --set defaultBackend.image.tag=%DEFAULTBACKEND_TAG% ^
  --set defaultBackend.image.digest="" ^
  -f internal-load-balancer.yaml

4. 检查AKS集群的额外RBAC限制 #

有些AKS集群可能配置了Azure AD RBAC或者自定义的集群权限限制，你需要确认执行Helm安装的账号是否拥有足够的集群级权限——比如是否绑定了cluster-admin或者能创建ClusterRole、ClusterRoleBinding的角色。如果账号权限不足，Helm可能无法正确创建admission所需的RBAC资源，进而导致后续的Secret创建失败。

5. 排查自定义配置文件的冲突 #

你在安装时指定了internal-load-balancer.yaml，请检查这个文件里是否有修改admission webhook相关的配置，比如是否禁用了admission webhook、修改了ServiceAccount名称或者覆盖了RBAC配置，这些都可能导致权限异常。

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