容器与 Kubernetes¶

OCI 镜像、运行时和分发规范之间是什么关系？¶

技术说明

OCI¹ 将容器生态拆成 Image Specification、Runtime Specification 和 Distribution Specification。镜像不是一个压缩的根文件系统，而是由 manifest、config 与按顺序叠加的只读 layer² 组成；config 记录入口、环境变量、用户以及 rootfs diff ID，manifest 用 digest 指向 config 和 layer。digest 与 tag³ 分别承担不可变内容标识和可移动别名的作用，因此生产部署应记录或固定 digest。

运行时规范描述 config.json、rootfs、namespace、mount、capability 与 cgroup 等如何组成一个 bundle，并定义 create/start/kill/delete 生命周期；runc 一类低层运行时消费该规范。分发规范定义 registry 的 blob、manifest 上传下载 API。Kubernetes⁴ 通过 CRI⁵ 调用 containerd 或 CRI-O，后者再管理镜像、快照和低层 runtime；OCI 本身并不定义调度、编排或 CRI。跨平台镜像还要检查 manifest index、架构与操作系统匹配，不能假设同一 digest 可在任意节点执行。

实践经验

复合场景中，流水线先推送 app:release，随后另一个任务覆盖同一 tag，部分节点缓存旧 manifest，导致同一 Deployment 出现两个二进制版本。证据是 Pod 的 imageID digest 不同，而 YAML 中 tag 相同。止血是暂停发布、把已验证 digest 写回工作负载并重建异常 Pod；长期改为构建一次、按 digest 晋级，签名与 SBOM 也绑定 digest。副作用是应急回滚不能只改 tag，发布系统必须保存 digest 到版本映射。

面试回答要点

容器与虚拟机的隔离边界有何不同，何时不能把容器当安全边界？¶

技术说明

虚拟机由 hypervisor⁶ 提供虚拟硬件并运行独立 guest kernel；普通 Linux 容器共享宿主机内核，依靠 namespace⁷ 隔离视图、cgroup⁸ 约束资源，再叠加 capability、seccomp、LSM⁹（SELinux/AppArmor）和只读文件系统降低权限。容器启动快、密度高，但 syscall 入口最终仍到同一个内核，内核漏洞、错误挂载的宿主路径、特权模式或泄露的 runtime socket 都可能突破隔离。

安全边界取决于威胁模型。互不信任的租户、可执行任意代码的 CI、公开的代码沙箱，通常需要 microVM、沙箱 runtime 或独立节点/账号；同一信任域内的微服务可使用普通容器，但仍应禁用 privileged、hostPID/hostNetwork、危险 capability 和可写 hostPath。不能用“容器里是非 root”替代验证：若 UID 映射到宿主 root 或拥有 CAP_SYS_ADMIN，风险仍很高。

实践经验

复合场景中，构建 Pod 为执行 Docker-in-Docker 挂载宿主 runtime socket，第三方 PR 脚本由此创建 privileged 容器并读取节点凭证。审计日志、PodSpec 和 socket 调用记录构成证据。止血是隔离 runner 节点、撤销云凭证并停用该模板；长期改用无守护进程构建器、短期 OIDC 凭证、受限网络和一次性节点。代价是构建兼容性与缓存命中率下降，需要专门优化缓存服务。

面试回答要点

Linux namespace 分别隔离什么？排障时如何判断进程实际所在的 namespace？¶

技术说明

常见 namespace 包括 PID（进程号与进程树）、mount（挂载视图）、network（接口、路由、端口、netfilter）、UTS（主机名）、IPC（System V IPC/POSIX message queue）、user（UID/GID 映射）、cgroup（cgroup 路径视图）和 time（部分时钟偏移）。namespace 主要改变“看见什么”，并不限制 CPU、内存或 I/O；资源限制属于 cgroup。多个容器也可能显式共享某个 namespace，例如 Pod 内容器通常共享网络 namespace。

