快速验证 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 看起来正常。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
实操建议：
- 先查 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-nodepod 的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 写得漂不漂亮重要得多。
