在ACK集群中使用CPFS智算版静态存储卷 - 容器服务 Kubernetes 版 ACK

CPFS智算版具有高吞吐量和IOPS性能，支持端到端RDMA网络加速，适用于AIGC、自动驾驶等智算场景。ACK支持将CPFS智算版文件系统以静态存储卷（PV）的形式挂载给工作负载使用。

重要

CPFS智算版目前处于邀测中，仅部分地域和可用区支持。如需使用，请联系客户经理申请。

功能介绍

基于CSI组件，ACK支持以PV/PVC的方式为工作负载挂载CPFS智算版静态存储卷。CSI会根据Pod最终调度的节点类型，自动选择最优的挂载方式：

VSC挂载：仅支持灵骏节点，需分别向 CPFS产品和灵骏产品咨询提交工单开通白名单。
VPC挂载：支持非灵骏节点，通过创建VPC挂载点实现。同一VPC下的节点均可挂载访问。

前提条件

已了解CPFS智算版的CPFS智算版使用限制。
集群满足以下条件：
- 集群版本：1.26及以上版本。如需升级集群，请参见手动升级集群。
- 节点操作系统：Alibaba Cloud Linux 3。
- 已安装以下存储组件，且版本满足要求。
  可在集群的组件管理页面，确认组件版本、安装或升级组件。
  - CSI组件（csi-plugin和csi-provisioner）：v1.33.1及以上版本。如需升级，请参见管理CSI组件。
  - cnfs-nas-daemon组件：0.1.2及以上版本。
    展开查看cnfs-nas-daemon介绍
    cnfs-nas-daemon负责管理EFC进程，其资源消耗较高，并直接影响存储性能。可在组件管理页面调整其资源配置，推荐的调整策略如下：
    CPU：CPU请求量与节点总带宽相关。计算规则为：每1Gb/s带宽需分配0.5 Core，并额外增加1 Core用于元数据管理。请根据此规则调整CPU配置。
    例如，对于一个配置了100Gb/s网卡的节点，推荐的CPU请求量为 100 * 0.5 + 1 = 51 Cores。
    Memory：CPFS智算版通过FUSE访问，其数据读写缓存及文件元数据均占用内存。推荐将内存请求量设置为节点总内存的15%。
    配置调整后，可根据实际负载情况进行动态扩缩。
    重要
    更新生效方式：cnfs-nas-daemon DaemonSet默认更新策略为OnDelete。在组件管理页面调整其CPU或Memory后，需手动删除节点上原有的cnfs-nas-daemon Pod，以触发重建使新配置生效。
    为确保业务稳定性，建议在业务低峰期执行此操作。
    操作风险：删除或重启 cnfs-nas-daemon Pod 会临时中断该节点上的CPFS挂载服务。
    不支持挂载点热升级的节点^①：此操作为硬中断，将导致应用Pod运行异常。需手动删除应用Pod，等待应用Pod重启后恢复。
    支持热升级的节点^①：应用Pod可在cnfs-nas-daemon Pod重启后自动恢复。
    ①：符合以下条件的节点支持热升级：
    节点系统内核为5.10.134-18及以上
    bmcpfs-csi-controller和bmcpfs-csi-plugin版本为 1.35.1 及以上
    cnfs-nas-daemon版本为0.1.9-compatible.1及以上
  - bmcpfs-csi组件：包括bmcpfs-csi-controller（控制面组件，由ACK托管）和bmcpfs-csi-node（节点侧组件，以DaemonSet形式部署在集群中）。

注意事项

使用VSC挂载时，运行 Pod 的节点必须与 CPFS 智算版文件系统实例处于同一 hpn-zone。
灵骏节点在初始化的时候必须与某一个 CPFS 智算版关联，否则无法使用 CSI 进行挂载。
灵骏节点出现故障需要下线前，必须先执行Pod排水（drain）操作。否则，将导致集群元信息不一致，造成Pod资源残留且无法被正常回收。
不支持在同一个Pod中通过多个PV挂载源于同一个CPFS实例的不同子目录。由于底层驱动的限制，此类配置会导致Pod挂载失败而无法启动。
推荐仅为该CPFS实例创建一个PV/PVC，然后在Pod的volumeMounts配置中使用subPath字段来分别挂载所需的子目录。
subPath 基于轻量级的bind mount 机制实现，不会带来额外性能开销。

