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

本文档系统梳理高级 K8s 运维工程师所需掌握的核心技能、知识体系及高频面试题，适用于候选人备考与面试官出题参考。

技能全景图
Kubernetes 核心架构
Pod 与工作负载
网络模型与 CNI
存储与 CSI
调度与资源管理
安全与 RBAC
集群部署与升级
可观测性（监控/日志/链路追踪）
Helm 与 GitOps
故障排查与应急响应
高可用与灾备
Service Mesh 与云原生进阶
CI/CD 与 DevOps 实践
多集群与混合云
性能调优
软技能与架构设计
面试高频题 TOP 50

1. 技能全景图

高级 K8s 运维工程师技能树
|-- 基础设施层
|   |-- Linux 系统管理（内核参数、cgroup、namespace、iptables/nftables）
|   |-- 容器运行时（containerd、CRI-O、Docker）
|   |-- 网络基础（TCP/IP、DNS、BGP、VXLAN、负载均衡）
|   +-- 存储基础（文件系统、LVM、NFS、iSCSI、Ceph）
|-- Kubernetes 核心层
|   |-- 集群架构与控制平面组件
|   |-- etcd 运维与调优
|   |-- 工作负载管理（Deployment/StatefulSet/DaemonSet/Job/CronJob）
|   |-- Service/Ingress/Gateway API
|   |-- 存储编排（PV/PVC/StorageClass/CSI）
|   |-- 调度策略（亲和性/污点/优先级/拓扑感知）
|   +-- 安全（RBAC/NetworkPolicy/PodSecurity/Admission Controller）
|-- 运维工具层
|   |-- Helm / Kustomize
|   |-- ArgoCD / Flux（GitOps）
|   |-- Prometheus / Grafana / Alertmanager
|   |-- ELK/EFK/Loki + Fluentd/Fluent Bit
|   |-- Jaeger / OpenTelemetry
|   +-- kubectl / kubectx / krew / k9s
|-- 进阶能力层
|   |-- Service Mesh（Istio/Linkerd）
|   |-- Operator 开发（Kubebuilder/Operator SDK）
|   |-- 集群联邦与多集群管理
|   |-- 自动伸缩（HPA/VPA/KEDA/CA）
|   |-- 安全加固（CIS Benchmark/Falco/Trivy/Kyverno）
|   +-- 混沌工程（Chaos Mesh/Litmus）
+-- 软技能层
    |-- 故障分析与根因定位
    |-- 容量规划与成本优化
    |-- 技术方案设计与文档能力
    +-- 团队协作与 Mentoring

2. Kubernetes 核心架构

2.1 控制平面组件

组件	职责	高频考点
kube-apiserver	RESTful API 入口，所有操作的唯一入口	聚合层、Admission Controller 链、请求处理流程（认证->授权->准入）
etcd	分布式键值存储，保存集群状态	Raft 协议、数据备份恢复、性能调优、脑裂处理
kube-scheduler	Pod 调度	调度框架、调度插件、调度扩展
kube-controller-manager	运行各种控制器	控制器模式（Reconciliation Loop）、Leader Election
cloud-controller-manager	云厂商集成	与 kube-controller-manager 的区别

2.2 节点组件

组件	职责	高频考点
kubelet	节点代理，管理 Pod 生命周期	PLEG、Pod 生命周期事件、健康检查机制
kube-proxy	网络代理	三种模式（userspace/iptables/IPVS）对比、IPVS 原理
容器运行时	运行容器	CRI 接口、containerd 架构、runc 工作原理

2.3 核心概念深度理解

声明式 API vs 命令式 API：

Kubernetes 采用声明式 API，用户描述期望状态（Desired State），控制器不断调谐使其趋近于实际状态（Actual State）
Reconciliation Loop 是 K8s 的核心模式，每个控制器都在不断执行 Watch -> Diff -> Act 循环

Level-triggered vs Edge-triggered：

K8s 使用 Level-triggered 设计：控制器只看当前状态与期望状态的差异，不关心事件触发序列
这意味着即使错过某些事件通知，系统仍能自愈

面试要点 - 从 kubectl apply 到 Pod 运行的完整流程：

1. kubectl 将 YAML 序列化为 JSON，发送 HTTPS 请求到 kube-apiserver
2. apiserver 进行 Authentication（认证身份）-> Authorization（RBAC 鉴权）->
   Mutating Admission（修改资源）-> Schema Validation（校验格式）->
   Validating Admission（校验业务规则）
3. apiserver 将资源写入 etcd
4. 对应的 Controller（如 Deployment Controller）通过 Informer Watch 到变更
5. Deployment Controller 创建 ReplicaSet，ReplicaSet Controller 创建 Pod 对象写入 etcd
6. Scheduler Watch 到 Pending 状态的 Pod，执行调度算法选择 Node，写入 nodeName
7. 目标节点的 kubelet Watch 到有 nodeName 指向自己的 Pod
8. kubelet 通过 CRI 调用容器运行时（如 containerd）创建容器
9. kubelet 上报 Pod 状态给 apiserver，状态变为 Running
10. Endpoint Controller Watch 到 Pod Ready，将其加入 Service 的 Endpoints

