分三层看 kubelet
kubelet 出问题时，kubectl 能看到的只是结果（节点 NotReady、Pod 卡住），一手材料在节点上。排查分三层：服务状态，确认进程是否在运行、是否在反复重启；日志，用 journalctl 抓 kubelet 的报错与启动信息；配置来源，核对 config.yaml 与命令行启动参数是否一致，两者冲突时日志里通常有明确提示。三层对齐之后，绝大多数问题都能定位到具体配置项或系统依赖。
三层检查点
| 层 | 查看方式 | 能发现什么 |
|---|---|---|
| 服务状态 | systemctl status kubelet | 进程是否存在、最近是否重启、退出码 |
| 运行日志 | journalctl -u kubelet -n 100 | 配置解析错误、运行时连接失败、证书问题 |
| 配置来源 | ps -ef | grep kubelet 与 /var/lib/kubelet/config.yaml | 启动参数与配置文件是否冲突 |
| 系统依赖 | swap 状态、cgroup 驱动、容器运行时服务 | kubelet 之外的环境问题 |
典型使用场景
- 节点 NotReady：先确认 kubelet 是否在跑，再判断是配置问题还是网络与运行时问题
- 改配置不生效：核对改动是否落在实际被读取的文件上，以及是否需要重启
- 节点加入集群失败：日志里通常直接写明是认证、运行时还是系统配置问题
- cgroup 驱动不匹配：kubelet 与容器运行时驱动不一致时，节点起来后会持续报错
- 证书过期：日志出现 TLS 或证书相关错误，指向需要轮换的组件
三层检查命令
三层检查命令
systemctl is-active kubelet # 服务是否在运行
systemctl status kubelet --no-pager | head -20 # 最近一次退出与重启情况
journalctl -u kubelet -n 100 --no-pager # 最近日志
journalctl -u kubelet --since '10 min ago' | grep -iE 'failed|error' | tail -20
ps -ef | grep '[k]ubelet' # 实际启动参数
head -40 /var/lib/kubelet/config.yaml # 实际读取的配置文件常见日志线索
| 关键词 | 指向 | 处理方向 |
|---|---|---|
| failed to load kubelet config file | 配置文件路径或格式问题 | 核对配置路径与 yaml 语法 |
| cgroup driver does not match | 与容器运行时驱动不一致 | 统一为同一种驱动后重启 |
| failed to get node info / TLS | 与 apiserver 通信或证书异常 | 检查证书有效期与网络连通性 |
| swap is on | 未关闭交换分区 | 按集群要求关闭 swap |
| PLEG is not healthy | 运行时或容器状态同步异常 | 先查容器运行时服务状态 |
kubelet 的配置在启动时读取，改完 config.yaml 只做 reload 通常不生效，需要重启服务。重启前先确认节点上是否有正在进行的排水或维护动作，避免多个动作叠加。
启动参数与配置文件同时存在时，命令行参数往往优先，日志会提示某一项被覆盖。审计节点配置时应同时记录两者，只看文件会得出与线上不一致的结论。