Gunakan Volume Provisioning Dinamis CPFS for Lingjun di Kluster ACK - Container Service for Kubernetes

Mekanisme provisioning volume dinamis menyediakan penyimpanan otomatis dan sesuai permintaan untuk CPFS for Lingjun, menghilangkan kompleksitas manajemen Persistent Volume (PV) secara manual. Metode ini mendukung operasi baca dan tulis paralel oleh beberapa aplikasi, sehingga sangat cocok untuk skenario seperti pelatihan AI dan analitik data, memungkinkan berbagi data secara efisien—seperti kode, file konfigurasi, dan hasil komputasi—antar aplikasi.

Persiapan

Tinjau Batasan untuk CPFS for Lingjun.
Pastikan kluster memenuhi persyaratan berikut:
- Versi kluster: 1.26 atau lebih baru. Untuk meningkatkan kluster Anda, lihat Tingkatkan kluster secara manual.
- Sistem operasi node: Alibaba Cloud Linux 3.
- Komponen penyimpanan berikut telah diinstal dan memenuhi persyaratan versi.
  
  Buka halaman Add-ons untuk memeriksa versi, menginstal, atau meningkatkan komponen.
  - Add-on CSI (csi-plugin dan csi-provisioner): v1.33.1 atau lebih baru. Untuk meningkatkan, lihat Kelola add-on CSI.
  - Add-on cnfs-nas-daemon: 0.1.2 atau lebih baru.
    Bentangkan untuk melihat detail tentang cnfs-nas-daemon
    Add-on cnfs-nas-daemon mengelola proses EFC. Komponen ini mengonsumsi sumber daya signifikan dan secara langsung memengaruhi performa penyimpanan. Sesuaikan konfigurasi sumber dayanya di halaman Add-ons. Gunakan rekomendasi berikut:
    
    CPU: Permintaan CPU berskala sebanding dengan total bandwidth node. Alokasikan 0,5 core per 1 Gb/s bandwidth, ditambah 1 core tambahan untuk manajemen metadata. Sesuaikan pengaturan CPU menggunakan aturan ini.
    
    Contohnya, untuk node dengan NIC 100 Gb/s, atur permintaan CPU menjadi 100 * 0.5 + 1 = 51 core.
    
    Memori: CPFS for Lingjun menggunakan FUSE. Caching baca/tulis data dan metadata file mengonsumsi memori. Atur permintaan memori menjadi 15% dari total memori node.
    
    Setelah menyesuaikan konfigurasi, ubah ukuran sumber daya secara dinamis berdasarkan beban kerja aktual.
    
    Penting
    
    Perilaku pembaruan: DaemonSet cnfs-nas-daemon menggunakan strategi pembaruan OnDelete secara default. Setelah mengubah pengaturan CPU atau memori di halaman Add-ons, hapus secara manual pod cnfs-nas-daemon yang ada di setiap node untuk memicu pembuatan ulang dan menerapkan pengaturan baru.
    
    Lakukan operasi ini selama jam sepi untuk memastikan stabilitas bisnis.
    
    Risiko: Menghapus atau me-restart pod cnfs-nas-daemon akan mengganggu pemasangan CPFS sementara di node tersebut.
    
    Node tanpa dukungan hot upgrade^①: Hal ini menyebabkan gangguan perangkat keras. Pod aplikasi gagal dan memerlukan penghapusan manual. Setelah dihapus, pod aplikasi akan me-restart dan pulih secara otomatis.
    
    Node dengan dukungan hot upgrade^①: Pod aplikasi pulih secara otomatis setelah pod cnfs-nas-daemon di-restart.
    
    ① Node mendukung hot upgrade jika memenuhi semua kondisi berikut:
    
    Versi kernel adalah 5.10.134-18 atau lebih baru.
    
    Versi bmcpfs-csi-controller dan bmcpfs-csi-plugin adalah 1.35.1 atau lebih baru.
    
    Versi cnfs-nas-daemon adalah 0.1.9-compatible.1 atau versi yang lebih baru.
  - Komponen bmcpfs-csi: 1.35.1 atau lebih baru.
    
    Komponen ini mencakup bmcpfs-csi-controller (komponen control plane, dikelola oleh ACK) dan bmcpfs-csi-node (komponen sisi node, diterapkan sebagai DaemonSet di kluster).