3. Pod 与工作负载

3.1 Pod 生命周期

Pending -> Running -> Succeeded/Failed

详细阶段：
1. Pending: Pod 已被接受但未运行（等待调度/拉取镜像）
2. Init Containers: 按顺序执行初始化容器
3. Running: 主容器运行中
   - PostStart Hook: 容器启动后立即执行
   - 健康检查: Liveness/Readiness/Startup Probe
4. Terminating: 收到终止信号
   - PreStop Hook: 优雅终止前执行
   - SIGTERM -> 等待 terminationGracePeriodSeconds -> SIGKILL

3.2 探针（Probes）

探针类型	作用	失败行为
Liveness Probe	检测容器是否存活	重启容器
Readiness Probe	检测容器是否就绪	从 Service Endpoints 移除
Startup Probe	检测容器是否已启动	禁用其他探针直到成功

慢启动应用推荐配置：

yaml

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10
  failureThreshold: 3
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5
  failureThreshold: 3

3.3 工作负载对比

类型	特点	适用场景
Deployment	无状态、滚动更新、回滚	Web 服务、API 服务
StatefulSet	有序部署、稳定网络标识、持久存储	数据库、消息队列
DaemonSet	每节点一个 Pod	日志采集、监控 Agent、网络插件
Job	一次性任务	数据迁移、批处理
CronJob	定时任务	定时备份、报表生成

3.4 更新策略

Deployment 滚动更新：

maxSurge: 更新时允许超出的 Pod 数量
maxUnavailable: 更新时允许不可用的 Pod 数量
通过 revisionHistoryLimit 保留历史 ReplicaSet 实现回滚

StatefulSet 更新策略：

RollingUpdate: 按逆序（从最大序号到0）逐个更新
OnDelete: 手动删除 Pod 时才更新
Partition: 控制滚动更新的断点

4. 网络模型与 CNI

4.1 K8s 网络模型四大问题

1. Pod 与 Pod 通信：同一扁平网络，无需 NAT
2. Pod 与 Service 通信：通过 ClusterIP/iptables/IPVS
3. 外部访问 Service：NodePort / LoadBalancer / Ingress
4. Service 发现：DNS（CoreDNS）或环境变量

4.2 Service 类型

类型	说明	使用场景
ClusterIP	集群内部虚拟 IP	内部服务间通信
NodePort	在每个节点上暴露端口	简单外部访问
LoadBalancer	云厂商负载均衡器	生产环境外部访问
ExternalName	CNAME 映射	对接外部服务

4.3 kube-proxy 模式对比

模式	原理	优缺点
iptables	为每个 Service 创建 iptables 规则	简单可靠，Service 多时规则链长、性能下降
IPVS	使用 Linux IPVS（LVS）内核模块	高性能 O(1) 查找，支持多种负载均衡算法，大规模场景首选
userspace	用户态代理（已弃用）	性能差，仅用于兼容

IPVS 面试要点：

IPVS 使用哈希表存储规则，查找复杂度 O(1)，iptables 是 O(n)
支持 rr（轮询）、wrr（加权轮询）、lc（最少连接）、sh（源哈希）等算法
需要内核加载 ip_vs 模块
配合 ipset 或单独的 kube-router 可进一步优化

4.4 CNI 插件对比

插件	网络方案	特点
Calico	BGP + VXLAN	网络策略强、性能好、支持 BGP Peering
Cilium	eBPF	高性能、细粒度安全策略、Hubble 可观测性
Flannel	VXLAN	简单易用、功能较少
Weave	VXLAN + Mesh	自动发现、加密通信

Calico 深入：

BGP 模式：直接通过 BGP 协议传播 Pod 路由，无封装开销（同 L2 网络）
VXLAN 模式：跨 L2/L3 网络时封装为 VXLAN（有约 50 字节头部开销）
IPIP 模式：IP-in-IP 封装（14 字节开销）
网络策略实现：通过 iptables 规则在 veth pair 的 host 端实施

4.5 DNS 架构

Pod DNS 解析路径：
`<service-name>.<namespace>.svc.cluster.local`

CoreDNS 配置（Corefile）：
|-- kubernetes 插件：解析集群内部 Service
|-- forward 插件：转发外部 DNS 请求到上游
|-- cache 插件：DNS 缓存
+-- log 插件：查询日志

常见问题排查：
- dnsPolicy: ClusterFirst（默认）/ Default / None / ClusterFirstWithHostNet
- ndots 问题：默认 ndots:5 导致大量无效查询，建议对频繁外部查询的应用设 ndots:2

4.6 Ingress 与 Gateway API

