简介面向云原生与容器技术相关岗位的求职者这套面试题集锦共整理一百二十八道高频考题覆盖分布式键值数据库的特性与适用场景、集群管理核心概念、常见部署方式、主节点与工作节点的职责、最小调度单元与标签机制等基础原理也包含负载均衡、分布式锁、服务发现等常见追问方向可帮助面试前快速建立知识框架并查漏补缺。题目对一致性算法、监听机制、消息发布与订阅等关键机制均有清晰梳理同时解释了容器运行时与编排平台的分工关系适合在较短时间内理解云原生应用的核心逻辑。压缩包为单个PDF文档大小约二点七三兆字节按题号逐条编排便于翻阅、标注与记忆。目前已有四千六百三十六人学习下载适合正在准备容器相关岗位面试、希望提升编排理解深度的初、中级开发者使用。1. 把128道K8s面试题当系统学而不是当题库背云原生岗位的技术面试里K8s和Docker几乎是必考项很多候选人的第一反应就是找一份K8s面试题集锦慢慢刷它个128题。可真正上手后你会发现不带体系地刷题效率极低今天背了Pod调度明天又忘Service原理遇到追问就卡壳。我建议你换个思路——把这份128题的题集当成一张知识地图而不是题目清单。它覆盖的其实是K8s的完整主干从Pod生命周期到控制器、网络、存储、调度、安全再到排障手法。顺着题目的脉络把每个概念落回集群里验证一遍你会发现自己不仅能答题还能讲出操作依据。这套资料尤其适合准备一到两轮面试的从业者也适合刚学完K8s基础但不知道深浅的开发者。读完这篇笔记你会知道怎么拆题、怎么验证、怎么复盘以及哪些题最容易背完就忘。2. 拆题先于做题从128题里提炼六个知识块2.1 先把题集按模块归类一份128题的题集通常不会把“容器基础”和“集群运维”放在一起。我拿到题集后做的第一件事不是从第一题开始背而是把目录或题面全部扫描一遍按考点打上标签。最常见的分类是这样的模块典型题示例核心考点基础概念镜像与容器的区别Docker与K8s的关系容器运行时、镜像分层、CGroup与NamespacePod与调度Pod的生命周期Pending状态排查初始化容器、探针、污点容忍、资源限制控制器Deployment与StatefulSet的区别滚动更新、副本管理、有状态服务Service与网络ClusterIP与NodePort的区别Ingress转发原理kube-proxy、iptables、DNS、网络插件存储PV与PVC的关系StorageClass的作用存储卷生命周期、动态供给安全与运维RBAC最小权限镜像拉取策略etcd备份认证授权、PodSecurityPolicy、灾备这个归类动作的价值在于它告诉你128题其实只有六个大知识点。每个模块的题目数量可能差异很大但面试官从每个模块抽题的概率却差不多所以不能因为“存储题才10道”就跳过。2.2 用题干反向罗列考点把题目归类之后下一步是从题干反向拆解考点。举个例子“创建一个Pod后它一直Pending可能是什么原因”这道题表面问的是排障实际考的其实是调度器流程、污点容忍、节点资源计算、镜像拉取阶段、PVC绑定。如果你只背“资源不足导致Pending”那么面试官随便追问“那你怎么确认是资源不足”你就会露怯。我一般会准备一个Excel或Markdown表每道题一行列名是题号、模块、核心考点、扩展追问、我的答案关键词。比如题号073模块调度核心考点节点选择器、污点与容忍扩展追问如果多个节点都满足条件怎么办如果污点打在了master节点上答案关键词scheduler、filter、score、preferredDuringScheduling...这样拆完之后你会发现很多题背后的考点是重叠的。比如“DaemonSet为什么适合日志采集”“StatefulSet的Pod名称为什么是固定的”它们都指向同一个底层机制Pod的唯一标识与调度差异。把重叠的考点合并128题会浓缩成60个左右的完整知识树这才是你自己的题库。2.3 把答案转成“关键词流程图”面试答题和口语表达不一样面试官要的是结构。我刷这道题集时会把每个题目的答案整理成“结论 - 原理 - 操作痕迹”三段式。结论用一句话原理用两三句白话操作痕迹必须给出能证明你做过的东西比如“我用kubectl describe node看到xxx”。举个例子“Service的负载均衡是基于什么实现的”。答案不是背“iptables规则”而是说结论kube-proxy组件维护Service到Pod的转发规则。原理当前默认用iptables每条规则对应随机选择的一个后端Pod。操作痕迹我在集群里创建一个多副本Deployment后查看过iptables-save的输出看到DNAT规则数量随Pod副本数变化。这种“关键词痕迹”的答法能让面试官觉得你不仅看过书还真动手排过。后面我会讲怎么用实验环境把这些痕迹逐个做出来。3. 让答案能落地搭一套minikube环境逐组验证3.1 用minikube起单节点集群背答案之前先建一个能动手的集群。我推荐用minikube因为它在笔记本上就能跑网络插件等组件也能一键启停。启动命令很关键直接决定后面的网络题能不能复现minikube start --driverdocker --cniflannel --cpus2 --memory4096这条命令的意思是用Docker作为虚拟化驱动容器网络接口指定为flannel同时给2个CPU核和4GB内存。我特意带上--cniflannel是因为默认的calico在某些场景下需要更多资源而面试题里经常出现的“跨节点Pod互通”用flannel更容易在单节点上演示。如果本地已经跑着多个容器建议先执行minikube status确认当前状态避免重复启动导致端口冲突。启动完成后用kubectl get nodes能看到节点状态变成Ready后面我们验证的所有命令都在这个环境里跑。3.2 实操验证Pod调度与生命周期很多题集都爱问“Pod从创建到Running经过哪些阶段”对应的命令其实很简单kubectl run nginx-demo --imagenginx --restartNever kubectl get pod nginx-demo -w kubectl describe pod nginx-demo逻辑说明kubectl run创建Pod-w参数持续监听状态变化describe展示Events。这里要重点看Pod的Status从Pending变化到ContainerCreating再到Running的完整过程以及Events里每一步的操作者是谁。参数说明--restartNever表示只创建Pod而不是Deployment这样你能直接观察Pod本身的生命周期。如果后面想测删除和重建再加一个--rm参数在测试结束后自动清理。看完生命周期再看调度题。比如“如何让Pod固定调度到某个节点”kubectl label node minikube disktypessd kubectl run nginx-schedule --imagenginx --restartNever --dry-runclient -o yaml pod-schedule.yaml逻辑说明label给节点打标签--dry-runclient -o yaml生成一个YAML文件而不是真的创建Pod方便我们修改。接下来在YAML里加nodeSelector字段再kubectl apply -f pod-schedule.yaml验证Pod只会在带disktypessd标签的节点上调度。这一步做完面试题里“NodeSelector的用法”就算落地了。你可以顺手再测污点kubectl taint node minikube keyvalue:NoSchedule然后发现不带容忍的Pod会一直Pending带tolerations的Pod则正常调度。3.3 实操验证Service与网络Service相关的题只靠看理论很容易混乱。我在验证时通常会做一组对比实验kubectl create deployment web --imagenginx --replicas3 kubectl expose deployment web --port80 --target-port80 --typeClusterIP kubectl get endpoints web ip addr show docker0 | grep inet kubectl exec web-xxxxx -- curl http://web:80 -I逻辑说明先创建三个副本的Deployment再通过expose生成Service。kubectl get endpoints能看到Pod的IP列表如果Endpoints为空说明Service的Selector没有匹配到任何Pod这是最常见的翻车点。最后一个kubectl exec验证集群内部通过Service名称访问。参数说明--port80是Service暴露的端口--target-port80是Pod的容器端口。如果容器内的服务监听的是8080这里两个值就必须不一样很多题目专门考这个差异。如果题集里有“NodePort的端口范围”这道题可以继续执行kubectl get svc web -o yaml | grep -A3 type: NodePort kubectl patch service web -p {spec:{type:NodePort}}上面把ClusterIP改成NodePort后Service的nodePort字段会随机分配在30000-32767之间。这个范围在K8s里是默认配置面试答30000到32767再补充一句“可在apiserver的service-node-port-range参数里改”这道题就拿下了。3.4 把“排障题”变成“实战题”题集里最多的就是“Pod启动失败怎么排查”。与其背步骤不如故意搞坏一个Pod再救回来kubectl run fail-demo --imagenginx --restartNever --dry-runclient -o yaml | sed s/nginx/nginx:doesnotexist/ | kubectl apply -f - kubectl get pod fail-demo kubectl describe pod fail-demo | tail -20逻辑说明用sed把镜像名改成不存在的版本然后创建Pod。此时Pod会停留在ImagePullBackOff状态get看到的Status是ErrImagePulldescribe里的Events会明确告诉你Failed to pull image。解决方法是把镜像名改回来再kubectl replace --force -f或者kubectl delete pod fail-demo重建。这套操作做一遍比背十遍排查步骤都管用。你会真正记住镜像拉取失败会停在Pending状态Events里的原因能看懂kubectl delete pod删不掉的时候要先看kubectl get pv或检查是否有StatefulSet在强制保持副本数。4. 背题过程中的典型翻车与避坑清单4.1 现象默认命名空间里找不到刚创建的资源很多人在练习时用kubectl get all发现什么资源都看不到或者显示No resources found。第一次遇到这个问题我以为是集群坏了折腾半小时后才意识到自己创建资源时可能加了-n而查看命令没带。更隐蔽的是YAML里写了namespace: test但kubectl get默认看的是default。解决所有查询命令统一带着-n或者先kubectl get namespaces确认当前有哪些命名空间。从那以后我的每个命令前都会加-n除非明确要看全局资源。4.2 现象Service的ClusterIP通了但Pod没响应用kubectl port-forward svc/web 8080:80映射端口后浏览器访问不了。排查发现Service定义里selector的值写错了比如Pod的Label是appwebService的Selector却写成了appnginx。这种情况下Endpoints列表是空的但Service本身看着正常。解决永远先执行kubectl get endpoints service名如果Endpoints没有显示Pod IP说明Selector不匹配。这是题集里“Service网络不通”最常见的根因。4.3 现象Pod一直Pending但Events里没有任何报错创建Pod后状态卡在Pendingkubectl describe pod看不到明显的失败原因只有“0/1 nodes available”。这时候要往内存和CPU申请值上怀疑。我踩过的坑是YAML里resources.requests.memory写了4Gi而我的nodes总内存才3.7Gi调度器直接判定节点不满足条件但Events里不会直接说“内存不够”只会说“schedule failed: fit”。解决用kubectl describe node minikube查看Allocated resources与实际容量把requests调小或扩容节点。顺带记住这个现象解释了面试题“什么情况下Pod会Pending且Events无异常”。4.4 现象镜像在Docker Hub能拉但在K8s里一直ImagePullBackOff公司内部用的是自建镜像仓库但我在没有配置imagePullSecret的情况下直接用了私有镜像地址然后犯了个简单错误仓库名大小写写错镜像标签写成latest而私有仓库里根本没有latest。kubectl describe pod里的Events提示“repository does not exist”。解决先用docker pull验证镜像地址能拉通再检查K8s侧的imagePullPolicy是否因为latest标签导致每次都尝试拉取。如果集群内所有节点都拉不到还需要把imagePullSecrets加到ServiceAccount或Pod上。4.5 现象kubectl apply更新后Pod一直在“ContainerCreating”转圈这题我印象特别深。当时用Deployment改镜像版本kubectl apply后Pod一直循环重建。看logs没有输出describe的事件显示“Readiness probe failed”。原因是我配置的readinessProbe指向的/healthz路径在应用里还没实现导致新Pod永远不就绪旧Pod一直被保留而非替换。解决把探针路径改成应用真正提供健康检查的接口或者临时去掉readinessProbe再重新apply。这个坑对应面试题“滚动更新卡住怎么办”回答时一定要提到kubectl rollout status和kubectl rollout undo。5. 面试题背后的“源码级”说服力会看日志和事件才算会答5.1 kubectl describe是答题的万能钥匙题集里大量题目看起来在问原理实际上考官想听的是“你怎么定位问题”。所以我刷题时要求自己每个排障题必须能说出对应的describe输出字段。例如“Pod被驱逐”题答案不止是节点内存不足还要能指出kubectl describe pod里Status的Reason显示Evicted以及kubectl describe node里MemoryPressure条件为True。这些字段才是答案的证据。5.2 kubectl explain查API字段背API字段时与其死记Hard不如用命令查kubectl explain deployment.spec.template.spec.containers.resources kubectl explain pod.spec.affinity逻辑说明kubectl explain会直接输出字段类型、是否必选、默认值还能展开嵌套结构。这两个例子分别查资源限制字段和亲和性配置遇到题目问“requests和limits的区别”时执行一下就能看到字段注释里写的hugepages等细节。参数说明如果某个字段解释不够清楚加上--recursive参数递归展开子字段或者进入kubectl explain deployment.spec.template逐层看。这个方法对背“StatefulSet的volumeClaimTemplates怎么写”特别有效比翻书快得多。5.3 用日志定位“调度失败”的根因面试题里“调度器如何在多个节点间选择”的答案是两部分先过滤filter再打分score。但如果你能在答完后补一句“我遇到调度卡住时会先看调度器日志搜索FailedToPlacePod再看Spec的host字段”效果完全不同。在本地minikube上调度器以静态Pod方式运行kubectl logs -n kube-system kube-scheduler-minikube --tail50 | grep -i schedule逻辑说明kube-scheduler-minikube是master上的调度器Pod日志里会出现“Attempting to schedule pod”以及选中的节点。如果Pod一直Pending这条日志会显示失败原因比如“0/1 nodes are available: 1 node(s) had untolerated taint”。参数说明使用--tail50限制最近50行方便快速找到问题。如果你的集群没有kube-scheduler这个Pod而是用systemd管理的组件那就改用journalctl -u kube-scheduler。这段实验做完后我对调度类题目的理解明显上升了一个层次。后面再遇到“污点和容忍的原理”这类题我不需要背概念直接拿日志和describe结果当证据即可。6. 把128题过成复习闭环二刷标记与错题复盘6.1 错题标记规则第一遍刷题时很多人习惯把错题用红色标出来第二遍从头再看一遍。这其实效率不高。我给自己定的规则是一刷只看题和答案凡是不能30秒内想出“结论原理操作痕迹”的就标记为“模糊题”凡是能讲出来但追问一句就卡壳的标记为“陷阱题”真正能流利回答的标记为“熟练题”。之后用一个小脚本整理输出import csv questions [] with open(k8s_interview_128.csv, encodingutf-8) as f: for row in csv.DictReader(f): q row[题目] status row[状态] # 模糊/陷阱/熟练 if status ! 熟练: questions.append({question: q, status: status, revised: 0}) with open(review_queue.csv, w, encodingutf-8, newline) as f: writer csv.DictWriter(f, fieldnames[question, status, revised]) writer.writeheader() writer.writerows(questions)逻辑说明这段脚本读取原始题集CSV过滤掉标记为熟练的题目生成一个复习队列。字段revised用来记录已经复习第几遍二刷时每过一遍就加1。我用Python是因为读取表格和生成新表最方便也可以直接复制到Excel里手工筛选。参数说明如果你的题集是Markdown格式先用工具转换成CSV或Excel保持“题目”和“状态”两列就能跑通。newline是为了避免Windows上输出CSV出现空行。6.2 间隔重复把复习排到日历上二刷不要当天做也不要在临考前一天做。我实验下来比较舒服的节奏是第一次复习在第1天第二次在第3天第三次在第7天。比如周一刷了一组“Service与网络”的题周二过了模糊题周四再过一遍陷阱题下周一对全部重新过一遍。复习的时候只看错题列表不从头翻答案先口头回答再看解析。这里可以用一个简单的表格记录复习轮次时间点重点对象目标扫描第1天全部128题标记模糊/陷阱一刷错题第2天模糊题能说出关键词二刷错题第4天陷阱题上次模糊题能讲出操作痕迹三刷错题第7天全部非熟练题模拟面试追问这四轮走完大概率所有题都能进入熟练状态。6.3 怎么收尾才不白刷最后一件事是把结束前一晚的复习限定在20个最烂的题上。我通常会在确认完错题列表后随机抽几道出来用手机语音录音的方式讲给自己听再回放比对逻辑是否清晰。这个方法帮我发现了不少“脑子里知道但说不出来”的问题。如果有道题连讲三遍都卡壳就回集群里再敲一遍对应命令让肌肉记忆带出答案。以前我刷完题集总觉得什么都懂可真去面试时面试官一个问题追问到“怎么确认”我就开始含糊。后来养成习惯每道题只要涉及操作就必须先跑一遍命令再下结论。从那以后我每次准备K8s面试都强制自己先用minikube把对应现象复现一遍再看解析。希望这套拆题和验证的方法能帮到你既别被128题吓住也别被它带偏。本文还有配套的精品资源点击获取