步骤一：创建CPFS文件系统

参见创建CPFS智算版文件系统创建CPFS文件系统，并记录文件系统ID。
（可选）如需在非灵骏节点实现挂载，请创建VPC挂载点（与集群节点所在的VPC一致），并记录挂载点域名。格式为cpfs-***-vpc-***.<Region>.cpfs.aliyuncs.com。
如果Pod将调度到灵骏节点，则默认使用VSC挂载，无需此步骤。

步骤二：创建PV和PVC

基于已有的CPFS文件系统，创建对应的PV和PVC。

修改以下YAML示例，保存为bmcpfs-pv-pvc.yaml。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: bmcpfs
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 10Ti
  claimRef:
    name: bmcpfs
    namespace: default
  csi:
    driver: bmcpfsplugin.csi.alibabacloud.com
    volumeAttributes:
       # 如果Pod调度至非灵骏节点，或者开启了跨域自动切换vpc能力，此项为必填，否则挂载会失败
      vpcMountTarget: cpfs-***-vpc-***.<Region>.cpfs.aliyuncs.com
      # 如果Pod调度到与当前 bmcpfs 所在的不同可用区的节点， 则自动使用 vpcMountTarget 挂载点访问 cpfs 存储
      mountpointAutoSwitch: "true"
    # 将volumeHandle替换为CPFS智算版文件系统ID
    volumeHandle: bmcpfs-*****
  mountOptions: []

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: bmcpfs
  namespace: default
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 10Ti
  volumeMode: Filesystem
  volumeName: bmcpfs

PV参数

参数	说明
`accessModes`	PV的访问模式。
`capacity.storage`	声明存储卷容量。仅作声明，不影响实际容量。
`csi.driver`	驱动类型。挂载CPFS智算版时，固定为`bmcpfsplugin.csi.alibabacloud.com`。
`csi.volumeAttributes.vpcMountTarget`	CPFS的VPC挂载点域名。置空会导致在非灵骏节点上挂载失败。如果Pod调度至灵骏节点，则无需设置。
`csi.volumeAttributes.mountpointAutoSwitch`	是否允许 bmcpfs 在 vsc 挂载点（默认创建&获取）和 vpc 挂载点（需指定）之间自动切换与 `csi.volumeAttributes.vpcMountTarget` 绑定使用
`csi.volumeHandle`	CPFS文件系统的ID。
`mountOptions`	挂载参数。

PVC参数

参数	说明
`accessModes`	PVC请求PV的访问模式，需与PV匹配。
`resources.requests.storage`	分配给Pod的存储容量。不大于PV容量。
`volumeMode`	挂载模式，需设置为`Filesystem`。
`volumeName`	PVC要绑定的PV名称。

创建PV和PVC。
```
kubectl apply -f bmcpfs-pv-pvc.yaml
```

确认PVC已绑定PV。

kubectl get pvc bmcpfs

预期输出：

NAME     STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
bmcpfs   Bound    bmcpfs   10Ti       RWX                           <unset>                 51s

STATUS为Bound，PV和PVC绑定成功。

步骤三：创建应用并挂载CPFS

场景一：挂载整个CPFS文件系统

此场景将整个CPFS文件系统挂载到容器中。

使用以下YAML内容，创建cpfs-test.yaml文件，声明挂载CPFS智算版静态存储卷。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cpfs-test
  labels:
    app: cpfs-test
spec:
  replicas: 2
  selector:
    matchLabels:
      app: cpfs-test
  template:
    metadata:
      labels:
        app: cpfs-test
    spec:
      containers:
      - name: nginx
        image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        ports:
        - containerPort: 80
        volumeMounts:
          - name: pvc-cpfs
            mountPath: /data
      volumes:
        - name: pvc-cpfs
          persistentVolumeClaim:
            claimName: bmcpfs

