Pod：生命周期、探针与资源
Pod 将紧密协作的容器作为一个整体调度。本文负责组成、状态、探针、资源与终止过程。
1. 面试核心
先记住这几条，再读正文- 共享资源。 Pod 内容器共享网络空间，并可挂载同一卷。卡 · Pod 的组成
- 状态与故障表现。 CrashLoopBackOff 表示容器重启退避，Pending 是 Pod 阶段。卡 · 状态与排查
- 探针职责。 readiness 影响接流量，liveness 失败触发容器重启处理。卡 · 探针
- 资源调度与限制。 requests 参与调度，CPU limit 通过配额实施限流。卡 · 资源配置与 QoS
- 优雅终止。
preStop与应用退出共用终止宽限期。卡 · 优雅终止与流量排空
2. Pod 的组成
同一 Pod 的容器共用网络 Namespace。它们通过 localhost 通信，需避免监听端口冲突。共享卷可用于交换文件。容器根文件系统各自独立。
Pod 内各容器调度到同一节点。Linux 运行时可用 pause 容器维持沙箱。默认配置下，各容器使用独立的进程视图。shareProcessNamespace: true 才显式共享进程空间。
普通 init 容器按顺序执行，并成功结束。随后，业务容器启动。sidecar 则长期提供代理、日志等辅助能力。
Kubernetes 的原生 sidecar 声明在 initContainers 中，使用 restartPolicy: Always。kubelet 确认它已启动后，再处理后续 init 容器。配置 startupProbe 时，启动确认还依赖该探针。正常终止时，原生 sidecar 在业务容器之后停止。
3. 状态与排查
| Pod phase | 含义 |
|---|---|
| Pending | 已接受，部分容器尚未完成启动准备 |
| Running | 已绑定节点，容器已创建；至少一个在运行或启动重启中 |
| Succeeded | 所有容器成功结束，并且不再重启 |
| Failed | 所有容器结束，至少一个失败，并且不再重启 |
| Unknown | 无法取得 Pod 状态 |
kubectl get pod 的 STATUS 是展示信息。它还会显示容器等待原因及终止状态。
| 表现 | 重点证据 |
|---|---|
| 未调度 Pending | FailedScheduling、requests、约束与 PVC |
| ContainerCreating | 卷挂载、CNI 与镜像准备事件 |
| ImagePullBackOff | 镜像地址、凭据、网络与拉取事件 |
| CrashLoopBackOff | 上次退出原因、日志和探针事件 |
| OOMKilled | 内存限额、节点压力与内核 OOM 记录 |
| Terminating | preStop、存储卸载、finalizer 与节点状态 |
缺少必需 Secret 可阻止容器创建。程序读取配置后主动退出，则会进入重启流程。两者应按事件区分。
kubectl describe pod web
kubectl logs web -c app --previous
kubectl get events --sort-by=.lastTimestamp
describe 用于定位事件和上次容器状态。logs 的 --previous 读取上一个容器实例的日志。退出码 137 还需核对 OOMKilled 与终止记录。停止超时后的 SIGKILL 也能产生 137。
4. 探针
| 探针 | 失败达到阈值后的行为 |
|---|---|
| livenessProbe | kubelet 终止容器，再按重启策略处理 |
| readinessProbe | 标记未就绪，常规 Service 流量停止选用该端点 |
| startupProbe | 终止启动失败的容器，再按重启策略处理 |
startupProbe 成功前，另外两种探针暂缓执行。HTTP 探针接受 200—399 状态码。TCP 检查建连，exec 检查退出码 0。gRPC 探针检查健康服务响应。
startupProbe:
httpGet: {path: /healthz, port: 8080}
periodSeconds: 5
failureThreshold: 30
livenessProbe:
httpGet: {path: /healthz, port: 8080}
periodSeconds: 10
failureThreshold: 3
readinessProbe:
httpGet: {path: /ready, port: 8080}
periodSeconds: 5
示例为启动预留约 150 秒的探测预算。实际时点还受单次超时与探测调度影响。liveness 用于识别重启能恢复的本地故障。将共享数据库故障纳入 liveness，会触发连锁重启。
readiness 应反映当前实例能否处理请求。共享依赖检查也要考虑全部副本同时摘流量的后果。探针失败不会主动断开所有已有连接。
5. 资源配置与 QoS
以下使用容器级资源配置。
resources:
requests: {cpu: 500m, memory: 512Mi}
limits: {cpu: "1", memory: 1Gi}
调度器按 requests 计算资源需求。CPU 超过配额会限流。内存达到上限且回收不足时，内核可触发 OOM。具体 cgroup 机制见 容器原理。
| QoS | 容器级配置下的条件 |
|---|---|
| Guaranteed | 每个容器都配置 CPU、内存；各自 request 等于 limit |
| BestEffort | 所有容器都未配置 CPU、内存的 request 和 limit |
| Burstable | 其他配置 |
节点压力驱逐按所需回收的资源排序。主要依据是是否超过 requests、Priority 和超出量。QoS 只是部分资源配置的归类。磁盘或 inode 压力还需按对应资源处理。
kubectl drain 默认通过 Eviction API 驱逐。该路径遵守 PodDisruptionBudget。节点压力驱逐与节点故障不受 PDB 保护。
6. 调度约束与弹性伸缩
| 机制 | 含义 |
|---|---|
| nodeSelector、required 亲和 | 硬性筛选节点 |
| preferred 亲和 | 为满足偏好的节点评分 |
| NoSchedule 污点 | 拒绝缺少容忍的新调度 |
| PreferNoSchedule 污点 | 尽量避开缺少容忍的 Pod |
| NoExecute 污点 | 还可驱逐未容忍的已有 Pod |
| 反亲和、拓扑分布 | 约束副本在节点或可用区的分布 |
容忍只是通过污点检查。它不会保证 Pod 被调度到该节点。
HPA 根据指标调整副本数。基本计算为 ceil(当前副本数 × 当前指标 / 目标指标)。CPU 利用率目标以 requests 为分母。使用 CPU 绝对值目标时，计算口径不同。
控制器还处理缺失指标、未就绪副本和容差。缩容稳定窗口用于减少抖动。VPA 调整资源请求，Cluster Autoscaler 调整节点。应用扩容需与节点容量配合。
7. 优雅终止与流量排空
正常删除 Pod 后，终止宽限期开始计时。默认 terminationGracePeriodSeconds 为 30 秒。kubelet 先运行 preStop，再请求运行时发送停止信号。默认信号为 SIGTERM，镜像或配置可以覆盖。
preStop 耗时计入同一个宽限期。应用应停止接收新请求，并完成在途工作。宽限期结束后，剩余进程会被强制终止。
端点更新与本地停止流程并行推进。终止端点会标记为未就绪，规则传播需要时间。应用需留出传播时间，并处理已有连接。固定 sleep 只能提供等待窗口。它的时长应结合入口传播和请求耗时验证。
强制删除会先移除 API 对象。它无法确认失联节点上的进程已经停止。有状态业务还需隔离旧实例，避免重复执行。
8 · 面试题卡片
本页题目与参考回答
8.1 为什么 Kubernetes 的最小调度单位是 Pod 而不是容器？Pod 和容器是什么关系？
考察重点
- Pod 内容器共享的网络和存储；pause 容器的作用。
- 需要紧密协作的进程为什么要作为整体调度。
相关内容：Pod 的组成。
参考回答
Pod 把需要共享网络和卷的容器作为整体调度。
它们共用网络空间，通过 localhost 通信。业务容器和日志 sidecar 也可挂载同一卷。
Pod 内容器在同一节点运行，但各自管理进程生命周期。共享进程视图需额外配置。普通 init 容器先完成初始化。原生 sidecar 长期运行，并具有专门的停止顺序。Deployment 管理多个 Pod 副本。
8.2 Pod 有哪些状态？一个 Pod 一直 Pending 或反复 CrashLoopBackOff，你怎样排查？
考察重点
- Pod 阶段与容器状态原因的区别。
- 按 Pending、拉镜像、崩溃分类的排查命令和常见根因；退出码。
相关内容：状态与排查。
参考回答
Pod phase 有 Pending、Running、Succeeded、Failed、Unknown。
CrashLoopBackOff 是容器重启退避状态。
Pending 先查 kubectl describe pod。FailedScheduling 对应资源、污点、亲和性或卷约束。已调度时再查镜像、挂载和网络事件。缺少必需 Secret 会阻止容器创建。
CrashLoopBackOff 先查 kubectl logs --previous。再结合上次退出原因、探针和 OOM 记录。137 需要区分 OOM 与其他 SIGKILL 来源。根据证据修正配置、资源或启动行为。
8.3 Kubernetes 有哪三种探针？分别起什么作用，配置时要注意什么？
考察重点
- 三种探针失败后的不同动作。
- 存活探针不检查下游；启动探针保护慢启动应用；探针与节点健康的区别。
相关内容：探针。
参考回答
readiness 控制接流量，liveness 判断是否需要重启。
startup 为慢启动提供独立的探测预算。startup 成功前，另外两类探针暂缓执行。
liveness 失败达到阈值后，kubelet 终止容器。后续重启受 restartPolicy 约束。readiness 失败只改变就绪状态，已有连接仍需处理。
liveness 应检查重启能修复的本地故障。共享依赖故障放入该探针会造成连锁重启。超时和失败阈值应覆盖可接受的短暂抖动。
8.4 资源的 requests 和 limits 有什么区别？什么情况下 Pod 会被驱逐？污点、亲和性和 HPA 怎样使用？
考察重点
- requests 用于调度、limits 强制执行；CPU 与内存超限的不同后果；QoS 与驱逐顺序。
- 污点的三种效果、反亲和的用途；HPA 的计算方式和前提。
参考回答
requests 决定调度时的资源需求，limits 约束运行时用量；驱逐和扩缩容还要结合节点状态与调度规则。
- 资源与驱逐。 CPU 配额耗尽会限流，内存回收不足可触发 OOM。节点压力驱逐考虑是否超出
requests、Priority 和超出量，顺序并非固定的 QoS 排序。PDB 约束 Eviction API 发起的自愿驱逐，节点压力和故障仍可中断 Pod。 - 放置与扩容。 硬性亲和筛选节点，软性亲和影响评分；容忍只允许通过对应污点检查。HPA 调整副本数，CPU 利用率按
requests计算。节点容量不足时还需配合节点扩容。
8.5 preStop 是否另有 30 秒执行时间？删除 Pod 怎样减少请求失败？
考察重点：共享宽限期、端点传播和在途请求。
相关内容：优雅终止与流量排空。
参考回答
preStop 与应用退出共用终止宽限期。
默认总宽限期为 30 秒。端点更新与本地停止并行进行。应用需等待流量摘除传播，并完成在途请求。宽限期应覆盖这两段工作。强制删除还需防止旧实例继续运行。