企业官网建设流程全解析

1. 一次真实复盘：背了三个月八股，面试官三个追问我就卡住了

先说个我自己的经历。某次跳槽面试，前半小时聊得还行，docker和k8s相关的题我都答上了——镜像分层、Pod调度、Service类型，这些都是背过的。结果面试官突然问了一句："那你说说，docker run之后，容器里第一个进程到底是怎么被拉起来的？它和宿主机上的普通进程有什么区别？"

我当场愣住了。这个问题其实不难，考的是 namespace 和 cgroups，但我平时只会背"容器是隔离的进程"，真让我把 clone、pivot_root、mount 这条链路讲清楚，就露怯了。那次面试之后我花了两个多星期，把 Docker 和 K8s 的面试题重新整理了一遍，原则很简单：不追求题量，追求每个问题背后"面试官到底想确认什么"。

这份总结就是从那之后持续整理的，目前是第一版，先放出来，后续还会继续补。适合三类人看：准备容器相关岗位面试的候选人、团队里负责容器平台建设想查漏补缺的工程师、以及刚入门 Docker/K8s 想建立系统认知的同学。

我按面试的实际流程把内容分成了几个层次：先是最基础但最容易被追问出深度的容器与镜像题，然后是容器网络，再往上才是 K8s 的调度、服务治理、资源管理，最后是偏运维向的集群故障排查。这个顺序基本对应一轮技术面到终面的考察深度。

1.1 面试官不考答案，考的是你有没有自己动手碰过

你会发现一个规律：真正有分量的面试题，都长着一张"你肯定见过"的脸。比如"Docker 和虚拟机有什么区别""Pod 和容器的关系是什么""Service 有哪几种类型"。这些题在网上随便一搜就有标准答案，但面试官要的不是背诵版，而是你在实际部署、排查、调优过程中沉淀下来的理解。

举个典型例子。"镜像分层"这道题，初级答法是"镜像由多层组成，可以复用缓存"；中级的会讲 overlay2 的 lowerdir 和 upperdir、copy-on-write 机制；高级的会联系到容器写放大、镜像体积优化、多阶段构建的动机。同一个问题，三个人三种深度，面试官瞬间就能判断你处在哪个段位。

所以这份总结里，每道题我都尽量给出分层的回答思路：保底答法是什么，进阶可以补充什么，什么情况下主动提到底层原理会加分。这不是教你怎么炫技，而是告诉你知识边界在哪里——面试官也是人，他最怕的不是你不会，而是你用一个背熟的答案伪装会。

1.2 追问链才是真正的考题

我观察到的另一个现象是：现在的面试官很少直接丢一个开放题，而是用一个简单的引子开始，然后沿着你的回答一路追问。比如：

• 问：Dockerfile 里 CMD 和 ENTRYPOINT 有什么区别？
• 答：CMD 是默认命令，ENTRYPOINT 是入口点……
• 追：那我两个都写了，启动时怎么选？如果我传了参数进去，哪个会被覆盖？
• 再追：exec 形式和 shell 形式有什么不同？为什么推荐 exec 形式？
• 继续追：容器里 PID 1 为什么最好用 exec 形式跑？不这样会有什么后果？

你看，一道 CMD/ENTRYPOINT 的题，追问到最后已经涉及 Linux 信号处理、僵尸进程回收了。面试官不是要难为你，他是在顺着一条"如果这个容器真要跑生产，哪些细节会被踩到"的线来验证你有没有实战经验。

这份总结里我会把这类追问链完整写出来，每一环都给出解释。你看的时候不是去背，而是想象自己站在白板前面，用嘴把这条链顺下来。能顺下来，说明你真的懂了。

2. 镜像、容器与进程：Docker 基础题的正确打开方式

这一章是几乎所有技术面的第一轮必考，题目看起来都很基础，翻车率却高得离谱。原因很简单：大多数人只记住了一句话结论，没记住结论背后的机制。

2.1 镜像分层机制：从 docker pull 的进度条说起

高频题："Docker 镜像为什么能这么快传输和启动？"标准回答是镜像分层加 UnionFS。但建议你再往前走一步：说得出来 overlay2 的布局吗？

