前两年面试我还总听人抱怨“K8s这东西太重了面试用得着考这么细吗”今年再听到的版本已经变成了“k8s面试题网上找了十几份怎么每份都像在背八股文考完自己心里还是没底。”这个转变其实很正常——容器化已经是很多团队的默认部署方式Docker和Kubernetes不再是“加分项”而是“基础项”面试自然就越问越深、越问越偏实战。我自己既做过候选人也坐在面试官对面问过不少人。一个比较明显的感觉是K8s面试的考察重点已经从“知不知道概念”转向了“能不能解释清为什么这么设计、出问题怎么排查”。比如很多人都知道Pod是K8s的最小调度单元但一问“为什么不是容器直接调度”立刻卡住。这类问题靠死记硬背没法答好得真正理解K8s的设计思路。这篇文章我把这些年面试和被面试过程中遇到的高频题目做了下整理按容器基础、Pod与调度、网络与服务发现、存储与配置、高可用与排错几个维度拆开讲。不是为了让你背答案而是帮你梳理清楚每类问题背后的核心逻辑和答题框架顺带把我的排查经验和踩坑经历也放进去。1. 面试官到底在考什么K8s面试的层级划分与出题逻辑先说个规律面试官的题目看似随机其实背后有比较清晰的层级逻辑。理解这个逻辑比盲目刷题重要得多。1.1 基础概念层考察知识面的广度这个层面的题主要是筛掉完全没接触过的候选人。常见问题包括“Docker和虚拟机有什么区别”“镜像和容器有什么关系”“Pod和Deployment有什么区别”“Service有什么用”等。这一层题目特点是直来直去答案基本是固定的。但它真正的考察目的不是看你背得多熟而是看你能不能用简洁清晰的语言把概念讲明白。我见过不少候选人简历上写着“熟悉Kubernetes”但要他说清楚镜像和容器的区别支吾半天说不利索。这种情况在面试官眼里很减分因为概念说不清楚往往意味着实际动手也够呛。我的建议是基础概念题别只背定义尝试用“一句话解释 一个类比 一个实际场景”的结构来组织答案。比如“镜像和容器的区别”可以这么说“镜像是一个只读的模板容器是镜像运行时的实例就像程序和进程的关系一样。我经常用docker run启动多个容器它们共享同一个镜像但各自有独立的文件系统和进程空间。”1.2 原理机制层考察对K8s设计思想的理解这一层是区分“背过”和“理解”的关键。典型问题如“为什么K8s不直接调度容器而是用Pod”“kube-proxy的iptables和IPVS模式有什么区别”“etcd在K8s里扮演什么角色”“Pod的探针有哪些分别适用什么场景”。这类题目没有标准答案面试官想听的是你的推理过程。比如问“为什么用Pod”最好的回答方式是先讲Pod的设计目的——一组需要共享网络和存储的容器被封装在一起然后举一个实际场景比如sidecar模式和日志收集容器为什么要和业务容器放在同一个Pod里。我之前辅导过一个小伙伴他说自己面试时被问到“配置探针的时候initialDelaySeconds一般设置多少”直接懵了。后来我告诉他这类题看似考参数实际上考的是你有没有真正部署过有状态服务——initialDelaySeconds要根据应用启动时间来判断而不是网上随便抄一个“30”。1.3 实操排错层考察真实运维能力这是目前面试比重逐渐变大的一个层级。K8s运维场景中经常需要面对的问题例如Pod一直Pending、镜像拉取失败、Service无法访问、节点处于NotReady状态等都是面试官爱问的。答好这类题的关键是要有清晰的排查链路而不是上来就想“是不是网络问题”。以Pod卡在Pending为例正确顺序是先看Event描述——用kubectl describe pod命令查看具体的调度失败原因可能是资源不足、节点亲和性限制或存储卷挂载失败然后针对具体原因逐步排查是节点资源不足就检查节点可用资源是污点无法容忍就检查节点污点配置最后再考虑分配或扩容等解决方案。我在实际排查中遇到过很多次“Pod一直ContainerCreating”的情况后来养成了习惯——先kubectl describe pod再看kubelet日志最后看容器运行时日志。这个顺序基本能覆盖大部分问题。2. 容器与镜像篇Docker基础题的高频考点与答题套路容器是K8s的基石面试官通常会先从Docker相关的问题开始热身同时也是为了考察你到底是在K8s上层敲命令还是真对容器运行时有所理解。这一层问得深了很容易拉开差距。2.1 Docker与虚拟机面试官最爱的“一题三连问”“Docker和虚拟机有什么区别”这道题几乎逢面必问但很多人答得流于表面——说Docker更轻量、启动更快、资源占用更少。这些是结果不是原因。我一般建议从三个层面回答隔离级别不同虚拟机通过Hypervisor虚拟化硬件每个VM有自己的完整操作系统硬件级隔离容器共享宿主机内核通过Namespace做资源隔离通过Cgroup做资源限制是进程级隔离。启动速度与资源密度不同虚拟机启动要引导整个OS秒级到分钟级容器启动本质上是启动一个进程毫秒级到秒级。同样一台机器跑虚拟机可能只能撑几十个但容器可以跑几百个。安全边界不同虚拟机隔离更彻底一个VM被攻破不容易直接影响宿主机容器共享内核一旦内核漏洞被利用逃逸风险相对更高。答完之后有经验的面试官通常会追问“那你觉得什么场景下适合用虚拟机什么场景适合用容器”这个问题才真正考验认知。我一般会答如果追求强隔离、需要运行不同内核版本或操作系统、有合规要求虚拟机更合适如果追求部署密度、弹性伸缩、CI/CD流水线效率容器更合适。很多团队实际是两者混合使用比如在虚拟机里跑K8s集群Pod再跑在容器里。2.2 镜像分层与Dockerfile考的是对OCI规范的底层理解“Docker镜像为什么可以分层”这个问题也常见。核心要答出来**镜像是由多个只读层叠加组成的每一层对应Dockerfile中的一条指令层与层之间有依赖关系构建时会复用已有的缓存层。**容器运行的时候在镜像层之上加一个可写层叫容器层。这个设计带来的两个直接好处是镜像可以复用和增量传输以及多个容器可以从同一镜像启动但各自拥有独立可写层。这也是为什么Docker Hub上拉镜像时已经存在的层会显示为“Already exists”。关于Dockerfile面试官经常让候选人说说“你写Dockerfile时有哪些优化技巧”。这里有几个高频点尽量减少层数每条RUN指令会新增一层多个RUN尽量用合并但别为了合并而牺牲缓存命中率。利用构建缓存把不常变的依赖安装放在前面把经常变的源码复制放在后面这样可以最大化利用缓存层。使用.dockerignore避免把node_modules、.git等不必要文件打进构建上下文既加快传输又减少镜像体积。多阶段构建例如Golang应用先在golang:1.20镜像里编译再把二进制拷贝到alpine镜像里运行最终镜像可以控制在几十MB。注意基础镜像选择alpine体积小但部分C库兼容有问题slim版本是另一个常用选择。2.3 容器生命周期和信号处理进程模型才是真正的分水岭很多面试官会在这一层设置一个“陷阱题”问你“容器里PID 1是什么进程为什么重要”如果你没踩过这个坑很容易答不出来。常规Docker命令未特殊处理时直接运行一个应用应用本身就是容器里的PID 1。PID 1和普通进程不同它负责处理孤儿进程的收养还会接收系统发给容器的信号比如SIGTERM。如果应用没有正确捕获和处理SIGTERM那么你执行docker stop时可能等很久默认等待10秒之后直接SIGKILL甚至出现容器无法优雅退出的情况。实操中我建议养成几个习惯用tini或用--init参数作为PID 1来托管信号Dockerfile里显式设置STOPSIGNAL脚本启动类应用时用exec方式而不是开一个子进程。这些细节K8s的terminationGracePeriodSeconds配置也有关联——Pod删除时kubelet向容器发送SIGTERM如果应用不响应或处理时间太长最终会被强制杀掉导致请求中断。我自己的经验是很多人写完容器应用只测了“能启动”没测“能不能优雅退出”。有一次我把一个Java服务容器化之后明明代码里有addShutdownHook但docker stop还是会等满10秒最后排查发现是启动脚本的问题——我用了java -jar xx.jar 方式启动导致JVM变成了子进程PID 1是脚本信号根本没传给JVM。改成exec java -jar xx.jar之后问题就没了。3. Pod与调度篇搞懂这几个问题Pod相关面试题就通了一半Pod是K8s的世界观里最基本的一个概念面试题基本都绕不开。这个部分我挑几个最关键的问题展开讲答好了调度相关的题目基本就通了一半。3.1 为什么Pod是最小调度单元而不是容器这道题看起来很基础但我几乎每次面试都会问。很多人答“因为K8s设计如此”等于没答。比较好的回答思路是Pod是一组容器的集合这些容器共享同一个网络命名空间共享IP和端口空间、共享存储卷、共享主机名可以在本地通过localhost互相通信。有些场景天然需要多个容器协同工作比如边车模式——日志收集容器在Pod的另一个容器里读取日志文件又比如代理容器和业务容器共享网络栈业务流量先经过代理容器处理。K8s需要以Pod为单位进行统一的资源分配、调度、健康检查和生命周期管理。如果以容器为调度单位容器之间的相关性就无法表达调度器也无从下手。一个比较形象的类比是Pod就像一栋楼的公用设施楼里的多个房间共享水电网络和楼道容器就是房间各自做自己的事但依赖Pod提供的公共设施。这样回答基本能把面试官说服。3.2 探针、重启策略与Pod生命周期探针是高频考点主要三种livenessProbe存活探针检测应用是否存活失败会重启容器、readinessProbe就绪探针检测应用是否准备好接收流量失败会摘除Endpoint、startupProbe启动探针用于慢启动应用保护livenessProbe不被误杀。面试官常挖的一个细节是“livenessProbe失败时What happens”很多人会马上回答“容器会被重启”但再追问“是谁执行的重启重启的是Pod还是容器”就有人答错了。正确的链路是kubelet通过容器运行时执行探测连续失败超过failureThreshold次后kubelet会根据restartPolicy决定是否重启容器——注意K8s重启的对象是容器而非Pod同一个Pod内的其他容器不受影响。实操中同样遇到过不少坑探针配置得太激进如periodSeconds设置为1秒导致宿主机负载升高应用被频繁误杀又或者在K8s 1.16版本之前没有startupProbe慢启动应用必须把initialDelaySeconds调大还有一次是readinessProbe里配置了依赖数据库的接口导致数据库抖动时整个应用实例被摘除流量全部打到另一台机器上——这就是探针路径设计不合理带来的连锁故障。这里给几条实战建议存活探针不要依赖外部服务探针本身应只检查应用自身存活状态。就绪探针可以依赖关键依赖项的检查但建议超时和失败阈值都设宽松些避免依赖抖动导致大规模摘除。慢启动应用优先使用startupProbe而不是无限调大initialDelaySeconds。3.3 从调度器视角理解节点亲和性、污点与容忍调度相关的高频题基本集中在“如何把Pod调度到指定节点”这个问题上。一般来说有三种方式nodeSelector、节点亲和性nodeAffinity、污点和容忍taint和toleration此外还有nodeName直接指定节点。我经常问的一个题目是“nodeSelector和nodeAffinity有什么区别”答得好的候选人会说nodeSelector是一个简单的精确匹配只能根据标签的key和value做等值匹配nodeAffinity则表达能力更强支持In、NotIn、Exists、Gt、Lt等操作符还区分requiredDuringSchedulingIgnoredDuringExecution硬性要求和preferredDuringSchedulingIgnoredDuringExecution软性偏好。污点和容忍的逻辑则完全不同。污点是打在节点上的“排斥标签”默认情况下Pod不会调度到带污点的节点上只有Pod声明了对应的容忍toleration才可以被调度上去。比如控制面节点通常有node-role.kubernetes.io/control-plane:NoSchedule污点所以你自定义的Pod不会跑到控制面上去。同时污点还有NoExecute效果——不仅影响新Pod的调度还会驱逐节点上已运行的Pod。实操中常用的场景是给专用GPU节点打污点只有声明了容忍的GPU任务Pod能调度上去。再比如给网络有特殊要求的节点打污点防止普通业务Pod占用。这套逻辑答清楚了说明你对调度器的约束模型有系统理解。3.4 控制器大观Deployment/StatefulSet/DaemonSet怎么选控制器类问题在面试中基本都是送分题但也是很多人说不利索的题。你需要把每个控制器的核心职责和应用场景讲清楚Deployment无状态应用。管理的Pod可替换、可水平扩展支持滚动更新和回滚。Pod名称带随机后缀任意一个挂了副本控制器都会重新拉起一个新的。StatefulSet有状态应用。Pod有稳定且唯一的网络标识如pod-0、pod-1有稳定的持久化存储有顺序的部署、扩容、升级和删除行为。常用于数据库、ZooKeeper、Kafka等。DaemonSet每个匹配的节点上运行一个Pod。典型场景包括日志收集Fluentd、监控采集Prometheus Node Exporter、网络插件Calico等。Job/CronJob执行一次性任务或定时任务。面试官在这里通常追加一问“Deployment的滚动更新策略是怎么实现的”这就要提到maxUnavailable和maxSurge这两个参数。简单说滚动更新通过ReplicaSet逐渐增加新版本Pod数量、减少旧版本Pod数量来完成。maxUnavailable决定更新过程中允许最多有多少个Pod不可用maxSurge决定最多允许超出期望副本数多少个Pod。理解这两个参数你才能解释“为什么更新过程中服务不中断”。4. 网络与服务发现篇Service、Ingress和CNI的底层逻辑网络是K8s里最抽象、也最容易把候选人问倒的部分因为平时直接用kubectl expose创建Service很容易但内部数据链路是什么样的很多人没有细细捋过。4.1 ClusterIP、kube-proxy与iptables/IPVS工作链路面试官很爱问“Service的ClusterIP是怎么生效的”。回答这个问题要把组件串联起来Service是一个API对象创建后会被写入etcd同时API Server会为它分配一个ClusterIP虚拟IP。kube-proxy监听Service和Endpoints或EndpointSlice的变化在节点上生成对应的负载均衡规则。默认模式是iptables通过NAT规则把发往ClusterIP的流量转发到后端的Pod IPIPVS模式则是利用内核的IPVS模块做负载均衡支持更丰富的调度算法如rr、lc、sh在Service数量大的时候性能更好。一个值得展开的细节是**ClusterIP是虚拟的它不绑定任何物理网卡真正发起转发的是节点上的kube-proxy规则。**所以我们常说ClusterIP只能在集群内部访问因为它本质上是节点上的DNAT规则外部流量不经过这套规则。我还见过一个挺隐蔽的面试追问“Service创建了但Pod没有就绪curl ClusterIP会怎样”很多人会答“超时”。其实如果是只定义了selector但Pod没就绪ClusterIP会存在但iptables规则里没有后端流量会直接DROP——表现就是请求卡住直到超时而不是立即失败。这个细节说明了对Endpoint更新机制的理解深度。4.2 Service、Ingress、DNS服务发现的完整路径服务发现是面试常考的一个链路题。一般我会问“一个前端Pod要访问后端ServicePod里解析到的域名是什么”完整链路是Pod内DNS解析使用CoreDNSPod中配置的resolv.conf指向集群的DNS服务地址。当你访问backend.default.svc.cluster.local时CoreDNS解析出ClusterIP然后流量幸运到kube-proxy规则被转发到后端的Pod IP。这里面还有两个容易忽略的细节Service的端口名也会被解析成DNS SRV记录可用于服务间按协议查找。Headless ServiceclusterIP: None不会创建ClusterIPDNS会直接返回后端Pod的IP列表适合需要客户端自己做负载均衡的场景比如StatefulSet集群内的节点间通信。至于Ingress它工作在七层负责HTTP/HTTPS路由。Ingress Controller比如Nginx Ingress、Traefik才真正干活的组件Ingress只是声明路由规则。很多人在这里犯糊涂把Ingress和Ingress Controller混为一谈。4.3 CNI网络模型每个Pod都有独立IP是怎么做到的面试官如果问“Pod是怎么拿到IP的”就是在考察CNI。K8s本身不实现网络它通过CNI接口调用网络插件Calico、Flannel、Cilium等。Pod网络的核心要求是每个Pod都拥有一个集群内可路由的唯一IPPod之间可以不通过NAT直接通信。为满足这个模型常见实现Overlay网络如Flannel的VXLAN模式Pod流量被封装在UDP包里传输配置简单但性能略有损耗。BGP路由方案如Calico的BGP模式每个节点作为路由器通过BGP协议扩散Pod网段路由性能高但底层网络需要支持BGP路由传播。eBPF方案如Cilium用内核eBPF技术实现网络策略和转发性能和可观测性都更好是目前比较推荐的新方向。这一节在面试时不用讲得太深把“CNI是接口、插件是实现、每种方案各有取舍”这个逻辑讲清楚就够了。如果面试官继续追问“你在生产环境选型怎么选”可以从团队技术栈、网络策略需求、是否用ServiceMesh、性能要求几个维度去拆。5. 存储、配置与安全篇容易被问倒但必须答上的基础知识存储和安全这块是很多人复习时的盲区觉得“反正我天天用emptyDirPV/PVC用得少”。但一旦被问起来答不上又显得项目经验不够扎实。5.1 PV/PVC/StorageClass从静态供给到动态供给“PV和PVC的区别是什么”是这类的必问题。简短版答案是PV是集群级别的存储资源由管理员预先创建或由StorageClass动态创建PVC是用户申请存储资源的请求声明需要的容量和访问模式Pod通过PVC引用存储PVC绑定到满足条件的PV。一般我会建议考生再补充一下生命周期与绑定逻辑PVC和PV通过storageClassName、accessModes、容量等条件匹配绑定。如果没有符合的PVPVC会一直处于Pending状态K8s有一个叫WaitForFirstConsumer的延迟绑定机制——可以先创建PVC等Pod调度到某个节点后再根据该节点的可用区动态创建卷这对云环境比较友好。访问模式也是考点ReadWriteOnceRWO允许单节点读写、ReadOnlyManyROX允许多节点只读、ReadWriteManyRWX允许多节点读写。不同存储支持的模式不同比如云盘一般只支持RWONFS支持RWX。用错访问模式会出现Pod调度成功但挂载失败的情况。这类问题最能打开话匣子的展开方向是我之前帮一个团队排查过的一个问题所有Pod都卡在ContainerCreatingkubectl describe显示failed to mount volume排查半天发现是云盘的diskId写错了挂载点指向了一个不存在的云盘。所以碰到挂载失败且网络、存储插件都没问题时先检查存储资源的ID和可用区。5.2 ConfigMap与Secret配置注入的边界与权限问题“ConfigMap和Secret有什么区别”这个问题看起来简单但答案里有几个关键点存储形式不同ConfigMap明文存储适合非敏感配置Secret用Base64编码存储但对敏感数据来说Base64不算加密只是编码所以生产环境建议开启etcd加密或使用外部密钥管理方案如Vault、KMS。使用方式相同两者都能通过环境变量注入或挂载为文件。更新机制不同通过环境变量方式注入的配置Pod运行期间不会动态更新通过volume方式注入的配置K8s会定期同步到挂载卷应用需要监听文件变化才能生效。我补充一个踩坑经历之前我用ConfigMap挂载Nginx配置修改ConfigMap后发现Nginx容器里文件已经更新了但Nginx进程并没有重新加载配置最后还得靠reload容器进程或重启Pod来实现。所以面试时可以提一句“如果应用不支持动态加载配置修改ConfigMap后需要滚动重启Pod”这比单纯背概念更有说服力。5.3 RBAC与服务账户最小权限原则在K8s里的落地安全类的常见题目是“RBAC是什么如何给一个Pod配置只读权限”。答案是K8s通过RBAC做权限控制核心有Role/ClusterRole、RoleBinding/ClusterRoleBinding、ServiceAccount三个概念。以“Pod访问K8s API”为例流程是创建ServiceAccount创建Role或ClusterRole声明权限规则比如对Pod资源只读通过RoleBinding将Role绑定到ServiceAccount在Pod的spec中设置serviceAccountName。提一个值得记住的话题默认情况下Pod会挂载一个ServiceAccount的token文件API请求会自动带上身份信息。这个token实际上是JWT格式默认有效期比较长。现在K8s新版本推荐使用TokenRequest API提供短时间有效期的token权限更收敛更适合外部系统对接。“最小权限原则”不是一句空话在K8s里的落地就是——能不给cluster-admin就不给能用一个独立ServiceAccount就别用default。面试时如果能主动提到自己曾用RBAC收紧过线上权限、回收过长期token会是一个很好的加分细节。6. 集群高可用与排错篇面试官拿来区分“会用”和“会养”的分水岭前几年面试能把Service和Deployment说清楚就可以过关了。现在不行了面试官更倾向于通过高可用和排错类问题看你有没有“养过”集群的经验。这类题目很开放答得好不好全看平时积累。6.1 etcd与控制面组件面试官深挖高可用时在挖什么“K8s集群的etcd挂了会怎样”这是高可用题里我能想到的最经典问题之一。etcd存储了集群全部的期望状态比如Pod、Service、ConfigMap等对象数据。如果etcd挂了kube-apiserver无法读写数据整个集群的管理平面就瘫痪了——但注意已经运行中的Pod和kubelet不受影响它们还在照常跑。这就是“控制面和数据面分离”设计的好处。真正的高可用问题是etcd的raft协议怎么工作这里要答出来etcd集群至少需要3个节点才能容错1个节点5个节点能容错2个数据会通过raft日志在节点间复制。如果集群节点间网络分区少数派节点会失去领导人选举能力表现为只能读不能写。控制面组件的职责也要能说清楚kube-apiserver是无状态网关负责提供API、鉴权、准入控制kube-scheduler负责把Pod调度到合适的节点kube-controller-manager运行各种controller节点控制器、副本控制器等负责把当前状态调整为目标状态。一个常见面试题是“kube-apiserver挂了kubelet还会正常工作吗”答案分两层kubelet会继续维护本节点的Pod运行但如果Pod需要重新调度或创建新Pod这部分逻辑依赖apiserver和scheduler就会出不来。6.2 一个Pod卡在Pending排查链路是什么这类排错题答案没有唯一标准但基本要符合以下排查链路看事件kubectl describe pod pod-name重点看Events列表。看调度器日志如果事件提示0/3 nodes available原因可能是资源不足、节点有污点、nodeSelector不匹配等。看节点资源kubectl top nodes确认节点资源是否充足。看StorageClass和PVC如果事件里面提到waiting for a volume to be created去排查StorageClass的Provisioner是否正常工作。如果事件里没有任何内容考虑是不是需要检查调度器本身比如自定义调度器或者调度器Pod挂了。我实际遇到过最“隐蔽”的一次Pending问题是节点上有GPU资源但Pod没声明申请GPU调度器认为没有任何节点满足“包含GPU资源”的条件于是一直Pending。最后通过看事件的FailedScheduling消息才定位到是资源名写错了——nvidia.com/gpu写成了nvidia/gpu。这些小细节面试时不一定问到但实际操作中真的会碰见。6.3 资源请求/限制与HPA为什么节点会异常“Pod内存超限会怎样”是考查资源机制的一个好问题。这个问题我觉得可以说一下K8s里两类资源超限的不同表现CPU是可压缩资源超限时会产生CPU ThrottlingPod还在运行但变慢了一般不会被杀掉。内存是不可压缩资源超限时容器内的进程如果继续申请内存内核OOM Killer会根据oom_score杀掉进程进而导致容器重启。面试官继续抠细节时可以问“为什么有时候还没超limit也会被杀”这实际上和节点整体内存有关。如果节点本身可用内存偏低内核OS的cgroup OOM和系统OOM的边界会变得比较复杂需要结合eviction机制来理解——kubelet为了稳住节点会设置--eviction-hard当节点MemoryPressure超过阈值时开始驱逐Pod而不是等容器自己超限。HPAHorizontalPodAutoscaler也算高频题重点答清楚HPA通过Metrics API获取Pod资源指标CPU、内存或自定义指标根据当前指标和期望值计算需要的副本数有一个--horizontal-pod-autoscaler-sync-period控制同步周期。扩展时以Pod数量为粒度且受minReplicas和maxReplicas限制。要提一句HPA的实现依赖metrics-server没有安装metrics-server的话CPU指标采集不到HPA就没法正常工作。7. 备战策略二八法则与复习路线建议内容聊到这里题型的脉络基本就清楚了。最后一年总结下来我建议按“二八法则”来准备K8s面试题——花80%精力掌握20%的高频考点远比我见过很多人把时间耗在背诵冷门参数上有效得多。对于准备时间有限的求职者我的建议是这样的先动手搭一个集群别只看文档至少要在自己电脑上用kind或minikube完整跑一遍“部署应用→创建Service→配置探针→滚动更新→回滚”的流程。有了亲手操作的经验面试中很多概念题会自动串起来。把kubectl常用命令背熟特别是describe、logs、exec、get、apply、top这些排错命令。面试时如果能脱口而出排查命令说服力会好很多因为k8s是命令行工具的世界大多数工作都在kubectl上面。深挖两三个真实场景比如你曾经用StatefulSet部署过MySQL、用Ingress配置过HTTPS、用RBAC收过权限——挑两三个往深了准备把涉及的技术细节都搞清楚面试时每个都能讲5分钟比蜻蜓点水地重复十个项目强。可以适当看看官方文档Kubernetes官方文档概念部分写得非常清楚特别是Pod Lifecycle、Service、RBAC这三块比很多博客都靠谱。遇到有争议的细节以官方文档为准。不要只啃面试题集合面试题集合适合查漏补缺不适合当教材。我见过太多人背诵了“200道真题”结果面试官稍微换个角度就陷入背过的题没听过、没背过的题答不上来的困境。最后再分享一个我在准备面试时用到的比较有效的做法——把每个考点都写成“自己讲给自己听”的稿子然后模拟面试官追问。比如写完“为什么用Pod”就追问一句“Pod内多个容器如何共享网络”再追问“那如果有两个容器都想监听80端口怎么办”——一个接一个地问下去直到答不上来然后去查资料、验证、补充。这个过程很枯燥但坚持一个月面试时能明显感到自己“有底气了”。K8s的知识体系确实庞大但面试考来考去万变不离其宗——最终都在考察你是否理解这套系统“为什么这么设计”。把每个概念背后的动机和取舍想明白比记住再多细节都值钱。