Catatan Penting

Saat menggunakan pemasangan VSC, node yang menjalankan pod harus berada di hpn-zone yang sama dengan instans sistem file CPFS for Lingjun.
Node Lingjun harus dikaitkan dengan sistem file CPFS for Lingjun selama inisialisasi. Jika tidak, pemasangan CSI akan gagal.
Sebelum mengambil offline node Lingjun karena kegagalan, drain semua pod darinya. Melewatkan langkah ini menyebabkan ketidakkonsistenan metadata kluster, meninggalkan sumber daya pod yang tidak dapat dipulihkan.
Jangan memasang beberapa volume dari sistem file CPFS for Lingjun yang sama dalam satu pod (misalnya, beberapa PV yang dibuat oleh StorageClass yang berisi bmcpfsId yang sama). Karena keterbatasan protokol native, ketika pod yang sama mencoba memasang instans sistem file yang sama beberapa kali (bahkan ke subdirektori berbeda), hal ini menyebabkan perilaku tak terduga.

Langkah 1: Buat Sistem File CPFS

Buat sistem file CPFS for Lingjun. Lihat Buat Sistem File CPFS for Lingjun. Catat ID sistem file tersebut.
(Opsional) Jika Anda ingin memasang pada node non-Lingjun, buat titik pemasangan VPC buat titik pemasangan VPC (di VPC yang sama dengan node kluster Anda), dan catat nama domain titik pemasangan tersebut. Formatnya adalah cpfs-***-vpc-***.<Region>.cpfs.aliyuncs.com.

Jika pod dijadwalkan ke node Lingjun, pemasangan VSC digunakan secara default. Lewati langkah ini.

Langkah 2: Buat StorageClass

Buat objek StorageClass sebagai templat penyimpanan.

Anda dapat membuat sc.yaml menggunakan konten berikut.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: alicloud-bmcpfs-test
provisioner: bmcpfsplugin.csi.alibabacloud.com
parameters:
  # ID sistem file CPFS for Lingjun
  bmcpfsId: bmcpfs-29000z8xz3lf5nj*****  
  # Tentukan subdirektori dalam sistem file
  # path: "/shared"  
# Izinkan ekspansi berikutnya
allowVolumeExpansion: true  
# Delete (pembersihan otomatis) atau Retain (simpan data)
reclaimPolicy: Delete

Deskripsi parameter:

Parameter	Wajib	Deskripsi
`bmcpfsId`	Ya	ID sistem file BMCPFS, dalam format `bmcpfs-xxxxxxxxx` atau `cpfs-xxxxxxxxx`.
`path`	Tidak	Subdirektori dalam sistem file. Jika ditentukan: Volume dibuat di bawah path `{path}/{volumeName}/`. Jika tidak ditentukan: Volume dibuat di bawah path `/{volumeName}/`.
`allowVolumeExpansion`	Tidak	Izinkan ekspansi otomatis melalui PVC nanti. Versi saat ini tidak mendukung ekspansi dinamis. Ini adalah parameter cadangan.
`reclaimPolicy`	Tidak	`Delete` (default): Secara otomatis menghapus fileset di sistem file backend saat Anda menghapus PVC. `Retain`: Menyimpan fileset di sistem file backend saat Anda menghapus PVC. Bersihkan secara manual. Direkomendasikan untuk lingkungan produksi.

Anda dapat membuat StorageClass tersebut.
```
kubectl apply -f sc.yaml
```

Langkah 3: Buat PVC

Aplikasi meminta volume melalui PVC dan mereferensikan StorageClass sebagai templat konfigurasi.

Anda dapat membuat pvc.yaml menggunakan konten berikut.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: bmcpfs-vsc
  namespace: default
spec:
  accessModes:
    # Volume CPFS for Lingjun mendukung banyak pod membaca dan menulis secara bersamaan
    - ReadWriteMany  
  resources:
    requests:
      # Mendukung penyimpanan kapasitas besar (tingkat Ti)
      storage: 10Ti  
  # Hanya mendukung Filesystem
  volumeMode: Filesystem
  # Tentukan StorageClass yang dibuat sebelumnya
  storageClassName: alicloud-bmcpfs-test

Deskripsi parameter:

Parameter berikut wajib diisi.

