简介：面向准备云原生与Kubernetes相关岗位面试的开发者，这份面试题集锦精选了128道高频考题，内容覆盖ETCD的核心特性与应用场景（如服务发现、消息发布订阅、分布式锁、Leader选举）、Kubernetes与Docker的关系、常见的集群部署方式、Pod/Service/Label等基础对象，以及Master与Node的职责分工和集群管理机制等。每题均配有细致解析，从概念原理到面试题问法分层拆解，既方便快速回忆，也能深入理解易错细节。打包内容为单个PDF文件，完整文档约2.73MB，结构清晰，可按专题翻阅，适合笔试冲刺、面试前一小时快速过一遍。目前已有4636人学习下载，经过大量求职者实测，能有效检验知识薄弱点、补齐云原生认知短板。把这128题学透，既可系统梳理容器编排技术主干，也能掌握面试官追问背后的设计思路，提升通过率。

1. 云原生与K8s面试题集锦：128题的规模为什么刚好够用

聊到云原生方向的K8s面试题集锦，最常见的问题不是“某道题我会不会”，而是“这个体量到底怎么用”。128道题，说少不少，说多也不算多，恰好卡在一个微妙的区间：比“几十道精选”更系统，又比“几百道大而全”更适合逐题消化。我的真实感受是，面向K8s面试准备，真正的瓶颈从来不是题目数量，而是题目之间能不能连成知识网络——比如面试官问“Pod重建后IP会不会变”，其实是在等你把Deployment、StatefulSet、Headless Service、Service负载均衡串成一条线。

这篇笔记就按128题这个规模展开，讲三件事：题目应该如何按主题分配、高频题型怎么答才能让面试官觉得你“真做过”、准备过程中最容易踩的坑在哪。最后给一套把题集变成自己专属题库的进阶用法。内容面向准备K8s面试的开发、运维和SRE，也适合想用题目检验团队云原生水平的负责人——你可以直接拿这个框架去组一轮内部自测。

2. 读薄128题：主题分布、难度分层与三轮自测节奏

拿到128题之后，第一件事不是埋头刷，而是先把题目“读薄”。一套合格题集必须有明确的结构感，否则刷到第50题时你会彻底忘了前面40题在考什么。我见过不少候选人拿着一份几百道的大题库反复翻，最后记住的永远是开头那几道主题重复的题，恰恰是这种无结构刷题，最容易在面试现场暴露出知识盲区。

2.1 主题拆解：128题应该落在哪些方向

如果让我来设计一套128题规模的K8s面试题集，会按下面的比例分配主题。这个分布不是我拍脑袋想的，而是根据面试高频考点和线上运维事故的高发区域倒推出来的：

这里Pod与工作负载和网络各占大头，是因为它们在真实面试追问中出现频率最高。存储和安全每道题都能引出生产环境的核心考题，建议权重等同。常见做法是把故障排查类题目穿插进每个主题里问，而不是单独集中——比如问完Service再追问“ClusterIP访问不通怎么排查”，这种组合出题方式比单题更能区分候选人的实战经验。你手里的128题如果分布跟这张表明显不一致，比如存储只有3道而镜像占了30道，那就需要警惕题目来源的偏科问题。

2.2 三轮扫题法与标记体系

题目分好类之后，我一般会按“三轮扫题法”推进，而不是从头到尾逐题刷。这套方法的核心理念是先求覆盖、再求深度，避免在前几道难题上卡太久导致整体节奏失控。

第一轮：按主题全量扫题，每道题只给自己三种标记——懂、半懂、不懂。这一轮的目标是建立全局认知，不追求答对，更不追求背熟。半懂和不懂的题加起来超过一半是非常正常的，别慌，这说明你找到了自己的真实边界。要求是这一轮在5到7天内完成，每天处理一个主题。

第二轮：只刷半懂和不懂的题，每道题把答案压缩成三句话。三句话是硬约束：一句讲原理、一句讲命令或配置、一句讲出现什么问题怎么排查。压不到三句说明理解还有空洞，必须回补。这一轮是128题里最耗时间的阶段，建议每天只深入消化10道题，宁可少做也要完整。

