4. Service与kube-proxy转发机制
Service 是 Kubernetes 中稳定访问后端 Pod 的抽象入口，而真正把 Service 的虚拟 IP（ClusterIP）落到具体 Pod 上的，是每个节点上的 kube-proxy。理解 kube-proxy 的两种主流实现——iptables 模式与 IPVS 模式——是排查 Service 访问慢、连接超时、规则膨胀等问题的前提。本节从数据包在内核中的实际走向出发，对比两种模式的实现差异，分析规则规模与连接跟踪表对性能的影响，并给出可落地的调优方向。
一、Service 到 Pod 的转发链路
当客户端访问 ClusterIP:Port 时，数据包先到达节点网络栈，由 kube-proxy 写入的转发规则完成 DNAT，把目标地址改写为某个 Endpoint（Pod IP:TargetPort），再经 CNI 网络送达 Pod。返回流量则依赖 conntrack（连接跟踪）做反向转换。因此，kube-proxy 的规则形态和 conntrack 的行为共同决定了 Service 的性能上限。
二、iptables 模式的实现与瓶颈
iptables 模式下，kube-proxy 为每个 Service 生成一条 KUBE-SERVICES 链上的匹配规则，命中后再跳转到对应的 KUBE-SVC-xxxx 链，由该链按概率（statistic 模块）随机选择一条 KUBE-SEP-xxxx 规则完成 DNAT。这意味着：
- 匹配是线性的：数据包要按顺序逐条比对规则，Service 越多，命中目标规则前经过的规则越多。
- 规则数量随 Service 与 Endpoint 数量乘积增长：每个 Endpoint 至少一条 SEP 规则，规模大时可达数万条。
- 更新代价高：kube-proxy 在同步时倾向于整体重写相关链，规则量大时同步耗时明显，期间可能出现短暂的不一致。
因此，当集群 Service 数量达到数百甚至上千、且访问模式以短连接为主时，iptables 模式容易出现转发延迟上升、CPU 在软中断中消耗偏高、规则同步变慢等现象。
三、IPVS 模式的实现与优势
IPVS 是内核自带的四层负载均衡器，kube-proxy 在 IPVS 模式下把每个 Service 映射为一个虚拟服务（Virtual Service），把每个 Endpoint 映射为真实服务器（Real Server），并挂载到内核的哈希表中。数据包进入后由 IPVS 直接查表转发，不再逐条遍历规则。其关键差异在于：
- 查找复杂度低：哈希查找接近 O(1)，转发性能对 Service 数量不敏感。
- 支持多种调度算法：如
rr（轮询）、wrr（加权轮询）、lc（最少连接）、sh（源地址哈希），可按业务特征选择。 - 增量更新：新增或删除 Endpoint 时只改动对应表项，不必全量刷写。
需要注意的是，IPVS 模式仍依赖 iptables 处理 SNAT、NodePort、masquerade 等辅助逻辑，因此并非完全脱离 iptables，只是把核心的 Service 转发从规则链迁移到了哈希表。
四、连接跟踪表压力
无论哪种模式，Service 转发都依赖 conntrack 记录连接状态。每个新建连接都会在 /proc/sys/net/netfilter/nf_conntrack 中占用一个表项，默认上限常为 65536 或 262144。当短连接 QPS 很高、或存在大量 TIME_WAIT 未及时回收时，可能出现：
nf_conntrack: table full, dropping packet日志，新连接被丢弃；- DNAT 反向转换失败，表现为连接建立后无响应或超时；
- conntrack 表项老化慢，占用内存持续升高。
可通过以下命令观察当前压力：
# 查看 conntrack 使用量与上限
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
# 查看超时参数（秒）
sysctl net.netfilter.nf_conntrack_tcp_timeout_established
sysctl net.netfilter.nf_conntrack_tcp_timeout_time_wait五、调优方向
结合上述机制，调优可从模式选择、内核参数与业务侧三方面入手：
| 方向 | 关键动作 | 适用场景 |
|---|---|---|
| 切换 IPVS | kube-proxy 配置 mode: ipvs，并设置 ipvs.scheduler | Service 数量多、短连接密集 |
| 扩大 conntrack | 提高 nf_conntrack_max，缩短 tcp_timeout_time_wait | 高并发短连接、TIME_WAIT 堆积 |
| 减少 Service 数量 | 合并同类 Service，避免为每个端口单独建 Service | iptables 模式下规则膨胀 |
| 使用本地转发 | 设置 externalTrafficPolicy: Local 或 internalTrafficPolicy: Local | 降低跨节点跳数、保留源 IP |
| 会话保持 | IPVS 下使用 sh 调度并配置 sessionAffinity | 需要同一客户端固定后端 |
nf_conntrack_max 会同步增加内存占用，需结合节点内存评估；同时应关注 nf_conntrack_buckets 与 max 的比例，避免哈希冲突导致查找变慢。总体而言，iptables 模式实现简单、兼容性好，适合中小规模集群；IPVS 模式在 Service 与 Endpoint 规模较大时具备明显的转发性能优势。实际排障中，应先确认当前 kube-proxy 模式与规则/表项规模，再结合 conntrack 使用率判断瓶颈位于规则匹配还是连接跟踪，最后有针对性地调整模式与内核参数。