Kubernetes 架构师模拟面试手册

配合面试手册使用模拟真实面试场景, 含参考答案与评分要点

1. 面试流程概述

典型面试流程 (4-5轮, 总时长约3-4小时)

轮次	面试官	时长	重点
第一轮	技术Leader/同级	45min	基础知识, 项目经验, 技术广度
第二轮	资深架构师	60min	技术深度, 方案设计, 疑难问题
第三轮	架构委员会	60min	系统设计, 架构思维, 全局视野
第四轮	SRE/运维负责人	45min	故障排查, 应急响应, 运维能力
第五轮	总监/VP	30min	管理潜力, 技术视野, 文化匹配

评分维度

维度	权重	说明
技术深度	30%	K8s核心原理, 疑难问题解决能力
架构能力	25%	系统设计, 方案权衡, 全局视野
实战经验	25%	真实案例, 生产问题处理, 数据驱动
沟通表达	10%	逻辑清晰, 表达准确, 主动引导
学习成长	10%	技术热情, 学习方法, 行业视野

2. 第一轮: 基础知识与经验

Q1: 请介绍一下你的K8s相关经验, 管理过的最大集群规模?

评分要点: 真实性、规模感、角色清晰度

参考答案框架:

我在XX公司负责容器平台建设, 管理过3个生产集群, 最大的一个有约2000个节点、 50000+Pod。日常承载公司80%的微服务, 日均部署200+次。
我的核心职责包括:
集群架构设计与升级规划 - 主导了从1.22到1.28的跨版本升级
GPU资源池化 - 设计了GPU共享方案, 将GPU利用率从25%提升到65%
成本优化 - 通过混部+弹性伸缩, 年化节省云资源费用¥300万
稳定性保障 - 建立了完整的SLO体系, 平台可用性从99.9%提升到99.97%

常见陷阱:

夸大集群规模 (面试官会追问细节)
只说做了什么, 不说为什么 (缺少trade-off分析)
没有数据支撑 (缺少具体指标)

Q2: K8s中Pod的QoS等级有哪些? 分别在什么场景使用?

评分要点: 理解深度, 是否能延伸到实际场景

参考答案:

K8s定义了3种QoS等级:
Guaranteed: requests == limits, CPU和Memory都设置。
OOM时最后被kill (oom_score_adj=-998)
使用场景: 核心微服务、数据库、延迟敏感型服务
Burstable: 至少一个容器设置了requests, 且requests < limits
OOM时按超出request的比例决定kill顺序 (oom_score_adj=2~999)
使用场景: 大多数常规业务服务
BestEffort: 不设置任何requests/limits
最先被OOM kill (oom_score_adj=1000)
使用场景: 开发测试、离线批处理、低优先级任务
实际中我还会结合PriorityClass使用, 比如:
P0核心服务: Guaranteed + system-node-critical
P1普通服务: Burstable + high-priority
P2批处理: BestEffort + low-priority, 配合在离线混部

Q3: 解释一下K8s的声明式API和最终一致性?

参考答案:

声明式API: 用户描述"期望状态"(Desired State), 系统负责将"实际状态"收敛到期望状态。区别于命令式: 用户不是告诉系统"怎么做", 而是"要什么"。
最终一致性: 系统不保证操作立即完成, 但保证最终会达到一致状态。 K8s通过Controller的reconcile循环实现:
while true {
    desired = 读取用户声明的期望状态
    actual = 读取当前实际状态
    if desired != actual {
        执行操作使actual趋向desired
    }
    sleep(interval)
}
实际影响:
kubectl apply不是立即生效, 而是异步收敛
可能出现中间状态, 需要 readiness probe 保障
Operator设计也遵循这个模式

Q4: kube-proxy的三种模式有什么区别? 生产环境选哪个?

参考答案:

userspace模式 (已废弃): kube-proxy在用户空间代理流量, 性能差
iptables模式 (默认):
每个Service生成iptables规则, 线性匹配
问题: Service多时(>1000), iptables规则数爆炸, 匹配慢
规则数: O(Service × Port)
IPVS模式 (推荐生产):
使用Linux内核IPVS模块, 哈希表匹配
支持多种负载均衡算法: rr/wrr/wlc/sh/sed/nq
连接追踪更精确
规则数: O(Service), 性能恒定
生产选择: IPVS模式, 原因:
大规模Service下性能稳定
支持更丰富的负载均衡算法
连接管理更精细
但需注意: IPVS和iptables可能冲突, 需清理iptables残留规则

