在K8S中，K8S集群外部，突然之间无法访问到Pod，排查思路是什么？

Kubernetes外部访问突发失效？

在生产环境中，Kubernetes服务突发不可用是最让运维团队心跳加速的场景。本文将分享经过300+生产事故锤炼的排查方法论，用一张排查地图帮你快速定位问题。

---

一、第一反应：建立三维坐标系

当警报响起时，先明确三个关键维度：

1. 影响范围：单服务不可用还是所有服务异常？
2. 时间线：最后一次正常操作是什么？（如部署/配置变更）
3. 访问路径：客户端 → 负载均衡 → NodePort → Service → Pod的哪一环断裂？

---

二、实战排查流程图

开始
│
├─ 1. 检查服务暴露方式是否存活
│   ├─ LoadBalancer: 查看云平台控制台状态
│   ├─ NodePort:    telnet <节点IP>:30000
│   └─ Ingress:     curl -v http://ingress-controller-pod
│
├─ 2. 验证Endpoint是否健康
│   └─ kubectl get endpoints <service-name>
│
├─ 3. 穿透式网络探测
│   ├─ 从外部网络测试：nc -zv <外部IP> <端口>
│   ├─ 从节点测试：       kubectl exec <node-shell> curl <ClusterIP>:<port>
│   └─ 跨节点测试：       kubectl exec <pod-A> curl <pod-B_IP>
│
├─ 4. 解剖Service配置
│   ├─ 检查标签选择器：kubectl describe svc <name> | grep Selector
│   ├─ 端口映射验证：  kubectl get svc -o=jsonpath='{...targetPort}'
│   └─ 会话保持检查：  spec.sessionAffinity配置
│
├─ 5. 深挖网络策略
│   ├─ 查看NetworkPolicy：kubectl get networkpolicy
│   ├─ 检查Calico日志：   kubectl logs -n kube-system <calico-pod>
│   └─ 临时放行策略：     kubectl apply -f allow-all.yaml（仅测试）
│
├─ 6. 追踪数据包路径
│   ├─ 在Node抓包：      tcpdump -i eth0 port <NodePort>
│   ├─ 在Pod抓包：       kubectl exec <pod> -- tcpdump -i eth0
│   └─ 使用nsenter工具：  nsenter -t <pid> -n tcpdump
│
└─ 7. 终极武器：Sidecar诊断容器
    └─ 启动临时诊断Pod：
       kubectl run debug --image=nicolaka/netshoot --rm -it -- bash

---

三、十大经典踩坑场景

场景1：Label手滑打错

症状：Service显示有Endpoint，但实际无流量
检测：kubectl get pods -l app=your-label
修复：对齐Service Selector与Pod Label

场景2：NodePort端口被占

症状：Node显示LISTEN但无法连接
检测：netstat -tulnp | grep 30000
修复：更换端口或排查占用进程

场景3：云厂商负载均衡器隐身

症状：LoadBalancer External IP显示
检测：查看云平台配额和健康检查配置
修复：检查子网标签和安全组规则

场景4：Ingress控制器暴走

症状：Ingress配置正常但返回404
检测：kubectl logs -n ingress-nginx <pod> | grep "error reloading"
修复：检查Annotation语法和证书Secret

场景5：NetworkPolicy作祟

症状：集群内可访问，外部不通
检测：临时创建allow-all策略测试
修复：细化策略规则，参考：

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-external
spec:
  podSelector: {}
  ingress:
  - from: []

场景6：kube-proxy抽风

症状：NodePort无iptables规则
检测：iptables-save | grep <ServiceIP>
修复：重启kube-proxy或检查conntrack表

场景7：Pod跨节点不通

症状：同节点Pod可互访，跨节点失败
检测：检查CNI插件日志和节点路由表
修复：确认VXLAN/BPF模式配置一致性

场景8：CoreDNS罢工

症状：域名解析超时
检测：kubectl exec -it busybox -- nslookup kubernetes.default
修复：检查CoreDNS副本数和上游DNS配置

场景9：节点防火墙觉醒

症状：突然新增iptables规则
检测：iptables -L KUBE-SERVICES -nv --line-numbers
修复：禁用firewalld或配置白名单

场景10：MTU黑洞吞噬

症状：大包丢失，小包正常
检测：ping -s 1472 <目标IP>（分片测试）
修复：调整CNI的MTU值小于物理网络

---

四、预防性运维 Checklist

1. 日常巡检项：

   • 每周校验Service/Endpoint映射关系
   • 监控LoadBalancer健康检查成功率
   • 定期清理ESTABLISHED过万的连接

2. 混沌工程测试：

   # 随机重启ingress控制器
   kubectl delete pod -n ingress-nginx --random
   # 模拟网络分区
   iptables -A INPUT -s <node-ip> -j DROP
   

3. 关键监控指标：

   kube_service_spec_type //服务类型
   probe_success{job="kubernetes-services"} //健康检查
   node_network_up //网卡状态
   

---

五、高级武器库

1. eBPF终极追踪：

   kubectl trace node <node-name> \
     'kprobe:kube_proxy* { @[comm] = count(); }'
   

2. Istio诊断工具：

   istioctl analyze --all-namespaces
   istioctl proxy-config endpoints <pod-name>
   

3. 网络拓扑可视化：

   kubectl get networkpolicy -o yaml | weave scope
   

---

结语：网络问题排查就像侦探破案，需要系统性的思维工具。建议团队定期进行"断网演习"，培养对K8s网络架构的肌肉记忆。记住：每一次故障都是优化系统韧性的机会，做好根因分析才能让系统越炸越强！