Kubernetes｜学习笔记

ErizJ2026-05-04 9:04

文章目录

  • [0. K8s 面试知识主线](#0. K8s 面试知识主线)
  • [1. Kubernetes 是什么？为什么需要它？](#1. Kubernetes 是什么？为什么需要它？)
    • [1.1 一句话定义](#1.1 一句话定义)
    • [1.2 应用部署方式的演进](#1.2 应用部署方式的演进)
      • [1.2.1 传统部署](#1.2.1 传统部署)
      • [1.2.2 虚拟机部署](#1.2.2 虚拟机部署)
      • [1.2.3 容器化部署](#1.2.3 容器化部署)
    • [1.3 K8s 核心能力](#1.3 K8s 核心能力)
  • [2. K8s 架构组件](#2. K8s 架构组件)
    • [2.1 控制平面组件](#2.1 控制平面组件)
    • [2.1.1 kube-apiserver](#2.1.1 kube-apiserver)
    • [2.1.2 etcd](#2.1.2 etcd)
    • [2.1.3 kube-scheduler](#2.1.3 kube-scheduler)
    • [2.1.4 kube-controller-manager](#2.1.4 kube-controller-manager)
    • [2.1.5 cloud-controller-manager](#2.1.5 cloud-controller-manager)
    • [2.2 工作节点组件](#2.2 工作节点组件)
    • [2.2.1 kubelet](#2.2.1 kubelet)
    • [2.2.2 kube-proxy](#2.2.2 kube-proxy)
    • [2.2.3 container runtime](#2.2.3 container runtime)
  • [3. K8s 核心设计思想](#3. K8s 核心设计思想)
    • [3.1 声明式 API](#3.1 声明式 API)
    • [3.2 资源与对象](#3.2 资源与对象)
    • [3.3 spec 与 status](#3.3 spec 与 status)
    • [3.4 Label 与 Selector](#3.4 Label 与 Selector)
  • [4. Pod 详解](#4. Pod 详解)
    • [4.1 Pod 是什么？](#4.1 Pod 是什么？)
    • [4.2 为什么 K8s 不直接调度容器，而是调度 Pod？](#4.2 为什么 K8s 不直接调度容器，而是调度 Pod？)
    • [4.3 Pod 生命周期](#4.3 Pod 生命周期)
    • [4.4 Pod 重启策略 restartPolicy](#4.4 Pod 重启策略 restartPolicy)
    • [4.5 InitContainer](#4.5 InitContainer)
    • [4.6 三种探针](#4.6 三种探针)
      • [4.6.1 StartupProbe：启动探针](#4.6.1 StartupProbe：启动探针)
      • [4.6.2 LivenessProbe：存活探针](#4.6.2 LivenessProbe：存活探针)
      • [4.6.3 ReadinessProbe：就绪探针](#4.6.3 ReadinessProbe：就绪探针)
    • [4.7 Liveness 和 Readiness 区别](#4.7 Liveness 和 Readiness 区别)
    • [4.8 探针检测方式](#4.8 探针检测方式)
    • [4.9 Pod 优雅终止](#4.9 Pod 优雅终止)
    • [4.10 preStop 的作用](#4.10 preStop 的作用)
    • [4.11 requests 与 limits](#4.11 requests 与 limits)
  • [5. Workload 控制器](#5. Workload 控制器)
    • [5.1 ReplicaSet](#5.1 ReplicaSet)
    • [5.2 Deployment](#5.2 Deployment)
    • [5.3 Deployment 滚动更新原理](#5.3 Deployment 滚动更新原理)
    • [5.4 Deployment 回滚](#5.4 Deployment 回滚)
    • [5.5 Deployment 扩容缩容](#5.5 Deployment 扩容缩容)
    • [5.6 StatefulSet](#5.6 StatefulSet)
    • [5.7 StatefulSet 和 Deployment 区别](#5.7 StatefulSet 和 Deployment 区别)
    • [5.8 Headless Service](#5.8 Headless Service)
    • [5.9 DaemonSet](#5.9 DaemonSet)
    • [5.10 Job](#5.10 Job)
    • [5.11 CronJob](#5.11 CronJob)
  • [6. Service 与服务发现](#6. Service 与服务发现)
    • [6.1 为什么需要 Service？](#6.1 为什么需要 Service？)
    • [6.2 Service、Endpoint、Pod 的关系](#6.2 Service、Endpoint、Pod 的关系)
    • [6.3 Service 类型](#6.3 Service 类型)
    • [6.4 ClusterIP](#6.4 ClusterIP)
    • [6.5 NodePort](#6.5 NodePort)
    • [6.6 LoadBalancer](#6.6 LoadBalancer)
    • [6.7 ExternalName](#6.7 ExternalName)
  • [7. Ingress](#7. Ingress)
    • [7.1 Ingress 是什么？](#7.1 Ingress 是什么？)
    • [7.2 Service 和 Ingress 区别](#7.2 Service 和 Ingress 区别)
    • [7.3 Ingress pathType](#7.3 Ingress pathType)
  • [8. ConfigMap 与 Secret](#8. ConfigMap 与 Secret)
    • [8.1 ConfigMap](#8.1 ConfigMap)
    • [8.2 Secret](#8.2 Secret)
    • [8.3 ConfigMap 和 Secret 区别](#8.3 ConfigMap 和 Secret 区别)
    • [8.4 subPath 热更新问题](#8.4 subPath 热更新问题)
  • [9. 存储：Volume、PV、PVC、StorageClass](#9. 存储：Volume、PV、PVC、StorageClass)
    • [9.1 Volume](#9.1 Volume)
    • [9.2 emptyDir](#9.2 emptyDir)
    • [9.3 hostPath](#9.3 hostPath)
    • [9.4 NFS](#9.4 NFS)
    • [9.5 PV 与 PVC](#9.5 PV 与 PVC)
    • [9.6 AccessModes](#9.6 AccessModes)
    • [9.7 PV 回收策略](#9.7 PV 回收策略)
    • [9.8 StorageClass](#9.8 StorageClass)
    • [9.9 CSI](#9.9 CSI)
  • [10. 调度机制](#10. 调度机制)
    • [10.1 Scheduler 调度流程](#10.1 Scheduler 调度流程)
    • [10.2 nodeSelector](#10.2 nodeSelector)
    • [10.3 nodeAffinity](#10.3 nodeAffinity)
    • [10.4 podAffinity / podAntiAffinity](#10.4 podAffinity / podAntiAffinity)
    • [10.5 Taint 与 Toleration](#10.5 Taint 与 Toleration)
    • [10.6 Taint/Toleration 和 Affinity 区别](#10.6 Taint/Toleration 和 Affinity 区别)
    • [10.7 cordon、drain、uncordon](#10.7 cordon、drain、uncordon)
  • [11. HPA 自动扩缩容](#11. HPA 自动扩缩容)
    • [11.1 HPA 是什么？](#11.1 HPA 是什么？)
    • [11.2 HPA 工作原理](#11.2 HPA 工作原理)
    • [11.3 HPA 常用命令](#11.3 HPA 常用命令)
  • [12. RBAC 权限控制](#12. RBAC 权限控制)
    • [12.1 RBAC 是什么？](#12.1 RBAC 是什么？)
    • [12.2 Role 和 ClusterRole 区别](#12.2 Role 和 ClusterRole 区别)
    • [12.3 ServiceAccount](#12.3 ServiceAccount)
    • [12.4 RBAC 面试标准答案](#12.4 RBAC 面试标准答案)
  • [13. Namespace 与资源隔离](#13. Namespace 与资源隔离)
    • [13.1 Namespace 作用](#13.1 Namespace 作用)
    • [13.2 Namespace 是否等于强隔离？](#13.2 Namespace 是否等于强隔离？)
  • [14. NetworkPolicy 与网络隔离](#14. NetworkPolicy 与网络隔离)
    • [14.1 NetworkPolicy 是什么？](#14.1 NetworkPolicy 是什么？)
  • [15. Helm](#15. Helm)
    • [15.1 Helm 是什么？](#15.1 Helm 是什么？)
    • [15.2 Helm 解决什么问题？](#15.2 Helm 解决什么问题？)
  • [16. 监控与日志](#16. 监控与日志)
    • [16.1 metrics-server](#16.1 metrics-server)
    • [16.2 Prometheus](#16.2 Prometheus)
    • [16.3 ELK / EFK 日志系统](#16.3 ELK / EFK 日志系统)
  • [17. DevOps 与 K8s 落地](#17. DevOps 与 K8s 落地)
  • [18. 常用 kubectl 命令](#18. 常用 kubectl 命令)
    • [18.1 查看资源](#18.1 查看资源)
    • [18.2 描述资源](#18.2 描述资源)
    • [18.3 日志与进入容器](#18.3 日志与进入容器)
    • [18.4 发布和回滚](#18.4 发布和回滚)
    • [18.5 扩缩容](#18.5 扩缩容)
    • [18.6 节点维护](#18.6 节点维护)
    • [18.7 常用资源缩写](#18.7 常用资源缩写)
  • [19. 高频面试题标准答案模板](#19. 高频面试题标准答案模板)
    • [19.1 什么是 Kubernetes？](#19.1 什么是 Kubernetes？)
    • [19.2 Docker 和 Kubernetes 的关系？](#19.2 Docker 和 Kubernetes 的关系？)
    • [19.3 K8s 核心组件有哪些？](#19.3 K8s 核心组件有哪些？)
    • [19.4 Pod 为什么是最小调度单位？](#19.4 Pod 为什么是最小调度单位？)
    • [19.5 Pod 和容器有什么区别？](#19.5 Pod 和容器有什么区别？)
    • [19.6 Deployment、ReplicaSet、Pod 的关系？](#19.6 Deployment、ReplicaSet、Pod 的关系？)
    • [19.7 Deployment 如何滚动更新？](#19.7 Deployment 如何滚动更新？)
    • [19.8 Deployment 如何回滚？](#19.8 Deployment 如何回滚？)
    • [19.9 StatefulSet 和 Deployment 区别？](#19.9 StatefulSet 和 Deployment 区别？)
    • [19.10 DaemonSet 适合什么场景？](#19.10 DaemonSet 适合什么场景？)
    • [19.11 Service 是什么？](#19.11 Service 是什么？)
    • [19.12 Service 有哪些类型？](#19.12 Service 有哪些类型？)
    • [19.13 Service 和 Ingress 区别？](#19.13 Service 和 Ingress 区别？)
    • [19.14 kube-proxy 的作用？](#19.14 kube-proxy 的作用？)
    • [19.15 ConfigMap 和 Secret 区别？](#19.15 ConfigMap 和 Secret 区别？)
    • [19.16 Secret 为什么说不是加密？](#19.16 Secret 为什么说不是加密？)
    • [19.17 PV 和 PVC 是什么？](#19.17 PV 和 PVC 是什么？)
    • [19.18 StorageClass 是什么？](#19.18 StorageClass 是什么？)
    • [19.19 emptyDir 和 hostPath 区别？](#19.19 emptyDir 和 hostPath 区别？)
    • [19.20 HPA 原理？](#19.20 HPA 原理？)
    • [19.21 Liveness、Readiness、Startup 区别？](#19.21 Liveness、Readiness、Startup 区别？)
    • [19.22 Pod 删除时发生了什么？](#19.22 Pod 删除时发生了什么？)
    • [19.23 InitContainer 和 postStart 区别？](#19.23 InitContainer 和 postStart 区别？)
    • [19.24 nodeSelector 和 nodeAffinity 区别？](#19.24 nodeSelector 和 nodeAffinity 区别？)
    • [19.25 亲和性和污点容忍区别？](#19.25 亲和性和污点容忍区别？)
    • [19.26 RBAC 是什么？](#19.26 RBAC 是什么？)
    • [19.27 ServiceAccount 是什么？](#19.27 ServiceAccount 是什么？)
    • [19.28 Namespace 是强隔离吗？](#19.28 Namespace 是强隔离吗？)
    • [19.29 NetworkPolicy 是什么？](#19.29 NetworkPolicy 是什么？)
    • [19.30 Helm 是什么？](#19.30 Helm 是什么？)
  • [20. 高频排障题](#20. 高频排障题)
    • [20.1 Pod 一直 Pending 怎么排查？](#20.1 Pod 一直 Pending 怎么排查？)
    • [20.2 Pod ImagePullBackOff 怎么排查？](#20.2 Pod ImagePullBackOff 怎么排查？)
    • [20.3 Pod CrashLoopBackOff 怎么排查？](#20.3 Pod CrashLoopBackOff 怎么排查？)
    • [20.4 Service 访问不到 Pod 怎么排查？](#20.4 Service 访问不到 Pod 怎么排查？)
    • [20.5 Ingress 不生效怎么排查？](#20.5 Ingress 不生效怎么排查？)
    • [20.6 HPA 不扩容怎么排查？](#20.6 HPA 不扩容怎么排查？)
    • [20.7 PVC 一直 Pending 怎么排查？](#20.7 PVC 一直 Pending 怎么排查？)
  • [21. 后端开发面试重点优先级](#21. 后端开发面试重点优先级)
    • [21.1 一级重点：必须背熟](#21.1 一级重点：必须背熟)
    • [21.2 二级重点：需要理解](#21.2 二级重点：需要理解)
    • [21.3 三级加分点](#21.3 三级加分点)
  • [22. 最后一页速记版](#22. 最后一页速记版)

适用目标：后端开发 / Java 后端 / Go 后端 / 云原生基础面试

复习方式：先理解主线，再背标准答案，最后用排障题串起来。

核心结论：Kubernetes 本质是一个声明式容器编排系统。用户提交期望状态，K8s 通过 API Server、Scheduler、Controller、Kubelet 等组件不断把集群实际状态调整为期望状态。

0. K8s 面试知识主线

K8s 面试不是孤立背概念，而是围绕一条完整链路展开：

text 复制代码 
为什么需要 K8s
  -> K8s 架构组件
  -> Pod 为什么是最小调度单元
  -> Deployment 如何管理副本、自愈、滚动更新、回滚
  -> Service 如何做服务发现和负载均衡
  -> Ingress 如何暴露 HTTP/HTTPS 服务
  -> ConfigMap / Secret 如何管理配置
  -> PV / PVC / StorageClass 如何管理存储
  -> Scheduler 如何调度 Pod
  -> HPA 如何自动扩缩容
  -> RBAC 如何做权限控制
  -> Helm / Prometheus / ELK / Jenkins 如何落地生产
  -> Pod 起不来、Service 不通、Ingress 不生效如何排查

1. Kubernetes 是什么？为什么需要它？

1.1 一句话定义

Kubernetes，简称 K8s，是一个用于自动化部署、扩缩容、服务发现、负载均衡、配置管理、存储编排和故障自愈的容器编排平台。

Docker 解决的是：

text 复制代码 
如何在一台机器上运行一个容器

K8s 解决的是：

text 复制代码 
如何在一组机器上稳定运行大量容器化应用

1.2 应用部署方式的演进

1.2.1 传统部署

应用直接部署在物理机上。

问题：

  • 应用之间资源不隔离；
  • 依赖冲突；
  • 扩容靠人工；
  • 故障恢复靠人工；
  • 发布和回滚成本高。

1.2.2 虚拟机部署

通过虚拟机隔离不同应用。

优点：

  • 隔离性更好；
  • 可以按虚拟机维度扩容；
  • 环境冲突减少。

缺点：

  • 虚拟机较重；
  • 启动慢；
  • 资源开销大；
  • 运维复杂。

1.2.3 容器化部署

通过 Docker / containerd 运行容器。

优点：

  • 启动快；
  • 镜像标准化；
  • 环境一致；
  • 资源开销小；
  • 易于迁移。

但是容器本身不能完全解决以下问题：

text 复制代码 
容器挂了谁拉起来？
多个容器部署到哪台机器？
如何做服务发现？
如何做负载均衡？
如何滚动发布？
如何回滚？
如何自动扩缩容？
如何管理配置和密钥？
如何挂载持久化存储？
如何做权限控制？

K8s 就是为了解决容器大规模编排和管理问题。

1.3 K8s 核心能力

能力 说明
自我修复 Pod 异常退出、节点故障时自动重新拉起或迁移
弹性伸缩 支持手动扩缩容，也支持 HPA 自动扩缩容
自动部署和回滚 Deployment 支持滚动更新和版本回滚
服务发现和负载均衡 Service 提供稳定访问入口
配置和密钥管理 ConfigMap 管普通配置，Secret 管敏感配置
存储编排 PV / PVC / StorageClass 解耦应用和底层存储
批处理任务 Job / CronJob 支持一次性任务和定时任务
权限控制 RBAC 控制用户或服务账号能访问哪些资源

2. K8s 架构组件

K8s 集群分为控制平面和工作节点。

text 复制代码 
用户 / kubectl / CI-CD
        |
        v
kube-apiserver
        |
        +--> etcd
        +--> kube-scheduler
        +--> kube-controller-manager
        +--> cloud-controller-manager
        |
        v
Worker Node:
  kubelet + kube-proxy + container runtime

2.1 控制平面组件

2.1.1 kube-apiserver

API Server 是整个集群的统一入口。

作用：

  • 对外暴露 Kubernetes API；
  • 接收 kubectl、客户端、控制器的请求；
  • 做认证、鉴权、准入控制；
  • 将资源对象持久化到 etcd；
  • 其他组件基本都通过 API Server 通信。

面试标准回答：

kube-apiserver 是 K8s 控制面的入口，所有资源的创建、查询、更新、删除都通过它完成。kubectl 本质上也是调用 API Server。它负责认证、鉴权、准入控制和资源对象读写，是整个集群控制流量的中心。

2.1.2 etcd

etcd 是分布式、高可用的键值数据库。

作用：

  • 保存集群所有状态数据；
  • 保存 Pod、Service、Deployment、ConfigMap、Secret、Node 等对象；
  • 是 Kubernetes 的后端数据库。

面试重点：

text 复制代码 
etcd 很重要，生产环境必须备份。
etcd 挂了，已有 Pod 不一定立刻挂，但控制面无法可靠创建、更新、调度资源。

面试标准回答：

etcd 是 K8s 的后端存储，保存整个集群的期望状态和实际状态信息。API Server 负责读写 etcd，Controller 和 Scheduler 再根据这些状态做控制循环。生产中 etcd 必须高可用部署并定期备份。

2.1.3 kube-scheduler

Scheduler 负责把还没有绑定节点的 Pod 分配到合适的 Node。

调度大致分两步：

text 复制代码 
过滤 Filter：排除不满足条件的节点
打分 Score：从可用节点中选出最优节点

考虑因素：

  • 节点资源是否足够；
  • 节点是否 Ready；
  • nodeSelector；
  • nodeAffinity；
  • podAffinity / podAntiAffinity；
  • taints / tolerations；
  • 端口冲突；
  • 存储约束。

面试标准回答：

Scheduler 只负责给 Pod 选择节点，不直接运行容器。它先过滤掉资源不足、污点不容忍、标签不匹配的节点，再根据资源均衡、亲和性等策略打分，最终把 Pod 绑定到某个 Node。真正拉镜像和启动容器的是该节点上的 kubelet。

2.1.4 kube-controller-manager

Controller Manager 负责运行各种控制器。

常见控制器：

  • Deployment Controller；
  • ReplicaSet Controller；
  • Node Controller；
  • Job Controller；
  • EndpointSlice Controller；
  • ServiceAccount Controller。

核心思想：

text 复制代码 
控制器不断 watch API Server 中的资源状态：

如果 实际状态 != 期望状态
就采取动作让实际状态靠近期望状态

面试标准回答：

Controller Manager 是 K8s 声明式系统的核心。用户提交的是期望状态，比如 Deployment 副本数为 3。控制器会持续观察实际状态，如果只剩 2 个 Pod，就创建新的 Pod；如果多了，就删除多余 Pod。这就是 K8s 的控制循环。

2.1.5 cloud-controller-manager

cloud-controller-manager 用于对接云厂商能力。

作用：

  • 云负载均衡；
  • 云磁盘；
  • 云主机节点生命周期；
  • 云路由。

本地学习环境不一定需要这个组件。

2.2 工作节点组件

2.2.1 kubelet

kubelet 是每个 Node 上的核心代理。

作用：

  • 从 API Server 接收分配到本节点的 Pod；
  • 调用容器运行时创建容器；
  • 管理 Pod 生命周期；
  • 执行探针；
  • 挂载 Volume；
  • 上报节点和 Pod 状态。

面试标准回答：

kubelet 是 Node 上真正干活的组件。Scheduler 只是决定 Pod 放在哪台机器，kubelet 才负责在这台机器上拉镜像、启动容器、执行探针、挂载卷，并持续向 API Server 上报状态。

2.2.2 kube-proxy

kube-proxy 负责 Service 的网络转发规则。

作用：

  • 监听 Service 和 Endpoint / EndpointSlice 变化；
  • 在节点上维护 iptables 或 IPVS 规则；
  • 把访问 Service ClusterIP 的流量转发到后端 Pod。

面试标准回答：

kube-proxy 是 Service 负载均衡的实现组件。Service 本身只是一个抽象对象，真正的数据转发规则由 kube-proxy 在每台节点上维护，常见实现方式是 iptables 或 IPVS。

2.2.3 container runtime

容器运行时负责真正运行容器。

常见运行时：

  • containerd；
  • CRI-O；
  • Docker 早期常见，新版本 K8s 不再直接依赖 Docker，而是通过 CRI 对接运行时。

面试标准回答：

K8s 不直接运行容器，而是由 kubelet 通过 CRI 调用容器运行时。运行时负责拉镜像、创建容器、启动容器、停止容器。

3. K8s 核心设计思想

3.1 声明式 API

K8s 的使用方式不是告诉系统一步一步怎么做，而是告诉系统想要什么状态。

例如：

yaml 复制代码 
replicas: 3

含义是：

text 复制代码 
我希望一直有 3 个副本运行

K8s 会自动维护：

text 复制代码 
期望状态：3 个 Pod
实际状态：2 个 Pod
控制器动作：创建 1 个新 Pod

面试标准回答：

K8s 的核心是声明式 API。用户提交期望状态，控制器通过控制循环不断对比实际状态和期望状态，并自动修复偏差。这也是它能自愈、扩缩容、滚动更新的基础。

3.2 资源与对象

K8s 中万物皆资源。

常见资源：

  • Pod；
  • Deployment；
  • ReplicaSet；
  • StatefulSet；
  • DaemonSet；
  • Service；
  • Ingress；
  • ConfigMap；
  • Secret；
  • PV；
  • PVC；
  • StorageClass；
  • Namespace；
  • Role；
  • ClusterRole；
  • HPA。

对象是资源的实例。

例如：

text 复制代码 
Pod 是资源类型
nginx-xxx 是一个具体 Pod 对象

3.3 spec 与 status

每个对象通常都有：

text 复制代码 
spec：期望状态，用户定义
status：实际状态，K8s 维护

示例：

yaml 复制代码 
spec:
  replicas: 3

status:
  availableReplicas: 2

面试标准回答：

spec 描述用户想要的状态，status 描述当前实际状态。K8s 控制器会持续比较两者，如果不一致，就执行对应动作，比如创建 Pod、删除 Pod、重新调度等。

3.4 Label 与 Selector

Label 是对象上的键值对。

yaml 复制代码 
labels:
  app: nginx
  version: v1

Selector 用来选择一组对象。

yaml 复制代码 
selector:
  matchLabels:
    app: nginx

典型用途：

  • Deployment 通过 selector 管理 ReplicaSet / Pod；
  • Service 通过 selector 找到后端 Pod；
  • kubectl 通过 label 查询资源；
  • 调度时配合亲和性使用。

面试标准回答：

Label 是资源对象的标签，Selector 是筛选标签的规则。K8s 中很多资源之间不是靠名字硬绑定，而是通过 Label + Selector 关联，比如 Service 通过 selector 找到一组 Pod，再把流量转发过去。

4. Pod 详解

4.1 Pod 是什么？

Pod 是 Kubernetes 中最小的可部署和调度单元。

一个 Pod 可以包含：

  • 一个容器；
  • 多个紧密协作的容器；
  • 共享网络命名空间；
  • 共享存储卷；
  • 独立的 Pod IP；
  • 容器启动参数；
  • 资源请求和资源限制。

常见模式：

text 复制代码 
一个 Pod 一个业务容器：最常见
一个 Pod 多个容器：Sidecar / Adapter / Ambassador 模式

4.2 为什么 K8s 不直接调度容器，而是调度 Pod？

面试标准回答：

因为真实应用中有些容器天然需要紧密协作，比如业务容器和日志采集 sidecar、服务网格 sidecar、配置热更新 sidecar。它们需要共享网络、共享存储、共同调度、共同生命周期管理。如果直接以容器为调度单位，很难表达这种紧耦合关系。Pod 抽象把一组紧密协作的容器封装成一个逻辑主机，对外表现为一个部署单元，这样既能支持单容器应用，也能支持多容器协作。

底层理解：

text 复制代码 
同一个 Pod 内：
- 共享 network namespace，因此 localhost 可互相访问；
- 共享 Pod IP；
- 可以共享 Volume；
- 会被调度到同一台 Node；
- 生命周期通常绑定在一起。

4.3 Pod 生命周期

阶段 含义
Pending Pod 已创建，但还没有完全运行，可能在调度或拉镜像
Running Pod 已绑定节点，至少一个容器正在运行或启动
Succeeded 所有容器正常退出，不再重启
Failed 至少一个容器异常退出且不会再重启
Unknown 无法获取 Pod 状态，通常是节点通信异常

常见等待原因：

状态 可能原因
ImagePullBackOff 镜像地址错误、私有仓库无权限、网络拉取失败
CrashLoopBackOff 容器启动后不断崩溃
Pending 资源不足、调度约束不满足、PVC 未绑定
ContainerCreating 正在创建容器、挂载卷、拉镜像
Terminating 正在优雅终止

4.4 Pod 重启策略 restartPolicy

三种策略：

策略 含义
Always 容器退出就重启，默认值，适合长期服务
OnFailure 非 0 退出码才重启，适合 Job
Never 不重启，适合一次性任务

注意：

text 复制代码 
Deployment 通常使用 Always。
Job / CronJob 常用 OnFailure 或 Never。

4.5 InitContainer

InitContainer 是初始化容器，在业务容器启动前执行。

特点：

  • 一定先于业务容器执行；
  • 多个 InitContainer 顺序执行；
  • 前一个成功后才执行下一个；
  • 全部成功后才启动主容器；
  • 适合做初始化检查、等待依赖、下载配置、数据库初始化等。

面试标准回答：

InitContainer 用于在业务容器启动前完成初始化工作。相比 postStart，它可以保证一定在主容器 EntryPoint 之前完成，而且它本身是一个完整容器，可以使用独立镜像和工具执行复杂初始化逻辑。

4.6 三种探针

K8s 有三种核心探针：

  • StartupProbe；
  • LivenessProbe；
  • ReadinessProbe。

4.6.1 StartupProbe：启动探针

判断应用是否已经启动完成。

适用场景：

  • 启动很慢的 Java 应用；
  • 初始化耗时长的服务；
  • 避免 livenessProbe 过早杀死应用。

特点：

text 复制代码 
配置 startupProbe 后，livenessProbe 和 readinessProbe 会等 startupProbe 成功后再开始工作。

4.6.2 LivenessProbe：存活探针

判断容器是否还活着。

失败后：

text 复制代码 
kubelet 会根据 restartPolicy 重启容器

适用场景：

  • 应用死锁；
  • 进程假死；
  • 连接池阻塞；
  • 服务内部不可恢复错误。

4.6.3 ReadinessProbe：就绪探针

判断容器是否可以接收流量。

失败后：

text 复制代码 
Pod 不会被重启
但会从 Service 后端 Endpoint 中摘除
不再接收流量

适用场景：

  • 应用启动中；
  • 依赖数据库未连接；
  • 缓存未加载；
  • 临时不可服务。

4.7 Liveness 和 Readiness 区别

面试标准回答：

LivenessProbe 判断容器是否需要重启，失败后 kubelet 会重启容器；ReadinessProbe 判断容器是否可以对外提供服务，失败后不会重启容器，只会把 Pod 从 Service 的流量后端摘掉。简单说，Liveness 管"要不要重启"，Readiness 管"要不要接流量"。

4.8 探针检测方式

方式 说明
HTTPGet 访问 HTTP 接口，2xx/3xx 通常视为成功
TCPSocket 检查端口是否能建立 TCP 连接
Exec 在容器内执行命令，返回 0 表示成功

生产建议：

text 复制代码 
HTTP 服务优先用 HTTPGet
非 HTTP 服务可用 TCP
复杂自检可以用 Exec，但注意命令开销

4.9 Pod 优雅终止

删除 Pod 时流程大致是：

text 复制代码 
1. Pod 被标记为 Terminating
2. Endpoint / EndpointSlice 中摘除 Pod IP
3. kubelet 执行 preStop
4. 向容器主进程发送 SIGTERM
5. 等待 terminationGracePeriodSeconds
6. 超时后发送 SIGKILL 强杀

面试标准回答：

K8s 删除 Pod 不是立刻 kill，而是先从 Service 后端摘除，避免新流量进入，然后执行 preStop，再发送 SIGTERM 给容器主进程，让应用有机会关闭连接、刷盘、注销注册中心、处理完正在执行的请求。如果超过 terminationGracePeriodSeconds 还没退出，就会 SIGKILL 强制终止。

4.10 preStop 的作用

preStop 是容器停止前的钩子。

常用场景：

  • 让应用 sleep 几秒，等待负载均衡摘流量；
  • 调用接口通知注册中心下线；
  • 执行清理逻辑；
  • 等待请求处理完成。

注意：

text 复制代码 
preStop 执行时间也算在 terminationGracePeriodSeconds 内。
如果 preStop 要 sleep 20s，优雅终止时间不能设置太短。

4.11 requests 与 limits

yaml 复制代码 
resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 512Mi
字段 含义
requests.cpu 调度时预留的 CPU
requests.memory 调度时预留的内存
limits.cpu 容器最多可使用的 CPU
limits.memory 容器最多可使用的内存

面试标准回答：

requests 主要影响调度，Scheduler 根据 requests 判断节点资源是否足够；limits 是运行时上限。CPU 超过 limit 会被限流，内存超过 limit 通常会触发 OOMKilled。

5. Workload 控制器

不要直接裸跑 Pod。

原因：

text 复制代码 
Pod 自身不具备自愈能力。
如果节点故障或 Pod 被删除，裸 Pod 不会自动补回来。

生产通常使用控制器管理 Pod。

5.1 ReplicaSet

ReplicaSet 保证某个 Pod 副本数始终满足期望。

例如：

text 复制代码 
期望副本数：3
实际副本数：2
ReplicaSet 创建 1 个新 Pod

一般不直接使用 ReplicaSet，而是通过 Deployment 间接使用。

5.2 Deployment

Deployment 是最常见的无状态应用控制器。

能力：

  • 管理 ReplicaSet；
  • 管理 Pod 副本；
  • 滚动更新；
  • 回滚；
  • 扩容缩容；
  • 暂停和恢复发布；
  • 保证高可用。

关系：

text 复制代码 
Deployment -> ReplicaSet -> Pod

面试标准回答：

Deployment 是用于部署无状态服务的高级控制器。它并不直接管理 Pod，而是通过 ReplicaSet 管理 Pod 副本。Deployment 提供声明式更新、滚动发布、回滚、扩缩容等能力，是生产部署 Web 服务、后端服务最常用的资源。

5.3 Deployment 滚动更新原理

触发条件：

text 复制代码 
只有修改 spec.template 中的内容才会触发滚动更新。
例如修改镜像版本、环境变量、资源限制、探针等。

不会触发滚动更新的操作：

text 复制代码 
只修改 replicas 副本数。

滚动更新过程：

text 复制代码 
1. 创建新的 ReplicaSet
2. 按策略逐步增加新 Pod
3. 同时逐步减少旧 Pod
4. 新 Pod Ready 后才继续替换
5. 保证服务整体可用

关键参数：

参数 含义
maxSurge 更新时最多可以额外创建多少 Pod
maxUnavailable 更新时最多允许多少 Pod 不可用
revisionHistoryLimit 保留多少历史版本用于回滚

示例：

yaml 复制代码 
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 25%
    maxUnavailable: 25%

面试标准回答：

Deployment 滚动更新时会创建新的 ReplicaSet，然后按照 maxSurge 和 maxUnavailable 控制新旧 Pod 替换节奏。新 Pod Ready 后，旧 Pod 才会逐步下线，从而尽量保证服务不中断。

5.4 Deployment 回滚

常用命令：

bash 复制代码 
kubectl rollout history deployment/nginx
kubectl rollout undo deployment/nginx
kubectl rollout undo deployment/nginx --to-revision=2

典型场景：

text 复制代码 
镜像版本写错
新版本启动失败
新版本探针失败
业务异常，需要回退到稳定版本

面试标准回答：

Deployment 每次 PodTemplate 变更都会生成新的 revision，并保留历史 ReplicaSet。回滚本质上是把当前 Deployment 的 PodTemplate 恢复到历史版本，然后重新触发一次滚动更新。

5.5 Deployment 扩容缩容

命令：

bash 复制代码 
kubectl scale deployment nginx --replicas=5

注意：

text 复制代码 
扩容缩容只改变 replicas，不改变 PodTemplate，因此不会创建新的 ReplicaSet revision。

5.6 StatefulSet

StatefulSet 用于有状态服务。

典型应用：

  • MySQL；
  • Redis；
  • Kafka；
  • ZooKeeper；
  • Elasticsearch。

StatefulSet 保证三类稳定性：

稳定性 说明
稳定网络标识 Pod 名称固定，如 web-0、web-1
稳定存储 每个 Pod 绑定自己的 PVC
有序部署和删除 创建从 0 到 N-1，删除从 N-1 到 0

依赖：

text 复制代码 
StatefulSet 通常需要 Headless Service 提供稳定 DNS。

DNS 形式：

text 复制代码 
pod-name.service-name.namespace.svc.cluster.local

面试标准回答：

StatefulSet 用来部署有状态服务。相比 Deployment，它能保证 Pod 名称稳定、网络标识稳定、存储稳定，并且按顺序创建、更新和删除。每个 Pod 可以通过 volumeClaimTemplates 绑定独立 PVC，所以即使 Pod 重建，也能重新挂载原来的数据。

5.7 StatefulSet 和 Deployment 区别

对比 Deployment StatefulSet
适用场景 无状态服务 有状态服务
Pod 名称 随机 固定有序
网络标识 不稳定 稳定
存储 通常共享或无状态 每个 Pod 独立 PVC
创建删除顺序 无序 有序
典型应用 Web / API 服务 MySQL / Redis / Kafka

面试标准回答：

Deployment 适合无状态服务，Pod 可以任意替换，名称和存储不需要稳定；StatefulSet 适合有状态服务，要求 Pod 身份、网络标识和存储稳定，并且创建、扩容、缩容、删除都有顺序。

5.8 Headless Service

Headless Service 是没有 ClusterIP 的 Service。

yaml 复制代码 
clusterIP: None

作用：

  • 不提供普通负载均衡入口；
  • 直接返回后端 Pod DNS 记录；
  • 常配合 StatefulSet 使用；
  • 为每个 Pod 提供稳定域名。

面试标准回答：

Headless Service 不分配 ClusterIP，也不做普通负载均衡，而是通过 DNS 暴露后端 Pod 的地址。StatefulSet 依赖它给每个有序 Pod 提供稳定 DNS 名称。

5.9 DaemonSet

DaemonSet 保证每个符合条件的 Node 上运行一个 Pod。

典型场景：

  • 日志采集 Agent：Fluentd、Filebeat；
  • 监控 Agent：Node Exporter；
  • 网络组件：kube-proxy、CNI 插件；
  • 存储插件。

面试标准回答：

DaemonSet 适合部署每个节点都需要运行的系统级组件，比如日志采集、节点监控、网络插件。它会保证每个符合调度条件的节点上都有一个副本，新节点加入集群后也会自动创建对应 Pod。

5.10 Job

Job 用于一次性任务。

特点：

  • 执行完成后 Pod 结束；
  • 保证任务成功完成指定次数；
  • 失败可重试；
  • 常用于数据处理、批处理、离线任务。

5.11 CronJob

CronJob 用于定时任务，类似 Linux crontab。

常见字段：

字段 含义
schedule cron 表达式
concurrencyPolicy 并发策略
successfulJobsHistoryLimit 保留成功 Job 数
failedJobsHistoryLimit 保留失败 Job 数
suspend 是否暂停

并发策略：

策略 含义
Allow 允许多个 Job 并发执行
Forbid 上一次没结束则跳过本次
Replace 新 Job 替换旧 Job

面试标准回答：

CronJob 是定时创建 Job 的控制器。它适合周期性任务，比如定时清理、定时报表、备份任务。concurrencyPolicy 控制并发行为，Allow 允许并发，Forbid 会跳过重叠任务，Replace 会用新任务替换旧任务。

6. Service 与服务发现

6.1 为什么需要 Service？

Pod IP 是不稳定的。

原因：

text 复制代码 
Pod 重建后 IP 会变
Deployment 扩缩容后后端 Pod 会变化
客户端不应该直接依赖 Pod IP

Service 提供稳定访问入口。

Service 负责：

  • 给一组 Pod 提供稳定虚拟 IP；
  • 基于 Label Selector 找到后端 Pod；
  • 做四层负载均衡；
  • 配合 DNS 提供服务名访问。

面试标准回答：

Pod IP 是动态变化的，不能作为稳定访问入口。Service 通过 selector 关联一组 Pod，并提供稳定的 ClusterIP 和 DNS 名称。客户端访问 Service，流量会被负载均衡到后端 Pod。

6.2 Service、Endpoint、Pod 的关系

text 复制代码 
Service
  selector: app=nginx
        |
        v
Endpoint / EndpointSlice
  保存匹配到的 Pod IP + Port
        |
        v
Pod

流程：

text 复制代码 
1. Service 根据 selector 匹配 Pod
2. Endpoint Controller 生成 Endpoint / EndpointSlice
3. kube-proxy watch Service 和 Endpoint 变化
4. kube-proxy 在节点维护转发规则
5. 访问 Service IP 的流量转发到后端 Pod

面试标准回答：

Service 不直接保存 Pod，而是通过 selector 匹配 Pod。匹配结果会体现在 Endpoint 或 EndpointSlice 中，里面记录后端 Pod 的 IP 和端口。kube-proxy 根据这些信息生成转发规则，实现 Service 到 Pod 的负载均衡。

6.3 Service 类型

类型 作用
ClusterIP 默认类型，只能集群内部访问
NodePort 在每个节点暴露端口，外部通过 NodeIP:NodePort 访问
LoadBalancer 借助云厂商负载均衡器暴露服务
ExternalName 把 Service 映射到外部域名，返回 CNAME

6.4 ClusterIP

默认类型。

适合：

  • 集群内部微服务互相访问；
  • 后端服务之间通信。

访问方式：

bash 复制代码 
curl http://service-name
curl http://service-name.namespace

6.5 NodePort

NodePort 会在每个节点上打开一个端口。

默认端口范围：

text 复制代码 
30000 - 32767

访问方式：

text 复制代码 
任意 NodeIP:NodePort

缺点：

  • 端口管理麻烦；
  • 直接暴露节点端口；
  • 生产中常配合负载均衡或 Ingress 使用。

6.6 LoadBalancer

适用于云环境。

流程：

text 复制代码 
Service type=LoadBalancer
  -> 云厂商创建外部负载均衡器
  -> 转发到 NodePort / Pod

6.7 ExternalName

ExternalName 把服务名映射到外部域名。

适合：

  • 集群内应用通过统一服务名访问外部服务；
  • 迁移过程中屏蔽外部域名变化。

7. Ingress

7.1 Ingress 是什么？

Ingress 是七层 HTTP/HTTPS 路由规则。

它可以基于：

  • 域名；
  • 路径；
  • TLS；
  • Header；
  • 注解扩展能力。

把外部请求转发到不同 Service。

text 复制代码 
client
  -> Ingress Controller
  -> Ingress rule
  -> Service
  -> Pod

注意：

text 复制代码 
Ingress 只是规则。
真正执行转发的是 Ingress Controller。

常见 Ingress Controller：

  • ingress-nginx；
  • Traefik；
  • HAProxy；
  • 云厂商 Ingress Controller。

7.2 Service 和 Ingress 区别

对比 Service Ingress
层次 四层 TCP/UDP 七层 HTTP/HTTPS
作用 暴露一组 Pod 管理外部 HTTP 路由
负载能力 基础负载均衡 域名、路径、TLS
实现组件 kube-proxy / 云 LB Ingress Controller
典型用途 服务内部访问 Web/API 网关入口

面试标准回答：

Service 解决的是一组 Pod 的稳定访问和四层负载均衡；Ingress 解决的是 HTTP/HTTPS 入口流量管理，比如按域名和路径转发到不同 Service。Ingress 本身只是规则，必须配合 Ingress Controller 才能生效。

7.3 Ingress pathType

类型 含义
Exact 精确匹配路径
Prefix 前缀匹配
ImplementationSpecific 由具体 Ingress Controller 决定

8. ConfigMap 与 Secret

8.1 ConfigMap

ConfigMap 用来保存非敏感配置。

使用方式：

  • 环境变量；
  • 命令行参数；
  • Volume 文件挂载；
  • 配置文件挂载。

典型用途：

  • application.yml；
  • nginx.conf；
  • JVM 参数；
  • 服务地址；
  • feature flag。

面试标准回答：

ConfigMap 用来把配置从镜像中解耦出来。这样配置修改不需要重新构建镜像，可以让同一份镜像在开发、测试、生产环境中使用不同配置。

8.2 Secret

Secret 用来保存敏感信息。

典型内容：

  • 密码；
  • token；
  • TLS 证书；
  • Docker 私有仓库认证；
  • ServiceAccount token。

常见类型：

类型 说明
Opaque 通用 Secret
kubernetes.io/dockerconfigjson 私有镜像仓库认证
kubernetes.io/tls TLS 证书
ServiceAccount token 访问 API Server 的 token

重要注意：

text 复制代码 
Secret 默认只是 base64 编码，不等于真正加密。
生产环境需要结合 RBAC、etcd encryption at rest、最小权限、外部密钥系统。

面试标准回答：

Secret 用来保存密码、token、证书等敏感数据。它比 ConfigMap 更适合敏感配置，但默认 data 字段只是 base64 编码，不等于加密。生产环境还需要开启 etcd 静态加密、限制 RBAC 权限，并避免把 Secret 泄露到日志或镜像中。

8.3 ConfigMap 和 Secret 区别

对比 ConfigMap Secret
数据类型 普通配置 敏感配置
默认表现 明文 base64 编码
典型内容 配置文件、环境变量 密码、token、证书
权限控制 普通配置权限 更需要 RBAC 限制
是否加密 否 默认不是真加密，需要额外配置

8.4 subPath 热更新问题

使用 ConfigMap / Secret 挂载时：

普通目录挂载

text 复制代码 
ConfigMap 更新后，挂载内容会延迟更新。

subPath 挂载

text 复制代码 
不会自动热更新。

面试标准回答：

ConfigMap 以普通 Volume 方式挂载时，内容可能会延迟更新；但如果使用 subPath 挂载单个文件，更新 ConfigMap 后容器内文件不会自动更新。因为 subPath 本质上是一次性绑定到具体文件路径，不会跟随后续投射内容变化。

9. 存储：Volume、PV、PVC、StorageClass

9.1 Volume

Volume 是 Pod 级别的数据卷。

常见类型：

  • emptyDir；
  • hostPath；
  • nfs；
  • configMap；
  • secret；
  • persistentVolumeClaim；
  • CSI。

9.2 emptyDir

emptyDir 是 Pod 内临时目录。

特点：

  • Pod 创建时创建；
  • Pod 删除时删除；
  • 同一个 Pod 内多个容器可共享；
  • 可使用磁盘或内存。

适用：

  • 临时缓存；
  • 容器间共享临时文件；
  • sidecar 共享日志文件。

注意：

text 复制代码 
emptyDir 生命周期跟 Pod 绑定，不适合持久化数据。

9.3 hostPath

hostPath 把宿主机目录挂到 Pod 中。

特点：

  • 数据存储在具体 Node 上；
  • Pod 删除后数据仍在宿主机；
  • Pod 漂移到其他 Node 后访问不到原数据；
  • 有安全风险。

适用：

  • 节点日志采集；
  • 访问宿主机系统文件；
  • 本地测试。

生产慎用。

面试标准回答：

hostPath 会把宿主机目录挂到 Pod 中，数据和具体节点绑定。它不适合普通业务持久化，因为 Pod 调度到其他节点后就访问不到原来的数据，而且会带来宿主机安全风险。它更适合日志采集、监控 agent 等节点级场景。

9.4 NFS

NFS 是网络文件系统。

特点：

  • Pod 删除后数据不丢；
  • 多个 Pod 可共享；
  • 数据不绑定具体 Node；
  • 性能和一致性依赖 NFS 服务。

9.5 PV 与 PVC

PV：PersistentVolume，集群中的持久化存储资源。

PVC：PersistentVolumeClaim，用户对存储的申请。

关系：

text 复制代码 
Pod -> PVC -> PV -> 真实存储

为什么要有 PVC？

text 复制代码 
业务开发者不需要关心底层是 NFS、Ceph、云盘还是本地盘。
只需要声明：我要 10Gi、ReadWriteOnce 的存储。

面试标准回答：

PV 是集群管理员提供的存储资源，PVC 是用户对存储资源的申请。Pod 不直接绑定具体存储，而是引用 PVC。这样可以把应用和底层存储实现解耦，提高可移植性。

9.6 AccessModes

模式 含义
ReadWriteOnce 单节点读写
ReadOnlyMany 多节点只读
ReadWriteMany 多节点读写
ReadWriteOncePod 单 Pod 读写

常见情况：

text 复制代码 
云盘通常 ReadWriteOnce。
NFS 通常支持 ReadWriteMany。

9.7 PV 回收策略

策略 含义
Retain PVC 删除后 PV 和数据保留，需要手动处理
Delete PVC 删除后 PV 和底层存储一起删除
Recycle 已废弃，不建议使用

面试标准回答：

PV reclaimPolicy 决定 PVC 删除后底层存储如何处理。Retain 会保留数据，适合重要数据；Delete 会自动删除底层存储，适合动态存储；Recycle 已经不推荐使用。

9.8 StorageClass

StorageClass 用于动态制备 PV。

没有 StorageClass 时：

text 复制代码 
管理员提前创建 PV
用户创建 PVC
K8s 绑定 PVC 和 PV

有 StorageClass 时：

text 复制代码 
用户创建 PVC
StorageClass 调用 provisioner
自动创建 PV 和底层存储

面试标准回答：

StorageClass 解决的是动态创建 PV 的问题。用户只需要创建 PVC 并指定 storageClassName，K8s 就可以通过对应 provisioner 自动创建底层存储和 PV，减少管理员手动维护 PV 的成本。

9.9 CSI

CSI 是 Container Storage Interface。

作用：

text 复制代码 
统一容器编排系统和第三方存储系统的接口。

意义：

  • K8s 不需要内置所有存储插件；
  • 存储厂商可以独立开发 CSI Driver；
  • 解耦 K8s 和底层存储系统。

10. 调度机制

10.1 Scheduler 调度流程

大体流程：

text 复制代码 
1. 用户创建 Pod
2. Pod 进入 Pending
3. Scheduler watch 到未调度 Pod
4. 过滤不满足条件的 Node
5. 给剩余 Node 打分
6. 选择最优 Node
7. 写入 Pod 的 nodeName
8. 对应 Node 的 kubelet 启动 Pod

过滤条件包括：

  • 节点资源是否足够；
  • 节点是否 Ready；
  • 端口是否冲突；
  • nodeSelector 是否匹配；
  • nodeAffinity 是否匹配；
  • taints 是否被 toleration 容忍；
  • PVC / PV 是否满足；
  • Pod 亲和反亲和条件是否满足。

10.2 nodeSelector

最简单的节点选择方式。

yaml 复制代码 
nodeSelector:
  disktype: ssd

含义：

text 复制代码 
Pod 只能调度到有 disktype=ssd 标签的节点。

缺点：

text 复制代码 
只支持简单等值匹配，不够灵活。

10.3 nodeAffinity

节点亲和性，比 nodeSelector 更强。

支持：

  • In；
  • NotIn；
  • Exists；
  • DoesNotExist；
  • Gt；
  • Lt。

两类：

类型 含义
requiredDuringSchedulingIgnoredDuringExecution 硬要求，必须满足
preferredDuringSchedulingIgnoredDuringExecution 软要求，尽量满足

面试标准回答：

nodeSelector 是简单标签匹配，nodeAffinity 是更强的节点选择机制，支持更丰富的表达式，并且分为硬亲和和软亲和。硬亲和不满足就不能调度，软亲和不满足也可以调度，只是优先级较低。

10.4 podAffinity / podAntiAffinity

基于 Pod 标签选择节点。

podAffinity：

text 复制代码 
希望和某些 Pod 调度到一起。

podAntiAffinity：

text 复制代码 
希望不要和某些 Pod 调度到一起。

典型场景：

  • 同一个服务的多个副本尽量分散到不同节点；
  • Web 服务尽量靠近缓存服务；
  • 主从组件部署到不同机器提高可用性。

面试标准回答：

nodeAffinity 是根据节点标签选节点，podAffinity 是根据节点上已有 Pod 的标签选节点。podAntiAffinity 常用于把同一应用的多个副本打散到不同节点，避免单点故障。

10.5 Taint 与 Toleration

Taint：污点，打在 Node 上，表示这个节点不希望普通 Pod 调度过来。

Toleration：容忍，写在 Pod 上，表示这个 Pod 可以容忍某个污点。

关系：

text 复制代码 
Node 有污点
Pod 没有对应容忍
=> Pod 不能调度到该节点

污点效果：

effect 含义
NoSchedule 不允许新 Pod 调度上来
PreferNoSchedule 尽量不要调度上来
NoExecute 不仅不调度，还会驱逐不容忍的已有 Pod

面试标准回答：

Taint 是节点排斥 Pod 的机制，Toleration 是 Pod 表示自己能容忍某些污点。它们通常配合使用，把某些节点保留给特殊业务，比如 GPU 节点、存储节点、Master 节点等。

10.6 Taint/Toleration 和 Affinity 区别

对比 Affinity Taint/Toleration
主体 Pod 主动选择节点 Node 排斥 Pod
方向 吸引 排斥
用途 想去哪类节点 哪些 Pod 能来这个节点
常见场景 按节点类型调度 专用节点隔离

面试标准回答：

亲和性是 Pod 主动选择节点，污点是节点主动排斥 Pod。Affinity 表达"我想去哪里"，Taint 表达"谁不能来我这里"，Toleration 表达"我能容忍这个限制"。

10.7 cordon、drain、uncordon

bash 复制代码 
kubectl cordon node1
kubectl drain node1 --ignore-daemonsets
kubectl uncordon node1
命令 作用
cordon 标记节点不可调度，但不驱逐已有 Pod
drain 驱逐节点上的 Pod，常用于节点维护
uncordon 恢复节点可调度

面试标准回答：

节点维护时先 cordon，避免新 Pod 调度上来；再 drain，把已有 Pod 安全驱逐到其他节点；维护完成后 uncordon 恢复调度。

11. HPA 自动扩缩容

11.1 HPA 是什么？

HPA：Horizontal Pod Autoscaler，Pod 水平自动扩缩容。

作用：

text 复制代码 
根据 CPU、内存或自定义指标，自动调整 Deployment / StatefulSet 等工作负载的副本数。

常用对象：

  • Deployment；
  • ReplicaSet；
  • StatefulSet。

不适合：

  • DaemonSet；
  • 不能水平扩展的有状态服务。

11.2 HPA 工作原理

流程：

text 复制代码 
1. metrics-server 采集 Pod 指标
2. HPA Controller 周期性获取指标
3. 对比目标利用率
4. 计算期望副本数
5. 修改目标 workload 的 replicas
6. Deployment / RS 创建或删除 Pod

前提：

text 复制代码 
容器必须配置 resources.requests。
否则 CPU 利用率百分比无法正确计算。

面试标准回答：

HPA 通过 metrics-server 获取 Pod 的资源使用情况，根据目标 CPU 或内存利用率计算期望副本数，然后修改 Deployment 的 replicas。真正创建和删除 Pod 的还是 Deployment/ReplicaSet。使用 CPU 百分比扩容时必须配置 requests.cpu，因为利用率是实际使用量除以 requests 计算出来的。

11.3 HPA 常用命令

bash 复制代码 
kubectl autoscale deployment nginx --cpu-percent=60 --min=2 --max=10
kubectl get hpa
kubectl describe hpa nginx
kubectl top pod

12. RBAC 权限控制

12.1 RBAC 是什么？

RBAC：Role-Based Access Control，基于角色的访问控制。

核心对象：

对象 说明
Role 命名空间级权限集合
ClusterRole 集群级权限集合
RoleBinding 在某个 namespace 内把主体绑定到 Role/ClusterRole
ClusterRoleBinding 在整个集群范围把主体绑定到 ClusterRole
ServiceAccount Pod 内访问 API Server 的身份

12.2 Role 和 ClusterRole 区别

对比 Role ClusterRole
作用范围 namespace 内 集群级
可授权资源 命名空间资源 命名空间资源 + 集群资源
典型资源 Pod、Service、ConfigMap Node、PV、Namespace
绑定方式 RoleBinding ClusterRoleBinding 或 RoleBinding

注意：

text 复制代码 
ClusterRole 也可以通过 RoleBinding 绑定到某个 namespace 内使用。

12.3 ServiceAccount

ServiceAccount 是 Pod 访问 Kubernetes API 的身份。

典型场景：

  • Jenkins Pod 操作集群资源；
  • Ingress Controller watch Ingress；
  • Prometheus 抓取集群资源；
  • 自定义 Controller watch API Server。

面试标准回答：

普通用户访问集群通常用 User，Pod 内程序访问 API Server 通常用 ServiceAccount。生产中应该给 ServiceAccount 绑定最小权限，避免容器被入侵后拥有过大集群权限。

12.4 RBAC 面试标准答案

RBAC 用来控制谁可以对哪些资源执行哪些动作。Role 是命名空间级权限集合，ClusterRole 是集群级权限集合；RoleBinding 或 ClusterRoleBinding 把用户、用户组或 ServiceAccount 绑定到这些权限集合上。生产中一般使用 ServiceAccount 给 Pod 授权，并遵循最小权限原则。

13. Namespace 与资源隔离

13.1 Namespace 作用

Namespace 是逻辑隔离单位。

常见用途：

  • 多环境隔离：dev、test、prod；
  • 多团队隔离；
  • 多项目隔离；
  • 资源配额隔离；
  • RBAC 权限边界。

默认 namespace：

名称 作用
default 默认命名空间
kube-system K8s 系统组件
kube-public 通常可被所有用户读取
kube-node-lease 节点租约信息

13.2 Namespace 是否等于强隔离？

不是。

Namespace 主要是逻辑隔离，不是强安全隔离。

要实现更完整隔离还需要：

  • RBAC；
  • ResourceQuota；
  • LimitRange；
  • NetworkPolicy；
  • Pod Security；
  • 独立节点池；
  • 多集群隔离。

面试标准回答：

Namespace 主要提供逻辑隔离和资源组织能力，本身不是完整的安全边界。生产中通常还要结合 RBAC、ResourceQuota、LimitRange、NetworkPolicy 等机制实现权限、资源和网络隔离。

14. NetworkPolicy 与网络隔离

14.1 NetworkPolicy 是什么？

NetworkPolicy 用来控制 Pod 间网络访问规则。

可以限制：

  • 哪些 Pod 可以访问当前 Pod；
  • 当前 Pod 可以访问哪些目标；
  • 哪些端口可以访问；
  • 哪些 namespace 可以访问。

注意：

text 复制代码 
NetworkPolicy 需要 CNI 插件支持。
不是所有 CNI 都实现 NetworkPolicy。
Calico 常用来支持 NetworkPolicy。

面试标准回答：

NetworkPolicy 是 K8s 的网络访问控制资源，用于限制 Pod 的入站和出站流量。它本身只是规则，必须依赖支持该能力的 CNI 插件实现，比如 Calico。

15. Helm

15.1 Helm 是什么？

Helm 是 Kubernetes 的包管理工具。

类比：

text 复制代码 
Linux: yum / apt
K8s: Helm

核心概念：

概念 说明
Chart 应用安装包模板
Values 参数配置
Release Chart 安装后生成的一次实例
Repository Chart 仓库

15.2 Helm 解决什么问题？

不用 Helm 时：

text 复制代码 
部署一个复杂应用需要写很多 YAML：
Deployment、Service、Ingress、ConfigMap、Secret、PVC...

使用 Helm 后：

text 复制代码 
模板化 YAML
通过 values.yaml 控制不同环境参数
支持安装、升级、回滚、卸载

常用命令：

bash 复制代码 
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm search repo redis
helm install redis ./redis -n redis
helm upgrade redis ./redis
helm history redis
helm rollback redis 2
helm uninstall redis -n redis

面试标准回答：

Helm 是 K8s 的包管理器，用 Chart 描述一组 Kubernetes 资源，用 values.yaml 参数化配置。它解决了复杂应用 YAML 多、环境差异大、升级回滚不方便的问题。

16. 监控与日志

16.1 metrics-server

metrics-server 提供基础资源指标。

用于：

  • kubectl top；
  • HPA CPU / 内存指标。

注意：

text 复制代码 
metrics-server 不是完整监控系统，只提供实时资源指标，不做长期存储。

16.2 Prometheus

Prometheus 是常见 K8s 监控系统。

核心能力：

  • 指标采集；
  • 时序存储；
  • PromQL 查询；
  • 告警；
  • Grafana 可视化。

K8s 中常见采集对象：

  • kube-apiserver；
  • kubelet / cAdvisor；
  • node-exporter；
  • kube-state-metrics；
  • 应用自定义 metrics。

面试标准回答：

metrics-server 主要给 HPA 和 kubectl top 提供实时资源指标；Prometheus 是完整监控体系，负责采集、存储、查询、告警和可视化，适合生产环境监控。

16.3 ELK / EFK 日志系统

常见架构：

text 复制代码 
Filebeat / Fluentd
  -> Elasticsearch
  -> Kibana

或者：

text 复制代码 
Logstash 做中间处理。

在 K8s 中常用 DaemonSet 部署日志采集 Agent。

原因：

text 复制代码 
每个 Node 都需要采集本机容器日志。
DaemonSet 正好保证每个节点一个日志采集 Pod。

面试标准回答：

K8s 日志采集通常用 DaemonSet 在每个节点部署 Filebeat 或 Fluentd，采集容器标准输出或宿主机日志文件，再发送到 Elasticsearch，最后用 Kibana 查询和分析。

17. DevOps 与 K8s 落地

常见链路：

text 复制代码 
开发提交代码
  -> GitLab
  -> Jenkins 触发流水线
  -> Maven / Gradle 构建
  -> 单元测试 / SonarQube 扫描
  -> Docker 构建镜像
  -> 推送 Harbor 镜像仓库
  -> kubectl / Helm 部署到 K8s
  -> Prometheus 监控
  -> ELK 日志分析

面试标准回答：

在 DevOps 落地中，K8s 主要作为应用运行平台。CI 负责代码编译、测试、镜像构建和推送，CD 负责用 kubectl 或 Helm 更新 K8s 资源。发布后通过 Prometheus 监控指标，通过 ELK/EFK 收集日志，实现完整闭环。

18. 常用 kubectl 命令

18.1 查看资源

bash 复制代码 
kubectl get pod
kubectl get pod -A
kubectl get pod -o wide
kubectl get svc
kubectl get deploy
kubectl get rs
kubectl get node
kubectl get ingress
kubectl get pvc
kubectl get pv

18.2 描述资源

bash 复制代码 
kubectl describe pod <pod-name>
kubectl describe deploy <deploy-name>
kubectl describe svc <svc-name>
kubectl describe node <node-name>

18.3 日志与进入容器

bash 复制代码 
kubectl logs <pod-name>
kubectl logs -f <pod-name>
kubectl logs <pod-name> -c <container-name>
kubectl exec -it <pod-name> -- sh
kubectl exec -it <pod-name> -c <container-name> -- sh

18.4 发布和回滚

bash 复制代码 
kubectl set image deployment/nginx nginx=nginx:1.25
kubectl rollout status deployment/nginx
kubectl rollout history deployment/nginx
kubectl rollout undo deployment/nginx
kubectl rollout undo deployment/nginx --to-revision=2

18.5 扩缩容

bash 复制代码 
kubectl scale deployment nginx --replicas=5
kubectl autoscale deployment nginx --cpu-percent=60 --min=2 --max=10
kubectl get hpa

18.6 节点维护

bash 复制代码 
kubectl cordon node1
kubectl drain node1 --ignore-daemonsets
kubectl uncordon node1
kubectl taint nodes node1 dedicated=gpu:NoSchedule

18.7 常用资源缩写

资源 缩写
pods po
services svc
deployments deploy
replicasets rs
daemonsets ds
configmaps cm
secrets 无常用缩写
namespaces ns
nodes no
persistentvolumes pv
persistentvolumeclaims pvc
horizontalpodautoscalers hpa
ingresses ing
endpoints ep
serviceaccounts sa

19. 高频面试题标准答案模板

19.1 什么是 Kubernetes？

Kubernetes 是一个开源的容器编排平台，用于自动化部署、扩缩容和管理容器化应用。它通过声明式 API 描述期望状态，再由控制器不断把实际状态调整为期望状态，从而实现自愈、滚动更新、服务发现、负载均衡、配置管理和存储编排等能力。

19.2 Docker 和 Kubernetes 的关系？

Docker 解决的是单机容器运行和镜像构建问题，Kubernetes 解决的是多机器、多容器、大规模应用编排问题。Docker 可以作为容器构建工具，K8s 通过容器运行时运行容器。简单说，Docker 管单个容器，K8s 管一组机器上的大量容器。

19.3 K8s 核心组件有哪些？

控制面包括 kube-apiserver、etcd、kube-scheduler、kube-controller-manager、cloud-controller-manager。工作节点包括 kubelet、kube-proxy 和 container runtime。API Server 是入口，etcd 存储状态，Scheduler 负责调度，Controller Manager 负责控制循环，kubelet 负责节点上 Pod 生命周期，kube-proxy 负责 Service 转发。

19.4 Pod 为什么是最小调度单位？

因为一个业务运行单元可能由多个紧密协作的容器组成，例如业务容器和 sidecar。它们需要共享网络、共享存储、共同调度和生命周期绑定。Pod 把这些容器抽象成一个逻辑主机，对外表现为一个部署和调度单元。

19.5 Pod 和容器有什么区别？

容器是应用进程的运行环境，Pod 是 K8s 调度和管理的最小单位。一个 Pod 可以包含一个或多个容器，同一个 Pod 内的容器共享网络命名空间和存储卷。K8s 不直接调度容器，而是调度 Pod。

19.6 Deployment、ReplicaSet、Pod 的关系？

Deployment 管理 ReplicaSet，ReplicaSet 管理 Pod。Deployment 负责声明式更新、滚动发布和回滚；ReplicaSet 负责维持副本数量；Pod 是真正运行容器的实例。

19.7 Deployment 如何滚动更新？

修改 Deployment 的 PodTemplate 后，会创建新的 ReplicaSet。Deployment 根据 maxSurge 和 maxUnavailable 控制新旧 Pod 替换节奏，逐步创建新 Pod、删除旧 Pod。新 Pod Ready 后才继续更新，从而降低服务中断风险。

19.8 Deployment 如何回滚？

每次修改 PodTemplate 都会产生新的 revision，并保留历史 ReplicaSet。回滚时可以通过 kubectl rollout undo 恢复到上一个或指定 revision，本质上是把 PodTemplate 恢复成历史版本并重新滚动发布。

19.9 StatefulSet 和 Deployment 区别？

Deployment 适合无状态服务，Pod 可任意替换，名称和存储不稳定；StatefulSet 适合有状态服务，提供稳定 Pod 名称、稳定网络标识、稳定存储和有序部署删除，常用于 MySQL、Redis、Kafka 等。

19.10 DaemonSet 适合什么场景？

DaemonSet 保证每个符合条件的节点上运行一个 Pod，适合部署节点级组件，如日志采集 Filebeat/Fluentd、监控 Node Exporter、网络插件、kube-proxy 等。

19.11 Service 是什么？

Service 是一组 Pod 的稳定访问入口。由于 Pod IP 会变化，客户端不应该直接访问 Pod。Service 通过 selector 关联后端 Pod，并提供稳定 ClusterIP 和 DNS 名称，kube-proxy 负责把流量转发到具体 Pod。

19.12 Service 有哪些类型？

常见类型包括 ClusterIP、NodePort、LoadBalancer 和 ExternalName。ClusterIP 用于集群内部访问，NodePort 通过节点端口暴露服务，LoadBalancer 借助云厂商负载均衡器，ExternalName 把服务名映射到外部域名。

19.13 Service 和 Ingress 区别？

Service 提供一组 Pod 的四层稳定访问和负载均衡，Ingress 提供七层 HTTP/HTTPS 路由能力。Ingress 可以根据域名、路径、TLS 等规则把外部流量转发到不同 Service。Ingress 必须配合 Ingress Controller 才能工作。

19.14 kube-proxy 的作用？

kube-proxy 监听 Service 和 Endpoint/EndpointSlice 的变化，并在每个节点上维护 iptables 或 IPVS 转发规则，使访问 Service ClusterIP 的流量可以负载均衡到后端 Pod。

19.15 ConfigMap 和 Secret 区别？

ConfigMap 用于普通配置，Secret 用于密码、token、证书等敏感数据。Secret 默认只是 base64 编码，不等于真正加密。生产中需要结合 RBAC、etcd 静态加密和最小权限使用。

19.16 Secret 为什么说不是加密？

因为 Secret 的 data 字段默认是 base64 编码，base64 可以直接解码，不是加密算法。Secret 的安全性主要依赖 K8s 的访问控制、etcd 加密配置和使用规范。

19.17 PV 和 PVC 是什么？

PV 是集群中的持久化存储资源，PVC 是用户对存储的申请。Pod 通过 PVC 使用 PV，而不是直接关心底层存储实现。这样可以解耦业务应用和具体存储系统。

19.18 StorageClass 是什么？

StorageClass 用于动态制备 PV。用户创建 PVC 并指定 storageClassName 后，K8s 可以通过对应 provisioner 自动创建底层存储和 PV，避免管理员手动提前创建 PV。

19.19 emptyDir 和 hostPath 区别？

emptyDir 是 Pod 生命周期内的临时目录，Pod 删除后数据消失，适合临时缓存和容器间共享。hostPath 是宿主机目录挂载，Pod 删除后数据还在节点上，但和具体节点绑定，有安全风险，生产业务慎用。

19.20 HPA 原理？

HPA 通过 metrics-server 获取 Pod 指标，根据目标 CPU、内存或自定义指标计算期望副本数，然后修改目标资源的 replicas。真正创建或删除 Pod 的还是 Deployment/ReplicaSet。使用 CPU 利用率扩容时，容器必须配置 requests.cpu。

19.21 Liveness、Readiness、Startup 区别？

StartupProbe 判断应用是否启动完成；LivenessProbe 判断应用是否需要重启，失败后 kubelet 会重启容器；ReadinessProbe 判断应用是否可以接收流量，失败后 Pod 会从 Service 后端摘除但不会重启。

19.22 Pod 删除时发生了什么？

Pod 会进入 Terminating 状态，先从 Endpoint 中摘除，避免新流量进入；然后执行 preStop，发送 SIGTERM 给主进程，等待应用优雅退出；超过 terminationGracePeriodSeconds 后发送 SIGKILL 强杀。

19.23 InitContainer 和 postStart 区别？

InitContainer 一定在主容器启动前执行，且可以使用独立镜像完成复杂初始化；postStart 是容器启动后的生命周期钩子，不保证一定在容器 EntryPoint 前执行。需要严格启动前初始化时，应使用 InitContainer。

19.24 nodeSelector 和 nodeAffinity 区别？

nodeSelector 是简单的节点标签等值匹配；nodeAffinity 功能更强，支持 In、NotIn、Exists 等表达式，并区分硬亲和 required 和软亲和 preferred。

19.25 亲和性和污点容忍区别？

亲和性是 Pod 主动选择节点，表达"我想去哪里"；污点是 Node 排斥 Pod，表达"谁不能来这里"；容忍是 Pod 表达自己可以接受某个污点。它们常配合实现专用节点调度。

19.26 RBAC 是什么？

RBAC 是基于角色的访问控制。Role/ClusterRole 定义权限集合，RoleBinding/ClusterRoleBinding 把用户、用户组或 ServiceAccount 绑定到权限上。Role 作用于 namespace，ClusterRole 可以作用于集群级资源。

19.27 ServiceAccount 是什么？

ServiceAccount 是 Pod 内程序访问 Kubernetes API 的身份。比如 Prometheus、Ingress Controller、Jenkins Agent 等需要访问 API Server 时，通常通过 ServiceAccount 加 RBAC 授权。生产中应遵循最小权限原则。

19.28 Namespace 是强隔离吗？

Namespace 主要是逻辑隔离，用于区分环境、团队、项目和权限边界。它本身不是强安全隔离，生产中还要结合 RBAC、ResourceQuota、LimitRange、NetworkPolicy 等机制实现权限、资源和网络隔离。

19.29 NetworkPolicy 是什么？

NetworkPolicy 是 K8s 的网络访问控制资源，用来限制 Pod 的入站和出站流量。它本身只是规则，必须由支持 NetworkPolicy 的 CNI 插件实现，例如 Calico。

19.30 Helm 是什么？

Helm 是 Kubernetes 的包管理工具。它用 Chart 描述一组 Kubernetes 资源，用 values.yaml 管理参数，并支持安装、升级、回滚和卸载，适合部署复杂应用。

20. 高频排障题

20.1 Pod 一直 Pending 怎么排查？

思路：

text 复制代码 
1. kubectl describe pod 查看 Events
2. 看是否资源不足：CPU / Memory requests 过大
3. 看是否 nodeSelector / nodeAffinity 不匹配
4. 看是否 taint 没有 toleration
5. 看 PVC 是否未绑定
6. 看节点是否 NotReady
7. 看是否端口冲突或调度策略限制

标准回答：

Pending 说明 Pod 还没成功调度或创建。我会先 describe pod 看 Events。如果是调度失败，重点看节点资源、亲和性、污点容忍、PVC 绑定和节点状态；如果是存储问题，就看 PVC/PV/StorageClass；如果是资源不足，就调整 requests 或扩容节点。

20.2 Pod ImagePullBackOff 怎么排查？

常见原因：

  • 镜像名错误；
  • tag 不存在；
  • 镜像仓库网络不通；
  • 私有仓库认证失败；
  • imagePullSecrets 没配置；
  • 节点 DNS 问题。

命令：

bash 复制代码 
kubectl describe pod <pod>
kubectl get secret
kubectl describe secret <image-pull-secret>

标准回答：

ImagePullBackOff 是拉镜像失败后的退避状态。我会先 describe pod 看具体错误，如果是 not found 就检查镜像名和 tag；如果是 unauthorized 就检查 imagePullSecrets；如果是 timeout 就检查节点网络、DNS 和镜像仓库连通性。

20.3 Pod CrashLoopBackOff 怎么排查？

常见原因：

  • 应用启动失败；
  • 配置错误；
  • 环境变量缺失；
  • 端口冲突；
  • 依赖服务不可用；
  • LivenessProbe 配置过激；
  • OOMKilled。

命令：

bash 复制代码 
kubectl logs <pod>
kubectl logs <pod> --previous
kubectl describe pod <pod>
kubectl get events

标准回答：

CrashLoopBackOff 表示容器反复启动失败。我会先看当前日志和 previous 日志，再 describe pod 看退出码、OOMKilled、探针失败等事件。如果是应用配置错误，修配置；如果是 OOM，调大内存 limit 或优化应用；如果是探针过早失败，调整 initialDelaySeconds 或使用 startupProbe。

20.4 Service 访问不到 Pod 怎么排查？

思路：

text 复制代码 
1. kubectl get svc 看 Service 是否存在
2. kubectl get endpoints 看是否有后端 Pod IP
3. 检查 Service selector 是否匹配 Pod label
4. 检查 targetPort 是否等于容器监听端口
5. 检查 Pod readiness 是否 Ready
6. 进入集群内 busybox curl service-name
7. 检查 kube-proxy / CNI / NetworkPolicy

标准回答：

Service 访问不到时，关键看 endpoints 是否为空。如果为空，大概率是 selector 和 Pod label 不匹配，或者 Pod 没 Ready。如果 endpoints 正常，再检查 targetPort、容器端口、kube-proxy、CNI 和 NetworkPolicy。

20.5 Ingress 不生效怎么排查？

思路：

text 复制代码 
1. Ingress Controller 是否部署成功
2. IngressClass 是否匹配
3. Ingress rules host/path 是否正确
4. backend Service 是否存在
5. Service endpoints 是否正常
6. DNS 是否解析到 Ingress Controller
7. Controller 日志是否有报错

标准回答：

Ingress 不生效时，先确认 Ingress Controller 是否正常，因为 Ingress 只是规则，没有 Controller 不会转发。然后检查 IngressClass、域名路径规则、后端 Service 和 endpoints。最后看 DNS、TLS secret 和 Controller 日志。

20.6 HPA 不扩容怎么排查？

思路：

text 复制代码 
1. metrics-server 是否正常
2. kubectl top pod 是否有数据
3. Pod 是否配置 requests.cpu / memory
4. HPA target 是否正确
5. 当前指标是否超过阈值
6. minReplicas / maxReplicas 是否限制
7. 是否存在扩缩容冷却时间

标准回答：

HPA 不扩容时，我会先看 metrics-server 和 kubectl top 是否正常，再检查容器有没有配置 requests，因为 CPU 利用率依赖 requests 计算。然后看 HPA 目标对象、当前指标、maxReplicas 和事件信息。

20.7 PVC 一直 Pending 怎么排查？

思路：

text 复制代码 
1. PVC 指定的 storageClassName 是否存在
2. 是否有可匹配的 PV
3. accessModes 是否匹配
4. requested storage 是否超过 PV 容量
5. StorageClass provisioner 是否正常
6. 动态制备器 Pod 是否正常
7. 底层存储是否可用

标准回答：

PVC Pending 说明没有绑定到合适 PV。我会检查 storageClassName、accessModes、容量是否匹配。如果是动态制备，还要看 provisioner 是否正常、底层存储是否可用。

21. 后端开发面试重点优先级

21.1 一级重点：必须背熟

text 复制代码 
1. K8s 架构组件
2. Pod 为什么是最小单位
3. Deployment / ReplicaSet / Pod 关系
4. Deployment 滚动更新和回滚
5. Service 原理和类型
6. Service / Endpoint / Pod 关系
7. Ingress 和 Service 区别
8. ConfigMap 和 Secret 区别
9. PV / PVC / StorageClass
10. Liveness / Readiness / Startup 探针
11. HPA 原理
12. nodeSelector / affinity / taint / toleration
13. RBAC、Role、ClusterRole、ServiceAccount
14. 常见 Pod 启动失败排查

21.2 二级重点：需要理解

text 复制代码 
1. DaemonSet 场景
2. StatefulSet 原理
3. Headless Service
4. Job / CronJob
5. Helm
6. Prometheus / metrics-server
7. ELK / EFK 日志采集
8. NetworkPolicy
9. Namespace 隔离
10. cordon / drain / uncordon

21.3 三级加分点

text 复制代码 
1. kube-proxy iptables / IPVS
2. CNI / CSI / CRI
3. etcd 备份与恢复
4. Pod 优雅终止
5. subPath 配置热更新问题
6. Pod QoS 与 OOMKilled
7. Service mesh sidecar 理解
8. Jenkins + Harbor + Helm 的 CI/CD 链路

22. 最后一页速记版

text 复制代码 
K8s 是声明式容器编排系统。

API Server：统一入口。
etcd：保存集群状态。
Scheduler：给 Pod 选 Node。
Controller Manager：控制循环，维护期望状态。
kubelet：节点上启动和管理 Pod。
kube-proxy：实现 Service 转发。
container runtime：真正运行容器。

Pod：最小调度单元，共享网络和存储。
Deployment：无状态服务，滚动更新、回滚、扩缩容。
ReplicaSet：保证副本数。
StatefulSet：有状态服务，稳定网络、稳定存储、有序管理。
DaemonSet：每个节点一个 Pod，日志监控网络插件。
Job：一次性任务。
CronJob：定时任务。

Service：稳定访问入口，四层负载均衡。
Endpoint：Service 后端 Pod IP 列表。
Ingress：七层 HTTP/HTTPS 路由，必须配合 Controller。
ConfigMap：普通配置。
Secret：敏感配置，默认 base64 不是加密。
PV：集群存储资源。
PVC：用户存储申请。
StorageClass：动态创建 PV。
HPA：根据指标自动扩缩容。
RBAC：Role / ClusterRole + Binding 控制权限。
ServiceAccount：Pod 访问 API Server 的身份。
Affinity：Pod 选择节点。
Taint：节点排斥 Pod。
Toleration：Pod 容忍污点。

排障口诀：
Pod 起不来：describe + logs + events。
Service 不通：svc -> endpoints -> pod label -> targetPort -> readiness。
Ingress 不通：controller -> ingressClass -> rules -> svc -> endpoints -> DNS。
HPA 不动：metrics-server -> top -> requests -> target -> maxReplicas。
PVC Pending：storageClass -> PV -> accessModes -> capacity -> provisioner。
相关推荐
羊群智妍1 小时前
2026 AI搜索优化｜免费GEO监测工具亲测推荐
笔记
rOuN STAT2 小时前
Golang 构建学习
开发语言·学习·golang
网络工程小王2 小时前
【LangChain Prompt 完整指南】提示词篇
运维·人工智能·学习
啊哈一半醒2 小时前
React 核心知识点系统总结：从基础语法到高级 API，一篇文章梳理完整学习路线
javascript·学习·react.js
ouliten2 小时前
[Triton笔记1]核心概念
笔记·python·深度学习·triton
Resistance丶未来2 小时前
Coding-Interview-University 学习路径实战评测
人工智能·gpt·学习·github·claude·gemini·kimi
ErizJ2 小时前
Docker | 学习笔记
笔记·学习·docker
ErizJ2 小时前
Kafka | 学习笔记
笔记·学习·kafka
ZC跨境爬虫2 小时前
跟着 MDN 学 HTML day_10：（超链接核心语法+路径规则）
前端·css·笔记·ui·html·edge浏览器
热门推荐
01要裂开了！ChatGPT要手机号验证了？注册Codex要求验证电话号码怎么办？2026年登陆Codex要手机号验证的解决办法02GitHub 镜像站点03【AI】2026 年具身智能模型和世界模型总结04Codex 接入 DeepSeek API 完整配置文档05裂开！ChatGPT 居然开始要手机号验证，附详细解决方法06零基础教你claude code 接入 deepseek V4072026年AI前瞻：量子AI、具身智能与科学发现的新纪元08在Windows 11上安装Docker的踩坑记录09实测可用｜小米 MiMo 百万亿 Token 免费领，开发者速冲10CVE-2026-31431 (Copy Fail) 漏洞复现与验证记录