Gunakan CPFS yang Disiapkan Secara Statis untuk Volume LINGJUN dalam Kluster ACK - Container Service for Kubernetes

Cloud Parallel File Storage (CPFS) untuk Lingjun menyediakan throughput tinggi dan operasi input/output per detik (IOPS) dengan dukungan akselerasi jaringan Remote Direct Memory Access (RDMA) dari ujung ke ujung. Fitur ini menjadikannya ideal untuk skenario komputasi cerdas seperti konten yang dihasilkan oleh artificial intelligence (AIGC) dan mengemudi otonom. Anda dapat memasang sistem file CPFS untuk Lingjun ke beban kerja di Alibaba Cloud Container Service for Kubernetes (ACK) sebagai volume persisten (PV) yang disiapkan secara statis.

Penting

CPFS untuk Lingjun saat ini dalam pratinjau undangan dan hanya tersedia di wilayah serta zona tertentu. Untuk menggunakan fitur ini, hubungi manajer akun Anda.

Cara kerjanya

Berdasarkan komponen Container Storage Interface (CSI), ACK memungkinkan beban kerja untuk memasang volume CPFS untuk Lingjun yang disiapkan secara statis menggunakan Persistent Volume (PV) dan Persistent Volume Claims (PVC). Komponen CSI secara otomatis memilih metode pemasangan optimal berdasarkan jenis node tempat pod dijadwalkan:

Pemasangan Virtual Storage Channel (VSC): Digunakan secara eksklusif untuk node Lingjun. Metode ini memerlukan akses daftar izin untuk layanan CPFS untuk Lingjun dan Lingjun. Untuk menggunakan metode ini, ajukan tiket.
Pemasangan Virtual Private Cloud (VPC): Digunakan untuk semua jenis node lainnya. Metode ini memerlukan titik pemasangan VPC untuk dibuat pada sistem file, sehingga memungkinkan setiap node dalam VPC yang sama untuk memasang dan mengaksesnya.

Prasyarat

Anda sudah familiar dengan batasan CPFS untuk Lingjun.
Kluster Anda menjalankan versi Kubernetes 1.26 atau lebih baru. Tingkatkan kluster jika diperlukan.
Komponen penyimpanan berikut terpasang di kluster dan memenuhi persyaratan versi minimum:
Di halaman Add-ons kluster, Anda dapat memastikan versi komponen, serta menginstal atau memperbarui komponen.
- Komponen CSI (csi-plugin dan csi-provisioner): Versi csi-plugin adalah 1.33.1 atau lebih baru. Perbarui csi-plugin jika diperlukan.
- cnfs-nas-daemon: Versinya adalah 0.1.2 atau lebih baru.
  Catatan
  - Komponen cnfs-nas-daemon mengelola proses Elastic Fabric Controller (EFC) dan bisa sangat intensif sumber daya. Konsumsi sumber dayanya langsung berkaitan dengan performa penyimpanan yang diharapkan. Sesuaikan alokasi sumber daya untuk komponen ini di halaman Add-ons berdasarkan panduan berikut dan performa serta konsumsi memori aktual beban kerja Anda:
    CPU: Persyaratan CPU untuk pod cnfs-nas-daemon ditentukan oleh total bandwidth jaringan node. Setiap 1 Gbps bandwidth membutuhkan 0,5 core CPU, dan pengelolaan metadata membutuhkan 1 core CPU. Konfigurasikan permintaan dan batas CPU sesuai rumus ini.
    Memori: CPFS untuk Lingjun diakses melalui Filesystem in Userspace (FUSE), yang menggunakan memori sistem untuk caching data dan metadata file. Kami merekomendasikan mengalokasikan sekitar 15% dari total memori node untuk pod cnfs-nas-daemon.
  - DaemonSet cnfs-nas-daemon memiliki strategi pembaruan default yaitu OnDelete. Untuk menerapkan perubahan apa pun pada konfigurasi CPU atau memorinya, Anda harus secara manual menghapus pod cnfs-nas-daemon yang ada di setiap node. Kubernetes kemudian akan secara otomatis membuat ulang mereka dengan pengaturan sumber daya baru.
