Kubernetes面试全维度指南：从基础到实战

1. Kubernetes面试全维度指南：从基础概念到实战场景

作为云原生时代的核心技术栈，Kubernetes已经成为运维工程师和架构师的必备技能。我在过去三年面试过上百位K8s相关岗位候选人，发现大多数人在准备面试时存在两个误区：要么死记硬背概念缺乏深度理解，要么只关注命令操作而忽视设计原理。本文将基于真实面试场景，系统梳理K8s知识体系，带你建立结构化认知框架。

2. 基础概念类（入门必问）

2.1 Kubernetes核心定位与价值

面试官常以"请用通俗语言解释K8s"作为开场问题。最佳回答应包含三个层次：

• 本质定义：开源的容器编排系统，提供应用部署、扩缩容和管理的自动化能力
• 核心价值：解决微服务架构下容器化应用的三大痛点——跨主机调度（如如何将100个容器合理分配到20台服务器）、服务发现（容器IP动态变化时如何保持通信）、故障自愈（容器崩溃后如何自动恢复）
• 典型场景：相比Docker原生编排工具Swarm，K8s更适合大规模生产环境，支持更复杂的调度策略和插件体系

注意：避免直接背诵官方定义。我曾遇到候选人机械回答"K8s是CNCF项目"，却说不清它具体解决了什么问题。建议用"以前运维怎么做→现在K8s如何改进"的对比方式阐述。

2.2 声明式API设计哲学

这是K8s区别于传统运维工具的核心特征，需要理解其背后的工程思想：

yaml复制# 传统命令式操作（Imperative）：
kubectl run nginx --image=nginx:1.14 

# 声明式操作（Declarative）：
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.14

关键差异在于：

• 命令式关注"怎么做"（执行具体操作步骤）
• 声明式关注"要什么"（描述最终期望状态）
• 优势：可重复执行（多次apply不会产生副作用）、状态可追溯（通过etcd保存完整状态历史）

2.3 核心抽象模型

K8s通过API对象对基础设施进行抽象，常见误解是混淆不同资源类型：

• Pod：最小调度单元（不是容器），类比虚拟机中的"进程组"
• Deployment：无状态应用的版本控制器，管理ReplicaSet的更迭
• StatefulSet：有状态应用控制器，保障Pod名称和存储的稳定性
• Service：网络端点抽象，提供稳定的ClusterIP和DNS名称

我曾让候选人画图说明这些对象的关系，优秀回答通常会标注出控制循环（如Deployment→ReplicaSet→Pod的级联关系）。

3. 核心组件类（重点必问）

3.1 控制平面组件协作原理

面试中经常要求解释组件交互流程，建议从客户端请求视角说明：

1. kubectl提交YAML到API Server（唯一入口）
2. Scheduler监听未绑定Node的Pod，根据资源请求和约束选择合适节点
3. Controller Manager中的Deployment控制器发现期望副本数与实际不符，创建新的ReplicaSet
4. kubelet通过API Server获取分配给本机的Pod清单，调用容器运行时（如containerd）启动容器
5. kube-proxy配置iptables/ipvs规则，实现Service的负载均衡

常见陷阱问题："etcd存储了什么数据？"正确答案应包括：

• 集群所有资源对象的完整状态
• 不包括容器镜像和持久化数据
• 定期执行snapshot防止数据丢失

3.2 kubelet工作原理深度解析

作为节点上的"超级管家"，kubelet的功能常被低估。在面试中可突出以下要点：

• 容器生命周期管理：通过CRI（Container Runtime Interface）与Docker/containerd等运行时交互
• 健康检查机制：
  • Liveness Probe：决定是否重启容器
  • Readiness Probe：控制流量接入
  • Startup Probe：保护慢启动应用
• 资源监控：定期向API Server报告节点资源使用情况

实操建议：遇到"kubelet无法启动容器"的问题时，按以下顺序排查：

bash复制# 查看kubelet日志
journalctl -u kubelet -n 100

# 检查容器运行时状态
crictl ps -a

# 验证镜像拉取权限
crictl pull nginx:latest

4. 资源管理类（高频实操）

4.1 资源请求与限制配置

这是生产环境必须掌握的配置项，但80%的候选人存在理解偏差：

yaml复制resources:
  requests:
    cpu: "500m"  # 0.5核，调度依据
    memory: "1Gi" # 最小保障资源
  limits:
    cpu: "2"     # 硬上限，超过会被throttle
    memory: "4Gi" # 超过会被OOM kill

关键知识点：

• requests影响调度结果，总和不能超过节点allocatable资源
• limits是运行时约束，防止单个Pod耗尽系统资源
• 内存限制必须设置，否则可能引发节点级OOM

常见误区：认为CPU limits应该总是设置。实际上对于延迟敏感型应用（如交易系统），建议只设requests避免CPU节流。

4.2 HPA自动扩缩容策略

Horizontal Pod Autoscaler的考核重点在于指标选择和算法理解：

yaml复制apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  minReplicas: 2
  maxReplicas: 10

扩缩容行为取决于：

• 当前指标值与目标值的比率
• 最近3-5分钟的指标趋势（避免抖动）
• 冷却窗口（scaleDown稳定期默认5分钟）

