Kubernetes面试高频题详解：从滚动更新到网络存储与安全排错

Kubernetes面试题分类汇总这个系列写到第004篇了。20260309这一批，我把近期收集到的面试反馈重新筛了一遍，题目集中在几个面试官特别爱深挖的模块：控制器的滚动更新细节、网络转发链路、存储动态供给、安全与准入控制，还有一大票排错类题目。前几篇已经覆盖了基础概念、Pod生命周期和调度器原理，这一篇专门补齐容易暴露细节盲区的部分，同时也收录了几道看似简单但实际答不对的经典题。

Kubernetes相关的岗位面试，考察方式已经从“背概念”转向“现场推演”了。面试官很少直接问“Deployment是什么”，而是问“Deployment滚动更新时，如果新Pod一直不Ready会怎样”，“StatefulSet删除后重新创建，Pod数量和标识怎么变化”，“Service的ClusterIP到底在哪里生效”。这些问题教材上都能找到答案，但能答得完整、答到点子上的人不多。我整理这篇的时候，刻意把“追问方向”也写了出来，方便你模拟面试官往下追问的节奏。

这篇收录第25到第44题，按专题拆成六个大节。每题我都按“常见问法、考察点、参考回答、追问方向、避坑提示”的结构组织。文章涉及的命令和资源清单都可以直接复制去实验环境验证。

1. 架构与核心组件专题

1.1 第25题：kube-apiserver在一条Pod创建请求中做了哪些事

常见问法： “用户执行kubectl apply之后，从请求到Pod创建完成，kube-apiserver分别参与了哪些环节？”

考察点： 这个问题考察的不只是apiserver的功能列表，而是能不能把认证、鉴权、准入、API对象持久化和watch通知这一整条链路串起来。

参考回答： 请求进入kube-apiserver后大致经过六个阶段。第一，TLS终止和解码，apiserver以HTTPS提供服务，客户端证书在这里被校验。第二，认证阶段，通过x509证书、token或basic auth识别调用者身份。第三，鉴权阶段，RBAC的规则在这里生效，apiserver根据请求的动词和资源属性找到对应的策略，没有权限直接返回403。第四，准入控制阶段，这一层是webhook类插件和内置准入插件的混合体，NamespaceLifecycle、ResourceQuota、PodSecurity等都在这里起作用。第五，对象校验和默认值填充，apiserver调用scheme里的校验逻辑，对缺失字段填充默认值。第六，序列化并写入etcd，写入成功后apiserver会通过watch机制向所有关心该资源的listener推送一条ADDED事件，kubelet和controller-manager都是通过这些watch事件感知变化并开始行动的。

追问方向： 如果两个用户同时提交两个相同名称的Pod会怎样？答案在于etcd底层事务。apiserver写入时带上了资源版本的比较条件，后写入的那一个会因为版本冲突而失败，用户会收到AlreadyExists或Conflict错误。

避坑提示： 别把kube-scheduler说成在apiserver内部做调度。调度器是独立组件，它和apiserver之间只有API调用关系，没有进程级别的耦合。

1.2 第26题：etcd的raft协议和集群容灾策略

常见问法： “etcd集群最少需要几台？为什么是奇数？数据是怎么保证一致的？”

考察点： 对分布式共识的理解，区分“多数派可用”和“半数以上存活”，以及数据备份与恢复的基本操作。

参考回答： etcd使用raft协议实现共识。一个raft集群中每个节点都有角色，Leader接收写请求并把日志条目复制给Follower，超过半数节点持久化成功后这条日志才被认为是已提交的。因此集群允许故障的节点数是n-1除以2向下取整，3节点集群允许坏1台，5节点允许坏2台。使用奇数节点的原因是偶数节点在容错能力上没有额外收益，4节点和3节点的容错上限都是1台，但4节点的脑裂风险面更大、内部通信开销更高。etcd的数据持久化依赖WAL日志和快照，定期执行snapshot可以控制WAL文件大小，恢复时先恢复最新快照再重放快照之后的日志条目。

追问方向： 如果一台节点的数据明显落后于Leader怎么办？答案是新加入节点会先通过快照追赶，如果落后太多则自动丢弃旧数据从快照开始同步，不需要手工干预。面试时能说出“snapshot + WAL重放”这两个词就够了。

避坑提示： 不要提出“从备份恢复etcd需要重启整个Master节点”这样的回答。恢复单个etcd节点后，它会自动向Leader追赶数据，只有全部节点数据损坏时才需要从备份整体恢复。

1.3 第27题：kubelet的PLEG机制

常见问法： “有没有遇到过Pod状态和容器真实状态不一致的情况？kubelet是怎么感知容器变化的？”