Q5: 你们CI/CD流水线是怎么设计的?

参考答案框架:

我们基于ArgoCD + Tekton构建GitOps流水线:

开发者push代码 → GitLab Webhook → Tekton Pipeline:
  1. 代码检查 (lint/static analysis)
  2. 单元测试 + 覆盖率检查 (>80%)
  3. 构建镜像 (Kaniko, 无需Docker daemon)
  4. 镜像安全扫描 (Trivy, 高危漏洞阻断)
  5. 推送镜像到Harbor (带签名cosign)
  6. 更新Git仓库中的K8s manifest

ArgoCD 监听Git变更 → 自动同步到K8s:
  - Dev环境: 自动部署
  - Staging: 自动部署 + 自动化测试
  - Production: 手动审批 + Canary发布 (Argo Rollouts)

关键设计:

Git作为唯一真相源 (Single Source of Truth)
镜像不可变标签 (不用latest)
部署和构建分离
回滚只需 git revert

3. 第二轮: 技术深度

Q6: 详细讲讲你们GPU资源管理是怎么做的? 遇到过什么问题?

评分要点: 方案选型逻辑, 实际问题经验, 数据支撑

参考答案:

我们经历了三个阶段:
阶段一: 整卡分配 (Device Plugin)
使用NVIDIA Device Plugin, 每块GPU分配给一个Pod
问题: 推理服务只需要2-4GB显存, 但A100有80GB, 利用率仅5-10%
每月GPU成本¥200万, 严重浪费
阶段二: MIG切分
A100启用MIG, 切成1g.10gb/2g.20gb/3g.40gb实例
优点: 硬件级隔离, 性能可预测, ECC独立
问题: 切分粒度固定, 不支持T4/V100, 运维复杂
阶段三: HAMi共享方案 (当前)
使用HAMi(火山引擎开源)做显存+算力切分
每卡最多切10份, 支持显存和算力独立配置
调度器扩展: 感知GPU显存余量, binpack调度
效果: GPU利用率从25%提升到65%, 月省¥80万
遇到的问题:
CUDA兼容性: 某些框架(TensorRT)与CUDA hook冲突 → 白名单机制
显存泄漏: 共享GPU上一个Pod OOM影响其他Pod → 设置memoryLimit+监控
拓扑感知: 分布式训练跨NUMA导致性能下降 → Volcano+TopologyManager

Q7: etcd的Raft协议怎么工作? 大规模集群如何优化etcd?

评分要点: 分布式系统理论, 实战优化经验

参考答案:

Raft核心流程:
Leader选举: 一个Leader + 多个Follower, 心跳超时触发重选
日志复制: Client写请求→Leader追加日志→复制到Follower→多数确认→commit
安全性: 日志匹配、Leader完备性、状态机安全
etcd在K8s中的关键优化:
存储层优化:
必须使用SSD/NVMe (etcd对fsync延迟极其敏感, p99<10ms)
定期compaction (压缩历史版本) + defrag (碎片整理)
quota-backend-bytes: 8GB (默认2GB太小)
架构层优化:
分离events etcd: events高频小写入, 独立集群避免影响主etcd
API Server缓存: watch cache减少etcd读压力
分页List: 避免一次性返回大量数据
参数调优 (大规模集群):
--snapshot-count=10000           # 快照频率
--heartbeat-interval=100         # 心跳间隔(ms)
--election-timeout=1000          # 选举超时(ms)
--max-request-bytes=33554432     # 最大请求32MB
监控指标:
etcd_disk_wal_fsync_duration_seconds (WAL写入延迟)
etcd_disk_backend_commit_duration_seconds (后端提交延迟)
etcd_server_proposals_failed_total (提案失败数)

Q8: Cilium和Calico有什么区别? 你会怎么选?

评分要点: 网络方案深度理解, 选型决策能力

参考答案:

Calico:
数据面: iptables/IPVS规则或 eBPF (Calico 3.18+)
路由模式: BGP Direct Routing (同L2) 或 IPIP/VXLAN (跨L3)
网络策略: Calico NetworkPolicy (扩展了K8s NP, 支持FQDN)
优势: 成熟稳定, 社区大, 企业版功能丰富
劣势: iptables模式大规模下性能下降
Cilium:
数据面: 完全基于eBPF (内核态可编程)
不依赖iptables/IPVS, 性能更好
网络策略: CiliumNetworkPolicy (L7感知, HTTP/gRPC/Kafka)
可观测性: Hubble (eBPF级别的流量可视化)
优势: 性能优异, L7策略, 可观测性强
劣势: 需要较新内核(>=4.19), 学习曲线陡
选型决策:
场景推荐原因
大规模(>1000节点) Cilium eBPF性能优势明显
L7网络策略需求 Cilium 原生支持HTTP/gRPC策略
保守稳定优先 Calico 成熟度高, 文档全
内核版本老旧 Calico Cilium需要>=4.19
可观测性要求高 Cilium Hubble流量可视化
我的实际选择: 新集群用Cilium, 旧集群维持Calico不迁移。迁移成本高且风险大, 除非有明确性能瓶颈。

场景	推荐	原因
大规模(>1000节点)	Cilium	eBPF性能优势明显
L7网络策略需求	Cilium	原生支持HTTP/gRPC策略
保守稳定优先	Calico	成熟度高, 文档全
内核版本老旧	Calico	Cilium需要>=4.19
可观测性要求高	Cilium	Hubble流量可视化

Q9: 讲讲你开发过的Operator? 设计思路是什么?

评分要点: Operator开发经验, 设计模式理解

参考答案:

我开发过一个数据库自动运维Operator, 主要功能:

自动故障切换 (主从切换)
自动备份与恢复
自动扩容 (垂直+水平)
配置热更新

设计思路:

CRD设计:

yaml

apiVersion: db.example.com/v1alpha1
kind: DatabaseCluster
spec:
  replicas: 3                    # 实例数
  version: "8.0.35"              # 数据库版本
  storage:
    size: 100Gi
    storageClass: ceph-rbd
  resources:
    cpu: "4"
    memory: "16Gi"
  backup:
    schedule: "0 2 * * *"        # 每天2点备份
    retention: 7                  # 保留7天
  autoScaling:
    enabled: true
    maxReplicas: 5
status:
  phase: Running                 # Running/Failover/Backup/Scaling
  primary: db-cluster-0
  replicas:
  - name: db-cluster-0
    role: primary
    ready: true
  - name: db-cluster-1
    role: replica
    ready: true
  lastBackupTime: "2026-08-22T02:00:00Z"
  conditions:
  - type: Ready
    status: "True"

Controller核心逻辑:

Reconcile():
  1. 读取DatabaseCluster CR
  2. 对比期望状态 vs 实际状态
  3. 根据Phase执行对应操作:
     - Creating: 创建StatefulSet + Service + ConfigMap
     - Running: 健康检查, 监控主从延迟
     - Failover: 选举新主, 更新Service selector
     - Backup: 执行备份, 清理过期备份
     - Scaling: 扩/缩副本, 等待数据同步
  4. 更新Status
  5. 设置RequeueAfter (定期reconcile)

关键技术点:

使用kubebuilder脚手架, controller-runtime框架
Finalizer防止误删: 删除前先备份数据
OwnerReference级联删除
LeaderElection多副本部署
Status条件设计遵循K8s conventions

Q10: 如何实现K8s集群的多租户隔离?

评分要点: 隔离级别理解, 方案完整性

参考答案:

多租户隔离分三个层次:
1. 命名空间隔离 (轻量级)
RBAC: 每个租户独立的Role/RoleBinding
ResourceQuota: 限制CPU/内存/Pod数
LimitRange: 默认requests/limits
NetworkPolicy: 命名空间间网络隔离
适用: 内部团队, 信任度高
2. 虚拟集群隔离 (中等)
vCluster: 每个租户一个虚拟集群
共享物理集群, 独立API Server
适用: 多部门, 需要独立管控
3. 独立集群隔离 (重量级)
每个租户一个物理集群
共享控制平面管理 (Rancher/KubeSphere)
适用: 外部客户, 强合规要求
我实际用的是方案1+增强:
yaml
# 网络隔离
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: tenant-a
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}          # 只允许同命名空间
额外增强:
OPA Gatekeeper: 统一策略管控 (禁止hostNetwork, 限制镜像仓库)
Kyverno: 自动注入sidecar, 强制label
存储隔离: 每个租户独立StorageClass/命名空间
日志隔离: Loki tenant-id隔离
成本分摊: Kubecost按命名空间统计成本