Ingress Controller 选项：
|-- Nginx Ingress：最成熟、功能丰富
|-- Traefik：自动服务发现、中间件
|-- Contour：Envoy-based、高性能
+-- Kong：API 网关能力、插件生态

Gateway API（Ingress 的下一代替代）：
|-- GatewayClass：定义网关实现（类似 IngressClass）
|-- Gateway：定义监听器和地址（类似 Ingress）
|-- HTTPRoute/TCPRoute/TLSRoute：定义路由规则
+-- 优势：角色分离（平台团队管 Gateway，应用团队管 Route）、表达力更强

5. 存储与 CSI

5.1 存储对象

PV（PersistentVolume）-> PVC（PersistentVolumeClaim）-> Pod

静态供给：管理员手动创建 PV，用户创建 PVC 绑定
动态供给：用户创建 PVC，StorageClass 自动创建 PV（Provisioner）

5.2 访问模式

模式	缩写	说明
ReadWriteOnce	RWO	单节点读写
ReadOnlyMany	ROX	多节点只读
ReadWriteMany	RWX	多节点读写
ReadWriteOncePod	RWOP	单 Pod 读写（1.27+）

5.3 回收策略

策略	说明
Retain	保留数据，需手动清理
Delete	PVC 删除时自动删除 PV 和底层存储
Recycle	已弃用（执行 rm -rf）

5.4 CSI 架构

CSI 插件组成：
|-- Controller Plugin（运行在任意节点，通常作为 Deployment）
|   |-- CreateVolume / DeleteVolume
|   |-- ControllerPublishVolume / ControllerUnpublishVolume
|   +-- 负责卷的创建、删除、挂载/卸载
|-- Node Plugin（每个节点一个，作为 DaemonSet）
|   |-- NodeStageVolume / NodeUnstageVolume
|   |-- NodePublishVolume / NodeUnpublishVolume
|   +-- 负责本节点上卷的格式化和挂载
+-- Sidecar 容器
    |-- external-provisioner：监听 PVC，调用 CreateVolume
    |-- external-attacher：监听 VolumeAttachment，调用 ControllerPublishVolume
    |-- external-resizer：监听 PVC resize 请求
    +-- external-snapshotter：处理 VolumeSnapshot

5.5 Volume 快照与克隆

yaml

# VolumeSnapshot
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-snapshot
spec:
  volumeSnapshotClassName: csi-snapshot-class
  source:
    persistentVolumeClaimName: my-pvc

# 从快照恢复 PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restored-pvc
spec:
  dataSource:
    name: my-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes: [ReadWriteOnce]
  resources:
    requests:
      storage: 10Gi

6. 调度与资源管理

6.1 调度流程

Pod 创建 -> 调度队列 -> Scheduling Cycle -> Binding

Scheduling Cycle:
1. PreFilter 插件：预处理/检查
2. Filter 插件：过滤不可调度节点
   - NodeResourcesFit：资源是否充足
   - NodeAffinity：节点亲和性
   - TaintToleration：污点容忍
   - PodTopologySpread：拓扑分布约束
3. Score 插件：对可调度节点打分
   - LeastRequestedPriority：资源最空闲的节点
   - BalancedResourceAllocation：CPU/内存均衡
   - InterPodAffinity：Pod 间亲和性打分
4. Reserve：预留资源
5. Permit：允许/拒绝/等待
6. Bind：绑定到节点

6.2 调度策略

yaml

# 节点亲和性
nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
    - matchExpressions:
      - key: topology.kubernetes.io/zone
        operator: In
        values: [us-east-1a, us-east-1b]
  preferredDuringSchedulingIgnoredDuringExecution:
  - weight: 80
    preference:
      matchExpressions:
      - key: node-type
        operator: In
        values: [high-performance]

# Pod 亲和性/反亲和性
podAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
  - labelSelector:
      matchExpressions:
      - key: app
        operator: In
        values: [cache]
    topologyKey: topology.kubernetes.io/zone

# 拓扑分布约束
topologySpreadConstraints:
- maxSkew: 1
  topologyKey: topology.kubernetes.io/zone
  whenUnsatisfiable: DoNotSchedule
  labelSelector:
    matchLabels:
      app: web

6.3 资源管理

资源请求（Requests）vs 限制（Limits）：
|-- Requests：调度依据，保证分配的最小资源
|-- Limits：运行时上限，超出会被限制（CPU 被 throttle）或杀掉（OOM Kill）
+-- QoS 等级：
    |-- Guaranteed：requests == limits（CPU 和 Memory 都设置）-> 最高优先级
    |-- Burstable：至少一个容器设置了 requests -> 中等优先级
    +-- BestEffort：未设置任何 requests/limits -> 最低优先级（首先被驱逐）

LimitRange：为 namespace 设置默认的资源请求/限制
ResourceQuota：限制 namespace 的总资源用量

6.4 自动伸缩