在 overlay2 驱动下，镜像的每一层都对应宿主机/var/lib/docker/overlay2/下的一个目录。容器启动时，所有只读层作为 lowerdir，容器自己的可写层是 upperdir，两者通过 merged 目录联合挂载。读文件时从上往下找，写文件时触发 copy-on-write——也就是先把 lowerdir 里的文件复制到 upperdir 再修改，所以容器内修改不会污染镜像层。

明白这个机制，你就能回答一连串追问：

• 问：为什么容器删除后所有修改都丢了？——因为修改都写在 upperdir，可写层随容器销毁，除非 commit 或挂载 volume。
• 问：为什么同一个镜像启动几十个容器不占几十份磁盘空间？——只读层共享，每个容器只有一份很小的可写层。
• 问：镜像层数越多越好吗？——不是，层数多会增加联合挂载的查找开销，还容易产生"下层文件被高版本误删"的连带问题，通常建议控制在合理范围内。
• 问：那怎么减小镜像？——多阶段构建、合并 RUN 指令、清理包管理器缓存、换更小的基础镜像，都是常见手段。

这里有个我实际踩过的坑：某次把一个镜像从 1.2GB 压到 160MB，只做了一件事——把构建阶段和运行阶段彻底分开，运行阶段只拷贝编译产物和必要运行库。面试里聊到这个例子，比背多少概念都有说服力，因为它说明你真的动手优化过。

2.2 CMD 与 ENTRYPOINT：一道题能问出经验的深浅

这道题出镜率极高，也是追问链最容易展开的。

保底回答：ENTRYPOINT 定义容器启动时执行的可执行文件，CMD 提供默认参数。如果 Dockerfile 里同时写了 ENTRYPOINT 和 CMD，运行容器时用docker run image args传入的 args 会替换掉 CMD，而 ENTRYPOINT 保持不变。

进阶回答要能区分 exec 形式和 shell 形式：

CMD ["nginx", "-g", "daemon off;"] # exec 形式，推荐 CMD nginx -g "daemon off;" # shell 形式，不推荐

exec 形式不会经过/bin/sh -c，容器 PID 1 就是那个可执行文件本身，信号能直接送达；shell 形式会先起一个 shell，再由 shell fork 子进程，nginx 不是 PID 1。这带来两个实际后果：一是docker stop发 SIGTERM 时，shell 形式的容器可能不会把信号转发给子进程，导致优雅退出失效；二是 PID 1 有回收僵尸进程的职责，shell 不一定会好好履行。

所以生产 Dockerfile 里通常推荐 exec 形式。K8s 场景下，如果镜像里的 ENTRYPOINT 写的是 shell 形式，preStop 钩子有时候会出现"钩子跑了，主进程还没收到信号"的怪问题，根因可能就在这。

2.3 容器里的 PID 1：为什么大家都推荐 tini

这个问题通常会以案例形式出现："容器里出现大量僵尸进程该怎么处理？"

原因是容器 PID 1 承担了两个职责：信号处理和僵尸进程回收。如果 PID 1 不是 init 类进程，而是业务二进制，往往要么不处理 SIGTERM，要么没法 wait 回收子进程。

实操解法是在 Dockerfile 里加 tini，或者直接用docker run --init，让 tini 当 PID 1，负责转发信号和回收僵尸。K8s 里很多基础镜像默认集成类似组件，目的都一样。

面试答题时能提到这个层次，就已经超出"会写 Dockerfile"的范畴了，它会让人觉得你处理过线上容器异常退出、进程残留这类问题，而不是只看过教程。

2.4 容器隔离的底层：namespace 和 cgroups 一个都不能少

这道题几乎必考："容器是什么？它和虚拟机有什么区别？"

保底答法：容器是进程级隔离，用 Linux 内核的 namespace 和 cgroups；虚拟机是硬件级虚拟化，每个 VM 有独立内核。

