高级 Kubernetes 运维工程师模拟面试手册

本手册模拟真实面试场景，包含 6 轮面试流程、评分标准和参考答案，适用于面试官参考和候选人自测。

面试流程设计
第一轮：基础知识筛选（15 分钟）
第二轮：深度技术面试（30 分钟）
第三轮：故障排查实战（25 分钟）
第四轮：系统设计（30 分钟）
第五轮：运维工具与生态（20 分钟）
第六轮：行为面试与文化匹配（15 分钟）
评分体系
面试官使用指南
候选人自测清单

1. 面试流程设计

1.1 面试安排

总时长：约 2.5 小时（可拆分为两轮）

第一轮：基础知识筛选（15 分钟）
  - 目标：快速验证候选人知识广度和基础深度
  - 形式：快问快答

第二轮：深度技术面试（30 分钟）
  - 目标：考察核心技术栈的深度理解
  - 形式：追问式深入

第三轮：故障排查实战（25 分钟）
  - 目标：考察实战排障能力和思维方法
  - 形式：场景模拟 + 现场操作

第四轮：系统设计（30 分钟）
  - 目标：考察架构设计能力和全局思维
  - 形式：白板/共享屏幕设计

第五轮：运维工具与生态（20 分钟）
  - 目标：考察工具链掌握和最佳实践
  - 形式：方案讨论

第六轮：行为面试与文化匹配（15 分钟）
  - 目标：考察软技能、团队协作、成长潜力
  - 形式：STAR 方法

1.2 评分等级

等级	描述	分数
S - 卓越	超越预期，有独到见解或深入实践经验分享	5
A - 优秀	完全满足预期，回答准确且有深度	4
B - 良好	基本满足预期，核心概念正确	3
C - 一般	部分正确，但缺乏深度或有小错误	2
D - 不足	概念错误或无法回答	1

2. 第一轮：基础知识筛选

目标：15 分钟内快速评估候选人知识面。每题限时 1-2 分钟，面试官根据回答决定是否追问。

Q1: 请简述 Kubernetes 的核心架构，控制平面有哪些关键组件？

期望回答（B 级）：

控制平面包括 kube-apiserver（API 入口）、etcd（状态存储）、kube-scheduler（调度）、kube-controller-manager（控制器）。节点上有 kubelet（节点代理）和 kube-proxy（网络代理）。

追问（如回答到位）：

"apiserver 如何处理一个请求？经过哪些阶段？"
"etcd 用的什么一致性算法？为什么选择奇数节点？"

评分要点：

能说出 4 个控制平面组件 + 2 个节点组件 = B
能说清楚各组件交互流程 = A
能深入 apiserver 请求链（认证->授权->准入）或 etcd Raft = S

Q2: Pod 的三种探针分别是什么？它们的区别和适用场景？

期望回答（B 级）：

Liveness Probe 检测容器是否存活，失败则重启容器；Readiness Probe 检测是否就绪，失败则从 Service 移除；Startup Probe 用于慢启动应用，成功前禁用其他探针。

追问：

"如果一个 Java 应用启动需要 2 分钟，你会怎么配置探针？"
"Liveness Probe 失败和 Readiness Probe 失败的处理逻辑有什么根本区别？"

评分要点：

说出三种探针及基本区别 = B
能解释失败处理逻辑差异 = A
能结合实际场景给出合理配置方案，提到 StartupProbe 解决慢启动问题 = S

Q3: 解释 Kubernetes 中 Service 的几种类型，以及它们的区别。

期望回答（B 级）：

ClusterIP 是内部虚拟 IP；NodePort 在节点上暴露端口；LoadBalancer 创建外部负载均衡器；ExternalName 做 CNAME 映射。

追问：

"ClusterIP 实际上是如何工作的？iptables 和 IPVS 模式有什么区别？"
"如果需要暴露 gRPC 服务，你会怎么选择？"

Q4: 什么是 RBAC？Role 和 ClusterRole 有什么区别？

期望回答（B 级）：

RBAC 是基于角色的访问控制。Role 作用于 namespace 级别，ClusterRole 作用于集群级别。通过 RoleBinding/ClusterRoleBinding 将角色绑定到用户、组或 ServiceAccount。

追问：

"如何为一个 CI/CD 流水线创建最小权限的 ServiceAccount？"
"ClusterRole 能绑定到特定 namespace 吗？怎么做？"

Q5: 解释 PV、PVC 和 StorageClass 的关系。

期望回答（B 级）：

PV 是集群中的存储资源，PVC 是用户对存储的请求，StorageClass 定义存储类别和动态供给的 Provisioner。PVC 绑定 PV，StorageClass 可以自动创建 PV。

