企业官网建设流程全解析

kubernetes（K8s）学习笔记：第十三期与第十四期核心知识点自测与详解

本自测解析针对 Kubernetes 系列第十三期（集群存储与有状态应用（上篇）：动态卷供应——StorageClass + Provisioner）和第十四期（集群存储与有状态应用（下篇）：StatefulSet 有状态应用管理）的核心内容。共 10 题，每题包含题目回顾、考查知识点、详细解答与分析，帮助读者巩固 Kubernetes 动态存储与有状态应用管理的核心技能。

文章索引：

Kubernetes（K8s）学习笔记（第十三期）：集群存储与有状态应用（上篇）：动态卷供应——StorageClass + Provisioner

Kubernetes（K8s）学习笔记（第十四期）：集群存储与有状态应用（下篇）：StatefulSet 有状态应用管理

更多自我检测系列欢迎浏览：每日知识点小问答

我的主页：AOwhisky，这里有更多运维系统性知识整理和其他有趣内容，欢迎与我一起探讨学习~

第十三期：动态卷供应（StorageClass + Provisioner）（第 1-5 题）

题目一：动态卷供应与静态卷供应的核心区别

题目：Kubernetes 中动态卷供应和静态卷供应的核心区别是什么？请从 PV 创建方式、管理员工作量、资源利用率、适用场景四个维度对比。为什么动态卷供应是生产环境推荐的方式？

考查知识点

• 动态卷 vs 静态卷对比 —— 第十三期 §1.1、§5.1
• 两种方式的优缺点

详细解答

核心区别：

为什么动态卷供应是生产环境推荐方式：

1. 自动化：用户只需创建 PVC，系统自动完成 PV 创建和绑定，无需管理员干预
2. 高效利用资源：按需分配，避免资源浪费
3. 快速响应：秒级完成存储分配，不影响应用部署速度
4. 可扩展：支持大规模集群，无需为每个 PVC 手动创建 PV
5. 标准化：通过 StorageClass 统一管理存储套餐，降低运维复杂度

题目二：StorageClass 的核心配置字段

题目：StorageClass 的provisioner、reclaimPolicy、volumeBindingMode三个字段分别起什么作用？NFS 存储和本地存储是否有内置的 Provisioner？Local Path Provisioner 的volumeBindingMode应该设置为什么值？为什么？

考查知识点

• StorageClass 核心配置 —— 第十三期 §2
• 各字段含义与适用场景

详细解答

三个核心字段：

NFS 和本地存储的内置 Provisioner：

• NFS：❌没有内置 Provisioner，需部署外部组件（如 NFS Provisioner）
• 本地存储：❌没有内置 Provisioner，需部署外部组件（如 Local Path Provisioner）

Local Path Provisioner 的 volumeBindingMode：

• 应设置为WaitForFirstConsumer
• 原因：本地存储绑定到特定节点，需要等 Pod 调度后才能确定在哪个节点创建 PV
• 如果使用Immediate模式，PV 可能创建在错误的节点上，导致 Pod 无法访问

YAML 示例：

apiVersion:storage.k8s.io/v1kind:StorageClassmetadata:name:local-pathprovisioner:rancher.io/local-pathreclaimPolicy:DeletevolumeBindingMode:WaitForFirstConsumer# 本地存储必须使用此模式

题目三：Local Path Provisioner 的工作原理与局限性

题目：Local Path Provisioner 的工作原理是什么？它使用什么类型的存储？为什么 Local Path Provisioner 不支持 Pod 跨节点调度？请写出其典型使用场景。

考查知识点

• Local Path Provisioner —— 第十三期 §3
• 工作原理与局限性

详细解答

工作原理：

1. Local Path Provisioner 在每个节点上使用本地磁盘目录（默认/opt/local-path-provisioner）
2. 当用户创建 PVC 时，PVC 处于Pending状态（volumeBindingMode: WaitForFirstConsumer）
3. 当 Pod 创建并调度到某个节点后，Provisioner 在该节点上创建对应的存储目录
4. 系统自动创建 PV 并与 PVC 绑定
5. Pod 使用该 PVC 挂载本地存储

Helper Pod 的工作机制：

• 以privileged: true权限运行，确保有权限创建目录
• 使用system-node-critical优先级，不会被驱逐
• 容忍node.kubernetes.io/disk-pressure污点

为什么不支持 Pod 跨节点调度：

