📚 课程目录第1章容器持久化存储挑战与ONTAP定位

1. 容器持久化存储挑战与ONTAP定位

容器天生是“无状态、可随时销毁、可快速重建”的工作负载载体。镜像层只读，容器可写层随容器生命周期结束而消失，这一设计让应用发布、扩缩容和滚动升级变得极其轻快，但也直接带来一个矛盾：数据库、消息队列、日志归档、AI 训练数据集、CI 构建缓存等真实业务，必须把数据写到容器生命周期之外。Kubernetes 用 Volume、PersistentVolume（PV）、PersistentVolumeClaim（PVC）、StorageClass 和 CSI 这一整套抽象来解决该矛盾，而 ONTAP 正是通过 CSI 驱动进入这套抽象，成为容器生态中可被动态供给的企业级存储后端。

一、容器存储的三层需求

理解容器持久化，先要区分三类存储需求，它们的生命周期和性能诉求完全不同。

临时存储（ephemeral）：如 emptyDir，随 Pod 创建、随 Pod 删除，用于容器间共享临时文件、缓存中间结果。它不解决持久化问题。
节点本地持久存储（local/hostPath）：数据落在某个节点磁盘上，Pod 重建后若调度到别的节点，数据就“看不见”了，且节点故障即数据不可用。
网络持久存储（PV/PVC + CSI）：数据独立于节点和 Pod 存在，Pod 在任意节点重建后仍能挂载同一份数据，并具备快照、克隆、扩容、复制等企业级能力。ONTAP 属于这一类。

从运维视角看，容器存储真正难的不是“挂上一块盘”，而是四件事：动态供给（PVC 一提交就自动创建卷，无需人工开 LUN）、生命周期解耦（Pod 删除后数据仍在，PVC 删除后按回收策略处理）、访问模式匹配（ReadWriteOnce / ReadOnlyMany / ReadWriteMany / ReadWriteOncePod 与后端协议对应）、数据服务能力（快照、克隆、扩容、加密、QoS、跨站点复制）。这四点决定了存储方案能否支撑生产级容器平台。

二、Kubernetes 持久卷机制的关键链路

Kubernetes 的持久化链路可以概括为“声明—绑定—挂载—回收”四个阶段。用户提交 PVC 声明容量与访问模式；StorageClass 决定由哪个 provisioner（此处即 ONTAP CSI 驱动）来创建卷；CSI 驱动调用 ONTAP 创建对应卷并返回卷标识；kubelet 在 Pod 调度到的节点上通过 CSI Node 插件把卷挂载进容器；当 PVC 被删除时，按 reclaimPolicy（Delete 或 Retain）决定后端卷是删除还是保留。

其中有两个容易被忽视但影响很大的细节。第一，访问模式并不等于协议：ReadWriteMany 通常需要 NFS 或 SMB 这类共享文件协议，而块协议（iSCSI/NVMe/TCP）一般只提供 ReadWriteOnce。第二，拓扑约束：如果后端存储有可用区或节点亲和限制，PV 必须带 nodeAffinity，否则 Pod 可能被调度到无法访问该卷的节点上而一直 Pending。ONTAP 的 SVM、聚合（aggregate）、LIF 与节点/站点布局，会直接影响这些约束的配置方式。

三、ONTAP 在容器生态中的角色与价值

ONTAP 不是“又一块网络盘”，它把企业级数据管理能力带进了 Kubernetes 声明式模型。其价值可归纳为四点：

统一多协议供给：同一套 ONTAP 集群可同时提供 NFS、SMB、iSCSI、NVMe/TCP，对应不同访问模式与性能诉求，避免为文件、块、对象分别建设孤岛存储。
存储效率与数据服务：重复数据删除、压缩、精简配置、SnapMirror/SnapVault、FlexClone、卷级 QoS，这些能力通过 CSI 的 Snapshot、Clone、Resize 接口暴露给 Kubernetes，使“给 PVC 打快照”“从快照克隆新环境”成为标准操作。
多租户与安全隔离：以 SVM 为租户边界，配合导出策略、CHAP、Kerberos、卷加密，满足不同团队、不同命名空间的隔离要求。
与云原生运维对齐：通过 Trident（NetApp 的 CSI 实现）以 CRD 方式声明后端、存储池与 StorageClass，运维人员用 kubectl 即可完成存储编排，而非登录存储命令行手工建卷。

下面这张图把“容器存储需求 → Kubernetes 抽象 → ONTAP/Trident 落地”的对应关系一次看清，重点表达各层之间的映射与数据流方向，而不是罗列步骤。

四、一个可对照的示例：从 PVC 到 ONTAP 卷

下面给出一个教学示例（参数为合理假设，非实测结果），用于说明声明式存储如何落到 ONTAP 对象上。假设某团队需要为 MySQL 提供 100GiB 的块存储，访问模式为 ReadWriteOnce，并希望支持快照。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ontap-iscsi-gold
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san"
  fsType: "ext4"
  storagePools: "ontap_cluster:aggr1"
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-data
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: ontap-iscsi-gold
  resources:
    requests:
      storage: 100Gi

提交后可用 kubectl get pvc mysql-data 观察状态从 Pending 变为 Bound；此时 Trident 已在 ONTAP 的 aggr1 上创建了一个 100GiB 的精简配置 LUN，并映射给对应 igroup。若把 volumeBindingMode 设为 WaitForFirstConsumer，PV 会等到 Pod 调度确定后再创建，从而避免“卷建在 A 站点、Pod 调度到 B 站点”的拓扑错配。删除 PVC 时，因 reclaimPolicy: Delete，后端卷会被回收；若业务要求保留数据，应改为 Retain，并在确认后再手工清理 ONTAP 卷。

判断存储方案是否合格，可以问四个问题：PVC 能否自动供给？Pod 重建后数据是否仍在？访问模式与协议是否匹配？快照、克隆、扩容是否可用？ONTAP + Trident 的价值，正在于让这四个问题都能用声明式方式回答。

五、ONTAP 的定位总结

在容器生态中，ONTAP 的定位不是替代 Kubernetes 的存储抽象，而是成为其背后可靠、可编排、具备企业级数据服务的存储底座。Kubernetes 负责“声明与调度”，CSI/Trident 负责“翻译与执行”，ONTAP 负责“承载与保护”。三者分工清晰，才能让有状态应用在容器平台上获得与虚拟机时代同等甚至更强的数据管理能力。理解这条分层关系，是后续学习 Trident 部署、StorageClass 设计、快照克隆与跨站点复制的起点。