简介这是一份面向Kubernetes相关岗位求职者的面试题库合集收录128道高频云原生与K8s面试题覆盖etcd原理、Pod调度、集群管理、部署方式、服务发现等核心主题。资源包共1个PDF文件整体大小约2.73MB既便于按目录速览也适合打印或导入阅读器反复研读。目前已有4636人学习下载题目组织从基础概念到运维实践逐层递进适合正在准备K8s/Docker面试的初中级工程师查漏补缺。PDF中不仅给出了结论性答案还围绕Raft一致性算法、Replication Controller副本控制、分布式锁与Leader竞选等经典考点展开说明可帮助读者理解背后的设计思想与常见误区提升面试应答深度。对于希望快速建立云原生知识框架、强化容器编排理解、增加面试过关率的求职者来说是一份实用的备查资料。1. 128 道 k8s 面试题集锦为什么背完答案还是过不了面试面试前我把这套 128 题的云原生与 k8s 面试集锦从头到尾刷了两遍答案背得滚瓜烂熟结果一面就被一个“Pod 一直 Pending 你怎么查”问住了。不是因为题没刷到而是我只会背结论不会讲过程。这套 128 题集锦覆盖面确实够广从容器基础、Pod 调度到集群排障都有涉及适合三类人准备求职的开发者、要在团队内做技术分享的负责人、想系统查漏补缺的运维。它的正确用法不是背答案而是拿题目当引子把每个考点扩成一条能讲清楚原理、操作和排查思路的完整链路。这篇就按这个思路把这 128 题拆成一张可执行的学习地图。2. 给 128 题建一张知识地图把题目按考点拆成五个复习区2.1 先按考察意图分类而不是按题目序号刷拿到一份 128 题的集锦最忌讳的做法是从第 1 题按顺序刷到第 128 题。题目的排列顺序往往不是按知识体系排的前面可能是概念题中间突然跳到一个冷门的存储细节顺序刷会让你的大脑在几类思维模式之间来回切换记忆效率很低。我一般会把题目先打散按考察意图重新归类。复习区题目覆盖方向核心考察点优先级基础与架构区容器与镜像、Pod 基础、k8s 组件职责能不能说清控制面与节点侧的分工高核心对象区Deployment、StatefulSet、DaemonSet、Job控制器选型与各自约束高调度与编排区调度器流程、亲和性、污点容忍、资源请求面对异常调度时有没有排查思路高网络与存储区Service、Ingress、PV/PVC、CNI链路是否完整最容易暴露半桶水中排障与进阶区故障排查、HPA、配额、安全上下文有没有实战经验能不能讲出过程中这五个分区不是平均用力。按我辅导过的人来看核心对象区和调度编排区的题目在面试中出现的概率最高网络与存储区是翻车重灾区因为这两块光靠背概念是答不深的。2.2 按“二八法则”排优先级四周完成第一轮128 题看上去量很大实际上大量题目是同一考点的不同问法。比如“Deployment 滚动更新怎么控制速率”和“Deployment 回滚怎么操作”本质上都在考你对控制器状态机的理解这两类题可以合并准备。我建议按下面这个节奏推进四周刷完第一轮。周次主攻区产出物第一周基础与架构区 核心对象区能画出示意链路图说清一个请求如何从 API Server 到 Pod第二周调度与编排区 网络区能现场手写核心对象的清单文件说出关键字段含义第三周存储区 排障区能按固定顺序排查一个故障案例第四周全量随机抽题按面试节奏模拟每道题限时 3 到 5 分钟操作上我在第一轮没有直接背答案而是先看题目自己想一遍这题在问什么考的是哪个组件我工作中碰过没有想不出来再去翻集锦里的参考解答把解答当成对照材料而不是背诵材料。2.3 用题目自测时按“卡点四列”做记录刷题集锦时大多数人只会在题目旁边打个勾表示“看过了”。这个习惯的坏处是一周后你回头看根本想不起来当时卡在哪里。我会用一个四列表格记录每一次自测的结果。题目方向我的回答要点卡在哪里下一步动作Pod 重启策略只答了 Always/OnFailure/Never说不清和探针配合的边界复述探针失败时的重启流程Service 类型答了 ClusterIP/NodePort解释不了 ClusterIP 的虚拟 IP 怎么转发用 tcpdump 抓一次包验证HPA 扩缩容答了 CPU 触发不知道自定义指标怎么接入搭一个基于 Prometheus 的 HPA demo这个记录表的核心价值在于把“不会”从结果变成了下一步动作。每次刷题结束我只看“卡在哪里”这一列就能精确知道这一轮复习要补什么而不是把时间平摊到所有题目上。3. 高频考点逐个过从 Pod 调度原理到控制器选型拆出可复述的答题骨架3.1 Pod 卡在 Pending一条排查命令带出整条生命周期链路“Pod 一直 Pending”几乎是我见过出现频率最高的场景题它会连环追问出调度器、资源请求、污点和容忍一整串考点。答题的起点不是背诵概念而是先给出一条真实的排查命令。# 先看 Pod 当前状态确认确实卡在 Pending kubectl get pod -n namespace # 用 describe 看事件Pending 的根因几乎都在 Events 段里 kubectl describe pod pod-name -n namespace执行逻辑是get 命令先确认状态没有变化describe 命令定位到调度器给出的具体拒绝原因。describe 输出里要重点看 Events 段常见就那么三类节点资源不足、镜像拉取失败、调度约束不满足。这三类分别对应三条链路资源不足看节点可用量镜像问题看拉取策略和仓库连通性调度约束看 nodeSelector、亲和性、污点这三样配置。答题时我会把原理和现象合在一起说调度器为 Pod 找到一个满足资源请求的节点如果所有节点都不满足Pod 就留在 Pending。然后立刻补一句“资源请求不等于资源限制”请求是调度依据限制是运行时约束。这句话很关键因为至少有半数人会把 requests 和 limits 混为一谈。3.2 控制器选型题Deployment、StatefulSet、DaemonSet 一句话说清区别控制器类题目在 128 题集锦里占比不低考法通常是“什么场景用哪个控制器”。我给出一套可以稳定复述的对比框架。控制器核心特征适用场景面试必带出的点Deployment无状态、随机标识、共享存储可选Web 服务、API 服务滚动更新与回滚机制StatefulSet有状态、稳定网络标识、每个副本独立存储数据库、消息队列、ZooKeeper 类集群稳定标识依赖 serviceNameDaemonSet每个节点一个副本日志采集、监控采集、网络插件节点新增时自动扩容手写 StatefulSet 清单是面试里常见的要求我一般会写下面这个最小可运行版本。apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: serviceName: web replicas: 3 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80 name: web这里最容易被追问的是 serviceName 字段它让每个 Pod 获得一个稳定的 DNS 名称格式是 $(statefulset名)-$(序号).$(service名)。解析到对应 Pod 的 IP而不是通过 Service 负载均衡。换句话说没有 serviceNameStatefulSet 的稳定网络标识就不成立。这一句说出来面试官就知道你不是只背了清单模板。3.3 Service 的 ClusterIP 到底怎么工作从虚拟 IP 到 endpoints网络区的题目里ClusterIP 的实现原理是必考项。很多人能说出“Service 有三种类型”但被问到“ClusterIP 是怎么把流量转到 Pod 的”就卡住了。答题主干就三句话ClusterIP 是一个虚拟 IP真正干活的是它背后的 endpoints 列表转发动作由节点上的 kube-proxy 完成。# 查看 Service 背后的 endpoints 是否就绪 kubectl get endpoints service-name # 查看 Service 的详细信息重点关注 selector 和 ports kubectl describe svc service-name如果 describe 出来的 endpoints 列表是空的问题基本都出在 selector 和 Pod 标签不匹配这是最常见的排查路径。kube-proxy 的工作模式有两种iptables 和 IPVS。iptables 模式是逐条规则匹配规则多的时候性能容易掉IPVS 模式用内核哈希表吞吐更高。现在新集群大多默认 IPVS但面试时两种模式都要能说清。我会再补一个容易被忽略的细节ClusterIP 的 Service 做的是四层转发不关心 HTTP 协议内容要做域名和路径维度的路由得靠 Ingress。这个边界想不清楚遇到“Service 和 Ingress 有什么区别”这种题就会答混。3.4 调度器题资源请求、亲和性与污点容忍的组合用法调度器相关题目是集锦里变化最多的一类因为它可以把多个机制组合起来考。一个典型问法是“有两个节点一个打了标签一个有污点Pod 怎么调度”。# 调度约束组合示例节点选择 容忍 spec: nodeSelector: disktype: ssd tolerations: - key: dedicated operator: Equal value: gpu effect: NoSchedule containers: - name: app image: nginx:1.25这个清单里其实藏了三层逻辑nodeSelector 指定必须是打了 disktypessd 标签的节点tolerations 让 Pod 可以容忍 dedicatedgpu 的污点但容忍不等于强制调度到该节点只是“允许”调度到这个节点。如果要强制绑定得加 nodeAffinity 的 requiredDuringSchedulingIgnoredDuringExecution。operator 字段有两个值需要分清Equal 表示键值都匹配Exists 表示只要键存在即可不需要管值。我在面试时被追问过这个区别当时只记得 EqualExpists 那个拼写都答错了这种细节失分很不值。4. 面试答题的方法论把知识点组织成面试官听得懂的答案结构4.1 结论先行把考点压缩成一分钟能讲完的结论技术面试有一个常见的失败模式面试官问“Pod 为什么会被重新调度”候选人从 Pod 是什么开始讲绕了三分钟还没到重点。面试官其实不是不知道基础概念他想听的是你能不能在 60 秒内给出有效信息。我习惯把每个考点先压缩成一个一句话结论先抛结论再展开。以“Pod 为什么会被重新调度”为例一句话结论是节点资源不足、节点故障或节点被主动封锁时调度器会把 Pod 调度到别的可用节点。然后展开三点资源维度看 requests 和节点可分配量故障维度看 node controller 的判定时间主动维度看 cordon 和 drain 操作。这套结构能让面试官快速判断你对这个点有没有体系化的认识。4.2 场景题的回答套路先现象、再排查、后根因集锦里有一类题给的不是概念而是场景比如“Pod 一直 CrashLoopBackOff 怎么处理”。这类题考的已经不是记忆而是你有没有真实处理过问题。我推荐一套固定的回答框架按这个顺序讲不会乱。第一步描述现象确认路径先 kubectl get pod 看状态再 kubectl describe pod 看事件。第二步按顺序排查CrashLoopBackOff 的核心是容器启动后崩溃被不断重启所以要看日志定位崩溃原因命令是 kubectl logs 加 --previous 参数看上一次崩溃的输出。第三步给根因和修复方向常见原因是启动命令参数错误、探针配置过严、依赖的服务还没就绪修复方式分别对应调整启动参数、放宽探针、检查依赖。# 查看上一次崩溃的容器日志CrashLoopBackOff 排查的关键命令 kubectl logs pod-name --previous -n namespace很多人栽在这一题上是因为一上来就改配置不讲排查过程。面试官想看的是你的排查顺序是否合理会不会用 --previous 这种细节参数。把这个命令带出来就已经比大多数候选人强了。4.3 被追问怎么接承认边界同时给出验证路径面试里最怕的不是被问倒而是被问倒之后开始编。集锦里有些题的答案本身就有版本边界和适用条件面试官追问深了超出你实践范围是正常的。我总结了一个相对稳的应对句式这个点我没有在生产环境验证过但我可以这样来验证。比如被问到“大量 Pod 同时启动时 API Server 会不会过载”如果你没压过不要硬答“不会”。你可以说我没做过大规模压测但以我对 API Server 的理解它会优先保证一致性大量并发写入时 etcd 会成为瓶颈我会用 kubectl 的请求日志和 etcd 的监控指标来验证这个判断。这一句话同时展示了诚实和排查能力比编一个数字强得多。5. 刷题与面试的避坑清单5 个让简历和答案一起翻车的常见问题5.1 只背答案不背场景追问一到两层就露馅现象概念题答得很顺“Deployment 的滚动更新是什么”能背出一整段但面试官换成“线上发布把副本数从 3 改成 10观察什么指标”就卡住。原因答案背的是文字顺序不是因果关系。滚动更新的本质是控制新旧 ReplicaSet 的副本比例没动手操作过就不知道实际要看 Pod 状态和事件。解决每个概念题旁边补一个场景自问。背完“滚动更新”立刻追问自己“maxSurge 和 maxUnavailable 分别控制什么”并把两个参数的默认值说出来。说不出来就回去查查完再自问一遍。5.2 把版本特性当通用答案被问“从哪个版本开始”就沉默现象答“这个功能用 xxx 字段实现”面试官追问“这个字段哪个版本 GA 的、之前用什么替代”答不上来。原因集锦里的答案往往只针对一个版本范围很多特性是 alpha、beta、stable 逐步演进的。直接把最新版本的行为当默认行为讲等于把边界抹掉了。解决凡涉及特性先声明版本边界。不确定时用“我主要用的是 1.2x 版本这个特性在那个版本里已经是 stable之前的情况我需要确认”这个句式比假装都知道要好。5.3 命令记忆没跟概念绑定手写命令时现场翻车现象能解释清楚 Service 的原理但被要求现场输入一条查看 endpoints 的命令时把 get 和 describe 混用或者忘记加 -n 指定命名空间。原因把命令当独立知识背了没有和“原理里的哪一环”对应起来。describe 对应事件和状态get 对应列表和概要logs 对应容器输出这些命令各自服务的排查阶段不一样。解决每学一个概念强制配一条排查命令。学完调度原理配 kubectl describe pod 看调度事件学完 Service配 kubectl get endpoints 看后端是否就绪。让命令成为概念的验证工具而不是孤立记忆。5.4 简历写“精通 k8s”但题目只覆盖到基础概念现象简历里写了“精通 Kubernetes”面试官直接按资深标准问 HPA 自定义指标、多集群管理答不上来。原因标题集锦覆盖的是通用知识面“精通”意味着你能处理边界情况两者不是一回事。简历写得越高面试官问得越深这是自找的难度。解决简历里写“熟悉”而不是“精通”并在项目中具体写用过哪些能力比如“负责过服务网格边车注入”让面试官在你能覆盖的范围内提问。5.5 只刷题不实操所有回答都停留在“听说过”现象被问 “Pod 重建后 IP 变了怎么办”能背出“用 Service 固定访问入口”但被追问“Service 的 endpoints 是怎么更新的”就说不上来了。原因没有亲手操作过 Pod 重建没见过 endpoints 列表在 Pod 删除后自动摘除的过程对这套机制的印象是抽象的。解决本地搭一个最小集群亲手做一次实验创建 Deployment、记录 Pod IP、删除 Pod、观察新的 IP 和 endpoints 的变化。这个实验只需要十几分钟但做完之后你对 Service 和 endpoints 的理解会发生本质变化。6. 从刷题到体系5 个验证动作确认 128 题真的长在你身上刷完第一轮题目后最需要做的不是二刷而是验证自己能不能脱离集锦独立输出。我常用 5 个动作做验证。第一个动作是自讲 30 分钟随机抽 10 道题不看材料每道题讲三分钟用手机录音回放时重点听自己哪里停顿、哪里说得含糊。含糊的地方就是要补的盲区。第二个动作是故障注入演练在自己的测试集群里制造真实故障比如手动给节点打上污点或者把镜像 tag 改成一个不存在的版本然后只靠命令去定位。这个动作直接检验第 3 章和第 5 章里所有排查思路是不是真的能用。第三个动作是写排查笔记每次演练结束把现象、排查命令、根因、修复动作整理成一篇短文。写作会逼你把零散的命令串成逻辑链这一步对记忆的巩固效果远大于再背一遍答案。第四个动作是题目归并练习把 128 题按自己的理解重新合并成 40 题左右合并标准是“同一个原理能答通的一组题就放一起”。如果发现某道题你合并不进去说明你还没理解它在考什么。第五个动作是主动引导把最熟的一个方向练到能主动带节奏。面试是对话你完全可以在答完一道题之后自然补一句“这块我在生产环境还碰到过一个相关的问题那次是……”把话题引到你熟悉的领域里。这就从被动答题变成了主动展示。我自己刷这套题时吃过最大的亏就是以为背完答案就结束了结果第一次模拟面试被问得原形毕露。后来改成“当讲师”的方式每道题都讲给别人听讲不出来就回去查查完再讲一遍才真正把题目变成自己的能力。这条路没有捷径但用对方法128 题刷一遍的效果能超过别人盲目刷三遍。希望帮到你。本文还有配套的精品资源点击获取 K8s面试128题：从Pod调度到控制器选型，掌握原理才能通关
简介这是一份面向Kubernetes相关岗位求职者的面试题库合集收录128道高频云原生与K8s面试题覆盖etcd原理、Pod调度、集群管理、部署方式、服务发现等核心主题。资源包共1个PDF文件整体大小约2.73MB既便于按目录速览也适合打印或导入阅读器反复研读。目前已有4636人学习下载题目组织从基础概念到运维实践逐层递进适合正在准备K8s/Docker面试的初中级工程师查漏补缺。PDF中不仅给出了结论性答案还围绕Raft一致性算法、Replication Controller副本控制、分布式锁与Leader竞选等经典考点展开说明可帮助读者理解背后的设计思想与常见误区提升面试应答深度。对于希望快速建立云原生知识框架、强化容器编排理解、增加面试过关率的求职者来说是一份实用的备查资料。1. 128 道 k8s 面试题集锦为什么背完答案还是过不了面试面试前我把这套 128 题的云原生与 k8s 面试集锦从头到尾刷了两遍答案背得滚瓜烂熟结果一面就被一个“Pod 一直 Pending 你怎么查”问住了。不是因为题没刷到而是我只会背结论不会讲过程。这套 128 题集锦覆盖面确实够广从容器基础、Pod 调度到集群排障都有涉及适合三类人准备求职的开发者、要在团队内做技术分享的负责人、想系统查漏补缺的运维。它的正确用法不是背答案而是拿题目当引子把每个考点扩成一条能讲清楚原理、操作和排查思路的完整链路。这篇就按这个思路把这 128 题拆成一张可执行的学习地图。2. 给 128 题建一张知识地图把题目按考点拆成五个复习区2.1 先按考察意图分类而不是按题目序号刷拿到一份 128 题的集锦最忌讳的做法是从第 1 题按顺序刷到第 128 题。题目的排列顺序往往不是按知识体系排的前面可能是概念题中间突然跳到一个冷门的存储细节顺序刷会让你的大脑在几类思维模式之间来回切换记忆效率很低。我一般会把题目先打散按考察意图重新归类。复习区题目覆盖方向核心考察点优先级基础与架构区容器与镜像、Pod 基础、k8s 组件职责能不能说清控制面与节点侧的分工高核心对象区Deployment、StatefulSet、DaemonSet、Job控制器选型与各自约束高调度与编排区调度器流程、亲和性、污点容忍、资源请求面对异常调度时有没有排查思路高网络与存储区Service、Ingress、PV/PVC、CNI链路是否完整最容易暴露半桶水中排障与进阶区故障排查、HPA、配额、安全上下文有没有实战经验能不能讲出过程中这五个分区不是平均用力。按我辅导过的人来看核心对象区和调度编排区的题目在面试中出现的概率最高网络与存储区是翻车重灾区因为这两块光靠背概念是答不深的。2.2 按“二八法则”排优先级四周完成第一轮128 题看上去量很大实际上大量题目是同一考点的不同问法。比如“Deployment 滚动更新怎么控制速率”和“Deployment 回滚怎么操作”本质上都在考你对控制器状态机的理解这两类题可以合并准备。我建议按下面这个节奏推进四周刷完第一轮。周次主攻区产出物第一周基础与架构区 核心对象区能画出示意链路图说清一个请求如何从 API Server 到 Pod第二周调度与编排区 网络区能现场手写核心对象的清单文件说出关键字段含义第三周存储区 排障区能按固定顺序排查一个故障案例第四周全量随机抽题按面试节奏模拟每道题限时 3 到 5 分钟操作上我在第一轮没有直接背答案而是先看题目自己想一遍这题在问什么考的是哪个组件我工作中碰过没有想不出来再去翻集锦里的参考解答把解答当成对照材料而不是背诵材料。2.3 用题目自测时按“卡点四列”做记录刷题集锦时大多数人只会在题目旁边打个勾表示“看过了”。这个习惯的坏处是一周后你回头看根本想不起来当时卡在哪里。我会用一个四列表格记录每一次自测的结果。题目方向我的回答要点卡在哪里下一步动作Pod 重启策略只答了 Always/OnFailure/Never说不清和探针配合的边界复述探针失败时的重启流程Service 类型答了 ClusterIP/NodePort解释不了 ClusterIP 的虚拟 IP 怎么转发用 tcpdump 抓一次包验证HPA 扩缩容答了 CPU 触发不知道自定义指标怎么接入搭一个基于 Prometheus 的 HPA demo这个记录表的核心价值在于把“不会”从结果变成了下一步动作。每次刷题结束我只看“卡在哪里”这一列就能精确知道这一轮复习要补什么而不是把时间平摊到所有题目上。3. 高频考点逐个过从 Pod 调度原理到控制器选型拆出可复述的答题骨架3.1 Pod 卡在 Pending一条排查命令带出整条生命周期链路“Pod 一直 Pending”几乎是我见过出现频率最高的场景题它会连环追问出调度器、资源请求、污点和容忍一整串考点。答题的起点不是背诵概念而是先给出一条真实的排查命令。# 先看 Pod 当前状态确认确实卡在 Pending kubectl get pod -n namespace # 用 describe 看事件Pending 的根因几乎都在 Events 段里 kubectl describe pod pod-name -n namespace执行逻辑是get 命令先确认状态没有变化describe 命令定位到调度器给出的具体拒绝原因。describe 输出里要重点看 Events 段常见就那么三类节点资源不足、镜像拉取失败、调度约束不满足。这三类分别对应三条链路资源不足看节点可用量镜像问题看拉取策略和仓库连通性调度约束看 nodeSelector、亲和性、污点这三样配置。答题时我会把原理和现象合在一起说调度器为 Pod 找到一个满足资源请求的节点如果所有节点都不满足Pod 就留在 Pending。然后立刻补一句“资源请求不等于资源限制”请求是调度依据限制是运行时约束。这句话很关键因为至少有半数人会把 requests 和 limits 混为一谈。3.2 控制器选型题Deployment、StatefulSet、DaemonSet 一句话说清区别控制器类题目在 128 题集锦里占比不低考法通常是“什么场景用哪个控制器”。我给出一套可以稳定复述的对比框架。控制器核心特征适用场景面试必带出的点Deployment无状态、随机标识、共享存储可选Web 服务、API 服务滚动更新与回滚机制StatefulSet有状态、稳定网络标识、每个副本独立存储数据库、消息队列、ZooKeeper 类集群稳定标识依赖 serviceNameDaemonSet每个节点一个副本日志采集、监控采集、网络插件节点新增时自动扩容手写 StatefulSet 清单是面试里常见的要求我一般会写下面这个最小可运行版本。apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: serviceName: web replicas: 3 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80 name: web这里最容易被追问的是 serviceName 字段它让每个 Pod 获得一个稳定的 DNS 名称格式是 $(statefulset名)-$(序号).$(service名)。解析到对应 Pod 的 IP而不是通过 Service 负载均衡。换句话说没有 serviceNameStatefulSet 的稳定网络标识就不成立。这一句说出来面试官就知道你不是只背了清单模板。3.3 Service 的 ClusterIP 到底怎么工作从虚拟 IP 到 endpoints网络区的题目里ClusterIP 的实现原理是必考项。很多人能说出“Service 有三种类型”但被问到“ClusterIP 是怎么把流量转到 Pod 的”就卡住了。答题主干就三句话ClusterIP 是一个虚拟 IP真正干活的是它背后的 endpoints 列表转发动作由节点上的 kube-proxy 完成。# 查看 Service 背后的 endpoints 是否就绪 kubectl get endpoints service-name # 查看 Service 的详细信息重点关注 selector 和 ports kubectl describe svc service-name如果 describe 出来的 endpoints 列表是空的问题基本都出在 selector 和 Pod 标签不匹配这是最常见的排查路径。kube-proxy 的工作模式有两种iptables 和 IPVS。iptables 模式是逐条规则匹配规则多的时候性能容易掉IPVS 模式用内核哈希表吞吐更高。现在新集群大多默认 IPVS但面试时两种模式都要能说清。我会再补一个容易被忽略的细节ClusterIP 的 Service 做的是四层转发不关心 HTTP 协议内容要做域名和路径维度的路由得靠 Ingress。这个边界想不清楚遇到“Service 和 Ingress 有什么区别”这种题就会答混。3.4 调度器题资源请求、亲和性与污点容忍的组合用法调度器相关题目是集锦里变化最多的一类因为它可以把多个机制组合起来考。一个典型问法是“有两个节点一个打了标签一个有污点Pod 怎么调度”。# 调度约束组合示例节点选择 容忍 spec: nodeSelector: disktype: ssd tolerations: - key: dedicated operator: Equal value: gpu effect: NoSchedule containers: - name: app image: nginx:1.25这个清单里其实藏了三层逻辑nodeSelector 指定必须是打了 disktypessd 标签的节点tolerations 让 Pod 可以容忍 dedicatedgpu 的污点但容忍不等于强制调度到该节点只是“允许”调度到这个节点。如果要强制绑定得加 nodeAffinity 的 requiredDuringSchedulingIgnoredDuringExecution。operator 字段有两个值需要分清Equal 表示键值都匹配Exists 表示只要键存在即可不需要管值。我在面试时被追问过这个区别当时只记得 EqualExpists 那个拼写都答错了这种细节失分很不值。4. 面试答题的方法论把知识点组织成面试官听得懂的答案结构4.1 结论先行把考点压缩成一分钟能讲完的结论技术面试有一个常见的失败模式面试官问“Pod 为什么会被重新调度”候选人从 Pod 是什么开始讲绕了三分钟还没到重点。面试官其实不是不知道基础概念他想听的是你能不能在 60 秒内给出有效信息。我习惯把每个考点先压缩成一个一句话结论先抛结论再展开。以“Pod 为什么会被重新调度”为例一句话结论是节点资源不足、节点故障或节点被主动封锁时调度器会把 Pod 调度到别的可用节点。然后展开三点资源维度看 requests 和节点可分配量故障维度看 node controller 的判定时间主动维度看 cordon 和 drain 操作。这套结构能让面试官快速判断你对这个点有没有体系化的认识。4.2 场景题的回答套路先现象、再排查、后根因集锦里有一类题给的不是概念而是场景比如“Pod 一直 CrashLoopBackOff 怎么处理”。这类题考的已经不是记忆而是你有没有真实处理过问题。我推荐一套固定的回答框架按这个顺序讲不会乱。第一步描述现象确认路径先 kubectl get pod 看状态再 kubectl describe pod 看事件。第二步按顺序排查CrashLoopBackOff 的核心是容器启动后崩溃被不断重启所以要看日志定位崩溃原因命令是 kubectl logs 加 --previous 参数看上一次崩溃的输出。第三步给根因和修复方向常见原因是启动命令参数错误、探针配置过严、依赖的服务还没就绪修复方式分别对应调整启动参数、放宽探针、检查依赖。# 查看上一次崩溃的容器日志CrashLoopBackOff 排查的关键命令 kubectl logs pod-name --previous -n namespace很多人栽在这一题上是因为一上来就改配置不讲排查过程。面试官想看的是你的排查顺序是否合理会不会用 --previous 这种细节参数。把这个命令带出来就已经比大多数候选人强了。4.3 被追问怎么接承认边界同时给出验证路径面试里最怕的不是被问倒而是被问倒之后开始编。集锦里有些题的答案本身就有版本边界和适用条件面试官追问深了超出你实践范围是正常的。我总结了一个相对稳的应对句式这个点我没有在生产环境验证过但我可以这样来验证。比如被问到“大量 Pod 同时启动时 API Server 会不会过载”如果你没压过不要硬答“不会”。你可以说我没做过大规模压测但以我对 API Server 的理解它会优先保证一致性大量并发写入时 etcd 会成为瓶颈我会用 kubectl 的请求日志和 etcd 的监控指标来验证这个判断。这一句话同时展示了诚实和排查能力比编一个数字强得多。5. 刷题与面试的避坑清单5 个让简历和答案一起翻车的常见问题5.1 只背答案不背场景追问一到两层就露馅现象概念题答得很顺“Deployment 的滚动更新是什么”能背出一整段但面试官换成“线上发布把副本数从 3 改成 10观察什么指标”就卡住。原因答案背的是文字顺序不是因果关系。滚动更新的本质是控制新旧 ReplicaSet 的副本比例没动手操作过就不知道实际要看 Pod 状态和事件。解决每个概念题旁边补一个场景自问。背完“滚动更新”立刻追问自己“maxSurge 和 maxUnavailable 分别控制什么”并把两个参数的默认值说出来。说不出来就回去查查完再自问一遍。5.2 把版本特性当通用答案被问“从哪个版本开始”就沉默现象答“这个功能用 xxx 字段实现”面试官追问“这个字段哪个版本 GA 的、之前用什么替代”答不上来。原因集锦里的答案往往只针对一个版本范围很多特性是 alpha、beta、stable 逐步演进的。直接把最新版本的行为当默认行为讲等于把边界抹掉了。解决凡涉及特性先声明版本边界。不确定时用“我主要用的是 1.2x 版本这个特性在那个版本里已经是 stable之前的情况我需要确认”这个句式比假装都知道要好。5.3 命令记忆没跟概念绑定手写命令时现场翻车现象能解释清楚 Service 的原理但被要求现场输入一条查看 endpoints 的命令时把 get 和 describe 混用或者忘记加 -n 指定命名空间。原因把命令当独立知识背了没有和“原理里的哪一环”对应起来。describe 对应事件和状态get 对应列表和概要logs 对应容器输出这些命令各自服务的排查阶段不一样。解决每学一个概念强制配一条排查命令。学完调度原理配 kubectl describe pod 看调度事件学完 Service配 kubectl get endpoints 看后端是否就绪。让命令成为概念的验证工具而不是孤立记忆。5.4 简历写“精通 k8s”但题目只覆盖到基础概念现象简历里写了“精通 Kubernetes”面试官直接按资深标准问 HPA 自定义指标、多集群管理答不上来。原因标题集锦覆盖的是通用知识面“精通”意味着你能处理边界情况两者不是一回事。简历写得越高面试官问得越深这是自找的难度。解决简历里写“熟悉”而不是“精通”并在项目中具体写用过哪些能力比如“负责过服务网格边车注入”让面试官在你能覆盖的范围内提问。5.5 只刷题不实操所有回答都停留在“听说过”现象被问 “Pod 重建后 IP 变了怎么办”能背出“用 Service 固定访问入口”但被追问“Service 的 endpoints 是怎么更新的”就说不上来了。原因没有亲手操作过 Pod 重建没见过 endpoints 列表在 Pod 删除后自动摘除的过程对这套机制的印象是抽象的。解决本地搭一个最小集群亲手做一次实验创建 Deployment、记录 Pod IP、删除 Pod、观察新的 IP 和 endpoints 的变化。这个实验只需要十几分钟但做完之后你对 Service 和 endpoints 的理解会发生本质变化。6. 从刷题到体系5 个验证动作确认 128 题真的长在你身上刷完第一轮题目后最需要做的不是二刷而是验证自己能不能脱离集锦独立输出。我常用 5 个动作做验证。第一个动作是自讲 30 分钟随机抽 10 道题不看材料每道题讲三分钟用手机录音回放时重点听自己哪里停顿、哪里说得含糊。含糊的地方就是要补的盲区。第二个动作是故障注入演练在自己的测试集群里制造真实故障比如手动给节点打上污点或者把镜像 tag 改成一个不存在的版本然后只靠命令去定位。这个动作直接检验第 3 章和第 5 章里所有排查思路是不是真的能用。第三个动作是写排查笔记每次演练结束把现象、排查命令、根因、修复动作整理成一篇短文。写作会逼你把零散的命令串成逻辑链这一步对记忆的巩固效果远大于再背一遍答案。第四个动作是题目归并练习把 128 题按自己的理解重新合并成 40 题左右合并标准是“同一个原理能答通的一组题就放一起”。如果发现某道题你合并不进去说明你还没理解它在考什么。第五个动作是主动引导把最熟的一个方向练到能主动带节奏。面试是对话你完全可以在答完一道题之后自然补一句“这块我在生产环境还碰到过一个相关的问题那次是……”把话题引到你熟悉的领域里。这就从被动答题变成了主动展示。我自己刷这套题时吃过最大的亏就是以为背完答案就结束了结果第一次模拟面试被问得原形毕露。后来改成“当讲师”的方式每道题都讲给别人听讲不出来就回去查查完再讲一遍才真正把题目变成自己的能力。这条路没有捷径但用对方法128 题刷一遍的效果能超过别人盲目刷三遍。希望帮到你。本文还有配套的精品资源点击获取