工作负载：Deployment、StatefulSet、DaemonSet、Job - 面试题

#

★★★

1. Deployment RollingUpdate 的 maxSurge/maxUnavailable 配置与发布中断排查中资源不足导致 Pod 卡 Pending 及 progressDeadlineSeconds

问题

Deployment RollingUpdate 的 maxSurge/maxUnavailable 如何配置？发布中断（如资源不足导致 Pod 卡 Pending）如何排查？progressDeadlineSeconds 的作用？

考察点

maxSurge/maxUnavailable 语义
滚动更新的可用性保障
卡 Pending 的排查

答案

maxUnavailable 表示滚动更新过程中最多允许不可用的副本数（相对期望副本的百分比或整数），保证可用副本数不低于期望-maxUnavailable；maxSurge 表示最多允许超出期望副本数的额外副本数，保证新增副本数不超过期望+maxSurge。K8s 在保证两者前提下滚动替换 Pod。若资源不足，新 Pod 卡 Pending，旧 Pod 无法被替换，发布停滞。排查：看 Pod 事件（Unschedulable、Insufficient cpu/memory）、节点资源。progressDeadlineSeconds 定义滚动更新必须在指定时间内完成（10 分钟），超时则 Deployment 标记为 Progressing=False 并触发 rollout 失败状态，可 kubectl rollout status 查看。

解析

核心是"maxSurge/maxUnavailable 控制流速与可用性"。发布中断时先看事件与资源，progressDeadlineSeconds 用于检测卡住。

示例代码

apiVersion: apps/v1
kind: Deployment
metadata: { name: app }
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  progressDeadlineSeconds: 600

#

★★★

2. PodDisruptionBudget（PDB）如何界定自愿中断与非自愿中断，即 minAvailable 与 maxUnavailable 的语义、kubectl drain 与集群自动扩缩容如何受 PDB 约束以及为何节点宕机等非自愿中断无法被 PDB 阻止？

问题

PodDisruptionBudget（PDB）如何界定自愿中断与非自愿中断？minAvailable 与 maxUnavailable 的语义，kubectl drain 与自动扩缩容如何受 PDB 约束，为何非自愿中断无法阻止？

考察点

自愿中断（voluntary）与非自愿中断（involuntary）
minAvailable 与 maxUnavailable
drain 与 PDB 的交互

答案

自愿中断（voluntary）是运维主动发起的，如 kubectl drain、节点升级、集群缩容、主动删除；非自愿中断（involuntary）是硬件故障、节点宕机、OOM 等不可控事件。PDB 只约束自愿中断：当执行 drain/缩容时，控制器会检查 PDB，若驱逐后可用副本数低于 minAvailable（或不可用超过 maxUnavailable）则拒绝驱逐，等待。minAvailable 保证至少可用副本数，maxUnavailable 保证最多不可用副本数。节点宕机等非自愿中断无法被 PDB 阻止，因为 Pod 已物理失效，PDB 只能事后靠控制器重建，无法阻止中断发生。

解析

核心是"PDB 只约束自愿中断 + 保证可用副本下限"。drain 与缩容受 PDB 约束，硬件故障不受。

示例代码

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: { name: app-pdb }
spec:
  minAvailable: 2
  selector:
    matchLabels: { app: api }

#

★★★

3. StatefulSet Pod 卡 Pending/删除重建的故障场景中 PVC 绑定失败、节点亲和冲突、volumeClaimTemplates 与 StorageClass 延迟绑定

问题

StatefulSet Pod 卡 Pending 或删除重建的故障场景有哪些？PVC 绑定失败、节点亲和冲突、volumeClaimTemplates 与延迟绑定如何影响？

考察点

PVC 绑定失败的场景
节点亲和冲突
volumeClaimTemplates 与 WaitForFirstConsumer

答案

StatefulSet 卡 Pending 常见原因：1）PVC 无法绑定（StorageClass 不存在、动态供给失败、无匹配 PV），Pod 等待 PVC Bound；2）volumeClaimTemplates 创建的 PVC 绑定到节点，但节点亲和（nodeAffinity）冲突导致 Pod 无法调度到有数据的节点；3）StorageClass 用 WaitForFirstConsumer 延迟绑定，Pod 需先调度才能绑定 PVC，若调度失败则卡住。删除重建时若 PVC 未删除，数据保留但 Pod 可能因旧 PVC 绑定到已消失节点而无法重启。排查：kubectl describe pod、kubectl get pvc 看状态（Pending/Bound）、kubectl get pv 看绑定。