第三轮：白纸复述。拿出一张A4纸，不看任何笔记，把你认定的高频题按主题默写出来——包括核心命令、关键参数、易错点。默写不出来的题目就是最后的漏网之鱼，也是你最需要“后悔药”的地方。做过三轮你会发现，真正需要反复看的题可能只有20到30道，此时这份题集已经被你“读薄”了。可以用下面这个模板跟踪进度，每道题一行记录，考前只看标红的行：

| 主题 | 题号 | 首轮标记 | 第二轮日期 | 白纸复述 | 备注 | |---|---|---|---|---|---| | 网络 | 084 | 半懂 | 11-05 | 通过 | Service 会话保持追问没答全 | | 存储 | 073 | 不懂 | 11-06 | 未通过 | PV 回收策略 Recycle 已废弃 |

逻辑说明：这个模板的核心作用是把“我好像看过”变成“我确实记住”。状态列必须具体，不能只写“复习了”，要写“通过”或“未通过”，这样第三轮才能精准定位薄弱点。备注列记录追问卡壳的地方，补全这个细节之后，题集才开始变成“你的”题库。参数方面，首轮标记建议用三种状态就够了，不要细分“大概懂”“也许懂”这种模糊状态，否则第二轮没法排序优先级。

2.3 从一道题长出追问链：错题反推知识缺口

单一题目只是面试考察的起点，面试官几乎一定会在你的回答里找追问方向。这就是为什么很多候选人觉得自己背了很多题，面试下来却说“问题我全见过，但就是答不到点上”。因为记忆的是孤立答案，而不是知识之间的连接。

以“Pod重建后IP会不会变”这道题为例：初级回答是“会变，因为IP不固定”，面试官接着问“那Deployment滚动更新时IP变化，下游服务怎么感知”？如果答“通过Service的ClusterIP访问就行”，面试官又问“StatefulSet的Pod IP也变吗，它的网络标识靠什么维持”？到这一层，你会发现单纯的Pod题已经延伸到了Service机制和StatefulSet原理。如果再往下走，“Headless Service的A记录怎么解析”，题目就从存储题变成了DNS解析题。

这就是我常说的“追问链”。准备128题时，每道题都按“这道题会引出哪三个追问”做一次扩展练习。扩展完了就写5.1那类错题笔记。不要想着把题库里所有题都做一次追问链，时间不值得。只对首轮标“半懂”的题做就够，这个数量通常只有四十道上下。真正的面试场上有时候你答到一半，面试官就会示意换下一题——那不是你答得差，恰恰是你答到了追问链的终点。别慌，这说明这道题你已经过关了。

三句话压缩实例也可以直接套用：比如“Pod启动失败”这道题，三句话版本是“先用kubectl get events看调度事件，再用kubectl describe pod看Status与Conditions，最后kubectl logs看容器输出”。这三句话本身就是一道排查题的标准答题骨架，比背十句原理更实用。

3. 高频题怎么答：原理、YAML实操与故障排查三条线

128题里真正决定面试结果的，从来不是那些“说说Docker和虚拟机区别”的热身题，而是三类能看出实战深度的高频大题：原理题、YAML实操题、故障排查题。这三类题共同的特点是都能连环追问，且追问深度没有上限。把这三条线理透了，基本能在面试里覆盖掉八成以上的生产场景。

3.1 原理题答题骨架：从“知道是什么”到“讲得出为什么”

原理题最怕的回答方式是背诵式的“因为所以”。比如问etcd为什么选Raft协议而不选别的共识算法，很多人一张嘴就“Raft是共识算法，etcd用它保证数据一致”，这句话挑不出毛病，但也拿不到加分。面试官期待的是你一步步往上搭骨架，让他看见你“推导”的路径。