考察点： 这道题用来拉开候选人差距。知道PLEG能看出来是对运行时机制有过真实研究的人。

参考回答： kubelet依赖PLEG，即Pod Lifecycle Event Generator，来感知Pod内容器的状态变化。PLEG定期调用容器运行时接口获取当前所有容器的状态列表，与本地缓存的状态做对比，发现有差异后生成事件并放入事件队列。真正的状态同步循环消费这些事件，逐一刷新PodStatus。这么做是为了避免每次Pod状态变更都去做全量同步，减少kubelet对运行时的频繁调用。常见的故障场景是运行时响应慢导致PLEG检测周期拉长，表现为Pod一直显示Running但实际容器已经退出，或者Pod删除后状态迟迟不变。排查时看kubelet日志里的plegReload和Pod worker耗时指标。

追问方向： 即使PLEG正常，kubelet和运行时之间的连接断开也会导致状态不一致。可以补充说明通过healthz、定期调用Version接口探活，以及节点上报NotReady的机制。

避坑提示： 不要单纯回答说“kubelet定期轮询容器状态”，这只说对了一半，关键是要说出“事件驱动”和“缓存对比”这两个设计意图。

2. 调度与Pod生命周期专题

2.1 第28题：Pod从创建到Ready的完整流程

常见问法： “一个Pod被调度到节点上之后，节点上会发生什么？”

考察点： 调度器做了哪些决策，kubelet如何启动容器，以及就绪探针在什么时候开始运行。

参考回答： Pod被调度后，kubelet通过watch机制感知到该Pod已经绑定到本节点。随后kubelet启动Pod sandbox，也就是pause容器，pause容器负责持有Pod的网络命名空间和部分资源，业务容器加入这个沙箱才能共享网络。沙箱创建完成后按顺序启动init容器，init容器全部成功后启动主容器列表。所有容器成功启动后，kubelet开始执行readinessProbe探测，探测通过后将Pod的Ready条件置为True，并更新Pod状态。kube-proxy观察到Pod IP和Ready状态后，才会将该Pod IP写入对应的Service后端列表。这就是为什么对外请求不会路由到未就绪Pod的根本原因。

追问方向： 如果readinessProbe一直失败，Pod会被怎样？保持Running但Ready为False，Endpoints列表里不会出现这个Pod的IP，Deployment也不会把它算进available副本。注意不是重启容器，只有livenessProbe失败才触发重启。

避坑提示： 很多人把阶段描述成“容器启动后马上加入Endpoints”，这是错的。必须强调就绪门控，即EndpointSlice Controller只读取Ready为True的Pod。

2.2 第29题：livenessProbe、readinessProbe、startupProbe的区别

常见问法： “三种探针分别解决什么问题？什么时候用startupProbe？”

考察点： 对Pod可用性的三层理解，包括进程是否存活、流量是否可以进入、服务启动是否完成。

参考回答： livenessProbe判断容器是否还活着，失败会触发restartPolicy对应的操作，一般是重启容器，常用于排出内存泄漏、死锁等进程还在但已经不可用的场景。readinessProbe判断容器是否准备好接收请求，失败时将Pod标记为未就绪，从Service的后端列表中摘除，但不会重启容器。startupProbe是给启动过程特别慢的应用用的，它在其他探针之前运行，只有启动探针成功后，liveness和readiness才开始生效。对待老旧的Java应用，启动可能要一两分钟，如果直接配livenessProbe且failureThreshold设置太小，容器可能在启动完成前就被杀掉。用startupProbe把这段保护时间隔离开，避免这类误杀。

追问方向： 三种探针都支持httpGet、exec、tcpSocket。如果三种探针同时配置，执行顺序是什么？startup成功后才能执行其余探针，这个顺序要讲清楚。

避坑提示： 不要把readiness失败解释成自动重启。这是一个高频扣分点，回答前先想想restartPolicy是否真的会被触发。

2.3 第30题：调度器如何保证高优先级Pod能插队

常见问法： “PriorityClass怎么用？一个新提交的高优先级Pod能抢占已经在运行的Pod吗？”

考察点： 调度队列的优先级处理和抢占调度逻辑。

参考回答： Kubernetes调度器为每个Pod维护一个优先级，数值越高越先被调度。调度队列内部按优先级排序，高优先级Pod会排到低优先级Pod前面。如果集群资源不足，调度器会尝试抢占，即驱逐节点上那些优先级更低的Pod，腾出空间来放置高优先级Pod。被驱逐的Pod进入终止流程，但并不保证会被杀死，Pod的优雅退出时间超时后才会强制终止。调度器会优先选择牺牲Pod数量最少、对运行影响最小的节点作为抢占目标。PodDisruptionBudget可以保护有状态服务，降低自愿驱逐的概率，但注意它对抢占这种非自愿驱逐的作用有限，只能通过PSD与PDB的交互机制部分生效。

