上一篇【第50篇】多集群网络互联——Submariner和Cilium Cluster Mesh下一篇【第52篇】K8s安全体系全景——Authentication/Authorization/Admission三道防线摘要前面五篇把K8s网络从模型到插件、从DNS到策略都讲透了。但理论和实战之间隔着一道墙真出问题的时候你对着一个超时的错误根本不知道从哪下手。网络问题最磨人的地方在于——它横跨多个层级。一个HTTP请求从Pod出去要过Pod网络、Service转发、kube-proxy、CNI插件、Node路由、物理网络……任何一层出问题表现都是连不上但根因天差地别。这篇文章给你一条**“黄金排查路径”**Pod→Service→Node→外部。按顺序一层层剥配合ip/nsenter/tcpdump/kubectl exec这几把利器90%的网络问题都能在一顿饭功夫内定位。一、黄金排查路径1.1 总览【网络排查黄金路径——从内到外逐层剥洋葱】 请求: Pod A → (Pod网络) → Service → (Node网络) → 外部/对端Pod │ │ │ ▼ ▼ ▼ Layer1: Pod本机能通吗 (localhost / 自身IP) Layer2: Service能通吗 (ClusterIP / Endpoints) Layer3: Node层面OK吗 (CNI / 路由 / 防火墙) Layer4: 外部/跨Node能通吗(物理网络 / 安全组) 口诀先确认自己没问题再确认中间人没问题 最后确认外面没问题。要点排查网络最忌讳东戳一下西戳一下。记住这个顺序——先Pod内部再Service再Node最后外部。每次只验证一层确认这层OK了再往下一层走。这样你永远不会在Pod本身都起不来的时候去调CNI。二、Layer 1Pod自身网络2.1 Pod能上网吗进程真在监听吗# 1. 进Pod看看进程在不在监听kubectlexec-itmy-pod --netstat-tlnp2/dev/null||\kubectlexec-itmy-pod -- ss-tlnp# 如果看不到 0.0.0.0:8080 在 LISTEN → 应用没起来或监听了127.0.0.1# 2. 在Pod里自己curl自己kubectlexec-itmy-pod --curl-slocalhost:8080/health# 自己都curl不通 → 应用层问题不是网络问题先去看应用日志# 3. 看Pod IP 和 路由kubectlexec-itmy-pod --ipaddr show kubectlexec-itmy-pod --iproute show2.2 常见坑应用只监听127.0.0.1【经典坑应用监听 localhost集群里谁都连不上】 错误配置 server.listen(127.0.0.1, 8080) ← 只接受本机回环 → 其他Pod访问这个Pod的Pod IP:8080 → 拒绝 正确配置 server.listen(0.0.0.0, 8080) ← 接受所有网卡 → 其他Pod才能通过Pod IP访问三、Layer 2Service和Endpoints3.1 Endpoint为空 Service白搭这是Service不通的最高频原因Service背后没有Endpoint没有健康的Pod。# 1. 看Service的Endpoint有没有kubectl get endpoints my-service# NAME ENDPOINTS AGE# my-service 10.244.1.5:8080,10.244.1.6 ← 有正常# 如果 ENDPOINTS 是 none → Service没匹配到Pod# 2. 为什么没匹配到看Selector对不对kubectl describeservicemy-service# Selector: appbackendkubectl get pods-lappbackend# 如果Pod的Label不是appbackend → 永远匹配不上# 3. 看EndpointSlice (新版本)kubectl get endpointslices-lkubernetes.io/service-namemy-service【Service不通的排查链】 kubectl get svc → ClusterIP 有了 │ 有 ▼ kubectl get endpoints → 有后端Pod IP │ 没有 ▼ 检查 Service.selector 和 Pod.labels 是否一致 │ 一致但还没有 ▼ 检查 Pod 是否 Ready (readinessProbe通过) │ Pod 不 Ready → kube-controller-manager不会把它加入Endpoints ▼ 检查 kube-proxy 是否正常运行 模式正确要点Service不通八成是Endpoint为空。而Endpoint为空八成是Selector和Pod Label对不上或者Pod的readinessProbe没过不Ready的Pod不会被加入Endpoint。先kubectl get endpoints一发真相往往就出来了。四、Layer 3Node和CNI4.1 CNI插件是否健康# 1. 看CNI插件Pod状态kubectl get pods-nkube-system-owide|grep-Ecalico|flannel|cilium# 不是Running看日志# 2. 看节点上的CNI配置和二进制ls/etc/cni/net.d/# 配置文件ls/opt/cni/bin/# 二进制# 3. 看节点路由表 (跨Node通信靠它)iproute show|greppod-cidr# 没有对端Pod网段的路由 → CNI插件没写路由# 4. 看vxlan/bgp接口iplinkshow|grep-Evxlan|flannel|cali|cilium4.2 用tcpdump抓包定位# 在Node上抓Pod的包 (进Pod的网络命名空间抓)# 方法1: 用nsenter进Pod的netnsPID$(dockerinspect-f{{.State.Pid}}container-id)nsenter-t$PID-ntcpdump-ieth0-nnport8080# 方法2: 直接在主机的veth上抓iplinkshow|grepveth tcpdump-ivethxxxx-nnhost10.244.1.5# 看包到没到对端Nodetcpdump-iany-nnhost10.244.2.5# 在对端Node抓# 如果发出去了但没回来 → 对端CNI/防火墙问题# 如果根本没发出去 → 本端路由/iptables问题五、Layer 4DNS与跨Node5.1 DNS解析失败# 1. 直接在Pod里解析kubectlexec-itmy-pod --nslookupkubernetes.default# 失败检查CoreDNSkubectl get pods-nkube-system-lk8s-appkube-dns kubectl logs-nkube-system-lk8s-appkube-dns|grep-ierror# 2. 看Pod的resolv.confkubectlexec-itmy-pod --cat/etc/resolv.conf# nameserver 必须是CoreDNS的ClusterIP# 3. 经典坑: ndots:5 导致外部域名慢# 解决: 调整dnsConfig或ndots值5.2 跨Node不通【跨Node不通的排查清单】 1. 安全组/防火墙挡了 → 同Node能通、跨Node不通多半是云厂商安全组没放行 → 放行: VXLAN(8472/UDP) / BGP(179/TCP) / 节点IP段 2. CNI封装模式对吗 → Flannel默认vxlan确认8472端口通 → Calico BGP模式确认节点间IP层可达 3. 路由表有没有对端网段 → ip route show | grep 对端Pod CIDR六、排查工具箱速查【K8s网络排查瑞士军刀】 kubectl exec -it pod -- cmd 进Pod执行命令 kubectl get endpoints svc 看Service后端 kubectl describe svc svc 看Service详情/事件 kubectl get pods -n kube-system 看网络插件状态 ip route show 看Node路由表 ip link show 看网络接口 tcpdump -i if -nn 过滤 抓包(最硬核) nsenter -t pid -n cmd 进Pod netns curl -s ip:port 测连通性要点网络排查没有捷径但有顺序。抓住黄金路径——先Pod、再Service、再Node、最后外部——每一步用对工具你就能从一脸懵变成一眼定位。tcpdump虽然硬核但当你怀疑包被丢了、被改了它就是最后的真相之眼。本篇小结网络不通不可怕可怕的是没章法地乱试。记住黄金路径Pod自身进程监听了0.0.0.0吗→ ServiceEndpoint有后端吗Selector对吗→ Node/CNI插件活着吗路由写了吗→ 外部/DNS安全组放了吗CoreDNS活吗。九成问题集中在前两层——Endpoint为空和DNS故障。tcpdumpnsenter是你的终极武器但当它们出场时说明问题已经比较深了。网络模块到此通关下一篇我们进入安全体系——K8s的三道防线。上一篇【第50篇】多集群网络互联——Submariner和Cilium Cluster Mesh下一篇【第52篇】K8s安全体系全景——Authentication/Authorization/Admission三道防线 【Kubernetes从入门到精通】第51篇：K8s网络故障排查指南——Pod不通了别慌，按这条“黄金路径“走
上一篇【第50篇】多集群网络互联——Submariner和Cilium Cluster Mesh下一篇【第52篇】K8s安全体系全景——Authentication/Authorization/Admission三道防线摘要前面五篇把K8s网络从模型到插件、从DNS到策略都讲透了。但理论和实战之间隔着一道墙真出问题的时候你对着一个超时的错误根本不知道从哪下手。网络问题最磨人的地方在于——它横跨多个层级。一个HTTP请求从Pod出去要过Pod网络、Service转发、kube-proxy、CNI插件、Node路由、物理网络……任何一层出问题表现都是连不上但根因天差地别。这篇文章给你一条**“黄金排查路径”**Pod→Service→Node→外部。按顺序一层层剥配合ip/nsenter/tcpdump/kubectl exec这几把利器90%的网络问题都能在一顿饭功夫内定位。一、黄金排查路径1.1 总览【网络排查黄金路径——从内到外逐层剥洋葱】 请求: Pod A → (Pod网络) → Service → (Node网络) → 外部/对端Pod │ │ │ ▼ ▼ ▼ Layer1: Pod本机能通吗 (localhost / 自身IP) Layer2: Service能通吗 (ClusterIP / Endpoints) Layer3: Node层面OK吗 (CNI / 路由 / 防火墙) Layer4: 外部/跨Node能通吗(物理网络 / 安全组) 口诀先确认自己没问题再确认中间人没问题 最后确认外面没问题。要点排查网络最忌讳东戳一下西戳一下。记住这个顺序——先Pod内部再Service再Node最后外部。每次只验证一层确认这层OK了再往下一层走。这样你永远不会在Pod本身都起不来的时候去调CNI。二、Layer 1Pod自身网络2.1 Pod能上网吗进程真在监听吗# 1. 进Pod看看进程在不在监听kubectlexec-itmy-pod --netstat-tlnp2/dev/null||\kubectlexec-itmy-pod -- ss-tlnp# 如果看不到 0.0.0.0:8080 在 LISTEN → 应用没起来或监听了127.0.0.1# 2. 在Pod里自己curl自己kubectlexec-itmy-pod --curl-slocalhost:8080/health# 自己都curl不通 → 应用层问题不是网络问题先去看应用日志# 3. 看Pod IP 和 路由kubectlexec-itmy-pod --ipaddr show kubectlexec-itmy-pod --iproute show2.2 常见坑应用只监听127.0.0.1【经典坑应用监听 localhost集群里谁都连不上】 错误配置 server.listen(127.0.0.1, 8080) ← 只接受本机回环 → 其他Pod访问这个Pod的Pod IP:8080 → 拒绝 正确配置 server.listen(0.0.0.0, 8080) ← 接受所有网卡 → 其他Pod才能通过Pod IP访问三、Layer 2Service和Endpoints3.1 Endpoint为空 Service白搭这是Service不通的最高频原因Service背后没有Endpoint没有健康的Pod。# 1. 看Service的Endpoint有没有kubectl get endpoints my-service# NAME ENDPOINTS AGE# my-service 10.244.1.5:8080,10.244.1.6 ← 有正常# 如果 ENDPOINTS 是 none → Service没匹配到Pod# 2. 为什么没匹配到看Selector对不对kubectl describeservicemy-service# Selector: appbackendkubectl get pods-lappbackend# 如果Pod的Label不是appbackend → 永远匹配不上# 3. 看EndpointSlice (新版本)kubectl get endpointslices-lkubernetes.io/service-namemy-service【Service不通的排查链】 kubectl get svc → ClusterIP 有了 │ 有 ▼ kubectl get endpoints → 有后端Pod IP │ 没有 ▼ 检查 Service.selector 和 Pod.labels 是否一致 │ 一致但还没有 ▼ 检查 Pod 是否 Ready (readinessProbe通过) │ Pod 不 Ready → kube-controller-manager不会把它加入Endpoints ▼ 检查 kube-proxy 是否正常运行 模式正确要点Service不通八成是Endpoint为空。而Endpoint为空八成是Selector和Pod Label对不上或者Pod的readinessProbe没过不Ready的Pod不会被加入Endpoint。先kubectl get endpoints一发真相往往就出来了。四、Layer 3Node和CNI4.1 CNI插件是否健康# 1. 看CNI插件Pod状态kubectl get pods-nkube-system-owide|grep-Ecalico|flannel|cilium# 不是Running看日志# 2. 看节点上的CNI配置和二进制ls/etc/cni/net.d/# 配置文件ls/opt/cni/bin/# 二进制# 3. 看节点路由表 (跨Node通信靠它)iproute show|greppod-cidr# 没有对端Pod网段的路由 → CNI插件没写路由# 4. 看vxlan/bgp接口iplinkshow|grep-Evxlan|flannel|cali|cilium4.2 用tcpdump抓包定位# 在Node上抓Pod的包 (进Pod的网络命名空间抓)# 方法1: 用nsenter进Pod的netnsPID$(dockerinspect-f{{.State.Pid}}container-id)nsenter-t$PID-ntcpdump-ieth0-nnport8080# 方法2: 直接在主机的veth上抓iplinkshow|grepveth tcpdump-ivethxxxx-nnhost10.244.1.5# 看包到没到对端Nodetcpdump-iany-nnhost10.244.2.5# 在对端Node抓# 如果发出去了但没回来 → 对端CNI/防火墙问题# 如果根本没发出去 → 本端路由/iptables问题五、Layer 4DNS与跨Node5.1 DNS解析失败# 1. 直接在Pod里解析kubectlexec-itmy-pod --nslookupkubernetes.default# 失败检查CoreDNSkubectl get pods-nkube-system-lk8s-appkube-dns kubectl logs-nkube-system-lk8s-appkube-dns|grep-ierror# 2. 看Pod的resolv.confkubectlexec-itmy-pod --cat/etc/resolv.conf# nameserver 必须是CoreDNS的ClusterIP# 3. 经典坑: ndots:5 导致外部域名慢# 解决: 调整dnsConfig或ndots值5.2 跨Node不通【跨Node不通的排查清单】 1. 安全组/防火墙挡了 → 同Node能通、跨Node不通多半是云厂商安全组没放行 → 放行: VXLAN(8472/UDP) / BGP(179/TCP) / 节点IP段 2. CNI封装模式对吗 → Flannel默认vxlan确认8472端口通 → Calico BGP模式确认节点间IP层可达 3. 路由表有没有对端网段 → ip route show | grep 对端Pod CIDR六、排查工具箱速查【K8s网络排查瑞士军刀】 kubectl exec -it pod -- cmd 进Pod执行命令 kubectl get endpoints svc 看Service后端 kubectl describe svc svc 看Service详情/事件 kubectl get pods -n kube-system 看网络插件状态 ip route show 看Node路由表 ip link show 看网络接口 tcpdump -i if -nn 过滤 抓包(最硬核) nsenter -t pid -n cmd 进Pod netns curl -s ip:port 测连通性要点网络排查没有捷径但有顺序。抓住黄金路径——先Pod、再Service、再Node、最后外部——每一步用对工具你就能从一脸懵变成一眼定位。tcpdump虽然硬核但当你怀疑包被丢了、被改了它就是最后的真相之眼。本篇小结网络不通不可怕可怕的是没章法地乱试。记住黄金路径Pod自身进程监听了0.0.0.0吗→ ServiceEndpoint有后端吗Selector对吗→ Node/CNI插件活着吗路由写了吗→ 外部/DNS安全组放了吗CoreDNS活吗。九成问题集中在前两层——Endpoint为空和DNS故障。tcpdumpnsenter是你的终极武器但当它们出场时说明问题已经比较深了。网络模块到此通关下一篇我们进入安全体系——K8s的三道防线。上一篇【第50篇】多集群网络互联——Submariner和Cilium Cluster Mesh下一篇【第52篇】K8s安全体系全景——Authentication/Authorization/Admission三道防线