伸缩方式	缩写	功能	适用场景
Horizontal Pod Autoscaler	HPA	根据 CPU/Memory/自定义指标扩缩 Pod 副本数	无状态应用水平伸缩
Vertical Pod Autoscaler	VPA	自动调整 Pod 的 requests/limits	优化资源配额
Cluster Autoscaler	CA	根据 Pending Pod 自动扩缩节点	集群容量弹性
KEDA	KEDA	基于事件驱动的自动伸缩	消息队列、定时任务

7. 安全与 RBAC

7.1 RBAC 四大资源

资源	作用域	说明
Role	Namespace	定义 namespace 内权限
RoleBinding	Namespace	将 Role 绑定到用户/组/SA
ClusterRole	Cluster	定义集群级权限
ClusterRoleBinding	Cluster	将 ClusterRole 绑定到主体

yaml

# 最小权限原则示例
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: ['']
  resources: ['pods']
  verbs: ['get', 'list', 'watch']
- apiGroups: ['']
  resources: ['pods/log']
  verbs: ['get']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
- kind: ServiceAccount
  name: monitoring-sa
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

7.2 Pod 安全

Pod Security Standards（替代已弃用的 PodSecurityPolicy）：
|-- Privileged：无限制（系统组件用）
|-- Baseline：最低限度安全策略（防止已知提权）
|   |-- 禁止 hostNetwork/hostPID/hostIPC
|   |-- 禁止特权容器
|   |-- 禁止已知危险 capabilities
|   +-- 禁止 hostPath 卷
+-- Restricted：严格安全策略（最佳实践）
    |-- 必须以非 root 运行
    |-- 禁止特权提升（allowPrivilegeEscalation: false）
    |-- 只允许最小 capabilities
    +-- 必须使用 seccomp profile

Pod Security Admission（1.25+ 内置）：
|-- enforce：强制执行策略
|-- audit：审计违反策略的行为
+-- warn：警告违反策略的行为

7.3 安全加固清单

[ ] 启用 RBAC，禁用 ABAC
[ ] 禁用匿名访问
[ ] 使用 ServiceAccount Token Volume Projection（1.20+）
[ ] 限制 ServiceAccount 的 automountServiceAccountToken
[ ] 启用审计日志（Audit Policy）
[ ] 配置 Pod Security Admission
[ ] 实施 NetworkPolicy（默认拒绝所有，按需放行）
[ ] 镜像签名验证（Cosign/Notary）
[ ] 镜像漏洞扫描（Trivy）
[ ] etcd 加密存储 Secret（EncryptionConfiguration）
[ ] 使用外部密钥管理（Vault/Sealed Secrets/External Secrets Operator）
[ ] 定期 CIS Benchmark 扫描（kube-bench）
[ ] 运行时安全（Falco）
[ ] 最小化容器镜像（distroless/scratch）

8. 集群部署与升级

8.1 部署工具对比

工具	特点	适用场景
kubeadm	官方工具，灵活可定制	生产环境、自定义部署
kops	AWS/GCE 集群管理	公有云集群
k3s	轻量级 K8s 发行版	边缘计算、IoT、开发环境
RKE/RKE2	Rancher 企业级发行版	企业生产环境、合规场景
Terraform + kubeadm	IaC 方式部署	基础设施即代码实践

8.2 集群升级流程

控制平面升级（按顺序）：
1. 升级 etcd（备份 -> 升级 -> 验证）
2. 升级 kube-apiserver（滚动重启）
3. 升级 kube-controller-manager
4. 升级 kube-scheduler
5. 升级 kube-proxy

节点升级（逐节点）：
1. kubectl drain `<node>` --ignore-daemonsets --delete-emptydir-data
2. 升级 kubelet 和 kubectl
3. systemctl restart kubelet
4. kubectl uncordon `<node>`

注意事项：
- 跨版本升级只能跨一个小版本（1.26->1.27->1.28）
- 升级前检查 API 弃用（pluto/kubectl-convert）
- 保持 kubelet 版本 <= apiserver 版本
- 升级前测试所有关键 addon 兼容性

8.3 etcd 运维

bash

# 备份
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db   --endpoints=https://127.0.0.1:2379   --cacert=/etc/kubernetes/pki/etcd/ca.crt   --cert=/etc/kubernetes/pki/etcd/server.crt   --key=/etc/kubernetes/pki/etcd/server.key

# 恢复
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot.db   --data-dir=/var/lib/etcd-restored

etcd 性能调优要点：

使用 SSD 存储（fsync < 10ms）
分离 etcd 到独立节点
设置合理的 quota-backend-bytes（默认 2GB，建议 8GB）
定期 defrag（压缩 + 碎片整理）
监控 wal_fsync_duration_seconds 和 backend_commit_duration_seconds

9. 可观测性（监控/日志/链路追踪）

9.1 监控体系

