【架构实战】Kubernetes网络模型深度剖析从Pod通信到Service流量转发当我们把应用搬上 Kubernetes最先被劝退的往往是网络。为什么 Pod 之间能直接互通Service 的 ClusterIP 到底是个啥kube-proxy 在背后干了什么Ingress 又是怎么把流量导进来的这一篇把 Kubernetes 的网络模型拆开揉碎从底层原理到生产实践一次讲透。一、K8s 网络的三大前提假设Kubernetes 网络模型建立在三个理所当然的假设之上理解它们就理解了一半Pod 拥有的 IP 全局可达任意节点上的任意 Pod都可以不经由 NAT 直接访问其他任意节点上的任意 Pod。节点上的代理如 kubelet可以访问同节点的 Pod哪怕跨网络平面也行。Pod 视角的自己 IP 别人看到的 IPPod 内部curl自己和集群里别人curl它IP 是一致的没有内部地址 / 外部地址的分裂。这三条合在一起就是著名的IP-per-Pod模型。每个 Pod 拿到一个真实可用的 IP应用不用关心自己在哪个节点像活在同一个大二层网络里。二、Pod 网络是怎么打通的CNI 与 overlayPod 之间能互通靠的是CNIContainer Network Interface。kubelet 创建 Pod 时会调用 CNI 插件给 Pod 的网卡分配 IP、配置路由、把 veth 插进节点的网桥。实现方式分两派Underlay路由方案如 CalicoBGP 模式、直接用底层网络路由 Pod CIDR。性能最好延迟接近物理网络但需要底层网络配合或 BGP 打通。Overlay隧道方案如 FlannelVXLAN、CalicoIPIP、CiliumVXLAN / Geneve。在节点间建隧道封装对底层无要求代价是封装/解封装的 CPU 开销和一点点延迟。选型建议节点都在同二层或能跑 BGP优先 Calico 路由模式云上跨 VPC 或无法改路由用 overlay。生产环境我更推荐Cilium——基于 eBPF既能做网络又能做可观测性和安全策略性能还吊打 iptables 方案。三、Service给一组 Pod 一个稳定入口Pod 是会漂移、会重建的IP 随时变。Service 干的事就是给一组动态 Pod 一个固定虚拟 IPClusterIP。流量路径是这样的客户端访问Service ClusterIP:Port内核根据 iptables/IPVS 规则把目标 IP 改写成某个后端 Pod 的真实 IPDNAT请求被转发到被选中的 Pod。kube-proxy 的三种模式userspace已淘汰慢每次转发走一遍用户态。iptables默认模式靠链式规则做 DNAT。规则一多万条时新增/更新 Service 会抖动且转发是纯随机/O 哈希。IPVS基于内核哈希表转发性能稳定支持轮询、最少连接等多种负载均衡算法大规模集群首选。实践上超过几百个 Service 就建议切 IPVSkube-proxy --proxy-modeipvs。四、DNS 与 Service 发现集群里服务之间很少记 IP都是记名字。CoreDNS把service.namespace.svc.cluster.local解析成 ClusterIP。注意两个坑DNS 解析有缓存Pod 内的 ndots 配置可能导致短域名如只写service被错误地追加搜索域造成多余的 DNS 查询甚至解析失败。微服务调用链长时DNS 抖动会放大成连锁超时。headless ServiceclusterIP: None不做负载均衡DNS 直接返回所有后端 Pod IP适合有状态服务如数据库集群自己做选主。五、Ingress把外部流量引进来Service 的 ClusterIP 只在集群内可达。要把流量从公网导进来靠Ingress。它本质是一个七层HTTP/HTTPS路由规则根据域名、路径把请求转发到对应的 Service。背后跑着一个Ingress Controller本质是监听 Ingress 对象的 Pod典型如 Nginx Ingress、Traefik、APISIX。它把规则翻译成自身的转发配置。对比一下Nginx Ingress生态成熟、稳但配置 reload 有延迟APISIX / Traefik动态配置、支持插件化鉴权限流更适合云原生网关场景四层TCP/UDP流量则要用LoadBalancer 类型的 Service或type: NodePort。生产建议Ingress Controller 前置一个云 LB 或 L4 负载再做 TLS termination证书用 cert-manager 自动续期别再手动换证书了。六、网络策略与可观测性网络通了还得管谁能访问谁。NetworkPolicy用标签声明 Pod 间的访问白名单默认是放行一切配了策略后变成默认拒绝。注意它依赖 CNI 插件支持Calico、Cilium 都支持Flannel 默认不支持。出了问题怎么查几个黄金命令kubectl get pods-owide# 看 Pod IP 和所在节点kubectlexec-itpod--curl-Isvc# 验证服务连通kubectl port-forwardpod8080:80# 本地转发调试更进阶的用 Cilium 的cilium monitor或 Hubble 直接看每个请求的转发路径、丢包原因比抓包省事十倍。七、小结Kubernetes 网络看着吓人其实就三层Pod 网络CNI解决Pod 之间怎么通Service kube-proxy解决Pod 漂移了怎么稳定访问Ingress解决外面流量怎么进来。记住一句话网络问题 80% 是 DNS 和 iptables 规则剩下 20% 才是 CNI 本身。把这三层模型刻进脑子里再复杂的网络故障你也能顺着流量路径一路定位到底。下一篇预告Kubernetes 安全加固——从 RBAC 到 Pod Security Standards 的实战落地。