K8s-Service类型#

Headless Service：clusterIP=None，直接返回 Pod IP 列表

kube-proxy 转发机制（ClusterIP 底层）#

关键认知： ClusterIP 是虚拟 IP，没有任何实体网卡或进程在监听它。它只是一个被 kube-proxy 写进内核转发规则的”靶子”，数据包发往它时被内核改写目的地址（DNAT）转到真实 Pod IP。kube-proxy 不亲自转发流量，它只负责”维护规则”。

iptables 模式 — DNAT 规则链： Service/Endpoint 变化时 kube-proxy 重写一组链：

PREROUTING/OUTPUT → KUBE-SERVICES   （按 ClusterIP:Port 匹配，命中跳转）
                  → KUBE-SVC-xxx    （某个 Service 的入口）
                  → KUBE-SEP-yyy    （某个具体 Pod endpoint，做 DNAT 改写目的 IP）

• 概率负载均衡： KUBE-SVC 链用 statistic --probability 按概率分发到各 KUBE-SEP（如 3 个后端：1/3、1/2、1.0 递推），实现近似均匀。
• conntrack 会话保持： 首包 DNAT 后，连接跟踪表（conntrack）记录”原始目的 ↔ 改写后 Pod”映射，后续同连接的包直接查表走同一 Pod，回包自动反向 SNAT/un-DNAT，保证整条 TCP 连接打到同一后端。

iptables 的性能瓶颈： 规则是线性匹配 O(n)，Service/Endpoint 数量上万时，每个包要顺序过一长串规则，且每次变更要全量刷新规则，CPU 飙升、收敛变慢。

IPVS 模式 — O(1) 解法： 基于内核 LVS，用 hash 表存储 Service→后端映射，查找 O(1) 不随规模线性劣化；原生支持多种调度算法（rr/wrr/lc/sh 等）。大集群（千级以上 Service）首选 IPVS。 注意 IPVS 仍可能配合少量 iptables 做 SNAT/标记。

K8s中Service是将一组Pod暴露为网络服务的抽象，有四种类型。ClusterIP是默认类型，分配一个集群内部虚拟IP，只有集群内的Pod能访问，适合服务间内部通信。NodePort在ClusterIP基础上，在每个Node上开放一个固定端口（30000-32767范围），外部通过NodeIP:Port访问，适合开发测试但不适合生产。LoadBalancer在NodePort基础上，自动调用云厂商API创建外部负载均衡器，是生产环境对外暴露服务的标准方式。ExternalName比较特殊，它不做代理转发，只是创建一个DNS CNAME记录指向外部服务域名。还有一个特殊的Headless Service，设置clusterIP=None，DNS查询直接返回所有Pod的IP列表而不是VIP，适合StatefulSet等需要直连特定Pod的场景。

追问方向：

• “ClusterIP 底层怎么实现的？”→ kube-proxy 通过 iptables 或 IPVS 规则将发往 ClusterIP 的流量转发到后端 Pod；IPVS 模式性能更好，支持更多负载均衡算法（轮询、最小连接数等）
• “Headless Service 有什么用？”→ 设置 clusterIP=None，DNS 查询直接返回所有 Pod IP 而非 VIP；适用于 StatefulSet（如 MySQL 主从需要连接特定 Pod）和客户端自行做负载均衡的场景
• “生产环境怎么暴露服务？”→ 通常用 Ingress Controller（如 Nginx Ingress）统一管理外部流量，支持域名路由、TLS 终止、限流等；避免每个服务都用 LoadBalancer 浪费公网 IP

易错点：

• ❌ 以为 ClusterIP 上有进程在监听——它是纯虚拟 IP，靠内核 iptables/IPVS 的 DNAT 规则改写目的地址，没有实体
• ❌ 以为 kube-proxy 亲自代理转发流量——它只维护转发规则，真正转发由内核（netfilter/IPVS）完成，数据不经过 kube-proxy 进程
• ❌ 大集群还硬上 iptables 模式——规则 O(n) 线性劣化，应切 IPVS（hash 表 O(1)）