Pod 能够相互通信仅仅是服务部署的基础，要稳定可靠地对外提供服务，则依赖于 Service 这个核心抽象。然而，许多人对 Service 的理解仅停留在“一个虚拟 IP”的层面，对其内部工作机制存在不少困惑：
- 客户端请求究竟是如何从 Service IP 抵达后端 Pod 的？
- kube-proxy 组件在这个过程中扮演了什么角色？
- ClusterIP 和 NodePort 这两种主要类型的流量路径有何本质区别？
本文将深入解析 Service 的网络模型与 kube-proxy 的工作原理，彻底厘清这些问题。
01 Service 的本质与价值
首先需要明确一个关键概念：Service 不是一个进程，也不是一个代理服务器，而是一组预先定义好的、稳定的访问规则。
Pod 自身作为服务实例存在一些天然缺陷：
- IP 地址不稳定：Pod 重建后 IP 会改变。
- 生命周期短暂：Pod 可能因各种原因（如故障、滚动更新）被销毁和新建。
- 动态伸缩：服务的 Pod 副本数量会根据负载动态调整。
Service 正是为了解决这些问题而设计的，它提供了：
- 稳定的访问入口：一个固定的虚拟 IP (ClusterIP) 或域名。
- 后端透明性：调用方无需感知后端 Pod 的具体数量、IP 和状态变化。
- 自动负载均衡：流量会被自动、均衡地分发到后端的多个 Pod。
因此，Service 的核心能力可以概括为一句话：将发往 Service 的访问流量，按照既定规则转发到一组匹配标签选择器（selector）的 Pod 上。
02 kube-proxy：Service 规则的执行引擎
Service 本身只是一个存储在 etcd 中的 API 对象（一组规则），真正让这些规则生效、指挥流量转发的，是运行在每个工作节点上的 kube-proxy 组件。
kube-proxy 以守护进程的形式运行，它的核心职责包括：
- 监听与同步：实时监听 Kubernetes API Server 上 Service 和 Endpoint（后端 Pod 集合）对象的变化。
- 配置规则：根据监听到的变化，在本机（其所在的 Node 节点）配置相应的网络转发规则。
- 流量转发：确保所有指向 Service 的流量能够被本机的网络栈根据这些规则正确转发到后端 Pod。
为了实现流量转发，kube-proxy 支持三种工作模式：
这三种模式的本质区别在于实现流量转发规则的技术路径不同。
03 ClusterIP 模式深度解析
3.1 ClusterIP 是什么？
ClusterIP 是 Service 的默认类型，它提供了一个仅在集群内部可访问的虚拟 IP 地址（Virtual IP， VIP）。这个 IP 的特点是：
- 存在于集群的 Service CIDR 网段内（如 10.96.0.0/12）。
- 不绑定在任何物理或虚拟网络设备上。
- 无法被
ping 通，因为它只是一个存在于转发规则中的逻辑地址。
例如，一个 Service 可能被分配如下 ClusterIP：
Service IP: 10.96.120.5
3.2 ClusterIP 流量路径（以 iptables 模式为例）
假设在 运维/DevOps 实践中，一个位于 Pod A 的客户端需要访问一个 ClusterIP 类型的 Service，其目标后端是 Pod B。请求的真实路径并非直观的“Pod A -> ClusterIP -> Pod B”。
真实流程如下：
-
发起请求：Pod A 中的应用向 Service 的 ClusterIP 发起请求。
curl http://10.96.120.5:80
-
进入网络栈：该网络包离开 Pod A 的网络空间，进入其所在宿主机（Node）的网络栈。
-
规则匹配与转发：kube-proxy 预先在本机配置的 iptables 规则开始生效。这些规则会：
-
抵达目标：经过 DNAT 后的数据包，通过网络路由，最终被送达目标 Pod B。
核心要点：
- 整个过程中，不存在一个名为“Service”的进程在接收和代理流量。
- 流量转发不经过中心节点，完全由各个节点内核根据本地规则处理。
- Service 的本质就是一组由 kube-proxy 维护的、分布在各节点的 NAT 规则表。
04 NodePort 模式：外部访问的实现机制
4.1 NodePort 的工作原理
NodePort 类型在 ClusterIP 的基础上增加了一层能力，允许从集群外部访问 Service。它主要做了两件事：
- 为 Service 在集群所有节点上分配一个固定的端口（范围默认为 30000–32767）。
- 在每个节点的内核中配置规则，监听该端口上的流量。
访问模式变为：
外部客户端 -> 任意Node的IP:NodePort -> Service -> Pod
4.2 NodePort 流量完整路径
当一个外部客户端试图访问服务时：
-
请求进入：客户端的请求到达集群中任意一个 Node 的 NodeIP:NodePort（如 192.168.1.100:30080）。
-
NodePort 规则匹配：该节点上的 kube-proxy 配置的 iptables/IPVS 规则首先匹配到 NodePort。
-
第一次 DNAT：规则将请求的目标地址进行第一次 DNAT，从 NodeIP:NodePort 转换为该 Service 的 ClusterIP:ServicePort。
-
第二次 DNAT：紧接着，匹配到 ClusterIP 的规则（即上一节描述的规则）生效，执行第二次 DNAT，将目标地址转换为最终的后端 PodIP:PodPort。
即完整路径为：
Client -> NodeIP:30080 -> (DNAT) -> ClusterIP:80 -> (DNAT) -> PodIP:8080
关键注意事项：
- 请求可以发送到集群内任何节点，无论该节点上是否运行着目标 Pod。
- 如果 Pod 不在接收请求的节点上，该节点的
kube-proxy 或 网络/系统 层面的路由/隧道机制（如路由网络或 Overlay 网络）会负责将流量转发到 Pod 所在的正确节点。
05 kube-proxy：iptables 与 IPVS 模式对比
iptables 模式
- 优点：实现简单、稳定可靠，是历史最悠久的模式。
- 缺点：当集群内 Service 和 Pod 数量极大时，iptables 规则链会变得非常冗长，导致规则匹配效率下降，网络延迟增加。其负载均衡算法相对单一（主要为随机）。
- 适用场景：中小规模集群，或对模式通用性要求高的环境。
IPVS 模式
- 优点：基于内核的 Layer 4 负载均衡器，专为大规模负载均衡设计。支持丰富的调度算法（如 rr, wrr, lc, wlc 等），性能更高。
- 缺点：需要节点内核支持 IPVS 模块。
- 适用场景：大规模生产集群，Service 数量超过数千个，对性能和多种负载均衡算法有明确需求。
生产建议：在节点数量多、Service 规模大的 云原生/IaaS 环境中，应优先考虑使用 IPVS 模式以获得更优的网络性能。
06 关于 Service 的常见认知误区
❌ 误区一：Service 拥有一个真实可路由的 IP 地址。
✔ 纠正：Service IP（ClusterIP）是纯粹的虚拟 IP，仅存在于内核的 iptables/IPVS 规则或 IPVS 哈希表中，在网络设备上不可见。
❌ 误区二：流量必须先经过 kube-proxy 进程处理。
✔ 纠正：kube-proxy 只是一个“配置者”（Configurator）。流量直接由 Linux 内核根据 kube-proxy 预先配置好的 netfilter (iptables) 或 IPVS 规则进行转发，不流经 kube-proxy 进程本身。
❌ 误区三：NodePort 只在运行了目标 Pod 的节点上生效。
✔ 纠正：NodePort 类型的 Service 会在集群每一个 Node 节点上开通并监听相同的端口。外部流量可以访问任意节点，即使该节点上没有服务 Pod，节点的 kube-proxy 也会负责将流量转发到正确的节点。
07 核心要点总结
- Service 是规则：它是一组稳定的、抽象的服务访问规则，而非一个实体组件。
- kube-proxy 是执行者：作为每个节点上的代理，它负责将 Service 规则翻译成本机的网络转发规则。
- ClusterIP 靠 DNAT：集群内部访问通过 DNAT 规则实现虚拟 IP 到真实 Pod IP 的转换和负载均衡。
- NodePort 是扩展：NodePort = 在所有节点上开放端口 + Service 标准的 ClusterIP 转发机制。
- 模式选择：iptables 模式简单通用，IPVS 模式则更适合大规模、高性能的
云原生 场景，能够提供更专业的负载均衡能力。
发表于 13 小时前
|
查看: 2|
回复: 0
