k8s中pod无法访问的排查思路

Kubernetes Pod失联排查手册：从救火到防火的生产级策略

作为Kubernetes老司机，面对Pod突然失联的紧急情况，你是否经历过这样的绝望时刻？本文将分享一套经过上百个生产环境验证的黄金排查流程，助你快速定位问题根源。

---

一、第一响应：5分钟快速定位

Pod失联故障排查决策树

1. Pod状态检查（30秒）

   kubectl get pod -o wide | grep -v Running  # 过滤异常Pod
   

   • 关键状态解读：
     • CrashLoopBackOff：应用持续崩溃
     • ImagePullBackOff：镜像拉取失败
     • Pending：调度失败

2. 事件日志分析（1分钟）

   kubectl describe pod <pod-name> | grep -A20 Events
   

   • 典型事件：

     FailedScheduling: 0/3 nodes are available: 3 Insufficient cpu
     

3. 存活探针检查（2分钟）

   livenessProbe:
     httpGet:
       path: /healthz
       port: 8080
     initialDelaySeconds: 30  # 常见配置错误点
   

   • 快速验证：

     kubectl exec -it <pod> -- curl localhost:8080/healthz
     

---

二、网络层深度排查

1. 四层连通性测试

   # 创建调试容器
   kubectl run net-tester --image=nicolaka/netshoot -- sleep 3600
   
   # 进入容器执行测试
   kubectl exec -it net-tester -- 
   > curl -v telnet://<pod-ip>:<port>  # TCP层测试
   > dig <service-name>.<namespace>.svc.cluster.local  # DNS解析测试
   

2. Service端点验证

   kubectl get endpoints <service-name>  # 查看实际转发地址
   

   • 异常现象：Endpoints列表为空或IP错误

3. 网络策略审计

   kubectl get networkpolicy -A  # 查看生效的网络策略
   

   • 经典案例：

     # 错误配置导致拒绝所有入站流量
     ingress:
     - from: []
     

---

三、系统层隐藏问题挖掘

1. 节点资源黑洞

   # 查看节点资源水位
   kubectl top node --use-protocol-buffers
   
   # 检查磁盘inode
   kubectl debug node/<node-name> -it -- chroot /host df -i
   

2. 内核参数陷阱

   # 常见问题参数
   sysctl -a | grep -E 'somaxconn|tw_reuse'
   

   • 关键值参考：

     net.core.somaxconn = 32768
     net.ipv4.tcp_tw_reuse = 1
     

3. CNI插件故障

   # Calico诊断
   calicoctl node status
   
   # Flannel日志检查
   kubectl logs -n kube-system kube-flannel-ds-xxxxx
   

---

四、高级诊断工具链

工具名称	适用场景	使用示例
ksniff	容器网络抓包	kubectl ksniff <pod> -p 80
kube-score	配置健康扫描	kube-score score pod.yaml
popeye	集群健康诊断	popeye -n <namespace>
kube-burner	压力测试复现	kube-burner init -c pod.yml

---

五、生产环境经典案例库

1. 案例1：时钟漂移导致证书失效

   • 现象：HTTPS连接突然失败
   • 排查：

     kubectl exec <pod> -- date && date
     # 节点时间与Pod时间差异超过证书有效期
     

   • 解决：部署NTP时间同步服务

2. 案例2：IPVS模式下的端口复用

   • 现象：随机出现连接重置
   • 排查：

     sysctl -w net.ipv4.vs.conn_reuse_mode=0
     

   • 修复：调整IPVS内核参数

3. 案例3：Cilium的BPF映射溢出

   • 现象：网络策略突然失效
   • 排查：

     cilium status | grep BPF
     

   • 解决：清理BPF映射或升级CNI版本

---

六、防御性编程实践

1. Pod启动自检脚本

   lifecycle:
     postStart:
       exec:
         command: ["/bin/sh", "-c", "curl localhost:8080/health || exit 1"]
   

2. 混沌工程验证

   # 模拟网络中断
   kubectl chaos mesh network delay --duration=5m pod/<app>
   

3. 监控黄金指标

   1. 就绪端点变化率
   2. 容器重启次数
   3. TCP重传率
   4. DNS查询延迟
   

---

七、排查速查手册

症状	优先检查点	关键命令
服务完全不可用	Pod状态/事件日志	kubectl get events -A --sort-by=.metadata.creationTimestamp
间歇性连接失败	节点TCP连接池	ss -s
跨命名空间访问失败	网络策略/域名解析	kubectl run -it dns-test --image=busybox:1.28 -- nslookup <service>
仅特定节点异常	内核版本/硬件兼容性	kubectl get nodes -o wide

---

通过建立系统化的排查思维，结合防御性设计，我们可以将故障恢复时间从小时级缩短到分钟级。记住：每次事故都是改进系统的最佳机会，建议建立故障复盘机制，将经验沉淀为自动化检查脚本。