K8S系列 之 重温iptables

薛之谦： 学 iptables 有什么用？

Linux 网络核心之一 ，不学你不明白流量咋走的，遇到问题就蒙

Linux 网络技术栈分层

从数据包进入网卡到应用层的路径：

物理层：网卡驱动（eth0）。

数据链路层：MAC 地址、VLAN（bridge、veth）。

网络层：IP 路由（route -n）、iptables/nftables（PREROUTING）。

传输层：TCP/UDP，conntrack（据说ipvs直接搞这个弄了个内核哈希表，快是快，但是使用了ipvs，networkpolicy还是要依赖iptables） 。

应用层：Socket（如 kube-proxy 监听 Service）。

对应常用命令：

tcpdump -i eth0 port 80      # 抓包
ip route show                # 路由表
conntrack -L                 # 连接跟踪
iptables -t nat -L -v        # 查看 NAT 规则

iptables/nftables 是 Linux 网络栈的"防火墙+路由器"：

流量过滤（安全组、NetworkPolicy）。

NAT（Service 的 ClusterIP/NodePort）。

流量整形（QoS）。

对比一下常用的iptables（貌似还有个uftables 没用过） vs ipvs：

简单来说一个是线性一条一条规则，通过NAT 间接操作conntrack；一个是哈斯表，直接操作conntrack。
（1）iptables

• 有五链四表 ：
  • 四表 ：raw、mangle、nat、filter。
  • 五链 ：PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING。
• 规则粒度细：每条规则独立处理，适合复杂策略（如 NetworkPolicy）。

（2）ipvs（IP Virtual Server）

• 没有五链四表 ！
  • ipvs 是 L4 负载均衡器 （基于内核的哈希表），直接操作连接跟踪（conntrack）。
  • 只有三种负载均衡模式 ：NAT、DR（Direct Routing）、TUN（IP Tunneling）。
• 性能更高：规则数量对性能影响小，适合大规模 Service。

注意：1 ipvs 只负责 Service 负载均衡：

处理 ClusterIP/NodePort 的流量转发（L4）。

不涉及 NetworkPolicy 的 L3/L4 规则。

2 NetworkPolicy 由 CNI 插件实现：

插件（如 Calico、Cilium）会在 iptables/nftables 中插入规则，控制 Pod 流量。

例如，拒绝从 Pod A 到 Pod B 的流量，规则会加在 FORWARD 链或 Pod 的 veth 设备上。

具体故障举例

例如 Service 不通时，能否快速定位是 iptables 规则缺失还是路由问题。

** 复习一下 Linux 网络技术栈分层**

从数据包进入网卡到应用层的路径：

1. 物理层 ：网卡驱动（eth0）。
2. 数据链路层 ：MAC 地址、VLAN（bridge、veth）。
3. 网络层 ：IP 路由（route -n）、iptables/nftables（PREROUTING）。
4. 传输层 ：TCP/UDP，conntrack 跟踪连接。
5. 应用层 ：Socket（如 kube-proxy 监听 Service）。

对应分层命令：

tcpdump -i eth0 port 80      # 抓包
ip route show                # 路由表
conntrack -L                 # 连接跟踪
iptables -t nat -L -v        # 查看 NAT 规则

---

来演一个小故障：某K8S Service 无法访问

现象

curl http://10.96.0.1:80（ClusterIP）超时，但 Pod 直接访问正常。

思路

先看看 pod是否正常，proxy是否正常工作，再一层一层往上面找 L3/L4 规则

排查步骤

1. 检查 Service 和 Endpoint：

   kubectl get svc kubernetes -o yaml  # 确认 ClusterIP 和端口
   kubectl get ep kubernetes           # 确认后端 Pod 是否健康

2. 检查 iptables 规则：

   sudo iptables -t nat -L KUBE-SERVICES | grep 10.96.0.1

   • 若无规则 ：kube-proxy 未正常工作（检查日志 journalctl -u kube-proxy）。

   • 有规则但丢包 ：进一步检查：

     sudo iptables -t nat -L KUBE-SVC-XXX  # 查看具体链的规则

3. 验证数据包路径：

   • 在目标节点抓包：

     sudo tcpdump -i any host 10.96.0.1 -nn

   • 若无流量 ：可能是 FORWARD 链被丢弃（检查 iptables -L FORWARD）。

4. 根本原因：

   • bridge-nf-call-iptables=0 ：桥接流量未经过 iptables，导致 Service 规则失效。

   • 修复 ：

     echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables

涉及原理

• PREROUTING 链 ：将 ClusterIP DNAT 到 Pod IP。
• FORWARD 链 ：允许跨节点 Pod 流量（需 ip_forward=1）。

---

总结

技术	作用	故障案例中的角色
iptables	NAT/过滤	Service 规则丢失导致 ClusterIP 不通
ipvs	高性能负载均衡	替代 iptables 提升性能
conntrack	跟踪连接状态	确保 NAT 前后包匹配
bridge	管理 Pod 网络（cni0）	桥接流量需经 iptables（否则丢包）

扩展 ：

iptables并非无法替代的 ，eBPF （）。

对比一下：calico和ciliumcalico和cilium简单对比