容器网络模型与服务发现：从踩坑到精通，Kubernetes 网络问题排查全指南

写在前面 ：Kubernetes 网络是云原生领域最让新手"怀疑人生"的模块之一。本文从一个真实的生产故障出发，系统梳理 CNI 插件差异、Service 类型选择、DNS 解析机制，并给出可落地的 Pod 通信排查方法论。如果你也曾被 connection refused、no route to host、DNS lookup failed 折磨过，这篇文章就是为你写的。

文章目录

[容器网络模型与服务发现：从踩坑到精通，Kubernetes 网络问题排查全指南](#容器网络模型与服务发现：从踩坑到精通，Kubernetes 网络问题排查全指南)
- [一、摘要：一次凌晨 2 点的生产故障](#一、摘要：一次凌晨 2 点的生产故障)
- 二、开发环境
- [三、Kubernetes 网络模型基础](#三、Kubernetes 网络模型基础)
- - [3.1 CNI 概述：为什么需要它](#3.1 CNI 概述：为什么需要它)
  - [3.2 Pod 网络通信的三种场景](#3.2 Pod 网络通信的三种场景)
- [四、主流 CNI 插件深度对比](#四、主流 CNI 插件深度对比)
- - [4.1 Flannel：简单即正义](#4.1 Flannel：简单即正义)
  - [4.2 Calico：企业级网络的首选](#4.2 Calico：企业级网络的首选)
  - [4.3 Weave：被遗忘的"全连接"方案](#4.3 Weave：被遗忘的"全连接"方案)
  - [4.4 三插件横向对比](#4.4 三插件横向对比)
- [五、Kubernetes Service 类型详解](#五、Kubernetes Service 类型详解)
- - [5.1 ClusterIP：集群内部的"虚拟 IP"](#5.1 ClusterIP：集群内部的"虚拟 IP")
  - [5.2 NodePort：每个节点上的"端口映射"](#5.2 NodePort：每个节点上的"端口映射")
  - [5.3 LoadBalancer：云原生的"一键暴露"](#5.3 LoadBalancer：云原生的"一键暴露")
  - [5.4 三种 Service 类型对比](#5.4 三种 Service 类型对比)
- [六、CoreDNS 与服务发现机制](#六、CoreDNS 与服务发现机制)
- - [6.1 DNS 解析流程：一次服务调用背后的五次查询](#6.1 DNS 解析流程：一次服务调用背后的五次查询)
  - [6.2 CoreDNS 配置与常见故障](#6.2 CoreDNS 配置与常见故障)
- [七、Pod 通信故障排查实战](#七、Pod 通信故障排查实战)
- - [7.1 排查工具链：你的"网络听诊器"](#7.1 排查工具链：你的"网络听诊器")
  - [7.2 排查决策树](#7.2 排查决策树)
  - [7.3 实战案例：跨节点 Pod 通信超时](#7.3 实战案例：跨节点 Pod 通信超时)
  - [7.4 实战案例：Service 访问间歇性 502](#7.4 实战案例：Service 访问间歇性 502)
- 八、总结与最佳实践
- - [8.1 CNI 选型决策](#8.1 CNI 选型决策)
  - [8.2 Service 设计原则](#8.2 Service 设计原则)
  - [8.3 DNS 优化 checklist](#8.3 DNS 优化 checklist)
  - [8.4 排查口诀](#8.4 排查口诀)

一、摘要：一次凌晨 2 点的生产故障

事情发生在某次微服务上线后的凌晨。监控告警突然炸锅：订单服务无法调用库存服务的 gRPC 接口，错误日志清一色是 Connection refused 和 i/o timeout。

排查链路如下：

✅ Pod 状态正常，kubectl get pods 显示 Running
✅ Service 存在，kubectl get svc 显示 ClusterIP 已分配
❌ 但 curl 测试发现，从订单 Pod 访问 inventory-service:8080 时，DNS 解析成功，TCP 连接却直接超时
❌ 跨节点 Pod 之间 ping 不通，同节点 Pod 通信正常

最终定位：Flannel 的 VXLAN 后端在跨节点通信时，因为底层云厂商的安全组规则限制了 UDP 8472 端口，导致 Overlay 网络封装后的数据包被丢弃。而这个问题在单节点测试环境完全无法复现。

这次故障让我深刻意识到：Kubernetes 网络不是"配置完就忘"的组件，理解 CNI 差异、Service 类型、DNS 机制，是每一位云原生开发者的必修课。

二、开发环境

组件	版本	说明
Kubernetes	v1.28.4	生产集群版本
Container Runtime	containerd v1.7.2	替代 Docker
CNI 插件	Flannel v0.22.0 → Calico v3.26.1	故障后迁移
DNS	CoreDNS v1.10.1	集群默认 DNS
云厂商	阿里云 ACK	VPC 网络环境
操作系统	Ubuntu 22.04 LTS	节点系统

三、Kubernetes 网络模型基础

3.1 CNI 概述：为什么需要它

Kubernetes 本身并不直接管理容器网络，而是通过 CNI（Container Network Interface） 规范，将网络配置委托给第三方插件。CNI 的核心职责只有三件事：

为每个 Pod 分配独立的 IP 地址（Pod IP 是集群内通信的基础）
确保 Pod 之间可以直接通信（无需 NAT）
实现网络策略（NetworkPolicy）（可选，取决于插件能力）

关键认知 ：Kubernetes 对网络的要求非常严格------所有 Pod 必须在任意节点上都能直接通信，且通信时源 IP 不能被修改。这个约束直接决定了 CNI 插件的设计方向。

3.2 Pod 网络通信的三种场景

同节点通信
跨节点通信
Pod → Service → Pod
Pod A

Node 1
Pod B

Node 1
Pod C

Node 2
Service

ClusterIP
Pod D

任意节点

通信场景	技术实现	常见问题
同节点 Pod 通信	Linux veth pair + 网桥（cni0）	网桥配置错误、iptables 规则冲突
跨节点 Pod 通信	Overlay（VXLAN/IPIP）或 Underlay（BGP）	底层网络限制、MTU 不匹配、路由缺失
Pod → Service → Pod	kube-proxy + iptables/IPVS + DNS	DNS 解析失败、Endpoint 未更新、SNAT 异常

四、主流 CNI 插件深度对比

4.1 Flannel：简单即正义

Flannel 是 Kubernetes 社区最轻量的 CNI 插件，专为 "快速跑起来" 设计。

核心机制：

每个节点分配一个子网（/24），由 flanneld 守护进程维护
跨节点通信通过 VXLAN 或 host-gw 实现
数据包封装后通过 UDP 8472（VXLAN）或直连路由（host-gw）发送

优点：部署简单、资源占用低、社区成熟
缺点：不支持 NetworkPolicy、Overlay 性能损耗约 10%~20%、大规模集群路由表膨胀

踩坑实录 ：Flannel 的 VXLAN 模式在阿里云、AWS 等云厂商环境中，必须确保节点安全组放行 UDP 8472 端口。很多新手在自建集群时只放行了 TCP 端口，导致跨节点 Pod 通信直接挂掉，而单节点测试完全正常------这正是本文开头故障的根因。

4.2 Calico：企业级网络的首选

Calico 是目前生产环境使用最广泛的 CNI 插件，以 BGP 路由 和 NetworkPolicy 著称。

核心机制：

默认使用 BGP（Border Gateway Protocol） 在节点间分发路由，数据包无需封装，直接通过底层网络传输
也支持 VXLAN/IPIP 模式（用于不支持 BGP 的环境）
通过 felix 组件实现 iptables/eBPF 规则管理，支持细粒度网络策略

优点：性能接近原生网络、支持 NetworkPolicy、可扩展性强、支持 eBPF 数据面
缺点：配置复杂、需要底层网络支持 BGP（或改用 IPIP/VXLAN）、学习曲线陡峭

最佳实践 ：在阿里云 VPC 环境中，推荐 Calico 的 VXLAN CrossSubnet 模式------同子网内使用 BGP 直连，跨子网自动降级为 VXLAN，兼顾性能与兼容性。

4.3 Weave：被遗忘的"全连接"方案

Weave 曾以 "零配置组网" 闻名，但近年来社区活跃度明显下降。

核心机制：

每个节点运行 Weave 路由器，建立全连接的网状拓扑
默认使用 VXLAN 封装，支持加密（NaCl）
自动发现拓扑，无需依赖 etcd 存储 IP 分配信息

优点：部署简单、支持加密通信、自动故障恢复
缺点：性能较差（全连接拓扑开销大）、社区维护放缓、大规模集群表现不佳

4.4 三插件横向对比

维度	Flannel	Calico	Weave
网络模式	VXLAN / host-gw	BGP / VXLAN / IPIP / eBPF	VXLAN（全连接）
NetworkPolicy	❌ 不支持	✅ 原生支持	⚠️ 部分支持
性能	⭐⭐⭐ 中等	⭐⭐⭐⭐⭐ 接近原生	⭐⭐ 较低
部署复杂度	⭐ 极低	⭐⭐⭐⭐ 较高	⭐⭐ 较低
加密支持	❌ 无	⚠️ WireGuard（可选）	✅ 原生支持
大规模集群	⚠️ 路由表膨胀	✅ 优秀	❌ 不推荐
云厂商兼容性	⚠️ 需放行 UDP 8472	✅ 优秀（推荐 VXLAN 模式）	⚠️ 一般
社区活跃度	⭐⭐⭐ 维护中	⭐⭐⭐⭐⭐ 非常活跃	⭐⭐ 逐渐冷清
适用场景	测试环境、小型集群	生产环境、中大规模集群	边缘计算、加密需求场景

选型建议：新手测试用 Flannel，生产环境无脑选 Calico。Weave 除非有特殊加密需求，否则不建议在新集群中使用。

五、Kubernetes Service 类型详解

Service 是 Kubernetes 实现服务发现的核心抽象。但很多新手对三种类型的区别一知半解，导致暴露方式错误或访问异常。

5.1 ClusterIP：集群内部的"虚拟 IP"

定义：为 Service 分配一个仅集群内部可达的虚拟 IP，是 默认类型。

工作原理：

kube-proxy 在每个节点上维护 iptables/IPVS 规则，将 ClusterIP:Port 的流量 DNAT 到后端 Pod IP
DNS 记录由 CoreDNS 维护，格式为 <service-name>.<<namespace>.svc.cluster.local

适用场景：微服务内部调用、数据库连接、缓存访问等不需要外部暴露的服务。
Endpoint Pod Service ClusterIP iptables/IPVS CoreDNS 客户端 Pod Endpoint Pod Service ClusterIP iptables/IPVS CoreDNS 客户端 Pod 查询 inventory-service.default.svc.cluster.local 返回 10.96.123.45 发送请求到 10.96.123.45:8080 DNAT 转发到 Pod IP: 10.244.1.23:8080 返回响应

新手大坑 ：ClusterIP 仅在集群内部可达。如果你在节点上直接用 curl <ClusterIP> 测试，大概率会失败------因为节点本身不属于 Pod 网络命名空间。正确的测试方式是 kubectl run 一个临时 Pod，或者使用 kubectl port-forward。

5.2 NodePort：每个节点上的"端口映射"

定义：在集群每个节点的 IP 上开放一个固定端口（30000-32767），将外部流量转发到 Service。

工作原理：

kube-proxy 在节点上监听 <NodeIP>:<<NodePort>
流量进入后，先 DNAT 到 ClusterIP，再负载均衡到后端 Pod
支持 externalTrafficPolicy: Local（保留客户端源 IP，但可能导致流量不均衡）或 Cluster（默认，节点间二次转发，源 IP 被 SNAT）

适用场景：开发测试、小型集群、没有云负载均衡器的裸金属环境。

配置项	`Cluster`（默认）	`Local`
源 IP 保留	❌ 被 SNAT 替换	✅ 保留真实客户端 IP
负载均衡	✅ 均匀分布	⚠️ 仅转发到本节点 Pod
健康检查	不需要	需要配合 `healthCheckNodePort`
适用场景	通用场景	需要获取客户端 IP 的日志/审计场景

踩坑实录 ：NodePort 的默认端口范围是 30000-32767，很多防火墙策略会限制这个范围。如果需要自定义（比如用 80/443），必须修改 kube-apiserver 的 --service-node-port-range 参数，但这可能引发端口冲突。

5.3 LoadBalancer：云原生的"一键暴露"

定义：在云厂商环境中，自动创建一个外部负载均衡器（如阿里云 SLB、AWS ELB），并将流量转发到 NodePort 或直连 Pod。

工作原理：

Kubernetes 通过 Cloud Controller Manager 调用云厂商 API 创建 LB
LB 后端挂载到各节点的 NodePort，或直接挂载 Pod IP（部分云厂商支持）
分配一个外部可访问的 IP（EXTERNAL-IP）

适用场景：生产环境对外暴露服务、需要高可用入口、需要 TLS 终止或健康检查。

成本警告 ：LoadBalancer 类型的 Service 在云厂商环境中按量计费。测试环境滥用 LoadBalancer 可能导致账单爆炸。建议开发环境用 Ingress + ClusterIP 替代。

5.4 三种 Service 类型对比

特性	ClusterIP	NodePort	LoadBalancer
暴露范围	集群内部	节点 IP + 端口	外部公网 IP
IP 来源	虚拟 IP（10.96.x.x）	节点真实 IP	云厂商分配
端口范围	任意	30000-32767（默认）	任意（由 LB 决定）
源 IP 保留	✅ 始终保留	⚠️ 取决于策略	⚠️ 取决于云厂商实现
性能开销	低（iptables/IPVS）	中（二次转发）	高（云 LB 跳转）
高可用	依赖 kube-proxy	依赖节点可用性	✅ LB 多可用区
成本	免费	免费	💰 按量计费
典型用途	内部微服务	裸金属/测试暴露	生产入口

六、CoreDNS 与服务发现机制

6.1 DNS 解析流程：一次服务调用背后的五次查询

当你在一个 Pod 中访问 inventory-service 时，DNS 解析远比想象中复杂：
否
是
应用代码: http://inventory-service:8080
Pod /etc/resolv.conf

nameserver 10.96.0.10

search default.svc.cluster.local svc.cluster.local cluster.local
是否 FQDN?
拼接 search 域名:

inventory-service.default.svc.cluster.local
直接查询
CoreDNS Pod
查询 Kubernetes API

获取 Service 记录
返回 ClusterIP: 10.96.123.45
应用发起 TCP 连接
kube-proxy iptables

DNAT 到 Endpoint Pod
后端 Pod 响应

6.2 CoreDNS 配置与常见故障

CoreDNS 的配置存储在 Corefile ConfigMap 中，默认包含以下关键插件：

插件	作用	故障表现
`kubernetes`	监听 K8s API，动态生成 DNS 记录	Pod 启动后 DNS 迟迟不生效
`forward`	将非集群域名转发到上游 DNS	外部域名解析失败
`cache`	缓存 DNS 响应	DNS 记录更新后客户端仍拿到旧 IP
`loop`	检测 DNS 查询死循环	CoreDNS Pod 频繁重启
`hosts`	自定义静态 hosts	自定义域名不生效

新手大坑 #1：DNS 解析慢 / 超时

默认的 ndots:5 配置会导致短域名（如 inventory-service）依次尝试 4 个 search 域拼接，产生大量无效查询。优化方案：

应用代码中使用 FQDN（如 inventory-service.default.svc.cluster.local.）

或修改 Pod DNSConfig 降低 ndots 值
新手大坑 #2：Service 删除了，DNS 还能解析

CoreDNS 默认缓存 TTL 为 30 秒。如果你删除了 Service 但 Pod 仍缓存了旧记录，会出现 DNS 解析成功但连接失败的诡异现象。此时需要等待缓存过期，或重启 CoreDNS Pod。
新手大坑 #3：Headless Service 的 DNS 返回 Pod IP 而非 ClusterIP

当 clusterIP: None 时，DNS 直接返回后端 Pod IP 列表（A 记录），而非虚拟 ClusterIP。这对 StatefulSet（如 Redis、Kafka）非常重要，但对期望通过固定 IP 连接的服务会造成混乱。

七、Pod 通信故障排查实战

7.1 排查工具链：你的"网络听诊器"

工具	用途	使用场景
`kubectl get pods -o wide`	查看 Pod IP、所在节点	快速定位 Pod 分布
`kubectl get svc, endpoints`	检查 Service 和 Endpoint 绑定	确认 Service 是否正确关联 Pod
`kubectl run debug --rm -it --image=nicolaka/netshoot -- /bin/bash`	启动网络调试容器	在目标命名空间执行 `ping`、`curl`、`nslookup`、`tcpdump`
`nslookup / dig`	DNS 解析测试	验证 CoreDNS 是否正常工作
`ping / traceroute`	网络连通性测试	判断是路由问题还是防火墙问题
`telnet / nc -vz`	端口连通性测试	确认服务端口是否监听
`iptables -t nat -L -n -v`	查看 kube-proxy 规则	排查 DNAT/SNAT 异常
`tcpdump -i any -n host <pod-ip>`	抓包分析	终极手段，看数据包是否到达

7.2 排查决策树

否
是
否
是
是
同节点
跨节点
Pod A 无法访问 Pod B
DNS 能解析吗?
检查 CoreDNS

检查 Service 是否存在

检查 resolv.conf
TCP 连接能建立吗?
同节点还是跨节点?
HTTP 返回错误?
检查应用日志

检查 Service TargetPort
检查网桥 cni0

检查 veth pair

检查 iptables
检查 CNI 后端:

VXLAN UDP 8472?

BGP 路由?

云厂商安全组?

7.3 实战案例：跨节点 Pod 通信超时

现象：订单服务（Node A）调用库存服务（Node B），curl 超时，但库存服务在 Node B 本地访问正常。

排查过程：

kubectl get endpoints inventory-service → Endpoint 正常，IP 正确

在订单 Pod 中 nslookup inventory-service → DNS 返回 ClusterIP 正常

ping <库存 Pod IP> → 跨节点 ping 不通，同节点 ping 正常

节点上 ip route → 发现没有到目标子网的路由

systemctl status flanneld → 状态正常，但 cat /run/flannel/subnet.env 发现子网与节点实际网段不一致

根因：节点曾手动修改过 IP，Flannel 的 lease 未刷新，导致路由指向错误子网

修复：删除 Flannel lease（etcd 或 Kubernetes 中 kube-flannel lease），重启 flanneld Pod，路由恢复

7.4 实战案例：Service 访问间歇性 502

现象：通过 Ingress 访问服务，偶发 502 Bad Gateway。

排查过程：

Ingress 日志显示后端连接超时

kubectl get endpoints → 发现 Endpoint 列表中有一个 Pod IP 已不存在（Pod 已删除但 Endpoint 未更新）

kubectl describe svc → Endpoints 字段确实包含已终止的 Pod IP

根因：Pod 终止时未正确处理优雅关闭，kubelet 未及时上报 Endpoint 变更，导致 Service 仍向已销毁 Pod 转发流量

修复：为 Pod 添加 preStop 钩子 + 合理 terminationGracePeriodSeconds，确保应用收到 SIGTERM 后主动从 Endpoint 摘除

八、总结与最佳实践

8.1 CNI 选型决策

场景	推荐方案	理由
本地测试 / Minikube	Flannel	一键部署，零配置
云厂商 VPC（阿里云/AWS/GCP）	Calico VXLAN CrossSubnet	兼容性强，性能优秀，支持 NetworkPolicy
裸金属 / 私有云	Calico BGP	无 Overlay 开销，接近原生性能
强加密需求	Calico + WireGuard / Cilium	透明加密，不影响应用层
超大规模集群（5000+ 节点）	Cilium eBPF	替代 kube-proxy，O(1) 复杂度

8.2 Service 设计原则

内部服务一律用 ClusterIP，通过 Ingress 统一暴露入口，避免滥用 NodePort 和 LoadBalancer
需要源 IP 的场景 （如审计、WAF、速率限制），务必设置 externalTrafficPolicy: Local，并配合 podAntiAffinity 确保每个节点都有后端 Pod
Headless Service 仅用于 StatefulSet，无状态服务不要滥用，否则失去负载均衡能力

8.3 DNS 优化 checklist

应用代码中使用 FQDN 或合理配置 ndots
CoreDNS 副本数 ≥ 2，避免单点故障
监控 CoreDNS 的 forward 延迟和 kubernetes API 查询延迟
大规模集群考虑 NodeLocal DNSCache，降低 CoreDNS 负载

8.4 排查口诀

"一查 DNS，二查 Endpoint，三查路由，四抓包"

DNS 不通 → 看 CoreDNS 和 resolv.conf

DNS 通但 TCP 不通 → 看路由和防火墙

TCP 通但 HTTP 错 → 看应用和 Service TargetPort

一切正常但偶发故障 → 抓包，看 MTU、SNAT、连接耗尽

最后的话 ：Kubernetes 网络没有银弹。Flannel 的简单、Calico 的强大、Weave 的便捷，都是在特定约束下的 trade-off。理解这些差异，不是为了记住参数，而是为了在故障发生时，能够快速定位"这是哪一层的问题"。希望这篇文章能让你下一次面对 connection refused 时，少熬一个凌晨。

参考文档：