4. 第三轮: 系统设计与架构

Q11: [设计题] 请设计一个支撑日均10万次部署的K8s平台

评分要点: 全局视野, 方案完整性, 扩展性考虑

参考答案框架:

整体架构:
┌─────────────────────────────────────────────────────┐
│                   开发者门户 (Web UI)                 │
│  应用管理 | 部署记录 | 资源查看 | 自助运维              │
└───────────────────────┬─────────────────────────────┘
                        │
┌───────────────────────┴─────────────────────────────┐
│                GitOps 控制层                          │
│  GitLab → ArgoCD → K8s Manifest                      │
└───────────────────────┬─────────────────────────────┘
                        │
┌───────────────────────┴─────────────────────────────┐
│              多集群管理层 (Karmada/Clusternet)         │
│  集群注册 | 策略下发 | 故障迁移 | 统一调度              │
├─────────────┬──────────────┬────────────────────────┤
│  生产集群A   │  生产集群B    │   预发/测试集群          │
│  (华东)      │  (华南)      │                         │
└─────────────┴──────────────┴────────────────────────┘
关键设计决策:
1. 部署流水线 (日均10万次 = ~70次/分钟)
构建: Tekton Pipeline, 并发构建限制50个
镜像: Harbor多副本, P2P预分发(Dragonfly)
部署: ArgoCD, 按集群分片, 每个分片管理1000应用
策略: Canary + 自动回滚 (基于Prometheus指标)
2. 镜像分发 (10万次部署的镜像拉取瓶颈)
P2P分发: Dragonfly/DADI, 节点间共享镜像层
预热机制: 部署前主动pull到目标节点
镜像瘦身: multi-stage build, 基础镜像复用
3. 配置管理
环境差异: Kustomize overlay
配置变更: 独立ConfigMap + 热更新(Reload Operator)
密钥管理: External Secrets Operator → Vault
4. 可观测性
部署看板: Grafana + ArgoCD metrics
变更追踪: 每次部署关联Git commit + 影响分析
成本看板: Kubecost按应用/团队统计
5. 容灾与回滚
自动回滚: 部署后5分钟内错误率>5%自动回滚
灰度策略: Argo Rollouts, 5%→20%→50%→100%
全量回滚: <30秒, git revert + ArgoCD sync

Q12: [设计题] 如何设计AI训练平台, 支撑100+数据科学家的GPU训练任务?

评分要点: AI场景理解, 资源调度能力, 用户体验考虑

参考答案框架:

平台架构:

┌────────────────────────────────────────────────────┐
│              AI训练平台 (Web UI / JupyterHub)        │
│  创建训练任务 | 查看日志 | TensorBoard | 模型管理      │
└────────────────────────┬───────────────────────────┘
                         │
┌────────────────────────┴───────────────────────────┐
│              任务编排层 (Kubeflow/自研)               │
│  训练Job | 数据处理 | 超参搜索 | 模型评估             │
├────────────────────────┬───────────────────────────┤
│    Volcano调度器         │    K8s + GPU集群           │
│  Gang Scheduling        │  A100/H100节点池            │
│  Fair-share Queue       │  分布式训练(RDMA/NVLink)    │
│  优先级抢占              │  对象存储(训练数据/模型)     │
└────────────────────────┴───────────────────────────┘

核心设计:

1. 资源队列管理 (Volcano)

yaml

apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: team-nlp
spec:
  weight: 30              # NLP团队30%资源份额
  reclaimable: true       # 空闲资源可被回收
  capability:             # 上限
    nvidia.com/gpu: 32

2. 训练任务模板 (PyTorchJob)

yaml

apiVersion: kubeflow.org/v1
kind: PyTorchJob
metadata:
  name: llm-finetune
spec:
  pytorchReplicaSpecs:
    Master:
      replicas: 1
      template:
        spec:
          containers:
          - name: pytorch
            resources:
              limits:
                nvidia.com/gpu: 8
    Worker:
      replicas: 7
      template:
        spec:
          containers:
          - name: pytorch
            resources:
              limits:
                nvidia.com/gpu: 8

3. 关键优化:

