2. Kubernetes 网络基础：Pod 网络模型、Service 与 Ingress 流量路径

在深入后端鉴权拦截链路的性能优化之前，必须透彻理解 Kubernetes 集群内的网络通信模型。本章将拆解 Pod 网络模型、Service 抽象层以及 Ingress 南北向流量的完整路径，为后续分析鉴权组件在数据路径中的位置与性能瓶颈奠定基础。

2.1 Pod 网络模型：扁平 IP 与容器间通信

Kubernetes 要求每个 Pod 拥有一个集群内唯一的 IP 地址（Cluster IP），且 Pod 内的所有容器共享该 IP 与网络命名空间。这种“每个 Pod 一个 IP”的扁平网络模型，使得 Pod 之间无需 NAT 即可直接通信。

特性 说明
IP 分配 每个 Pod 从集群 CIDR 中获取唯一 IP，Pod 重启或迁移后 IP 可能变化
容器间通信 Pod 内多个容器共享 localhost，通过不同端口区分服务
Pod 间通信 直接通过 Pod IP 通信，无需端口映射，网络插件（CNI）负责路由
节点间通信 CNI 插件（如 Calico、Flannel、Cilium）通过 Overlay 或 BGP 实现跨节点 Pod 互通
性能要点： 扁平网络模型消除了传统 Docker 桥接网络的端口映射开销，但 CNI 插件的封装方式（如 VXLAN Overlay）会引入额外的 CPU 与延迟开销。对于鉴权拦截链路，建议优先选择原生路由（BGP）或 eBPF 加速方案（Cilium）以减少网络跳数。

2.2 Service 抽象层：流量负载均衡与 ClusterIP

Pod 的 IP 是动态的，因此 Kubernetes 引入 Service 作为稳定的访问入口。Service 通过标签选择器关联一组 Pod，并提供 ClusterIP（虚拟 IP）实现四层负载均衡。

  • ClusterIP（默认）： 仅在集群内部可达，通过 iptables/IPVS 规则将流量转发到后端 Pod。
  • NodePort： 在每个节点上开放一个静态端口（30000-32767），外部流量通过 NodeIP:NodePort 进入。
  • LoadBalancer： 云厂商提供的外部负载均衡器，将流量分发到 NodePort 或直接到 Pod。
  • Headless Service： 不分配 ClusterIP，直接返回后端 Pod IP 列表，适用于有状态应用。
流量路径（iptables 模式）：
Client → ClusterIP:Port → iptables DNAT 规则 → 随机 Pod IP:Port → Pod 容器

Service 的负载均衡模式直接影响鉴权拦截链路的延迟：

模式 转发机制 延迟特征 适用场景
iptables 内核 Netfilter 规则链，随机选择后端 规则数量增加时延迟线性上升 小规模集群（< 1000 条规则）
IPVS 内核哈希表，直接查找后端 规则数量增加时延迟几乎不变 大规模集群，高吞吐场景
eBPF (Cilium) 内核 BPF 程序，绕过 iptables 极低延迟，无规则链遍历开销 性能敏感型鉴权链路
Service 流量路径：ClusterIP → iptables/IPVS → Pod Client ClusterIP:80 iptables/IPVS DNAT + 负载均衡 Pod A Pod B Pod C 关键路径说明： 1. Client 请求到达 ClusterIP:80（虚拟 IP，仅存在于内核规则中）。 2. iptables/IPVS 规则匹配目标 IP:Port，执行 DNAT 替换为后端 Pod IP。 3. 内核根据负载均衡算法（随机/轮询/最小连接）选择一个 Pod。 4. 数据包直接路由到目标 Pod 所在节点的网络栈，最终进入容器。 5. 回程流量直接由 Pod 返回 Client，无需再次经过 Service（连接跟踪）。 优化建议： - 使用 IPVS 替代 iptables 避免规则链遍历；- 启用 Cilium eBPF 完全绕过 iptables。

2.3 Ingress 流量路径：南北向入口与七层路由

Ingress 是 Kubernetes 的七层（HTTP/HTTPS）流量入口，负责将外部请求路由到集群内部的 Service。相比 Service 的四层转发，Ingress 能够基于 Host、Path、Header 等应用层信息进行精细化路由，是后端鉴权拦截链路的首选入口点。

常见误区： Ingress 本身只是一个 API 对象，真正处理流量的是 Ingress Controller（如 Nginx Ingress、Traefik、HAProxy Ingress）。Controller 通常以 Deployment 或 DaemonSet 形式运行在集群内，并监听 Ingress 资源变化动态更新路由规则。

2.4 完整流量路径：从外部到 Pod

结合 Ingress 与 Service，一个完整的外部请求到达后端 Pod 的路径如下：

  1. DNS 解析： 客户端解析域名到 Ingress Controller 的对外暴露地址（LoadBalancer IP 或 NodePort）。
  2. Ingress Controller 接收： Controller 根据 Host/Path 匹配 Ingress 规则，选择对应的后端 Service。
  3. Service 负载均衡： Controller 将请求转发到 Service 的 ClusterIP（或直接转发到 Pod IP，取决于 Controller 配置）。
  4. Pod 处理： 请求到达目标 Pod 的容器端口，应用层开始处理（包括鉴权拦截）。
Ingress + Service 完整流量路径 外部客户端 DNS 域名解析 Ingress Controller Service ClusterIP 后端 Pod 组 鉴权拦截器 业务逻辑 路径总结： 外部客户端 → DNS → Ingress Controller（七层路由） → Service（四层负载均衡） → Pod（鉴权 + 业务） 鉴权拦截器通常部署在 Pod 内的 Sidecar 或应用网关层，位于 Service 转发之后、业务逻辑之前。

2.5 性能优化关键点总结

网络层级 潜在瓶颈 优化方向
Pod 网络 CNI Overlay 封装开销 使用原生路由（BGP）或 eBPF 加速（Cilium）
Service iptables 规则链遍历 切换 IPVS 模式；启用 Cilium eBPF 绕过 iptables
Ingress Controller 配置重载、TLS 终止 使用高性能 Controller（Nginx Ingress 调优）；启用 TLS 会话复用
鉴权拦截 网络跳数增加、额外解析开销 将鉴权组件部署为 Sidecar 或 DaemonSet 就近处理；避免跨节点转发
实践建议： 在鉴权拦截链路中，优先将 Ingress Controller 与鉴权服务部署在同一节点或同一可用区，减少跨节点网络延迟。同时，使用 IPVS 或 eBPF 模式替代默认的 iptables 模式，可降低 20%-40% 的转发延迟。
← 上一章 📖 返回目录 下一章 →