追问：

"什么是 CSI？它和早期的 in-tree volume plugin 有什么区别？"
"如何实现存储卷的快照和恢复？"

3. 第二轮：深度技术面试

目标：深入考察候选人对核心技术的理解深度。面试官根据候选人回答逐层追问。

Q6: 请详细描述从 `kubectl apply -f deployment.yaml` 到 Pod 真正运行的完整流程。

期望回答（B 级）：

kubectl 发送请求到 apiserver -> apiserver 验证和鉴权 -> 写入 etcd -> Controller 创建 ReplicaSet 和 Pod -> Scheduler 调度 -> kubelet 拉取镜像启动容器。

期望回答（A 级）：

补充 Admission Controller 链（Mutating -> Validation）、Informer Watch 机制、Scheduler 调度框架（Filter -> Score -> Bind）、kubelet 通过 CRI 调用容器运行时。

期望回答（S 级）：

提到 apiserver 的 protobuf 序列化优化、Informer 的 DeltaFIFO 和本地缓存、Scheduler 的 PreFilter/Permit 扩展点、kubelet 的 PLEG 机制、EndpointSlice Controller 更新 Service endpoints。

追问链：

"apiserver 的 Admission Controller 有哪些类型？Mutating 和 Validating 的执行顺序？"
"Informer 机制中 List-Watch 是怎么工作的？为什么要用本地缓存？"
"Scheduler 的调度框架有哪些扩展点？如何自定义调度器？"

Q7: 请深入解释 kube-proxy 的 IPVS 模式，它比 iptables 模式有什么优势？

期望回答（B 级）：

IPVS 使用内核的 LVS 模块，通过哈希表存储规则，查找复杂度 O(1)，而 iptables 是链式遍历 O(n)。IPVS 支持多种负载均衡算法。

期望回答（A 级）：

能解释 IPVS 工作在内核态，使用 netlink 接口编程，支持 rr/wrr/lc/sh/sed/nq 等算法。大规模 Service 场景下（>1000）性能优势明显。

期望回答（S 级）：

能讨论 IPVS 的 conntrack 处理、与 kube-router 的对比、IPVS 的 graceful termination 实现、以及 eBPF/Cilium 完全绕过 iptables/IPVS 的方案。

追问链：

"IPVS 模式下 kube-proxy 是如何维护规则的？"
"如果要排查 Service 间歇性连接超时，你会怎么做？"
"了解 Cilium 的 eBPF 数据面吗？它和 IPVS 有什么本质区别？"

Q8: 解释 Kubernetes 中资源的 QoS 等级，以及它如何影响 Pod 的驱逐？

期望回答（B 级）：

QoS 分三级：Guaranteed（requests=limits）、Burstable（至少设了 requests）、BestEffort（什么都没设）。节点资源紧张时，BestEffort 最先被驱逐。

期望回答（A 级）：

详细解释 QoS 计算规则（CPU 和 Memory 都要满足条件）、驱逐机制分 soft eviction 和 hard eviction、kubelet 的 eviction threshold 配置、Grace Period。

期望回答（S 级）：

能讨论 OOM Score 的计算（与 QoS 关联）、eviction manager 的信号（memory.available, nodefs.available, imagefs.available, allocatableMemory）、以及 PDB 如何保护应用不被过度驱逐。能结合生产经验给出最佳实践。

追问链：

"如果一个 Guaranteed Pod 和一个 BestEffort Pod 同时运行在资源紧张的节点上，具体驱逐逻辑是什么？"
"如何设计一个策略保证核心服务永远不会被驱逐？"
"node-pressure eviction 和 graceful node shutdown 有什么区别？"

Q9: 详细解释 Calico 网络插件的工作原理，BGP 模式和 VXLAN 模式如何选择？

期望回答（B 级）：

Calico 通过 veth pair 连接 Pod 和宿主机网络。BGP 模式通过 BGP 协议在节点间传播 Pod 路由，VXLAN 模式通过封装实现跨网络通信。

期望回答（A 级）：

能解释 BIRD BGP daemon 的角色、Felix agent 管理 iptables 规则、BGP 模式无封装开销但要求 L2 连通、VXLAN 有 50 字节封装开销但可跨 L3。能说明 RR（Route Reflector）在大规模场景的使用。

期望回答（S 级）：

能讨论 Calico 的 eBPF dataplane 模式（绕过 iptables）、NetworkPolicy 的实现机制（iptables 规则生成）、与 Cilium 的对比、以及在生产环境中的调优经验（如 BGP 对等策略、MTU 设置、网络策略性能优化）。

