Istio 1.9.2 跨节点sidecar注入Pod无法连通istiod致健康检查失败

已采集的集群基础状态 #

# 集群节点状态
kubectl get nodes
NAME     STATUS   ROLES                  AGE    VERSION
k8s-d0   Ready    control-plane,master   7d2h   v1.20.5
k8s-d1   Ready    <none>                 7d2h   v1.20.5
k8s-d2   Ready    <none>                 7d2h   v1.20.5

# istio-system命名空间Pod状态
kubectl get pods -n istio-system -o wide                   
NAME                                    READY   STATUS    RESTARTS   AGE     IP             NODE     NOMINATED NODE   READINESS GATES
istio-egressgateway-54658cd5f5-thj76    1/1     Running   0          7m6s    10.244.1.44    k8s-d1   <none>           <none>
istio-ingressgateway-7cc49dcd99-tfkgs   1/1     Running   0          7m6s    10.244.1.43    k8s-d1   <none>           <none>
istiod-db9f9f86-j2mjv                   1/1     Running   0          7m10s   10.244.2.100   k8s-d2   <none>           <none>

# sauron--desenvolvimento命名空间Pod状态
kubectl get pods -n sauron--desenvolvimento -o wide
NAME                      READY   STATUS    RESTARTS   AGE     IP             NODE     NOMINATED NODE   READINESS GATES
sauron-66dc8ff67d-kgsk2   1/2     Running   0          49s     10.244.2.101   k8s-d2   <none>           <none>
sauron-66dc8ff67d-rs8lv   2/2     Running   0          5m27s   10.244.1.46    k8s-d1   <none>           <none>

# istio-system命名空间服务状态
kubectl get services -n istio-system        
NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                                                                      AGE  
istio-egressgateway    ClusterIP      10.99.11.179     <none>        80/TCP,443/TCP,15443/TCP                                                     9m12s
istio-ingressgateway   LoadBalancer   10.100.239.142   <pending>     15021:30460/TCP,80:30453/TCP,443:31822/TCP,15012:30062/TCP,15443:31932/TCP   9m12s
istiod                 ClusterIP      10.104.84.82     <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP                                        9m16s

故障现象 #

• 注入Envoy Sidecar的Pod调度至k8s-d2节点（与istio-ingressgateway所在的k8s-d1节点不同）时，始终无法通过就绪探针，状态停留在1/2 Running
• Sidecar持续报错：Readiness probe failed: Get "http://10.244.2.101:15021/healthz/ready": dial tcp 10.244.2.101:15021: connect: connection refused
• Sidecar日志显示无法连接istiod的15012端口拉取XDS配置，同时无法生成工作负载证书
• 故障Pod内执行curl 10.104.84.82:15012返回连接拒绝，无法访问istiod的ClusterIP服务
• 同节点部署在k8s-d1的注入Sidecar Pod运行状态完全正常，可正常拉取配置、通过探针

故障根因定位 #

从现有状态交叉验证，可直接排除Istio核心组件异常（istiod Pod处于Running状态，同节点的工作负载可正常完成配置拉取），故障点集中在k8s-d2节点的流量转发链路层面：

• ClusterIP是Kubernetes的虚拟服务IP，需依赖每个节点上的kube-proxy组件下发DNAT规则，将目标为ClusterIP的流量转发到后端Pod的真实IP
• 目前k8s-d1节点上的所有Pod均可正常访问istiod，说明k8s-d1侧的kube-proxy规则、防火墙配置、CNI网络均正常
• k8s-d2节点上同时部署了istiod Pod与故障sauron Pod，两者同属节点内部的Pod网段，但访问istiod的ClusterIP时完全不通，说明k8s-d2节点本身的规则同步、防火墙拦截存在问题，导致ClusterIP流量无法被正常转发

最常见的两类触发场景：

1. k8s-d2节点的kube-proxy未正常同步iptables/IPVS规则，缺少istiod ClusterIP对应的DNAT条目，导致Pod发出的流量被丢弃
2. k8s-d2节点的防火墙规则拦截了Pod网段间的双向流量，导致无论同节点还是跨节点的ClusterIP转发流量被节点出接口丢弃

排查与修复步骤 #

• 第一步：测试节点直连Pod IP的连通性
  登录k8s-d2节点，执行curl 10.244.2.100:15012测试直连istiod真实Pod IP的连通性，如果返回超时/拒绝，说明节点网络层存在拦截
  临时关闭节点防火墙做连通性验证（生产环境仅做测试，测试完成后需配置永久规则），放行整个Pod CIDR网段（10.244.0.0/16）的双向访问权限
• 第二步：检查k8s-d2节点的kube-proxy运行状态
  执行命令查看该节点上kube-proxy的日志：kubectl logs -n kube-system -l k8s-app=kube-proxy --field-selector spec.nodeName=k8s-d2
  如果存在apiserver连接超时、规则同步失败的报错，直接删除该节点上的kube-proxy Pod，等待控制器自动拉起新实例，待规则同步完成后在故障Pod内重新测试连通性
• 第三步：检查节点上的CNI插件状态
  查看k8s-d2节点上flannel/calico等CNI插件的Pod运行状态，如果存在重启、报错，重启异常的CNI Pod恢复节点Pod网桥的转发能力
• 修复验证
  网络链路恢复后，Sidecar会自动重试连接istiod拉取配置、生成证书，等待2分钟左右可观察到：
  • 就绪探针不再报连接拒绝，Sidecar健康检查通过
  • Pod READY状态从1/2转为2/2
  • Sidecar日志不再抛出连接超时、证书生成失败的报错

长期优化建议 #

• 用DaemonSet自动下发节点防火墙规则，避免节点重置后规则丢失
• 对kube-proxy、CNI组件的规则同步状态配置监控，出现同步失败时及时告警
• 针对Istio 1.9.2版本的Sidecar连接重试逻辑，可适当增加重试间隔参数，降低网络瞬断对Pod就绪状态的影响

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