主题
模拟面试题深度详解（6 轮 25 题）
每轮模拟面试包含 4-5 道题，模拟真实面试场景。每题给出完整答题思路、技术原理、参考答案、追问预判。
第一轮：基础能力验证（4 题）
M1: 描述 K8s 集群的整体架构，各组件如何协同工作
面试官意图： 考察候选人对 K8s 架构的全局理解深度。
答题框架：
第一层：组件列举（30 秒）
控制平面 4 个 + 节点 3 个
第二层：协同流程（1 分钟）
选一个场景串联：如"用户执行 kubectl apply 创建 Deployment"
kubectl → apiserver（认证授权准入）→ etcd 写入
→ Deployment Controller Watch 到变更 → 创建 ReplicaSet
→ ReplicaSet Controller Watch → 创建 Pod
→ Scheduler Watch 到未调度 Pod → 调度到节点
→ kubelet Watch 到分配到本节点的 Pod → CRI 创建容器
→ kube-proxy Watch → 更新 iptables/IPVS 规则
第三层：深入设计（如果面试官追问）
Level-triggered 设计、Informer 机制、Leader Election完整参考答案（A 级，2 分钟）：
K8s 由控制平面和节点组成。控制平面核心是 apiserver（唯一 API 入口，处理认证→授权→准入），etcd（唯一状态存储，Raft 共识保证一致性），controller-manager（运行各种 Reconciliation Loop），scheduler（Pod 调度）。节点上 kubelet 管理 Pod 生命周期，kube-proxy 管理 Service 规则，containerd 是容器运行时。所有组件通过 apiserver 通信，apiserver 是唯一读写 etcd 的组件。Controller 通过 Informer 机制 Watch apiserver 变更，使用 Level-triggered 设计，只看当前状态和期望状态的差异。
常见追问及应对：
Q: apiserver 如果挂了会怎样？ A: apiserver 多实例部署（3+），前置 LB。单个 apiserver 挂了，LB 自动切到其他实例。如果全部挂了，控制平面不可用，但已运行的 Pod 不受影响（kubelet 独立运行，已有容器继续运行）。
M2: ClusterIP、NodePort、LoadBalancer 三种 Service 类型的区别
完整参考答案（A 级）：
ClusterIP 是默认类型，只在集群内部可访问，kube-proxy 通过 iptables/IPVS 规则实现流量转发到后端 Pod。NodePort 在每个节点上暴露一个端口（默认 30000-32767），外部可以通过任意 NodeIP:NodePort 访问。LoadBalancer 类型在支持云厂商的平台上自动创建外部 LB，将外部流量路由到 NodePort。三者是递进关系：LoadBalancer = NodePort + 外部 LB，NodePort = ClusterIP + 节点端口。
追问预判：
Q: ExternalTrafficPolicy 的 Cluster 和 Local 区别？ A: Cluster 模式流量被负载均衡到所有节点的后端 Pod（可能跨节点），Local 模式只路由到本节点的 Pod（保留客户端源 IP，但可能负载不均）。
M3: Pod 的生命周期有哪些阶段？探针如何工作？
完整参考答案（A 级）：
Pod 生命周期阶段：Pending（调度中）→ Running（至少一个容器运行中）→ Succeeded（所有容器成功退出）→ Failed（有容器失败退出）→ Unknown（无法获取状态）。探针三种类型：LivenessProbe（存活检查，失败则重启容器）、ReadinessProbe（就绪检查，失败则从 Service 端点移除）、StartupProbe（启动检查，保护慢启动应用）。探针方式：httpGet（HTTP 状态码 2xx/3xx 为成功）、tcpSocket（端口可连接）、exec（命令退出码 0）。
关键细节：
StartupProbe 的作用：
对于启动慢的应用（如 Java 应用首次启动需要 60s），
如果只配 LivenessProbe（initialDelaySeconds: 30），
应用还没启动就被 Liveness 杀掉重启，导致无限重启循环。
解决方案：先配 StartupProbe（failureThreshold: 30, periodSeconds: 2），
允许最多 60s 启动时间。StartupProbe 通过后，Liveness 才开始生效。M4: 如何实现 K8s 的自动伸缩？
完整参考答案（A 级）：
K8s 自动伸缩分三层：1) HPA（Horizontal Pod Autoscaler）基于 CPU/Memory/自定义指标调整 Pod 副本数；2) VPA（Vertical Pod Autoscaler）调整 Pod 的 requests/limits，不能与基于 CPU/Memory 的 HPA 同时使用；3) Cluster Autoscaler 基于 Pending Pod 扩容节点，基于节点利用率缩容节点。生产推荐：HPA（自定义指标如 QPS）+ VPA（Off 模式仅推荐）+ Cluster Autoscaler。
第二轮：网络与安全深度（4 题）
M5: 一个 Pod 访问另一个 Pod 的完整网络路径是什么？
完整参考答案（A 级，VXLAN 模式）：
同节点：Pod A → veth pair → cni0 bridge → Pod B（不离开宿主机）。跨节点：Pod A → veth → 宿主机 A → VXLAN 封装（源 NodeA IP，目标 NodeB IP）→ 物理网络 → 宿主机 B → VXLAN 解封 → veth → Pod B。Service 访问：Pod → ClusterIP → iptables/IPVS DNAT → 后端 Pod IP。BGP 模式无封装，直接路由 Pod IP。
M6: 如何加固一个生产 K8s 集群？给出你的安全清单
完整参考答案（A 级）：
分五层加固：1) 控制平面：apiserver
--authorization-mode=RBAC,Node，etcd 加密 Secret，审计日志开启；2) 节点：kubelet--anonymous-auth=false，Pod Security Standards restricted 级别，禁用特权容器，drop ALL capabilities 按需添加；3) 网络：default-deny NetworkPolicy，mTLS（Service Mesh），Ingress WAF；4) 供应链：Trivy 镜像扫描，Kyverno 限制镜像来源，cosign 签名验证；5) 运行时：Falco 异常行为检测，定期 CIS Benchmark 扫描（kube-bench）。
M7: RBAC 如何设计最小权限？给一个实际案例
完整参考答案（A 级）：
案例：为 CI/CD Pipeline 创建 ServiceAccount，只允许在
productionnamespace 中部署应用：
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: cicd-deployer
namespace: production
rules:
- apiGroups: ["apps"]
resources: ["deployments", "replicasets"]
verbs: ["get", "list", "create", "update", "patch"]
- apiGroups: [""]
resources: ["services", "configmaps"]
verbs: ["get", "list", "create", "update", "patch"]
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"] # 只读，不能 exec
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: cicd-deployer-binding
namespace: production
subjects:
- kind: ServiceAccount
name: cicd-pipeline
namespace: ci-system
roleRef:
kind: Role
name: cicd-deployer
apiGroup: rbac.authorization.k8s.io关键设计点：1) Role（非 ClusterRole），限定在 production namespace；2) 不授予 secrets/pods/exec/nodes 权限；3) verbs 最小化（无 delete）；4) 验证：
kubectl auth can-i create deployments --as system:serviceaccount:ci-system:cicd-pipeline -n production。
M8: 容器逃逸的原理和防御方案
完整参考答案（A 级）：
逃逸原理：攻击者利用容器隔离的弱点突破 namespace/cgroup 边界获取宿主机权限。常见方式：1) 内核漏洞（Dirty COW）；2) privileged 模式（直接访问宿主机设备）；3) 挂载宿主机根目录（
hostPath: /）；4) Docker socket 挂载（创建特权容器）。防御：1) Pod Security Standards restricted 级别；2) drop ALL capabilities + 按需添加；3) readOnlyRootFilesystem: true；4) Seccomp Profile 限制系统调用；5) gVisor/Kata Containers 提供 VM 级别隔离；6) distroless 基础镜像减少攻击面。
第三轮：存储与调度（4 题）
M9: PV/PVC 绑定失败怎么排查？
完整参考答案（A 级）：
排查步骤：1)
kubectl get pv检查 Available 的 PV 容量和 accessModes；2)kubectl describe pvc查看 Events 中的错误信息；3) 检查 storageClassName 是否匹配；4) 检查 accessModes（如 ReadWriteMany 需要支持多节点读写的 CSI）；5) 检查 nodeAffinity（Local PV 需要匹配节点标签）；6) 动态供给时检查 StorageClass 的 Provisioner 日志。最常见原因：容量不匹配、storageClassName 不一致、accessModes 不兼容。
M10: 如何在 K8s 上运行 MySQL 集群？
完整参考答案（A 级）：
方案：StatefulSet + volumeClaimTemplates + Headless Service + Operator。关键设计：1) 每个 MySQL Pod（mysql-0/1/2）绑定独立 PVC（Local PV 高性能 或 Rook-Ceph 分布式）；2) Headless Service 提供稳定 DNS（mysql-0.mysql.default.svc.cluster.local）；3) mysql-0 为主节点，mysql-1/2 为从节点，通过 GTID 复制；4) ReadinessProbe 检查从节点同步状态；5) PDB 确保不同时驱逐多个 MySQL Pod；6) 定期 VolumeSnapshot + 异地备份。生产建议优先使用云厂商托管数据库。
M11: GPU 调度的限制和 vGPU 方案
完整参考答案（A 级）：
原生 GPU 调度限制：1) 只能请求整数个 GPU（不能共享）；2) GPU 不支持超卖；3) 无 GPU 拓扑感知（可能把需要 NVLink 连接的 GPU 分配到不同节点）。vGPU 方案：HAMi 支持显存和算力两个维度切分，将一块 GPU 分为多个虚拟 GPU，提高利用率。MIG（Multi-Instance GPU）是 NVIDIA 官方方案，将 A100 切分为 1g/2g/3g/7g 四种规格。生产建议：训练任务用整卡（性能优先），推理服务用 vGPU 共享（成本优先）。
M12: 调度器如何决定把 Pod 放到哪个节点？
完整参考答案（A 级）：
调度器流程：PreFilter → Filter → PostFilter → PreScore → Score → Reserve → Permit → PreBind → Bind。Filter 阶段排除不可用节点（资源不足、Taint 不匹配、NodeSelector 不满足）。Score 阶段对剩余节点打分（LeastAllocated 优先选资源多的节点、InterPodAffinity 优先选亲和 Pod 所在节点、BalancedAllocation 优先选资源均衡的节点）。选择得分最高的节点绑定 Pod。可通过 nodeAffinity、podAffinity/podAntiAffinity、Taint/Toleration 影响调度决策。
第四轮：故障排查实战（5 题）
M13: Pod 一直 Pending 怎么排查？
完整参考答案（A 级）：
kubectl describe pod查看 Events。常见原因：1) 资源不足（Insufficient cpu/memory）→ 扩容节点或降低 requests；2) 没有匹配的 PV（pod has unbound immediate PersistentVolumeClaims）→ 检查 PV 可用性和 StorageClass；3) Taint/Toleration 不匹配 → 检查节点 Taint；4) nodeAffinity/nodeSelector 不满足 → 检查节点标签；5) 调度器配置问题 → 检查 kube-scheduler 日志。
M14: 节点 NotReady 的排查步骤
完整参考答案（A 级）：
排查步骤：1)
kubectl describe node <node>查看 Conditions（Ready=False 的时间和原因）；2) SSH 到节点检查 kubelet 状态（systemctl status kubelet+journalctl -u kubelet -f）；3) 检查节点资源（CPU/Memory/Disk/Inode）；4) 检查 CNI 插件状态（/var/log/cni/日志）；5) 检查容器运行时（crictl ps）；6) 检查网络连通性（ping apiserver、ping 其他节点）。常见原因：kubelet 崩溃、磁盘满、CNI 异常、容器运行时卡死。
M15: 集群内 DNS 解析失败怎么排查？
完整参考答案（A 级）：
排查步骤：1) 在 Pod 内
nslookup kubernetes.default测试 DNS；2)kubectl get pods -n kube-system -l k8s-app=kube-dns检查 CoreDNS Pod 状态；3)kubectl logs -n kube-system <coredns-pod>检查 CoreDNS 日志；4) 检查 CoreDNS Service（ClusterIP 是否为 10.96.0.10）；5) 检查 Pod 的/etc/resolv.conf（nameserver 是否指向 CoreDNS）；6) 检查 NetworkPolicy 是否阻断了 DNS 端口（53/UDP）。
M16: 应用更新后出现间歇性 502 错误
完整参考答案（A 级）：
这是典型的零停机部署配置问题。排查：1) 检查 Deployment 的滚动更新策略（是否设置 maxUnavailable: 0）；2) 检查是否配置了 preStop Hook（
exec: command: ["sleep", "5"]）；3) 检查 ReadinessProbe 是否正确配置；4) 检查 terminationGracePeriodSeconds 是否足够。根因：Pod 终止时，kube-proxy 更新 iptables/IPVS 规则有 1-3 秒延迟，期间新请求仍可能路由到正在终止的 Pod。解决：preStop sleep 5s + maxUnavailable: 0 + ReadinessProbe。
M17: 如何排查 etcd 性能问题？
完整参考答案（A 级）：
排查步骤：1)
etcdctl endpoint health检查健康状态；2)etcdctl endpoint status查看 Leader 和 DB size；3) 检查磁盘延迟（fio测试，etcd 要求 fsync < 10ms）；4) 检查 etcd 指标：etcd_disk_wal_fsync_duration_seconds（WAL 写入延迟）和etcd_disk_backend_commit_duration_seconds（后端提交延迟）；5) 检查 DB size，超过 8GB 需要 defrag；6) 检查网络延迟（节点间 RTT）。优化：NVMe SSD、独立磁盘、定期 defrag、--quota-backend-bytes=8GB。
第五轮：架构设计与方案（4 题）
M18: 如何设计一个支持 1000+ 微服务的 K8s 平台？
完整参考答案（A 级）：
平台设计五层：1) 控制平面：etcd 5 节点独立集群 + apiserver 5 实例 + 独立 LB；2) 网络层：Cilium eBPF（替代 iptables）+ Gateway API（替代 Ingress）+ Istio Service Mesh（东西向流量治理）；3) 节点层：按业务域划分节点池（核心服务池 / 通用服务池 / 批处理池）+ Taint/Toleration 隔离；4) 可观测性：VictoriaMetrics + Loki + Tempo（指标/日志/追踪三件套）+ Grafana 统一面板；5) 运维层：ArgoCD GitOps + Cluster API 集群管理 + OPA/Kyverno 策略自动化。
M19: 如何实现跨 AZ 的高可用？
完整参考答案（A 级）：
跨 AZ 高可用设计：1) 控制平面：etcd 3/5 节点分布在不同 AZ；2) 节点层：每个 AZ 至少 3 个节点；3) 应用层：Pod Anti-Affinity（preferredDuringScheduling）跨 AZ 分布 + PDB（minAvailable）；4) 流量层：云厂商多 AZ LB + Gateway API + HPA；5) 存储层：分布式存储跨 AZ 复制（Ceph 三副本分布在不同 AZ）；6) DNS 层：Route53/AlibabaDNS 健康检查 + 故障转移。
M20: 如何设计灰度发布系统？
完整参考答案（A 级）：
灰度发布方案：1) 金丝雀发布（Argo Rollouts）：1% → 5% → 20% → 100% 逐步扩大流量，基于 Prometheus 指标（错误率、延迟）自动决策 Rollback 或 Promote；2) 蓝绿部署：新旧版本并行，100% 切换；3) 流量分割：Gateway API HTTPRoute 的 weight 字段控制流量比例。完整流程：Git push → CI 构建镜像 → ArgoCD Sync → Argo Rollouts 自动灰度 → Prometheus 指标监控 → 自动 Promote/Rollback。
M21: 如何设计 K8s 的多租户隔离方案？
完整参考答案（A 级）：
多租户隔离方案（三层）：1) 控制平面隔离：每个租户独立集群（最强隔离，成本最高）；2) Namespace 隔离：同一集群内，每个租户一个 Namespace，通过 RBAC + ResourceQuota + LimitRange + NetworkPolicy + Pod Security Standards；3) 节点隔离：Taint/Toleration 将租户 Pod 调度到专属节点。生产推荐：重要业务独立集群，一般业务 Namespace 隔离。
第六轮：综合场景与行为面试（4 题）
M22: 描述一次你处理过的最严重的 K8s 生产故障
答题框架（STAR 方法）：
S（Situation）：描述背景（什么集群、什么应用、什么时间）
T（Task）：你的职责是什么
A（Action）：你具体做了什么（排查步骤、解决方案）
R（Result）：结果如何（恢复了没有、事后改进措施）
关键要点：
- 要具体（具体的错误信息、具体的命令、具体的时间线）
- 要展示排查思路（不是直接知道答案，而是如何一步步定位的）
- 要展示复盘能力（事后改进措施）参考示例：
去年双十一前，我们的电商集群（200 节点）突然出现大量 Pod CrashLoopBackOff。排查过程：1) 首先看监控，发现所有微服务的重启次数同时飙升；2)
kubectl logs看到大量数据库连接超时；3) 检查 MySQL 节点，发现连接池被耗尽（max_connections=1000 已用完）；4) 根因是 HPA 自动扩容了 200 个 Pod，每个 Pod 创建 10 个数据库连接，瞬间增加了 2000 个连接；5) 紧急措施：临时提高 max_connections + 缩容部分 Pod；6) 事后改进：引入 PgBouncer 连接池 + HPA 配置最大连接数限制 + 压测验证。
M23: 你如何规划 K8s 的版本升级策略？
完整参考答案（A 级）：
升级策略：1) 保持 N-2 版本策略（生产落后社区 2 个小版本）；2) 升级路径：staging 先升级验证 → prod 灰度升级；3) 升级前检查：废弃 API、CNI/CSI 兼容版本、etcd 快照备份；4) 升级过程：控制平面一次一个小版本 → kubelet 逐节点 cordon+drain+升级+uncordon；5) 回滚方案：etcd 快照恢复 + kubelet 降级；6) 大版本升级关注 API 废弃（如 1.25 移除 PodSecurityPolicy → Pod Security Standards）。
M24: 如何向团队推广 K8s 最佳实践？
完整参考答案（A 级）：
推广策略：1) 自动化强制：OPA/Kyverno 策略自动拦截不符合规范的 YAML；2) 模板化：提供标准化的 Helm Chart 模板和 CI/CD Pipeline 模板；3) 可视化：Grafana Dashboard 展示各团队的资源浪费率、安全合规率；4) 培训：定期 Tech Talk + 内部文档 + 新人 Onboarding 清单；5) 激励机制：月度"最佳 K8s 实践团队"评选；6) 自服务平台：降低使用门槛（开发者无需理解 K8s 细节，只需填写应用配置表单）。
M25: 你认为 K8s 生态未来的发展方向是什么？
完整参考答案（A 级）：
趋势判断：1) Gateway API 逐步替代 Ingress（2025-2026 年完成主流迁移）；2) eBPF 成为标配（Cilium/Tetragon 替代 iptables/Falco）；3) Wasm（WebAssembly）成为容器替代方案（启动快、隔离强、跨平台）；4) AI/ML 工作负载成为 K8s 最大增量场景（GPU 调度、分布式训练、模型服务）；5) 多集群联邦成为常态（Karmada/Admiral）；6) Platform Engineering 理念：K8s 从"开发者直接使用"变为"平台团队封装为内部产品"（如 Backstage + Crossplane）；7) 声明式集群管理（Cluster API）替代脚本化运维。