Q10: 如何实现 Kubernetes 集群的高可用？请从控制平面和应用两个层面说明。

期望回答（B 级）：

控制平面：多 master 节点、etcd 集群、apiserver 前面加 LB。应用层面：多副本、反亲和、PDB。

期望回答（A 级）：

能详细描述：
etcd 至少 3 节点（奇数），Stacked vs External 模式
apiserver 多实例 + LB（HAProxy/keepalived/kube-vip）
controller-manager 和 scheduler 的 Leader Election
应用层：Pod 反亲和、PDB、优雅终止、健康检查

期望回答（S 级）：

能讨论跨可用区部署策略、etcd learner 节点、apiserver 的流量分配（priority-based）、多集群容灾（Active-Active vs Active-Standby）、Velero 备份策略、灾难恢复 RTO/RPO 目标设定。

4. 第三轮：故障排查实战

目标：通过场景模拟考察候选人的排障思路、方法论和实际操作能力。

Q11: [场景] 线上告警：某个 Deployment 的所有 Pod 都处于 Pending 状态，请描述你的排查过程。

期望排查路径（B 级）：

1. kubectl get pods -n `<ns>` -o wide
2. kubectl describe pod `<pod-name>`
3. 查看 Events 部分的错误信息
4. 根据错误信息定位原因

期望排查路径（A 级）：

1. kubectl get pods -n `<ns>` -o wide
2. kubectl describe pod `<pod-name>` -> 查看 Events
3. 如果是资源不足：
   - kubectl describe nodes -> 查看资源分配情况
   - kubectl top nodes -> 查看实际使用
   - 检查是否有 DaemonSet 占用过多资源
4. 如果是调度约束：
   - 检查 nodeSelector / nodeAffinity
   - 检查 Taints/Tolerations
   - 检查 topologySpreadConstraints
5. 如果是 PVC 问题：
   - kubectl get pvc -> 查看 STATUS
   - 检查 StorageClass 和 Provisioner

期望排查路径（S 级）：

在上述基础上还能：
- 检查 scheduler 日志（是否有调度失败记录）
- 使用 kubectl get events --field-selector involvedObject.name=`<pod>`
- 检查是否有 PriorityClass 导致抢占
- 检查 ResourceQuota 是否限制了 namespace 资源
- 如果是近期发生，检查最近的变更（git log / ArgoCD history）
- 给出预防措施（如 PDB、资源预算、调度告警）

Q12: [场景] 某个 Service 间歇性返回 502 错误，你会如何排查？

期望排查路径：

1. 确认问题范围：
   - 是所有请求还是部分请求？
   - 是某个 Pod 还是所有 Pod？
   - 是否有规律（时间、流量）？

2. 检查 Pod 状态：
   - kubectl get pods -> 是否有重启？
   - kubectl logs `<pod>` --previous -> 崩溃前日志
   - kubectl describe pod -> OOM Kill? Liveness 失败?

3. 检查 Endpoints：
   - kubectl get endpoints `<svc>`
   - 是否某些 Pod 不在 Endpoints 中（Readiness 失败）
   - Endpoints 是否在频繁变化（Pod 反复 Ready/NotReady）

4. 检查 kube-proxy：
   - iptables-save | grep `<service-clusterip>`
   - 规则是否与实际 Pod IP 一致
   - 是否有 stale connection（conntrack 表问题）

5. 检查应用层面：
   - 连接池配置是否合理
   - 优雅终止是否正确处理（PreStop Hook）
   - 滚动更新时是否有短暂不可用

6. 常见根因：
   - 滚动更新时旧 Pod 已终止但 conntrack 未清除
   - 应用未正确处理 SIGTERM 导致请求中断
   - Readiness Probe 配置不当导致流量打到未就绪的 Pod
   - 后端连接池中有已关闭的连接

评分要点：

有系统的排查思路（分层法）= B
能定位到具体技术细节（conntrack、PreStop Hook）= A
能结合生产经验，给出多种可能根因和预防措施 = S

Q13: [场景] 集群中的某个节点突然变成 NotReady，你的排查步骤是什么？

期望回答：

1. 初步信息收集：
   - kubectl describe node `<node>` -> 查看 Conditions
   - kubectl get events --field-selector involvedObject.name=`<node>`

2. 尝试 SSH 登录节点：
   - 能否 SSH 登录？不能 -> 可能是网络/主机问题
   - 系统负载：uptime, top
   - 磁盘：df -h, df -i（inode）
   - 内存：free -m, dmesg | grep -i oom