数据加载: 训练数据放对象存储, 通过JuiceFS/Alluxio缓存
Checkpoint: 定期存到对象存储, 支持断点续训
GPU监控: DCGM Exporter + Grafana, 实时监控利用率/温度/功耗
弹性训练: Torch Elastic, Worker故障自动重调度
Spot GPU: 非紧急任务使用Spot实例, 成本降低60%

4. 用户体验:

JupyterHub: 在线开发环境, 按需申请GPU
实验跟踪: MLflow/Weights & Biases集成
模型仓库: MLflow Model Registry

Q13: [设计题] 如何设计K8s集群的灾备方案?

评分要点: RPO/RTO理解, 方案完整性

参考答案框架:

灾备目标:
RPO (Recovery Point Objective): 数据丢失容忍度, 目标<15分钟
RTO (Recovery Time Objective): 恢复时间目标, 目标<30分钟
多层灾备方案:
1. 控制平面备份
bash
# etcd定时备份 (每15分钟)
etcdctl snapshot save /backup/etcd-$(date +%Y%m%d-%H%M).db
# 备份到异地对象存储
aws s3 cp /backup/ s3://etcd-backup/ --recursive
2. 应用状态备份 (Velero)
bash
# 备份命名空间+PV数据
velero backup create daily-backup \
  --include-namespaces production \
  --snapshot-volumes \
  --ttl 720h
3. 多集群容灾
主集群: 生产流量
备集群: 异步同步 (GitOps + 数据复制)
流量切换: DNS切换或 GSLB全局负载均衡
4. 故障演练
每月: 单节点故障演练 (ChaosBlade)
每季度: 整集群故障切换演练
每年: 跨区域灾备演练

5. 第四轮: 故障排查与应急

Q14: [场景题] 凌晨2点收到告警: 生产集群50%的Pod处于Pending状态, 你怎么处理?

评分要点: 排查思路系统性, 应急处理能力, 沟通意识

参考答案:

第一步: 快速评估影响 (1分钟)
确认告警范围: 哪些命名空间/服务受影响
查看用户影响: 是否有面向用户的服务不可用
如果P0级影响, 立即拉起War Room, 通知on-call
第二步: 定位Pending原因 (5分钟)
bash
# 批量查看Pending Pod的事件
kubectl get pods -A --field-selector=status.phase=Pending -o wide
kubectl describe pod &lt;pod-name&gt; -n &lt;ns&gt;

# 常见输出及对应:
# "no nodes available" → 节点全部不健康
# "Insufficient cpu/memory" → 资源耗尽
# "node(s) had taint" → 污点问题
# "0/N nodes are available" → 调度器异常
第三步: 根据原因分类处理
情况A: 节点大面积NotReady
bash
kubectl get nodes | grep NotReady | wc -l
# 检查是否网络分区
ping &lt;node-ip&gt;
# 检查kubelet
ssh &lt;node&gt; "systemctl status kubelet && journalctl -u kubelet -n 50"
# 如果是证书过期, 批量更新
情况B: 资源耗尽
bash
kubectl top nodes | sort -k3 -rn | head -10
# 查看是否有异常Pod消耗资源
kubectl top pods -A --sort-by=cpu | head -20
# 临时措施: 驱逐低优先级Pod
# 长期: 扩容节点/优化资源request
情况C: 调度器异常
bash
kubectl logs -n kube-system -l component=kube-scheduler
# 检查调度器leader选举是否正常
kubectl get lease -n kube-system kube-scheduler
第四步: 恢复与复盘
恢复后验证: 所有Pod Running, 服务健康检查通过
撰写故障报告: 时间线、根因、影响范围、改进措施
改进: 添加预防性监控, 优化告警规则

Q15: [场景题] 线上服务突然出现大量502错误, 但Pod状态都是Running, 怎么排查?

评分要点: 分层排查思路, 网络理解深度

参考答案:

分层排查:

Layer 1: 确认Pod健康

bash

# Pod虽然Running, 但容器可能异常
kubectl get pods -o wide | grep &lt;service&gt;
kubectl exec -it &lt;pod&gt; -- curl localhost:8080/health
# 检查容器是否重启
kubectl get pods -o json | jq '.status.containerStatuses[].restartCount'

Layer 2: 检查Endpoint

bash

# Endpoint是否正确?
kubectl get endpoints &lt;service-name&gt;
# 如果endpoint为空: 可能是readiness probe失败
kubectl describe pod &lt;pod&gt; | grep -A5 "Conditions"
# Ready=False 说明readiness probe不通过