实战技巧：对于突发流量场景，可结合KEDA使用自定义指标（如RabbitMQ队列长度）实现快速扩容。

5. 网络类（难点）

5.1 Service网络实现机制

这是面试最高频的难点问题，需要分层次解释：

1. ClusterIP原理：

   • 虚拟IP由kube-proxy维护
   • iptables模式：为每个Service创建链式规则
   • ipvs模式：基于哈希表，性能更好（万级Service推荐）

2. DNS服务发现：

   • CoreDNS配置<service>.<ns>.svc.cluster.local解析
   • Headless Service（无ClusterIP）直接返回PodIP列表

3. 网络策略实践：

yaml复制apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
spec:
  podSelector:
    matchLabels:
      role: db
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: app
    ports:
    - protocol: TCP
      port: 5432

该策略只允许带有role=app标签的Pod访问5432端口。

5.2 Ingress控制器对比

常见面试题："Nginx Ingress与Traefik如何选型？"可从以下维度分析：

生产环境建议：流量稳定的传统应用用Nginx，需要频繁变更路由规则的选择Traefik。

6. 存储类（核心）

6.1 PV与PVC绑定机制

存储管理常让初学者困惑，可用"租房模型"类比：

• PV（PersistentVolume）：如同待租的房源，由管理员预先创建
• PVC（PersistentVolumeClaim）：如同租户的需求申请
• StorageClass：定义房源类型（SSD/HDD）和供应方式（静态/动态）

典型问题："PVC一直处于Pending状态怎么办？"
排查步骤：

1. 检查StorageClass是否存在且标记为default

   bash复制kubectl get storageclass
   

2. 验证PV是否满足PVC的size/accessMode要求
3. 查看PVC事件信息

   bash复制kubectl describe pvc myclaim
   

6.2 StatefulSet存储实践

有状态应用的存储需要特别注意：

yaml复制volumeClaimTemplates:
- metadata:
    name: data
  spec:
    accessModes: [ "ReadWriteOnce" ]
    storageClassName: "ssd"
    resources:
      requests:
        storage: 100Gi

关键特性：

• 每个Pod获得独立的PVC（命名格式<claim>-<pod>）
• 删除Pod不会自动删除PVC，避免数据丢失
• 建议搭配Headless Service使用，实现稳定的网络标识

7. 运维与故障排查类（实战必问）

7.1 故障诊断工具箱

资深K8s工程师的排查流程：

1. 资源状态检查：

   bash复制kubectl get pods -o wide
   kubectl describe pod <name>
   

2. 日志分析：

   bash复制kubectl logs -f <pod> -c <container>
   

3. 进入容器调试：

   bash复制kubectl exec -it <pod> -- sh
   

4. 节点级检查：

   bash复制kubectl debug node/<name> -it --image=busybox
   

7.2 典型问题处理方案

收集的常见生产环境问题：

8. 高级特性类（进阶必问）

8.1 Operator设计模式

这是K8s高级开发的必备技能，核心要点：

• 自定义资源（CRD）：扩展API资源类型
• 控制器逻辑：监听CR变化并执行调和逻辑
• 典型案例：etcd-operator、prometheus-operator

面试时可要求解释Operator的工作流程：

1. 用户创建自定义资源实例（如EtcdCluster）
2. Operator的控制器监听到该事件
3. 根据业务逻辑创建对应的StatefulSet/Service等资源
4. 持续监控集群状态，确保与期望状态一致

8.2 安全管控实践

RBAC是安全领域的必问题目：

yaml复制apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: dev-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

该配置允许dev-user用户在default命名空间读取Pod信息。

9. 实战场景类（综合能力）

9.1 集群升级方案设计

面试官常考察系统设计能力，例如："如何零停机升级生产集群？"
标准答案应包含：

1. 前置检查：
   • 备份etcd数据
   • 验证工作负载符合PodDisruptionBudget
2. 升级顺序：
   • 先升级master节点（逐个隔离升级）
   • 再升级worker节点（通过drain/cordon操作）
3. 回滚计划：
   • 保留旧版本二进制文件
   • 准备etcd快照恢复方案

9.2 性能优化案例

分享一个真实优化经验更能体现价值：
"某次API响应变慢排查发现：

1. 监控显示某节点CPU throttling严重
2. 检查发现多个Pod未设置CPU limits导致资源争抢
3. 解决方案：
   • 为所有Pod配置合理的requests/limits
   • 启用CPU管理器（cpu-manager）为关键Pod分配独占核心
     优化后P99延迟降低40%"

10. 面试准备建议

最后给准备K8s面试的工程师三个实用建议：

1. 原理与实操并重：不仅要会写YAML，还要能解释每个字段的作用
2. 构建知识图谱：用思维导图串联核心概念（如Pod→Deployment→ReplicaSet的关系）
3. 模拟故障场景：在实验环境中故意制造故障（如杀死kubelet进程），练习排查过程

我在技术评审中最看重的不是候选人知道多少命令，而是能否建立系统化的知识框架，以及遇到未知问题时的排查思路。建议用本文的分类体系作为学习路线图，逐层深入掌握K8s核心能力。