跳转至

Kubernetes 核心体系

这部分怎么准备

高级运维面试里的 Kubernetes，通常不是只问你会不会 kubectl，而是看你是否真正理解：

  • 集群是怎么工作的
  • 工作负载为什么这样设计
  • 调度、网络、存储为什么会出问题
  • 线上升级、扩容、迁移、故障处理你是否真的做过

这页按“可直接背诵 + 可继续展开”的方式整理。

1 分钟开场回答

如果面试官让你概括自己对 Kubernetes 的理解，可以先这样答：

Kubernetes 本质上是一套面向容器应用的声明式编排系统。
它的核心思想不是“手动管理容器”，而是把期望状态交给控制面，由控制器不断把实际状态拉回期望状态。
从运维视角看，我会重点关注 5 个方面：集群架构是否稳定、工作负载模型是否合适、资源调度是否合理、网络和存储是否可靠、以及升级和故障处理是否可控。
真正的难点通常不在部署应用，而在于如何让集群在多环境、多业务、高并发和频繁变更场景下保持稳定、可观测、可回滚。

这个回答的价值在于：

  • 先把 Kubernetes 定义成“声明式编排系统”
  • 再把运维视角引到稳定性、治理和故障处理
  • 给后续追问埋下结构化入口

核心认知

你要先记住的主线

Kubernetes 的核心逻辑可以概括成一句话：

用户通过 YAML 提交期望状态，apiserver 写入 etcd，controller 和 scheduler 持续驱动集群把实际状态收敛到目标状态，kubelet 负责在节点上真正执行。

你可以这样展开

  • apiserver 是控制面的统一入口，所有读写都先经过它
  • etcd 保存集群状态，是整个控制面的数据基石
  • controller-manager 负责“发现偏差并纠正偏差”
  • scheduler 负责“把 Pod 放到合适的节点”
  • kubelet 负责“让节点上的容器真正跑起来”
  • kube-proxy 和 CNI 负责让网络通信符合 Kubernetes 的抽象模型

集群架构

标准回答

Kubernetes 集群可以分成 Control Plane 和 Worker Node 两部分。

Control Plane 负责“管理和决策”，核心组件包括：

  • kube-apiserver：统一 API 入口
  • etcd：保存集群状态
  • kube-controller-manager：运行各种控制器
  • kube-scheduler：负责调度 Pod

Worker Node 负责“实际运行负载”，核心组件包括：

  • kubelet：管理节点上的 Pod 生命周期
  • container runtime：如 containerd
  • kube-proxy：维护 Service 转发规则

高级运维视角要补的点

  • apiserver 要高可用，因为它是所有控制流量入口
  • etcd 要重点保护，因为它是状态源，损坏会直接影响整个集群
  • 节点层问题通常先看 kubelet、运行时、磁盘、CNI
  • 真正的生产集群关注的不只是能跑，还包括版本管理、证书轮转、备份恢复、资源水位和组件依赖关系

高频追问

etcd 为什么重要

  • etcd 存的是集群元数据和期望状态
  • 如果 etcd 不可用，控制面会失去状态读写能力
  • 如果 etcd 数据损坏，集群可能无法恢复到正确状态

apiserver 为什么是核心

  • 所有组件都通过 apiserver 交互
  • 它既是控制入口，也是鉴权、准入和资源校验的关键位置

核心对象及使用边界

面试里一定要答清楚的对象边界

Pod

  • 最小调度单元
  • 一个或多个紧密耦合的容器共享网络和存储命名空间
  • 通常不直接手工管理 Pod，而是交给更高层控制器

Deployment

  • 适合无状态应用
  • 管理副本数、滚动更新、回滚
  • 高频场景是 Web 服务、API 服务、通用业务服务

StatefulSet

  • 适合有状态应用
  • 提供稳定网络标识、稳定存储绑定、有序发布和有序缩容
  • 高频场景是数据库、消息队列、需要固定身份的集群组件

DaemonSet

  • 每个节点运行一个 Pod
  • 常见场景是日志采集、监控 Agent、节点安全组件

Job / CronJob

  • 适合一次性任务和定时任务
  • 常见场景是数据修复、批处理、周期巡检

面试标准说法

Deployment 和 StatefulSet 的核心区别不只是“有状态”和“无状态”，更重要的是是否需要稳定身份和稳定存储。
如果应用只需要弹性副本和滚动更新，用 Deployment；如果它依赖固定网络标识、固定 PVC 绑定或者有序启动终止，就更适合 StatefulSet。

