Gunakan Volume Provision Statis CPFS for Lingjun di Kluster ACK - Container Service for Kubernetes

Cloud Parallel File System (CPFS) for Lingjun menyediakan throughput dan IOPS tinggi dengan akselerasi jaringan Remote Direct Memory Access (RDMA) end-to-end, menjadikannya ideal untuk skenario AI dan komputasi-intensif seperti AI-Generated Content (AIGC) serta kendaraan otonom. ACK mendukung pemasangan sistem file CPFS for Lingjun sebagai persistent volume (PV) yang diprovision secara statis.

Penting

CPFS for Lingjun berada dalam pratinjau undangan dan hanya tersedia di wilayah dan zona tertentu. Hubungi manajer akun Anda untuk meminta akses.

Pilih metode pemasangan

Berdasarkan Container Storage Interface (CSI), ACK mendukung pemasangan sistem file CPFS for Lingjun sebagai PV dan persistent volume claim (PVC) yang diprovision secara statis. Add-on CSI secara otomatis memilih metode pemasangan optimal berdasarkan tipe node pod:

Metode pemasangan	Node yang didukung	Persyaratan
Virtual storage channel (VSC)	Hanya node Lingjun	Anda harus mengajukan Tiket kepada tim produk CPFS dan Lingjun untuk memperoleh akses allowlist.
VPC	Node non-Lingjun	Buat titik pemasangan VPC di VPC yang sama dengan node kluster.

Sebelum memulai, identifikasi jalur yang berlaku untuk kluster Anda:

Pod berjalan di node Lingjun—pemasangan VSC secara default. Lewati pembuatan titik pemasangan VPC.
Pod berjalan di node non-Lingjun—diperlukan pemasangan VPC. Buat titik pemasangan VPC pada Langkah 1.
Pod berjalan di kedua tipe node—atur kedua parameter vpcMountTarget dan mountpointAutoSwitch: "true" di PV. Add-on CSI akan beralih secara otomatis.

Prasyarat

Sebelum memulai, pastikan Anda telah:

Meninjau batasan untuk CPFS for Lingjun
Menggunakan kluster ACK yang menjalankan Kubernetes 1.26 atau lebih baru. Upgrade jika diperlukan.
Node yang menjalankan Alibaba Cloud Linux 3
Add-on penyimpanan berikut pada versi yang disyaratkan (verifikasi dan upgrade di halaman Add-ons):
- Add-on CSI (csi-plugin dan csi-provisioner): v1.33.1 atau lebih baru (manage CSI add-ons).
- cnfs-nas-daemon: 0.1.2 atau lebih baru
  Konfigurasikan sumber daya cnfs-nas-daemon
  Add-on cnfs-nas-daemon mengelola proses Elastic File Client (EFC), mengonsumsi sumber daya signifikan, dan berdampak langsung pada performa penyimpanan. Sesuaikan sumber daya di halaman Add-ons:
  - CPU: Bergantung pada total bandwidth node. Direkomendasikan: 0,5 core per 1 Gbps bandwidth, ditambah 1 core tambahan untuk manajemen metadata.
    
    Contoh: Untuk node 100 Gbps, request CPU adalah 100 × 0,5 + 1 = 51 core.
  - Memori: CPFS for Lingjun menggunakan Filesystem in USErspace (FUSE), sehingga cache baca/tulis dan metadata mengonsumsi memori. Atur request menjadi 15% dari total memori node.
  Sesuaikan sesuai kebutuhan workload Anda.
  Penting
  
  Perilaku pembaruan: cnfs-nas-daemon menggunakan strategi pembaruan OnDelete secara default. Setelah menyesuaikan CPU atau memori di halaman Add-ons, hapus secara manual pod cnfs-nas-daemon di setiap node agar dibuat ulang dengan konfigurasi baru. Lakukan selama jam sepi.
  
  Risiko gangguan: Menghapus atau me-restart pod cnfs-nas-daemon sementara mengganggu layanan pemasangan CPFS di node tersebut.
  
  Untuk node tanpa dukungan hot-upgrade^①: Gangguan keras yang menyebabkan pod aplikasi gagal. Hapus dan restart pod aplikasi secara manual untuk memulihkan layanan.
  
  Untuk node dengan dukungan hot-upgrade^①: Pod aplikasi pulih secara otomatis setelah cnfs-nas-daemon direstart.
  
  ①: Sebuah node mendukung hot upgrade jika memenuhi semua kondisi berikut:
  
  Versi kernel node adalah 5.10.134-18 atau lebih baru.
  
  bmcpfs-csi-controller dan bmcpfs-csi-plugin versi 1.35.1 atau lebih baru.
  
  cnfs-nas-daemon versi 0.1.9-compatible.1 atau lebih baru.