- bmcpfs-csi: Ini mencakup bmcpfs-csi-controller (komponen lapisan kontrol yang dikelola oleh ACK) dan bmcpfs-csi-node (komponen sisi node yang diterapkan sebagai DaemonSet di kluster).

Pertimbangan penting

Saat menggunakan pemasangan VSC, pod harus dijadwalkan ke node Lingjun yang berada di zona hpn-zone yang sama dengan sistem file CPFS untuk Lingjun.
Node Lingjun harus dikaitkan dengan sistem file CPFS untuk Lingjun selama inisialisasi. Jika tidak, Anda tidak dapat menggunakan komponen CSI untuk memasang sistem file tersebut.
Sebelum menonaktifkan node Lingjun karena kegagalan, Anda harus terlebih dahulu mengosongkan node dari pod-nya. Kegagalan melakukan ini akan mengakibatkan ketidaksesuaian dalam metadata kluster, meninggalkan sumber daya pod yang tidak dapat dikumpulkan sampah dengan benar.
Jangan pasang beberapa subdirektori dari sistem file CPFS yang sama sebagai PV terpisah dalam satu pod. Karena keterbatasan driver dasar, ini akan menyebabkan pod gagal dipasang dan dimulai. Sebagai gantinya, buat hanya satu PV dan PVC untuk memasang seluruh volume CPFS sekali. Kemudian, dalam konfigurasi volumeMounts pod, gunakan bidang subPath untuk memasang subdirektori yang diperlukan secara terpisah.
Fitur subPath diimplementasikan berdasarkan mekanisme bind mount ringan dan tidak menyebabkan overhead kinerja tambahan.

Langkah 1: Buat sistem file CPFS

Ikuti petunjuk di Buat Sistem File CPFS untuk Lingjun untuk membuat sistem file. Catat ID sistem file.
(Opsional) Untuk memasang sistem file pada node non-Lingjun, buat titik pemasangan VPC di VPC yang sama dengan node kluster Anda. Catat domain titik pemasangan. Format domain adalah cpfs-***-vpc-***.<Region>.cpfs.aliyuncs.com.
Lewati langkah ini jika pod dijadwalkan ke node Lingjun. Metode pemasangan VSC digunakan secara default.

Langkah 2: Buat PV dan PVC

Buat file bernama bmcpfs-pv-pvc.yaml dengan konten berikut.

Ganti nilai volumeHandle dengan ID sistem file Anda.
Jika menggunakan titik pemasangan VPC, ganti nilai vpcMountTarget dengan domain titik pemasangan Anda. Hilangkan bidang ini jika Anda hanya menggunakan node Lingjun.

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:
       # Bidang ini diperlukan jika pod dijadwalkan ke node non-Lingjun. Hilangkan untuk kluster hanya Lingjun.
      vpcMountTarget: cpfs-***-vpc-***.<Region>.cpfs.aliyuncs.com
    # Ganti volumeHandle dengan ID sistem file Anda.
    volumeHandle: bmcpfs-*****
  mountOptions: []

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

Parameter PV

Parameter	Deskripsi
`accessModes`	Mode akses PV.
`capacity.storage`	Kapasitas yang dinyatakan dari volume. Ini hanya deklarasi dan tidak memengaruhi kapasitas aktual.
`csi.driver`	Tipe driver. Saat Anda memasang sistem file CPFS untuk Lingjun, atur ini ke `bmcpfsplugin.csi.alibabacloud.com`.
`csi.volumeAttributes.vpcMountTarget`	Nama domain titik pemasangan VPC untuk sistem file CPFS. Jika dibiarkan kosong, pemasangan gagal pada node non-Lingjun. Hilangkan parameter ini jika pod dijadwalkan ke node Lingjun.
`csi.volumeHandle`	ID sistem file CPFS.
`mountOptions`	Parameter pemasangan.

Parameter PVC

