在K8S中,Iptables 四表五链有哪些?
在 Kubernetes 中,kube-proxy 使用 iptables 实现 Service 的负载均衡和流量转发。理解 iptables 的 四表五链 是掌握 K8S 网络机制的关键基础。以下是详细解析:
一、iptables 核心概念
1. 表(Tables)
iptables 的功能按表分类,每个表处理特定类型的流量:
| 表名 | 作用 | K8S 中的重要性 |
|---|---|---|
filter |
默认表,负责过滤流量(允许/拒绝数据包) | ⭐⭐ |
nat |
网络地址转换(NAT),用于修改数据包的源/目标 IP 和端口(如 SNAT、DNAT) | ⭐⭐⭐⭐⭐(K8S Service 核心依赖) |
mangle |
修改数据包头部(如 TTL、QoS 标记) | ⭐(K8S 极少使用) |
raw |
连接跟踪(conntrack)前处理,用于豁免某些数据包的跟踪 | ⭐⭐ |
2. 链(Chains)
链是规则的集合,按数据包流经位置分为五条内置链:
| 链名 | 触发时机 | 常见操作 |
|---|---|---|
PREROUTING |
数据包进入网络接口后、路由决策前 | DNAT(目标地址转换) |
INPUT |
数据包目标是本机(如访问 Node 的 SSH 服务) | 过滤本地流量 |
FORWARD |
数据包需要转发到其他机器(如 Pod 跨节点通信) | 过滤转发流量 |
OUTPUT |
本机生成的出站数据包(如 Pod 访问外部服务) | SNAT(源地址转换) |
POSTROUTING |
数据包离开网络接口前 | MASQUERADE(动态 SNAT) |
二、四表五链的协作关系
数据包处理流程(含 K8S 相关操作):
+-------------------------+
| Network |
| Interface |
+------------+------------+
▼
+-----------------+
| PREROUTING | // K8S:Service DNAT 在此发生!
| (nat, mangle) |
+--------+--------+
▼
+-----------------+
| ROUTING DECISION | // 判断目标是本机还是其他节点
+--------+--------+
|
+-------------------------+-------------------------+
| |
目标为本机?(INPUT) 需要转发?(FORWARD)
| |
+---------------▼---------------+ +------------▼------------+
| INPUT 链 | | FORWARD 链 |
| (filter, mangle) | | (filter) |
+---------------+---------------+ +------------+------------+
| |
+---------------▼---------------+ +------------▼------------+
| Local Process (本机进程) | | POSTROUTING |
| (如 kubelet、kube-proxy) | | (nat) | // K8S:SNAT 在此发生!
+---------------+---------------+ +------------+------------+
| |
+---------------▼---------------+ +------------▼------------+
| OUTPUT 链 | | Network |
| (nat, filter, mangle, raw) | | Interface |
+---------------+---------------+ +-------------------------+
|
+---------------▼---------------+
| POSTROUTING 链 |
| (nat, mangle) |
+---------------+---------------+
|
▼
+-----------------+
| Network |
| Interface |
+-----------------+
三、Kubernetes 如何使用 iptables?
kube-proxy 在 nat 表 中创建自定义链,实现 Service 流量转发:
1. 核心自定义链(由 kube-proxy 管理)
| 自定义链名 | 挂载点 | 作用 |
|---|---|---|
KUBE-SERVICES |
PREROUTING |
入口流量第一跳,匹配目标 IP 是否为 Service 的 ClusterIP |
KUBE-NODEPORTS |
KUBE-SERVICES |
处理 NodePort 类型 Service 的流量 |
KUBE-SVC-XXXXX |
KUBE-SERVICES |
代表单个 Service,负载均衡到多个 Pod(通过 KUBE-SEP-XXXX 链) |
KUBE-SEP-XXXX |
KUBE-SVC-XXXX |
代表 Service 的一个 Endpoint(Pod),执行 DNAT 到具体 Pod IP |
KUBE-POSTROUTING |
POSTROUTING |
对出站流量做 SNAT(MASQUERADE) |
2. Service 流量转发示例(以 NodePort 为例)
场景:外部用户访问 NodeIP:NodePort
1. 数据包进入节点网卡
▼
2. PREROUTING 链 (nat 表)
▼
3. KUBE-SERVICES 链 (匹配目标端口为 NodePort)
▼
4. KUBE-NODEPORTS 链
▼
5. KUBE-SVC-XXX 链 (负载均衡选择 Pod)
▼
6. KUBE-SEP-YYY 链 (DNAT:将目标 IP:Port 替换为 PodIP:PodPort)
▼
7. 路由决策 → 若 Pod 在其他节点,进入 FORWARD 链
▼
8. POSTROUTING 链 (SNAT:MASQUERADE 修改源 IP 为节点 IP)
▼
9. 数据包发送到目标 Pod
3. 关键 iptables 规则示例
# 查看 NAT 表中 KUBE-SERVICES 链规则
iptables -t nat -L KUBE-SERVICES -n --line-numbers
# 输出示例:
Chain KUBE-SERVICES (2 references)
num target prot opt source destination
1 KUBE-SVC-ABC123 tcp -- 0.0.0.0/0 10.96.0.1 (ClusterIP) tcp dpt:80
2 KUBE-NODEPORTS all -- 0.0.0.0/0 0.0.0.0/0 /* 处理 NodePort 流量 */
四、K8S 中 iptables 的局限性
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 规则膨胀 | 大量 Service/Endpoint 导致规则数剧增 | 切换为 ipvs 模式 |
| 性能下降 | 线性匹配规则,时间复杂度 O(n) | ipvs 基于哈希表 (O(1)) |
| 调试困难 | 数千条规则难以人工阅读 | 使用 iptables-save 导出 |
💡 生产建议:
- 当 Service 超过 1000 个时,将
kube-proxy模式切换为ipvs(--proxy-mode=ipvs)。ipvs使用 Linux 内核的 LVS 框架,性能更高,支持更多调度算法(rr、lc 等)。
总结
- 四表:
nat(核心)、filter、mangle、raw - 五链:
PREROUTING(DNAT 入口)、INPUT、FORWARD、OUTPUT、POSTROUTING(SNAT 出口) - K8S 核心链:
KUBE-SERVICES→KUBE-SVC-XXX→KUBE-SEP-XXX(DNAT 到 Pod) - SNAT 位置:
POSTROUTING链的MASQUERADE规则
理解 iptables 四表五链,是诊断 Service 不通、网络性能问题的底层基础!
浙公网安备 33010602011771号