AKS环境下Nginx Ingress+Cert-Manager证书签发失败求助

核心问题分析 #

目前遇到的两个关键错误：HTTP-01挑战连接超时、无法找到challenges.acme.cert-manager.io资源，分别指向网络连通性问题和CRD/权限配置问题，以下是针对性排查步骤：

一、排查HTTP-01挑战超时问题 #

• 验证网络入站规则：
  确认AKS集群的NSG（网络安全组）或Azure防火墙已开放80端口入站到Nginx Ingress Controller的External-IP，同时开放443端口出站到Let's Encrypt的ACME服务器（acme-v02.api.letsencrypt.org）。可通过Azure门户查看NSG的入站/出站规则，或在AKS节点上执行nc -zv acme-v02.api.letsencrypt.org 443测试连通性。
• 确认DNS解析有效性：
  用nslookup <dev-domain>或dig <dev-domain>测试公网是否能将dev环境域名正确解析到Ingress Controller的External-IP，避免因DNS缓存或配置错误导致挑战请求无法到达集群。
• 检查Ingress 80端口可用性：
  1. 查看Nginx Ingress Service状态：kubectl get svc -n default，确认80端口的TYPE为LoadBalancer且External-IP已分配。
  2. 创建临时测试Ingress验证连通性：

     apiVersion: networking.k8s.io/v1
     kind: Ingress
     metadata:
       name: test-ingress
       namespace: dev
     spec:
       rules:
       - host: <dev-domain>
         http:
           paths:
           - path: /test
             pathType: Prefix
             backend:
               service:
                 name: <your-dev-service>
                 port:
                   number: 80
     

     部署后执行curl http://<dev-domain>/test测试，确认HTTP请求能正常到达后端服务，排除Ingress本身的转发问题。
• 检查临时挑战Ingress：
  发起证书请求后，执行kubectl get ingress -n dev，查看是否存在cm-acme-http-solver-xxxx格式的临时Ingress。若不存在，说明cert-manager未触发挑战流程，需检查Ingress的TLS配置是否正确关联ClusterIssuer。

二、排查challenges.acme.cert-manager.io资源找不到问题 #

• 验证CRD安装状态：
  执行kubectl get crds | grep cert-manager，确认challenges.acme.cert-manager.io已存在。若缺失，重新安装cert-manager并确保开启CRDs：

  helm upgrade --install cert-manager cert-manager/cert-manager \
    -n default \
    --set installCRDs=true
  

• 检查cert-manager权限配置：
  查看cert-manager的ClusterRoleBinding：kubectl get clusterrolebindings | grep cert-manager，确认其绑定的ClusterRole包含对challenges.acme.cert-manager.io资源的create、get、list、update、delete权限。若权限不足，重新部署cert-manager或手动调整ClusterRole。
• 查看Challenge资源状态：
  执行kubectl get challenges.acme.cert-manager.io -A，检查是否有对应域名的Challenge资源。若资源未创建，需排查Ingress的TLS段配置：

  tls:
  - hosts:
    - <dev-domain>
    secretName: <your-tls-secret-name>
  

  确保secretName未被占用，且Ingress注解cert-manager.io/cluster-issuer: "<your-cluster-issuer-name>"正确配置。

优化方案 #

• 切换为DNS-01挑战：
  若HTTP-01因网络限制无法使用，改用DNS-01挑战（无需开放80端口）。针对Azure DNS，可配置cert-manager使用Azure Managed Identity授权，自动添加TXT记录完成验证，避免防火墙/NSG的端口限制。
• 隔离资源命名空间：
  将Nginx Ingress部署到ingress-nginx命名空间，cert-manager部署到cert-manager命名空间，替代default命名空间，便于权限隔离和资源管理，减少冲突风险。
• 提升cert-manager日志级别：
  升级cert-manager时开启debug日志：

  helm upgrade cert-manager cert-manager/cert-manager \
    -n cert-manager \
    --set logLevel=debug
  

  更详细的日志可帮助定位挑战失败的具体原因，比如DNS解析延迟、权限不足等。
• 先使用Let's Encrypt测试环境：
  将ClusterIssuer的服务器地址改为测试环境（https://acme-staging-v02.api.letsencrypt.org/directory），验证配置无误后再切换到生产环境，避免触发生产环境的速率限制。
• 规范Ingress注解配置：
  在Ingress中添加必要注解，确保cert-manager正确识别：

  metadata:
    annotations:
      cert-manager.io/cluster-issuer: "<your-cluster-issuer-name>"
      nginx.ingress.kubernetes.io/ssl-redirect: "true"
      nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
  

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