Kubernetes节点防火墙策略需按角色精细开放端口：Master节点开放6443、2379–2380等，Worker节点开放10250及NodePort范围，并推荐用firewalld按区域（如trusted/public）管控流量，避免停用防火墙或清空iptables。
为 Kubernetes 节点配置防火墙策略，核心在于平衡安全性与通信需求：既不能完全放行带来风险，也不能过度拦截导致组件失联。实际做法取决于环境定位——测试环境可简化处理，生产环境必须精细管控。
明确节点角色与端口范围
Kubernetes 各组件依赖特定端口通信，需按角色区分开放：
-
Master 节点：必须开放
6443（API Server）、2379–2380（etcd 客户端/peer）、10251（kube-scheduler）、10252（kube-controller-manager）、10250（kubelet API）、10255（只读 kubelet 端口，可选） -
Worker 节点：至少开放
10250（供 master 调用）、30000–32767（NodePort 范围，若使用）；若启用 HostPort 或 CNI 插件（如 Flannel），还需确认其所需端口（如 Flannel 默认用8472/udp）
推荐使用 firewalld 进行区域化管理
相比直接清空 iptables，firewalld 更适合生产环境，支持按源 IP 划分信任等级：
- 将集群内网段（如
192.168.10.0/24）加入trusted区域，允许所有服务互通 - 对外暴露的服务（如 Ingress Controller）仅在
public区域开放对应端口（如80/tcp、443/tcp），禁用无关服务（如dhcpv6-client） - 执行示例：
sudo firewall-cmd --permanent --zone=trusted --add-source=192.168.10.0/24sudo firewall-cmd --permanent --zone=public --add-port=6443/tcpsudo firewall-cmd --reload
避免常见错误配置
以下操作看似“省事”，但在多数场景下不推荐：
- 直接
systemctl stop firewalld && systemctl disable firewalld—— 测试可行，但绕过安全基线，不符合生产规范 - 用
iptables -F清空规则 —— 可能误删 CNI 或 kube-proxy 设置的必要链，引发网络插件异常 - 仅开放端口却不指定 source 或 zone —— 默认 public 区域会拒绝非白名单流量，导致节点间心跳失败
验证与持续维护
配置后务必验证连通性：
- 从 worker ping master 的
6443端口：curl -vk https://<master-ip>:6443/healthz</master-ip> - 检查 kubelet 是否可被访问：
curl http://localhost:10255/pods（需确保该端口已按需开放） - 定期审查规则：
firewall-cmd --list-all-zones，确认无冗余或冲突策略
