Kubernetes 架构师面试手册

最后更新: 2026年8月 | 适用K8s版本: 1.28+

1. 角色定位与日常职责

1.1 K8s架构师的核心定位

K8s架构师 = 基础设施设计者 + 平台能力输出者 + 成本优化推动者 + 稳定性守护者

维度	职责范围	交付物
架构设计	集群规划、多集群管理、网络方案选型、存储方案设计	架构设计文档、技术方案评审
平台建设	容器平台PaaS建设、CI/CD流水线、自动化运维体系	平台产品、自动化工具链
稳定性保障	SLA保障、故障演练、容量规划、灾备方案	SLO/SLI定义、故障复盘报告
成本优化	资源利用率提升、弹性伸缩策略、Spot实例管理	月度成本分析报告
技术赋能	技术培训、最佳实践推广、疑难问题攻关	技术分享、最佳实践文档
安全合规	安全策略制定、镜像扫描、RBAC管理、审计日志	安全合规报告

1.2 一天典型工作

08:30-09:00 查看监控大盘 (Grafana/Prometheus), 巡检集群健康状态
09:00-09:30 站会 (Standup) - 同步昨日进展、今日计划、阻塞项
09:30-11:30 深度工作时间 - 架构方案设计/技术难点攻关/代码Review
11:30-12:00 处理工单/审批/跨团队技术协作
13:30-14:30 技术方案评审会 / 架构评审会
14:30-16:30 平台开发/工具建设/故障排查支持
16:30-17:30 容量规划/成本分析/优化方案推进
17:30-18:00 日报/周报整理, 知识库更新

1.3 与相关角色的协作

CTO/VP (战略决策) → K8s架构师 (技术决策中枢) → SRE/运维(集群运维) + 开发团队(业务方) + 安全/合规团队(安全审计)

2. 日常工作与汇报体系

2.1 日常工作内容矩阵

第一层: 稳定性保障 (每日必做)

工作项	具体内容	频率	工具
集群巡检	节点健康、Pod状态、资源水位	每日	Prometheus + Grafana
告警处理	处理P0-P3级别告警	实时	AlertManager + PagerDuty
容量监控	CPU/内存/磁盘/网络使用率	每日	VPA推荐 + HPA指标
安全巡检	镜像漏洞、RBAC变更、网络策略	每日	Trivy + Falco
备份验证	etcd快照、PV数据备份	每周	Velero

第二层: 平台建设与优化 (每周推进)

工作项	具体内容	交付周期
K8s版本升级	灰度升级计划、兼容性测试、回滚方案	每季度
新功能落地	评估新特性、PoC验证、推广方案	每月
自动化工具	Operator开发、CLI工具、自动化脚本	持续
性能调优	调度优化、网络优化、存储优化	每月
文档维护	运维手册、故障处理SOP、架构文档	持续

第三层: 战略规划 (每月/每季度)

工作项	具体内容	汇报对象
容量规划	未来3-6个月资源需求预测	VP/CTO
成本优化	资源利用率分析、降本方案	CFO/VP
技术选型	新组件/新方案评估	技术委员会
多集群战略	混合云/多云/边缘节点规划	CTO

2.2 汇报体系

日报模板

集群概况: 集群数量、节点数、Pod数、整体可用率
今日告警: P0/P1/P2次数, 重点告警详情
今日工作: 进行中/已完成/阻塞中
明日计划
需要协调事项

周报关键指标

指标	目标	实际	趋势
API Server可用性	99.95%	99.98%	上升
Pod启动P99延迟	<30s	22s	平稳
节点故障率	<0.5%	0.2%	下降
部署成功率	>99%	99.5%	平稳
资源利用率(CPU)	40-60%	52%	上升
资源利用率(MEM)	50-70%	61%	平稳

月度/季度汇报 (面向管理层)

执行摘要 (一句话总结)
关键成果 (完成的项目)
成本分析 (总成本、单位请求成本、资源浪费率)
风险与应对 (风险矩阵)
下月规划 (重点项目)

