清浅池塘我是面试官，也被人面试过。面过的候选人里，能把Kubernetes常见问题背得滚瓜烂熟的大有人在，但真正能把"为什么这样设计"讲清楚的人，一年遇不到几个。Kubernetes的知识点就像一棵树，如果你只摘叶子，背再多面试题也经不住深挖一层。这篇文章我梳理了这些年积累的Kubernetes核心知识点，全部按面试问答的方式来写，但重点放在答案背后的逻辑和关联上，适合正在准备Kubernetes相关岗位面试的读者，也适合那些用Kubernetes做部署但总觉得哪里没吃透的开发者。
1. 面试官想从Kubernetes问题里看出什么
先把话放在前面：面试官问你Kubernetes知识点，很少是为了考你API怎么拼写，而是想通过你的回答判断三件事——你对分布式系统的理解深度、你排障时的思维路径、以及你有没有真正在生产环境里摸爬滚打过。这篇文章覆盖的内容基本都是围绕"理解深度"和"实战经验"两个维度展开的。
1.1 不要只背"是什么"，要讲清"为什么"
举个最常见的例子。面试官问"什么是Pod"，十个候选人里八个会回答"Pod是Kubernetes里最小的调度单元"。这个答案对不对？对，但毫无信息量。换个说法：Pod是Kubernetes中一组共享网络命名空间和存储卷的容器的集合，它是调度的原子单位，容器只是Pod内的普通成员。这样回答，面试官立刻就能判断你是背过概念还是真的理解Pod存在的意义——为什么要引入Pod这个层？因为多个进程共享同一个网络栈和存储上下文的需求太常见了，比如日志采集sidecar需要和业务容器共享网络才能访问localhost，这种场景必须有Pod这个抽象层。
类似地，当面试官问"Deployment和StatefulSet的区别"时，"一切都好"，SDN插件通过CNI给Pod分配IP，kubelet调用CRI运行时启动容器，kube-proxy根据Service配置写入转发规则。这套链路里，每一条消息的流向都有明确的协议和端口定义，生产环境排障时你能快速判断问题出在哪个环节。
1.2 面试里最常见的"追问节奏"
我面试别人时特别喜欢用连环追问的方式来验证候选人是不是真的懂。比如：
第一次问："Kubernetes的调度器是怎么工作的？"——大多数人都能答上"过滤加打分"。
第二次问："如果一个Pod一直Pending，你怎么排查？"——有人开始卡壳了。
第三次问："节点资源充足，但Pod还是Pending，是什么原因？"——到这个层面，能答上来的人基本就是有真实排障经验的。
这种追问节奏，比直接问"kubectl describe pod看到什么字段"要有效得多。所以这篇文章里，我在每个知识点下面都加了类似的追问视角，你能接住两三轮，面试基本就稳了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Pod、容器与探针的底层配合逻辑
Kubernetes里最核心也最容易被低估的概念就是Pod。很多初学者把它理解成"装容器的盒子"，实际上Pod有着非常具体的设计意图，面试中围绕Pod展开的问题通常能拉开候选人的档次。
2.1 Pod为什么需要pause容器
这是我在面试时特别喜欢问的一个细节。很多人知道Kubernetes创建Pod的时候会先启动一个pause容器（或叫infra容器），但不知道为什么。
pause容器的核心作用是作为Pod内所有容器的"基础设施"——它在Pod创建时第一个启动，负责创建并持有Pod的网络命名空间、PID命名空间（1.0版本之后）、IPC命名空间和UTS命名空间。后面启动的业务容器通过JoinNetworkNamespace的方式"加入"pause容器的网络栈，这样Pod内所有容器才能通过localhost互相通信，才能共享同一个IP地址。
这个设计不是Kubernetes团队拍脑袋想出来的，而是源于对实际问题的思考。不是每个进程都适合用"一个容器一个进程"的方式直接跑，比如一个应用既需要Nginx提供HTTP服务，又需要一个独立的sidecar进程负责日志采集，这两个进程确实有共享网络栈的需求，如果没有Pod这层抽象，你就得把所有功能塞进同一个容器里。也正是因为pause容器持有全部基础设施命名空间，当一个容器崩溃退出后，Pod内的网络栈不会受影响，其他容器可以继续工作。
追问一句：既然PID命名空间共享，那Pod里的进程能看到彼此吗？答案是pause容器本身和容器内PID1的进程关系需要开启shareProcessNamespace选项才能互相可见，默认是关闭的。这个细节知道的人不多，但在面试中如果主动讲出来，会非常加分。
2.2 容器探针的三种类型和使用场景
探针问题几乎是Kubernetes面试必考的内容，我认为核心不在于记住三个探针的名字，而在于讲清楚它们的配合逻辑和典型坑。
LivenessProbe决定容器要不要被重启，ReadinessProbe决定容器要不要从Service的Endpoints里摘除，StartupProbe决定——这句话我说得直白一点——给前两个探针争取多长时间。为什么要分三种？如果你有一个Java应用，启动就需要两分钟甚至更长，而容器本身启动很快，LivenessProbe可能在启动阶段就探测失败，直接触发重启，陷入重启循环。StartupProbe就是为这种场景设计的，它成功之前，Liveness和Readiness探针都会暂停工作，给慢启动应用留出一条活路。
三种探针的对比我用一个表格来总结，这个表格在面试复习时可以直接背：
| 探针类型 | 失败后果 | 典型场景 | 需要注意的坑 |
|---|---|---|---|
| LivenessProbe | 重启容器 | 进程死锁、内存泄漏导致无法响应 | 不要依赖外部依赖做Liveness判断，否则一次数据库抖动会让整个集群反复重启所有Pod |
| ReadinessProbe | 从Service Endpoints中摘除 | 应用初始化未完成、依赖服务不可用 | 探针超时时间太短会导致正常流量频繁中断 |
| StartupProbe | 重启容器（但给了缓冲时间） | 慢启动应用 | 失败阈值配太小，无法覆盖真实的启动时间 |
这里分享一个我踩过的真实坑：刚开始做容器化改造的时候，我把数据库连接检查放进了LivenessProbe，结果是数据库一主从切换，所有Pod的Liveness全部失败，集群进入连锁重启，故障时间从预期的5分钟延长到了40分钟。后来才想明白，Liveness探针应该只检查"当前进程是否还能正常提供内循环服务"，比如HTTP服务检查一个本地健康端点，外部依赖的健康状态应该交给ReadinessProbe去判断。
2.3 Pod生命周期、重启策略与优雅终止
面试中还经常考Pod的phase流转：Pending→Running→Succeeded/Failed，以及Unknown状态的含义。这里我重点讲一个细节——Pod的重启策略（restartPolicy）和Job场景的关系。
restartPolicy有Always、OnFailure、Never三种。很多人以为重启策略是"容器崩没崩"这个维度，但实际上它是"Pod里的容器退出后，kubelet要不要把它拉起来"这个维度。默认情况下，Deployment管理的Pod用Always，保证服务不中断。但在Job和CronJob场景里，如果任务跑完了，容器正常退出（exit code 0），Pod应该进入Completed状态，而不是被反复重启。所以Job场景通常配Never或OnFailure，否则任务永远结束不了。
另一个面试必考点是Pod优雅终止（Graceful Shutdown）的过程。当你执行kubectl delete pod时，Kubernetes会先向Pod发送SIGTERM信号，然后等待一个宽限期（默认30秒，可以在Pod的spec.terminationGracePeriodSeconds里修改），宽限期结束后如果进程还在，就发送SIGKILL强制杀死。
这个流程里的"坑"在于：如果你的应用只监听了SIGINT没有监听SIGTERM，或者处理信号的时间超过了宽限期，就会被迫强杀，没有任何优雅终止可言。我在生产环境里见过不少因为处理不了SIGTERM导致的"优雅终止失效"事故。
3. Deployment与工作负载控制器的滚动更新逻辑
从面试频次来看，工作负载控制器是绝对的高频区，其中Deployment又是重中之重。这部分的考点已经从"会创建Deployment"升级到"能讲清楚一次滚动更新过程发生了什么"。
3.1 ReplicaSet和Deployment的层级关系
现在的Kubernetes面试里，很少有人直接问你"ReplicaSet是什么"，但几乎所有人都会问"Deployment的滚动更新是怎么实现的"。如果你能讲清楚"Deployment→ReplicaSet→Pod"这三层的协作方式，就把两代控制器（ReplicaController→ReplicaSet）和Deployment的关系全部串起来了。
Deployment本身不直接管理Pod，它创建和管理ReplicaSet。一次滚动更新发生时，Deployment会创建一个新的ReplicaSet，然后将新RS的副本数从0逐步增加到目标值，同时把旧RS的副本数逐步减少到0。这就解释了为什么更新过程中你会看到两个RS同时在运行——一个承担旧的Pod，一个承载新的Pod。
这里有一个实际排障中非常有用、但面试中很少人主动提到的细节：指定revision回滚时，kubectl rollout undo deployment/xxx --to-revision=2，这个命令的本质是将新RS的副本数归零、把旧RS的副本数恢复。如果你想保留多几个版本的RS以便快速回滚，要记得调高spec.revisionHistoryLimit，默认是10，生产环境建议根据发布频率适当调大，否则回滚选项会丢失。
3.2 maxSurge和maxUnavailable的参数博弈
滚动更新的两个关键参数是maxSurge和maxUnavailable，它们直接决定了发布过程中Pod数量的变化。我用一个具体例子来演算：
假设replicas=10，maxSurge=25%，maxUnavailable=25%。
- 滚动开始时，旧的RS有10个副本，此时Kubernetes会先创建新的Pod，最多允许额外创建2个（10 x 25% = 2.5，向下取整），所以运行中的Pod总数最多是12个。
- 同时允许最多2个旧Pod处于不可用状态，所以删除操作也会同步进行，最终维持"总数不超12，可用Pod不低于8"这个约束。
如果你的服务流量有波峰，或者启动速度慢，建议把两个参数都调小一点，比如maxSurge=1，maxUnavailable=0，也就是"先创建一个新的，等它Ready后再杀一个旧的"，这样发布期间不会出现断流，缺点是速度慢。反过来，如果能接受短暂降级，就用maxSurge=0，maxUnavailable=1，先把旧Pod全部杀掉再拉新的，这时会有短暂的可用副本为0的时间窗。这两个参数不是随便配的，它们直接决定你发布策略的"可用性预算"。
3.3 StatefulSet、DaemonSet与Operator的定位差异
StatefulSet的面试考点集中在三个关键词：稳定的网络标识、稳定的持久化存储、有序的部署和收缩（scale）。和Deployment最大的区别在于，StatefulSet每个Pod的标识是透明的——Pod的名字带有序号，比如web-0、web-1，对应的PVC也各自独立，Pod在重新调度后还能拿到同一个PVC的数据。面试官如果问你"为什么不直接用Deployment挂共享存储来跑数据库"，你就从这三个维度回答：网络标识不稳定、每个实例需要独立存储、缩容扩容不能乱序。
DaemonSet的考点相对简单：保证集群内每个符合条件的节点都运行一个Pod，典型场景是节点监控（node-exporter）、日志采集（fluentd、filebeat）、网络插件（calico的节点端组件）。值得多说一句的是，DaemonSet的默认调度策略在过去版本中是忽略未调度的节点和不可调度节点的，所以排查DaemonSet Pod没起来时，要记得检查节点的taint和污点耐受配置。
Operator这个知识点这两年越来越高频。直白的理解是：Operator = 自定义资源定义（CRD） + 控制器逻辑（Controller），它把运维某类有状态应用的领域知识编进代码里，实现了"应用本身可以被Kubernetes管理"。面试中如果能说出"etcd-operator、prometheus-operator是最常用的例子"，再补一句"Operator本质上也是一个控制器，只是它watch的是自定义资源"，基本就及格了。想要深入的话，可以提一下helm和Operator的区别——Helm是打包分发工具，Operator是生命周期管理工具，一个管安装升级，一个管运行状态自愈。
4. Service网络：ClusterIP、DNS与Ingress的层层穿透
Service相关的知识，我的经验是：只要网络部分你自己能画通一条从外部流量到Pod的路径，Kubernetes的中级岗位基本就没有短板。
4.1 ClusterIP为什么是"虚拟"IP
ClusterIP是Service的一种类型，它提供一个集群内部虚拟IP。说它"虚拟"，是因为这个IP并不是绑定在某个具体网卡上的，它没有对应的真实设备，只存在于iptables/IPVS规则里。数据包的目的地址是ClusterIP，经过节点上的转发规则后才被改写为某个具体Pod的IP。
理解这一点对排障特别重要。很多人遇到"Service通但Pod不通""ClusterIP ping不通"这类问题时一脸懵，其实如果你清楚ClusterIP是虚拟的，就知道它本身就不支持ICMP（ping），因为它没有网卡实体。遇到Service不通，正确的排查路径是：先确认Endpoints有内容、再看kube-proxy有没有生成对应规则、最后检查Pod是否Ready且标签匹配。
kube-proxy的不同工作模式，这里我用一张表说明：
| 模式 | 工作原理 | 优点 | 缺点 |
|---|---|---|---|
| userspace | 用户态代理转发 | 兼容性最好 | 性能极差，已基本废弃 |
| iptables | 内核态Netfilter规则链 | 性能好、配置简单 | 规则数量多时更新延迟大、随机转发（无法保持同一来源IP到同一Pod） |
| IPVS | 内核态LVS负载均衡 | 支持更多负载均衡算法、规则更新效率高、性能优 | 部分环境需要额外内核模块（ip_vs、ip_vs_rr等） |
这里再补一个面试加分点：使用iptables模式时，Service的ClusterIP被写入NAT规则中，如果集群Service数量超过几千，iptables规则会变得非常庞大，规则更新时CPU占用飙升。很多大集群切换到IPVS模式就是为了解决这个问题。如果面试官问"为什么Service在Pod数量很多的情况下性能下降"，你能主动引到这个方向上，绝对是加分项。
4.2 Service的流量路由细节与headless service
Service通过selector选择一组Pod，然后把这些Pod的IP写入Endpoints（或EndpointSlice，新版本中EndpointSlice已经成为默认）。当负载均衡算法收到转发请求时，它会在Endpoints列表里选择一个Pod作为目标。这就是Service做负载均衡的底层逻辑。
如果你给Service设置了clusterIP: None，它就是一个headless service，不会分配ClusterIP，kube-proxy也不会为其生成转发规则。此时DNS会直接返回后端所有Pod的IP列表，而不是一个虚拟IP。这个机制在两类场景中特别常用：一类是StatefulSet需要获取实例列表的场景（比如数据库集群里的节点互相发现），另一类是客户端需要自行做负载均衡的场景（比如某些框架内置了对多IP的处理能力）。面试时能讲出headless service对StatefulSet网络发现的支撑作用，说明你对有状态应用在K8s上的运行机制是有实战理解的。
4.3 DNS解析、Ingress与Service的区别
集群内的DNS服务（CoreDNS）是Kubernetes服务发现的基础设施。一个Service创建后，在集群内部可以直接通过<service-name>.<namespace>.svc.cluster.local这个完整域名访问到。需要特别注意的是，跨Namespace访问时不能省略namespace部分——my-service和my-service.default指向的是完全不同的Service。使用kubectl run创建临时pod做测试时，我自己经常因为漏掉namespace后缀踩坑。
Ingress和Service的区别，用"总机"来类比最直观：Service是分机，Ingress是前台总机。Ingress根据域名和URL路径把请求路由到不同的Service，再由Service转发到具体的Pod。Ingress本身只是一个API对象，真正干活的是Ingress Controller（常见的有nginx-ingress、traefik、kong等）。如果你只创建了Ingress资源但没有部署Ingress Controller，这个Ingress不会产生任何实际效果——这个坑我见过很多新手踩，面试中主动讲出来会显得你确实部署过。
5. 调度器的一票否决与软硬约束
调度器的知识点在今年Kubernetes面试中明显变多了，可能是因为越来越多的公司开始关注大规模集群的稳定性问题。调度部分的考察核心，说到底就一句话：一个Pod被放到某个节点之前，系统做了哪些判断。
5.1 调度流程的两阶段：过滤与打分
Kubernetes默认调度器（kube-scheduler）的工作可以简化为两个阶段：
第一阶段是过滤（Filtering），也叫Predicates。把不满足Pod硬性条件的节点全部排除掉。常见的过滤条件包括：节点资源是否满足requests、节点是否有匹配的nodeSelector、节点是否被某些taint且Pod没有对应toleration、节点端口是否冲突等。
第二阶段是打分（Scoring），也叫Priorities。在通过过滤的节点里按一系列优先级函数打分，选择分数最高的节点。打分因素包括资源利用率（尽量选择资源占用少的节点）、Pod亲和性/反亲和性、节点上已有Pod数量、节点标签匹配度等。
我在生产环境里遇到过一个典型的调度问题：一个Pod一直Pending，describe之后发现提示0/8 nodes available: 8 Insufficient nvidia.com/gpu。排查后发现是节点上GPU资源已经被占满，但应用没有配置对应的nodeSelector，调度器只能把它放在普通节点上，而普通节点没有GPU资源。后来通过给GPU节点打上专用标签并配置nodeSelector + toleration解决。这个案例说明，过滤阶段的坑往往不是"过滤错了"，而是"Pod的限制条件没有表达清楚"。
5.2 nodeSelector、亲和性与反亲和性的强度差异
nodeSelector是最简单的节点选择方式——通过节点的标签精确匹配。它的能力很弱：只能表达"等于"关系，不能表达"在枚举范围内""不等于"这类更复杂的逻辑。
nodeAffinity（节点亲和性）和podAffinity（Pod亲和性）引入了更丰富的匹配表达式，比如In、NotIn、Exists、DoesNotExist，并且可以设置软性约束（preferredDuringSchedulingIgnoredDuringExecution）和硬性约束（requiredDuringSchedulingIgnoredDuringExecution）。软性约束的含义是"尽量满足，不满足也不拦着"，调度器会把它作为打分项，而不是过滤项。
podAntiAffinity（Pod反亲和性）在分布式系统的部署中尤其重要，比如将同一个应用的多个副本分散到不同节点上，避免单节点故障导致整个应用不可用。但要注意的是，使用podAntiAffinity时，Pod会访问API Server查询其他Pod的位置，如果集群规模很大，会产生额外的API Server压力。所以大规模场景要测试用topologyKey做分组，比如topologyKey: kubernetes.io/hostname表示按主机维度做反亲和。追问高级一点的用法：topologyKey除了hostname，还能用topology.kubernetes.io/zone实现跨可用区级别的亲和或反亲和，这个点在多区域集群的面试题里出现过很多次。
5.3 taint和toleration的工作机制
taint和toleration两个词在面试中总是成对出现：节点上打了污点（taint），Pod只有容忍（toleration）这个污点才被允许调度上去。
有三个内置污点需要重点掌握，因为它们和节点故障直接相关：
| 污点 | 含义 | 是否自动添加 |
|---|---|---|
| node.kubernetes.io/not-ready | 节点未就绪 | 是 |
| node.kubernetes.io/unreachable | 节点不可达 | 是 |
| node.kubernetes.io/disk-pressure | 节点磁盘压力过大 | 是 |
默认情况下，节点进入NotReady状态后，会添加NoExecute类型的污点，之后已经在上面运行的Pod会按容忍时限（tolerationSeconds）被驱离。如果容忍时限设置为0，Pod立刻被调度到其他节点；如果不设置tolerationSeconds而是直接容忍该污点，Pod会一直留在节点上，直到节点恢复或Pod被手动删除。这个默认行为的完整链路，加上"调度器如何根据污点驱逐Pod"的分析，能把调度、控制器、kubelet三个组件串联起来，面试中系统讲出来很显水平。
6. 存储、配置与安全：容易被追问的细节
这一部分的知识点，坦白讲是很多Kubernetes开发者的薄弱区。大家都觉得"我没有为存储和权限折腾过"，但面试官恰恰喜欢从这些地方提问，因为能看出你是否在真实环境里部署过带状态的业务。
6.1 PV、PVC与StorageClass的三角关系
PersistentVolume（PV）是集群级别的存储资源，PersistentVolumeClaim（PVC）是用户对存储资源的请求，StorageClass则是动态供给的模板。
面试中常问的问题是"PV和PVC怎么关联"。答案有两层：静态供给时，管理员预先创建PV，PVC根据所需的容量和访问模式（ReadWriteOnce、ReadOnlyMany、ReadWriteMany）去匹配满足条件的PV；动态供给时，PVC指定StorageClass，由Provisioner组件根据StorageClass的配置自动创建PV。
StorageClass里值得展开的一个点是reclaimPolicy（回收策略），它决定PV释放后是保留（Retain）、删除（Delete）还是回收（Recycle，已废弃）。生产环境中，数据库类应用推荐Retain，否则误删PVC会导致整个PV连带底层存储被删掉，数据直接清零。这个教训是真的疼过——我有一次测试环境误删了PVC，StorageClass的reclaimPolicy是Delete，背后的云盘直接被释放了，一周的测试数据全部消失。从那以后，所有带数据的环境，我配置StorageClass时第一件事就是去看回收策略。
还有一个经常被忽视但面试容易问的知识点：PVC扩容。如果底层存储支持动态扩容（比如AWS EBS、Ceph RBD），你可以在PVC的spec.resources.requests.storage里增大容量，但前提是StorageClass里设置了allowVolumeExpansion: true。并且，扩容不等于自动生效，需要保证PVC的storageClass字段里的provisioner支持在线扩容。这个知识点和"有状态应用的存储扩展方案"是连着考的。
6.2 ConfigMap与Secret挂载的"更新不更新"问题
Kubernetes的ConfigMap和Secret都可以通过环境变量或文件卷的方式注入到Pod中。面试中的高频问题是"改了ConfigMap之后，Pod里的配置会自动更新吗"。
答案要分开说：如果是通过环境变量注入的，不会更新，Pod必须重启才会拿到新的环境变量值；如果是通过volume挂载的，Kubernetes会定期同步（同步周期通常是kubelet的syncPeriod，默认大约1分钟），但容器里的进程要不要重新加载配置，取决于这个进程是否监听了文件变化事件。Nginx这种支持reload的还行，Java应用通常需要重启进程才能感知到配置变化。
Secret在传递过程中的安全机制值得多说一句。Secret默认只是Base64编码存储，并不是加密的。如果你开启了etcd的静态加密（EncryptionAtRest），Secret在持久化到etcd时才会真正加密。RBAC权限管控是Secret安全的第一道防线nd所以面试中聊到Secret时，最好主动提一句"Secret的安全性依赖RBAC和etcd加密配置，不能仅仅依赖Base64编码"，这个细节能体现出你对安全的理解层级。
6.3 RBAC、ServiceAccount与PodSecurityContext
RBAC（基于角色的访问控制）是Kubernetes安全体系的核心，它的三个核心对象是Role、ClusterRole和RoleBinding。Role是命名空间级别的权限集合，ClusterRole是集群级别的权限集合，RoleBinding把某个Role或ClusterRole授予某个用户或ServiceAccount。
面试中我遇到过很多候选人分不清"用户"和"ServiceAccount"这两个概念。其实很简单：用户是给人用的身份，ServiceAccount是给Pod里的进程用的身份。Pod运行时，会携带一个ServiceAccount的令牌（token），用于访问API Server。所以当你看Pod日志发现"forbidden: User system:serviceaccount:default:default cannot list resource pods"，意思就是当前Pod使用的ServiceAccount没有列出Pod的权限，你去给对应的ServiceAccount绑定Role就好。
PodSecurityContext是Pod级别的安全上下文，它定义Pod内进程以什么用户运行（runAsUser）、是否只读根文件系统（readOnlyRootFilesystem）、是否具备特权（privileged）等。生产环境的安全基线是：禁止特权容器、禁止以root运行、只读根文件系统。如果面试官追问"在Kubernetes上实现纵深防御怎么做"，你可以从PodSecurityContext、RBAC、NetworkPolicy、Secret加密存储等多层来组织答案，大部分候选人只会提到其中一两层，你能讲出三到四层就非常出彩了。
7. 故障排查的正确姿势与面试加分项
我记得自己转过好多Kubernetes的坑，真正让我建立起"K8s排障思维"的是几个经典的Case，这里我完整还原一次排障链路，大家可以看看面试的时候，怎么讲才能让面试官觉得"这人有实战经验"。
7.1 一次Pod Pending的完整排查链路
背景：有同事反馈某个服务发版后一直没有流量，查看Pod列表发现状态一直是Pending。
第一步，kubectl get pod确认状态，然后kubectl describe pod xxx查看Events。
Events里的关键信息是：
code复制Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 3m30s default-scheduler 0/5 nodes are available:
3 node(s) didn't match node selector, 2 Insufficient cpu.
这一步直接锁定了两个问题：
- 有3个节点因为nodeSelector不匹配被过滤掉了；
- 剩下2个节点CPU资源不足。
第二步，检查我用的nodeSelector是什么。查看Deployment的YAML，发现我填了nodeSelector: gpu: "true"，但集群里打这个标签的节点都已经被其他Pod占满了。而另外两个普通节点没有这个标签，所以被过滤了。
第三步，确认资源情况。kubectl describe node <node-name>查看Allocatable的CPU，发现CPU requests已经接近上限。再看一下已经运行的其他Pod占用了多少配额。
第四步，解决。要么去释放那两个匹配节点上的资源，要么调整Deployment的requests到一个合理值，要么去掉不必要的nodeSelector。因为业务不需要GPU，最终我选择去掉后缀的"gpu:true"标签匹配，并调低了requests，Pod很快调度成功。
这个案例的面试价值在于它展示了一个完整的"描述问题→定位根因→验证假设→解决"的链路，而不是一上来就删Pod重启。面试官最怕听到的答案是"当时卡了，我重启了一下Pod就好了"——这句话里没有任何信息量，也无法证明你有排障能力。
7.2 kubectl查看与调试的关键指令组合
排障效率高的人，通常不是记住了一堆命令，而是有一套固定的排查顺序：
kubectl get events --sort-by=.lastTimestamp——先看集群级事件，很多问题在事件里有直接线索。kubectl describe pod <name>——看Pod级别的详细信息和Events。kubectl logs <pod> -c <container>——看应用日志，如果Pod有多个容器，记得指定-c参数。kubectl get endpoints <service>——如果涉及"Pod正常但Service不通"的问题，这一步直接检查后端有没有可用的Endpoints。kubectl exec -it <pod> -- /bin/sh——进入容器做网络连通性测试（curl、ping、telnet）。
我自己还习惯在排查时加一个关键参数：kubectl get pod -o wide。它会列出Pod被调度到了哪个节点以及Pod的IP，这是很多网络排查的起点。比如怀疑跨节点访问不通时，先确认Pod在哪个节点上，再去测源节点到目标节点的连通性。
7.3 etcd备份、PodDisruptionBudget与HPA的运维必答题
etcd是Kubernetes控制面的状态存储，可以说是集群里最重要的组件。面试中关于etcd的必考题是"你的备份策略是什么"。一个成熟的方案是：每天全量快照加定时增量备份。etcd提供etcdctl snapshot save命令做快照，建议同时把快照传到对象存储。注意，etcd的备份必须和Kubernetes证书体系一起考虑，如果你只备份了etcd数据而没有备份证书，即使恢复出来也无法和API Server正常通信。
PodDisruptionBudget（PDB）很多同学面试前不知道，但它其实是优雅运维的核心工具。PDB定义了"在一次自愿中断（比如节点维护、集群升级）时，某个应用允许最多有多少个Pod不可用"。比如设置minAvailable: 2，那么节点驱逐Pod时必须保证至少2个Pod可用。这里要强调的是，PDB只对自愿中断（voluntary disruptions）生效，对节点宕机、Pod崩溃这类非自愿中断无效。如果你能说出这个边界，会觉得你对PDB的语义理解得很准。
HorizontalPodAutoscaler（HPA）是弹性伸缩的必考知识点。它的核心公式是：
code复制desiredReplicas = ceil(currentReplicas * (currentMetricValue / desiredMetricValue))
以CPU为例：如果当前副本数是4，当前CPU使用率是80%，目标是50%，那么：
code复制desiredReplicas = ceil(4 * (80% / 50%)) = ceil(4 * 1.6) = 7（向上取整）
这里有两个重要参数要理解：minReplicas和maxReplicas决定了副本数的边界；behavior块里的scaleDown.stabilizationWindowSeconds可以控制缩容的冷却时间，防止指标抖动导致频繁缩容。这个参数在生产环境里非常有用，默认300秒可能让你觉得缩容太慢，但如果你调成0，高峰期一过副本数直接掉下去，下一波流量来了又要扩容，反而容易引发雪崩。这个话题往深了说就是"弹性扩缩容的稳定性设计"，面试时能聊到这一步，说明你确实处理过真实的突发流量。
8. 围绕部署经验的高频追问
"Kubernetes部署"是搜索热度很高的词，面试中关于部署的问题也几乎场场必问。这部分我把部署相关的高频追问整理出来，每个追问背后都藏着一个"你是在生产环境待过，还是只在本地Minikube玩过"的判断标准。
8.1 kubeadm部署的核心流程与易错点
用kubeadm部署一个集群，核心步骤是：
- 所有节点安装容器运行时（containerd是最主流的选择）、kubeadm、kubelet、kubectl。
- 控制平面节点执行
kubeadm init，指定API Server地址、Pod网络CIDR、Service网络CIDR。 - 按提示配置kubeconfig（
mkdir -p $HOME/.kube && cp /etc/kubernetes/admin.conf $HOME/.kube/config）。 - 安装CNI插件（Calico是默认推荐之一）。
- 工作节点执行
kubeadm join，带上控制平面给的token和证书指纹。
这里面的易错点很有讲究。最容易翻车的环节是"容器运行时不匹配"——系统里装了Docker，但kubelet配置里指定的endpoint是containerd的socket，结果kubelet一直连不上运行时，节点状态永远是NotReady。还有镜像拉取问题：kubeadm init指定的kube-apiserver、kube-controller-manager等镜像地址在某些网络环境下拉不到，需要在kubeadm配置里先换好镜像源再init。
8.2 部署完成后必做的基础设施验证
集群部署完不是"节点都Ready"就完事了，面试中如果被问"你怎么验证一个新建集群是健康的"，我建议按下面这个清单来：
kubectl get nodes——所有节点状态都是Ready。kubectl get pods -n kube-system——核心组件全部Running且ready状态为1/1。- 部署一个测试用的Nginx Deployment，暴露为NodePort或LoadBalancer服务，验证集群内和集群外访问路径都通。
kubectl exec进入Pod，测试DNS解析是否正常（nslookup kubernetes.default.svc.cluster.local）。- 检查CoreDNS的Pod是否有解析失败的日志，检查kube-proxy是否在每个节点上都正常运行。
这套验证做完，才敢说集群是可用的。只看到kubectl get nodes全是Ready就放心下班的人，大概率会在上线那天晚上被电话叫醒。
8.3 CNI选型与单节点、高可用架构的取舍
CNI插件的选型也是高频面试题。目前主流选择是Calico和Cilium。Calico以BGP为基础实现纯三层网络方案，不依赖Overlay封装（但也可以启用VXLAN模式），性能和排障都相对友好。Cilium基于eBPF，在可观测性和安全策略能力上更强，但对内核版本有要求（一般建议5.4+）。Flannel部署最简单、最不容易出错，但功能和性能都偏弱，生产环境我一般不会直接上Flannel。
集群架构问题上，面试官喜欢问"单节点集群和HA集群的差别，以及你会怎么选"。单节点集群（kubeadm部署时控制平面和工作节点都在一台机器上）适合学习、开发和边缘计算场景，成本低且足够用。生产环境，尤其是核心业务，必须用HA架构：至少3个控制平面节点，前面配负载均衡器（keepalived+HAProxy或者云厂商的LB）把API Server请求分发到多个控制节点，工作节点数量按业务规模规划。3个控制平面的核心意义在于etcd的quorum机制——多数节点存活才能选出Leader，3节点允许1个故障不丢可用性，5节点允许2个故障。
8.4 部署后运维必须关心的三个"看不见"的组件
最后补充三个部署后很多人会忽略、但生产环境出问题基本都出在它们身上的组件：
第一个是kube-proxy。它负责Service规则的写入。如果你发现Service创建后流量不通，先看Pod的Endpoints是否存在，再看kube-proxy日志有没有报错，检查iptables规则或IPVS规则有没有生成。
第二个是CoreDNS。它负责集群内DNS解析。核心问题是"CoreDNS Pod的副本数是否足够"和"CoreDNS的缓存配置是否合理"。高并发下CoreDNS的副本数不够，会导致Pod解析超时，间接引发大量服务互访失败，这种问题查起来非常费劲。
第三个是metrics-server。它是HPA依赖的数据来源，没有它，HPA的CPU指标就为空，无法做弹性伸缩。很多人在测试环境配好了HPA但一直不生效，排查了半天最后发现metrics-server没有安装，这是一个低级的坑，但很容易犯。
最后再分享一个我自己的习惯：每次面试前，我都会把kubectl get pod之后可能出现的每一个状态（Pending、CrashLoopBackOff、ImagePullBackOff、Terminating、Evicted）都过一遍，讲清楚每一种状态背后最可能的原因和排查路径。这套东西熟练了之后，不只是面试，日常值班排障效率也会明显提升。如果你想在面试中把Kubernetes变成一个加分项而非减分项，关键是别背题，而是把每一个知识点的"为什么"和"踩过什么坑"都接住，这才是Kubernetes面试真正的分水岭。