Parameter	Deskripsi
`accessModes`	Hanya mendukung `ReadWriteMany`, artinya banyak pod dapat memasang dan membaca/menulis secara bersamaan.
`storage`	Kapasitas penyimpanan yang diminta, mendukung satuan seperti Gi dan Ti.
`volumeMode`	Hanya mendukung `Filesystem`.
`storageClassName`	Tentukan `StorageClass` yang akan digunakan, memicu pembuatan volume dinamis.

Anda dapat membuat PVC tersebut.
```
kubectl apply -f pvc.yaml
```
Anda dapat menjalankan perintah berikut untuk memastikan status PVC.
- Jalankan kubectl get pvc bmcpfs-vsc -n default untuk melihat status PVC. Jika STATUS bernilai Bound, ini menunjukkan bahwa sistem telah secara otomatis membuat PV yang sesuai.
- Jalankan kubectl describe pvc bmcpfs-vsc -n default dan periksa pesan Provisioning succeeded di bagian Events.

Langkah 4: Buat Workload dan Pasang PVC

Setelah PVC dibuat, Anda dapat menerapkan workload contoh dan memasang PV yang terikat ke PVC ke aplikasi.

Anda dapat membuat deploy.yaml menggunakan konten berikut.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cpfs-shared-example
spec:
  # Buat 3 replika untuk memverifikasi penyimpanan bersama untuk banyak pod
  replicas: 3
  selector:
    matchLabels:
      app: cpfs-shared-app
  template:
    metadata:
      labels:
        app: cpfs-shared-app
    spec:
      # Pastikan pod dapat dijadwalkan ke node Lingjun
      tolerations:
        - key: node-role.alibabacloud.com/lingjun
          operator: Exists
          effect: NoSchedule
      # Opsional: Untuk menjadwalkan semua pod ke node tertentu, hapus komentar baris ini dan ubah nama node
      # nodeName: cn-hangzhou.10.XX.XX.226
      containers:
      - name: app-container
        image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        volumeMounts:
          - name: pvc-cpfs
            # Pasang volume bersama ke direktori /data di dalam kontainer
            mountPath: /data
        # Perintah siklus hidup sederhana untuk memverifikasi penulisan dan berbagi data
        # Setelah pod dimulai, ia menulis file yang berisi hostname-nya ke direktori bersama
        lifecycle:
          postStart:
            exec:
              command:
                - /bin/sh
                - -c
                - >
                  echo "Data written by $(hostname)" > /data/$(hostname).txt && 
                  echo "Deployment is running, check shared data in /data." && 
                  sleep 3600
      volumes:
        - name: pvc-cpfs
          persistentVolumeClaim:
            # Referensikan PVC yang dibuat sebelumnya
            claimName: bmcpfs-vsc

Anda dapat membuat Deployment tersebut.
```
kubectl apply -f deploy.yaml
```

Panduan Pelepasan Resource

Untuk menghindari biaya tak terduga dan memastikan keamanan data, ikuti langkah-langkah berikut untuk melepaskan resource yang tidak digunakan.

Hapus Workload
- Operasi: Hapus semua aplikasi yang menggunakan PVC terkait, seperti Deployment atau StatefulSet, untuk menghentikan aplikasi dan melepas volume.
- Contoh perintah: kubectl delete deployment <your-deployment-name>
Hapus PVC
- Operasi: Hapus PVC yang terkait dengan aplikasi. Penanganan data backend bergantung pada kebijakan reclaim (reclaimPolicy) dari StorageClass.
  - Retain (direkomendasikan): Setelah menghapus PVC, fileset CPFS for Lingjun backend dan datanya tetap utuh.
  - Delete: Menghapus PVC akan menghapus permanen PV yang terikat dan fileset CPFS for Lingjun backend-nya. Operasi ini tidak dapat dikembalikan. Gunakan dengan hati-hati.