3. 资源管理方案 (CPU/内存/GPU)

3.1 CPU 资源管理

3.1.1 CPU调度策略全景

请求保障: requests, Guaranteed, Burstable, BestEffort
限制管控: limits, CPU Throttle, CFS Quota, CPU Manager
弹性调度: HPA, VPA, Cluster Autoscaler
高级策略: NUMA感知, CPU绑核, 拓扑管理, 干扰检测

3.1.2 QoS等级与CPU分配

yaml

# QoS Guaranteed - 延迟敏感型核心服务
# requests == limits
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: api
    resources:
      requests:
        cpu: "4"
        memory: "8Gi"
      limits:
        cpu: "4"
        memory: "8Gi"

# QoS Burstable - 常规业务服务
# requests < limits
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: web
    resources:
      requests:
        cpu: "1"
        memory: "2Gi"
      limits:
        cpu: "4"
        memory: "4Gi"

# QoS BestEffort - 批处理/测试任务
# 无requests/limits
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: worker
    resources: {}

3.1.3 CPU Manager 策略

kubelet配置:

cpuManagerPolicy: none (默认) - 通用Web服务, 灵活但有上下文切换
cpuManagerPolicy: static - 延迟敏感/高性能, CPU绑核, 需要Guaranteed QoS
static + full-pcpus-only (1.22+) - NFV/DPDK场景, 分配完整物理核
static + distribute-cpus-across-numa - 跨NUMA均匀分配
static + align-by-socket (1.28+) - 按Socket对齐

3.1.4 Topology Manager (NUMA感知)

none - 不做拓扑对齐, 普通业务
best-effort - 尽量对齐, 不对齐也调度, 大多数场景
restricted - 必须对齐, 否则拒绝调度, 性能敏感服务
single-numa-node - 所有资源必须在同一NUMA节点, 极致性能要求

Scope: container (按容器) 或 pod (按Pod整体)

3.1.5 HPA (水平自动伸缩)

yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-service
  minReplicas: 3
  maxReplicas: 50
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60     # 60秒内稳定才扩
      policies:
      - type: Pods
        value: 5                         # 每次最多扩5个
        periodSeconds: 60
      - type: Percent
        value: 30                        # 或当前副本数的30%
        periodSeconds: 60
      selectPolicy: Max
    scaleDown:
      stabilizationWindowSeconds: 300    # 5分钟内稳定才缩
      policies:
      - type: Pods
        value: 2                         # 每次最多缩2个
        periodSeconds: 120
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 65
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "1000"

3.1.6 Cluster Autoscaler (节点级伸缩)

关键参数:

--expander=least-waste - 扩展策略: least-waste/random/most-pods/priority
--balance-similar-node-groups - 均衡相似节点组
--scale-down-delay-after-add=10m - 扩容后10分钟不缩
--scale-down-unneeded-time=10m - 10分钟不需要才缩
--scale-down-utilization-threshold=0.5 - 节点利用率<50%触发缩容

3.1.7 VPA (垂直自动伸缩)

updateMode: "Off" (只推荐) | "Initial" (仅创建时) | "Recreate" (重建) | "Auto"
注意: VPA和HPA不能同时基于CPU/Memory使用
生产建议: VPA用Off模式只做推荐, 人工调整后更新request/limit

3.2 内存资源管理

3.2.1 内存管理全景

请求保障: requests, Guaranteed, NUMA本地内存, 预留策略
限制管控: limits, OOM Kill, memory.qos, cgroup v2
优化策略: HugePages, Swap(alpha), 内存去重KSM, 共享内存管理
故障处理: OOM处理, 内存回收, 优雅降级, 故障隔离

3.2.2 OOM Kill 优先级

当节点内存压力增大时:

首先回收page cache (inactive_anon/inactive_file)
然后对超过requests的Pod进行内存限流 (memory.high)
最后按优先级OOM Kill:
- BestEffort → Burstable (超request部分) → Guaranteed