可比较 /proc/${TARGET_PID}/ns/* 的 inode，或用 lsns 查看成员；nsenter -t "${TARGET_PID}" -n -m -p 可进入目标进程视图。排查 Pod 网络时，应先找到 sandbox/pause 进程的宿主 PID，再在其 network namespace 中检查 ip addr、ip route、ss 和 DNS，而不是只在节点默认 namespace 看端口。user namespace 的 /proc/${TARGET_PID}/uid_map 可验证容器 UID 到宿主 UID 的映射。进入目标 mount namespace 前还应使用只读方式，防止诊断命令意外修改容器文件系统。

实践经验

复合场景中，节点上 curl 127.0.0.1:15000 正常，但业务容器访问失败。证据显示运维进入的是宿主 network namespace，而 sidecar 端口只存在于 Pod namespace；进入 sandbox PID 后发现 iptables 重定向链未装载。止血是重建受影响 Pod 并暂停有问题的 CNI¹⁰/sidecar 版本；长期在诊断脚本中输出 namespace inode、目标 PID 和路由表，避免“在错误视图中得到正确结果”。重建会短时降低容量，需受 PDB¹¹ 与容量约束。

面试回答要点

cgroup v2 如何控制 CPU、内存和 I/O？如何解释“CPU 使用率不高但延迟升高”？¶

技术说明

cgroup v2 使用统一层级。CPU 权重由 cpu.weight 表示相对份额，带宽上限由 cpu.max 的 quota/period 控制；内存常用 memory.min/low/high/max 表达保护、回收节流和硬上限，memory.events 可见 high、oom、oom_kill；I/O 可用 io.weight 与 io.max。Kubernetes 的 request 主要参与调度并映射部分相对权重，limit 才可能形成硬上限，二者语义不能互换。

平均 CPU 使用率低并不排除 throttling：一个线程在短窗口迅速用完 quota，余下 period 被暂停，分钟级均值仍很低。应同时看 cpu.stat 的 nr_throttled、throttled_usec，应用 p99 延迟、run queue、PSI cpu.pressure，并核对节点是否超售。内存问题则联看 working set、memory.events、PSI 与内核 OOM 日志；单看 kubectl top 容易遗漏瞬时压力。指标要计算速率并对齐请求时间窗，累计计数本身不能说明当前仍在受限，还应和同节点对照组比较。

实践经验

复合场景中，Java API CPU 图仅 45%，发布后 p99 却从 80ms 升至 900ms。证据是每秒 nr_throttled 激增，线程 dump 显示请求线程可运行但未获调度，limit 恰好等于 1 核。止血是提升 limit 并扩副本，同时核对节点余量；长期以压测确定 request，谨慎设置 CPU limit，加入 throttling/PSI 告警。副作用是取消或提高 limit 可能放大邻居争抢，必须结合节点隔离和容量预留。

面试回答要点

containerd、CRI、shim 与 runc 在一次 Pod 启动中分别做什么？¶

技术说明

kubelet 通过 CRI 的 gRPC 接口请求拉取镜像、创建 Pod sandbox、创建并启动容器；containerd 的 CRI 插件处理请求，内容存储保存 blob，snapshotter（如 overlayfs）准备可写根文件系统，CNI 通常在 sandbox 建立阶段配置网络。containerd 随后为容器准备 OCI bundle，并由 shim 调用 runc 创建进程、namespace、mount 和 cgroup。

runc 完成创建后可退出，shim 作为每个容器或 Pod 级别的中间进程维持 stdio、收集退出状态，使 containerd 重启时业务进程不必随之退出。排障要按层定位：crictl 看 CRI 对象与 sandbox，ctr/nerdctl 更贴近 containerd，但不应随意修改 Kubernetes 管理的对象；检查 kubelet、containerd、shim 日志以及 CNI 结果，避免把 ImagePull、CreateContainer 与应用启动失败混为一谈。节点升级还需验证 kubelet、CRI API、runtime、CNI 和底层内核的兼容组合。

实践经验

复合场景中，新节点 Pod 长期停在 ContainerCreating。事件只有 sandbox 创建失败，containerd 日志显示 CNI 二进制不存在，而镜像已完整下载；这排除了 registry 与应用问题。止血是将节点 cordon、修复节点镜像包并重启 runtime 后逐个 drain/回收；长期把 CRI、CNI 二进制和配置纳入节点镜像验收，启动前执行 sandbox smoke test。重启 runtime 可能影响 exec/log 能力，需先确认运行中容器与 shim 状态。

面试回答要点

如何设计可复现、体积小且缓存有效的容器镜像构建？¶

技术说明

镜像层由 Dockerfile 指令及构建上下文决定。应先复制锁文件并安装依赖，再复制高频变化的源码；使用 .dockerignore 缩小上下文，多阶段构建只把运行制品与必要 CA/时区数据带入最终镜像。固定基础镜像 digest、依赖锁文件、构建器版本和目标平台，关闭或记录会引入当前时间、随机下载的步骤，才能接近可复现。体积小只是结果，关键是攻击面和依赖可追溯。

BuildKit cache mount 可缓存包管理目录，secret/SSH mount 可在构建时注入凭证且不写入 layer；不能用 ARG/ENV 保存 token，因为历史 layer 与 provenance 可能泄露。运行镜像应使用非 root 用户、明确入口与信号行为，并输出 SBOM、provenance、漏洞扫描结果。构建一次后在环境间晋级同一 digest，禁止每个环境重新 build。

实践经验

复合场景中，团队为减小镜像在同一 RUN 中下载私有依赖并删除 token，但扫描历史层仍找到凭证；不同区域重新构建又拉到了不同的未锁定包。止血是撤销 token、隔离相关镜像并以已知依赖重建；长期启用 secret mount、依赖锁定、digest 基础镜像与制品晋级。副作用是严格固定 digest 不会自动获得安全补丁，需要 Renovate 类更新流程和重建 SLA。

面试回答要点

如何构建容器运行时最小权限基线？¶

技术说明

最小权限应从身份、系统调用、文件系统和宿主接口四层实施：设置非 root runAsUser/runAsNonRoot，尽可能启用 user namespace；默认 drop all capabilities，仅按需加回如 NET_BIND_SERVICE；allowPrivilegeEscalation: false 阻止通过 setuid 获得新权限；使用 RuntimeDefault seccomp、SELinux/AppArmor，根文件系统只读，并为确需写入的位置挂临时卷。

应禁止 privileged、hostPID/IPC、非必要 hostNetwork、任意 hostPath、宿主设备和 runtime socket；服务账号不需要 API 时关闭 token 自动挂载。基线必须可测：准入策略阻止违规 Pod，运行时检测异常 syscall/进程，镜像扫描不等价于运行时隔离。端口小于 1024 可通过更高应用端口、服务映射或精确 capability 解决，不应因此整体 root 化。

实践经验

复合场景中，一个旧 exporter 以 root 运行并挂载 / 只读；漏洞利用虽不能改宿主，却读取了 kubelet 配置和云初始化残留。证据来自审计与节点文件访问事件。止血是撤销暴露身份、删除 DaemonSet、轮换凭证；长期拆分所需的 /proc 指标接口、采用受限挂载与专用节点，准入拒绝根目录 hostPath。副作用是少数节点代理确实需要宿主可见性，应通过单独策略、签名镜像和变更审批处理例外。

面试回答要点

镜像拉取慢或 ImagePullBackOff 应如何形成证据链？¶

技术说明

ImagePullBackOff 是 kubelet 在拉取失败后的退避状态，不是根因。先看 Pod events 中的状态码与错误类型：名称解析、TCP/TLS、401/403、404/manifest unknown、429 限流、磁盘不足或解压失败；再从节点直接验证 DNS、registry TLS、代理/no_proxy 和凭证作用域。还要核对镜像平台 manifest 是否包含节点架构、tag 是否存在，以及 imagePullPolicy 和凭证 secret 是否在同一 namespace。

拉取耗时应拆为 manifest 查询、layer 下载、解压/快照与启动。registry 指标、节点网络、containerd 日志和磁盘 IOPS 能区分瓶颈；镜像层并行、区域镜像缓存、预拉取只在证据支持时使用。不要盲目删节点所有镜像，这会制造下载风暴；垃圾回收应看 imagefs 容量、水位和正在使用的内容。

实践经验

复合场景中，全新 ARM 节点池上的 Pod 报 manifest 不匹配，而旧 x86 节点正常。事件明确显示 no match for platform，registry 里只有 amd64 manifest。止血是暂停扩到 ARM、把工作负载约束回 x86 并补发多架构 digest；长期在 CI 中逐架构启动测试并检查 manifest list。多架构构建增加时间和缓存成本，也要防止不同架构依赖版本漂移。

面试回答要点

单机容器网络从容器到外部的报文路径是什么？¶

技术说明

典型 bridge 模式中，容器 network namespace 内的 eth0 是 veth 一端，另一端连接宿主 bridge；容器按本 namespace 路由把包交给 veth，宿主转发并可能经 netfilter 做 SNAT/MASQUERADE 后从物理接口发出。入站端口映射通常由 nftables/iptables DNAT 或用户态代理实现。不同 CNI 可能使用路由、overlay、eBPF 或云网卡，不能默认所有集群都有 bridge 与 iptables。

排障按层验证：容器接口/路由与邻居表、宿主对应 veth、转发开关、策略规则、conntrack、MTU、物理/overlay 路径。抓包要在关键跳点同时进行并记录五元组变化；ip route get、ss、conntrack、tcpdump/eBPF 可验证假设。遇到小包成功大包失败优先检查 MTU/PMTUD，而不是先归因 DNS。还要检查回程路由和反向路径过滤，因为单向可达常被误判为服务端未监听。

实践经验

复合场景中，跨节点 gRPC 大请求超时，小健康检查正常。两端抓包显示 overlay 外层增加头部后超过底层 MTU，ICMP fragmentation-needed 又被网络策略丢弃。止血是降低 CNI MTU 并滚动重建端点；长期让节点启动检查底层 MTU、允许必要 ICMP、用大包探针做跨节点验证。降低 MTU 会增加分片前的包数量与 CPU 开销，需要容量验证。

面试回答要点

容器可写层、bind mount 和 volume 的语义及风险分别是什么？¶

技术说明

容器镜像层只读，可写层通常由 overlayfs 等 copy-on-write snapshot 提供，生命周期随容器删除，不适合持久数据；首次修改下层大文件会 copy-up，可能造成延迟与空间放大。bind mount 将指定宿主路径直接暴露给容器，性能和可见性直接，但强耦合节点布局并扩大宿主攻击面。由 runtime/编排器管理的 volume 与容器生命周期解耦，可由本地或远端存储驱动提供。

日志若无限写可写层，会占满 imagefs；数据库写 overlayfs 还可能遇到 CoW、fsync 与 inode 行为差异。应把持久数据放受支持的 volume，临时数据使用有 sizeLimit 的 ephemeral volume，根文件系统尽量只读。迁移和备份必须理解应用一致性，卷快照并不自动保证数据库事务一致；宿主 bind path 也不应作为跨节点调度可用性方案。

实践经验

复合场景中，应用把上传文件写到容器 /data，重启后丢失；同时旧 Pod 可写层未及时回收导致节点 imagefs 压力。通过 mountinfo、容器 snapshot 使用量和部署配置确认未挂卷。止血是暂停重启、从仍存活副本导出数据并挂 PVC 迁移；长期增加启动时存储检查、空间水位告警与数据持久性测试。迁移期间双写会引入一致性风险，因此应采用短暂只读窗口或可校验的复制流程。

面试回答要点

Kubernetes 控制面一次创建 Pod 的完整协调链路是什么？¶

技术说明

客户端把声明式对象提交给 kube-apiserver；API server 完成认证、授权、准入、默认值与校验后，将对象持久化到 etcd。controller-manager 中的控制器通过 watch/list 观察期望与实际状态，例如 Deployment 控制器创建 ReplicaSet、ReplicaSet 控制器创建未绑定 Pod。scheduler 发现 spec.nodeName 为空的 Pod，经预选过滤、打分及插件扩展选择节点，并通过绑定写回 API。

目标节点 kubelet watch 到绑定结果，通过 CRI 创建 sandbox/容器，通过 CNI 配网、CSI 挂卷，并不断上报 PodStatus；端点控制器据 readiness 更新 EndpointSlice。各组件不是同步调用的长事务，而是基于资源版本、watch 与重试的最终一致协调循环。因此“kubectl create 成功”只代表对象被 API 接受，不代表镜像、网络或应用已经就绪；排障应沿对象 ownerReference、events 与组件日志逐层追踪。

实践经验

复合场景中，Deployment 已显示期望副本 20，但只有 12 个 Ready。对象链显示 ReplicaSet 已创建 20 个 Pod，其中 8 个 Pending；scheduler 事件为节点卷拓扑不匹配，而非控制器失效。止血是把工作负载暂时调回有可用卷的可用区并补容量；长期在发布前验证 StorageClass 拓扑、节点池余量与调度模拟。临时降低拓扑约束可能削弱故障域冗余，应设恢复期限。

面试回答要点

Pod 的生命周期、状态与 condition 应如何正确解读？¶

技术说明

Pod phase 只有 Pending、Running、Succeeded、Failed、Unknown 等粗粒度结论；Running 仅表示至少一个容器正在运行或启动/重启中，并不等同于可接流量。应查看 status.conditions 的 PodScheduled、Initialized、ContainersReady、Ready，以及每个 container status 的 Waiting/Running/Terminated、reason、exitCode、restartCount、lastState。控制器和流量系统通常关心 Ready，排障则需要完整状态转移。

普通 init container 必须串行运行至成功后，常规容器才启动。原生 sidecar 自 Kubernetes v1.33 起进入稳定状态：它写在 initContainers 中，但使用容器级 restartPolicy: Always，会在 Pod 生命周期内持续运行；这与“把代理写成普通容器”或由注入器实现的 sidecar 不是同一机制。容器重启策略作用于同一 Pod sandbox 内，Pod 被重新调度则 UID 与本地数据均改变。kubectl describe pod 看事件与 condition，kubectl logs --previous 查看上一实例日志；还应通过 Pod UID 区分“容器重启”和“Pod 被替换”，否则会误判稳定性。终止中的 Pod 还可能短暂保留对象与 condition，统计时应同时过滤 deletionTimestamp，并按控制器期望副本核对分母。

实践经验

复合场景中，监控只按 Pod phase 统计，所有 Pod 均 Running，但订单成功率下降。证据是半数容器 readiness 为 false，lastState 显示 OOMKilled 后反复预热；Service 已正确摘除它们，但剩余实例过载。止血是回滚内存增长版本、扩容健康副本并限制并发；长期以 Ready endpoint、restart reason 和业务成功率联合告警。单纯扩副本会增加预热与下游压力，不能作为唯一措施。

面试回答要点

Kubernetes scheduler 如何过滤和打分？调度慢应检查什么？¶

技术说明

scheduler 处理未绑定 Pod，经 scheduling cycle 的 PreFilter/Filter/PostFilter/PreScore/Score/Reserve/Permit 等扩展点筛选并打分节点，再在 binding cycle 完成 PreBind/Bind/PostBind。资源、nodeSelector/affinity、taint/toleration、端口、卷拓扑、Pod topology spread 等都可能在 Filter 阶段排除节点；Score 只是对剩余可行节点排序，不能让不满足硬约束的节点“凑合运行”。

调度延迟需区分队列等待、计算耗时、无可行节点和绑定/卷操作。查看 Pod events 的 FailedScheduling 原因、scheduler 指标（pending pods、scheduling attempt、framework extension point duration）、调度器日志及 API 延迟。大量互相矛盾的硬约束、超大集群中的昂贵亲和规则、频繁失败重试和 API server 限流都会拖慢；不能只通过增加 scheduler 副本期望同一队列线性加速。

实践经验

复合场景中，一次机房扩容后大量 Pod Pending，事件同时显示 CPU 不足和 topology spread 不满足。统计可行节点发现目标 zone 有 CPU，但缺少新 workload 使用的 label；盲目加节点没有改善。止血是修复节点标签并分批重排，保留关键服务优先级；长期用准入校验标签键、对节点池做调度合成测试。手动放松 spread 可恢复容量，但会让副本集中于单故障域，需明确风险窗口。

面试回答要点

requests、limits、QoS 与 eviction 之间如何关联？¶

技术说明

调度器主要按容器 requests 汇总判断节点是否可容纳 Pod，而不是依据实时使用率；CPU limit 常映射为 CFS 带宽，内存 limit 是硬边界并可能触发容器 OOM。Pod 的 QoS 通常为 Guaranteed、Burstable 或 BestEffort：所有容器对 CPU/内存均设置相等 request/limit 才可能是 Guaranteed；无 request/limit 为 BestEffort，其余为 Burstable。QoS 影响节点压力下的驱逐排序，但不是绝对免死金牌。

kubelet 依据 memory.available、nodefs/imagefs、inode、PID 等 eviction signal 回收资源；先考虑超出 request、优先级和实际使用等。容器 OOMKilled 与 kubelet eviction 不同：前者通常由 cgroup/内核内存边界触发，后者是节点为自保终止 Pod。kubectl describe、termination reason、节点 conditions、kubelet 日志和 memory.events 应联合判断。本地临时存储 request/limit 与日志、emptyDir 使用也会影响调度和驱逐，不能只核对 CPU、内存。

实践经验

复合场景中，节点显示 MemoryPressure，批处理与部分 API 同时消失。API 虽为 Burstable，但实际内存远高于低估的 request，在驱逐排序中不利；事件明确为 Evicted，而非 OOMKilled。止血是停止批任务、扩节点并恢复 API；长期基于历史分位数调整 request、给关键服务 PriorityClass 与合理 Guaranteed 配置，并设置系统预留。提高 requests 会降低装箱率、增加成本，需以 SLO 和容量模型权衡。

面试回答要点

Deployment 滚动发布为何会卡住或产生容量峰值？¶

技术说明

Deployment 通过新旧 ReplicaSet 逐步调节副本，maxSurge 决定超过期望副本的临时增量，maxUnavailable 决定可暂时不可用数量；取整规则、readiness 和 minReadySeconds 共同影响推进。progressDeadlineSeconds 只用于报告进展失败，不自动回滚。若新 Pod 因调度、镜像、探针或配额不就绪，旧副本通常会保留到可用性预算允许的程度。

容量峰值不仅是 Pod 数，多余副本还会占 CPU、IP、卷 attach、连接池和下游并发。terminationGracePeriodSeconds 与 preStop 可使 terminating Pod 长时间占资源；HPA 同时改 replicas 时，发布控制的比例会动态变化。检查 Deployment conditions、ReplicaSet desired/current/available、Pod events 和 scheduler，避免只盯 kubectl rollout status。回滚也会创建新的 rollout 状态，必须重新验证旧版本对新配置和数据库 schema 仍兼容。

实践经验

复合场景中，20 副本服务设置 50% surge，新版本启动时每个实例建立 100 个数据库连接，数据库连接耗尽使探针失败，发布停滞。证据是新 ReplicaSet 10 个 Pod反复 NotReady，数据库连接数与发布同步突增。止血是暂停 rollout、缩小 surge、回滚并临时提高受控连接额度；长期加入连接预热限速、每实例池上限和发布前峰值预算。减小 surge 会延长发布，应结合风险选择。

面试回答要点

StatefulSet 提供了什么保证，又不保证什么？¶

技术说明

StatefulSet 为 Pod 提供稳定序号、稳定网络身份、按模板创建的独立 PVC，以及默认有序创建/删除更新语义；Headless Service 常用于稳定 DNS。它不提供数据库复制、leader 选举、数据一致性、备份或自动故障转移，也不保证 Pod 换节点后底层卷一定能在目标故障域挂载。应用仍需知道如何形成 quorum、重建副本并保护数据。

RollingUpdate 可按 ordinal 更新，partition 可用于分段；podManagementPolicy: Parallel 牺牲顺序以提高并行性，但只适用于应用允许时。缩容通常不会自动删除 PVC，以免误删数据；因此重扩时可能复用旧数据。上线前要验证卷拓扑、fencing、反亲和、PDB、优雅终止及版本兼容，尤其要防两个实例同时认为自己拥有同一份可写数据。

实践经验

复合场景中，三节点存储服务所在 zone 故障，Pod 在其他 zone Pending，PVC 绑定的是单区块存储。团队误以为 StatefulSet 会搬迁数据。止血选择恢复区内节点并从应用副本提供服务，而不是强行解绑卷；长期改为跨区应用复制、WaitForFirstConsumer、明确故障转移 runbook 与定期恢复演练。跨区复制提高网络成本，并需处理延迟和一致性权衡。

面试回答要点

DaemonSet、Job 与 CronJob 的控制语义和常见陷阱是什么？¶

技术说明

DaemonSet 保证符合节点选择条件的节点上运行一个 Pod，适合日志、网络和节点监控代理；节点变化会触发协调，但污点容忍、host 资源与滚动策略必须明确。Job 以成功完成次数为目标，可设置并行度、backoff、active deadline 和完成后 TTL；“Pod 重启”与“Job 新建 Pod 重试”可能让任务执行多次，因此业务动作必须幂等。

CronJob 按控制器观察到的时间创建 Job，支持 concurrencyPolicy、startingDeadlineSeconds、历史保留和时区配置。它不是严格的分布式 exactly-once 定时器：控制面停顿、网络分区或调度延迟可能造成漏过或重复创建。关键财务/变更任务要在应用层使用幂等键、租约/唯一约束与完成账本，不能只依赖 Forbid。

实践经验

复合场景中，月结 CronJob 因 API server 短暂不可用，恢复后任务重试，外部支付接口被调用两次。Job 状态与支付日志显示两个不同 Pod 使用相同业务批次但无幂等键。止血是停用 CronJob、冻结异常批次并对账补偿；长期以批次 ID 建唯一约束、把副作用与状态提交设计成可重放流程，并对 missed schedule 告警。严格串行会降低追赶速度，需要容量预案。

面试回答要点

startup、readiness、liveness probe 应如何分工？¶

技术说明

startup probe 用于保护慢启动：在其成功前，liveness/readiness 的正常判断不会导致慢启动被误杀；readiness 决定 Pod 是否进入 Service endpoint，失败应表示“暂不应接流量”；liveness 失败会让 kubelet 重启容器，只适用于进程确实无法自行恢复。三者可以使用 HTTP、TCP、exec 或 gRPC，但检查路径的成本、超时与依赖必须受控。

liveness 不应深查数据库、第三方 API 等共享依赖，否则依赖故障会让所有实例同步重启并形成风暴。readiness 可以反映必需依赖，但也要防抖；应用应区分本地活性、启动完成与接流能力。探针由 kubelet执行，网络路径与普通 Service 客户端可能不同；排障要看 probe event、应用日志、节点负载和 timeout，而不是只在本地 curl 一次。

实践经验

复合场景中，数据库抖动使 liveness 的深度查询超时，所有 API 容器被同步重启，连接风暴进一步压垮数据库。证据是重启原因均为 probe failure，进程此前仍能返回降级响应。止血是临时改用本地进程活性检查、分批恢复副本并限制数据库连接；长期拆分三类端点、加入启动保护、失败阈值与探针延迟 SLO。放宽探针会延迟真实死锁发现，需要应用 watchdog 和业务告警补充。

面试回答要点

Pod 优雅终止从删除请求到进程退出经历什么？¶

技术说明

删除 Pod 后 API 对象设置 deletionTimestamp，kubelet 开始终止流程：执行容器 preStop（若配置），向主进程发送 TERM，并在 terminationGracePeriodSeconds 倒计时内等待，超时后 KILL。与此同时端点控制器会更新 EndpointSlice，但数据面、负载均衡器和客户端缓存存在传播延迟，所以“Pod 已 NotReady”不等于所有新连接瞬时停止。

应用应在收到 TERM 后先停止接受新工作，继续完成或转移在途请求，刷新必要状态并在预算内退出；长连接、消息消费者、leader 和批任务各有不同的排空语义。preStop 时间包含在 grace period 内，不能把二者简单相加。滚动更新、节点 drain、抢占与 OOM 的保证也不同，OOM/KILL 无法依赖优雅回调。

实践经验

复合场景中，每次发布都有少量 502。抓包和 ingress 日志显示 Pod 收到 TERM 后立即退出，而旧 endpoint 仍被部分代理使用数秒。止血是延长 grace、在 TERM 后停止接新请求并等待连接排空；长期用 readiness gate/负载均衡摘流状态协调，发布测试统计终止窗口错误。盲目 sleep 会拖慢发布并占 surge 容量，等待时长应依据实际传播与请求分位数。

面试回答要点

HPA 的控制算法、指标边界与抖动治理是什么？¶

技术说明

HPA 周期性读取资源或自定义/外部指标，核心比例可概括为 期望副本 ≈ 当前副本 × 当前指标/目标指标，再结合取整、容忍区间、缺失指标、未就绪 Pod 与行为策略。CPU utilization 是使用量相对 request 的比例，没有合理 request 时语义会失真。扩缩容最终改变可伸缩工作负载的 replicas，并不直接保证新副本能调度或及时 Ready。

对队列业务，队列深度/每副本积压与处理时延通常比 CPU 更接近需求；但指标延迟、冷启动和下游容量会造成控制环过冲。应配置 scaleUp/scaleDown 策略、稳定窗口、速率限制、min/max replicas，并观测 desired/current、指标新鲜度、调度时间、Ready 时间与下游饱和。不能让 HPA 与手工/另一个控制器持续争写 replicas。

实践经验

复合场景中，流量尖峰后 HPA 快速从 20 扩到 100，但新 Pod 启动需 4 分钟，数据库先被连接打满；流量回落后又过快缩容导致队列反弹。证据链连接外部指标时间戳、desired replicas、Ready 延迟和数据库连接。止血是限制扩容速率、提高常驻最小副本并保护下游；长期缩短冷启动、改用队列时延指标和容量上限联动。更高 min replicas 增加成本，应由 SLO 和峰值频率决定。

面试回答要点

VPA 如何给出资源建议，为什么与 HPA 可能冲突？¶

技术说明

VPA 通常由 recommender 根据历史与当前资源使用估算 target、lower/upper bound，admission 组件可在 Pod 创建时修改 requests，updater 则按 updateMode 处理存量 Pod。模式必须以集群实际安装的 VPA 版本和功能门限为准：Off 只提供建议，Initial 仅在 Pod 创建时应用，Recreate 通过驱逐/重建更新；支持原地调整的环境还可使用 InPlaceOrRecreate 或 InPlace。Auto 自 VPA 1.4 起已弃用，不应再把它当作长期固定语义。VPA 主要调整 request，limit 的处理还取决于 resource policy；建议值也受 min/max allowed、数据窗口和异常峰值影响。

若 HPA 以 CPU utilization（使用量/request）扩缩副本，VPA 同时改变 request 会改变 HPA 分母，两个控制环可能互相干扰。常见做法是 VPA 仅建议、HPA 使用不依赖 request 的外部指标，或明确拆分控制维度。启用自动更新前需评估 PDB、重启成本、节点可调度余量和 JVM 等应用对内存变化的行为。

实践经验

复合场景中，VPA 以重建模式提高 request 后，部分替换 Pod 无法在现有节点装下，服务可用副本下降；HPA 同时因 CPU 百分比降低而缩容。证据是 VPA recommendation、updater/eviction 事件和 HPA desired 同步变化。止血是把 updateMode 切到 Off、恢复副本并补节点；长期离线审阅建议、设置边界，并以请求率/队列指标驱动 HPA。若评估原地调整模式，还要先验证工作负载、集群能力和失败回退，不能假设所有资源都能无重启变更。保守边界会降低自动优化收益，但更易控制风险。

面试回答要点

PDB 能保护什么，为什么节点维护时仍可能中断？¶

技术说明

PodDisruptionBudget 通过 minAvailable 或 maxUnavailable 约束匹配 Pod 的自愿中断（如 eviction API 驱动的 drain），控制器根据 healthy/current/desired 计算允许中断数。它不阻止节点宕机、内核崩溃、OOM、直接删除 Pod、工作负载自身滚动策略或某些不经 eviction 的动作，也不保证剩余副本实际能承载流量。

百分比取整、selector 范围、多个控制器共用标签以及 unhealthy Pod eviction policy 都会影响结果。若单副本设置 minAvailable: 1，安全 drain 可能永远阻塞；若多个副本集中一节点，PDB 也无法抵抗该节点突然失效。应同时设计副本数、拓扑分散、就绪语义和维护超时，自动化不得简单用强制删除绕过 PDB。

实践经验

复合场景中，升级节点池时 drain 卡住，操作脚本超时后使用强制删除，导致一个有状态服务失去 quorum。证据是 eviction 返回 429、PDB disruptionsAllowed 为 0，副本还集中在同一故障域。止血是停止后续节点操作、恢复 quorum 并逐一验证成员；长期让维护系统在 PDB 阻塞时升级为人工决策，补反亲和与容量前置检查。维护时间会变长，因此需要分批窗口和明确例外流程。

面试回答要点

node affinity、Pod affinity、topology spread 与 taint/toleration 如何选？¶

技术说明

nodeSelector/node affinity 表达 Pod 对节点标签的硬要求或软偏好，例如架构、GPU、合规区；taint 由节点排斥 Pod，toleration 只表示允许进入，不保证一定调度到该节点，通常再配 affinity 实现专用池。Pod affinity/anti-affinity 根据已有 Pod 标签和 topologyKey 做靠近/分散，适合通信局部性或副本隔离，但硬规则会随集群规模增加计算与死锁风险。

topology spread constraints 直接约束各故障域的副本偏斜，可配置 maxSkew、topologyKey 与无法满足时的行为，通常比复杂反亲和更能表达均匀分布。硬约束必须与节点标签、最小容量和扩容器理解一致；软偏好则可能在压力时被牺牲。标签是调度 API，应治理来源，不能让普通租户任意伪造安全/合规标签。

实践经验

复合场景中，服务同时配置硬 podAntiAffinity 与 zone spread，扩容时第三个 zone 无节点容量，所有新 Pod Pending。证据是 scheduler 逐项列出 affinity 与 spread 不满足。止血是为该 zone 补容量；在业务批准下临时把其中一条改软，而不是随意删全部规则。长期用最小可满足模型测试约束，并让集群扩容器识别节点池。软化规则可能集中副本，必须有风险告警。

面试回答要点

PriorityClass 与 preemption 如何工作，如何避免高优任务造成级联驱逐？¶

技术说明

PriorityClass 为 Pod 赋数值优先级，scheduler 队列通常优先处理高优 Pod；若无可行节点，preemption 可选择较低优先级 victim，使高优 Pod 有机会调度。抢占不是即时资源回收，受受害 Pod 终止时间、PDB 与重新调度影响；preemptionPolicy: Never 可保留排队优先级但禁止主动抢占。系统关键优先级应极少使用并受权限控制。

优先级不能创造容量，过多“最高优”会让机制失效；被抢占工作负载迁移到其他节点还可能再次挤压，形成 churn。设计时要按业务 SLO 分层，配资源配额、专用节点/预留容量、PDB 和抢占演练，并监控 preemption attempts、victims、pending time 与关键服务可用性。

实践经验

复合场景中，数据平台把大批临时任务误设为最高优先级，发布后抢占在线服务的辅助 Pod，辅助能力丢失又使主服务过载。events 和 scheduler 日志显示 victim 选择链。止血是暂停任务队列、纠正 PriorityClass 并恢复在线容量；长期限制高优类使用权限、按 namespace 配额，批任务改用可中断节点池。降低批任务优先级会延长完成时间，需要业务接受 SLA 分层。

面试回答要点

Service、EndpointSlice 与 kube-proxy/eBPF 数据面如何协作？¶

技术说明

Service 提供稳定虚拟 IP/端口和选择器语义，控制器把符合选择器的 Pod 地址编入 EndpointSlice；“出现在 Slice 中”不等于“应接收新流量”。EndpointSlice 还携带 ready、serving、terminating 条件，终止中或尚未就绪的端点可能继续存在；publishNotReadyAddresses 等配置还会改变就绪发布语义，消费方必须按条件处理。无 selector 的 Service 也可手工管理端点。数据面由 kube-proxy 的 iptables/IPVS 等实现，或由 CNI/eBPF 方案接管，将 ClusterIP/NodePort 流量负载到合格端点。Service 本身不是进程，不“监听”ClusterIP，因此在节点上用普通 ss 找不到监听并不异常。

排障应分对象与数据面：确认 selector、EndpointSlice 的 ready/serving/terminating、地址族与端口，再在客户端验证 DNS、路由/规则、连接追踪与后端监听。externalTrafficPolicy: Local 可保留源 IP并减少跳转，但没有合格本地 endpoint 的节点不会转发，负载均衡健康检查必须匹配；session affinity 与长连接也会造成流量不均。双栈集群还要核对客户端地址族与 EndpointSlice addressType，避免只验证 IPv4 路径。

实践经验

复合场景中，Service DNS 与 ClusterIP 正常，却间歇连接拒绝。EndpointSlice 显示旧版本 Pod 被自定义 readiness gate 错误标为 Ready，而应用尚未监听。止血是修正 gate 状态、摘除坏端点并暂停发布；长期把端点可用性与监听验证纳入控制器测试，并监控每端点失败率。直接手工删 EndpointSlice 会被控制器重建，只适合极短时且须同步修复来源。

面试回答要点

Ingress 与 Gateway API 的职责边界是什么，如何诊断 502/504？¶

技术说明

Ingress 是 HTTP(S) 路由 API，实际能力由 ingress controller 实现，注解也常带实现耦合。Gateway API 用 GatewayClass、Gateway、Listener、Route 等分离基础设施所有者与应用路由所有者，并提供更明确的绑定与状态条件；两者都不自动提供实现，必须有控制器把声明转为负载均衡器/代理配置。TLS 终止、重加密、源 IP 与健康检查语义应逐跳说明。

502 往往表示代理无法获得有效上游响应，如连接拒绝、重置、协议不匹配；504 常表示连接/响应超时，但具体含义以控制器日志为准。诊断按客户端→外部 LB→网关代理→Service/EndpointSlice→Pod 分段，比较 request ID、响应来源、各跳超时、重试与连接池。上游超时必须小于下游总体 deadline，并为重试保留预算。

实践经验

复合场景中，上传接口出现 504，应用日志中请求最终成功。网关 access log 显示 60 秒 upstream timeout，而应用 p99 已到 70 秒，客户端又自动重试，产生重复写。止血是暂停重试、临时提高有界超时并用幂等键保护写入；长期把大任务改异步，统一端到端 deadline 和取消传播。提高超时会占用连接与 worker，不能替代容量/协议设计。

面试回答要点

CNI 与 NetworkPolicy 分别负责什么，为什么写了策略仍可能不生效？¶

技术说明

CNI 是运行时调用的网络配置接口与插件约定，负责为 sandbox 分配地址、创建接口/路由并返回结果；集群网络方案还可能实现 overlay、路由、IPAM 与 Service 数据面。NetworkPolicy 是 Kubernetes 的意图 API，只有网络插件支持并启用策略执行时才会生效。策略通常对被 selector 选中的 Pod 在指定方向形成隔离，再以 allow 规则白名单放行；它不是按规则顺序处理的传统防火墙。

策略是可加性的，ingress 与 egress 在两端分别判定；空 selector、namespaceSelector 与 podSelector 的组合语义容易误写。DNS、监控、控制面、镜像/外部依赖都需显式考虑。验证不能只看对象已创建，应从受控源 Pod 发起正反测试，检查插件 policy 状态和丢包指标；hostNetwork、节点流量和不同插件扩展语义也可能超出标准边界。

实践经验

复合场景中，团队部署 default-deny 后业务仍可跨 namespace 访问，后来发现开发集群使用的基础 CNI 不执行 NetworkPolicy。API 接受对象造成了虚假安全感。止血是在边界防火墙限制敏感端点并暂停租户上线；长期将策略能力列为集群验收项，CI 做允许/拒绝探测和数据面审计。迁移到支持策略的 CNI 需滚动节点并评估连接中断。

面试回答要点

CoreDNS 解析链路和 Kubernetes DNS 常见故障如何排查？¶

技术说明

Pod 通常从 kubelet 注入的 /etc/resolv.conf 指向集群 DNS Service；CoreDNS 的 kubernetes 插件根据 Service、EndpointSlice 与 namespace 生成记录，未知域再按 Corefile 转发上游。搜索域与 ndots 会让短名称产生多次查询；headless Service 返回端点地址，普通 Service 返回 ClusterIP。DNSPolicy、hostNetwork 和自定义 dnsConfig 会改变这条链路。

排障从 Pod 内 resolv.conf、目标 FQDN 的 A/AAAA/SRV 查询开始，验证 DNS Service endpoint、CoreDNS 日志/延迟/缓存、到上游的网络策略与 conntrack。间歇 5 秒延迟常涉及查询重试、上游丢包、UDP/TCP fallback 或搜索域放大，不能一概归因 CoreDNS CPU。指标应包括 request rate、rcode、forward latency、cache hit 和每节点路径。若部署节点本地 DNS 缓存，还需分别验证本地代理到集群 DNS 与上游两段，避免层次遗漏，并检查负缓存是否延长恢复及影响范围。

实践经验

复合场景中，应用外部域名解析偶发 5 秒停顿。抓包显示每次先查询多个搜索域，UDP 回包在节点 conntrack 压力下丢失，随后重试成功。止血是扩 CoreDNS、降低连接追踪压力并让关键外部地址使用尾点 FQDN；长期优化 ndots/search、节点 conntrack 容量与 DNS SLO。缩短搜索列表可能影响依赖短名称的旧应用，需先盘点。

面试回答要点

Service Mesh 的 sidecar/ambient 数据面带来哪些收益与故障面？¶

技术说明

Service Mesh 将服务间身份、mTLS、路由、重试、遥测和策略下沉到代理数据面，由控制面分发配置。sidecar 模式为每个 Pod 注入代理并通过 iptables/eBPF 截获流量；ambient 等模式把部分能力移到节点/共享代理，减少每 Pod 开销，但信任边界、L7 能力与故障半径不同。Mesh 不会自动修复应用的幂等性、超时或容量设计。

引入后需观察应用、入站代理、出站代理、控制面和证书链多层状态。重试与超时若同时由 SDK、ingress、mesh 配置，会呈指数放大；代理资源不足会表现为应用 CPU 看似正常但请求排队。升级要考虑控制面/数据面版本兼容、证书轮换、排除端口与启动顺序，并保留绕过/回退路径。

实践经验

复合场景中，支付下游抖动时，客户端库重试 2 次、sidecar 又重试 2 次，单请求最多放大至 9 次，故障迅速扩大。trace 与代理统计显示多层 attempt。止血是关闭 mesh 对写请求的重试、限流并保护下游；长期统一 retry ownership、传播 deadline 和幂等键，建立重试预算。减少重试会暴露更多瞬时失败，需用熔断和明确错误处理替代。

面试回答要点

PV、PVC、StorageClass 与动态供给的绑定流程是什么？¶

技术说明

PVC 描述 namespace 内的容量、访问模式和 StorageClass 需求；PV 是集群级存储资源及其能力；StorageClass 指定 provisioner、参数、回收策略、绑定模式和扩容能力。动态供给时，外部 provisioner 观察 PVC 并调用存储后端创建卷，再生成/绑定 PV。Immediate 可能在 Pod 调度前就选定故障域，WaitForFirstConsumer 会等待 Pod 约束后再供给，减少卷与节点拓扑冲突。

访问模式是调度/挂载能力声明，不等于应用并发写入一定安全；RWO、RWX 等实际语义取决于驱动和挂载方式。PV reclaim policy 为 Delete 或 Retain 会影响 PVC 删除后的数据命运，但不替代备份。排查 Pending PVC 要看 provisioner 事件、配额、参数和后端；Pod 挂卷失败还需检查 attach、mount、节点插件与故障域。绑定后的 StorageClass 等核心属性通常不能随意修改，迁移应新建卷并校验数据。

实践经验

复合场景中，PVC 用 Immediate 在 zone A 创建，而 Pod 因 GPU 只能进 zone B，导致长期 Pending。事件分别显示卷 node affinity conflict 与节点约束。止血是新建采用 WaitForFirstConsumer 的 StorageClass 和 PVC，经过应用一致性复制后切换；长期按工作负载拓扑提供类目并做准入提示。迁移卷会产生停机或双写复杂度，不能简单修改已绑定卷的类别。

面试回答要点

CSI 的 provision、attach、mount、扩容和快照分别在哪一层完成？¶

技术说明

CSI 将存储能力暴露给编排器。controller 侧组件通常负责 Create/DeleteVolume、ControllerPublish（attach）、快照和部分扩容；每节点的 node plugin 负责 NodeStage/NodePublish，把设备准备并挂载到 Pod 路径。external-provisioner、attacher、resizer、snapshotter 等 sidecar 观察 Kubernetes 对象并调用驱动。不是所有后端都需要 attach，也不是每个驱动都支持在线扩容、快照或多节点写入，应以 CSIDriver/StorageClass 与驱动能力为准。

PVC 扩容通常先扩后端卷，再扩文件系统；需 StorageClass 允许扩容且文件系统/驱动支持，缩容通常不受支持。VolumeSnapshot 是控制面对象和后端快照的映射，一致性可能只是 crash-consistent；数据库应先 quiesce 或使用应用原生备份。故障定位要区分 provision、attach、stage、publish，查看 PVC/PV、VolumeAttachment、Pod events、controller 与 node plugin 日志。

实践经验

复合场景中，节点故障后 StatefulSet 新 Pod 报 multi-attach，旧节点状态未及时清理，云盘仍显示附着。证据是 VolumeAttachment 与云 API 一致指向旧节点。止血先确认旧节点彻底下线并执行 fencing，再通过受控流程解除旧 attach；长期自动核对节点生命状态、存储 attach 超时与 fencing，演练区故障。强制 detach 若旧主机仍可写会造成双写和文件系统损坏，绝不能只为加快恢复直接操作。

面试回答要点

Kubernetes 上运行数据库时，如何处理存储延迟、quorum 与故障转移？¶

技术说明

数据库可靠性来自数据库协议与存储特性共同作用，不来自 StatefulSet 标签。需要明确复制模式、quorum、写确认、故障检测、leader fencing、WAL/日志持久化和复制滞后；存储要验证 fsync 语义、尾延迟、IOPS/吞吐、队列深度、故障域与恢复时间。平均延迟正常但 fsync p99 抖动，仍会直接拉高事务提交和选举稳定性。

跨可用区复制可抗单区故障，却增加同步写 RTT；单区块卷即便有后端冗余，也不必然可跨区立即挂载。故障转移应先证明旧 leader 不能继续写，再提升满足数据完整性条件的副本。运维侧应监控 replication lag、quorum members、checkpoint/WAL、磁盘饱和与实际 RPO，备份则需在独立故障域恢复验证。

实践经验

复合场景中，存储尾延迟升高导致心跳超时，自动化连续选主，应用出现短暂双主保护性停写。证据显示 CPU 正常，但 fsync p99 和复制 apply lag 同时激增。止血是暂停自动故障转移、限写并迁移最慢卷上的副本；长期以存储尾延迟触发降载而非盲目选主，校准选举超时并增加跨区副本。放宽超时减少误切换，但会延长真实故障检测时间。

面试回答要点

Kubernetes RBAC 的鉴权链和最小权限设计方法是什么？¶

技术说明

认证得到 user/group 后，authorization 判断某个 verb、resource、subresource、namespace/name 是否允许。Role/ClusterRole 定义规则，RoleBinding 可在 namespace 内绑定 Role 或 ClusterRole，ClusterRoleBinding 则授予集群范围。规则是纯允许、可加性，没有显式 deny；get pods 不等于 get pods/log，create pods、bind/impersonate/escalate 及读取 Secret 都可能形成权限提升路径。

最小权限从真实操作清单与命名空间边界出发，优先 RoleBinding，资源名可固定时用 resourceNames，但需理解 list/watch 等限制。用 kubectl auth can-i --as ... 做正负验证，结合审计日志发现未使用和异常权限。聚合 ClusterRole、通配符与 CRD 新增资源会扩大未来权限，生产不宜把 * 作为便捷方案。权限回收还要检查所有 binding 与 group 继承，删除一条 RoleBinding 不一定消除等价授权路径，需做反向验证。

实践经验

复合场景中，CI 服务账号只有 namespace 内 Pod 创建权限，却可创建挂载高权限 ServiceAccount token 的 Pod，间接读取 Secret。审计日志串联 create Pod 与随后 secret get。止血是撤销 token、停用 CI 账号并删除异常 Pod；长期为 runner 使用独立 namespace、限制可选 serviceAccountName、关闭默认 token 挂载并加准入策略。更严格的创建约束会影响合法部署模板，需要提供受审计的替代路径。

面试回答要点

ServiceAccount token 应如何签发、挂载和轮换？¶

技术说明

现代 Kubernetes 工作负载应使用 TokenRequest 投射的短期、受 audience 和 expiration 约束的 ServiceAccount token，kubelet 负责轮换投射文件；应用需重新读取 token 或由客户端库处理更新。旧式长期 Secret token 暴露窗口更大，不应作为默认。Pod 不访问 API 时设置 automountServiceAccountToken: false，访问外部云服务则优先使用 workload identity/federation，而非静态云密钥。

token 的权限来自绑定到 ServiceAccount 的 RBAC，删除 Pod 不一定立刻消除已泄露 token 的全部风险，仍需关注有效期、audience 和签名密钥。Projected volume 还可把 token 与 CA、downward API 组合。审计要记录 SA、源 Pod/节点、verb/resource，检测跨 namespace 异常访问；应用不得把 token 写入日志、core dump 或构建制品。轮换是文件内容更新，长期缓存启动时字符串的旧客户端可能继续使用过期 token，必须验证 reload 行为。

实践经验

复合场景中，一个诊断 endpoint 返回环境与挂载文件片段，泄露了长期 SA token；攻击者数周后仍能调用 API。止血是撤销相关绑定、轮换签名/长期凭证并隔离应用；长期改用短期 projected token、关闭非必要挂载和响应脱敏，加入凭证泄露扫描。缩短有效期要求客户端正确刷新，旧 SDK 需先兼容测试。

面试回答要点

Pod Security Standards 的 Privileged、Baseline、Restricted 如何落地？¶

技术说明

Pod Security Standards 定义三个累进安全档位：Privileged 基本不限制；Baseline 阻止已知高风险配置；Restricted 强制更严格的非 root、seccomp、capability 等要求。内置 Pod Security Admission 可按 namespace label 分别设置 enforce、audit、warn 及对应版本。它检查 Pod 安全上下文与宿主能力，但不替代镜像信任、NetworkPolicy、RBAC 或运行时威胁检测。

落地应先 audit/warn 盘点，按 namespace 与工作负载分类修复，再启用 enforce；系统组件、CNI/CSI、节点代理往往确需更高权限，应放专门 namespace、限制写权限和镜像来源，而不是全局豁免。版本标签可固定策略版本以防升级时语义意外变化，但也要建立跟随升级评估流程。例外需记录 owner、理由、替代控制和到期时间，并持续核对是否仍被实际使用。

实践经验

复合场景中，团队直接对全环境启用 Restricted，日志 DaemonSet 因 hostPath 和 hostPID 被拒，节点日志出现盲区。止血是仅对受控系统 namespace 使用精确例外并恢复代理；长期先用 audit 生成违规清单，为节点组件独立策略和所有者，再逐 namespace enforce。例外会形成高价值攻击面，必须配签名、RBAC 和变更审计。

面试回答要点

Validating/Mutating Admission 与策略即代码如何安全使用？¶

技术说明

准入位于认证授权之后、对象写入 etcd 之前。Mutating admission 可注入/默认字段，之后 Validating admission 拒绝不合规对象；webhook 通过 AdmissionReview 调用外部服务，内置 ValidatingAdmissionPolicy 可用表达式完成部分校验。Mutation 应可预测、幂等并避免多个 webhook 顺序耦合；验证策略要输出可操作错误，而不是笼统拒绝。

webhook 自身处于 API 写路径，failurePolicy、timeoutSeconds、namespace/object selector、matchPolicy 和副本拓扑决定故障半径。安全关键拒绝通常倾向 fail-closed，但必须有高可用与 break-glass；非关键增强可 fail-open。上线策略应先 audit/dry-run、回放现有对象、金丝雀 scope，并监控延迟、错误与拒绝率，防止一条正则让整个集群无法创建 Pod。准入不应执行长耗时外部查询，必要数据应预缓存并定义陈旧时的安全行为。

实践经验

复合场景中，镜像校验 webhook 的证书过期且 failurePolicy=Fail，所有新 Pod 创建被拒，包括 webhook 自身替换 Pod。API 审计与 webhook TLS 错误锁定根因。止血按预案临时缩小 webhook 匹配范围并恢复证书，而非长期 fail-open；长期采用独立证书告警、冗余副本、跳过自身 namespace 和离线策略回放。break-glass 会削弱控制，必须限时并完整审计。

面试回答要点

Kubernetes Secret 的保护边界和加密方案是什么？¶

技术说明

Secret 的 base64 只是编码；对象默认经 API 存入 etcd，是否静态加密取决于 API server encryption configuration 与 KMS provider。还要保护 etcd 备份、API 访问、审计日志、节点上的投射文件和能创建 Pod 的间接读取路径。静态加密只解决存储介质泄露，不解决拥有 get secrets 权限或已攻陷工作负载读取明文。

更成熟方案以外部 secret manager 为源，通过 CSI、operator 或应用直取分发短期凭证，并使用 workload identity。需明确同步副本是否又落回 Kubernetes Secret、轮换后应用如何 reload、失败时缓存多久。Git 中应存加密密文或引用，密钥与密文分离；任何方案都需要版本、审计、吊销与泄露响应。

实践经验

复合场景中，etcd 备份被复制到权限过宽的对象桶，虽生产 API RBAC 严格，离线备份仍含未加密 Secret。访问日志证实异常下载。止血是吊销所有受影响凭证、封锁桶并保存取证；长期启用 KMS 静态加密、备份独立加密键与不可变访问策略，定期恢复后检查密文。大规模轮换会触发连接重建，应分批并监控依赖容量。

面试回答要点

多租户 Kubernetes 集群如何划分软隔离与硬隔离？¶

技术说明

namespace、RBAC、ResourceQuota、LimitRange、NetworkPolicy、Pod 安全准入和节点池可组成软多租户边界，适合有共同组织信任基础的团队。它们分别限制 API、资源、网络与运行权限，但共享控制面和内核。对互不信任租户、强合规、不同数据主权或任意代码执行，应使用独立集群/账号，或更强沙箱与专用节点，减少共享故障域。

控制面层还需限制 API priority/fairness、防止 CRD/webhook 等集群级资源被租户控制，并治理 ClusterRoleBinding、namespace 创建和节点标签。成本分摊、配额和突发容量必须与 SLO 配套：硬配额能防 noisy neighbor，也可能让关键发布因配额不足失败。租户 offboarding 要删除身份、网络、数据与外部云资源，而非只删 namespace。

实践经验

复合场景中，一个团队批量 list/watch 大型自定义资源，API server 延迟上升影响全体发布；CPU/内存 quota 对此无效。审计与 APF 指标显示该身份占用大量 seats。止血是限流该客户端并暂停其控制器；长期配置 API priority/fairness、客户端分页/退避与租户 API 预算。更严限流会延长控制器收敛，需按关键性分类。

面试回答要点

Kubernetes 集群升级应如何规划兼容性、顺序与回退？¶

技术说明

升级前应阅读目标版本 release notes 与 version skew policy，扫描已移除/弃用 API，验证 CRD conversion webhook、准入、CNI/CSI、ingress、metrics、备份和所有 add-on 的兼容矩阵。通常先升级控制面，再按支持的偏差范围升级节点与 kubelet；托管集群仍需自行验证插件、工作负载与 API 客户端，不能把供应商成功按钮当成应用验证。

节点池采用 canary 后分批 cordon/drain/替换，检查 PDB、容量、卷与长连接；控制面数据先备份并完成恢复演练。回退边界要现实：控制面/etcd schema 与云托管服务未必支持直接降级，常见回退是停止批次、把工作负载移回旧节点池或从备份重建。升级门禁应以 API 错误、调度、网络、存储和业务 SLI 决定。

实践经验

复合场景中，控制面升级后旧 admission webhook 读取了已变化的对象字段并返回 500，发布受阻。预生产只测了基础 Pod，未覆盖该 CRD。止血是停止节点升级、回退 webhook 版本/缩小匹配范围并恢复发布；长期建立 API 使用清单、真实对象回放和 canary 集群。保留旧节点池会短期增加成本，但提供更可行的数据面回退。

面试回答要点

etcd 备份恢复为何不是简单复制文件？¶

技术说明

etcd 是强一致键值库，Kubernetes 所有持久对象依赖它。应使用受支持的 snapshot 方法从健康 member 获取一致快照，并记录集群版本、revision、hash、证书和加密配置；直接复制正在运行的数据目录可能得到不一致内容。快照包含 Secret 等敏感数据，必须加密、严格授权并复制到独立故障域。

恢复通常是灾难操作：用 snapshot restore 创建新的 member 数据目录/集群身份，再按控制面方案启动并验证；恢复到旧 revision 还可能使 informer/watch 缓存对对象版本产生混淆，某些流程需要 revision bump 等受支持措施。恢复后要核对 member 健康、API 资源、控制器收敛、节点租约、外部云资源差异与 Secret 解密，而不是看到 apiserver 200 就宣告完成。

实践经验

复合场景中，误删大量对象后团队恢复昨夜快照，API 虽启动，但云负载均衡器和卷已在外部变化，控制器开始删除/重建资源。止血是先冻结破坏性控制器与云自动化，在隔离环境恢复并生成差异，再分资源重建；长期建立对象级恢复与全库恢复的决策树、小时级快照和季度演练。全库回退会丢失快照后的合法变更，通常爆炸半径大于定点修复。

面试回答要点

API server 延迟升高或控制面不可用时如何诊断？¶

技术说明

先区分客户端路径、API server 自身、admission、etcd 与依赖认证服务。客户端查看 DNS/TCP/TLS、HTTP 状态、apiserver flow-control headers；服务端关注请求率、按 verb/resource 的延迟与错误、inflight、APF queue/reject、webhook latency、etcd request/commit/fsync latency。kubectl 超时不代表控制面全挂，应测试 /readyz?verbose 并从不同网络位置验证。

高基数 list、无分页客户端、watch 频繁重连、大对象/事件风暴、慢 webhook 和 etcd 磁盘尾延迟都可能造成级联。事故中先冻结非关键部署/控制器、限制问题身份，保护 leader election 与节点心跳等关键流量；不应一上来重启所有控制面，因为会丢掉对比证据并放大选举。修复后验证 watch 恢复、调度收敛和业务状态，而非只看 API QPS。

实践经验

复合场景中，平台控制器 bug 每秒全量 list Secret，APF 队列增长，发布和节点租约更新变慢。审计日志按 userAgent 聚合后锁定来源，etcd fsync 正常，排除了存储。止血是缩容该控制器并给其低优先级限流；长期改为 informer/watch、分页和指数退避，设置租户 API 预算。限流可能延迟平台对象收敛，因此关键控制器应使用独立优先级配置。

面试回答要点

Pod Pending 的系统化排查顺序是什么？¶

技术说明

Pending 表示 Pod 尚未完成启动，可能根本未调度，也可能已绑定节点但镜像、sandbox、网络或卷尚未准备。先看 spec.nodeName 和 conditions/events：未绑定时检查资源 request、taint/toleration、affinity/spread、端口、PVC 拓扑、配额与 scheduler；已绑定时检查 kubelet、CRI、CNI、CSI、镜像拉取和 sandbox 状态。按阶段分类比背诵错误列表更可靠。

资源不足要看 request 与 allocatable/已分配，不是节点实时利用率；autoscaler 不扩容可能是约束无法由任何节点池满足、达到上限或 Pod 未被识别为可扩。events 有聚合和过期，重要事故应及时收集 scheduler 日志/指标。任何放松约束的应急动作都要说明会损失何种隔离、拓扑或性能保证。

实践经验

复合场景中，GPU Pod Pending，监控显示节点 GPU 空闲。scheduler event 显示 Pod 同时请求一个不存在的 extended resource 名称，是设备插件升级后资源键变化。止血是回滚工作负载资源键并暂停插件升级；长期对节点 advertised resources 与模板做契约测试，升级设备插件先 canary。强行删 request 虽可调度，却会让程序找不到设备或争用，不能作为止血。

面试回答要点

CrashLoopBackOff 应如何区分应用、配置与平台问题？¶

技术说明

CrashLoopBackOff 表示容器反复退出后 kubelet 延迟重启，它是现象而非原因。查看 current/last container state、exitCode、signal、reason、restartCount，读取 logs --previous；退出 0 也可能因为长驻容器入口脚本错误立即完成。再核对 command/args、环境、Secret/ConfigMap、挂载、权限、依赖、探针，以及节点 OOM/磁盘/运行时事件。

137 常与 SIGKILL/OOM 相关但不是唯一解释，143 常见于 TERM，也不能只按数字定案。若进程来不及输出，可使用临时调试容器、core dump 策略或在等价副本运行入口；不要直接修改生产容器破坏证据。区分 liveness 触发重启、应用自行退出、cgroup OOM 与节点压力后，止血方向完全不同。

实践经验

复合场景中，新版本全部 CrashLoop，日志为空，lastState exit 1。检查 PodSpec 发现只读根文件系统启用后，应用仍在 /app 写 PID 文件。止血是回滚并为特定 /run 挂 emptyDir，而非取消全部安全基线；长期启动测试在 Restricted 配置下运行，并让应用输出结构化启动阶段错误。增加临时卷需要 sizeLimit 和清理策略，避免转为磁盘压力。

面试回答要点

Pod 间网络不通时怎样用分层方法定位？¶

技术说明

先明确源、目的、端口、协议、时间窗与是否跨节点，再分别测试：应用是否监听正确地址；目的 Pod IP 直连；Service VIP；DNS 名称；入口网关。检查源/目的 network namespace 的路由和接口、NetworkPolicy 双向允许、EndpointSlice readiness、节点转发/conntrack、CNI 路由或隧道与底层网络。每一步只改变一个变量，才能定位断层。

连接超时、拒绝、reset 与 TLS 错误证据不同：拒绝通常说明到达无监听端口，超时可能是丢弃或回程问题。跨节点失败而同节点正常优先看 CNI/底网/MTU；仅 Service 失败看数据面与端点；仅名称失败看 DNS。抓包至少在源 Pod、源节点、目的节点/Pod关键点对齐时间和五元组，避免把重传误判为新请求。

实践经验

复合场景中，只有从新节点池到旧节点池的 Pod 流量超时。路由表正确，源节点抓到封装包，目的节点未收到；云网络流日志显示新子网安全规则未放行 overlay UDP。止血是精确开放节点子网间所需端口并限制来源；长期将 CNI 端口矩阵写入 IaC 与新节点池合成测试。临时全开安全组会扩大横向移动面，不应接受为永久修复。

面试回答要点

NodeNotReady、压力驱逐和节点故障应如何处置？¶

技术说明

NodeNotReady 可能来自 kubelet/容器运行时停止、节点网络到控制面中断、内核/硬件故障或资源饥饿。查看 Node conditions（Ready、Memory/Disk/PIDPressure）、lease/heartbeat 时间、kubelet/runtime/journal、系统 CPU/内存/磁盘/inode/PID、网络与云实例状态。控制器在容忍窗口后可能驱逐/替换 Pod，但有状态卷与无法访问控制面的孤岛节点需要额外 fencing。

处置先 cordon 隔离新调度，确认节点是否仍在提供流量和写数据；可通信且健康时用 drain 尊重 PDB，硬故障则按业务 RTO 和存储安全进行强制替换。磁盘压力要区分 nodefs/imagefs、日志、镜像与 deleted-open 文件；内存压力要看 PSI 和系统预留。重启可止血但会丢证据，采样后分批执行。

实践经验

复合场景中，多节点先 DiskPressure 后 NotReady，df 容量尚有余量，但 inode 已耗尽，原因是应用产生数百万小临时文件。证据来自 inode 使用、container writable layer 与 kubelet事件。止血是 cordon、停止异常工作负载并安全清理其明确目录，逐节点恢复；长期改聚合文件格式、emptyDir 限额和 inode 告警。清理 open 文件可能不释放空间，贸然重启会造成容量骤降，需按节点分批。

面试回答要点