DevOps 面试题精选（二）：Kubernetes 与云原生运维

Kubernetes 面试题最容易出现"会 kubectl、懂概念，但讲不清机制"的情况：Pod 被驱逐了不知道是 QoS 在起作用，HPA 不扩容不知道去查指标来源。本文精选 13 道生产导向的高频题，覆盖调度、流量、存储、配置与集群运维，每道先给结论再拆要点，也适合当作内部晋升答辩与值班准入的题库。

本文题目一览

• Pod 生命周期与 restartPolicy 有何讲究？
• Service 有哪几种类型？流量路径怎么走？
• Ingress 与 Gateway API 是什么关系？
• requests/limits 管什么？QoS 如何决定驱逐？
• HPA 的原理是什么？指标从哪来？
• 滚动更新怎么实现？回滚靠什么？
• StatefulSet 与 Deployment 有何区别？
• PV、PVC、StorageClass 是什么关系？
• ConfigMap/Secret 改了为什么不生效？
• 节点 NotReady 按什么顺序排查？
• etcd 有什么作用？如何备份？
• Helm 解决了什么问题？有哪些坑？
• 命名空间多租户隔离还差哪些机制？

1. Pod 生命周期与 restartPolicy 有何讲究？

结论：Pod 状态机为 Pending → Running → Succeeded/Failed；restartPolicy 决定容器退出后 kubelet 是否原地拉起，它作用于容器而不是 Pod。

• Always：退出即重启，Deployment 管理的 Pod 强制此值，保证副本自愈；
• OnFailure：非零退出才重启，适合 Job 类任务，配合 backoffLimit 控制重试上限；
• 探针别混淆：就绪探针失败只把 Pod 摘出 Service 后端、不重启；存活探针失败才触发重启。

2. Service 有哪几种类型？流量路径怎么走？

结论：Service 是一组 Pod 的稳定入口加负载均衡：靠标签选择器维护 Endpoints，kube-proxy 用 iptables/IPVS 把虚拟 IP 的流量转发到真实 Pod。

• ClusterIP：默认类型，仅集群内可达，服务间调用用它；
• NodePort / LoadBalancer：前者在每节点开固定端口，简单但管理粗糙；后者向云厂商申请外部 LB，是公有云标准做法；
• 排查抓手：连不通先看 kubectl get endpoints 是否为空，为空就是标签或就绪探针问题，与网络无关。

3. Ingress 与 Gateway API 是什么关系？

结论：Gateway API 是 Ingress 的继任者。Ingress 只标准化了最基础的七层路由，厂商能力全靠注解、不可移植；Gateway API 用分层模型把基础设施配置与应用路由解耦。

• 角色分离：平台团队管 Gateway（监听、证书），业务团队管自己的 HTTPRoute；
• 表达能力：权重切分、超时、重试等原来写注解的功能变成标准字段；
• 迁移现实：存量 Ingress 不必急迁，新业务直接上 Gateway API，老系统随控制器版本自然过渡。

4. requests/limits 管什么？QoS 如何决定驱逐？

结论：requests 是调度依据与资源下限，limits 是运行时上限（CPU 超了节流、内存超了 OOM Kill）；两者比值决定 QoS 等级，节点内存紧张时按等级从低到高驱逐。

• Guaranteed：requests 等于 limits，最后被驱逐，留给核心服务；
• Burstable / BestEffort：前者设了 requests 但小于 limits，是多数业务的形态；后者什么都不设，最先被清理；
• 设值依据：用 VPA 推荐或历史 P95/P99 用量打底，再结合驱逐与 OOM 记录迭代，拍脑袋填数比不填更危险。

5. HPA 的原理是什么？指标从哪来？

结论：HPA 是控制循环：周期性比较当前指标与目标值，按 期望副本 = 当前副本 ×（当前指标/目标指标）调整副本数；默认指标来自 metrics-server，可接 Prometheus 自定义指标。

• 不生效先查三点：没设 requests 时 CPU 利用率算不出、metrics-server 是否正常、是否被其他控制器打架改副本；
• 防抖：缩容有稳定窗口（默认 5 分钟）与速率限制，避免毛刺引起副本震荡；
• 指标局限：队列型负载用 CPU 扩缩会失真，应改用队列长度等自定义指标或 KEDA；HPA 只管副本，节点不足还需 autoscaler 扩节点。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

6. 滚动更新怎么实现？回滚靠什么？

结论：滚动更新靠 ReplicaSet 版本替换：每次模板变更新建一个 RS，按 maxSurge 与 maxUnavailable 的节奏此消彼长地换 Pod；回滚就是把版本指针指回旧 RS。

• 关键参数：maxSurge 控制最多多起几个，maxUnavailable 控制最多几个不可用，两者不能同为 0；
• 卡住先看：新 Pod 起不来滚动会停在半路，用 kubectl rollout status 看进度与新 RS 事件，别急着改副本数；
• 回滚：kubectl rollout undo 回上一版，前提是旧 RS 未被 revisionHistoryLimit 清理、且数据变更向前兼容。

7. StatefulSet 与 Deployment 有何区别？

结论：区别在"身份"：Deployment 的 Pod 完全对等、可任意替换；StatefulSet 给每个 Pod 稳定序号、独立 DNS 名和专属存储，启停严格有序。