Prometheus 生态：
|-- Prometheus Server：指标采集与存储（TSDB）
|-- Exporters：各种指标来源
|   |-- node-exporter：节点指标
|   |-- kube-state-metrics：K8s 对象状态指标
|   +-- cAdvisor（内置于 kubelet）：容器资源指标
|-- Alertmanager：告警路由、分组、抑制、静默
|-- Grafana：可视化仪表盘
|-- Thanos/Cortex/VictoriaMetrics：Prometheus 长期存储与多集群聚合
+-- PrometheusRule：定义告警规则

关键监控指标：
|-- 集群层面：节点状态、Pod 状态、部署状态、etcd 健康
|-- 资源层面：CPU/内存使用率 vs requests/limits、磁盘/网络 I/O、OOM Kill 次数
|-- 应用层面：RED（Request rate, Error rate, Duration）、USE（Utilization, Saturation, Errors）
+-- 控制平面：apiserver 请求延迟/错误率、scheduler 调度延迟、controller 队列深度

9.2 日志体系

日志采集方案：
|-- EFK Stack：Elasticsearch + Fluentd/Fluent Bit + Kibana
|-- Loki Stack：Loki + Promtail/Fluent Bit + Grafana（更轻量、成本更低）
+-- 最佳实践：
    |-- 使用 DaemonSet 部署 Fluent Bit 采集节点日志
    |-- 使用 Sidecar 采集特殊应用日志
    |-- 结构化日志（JSON 格式）
    |-- 设置日志级别过滤（生产环境只保留 WARN/ERROR）
    |-- 日志采样策略（高流量服务）
    +-- 日志生命周期管理（ILM/热温冷架构）

10. Helm 与 GitOps

10.1 Helm

核心概念：
|-- Chart：K8s 应用包
|-- Release：Chart 的一次部署实例
|-- Repository：Chart 仓库
+-- Values：自定义配置

Chart 最佳实践：
|-- 使用 Helm Lint 检查 Chart
|-- 使用 helm template 预览渲染结果
|-- 分离 values（values-dev.yaml/values-prod.yaml）
|-- 使用 helm-secrets 或 SOPS 加密敏感值
|-- Helm Hooks（pre-install/post-install/pre-upgrade 等）
+-- Helm Test（在 CI 中自动测试部署）

10.2 GitOps（ArgoCD）

GitOps 原则：
|-- 声明式：所有配置以 YAML/Helm/Kustomize 形式存在
|-- 版本化且不可变：Git 作为唯一真实来源
|-- 自动拉取：Controller 自动拉取 Git 变更并应用
+-- 持续调谐：自动检测并修复集群状态与 Git 的偏差

ArgoCD 架构：
|-- API Server：gRPC/REST API，CLI 和 UI 入口
|-- Repository Server：Git 仓库克隆和 manifest 渲染
|-- Application Controller：Watch Git 和集群状态，执行 Sync
+-- ApplicationSet Controller：动态生成 Application

Sync 策略：
|-- Manual Sync：手动触发同步
|-- Auto Sync：自动同步（可配置 Prune/SelfHeal）
|-- Sync Waves：通过注解控制资源部署顺序
|-- Health Checks：自定义健康检查
+-- Resource Hooks：PreSync/Sync/PostSync 钩子

11. 故障排查与应急响应

11.1 排查方法论

故障排查框架（USE/RED + 分层法）：

1. 确认故障现象
   kubectl get pods -A | grep -v Running
   kubectl get events --sort-by='.lastTimestamp'

2. 分层排查
   +-------------------------------------+
   | 应用层：应用日志、应用指标           |
   +-------------------------------------+
   | Pod 层：describe/logs/exec           |
   +-------------------------------------+
   | 节点层：kubelet 日志、系统资源       |
   +-------------------------------------+
   | 网络层：DNS、Service、NetworkPolicy  |
   +-------------------------------------+
   | 存储层：PV 状态、CSI 日志            |
   +-------------------------------------+
   | 控制平面：apiserver/etcd 状态        |
   +-------------------------------------+

11.2 常见故障场景

场景 1：Pod 一直 Pending

资源不足（Insufficient cpu/memory）-> 扩容或调整 requests
PVC 未绑定 -> 检查 PV/StorageClass
污点不容忍 -> 检查 Taints/Tolerations
节点亲和性不满足 -> 检查 nodeSelector/nodeAffinity
拓扑分布约束不满足 -> 检查 topologySpreadConstraints

场景 2：Pod CrashLoopBackOff

kubectl logs <pod> --previous（查看崩溃前日志）
退出码分析：1=应用错误, 137=OOMKilled/SIGKILL, 139=段错误, 143=SIGTERM

场景 3：Service 无法访问

确认 Endpoints 有 Pod IP
确认 Pod 的 Readiness Probe 通过
确认 NetworkPolicy 未阻断
确认 kube-proxy 工作正常
DNS 解析测试

场景 4：节点 NotReady

