简介面向准备云原生与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面试题集会按下面的比例分配主题。这个分布不是我拍脑袋想的而是根据面试高频考点和线上运维事故的高发区域倒推出来的主题题目数考察核心容器与镜像12Dockerfile编写、镜像分层、tag策略、镜像仓库Pod与工作负载24Pod生命周期、Deployment/StatefulSet/DaemonSet差异调度与资源14nodeSelector、亲和性、污点容忍、资源requests/limits存储12PV/PVC/StorageClass、emptyDir/hostPath差异、CSI网络18Service类型、Ingress、CNI选型、DNS解析机制安全与权限12RBAC、ServiceAccount、PodSecurityContext、Secret可观测性12探针、日志采集、Metrics指标、链路追踪故障排查12Pod启动失败、CrashLoopBackOff、节点NotReady云原生生态12CI/CD、Helm、Operator、Serverless/工作负载这里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-runclient -f gpu-worker.yaml注意这个只能验证语法结构合法验证不了字段语义比如device插件缺失这种问题要kubectl apply --dry-runserver才可能暴露更彻底的检查是看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 componentkube-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-runclient做语法校验。重点敲三次一次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也是HTTPSnginx应该如何透传而不重新加密IngressClassName和旧版annotation的区别是什么每追问一层你都必须重新调出对应主题的知识才能答得完整。把每道高频题都做一遍这个扩展128题就被拆成了三四百个知识锚点覆盖面的深度就会显著不一样。5.2 组建三角色的模拟面试模拟面试是验证备考成果最有效的方式但不是随便找个人互问就行。有条件的话找两三个同样在准备K8s面试的人组队规模三到四人最合适人太多每人发言次数太少。每人从128题里出10道题面试官角色轮换答题只用白纸不许查资料每道题答完之后面试官必须连环追问至少两轮直到答题者卡壳。所有卡壳点记录在共享的错题单里当天晚上复盘补齐。这种方式的效率往往比独自刷三轮要高出不少因为它能逼出“在压力下组织答案”的能力。卡壳点记完不需要额外整理把笔记集中在一页wiki页或文档里标题标上日期和主题范围后面复习直接看这页就够了。我自己的习惯是每次模拟面试结束把卡壳的追问链画成箭头图附在那道题后面复习时按箭头依次自问。这个习惯帮我避开了不少重复翻车——背过的题会忘但画过的追问链不会。希望你也能用这个思路把128题变成真正属于自己的面试武器少走弯路少踩坑祝面试顺利。本文还有配套的精品资源点击获取