我用得比较顺的答题骨架是四层结构：第一层说场景约束——K8s里所有API对象都持久化在etcd，必须保证多节点数据一致；第二层说算法选型——Raft相比Paxos更容易实现且工程验证充分，选举和日志复制两条主链路清晰；第三层说部署边界——生产环境最少三节点，容忍单节点故障，超过半数节点存活才能选出leader；第四层说异常现象——etcd集群超过半数节点失联会整体只读，K8s控制面的写请求全部失败。这四层一层一层递进，面试官就算追问，也只能往你没讲过的第五层挖——比如“Raft选举里的term和vote怎么防脑裂”，这时候即便答不完美，前面四层已经建立了“你真懂etcd”的印象，否则他根本不会追问到那么深。

再举一个高频题：为什么K8s不直接用容器而要用Pod。答题骨架同样四层：一是共享资源需求——同组容器要共享网络命名空间和存储卷；二是生命周期管理需求——Pod是一组容器的调度单元，重启是整体行为；三是Sidecar模式需要——日志采集、流量代理这类辅助容器要跟主容器同生共死；四是Pause容器的定位——它负责持有Pod的网络与命名空间，业务容器重启不影响网络标识。这样答的每一层都是“需求驱动设计”，而不是“Pod就是一组容器”这种名词解释。

3.2 YAML实操题：三分钟写对一份调度配置

手写YAML是面试里最容易翻车的环节，因为平时开发环境都有自动补全和校验，一旦回到白板环境，缩进和字段位置立刻暴露熟练度。面试官的常见考法是给你一个场景：一个需要GPU的Pod，要求调度到打了GPU标签的节点上，同时容忍节点上的专用污点。你要在三分钟内写出最小组可运行配置。

我一般会按下面的模板快速起手（注意：以下yaml是部署类工作负载的标准骨架，不代表线上生产直接照抄）：

apiVersion: apps/v1 kind: Deployment metadata: name: gpu-worker spec: replicas: 2 selector: matchLabels: app: gpu-worker template: metadata: labels: app: gpu-worker spec: nodeSelector: gpu-type: a100 tolerations: - key: dedicated operator: Equal value: gpu effect: NoSchedule containers: - name: main image: registry.example/gpu-svc:1.4.2 resources: limits: nvidia.com/gpu: "1"

几个大家容易写错的地方：第一，nodeSelector用的是key: value扁平结构，不是matchLabels嵌套，别把Deployment的selector写法带到这里；第二，toleration的operator如果不写，默认是Equal，此时value必须给全，如果写operator: Exists就不要再写value字段，二选一；第三，nvidia.com/gpu这个资源名不是deployment自带的，需要节点上装了对应设备插件之后才有效，否则调度器永远找不到满足条件的节点——这个不是YAML语法问题，是资源边界问题，面试时主动提一嘴“这依赖节点设备插件，集群没装会Pending”，反而比磕磕巴巴写完加分。

写完YAML之后我习惯补一句校验方式，让面试官知道你有工程意识。最常用的是kubectl apply --dry-run=client -f gpu-worker.yaml，注意这个只能验证语法结构合法，验证不了字段语义，比如device插件缺失这种问题要kubectl apply --dry-run=server才可能暴露；更彻底的检查是看kubectl describe pod里的Events。实际面试中把这套校验链路说出来，比单纯背字段要更能拿分。

3.3 故障排查题：先看事件、再描述、最后看日志

故障排查题的核心考查点不是你会多少命令，而是你的排查顺序有没有逻辑。很多候选人在面试时一上来就说“先看Pod日志”，这其实是次优答案——日志只对运行中的容器有意义，容器还没起来或者被调度卡住时，日志根本没有输出。正确的排查顺序应该是分层递减的，因为每一层的失败原因不同，需要逐层缩小范围。

I一般按这个顺序走：能看到集群事件，先看事件；看不到事件或者事件信息不够，再describe Pod取状态细节；最后才进容器看应用日志。这个方法能定位到绝大多数面试官会出的题，比如下面这类“Pod一直Pending”的问题。先截断一条“Pod Pending”的排查命令序列：

# 1. 看集群事件，确认调度器有没有报错 kubectl get events --sort-by=.lastTimestamp | grep -i <pod-name> # 2. 看Pod的详细状态和Conditions kubectl describe pod <pod-name> -n <namespace> # 3. 确认节点资源与标签是否满足 kubectl top node kubectl get nodes --show-labels # 4. 确认调度器组件本身是否健康 kubectl get pods -n kube-system -l component=kube-scheduler