• PV 创建在特定节点的本地磁盘上
• PVC 已经绑定了该节点的 PV
• 其他节点无法访问该节点的本地存储
• 因此，使用该 PVC 的所有 Pod 副本都必须调度到同一个节点

典型使用场景：

• ✅ 测试环境的临时存储
• ✅ 对性能要求高、对数据持久性要求不高的场景
• ✅ 单节点存储（不需要跨节点共享）
• ❌ 不适用于需要跨节点共享数据的生产环境

题目四：NFS Provisioner 的部署流程与优势

题目：请简述 NFS Provisioner 的部署流程（从 NFS 服务端到 StorageClass）。NFS Provisioner 相比 Local Path Provisioner 的核心优势是什么？NFS 的volumeBindingMode应该设置为什么值？

考查知识点

• NFS Provisioner 部署 —— 第十三期 §4
• 两种 Provisioner 对比

详细解答

NFS Provisioner 部署流程：

核心优势对比：

NFS 的volumeBindingMode：

• 应设置为Immediate（默认值）
• 原因：NFS 是共享存储，所有节点都可以访问，不绑定特定节点
• 创建 PVC 时即可立即创建 PV 并绑定，无需等待 Pod 调度

题目五：动态卷供应实验——PV 创建失败排查

题目：使用 Local Path Provisioner 创建 PVC 后，PVC 一直处于Pending状态。请列出可能的原因和排查步骤。如果使用 NFS Provisioner 时 Pod 出现CrashLoopBackOff，可能是什么问题？

考查知识点

• 常见错误排查 —— 第十三期 §5.5
• 排错思路

详细解答

Local Path PVC Pending 的可能原因：

排查步骤：

# 1. 检查 PVC 状态和事件kubectl describe pvc<pvc-name># 2. 检查 Provisioner Pod 状态kubectl get pods-nlocal-path-storage# 3. 检查 StorageClasskubectl get sc# 4. 如果使用 Local Path，检查节点目录是否存在ls/opt/local-path-provisioner/

NFS Provisioner Pod CrashLoopBackOff 的可能原因：

第十四期：StatefulSet 有状态应用管理（第 6-10 题）

题目六：StatefulSet 的三大核心特性

题目：StatefulSet 的三大核心特性是什么？请分别说明其含义。为什么 StatefulSet 必须关联 Headless Service？

考查知识点

• StatefulSet 核心特性 —— 第十四期 §2
• Headless Service 的作用

详细解答

StatefulSet 三大核心特性：

为什么必须关联 Headless Service：

• StatefulSet 需要为每个 Pod 提供固定的 DNS 解析
• Headless Service（clusterIP: None）不分配 ClusterIP，只负责 DNS 解析
• Pod 的 DNS 记录格式：<statefulset-name>-<ordinal>.<service-name>.<namespace>.svc.cluster.local
• 例如：nginx-0.nginx.default.svc.cluster.local
• 这保证了 Pod 之间可以通过固定的 DNS 名称互相通信

Headless Service 示例：

apiVersion:v1kind:Servicemetadata:name:nginxspec:clusterIP:None# Headless Serviceselector:app:nginxports:-port:80

题目七：StatefulSet vs Deployment 对比

题目：请从适用场景、网络、存储、扩缩容、更新策略五个维度对比 StatefulSet 和 Deployment。什么场景下应该使用 StatefulSet 而不是 Deployment？

考查知识点

• StatefulSet vs Deployment —— 第十四期 §3
• 选型依据

详细解答

应该使用 StatefulSet 的场景：

典型判断标准：

• 应用实例是否有唯一身份？（如主从、节点编号）
• 应用是否依赖持久化存储？
• 应用启动/关闭是否有顺序要求？
• 如果以上任一答案为“是”，应考虑使用 StatefulSet。

题目八：PVC 模板（volumeClaimTemplates）的工作机制

题目：StatefulSet 中的volumeClaimTemplates是什么？它为每个 Pod 创建的 PVC 命名格式是什么？当 StatefulSet 被删除时，PVC 会自动删除吗？为什么？

考查知识点

• PVC 模板 —— 第十四期 §2.4
• 存储生命周期

详细解答

volumeClaimTemplates的作用：

• 为 StatefulSet 中的每个 Pod 自动创建独立的 PVC
• 每个 Pod 获得专属的存储卷，互不干扰
• 确保 Pod 重建后能复用原有的数据