调度与资源管理

面试核心观点

调度不是简单“找个节点放上去”，而是在资源约束、拓扑要求、亲和性、污点容忍和业务稳定性之间做平衡。

你要会讲的几个关键点

requests 和 limits

  • requests 决定调度时至少要预留多少资源
  • limits 决定运行时最多可使用多少资源
  • CPU 超限通常是限速
  • Memory 超限通常可能触发 OOMKill

节点选择能力

  • nodeSelector：最简单的节点筛选
  • nodeAffinity：更灵活的节点亲和规则
  • podAffinity / podAntiAffinity：控制 Pod 之间如何靠近或分散
  • taint / toleration：做节点隔离

弹性能力

  • HPA：根据指标自动扩缩 Pod
  • VPA：调整 Pod 资源建议或资源值
  • Cluster Autoscaler：根据调度压力扩缩节点

高级运维面试常见表达

资源治理里最常见的问题不是“不会调度”，而是资源申请不准确导致集群利用率和稳定性同时变差。
如果 requests 配得太低，会造成节点过度装箱，运行时争抢严重；如果配得太高，会让调度失败率和资源浪费同时上升。
所以高级运维通常会把资源治理和容量治理一起做，而不是只盯着调度结果。

Service、网络与流量转发

先背结论

Kubernetes 的网络模型核心是：

  • 每个 Pod 都有独立 IP
  • Pod 之间理论上可以直接通信
  • Service 提供稳定访问入口
  • Ingress 提供集群外七层流量接入

Service 要怎么答

Service 的价值

  • 给一组动态变化的 Pod 提供稳定访问地址
  • 通过 label selector 关联后端 Pod
  • 屏蔽 Pod 生命周期变化对访问方的影响

Service 类型

  • ClusterIP：集群内访问
  • NodePort：通过节点端口暴露
  • LoadBalancer：依赖云厂商 LB
  • ExternalName：DNS 别名映射

kube-proxy 怎么答

面试里常见问法是：kube-proxy 有哪几种模式？

标准答法：

  • 常见模式是 iptables 和 ipvs
  • iptables 规则简单直接，兼容性广
  • ipvs 在大规模 Service 场景下一般性能更好，规则管理也更适合高并发转发

访问链路怎么答

如果面试官问“用户访问域名最终怎么到 Pod”，你可以这样答：

  1. 先通过 DNS 解析到负载均衡或 Ingress 地址
  2. 流量进入 Ingress Controller
  3. Ingress 按域名和路径匹配到目标 Service
  4. Service 再通过 kube-proxy 规则把流量转给后端 Pod
  5. 最终由 Pod 响应请求

存储体系

你要抓住的核心

Kubernetes 本身不提供具体存储实现，它提供的是统一抽象和生命周期管理。

核心对象怎么讲

  • Volume：Pod 内部使用的存储定义
  • PV：集群层面的持久卷资源
  • PVC：用户对存储的申请
  • StorageClass：动态供给存储的策略模板

面试关键表达

Kubernetes 的存储设计核心是把“应用如何申请存储”和“底层存储如何提供能力”解耦。
应用通常只关心 PVC，平台通过 StorageClass 和 CSI 驱动对接不同后端存储。

高频追问

StatefulSet 为什么经常和 PVC 一起出现

  • 因为有状态应用不仅要副本存活，还要让副本和数据保持稳定绑定关系

存储问题排查先看什么

  • PVC 是否绑定成功
  • StorageClass 是否正确
  • CSI 驱动是否正常
  • 节点挂载日志是否异常

升级、扩缩容与集群运维

这部分是高级岗位的加分区

如果你讲不出升级、节点维护、证书、备份恢复，面试官通常会判断你更多是“使用者”而不是“集群维护者”。

升级怎么答

可以按这个逻辑讲：

  1. 先确认版本跨度和兼容矩阵
  2. 先备份 etcd 和关键配置
  3. 优先升级控制面，再升级节点组件
  4. 分批 cordon + drain 节点，逐步滚动
  5. 升级后验证核心业务、网络、DNS、存储和监控

节点维护怎么答

  • 维护前先 cordon
  • 再 drain
  • 确认 Pod 已被安全迁移
  • 完成维护后 uncordon

