2. Kubernetes 核心概念回顾:Pod、Deployment、ReplicaSet、Node、kubelet
在深入排查 Deployment 镜像拉取失败 问题之前,必须牢固掌握 Kubernetes 集群中最核心的五个概念。它们是故障定位的“坐标系”——只有理解每个组件的职责与交互关系,才能准确判断资源瓶颈发生在哪一层。
2.1 概念速览与职责对比
下表从抽象层级、调度单位、生命周期三个维度对比五个核心对象,帮助你快速建立全局认知:
| 概念 | 所属层级 | 核心职责 | 是否直接运行容器 | 故障排查关注点 |
|---|---|---|---|---|
| Pod | 工作负载 | 最小调度单元,封装一个或多个容器 | 是 | 容器状态、镜像拉取、资源限制 |
| ReplicaSet | 工作负载 | 确保指定数量的 Pod 副本始终运行 | 否 | 副本数偏差、Pod 创建失败原因 |
| Deployment | 工作负载 | 声明式更新 Pod 和 ReplicaSet,支持滚动更新 | 否 | 更新策略、镜像版本、回滚状态 |
| Node | 基础设施 | 集群中的工作节点,提供计算/存储/网络资源 | 否 | 资源水位、磁盘空间、kubelet 健康 |
| kubelet | 节点代理 | 负责 Pod 生命周期管理,与容器运行时交互 | 否 | 日志、镜像拉取错误、PLEG 问题 |
排查口诀: Deployment 定版本 → ReplicaSet 保数量 → Pod 是容器载体 → Node 提供资源 → kubelet 执行拉取。镜像拉取失败时,kubelet 日志和Pod 事件是第一现场。
2.2 核心概念关系图
下图展示了从用户请求到容器运行的完整链路,以及各组件之间的依赖关系:
2.3 各概念深度解析
2.3.1 Pod —— 最小调度单元
- 定义:Pod 是 Kubernetes 中创建和管理的最小计算单元,一个 Pod 可以包含一个或多个紧密耦合的容器(共享网络栈和存储卷)。
- 镜像拉取相关:Pod 的
spec.containers[].image字段指定了容器镜像。kubelet 在调度 Pod 到 Node 后,负责拉取这些镜像。 - 状态机:Pod 状态包括
Pending(等待调度或拉取镜像)、Running、Failed、ImagePullBackOff(镜像拉取失败后的重试状态)。
排查要点: 当镜像拉取失败时,Pod 会进入
ImagePullBackOff 或 ErrImagePull 状态。使用 kubectl describe pod <pod-name> 查看 Events 字段,可以获取具体的失败原因(如 401 认证失败、404 镜像不存在、磁盘空间不足)。
2.3.2 ReplicaSet —— 副本保障机制
- 定义:ReplicaSet 确保指定数量的 Pod 副本在任何时间点都处于运行状态。如果 Pod 因故障退出或被删除,ReplicaSet 会创建新的 Pod 来替代。
- 与 Deployment 的关系:Deployment 是更高级的抽象,它管理 ReplicaSet 的创建、更新和回滚。每个 Deployment 版本对应一个 ReplicaSet。
- 镜像拉取影响:如果 ReplicaSet 无法创建足够数量的 Pod(例如镜像拉取失败),它会持续重试,直到达到期望副本数或用户介入。
2.3.3 Deployment —— 声明式更新引擎
- 定义:Deployment 为 Pod 和 ReplicaSet 提供声明式更新能力。你只需描述期望状态(如镜像版本、副本数),Deployment 控制器会逐步将实际状态调整到期望状态。
- 滚动更新策略:更新镜像时,Deployment 会创建新 ReplicaSet,逐步增加新 Pod 并缩减旧 Pod。如果新 Pod 因镜像拉取失败无法启动,滚动更新会暂停或回滚。
- 回滚机制:Deployment 保留历史版本记录,当新版本镜像拉取失败时,可以快速回滚到上一个稳定版本。
# 查看 Deployment 的滚动更新状态
kubectl rollout status deployment/<deployment-name>
# 查看 Deployment 历史版本
kubectl rollout history deployment/<deployment-name>
# 回滚到上一个版本
kubectl rollout undo deployment/<deployment-name>
2.3.4 Node —— 资源提供者
- 定义:Node 是 Kubernetes 集群中的工作节点,可以是物理机或虚拟机。它提供 CPU、内存、磁盘、网络等资源供 Pod 使用。
- 资源瓶颈与镜像拉取:镜像拉取失败有时并非镜像本身问题,而是 Node 资源不足:
- 磁盘空间不足:镜像需要解压到本地磁盘,如果
/var/lib/docker或容器运行时数据目录已满,拉取会失败。 - inode 耗尽:大量小文件导致文件系统 inode 耗尽,无法创建新文件。
- 网络带宽限制:大镜像在带宽受限时可能超时。
- 磁盘空间不足:镜像需要解压到本地磁盘,如果
常见误区:很多工程师只检查镜像仓库是否可达,却忽略了 Node 本地磁盘空间。使用
df -h 和 df -i 检查磁盘和 inode 使用率,是排查镜像拉取失败的第一步。
2.3.5 kubelet —— 节点上的“管家”
- 定义:kubelet 是运行在每个 Node 上的主要代理进程。它负责:
- 接收来自 API Server 的 Pod 定义。
- 调用容器运行时(如 Docker、containerd)拉取镜像、启动容器。
- 定期向 API Server 上报 Node 和 Pod 状态。
- 镜像拉取执行者:kubelet 是实际执行
docker pull或crictl pull的组件。所有镜像拉取错误都会记录在 kubelet 日志中。 - PLEG(Pod Lifecycle Event Generator)问题:当 kubelet 与容器运行时通信异常时,可能导致 Pod 状态更新延迟或镜像拉取卡住。
# 查看 kubelet 日志(journald 系统)
journalctl -u kubelet -f --no-pager | grep -i "image"
# 查看 kubelet 日志(文件方式)
tail -f /var/log/kubelet.log | grep -i "pull"
2.4 镜像拉取失败时的排查链路图
下图展示了从 Deployment 下发到 kubelet 执行拉取的完整链路,以及每个环节可能的故障点:
2.5 关键命令速查表
| 排查目标 | 命令 | 输出关键字段 |
|---|---|---|
| 查看 Deployment 状态 | kubectl get deployment <name> -o wide |
READY、UP-TO-DATE、AVAILABLE |
| 查看 ReplicaSet 状态 | kubectl get replicaset <name> -o wide |
DESIRED、CURRENT、READY |
| 查看 Pod 事件 | kubectl describe pod <name> |
Events 中的 Reason 和 Message |
| 查看 Node 资源 | kubectl describe node <node-name> |
Conditions、Allocated resources |
| 查看 kubelet 日志 | journalctl -u kubelet -f |
镜像拉取相关的 error/warning |
学习建议:在实验环境中,手动创建一个镜像名称错误的 Deployment(如
nginx:notexist),然后依次使用上述命令观察 Pod 状态变化和 kubelet 日志输出。这种“破坏性练习”能帮助你快速建立故障模式记忆。