- bmcpfs-csi: mencakup bmcpfs-csi-controller (add-on control-plane yang dikelola oleh ACK) dan bmcpfs-csi-node (DaemonSet sisi node)

Catatan penggunaan

Zona pemasangan VSC: Node tempat pod berjalan harus berada di hpn-zone yang sama dengan instans sistem file CPFS for Lingjun.
Inisialisasi node: Node Lingjun harus dikaitkan dengan sistem file CPFS for Lingjun selama inisialisasi. Jika tidak, pemasangan CSI gagal.
Drain node: Sebelum mendekomisioning node Lingjun yang rusak, drain semua pod darinya. Melewatkan langkah ini menyebabkan ketidakkonsistenan metadata kluster dan sumber daya pod terlantar yang tidak dapat dibersihkan.
Satu PV per instans CPFS: Pemasangan beberapa subdirektori dari sistem file CPFS yang sama sebagai PV terpisah ke satu pod tidak didukung. Karena keterbatasan driver, hal ini menyebabkan kegagalan startup pod. Buat satu PV/PVC dan gunakan volumeMounts.subPath untuk memasang subdirektori. subPath menggunakan bind mount ringan tanpa overhead performa.

Langkah 1: Buat sistem file CPFS

Buat sistem file CPFS for Lingjun dan catat ID sistem file.
(Opsional) Untuk node non-Lingjun, buat titik pemasangan VPC di VPC yang sama dengan node kluster Anda dan catat nama domain titik pemasangan. Format: cpfs-*-vpc-*.<Region>.cpfs.aliyuncs.com.

Tidak diperlukan jika pod berjalan di node Lingjun (pemasangan VSC secara default).

Langkah 2: Buat PV dan PVC

Simpan templat berikut sebagai bmcpfs-pv-pvc.yaml, ganti placeholder dengan ID sistem file Anda dan (jika diperlukan) titik pemasangan VPC.

Parameter PV

Parameter	Deskripsi	Wajib
`accessModes`	Mode akses untuk PV.	Ya
`capacity.storage`	Kapasitas penyimpanan yang dideklarasikan. Tidak memengaruhi kapasitas aktual.	Ya
`csi.driver`	Tipe driver. Untuk CPFS for Lingjun, gunakan `bmcpfsplugin.csi.alibabacloud.com`.	Ya
`csi.volumeHandle`	ID sistem file CPFS for Lingjun.	Ya
`csi.volumeAttributes.vpcMountTarget`	Nama domain titik pemasangan VPC. Diperlukan untuk node non-Lingjun; abaikan jika pod hanya dijadwalkan ke node Lingjun.	Bersyarat
`csi.volumeAttributes.mountpointAutoSwitch`	Mengaktifkan peralihan otomatis antara titik pemasangan VSC dan VPC. Gunakan bersama `vpcMountTarget`.	Tidak
`mountOptions`	Opsi pemasangan.	Tidak

Parameter PVC

Parameter	Deskripsi	Wajib
`accessModes`	Mode akses yang diminta oleh PVC. Harus sesuai dengan PV.	Ya
`resources.requests.storage`	Kapasitas penyimpanan yang dialokasikan ke pod. Tidak boleh melebihi kapasitas PV.	Ya
`volumeMode`	Mode pemasangan. Atur ke `Filesystem`.	Ya
`volumeName`	Nama PV yang akan di-bind ke PVC ini.	Ya

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:
      # Diperlukan jika pod dijadwalkan ke node non-Lingjun atau peralihan otomatis cross-zone VPC diaktifkan.
      # Abaikan jika pod hanya dijadwalkan ke node Lingjun.
      vpcMountTarget: cpfs-***-vpc-***.<Region>.cpfs.aliyuncs.com
      # Mengaktifkan peralihan otomatis antara titik pemasangan VSC dan VPC.
      # Gunakan bersama vpcMountTarget.
      mountpointAutoSwitch: "true"
    # Ganti dengan ID sistem file CPFS for Lingjun Anda.
    volumeHandle: bmcpfs-*****
  mountOptions: []

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