进阶答法要说得更细。容器的隔离来自 namespace：PID namespace 隔离进程号、Mount namespace 隔离挂载点、Network namespace 隔离网络栈、UTS namespace 隔离主机名、IPC namespace 隔离进程间通信、User namespace 隔离用户 ID。限制来自 cgroups：CPU、内存、磁盘 IO、PID 数等资源的配额。

这里有一个面试官特别爱追问的边界：同一个宿主机上所有容器共享内核，所以容器里的uname -a看到的是宿主机内核版本；也正因为共享内核，容器内不能随便加载内核模块、不能改全局 sysctl。这些"容器又不是真的虚拟机"的边界，能答上来才说明你真的理解隔离原理。

3. 容器网络：从 bridge 到 VXLAN，一道题就是一张链路图

网络是面试的重灾区。很多人能在网上把概念背个大概，一被追问细节就崩。这一章的题建议结合 tcpdump 和实际抓包去理解，光看文档是不够的。

3.1 单机容器网络：veth pair 和 iptables 是怎么配合的

高频题："默认 bridge 模式下，容器网络是怎么通的？外网访问容器端口映射又是怎么实现的？"

回答要按数据流拆：

1. 每个容器创建时会分配一对 veth 虚拟网卡，一端在容器内叫 eth0，另一端挂在宿主机 docker0 网桥上，名字类似 vethxxx。
2. 容器内的包从 eth0 发出，通过 veth pair 到达宿主机侧的 vethxxx，进入 docker0 这个 Linux 网桥。
3. 容器要访问外网时，docker0 发现目标不在本网段，于是把包交给默认网关处理——实际是一条 MASQUERADE（SNAT）规则，把容器 IP 换成宿主机出口 IP，回包再通过 conntrack 找回对应容器。

端口映射-p 8080:80则是 Docker 在宿主机 iptables 的链里加了一条 DNAT 规则，把宿主机 8080 端口的流量改写目标地址为容器 IP 的 80 端口。

追问方向一般是：

• host 网络模式下，容器直接用宿主机网络栈，没有独立 IP，性能好但隔离差。
• none 模式完全没有网络栈配置，常用于需要完全自定义网络的场景，比如跑一些网络抓包调试工具。
• 自定义 bridge 网络里，同一网段的多个容器可以天然互通，容器名还能当 DNS 用。

3.2 跨主机网络：Flannel、Calico 的取舍

K8s 里问跨主机容器网络，基本绕不开 CNI 插件。面试官常问："Flannel 和 Calico 有什么区别？你线上用哪个，为什么？"

Flannel 常见两种模式：

• VXLAN 模式：把容器网络包封装在 UDP 里，走宿主机网络转发，兼容性好，但多一次封装解封装，性能有损耗。
• host-gw 模式：直接在宿主机路由表里写下一跳路由，不封装，性能好，但要求所有 Pod 网段路由可达。

Calico 的典型做法是用 BGP 在节点间交换路由，默认是纯三层方案；它还有 IPIP 模式，适合某些底层网络无法直接路由的机房。Calico 的优势是配合 NetworkPolicy 做细粒度网络策略，Flannel 自身不带策略能力。

这题的高分回答不在于说谁好谁坏，而在于你知道按网络环境选型：底层网络简单、追求性能就选 host-gw；跨机房、底层不互通就选 VXLAN；要 NetworkPolicy、要更细的隔离能力就选 Calico。面试官要的是你脑子里的决策树，不是一句"我们用的 Calico"。

3.3 排查网络问题的答题套路

场景题非常常见："新部署的 Pod 能 ping 通同节点的另一个 Pod，但访问不了 Service 的 ClusterIP，怎么排查？"

思路大致是：

1. 先确认目标 Pod 是否 Ready，对应 Service 的 endpoints 里有没有真实 Pod IP。
2. 再确认 kube-proxy 是否生成了对应的 iptables 或 IPVS 规则。
3. 进入源 Pod，先 curl Service IP，再 curl 后端 Pod IP，判断是 Service 层的问题还是 Pod 自身监听问题。
4. 检查 conntrack 表是否被打满，netfilter 的 conntrack 满员会导致新连接建立失败，这是真实环境里很常见的隐形坑。
5. 如果涉及跨节点，再查 CNI 插件数据面的路由和封包情况。

