先看 systemctl status kubelet 获取退出码和主进程信息，再用 journalctl -u kubelet --since "1 hour ago" -n 100 --no-pager 查最近日志；重点排查证书、cgroup驱动、容器运行时socket路径、SELinux及配置文件一致性问题。
安装 Kubernetes 时出错，90% 的问题能直接从系统日志里定位；但盲目 journalctl -u kubelet 或翻 /var/log/kubelet.log 往往白费时间——关键不是“看哪里”，而是“按什么顺序看、带什么上下文看”。
查 kubelet 启动失败：先看 systemd 单元状态，再追 journalctl 输出
安装后 kubelet 无法启动（systemctl status kubelet 显示 failed 或 activating (start) 卡住），不能直接跳进日志海。必须分两步：
- 运行
systemctl status kubelet，重点看最后一行的 “Process: XXX ExecStart=…” 和紧随其后的 “Main PID” 及退出码（如code=exited, status=255） - 用
journalctl -u kubelet --since "1 hour ago" -n 100查最近 100 行，加--no-pager避免分页干扰；若看到failed to run Kubelet: unable to load client CA file或failed to validate cluster CIDR，说明配置文件（/var/lib/kubelet/config.yaml）或证书路径有硬伤 - 常见陷阱：kubeadm init 后未执行
systemctl daemon-reload && systemctl restart kubelet，导致 kubelet 仍读旧配置；或 SELinux 处于 enforcing 模式却没配置策略，journalctl 里会出现avc: denied但被滚动刷走
查容器运行时不就绪：聚焦 cgroup 和 socket 路径错误
kubelet 日志中反复出现 failed to run Kubelet: failed to get docker info 或 failed to connect to containerd: failed to dial...，本质是运行时集成失败。这不是 kubelet 自身 bug，而是环境适配问题：
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 确认运行时 socket 路径是否匹配：containerd 默认用
/run/containerd/containerd.sock，但某些发行版（如 CentOS Stream 9）可能用/run/crio/crio.sock；检查kubelet启动参数里的--container-runtime-endpoint值（可通过ps aux | grep kubelet提取） - cgroup 驱动不一致会静默失败：kubelet 默认用
systemd，而 containerd 配置为cgroupfs，此时 journalctl 里只有一句failed to initialize top-level QoS containers，毫无指向性；必须核对/etc/containerd/config.toml中[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]下的SystemdCgroup = true - 若用 Docker，注意它在 2024 年后已不被 kubeadm 官方支持；即使强行启用，
docker info输出中若无Cgroup Driver: systemd字样，kubelet 必报错
查 kubeadm init 卡在 preflight 或 control-plane 环节：过滤 WARNING 和 [ERROR] 行
kubeadm init 卡住时，控制台只显示进度条，真正线索藏在 /var/log/kubelet.log 或 journalctl 的原始流里。别信 “waiting for the control plane to become ready” 这类提示：
- 用
journalctl -u kubelet -f | grep -E "(WARNING|ERROR|\[.*\])"实时过滤；高频错误包括：[ERROR FileAvailable--etc-kubernetes-manifests-kube-apiserver.yaml]（manifest 目录权限不对）、[ERROR Port-10250]（端口被占用）、[WARNING SystemVerification]（内核参数net.bridge.bridge-nf-call-iptables未启用） - pre-flight 检查失败不会写入 kubelet 日志，而是在
kubeadm init进程 stdout/stderr 中输出；若用脚本后台运行，务必加2>&1 | tee install.log捕获 - init 后 etcd 不起来？查
journalctl -u etcd（不是 kubelet！），常见原因是/var/lib/etcd目录属主不是etcd用户，或磁盘 inode 耗尽（journalctl 里会报write /var/lib/etcd/member/snap/db: no space left on device，但实际是 inodes 满）
查节点 NotReady：区分 kubelet 健康但 node condition 异常
安装完成后 kubectl get nodes 显示 NotReady，不代表 kubelet 挂了——它可能完全健康，只是没上报正确状态。此时 journalctl -u kubelet 里全是正常心跳日志，反而误导人：
- 先运行
kubectl describe node <node-name>，看Conditions区域：若Ready=False但KubeletReady=True，说明问题出在 CNI 插件（如 Calico、Cilium）未就绪，而非 kubelet 本身 - 检查 CNI pod 是否 Running：
kubectl get pods -n kube-system | grep -E "(calico|cilium|kube-flannel)"；若 Pending，大概率是镜像拉不到（kubectl describe pod看Events）或 RBAC 权限缺失（journalctl -u kubelet 里会有Forbidden请求记录） - 一个易忽略点：kubeadm init 时指定的
--pod-network-cidr必须和 CNI 插件配置严格一致；比如 Calico 要求192.168.0.0/16，你填了10.244.0.0/16，节点永远卡在NetworkUnavailable=True
最复杂的不是命令怎么写，而是日志里哪一行该信、哪一行是噪音——比如 kubelet 启动时大量 NodeStatusUpdateFrequency 日志是正常轮询，而同一行里混着的 failed to list *v1.Pod: Unauthorized 才是致命线索。盯日志时，永远先锁定错误关键词，再回溯前 3 行上下文，而不是从头滚屏。