解析

核心是"StatefulSet 依赖 PVC 的绑定与节点亲和"。排查重点在 PVC 状态与调度约束。

示例代码

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata: { name: fast }
provisioner: example.com/provider
volumeBindingMode: WaitForFirstConsumer

#

★★★

4. StatefulSet 如何通过 headless Service 为副本提供稳定网络标识？

问题

StatefulSet 如何通过 headless Service 为副本提供稳定网络标识？

考察点

headless Service 与稳定 DNS
稳定网络标识（pod 名称、序号）
应用场景

答案

StatefulSet 需要 headless Service（clusterIP: None）来提供稳定网络标识。每个副本的 Pod 名称为 {statefulset-name}-{ordinal}（如 web-0、web-1），headless Service 为每个 Pod 生成稳定的 DNS 记录：{pod-name}.{svc-name}.{namespace}.svc.cluster.local。这样即使 Pod 重建（IP 变化），其 DNS 名称仍指向同名 Pod，实现稳定的网络身份。应用通过该 DNS 访问具体副本，用于集群内节点发现、主从配置等。

解析

核心是"Pod 名 + headless DNS 的稳定标识"。Pod 重建后名称不变，DNS 不变，网络身份稳定。

示例代码

apiVersion: v1
kind: Service
metadata: { name: web }
spec:
  clusterIP: None
  selector: { app: web }
---
apiVersion: apps/v1
kind: StatefulSet
metadata: { name: web }
spec:
  serviceName: web
  replicas: 3
  selector: { matchLabels: { app: web } }

#

★★★

5. StatefulSet 的 minReadySeconds 如何配合就绪探针控制滚动更新节奏？

问题

StatefulSet 的 minReadySeconds 如何配合就绪探针控制滚动更新节奏？

考察点

minReadySeconds 含义
与就绪探针配合
滚动更新节奏

答案

minReadySeconds 指定 Pod 达到就绪状态后需保持就绪多少秒才被认为"就绪可用"，用于避免 Pod 刚启动短暂就绪就被当作可用。它配合就绪探针（readinessProbe）使用：就绪探针确认应用可服务，minReadySeconds 确保这种就绪状态稳定一段时间。StatefulSet 滚动更新默认按序（从最大序号到最小）逐个更新，每个 Pod 只有满足就绪探针且经过 minReadySeconds 后才算就绪，controller 才继续更新下一个副本，从而控制更新节奏、保证可用性。

解析

核心是"就绪探针确认可用 + minReadySeconds 保证稳定"。StatefulSet 按序逐个更新。

示例代码

apiVersion: apps/v1
kind: StatefulSet
metadata: { name: web }
spec:
  updateStrategy:
    type: RollingUpdate
  minReadySeconds: 30
  template:
    spec:
      containers:
        - name: c
          image: app
          readinessProbe:
            httpGet: { path: /health, port: 8080 }

#

★★★

6. StatefulSet 缩容如何按序优雅删除副本（从最大序号开始）？

问题

StatefulSet 缩容如何按序优雅删除副本（从最大序号开始）？

考察点

缩容顺序（从最大序号）
优雅终止
PVC 是否保留

答案

StatefulSet 缩容时按序删除，从序号最大的副本开始（如 replicas 从 3 减到 1，先删 web-2，再 web-1），前序删除完成后才删除下一个。删除是优雅终止：先终止容器（terminationGracePeriodSeconds），再删除对应的 PVC（默认保留，除非 PVC 策略为 Delete）。按序删除保证有状态应用的数据一致性（先删最新副本）。注意：缩容后 PVC 默认保留，数据不丢失，但扩容后新 Pod 会按原序号重新绑定。

解析

核心是"从最大序号开始按序删除 + 优雅终止"。PVC 默认保留，数据持久。

#

★★★

7. topologySpreadConstraints 如何跨可用区或节点打散工作负载，即 maxSkew、topologyKey 与 whenUnsatisfiable（DoNotSchedule/ScheduleAnyway）的调度语义以及与 nodeAffinity、podAntiAffinity 的适用边界？

问题

topologySpreadConstraints 如何跨可用区或节点打散工作负载？maxSkew、topologyKey、whenUnsatisfiable 的语义，以及与 nodeAffinity、podAntiAffinity 的适用边界？

