必须关闭节点防火墙，否则kubelet、kube-proxy与API Server通信将断连；需停用firewalld/ufw并清空iptables规则，验证firewall-cmd --state返回not running且iptables无残留链。
必须关掉节点上的防火墙，否则 kubelet、kube-proxy 和 API Server 之间的通信大概率会断连。这不是“建议”，而是多数发行版（CentOS/RHEL、Ubuntu with ufw、firewalld 启用时）下 Kubernetes 组件无法正常工作的直接原因。Kubernetes 自身不依赖主机防火墙做安全隔离，反而会被它拦死关键端口。
哪些端口会被防火墙拦住？
防火墙不会只拦一个端口，而是系统性阻断多个组件间通信链路：
-
6443：API Server 监听端口，kubelet、kubeadm join、kubectl全部依赖它；不放行会导致节点无法注册、命令超时或connection refused -
10250：kubelet 的 HTTPS 端口，kubectl logs、exec、port-forward全部走这里；被拦后表现为“部分 Pod 可操作，部分不可” -
30000–32767：NodePort 默认范围，Service 暴露到宿主机的端口；没开会导致外部访问 NodePort Service 失败 -
10256（kube-proxy 健康检查）、2379–2380（etcd 客户端/peer 端口）等也常被顺带拦截
别信“我只开了几个端口就够了”
手动开放端口看似精细，实则高风险且不可持续：
- 不同 Kubernetes 版本、CNI 插件（如 Calico、Cilium）、云厂商托管组件（如 Konnectivity）会动态使用新端口，硬编码规则很快失效
- iptables 规则和 firewalld/ufw 冲突很常见——比如
kube-proxy插入的 iptables 链被 firewalld 的 zone 规则覆盖，导致流量在进入 nat 表前就被 DROP - SELinux + firewalld 双启用时，
kube-proxy绑定端口可能被 AVC 拒绝，日志里只显示Permission denied，不查ausearch -m avc根本看不出是 SELinux 干的
关防火墙的实操判断标准
不是“执行 systemctl stop firewalld”就完事，得验证是否真正退出网络过滤：
- 对 firewalld：
sudo firewall-cmd --state必须返回not running，而非running；同时确认sudo iptables -L -n | head -5输出中没有firewalld相关链（如FWDI_public） - 对 ufw：
sudo ufw status必须显示Inactive；若显示Active，仅sudo ufw disable不够，还要sudo ufw reset清除残留规则 - 对 iptables（传统模式）：
sudo iptables -P INPUT ACCEPT和sudo iptables -P FORWARD ACCEPT是最低要求；但更稳妥的是清空所有规则：sudo iptables -F && sudo iptables -t nat -F
最易被忽略的一点：云环境节点（如 Azure VM、AWS EC2）即使本地防火墙关了，NSG 或安全组仍可能拦着 6443 和 10250。这时候 kubectl get nodes 显示 NotReady，但 systemctl status kubelet 看起来一切正常——问题不在节点上，而在云平台网络策略里。
