很多准备面试的朋友一看到 Docker 和 Kubernetes 的题就头大原因不外乎两点一是知识点太散镜像、容器、网络、存储、编排、调度、服务发现每个方向都能单独拎出来出一套卷子二是光背概念没用面试官现在都会顺着一个点往下挖比如先问“Pod 里几个容器”再问“sidecar 怎么通信”接着问“Pod 重建后 IP 变了怎么办”一套组合拳下来死记硬背的答案根本顶不住。这份 Docker 和 K8s 面试题总结走的是“原理 场景 排查”的路子。直接背题解决不了问题但把每个高频问题背后的原理和现场回答的思路搞清楚面试时就能顺着自己的知识体系往深处聊。内容分成 Docker 基础、K8s 核心、网络存储、调度器、场景排查几个大块每道题都标注了面试官想考察的能力方向方便针对性复习。说明因为内容量比较大这一篇先把 Docker 部分的大部分高频题和 K8s 的入门核心题写完网络、调度器、存储以及更底层的 etcd 机制部分留在下一章。所有题目都是我在真实面试中遇到过的或者是同行交流中公认的高频题不是按文档目录硬凑的。1. 先说清楚这套面试题怎么用刷面试题最忌讳的就是“背答案”。容器这块技术栈有个特点面试官几乎不问纯记忆性的问题比如“Docker 有哪几种网络模式”而是给你一个场景“我用默认配置跑了一个 MySQL 容器结果外部连不上怎么排查”你要在脑子里把网络模式、端口映射、防火墙、容器内监听地址这几个环节串起来才能把这个问题答完整。这套题的用法我建议分三步先自己答一遍。拿到一道题不要马上去看解析先用两分钟时间口头回答。卡住的地方就是你知识体系里的缺口。对照解析找“为什么”。解析里不只有一个结论还有这个结论产生的原因。比如“容器内进程 PID 和宿主机 PID 不同是因为 PID namespace 隔离”理解了 namespace 这一层很多题都能顺势展开。追问自己一层。每个重点题后面我都留了“延伸考点”这些是面试官最常往深处挖的方向提前准备好现场就不会脑子空白。提示面试时如果遇到没准备过的题千万不要慌。多数面试官想知道的是你的排查思路而不是标准答案。把“我平时遇到这种问题会先看什么日志、再算什么数据”讲清楚比硬憋一个不确定的结论有效得多。2. Docker 高频题从底层原理到日常运维2.1 镜像、容器、仓库的区别为什么面试官要先问这个这道题看起来简单但答得好的人真不多。大部分人会背“镜像是模板容器是实例仓库是存放镜像的地方”但这个回答只触及了表面。我一般会从联合文件系统这个点切入接着说镜像层的内容然后说容器启动时在上面加了一层可写层这个结构直接决定了镜像构建和容器运行的很多行为镜像是一堆只读层堆起来的。每一层对应 Dockerfile 里的一条指令层与层之间共享所以多个镜像可以共用一个基础层这也就是为什么本地磁盘上镜像占了几个 GB但实际不少层都是去重的。容器启动的时候会在镜像层之上再加一个可写层。你对容器里文件的修改都发生在这个可写层。一旦容器删除这个可写层也就没了所以容器里的数据默认不持久化。仓库是镜像分发的中转站。Docker Hub 是公开仓库企业内部一般用私有仓库比如 Harbor 或者 Registry负责镜像的推送、拉取和权限管理。这个回答等于把镜像层、容器可写层、仓库分发三个知识点都带出来了面试官顺着就能问“怎么减少镜像体积”“容器数据怎么持久化”“私有仓库怎么搭”回答的空间很大。2.2 Docker 的网络模式bridge、host、none、container 的选型逻辑Docker 网络这块我面试的时候十次有八次会被问到。先背清楚默认的 bridge 模式创建容器的时候如果不指定网络就会接到名为docker0的 Linux 网桥上拿到一个172.17.x.x的 IP这个 IP 是容器自己的宿主机访问不到外部更访问不到。要让宿主机或者外部访问容器里的服务必须在启动时用-p做端口映射。这个-p映射的底层逻辑是 iptables 的 DNAT 规则。Docker 是在宿主机上通过端口代理的方式把宿主机某个端口收到的流量转发到容器 IP 的对应端口。理解这个机制后常见的排障思路就清楚了如果-p 3306:3306没用先检查宿主机防火墙是否放行 3306再检查容器内 MySQL 是否监听在 127.0.0.1 而不是0.0.0.0然后检查容器 IP 是否变化导致 DNAT 规则指向了失效地址。host 模式和 bridge 模式最大的区别是容器不拥有独立的网络 namespace直接复用宿主机的网络栈。这种模式下容器没有自己的 IP端口直接占用宿主机的端口。优点是网络效率高没有 NAT 转发缺点是隔离性差端口冲突要靠人管适合对网络性能要求高的场景比如一些压测工具。container 模式用得更少一些大意是让新容器和某个已存在的容器共享同一个网络 namespace。这个模式的价值在于两个容器可以通过 localhost 直接通信不需要走网络转发。比如监控容器和业务容器放在同一个网络命名空间里监控进程直接连127.0.0.1:xxxx就能抓到业务进程的监控数据。实际做题的时候无非是掌握两个要点bridge 是默认隔离方案生产环境里最常见的用法是创建一个自定义 bridge 网络让多个容器通过容器名互相访问。端口映射依赖 iptables/ipvs 规则排查外部访问不通时路径是“防火墙规则 - 端口监听 - 路由规则”。2.3 Docker 存储Volume、Bind Mount、tmpfs 怎么选面试里问到容器数据持久化我见过不少回答都是“用 volume 挂载数据放宿主机”然后就没了。其实这里藏着一个关键考点Docker 容器删除后容器内产生的所有数据都会消失因为可写层跟着容器一起没了。所以需要把需要持久化的目录挂载出来挂载方式主要有三种Volume数据卷由 Docker 管理存放路径在/var/lib/docker/volumes/下。这种方式的好处是数据不受容器生命周期影响多个容器可以共享同一个 volume。生产环境里做数据库容器、文件服务容器一般用这种方式。Bind Mount绑定挂载直接把宿主机的某个目录或者文件挂载到容器里。比如把宿主机/data/mysql挂到容器/var/lib/mysql。缺点是路径写死迁移性差但优点是方便查看和备份而且宿主机上可以直接改文件。开发环境调试配置用 bind mount 非常顺手-v /home/user/app:/app就可以做到宿主机改代码、容器里直接生效。tmpfs内存文件系统数据只存在内存里容器停止时数据清空。适合存放临时文件、缓存类数据不会落盘性能高。这里还有一个容易踩的坑就是权限问题。用 bind mount 挂载宿主机目录的时候如果宿主机的目录权限是root而容器内部进程是以uid1000的身份运行的启动容器后就会遇到 Permission denied。解决办法是在启动时用--user指定 uid或者把宿主机目录的属主改成对应 uid。2.4 容器资源限制为什么限制 CPU 和内存要一起做面试官问“怎么限制容器的资源使用”你可以直接甩出--cpus--memory这些参数但如果只说到参数层面就还差得远。这里是常考的一个底层机制docker run --memory2g --cpus2限制的是容器最多能用 2GB 内存和 2 个 CPU。但不限制的话一个失控的容器很可能把宿主机整个拖垮。比如容器的内存申请超出限制触发 OOMDocker 会直接把容器杀掉这个行为由内核 OOM Killer 完成很多时候看着像进程突然没了真凶其实是 OOM。CPU 限制相对温和一些限制的是 CPU 时间片容器只能在分配的额度里轮转不会杀掉进程。所以触发器不同内存超限直接杀CPU 超限只是慢。另外很多新手不知道还有一个隐含层Docker 的容器资源限制是基于 Cgroups 实现的。--cpu-shares是相对权重--cpus是绝对限制换算成 CPU 调度周期中的配额。面试时把这层原理点出来基本就能把候选人分层了基础回答docker run --memory 2g --cpus 2进阶回答说明 Cgroups 在 Linux 内核里通过 CFS 调度器分配 CPU 配额通过 memory cgroup 记录并限制内存使用量超出后触发 OOM Killer。2.5 Dockerfile 优化与镜像安全面试里最常被追问的细节Dockerfile 相关的题看起来像送分题实际上最容易暴露实践经验。这里有几个高频考点考点一RUN、CMD、ENTRYPOINT的区别RUN是构建镜像时执行的命令每执行一次就会生成一个新的镜像层。CMD是容器启动时的默认命令可以被docker run后面的命令覆盖。ENTRYPOINT也是启动命令但一般作为容器的主进程固定下来优先用ENTRYPOINT执行主程序把变参交给CMD。比如镜像里写ENTRYPOINT [nginx, -g] CMD [daemon off;]运行时如果执行docker run 镜像名 -v实际执行的是nginx -g -v而CMD里的默认参数会被覆盖。这个组合方式理解透了才能在设计镜像启动逻辑时不迷路。考点二怎么减小镜像体积使用更小的基础镜像比如alpine它基于 musl libc体积只有几 MB。合并 RUN 命令减少镜像层数。比如用连接多个命令减少中间层。删除构建过程中的临时文件比如 apt 缓存、.pyc文件。还有一个细节构建镜像时使用多阶段构建multi-stage build。比如编译 Go 程序的时候第一阶段用golang镜像编译出二进制第二阶段用alpine镜像把二进制 copy 进去最终镜像里只保留了运行环境编译器源码全都不在这样镜像体积能缩小十倍不止。考点三镜像安全镜像里最好以非 root 用户运行进程。Dockerfile 里用USER指令指定基础镜像里没有这个用户就先useradd创建一个。以 root 身份运行容器相当于把宿主机的 root 权限暴露给了容器进程一旦容器被入侵攻击者可以直接操作宿主机。这个安全观点现在几乎是必问点回答时最好顺手说一句K8s 里对应的安全上下文配置是securityContext.runAsNonRoot: true这样面试官就会知道你 Docker 和 K8s 是一套知识体系。2.6 Docker Compose 与 Docker 命令实战常规但高频Compose 相关的题不会单独出很多但往往作为“你平时怎么管理容器”这个问题的延展。面试时我会遇到这种问题“你们的环境里有十几个服务怎么管理的”这时候如果只回答“一个个 docker run”就露怯了。Compose 的核心价值是把一个服务的完整配置声明在一个 YAML 文件里然后一条docker-compose up -d全部启动。里面需要掌握的关键配置项services服务的定义一个服务对应一个镜像加上它的配置。environment环境变量用来传配置。depends_on服务依赖顺序比如先启动数据库再启动应用。networks定义服务间的通信网络。volumes持久化数据。被问到“Compose 和 K8s 有什么区别”时核心答案是Compose 解决的是单机多容器编排的问题K8s 解决的是跨多台服务器的容器编排和调度的问题。两者不在同一个维度。3. K8s 核心概念Pod、控制器与服务发现3.1 为什么 Pod 是最小调度单元而不是容器这道题几乎是 K8s 面试的必答题而且对理解整个 K8s 设计哲学极其关键。先背结论Pod 是 K8s 调度和资源分配的最小单元但 Pod 里可以包含一个或多个容器。面试官想探的点是 Pod 这个概念为什么存在。我一般会从业务通信和资源管理的角度拆共享网络命名空间。Pod 里的容器共享同一个网络命名空间也就是说它们共享 IP 和端口空间可以通过 localhost 互相访问。这解决了同组容器的本地通信问题。比如日志采集容器和业务容器放在一个 Pod 里日志采集可以直接读业务容器写在共享卷里的日志文件不需要走网络。共享存储卷。Pod 可以挂载多个 volumePod 里的容器都能访问这些 volume适合做文件交换和共享配置的场景。生命周期绑定。Pod 是整体调度的里面的容器要么一起调度到同一台 Node 上要么一起被重新调度。这保证了依赖关系紧密的容器不会被拆到两台机器上。从这些设计点出发很容易延展到sidecar 模式。业务容器负责主要功能辅助容器负责日志收集、流量治理、配置同步这些“边车”功能两者在同一个 Pod 里共生。面试官如果追问“sidecar 和跨 Pod 通信有什么区别”你就应该想到这就是“共享网络和存储 vs 通过网络访问”的区别。3.2 控制器怎么选Deployment、StatefulSet、DaemonSet、Job面试中经常会有这种开放式场景题“现在要部署一个 MySQL 主从复制用 Deployment 行不行”如果回答“行”面试官就知道你还没理解控制器的适用场景。这里我整理一个高频对照表直接背下来就能应付大多数题目控制器适用场景选它而不是 Deployment 的原因Deployment无状态服务Web 应用、API 服务支持滚动更新、回滚、声明式伸缩每个 Pod 都是可互换的StatefulSet有状态服务数据库、消息队列、Redis 集群为每个 Pod 提供稳定的网络标识和稳定的存储Pod 编号有序DaemonSet集群级组件日志采集、监控 Agent、网络插件保证每个 Node 上恰好运行一个副本Job / CronJob一次性任务、定时任务批处理、数据清理执行完成后 Pod 自然结束不会像 Deployment 那样保持运行理解了这张表还要能讲清楚 StatefulSet 的三个核心能力才算是真正拿下这道题稳定的网络 ID。StatefulSet 里的 Pod 名字和 hostname 是有序且固定的比如mysql-0、mysql-1、mysql-2配合 headless service可以直接通过 Pod 名解析到稳定的 DNS 地址这个能力对有状态的分布式系统比如 master 节点相互发现很关键。稳定的存储绑定。每个 Pod 会绑定一个专属的 PVCPod 重建后存储卷还能恢复挂载到新 Pod 上数据不丢。有序部署和收缩。StatefulSet 可以配置按顺序创建和删除 Pod从mysql-0开始先启动 master再启动 slave这个顺序在很多分布式系统里有硬性要求。3.3 Service为什么 Pod 一旦重建 IP 就变流量却不丢这个问题对用过一段时间 K8s 的人来说肯定有体感。Pod 是“临时”的滚动更新、故障重启、扩缩容的时候Pod 会被杀掉重建IP 完全变样。那么客户端怎么访问答案是Service。Service 在逻辑上是一个稳定的访问入口它有一个固定 IPClusterIP和一个固定 DNS 名。Service 后面用 selector 关联一组 PodPod 的 IP 变化时Service 会自动感知并更新 Endpoint 列表。所以访问流程是客户端访问Service 的 ClusterIP:端口。K8s 通过 kube-proxy 或者 ipvs 规则把请求转发到后端的某个 Pod IP。Pod 挂了重建后controller比如 Deployment会自动创建新 Pod新 Pod 注册到 Endpoint 里Service 的转发目标也随之更新。这道题里容易漏掉的知识点是 Service 的几种类型ClusterIP只能在集群内部访问默认类型。NodePort在 ClusterIP 基础上在每一台 Node 上开放一个特定端口外部通过任意NodeIP:NodePort访问。LoadBalancer由云平台负载均衡器承载把外部流量引入集群一般是 NodePort 的上层封装云厂商实现了对应的 controller 之后才会生效。3.4 Ingress:外部流量进入集群的最佳入口面试时问“Service 已经能把流量转发给 Pod 了为什么还需要 Ingress”大多数候选人答不到点子上。一个集群里如果有五六个服务每个服务都用 NodePort 暴露那么外部访问就要记住一堆端口号而且端口容易冲突管理混乱。Ingress 的作用是在七层HTTP/HTTPS做路由分发让外部请求按域名或者 URL 路径转发到对应的 Service。常见的 Ingress 规则长这样apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress spec: rules: - host: api.example.com http: paths: - path: /v1 pathType: Prefix backend: service: name: api-service port: number: 80 - path: /web pathType: Prefix backend: service: name: web-service port: number: 80面试官一定会追问的是 Ingress 真正干活的是谁。答案是Ingress Controller。Ingress 只是一个资源对象它本身不转发任何流量真正在集群里跑着一个负载均衡器比如 Nginx Ingress Controller 或者 TraefikIngress Controller 监听 Ingress 资源的变化然后动态生成 Nginx 配置并重载。链路总结为外部请求 - Ingress Controller七层负载均衡 - Service - Pod这道题答全就同时展示了你在服务发现和流量治理两个方向的知识储备。4. K8s 控制器与控制循环理解声明式运维的本质4.1 提一个“无用”的问题Deployment 是怎么做到规模不变的这个问题在面试里表面上看很简单实际上背后是 K8s 最核心的声明式 API 和控制器模式。很多新人知道 Deployment 只管写replicas: 3但完全不知道这个期望状态是谁在维护。我在面试时最喜欢用这个问题来区分候选人到底是用过 K8s还是只看了文档假设你设置replicas: 3然后有人手动执行kubectl delete pod删掉了其中一个 Pod。过几秒钟你会发现一个新的 Pod 被创建了出来。谁干的这不是 Deployment 干的而是运行在控制平面里的Deployment Controller干的。Deployment Controller 内部有一个循环大致流程是从 etcd 里读取当前状态现在有几个 Pod 存活。从用户期望的声明里读取期望状态应该有 3 个 Pod。对比差异发现当前状态少于期望状态。通过 API Server 创建缺少的 Pod让集群状态向期望状态靠近。这个循环被称为控制循环control loop也是 K8s 整个系统工作的核心哲学。每当实际状态和期望状态不一致控制器就会介入修正。面试时如果能把这个闭环讲出来再举例说明“打补丁式的运维与声明式运维的区别”这道题基本就能拿到满分。这个设计直接决定了 Kubernetes 的一个重要特性系统是自愈的。任何一个组件的删除、崩溃、异常都会被对应的控制器修复到期望的状态这也是 K8s 相比手工运维脚本的巨大优势。4.2 探针到底在检查什么说清楚就懂运维了K8s 的存活探针liveness probe和就绪探针readiness probe是运维场景里最高频的题但很多人背了参数没搞懂使用场景的区别。我这样区分理解存活探针livenessProbe回答“这个容器是不是还活着”。如果探针失败K8s 会杀掉并重启容器。典型用途是检测死锁。比如一个 Java 进程还在跑但因为内存泄漏导致假死存活探针的 HTTP 请求超时失败K8s 就会把它杀掉重新拉起。就绪探针readinessProbe回答“这个容器能不能接收流量”。如果探针失败K8s 会把该 Pod 从 Service 的 Endpoint 列表里剔除但不会杀掉容器。典型用途是服务启动慢的场景。比如应用启动时要加载缓存需要 30 秒这段时间如果就绪探针没有通过Service 就不会把流量转发过来避免了用户请求打到还在加载的实例上。再往深了走还有启动探针startupProbe用于容器启动特别慢的场景让 K8s 知道“这个容器正在启动先别用存活性探针给我杀掉”。三个探针的使用场景捋清楚基本上服务可用性相关的场景题都能答出个一二三来。对应到定位思路面试官如果问“线上有个 Pod 一直重启”第一步一定是kubectl describe pod看探针配置再查容器日志确认是存活探针失败了还是进程本身就崩了。这里要记得区分存活探针失败导致的频繁重启和无探针时进程退出导致的 CrashLoopBackOff排查路径完全不同。5. 高频场景排查题从命令到思路面试到后期基本都是场景题。面试官会给你一个模糊的现象看你用工具和数据还原出问题根因。这里挑三个我遇到的最高频场景展开。5.1 Pod 一直 Pending一看就是集群资源不够了很多人会直接说“集群没资源了加节点就行”。但这个答案只蒙对了一半。Pod 卡在 Pending 状态意思是调度器kube-scheduler到目前为止集群里没有找到合适的 Node 可以运行这个 Pod。造成这个结果的原因很多常见的有节点资源不足Pod 请求的 CPU/内存比集群里所有可用节点的剩余空间都大。节点不满足亲和性规则比如 Pod 写了nodeSelector要求节点带某个 label但集群里没有任何节点带这个 label。缺乏 PVC 对应的存储比如 Pod 引用了 PVC但这个 PVC 一直 Pending底层没有合适的 StorageClassPod 也就无法调度。有污点没有容忍节点上打了taintPod 没有对应的toleration调度器默认不会把 Pod 调度上去。排查指令非常固定kubectl describe pod pod-name看 Events 部分调度器会把拒绝原因写在里面比如0/3 nodes are available: 1 Insufficient memory, 2 node(s) didnt match node selector。照着这个提示顺着看就行。5.2 CrashLoopBackOff容器反复重启的根本原因怎么找CrashLoopBackOff 是 K8s 里最常见的故障现象之一。看到这个状态表示容器启动后很快就退出K8s 正在以指数退避的方式不断重启它。出现 CrashLoopBackOff原因多到数不清但最常见的几类是启动命令错误比如启动命令里路径写错进程秒退。配置文件错误环境变量没传对应用启动时读取配置报错。缺少依赖比如应用依赖数据库但数据库还没有就绪应用启动后连接失败直接退出。存活探针失败探针第一次探测就没通过容器被 K8s 杀掉。资源限制导致 OOM容器内存限制设置太小JVM 或者应用进程还没初始化完就被杀。排查崩溃问题一把钥匙就够了kubectl logs pod-name --previous--previous是查看上一次容器实例的日志因为当前实例已经退出了常规kubectl logs经常拉不到有效日志。然后再配合kubectl describe pod查看 Exit Code 和 OOMKilled 标志基本能锁定 80% 的原因。5.3 滚动更新卡住怎么定位面试题里还有一道经典场景发布新版本后新老版本各占一半半天都滚动不完。这道题的核心是滚动更新的机制。Deployment 滚动更新不是一次性把旧 Pod 全删掉换成新 Pod而是逐步替换。默认的maxSurge是 25%maxUnavailable是 25%意思是更新过程中可以多出 25% 的 Pod同时最多有 25% 的 Pod 不可用。如果新 Pod 一直处于不可用状态滚动更新就会卡住。卡住的原因主要有两个新 Pod 就绪探针一直不通过导致新 Pod 无法进入可用状态旧 Pod 就不会被继续删除。资源不足新 Pod 创建后卡 Pending集群没有足够的资源容纳多余的maxSurgePod。排查手段是kubectl rollout status deployment/name kubectl describe deployment/name如果describe里显示新 ReplicaSet 一直等待 Pod 就绪那就去看新 ReplicaSet 下 Pod 的状态和事件继续绕回到上一节的排查思路。有一定经验的面试官会在这个问题后面追加一句“那你觉得什么情况下滚动更新回滚最合适”这时候可以引到发布暂停rollout pause、分批放量、以及金丝雀发布等发布运维策略。6. 安全与多集群面试里容易被忽视但很重要的方向这一块内容在过去比较少出现在基础题里但最近一年越来越常被问因为云原生面试正在从“能不能跑起来”走向“跑起来之后怎么管好”。6.1 容器以 root 运行的危害和最小权限原则面试官说“我在 K8s 里跑了一个容器没有配置任何安全上下文里面以 root 身份运行有什么问题”如果你的回答只是“不安全”这个答案太单薄。好的回答链路是容器共享宿主内核。容器隔离的是用户态视图内核是同一个。如果容器内进程是 root内核里有些操作比如加载内核模块、设置系统参数就不能被 namespace 隔离住。一旦攻击者通过容器漏洞逃逸拿到 root 权限宿主就沦陷了。Linux capabilities 和 seccomp。容器默认允许的权限集合比传统系统进程大得多最佳实践是给容器去掉不需要的 capabilities追加seccomp配置文件限制系统调用有必要的话再加AppArmor/SELinux。安全上下文。K8s 里可以在 Pod yaml 中配置securityContext: runAsNonRoot: true capabilities: drop: - ALL readOnlyRootFilesystem: true这个回答的价值在于你展示了从 Docker 到 K8s 的完整安全知识而不是停留在“不要用 root”这种结论上。6.2 多集群管理与备份迁移从整个行业趋势看Kubernetes 已经不单单是“在一个集群里跑容器”跨国多集群、多区域容灾、云原生中间件迁移已经成为运维团队的日常。面试官如果问“你们现在如何管理多个集群”通常是在探寻你有没有跨集群的运维能力。核心答案围绕三点展开集群配置管理用 GitOps 方式管理多个集群的资源配置所有基础设施变更走仓库 审批流每次变更可追溯。应用编排与分发负责运维的人更关注一套编排如何一键分发到多个集群中间涉及 Helm Chart 打包、镜像版本控制、环境差异化配置。备份与恢复etcd 是集群状态的唯一真源。生产环境里必须周期性备份 etcd 快照每套集群的备份机制都要提前演练。大部分“集群坏了数据丢了”的故障都源于没有可用的 etcd 备份。实际经验我建议至少每半年做一次完整的恢复演练。只备份不演练等于没备份因为快照文件损坏、版本兼容、恢复流程不熟练都会在关键时刻掉链子。7. 面试官视角下的答题策略与复习重点最后一部分想直接给你一些非常实际的建议。刷题时很多人的误区是“觉得答上来就算会了”但从面试官的角度一道题答得好和答得差之间的分界线非常清楚不要只给结论要给依据。比如“Service 网络不通”不能说“可能是 kube-proxy 有问题”要说“我先看 Service 的 Endpoint 列表确认有没有可用的 Pod再检查 kube-proxy 是否在运行然后查看 node 上的 iptables/ipvs 规则”。给你的每个判断一个依据面试官才有办法顺着你的思路继续下去。把答案组织成递进关系。同一个问题先答是什么再答为什么最后讲场景。如果时间紧就优先讲为什么和场景。诚实面对不会的题。千万不要硬编。可以这样回应“这个细节我没有在生产环境验证过但我了解大概的原理是……”。面试官并不要求候选人什么都会但很介意候选人张嘴就来、把没验证过的东西说成实战经验。以下是我的个人备查心得也是我认为刷这套题最有效的方式先掌握“由外向内”的链路。所有 K8s 问题都可以沿着“客户端访问 - Ingress - Service - Endpoint - Pod - 容器 - 镜像”这条链路去定位它属于哪一层。面试题看着千变万化最后绝大多数都会落到这条链路的某一环。把命令刻进肌肉记忆。kubectl describe、kubectl logs --previous、kubectl get events、kubectl rollout status这四个命令可以解决现场 90% 的 K8s 故障。不用怕被问“你刚才说的那个命令具体参数是什么”用多了自然会。练习用两分钟讲清一个组件。面试时会要求你回答得很精炼不要一口气 5 分钟讲完。先用两分钟讲清核心原理再等面试官追问细节点。这份 Docker 和 K8s 面试题总结我把容器基础的大部分内容已经覆盖到了。下一部分会继续补齐 K8s 的网络底层CNI、Calico/Flannel、存储体系PV/PVC/StorageClass、调度器原理nodeSelector/Affinity/Taint/Toleration、以及 etcd 的选主和 watch 机制。最后再提醒一遍面试题只是引子真正的底气和把控感永远来自你亲手在一个真实环境里敲过的每一行命令。
