Linux Kubernetes 集群部署实战

快速验证 kubeadm init 失败是否因 cgroup 驱动不一致：先查 containerd 配置 containerd config dump | grep -a 5 ‘systemdcgroup’ 是否为 true，再查 kubelet 实际驱动 ps aux | grep kubelet | grep -o ‘cgroup-driver=[^ ]*’，两者不一致即为根因。

怎么快速验证 kubeadm init 失败是不是因为 cgroup 驱动不一致

绝大多数初始化卡在 [wait-control-plane] Waiting for the kubelet to boot up the control plane 或直接报错 failed to run Kubelet: failed to create kubelet: misconfiguration: cgroup driver: "systemd" is not supported，本质是容器运行时（如 containerd）和 kubelet 使用的 cgroup 驱动不匹配。

实操建议：

• 查 containerd 当前配置：containerd config dump | grep -A 5 'SystemdCgroup'，看是否为 true
• 查 kubelet 实际使用的驱动：ps aux | grep kubelet | grep -o 'cgroup-driver=[^ ]*'，常见值是 cgroup-driver=systemd 或 cgroup-driver=cgroupfs
• 若不一致，改 containerd：编辑 /etc/containerd/config.toml，确保 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] 下有 SystemdCgroup = true（对应 kubelet 的 systemd），然后 sudo systemctl restart containerd
• 别手动改 kubelet 参数去迁就 containerd —— 容器运行时驱动应由 runtime 自身决定，kubelet 要对齐它

为什么 kubeadm join 总提示 x509: certificate signed by unknown authority

这不是证书过期，而是 node 上的 kubelet 尝试连接 master 的 API Server 时，无法验证其 TLS 证书链 —— 根因通常是 control-plane 节点没把 CA 证书正确分发给 worker，或 kubeadm join 命令里漏了 --certificate-key（v1.15+ 默认需要）。

实操建议：

• 在 control-plane 节点上，用 kubeadm Token create --print-join-command 生成完整命令，别自己拼 kubeadm join ... --token ...
• 如果 token 过期（默认 24h），重新生成：kubeadm token create --ttl 2h，再配 --certificate-key（需先 kubeadm init phase upload-certs --upload-certs）
• worker 节点执行前，确认 /etc/kubernetes/pki/ca.crt 存在且内容与 master 一致；不一致就手动同步（scp 或 base64 粘贴）
• 别用 curl -k 绕过校验 —— 这会让 kubelet 启动失败，因为内部组件通信仍依赖合法证书

kubectl get nodes 显示 NotReady 但 pod 全是 Running，怎么办

Node 状态是 kubelet 上报的，NotReady 表示 kubelet 没能完成自检（比如网络插件没就绪、cni 配置缺失、disk pressure），但控制平面已调度完 pod，所以 kubectl get pods 看起来正常。

实操建议：

• 先查 kubelet 日志：journalctl -u kubelet -n 100 --no-pager | grep -i -E "(cni|network|ready|status)"
• 检查 CNI 插件是否部署成功：ls /etc/cni/net.d/ 应有非空配置文件（如 10-flannel.conflist），且 crictl ps | grep cni 能看到对应容器
• 确认 /var/lib/cni 目录权限是 root:root，非 root 用户写入会失败（尤其用 ansible 批量部署时容易 chown 错）
• Flannel 场景下，检查 ip link show flannel.1 是否存在；Calico 则看 calico-node pod 的 READY 列是否为 1/1

集群跑了一阵后 kubectl apply 变慢甚至超时，etcd 成瓶颈怎么看

不是网络问题，也不是 API Server 崩溃，而是 etcd 写入延迟升高导致请求排队 —— 常见于未调优的单节点 etcd、磁盘 I/O 拥塞、或 key 数量过多（比如大量 job/horizontalpodautoscaler 对象没清理）。

实操建议：

• 直连 etcd 查健康：ETCDCTL_API=3 etcdctl --endpoints https://127.0.0.1:2379 --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key endpoint health
• 看写入延迟：etcdctl --write-out=table endpoint status，重点关注 RTT 和 IsLeader 列；RTT > 100ms 就危险
• 检查碎片率：etcdctl --write-out=table endpoint status | grep -i 'db size|fragment'，>10% 就该 compact + defrag（先 etcdctl compact，再 etcdctl defrag）
• 别在生产集群用 etcdctl snapshot save 期间做高并发写入 —— 快照会阻塞写操作，加剧延迟

etcd 不是黑盒，它的延迟会直接传导到所有 kubectl 操作。哪怕只是加个 label，背后也是 etcd 的一次原子写。磁盘选 SATA 还是 NVMe，日志刷盘策略怎么设，这些细节比 YAML 写得漂不漂亮重要得多。