咱们今天不聊那些枯燥的教科书定义，直接钻进Kubernetes（以下简称K8s）那个看似神秘实则逻辑严密的网络内核里去看看。很多刚接触K8s的朋友，甚至是一些有经验的运维同学，在面对“为什么我的Pod连不上另一个Pod”、“为什么Service死活解析不通”或者“跨机房延迟怎么优化”这些问题时，往往会感到头大。其实，只要把底层的CNI（Container Network Interface）插件机制、Overlay网络的工作原理以及CoreDNS的运行逻辑拆解开来，你会发现这一切都有迹可循。
我们要解决的不仅仅是配置问题，更是理解数据流在集群中是如何跳跃的。想象一下，你的应用就像是在一个巨大的城市里穿梭的快递员，而K8s的网络就是这座城市的道路系统、交通信号灯和导航仪。如果道路设计不合理，或者导航出了问题，快递（数据包）就会迷路或迟到。
深入底层：K8s网络模型的三大支柱
在讨论具体的故障排查之前，我们必须先建立正确的认知框架。K8s的网络模型并不是单一的技术，而是由三个核心部分共同支撑起来的：Pod网络、Service网络和DNS服务。这三者环环相扣，任何一个环节出错，都会导致整个集群的通信瘫痪。
Pod网络：扁平化的虚拟局域网
K8s最核心的承诺之一是：每个Pod都拥有一个独立的IP地址，且所有Pod可以在不使用NAT的情况下直接相互通信。
为了实现这个目标，K8s引入了CNI插件。常见的CNI插件如Calico、Flannel、Weave Net等，它们各自有不同的实现方式，但目标一致：在物理节点之间建立一个覆盖网络（Overlay Network）。
以Flannel为例，它通常使用VXLAN技术。当Pod A（位于Node 1）想要发送数据包给Pod B（位于Node 2）时，数据包不会直接通过物理网卡发出，而是先被交给Node 1上的veth pair（虚拟以太网设备），进入Linux网桥。然后，Flannel的守护进程（flanneld）会查找路由表，发现目标Pod在Node 2上，于是将原始数据包封装在一个新的UDP包中，源IP是Node 1的物理IP，目的IP是Node 2的物理IP。这个封装后的包通过物理网络传输到Node 2，Node 2收到后解封装，提取出原始的Pod间数据包，最后投递给Pod B。
这个过程对应用程序是完全透明的。你不需要关心底层是VXLAN还是Geneve，也不需要关心物理网络的路由策略，只要IP通了，业务就能跑。
Service网络：负载均衡与抽象层
Pod的IP是易变的，Pod重启或调度到其他节点，IP就会改变。如果我们的应用直接依赖Pod IP，那维护成本将是灾难性的。因此，K8s引入了Service资源。
Service提供了一个稳定的虚拟IP（ClusterIP）和一个可选的域名。当客户端访问Service的ClusterIP时，流量会被kube-proxy组件接管。kube-proxy会在每个节点上维护一套iptables或IPVS规则，将发往ClusterIP的流量随机（或轮询）转发到后端某个健康的Pod IP上。
这里有一个关键点：Service的流量路径。
- 客户端 -> ClusterIP
- kube-proxy（iptables/IPVS）匹配规则
- 转发到后端Pod IP
- Pod接收并处理
如果这一步出现问题，比如kube-proxy僵死，或者iptables规则过于庞大导致性能瓶颈，Service就会失效。
DNS服务：内部服务的寻路地图
在K8s中，Service不仅仅通过IP访问，更推荐通过DNS名称访问，例如my-service.default.svc.cluster.local。这是通过CoreDNS（或旧版的kube-dns）实现的。
CoreDNS运行在集群内部，监听特定的端口。当Pod发起DNS查询时，请求会被重定向到CoreDNS Pod。CoreDNS根据配置文件（Corefile）中的规则，查询etcd或直接生成记录，返回Service对应的ClusterIP。
注意： DNS解析发生在应用层，而Pod和Service通信发生在网络层。很多时候，应用报错“连接超时”，其实是DNS解析失败导致的，而不是网络不通。
现实挑战：跨节点网络延迟的根源与CNI调优
虽然理论很完美，但在实际生产环境中，跨节点通信往往伴随着延迟抖动、丢包率高和吞吐量不足的问题。这通常不是K8s本身的错，而是CNI插件配置不当或底层物理网络不匹配造成的。
案例一：VXLAN封装带来的开销
如果你使用的是基于VXLAN的CNI（如Flannel默认模式或Calico的VXLAN模式），每个数据包都会增加至少50-60字节的头部开销（以太网+IP+UDP+VXLAN头）。对于小数据包密集型应用（如微服务间高频RPC调用），这种封装会导致严重的CPU消耗和延迟增加。
解决方案：启用BGP模式或直连路由
Calico是一个很好的例子。它支持两种主要模式：VXLAN和BGP。
- VXLAN模式：依赖控制平面学习MAC地址，所有流量经过Overlay隧道。
- BGP模式：Calico节点通过BGP协议交换路由信息，直接在物理网络上路由Pod IP。这意味着数据包不需要封装，直接通过物理网络传输，极大降低了延迟和CPU开销。
配置示例：
要切换到BGP模式，你需要修改Calico的DaemonSet配置。以下是一个典型的YAML片段，展示如何启用BGP：
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
name: default
spec:
calicoNetwork:
bgp: Enabled # 关键配置：启用BGP
ipPools:
- blockSize: 26
cidr: 10.244.0.0/16
encapsulation: VXLANCrossSubnet # 如果必须跨子网，保留VXLAN，否则设为None以完全走BGP
natOutgoing: Enabled
nodeSelector: all()
如果你的物理网络支持BGP（大多数企业级交换机都支持），强烈建议在生产环境使用BGP模式。这不仅解决了延迟问题，还简化了网络架构，因为不再需要维护复杂的隧道状态。
案例二：MTU不匹配导致的分片与丢包
另一个常见的问题是MTU（最大传输单元）设置不一致。VXLAN封装增加了头部大小，如果物理网络的MTU是标准的1500字节，而Pod内部的MTU也是1500字节，那么封装后的数据包大小将超过1500字节，导致需要分片或丢弃。
诊断步骤：
- 检查物理网卡的MTU：
ip link show eth0 - 检查CNI配置的MTU。例如，在Calico中，你可以在Installation CRD中指定mtu：
spec: calicoNetwork: mtu: 1440 # 通常为1500减去VXLAN头部(50-60)
最佳实践： 确保物理网络支持Jumbo Frames（巨型帧，如9000字节），并将CNI和节点的MTU统一设置为9000。这样可以避免分片，显著提升大流量传输的性能。如果无法更改物理网络，则必须在CNI配置中手动调整MTU，使其小于物理MTU减去封装开销。
深度剖析：DNS解析失败的排查指南
DNS解析失败是K8s中最令人头疼的问题之一，因为它往往表现为间歇性故障，且难以复现。CoreDNS虽然健壮，但它依赖于上游DNS、etcd存储以及集群内部的网络连通性。
场景分析：为什么Pod无法解析Service域名？
假设你在Pod A中执行nslookup my-service，返回NXDOMAIN或超时。
1. CoreDNS Pod本身的健康状况
首先，确认CoreDNS是否正常运行。
kubectl get pods -n kube-system | grep coredns
kubectl logs -n kube-system <coredns-pod-name>
如果CoreDNS Pod处于CrashLoopBackOff状态，查看日志是否有配置错误或内存溢出。
2. kubelet的配置问题
kubelet负责告诉Pod使用哪个DNS服务器。如果--cluster-dns参数未正确设置，或者--cluster-domain错误，Pod内的 resolv.conf 文件将指向错误的DNS。
检查方法：
进入Pod内部，查看 /etc/resolv.conf：
kubectl exec -it <pod-name> -- cat /etc/resolv.conf
你应该看到 nameserver 指向的是 10.96.0.10（默认ClusterIP）或其他你配置的CoreDNS IP。如果这里缺失或错误，修正kubelet启动参数：
# 在kubelet配置文件中
clusterDNS:
- 10.96.0.10
clusterDomain: cluster.local
3. 网络策略（NetworkPolicy）阻断
这是最容易被忽视的原因。即使CoreDNS运行正常，如果存在NetworkPolicy限制了DNS端口（UDP/TCP 53）的访问，Pod将无法解析。
排查示例： 检查是否有默认的Deny All策略：
kubectl get networkpolicy --all-namespaces
如果有策略阻止了到kube-system命名空间的DNS流量，你需要添加Allow规则：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-dns
namespace: default
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- ports:
- port: 53
protocol: UDP
- port: 53
protocol: TCP
from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
4. 上游DNS转发问题
CoreDNS通常会将非集群内部的查询转发给宿主机或外部DNS。如果宿主机无法访问互联网，或者防火墙阻断了出站DNS请求，CoreDNS将返回超时。
调试技巧：
在CoreDNS Pod中安装dig或nslookup工具，测试外部域名解析：
kubectl exec -it <coredns-pod-name> -n kube-system -- dig www.google.com
如果这一步失败，问题出在CoreDNS的配置（Corefile中的forward指令）或宿主机的网络出口。
Corefile配置示例：
.:53 {
errors
health
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
注意forward . /etc/resolv.conf这一行，它指示CoreDNS使用宿主机的DNS配置作为上游。确保宿主机能解析外网。
综合实战：构建一个高可用的网络架构
了解了原理和常见问题，我们来看看如何从零开始构建一个稳健的K8s网络环境。
第一步：选择正确的CNI插件
- 小型集群/开发环境：Flannel简单易懂，开箱即用，适合快速验证。
- 中型集群/需要细粒度控制：Calico提供强大的网络策略和BGP选项，性能优异。
- 大型分布式集群/多可用区：考虑Cilium，它基于eBPF技术，提供了极高的性能和可观测性，且原生支持L7网络策略。
第二步：标准化MTU和IPAM配置
无论选择哪种CNI，务必统一集群内的MTU设置。在初始化集群时，通过 kubeadm config 或云厂商的托管服务界面，明确指定Pod CIDR和Service CIDR，并确保它们不与物理网络冲突。
第三步：实施DNS健康监控
不要等到用户投诉才去检查DNS。部署Prometheus和Grafana，监控CoreDNS的指标：
coredns_dns_request_count_total: 请求总数coredns_dns_response_code_sum: 响应码分布（重点关注SERVFAIL和NXDOMAIN）coredns_cache_size: 缓存命中率
设置告警规则：当SERVFAIL比例超过1%时，立即通知运维团队。
第四步：编写网络策略文档
为每个命名空间编写清晰的NetworkPolicy文档，说明允许哪些入站和出站流量。避免使用“Deny All”而不加例外，除非你有明确的隔离需求。定期审计策略，移除过时的规则。
结语：从被动救火到主动防御
K8s的网络模型看似复杂，但其本质是为了解决容器动态性带来的通信难题。通过理解CNI插件的工作机制，我们可以优化跨节点通信的延迟；通过深入剖析DNS解析流程，我们可以快速定位并解决服务发现的故障。
记住，没有银弹。最好的网络架构是那些与你业务需求、物理基础设施和团队技能相匹配的架构。在实践中，多观察、多测试、多记录，你会发现，K8s的网络不再是黑盒，而是一个你可以精确控制的精密仪器。希望这篇解析能帮你拨开迷雾，建立起对K8s网络的深刻直觉。如果在实践中遇到具体的报错，欢迎随时回来查阅这些基础概念，它们往往是解决问题的钥匙。