Parameter	Deskripsi
`accessModes`	Mode akses yang diminta oleh PVC untuk PV. Ini harus cocok dengan mode akses PV.
`resources.requests.storage`	Kapasitas penyimpanan yang dialokasikan ke pod. Ini tidak boleh lebih besar dari kapasitas PV.
`volumeMode`	Mode pemasangan. Atur ini ke `Filesystem`.
`volumeName`	Nama PV yang akan dilekatkan ke PVC.

Terapkan manifest untuk membuat PV dan PVC.
```
kubectl apply -f bmcpfs-pv-pvc.yaml
```

Verifikasi bahwa PVC terikat ke PV.

kubectl get pvc bmcpfs

Keluaran yang diharapkan:

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

Status STATUS harus Bound.

Langkah 3: Pasang sistem file CPFS dalam aplikasi

Studi kasus 1: Pasang seluruh sistem file CPFS ke kontainer

Buat file bernama cpfs-test.yaml untuk menerapkan aplikasi contoh yang memasang seluruh sistem file 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

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

Periksa status penyebaran pod.

kubectl get pod -l app=cpfs-test

Keluaran 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

Masuk ke pod mana saja untuk memverifikasi bahwa volume CPFS untuk Lingjun yang disiapkan secara statis telah dipasang.

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)

Studi kasus 2: Pasang subdirektori sistem file CPFS

Dalam skenario penyimpanan bersama, gunakan volumeMounts.subPath untuk isolasi data multi-tenancy atau multi-tugas. Ini memungkinkan beberapa pod aplikasi berbagi volume CPFS yang sama, dengan masing-masing memiliki direktorinya sendiri yang independen.

Buat file bernama pod.yaml dengan konten berikut. Contoh ini membuat satu pod dengan dua kontainer, masing-masing memasang subdirektori berbeda dari PVC yang sama (bmcpfs) menggunakan subPath.

Saat memasang pod, jika subdirektori yang ditentukan oleh subPath (misalnya, workspace/alpha) tidak ada di sistem file CPFS, sistem secara otomatis membuatnya.

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 kontainer
          subPath: workspace/alpha   # Memasang hanya subdirektori workspace/alpha di volume

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

Sebarkan pod.
```
kubectl apply -f pod.yaml
```
Verifikasi pemasangan dan isolasi data dengan terhubung ke setiap kontainer dan membuat file. File yang dibuat di satu kontainer tidak terlihat di kontainer lain.
1. Verifikasi pemasangan dan isolasi data di kontainer task-alpha.
  1. Hubungkan ke kontainer task-alpha.
```
kubectl exec -it cpfs-subpath-demo-pod -c task-alpha-container -- /bin/sh
```
  2. Lihat sistem file yang dipasang untuk memastikan volume CPFS ada.
```
df -h
```
    Output yang Diharapkan berikut menunjukkan bahwa direktori bersama (/share) dipasang ke jalur /data/workspace di kontainer.
```
Filesystem                Size      Used Available Use% Mounted on
...
192.XX.XX.0:/share          10.0T     1.0G     10.0T   0% /data/workspace
...
```
  3. Periksa struktur direktori induk dari target pemasangan.
```
ls -l /data/
```
    Output yang Diharapkan berikut menunjukkan bahwa subdirektori bernama workspace ada di direktori /data/.
```
total 4
drwxr-xr-x    2 root     root          4096 Aug 15 10:00 workspace
```
  4. Buat file di direktori yang dipasang untuk memverifikasi izin tulis.
```
echo "hello from alpha" > /data/workspace/alpha.log
exit
```
2. Verifikasi pemasangan dan isolasi data di kontainer task-beta.
  1. Hubungkan ke kontainer task-beta.
```
kubectl exec -it cpfs-subpath-demo-pod -c task-beta-container -- /bin/sh
```
  2. Buat file di target pemasangan /data/workspace di kontainer.
```
echo "hello from beta" > /data/workspace/beta.log
```
  3. Periksa file di direktori /data/workspace/.
```
ls -l /data/workspace/
```
    Output yang Diharapkan berikut menunjukkan bahwa beta.log dibuat dan alpha.log tidak ada. Ini menunjukkan bahwa data diisolasi antara kedua kontainer.
```
total 4
-rw-r--r--    1 root     root            16 Aug 15 10:05 beta.log
```