PLEG 不健康（容器运行时问题）
磁盘空间满（imagefs/nodefs）
内存压力（MemoryPressure）
网络插件异常
时钟不同步

11.3 应急响应流程

1. 发现 -> 确认影响范围 -> 定级（P0-P3）
2. 止血（快速恢复服务）
   - 回滚最近的变更
   - 扩容 / 重启异常组件
   - 临时绕过方案
3. 定位根因（Root Cause Analysis）
4. 修复 -> 验证 -> 上线
5. 复盘（Post-Mortem）
   - 时间线
   - 根因分析（5 Why 分析法）
   - 改进措施（Action Items）
   - 责任不追究（Blameless）

12. 高可用与灾备

12.1 控制平面高可用

高可用架构：
|-- 至少 3 个 etcd 节点（奇数，容忍 (n-1)/2 个故障）
|-- 至少 2 个 kube-apiserver 实例 + 负载均衡器
|-- kube-controller-manager 和 kube-scheduler 通过 Leader Election 实现 HA
+-- 负载均衡方案：
    |-- 外部 LB（云厂商/HAProxy/Nginx）
    |-- kube-vip（VIP + ARP/BGP）
    +-- keepalived + haproxy

12.2 应用高可用

高可用策略：
|-- Pod 反亲和性：跨节点/可用区分布
|-- PodDisruptionBudget（PDB）：保证最小可用 Pod 数
|-- 多副本 + 负载均衡
|-- 优雅终止：PreStop Hook + SIGTERM 处理
|-- 健康检查：合理配置 Liveness/Readiness
+-- 资源保障：Guaranteed QoS + PDB

灾难恢复：
|-- etcd 定期备份（自动 + 异地存储）
|-- Velero 备份：集群资源 + PVC 数据
|-- 多集群容灾：Active-Active 或 Active-Standby
+-- DNS 快速切换：TTL 设置 + 健康检查

13. Service Mesh 与云原生进阶

13.1 Istio 架构

数据平面（Envoy Sidecar）：
|-- 流量拦截：iptables REDIRECT -> Envoy
|-- mTLS：服务间自动加密
|-- 流量管理：路由、重试、超时、熔断
+-- 可观测性：自动注入 trace span

控制平面（istiod）：
|-- Pilot：服务发现、流量规则下发
|-- Citadel：证书管理、mTLS
+-- Galley：配置校验（已合并到 istiod）

核心 CRD：
|-- VirtualService：路由规则（类似 Ingress）
|-- DestinationRule：流量策略（负载均衡、连接池、异常检测）
|-- Gateway：南北向流量入口
|-- ServiceEntry：注册外部服务
+-- Sidecar：限制 Envoy 代理范围

14. CI/CD 与 DevOps 实践

14.1 CI/CD Pipeline

完整流水线：
代码提交 -> 代码扫描 -> 单元测试 -> 构建镜像 -> 镜像扫描 -> 推送镜像 -> 部署

工具链：
|-- CI：GitHub Actions / GitLab CI / Jenkins
|-- 镜像构建：Kaniko / Buildah / BuildKit（无守护进程构建）
|-- 镜像扫描：Trivy / Grype / Snyk
|-- 镜像签名：Cosign / Notary
|-- 镜像仓库：Harbor（企业级）/ ECR / GCR
|-- CD：ArgoCD / Flux / Spinnaker
+-- 渐进式发布：Argo Rollouts / Flagger

14.2 镜像安全最佳实践

dockerfile

# 多阶段构建 + 最小化镜像
FROM golang:1.22 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags='-s -w' -o /app/main .

FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /app/main /main
USER nonroot:nonroot
ENTRYPOINT ['/main']

15. 多集群与混合云

方案	说明	特点
Karmada	CNCF 孵化项目	声明式多集群编排、策略驱动
Cluster API (CAPI)	声明式集群生命周期管理	统一管理多集群创建/升级/删除
Rancher	企业级多集群管理平台	UI 友好、RBAC 统一
Liqo	跨集群资源共享	虚拟节点、跨集群 Pod 调度

16. 性能调优

16.1 API Server 调优

- --max-requests-inflight：最大并发请求数（默认 400）
- --max-mutating-requests-inflight：最大变更请求数（默认 200）
- --watch-cache-size：Watch 缓存大小
- 客户端优化：
  - 使用 Informer 缓存（SharedInformer）减少 API 调用
  - 使用 protobuf 序列化（比 JSON 快 3-10x）
  - 合理的 resync period（避免全量 Reconcile）

16.2 etcd 调优

- 使用高性能 SSD（IOPS > 10000, 延迟 < 1ms）
- quota-backend-bytes: 8589934592（8GB）
- snapshot-count: 10000（降低快照频率）
- 定期压缩（compaction）和碎片整理（defrag）
- 避免大对象（拆分大 ConfigMap/Secret）

16.3 kubelet 调优

