📚 课程目录第3章 Pure Storage产品与容器存储能力概览

3. Pure Storage产品与容器存储能力概览

在把 Pure Storage 接入 Kubernetes 之前，必须先弄清楚一件事：Pure 并不是“一个存储产品”，而是一组面向不同数据形态的产品与插件组合。容器场景里最常见的困惑是——为什么有的 PVC 能在线扩容、有的能多 Pod 共享读写、有的却只能被单个节点挂载？答案往往不在 Kubernetes 侧，而在于后端到底是 FlashArray 还是 FlashBlade，以及 CSI 驱动把它暴露成了块设备还是文件系统。本节就把 FlashArray、FlashBlade、Pure1 与 Pure CSI 插件家族放在同一张能力地图上，讲清它们各自负责什么、对块存储和文件存储的支持差异在哪里。

四个组件，四种职责

FlashArray 是 Pure 的块存储阵列，对外提供 iSCSI、Fibre Channel、NVMe-oF 等块级协议。它的数据单元是卷（Volume），在 Kubernetes 中通常对应一个 ReadWriteOnce 的 PVC，被挂载为 ext4/xfs 文件系统或裸块设备。FlashArray 的强项是低延迟、快照与克隆效率高，适合数据库、有状态中间件这类单写多读、对 IOPS 敏感的工作负载。它原生支持 ActiveCluster 双活、SafeMode 快照保护，卷可以在线扩容，这些能力会通过 CSI 驱动透传给 PVC。

FlashBlade 是 Pure 的横向扩展文件与对象存储平台，对外提供 NFS、SMB、S3 协议。它的数据单元是文件系统（File System）和对象桶（Bucket）。在 Kubernetes 中，FlashBlade 通过 NFS 支撑 ReadWriteMany 的 PVC，让多个 Pod 同时读写同一份数据，典型场景是 AI 训练数据集、渲染农场、日志共享、CI 缓存。FlashBlade 的架构是刀片式全闪，容量和性能随刀片线性扩展，这与 FlashArray 的双控制器纵向扩展模型有本质区别。

Pure1 是云端管理与智能运维平台，不直接承载容器数据路径。它做的是全局遥测、容量与性能分析、AI 驱动的预测（如 Pure1 Meta）、以及跨阵列的资产视图。在容器集成中，Pure1 的价值体现在：通过它统一观察多个 FlashArray/FlashBlade 的健康与容量趋势，提前发现某个后端快照空间或 NFS 导出压力异常，从而避免 PVC 供给失败。它不参与 CSI 的挂载流程，但参与“运维闭环”。

Pure CSI 插件家族是真正把上述存储能力翻译成 Kubernetes API 的桥梁。它主要包含两个驱动：pure-csi（面向 FlashArray 的块存储驱动，也常被称为 Pure FlashArray CSI）和 pure-file-csi（面向 FlashBlade 的文件存储驱动）。两者都实现了 CSI 规范中的 Identity、Controller、Node 三组服务，但支持的参数与能力集不同。理解它们的差异，比记住插件名字更重要。

块与文件：差异到底体现在哪

把上面的地图落到具体参数上，差异会变得非常清晰。使用 pure-csi 时，StorageClass 的 provisioner 是 pure-csi，后端指向 FlashArray 的管理地址与 API Token，创建的卷是块设备，Kubernetes 只能把它挂到单个节点上，因此访问模式是 RWO 或 Raw Block。它支持 allowVolumeExpansion: true，扩容时 FlashArray 先扩卷，节点侧再扩文件系统。快照通过 VolumeSnapshotClass 触发，底层是 FlashArray 的瞬时快照，恢复时用克隆，速度与容量无关。

使用 pure-file-csi 时，后端指向 FlashBlade 的数据 VIP，创建的其实是 NFS 导出目录，多个节点可以同时挂载，因此支持 RWX 和 ROX。它同样支持扩容，但扩容的是文件系统配额而非块设备。快照能力依赖 FlashBlade 的文件系统快照，恢复时通常以新目录形式呈现。需要注意的是，FlashBlade 的 S3 对象存储并不通过这个 CSI 驱动暴露为 PVC，容器里访问 S3 一般走应用层 SDK 或 ObjectBucketClaim 类方案，这是很多人容易混淆的一点。

选型速记：需要单写、低延迟、在线扩容和块级快照，选 FlashArray + pure-csi；需要多 Pod 共享读写、高吞吐、目录级配额，选 FlashBlade + pure-file-csi。两者可以在同一集群共存，由不同 StorageClass 区分。

一个可对照的 StorageClass 示例

下面给出两个 StorageClass 的示例片段，参数为教学示例，实际地址与 Token 需替换为环境中的真实值。注意 backend 字段的取值差异，它直接决定了请求被路由到哪类后端。

# FlashArray 块存储（RWO）
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pure-block
provisioner: pure-csi
parameters:
  backend: flasharray
  array: FA-Prod-01          # FlashArray 管理地址标识
  protocol: iscsi            # 可选 fc / nvme
allowVolumeExpansion: true
reclaimPolicy: Delete
---
# FlashBlade 文件存储（RWX）
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pure-file
provisioner: pure-file-csi
parameters:
  backend: flashblade
  array: FB-AI-01            # FlashBlade 数据 VIP 标识
  nfsExport: /k8s            # NFS 导出根路径
allowVolumeExpansion: true
reclaimPolicy: Delete

创建 PVC 时只需引用对应 StorageClass，访问模式必须与驱动能力匹配。例如给 pure-block 申请 RWX 会一直处于 Pending，因为 FlashArray 块卷无法被多节点同时挂载；反过来给 pure-file 申请 Raw Block 也会失败，因为 NFS 不提供裸块语义。这类“卡在 Pending”的问题，八成是访问模式与后端类型不匹配，而不是插件没装好。

Pure1 在容器运维中的位置

Pure1 不参与 CSI 的 CreateVolume、NodeStage 等调用，所以它不会出现在 PVC 的挂载链路上。它的作用是让你在集群之外看到后端全貌：某个 FlashArray 的卷数量增长过快、快照空间接近阈值、某台 FlashBlade 的 NFS 吞吐持续偏高，这些趋势都可以在 Pure1 中提前发现。当 Kubernetes 侧出现批量 PVC 供给缓慢时，先看 Pure1 的后端健康与容量，往往比直接翻 CSI 日志更快定位方向。把 Pure1 当作“后端可观测性入口”，而不是存储网关，理解上就不会跑偏。

总结来看，FlashArray 与 FlashBlade 分别对应块与文件两条数据路径，pure-csi 与 pure-file-csi 是这两条路径在 Kubernetes 中的翻译层，Pure1 则是横跨两者的运维视图。四者各司其职，容器持久化的选型与排障，本质上就是判断当前请求落在哪条路径上、该路径的能力边界在哪里。