Layer 3: 检查Service/Ingress

bash

# Service端口映射是否正确
kubectl get svc &lt;service&gt; -o yaml
# Ingress/网关配置
kubectl get ingress &lt;name&gt; -o yaml
# 检查ingress controller日志
kubectl logs -n ingress-nginx -l app=ingress-nginx | tail -50

Layer 4: 检查网络链路

bash

# 从另一个Pod测试
kubectl run debug --rm -it --image=busybox -- sh
# 测试DNS
nslookup &lt;service-name&gt;.&lt;namespace&gt;.svc.cluster.local
# 测试连接
wget -qO- http://&lt;service&gt;:8080/health
# 测试IP直连
wget -qO- http://&lt;pod-ip&gt;:8080/health

常见根因:

应用假死: Running但无法处理请求 → 检查应用日志, OOM, GC
Readiness probe配置错误: 端口/路径不对
连接数耗尽: 后端keepalive连接堆积
iptables/IPVS规则异常: kube-proxy重启后规则丢失
DNS解析失败: CoreDNS OOM或配置错误

Q16: [场景题] 集群升级K8s版本(如1.27→1.29), 你怎么规划?

评分要点: 升级方案完整性, 风险控制

参考答案:

升级前准备 (提前2周):
阅读Changelog: 关注Breaking Changes, Deprecated APIs
兼容性检查:
bash
# 检查废弃API使用
kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis
# 使用pluto扫描废弃API
pluto detect-helm -o wide
组件兼容性: CNI/CSI/Ingress Controller与新版本兼容
测试环境验证: 先在测试集群完整演练
升级方案 (灰度执行):
1. 升级etcd (如需要): 备份 → 滚动升级 → 验证
2. 升级控制平面: API Server → Controller → Scheduler (逐个升级)
   - 每个组件升级后验证: kubectl get cs
3. 升级kubelet: 按可用区灰度
   - 先升级1个节点, 运行24h观察
   - 再升级20%节点, 观察48h
   - 最后全量升级
4. 升级Addons: CoreDNS, kube-proxy, CNI, CSI
5. 升级kubectl客户端
关键原则:
只跨一个小版本 (1.27→1.28→1.29, 不直接跨两个)
控制平面版本 >= kubelet版本 (永远不能反过来)
每步都有回滚方案
升级窗口避开业务高峰
升级期间冻结部署 (不发布新应用)

6. 第五轮: 管理与软技能

Q17: 你如何推动一个技术方案在团队内落地?

参考答案:

以"GPU共享方案推广"为例:
1. 问题定义 (Why)
数据: GPU利用率仅25%, 月成本¥200万, ¥150万浪费
影响: 阻碍业务扩展, 资源申请审批周期长
2. 方案论证 (What)
调研3个方案: MIG/HAMi/cGPU, 对比表
PoC验证: 选1个推理服务做A/B测试
结果数据: 利用率从25%→65%, 性能无损耗
3. 推动落地 (How)
找到Champion: 先找一个愿意试用的团队
小范围试点: 1个服务, 2周观察
输出文档: 接入指南, FAQ, 最佳实践
技术分享: 全公司Tech Talk
逐步推广: 每周跟进, 解决问题, 收集反馈
4. 度量效果
3个月后: 利用率65%, 月省¥80万, 15个团队接入
复盘: 总结经验, 规划下一阶段优化

Q18: 你如何处理技术分歧? 比如团队对网络方案选型有不同意见?

参考答案:

我的方法论: 数据驱动 + 小规模验证 + 时间盒决策
实际案例: Calico vs Cilium选型争论
Step 1: 明确评估标准 (双方对齐)
性能(吞吐量/延迟), 运维复杂度, 社区活跃度, 学习成本, 迁移成本
Step 2: 各自做PoC (时间盒2周)
Calico PoC: 部署测试集群, 压测, 记录
Cilium PoC: 同样流程
Step 3: 数据对比 (事实说话)
指标 Calico Cilium
1000 Service延迟 0.3ms 0.15ms
5000 Service延迟 2.1ms 0.18ms
运维复杂度低中
迁移成本 0 高
Step 4: 共识决策
新集群: Cilium (性能优势)
旧集群: 维持Calico (迁移成本高, 无明确收益)
双方都接受, 因为基于事实而非观点