追问方向： 高优先级Pod抢占后，被抢占的低优先级Pod会被重新调度到哪里？它进入重新调度流程，但有可能仍然失败。面试时能说出“调度器会等待PreemptionResult，然后重新入队”就够了。

避坑提示： 不要让面试官觉得抢占是“把Pod从一台机器搬到另一台机器”，抢占的本质是先终止再重新调度，中间会有一段时间服务不可用。

2.4 第31题：污点和容忍度的实际使用场景

常见问法： “nodeSelector和节点亲和性都能把Pod调度到指定节点，为什么还需要污点？”

考察点： 两类调度约束的本质区别：软性偏好和硬性排斥。

参考回答： nodeSelector和亲和性表达的是“Pod想待在哪些节点上”，是Pod对节点的选择；污点正好反过来，是节点对Pod的拒绝。设置污点的节点默认不会接受任何不带对应容忍度的Pod。两者的结合模型可以理解成双向约束，节点说我不欢迎某些Pod，Pod说我可以接受这个污点，两边的条件都满足才能调度上去。实际使用中最常见的场景是给专用节点打污点，比如GPU节点打上gpu=true:NoSchedule，需要GPU的Pod加上对应容忍度才能调度上去。NoExecute类型的污点作用不只是阻止调度，还能把已经在节点上运行但不容忍的Pod驱逐出去。

追问方向： 三档污点效果NoSchedule、PreferNoSchedule、NoExecute分别代表什么。NoSchedule是硬性不调度，PreferNoSchedule是软性尽量不调度，NoExecute是既阻止新调度又驱逐存量Pod。

避坑提示： 面试时说到“节点维护时打污点”要说明路径：先给节点打NoExecute污点并配置tolerationSeconds为0，让存量Pod尽快被调度到别处，或者配合cordon使用，cordon只影响新调度，不影响存量Pod。

3. 控制器与工作负载专题

3.1 第32题：Deployment滚动更新的完整链路

常见问法： “Deployment更新镜像时，新旧Pod是怎么交替的？maxSurge和maxUnavailable怎么算？”

考察点： ReplicaSet的版本化管理和滚动策略的计算，不只是背定义，要求现场推导。

参考回答： Deployment通过这个模板创建新的ReplicaSet，每次模板变化都会生成新的RS，旧RS保留用于回滚。滚动更新时maxSurge允许超出期望副本数的最大个数，maxUnavailable允许不可用副本的最大个数。假设副本数是10，默认maxUnavailable是25%，maxSurge是25%，计算结果四舍五入后表示更新过程中最多允许2个Pod不可用，同时最多可以有3个Pod超出期望副本数，因此实际副本数会在10到13之间浮动。控制器先扩容新RS、再缩容旧RS，直到新RS达到期望副本数且旧RS缩到0。如果新Pod迟迟不就绪，滚动会卡住而不是继续推进，这可以看作是“安全的楔子”机制。

追问方向： 如果要实现先停旧再起新或先起新再停旧的严格顺序，怎么配置？把maxUnavailable设置成1、maxSurge设置成0，结果是逐个停止旧Pod并逐个创建新Pod；反方向则是先逐个创建新Pod再停止旧Pod。默认策略是两者并行。

避坑提示： 面试官追问“available副本数”时不要答成“Running的Pod数”，available要求Ready为True并满足minReadySeconds的稳定时间。

3.2 第33题：StatefulSet的启停顺序和网络标识

常见问法： “StatefulSet和Deployment管理有状态服务的核心差异是什么？”

考察点： 有状态服务的三大要素：稳定的网络标识、稳定的存储、有序的启停。

参考回答： StatefulSet为每个Pod生成一个从0开始递增的序号，Pod名形如application-0、application-1。这个序号同时还决定了稳定的DNS域名，即使Pod重建后IP变了，域名不变，这能解决有状态服务节点间互相发现的问题。存储层面，StatefulSet可以配合volumeClaimTemplates，每个Pod自动生成独立的PVC，保证数据与Pod序号绑定，Pod换了节点数据也能找回来。启停顺序方面，StatefulSet缩容或删除时按倒序，从最大的序号开始终止，每个Pod必须完全终止后才轮到下一个；扩容则正序逐一生启，前一个Pod完全Running并Ready后才创建下一个。