- --kube-api-qps / --kube-api-burst：调整 kubelet 与 apiserver 通信的速率
- --serialize-image-pulls：禁用串行镜像拉取
- --image-gc-high-threshold / --image-gc-low-threshold：镜像垃圾回收阈值
- --max-pods：每节点最大 Pod 数（默认 110）
- --cpu-manager-policy：static（绑核，减少上下文切换）
- --topology-manager-policy：best-effort / single-numa-node（NUMA 感知）

17. 软技能与架构设计

17.1 系统设计面试

常见设计题：
1. 设计一个支撑 5000 节点的 K8s 集群
2. 设计一个多租户 K8s 平台
3. 设计一个跨地域高可用 K8s 架构
4. 设计 K8s 上运行有状态数据库的方案
5. 设计一个完整的 GitOps 工作流

答题框架（STAR + 架构）：
- Scenario：明确场景和约束条件
- Task：明确目标和非功能性需求
- Action：
  - 架构图（组件选型、网络拓扑）
  - 容量规划（节点规模、资源预算）
  - 高可用设计（冗余、故障转移）
  - 安全设计（隔离、认证、审计）
  - 可观测性（监控、告警、日志）
  - 运维自动化（IaC、GitOps、自愈）
- Result：预期效果、Trade-off 分析

18. 面试高频题 TOP 50

架构与原理（10题）

#	问题	考察点
1	K8s 控制平面各组件的职责和交互流程	架构理解深度
2	声明式 API 的工作原理，Level-triggered vs Edge-triggered	核心概念
3	Informer 机制的工作原理（List-Watch、DeltaFIFO、Indexer）	内部机制
4	etcd 的 Raft 共识算法原理，如何保证一致性	分布式系统
5	K8s 中 Controller 的 Reconciliation Loop 原理	控制模式
6	kubelet 的 PLEG（Pod Lifecycle Event Generator）工作原理	节点组件
7	CRI/CNI/CSI 接口的设计理念和交互流程	插件机制
8	K8s 如何实现零停机部署？涉及哪些组件的协作	端到端理解
9	K8s 中 Secret 的存储和加密机制	安全机制
10	K8s 的 API 聚合层（API Aggregation）是什么	扩展性

网络（10题）

#	问题	考察点
11	Service 的 ClusterIP 是如何工作的（iptables/IPVS）	Service 实现
12	Pod 跨节点通信的完整网络路径	网络模型
13	Ingress Controller 的工作原理	入口流量
14	NetworkPolicy 的实现原理和常见陷阱	网络安全
15	CoreDNS 在 K8s 中的角色和优化方法	DNS
16	如何实现 K8s 集群的外部流量入口（南北向流量）	流量架构
17	Calico BGP 模式和 VXLAN 模式的区别和选择	CNI
18	什么是 eBPF，Cilium 如何利用 eBPF	前沿技术
19	Gateway API 相比 Ingress 的优势	新特性
20	如何排查 Pod 间网络延迟问题	网络排障

存储（5题）

#	问题	考察点
21	PV 和 PVC 的绑定流程，静态 vs 动态供给	存储基础
22	CSI 插件的架构和工作流程	CSI
23	如何在 K8s 上运行有状态应用（数据库）	有状态应用
24	Volume 快照和克隆的区别和使用场景	数据管理
25	local volume vs network volume 的权衡	存储选型

调度与资源（5题）

#	问题	考察点
26	K8s 调度器的调度流程和扩展点	调度原理
27	如何保证关键应用不被驱逐	资源保障
28	HPA 和 VPA 能否同时使用？如何配合	自动伸缩
29	QoS 等级是如何计算的，对驱逐有什么影响	资源管理
30	如何实现 GPU 调度	异构计算

安全（5题）

#	问题	考察点
31	RBAC 的权限设计和最小权限原则	权限管理
32	如何加固一个 K8s 集群（安全清单）	安全全局观
33	ServiceAccount Token 的演进（1.20 前后）	认证机制
34	Admission Controller 有哪些类型，如何自定义	准入控制
35	如何应对容器逃逸攻击	容器安全

运维与排障（10题）

#	问题	考察点
36	如何排查 Pod CrashLoopBackOff	排障能力
37	集群升级的完整流程和注意事项	升级运维
38	如何备份和恢复 K8s 集群	灾备
39	如何设计一个完整的监控告警体系	可观测性
40	如何实现 K8s 集群的自动化运维	运维自动化
41	GitOps 的优势和实践，ArgoCD 工作原理	GitOps
42	Helm Chart 的开发和最佳实践	包管理
43	如何管理多环境的 K8s 部署	多环境
44	大规模集群（5000+节点）的运维挑战	规模经验
45	如何优化 K8s 的成本	成本意识

架构设计（5题）

