kubernetes节点集群不能直接依赖firewalld默认规则，因k8s组件端口多、来源复杂，public区域会拦截kubelet健康检查、cni通信、etcd同步等关键流量；须按角色划分区域、精确放行端口、隔离非必要服务并永久生效。
Kubernetes 节点集群不能直接依赖 firewalld 默认规则，因为 K8s 组件通信端口多、来源复杂，且默认 public 区域会拦截关键流量（如 kubelet 健康检查、CNI 插件通信、etcd 同步等）。配置专属规则的核心是：按角色划分区域 + 精确放行端口 + 隔离非必要服务 + 永久生效。
以下为生产可用的配置逻辑和操作步骤：
明确节点角色并绑定对应 firewalld 区域
不要所有节点都用默认 public 区域。应根据职责分配预定义区域，并绑定网卡或源 IP：
-
Master 节点：建议使用
trusted区域（允许全部入站），但仅限内网接口；或新建自定义区域（如k8s-master）并严格限定来源 -
Worker 节点：推荐使用
internal区域，只对 master 和其他 worker 开放必要端口 -
边缘/暴露节点（如 Ingress Controller 所在节点）：用
public区域，但移除默认服务（如 dhcpv6-client），仅保留明确需要的端口
绑定方式示例（以 master 节点为例）：
sudo firewall-cmd --permanent --zone=internal --change-interface=ens192<br>sudo firewall-cmd --permanent --set-default-zone=internal<br>sudo firewall-cmd --reload
按 K8s 组件需求开放端口，不依赖服务名
firewalld 内置的 ssh、http 等服务名与 K8s 无关，且易引入冗余规则。应直接按协议+端口开放，避免模糊匹配：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
Master 必开端口：
6443/tcp（API Server）、2379-2380/tcp（etcd）、10250/tcp（kubelet API）、10259/tcp（kube-scheduler）、10257/tcp（kube-controller-manager） -
Worker 必开端口：
10250/tcp（kubelet）、10255/tcp（只读 kubelet 端口，可选）、30000-32767/tcp+udp（NodePort 范围，按需启用） -
CNI 插件相关：Flannel 需要
8472/udp（VXLAN）；Calico 需要179/tcp（BGP）；若用 hostNetwork 模式，还需确保容器宿主机端口可达
添加命令示例（永久生效）：
sudo firewall-cmd --permanent --zone=internal --add-port=6443/tcp<br>sudo firewall-cmd --permanent --zone=internal --add-port=10250/tcp<br>sudo firewall-cmd --permanent --zone=internal --add-port=8472/udp<br>sudo firewall-cmd --reload
禁用默认服务，关闭非必要入口
默认 public 区域自带 ssh 和 dhcpv6-client，后者完全无用且可能暴露 IPv6 探测面：
- 移除所有默认服务：
sudo firewall-cmd --remove-service=ssh --remove-service=dhcpv6-client（运行时） - 永久移除：
sudo firewall-cmd --permanent --remove-service=ssh --remove-service=dhcpv6-client - 禁用 ICMP 回显（防 ping 扫描）：
sudo firewall-cmd --permanent --icmp-block=echo-request - 确认无富规则残留：
sudo firewall-cmd --list-rich-rules，清空测试期遗留规则
验证规则是否生效且不影响 K8s 运行
配置后必须验证两点：规则已加载 + K8s 组件仍可通信：
- 检查当前区域和端口：
sudo firewall-cmd --list-all --zone=internal - 从另一节点 telnet 测试关键端口：
telnet 192.168.1.100 6443（master IP） - 确认 kubelet 可被访问：
curl -k https://192.168.1.100:10250/healthz - 检查 Pod 网络连通性：
kubectl get nodes应显示Ready，kubectl run test --image=busybox -- sleep 3600后 exec 进入 ping 其他节点 IP
若节点状态为 NotReady，请优先检查 10250 是否被拦截，而非怀疑 CNI 配置。