oom_score_adj:

Guaranteed Pod: -998 (最低)
Burstable Pod: 2~999
BestEffort Pod: 1000 (最高, 最先被kill)

3.2.3 大页内存 (HugePages)

适用于: 数据库(MySQL/PostgreSQL), DPDK, JVM大堆等

yaml

spec:
  containers:
  - name: app
    resources:
      limits:
        hugepages-2Mi: "100Mi"      # 50个2MB大页
        hugepages-1Gi: "2Gi"        # 2个1GB大页
    volumeMounts:
    - name: hugepage
      mountPath: /hugepages
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

3.2.4 Swap支持 (K8s 1.28+ GA)

NoSwap (默认) - 不使用swap, 生产环境
LimitedSwap - 有限使用swap, 开发/测试环境, 提高部署密度

3.3 GPU 资源管理 (重点!)

3.3.1 GPU管理方案全景图

类别	方案	说明
原生支持	Device Plugin	整卡分配, 最小粒度1卡
共享GPU	vGPU/cGPU, HAMi, GPU Share	显存/算力切分
高级调度	拓扑感知, Gang Scheduling, Binpack, 优先级抢占	AI训练优化
虚拟化	NVIDIA MIG, SRIOV GPU, Kata + GPU Passthrough	硬件级隔离

3.3.2 方案一: 原生Device Plugin (整卡分配)

yaml

# NVIDIA Device Plugin 关键配置
env:
- name: MIG_STRATEGY
  value: "none"                 # none | single | mixed
- name: MPS_ENABLE
  value: "false"

# Pod使用GPU
spec:
  containers:
  - name: trainer
    resources:
      limits:
        nvidia.com/gpu: 2       # 请求2块完整GPU
    env:
    - name: NVIDIA_VISIBLE_DEVICES
      value: "all"
    - name: NVIDIA_DRIVER_CAPABILITIES
      value: "compute,utility"

优点: 简单可靠, 无性能损耗, 完整CUDA兼容
缺点: 最小粒度1卡, 推理场景利用率低, 资源浪费严重
适用: 大规模训练, 独占GPU的推理服务

3.3.3 方案二: NVIDIA MIG (Multi-Instance GPU)

A100/H100专用, 硬件级隔离:

Profile	SM数量	HBM	适用场景
1g.10gb	1/7	10GB	轻量推理, 开发测试
2g.20gb	2/7	20GB	中等推理, 小模型微调
3g.40gb	3/7	40GB	中等训练, 大模型推理
4g.40gb	4/7	40GB	大模型训练
7g.80gb	7/7	80GB	整卡 (不切分)

yaml

# 启用MIG
env:
- name: MIG_STRATEGY
  value: "mixed"

# Pod使用MIG实例
spec:
  containers:
  - name: inference
    resources:
      limits:
        nvidia.com/mig-1g.10gb: 1   # 1个1g.10gb的MIG实例

优点: 硬件级隔离, 性能可预测, 独立ECC/安全
缺点: 仅支持A100/H100, 切分配置固定, 不够灵活

3.3.4 方案三: GPU共享 (vGPU/显存切分)

方案	原理	隔离级别	性能损耗	来源
cGPU (阿里云)	CUDA拦截+显存/算力切分	进程级	❤️%	阿里云
HAMi	Device Plugin+调度器扩展	进程级	<5%	开源(火山引擎)
GPU Share (腾讯)	vGPU虚拟化	设备级	5-10%	腾讯云
virtAI (趋动科技)	CUDA Runtime拦截	进程级	<5%	商业
NVIDIA MPS	多进程共享SM	进程级	极低	NVIDIA

HAMi方案示例:

yaml

# HAMi调度器配置
# 每卡最多切分10份, 支持显存和算力独立切分
spec:
  schedulerName: hami-scheduler
  containers:
  - name: inference
    resources:
      limits:
        nvidia.com/gpu: 1             # 共享1块GPU
        nvidia.com/gpumem: 4096       # 4GB显存
        nvidia.com/gpucores: 30       # 30%算力