追问方向： 如果想打破启停顺序的限制，可以使用Parallel模式。另外要说明普通Deployment是不保证Pod标识稳定的，Pod重建后名称和IP都会变化，不适合需要节点间稳定联系的场景。

避坑提示： StatefulSet删除后PVC和PV默认保留，这是有意的。如果期望连数据一起清理，需要人工删除PVC，这种默认设计是用来防误删的。

3.3 第34题：工作负载控制器的选择

常见问法： “ Deployment、StatefulSet、DaemonSet、Job分别在什么场景下使用？”

考察点： 控制器模型的适配能力，能否根据实际场景选择正确的控制器。

参考回答： 我一般把这类题答成一张表：

更重要的是说明为什么。比如日志采集如果做成Deployment，新节点加入时Pod不会被自动调度过去，需要人肉扩容，DaemonSet通过nodeSelector和节点生命周期联动解决了这个问题。数据库如果用Deployment管理，节点重建后Pod漂移、数据丢失，StatefulSet通过在Pod和PVC之间建立一对一映射来保证存储稳定性。

追问方向： 当节点数量从3扩到10时，DaemonSet会怎样？自动在新增节点上创建Pod，不需要任何额外操作。这是DaemonSet的核心价值。

避坑提示： 不要答“Job就是跑一次的命令”。要考虑批量任务失败后的重试策略，可以补充说明backoffLimit和restartPolicy的取值关系。

3.4 第35题：级联删除与孤儿删除

常见问法： “删除一个Deployment时，它的Pod和RS会被一起删掉吗？改成kubectl delete --cascade=orphan会怎样？”

考察点： Kubernetes垃圾回收器的工作机制，Foreground、Background和Orphan三种删除策略。

参考回答： 默认情况下删除Deployment是级联删除，垃圾回收器会先删除其拥有的RS，RS删除后进一步触发其Pod的删除。删除顺序分为Foreground和Background两种模式。Foreground模式在删除Deployment后立即留下一个deletionTimestamp，表面上资源还在但处于终止中，后台的垃圾回收器先把依赖对象全部删除，最后再真正移除Deployment。Background模式则反过来，先删除Deployment，让依赖对象成为孤儿后由垃圾回收器清扫。如果不希望删除Deployment时牵连RS和Pod，可以使用Orphan策略，旧集群升级时经常用这种方式保留工作负载，但管理上会留下很多孤儿资源。

追问方向： ownerReference是级联删除的核心机制，RS的ownerReference指向Deployment，Pod的ownerReference指向RS，GC就是依据这条owner链逐级处理的。

避坑提示： 明确一个细节：级联删除不是kubectl去调用每个资源的Delete API，而是由Controller Manager内的GC控制器异步完成的，所以删除命令返回后，Pod可能还在Running状态。

4. 网络与服务发现专题

4.1 第36题：ClusterIP和kube-proxy的转发设计

常见问法： “Service的ClusterIP是虚拟IP吗？请求到这个IP之后是怎么转到Pod的？”

考察点： 对ClusterIP本质的理解，以及kube-proxy三种模式的工作原理。

参考回答： ClusterIP不归属于任何物理网络接口，它配合iptables或IPVS规则生效。kube-proxy监听Service和Endpoints变化，然后把规则写入主机的网络栈。请求到达节点后，内核里的规则会做DNAT，把目标地址从ClusterIP改写为一个具体的Pod IP，同时记录连接跟踪状态，使得回包时能够再反向翻译，保证客户端看到的始终是ClusterIP。iptables模式下这条规则链是一个个匹配条目，规则数量多时性能下降。IPVS模式把规则维护在内核的哈希表里，大规模Service场景下表现更好，还支持更多的负载均衡算法，因此生产环境大多使用IPVS模式。

追问方向： 如果Service后端Pod为空，ClusterIP的规则会匹配什么结果？这个和具体实现有关系，多数情况下请求会被丢弃或者重置，表现是不通。面试时能说出“空后端没有有效target，规则不生效”即可。

避坑提示： 不要把kube-proxy说成是Sidecar代理，它是节点上的进程。应用容器发送请求时不会经过kube-proxy，流量在节点内核层就被改写和转发。

4.2 第37题：Service发现与DNS解析细节

常见问法： “集群内Pod访问Service时，DNS解析返回几个IP？Headless Service有什么不同？”

考察点： CoreDNS的服务发现能力，以及Headless Service在无ClusterIP场景下如何工作。

