kubeadm init 卡在 [wait-control-plane] 阶段主因是 cri-dockerd/containerd 运行时未正确配置或 kubelet 服务未就绪；需检查 kubelet 状态、cgroup driver 一致性、containerd 是否启动，并确保 systemd 管理的 kubelet 已 active 且能响应本地 socket。
为什么 kubeadm init 卡在 [wait-control-plane] 阶段
绝大多数初学者卡在这一步，根本原因不是网络慢，而是 cri-dockerd 或 containerd 的镜像运行时未正确配置，或 kubelet 服务未就绪。kubeadm 默认依赖 systemd 管理的 kubelet，且要求其已启动、无报错、能响应本地 socket 请求。
实操建议：
- 先执行
sudo systemctl status kubelet，确认状态为 active (running)；若报failed to run Kubelet，常见是 cgroup driver 不匹配（containerd默认用systemd，而 kubelet 配置里写了cgroupfs） - 检查
/var/lib/kubelet/config.yaml中cgroupDriver值，必须与containerd的/etc/containerd/config.toml中[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]下的SystemdCgroup = true保持一致 - 执行
sudo crictl ps应返回空列表但不报错；若提示connection refused，说明containerd没启，或kubelet未指定正确的--container-runtime-endpoint - 跳过镜像拉取（仅测试）：加参数
--skip-phases=addon/coredns --image-repository registry.aliyuncs.com/google_containers，避免因国内网络卡在拉kube-apiserver镜像
初始化后 kubectl get nodes 显示 NotReady
NotReady 不等于失败，只是节点尚未通过 CNI 插件注册网络就绪状态。kubeadm init 完成后，kubelet 已注册节点，但 Pod 网络插件（如 Calico、Flannel）未部署，节点无法分配 IP、无法调度 Pod。
实操建议：
- 确认
kubectl get pods -A中coredns处于Pending状态 —— 这是典型 CNI 缺失信号 - Calico 安装必须严格匹配 Kubernetes 版本：
kubectl apply -f https://docs.projectcalico.org/v3.25/manifests/calico.yaml中的v3.25要根据你kubeadm version输出的 k8s 小版本（如 1.27.x → 用 v3.26）查对应文档 - Flannel 注意修改
net-conf.json中的Network字段，需与kubeadm init --pod-network-cidr参数值完全一致（例如都用10.244.0.0/16） - 部署后等 30 秒再查
kubectl get nodes，Calico 的calico-nodeDaemonSet 启动需要时间；若仍 NotReady，看kubectl describe node <name></name>中 Events 是否有NetworkPluginNotReady或FailedCreatePodSandBox
worker 节点 kubeadm join 报错 couldn't validate the identity of the API Server
这不是证书过期，而是 control-plane 节点上的 kubeadm init 生成的 token 过期（默认 24 小时），或 worker 节点时间与 master 相差超过 1 分钟（TLS 双向校验对时间敏感）。
一款AI工具，主要用于管理 OpenClaw 所使用的来自 OpenRouter 的免费 AI 模型。自动按质量对模型进行排序，配置回退机制以应对速率限制，并更新 opencla...，适合需要提升相关任务效率的用户。
实操建议：
- 在 master 上重新生成 token：
kubeadm token create --print-join-command，该命令输出的就是可直接复制执行的完整kubeadm join命令 - 检查所有节点是否启用 NTP 同步：
timedatectl status | grep "System clock synchronized"，应为 yes；若否，运行sudo timedatectl set-ntp true - 确保 worker 节点能访问 master 的 6443 端口：
nc -v <master-ip> 6443</master-ip>；若不通，检查防火墙（ufw或firewalld）是否放行，或云平台安全组规则 - 如果使用私有 CA 或自定义证书，
kubeadm join必须带上--certificate-key和--control-plane（仅用于新增 control-plane 节点），普通 worker 不需要后者
集群部署后 DNS 解析失败（nslookup kubernetes.default 超时）
DNS 失败几乎全是 CoreDNS Pod 异常或 Service ClusterIP 冲突导致，和 /etc/resolv.conf 无关。CoreDNS 依赖 kube-system namespace 下的 kube-dns Service（ClusterIP 类型），而该 Service 的 endpoints 必须指向正常运行的 CoreDNS Pod。
实操建议：
- 先确认
kubectl get svc -n kube-system kube-dns存在且CLUSTER-IP非None；再查kubectl get endpoints -n kube-system kube-dns，SUBSETS 应有 IP+端口，否则 CoreDNS Pod 未就绪 - 检查 CoreDNS Pod 日志：
kubectl logs -n kube-system deployment/coredns -c coredns；常见错误是日志里出现plugin/errors或反复打印ready: false，说明它连不上 kube-apiserver - 验证 apiserver 是否可访问：进任意 Pod（如 busybox），执行
curl -k https://10.96.0.1:443/healthz（10.96.0.1 是kube-dnsService 的 ClusterIP，也是kube-apiserver的默认 Service 地址）；若超时，说明 Service 网络不通，大概率是 CNI 插件没跑起来或配置错 CIDR - CoreDNS 的 ConfigMap 中
forward . /etc/resolv.conf行不能删 —— 它负责把外部域名转发给宿主机 DNS，删了会导致访问 google.com 失败，但不影响集群内服务发现
真正麻烦的从来不是命令敲几遍，而是每个组件对 cgroup driver、时间同步、CIDR 对齐、证书时效这些隐性契约的强依赖。漏掉一个，kubectl 就只会冷冷地返回 NotReady 或 Connection refused，不会告诉你少配了哪一行。
