Kubernetes面试题分类整理

Kubernetes面试题分类整理

一、基础概念类

1. 什么是Kubernetes？它解决了什么问题？

答案：
Kubernetes(简称K8s)是一个开源的容器编排系统，就像是一个智能的容器管家。它主要解决了以下问题：

• 容器太多管不过来：当你有成百上千个容器时，手动管理几乎不可能
• 容器挂了怎么办：自动检测并重启故障容器
• 流量大了怎么办：自动扩展容器数量应对高流量
• 版本更新怎么办：支持滚动更新，避免服务中断
• 资源分配不均：智能调度容器到合适的机器上

2. Pod是什么？为什么需要Pod而不是直接使用容器？

答案：
Pod是K8s中最小的调度单位，就像一个"小房间"，里面可以住一个或多个"室友"(容器)。

需要Pod的原因：

1. 亲密关系：有些容器必须在一起工作(比如日志收集容器和应用容器)
2. 共享资源：Pod内的容器共享网络和存储空间
3. 原子性：K8s以Pod为单位进行调度，保证相关容器总是一起运行
4. 生命周期：Pod内的容器同时创建、同时销毁

二、核心组件类

1. Kubernetes主节点(Master)有哪些核心组件？各自的作用是什么？

答案：
主节点就像K8s集群的"大脑"，包含：

1. API Server：集群的"前台"，所有操作都要通过它
2. etcd：集群的"记事本"，记录所有重要信息
3. Scheduler：聪明的"房产中介"，决定Pod该放在哪台机器
4. Controller Manager：勤劳的"管家"，确保实际状态和期望状态一致

2. kubelet和kube-proxy有什么区别？

答案：
这两个都是工作节点上的"工作人员"，但分工不同：

kubelet：

• 相当于"小区物业"，负责：
  • 管理本节点的Pod生命周期
  • 向Master汇报节点状态
  • 执行容器健康检查

kube-proxy：

• 相当于"小区门卫"，负责：
  • 维护网络规则
  • 实现Service的负载均衡
  • 让Pod之间能够互相通信

三、网络类

1. Kubernetes网络模型的基本原则是什么？

答案：
K8s网络遵循三个基本原则：

1. 每个Pod有独立IP：就像每户人家有独立门牌号
2. Pod之间直接通信：不需要NAT转换，可以直接"串门"
3. Pod看到的IP和别人看到的一致：IP地址不因位置变化而改变

2. Service有什么作用？有哪些类型？

答案：
Service是Pod的"固定电话"，解决了Pod IP会变化的问题。

Service类型：

1. ClusterIP：默认类型，只能在集群内部访问
2. NodePort：在每台机器上开个固定端口，外部可通过节点IP:端口访问
3. LoadBalancer：使用云服务商的负载均衡器，自动分配外部IP
4. ExternalName：把Service映射到外部DNS名称

四、存储类

1. Kubernetes中Volume有哪些类型？各自适用场景？

答案：
Volume是Pod的"外接硬盘"，主要类型：

1. emptyDir：临时文件夹，Pod删除就消失 - 适合临时缓存
2. hostPath：使用宿主机的目录 - 适合开发测试(生产环境慎用)
3. PersistentVolume(PV)：持久化存储，如NFS、云盘等
4. ConfigMap/Secret：特殊Volume，用于存放配置和敏感信息

2. PersistentVolume和PersistentVolumeClaim的关系？

答案：
这就像"仓库"和"租户"的关系：

• PV(PersistentVolume)：是实际的存储资源，就像仓库
• PVC(PersistentVolumeClaim)：是用户对存储的请求，就像租户申请使用仓库

工作流程：

1. 管理员先准备好各种大小的"仓库"(PV)
2. 用户提交"租赁申请"(PVC)，写明需要多大空间
3. K8s自动匹配符合条件的PV给PVC使用

五、调度类

1. 什么是节点亲和性(Node Affinity)？有什么作用？

答案：
节点亲和性就像"租房偏好"，告诉K8s调度器Pod更喜欢在什么样的节点上运行。

作用：

1. 硬件偏好：比如需要GPU的Pod只调度到有GPU的节点
2. 业务隔离：把生产环境和测试环境的Pod分开
3. 地域偏好：让Pod尽量靠近用户所在区域

