Kubernetes 网络原理深度解析：从 Pod 网络到 Service 与 Ingress 的完整链路原创

2026-10-27 服务器浏览 (7)

温馨提示：

本文最后更新于 2026-10-27，已超过 1 天没有更新。若文章内的图片失效（无法正常加载），请留言反馈或直接联系我。

Kubernetes 网络原理深度解析：从 Pod 网络到 Service 与 Ingress 的完整链路

Kubernetes 的网络模型是分布式系统中最容易被误解的部分之一。很多人能跑起集群，却说不清 Pod 之间、Pod 与 Service、以及集群入口流量到底是怎么流转的。这篇文章从第一性原理出发，把 K8s 网络拆成三层：Pod 网络、Service 网络、入口网络，逐层打通完整链路。

一、Pod 网络：每个 Pod 一个真实 IP

K8s 的核心网络假设是：每个 Pod 拥有独立的 IP，且集群内任意两个 Pod 无需 NAT 即可直接通信。这个假设由 CNI（Container Network Interface）插件实现。常见的 CNI 有 Calico（BGP 路由）、Flannel（VXLAN 覆盖）、Cilium（eBPF）。

无论哪种实现，Pod 网络都要解决三件事：

需求	解决方案	典型实现
每个 Pod 独立 IP	网络命名空间 + veth 对	所有 CNI
跨节点通信	路由协议 / 覆盖隧道	Calico BGP / Flannel VXLAN
网络策略隔离	iptables / eBPF 规则	NetworkPolicy + Cilium

# 一个 Pod 的网络拓扑（Node 上）
eth0 (宿主机网卡)
  └── cni0 (网桥) ── veth0 ──> Pod1 eth0 (10.244.1.2)
              └── veth1 ──> Pod2 eth0 (10.244.1.3)

二、Service 网络：稳定入口与负载均衡

Pod 的 IP 是动态的，删了重建就变。Service 提供稳定的虚拟 IP（ClusterIP），并把流量转发到一组后端 Pod。其核心是 kube-proxy，支持三种模式：

模式	实现	特点
userspace	用户态代理	已废弃，性能差
iptables	内核 netfilter 规则	默认，随机负载均衡
IPVS	内核 LVS	高性能，支持更多调度算法

# Service 到 Pod 的转发链（iptables 模式）
PREROUTING
  └→ KUBE-SERVICES (匹配 ClusterIP)
       └→ KUBE-SVC-XXX (负载均衡)
            └→ KUBE-SEP-YYY (转发到具体 Pod)

DNS 由 CoreDNS 提供服务：my-svc.default.svc.cluster.local 解析到 ClusterIP。

三、入口网络：从集群外访问服务

ClusterIP 只在集群内可达。要对外暴露服务，有三种主流方式：

方式	层级	适用场景
NodePort	每节点固定端口	简单调试、测试
LoadBalancer	云厂商负载均衡	云环境、生产
Ingress	七层 HTTP 路由	多域名、多路径、TLS 终止

生产环境推荐 Ingress + 云负载均衡 组合：云 LB 承接公网流量，Ingress Controller（如 Nginx Ingress、Traefik）负责按域名和路径路由到内部 Service。

# Ingress 示例
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /v1
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080