1. 课程导入与全景认知
在 Kubernetes 与容器化应用大规模落地的今天，一个绕不开的现实问题是：容器本身是无状态的、可随时销毁重建的，但数据库、消息队列、日志检索、AI 训练数据集这类有状态工作负载，必须把数据落到真正持久、可靠、可迁移的存储上。这就是容器持久化存储（Persistent Storage for Containers）要解决的核心命题。本课程围绕 HPE Alletra 存储平台，讲解它如何通过 CSI（Container Storage Interface）驱动与 Kubernetes 对接，为容器提供企业级持久卷能力。
要理解 HPE Alletra 的定位，先要看清它在整个存储栈中的位置。容器持久化存储大致分为三层：最上层是 Kubernetes 的存储抽象（PV、PVC、StorageClass、VolumeSnapshot），中间层是 CSI 插件（负责把 K8s 的存储请求翻译成后端存储的 API 调用），最下层是真正的存储系统（提供块、文件、快照、克隆、复制等能力）。HPE Alletra 属于最下层，同时 HPE 提供了对应的 CSI 驱动，把 Alletra 的块存储能力暴露给 K8s。下图展示了这一分层关系与数据路径。
从图中可以看到，K8s 侧只关心“我要一个 100Gi 的 ReadWriteOnce 卷”，而 CSI 驱动负责把这个声明翻译成 Alletra 上的实际卷创建动作，并把它挂载到目标节点。理解这条链路，是后续所有实验和排障的基础。
HPE Alletra 的核心价值
为什么在众多存储方案中选择 HPE Alletra 做容器持久化？可以从四个维度理解它的价值。
- 企业级可靠性：Alletra 提供多控制器冗余、双活路径、数据校验与自动故障切换，容器卷不会因为单点硬件故障而丢失数据。
- 性能与 QoS：支持为不同 PVC 设置性能上限，避免某个批处理任务把存储带宽吃满，影响在线业务。
- 数据服务能力：快照、克隆、远程复制这些能力可以直接通过 CSI 暴露给 K8s，用于数据库备份、测试环境快速搭建、跨站点容灾。
- 统一管理：通过 HPE GreenLake / Data Services Cloud Console 统一管理存储资源，容器卷和传统虚机卷在同一平台可见。
需要强调的是，Alletra 并不是“为容器专门造的新存储”，而是把成熟的企业存储能力通过 CSI 标准化接口开放给容器平台。这意味着容器工作负载可以获得与传统关键业务同等级的数据保护。
学习路径
本课程共 30 章，建议按“认知 → 部署 → 使用 → 运维 → 进阶”的顺序推进。前几章建立全景认知与环境准备；中间章节深入 CSI 驱动部署、StorageClass 定义、PVC 动态供给、快照与克隆；后续章节覆盖扩容、监控、故障排查、多集群与容灾场景。每一章都会给出可操作的命令、参数和判断依据，而不是停留在概念层面。
实验环境准备
为了让后续实验可复现，这里给出一个参考环境。请注意，以下参数属于教学示例配置，实际部署时应根据你的集群规模和存储阵列型号调整。
| 组件 | 示例配置 | 说明 |
|---|---|---|
| Kubernetes 集群 | v1.28，3 个 worker 节点 | 支持 CSI 与 VolumeSnapshot |
| 容器运行时 | containerd 1.7 | 需启用 mount propagation |
| HPE Alletra | Alletra 6000，双控制器 | 提供 iSCSI 数据路径 |
| CSI 驱动 | hpe-csi-driver v2.x | 通过 Helm 部署 |
| 管理网络 | 10.10.20.0/24 | K8s 节点访问阵列管理口 |
| 数据网络 | 10.10.30.0/24 | iSCSI 数据路径 |
部署前需要确认几个前提条件：所有 worker 节点已安装 iSCSI initiator（iscsid 服务运行中）；节点能解析并访问 Alletra 的管理 IP；集群已启用 CSISnapshot 相关 CRD。可以用下面的命令快速检查：
# 检查 iSCSI 服务
systemctl status iscsid
# 检查节点是否识别到 CSI 相关 CRD
kubectl get crd | grep -E "volumesnapshot|csidriver"
# 查看集群节点状态
kubectl get nodes -o wide