3. 检查 kubelet：
   - systemctl status kubelet
   - journalctl -u kubelet --since '30 min ago'
   - 常见错误：PLEG unhealthy, CNI error, certificate expired

4. 检查容器运行时：
   - crictl ps / ctr containers list
   - journalctl -u containerd

5. 检查网络：
   - 节点能否 ping 通 apiserver
   - CNI 插件状态
   - 时钟同步（chrony/ntpd）

6. 常见根因：
   - kubelet 证书过期（1年有效期）
   - 磁盘空间满（/var/lib/kubelet, /var/lib/containerd）
   - inode 耗尽（大量小文件/日志）
   - 内核 panic / OOM killer 杀死关键进程
   - 网络分区（脑裂）

Q14: [现场操作] 请写出排查 DNS 解析问题的完整命令序列。

期望回答（A 级）：

bash

# 1. 创建 debug pod
kubectl run debug --image=busybox:1.36 -it --rm -- /bin/sh

# 2. 检查 DNS 配置
cat /etc/resolv.conf
# 确认 nameserver 是 kube-dns 的 ClusterIP

# 3. 测试集群内解析
nslookup kubernetes.default.svc.cluster.local
nslookup `<service-name>`.`<namespace>`.svc.cluster.local

# 4. 测试外部解析
nslookup google.com

# 5. 检查 CoreDNS Pod 状态
kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs -n kube-system -l k8s-app=kube-dns

# 6. 检查 CoreDNS Service
kubectl get svc kube-dns -n kube-system
kubectl get endpoints kube-dns -n kube-system

# 7. 检查 CoreDNS 配置
kubectl get configmap coredns -n kube-system -o yaml

# 8. 使用 dig 进行详细查询
kubectl exec debug -- dig kubernetes.default.svc.cluster.local
kubectl exec debug -- dig +trace kubernetes.default.svc.cluster.local

# 9. 检查 ndots 问题
cat /etc/resolv.conf | grep ndots
# 默认 ndots:5，对外部域名解析会产生大量无效查询

5. 第四轮：系统设计

目标：考察候选人的架构设计能力和全局思维。

Q15: [设计题] 请设计一个支撑 2000+ 节点的 Kubernetes 生产集群架构。

评估维度：

1. 控制平面设计（25%）
   - 3+ master 节点，独立 etcd 集群（5 节点）
   - apiserver 前置 HAProxy + keepalived
   - 分离 etcd 到独立节点
   - apiserver 参数调优（max-requests-inflight, watch-cache-size）

2. 网络设计（25%）
   - CNI 选型（Calico BGP 或 Cilium eBPF）
   - IPVS 模式 kube-proxy
   - Ingress Controller 高可用（Nginx/Contour + HPA）
   - 网络分区规划（多 CIDR、多子网）
   - DNS 优化（CoreDNS cache、node-local DNS cache）

3. 存储设计（15%）
   - CSI 插件选型（Ceph RBD/CephFS, NFS, 云厂商 CSI）
   - StorageClass 分层（SSD/HDD/高性能）
   - 备份策略（Velero + etcd 快照）

4. 可观测性（15%）
   - Prometheus + Thanos（长期存储）
   - Grafana + 标准 Dashboard
   - Alertmanager + 告警分级
   - 日志：Loki + Fluent Bit
   - 链路追踪：Jaeger/OpenTelemetry

5. 安全设计（10%）
   - RBAC 分层设计
   - NetworkPolicy 分 namespace 策略
   - Pod Security Admission
   - 审计日志
   - 密钥管理（Vault/External Secrets）

6. 运维自动化（10%）
   - GitOps（ArgoCD）
   - IaC（Terraform + Ansible）
   - CI/CD Pipeline 设计
   - 集群升级自动化

评分要点：

能画出基本架构图，考虑 HA = B
能深入每个组件的选型理由和配置调优 = A
能考虑 Trade-off、成本、可扩展性、灾备、合规等全局因素 = S

Q16: [设计题] 请设计一个多租户 Kubernetes 平台，需要支持 50+ 个业务团队。

关键设计点：

1. 隔离策略
   - Namespace 级别隔离
   - RBAC：每个团队只能访问自己的 Namespace
   - NetworkPolicy：默认跨 Namespace 隔离
   - ResourceQuota：限制每个团队的资源用量
   - LimitRange：设置默认 requests/limits

2. 租户管理
   - 自助服务 Portal（申请 Namespace、配额）
   - 自动化 Namespace 创建（CRD + Controller 或 ArgoCD AppSet）
   - 租户间资源配额动态调整