参考回答： 普通Service会分配ClusterIP，DNS解析结果就是那个虚拟IP。Pod内通过service名.namespace.svc.cluster.local访问，CoreDNS负责返回对应的地址。Headless Service不分配ClusterIP，DNS解析会返回所有就绪Pod的IP列表，客户端可以自行负载均衡，这种模式常常配合StatefulSet使用，每个Pod还能通过稳定的域名直接访问。通过headless service暴露的Pod域名格式是podName.serviceName.namespace.svc.cluster.local。这解决了有状态服务集群内部的节点发现，比如每个数据库节点都通过域名定位彼此的地址。

追问方向： 为什么要区分集群外和集群内DNS配置？集群外的服务发现通常交给人肉维护或更上层的服务注册中心，集群内的服务发现全部由CoreDNS承载，两者边界要分开。

避坑提示： 很多人不知道Pod默认的dnsPolicy是ClusterFirst，只当CoreDNS异常时才会退到宿主机DNS。集群内某个应用解析不到其他服务时，第一步检查它的dnsPolicy，第二步查CoreDNS日志。

4.3 第38题：Ingress与Service的分工

常见问法： “有了Service为什么还需要Ingress？”

考察点： 七层路由和四层转发的区别，Ingress Controller的独立身份。

参考回答： Service解决的是从集群内或集群边缘到Pod的转发，它工作在L4层。Ingress承担的是七层路由，可以依据域名、URL路径把流量分发给不同的Service，还能在入口处统一做TLS终结、限流、跨域配置。Ingress要匹配一个名为IngressClass的对象，再由对应的Ingress Controller执行实际转发逻辑，常见的Controller有基于Nginx的实现、基于HAProxy的实现等不同的开源实现。重要的面试点是Ingress资源本身不承担流量，它只是一份声明，真正干活的是Controller。

追问方向： 一个请求经过Ingress Controller后转发到Service，Controller会根据Ingress规则找到后端Service，再通过Service的ClusterIP转发到Pod。这里重点是明确Ingress Controller部署在集群内部，如果它只被放在集群外部，反而会引入额外的网络链路。

避坑提示： 不要答出“Ingress是七层负载均衡，所以不需要Service”。Ingress规则里的每个backend仍然指向Service，链路并没有省略。

4.4 第39题：NetworkPolicy的隔离模型

常见问法： “Kubernetes默认允许所有Pod互访吗？怎么开启隔离？”

考察点： 网络插件对NetworkPolicy的支持，以及隔离规则的匹配逻辑。

参考回答： Kubernetes网络的默认行为是扁平互通，任何Pod不需要额外授权就能访问另一个Pod，除非底层网络策略禁止。NetworkPolicy就是在这种默认开放的模型上叠加白名单规则的机制。一个命名空间下只要创建了NetworkPolicy，匹配到的Pod就默认拒绝所有未显式放行的流量。规则体包括podSelector选择目标Pod，ingress和egress定义来源和目的。做一个只允许frontend访问backend数据库Pod的策略，就是选择backend的label，在ingress规则中允许携带frontend标签的Pod来源访问。要注意NetworkPolicy只是API层面的声明，必须有支持它的CNI插件才会真正生效，常见支持NetworkPolicy的CNI实现有好几种开源方案，也有部分插件不支持，需要在选型时确认。

追问方向： 如果命名空间里存在两个NetworkPolicy同时匹配同一个Pod，怎样处理？默认一组策略取并集，大部分CNI实现按并集规则执行。这个点可以作为加分项回答。

避坑提示： NetworkPolicy只拦截通过CNI数据面的流量，如果某流量走的是hostNetwork且绕过了网桥，网络策略不一定拦得住，面试时提一嘴“hostNetwork流量绕过策略”是加分项，但也容易引发追问，回答要谨慎。

5. 存储与持久化专题

5.1 第40题：PV、PVC、StorageClass三者的职责

常见问法： “用户要一块存储，系统怎么把请求和具体存储资源对应上？”

考察点： 存储抽象的能力分层：声明、绑定、供给。

参考回答： PVC是用例的存储声明，相当于告诉集群“我要一块10GB的读写存储”。PV是集群管理员预先准备的具体存储资源，相当于已经被创建好的一块存储空间，可能是云盘、本地磁盘或NAS目录。StorageClass负责把两者动态连接起来，PVC里指定storageClassName，Provisioner插件看到后自动从基础设施层创建对应PV，然后完成绑定。没有StorageClass的集群管理员只能手动预置PV，然后让PVC去匹配。PVC绑定PV的匹配条件是访问模式和容量参数，如果找不到合适PV，PVC会一直处于Pending状态。

追问方向： 删除PVC前需要先删除Pod吗？如果某个StatefulSet正在使用某PVC，直接删PVC时，由于PVC处于Bound状态且有Pod在使用，控制器会尝试保持绑定，实际操作中应该先删除使用该PVC的工作负载，再删PVC，否则外接存储可能残留孤儿数据。