考察点

topologySpreadConstraints 原理
maxSkew/topologyKey/whenUnsatisfiable
与 nodeAffinity/podAntiAffinity 的区别

答案

topologySpreadConstraints 用于把工作负载在拓扑域（topologyKey，如 zone、hostname）间均匀分布。maxSkew 表示不同拓扑域间 Pod 数量最大偏差；topologyKey 指定拓扑维度（如 zone）；whenUnsatisfiable 决定无法满足时行为：DoNotSchedule（硬约束，不调度）或 ScheduleAnyway（软约束，尽量打散）。它解决"故障域隔离与负载均衡"。与 nodeAffinity（指定节点/限制节点）、podAntiAffinity（避免同 Pod 同节点）不同：topologySpread 关注"每个拓扑域内 Pod 数量均衡"，是更全局的分布约束；nodeAffinity 是硬性选中某类节点；podAntiAffinity 是避免特定 Pod 同组。适用边界：topologySpread 适合全局打散，nodeAffinity 适合强制节点选择，podAntiAffinity 适合避免单点。

解析

核心是"拓扑域内数量均衡 + maxSkew 偏差控制"。whenUnsatisfiable 决定硬/软约束。

示例代码

apiVersion: v1
kind: Pod
spec:
  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: zone
      whenUnsatisfiable: DoNotSchedule
      labelSelector: { matchLabels: { app: api } }

#

★★

8. CronJob 如何按 cron 表达式调度 Job 并处理并发策略与历史保留？

问题

CronJob 如何按 cron 表达式调度 Job？并发策略与历史保留如何配置？

考察点

cron 表达式调度
concurrencyPolicy
历史保留（successfulJobsHistoryLimit）

答案

CronJob 按 cron 表达式（如 */5 * * * *）周期生成 Job。concurrencyPolicy 控制并发：Allow（允许并发）、Forbid（前一个未完成则跳过）、Replace（替换前一个）。历史保留用 successfulJobsHistoryLimit 与 failedJobsHistoryLimit 控制保留的 Job 数量。可设置 timeZone 指定时区。若调度时间错过了（如集群暂停），Jobs 会跳过或按 startingDeadlineSeconds 处理。CronJob 本身默认不删除历史 Job，需历史限制清理。

解析

核心是"cron 调度 + 并发策略 + 历史清理"。Forbid 防止堆积，历史限制防止资源泄漏。

示例代码

apiVersion: batch/v1
kind: CronJob
metadata: { name: backup }
spec:
  schedule: "0 2 * * *"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          containers: [{ name: c, image: backup }]
          restartPolicy: Never

#

★★

9. DaemonSet 的 RollingUpdate 与 OnDelete 更新策略有何差异？

问题

DaemonSet 的 RollingUpdate 与 OnDelete 更新策略有何差异？

考察点

RollingUpdate（顺序/逐个更新）
OnDelete（手动触发）
差异与适用场景

答案

DaemonSet 支持两种更新策略。RollingUpdate：自动滚动更新所有节点上的 Pod，可配置 maxUnavailable/maxSurge 控制更新速度，新配置逐步应用到各节点。OnDelete：不自动更新，只有手动删除某节点上的 Pod 后，DaemonSet 才用新配置重建该 Pod，适合需要精细控制更新节奏的场景。默认 RollingUpdate。差异核心：RollingUpdate 自动、OnDelete 手动精确控制。

解析

核心是"自动滚动 vs 手动触发的更新"。OnDelete 适合系统组件谨慎更新。

#

★★

10. Deployment 滚动更新与回滚的机制中 revision 历史、rollout undo 与暂停/恢复（pause/resume）如何配合使用

问题

Deployment 滚动更新与回滚的机制：revision 历史、rollout undo 与暂停/恢复（pause/resume）如何配合使用？

考察点

revision 历史
rollout 回滚
pause/resume

答案

Deployment 每次更新模板会生成新的 revision（版本号），历史 revision 保存在 ReplicaSet 中。kubectl rollout undo deployment/app 回滚到上一个 revision，--to-revision=N 回滚到指定版本。kubectl rollout pause 暂停滚动（新 revision 不应用，便于多步修改），resume 恢复滚动。回滚通过创建对应 revision 的 ReplicaSet 实现。配合使用：发布时 pause 确认再 resume，出问题立即 undo。

解析