能按这种链路答，面试官基本就认可你具备独立排查网络问题的能力了。顺序感本身就是一种能力展示。

4. Pod 生命周期与控制器选型：K8s 面试的分水岭

到了 K8s，题目的密度和深度都上来了。这一章先讲 Pod 本身，再讲控制器和调度，是考察重点中的重点，答得好不好直接决定你是在"中级"还是"高级"的档位。

4.1 Pod 为什么是最小调度单元：pause 容器的作用

高频题："Pod 和容器是什么关系？一个 Pod 能不能有多个容器？为什么？"

一个 Pod 里可以跑多个容器，但真正用对的是"紧密协作的进程组合"——比如一个业务容器加一个日志采集 sidecar、一个业务容器加一个网络代理。它们共享同一个 Network namespace，所以可以用 localhost 互访，也常共享 volume。

支撑这个共享的是 pause 容器（现在叫 sandbox 容器）。Pod 创建时先启动 pause 容器，由它先持有网络栈和命名空间，其他业务容器加入进来。这样就算业务容器频繁重启，Pod 的网络身份也保持稳定，IP 不会变。这个设计解释了为什么 Pod 是最小调度单元——因为网络、存储这些资源的边界是 Pod，不是单个容器。

4.2 init 容器与生命周期钩子

追问："如果业务容器启动前需要等依赖服务就绪、拉取配置，怎么做？"

答案是 init 容器。init 容器按顺序串行执行，全部成功退出后才启动主容器，适合做初始化、权限准备、数据预加载。需要注意 init 容器和主容器是分开的镜像，init 容器失败会反复重试，也会影响 Pod 状态。

生命周期钩子 postStart 和 preStop 也是高频考点：postStart 在容器创建后立刻执行，注意它和主进程没有严格的先序保证，也就是说不能假设主进程已经完成初始化；preStop 在容器终止前执行，常用来做优雅下线、从负载均衡摘除节点。

有一个实际经验：preStop 里调用 sleep 配合"把该容器从 Service endpoints 摘除"再退出，是避免滚动发布瞬间 502 的常见招。具体做法是 readiness 探针先失败，endpoints 摘除，sleep 几秒等存量请求结束，然后容器才真正退出。这套组合拳值得背下来。

4.3 探针的三兄弟：liveness、readiness、startup

这道题几乎是必考，我还没见过哪场技术面完全不问探针的。

• livenessProbe：失败到阈值就重启容器，判断进程是否活着。
• readinessProbe：失败到阈值就把 Pod 从 Service endpoints 摘除，判断是否可以接流量。
• startupProbe：给启动极慢的应用用的，防止 liveness 在启动阶段误杀。

面试官爱追问"为什么要有 readiness 和 liveness 两个，一个不够吗"——因为重启和摘流量是两回事：进程活着不代表它已经加载完配置、依赖已经就绪，把它从服务列表摘掉比重启更合理。liveness 管生死，readiness 管流量，职责不能混。

我见过不少生产事故，是 liveness 配了一个依赖数据库的检查，数据库一抖动，整批 Pod 被反复重启，越重启越起不来。正确做法是：liveness 只查本进程的基本健康，readiness 可以查依赖。这个区分就是实战经验和背答案的区别。

4.4 控制器选型：Deployment、StatefulSet、DaemonSet 怎么选

面试现场最容易出场景题："现在要部署一个 MySQL，用 Deployment 行吗？"

Deployment 适合无状态服务，滚动更新、副本管理、回滚都方便。StatefulSet 适合有状态服务，特点是有稳定的网络标识（Pod 名固定）、稳定的持久化存储（每个副本对应独立 PVC）、有序的部署和删除。MySQL、Redis 集群、ZooKeeper 这类需要稳定身份的多用 StatefulSet。DaemonSet 保证每个节点跑一个 Pod，适合日志采集、监控 agent、网络插件。

回答时再加一句"有状态服务的数据可靠性不只是靠 StatefulSet，存储本身的备份和高可用要看下层存储方案"，会让面试官觉得你想问题比较全面，而不是只会背控制器定义。

