3. Kubernetes 网络模型回顾：Pod IP、Service、kube-proxy、CNI 插件对连接的影响
在深入连接池水位调优之前，必须重新理解 Kubernetes 网络模型中的四个核心组件——Pod IP、Service、kube-proxy 和 CNI 插件——它们共同决定了数据包的转发路径、连接的生命周期以及后端实例的可见性。任何连接池参数的误配，根源往往是对这四层网络抽象的理解偏差。
3.1 四层网络抽象与连接路径
Kubernetes 网络模型强制满足三个基本要求：
- Pod 间无需 NAT 直接通信：每个 Pod 拥有独立的 IP 地址，所有 Pod 可以在同一平面内直接互访。
- 节点代理（kube-proxy）实现 Service 抽象：通过 iptables/IPVS 规则将虚拟 IP（ClusterIP）转换为后端 Pod IP。
- CNI 插件负责底层连通性：为 Pod 分配 IP、配置网络接口、实现跨节点路由或 Overlay 封装。
下图展示了从客户端 Pod 到目标 Service 再到后端 Pod 的完整数据包路径：
关键认知：连接池中的“连接”最终是 Pod IP 级别的 TCP 连接。Service 的 ClusterIP 只在连接建立时被 kube-proxy 转换为 Pod IP，后续数据包直接发往 Pod IP，不再经过 Service 虚拟 IP。
3.2 Pod IP：连接池的真实端点
Pod IP 是连接池中连接的实际目标地址。每个 Pod 重启后 IP 会变化，这直接导致连接池中的连接失效。理解 Pod IP 的特性对连接池水位管理至关重要：
| 特性 | 对连接池的影响 | 工程应对 |
|---|---|---|
| IP 动态性 | Pod 重建后 IP 变更，旧连接变为死连接 | 连接池必须实现空闲连接健康检查与自动驱逐 |
| 多副本分布 | 连接池需要维护到多个 Pod IP 的连接集合 | 使用客户端负载均衡策略（如轮询、最少连接） |
| 网络命名空间隔离 | 每个 Pod 拥有独立的网络栈，连接状态不共享 | 连接池参数需按 Pod 粒度独立配置 |
| CNI 分配的 IP 范围 | IP 段可能跨节点，连接可能跨节点转发 | 关注跨节点延迟对连接池超时设置的影响 |
3.3 Service 与 kube-proxy：连接分发与状态保持
Service 提供了稳定的虚拟 IP（ClusterIP），而 kube-proxy 负责将发往 ClusterIP 的流量转发到后端 Pod。kube-proxy 的三种模式对连接池行为有显著差异：
| 模式 | 转发机制 | 连接跟踪 | 连接池影响 |
|---|---|---|---|
| userspace（已弃用） | 用户态代理，性能差 | 内核 conntrack | 高延迟，不推荐 |
| iptables | 内核态 NAT 规则，随机选择后端 | 依赖 conntrack 保持连接一致性 | 连接建立后固定到同一 Pod；conntrack 表满导致丢包 |
| IPVS | 内核态 L4 负载均衡，支持调度算法 | 可选 conntrack，调度算法更丰富 | 支持最少连接、加权等算法；连接更均匀 |
连接池陷阱：iptables 模式下，如果 Service 后端 Pod 数量较少（如 2-3 个），iptables 规则的随机性可能导致连接分布不均，某些 Pod 的连接池水位过高而其他 Pod 空闲。建议使用 IPVS 模式并配置
sh（源地址哈希）或 lc（最少连接）调度算法。
3.4 CNI 插件：底层网络对连接的影响
CNI 插件决定了 Pod 之间以及 Pod 与外部网络的连通方式。不同的 CNI 实现会对连接延迟、吞吐量和连接稳定性产生直接影响：
| CNI 类型 | 代表实现 | 转发方式 | 连接池关注点 |
|---|---|---|---|
| Overlay | Flannel (VXLAN), Weave, Calico (IPIP) | 封装数据包，额外头部开销 | MTU 问题导致分片；额外延迟约 0.1-0.5ms |
| 路由 | Calico (BGP), Cilium (eBPF) | 直接路由，无封装 | 低延迟，高吞吐；依赖底层网络路由支持 |
| eBPF | Cilium | 内核态可编程数据面 | 绕过 iptables，连接跟踪更高效；支持连接负载均衡 |
下图对比了 Overlay 模式与路由模式在数据包处理路径上的差异：
3.5 连接池视角下的综合影响矩阵
将上述四个组件对连接池的影响汇总为决策矩阵，帮助你在实际工程中快速定位问题：
| 组件 | 连接建立 | 连接保持 | 连接断开 | 连接池参数影响 |
|---|---|---|---|---|
| Pod IP | 直接目标地址 | Pod 存活决定连接有效性 | Pod 删除导致连接 RST | maxPerRoute、idleTimeout |
| Service | 虚拟 IP 入口 | ClusterIP 不变，但后端可能变 | Service 删除导致连接中断 | connectTimeout、targetEndpoint |
| kube-proxy | DNAT 转换 | conntrack 保持会话 | conntrack 表满导致丢包 | maxConnections、evictionPolicy |
| CNI 插件 | 底层网络连通 | MTU、延迟影响连接质量 | 网络策略或封装导致超时 | socketTimeout、tcpKeepAlive |
实践建议：在配置连接池之前，先确认集群的 CNI 类型和 kube-proxy 模式。对于 Overlay 网络，适当增加
connectTimeout 和 socketTimeout 以容忍封装带来的额外延迟；对于 IPVS 模式，利用其调度算法优势实现更均衡的连接分布。