3.3.5 方案四: MPS (Multi-Process Service)

多个进程共享同一个GPU的CUDA上下文
避免上下文切换开销
MPS支持Active Thread Percentage控制算力
适用: 多个小推理服务共享一块GPU

3.3.6 GPU拓扑感知调度

关键概念:

NVLink全互联: 600GB/s bidir (A100)
NVSwitch: GPU间全互联交换
PCIe带宽: 仅32GB/s (Gen4 x16)
跨NUMA通信: 走QPI/UPI, 带宽更低

调度策略:

优先将分布式训练的GPU调度到同一NVSwitch域
使用Volcano的Gang Scheduling确保所有Worker同时调度
通过自定义标签标记GPU拓扑, 用nodeAffinity约束

yaml

# Gang Scheduling + 拓扑约束
apiVersion: scheduling.volcano.sh/v1beta1
kind: PodGroup
metadata:
  name: distributed-training
spec:
  minMember: 4
  queue: gpu-queue
  priorityClassName: high-priority

3.3.7 GPU资源管理方案选型决策树

需要GPU?
  |
  是大规模训练(整卡)? -- Yes --> Device Plugin (整卡分配)
  |
  No --> 推理/小任务?
           |
       Yes --> GPU型号?
       |       |
       |    A100/H100 --> MIG切分 (硬件隔离)
       |       |
       |    其他GPU --> HAMi/cGPU (软件切分)
       |
       No --> GPU共享 (HAMi/cGPU)

3.4 综合资源调度方案

3.4.1 调度框架选型

框架	定位	特性	适用场景
kube-scheduler	默认调度器	通用调度, 插件化	大多数场景
Volcano	批处理调度器	Gang/Fair-share/队列	AI训练, 大数据
YuniKorn	多租户调度器	层级队列, 抢占	多租户平台
Koordinator	混部调度器	在离线混部, 干扰检测	资源利用率提升
Karpenter	节点供给	按需供给节点, Binpack	云原生弹性

3.4.2 混部方案 (在离线混合部署)

在线服务 (LS/LR): requests 40%, limits 60%, 高优先级, 延迟敏感
离线任务 (BE): 使用在线任务未使用的资源, 可被随时驱逐
Koordinator Agent: 实时监控在线服务延迟, 动态压制离线任务资源
效果: 资源利用率从30%提升到60%+

4. 常见生产问题与解决方案

4.1 网络类问题

问题1: Pod间通信延迟高/丢包

现象: Pod间RPC调用P99延迟从5ms飙升到500ms, TCP重传率 > 1%

排查步骤:

基础连通性: kubectl exec -it <pod> -- ping -c 100 <target-ip>
检查conntrack表: conntrack -C 对比 nf_conntrack_max
检查IPVS规则: ipvsadm -ln | grep <service-ip>
抓包分析: tcpdump -i eth0 -w /tmp/capture.pcap host <target-ip>

原因	解决方案
conntrack表满	`sysctl -w net.netfilter.nf_conntrack_max=262144`
IPVS连接超时	调整 `--ipvs-conntrack-idle-timeout`
内核参数不优	调优tcp_keepalive, somaxconn等
Calico IPIP封装开销	同网段改用BGP Direct Routing
DNS解析延迟	启用NodeLocal DNSCache

问题2: Service负载均衡不均匀

现象: 某些Pod接收请求量远超其他Pod

原因	解决方案
连接复用导致倾斜	启用keepalive连接池, 缩短idle timeout
kube-proxy RR不均	切换到IPVS wrr/wlc算法
Session Affinity	如无必要关闭会话保持
客户端连接不释放	客户端侧添加连接超时

4.2 存储类问题

问题3: PV挂载超时/PVC Pending

排查:

kubectl get pvc -A | grep -v Bound
kubectl describe pvc <name> - 查看事件
kubectl get pods -n kube-system | grep csi - 检查CSI插件
kubectl describe sc <name> - 检查StorageClass

