EKS集群Ingress结合ELB与Route 53无法正常工作求助

一、先解决Ingress ADDRESS未映射问题 #

• 核对Ingress与IngressClass的关联：确认Ingress资源的spec.ingressClassName字段和已创建的IngressClass名称完全一致。执行kubectl get ingressclass查看IngressClass列表，再通过kubectl describe ingress <你的Ingress名称>验证关联是否正确。
• 检查Ingress Controller状态：EKS依赖Ingress Controller（如AWS Load Balancer Controller）创建ELB，执行kubectl get pods -n kube-system（若控制器部署在其他命名空间则替换）确认Pod是否处于Running状态，再通过kubectl logs <控制器Pod名称> -n kube-system查看日志是否有报错。
• 验证Ingress Controller的IAM权限：AWS Load Balancer Controller需要通过IRSA绑定足够权限的IAM策略（如AmazonEKSLoadBalancerControllerPolicy），确认IRSA配置正确，控制器具备创建、管理ELB的权限。

二、排查ELB健康检查失败 #

• 检查Service健康检查配置：LoadBalancer类型的Service会自动配置ELB健康检查，执行kubectl describe service <你的Service名称>查看healthCheckNodePort对应的端口，在节点上执行curl <节点IP>:<健康检查端口>/<健康检查路径>（默认路径为/），确认Pod能正常响应健康检查请求。
• 检查节点安全组规则：确保节点安全组入方向允许ELB安全组的流量访问健康检查端口和业务端口，ELB的健康检查流量来自其自身安全组，需在节点安全组中配置对应授权。
• 排查NetworkPolicy限制：若集群配置了NetworkPolicy，确认规则允许节点或ELB网段的流量访问Pod的健康检查端口和业务端口。
• 查看ELB目标组详情：在AWS控制台进入ELB对应的目标组，查看健康检查的路径、端口、超时/间隔设置是否匹配Web应用的实际情况，也可执行aws elbv2 describe-target-health --target-group-arn <目标组ARN>获取具体失败原因。

三、验证Service与Pod的关联有效性 #

• 核对Service selector与Pod labels：执行kubectl describe service <你的Service名称>查看selector配置，再通过kubectl get pods --show-labels确认Pod的labels与selector完全匹配，不匹配会导致Service无法关联Pod。
• 检查Endpoint状态：执行kubectl get endpoints <你的Service名称>，确认列表中存在Pod的IP和对应端口，若为空则说明selector不匹配或Pod未就绪。

四、验证Route53配置 #

• 确认A记录配置：Route53的A记录需配置为别名指向Ingress对应的ELB域名，而非手动填写IP（ELB IP会动态变化），检查记录值是否为ELB的完整域名。
• 验证域名解析：执行nslookup dobby.abc.com或dig dobby.abc.com，确认返回结果为ELB的域名，确保解析正常。

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