EKS集群Istio Gateway NLB仅部分目标组健康问题排查

已知前提 #

• 集群仅配置私有端点，通过Istio Gateway预置内部NLB，共生成5个目标组，3个健康、2个不健康
• 所有目标组后端为相同集群节点，仅监听端口存在差异
• 测试应用可通过NLB正常访问，已验证安全组放通所有流量，排除安全组拦截因素
• 已掌握配置：istio-ingressgateway LoadBalancer类型Service完整配置、已确认健康的端口（status-port 15021、http2 80）配置、istio-ingressgateway对应Endpoints完整配置

排查方向 #

1. 匹配不健康目标组的端口归属 #

首先在AWS控制台定位2个不健康目标组对应的监听端口，和istio-ingressgateway Service暴露的端口逐一比对，确认端口用途：

• Istio IngressGateway默认会暴露多个非业务端口，常见的包括15012（pilot-agent gRPC端口）、15443（TLS透传端口）、15090（Envoy metrics端口）、15017（webhook端口）等，这类端口很多默认仅绑定Pod本地回环地址，或者仅接受特定协议的请求，NLB默认TCP探测会直接被拒绝
• 核对每个端口对应的健康检查规则：15021端口健康的核心原因是Istio默认在该端口提供/healthz/ready的HTTP健康响应，只要NLB配置了对应HTTP健康检查就会通过；其余端口如果没有适配健康检查规则，很容易出现探测失败。

2. 核对Service配置与AWS LB Controller的生成逻辑 #

• 检查istio-ingressgateway Service的spec.ports列表，确认是否存在未配置对应Istio Gateway路由、不需要对外暴露的端口：AWS Load Balancer Controller默认会为LoadBalancer Service上声明的每一个端口生成独立的目标组和监听器，和端口是否实际承载业务无关
• 检查Service上的service.beta.kubernetes.io/aws-load-balancer-healthcheck-*系列注解，确认是否仅为80、15021端口配置了正确的健康检查规则，剩余端口沿用了默认的错误配置。

3. 节点侧直接验证端口连通性 #

登录任意集群节点，执行nc -zv <节点本地IP> <不健康目标组对应端口>直接测试连通性：

• 如果返回连接拒绝，说明对应端口的NodePort未在节点上正常监听，需要进一步排查kube-proxy的iptables/ipvs规则是否同步正常、istio-ingressgateway Pod是否正常监听对应容器端口
• 如果返回连通正常，问题基本锁定为NLB对应目标组的健康检查配置错误，调整探测协议、端口、路径即可。

4. 核对目标组类型一致性 #

检查5个目标组的目标类型是否统一：

• instance类型目标组会直接探测节点的NodePort，ip类型目标组会直接探测Pod IP
• 如果Service上的流量策略配置存在冲突，可能导致部分端口生成的目标组类型不一致，探测路径错误直接触发健康检查失败。

可行解决方法 #

• 清理无效端口暴露：直接修改istio-ingressgateway Service的spec.ports配置，删除没有对外访问需求的非业务端口（比如metrics、admin、webhook类端口），AWS LB Controller会自动删除对应多余目标组，从根源上消除无意义的健康检查异常。
• 适配对应端口的健康检查规则：如果确实需要保留相关端口的对外暴露能力，按端口实际服务属性配置NLB健康检查：HTTP/HTTPS类端口配置HTTP协议健康检查，探测路径设置为/healthz/ready；纯TCP服务端口确认在节点0.0.0.0地址正常监听后，配置TCP协议健康检查。
• 临时兜底调整：如果确认不健康端口不影响现有业务转发（当前应用可正常访问已经验证业务链路连通），可适当放宽对应目标组的健康检查失败阈值，避免偶发探测失败导致目标被摘除，该方案仅作临时兜底，不建议长期使用。

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