原因	解决方案
云盘配额用完	扩容云盘配额
CSI插件异常	重启CSI driver
AccessMode不匹配	确认RWO/ROX/RWX与存储后端匹配
AZ不一致	Pod调度到与PV相同的可用区
回收策略冲突	确认ReclaimPolicy

4.3 调度类问题

问题4: Pod长期Pending

排查:

kubectl describe pod <pod-name> - 查看Events
kubectl top nodes - 检查节点资源
kubectl get nodes -o json | jq '.items[].spec.taints' - 检查污点
kubectl get pdb -A - 检查PDB

原因	解决方案
资源不足	扩容节点/优化request/启用CA
污点不匹配	添加tolerations或移除taint
亲和性冲突	调整nodeAffinity/podAffinity
PVC未绑定	先解决存储问题
PDB阻止	检查PDB配置

问题5: 节点NotReady

排查:

journalctl -u kubelet -n 100 --no-pager - kubelet日志
systemctl status containerd - 容器运行时
df -h && df -i && free -m - 磁盘/内存/inode
curl -k https://<apiserver>:6443/healthz - API连通性

原因	解决方案
kubelet挂掉	`systemctl restart kubelet`
磁盘满/inode满	清理日志/镜像/旧容器
containerd挂掉	`systemctl restart containerd`
PLEG异常	重启kubelet, 检查pod lifecycle
证书过期	更新kubelet证书
CNI异常	重启CNI plugin

4.4 性能类问题

问题6: API Server响应慢

排查:

kubectl get --raw /metrics | grep apiserver_request_duration
etcdctl endpoint health --cluster - etcd健康
kubectl get pods -A --no-headers | wc -l - 资源数量

优化方案:

方案	具体操作
etcd优化	SSD存储, 定期compaction/defrag, 分离events etcd
API Server调参	`--max-requests-inflight=3000`
资源清理	清理过期Events, Jobs, Completed Pods
APF	启用API Priority and Fairness

4.5 安全类问题

问题7: 容器逃逸风险

排查:

检查特权容器: privileged == true
检查hostPath挂载
检查hostNetwork/hostPID

防护: Pod Security Standards (K8s 1.25+ GA)

enforce: restricted - 强制执行
audit: restricted - 审计记录
warn: restricted - 告警提示

5. 高难度问题深度剖析

5.1 最难问题: 大规模集群etcd性能瓶颈

背景: 集群规模5000+节点, 150,000+ Pod, etcd写入P99延迟 > 500ms

根因分析:

大量Pod状态更新 → etcd写入压力
etcd单个boltdb文件过大(>8GB) → 读写性能下降
未分离events etcd → 高频小写入冲击主etcd
kubelet node status更新频率过高(10s) → 雪崩式更新
Controller Manager reconcile频率过高

解决过程:

Step 1: 紧急缓解

bash

ETCDCTL_API=3 etcdctl compact <revision>
ETCDCTL_API=3 etcdctl defrag --endpoints=https://etcd-1:2379

Step 2: kubelet优化

nodeStatusUpdateFrequency: 30s (默认10s)
nodeStatusReportFrequency: 5m

Step 3: 分离events etcd

--etcd-servers-overrides=/events#https://etcd-events:2379

Step 4: Controller优化

--node-monitor-grace-period=60s (默认40s)
--horizontal-pod-autoscaler-sync-period=30s (默认15s)

Step 5: 启用APF (API Priority and Fairness)

为系统组件、普通用户、控制器分别设置优先级和限流

Step 6: etcd存储升级

将etcd数据盘升级到NVMe SSD
etcd对磁盘I/O极其敏感, fsync p99应 < 10ms

最终效果:

指标	优化前	优化后
etcd写入P99	500ms+	<20ms
API Server P99	3s	<200ms
Pod调度延迟	2min+	<10s

5.2 GPU集群分布式训练故障

背景: 64卡A100分布式训练(PyTorch DDP), 速度仅为单卡的8倍(理论55-60倍)

