主题
补充：高级 K8s 运维模拟面试实战
本章模拟真实面试场景，包含 6 轮面试流程和评分标准。适用于面试官参考出题和候选人自测。
面试流程设计
总时长：约 2.5 小时（可拆分为两轮）
第一轮：基础知识筛选（15 分钟）
快问快答，评估知识广度
第二轮：深度技术面试（30 分钟）
追问式深入，考察技术深度
第三轮：故障排查实战（25 分钟）
场景模拟 + 现场操作
第四轮：系统设计（30 分钟）
白板设计，考察架构思维
第五轮：运维工具与生态（20 分钟）
方案讨论
第六轮：行为面试与文化匹配（15 分钟）
STAR 方法第一轮：基础知识筛选
Q1: K8s 控制平面关键组件
B 级回答：
控制平面包括 apiserver、etcd、scheduler、controller-manager。节点上有 kubelet 和 kube-proxy。
A 级： 能描述各组件交互流程 S 级： 能深入 apiserver 请求链（认证→授权→准入）或 etcd Raft
Q2: Pod 三种探针的区别
B 级回答：
Liveness 检测存活，失败重启容器；Readiness 检测就绪，失败从 Service 移除；Startup 用于慢启动。
追问： "Java 应用启动需要 2 分钟，你会怎么配置探针？" S 级： 能给出 StartupProbe failureThreshold=30 + periodSeconds=5 的完整方案
Q3: Service 的几种类型
B 级： ClusterIP / NodePort / LoadBalancer / ExternalName A 级： 能解释 ClusterIP 通过 iptables/IPVS 实现 S 级： 能分析 externalTrafficPolicy: Local 的影响
Q4: RBAC 中 Role 和 ClusterRole 区别
B 级： Role 作用于 namespace，ClusterRole 作用于集群 追问： "ClusterRole 能绑定到特定 namespace 吗？"（能，用 RoleBinding 引用 ClusterRole）
Q5: PV、PVC 和 StorageClass 关系
B 级： PVC 绑定 PV，StorageClass 自动创建 PV 追问： "CSI 和 in-tree volume plugin 有什么区别？"
第二轮：深度技术面试
Q6: 从 kubectl apply 到 Pod Running 的完整流程
S 级期望：
完整描述 apiserver 处理链 → etcd 写入 → Controller Informer → Scheduler 调度框架 → kubelet CRI → kube-proxy 端点更新 → CoreDNS DNS 记录
Q7: IPVS 和 iptables 在大规模场景的差异
关键差异：
- iptables: O(n) 线性匹配，1000 Service 后明显延迟
- IPVS: O(1) 哈希查找，支持 rr/wrr/lc/sh 等负载均衡算法
- IPVS 支持连接保持，iptables 不支持
Q8: etcd 脑裂场景分析
脑裂场景：
- 3 节点集群，网络分区导致 2 个节点互不可见
- 有 Leader 的分区（2 节点）正常处理写入
- 无 Leader 的分区（1 节点）无法写入（无法达成多数派）
- K8s 表现为部分 apiserver 返回 503
预防措施：
- 避免跨高延迟网络部署 etcd
- 使用 etcd learner 节点（不参与投票）第三轮：故障排查实战
Q9: 100 个 Pod 中 30 个 Pending
排查路径：
1. kubectl describe pod <pending-pod>
→ 看 Events（FailedScheduling? FailedMount?）
2. 如果是 FailedScheduling：
→ 检查资源不足（kubectl describe node）
→ 检查污点不匹配
→ 检查亲和性/拓扑约束
3. 如果是 FailedMount：
→ PVC 是否 Bound？
→ CSI 插件是否正常？
4. 检查集群配额（ResourceQuota）Q10: 节点 CPU 100% 但 kubectl top 显示正常
排查路径：
1. kubectl top 只显示容器 CPU，不含 kubelet/kube-proxy/系统进程
2. SSH 到节点，用 top/mpstat 确认
3. 检查 kubelet 日志（PLEG 卡死？）
4. 检查内核态 CPU（perf top / bpftrace）
5. 检查 cgroup 层级是否正确Q11: DNS 解析间歇性失败
排查：
1. CoreDNS Pod 日志（OOM? 过载?）
2. CoreDNS Service 端点数（是否不够？）
3. conntrack 表是否满（nf_conntrack_count vs max）
4. 是否经过 Service ClusterIP（IPVS 模式 conntrack 问题）
5. 解决方案：NodeLocal DNSCache + 增大 conntrack max第四轮：系统设计
Q12: 设计 5000 节点 K8s 集群
答题框架：
控制平面：
- etcd 独立 5 节点集群（NVMe SSD）
- apiserver 3+ 实例前置 LB
- scheduler/controller-manager 各 2 副本（Leader Election）
网络：
- Cilium eBPF（替代 iptables）
- NodeLocal DNSCache
- 分片 Service 网段
节点：
- kubelet --kube-api-qps=50
- --serialize-image-pulls=false
- 按业务域划分 NodePool
可观测性：
- VictoriaMetrics（替代 Prometheus 单机瓶颈）
- 联邦告警Q13: 设计多租户 K8s 平台
隔离层次：
1. Namespace 级别隔离（默认）
2. RBAC 限制每个租户只能访问自己的 Namespace
3. ResourceQuota 限制资源用量
4. NetworkPolicy 隔离网络
5. OPA/Kyverno 强制执行策略
6. 可选：vCluster（虚拟集群隔离）
管理平面：
- 自助服务门户（创建 Namespace、配置配额）
- 审计日志（所有 API 操作记录）
- 成本分摊（Kubecost per namespace）第五轮：运维工具与生态
Q14: Helm vs Kustomize 选择
| 维度 | Helm | Kustomize |
|---|---|---|
| 模板引擎 | Go template（强大但复杂） | 纯 YAML overlay（简单直观） |
| 包管理 | Chart 仓库，版本管理 | 无包管理 |
| 适合场景 | 复杂应用、多环境 | 简单应用、配置覆盖 |
| GitOps 集成 | ArgoCD 支持 | ArgoCD 原生支持 |
Q15: 监控方案选型
中小规模（< 100 节点）：Prometheus + Grafana + AlertManager
中大规模：VictoriaMetrics / Thanos（Prometheus 兼容）
日志：Fluent Bit → Kafka → Loki（轻量）或 EFK（重量）
链路追踪：OpenTelemetry → Tempo / Jaeger第六轮：行为面试
Q16: 描述一次最复杂的故障排查经历
STAR 方法：
- Situation：描述背景和故障现象
- Task：你的职责和目标
- Action：排查步骤、使用的工具、关键发现
- Result：根因、修复方案、后续改进
Q17: 如何推动团队采纳最佳实践
评估维度：
- 是否有影响力（不只是自己做得好）
- 是否通过数据和案例说服团队
- 是否建立文档和 SOP
- 是否通过工具降低执行门槛
评分体系
| 面试轮次 | 权重 | 考察重点 |
|---|---|---|
| 第一轮：基础知识 | 15% | 知识广度 |
| 第二轮：深度技术 | 25% | 技术深度 |
| 第三轮：故障排查 | 25% | 实战能力 |
| 第四轮：系统设计 | 20% | 架构思维 |
| 第五轮：工具生态 | 10% | 工具链掌握 |
| 第六轮：行为面试 | 5% | 软技能 |
录用标准：
综合 >= 4.0：强烈推荐
综合 >= 3.5：推荐录用
综合 >= 3.0：待定
综合 < 3.0：不推荐
单项否决：故障排查 D 级 / 系统设计 D 级级别对标：
| 级别 | 能力要求 | 年限参考 |
|---|---|---|
| P6（中级） | 基础扎实，独立处理常见故障 | 2-4 年 |
| P7（高级） | 技术深入，独立处理复杂故障 | 4-7 年 |
| P8（资深） | 架构设计能力强，主导技术方案 | 7+ 年 |
面试官追问策略
深度追问（向下）：
- "这个组件的源码你看过吗？核心逻辑是怎样的？"
- "如果这个组件挂了会怎样？系统如何自愈？"
- "你在生产中遇到过相关问题吗？"
广度追问（向上）：
- "有没有其他方案可以替代？"
- "什么场景下不适用？"
- "扩展到 10 倍规模需要做哪些改变？"