PVC 命名格式：

<template-name>-<statefulset-name>-<ordinal>

示例：

volumeClaimTemplates:-metadata:name:nginx-data

StatefulSet 名称：nginx，副本数：3

创建的 PVC 名称：

• nginx-data-nginx-0
• nginx-data-nginx-1
• nginx-data-nginx-2

删除 StatefulSet 时 PVC 的行为：

• ❌ PVC不会自动删除

• 原因：数据是核心资产，Kubernetes 不会自动删除 PVC，防止数据丢失

• 如需清理，必须手动删除PVC：

  kubectl delete pvc nginx-data-nginx-0 nginx-data-nginx-1 nginx-data-nginx-2

• 如果 PV 的reclaimPolicy是Delete，删除 PVC 后 PV 和后端存储会被自动清理；如果是Retain，则需管理员手动清理

题目九：StatefulSet 的有序操作与启动依赖

题目：StatefulSet 创建 Pod 时的顺序是什么？为什么需要这种有序操作？在 etcd 集群中，ETCD_INITIAL_CLUSTER环境变量是如何利用 StatefulSet 的固定 DNS 实现集群自动组网的？

考查知识点

• 有序操作 —— 第十四期 §2.3
• etcd 集群组网实验 —— 第十四期 §5

详细解答

创建顺序：

• 从序号 0 开始递增：0 → 1 → 2 → … → N-1
• 前一个 Pod 必须处于Running 和 Ready状态后，才创建下一个
• 每个 Pod 创建间隔约 20~30 秒（由minReadySeconds控制）

缩容顺序：

• 从最大序号开始递减：N-1 → … → 2 → 1 → 0
• 前一个 Pod 彻底删除后，才删除下一个

为什么需要有序操作：

• 有状态应用通常有启动依赖关系
• 主节点（ordinal=0）必须先启动，初始化集群
• 从节点（ordinal>0）依赖主节点的网络地址加入集群
• 如果无序启动，从节点可能无法找到主节点，集群组网失败

etcd 集群自动组网：

env:-name:ETCD_NAMEvalueFrom:fieldRef:fieldPath:metadata.name# 获取 Pod 名称（etcd-0、etcd-1、etcd-2）-name:ETCD_INITIAL_CLUSTERvalue:"etcd-0=http://etcd-0.etcd.statefulset.svc.cluster.local:2380,etcd-1=http://etcd-1.etcd.statefulset.svc.cluster.local:2380,etcd-2=http://etcd-2.etcd.statefulset.svc.cluster.local:2380"

工作原理：

1. ETCD_NAME通过fieldRef获取 Pod 名称（如etcd-0）
2. ETCD_INITIAL_CLUSTER使用固定的 DNS 名称（StatefulSet 提供的稳定网络标识）
3. 每个 etcd 节点通过 DNS 名称找到其他节点
4. 即使 Pod 重建，DNS 名称不变，集群自动恢复
5. 实现了无需手动配置 IP 的自动组网

题目十：StatefulSet 的更新策略与生产环境最佳实践

题目：StatefulSet 支持哪两种更新策略？RollingUpdate策略的默认更新顺序是什么？如果希望只更新序号大于等于特定值的 Pod（金丝雀发布），应该配置什么参数？请写出生产环境中 StatefulSet 的三条最佳实践。

考查知识点

• StatefulSet 更新策略 —— 第十四期 §8
• 生产环境最佳实践 —— 第十四期 §10.6

详细解答

两种更新策略：

RollingUpdate 默认顺序：

• ... → 2 → 1 → 0（逆序）
• 从最大的序号开始更新
• 这样可以确保更新过程中集群的最小可用性

金丝雀发布配置：

apiVersion:apps/v1kind:StatefulSetmetadata:name:webspec:updateStrategy:type:RollingUpdaterollingUpdate:partition:2# 只更新序号 >= 2 的 Pod

• 序号< partition的 Pod 保持不变（稳定版）
• 序号>= partition的 Pod 会被更新（金丝雀版）
• 验证金丝雀版本稳定后，可将partition调整为 0 完成全量更新

生产环境最佳实践：

附：知识点对应总表

学习建议：对于答错的题目，请回看第十三期或第十四期对应章节，并动手在集群环境中执行相关命令。动态存储供应和有状态应用管理是 Kubernetes 生产环境的核心技能，建议通过实际操作加深理解。