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

AOwhisky2026-06-28 8:58

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

本自测解析针对 Kubernetes 系列第五期（存储与配置管理）和第六期（控制器管理）的核心内容。共 10 题，每题包含题目回顾、考查知识点、详细解答与分析，帮助读者巩固存储、配置与控制器管理技能。

第五期：存储与配置管理（5 题）

题目一：emptyDir、hostPath、NFS 三种 Volume 的区别

题目：请对比 Kubernetes 中 emptyDir、hostPath 和 NFS 三种 Volume 类型的特性，包括：数据持久性、跨节点共享能力、适用场景。并说明为什么 hostPath 不适合生产环境多节点集群？

考查知识点
  • Volume 类型对比 ------ 第五期 §2、§3、§4
  • 各类型适用场景
详细解答
特性 emptyDir hostPath NFS
数据持久性 Pod 删除即清除 宿主机保留 服务端保留
跨节点共享 ❌ 不共享 ❌ 不共享（各节点独立） ✅ 共享
适用场景 容器间临时数据共享 单节点测试、访问宿主机文件 跨节点共享存储
生产环境推荐 中等 ❌ 低 ✅ 高
数据安全性 低（随 Pod 删除） 中（宿主机保留，但依赖节点） 高（集中存储）

hostPath 不适合多节点集群的原因：

  1. 数据不跨节点：Pod 被调度到不同节点时，数据不可见
  2. 节点故障数据丢失：节点宕机后，本地数据可能无法恢复
  3. 权限问题：不同节点上目录权限可能不一致
  4. 安全风险：Pod 可能访问宿主机敏感目录

题目二：PV 与 PVC 架构及访问模式

题目：请解释 Kubernetes 中 PV 和 PVC 的概念及其关系。PV 的访问模式有哪些？每种访问模式的缩写是什么？NFS 支持哪些访问模式？

考查知识点
  • PV/PVC 架构 ------ 第五期 §5.1
  • 访问模式（accessModes）------ 第五期 §5.5
详细解答

PV（PersistentVolume）：集群级别的存储资源，由管理员预先创建，描述后端存储的容量、类型和访问方式。

PVC（PersistentVolumeClaim）：命名空间级别的存储申请，由用户创建，声明所需的存储容量和访问模式。

绑定关系：Kubernetes 控制平面根据 PVC 的请求（容量、访问模式、存储类）自动匹配合适的 PV 并进行绑定。

访问模式：

模式 缩写 含义 NFS 支持
ReadWriteOnce RWO 单节点读写 ✅
ReadOnlyMany ROX 多节点只读 ✅
ReadWriteMany RWX 多节点读写 ✅
ReadWriteOncePod RWOP 单 Pod 读写 取决于驱动

关键理解：NFS 是少数同时支持 RWO、ROX、RWX 三种访问模式的存储类型，因此非常适合作为 Kubernetes 共享存储的后端。

题目三：PV 回收策略

题目 ：PV 支持哪几种回收策略？请解释 Retain 策略的工作流程。当一个 PV 处于 Released 状态时，如何使其重新可用？

考查知识点
  • PV 回收策略 ------ 第五期 §5.6
  • Retain 策略
详细解答

PV 回收策略：

策略 行为 状态
Retain（默认） PVC 删除后，PV 保留数据，状态变为 Released ✅ 当前支持
Recycle 自动清理数据后重新可用 ❌ 已废弃
Delete 删除 PV 和关联的后端存储 ✅ 当前支持

Retain 策略工作流程：

  1. PVC 被删除
  2. PV 状态变为 Released
  3. PV 仍保留后端的实际数据
  4. PV 中的 claimRef 保留原 PVC 的引用信息
  5. 新的 PVC 无法自动绑定该 PV（因为 claimRef 残留）

使 Released PV 重新可用：

bash

复制代码 
# 1. 查看 PV 状态
kubectl get pv
# 状态为 Released

# 2. 编辑 PV，删除 claimRef 部分
kubectl edit pv web
# 删除 spec.claimRef 整个段落

# 3. 保存后，PV 状态变为 Available
kubectl get pv
# 状态为 Available

# 4. 新的 PVC 可以绑定该 PV

题目四：ConfigMap 与 Secret 的区别

题目：请从用途、数据编码、数据大小、更新机制、安全性五个维度对比 ConfigMap 和 Secret。Secret 的 Base64 编码是加密吗？为什么？

考查知识点
  • ConfigMap vs Secret ------ 第五期 §6、§7
  • Secret 安全性
详细解答
对比维度 ConfigMap Secret
用途 存储非敏感配置数据 存储敏感数据（密码、密钥、证书）
数据编码 明文 Base64 编码
数据大小 1 MiB 1 MiB
更新机制 Volume 方式支持动态更新 Volume 方式支持动态更新
安全性 低 中等（可启用 etcd 加密）

Base64 不是加密：

  • Base64 只是一种编码方式，不是加密算法
  • 任何人都可以解码：echo -n cmVkaGF0 | base64 -d → redhat
  • 真正的安全需要：
    1. 启用 etcd 加密（--encryption-provider-config）
    2. 使用 RBAC 限制 Secret 访问权限
    3. 考虑使用外部 Secret 管理工具（如 HashiCorp Vault）

