📚 课程目录第4章 NetApp Trident概述与部署规划

4. NetApp Trident概述与部署规划

在 Kubernetes 中，容器本身是无状态的，Pod 重建后本地数据随之消失。要让有状态应用（数据库、消息队列、AI 训练任务等）真正跑在生产环境，必须把存储从集群外部接入，并让存储的生命周期与 PVC/PV 的声明式模型对齐。NetApp Trident 正是承担这一角色的开源项目：它是符合 CSI（Container Storage Interface）规范的动态存储编排器，把 ONTAP、Cloud Volumes ONTAP、Amazon FSx for NetApp ONTAP、Azure NetApp Files 等后端抽象成 Kubernetes 原生的 StorageClass、PVC、VolumeSnapshotClass，让开发者用标准 YAML 就能申请、扩容、快照和克隆存储卷。

Trident 的架构分层

理解 Trident 的关键，是分清“控制面”和“数据面”。控制面由 Trident 控制器（trident-controller）和 Trident 节点插件（trident-node）组成，通常以 Deployment + DaemonSet 形式部署在 trident 命名空间。控制器负责监听 PVC、VolumeSnapshot、VolumeSnapshotContent 等对象，调用后端驱动完成卷的创建、删除、扩容、快照和克隆；节点插件运行在每个工作节点上，负责把远端卷挂载到 Pod 的挂载点，并在卸载时清理挂载状态。数据面则是真正的 ONTAP 存储系统，卷、快照、克隆都落在 SVM 上，Trident 只做编排，不搬运数据。

Trident 通过 CRD 描述自身状态：TridentBackendConfig 定义后端连接信息，TridentProvisioner 记录卷的供应关系，TridentVolumeSnapshot 关联快照对象。这些 CRD 让 Trident 的配置也具备声明式、可版本化的特性，便于 GitOps 管理。

后端配置：TridentBackendConfig 的要点

后端配置是 Trident 与 ONTAP 建立信任的入口。以 ONTAP 为例，需要准备 SVM 的管理 LIF 地址、数据 LIF 地址、具有足够权限的账号密码，以及一个用于存放卷的聚合或 SVM。Trident 支持两种配置方式：一是通过 tridentctl 命令行创建后端，二是通过 TridentBackendConfig CRD 声明式创建。生产环境推荐后者，因为它可以纳入 Git 仓库做版本管理。

一个典型的 ONTAP 后端配置示例（参数为教学示例，实际需替换为真实环境值）：

apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: ontap-nas-backend
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-nas
  backendName: ontap-nas-backend
  managementLIF: 192.168.10.50
  dataLIF: 192.168.10.51
  svm: svm-k8s
  username: trident_admin
  password: "<base64-encoded-password>"
  defaults:
    spaceReserve: none
    snapshotPolicy: default
    snapshotReserve: "10"

其中 storageDriverName 决定协议类型：ontap-nas 对应 NFS，ontap-san 对应 iSCSI，ontap-san-economy 适合多卷共享 LUN 的场景，ontap-nas-economy 适合大量小卷。选择驱动时要结合应用对访问模式的要求：NFS 支持 ReadWriteMany，iSCSI 通常只支持 ReadWriteOnce。配置完成后，用 tridentctl get backend -n trident 或查看 TridentBackendConfig 的 status 字段确认后端是否进入 Success 状态。

存储类与卷快照类

StorageClass 是开发者申请存储的“菜单”。它通过 provisioner: csi.trident.netapp.io 指向 Trident，并用 parameters 把后端名称、协议、快照策略等传递给 Trident。例如：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ontap-nas-gold
provisioner: csi.trident.netapp.io
parameters:
  backendType: ontap-nas
  backendName: ontap-nas-backend
  fsType: nfs
  snapshotPolicy: default
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate

这里 allowVolumeExpansion: true 允许 PVC 在线扩容，reclaimPolicy: Delete 表示 PVC 删除后 PV 也随之删除，适合临时环境；生产环境若需保留数据，可改为 Retain。VolumeSnapshotClass 则用于定义快照的驱动和删除策略，通常与 StorageClass 成对出现：

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: ontap-snapshot-class
driver: csi.trident.netapp.io
deletionPolicy: Delete
parameters:
  snapshotPolicy: default

创建快照时，用户只需声明一个 VolumeSnapshot 对象并引用该 SnapshotClass 和源 PVC，Trident 就会在 ONTAP 上生成对应的 Snapshot 副本。恢复时，可以用快照创建新的 PVC，实现快速克隆。

部署前的环境检查与版本兼容性

Trident 部署失败最常见的原因不是配置写错，而是环境前提不满足。部署前建议按以下清单逐项核对：

Kubernetes 版本：Trident 24.02 及以上支持 Kubernetes 1.25～1.29；若集群版本过旧，需先升级或选择匹配的 Trident 版本。
CSI 与快照组件：确认集群已启用 CSIDriver、CSINode 等特性门控，并安装 snapshot-controller 与 snapshot CRD，否则 VolumeSnapshotClass 无法生效。
节点依赖：使用 iSCSI 时，每个工作节点需安装 iscsi-initiator-utils 并启动 iscsid 服务；使用 NFS 时需确保 nfs-utils 或 nfs-common 已安装，且节点能访问 ONTAP 数据 LIF。
网络连通性：从节点测试管理 LIF 的 443 端口和数据 LIF 的 2049（NFS）或 3260（iSCSI）端口是否可达。
ONTAP 侧准备：SVM 已创建，管理账号具备 ontapi 访问权限，聚合有足够空间，且已配置 NFS 或 iSCSI 服务。
镜像与权限：若集群无法拉取公网镜像，需提前将 Trident 镜像同步到私有仓库；同时确认部署账号具备创建 CRD、ClusterRole 和命名空间的权限。

版本兼容性建议以 NetApp Interoperability Matrix（IMT）为准。Trident 版本、ONTAP 版本、Kubernetes 版本三者之间存在明确的兼容矩阵，例如 Trident 24.06 支持 ONTAP 9.8 及以上，搭配 Kubernetes 1.26～1.30。部署前先在 IMT 中确认组合，可避免大量返工。

完成上述检查后，可以用 tridentctl install -n trident 或 Helm Chart 安装 Trident。安装完成后，依次验证：Pod 是否 Running、CRD 是否注册、后端是否 Success、StorageClass 是否能动态供应 PVC。只有这四步都通过，才说明 Trident 已具备为有状态应用提供持久化存储的能力。