重新部署EKS集群后Route 53域名无法访问的排查求助

一、SSL证书未关联负载均衡器的核心原因排查 #

• Ingress注解缺失/错误：重新部署EKS后，Nginx Ingress的配置大概率没带上AWS证书关联的关键注解。之前能正常工作的Ingress配置里肯定有指定ACM证书ARN的注解，重新部署时可能遗漏了。
• IAM权限失效：即便之前权限没问题，新集群里Ingress Controller使用的服务账号可能没绑定正确的IAM角色——要操作LB关联证书，需要elasticloadbalancing:ModifyListener、acm:DescribeCertificate这类权限，得确认IRSA或者aws-auth配置是否同步到新集群。
• 证书引用错误：检查Ingress里填的证书ARN是不是当前状态为READY的那个，会不会误引用了旧证书或者其他未生效的证书。

二、域名可达性问题排查点 #

• 负载均衡器状态：去AWS控制台看LB是不是处于active状态，目标组的健康检查有没有通过。要是健康检查失败，LB会直接切断流量，CNAME解析对了也没用。
• Ingress资源状态：执行kubectl describe ingress <你的Ingress名称>，看Events栏有没有报错——比如证书找不到、LB创建超时、权限不足这些信息，都是直接线索。
• 安全组规则：虽然开了80/443，但得确认LB的安全组允许互联网访问，同时节点安全组要允许LB的安全组访问Pod的端口（比如容器暴露的8080）。

三、具体修复步骤 #

1. 补全Ingress注解：更新你的Ingress资源，加上AWS LB必需的注解，示例配置如下：

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: your-app-ingress
     annotations:
       kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:<区域>:<账号ID>:certificate/<证书ID>"
       kubernetes.io/aws-load-balancer-ssl-ports: "443"
       kubernetes.io/aws-load-balancer-backend-protocol: "http"
       kubernetes.io/aws-load-balancer-type: "external" # 按需调整为internal或nlb
   spec:
     tls:
     - hosts:
       - your-domain.com
     rules:
     - host: your-domain.com
       http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: your-backend-service
               port:
                 number: 80
   

   应用配置：kubectl apply -f your-ingress.yaml

2. 验证Ingress Controller权限：

   • 如果用IRSA，确认Ingress Controller的服务账号（通常在kube-system命名空间下，名为nginx-ingress）关联的IAM角色包含以下权限：

     {
       "Version": "2012-10-17",
       "Statement": [
         {
           "Effect": "Allow",
           "Action": [
             "elasticloadbalancing:DescribeLoadBalancers",
             "elasticloadbalancing:DescribeListeners",
             "elasticloadbalancing:ModifyListener",
             "elasticloadbalancing:AddTags",
             "acm:DescribeCertificate"
           ],
           "Resource": "*"
         }
       ]
     }
     

   • 不用IRSA的话，检查kube-system下的aws-auth ConfigMap，确保角色映射配置正确。

3. 确认LB与目标组状态：

   • 执行kubectl get svc -n kube-system找到Nginx Ingress的LB服务，复制其EXTERNAL-IP对应的域名，去AWS控制台核对该LB的443端口监听器是否关联了指定证书。如果没关联，删除Ingress再重新创建，触发Ingress Controller更新LB配置。
   • 查看目标组的健康检查结果，要是失败，检查Pod的端口是否正确、健康检查路径是否返回200状态码。

4. 验证DNS映射：虽然nslookup返回了CNAME，但确认该CNAME指向的是当前新集群的LB域名，而不是旧集群遗留的LB地址——要是Route53记录没更新，手动修正即可。

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