题目五：ConfigMap 动态更新

题目：当 ConfigMap 以 Volume 方式挂载到 Pod 后，更新 ConfigMap 的内容，Pod 内的文件会自动更新吗？如果是，大概需要多长时间？环境变量方式引用的 ConfigMap 会动态更新吗？

考查知识点
  • ConfigMap 动态更新 ------ 第五期 §6.4
  • Volume 挂载 vs 环境变量
详细解答

Volume 挂载方式：

  • ✅ 会自动更新
  • kubelet 周期性同步检查（默认约 30~60 秒）
  • Pod 内文件内容自动刷新

环境变量方式：

  • ❌ 不会自动更新
  • 环境变量在 Pod 启动时注入一次
  • 需要重启 Pod 才能生效

验证命令：

bash

复制代码 
# 1. 查看当前内容
kubectl exec web -- cat /usr/share/nginx/html/index.html

# 2. 更新 ConfigMap
kubectl edit configmap web1

# 3. 等待约 30~60 秒后再次查看
kubectl exec web -- cat /usr/share/nginx/html/index.html
# 内容已更新

第六期：控制器管理（5 题）

题目六：ReplicaSet 与 Deployment 的关系

题目 ：ReplicaSet 和 Deployment 的关系是什么？为什么生产环境推荐使用 Deployment 而不是直接使用 ReplicaSet？Deployment 的 spec.selector 和 ReplicaSet 的 selector 必须匹配吗？

考查知识点
  • ReplicaSet 与 Deployment 关系 ------ 第六期 §2、§3
  • 控制器层级关系
详细解答

关系：

  • Deployment 管理 ReplicaSet
  • Deployment 通过创建、更新、删除 ReplicaSet 来实现滚动更新和版本回滚
  • 每个 Deployment 版本对应一个 ReplicaSet

层级关系：

text

复制代码 
Deployment (web)
    └── ReplicaSet (web-5899d78c9)  ← 版本 1
    │       └── Pod (web-xxx)
    │       └── Pod (web-yyy)
    └── ReplicaSet (web-6c57bdf5f4)  ← 版本 2
            └── Pod (web-zzz)

生产环境推荐 Deployment 的原因：

  1. 支持滚动更新（零停机部署）
  2. 支持版本回滚
  3. 支持暂停/恢复更新
  4. 提供更新历史记录
  5. ReplicaSet 是 Deployment 的实现细节，直接操作 ReplicaSet 会失去上述能力

Selector 匹配规则：

  • Deployment 的 spec.selector 必须 与 ReplicaSet 的 selector 一致
  • 两者都必须匹配 Pod 模板中的 labels
  • 不一致会导致 Deployment 无法管理 ReplicaSet

题目七：滚动更新策略与 maxSurge/maxUnavailable

题目 ：Deployment 滚动更新时，maxSurge 和 maxUnavailable 两个参数的作用是什么？假设期望副本数为 10，maxSurge=25%，maxUnavailable=25%，请计算：最大副本数是多少？最小可用副本数是多少？

考查知识点
  • 滚动更新机制 ------ 第六期 §3.8
  • maxSurge / maxUnavailable
详细解答

参数含义：

参数 含义
maxSurge 滚动更新过程中超过期望副本数的最大数量（百分比或绝对值）
maxUnavailable 滚动更新过程中不可用副本数占期望值的最大比例（百分比或绝对值）

计算（期望副本数=10，maxSurge=25%，maxUnavailable=25%）：

  • maxSurge = ceil(10 × 25%) = 3（向上取整）
  • maxUnavailable = floor(10 × 25%) = 2（向下取整）
结果 数值 计算
最大副本数 13 10 + 3
最小可用副本数 8 10 - 2

配置示例：

yaml

复制代码 
spec:
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%

题目八：DaemonSet 的使用场景与调度

题目：DaemonSet 的典型使用场景有哪些？为什么 master 节点上默认不会运行普通的 DaemonSet Pod？如何让 DaemonSet 在 master 节点上运行？

考查知识点
  • DaemonSet 使用场景 ------ 第六期 §4.1
  • Taint 与 Toleration ------ 第六期 §4.3
详细解答

DaemonSet 典型场景：

场景 示例
日志收集 Fluentd、Logstash（每个节点采集日志）
监控采集 Prometheus Node Exporter（每个节点采集指标）
网络插件 Calico Node、kube-proxy（每个节点提供网络能力）
存储插件 CSI Node Driver（每个节点管理存储卷）

Master 节点默认不运行 DaemonSet Pod 的原因：

  • Master 节点有 Taint（污点） ：node-role.kubernetes.io/control-plane:NoSchedule
  • 该 Taint 阻止普通 Pod 调度到 master 节点
  • 系统级 DaemonSet（如 calico-node、kube-proxy）通过 Toleration 可以绕过

让 DaemonSet 在 master 节点运行的方法：

方法 1：添加 Toleration（推荐）

yaml