#	问题	考察点
46	设计一个多租户 K8s 平台	系统设计
47	设计一个跨地域高可用架构	HA 设计
48	K8s 上运行大数据/ML 工作负载的方案	场景设计
49	Service Mesh 是否应该引入，如何评估	技术决策
50	如何从单体应用迁移到 K8s 微服务架构	迁移策略

文档维护说明： 本文档基于 Kubernetes 1.28-1.32 版本编写，随着 K8s 版本迭代，部分内容可能需要更新。建议每季度审阅一次。

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

目录 ​

1. 技能全景图 ​

2. Kubernetes 核心架构 ​

2.1 控制平面组件 ​

2.2 节点组件 ​

2.3 核心概念深度理解 ​

3. Pod 与工作负载 ​

3.1 Pod 生命周期 ​

3.2 探针（Probes） ​

3.3 工作负载对比 ​

3.4 更新策略 ​

4. 网络模型与 CNI ​

4.1 K8s 网络模型四大问题 ​

4.2 Service 类型 ​

4.3 kube-proxy 模式对比 ​

4.4 CNI 插件对比 ​

4.5 DNS 架构 ​

4.6 Ingress 与 Gateway API ​

5. 存储与 CSI ​

5.1 存储对象 ​

5.2 访问模式 ​

5.3 回收策略 ​

5.4 CSI 架构 ​

5.5 Volume 快照与克隆 ​

6. 调度与资源管理 ​

6.1 调度流程 ​

6.2 调度策略 ​

6.3 资源管理 ​

6.4 自动伸缩 ​

7. 安全与 RBAC ​

7.1 RBAC 四大资源 ​

7.2 Pod 安全 ​

7.3 安全加固清单 ​

8. 集群部署与升级 ​

8.1 部署工具对比 ​

8.2 集群升级流程 ​

8.3 etcd 运维 ​

9. 可观测性（监控/日志/链路追踪） ​

9.1 监控体系 ​

9.2 日志体系 ​

10. Helm 与 GitOps ​

10.1 Helm ​

10.2 GitOps（ArgoCD） ​

11. 故障排查与应急响应 ​

11.1 排查方法论 ​

11.2 常见故障场景 ​

11.3 应急响应流程 ​

12. 高可用与灾备 ​

12.1 控制平面高可用 ​

12.2 应用高可用 ​

13. Service Mesh 与云原生进阶 ​

13.1 Istio 架构 ​

14. CI/CD 与 DevOps 实践 ​

14.1 CI/CD Pipeline ​

14.2 镜像安全最佳实践 ​

15. 多集群与混合云 ​

16. 性能调优 ​

16.1 API Server 调优 ​

16.2 etcd 调优 ​

16.3 kubelet 调优 ​

17. 软技能与架构设计 ​

17.1 系统设计面试 ​

18. 面试高频题 TOP 50 ​

架构与原理（10题） ​

网络（10题） ​

存储（5题） ​

调度与资源（5题） ​

安全（5题） ​

运维与排障（10题） ​

架构设计（5题） ​

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

目录

1. 技能全景图

2. Kubernetes 核心架构

2.1 控制平面组件

2.2 节点组件

2.3 核心概念深度理解

3. Pod 与工作负载

3.1 Pod 生命周期

3.2 探针（Probes）

3.3 工作负载对比

3.4 更新策略

4. 网络模型与 CNI

4.1 K8s 网络模型四大问题

4.2 Service 类型

4.3 kube-proxy 模式对比

4.4 CNI 插件对比

4.5 DNS 架构

4.6 Ingress 与 Gateway API

5. 存储与 CSI

5.1 存储对象

5.2 访问模式

5.3 回收策略

5.4 CSI 架构

5.5 Volume 快照与克隆

6. 调度与资源管理

6.1 调度流程

6.2 调度策略

6.3 资源管理

6.4 自动伸缩

7. 安全与 RBAC

7.1 RBAC 四大资源

7.2 Pod 安全

7.3 安全加固清单

8. 集群部署与升级

8.1 部署工具对比

8.2 集群升级流程

8.3 etcd 运维

9. 可观测性（监控/日志/链路追踪）

9.1 监控体系

9.2 日志体系

10. Helm 与 GitOps

10.1 Helm

10.2 GitOps（ArgoCD）

11. 故障排查与应急响应

11.1 排查方法论

11.2 常见故障场景

11.3 应急响应流程

12. 高可用与灾备

12.1 控制平面高可用

12.2 应用高可用

13. Service Mesh 与云原生进阶

13.1 Istio 架构

14. CI/CD 与 DevOps 实践

14.1 CI/CD Pipeline

14.2 镜像安全最佳实践

15. 多集群与混合云

16. 性能调优

16.1 API Server 调优

16.2 etcd 调优

16.3 kubelet 调优

17. 软技能与架构设计

17.1 系统设计面试

18. 面试高频题 TOP 50

架构与原理（10题）

网络（10题）

存储（5题）

调度与资源（5题）

安全（5题）

运维与排障（10题）

架构设计（5题）