上一篇【第47篇】NetworkPolicy——你的Pod之间需要防火墙下一篇【第49篇】Cilium——eBPF驱动的下一代K8s网络摘要前面我们一直在说Service负责负载均衡但Service自己不干活——真正把ClusterIP的流量转发到后端Pod的是kube-proxy这个默默无闻的搬运工。kube-proxy其实是个有故事的组件。它经历了三代架构演进userspace最老最慢已经被时代抛弃、iptables现在的主流靠一大堆iptables规则做随机均衡、IPVS新王登基哈希表O(1)转发丰富的调度算法。这篇文章把三种模式掰开揉碎(1)它们的转发链路到底差在哪(2)iptables为什么在大集群会规则爆炸拖垮性能(3)IPVS凭什么又快又灵活(4)怎么一键切到IPVS。读完你就知道为什么生产集群早该上IPVS了。一、kube-proxy在干啥1.1 它的核心职责【kube-proxy 的工作——Service的搬运工】 kube-proxy 在每个Node上都跑一个 │ │ 1. 监听 API Server有什么Service/Pod变化了 │ │ 2. 在Node上落地转发规则 │ • userspace: 起一个proxy进程监听端口 │ • iptables: 写一堆iptables规则 │ • IPVS: 写IPVS虚拟服务器/真实服务器 │ ▼ 用户访问 Service ClusterIP:Port → 被规则拦截 → 转发到某个后端Pod IP:Port要点kube-proxy的本质是个**“监听器规则写入器”**。它自己不转发任何包除了userspace模式而是把转发逻辑安装到内核里iptables/IPVS让内核去做高性能转发。这就是为什么切换模式不影响业务——规则换了个地方存而已。二、三代模式对比2.1 userspace被嫌弃的初代目【userspace 模式——每个包都要敲一次用户态的门】 Pod A ──访问──► ClusterIP:80 │ ▼ iptables 把包 重定向到本机 kube-proxy监听的 随机端口(如 10441) │ ▼ ┌─────────────┐ │ kube-proxy │ ← 用户态进程 │ (选一个后端) │ └──────┬──────┘ │ 再把包发出去 ▼ Pod B (后端) 问题每个包都要内核态→用户态→内核态走两趟 CPU开销巨大延迟高吞吐量上不去userspace模式在K8s 1.0时代是默认的后来因为性能太差1.2就引入了iptables模式替代它现在基本灭绝了。了解它只是为了理解演进史。2.2 iptables现在的主流【iptables 模式——在内核里用规则链做随机均衡】 Pod A ──访问──► ClusterIP:80 │ ▼ KUBE-SERVICES 链 │ ▼ KUBE-SVC-XXXXXX 链 (每个Service一条) │ ┌─────┴──────┐ │ 概率跳转 │ │ 30% → Pod1 │ statistic mode random │ 40% → Pod2 │ 概率 1/剩余权重 │ 30% → Pod3 │ └─────┬──────┘ ▼ KUBE-SEP-YYYYYY (DNAT到具体Pod IP) │ ▼ Pod B / Pod C / Pod D2.3 规则爆炸问题这是iptables模式最致命的软肋【iptables 规则数量随Service/Pod增长——线性爆炸】 Service数 Pod数 近似规则条数 ────────────────────────────────────── 10 50 ~ 几百条 100 500 ~ 几千条 1000 5000 ~ 几万条 ← 开始吃力 5000 20000 ~ 十几万条 ← 灾难 问题 • 每条规则是线性匹配(链表遍历)O(n) • 新增/删除Service要刷新整张表延迟高 • 规则越多kube-proxy同步越慢内存越大要点iptables用的是链表匹配规则是一条条遍历的虽然用了probability做负载分散但整体仍是线性查找。当集群有几千个Service、上万Pod时规则表会膨胀到十几万条不仅占用内存每次更新都要重刷全表延迟明显。这就是为什么大集群要换IPVS。三、IPVS新王登基3.1 哈希表O(1)的威力【IPVS 模式——哈希表直接命中不用遍历】 Pod A ──访问──► ClusterIP:80 │ ▼ IPVS 虚拟服务表 (Hash Map) ┌──────────────────────────┐ │ key: 10.96.0.1:80 │ │ ├─ real server: Pod1 │ ← O(1) 直接查到 │ ├─ real server: Pod2 │ │ └─ real server: Pod3 │ └──────────────────────────┘ │ 按调度算法选一个 (rr / lc / dh ...) ▼ Pod B / Pod C / Pod D维度iptablesIPVS数据结构链表(线性)哈希表(O(1))规则数量影响越大越慢几乎无影响调度算法仅随机概率rr/lc/dh/sh/sed/nq等连接复用一般支持会话保持健康检查无有(real server探测)大规模(1000 svc)❌ 吃力✅ 轻松3.2 IPVS支持的调度算法# 查看当前IPVS调度算法kubectl get configmap kube-proxy-nkube-system-oyaml|grepschedulerName# 默认: rr (轮询)# 支持的算法# rr : round-robin 轮询(最常用)# lc : least-connection 最少连接# dh : destination-hashing 目的地址哈希(同IP总到同Pod)# sh : source-hashing 源地址哈希(会话保持利器)# sed : shortest-expected-delay 最短期望延迟# nq : never-queue 永不排队(直接给空闲服务器)四、实战切到IPVS模式4.1 修改kube-proxy配置# 1. 编辑kube-proxy ConfigMapkubectl edit configmap kube-proxy-nkube-system# 修改# mode: ipvs# ipvs:# scheduler: rr # 可选 rr/lc/dh/sh/sed/nq# strictARP: false# 2. 重启kube-proxy (让配置生效)kubectl rollout restart daemonset/kube-proxy-nkube-system# 3. 验证IPVS规则已生成ipvsadm-Ln# 输出示例# TCP 10.96.0.1:443 rr# - 10.0.0.1:6443 Masq 1 0 0# TCP 10.96.0.10:53 rr# - 10.244.1.3:53 Masq 1 0 0# - 10.244.2.3:53 Masq 1 0 0# ↑ 看到这些虚拟服务就说明IPVS生效了要点切换IPVS要求Node内核加载了ip_vs相关模块。大多数现代Linux发行版都自带但如果你的内核太老或裁减过需要先modprobe ip_vs。另外IPVS模式默认也会保留iptables做MASQUERADE让Pod出网所以别以为切了IPVS就完全没有iptables了——只是Service转发那部分交给IPVS了。本篇小结kube-proxy的三代模式是K8s网络演进的缩影userspace因为每个包都进出用户态太慢被淘汰iptables靠内核规则链做随机均衡成了多年主流但规则线性增长会爆炸IPVS用哈希表O(1)转发多种调度算法轻松应对大集群是现在的生产首选。切IPVS很简单——改kube-proxy的mode为ipvs、重启DaemonSet、用ipvsadm -Ln验证即可。下一篇聊eBPF驱动的Cilium它会把kube-proxy彻底革掉命。上一篇【第47篇】NetworkPolicy——你的Pod之间需要防火墙下一篇【第49篇】Cilium——eBPF驱动的下一代K8s网络