复制代码 
spec:
  template:
    spec:
      tolerations:
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule

方法 2：移除 Taint（不推荐）

bash

复制代码 
kubectl taint node master node-role.kubernetes.io/control-plane-

题目九：Job 的 restartPolicy 与 backoffLimit

题目 ：Job 的 restartPolicy 有哪两种有效取值？它们的行为有何不同？backoffLimit 的作用是什么？当一个 Job 因错误命令持续失败时，如何避免无限创建 Pod？

考查知识点
  • Job restartPolicy ------ 第六期 §5.4
  • backoffLimit ------ 第六期 §5.5
详细解答

restartPolicy 有效取值：

策略 行为 Pod 数量 适用场景
Never 失败时创建新的 Pod 可能多个 不希望 Pod 重启，每次都是全新环境
OnFailure 失败时重启 Pod 始终 1 个 希望复用 Pod，减少创建开销

实验对比 （错误命令 echoxxx）：

策略 观察结果
Never 多个 Pod 持续创建，全部 StartError
OnFailure 始终 1 个 Pod，RESTARTS 不断增加

backoffLimit：

  • 控制 Job 失败重试的最大次数
  • 默认值为 6
  • 达到限制后，Job 状态变为 Failed

yaml

复制代码 
spec:
  backoffLimit: 2   # 最多重试 2 次

避免无限创建 Pod：

  1. 设置合理的 backoffLimit
  2. 使用 activeDeadlineSeconds 设置超时
  3. 使用 restartPolicy: Never 时注意重试次数

优先级 ：activeDeadlineSeconds 的优先级高于 backoffLimit。即使重试次数未达到限制，超时后也会终止 Job。

题目十：CronJob 的并发策略与时间表

题目 ：CronJob 的 .spec.concurrencyPolicy 有哪三种取值？分别说明其行为。Cron 时间表 0 2 * * 1-5 表示什么？如果错过了调度时间，如何控制是否执行？

考查知识点
  • CronJob 并发策略 ------ 第六期 §6.4
  • Cron 时间表语法 ------ 第六期 §6.3
  • startingDeadlineSeconds ------ 第六期 §6.4
详细解答

concurrencyPolicy 三种取值：

策略 行为 说明
Allow（默认） 允许并发执行 即使旧 Job 未完成，新 Job 仍会创建
Forbid 禁止并发执行 旧 Job 未完成时，跳过新 Job 的执行
Replace 替换当前运行的任务 取消正在运行的 Job，用新 Job 替换

Cron 时间表解析：

复制代码 
0 2 * * 1-5
  • 分钟：0
  • 小时：2（凌晨 2 点）
  • 日：*（每天）
  • 月：*（每月）
  • 星期：1-5（周一至周五）

含义：每周一至周五凌晨 2 点执行

错过调度时间的控制：

startingDeadlineSeconds：错过了调度时间后，开始任务的截止时间（秒）

yaml

复制代码 
spec:
  startingDeadlineSeconds: 200   # 错过调度后 200 秒内仍可执行
  • 设置后，超过截止时间则跳过该次执行
  • 不设置则没有截止时间
  • 适用于备份等可以跳过、但不能太晚执行的任务

附：知识点对应总表

题号 主要考查知识点（对应笔记章节）
1 第五期 §2、§3、§4 emptyDir / hostPath / NFS 对比
2 第五期 §5.1 PV/PVC 架构；§5.5 访问模式
3 第五期 §5.6 PV 回收策略（Retain）
4 第五期 §6、§7 ConfigMap vs Secret
5 第五期 §6.4 ConfigMap 动态更新
6 第六期 §2 ReplicaSet；§3 Deployment 关系
7 第六期 §3.8 滚动更新机制（maxSurge/maxUnavailable）
8 第六期 §4.1 DaemonSet 场景；§4.3 Taint/Toleration
9 第六期 §5.4 restartPolicy；§5.5 backoffLimit
10 第六期 §6.4 concurrencyPolicy；§6.3 Cron 语法；startingDeadlineSeconds

学习建议：对于答错的题目，请回看第五期或第六期对应章节，并动手在集群环境中验证。存储配置和控制器管理是 Kubernetes 生产环境的核心技能，建议结合实验加深理解。
--- Compiled and Authored by Whisky --- June 27th, 2026

热门推荐
012026年6月AI大模型全景报告：GPT-5.6、Claude Opus 4.8、Gemini 3.5，中美AI三足鼎立谁主沉浮？022026年6月AI行业全景：从百模大战到Agent元年，这30天发生了什么？032026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf04飞书长连接_事件订阅（接收消息，审批任务状态变更）05Trae国际版与国内版深度测评：AI原生IDE的双生花06GitHub 镜像站点07【AI】2026 年具身智能模型和世界模型总结082026年AI架构实战：彻底解决OpenAI接口超时与封号，Python调用GPT-5.2/Sora2企业级架构详解（附源码+压测报告）09Claude Code、Codex、Cursor三分天下：2026年AI编程Agent生态全景剖析102026 AI 编程工具终极实战指南：Cursor vs Claude Code vs Copilot，开发者该怎么选？