• 稳定标识：通过 Headless Service 提供固定域名，集群成员可按名字互相发现；
• 适用场景：数据库、Kafka、ZooKeeper 等有状态集群；无状态服务套它只增加复杂度；
• 多一手：支持 partition 分区滚动，可先只更新部分序号的 Pod 做灰度。

8. PV、PVC、StorageClass 是什么关系？

结论：三者是"供给、申领、模板"的关系：PVC 是应用对存储的声明，PV 是实际存储对象，StorageClass 定义按需创建 PV 的配方（驱动与性能等级）。

• 静态与动态：静态是管理员预建 PV 等待匹配；动态是无匹配时 CSI 驱动按模板自动创建，是公有云主流；
• 回收策略：PVC 删除后 PV 的 Retain/Delete 决定数据生死，生产数据一律 Retain；
• 访问模式：RWO 单节点读写、RWX 多节点共享，后者依赖 NFS/CephFS，选型先确认是否真需要共享写。

9. ConfigMap/Secret 改了为什么不生效？

结论：取决于注入方式：环境变量注入的永不更新、必须重启 Pod；volume 挂载的由 kubelet 周期同步（约 1 分钟延迟）；用 subPath 挂载的永不更新，这是最常见的坑。

• 环境变量：进程启动即定格，想生效只能滚动重启；
• Secret 并非加密：只是 base64 编码，真保密靠 etcd 静态加密、RBAC 收紧或外接 Vault；
• 联动更新：把配置哈希写进 Pod 模板注解，改配置即可自动触发滚动更新。

10. 节点 NotReady 按什么顺序排查？

结论：自下而上、先分责任面：先看是单点还是批量异常，再查 kubelet 与容器运行时，最后看资源压力信号。

• 先分面：批量异常先怀疑控制面、网络或机房，单节点才钻进节点本身；
• kubelet 与运行时：常见死因是证书过期、与 apiserver 不通、containerd 无响应；
• 资源压力：MemoryPressure、DiskPressure 顺藤摸瓜，日志与镜像写满系统盘是最经典剧本；处理顺序是先摘流量、再清现场。

# 节点异常排查命令组合
kubectl describe node <node-name>      # 看 Conditions 与事件
kubectl get pods -A --field-selector spec.nodeName=<node-name>
journalctl -u kubelet --since "30 min ago"   # 节点上看 kubelet 日志
crictl ps && crictl images                 # 运行时是否响应

11. etcd 有什么作用？如何备份？

结论：etcd 是集群唯一的事实来源，存全部对象状态，apiserver 是它的带缓存前端；etcd 丢数据等于集群没了，备份是运维红线。

• 性能敏感：对磁盘 fsync 延迟极其敏感，必须 SSD，IO 抖动直接表现为 apiserver 变慢；
• 备份：用 etcdctl snapshot save 定期全量快照并异地保存，恢复前先验证快照可读——没验证过等于没备份；
• 日常维护：关注库体积与碎片、定期 defrag，撑爆默认配额会触发只读告警；控制面升级前必须先备份。
• 部署形态：生产环境用奇数个节点（三个或五个）组集群保证仲裁，不要把 etcd 和重负载组件混布在同一批机器上。

12. Helm 解决了什么问题？有哪些坑？

结论：Helm 把一组清单打包成可参数化、可版本化的 Chart，解决"同应用多环境靠复制粘贴 YAML"的问题，本质是模板引擎加发布管理。

• 核心价值：values 分环境覆盖、一键安装与 helm rollback 按修订回滚；
• 模板坑：Go template 缩进与作用域易出诡异问题，逻辑复杂时应拆 values 或改用 Kustomize 补丁模式；
• 状态存放：release 记录以 Secret 存在目标命名空间，误删或权限混乱会让状态与实际资源对不上；与 GitOps 是组合关系而非替代。

13. 命名空间多租户隔离还差哪些机制？

结论：命名空间只是逻辑边界，本身不隔离任何东西；完整隔离是"资源有上限、网络不互通、权限不越界"三件套。

• ResourceQuota：限制命名空间总 CPU、内存与对象数，防单租户吃光集群；
• LimitRange：给容器设默认与上下限的 requests/limits，与 Quota 联动堵漏；
• NetworkPolicy + RBAC：默认命名空间之间网络是通的，要显式默认拒绝加白名单；账号只绑本命名空间 Role。强隔离场景应直接上独立集群。
• 审计留痕：开启审计日志并集中留存，跨租户的敏感操作要可追溯、可复盘，这是多租户对外交付时的合规底线。

面试官视角

这组题在考候选人脑子里的 K8s 是"对象清单"还是"控制系统"。区分度最高的几道：QoS 与驱逐（能把 requests/limits、QoS、节点压力串成因果链的，一定处理过线上驱逐）、ConfigMap 生效（答得出 subPath 不更新这种细节的，都是踩坑踩出来的）、节点 NotReady（看排查顺序就知道值没值过班——先分单点批量、再自下而上，而不是上来重启 kubelet）。加分回答的特征是"机制 + 证据命令"成对出现：讲 HPA 带上 requests 缺失导致指标算不出，讲回滚主动提数据兼容边界。只会背组件名、对 etcd 备份与 HPA 指标来源含糊的候选人，简历上的"精通 K8s"通常要打对折看。

Mr丶点心

打赏 海报 链接