3. 共享基础设施
   - 共享 Ingress Controller（按 Host 路由）
   - 共享监控（但数据隔离）
   - 共享日志（按 Namespace 过滤）
   - 共享镜像仓库（按 Project 隔离）

4. 安全合规
   - Pod Security Admission 分级（系统 Namespace: privileged, 业务: restricted）
   - OPA/Kyverno 策略引擎
   - 审计日志（按租户分析）

5. 成本分摊
   - Kubecost/OpenCost 按 Namespace 统计
   - 资源利用率报告
   - 计费模型设计

Q17: [设计题] 设计一个 K8s 上运行 MySQL 集群的方案，要求数据不丢失、支持在线扩容。

关键设计点：

1. StatefulSet + 持久存储
   - 使用 StatefulSet 管理 MySQL 实例
   - PVC 使用 Retain 回收策略
   - 本地存储 vs 网络存储的权衡

2. 主从复制
   - 1 Master + N Slaves
   - 使用 Operator（如 MySQL Operator / Vitess / PlanetScale）
   - 半同步复制 vs 异步复制

3. 高可用
   - 自动故障转移（Orchestrator / MHA）
   - VIP 漂移或 Proxy 层（ProxySQL）
   - PDB 保证最小可用实例

4. 备份策略
   - 定期全量备份（mysqldump/xtrabackup）
   - binlog 增量备份
   - Volume 快照
   - 异地备份

5. 扩容方案
   - 读扩容：增加 Slave 副本
   - 写扩容：分库分表（Vitess / ShardingSphere）
   - 存储扩容：PVC resize + 在线扩容

6. 监控
   - MySQL 专属指标（QPS、慢查询、复制延迟）
   - mysqld_exporter + Grafana

6. 第五轮：运维工具与生态

Q18: 请对比 Helm 和 Kustomize 的优缺点，以及它们各自适用的场景。

期望回答：

维度	Helm	Kustomize
定位	包管理器 + 模板引擎	配置叠加器
模板	Go template，灵活但复杂	YAML overlay，简单直接
参数化	values.yaml	kustomization.yaml + patches
生态	丰富的公共 Chart	较少公共 kustomization
版本管理	Release 版本	Git 版本
适用场景	打包发布、多环境复用	GitOps、配置差异管理
学习曲线	中等（模板语法）	低（YAML 叠加）
与 ArgoCD	支持良好	原生支持

追问：

"你们生产环境中是怎么管理 Helm Chart 的？"
"如何用 Kustomize 管理 dev/staging/prod 三个环境的差异？"

Q19: 描述 ArgoCD 的 Sync 机制，以及如何处理 Sync 失败的情况。

期望回答：

ArgoCD Sync 流程：
1. 检测 Git 中的 Desired State
2. 与集群中的 Live State 对比
3. 计算 Diff（需要变更的资源）
4. 按照 Sync Waves 排序（annotation: argocd.argoproj.io/sync-wave）
5. 执行 PreSync Hooks
6. 按顺序 Apply 资源
7. 执行 PostSync Hooks
8. 等待 Health Check 通过

Sync 失败处理：
- Prune 失败：检查 finalizer 是否阻塞
- Health Check 失败：检查应用日志和 events
- Hook 失败：检查 Hook Job 日志，修正后重新 Sync
- 资源冲突：使用 --force 或手动解决
- 回滚：argocd rollback `<app>` `<revision>`

Q20: 如何设计一个完整的 K8s 监控告警体系？请从指标采集到告警通知的全链路说明。

期望回答（A 级）：

指标采集层：
- node-exporter：节点 CPU/内存/磁盘/网络
- kube-state-metrics：K8s 对象状态
- cAdvisor（kubelet 内置）：容器资源指标
- prometheus-adapter / metrics-server：HPA 自定义指标
- 应用自身 metrics endpoint

存储与查询层：
- Prometheus：本地 TSDB 存储（保留 15 天）
- Thanos Sidecar + Store Gateway：长期存储（S3/GCS）
- Thanos Query：跨集群统一查询

告警层：
- PrometheusRule：定义告警规则
- Alertmanager：分组（group_by）、抑制（inhibit）、静默（silence）
- 告警路由：PagerDuty / Slack / 企业微信 / 钉钉 / 短信 / 电话

可视化层：
- Grafana Dashboard：分层展示
  - 集群总览 -> 节点详情 -> Pod 详情 -> 容器详情
  - RED Dashboard（应用层）
  - USE Dashboard（基础设施层）
  - 控制平面 Dashboard

