Images:

Kubernetes Networking | K8s Services and The Types

这是一个关于 Kubernetes Service（以 ClusterIP 类型为例）网络流量从客户端到 Pod 再返回的概念流程图，非常适合作为理解 Service 与 kube-proxy 如何协作的重要视觉参考。

修正并补充说明

一、Service 与 ClusterIP 基础

  • Kubernetes 的 Service 提供一个稳定的虚拟 IP（ClusterIP），用于将客户端请求负载均衡地转发给匹配标签的多副本 Pod。Pod IP 动态变化，但 Service IP 保持稳定 (discuss.kubernetes.io, test.k21academy.com).

二、kube-proxy 的核心角色

  • kube-proxy 是每个节点上运行的网络代理组件，它监听 Service 和 Endpoints 的变化，并将其转化为节点上的网络规则（如 iptables 或 IPVS）(kodekloud.com).
  • 在 iptables 模式 中，kube-proxy 利用 iptables 规则实现 DNAT（Destination NAT）：将流量从 ClusterIP 转发到某个后端 Pod (kubernetes.io).

三、从前端 Pod 到后端 Pod 的真实流量流程

  1. 前端 Pod 发送请求 到 Service 的 ClusterIP。
  2. 请求到达所在节点的 kube-proxy，触发匹配 Service 的 iptables 规则。
  3. kube-proxy 根据负载均衡策略（如轮询或随机）选择某个后端 Pod，并对目标 IP 做 DNAT，将请求改为具体 Pod 的 IP；源 IP 保持前端 Pod 的地址不变 (kerno.io, discuss.kubernetes.io).
  4. 如果目标 Pod 位于不同节点，该节点的 IP 转发或 overlay 网络（如 Flannel、Calico）会将请求传递到目标节点 (discuss.kubernetes.io).
  5. 后端 Pod 处理请求并响应，响应通过相反的路径返回。kube-proxy 或内核保持连接状态，自动处理反向 DNAT，将源地址恢复为 ClusterIP，确保客户端接收到正确的响应 (docs.tigera.io).

四、为什么这么设计？

  • 负载均衡：Service IP 均匀分配请求，避免某个 Pod 过载。
  • 抽象与透明化：客户端无需感知 Pod IP，只需与 Service 交互即可。
  • 灵活性：可动态扩容、缩容 Pod，无需修改客户端配置。
  • 效率：iptables 或 IPVS 在内核层高效处理转发，性能优越 (discuss.kubernetes.io, zesty.co).

最终整理：改进版笔记

一、Traffic Flow 概览

  • 客户端（前端 Pod）通过 ClusterIP 访问 Service。
  • kube-proxy 在所在节点安装网络规则（iptables/IPVS），拦截流量并通过 DNAT 指向某个后端 Pod。
  • 若 Pod 在其他节点，通过 CNI overlay 网络传递请求。
  • Pod 处理并响应，通过连接跟踪自动反向 DNAT 删除 ClusterIP，再将响应送回前端 Pod。

二、关键机制与优势

  • kube-proxy 是控制层组件，负责生成节点级路由规则。
  • iptables 模式：高效；规则链将 Service IP 映射到 Pod IP，实现负载均衡。
  • 高可用与动态：Pod 可频繁变化，Service 与 kube-proxy 动态协同保证流量连续可达。
  • 节点间通信：CNI overlay 网络确保跨节点 Pod 可访问。
  • 源 IP 保留：ClusterIP DNAT 不修改请求源地址，但 NodePort/LoadBalancer 类型则可能 SNAT 源 IP (docs.tigera.io, kodekloud.com, zesty.co).