指标	Calico	Cilium
1000 Service延迟	0.3ms	0.15ms
5000 Service延迟	2.1ms	0.18ms
运维复杂度	低	中
迁移成本	0	高

Q19: 你如何培养团队成员的技术能力?

参考答案:

1. 分级培养体系:
L1新人: 导师制, 基础任务, 每日1on1
L2成长: 独立负责模块, 参加技术评审, 写技术文档
L3骨干: 带小项目, 做技术分享, 参与架构决策
2. 具体实践:
每周Tech Talk: 轮流分享, 包括故障复盘
轮值On-call: 从Shadow到Primary, 培养应急能力
Code Review: 不仅审代码, 也审YAML和架构方案
技术债务日: 每月一天集中解决技术债
3. 衡量成长:
独立解决问题的比例
技术方案通过评审的质量
故障响应时间和恢复时间

7. 反问环节

高质量反问推荐 (选2-3个)

团队结构: "这个岗位所在的团队结构是怎样的? 架构师和SRE、开发团队的协作模式是什么?"
技术挑战: "目前平台面临的最大技术挑战是什么? 期望这个岗位在入职3个月内解决什么问题?"
技术栈: "目前用的K8s版本和主要组件是什么? 有没有在做多集群或者GPU相关的探索?"
发展方向: "这个岗位的晋升路径是怎样的? 团队未来的技术规划是什么方向?"
文化: "团队的技术决策流程是怎样的? 架构评审是怎么做的?"

反问禁区

"我不加班" (可以问: "团队的工作节奏是怎样的?")
"年终奖多少" (可以问: "薪酬结构中绩效占比如何?")
"能不能远程" (可以问: "团队的协作方式是怎样的?")

8. 面试评分卡

候选人评估表

评估维度	评分(1-5)	权重	备注
K8s基础知识	__/5	15%	Pod/Service/调度/网络
架构设计能力	__/5	20%	方案完整性, trade-off分析
故障排查能力	__/5	20%	系统性思路, 根因分析
GPU/异构计算	__/5	10%	GPU方案, 分布式训练
生产经验	__/5	15%	集群规模, 真实案例
沟通表达	__/5	10%	逻辑清晰, 引导对话
学习能力	__/5	5%	技术热情, 行业视野
管理潜力	__/5	5%	推动力, 培养他人
总分	__/5	100%

评分标准

分数	含义	描述
5	精通	远超期望, 能给出独到见解和深度洞察
4	熟练	达到期望, 答案完整准确, 有实战经验
3	掌握	基本达到, 知识面OK但缺少深度
2	了解	略低于期望, 只知道概念缺少实践
1	不了解	远低于期望, 无法回答

录用建议

Strong Hire (4.0+): 各维度均>=4, 至少有2个维度为5
Hire (3.5+): 核心维度(架构+排查+经验)>=4
Weak Hire (3.0-3.5): 有潜力但需培养, 可降级录用
No Hire (❤️.0): 核心能力不达标

附录: 面试准备Checklist

面试前一周

[ ] 复习K8s核心概念 (Pod生命周期, 调度, 网络, 存储)
[ ] 准备3-5个STAR格式的项目案例
[ ] 复习自己处理过的最难的3个故障
[ ] 准备1-2个系统设计案例 (画架构图)
[ ] 了解目标公司的技术栈和业务特点
[ ] 准备5个高质量反问

面试前一天

[ ] 复习面试手册中的高频考点
[ ] 准备自我介绍 (2分钟版本)
[ ] 检查网络连接和设备
[ ] 准备纸笔 (画架构图用)
[ ] 早点休息

面试当天

[ ] 提前15分钟到场/上线
[ ] 带上简历和笔记
[ ] 准备好水
[ ] 心态放松, 当作技术交流

面试核心心法:
STAR法则: Situation(背景) → Task(任务) → Action(行动) → Result(结果+数据)
先总后分: 先给结论, 再展开细节
主动引导: 把话题引向自己擅长的领域
诚实为上: 不会的坦诚说, 但补充"我的理解是..."或"我会这样排查..."
数据说话: 每个案例都带数据 (规模/提升百分比/金额)

本手册配合面试手册一起使用祝面试顺利!

Kubernetes 架构师模拟面试手册 ​

目录 ​

1. 面试流程概述 ​

典型面试流程 (4-5轮, 总时长约3-4小时) ​