告警分级策略：
- P0（立即响应）：集群不可用、控制平面故障、大面积 Pod 异常
- P1（15 分钟内）：节点 NotReady、核心服务不可用、etcd 异常
- P2（1 小时内）：Pod 重启频繁、资源使用率超标、证书即将过期
- P3（工作时间处理）：资源浪费、配置不一致、非核心告警

7. 第六轮：行为面试与文化匹配

使用 STAR 方法（Situation, Task, Action, Result）评估候选人的软技能。

Q21: 请描述一次你处理过的最严重的线上事故。你是如何应对的？

评估维度：

是否能清晰描述事故背景和影响
应急响应是否有序（止血 -> 定位 -> 修复）
是否有系统化的排障方法
事后是否有推动改进（复盘、Action Items）
沟通能力和团队协作

红旗信号：

推卸责任给他人
没有事后复盘和改进措施
无法清晰描述技术细节
只关注技术不关注业务影响

Q22: 你如何在团队中推广新技术或最佳实践？举一个具体例子。

评估维度：

技术影响力
沟通和说服能力
是否有系统化的推进方法
能否平衡技术理想与现实约束

Q23: 你如何保持技术能力的持续成长？最近在学什么新技术？

评估维度：

学习能力和热情
对云原生生态的关注度
知识深度 vs 广度的平衡
是否关注前沿趋势（eBPF, Gateway API, Wasm, AI Ops 等）

Q24: 请描述一个你在容量规划或成本优化方面的经验。

评估维度：

是否有数据驱动的决策能力
对资源利用率和成本的理解
工具使用经验（Kubecost, VPA, Cluster Autoscaler）
能否平衡成本和服务质量

Q25: 你如何看待 on-call 和值班？如何减少 on-call 的负担？

评估维度：

对 on-call 的态度和责任心
是否有系统化减少告警疲劳的思路
Runbook/SOP 建设经验
自动化运维意识

8. 评分体系

8.1 综合评分表

面试轮次	权重	考察重点
第一轮：基础知识	15%	知识广度、基本概念
第二轮：深度技术	25%	技术深度、原理理解
第三轮：故障排查	25%	实战能力、排障方法
第四轮：系统设计	20%	架构思维、全局视野
第五轮：工具生态	10%	工具链掌握、最佳实践
第六轮：行为面试	5%	软技能、文化匹配

8.2 录用建议标准

综合评分 >= 4.0：强烈推荐录用
综合评分 >= 3.5：推荐录用
综合评分 >= 3.0：待定（可加面）
综合评分 < 3.0：不推荐

单项否决：
- 故障排查能力 D 级：不具备独立值班能力
- 系统设计 D 级：不具备高级工程师水平
- 行为面试中发现严重文化不匹配

8.3 各级别对标

级别	对应能力	工作年限参考
P6（中级）	基础扎实，能独立处理常见故障	2-4 年
P7（高级）	技术深入，能独立处理复杂故障，有设计能力	4-7 年
P8（资深）	架构设计能力强，能主导技术方案，有影响力	7+ 年

9. 面试官使用指南

9.1 面试前准备

1. 阅读候选人简历，标记需要深挖的点
2. 根据候选人背景调整问题侧重：
   - 偏运维背景：加大故障排查比重
   - 偏开发背景：加大系统设计比重
   - 偏管理背景：加大行为面试比重
3. 准备追问链，确保能区分 B/A/S 级别
4. 准备实操环境（可选）：minikube/kind 集群

9.2 面试技巧

1. 营造轻松氛围：先聊简历上的项目经历
2. 追问而非否定：用"能再详细说说吗？"代替"这不对"
3. 记录关键回答：便于后续评估和交叉验证
4. 时间控制：每轮严格限时，避免某题耗时过多
5. 给候选人提问时间：好的候选人通常有好问题

9.3 追问策略

深度追问（向下）：
- "这个组件的源码你看过吗？核心逻辑是怎样的？"
- "如果这个组件挂了会怎样？系统如何自愈？"
- "你在生产环境中遇到过相关问题吗？怎么解决的？"

广度追问（向上）：
- "有没有其他方案可以替代？为什么选这个？"
- "这个方案在什么场景下不适用？"
- "如果要扩展到 10 倍规模，需要做哪些改变？"

10. 候选人自测清单

面试前，用这个清单自我评估。每项打 1-5 分，3 分以下的领域需要重点复习。

10.1 技术能力自评

核心架构：
[ ] 能描述 K8s 控制平面的完整架构和组件交互
[ ] 理解声明式 API、Reconciliation Loop、Level-triggered
[ ] 了解 Informer 机制（List-Watch, DeltaFIFO, Indexer）
[ ] 理解 etcd Raft 协议和数据一致性