排查过程:

nvidia-smi -q -d UTILIZATION → GPU利用率波动30%-95%
NCCL_DEBUG=INFO → "Failed to use NVLink, fallback to PCIe"
nvidia-smi topo -m → Worker-2的GPU跨NUMA节点
kubectl get pods -o wide → Pod被调度到NUMA边界

根因: kube-scheduler不感知GPU NUMA拓扑, Worker-2跨NUMA导致NVLink无法全互联

解决方案:

启用Topology Manager: topologyManagerPolicy: single-numa-node
启用CPU Manager: cpuManagerPolicy: static
使用Volcano调度器的拓扑感知
添加GPU拓扑标签, 用nodeAffinity约束调度
Gang Scheduling确保所有Worker同时调度

效果: 训练速度从8x提升到52x, 接近理论性能

5.3 大规模滚动升级导致服务雪崩

背景: 核心微服务(2000个Pod)滚动升级, maxUnavailable=25%

问题链:

500个Pod同时Terminating, 优雅关闭需30s
Endpoint Controller批量移除endpoint
剩余Pod突然接收5x流量, CPU飙升到95%
部分Pod OOM, HPA扩容但新Pod Pending
级联故障, 依赖服务超时

解决方案:

滚动策略: maxUnavailable: 0, maxSurge: 25% (先扩后缩)
preStop Hook: 先从LB摘除, sleep 30s等待endpoint更新
PDB保护: maxUnavailable: 5%
HPA预热: 升级前调高minReplicas
Istio流量权重渐进: 新版本10%→50%→100%

5.4 节点内存泄漏导致集群不稳定

背景: 多个节点每隔48-72小时出现MemoryPressure

排查:

slabtop -o → dentry/inode缓存持续增长 (48h从2GB到15GB)
根因: 监控Agent频繁扫描所有容器的/proc文件系统

解决方案:

sysctl -w vm.vfs_cache_pressure=200 (加大回收压力)
修复监控Agent扫描频率
kubelet eviction配置优化:
- evictionHard.memory.available: 500Mi
- evictionSoft.memory.available: 1Gi
- evictionSoftGracePeriod.memory.available: 5m
添加slab内存监控告警

6. 核心知识图谱

6.1 K8s架构师技能矩阵

Level 5 (精通):

集群架构设计与多集群管理
自定义Controller/Operator开发
大规模集群性能调优 (5000+节点)
GPU/异构计算资源管理
故障诊断与根因分析

Level 4 (熟练):

CNI网络方案 (Calico/Cilium/Flannel)
CSI存储方案 (Ceph/NFS/云盘)
服务网格 (Istio/Linkerd)
CI/CD流水线设计 (ArgoCD/Tekton)
监控告警体系 (Prometheus/Grafana)

Level 3 (掌握):

调度器原理与扩展
RBAC与安全策略
HPA/VPA/Cluster Autoscaler
Helm/Kustomize包管理
日志采集与分析 (EFK/Loki)

Level 2 (了解):

K8s核心概念 (Pod/Service/Deployment)
YAML编写与kubectl使用
Linux基础与网络知识
Docker容器基础

6.2 关键技术栈

领域	技术选型
容器运行时	containerd, CRI-O
网络	Calico, Cilium, Flannel, Multus, Istio
存储	Ceph, Rook, NFS, Longhorn
调度	Volcano, Karpenter, YuniKorn, Koordinator
可观测性	Prometheus, Grafana, Loki, Jaeger, OpenTelemetry
安全	OPA, Falco, Trivy, Kyverno, Pod Security Standards
CI/CD	ArgoCD, Tekton, Jenkins, Flux, GitHub Actions
平台	Rancher, KubeSphere, KubeVela, Kratix
工具	Helm, Kustomize, Terraform, kubectl, k9s
云厂商	AWS EKS, Aliyun ACK, Tencent TKE, Azure AKS, GCP GKE

7. 面试高频考点速查