- Contoh perintah: kubectl delete pvc <your-pvc-name>
Hapus PV (ketika kebijakan reclaim adalah Retain)
- Operasi: Jika kebijakan reclaim adalah Retain, PV berubah ke status Released setelah Anda menghapus PVC. Anda harus menghapus PV secara manual. Operasi ini hanya menghapus definisi resource di Kubernetes dan tidak memengaruhi data backend.
- Contoh perintah: kubectl delete pv <your-pv-name>
Hapus StorageClass (Opsional)
- Operasi: Jika Anda tidak lagi memerlukan kelas penyimpanan ini, Anda dapat menghapus StorageClass. Operasi ini tidak memengaruhi volume yang sudah dibuat.
- Contoh perintah: kubectl delete sc <your-sc-name>
Hapus Sistem File CPFS for Lingjun Backend
- Operasi: Operasi ini menghapus permanen semua data pada sistem file (termasuk data yang disimpan oleh kebijakan Retain) dan tidak dapat dipulihkan. Sebelum menjalankan, pastikan sistem file tidak memiliki ketergantungan bisnis. Untuk detailnya, lihat Hapus Sistem File.

FAQ

Mengapa PVC selalu dalam status `Pending`?

PVC dalam status Pending biasanya menunjukkan bahwa provisioning volume dinamis gagal. Anda dapat mengikuti langkah-langkah berikut untuk troubleshooting.

Periksa event PVC. Biasanya langsung menjelaskan alasan kegagalan.
```
kubectl describe pvc <your-pvc-name> -n <your-namespace>
```
Perhatikan informasi peringatan di bagian Events. Alasan umum meliputi:
- StorageClass not found: Bidang storageClassName salah, atau StorageClass yang sesuai tidak ada.
- provisioning failed atau failed to create fileset: Terjadi masalah saat berinteraksi dengan penyimpanan backend. Lanjutkan ke langkah berikutnya.
Periksa Konfigurasi StorageClass dan Driver CSI

Jika log event menunjukkan masalah konfigurasi atau tidak ada kesalahan jelas, Anda dapat memeriksa konfigurasi StorageClass dan status driver CSI.
```
# 1. Periksa konfigurasi YAML StorageClass
kubectl get storageclass <your-sc-name> -o yaml

# 2. Periksa apakah driver CSI terdaftar di kluster
kubectl get csidriver bmcpfsplugin.csi.alibabacloud.com
```
Anda dapat memastikan hal berikut:
- Konfigurasi StorageClass: Bidang provisioner benar, dan parameter parameters untuk bmcpfsId diisi dengan benar serta ID sistem file tersebut ada.
- Status bmcpfs-csi: Jika perintah get csidriver menghasilkan error atau tidak mengembalikan output, ini menunjukkan driver tidak terinstal dengan benar. Di halaman Add-ons kluster, Anda dapat menginstal bmcpfs-csi-controller, bmcpfs-csi-node, dan cnfs-nas-daemon.

Mengapa pod selalu dalam status `ContainerCreating`, atau mengapa muncul error `MountVolume.Setup failed` di event?

Error ini menunjukkan bahwa pod telah dijadwalkan ke node tetapi gagal memasang volume di node tersebut. Anda dapat mengikuti proses troubleshooting berikut.

Lihat Peristiwa Pod untuk Mengidentifikasi Penyebabnya

Anda dapat melihat log event pod menggunakan perintah describe pod.
```
kubectl describe pod <pod-name> -n <your-namespace>
```
Fokus pada pesan Warning di bagian Events, seperti FailedMount atau MountVolume.Setup failed.
Periksa Prasyarat Pemasangan

Pastikan status PVC adalah Bound. Pod hanya dapat memasang volume yang telah berhasil diikat.
```
kubectl get pvc <your-pvc-name>
```
STATUS PVC harus Bound. Jika berstatus Pending, ini menunjukkan adanya masalah selama pembuatan volume. Lihat Mengapa PVC selalu dalam status Pending?.
Periksa Log Detail Plug-in CSI Node

Jika PVC berstatus Bound dan pod berada di node yang benar, Anda dapat memastikan lebih lanjut operasi pemasangan yang dilakukan oleh komponen csi-plugin di sisi node.
```
# Lihat log csi-plugin di node pod untuk mendapatkan alasan kegagalan akhir
kubectl get pods -n kube-system -l app.kubernetes.io/name=bmcpfs-csi-driver   --field-selector spec.nodeName=<nodeName>   -o name | xargs kubectl logs -n kube-system -c csi-plugin
```
Log ini berisi pesan error tingkat terendah, seperti masalah konektivitas jaringan dari node ke backend penyimpanan, masalah izin titik pemasangan, atau error I/O mendasar.