4.5 调度器与亲和性：污点、节点选择与容忍度

高频题："K8s 是怎么决定一个 Pod 放哪个节点的？"

过程大致是：kube-scheduler 先做过滤，筛选满足资源、端口、亲和性、污点容忍条件的节点；再做打分，参考资源余量、分散性等；最后选分最高的节点绑定。

亲和性相关概念要分清：

• nodeSelector：最简单的节点标签选择。
• nodeAffinity：支持硬要求（requiredDuringScheduling）和软偏好（preferredDuringScheduling）。
• podAffinity / podAntiAffinity：让 Pod 靠近或避开某些 Pod，比如把同应用的副本分散到不同节点。
• taint 和 toleration：节点打污点，Pod 容忍污点才能调度上去。控制面默认有 NoSchedule 污点，所以业务 Pod 不会跑上去。

这里补充一个实战细节：给关键节点打上专用污点、给关键应用配置对应 toleration，可以避免"混部"导致的资源争抢问题。这个用法在面试里主动提出来，比单纯背概念更能体现你对调度的理解。

5. Service、DNS 与 Ingress：服务治理考题的完整链路

这一章的题可以连成一条线：流量从集群外进来 → Ingress 路由 → Service 负载均衡 → 后端 Pod → Pod 之间互相访问走 DNS。面试官经常从这条线里抽一个点让你展开。

5.1 kube-proxy 三种模式对比

这道题考的是"Service 的 ClusterIP 是怎么生效的"。

• userspace 模式：老古董，请求先进 kube-proxy 进程再转发，性能和稳定性都不行，现在基本不会用。
• iptables 模式：默认模式，kube-proxy 把 Service 的 ClusterIP 写进 iptables DNAT 规则，随机选中一个后端 Pod。规则数量随 Service 和 Endpoint 数量增长，量大后更新全量 iptables 会比较吃力。
• IPVS 模式：基于内核的 IPVS 模块，支持多种负载均衡算法，大量 Service 场景性能更稳。

追问："为什么 IPVS 模式下还有可能出现连接不均衡？"可以回答：IPVS 默认也依赖内核的连接跟踪来保持回包正确性，配置的调度算法和 conntrack 状态都会影响实际分布。能答到这里，说明你不是只知道 IPVS 比 iptables 快这一句话。

5.2 Service 类型与 Headless Service

四种类型要能脱口而出：ClusterIP（集群内虚拟 IP）、NodePort（在每个节点上开端口，流量转给 ClusterIP）、LoadBalancer（负载均衡器接 NodePort 或 ClusterIP）、ExternalName（DNS 映射到外部域名）。

Headless Service 是容易被忽略但很有用的点：clusterIP: None，没有虚拟 IP，DNS 直接返回后端 Pod 的 IP 列表。StatefulSet 的稳定 DNS 名，以及某些需要客户端自行负载均衡的场景，都依赖它。能主动提到 Headless Service 和 StatefulSet 的搭配，往往能加印象分。

5.3 Ingress 与 Ingress Controller 的关系

"Service 已经能提供集群内访问和 NodePort 暴露了，为什么还需要 Ingress？"

因为 Ingress 解决的是 HTTP/HTTPS 七层路由问题：按域名、按路径把流量分发到不同 Service，统一管理证书、rewrite、限流。Ingress 本身只是一组 API 资源，真正干活的是 Ingress Controller。多数面试官会承认，基于 Nginx 的 Controller 是这里最常见的参考实现。

如果面试官问"Ingress 的请求链路是怎样的"，回答顺序是：客户端 → 域名解析到 Ingress Controller 的入口地址 → Controller 根据 Ingress 规则路由 → 转发到对应 Service 的 ClusterIP → 再转到后端 Pod。把这个链路说清楚，比背 Ingress 的 YAML 字段有用得多。

5.4 集群内 DNS 解析的坑

还有一类高频题是 DNS。集群内完整域名规则要清楚：<service>.<namespace>.svc.cluster.local，同一 namespace 下可以直接用服务名，跨 namespace 要用<service>.<namespace>。