7.1 必会概念 (快问快答)

问题	要点
Pod的生命周期	Pending → Running → Succeeded/Failed
Deployment vs StatefulSet	无状态vs有状态, 稳定网络标识, 有序部署
Service类型	ClusterIP/NodePort/LoadBalancer/ExternalName
Ingress vs Gateway API	Ingress是v1beta1, Gateway API是新标准
RBAC四种资源	Role/ClusterRole + RoleBinding/ClusterRoleBinding
CRD是什么	Custom Resource Definition, 扩展K8s API
Operator模式	CRD + Controller = 自动化运维
最终一致性	K8s声明式API的核心, reconcile循环
etcd作用	K8s状态存储, Raft一致性协议
CNI/CRI/CSI	容器网络/运行时/存储接口标准

7.2 设计类问题模板

Q: 如何设计一个支撑10000节点的K8s集群?

答题框架:

控制平面高可用: API Server 3-5实例+LB, etcd 5节点+NVMe SSD+events分离
网络方案: Cilium(eBPF), 分层网络, IPVS模式
存储方案: Ceph RBD(块), CephFS(文件), MinIO(对象)
调度与资源: 多调度器, 混部, Cluster Autoscaler + Karpenter
可观测性: Thanos+多Prometheus, Loki, OpenTelemetry
安全: NetworkPolicy, 镜像扫描, 审计日志, Falco

7.3 薪资参考 (2025-2026)

级别	经验	年薪范围(国内)	关键能力
初级K8s工程师	1-3年	25-45万	K8s运维, 基础排障
中级K8s工程师	3-5年	45-70万	平台建设, 中级排障
高级K8s工程师	5-8年	70-100万	架构设计, 大规模运维
K8s架构师	8年+	100-150万+	全局架构, 技术决策
首席/Staff	10年+	150-200万+	技术战略, 行业标准

面试时重点展示:
问题诊断能力: 从现象到根因的系统性排查思路
方案设计能力: 权衡trade-off, 给出多个方案并说明取舍
实战经验: 真实案例, 具体数据, 实际效果
全局视野: 不仅懂技术细节, 还要理解业务和成本

本手册配合模拟面试手册一起使用

Kubernetes 架构师面试手册 ​

目录 ​

1. 角色定位与日常职责 ​

1.1 K8s架构师的核心定位 ​

1.2 一天典型工作 ​

1.3 与相关角色的协作 ​

2. 日常工作与汇报体系 ​

2.1 日常工作内容矩阵 ​

第一层: 稳定性保障 (每日必做) ​

第二层: 平台建设与优化 (每周推进) ​

第三层: 战略规划 (每月/每季度) ​

2.2 汇报体系 ​

日报模板 ​

周报关键指标 ​

月度/季度汇报 (面向管理层) ​

3. 资源管理方案 (CPU/内存/GPU) ​

3.1 CPU 资源管理 ​

3.1.1 CPU调度策略全景 ​

3.1.2 QoS等级与CPU分配 ​

3.1.3 CPU Manager 策略 ​

3.1.4 Topology Manager (NUMA感知) ​

3.1.5 HPA (水平自动伸缩) ​

3.1.6 Cluster Autoscaler (节点级伸缩) ​

3.1.7 VPA (垂直自动伸缩) ​

3.2 内存资源管理 ​

3.2.1 内存管理全景 ​

3.2.2 OOM Kill 优先级 ​

3.2.3 大页内存 (HugePages) ​

3.2.4 Swap支持 (K8s 1.28+ GA) ​

3.3 GPU 资源管理 (重点!) ​

3.3.1 GPU管理方案全景图 ​

3.3.2 方案一: 原生Device Plugin (整卡分配) ​

3.3.3 方案二: NVIDIA MIG (Multi-Instance GPU) ​

3.3.4 方案三: GPU共享 (vGPU/显存切分) ​

3.3.5 方案四: MPS (Multi-Process Service) ​

3.3.6 GPU拓扑感知调度 ​

