iptables 防护 Kubernetes 节点心跳的关键是精准识别、严格限定、主动隔离，而非简单放行；心跳实际承载于 etcd（2380）、kubelet（10250）、控制面组件（10257/10259）等 TCP 通信中，需通过 INPUT/OUTPUT 链分别限制源IP、禁止泛洪、阻断非必要外发，并避免与 kube-proxy 或 CNI 规则冲突。
iptables 可以有效防护 Kubernetes 集群节点间的心跳流量，但关键不在于“放行心跳”，而在于**精准识别、严格限定、主动隔离**——因为心跳本身不是独立协议，而是由 kubelet、etcd、apiserver 等组件通过 TCP 连接维持的周期性通信，容易被误放或滥用。
明确心跳流量的真实载体
集群节点间心跳并非专用端口或协议，而是嵌套在以下核心组件通信中：
-
etcd 成员健康检查：使用
2380（peer 通信端口），节点间持续 TCP 连接 + HTTP/2 Keep-Alive 或 gRPC 心跳帧 -
kubelet 与 apiserver 的状态上报：通过
10250（kubelet HTTPS 端口）定期 POST/healthz和/stats/summary -
控制平面组件探活：如 scheduler/controller-manager 通过
10257/10259向 apiserver 发起 HTTP GET/healthz
INPUT 链：只允许可信源发起的心跳连接
禁止泛洪式探测，仅允许已知节点 IP 建立初始连接：
- 清空并设默认策略：
iptables -P INPUT DROP - 放行本机回环：
iptables -A INPUT -i lo -j ACCEPT - 放行 ESTABLISHED/RELATED 响应包（必需）：
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT - 仅限 etcd 集群成员访问 2380：
iptables -A INPUT -s 10.10.1.10/32 -p tcp --dport 2380 -j ACCEPT（逐个添加所有 peer IP） - 仅限 master 节点访问 kubelet 10250：
iptables -A INPUT -s 10.10.0.100/32 -p tcp --dport 10250 -m state --state NEW -j ACCEPT（避免用 0.0.0.0/0）
OUTPUT 链：阻断非必要主动心跳外发
防止节点被入侵后反向探测其他节点，或误配置导致心跳风暴：
- 设 OUTPUT 默认为 DROP：
iptables -P OUTPUT DROP - 仅允许本地回环：
iptables -A OUTPUT -o lo -j ACCEPT - 仅允许回应已有连接：
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -
禁止主动 DNS 查询（防域名劫持触发异常心跳）：
iptables -A OUTPUT -p udp --dport 53 -j REJECT（若需解析，白名单上游 DNS IP） -
禁止出向 ICMP（防 ping 扫描暴露拓扑）：
iptables -A OUTPUT -p icmp -j REJECT
避免与 kube-proxy 规则冲突
kube-proxy 的 iptables 模式会插入大量自定义链（如 KUBE-SERVICES），可能干扰节点间直连心跳：
- 确保心跳端口（如 2380、10250）不被 Service ClusterIP 或 NodePort 覆盖；etcd peer 通信必须走 hostNetwork 或静态 IP，不可走 ClusterIP
- 若使用 calico/cilium 等 CNI，确认其未启用“自动放行节点间流量”策略（如 calico 的
NodeToNodeMeshEnabled应设为 false） - 规则加载顺序很重要：手动 iptables 规则应在 kube-proxy 启动后执行，或使用
-I INPUT 1插入最前，确保优先匹配