实际排障中常见的问题包括：DNS 解析结果和实际 Pod IP 不同步、节点上的 search domain 太长导致每次解析发一堆查询、Pod 里 nslookup 正常但业务连接超时。这些问题都需要分层看：先看 DNS 服务器本身，再看 Pod 的 resolv.conf，最后看业务代码是否缓存了 DNS 结果。面试里能讲出一个具体的 DNS 故障案例，是很加分的。

6. 资源配额、探针与 HPA：场景题里最容易被扣分的细节

这一章的题通常不以"是什么"的方式出现，而是藏在场景里。很多候选人前面几轮答得不错，到这里开始暴露对生产运维细节的陌生。

6.1 requests 和 limits：为什么 CPU 按分、内存按绝对量

高频题："requests 和 limits 有什么区别？只写 limits 有什么风险？"

requests 用于调度器做资源评估和节点分配，limits 用于限制容器实际可用的资源上限。

• CPU 是可压缩资源，CPU limits 用的是调度周期里的时间片配额，超了只会被限流，进程不会死。
• 内存是不可压缩资源，内存 limits 超了会被内核 OOM kill。

只写 limits 不写 requests 是个经典坑：没写 requests 时系统会按 limits 计算调度，导致节点资源被"虚占"，明明没有那么多实际负载，新 Pod 却调度不上去。生产里建议明确区分两者诉求，并理解 QoS 等级对驱逐顺序的影响。

QoS 等级这里顺便说一下：

• Guaranteed：requests 和 limits 都设置且相等。
• Burstable：requests 设置了，但 limits 更大或部分未设置。
• BestEffort：什么都没设置。

节点资源紧张时，驱逐顺序是 BestEffort 优先，Guaranteed 最后。记住这个顺序，很多"为什么我的 Pod 被杀了"的问题就有答案了。

6.2 HPA 的缩放原理

HPA 题通常跟资源题连着出："HPA 是怎么拿到 CPU 指标的？扩容公式是什么？"

链路是：metrics-server 通过 kubelet 的 cAdvisor 采集容器指标，HPA 控制器周期性读取，按公式计算期望副本数：期望副本数 = ceil(当前副本数 × 当前指标值 / 目标指标值)。为了防止频繁抖动，HPA 有冷却窗口。

需要注意的是，HPA 只能处理有明确伸缩意义的指标，比如 CPU、内存；自定义业务指标（如队列长度、QPS）还需要额外的采集链路，比如 Prometheus Adapter。面试官听到你提到这层，就知道你用过不止默认的 CPU 扩容。

6.3 节点压力与 Pod 驱逐

这类题常以故障形式出现："节点内存快满了，为什么这几个 Pod 被驱逐了？"

kubelet 会根据节点内存、磁盘等压力触发驱逐，驱逐顺序优先考虑 QoS。理解 QoS 等级的来源，有助于解释为什么有的 Pod 幸存、有的被清掉。这是一个很容易被忽略但生产价值很高的考点。

还要注意磁盘压力：镜像拉取失败、容器日志占满磁盘，都可能触发驱逐。面试时能把驱逐从"内存"延伸到"磁盘 inode 耗尽"，你就已经超过大部分候选人了。

7. etcd、证书与故障排查：终面压轴题的应答套路

到了终面，面试官基本不考定义，考的是你面对真实故障时的应变能力。这一章的题没有标准答案，但有标准思路。

7.1 etcd：集群的大脑和它的备份恢复

问 etcd 的题通常不是问 Raft 协议细节，而是考实操意识："etcd 备份怎么做？节点挂了怎么恢复？"

要点：etcd 作为集群的存储层，保存了所有资源对象的状态。建议定期做快照备份，常见做法是 etcdctl 的 snapshot save。恢复时要注意版本匹配，以及恢复方式对集群成员的影响——通常是所有 etcd 节点停止后，用快照替换数据目录再重启。

这里分享一个真实教训：某团队只备份了 etcd 快照文件，从没验证过恢复流程，真到灾难场景才发现快照版本和 etcd 二进制版本不一致，恢复过程极其波折。所以"备份可恢复性"本身，要和"备份"一起进面试回答。能说出这个细节，说明你真的为最坏情况做过演练。

