<p>iptables 是容器网络的底层执行引擎，负责数据包过滤与地址转换，Kubernetes 通过 kube-proxy 和 CNI 插件将其上层策略（Service/NetworkPolicy）动态翻译为 iptables 规则并维护；需避免手动干扰 KUBE-* 链，优先用 NetworkPolicy 和 CNI 自定义策略增强安全，结合系统级默认 DROP 与命名空间级 default-deny 实现零信任隔离。</p>
iptables 不是独立运行的防火墙，它和 Kubernetes 这类容器编排工具的网络组件深度协同——不是“谁管谁”，而是分工合作：iptables 负责底层数据包过滤与地址转换，Kubernetes 网络插件（如 Cilium、Calico）或 kube-proxy 负责把上层声明式策略（比如 Service、NetworkPolicy）翻译成 iptables 规则并动态维护。
iptables 是容器网络的底层执行引擎
Kubernetes 本身不直接操作网络设备，它依赖 CNI 插件和 kube-proxy 来落地网络行为。在 iptables 模式下：
- kube-proxy 会持续监听 Service 和 Endpoint 变化，自动生成并刷新 nat 表 中的规则链（如 KUBE-SERVICES、KUBE-SVC-*），实现 ClusterIP 和 NodePort 的流量转发
- CNI 插件（如 Calico）会在 filter 表 中插入 Pod 级别隔离规则，把 NetworkPolicy 的标签选择器转为具体 iptables -A INPUT/FORWARD 规则
- Cilium 则更进一步，在 eBPF 层替代部分 iptables 功能，但依然兼容并可回退到 iptables 模式，确保策略一致性
避免规则冲突的关键原则
手动添加的 iptables 规则如果位置不当，极易被 kube-proxy 或 CNI 覆盖或绕过。安全做法是：
- 把基础主机防护规则（如 SSH、ICMP、管理端口）放在 INPUT 链最前端，用 -I 而非 -A 插入，确保优先匹配
- 不要直接修改 kube-proxy 创建的 KUBE-* 链，它们由控制器自动管理；如需增强，应通过 NetworkPolicy 或 CNI 自定义策略实现
- 禁用 firewalld 或 ufw 等抽象层工具——它们与 kube-proxy 的 iptables 操作存在竞争，容易导致规则丢失或重复加载
命名空间级隔离靠双层策略配合
真正有效的隔离需要系统级与应用级策略叠加：
- 第一层：在节点操作系统上用 iptables 设置默认 DROP，仅开放必要管理端口（6443、2379、10250 等），堵住外部非法入口
- 第二层：在 Kubernetes 中为每个命名空间部署 default-deny NetworkPolicy，再按需放开 Pod 间通信（例如允许 ingress-nginx 访问 backend 命名空间）
- 两者不重叠也不替代——前者防外部越权访问节点，后者控内部服务间调用，共同构成零信任基础
可观测性与调试建议
当网络不通时，要分层排查：
- 先确认 iptables 规则是否生效：
iptables -L INPUT -n看基础策略，iptables -t nat -L -n | grep KUBE看 Service 转发链 - 再检查 NetworkPolicy 是否被正确翻译：
kubectl get networkpolicy -n <ns>+cilium policy get（若用 Cilium） - 最后验证连接路径：Pod → NodePort → iptables nat → Service → Endpoint → 目标 Pod，每跳都可能被某层规则拦截