评分维度 ​

2. 第一轮: 基础知识与经验 ​

Q1: 请介绍一下你的K8s相关经验, 管理过的最大集群规模? ​

Q2: K8s中Pod的QoS等级有哪些? 分别在什么场景使用? ​

Q3: 解释一下K8s的声明式API和最终一致性? ​

Q4: kube-proxy的三种模式有什么区别? 生产环境选哪个? ​

Q5: 你们CI/CD流水线是怎么设计的? ​

3. 第二轮: 技术深度 ​

Q6: 详细讲讲你们GPU资源管理是怎么做的? 遇到过什么问题? ​

Q7: etcd的Raft协议怎么工作? 大规模集群如何优化etcd? ​

Q8: Cilium和Calico有什么区别? 你会怎么选? ​

Q9: 讲讲你开发过的Operator? 设计思路是什么? ​

Q10: 如何实现K8s集群的多租户隔离? ​

4. 第三轮: 系统设计与架构 ​

Q11: [设计题] 请设计一个支撑日均10万次部署的K8s平台 ​

Q12: [设计题] 如何设计AI训练平台, 支撑100+数据科学家的GPU训练任务? ​

Q13: [设计题] 如何设计K8s集群的灾备方案? ​

5. 第四轮: 故障排查与应急 ​

Q14: [场景题] 凌晨2点收到告警: 生产集群50%的Pod处于Pending状态, 你怎么处理? ​

Q15: [场景题] 线上服务突然出现大量502错误, 但Pod状态都是Running, 怎么排查? ​

Q16: [场景题] 集群升级K8s版本(如1.27→1.29), 你怎么规划? ​

6. 第五轮: 管理与软技能 ​

Q17: 你如何推动一个技术方案在团队内落地? ​

Q18: 你如何处理技术分歧? 比如团队对网络方案选型有不同意见? ​

Q19: 你如何培养团队成员的技术能力? ​

7. 反问环节 ​

高质量反问推荐 (选2-3个) ​

反问禁区 ​

8. 面试评分卡 ​

候选人评估表 ​

评分标准 ​

录用建议 ​

附录: 面试准备Checklist ​

面试前一周 ​

面试前一天 ​

面试当天 ​

Kubernetes 架构师模拟面试手册

目录

1. 面试流程概述

典型面试流程 (4-5轮, 总时长约3-4小时)

评分维度

2. 第一轮: 基础知识与经验

Q1: 请介绍一下你的K8s相关经验, 管理过的最大集群规模?

Q2: K8s中Pod的QoS等级有哪些? 分别在什么场景使用?

Q3: 解释一下K8s的声明式API和最终一致性?

Q4: kube-proxy的三种模式有什么区别? 生产环境选哪个?

Q5: 你们CI/CD流水线是怎么设计的?

3. 第二轮: 技术深度

Q6: 详细讲讲你们GPU资源管理是怎么做的? 遇到过什么问题?

Q7: etcd的Raft协议怎么工作? 大规模集群如何优化etcd?

Q8: Cilium和Calico有什么区别? 你会怎么选?

Q9: 讲讲你开发过的Operator? 设计思路是什么?

Q10: 如何实现K8s集群的多租户隔离?

4. 第三轮: 系统设计与架构

Q11: [设计题] 请设计一个支撑日均10万次部署的K8s平台

Q12: [设计题] 如何设计AI训练平台, 支撑100+数据科学家的GPU训练任务?

Q13: [设计题] 如何设计K8s集群的灾备方案?

5. 第四轮: 故障排查与应急

Q14: [场景题] 凌晨2点收到告警: 生产集群50%的Pod处于Pending状态, 你怎么处理?

Q15: [场景题] 线上服务突然出现大量502错误, 但Pod状态都是Running, 怎么排查?

Q16: [场景题] 集群升级K8s版本(如1.27→1.29), 你怎么规划?

6. 第五轮: 管理与软技能

Q17: 你如何推动一个技术方案在团队内落地?

Q18: 你如何处理技术分歧? 比如团队对网络方案选型有不同意见?

Q19: 你如何培养团队成员的技术能力?

7. 反问环节

高质量反问推荐 (选2-3个)

反问禁区

8. 面试评分卡

候选人评估表

评分标准

录用建议

附录: 面试准备Checklist

面试前一周

面试前一天

面试当天