核心是"revision 历史 + undo 回滚 + pause/resume 控制"。这是灰度/发布流程的基础。

示例代码

kubectl rollout status deployment/app
kubectl rollout history deployment/app
kubectl rollout undo deployment/app --to-revision=2
kubectl rollout pause deployment/app
kubectl rollout resume deployment/app

#

★★

11. HPA 如何从 metrics-server 获取指标并计算目标副本数？

问题

HPA 如何从 metrics-server 获取指标并计算目标副本数？

考察点

metrics-server 采样
HPA 计算逻辑
目标副本数公式

答案

HPA（HorizontalPodAutoscaler）通过 metrics-server 获取 CPU/内存等资源指标（metrics-server 从 kubelet 的 cAdvisor 采集）。HPA 控制器周期性（默认 15s）拉取指标，计算目标副本数 = ceil(当前副本数 × 当前用量 / 目标用量)。支持 CPU、内存、自定义指标（custom metrics）与外部指标。为避免抖动，有冷却（cooldown）机制：扩缩容有延迟（scale-down 等 5 分钟）。计算结果受 minReplicas/maxReplicas 限制。

解析

核心是"指标采集 + 期望副本数公式 + 冷却"。CPU 目标用平均值计算。

示例代码

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: app }
spec:
  scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: app }
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target: { type: Utilization, averageUtilization: 60 }

#

★★

12. Job 的 completionMode（Indexed/NonIndexed）如何控制批量任务完成语义？

问题

Job 的 completionMode（Indexed/NonIndexed）如何控制批量任务完成语义？

考察点

completionMode 两种模式
Indexed 的索引完成
NonIndexed 的任意完成

答案

Job 的 completionMode 控制任务完成语义。NonIndexed（默认）：Job 完成后只需达到 completions 数量的 Pod 成功即可，不区分哪个 Pod 成功。Indexed：每个 Pod 被分配一个索引（0 到 completions-1），Pod 名带索引，且必须每个索引对应的 Pod 都成功才算完成，适合需要按索引处理数据分片的批量任务（如 MapReduce）。Indexed 的 Pod 通过 JOB_COMPLETION_INDEX 环境变量获取索引。

解析

核心是"NonIndexed 模糊完成 vs Indexed 按索引完成"。Indexed 适合分片数据处理。

示例代码

apiVersion: batch/v1
kind: Job
metadata: { name: parallel }
spec:
  completions: 4
  parallelism: 2
  completionMode: Indexed
  template:
    spec:
      containers:
        - name: c
          image: worker
          env: [{ name: JOB_COMPLETION_INDEX, valueFrom: { fieldRef: { fieldPath: metadata.annotations['batch.kubernetes.io/job-completion-index'] } } }]
      restartPolicy: Never

#

★

13. DaemonSet 的适用场景与调度约束中节点亲和、污点容忍与优先级类如何控制部署范围

问题

DaemonSet 的适用场景与调度约束：节点亲和、污点容忍与优先级类如何控制部署范围？

考察点

DaemonSet 适用场景
节点亲和
污点容忍

答案

DaemonSet 保证每个节点上运行一个 Pod，适合系统组件：日志采集（fluentd）、监控（node-exporter）、CNI、kube-proxy、存储节点代理等。控制部署范围：节点亲和（nodeAffinity）限定只在特定节点（如带标签节点）运行；污点容忍（tolerations）允许调度到有污点的节点；优先级类（priorityClassName）影响驱逐与抢占顺序。DaemonSet 默认每个节点一个，可用约束缩小范围。

解析

核心是"每节点一个 + 亲和/容忍/优先级控制范围"。系统组件常加容忍以运行在关键节点。

#

★

14. Job 的并发与重试策略中 parallelism/completions、backoffLimit 与 activeDeadlineSeconds 如何配置

问题

Job 的并发与重试策略：parallelism/completions、backoffLimit 与 activeDeadlineSeconds 如何配置？

考察点

parallelism 与 completions
backoffLimit 重试
activeDeadlineSeconds 超时

答案

Job 的 parallelism 表示同时运行的 Pod 数，completions 表示总需成功完成的 Pod 数。backoffLimit 表示 Pod 失败后的最大重试次数（默认 6），超过后 Job 标记失败。activeDeadlineSeconds 表示 Job 整体运行的最长时间，超时则终止 Job（标记失败）。ttlSecondsAfterFinished 可自动清理完成的 Job。配置组合：suspended 可暂停 Job。

