工作节点加入集群前必须满足4个前提条件：时间同步、关闭swap、加载br_netfilter和overlay内核模块、网络互通；漏掉任一将导致notready或join报错。
工作节点加入集群前必须满足的 4 个前提条件
不是执行 kubeadm join 就能成功加入——漏掉任一条件都会卡在 NotReady 或直接报错。常见失败现象包括：节点出现在 kubectl get nodes 列表里但状态一直是 NotReady，或 kubeadm join 执行后提示 connection refused、certificate signed by unknown authority。
- 所有节点时间同步（
systemctl status chronyd或timedatectl status必须显示 synchronized） - 关闭 swap：
swapoff -a+ 注释/etc/fstab中 swap 行（否则kubelet拒绝启动） - 内核模块加载：确保
br_netfilter和overlay已加载（lsmod | grep -E "br_netfilter|overlay"应有输出） - 网络互通：工作节点能
ping通 master 的--apiserver-advertise-address地址，且能访问6443/tcp端口（用nc -vz <master-ip> 6443</master-ip>验证）
kubeadm join 命令必须带 --control-plane 才能加 Master 节点？
不。加普通工作节点（Worker）时，kubeadm join 命令绝对不能加 --control-plane 参数——那是给新增 Master 节点用的。加了反而会触发控制平面初始化流程，导致 kubelet 启动失败或证书冲突。
正确做法是：在 master 上运行 kubeadm token create --print-join-command 获取原始命令，它默认不含 --control-plane；若 token 过期（默认 24 小时），就重新生成一个新 token 再取命令。
示例输出：
kubeadm join 192.168.1.236:6443 --token abcdef.0123456789abcdef \
--discovery-token-ca-cert-hash sha256:1a2b3c...
注意：如果 master 初始化时用了 --image-repository（如阿里云镜像源），新节点也需提前配置好相同镜像源，否则拉取 pause 镜像失败，kubelet 会反复 crashloop。
为什么新节点始终卡在 NotReady，但 pod 网络插件已装好？
因为 kubelet 启动后需要先通过 CNI 插件分配 IP 并注册自身状态，而多数 CNI（如 Flannel、Calico）只在 master 节点部署 DaemonSet，不会自动下发到新加入的工作节点——除非该插件的 manifest 明确设置了 nodeSelector 或 tolerations 允许调度到所有节点。
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
排查步骤：
- 在新节点上执行
sudo journalctl -u kubelet -n 100 --no-pager，重点看是否有"Failed to run IPAM"、"CNI plugin not found" - 检查
/etc/cni/net.d/是否存在配置文件（如10-flannel.conflist），内容是否与 master 一致 - 确认
/opt/cni/bin/下有对应二进制（如flannel、calico），缺失则需手动复制或重装插件
Flannel 用户可快速修复：在 master 上运行 kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml，它默认支持全部节点。
批量加入多个工作节点时最容易忽略的兼容性细节
不同节点操作系统或内核版本差异，会导致 kubelet 启动后无法注册进集群，尤其在混合 CentOS 7 / Debian 12 / Rocky 9 环境中。
关键点：
-
kubeadm和kubelet版本必须严格一致（kubeadm version与kubelet --version输出完全相同），否则join可能静默失败 - containerd 用户需确认
/etc/containerd/config.toml中SystemdCgroup = true已启用（CentOS/Rocky 默认 false，Debian 默认 true） - SELinux 启用时（如 CentOS），需确保
containerd或docker进程有足够策略，否则 CNI 插件调用失败
最稳妥的做法：所有节点用同一份安装脚本初始化，而不是逐条复制命令——尤其是 modprobe 加载顺序、sysctl 参数写入、containerd 配置生成这几步，手敲极易遗漏。