工作负载：
[ ] 掌握 Pod 生命周期和三种探针的配置
[ ] 理解 Deployment/StatefulSet/DaemonSet 的区别和适用场景
[ ] 掌握滚动更新策略和回滚操作
[ ] 了解 Init Container 和 Sidecar 模式

网络：
[ ] 理解 K8s 网络模型（Pod 间通信、Service、DNS）
[ ] 掌握 iptables/IPVS 模式的区别
[ ] 了解至少一种 CNI 插件（Calico/Cilium）的工作原理
[ ] 掌握 Ingress/Gateway API 的配置
[ ] 能排查 DNS 和网络连接问题

存储：
[ ] 理解 PV/PVC/StorageClass 的关系
[ ] 了解 CSI 插件架构
[ ] 掌握 Volume 快照和恢复

调度与资源：
[ ] 理解调度器流程和调度策略
[ ] 掌握 QoS 等级和驱逐机制
[ ] 了解 HPA/VPA/Cluster Autoscaler 的配置

安全：
[ ] 掌握 RBAC 设计和最小权限原则
[ ] 了解 Pod Security Standards
[ ] 掌握 NetworkPolicy 配置
[ ] 了解安全加固清单

运维：
[ ] 能独立排查常见故障（Pending/CrashLoop/NotReady）
[ ] 掌握集群升级流程
[ ] 掌握 etcd 备份和恢复
[ ] 了解监控告警体系设计

工具链：
[ ] 熟练使用 kubectl 各种命令
[ ] 掌握 Helm Chart 开发
[ ] 了解 GitOps（ArgoCD）工作流
[ ] 了解 CI/CD Pipeline 设计

10.2 面试准备建议

1. 复习简历上提到的每个项目，准备 3 分钟讲述版本
2. 准备 2-3 个故障排查的故事（STAR 格式）
3. 准备 1 个系统设计的案例（架构图 + Trade-off）
4. 了解目标公司的技术栈和 K8s 使用场景
5. 准备 3 个要问面试官的问题
6. 复习目标职级的能力要求，有针对性地准备
7. 如果有实操环节，确保本地有 kubectl/kind 可用

面试心态：
- 不确定的问题诚实说，但可以分享你的推理过程
- 展示解决问题的思路比给出正确答案更重要
- 高级工程师面试看重的是深度和方法论，不是背诵
- 把面试当作技术讨论，而不是考试

文档维护说明： 本手册建议每半年更新一次，补充新的面试题目和技术趋势。面试官使用后可补充新的追问和评分经验。

高级 Kubernetes 运维工程师模拟面试手册 ​

目录 ​

1. 面试流程设计 ​

1.1 面试安排 ​

1.2 评分等级 ​

2. 第一轮：基础知识筛选 ​

Q1: 请简述 Kubernetes 的核心架构，控制平面有哪些关键组件？ ​

Q2: Pod 的三种探针分别是什么？它们的区别和适用场景？ ​

Q3: 解释 Kubernetes 中 Service 的几种类型，以及它们的区别。 ​

Q4: 什么是 RBAC？Role 和 ClusterRole 有什么区别？ ​

Q5: 解释 PV、PVC 和 StorageClass 的关系。 ​

3. 第二轮：深度技术面试 ​

Q6: 请详细描述从 kubectl apply -f deployment.yaml 到 Pod 真正运行的完整流程。 ​

Q7: 请深入解释 kube-proxy 的 IPVS 模式，它比 iptables 模式有什么优势？ ​

Q8: 解释 Kubernetes 中资源的 QoS 等级，以及它如何影响 Pod 的驱逐？ ​

Q9: 详细解释 Calico 网络插件的工作原理，BGP 模式和 VXLAN 模式如何选择？ ​

Q10: 如何实现 Kubernetes 集群的高可用？请从控制平面和应用两个层面说明。 ​

4. 第三轮：故障排查实战 ​

Q11: [场景] 线上告警：某个 Deployment 的所有 Pod 都处于 Pending 状态，请描述你的排查过程。 ​

Q12: [场景] 某个 Service 间歇性返回 502 错误，你会如何排查？ ​

Q13: [场景] 集群中的某个节点突然变成 NotReady，你的排查步骤是什么？ ​

Q14: [现场操作] 请写出排查 DNS 解析问题的完整命令序列。 ​

5. 第四轮：系统设计 ​

Q15: [设计题] 请设计一个支撑 2000+ 节点的 Kubernetes 生产集群架构。 ​

