📚 课程目录第3章 kube-proxy工作原理

3、kube-proxy 工作原理：iptables/IPVS 模式、Service 与 Endpoints 同步机制

kube-proxy 是 Kubernetes 集群中负责实现 Service 网络代理的核心组件，运行在每个 Node 上。它监听 API Server 中 Service 与 Endpoints 资源的变化，并根据代理模式（iptables/IPVS/userspace）将规则写入节点内核，使集群内外的流量能够正确路由到后端 Pod。理解其工作原理，是诊断证书轮换导致规则失效的基础。

3.1 两种主流代理模式对比

当前生产环境主要使用 iptables 和 IPVS 两种模式。userspace 模式因性能问题已基本被弃用。下表从规则结构、性能、复杂度等维度进行对比：

对比维度	iptables 模式	IPVS 模式
内核组件	Netfilter 钩子 + 规则链表	LVS 内核模块 + 哈希表
规则结构	链式遍历，规则数量线性增长	哈希查找，时间复杂度 O(1)
大规模集群性能	Service 数量 > 1000 时延迟明显	支持 10,000+ 服务，性能稳定
负载均衡算法	仅支持随机（概率均等）	支持 rr、lc、dh、sh、sed、nq 等多种算法
内核模块依赖	无额外依赖	需加载 ip_vs、ip_vs_rr 等模块
规则更新方式	全量刷新（iptables-restore）	增量更新（通过 netlink 接口）
排障复杂度	规则链长，排查较复杂	需使用 ipvsadm 工具，规则更直观

选型建议： 集群规模小于 100 个 Service 时，iptables 模式足够稳定且无需额外内核配置；超过 500 个 Service 或对延迟敏感的场景，强烈建议使用 IPVS 模式。

3.2 Service 与 Endpoints 同步机制

kube-proxy 的核心逻辑是一个 控制循环（Control Loop），它通过 Informer 机制监听 API Server 上的 Service 和 Endpoints（或 EndpointSlice）资源。当证书轮换导致 kube-proxy 与 API Server 的连接中断时，这个循环就会失效。

同步流程分为以下关键步骤：

监听阶段： kube-proxy 启动后，向 API Server 注册 Service 和 Endpoints 的 Watch 请求，建立长连接。
事件入队： 当 Service 或 Endpoints 发生变化（新增、删除、更新），Informer 将事件对象放入工作队列（Work Queue）。
去重与合并： 工作队列对同一资源的多次更新进行去重合并，避免频繁触发规则重写。
规则计算： 从队列中取出事件，根据当前代理模式（iptables/IPVS）计算新的规则集合。
规则写入： 将计算后的规则通过 iptables-restore 或 netlink 接口写入内核。
健康检查： 定期（默认 30 秒）对后端 Pod 进行健康检查，剔除异常 Endpoints。

  关键依赖： 步骤 1 和步骤 2 依赖 kube-proxy 与 API Server 之间的 TLS 连接。如果证书过期或轮换后未正确加载，Watch 连接会断开，Informer 无法收到事件，导致规则永久停滞。

3.3 iptables 模式规则链结构

在 iptables 模式下，kube-proxy 在 nat 表中创建一系列自定义链，形成如下层级结构：

PREROUTING --> KUBE-SERVICES
  |
  +--> 匹配 ClusterIP:Port --> KUBE-SVC-XXXXX
  |     |
  |     +--> KUBE-SEP-YYYY1 (Pod1)
  |     +--> KUBE-SEP-YYYY2 (Pod2)
  |     +--> KUBE-SEP-YYYY3 (Pod3)
  |
  +--> 匹配 NodePort --> KUBE-NODEPORTS
  +--> 匹配 ExternalIP --> KUBE-EXT-XXXXX

OUTPUT --> KUBE-SERVICES (本地进程访问 ClusterIP)

每个 KUBE-SVC-XXXXX 链对应一个 Service，内部通过 statistic 模块实现概率均等的负载均衡，将流量随机转发到对应的 KUBE-SEP-YYYY 链（每个 Endpoint 一条规则）。

3.4 IPVS 模式规则结构

IPVS 模式使用内核哈希表，规则结构更加扁平。通过 ipvsadm 命令可以查看：

# 查看所有 IPVS 虚拟服务
ipvsadm -Ln

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.96.0.1:443 rr
  -> 192.168.1.10:6443            Masq    1      0          0
TCP  10.96.0.10:53 rr
  -> 192.168.1.20:53              Masq    1      0          0
  -> 192.168.1.21:53              Masq    1      0          0

每个 VirtualServer 对应一个 Service，RealServer 对应后端 Pod。IPVS 模式还额外依赖 ipset 来处理 ClusterIP 和 NodePort 的流量分类，减少 iptables 规则数量。

3.5 同步机制与证书轮换的关联点

证书轮换导致 kube-proxy 规则失效的根因，在于同步机制的两个关键环节：

Watch 连接中断： kube-proxy 使用客户端证书与 API Server 建立 Watch 长连接。证书轮换后，如果 kube-proxy 未自动加载新证书（或重启），连接会被 API Server 断开，Informer 停止接收事件。
定时同步失效： kube-proxy 默认每 5 分钟执行一次全量同步（--sync-period），作为 Watch 机制的兜底。如果证书错误导致 API 调用失败，定时同步也会失败，规则永久停留在旧状态。

典型故障现象： 证书轮换后，新创建的 Service 无法访问，但旧 Service 仍然正常。这是因为旧 Service 的规则在证书失效前已写入内核，而新 Service 的事件因 Watch 中断未被处理。重启 kube-proxy Pod 通常可以临时恢复，但根本解决需要确保证书热加载机制正常。

3.6 同步周期与故障恢复时间

kube-proxy 的同步机制包含两个时间维度，直接影响证书轮换后的故障恢复速度：

同步类型	默认周期	触发条件	证书失效影响
事件驱动同步	实时（毫秒级）	Watch 收到资源变更事件	Watch 中断后完全失效
定时全量同步	5 分钟（--sync-period）	定时器到期	API 调用失败，同步跳过
健康检查同步	30 秒（--healthz-bind-address）	健康检查探测	不影响规则更新

  恢复策略： 当证书轮换导致规则失效时，最快的恢复方式是手动重启 kube-proxy Pod（触发重新加载证书和全量同步）。如果集群规模较大，建议使用 kubectl rollout restart 滚动重启，避免所有节点同时中断。