创建Deployment。
```
kubectl create -f cpfs-test.yaml
```

查看Pod部署情况。

kubectl get pod -l app=cpfs-test

预期输出：

NAME                         READY   STATUS    RESTARTS   AGE
cpfs-test-76b77d64b5-2hw96   1/1     Running   0          42s
cpfs-test-76b77d64b5-dnwdx   1/1     Running   0          42s

进入任一Pod，验证CPFS智算版静态存储卷是否挂载成功。

kubectl exec -it <pod-name> -- mount | grep /data

预期输出如下，表明CPFS智算版静态存储卷挂载成功。

bindroot-f0a5c-******:cpfs-*******-vpc-****.cn-shanghai.cpfs.aliyuncs.com:/ on /data type fuse.aliyun-alinas-efc (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=1048576)

场景二：挂载整个CPFS文件系统的子目录

在共享存储场景中，如需实现多租户或多任务的数据隔离，让多个应用Pod 共享同一个 CPFS 卷，但又各自拥有独立目录时，可通过 volumeMounts.subPath 来实现。

参见以下内容，创建 pod.yaml。Pod包含两个容器，分别通过subPath挂载同一个PVC (bmcpfs) 的不同子目录。

当Pod挂载时，如果subPath指定的子目录（例如workspace/alpha）在CPFS文件系统中不存在，系统将自动创建。

apiVersion: v1
kind: Pod
metadata:
  name: cpfs-subpath-demo-pod
spec:
  containers:
    - name: task-alpha-container
      image: busybox:1.35
      command: ["/bin/sh", "-c", "sleep 3600"]
      volumeMounts:
        - name: cpfs-storage
          mountPath: /data/workspace # 容器内的挂载路径
          subPath: workspace/alpha   # 指定挂载卷内的 workspace/alpha 子目录，而非整个卷

    - name: task-beta-container
      image: busybox:1.35
      command: ["/bin/sh", "-c", "sleep 3600"]
      volumeMounts:
        - name: cpfs-storage
          mountPath: /data/workspace # 容器内的挂载路径可以相同
          subPath: workspace/beta    # 指定挂载卷内的 workspace/beta 子目录，而非整个卷
  volumes:
    - name: cpfs-storage
      persistentVolumeClaim:
        claimName: bmcpfs # 引用此前创建的PVC

部署Pod。
```
kubectl apply -f pod.yaml
```
验证 task-alpha 容器的挂载和写入。
1. 连接到task-alpha容器。
```
kubectl exec -it cpfs-subpath-demo-pod -c task-alpha-container -- /bin/sh
```
2. 查看已挂载的文件系统，确认 CPFS 存储卷是否存在。
```
df -h
```
  预期输出如下，表明共享目录（/share）已被成功挂载到容器内的 /data/workspace 路径下。
```
Filesystem                Size      Used Available Use% Mounted on
...
192.XX.XX.0:/share          10.0T     1.0G     10.0T   0% /data/workspace
...
```
3. 检查挂载点的父目录结构。
```
ls -l /data/
```
  预期输出如下，表明/data 目录下存在名为 workspace 的子目录。
```
total 4
drwxr-xr-x    2 root     root          4096 Aug 15 10:00 workspace
```
4. 在挂载目录中创建文件以验证写入权限。
```
echo "hello from alpha" > /data/workspace/alpha.log
exit
```
验证 task-beta 容器的挂载和数据隔离。
1. 连接到task-beta容器。
```
kubectl exec -it cpfs-subpath-demo-pod -c task-beta-container -- /bin/sh
```
2. 在容器的挂载点 /data/workspace 中创建文件。
```
echo "hello from beta" > /data/workspace/beta.log
```
3. 检查/data/workspace/目录下的文件。
```
ls -l /data/workspace/
```
  预期输出如下，表明beta.log写入成功，且不存在alpha.log，两个容器间的数据相互隔离。
```
total 4
-rw-r--r--    1 root     root            16 Aug 15 10:05 beta.log
```