示例：

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: gpu
          operator: In
          values:
          - "true"

这段配置意思是：“必须把我调度到有gpu=true标签的节点上”

2. 资源请求(requests)和限制(limits)有什么区别？

答案：
这就像"最低工资"和"最高工资"的区别：

• requests：Pod运行至少需要的资源量，调度器根据这个值选择节点
• limits：Pod最多能使用的资源量，超过会被限制或终止

示例：

resources:
  requests:
    memory: "64Mi"
    cpu: "250m"
  limits:
    memory: "128Mi"
    cpu: "500m"

意思是：“我至少需要64MB内存和0.25个CPU核心，但最多只能用128MB内存和0.5个CPU核心”

六、安全类

1. Kubernetes中的RBAC是什么？如何工作？

答案：
RBAC(基于角色的访问控制)就像公司的"权限门禁系统"：

核心概念：

1. Role：定义在某个命名空间内的权限(如开发部权限)
2. ClusterRole：定义集群范围的权限(如管理员权限)
3. RoleBinding：把Role绑定到用户/组(如给张三分配开发权限)
4. ClusterRoleBinding：把ClusterRole绑定到用户/组

工作流程：

1. 先定义角色(Role)和权限
2. 再把角色绑定(Binding)给具体用户
3. 用户访问资源时，API Server会检查是否有对应权限

2. Service Account和User Account有什么区别？

答案：
这两种账号就像"员工工牌"和"访客证"的区别：

User Account：

• 给真人使用的账号
• 通常通过证书或外部认证系统管理
• 用于kubectl操作或API调用

Service Account：

• 给Pod里的程序使用的账号
• 由K8s自动管理
• 用于Pod访问K8s API
• 每个命名空间有默认的default service account

七、运维类

1. 如何排查Pod启动失败的问题？

答案：
排查步骤像"医生看病"：

1. 看症状：kubectl describe pod 查看Events
2. 查日志：kubectl logs [-c container-name]
3. 进容器：kubectl exec -it -- /bin/sh
4. 查配置：检查镜像、资源限制、健康检查等配置
5. 查节点：kubectl describe node 看节点资源是否充足

常见原因：

• 镜像拉取失败
• 资源不足
• 健康检查不通过
• 挂载存储失败
• 端口冲突

2. 如何实现零停机部署？

答案：
零停机部署就像"给行驶中的汽车换轮胎"，常用方法：

1. 滚动更新：
   • 逐步用新Pod替换旧Pod
   • 确保始终有足够Pod处理请求
   • 自动回滚如果更新失败
2. 蓝绿部署：
   • 准备两套环境(蓝和绿)
   • 先在绿环境部署新版本
   • 测试通过后切换流量
3. 金丝雀发布：
   • 先让少量用户使用新版本
   • 确认没问题再逐步扩大范围

配置示例(Deployment的滚动更新策略)：

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1       # 可以比期望多创建1个Pod
    maxUnavailable: 0 # 保证始终有足够Pod

八、高级特性类

1. Operator模式是什么？解决了什么问题？

答案：
Operator就像"专业管家"，专门管理某种复杂应用。

解决的问题：

• 有些应用(如数据库)有复杂的运维逻辑
• 常规的Deployment无法满足这些特殊需求
• 需要领域知识来管理应用生命周期

工作原理：

1. 使用Custom Resource Definition(CRD)定义自定义资源
2. 开发Controller来监听这些资源变化
3. Controller根据领域知识执行相应操作

示例：
Etcd Operator可以：

• 自动备份恢复
• 处理节点故障
• 执行版本升级
• 调整集群规模

2. HPA(Horizontal Pod Autoscaler)如何工作？

答案：
HPA就像"自动伸缩的橡皮筋"，根据负载调整Pod数量。

工作原理：

1. 定期(默认30秒)检查指标(CPU/内存或自定义指标)
2. 对比当前指标与目标值
3. 计算需要的Pod数量：期望副本数 = ceil[当前副本数 * (当前指标 / 目标指标)]
4. 调整Deployment/ReplicaSet的副本数

配置示例：

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

意思是：“根据CPU使用率自动调整myapp的Pod数量，保持在1-10个之间，目标是CPU使用率50%”

---

希望这份整理对您有所帮助！如果需要更深入的解释或更多题目，可以随时告诉我。