7.2 控制面组件与证书体系

"kube-apiserver、kube-controller-manager、kube-scheduler 各负责什么？"这道题简单，但常被追问到"整个请求从 kubectl 到 Pod 的链路"。

完整链路大致是：kubectl → kube-apiserver（认证、鉴权、准入控制）→ 写入 etcd → kube-scheduler 调度 → kubelet 通过 watch 拿到 Pod 定义 → 调用容器运行时创建容器。

其中认证方式、RBAC 角色绑定、ServiceAccount 的 Token 机制，都是终面常考方向。比如"Pod 里访问 K8s API 用的是谁的证书""为什么默认的 ServiceAccount 权限很小"，这些题的目的是确认你理解安全边界的实际运作，而不只是会写几个 RBAC YAML。

7.3 故障排查场景题：从表象到根因

终面最爱出的题目是："线上有 Pod 一直 CrashLoopBackOff，你怎么办？"这是考察排障综合能力，回答建议按顺序来：

1. kubectl describe pod看事件：镜像拉取失败、探针失败、OOMKilled，还是正常 ExitCode 非零。
2. kubectl logs看容器日志，注意 CrashLoopBackOff 时前一个容器实例的日志往往才是有用的，因为当前实例可能一直没起来。
3. 如果是探针导致的重启，检查探针配置和启动速度。
4. 如果是 OOM，检查 limits 是否过小、JVM 这类应用是否有额外堆外内存。
5. 最后看节点资源、镜像仓库、网络等外部依赖。

回答这类题的关键不是背命令，而是展示出你有分层排除的习惯：先事件，再日志，再配置，再环境。每走一步都要说清楚"这一步排除了什么可能"，这才是面试官想看到的。

7.4 Node NotReady 和资源泄露排查

另一个高频场景是"节点变成 NotReady"。常规思路：

1. 看 kubelet 状态和日志。
2. 看节点资源：磁盘满、内存耗尽、PID 耗尽都可能让 kubelet 上报 NotReady。
3. 看网络：kubelet 到 apiserver 的连接是否正常，证书是否过期。
4. 如果是大规模节点 NotReady，考虑镜像预拉、资源风暴等原因。

我实际遇到过最隐蔽的一次 NotReady，根因是某个节点上数据盘所在的 inode 耗尽，容器运行时无法创建新容器，kubelet 感知后标记 NotReady。很多工程师先看磁盘空间，忘了看 inode。df -i这个命令，在面试里主动提出来会很加分，因为它说明你排过真实故障。

8. 未完待续：后续想补齐的几个专题

这次先整理到这里。坦白说，容器和 K8s 的面试题体系太庞大了，一次很难写完。目前这份已经覆盖了从镜像、网络、Pod、控制器、服务治理到资源管理和排障的主线，但还缺几块我认为同样高频的内容。

我计划后续补这几个专题：

• 容器安全的面试题：镜像扫描、运行时安全、最小权限原则、Pod 安全标准。
• 存储与持久化的面试题：PV/PVC/StorageClass 的完整链路、动态供给、常见存储插件对比。
• 云原生生态与 GitOps：Helm、Operator 模式、声明式交付相关的基础考点。
• 更细的 kubectl 排障技巧和现场模拟题。
• 新特性考点：Webhook、Gateway API、Sidecar 容器等。

另外我自己复习下来有个体会：面试题终究是提醒你"哪些知识点重要"的索引，真正到面试场上能稳定输出的，一定是建立在亲手部署、排障、复盘基础上的理解。如果你正在准备面试，建议每读完一类题，就去自己环境里跑一遍题里的场景——建个多节点集群、故意破坏一个 Service 再看流量怎么走、把某个 Pod 的探针故意配错观察行为。这个过程比刷十遍题都值。

等下一批题目整理完，我会继续把这份总结往下写。也欢迎你留言告诉我，你遇到过哪些记忆深刻的 docker 和 k8s 面试题，我尽量在下一版里补进去。