3.3.7 GPU资源管理方案选型决策树 ​

3.4 综合资源调度方案 ​

3.4.1 调度框架选型 ​

3.4.2 混部方案 (在离线混合部署) ​

4. 常见生产问题与解决方案 ​

4.1 网络类问题 ​

问题1: Pod间通信延迟高/丢包 ​

问题2: Service负载均衡不均匀 ​

4.2 存储类问题 ​

问题3: PV挂载超时/PVC Pending ​

4.3 调度类问题 ​

问题4: Pod长期Pending ​

问题5: 节点NotReady ​

4.4 性能类问题 ​

问题6: API Server响应慢 ​

4.5 安全类问题 ​

问题7: 容器逃逸风险 ​

5. 高难度问题深度剖析 ​

5.1 最难问题: 大规模集群etcd性能瓶颈 ​

5.2 GPU集群分布式训练故障 ​

5.3 大规模滚动升级导致服务雪崩 ​

5.4 节点内存泄漏导致集群不稳定 ​

6. 核心知识图谱 ​

6.1 K8s架构师技能矩阵 ​

6.2 关键技术栈 ​

7. 面试高频考点速查 ​

7.1 必会概念 (快问快答) ​

7.2 设计类问题模板 ​

7.3 薪资参考 (2025-2026) ​

Kubernetes 架构师面试手册

目录

1. 角色定位与日常职责

1.1 K8s架构师的核心定位

1.2 一天典型工作

1.3 与相关角色的协作

2. 日常工作与汇报体系

2.1 日常工作内容矩阵

第一层: 稳定性保障 (每日必做)

第二层: 平台建设与优化 (每周推进)

第三层: 战略规划 (每月/每季度)

2.2 汇报体系

日报模板

周报关键指标

月度/季度汇报 (面向管理层)

3. 资源管理方案 (CPU/内存/GPU)

3.1 CPU 资源管理

3.1.1 CPU调度策略全景

3.1.2 QoS等级与CPU分配

3.1.3 CPU Manager 策略

3.1.4 Topology Manager (NUMA感知)

3.1.5 HPA (水平自动伸缩)

3.1.6 Cluster Autoscaler (节点级伸缩)

3.1.7 VPA (垂直自动伸缩)

3.2 内存资源管理

3.2.1 内存管理全景

3.2.2 OOM Kill 优先级

3.2.3 大页内存 (HugePages)

3.2.4 Swap支持 (K8s 1.28+ GA)

3.3 GPU 资源管理 (重点!)

3.3.1 GPU管理方案全景图

3.3.2 方案一: 原生Device Plugin (整卡分配)

3.3.3 方案二: NVIDIA MIG (Multi-Instance GPU)

3.3.4 方案三: GPU共享 (vGPU/显存切分)

3.3.5 方案四: MPS (Multi-Process Service)

3.3.6 GPU拓扑感知调度

3.3.7 GPU资源管理方案选型决策树

3.4 综合资源调度方案

3.4.1 调度框架选型

3.4.2 混部方案 (在离线混合部署)

4. 常见生产问题与解决方案

4.1 网络类问题

问题1: Pod间通信延迟高/丢包

问题2: Service负载均衡不均匀

4.2 存储类问题

问题3: PV挂载超时/PVC Pending

4.3 调度类问题

问题4: Pod长期Pending

问题5: 节点NotReady

4.4 性能类问题

问题6: API Server响应慢

4.5 安全类问题

问题7: 容器逃逸风险

5. 高难度问题深度剖析

5.1 最难问题: 大规模集群etcd性能瓶颈

5.2 GPU集群分布式训练故障

5.3 大规模滚动升级导致服务雪崩

5.4 节点内存泄漏导致集群不稳定

6. 核心知识图谱

6.1 K8s架构师技能矩阵

6.2 关键技术栈

7. 面试高频考点速查

7.1 必会概念 (快问快答)

7.2 设计类问题模板

7.3 薪资参考 (2025-2026)