避坑提示： 要能区分两种访问模式，ReadWriteOnce是单节点读写，ReadOnlyMany是多个节点同时只读，ReadWriteMany是多节点同时读写。云盘类存储往往只支持前两者，考虑业务需要跨节点共享时不能盲目选择ReadWriteMany。

5.2 第41题：PV的回收策略与动态供给

常见问法： “PV用完之后，数据怎么处理？Retain和Delete有什么区别？”

考察点： ReclaimPolicy的生命周期管理，以及动态供给下回收策略绑定关系。

参考回答： PV的回收策略决定PVC删除后的行为。Retain表示保留数据，PV进入Released状态，管理员需要手动决定是清理还是复用，数据不会自动删除，这是重要的数据安全兜底。Delete表示PVC删除时自动删除底层存储卷和相关资源，动态供给的PV通常默认Delete，且由StorageClass决定默认回收策略。Recycle已经在当前标准里不推荐使用，只在少数老版本里存在，正确选择应该用Retain加手动清理流程。如果选择Delete，底层云盘会同步删除，误删PVC会导致数据不可找回，因此关键数据存储类建议把reclaimPolicy显式改为Retain。

追问方向： 一个PV被删除后，PVC还能被其他PVC绑定吗？不能，绑定关系是排他的，一个PV同时只能绑定一个PVC。面试时说出“PV与PVC是一对一绑定”即可。

避坑提示： 不要混淆StorageClass的AllowVolumeExpansion和reclaimPolicy。前者是存储扩容支持，后者是回收规则，两者没有依赖关系。

5.3 第42题：本地存储与CSI插件的适用边界

常见问法： “Kubernetes里的本地磁盘能不能直接用？为什么要引入CSI？”

考察点： 本地卷的局限性和CSI解耦设计。

参考回答： Kubernetes为本地存储提供了local类型的PV，配合延迟绑定机制能把Pod调度到离数据最近的节点上。但LocalPV有很明显的限制，数据绑定节点、节点故障意味着数据可能跟着节点一起丢失，所以它只适合对高可用要求不高的缓存类应用。CSI是容器存储接口标准，它让Kubernetes核心不直接绑死某个厂商的存储实现，存储驱动以独立进程形式部署，提供节点注册、卷挂载、快照和扩容等能力。集群管理员如果选择某厂商云盘做默认存储类，只需安装对应CSI插件并创建StorageClass，PVC创建后插件自动完成云盘创建。

追问方向： 为什么要用延迟绑定？因为LocalPV要求Pod调度到特定节点，如果PV已经绑定到某个节点而调度器把Pod调度到另一台，挂载就会失败。延迟绑定意味着绑定发生在Pod调度决策之后，先选节点再看PV。

避坑提示： 不要把hostPath和local PV混为一谈。hostPath是节点上的任意路径，几乎不提供调度约束和数据保护；local PV会通过nodeAffinity把卷与特定节点绑定，两者不是一个级别。

6. 安全与权限控制专题

6.1 第43题：RBAC的配置逻辑和ServiceAccount的关系

常见问法： “怎么给一个应用一个只读Pod的权限？”

考察点： Role、ClusterRole、RoleBinding、ClusterRoleBinding之间的关系，以及ServiceAccount承载身份的方式。

参考回答： 首先创建一个ServiceAccount，显式声明该身份的工作负载归属。然后决定授权范围，如果是给某个特定命名空间内的资源授权，用Role加RoleBinding；如果是跨命名空间授权或操作集群级资源，比如查看所有命名空间的Pod，用ClusterRole加ClusterRoleBinding。实际操作中也可以把ClusterRole与RoleBinding组合使用，在一个命名空间内只授予ClusterRole定义的部分权限，这种组合能把权限范围收得更细。给应用声明权限后，在Deployment的spec中指定serviceAccountName，Pod内部通过挂载的token向apiserver发起请求时，apiserver会识别这个SA的身份并按RBAC绑定规则判断允许或拒绝。

追问方向： 如果同时配置了SA的token和ConfigMap，这两种凭证有什么区别？token会周期轮换，ConfigMap里的静态内容不会自动更新，安全性上token更可靠。Secret的值必须经过base64编码，但它只是编码不是加密。

避坑提示： 高频扣分点是把ClusterRoleBinding中的subjects理解成只能绑定ServiceAccount。ClusterRoleBinding可以绑定User、Group、ServiceAccount三种对象。用户能在集群外访问集群内API，通常是通过证书或kubeconfig标识身份，它与SA是不同的身份来源。