Terapkan konfigurasi.
```
kubectl apply -f bmcpfs-pv-pvc.yaml
```

Konfirmasi bahwa PVC terikat ke PV.

kubectl get pvc bmcpfs

Output yang diharapkan:

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

STATUS bernilai Bound, yang mengonfirmasi PVC terikat ke PV.

Langkah 3: Deploy workload

Skenario 1: Pasang seluruh sistem file CPFS

Gunakan pendekatan ini ketika semua kontainer memerlukan akses penuh ke sistem file CPFS.

Simpan templat YAML berikut sebagai cpfs-test.yaml.

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

Buat Deployment.
```
kubectl create -f cpfs-test.yaml
```

Verifikasi kedua pod sedang berjalan.

kubectl get pod -l app=cpfs-test

Output yang diharapkan:

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

Verifikasi pemasangan volume CPFS di dalam pod.

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

Output yang diharapkan:

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)

Tipe pemasangan fuse.aliyun-alinas-efc di /data mengonfirmasi volume CPFS telah dipasang.

Skenario 2: Pasang subdirektori untuk isolasi data

Dalam skenario penyimpanan bersama seperti pengaturan multi-penyewa atau multitasking, beberapa kontainer dapat berbagi satu volume CPFS sekaligus mengisolasi data di direktori terpisah. Gunakan volumeMounts.subPath untuk memasang subdirektori berbeda ke kontainer berbeda dari PVC yang sama.

Jika direktori subPath (misalnya, workspace/alpha) belum ada, direktori tersebut akan dibuat secara otomatis.

Simpan templat YAML berikut sebagai pod.yaml. Pod ini menjalankan dua kontainer, masing-masing memasang subdirektori berbeda dari PVC yang sama (bmcpfs).

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        # Jalur pemasangan di dalam kontainer
          subPath: workspace/alpha          # Hanya pasang subdirektori workspace/alpha

    - name: task-beta-container
      image: busybox:1.35
      command: ["/bin/sh", "-c", "sleep 3600"]
      volumeMounts:
        - name: cpfs-storage
          mountPath: /data/workspace        # Jalur pemasangan bisa identik di berbagai kontainer
          subPath: workspace/beta           # Hanya pasang subdirektori workspace/beta
  volumes:
    - name: cpfs-storage
      persistentVolumeClaim:
        claimName: bmcpfs                  # Referensi ke PVC yang dibuat sebelumnya

Deploy pod.
```
kubectl apply -f pod.yaml
```

Verifikasi pemasangan dan izin tulis untuk task-alpha-container.

Konek ke kontainer.

kubectl exec -it cpfs-subpath-demo-pod -c task-alpha-container -- /bin/sh

Konfirmasi volume CPFS telah dipasang.
```
df -h
```
Output yang diharapkan (direktori bersama dipasang di /data/workspace):
```
Filesystem                Size      Used Available Use% Mounted on
...
192.XX.XX.0:/share          10.0T     1.0G     10.0T   0% /data/workspace
...
```
Entri filesystem di /data/workspace mengonfirmasi subdirektori CPFS telah dipasang.

Periksa struktur direktori induk.

ls -l /data/

Output yang diharapkan:

total 4
drwxr-xr-x    2 root     root          4096 Aug 15 10:00 workspace

Tulis file uji dan keluar.

echo "hello from alpha" > /data/workspace/alpha.log
exit

Verifikasi pemasangan task-beta-container dan isolasi data.
1. Konek ke kontainer.
```
kubectl exec -it cpfs-subpath-demo-pod -c task-beta-container -- /bin/sh
```
2. Tulis file uji.
```
echo "hello from beta" > /data/workspace/beta.log
```
3. Daftar file di titik pemasangan.
```
ls -l /data/workspace/
```
  Output yang diharapkan:
```
total 4
-rw-r--r--    1 root     root            16 Aug 15 10:05 beta.log
```
  beta.log ada tetapi alpha.log tidak ada, yang mengonfirmasi isolasi data antar kontainer.