逻辑说明：第1步先看events是最省力的，调度器拒绝Pod时通常会把失败原因写进事件里，比如“0/3 nodes available”和具体的资源不足字样。如果事件里没有有效信息，第2步describe可以看Status下的Conditions，比如PodScheduled是否True，以及容器状态卡在Waiting还是Terminated。第3步查节点资源和标签，定位是污点不匹配还是资源无法满足。这个过程最重要的原则是“先看状态，再看日志”，有些面试题还把“容器OOM了怎么排查”和“节点内存不足怎么排查”混着问，两者的命令顺序完全不一样，前者直接看Pod的OOMKilled状态再查应用日志，后者要先看节点的Allocatable和实际使用量。这里有一个很实际的观念：去面试时不要把故障排查当成“背诵命令”，它本质上是二分查找——每一步都在缩小嫌疑范围。把你线下处理故障时的那套真实流程搬到回答里，就已经比大多数只背了“kubectl logs”的候选人好了。

4. 准备这套面试题的避坑记录：现象、原因与解决

前面讲的都是“怎么准备”，这一章单独说“准备过程中的坑”。这些坑不是技术难点的坑，而是备考方法本身的坑——它们不解决的话，刷题效率会非常低，甚至可能给面试埋雷。每一条都是真实发生过的翻车场景，我按现象、原因、解决三步拆解。

4.1 只背概念不手写配置，考场上缩进翻车

现象：面试官让手写一个带资源limits和livenessProbe的Deployment，候选人写完发现livenessProbe缩进到了containers外面，而且resources的requests和limits顺序写反。面试官看了一眼没说话，后续氛围直接冷掉。

原因：平时全部依赖IDE的格式化和自动补全，对YAML的层级关系缺乏肌肉记忆。背题阶段只记“有requests和limits这两个字段”，没注意它们在spec.containers[].resources下面，更没注意probe是在containers层级下的字段，与resources平级。

解决：备考阶段每天手敲一个完整YAML，不复制粘贴，敲完用kubectl apply --dry-run=client做语法校验。重点敲三次：一次Deployment，一次StatefulSet，一次Job。敲的时候默写字段层级，而不是照抄笔记。面试前两周，连续每天练一遍，考场肌肉记忆就有了。另外，手写完必须自查selector与template.labels是否匹配，这个不匹配在deployment里是常见的报错点，很多面试官会盯着这个问。

4.2 背了CNI选型表，却讲不清选型理由

现象：被追问“你们的集群为什么用这种网络方案而不是另一种”时，候选人只答出“支持网络策略、性能好”，再往下问“它跟Flannel的数据面路径有什么本质差异”就卡住。原因很明显：把选型表当成八股文背了，没有真正理解网络插件的转发模型差异。

解决：与其考前背二十个插件的优缺点，不如把两个最主流的方案彻底吃透。核心是理解vxlan模式和路由模式的本质差别：vxlan是UDP封包走隧道，跨节点通信经过VTEP设备封包解包；路由模式是直接把Pod网段路由到宿主机，通过host的IP转发。面试中把“数据面路径”这三个字讲出来，比背“支持BGP、支持网络策略”这类官方文档话术更有说服力。如果你有条件，在自己的测试集群把两个插件各部署一次，看Pod网段、看跨节点ping走的路径，比任何文档都牢固。实在没条件就用模拟集群，用ip route对比两种方案的路由表差异就行。

4.3 高可用方案只答“多master”，漏掉etcd恢复这道送命题

现象：被问“集群怎么保障高可用和容灾恢复”时，候选人流利答出“多master节点、组件高可用、数据备份”，面试官追问一句“假如所有master都挂了，你从哪开始恢复”，候选人只答“重启服务”，完全没提etcd数据。

原因：备考时把高可用理解成了“组件数量多就高可用”，忽略了一个事实——K8s控制面的唯一数据源在etcd，如果etcd数据损坏，所有组件都起来也没用。etcd这个黑匣子往往是备考里最被忽略、却在真实面试里最容易被追问的盲区。