6.2 第44题：Secret和ConfigMap的存储、使用与安全风险

常见问法： “Secret和ConfigMap有什么区别？Secret能加密吗？”

考察点： 配置信息的承载方式和安全性的真实边界。

参考回答： 两者都可以存放应用配置，区别在于Secret用于存放敏感信息和少量token类数据，ConfigMap负责普通文本配置，两者的挂载方式都支持环境变量注入和文件挂载。Secret的etcd存储默认只做base64编码，不是加密。有经验的面试者会联想到加密能力，Kubernetes提供了EncryptionConfiguration，开启后可以在写etcd时对Secret做AES加密，但这属于集群级配置，默认并不开启。ConfigMap不能存储敏感数据，生产环境中常见的错误是有人把数据库密码写成ConfigMap，这是一个明显需要纠正的做法，标准方案是Secret挂载为文件，避免以环境变量形式暴露在Pod spec和镜像层里。

追问方向： ConfigMap更新后，已经挂载到容器的文件会自动更新吗？已经部署的Pod不会自动重载，需要滚动重启或调用控制器触发重启才能读取到新值，但通过subPath挂载的文件更新行为又有所不同，不会更新到容器内。想要热更新配置，通常需要配合项目自身的配置热加载能力。

避坑提示： 面试时不要说出“Secret传输时自动加密”，Secret在节点磁盘上是未加密状态，并且在镜像构建层留下的历史值无法通过更新Secret清理，推广使用外部密钥管理系统或项目提供的密钥SDK是更专业的补充。

6.3 第45题：Pod Security Admission的工作原理

常见问法： “现在怎么限制Pod以root身份运行？PodSecurityPolicy吗？”

考察点： 是否了解PodSecurityPolicy已经废弃和Pod Security Admission的替代关系，以及三个安全配置级别的含义。

参考回答： PodSecurityPolicy早已在较新版本中正式移除，默认方案是Pod Security Admission，即PSA。它以准入控制器的方式工作，在Pod创建和更新时根据命名空间设置的标签决定是否放行。三个策略级别从宽到严分别是privileged、baseline、restricted。privileged完全放开特权容器、hostNetwork这类能力；baseline允许常见工作负载但要禁掉明显的高危行为，比如privileged容器、hostPath挂载、hostPID共享；restricted则更严格，要求设置seccompProfile、禁止以root运行、禁止特权提升，符合当前安全加固的基线要求。命名空间可以设置强制(enforce)、审计(audit)、警告(warn)三种模式，分别控制拦截、记录审计日志、返回警告三种行为。

追问方向： PSA如何影响现有工作负载？如果命名空间从无策略切到restricted，历史创建的Pod不会被动重建，只有重新创建时才会被拦截。已存在Pod是否被评估，取决于具体版本的实现细节。

避坑提示： 不要说出所有Pod都必须用restricted模式。对于跑网络插件、存储驱动的系统组件，可能需要privileged，策略分级的意义在于按风险容忍度划定安全边界，而不是一刀切。

7. 排错与实操场景专题

7.1 第46题：Pod一直Pending的排查路线

常见问法： “新创建的Pod一直卡在Pending状态，怎么查？”

考察点： 调度失败的真实原因分诊能力。

参考回答： Pending说明Pod还没有被调度到节点，优先执行kubectl describe pod查看事件输出。常见原因按频率排，第一是节点资源不足，事件里会出现类似0/3 nodes are available的提示，同时还会给出各节点因哪些条件不满足被排除，可能是CPU压力、内存压力或者污点不匹配。第二是PVC无法绑定，如果Pod声明了PVC而PV不存在或StorageClass无法供给，调度器同样不会把Pod调度上去。第三是nodeSelector或节点亲和性没有节点能匹配。第四是节点标签和污点配合不当。使用kubectl get events --sort-by=.lastTimestamp命令按时间顺序查看，比单看Pod describe更容易发现关联资源的问题。

追问方向： 事件里出现FailedScheduling同时又有调度器队列堆积，优先怀疑master节点上调度器负载过高。排查步骤是检查kube-scheduler指标、查看是否启动了多份调度器副本导致选主异常。

避坑提示： 不要一看到Pending就先去查节点网络。先看事件，再看PVC状态，最后看节点条件，这个顺序能覆盖80%的Pending原因。

7.2 第47题：CrashLoopBackOff和ImagePullBackOff的处理方法

常见问法： “Pod反复重启，镜像拉不下来，分别怎么处理？”

考察点： 两类错误的状态机和根本原因排查。