解析

核心是"并发数 + 总完成数 + 重试上限 + 超时"。backoffLimit 防无限重试，activeDeadline 防无限运行。

示例代码

apiVersion: batch/v1
kind: Job
metadata: { name: task }
spec:
  parallelism: 5
  completions: 10
  backoffLimit: 4
  activeDeadlineSeconds: 3600

#

★

15. ReplicationController 与 Deployment 的副本管理差异及替代关系？

问题

ReplicationController 与 Deployment 的副本管理差异及替代关系？

考察点

RC 的机制
Deployment 的演进
替代关系

答案

ReplicationController（RC）是早期副本控制器，保证指定数量的 Pod 运行，通过 selector 匹配 Pod。Deployment 是更高级的抽象，管理 ReplicaSet（RS），提供滚动更新、版本回滚、暂停恢复等能力。RC 已被 RS/Deployment 取代，Deployment 声明式管理副本并支持更新策略。RC 只能管理副本数，不能滚动更新。现代集群推荐使用 Deployment（或 StatefulSet/DaemonSet/Job）。

解析

核心是"RC 是早期副本控制器，Deployment 提供更新与回滚能力"。RC 已被取代。

#

★

16. StatefulSet 的稳定标识机制中 Pod 名称、PVC 绑定与网络身份的对应关系如何影响故障恢复

问题

StatefulSet 的稳定标识机制：Pod 名称、PVC 绑定与网络身份的对应关系如何影响故障恢复？

考察点

Pod 名称与序号
PVC 绑定到 Pod
网络身份（headless DNS）

答案

StatefulSet 的每个 Pod 有稳定名称（{name}-{ordinal}），其对应的 PVC（volumeClaimTemplates 生成）与该 Pod 序号的名称绑定（如 data-web-0）。Pod 故障删除后，controller 用相同名称重建，重新绑定原 PVC，从而恢复数据。网络身份通过 headless Service 的 DNS（{pod}.{svc}.{ns}.svc）稳定。故障恢复时 Pod 保持名称、PVC 与网络身份一致，因此数据和应用状态能恢复。若 PVC 被删除或丢失，恢复会失败。

解析

核心是"名称、PVC、网络身份的稳定三元组"。故障恢复依赖这三者的一致性。

#

★

17. VPA 的 recommender 如何基于历史用量生成 requests 推荐值？

问题

VPA 的 recommender 如何基于历史用量生成 requests 推荐值？

考察点

VPA 组件架构
recommender 的指标来源
推荐算法

答案

VPA（Vertical Pod Autoscaler）由 recommender、updater、admission 三个组件组成。recommender 从 metrics-server/历史指标获取 Pod 的 CPU/内存用量，结合容器请求，通过算法（如基于百分位的安全边际）计算推荐 requests 值，并写入 VPA 的 status 并更新 recommendation。updater 根据推荐驱逐 Pod 使其按新 requests 重建，admission webhook 在 Pod 创建时注入推荐值。推荐有两种：recommendation（requests 建议）与 updateMode（Auto/Initial/Off）。推荐值通常取历史用量的某个百分位（如 95% 分位）加缓冲。

解析

核心是"recommender 基于历史用量百分位计算推荐值"。VPA 与 HPA 不适用同时用 CPU 指标。

#

★

18. 工作负载的资源请求与限制中 requests 如何影响调度、limits 如何触发驱逐与 OOM 以及二者失衡的后果

问题

工作负载的资源请求与限制：requests 如何影响调度、limits 如何触发驱逐与 OOM，以及二者失衡的后果？

考察点

requests 影响调度
limits 触发 OOM/驱逐
失衡后果

答案

requests 用于调度：调度器按节点上已分配 requests 之和判断是否放得下更多 Pod；limits 用于运行时限制：容器超过 limits 时会被 CPU 限流、内存 OOM 杀掉。二者失衡的后果：若 requests 高而 limits 低，节点资源按 requests 预留导致利用率低；若 requests 低而 limits 高，节点可能超卖（oversubscription），多个 Pod 同时突增内存时触发 OOM/驱逐。requests 与 limits 相等时 QoS 为 Guaranteed（最稳定），不等为 Burstable，都未设置为 BestEffort。驱逐顺序：BestEffort 先被驱逐。

解析

核心是"requests 决定调度预留，limits 决定运行时上限"。合理设置避免超卖与浪费。