解决：把这条链路补齐——恢复顺序不是先启动kube-apiserver，而是先恢复etcd快照，再用快照重建集群数据。至少在本地虚拟机或模拟集群里完整演练一次备份恢复流程，需要的核心命令是etcdctl snapshot save和etcdctl snapshot restore。面试时能主动说出“快照恢复到临时目录再启动etcd”的细节，就已经超过了一大批只背概念的人。切记不要空谈“有多副本就安全”，要回答“怎么验证备份可用”这个更深一层的问题——每个季度做一次恢复演练，才算真正能交付的高可用。

4.4 把“我见过某个特性”当成“我用过”

现象：面试官追问候选人的集群版本，候选人报了版本，面试官更具体的问“这个版本里某API是否已经废弃”，候选人支支吾吾。后续聊到Ingress、HPA里的某个字段，候选人说“这个配置见过”，但实际线上配置里从未用过。

原因：备考材料往往来自各种技术文章或视频，这些内容不会刻意标注Kubernetes的版本边界和废弃节奏。很多人在看教程时默认“文档写的就是当前版本能用的”，忽略了不同小版本之间API兼容性的差异，尤其是那些从extensions/v1beta1迁移到networking.k8s.io/v1的API变更，其实直接影响yaml能否被正确解析。

解决：准备面试时，所有涉及API资源和字段的题目，一律用kubectl explain核一遍再回答。这个命令能显示当前集群实际可用的API版本和字段说明，比对照网上的版本教程准确得多。面试时如果被问“某个字段在你这版能不能配”，我一般会建议不要凭记忆确认，而是如实说“我习惯用kubectl explain现场核对，避免集群版本和文档不一致导致的误判”——这比瞎猜答案可信度高太多。另外买一个低频但高区分度的习惯：考前把自己的集群版本和题集里所有yaml样例过一遍，凡是explain查不到字段的直接划掉，标注“此版本不可用”，避免面试时背到一口过时的配置。

5. 把题集变成自己的面试题库：一题多问与模拟面试

128题过完三轮之后，大多数人的准备会进入一个尴尬期：题目都眼熟，但没法判断自己到底是不是真会。这时候需要把题集从“用来练”变成“用来测”。我的习惯是两件事：一题多问扩展成追问链，以及组建三人模拟面试。

5.1 一题多问：把单题扩成追问链

拿一道高频的Ingress题举例，初级准备方式是背“Ingress是七层负载均衡，有nginx和traefik等实现”。但如果你拿这道题去问自己“还能怎么问”，会得到这样一串追问：TLS证书配置在Ingress哪个字段？更新证书后需要重启Ingress Controller吗？如果后端Service也是HTTPS，nginx应该如何透传而不重新加密？IngressClassName和旧版annotation的区别是什么？每追问一层，你都必须重新调出对应主题的知识，才能答得完整。把每道高频题都做一遍这个扩展，128题就被拆成了三四百个知识锚点，覆盖面的深度就会显著不一样。

5.2 组建三角色的模拟面试

模拟面试是验证备考成果最有效的方式，但不是随便找个人互问就行。有条件的话，找两三个同样在准备K8s面试的人组队，规模三到四人最合适，人太多每人发言次数太少。每人从128题里出10道题，面试官角色轮换，答题只用白纸不许查资料；每道题答完之后，面试官必须连环追问至少两轮，直到答题者卡壳。所有卡壳点记录在共享的错题单里，当天晚上复盘补齐。这种方式的效率，往往比独自刷三轮要高出不少，因为它能逼出“在压力下组织答案”的能力。

卡壳点记完不需要额外整理，把笔记集中在一页wiki页或文档里，标题标上日期和主题范围，后面复习直接看这页就够了。我自己的习惯是每次模拟面试结束，把卡壳的追问链画成箭头图附在那道题后面，复习时按箭头依次自问。这个习惯帮我避开了不少重复翻车——背过的题会忘，但画过的追问链不会。希望你也能用这个思路把128题变成真正属于自己的面试武器，少走弯路，少踩坑，祝面试顺利。

本文还有配套的精品资源，点击获取