参考回答： CrashLoopBackOff表示容器启动后立刻崩溃，kubelet不断尝试重启但每次都在偏离正常状态。常规操作是kubectl logs查看业务日志，如果日志为空，要考虑是否进程直接被杀，比如OOMKilled，用kubectl describe查看Last State的Exit Code和OOMKilled字段，内存超限的解法是调整内存请求或优化进程堆内存。启动阶段崩溃还有一种可能是配置文件挂载路径错误，应用读不到配置就退出。ImagePullBackOff表示镜像拉不下来，原因集中在镜像地址错误、镜像不存在、私有仓库认证失败、节点访问仓库网络不通。分别通过检查镜像名称拼写、镜像标签是否上传、imagePullSecrets配置、节点到仓库的网络连通性排查。

追问方向： 什么情况会出现ImagePullBackOff但实际镜像地址完全正确？很可能是私有仓库证书不被节点信任，或者仓库凭据过期，拉取动作一直失败。优先查看kubelet日志和节点上的容器运行时配置。

避坑提示： 容器退出Code 137通常表示被SIGKILL杀死，常见原因是OOM或节点压力驱逐，不要在所有场景里都归因到应用自身异常。

7.3 第48题：节点NotReady和apiserver证书过期

常见问法： “节点突然变成NotReady怎么查？kubeadm部署的集群证书过期了怎么办？”

考察点： 对集群运维边界的理解，既要排查节点侧，也要考虑控制面。

参考回答： 节点NotReady的根因大概率出现在kubelet和运行时。先登录节点执行systemctl status kubelet查看服务状态，再检查kubelet到控制面的网络链路，关键验证方法是看kubelet日志里最近一次与apiserver的握手结果。另一个常见原因是磁盘压力，节点磁盘达到阈值后kubelet会主动标记节点NotReady并驱逐Pod。如果是证书过期，集群会表现得非常诡异：kubectl get nodes能看到节点但状态中断，或者连接被拒。kubeadm部署的集群执行kubeadm certs check-expiration查看证书有效期，过期的执行kubeadm certs renew all并重启相关静态Pod组件。证书更新后需要把更新后的kubeconfig同步到所有客户端。

追问方向： 控制面组件的证书过期会导致什么现象？apiserver本身无法启动，或者kubelet无法认证。这两种情况恢复步骤不同，前者从etcd或备份恢复apiserver，后者只需更新kubelet的kubeconfig。

避坑提示： 不要在没有时间同步的集群里想当然地判断证书没过期。节点如果比签发时间还早，证书校验必然失败，NTP和chrony的配置应该是回答里的前置条件。

7.4 高频排错命令速查表

这组速查表的价值不是背下来，而是建立“症状->命令->字段”的思路链路。我在实际处理集群告警时，几乎不背文档，靠的是一张类似这样的自建速查表，把每个组件的核心日志位置和关键错误码记下来，排查效率能明显提高。

8. 备考心得与实测补充

这一篇的题目难度比前三篇整体上调了一档。如果只看官方文档，你会发现每一道题的知识点都能找到出处，但面试时仍答不好，原因往往是缺一层“现场推演”能力。比如Deployment滚动更新那题，光知道maxSurge和maxUnavailable的定义是不够的，还得能算出来默认值在10副本时是2不可用和3超量。面试官真正想听的是你对机制运转过程的自然叙述，而不是背句子。

我建议备考时在真实环境里亲手做三次实验。第一次实验名为“探针实验”，给一个应用分别配liveness、readiness、startup探针，观察不同阶段容器是否重启、Pod是否Ready。第二次实验名为“滚动更新实验”，把Deployment副本数设为10，更新镜像后实时观察ReplicaSet数量变化，同时在另一个终端执行kubectl rollout status。第三次实验名为“故障恢复实验”，手动删除一个正在跑关键工作负载的etcd节点，观察集群是否自动选出新Leader。做完这三个实验，你会发现好多题不用刻意背，答案已经内化了。

另外关于Kubernetes的版本升级，我把自己的原则分享出来作为补充：社区对某个资源的废弃通常分两步，先标记废弃，再在后续版本中移除。日常学习不要只看当前版本，还要看官方废弃计划，避免面试提到已删除的PodSecurityPolicy时露怯。我自己踩过一次类似的坑，花了两周维护一套旧PodSecurityPolicy规则，最后发现新版本集群里这个资源根本不存在。

这次的整理先到这里。下一篇004之后的版本，我准备按“调度器源码分析”和“CNI插件调试思路”两个方向展开，这两个方向的面试题这两年出现频率明显上升。如果你在准备Kubernetes岗位，建议把这篇第25到48题逐题写一遍自己的回答，再对照参考答案检查遗漏点。写得出来的才是真的会。