Q16: [设计题] 请设计一个多租户 Kubernetes 平台，需要支持 50+ 个业务团队。 ​

Q17: [设计题] 设计一个 K8s 上运行 MySQL 集群的方案，要求数据不丢失、支持在线扩容。 ​

6. 第五轮：运维工具与生态 ​

Q18: 请对比 Helm 和 Kustomize 的优缺点，以及它们各自适用的场景。 ​

Q19: 描述 ArgoCD 的 Sync 机制，以及如何处理 Sync 失败的情况。 ​

Q20: 如何设计一个完整的 K8s 监控告警体系？请从指标采集到告警通知的全链路说明。 ​

7. 第六轮：行为面试与文化匹配 ​

Q21: 请描述一次你处理过的最严重的线上事故。你是如何应对的？ ​

Q22: 你如何在团队中推广新技术或最佳实践？举一个具体例子。 ​

Q23: 你如何保持技术能力的持续成长？最近在学什么新技术？ ​

Q24: 请描述一个你在容量规划或成本优化方面的经验。 ​

Q25: 你如何看待 on-call 和值班？如何减少 on-call 的负担？ ​

8. 评分体系 ​

8.1 综合评分表 ​

8.2 录用建议标准 ​

8.3 各级别对标 ​

9. 面试官使用指南 ​

9.1 面试前准备 ​

9.2 面试技巧 ​

9.3 追问策略 ​

10. 候选人自测清单 ​

10.1 技术能力自评 ​

10.2 面试准备建议 ​

高级 Kubernetes 运维工程师模拟面试手册

目录

1. 面试流程设计

1.1 面试安排

1.2 评分等级

2. 第一轮：基础知识筛选

Q1: 请简述 Kubernetes 的核心架构，控制平面有哪些关键组件？

Q2: Pod 的三种探针分别是什么？它们的区别和适用场景？

Q3: 解释 Kubernetes 中 Service 的几种类型，以及它们的区别。

Q4: 什么是 RBAC？Role 和 ClusterRole 有什么区别？

Q5: 解释 PV、PVC 和 StorageClass 的关系。

3. 第二轮：深度技术面试

Q6: 请详细描述从 `kubectl apply -f deployment.yaml` 到 Pod 真正运行的完整流程。

Q7: 请深入解释 kube-proxy 的 IPVS 模式，它比 iptables 模式有什么优势？

Q8: 解释 Kubernetes 中资源的 QoS 等级，以及它如何影响 Pod 的驱逐？

Q9: 详细解释 Calico 网络插件的工作原理，BGP 模式和 VXLAN 模式如何选择？

Q10: 如何实现 Kubernetes 集群的高可用？请从控制平面和应用两个层面说明。

4. 第三轮：故障排查实战

Q11: [场景] 线上告警：某个 Deployment 的所有 Pod 都处于 Pending 状态，请描述你的排查过程。

Q12: [场景] 某个 Service 间歇性返回 502 错误，你会如何排查？

Q13: [场景] 集群中的某个节点突然变成 NotReady，你的排查步骤是什么？

Q14: [现场操作] 请写出排查 DNS 解析问题的完整命令序列。

5. 第四轮：系统设计

Q15: [设计题] 请设计一个支撑 2000+ 节点的 Kubernetes 生产集群架构。

Q16: [设计题] 请设计一个多租户 Kubernetes 平台，需要支持 50+ 个业务团队。

Q17: [设计题] 设计一个 K8s 上运行 MySQL 集群的方案，要求数据不丢失、支持在线扩容。

6. 第五轮：运维工具与生态

Q18: 请对比 Helm 和 Kustomize 的优缺点，以及它们各自适用的场景。

Q19: 描述 ArgoCD 的 Sync 机制，以及如何处理 Sync 失败的情况。

Q20: 如何设计一个完整的 K8s 监控告警体系？请从指标采集到告警通知的全链路说明。

7. 第六轮：行为面试与文化匹配

Q21: 请描述一次你处理过的最严重的线上事故。你是如何应对的？

Q22: 你如何在团队中推广新技术或最佳实践？举一个具体例子。

Q23: 你如何保持技术能力的持续成长？最近在学什么新技术？

Q24: 请描述一个你在容量规划或成本优化方面的经验。

Q25: 你如何看待 on-call 和值班？如何减少 on-call 的负担？

8. 评分体系

8.1 综合评分表

8.2 录用建议标准

8.3 各级别对标

9. 面试官使用指南

9.1 面试前准备

9.2 面试技巧

9.3 追问策略

10. 候选人自测清单

10.1 技术能力自评

10.2 面试准备建议