Istio服务网格Pod含Sidecar却无法被识别的503问题排查求助

一、先解决 istioctl x describe pod 报错问题 #

• 执行 kubectl get pods -n demoapp 确认目标Pod的准确名称，排查是否存在拼写错误、Pod已重建（重启后名称变更）的情况
• 若Pod确实存在，尝试用Pod IP替代名称执行命令：istioctl x describe ip <目标Pod的IP> -n demoapp
• 检查本地istioctl版本是否与集群中Istio控制平面版本一致，版本不匹配可能导致命令执行异常

二、503 响应问题排查步骤 #

1. 验证应用Pod本身的可用性 #

• 在集群内部部署测试Pod（如sleep），执行 curl <目标PodIP>:<应用端口>，确认应用本身是否能正常响应，排除应用自身故障
• 检查目标Pod的**就绪探针（readinessProbe）**配置及状态：执行 kubectl describe pod <目标Pod名称> -n demoapp，查看Readiness Gates和Conditions字段，若探针失败，Istio会将Pod从负载均衡池中移除，返回503

2. 核对Istio流量规则配置 #

• 确认VirtualService的hosts字段与Gateway的hosts字段完全匹配，且Gateway的selector标签与Ingress Gateway Pod的标签一致
• 检查DestinationRule是否配置了错误的subset：若VirtualService指向了某个subset，需确认该subset对应的Pod标签与目标Pod的标签完全匹配，否则会因找不到后端返回503
• 查看Sidecar的端口配置：执行 kubectl describe pod <目标Pod名称> -n demoapp，确认应用容器的端口已被Sidecar正确监听，无端口冲突

3. 检查Ingress Gateway状态 #

• 查看Ingress Gateway Pod的日志：kubectl logs <gateway-pod-name> -n istio-system -c istio-proxy，排查是否存在转发流量时的错误（如找不到后端集群的日志）
• 查看Gateway的路由表：istioctl pc routes <gateway-pod-name> -n istio-system，确认是否存在对应VirtualService的路由规则，规则中的目标服务、端口是否正确
• 确认Gateway Service的外部IP是否正常，且GKE防火墙规则允许外部访问该IP的对应端口（如80/443）

4. 排查网络策略与防火墙 #

• 检查demoapp命名空间和istio-system命名空间的NetworkPolicy配置，确认未阻止Ingress Gateway到应用Pod的流量
• 核对GKE集群的防火墙规则，确保允许集群内部Pod之间的通信（如Istio Gateway所在节点到应用Pod所在节点的端口访问）

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