etcd 运维怎么答

  • 定期备份
  • 关注容量和碎片整理
  • 确保选举稳定
  • 恢复演练一定要做，不要只停留在“理论知道怎么恢复”

高频故障场景与答题模板

Pod Pending

先讲排查主线

  1. 看 describe pod
  2. 看 events
  3. 看调度失败原因
  4. 看节点资源、污点、亲和性、PVC

常见原因

  • CPU / 内存不足
  • requests 过大
  • taint 未容忍
  • 亲和或反亲和条件过严
  • PVC 未绑定

面试表达模板

Pod Pending 我一般先不急着看业务日志，因为这说明它还没真正跑起来。
我会先 kubectl describe pod 看调度事件，重点确认是资源不足、节点选择条件不满足，还是存储绑定失败。
如果是资源问题，我会继续看节点剩余资源和 requests 配置；如果是策略问题，就检查 taint、toleration、亲和性和拓扑分布限制。

Pod CrashLoopBackOff

排查重点

  • 容器启动命令是否异常
  • 配置文件或环境变量是否错误
  • 探针是否误杀
  • 依赖服务是否不可达
  • OOMKill 是否发生

标准说法

CrashLoopBackOff 说明容器能启动，但很快反复退出。
我通常会先看容器日志和退出码，再结合 describe pod 判断是应用自身报错、依赖失败、探针配置问题，还是资源不足导致 OOM。

Service 不通

排查顺序

  1. Service selector 是否匹配到 Pod
  2. Endpoints 是否生成
  3. Pod 是否 Ready
  4. 端口映射是否正确
  5. kube-proxy 或 CNI 是否异常

CoreDNS 异常

面试回答重点

  • 先确认是否所有命名空间都异常
  • 看 CoreDNS Pod 状态和日志
  • 看上游 DNS 可达性
  • 看 CNI、NetworkPolicy、节点网络问题

节点 NotReady

常见原因

  • kubelet 异常
  • 容器运行时异常
  • 节点磁盘或 inode 打满
  • 网络中断
  • 证书或心跳异常

高频面试题直接答案

Deployment 和 StatefulSet 的边界是什么

Deployment 适合无状态服务，重点是副本管理、滚动更新和快速回滚；StatefulSet 适合需要稳定身份、稳定网络标识和稳定存储绑定的有状态服务。真正的判断标准不是“有没有数据”，而是应用是否依赖固定实例身份和数据连续性。

Pod 一直 Pending 你怎么查

先看 kubectl describe pod 和 events，确认是资源、调度策略还是存储问题。资源不够就看节点余量和 requests；策略不满足就看 taint、toleration、affinity；如果涉及持久化，就检查 PVC、PV、StorageClass 和 CSI。

kube-proxy 有哪几种模式？差异是什么

常见是 iptables 和 ipvs。iptables 简单、通用，ipvs 在大规模规则场景下性能和扩展性更好。面试里重点不是背模式名，而是知道它们都在解决 Service 到后端 Pod 的转发问题。

你做过哪些集群升级或迁移工作

建议按这个顺序回答：背景是什么、为什么升级或迁移、风险点是什么、怎么分批实施、怎么验证、出了问题怎么回滚、最后结果如何。面试官更想听“过程控制能力”，而不是只听你说“升级成功了”。

你的答题框架

后续你在面试里遇到 Kubernetes 问题，建议固定按这个顺序回答：

  1. 先定义问题是什么
  2. 再说核心原理
  3. 再讲运维视角关注点
  4. 最后补一个真实场景或排障路径

例如回答“为什么 Pod 会调度失败”，不要只说“资源不够”，而是说：

  • 调度本质上是资源和约束匹配
  • 失败通常来自资源不足、策略限制或存储约束
  • 我的排查顺序是 events、节点资源、策略规则、PVC

这样面试官会更容易判断你有生产经验。

最后要背下来的 10 个关键词

  • 声明式
  • 期望状态
  • 控制器收敛
  • 调度约束
  • 资源治理
  • Service 抽象
  • 存储解耦
  • 分批升级
  • 先看 events
  • 稳定性优先

下一步建议

如果你继续往下补，我建议 Kubernetes 这一页下一轮再加 3 类内容：

  • kubectl 高频排障命令清单
  • 真实故障案例 3 篇
  • 架构题回答模板 2 套