Use CPFS for Lingjun Statically Provisioned Volumes in ACK Clusters - Container Service for Kubernetes

Choisir une méthode de montage

S'appuyant sur l'interface Container Storage Interface (CSI), ACK permet de monter les systèmes de fichiers CPFS for Lingjun sous forme de PV et de revendications de volume persistant (PVC) pré-provisionnés statiquement. Le module complémentaire CSI sélectionne automatiquement la méthode de montage optimale en fonction du type de nœud sur lequel s'exécute le pod :

Méthode de montage	Nœuds pris en charge	Prérequis
Canal de stockage virtuel (VSC)	Nœuds Lingjun uniquement	Aucune configuration supplémentaire requise.
VPC	Nœuds non-Lingjun	Créez un point de montage VPC dans le même VPC que les nœuds du cluster.

Avant de commencer, identifiez le scénario qui s'applique à votre cluster :

Les pods s'exécutent sur des nœuds Lingjun : le montage VSC est utilisé par défaut. Ignorez la création du point de montage VPC.
Les pods s'exécutent sur des nœuds non-Lingjun : le montage VPC est requis. Créez un point de montage VPC à l'étape 1.
Les pods s'exécutent sur les deux types de nœuds : Définissez à la fois vpcMountTarget et mountpointAutoSwitch: "true" dans le PV. Le module complémentaire CSI effectuera le basculement automatiquement.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

Consultez les limites de CPFS for Lingjun
Un cluster ACK exécutant Kubernetes 1.26 ou version ultérieure. Mettez à niveau si nécessaire.
Des nœuds exécutant Alibaba Cloud Linux 3
Les modules complémentaires de stockage suivants, aux versions requises (vérifiez et mettez à jour depuis la page Add-ons) :
- Module complémentaire CSI (csi-plugin et csi-provisioner) : v1.33.1 ou ultérieur (gestion des modules complémentaires CSI).
- cnfs-nas-daemon : 0.1.2 ou ultérieur
  Configurer les ressources cnfs-nas-daemon
  Le module complémentaire cnfs-nas-daemon gère les processus Elastic File Client (EFC). Il consomme des ressources importantes et impacte directement les performances du stockage. Ajustez les ressources depuis la page Add-ons :
  - CPU : Dépend de la bande passante totale du nœud. Recommandation : 0,5 cœur par Gbps de bande passante, plus 1 cœur supplémentaire pour la gestion des métadonnées.
    
    Exemple : Pour un nœud de 100 Gbps, la demande CPU est de 100 × 0.5 + 1 = 51 cœurs.
  - Mémoire : CPFS for Lingjun utilise Filesystem in USErspace (FUSE), ce qui signifie que les caches de lecture/écriture et les métadonnées consomment de la mémoire. Définissez la demande à 15 % de la mémoire totale du nœud.
  Ajustez ces valeurs selon vos besoins et votre charge de travail.
  Important
  
  Comportement lors des mises à jour : cnfs-nas-daemon utilise par défaut une stratégie de mise à jour OnDelete. Après avoir ajusté le CPU ou la mémoire sur la page Add-ons, supprimez manuellement les pods cnfs-nas-daemon sur chaque nœud afin de les recréer avec la nouvelle configuration. Effectuez cette opération pendant les heures creuses.
  
  Risque d'interruption : La suppression ou le redémarrage du pod cnfs-nas-daemon interrompt temporairement le service de montage CPFS sur ce nœud.
  
  Pour les nœuds ne prenant pas en charge la mise à niveau à chaud^① : Interruption brutale entraînant l'échec des pods applicatifs. Supprimez et redémarrez manuellement les pods applicatifs pour rétablir le service.
  
  Pour les nœuds prenant en charge la mise à niveau à chaud^① : Les pods applicatifs récupèrent automatiquement après le redémarrage de cnfs-nas-daemon.
  
  ① : Un nœud prend en charge les mises à niveau à chaud s'il remplit toutes les conditions suivantes :
  
  La version du noyau du nœud est 5.10.134-18 ou ultérieure.
  
  bmcpfs-csi-controller et bmcpfs-csi-plugin sont en version 1.35.1 ou ultérieure.
  
  cnfs-nas-daemon est en version 0.1.9-compatible.1 ou ultérieure.
- bmcpfs-csi : comprend bmcpfs-csi-controller (module complémentaire du plan de contrôle géré par ACK) et bmcpfs-csi-node (DaemonSet côté nœud)

Notes d'utilisation

Zone de montage VSC : Le nœud exécutant le pod doit se trouver dans la même hpn-zone que l'instance du système de fichiers CPFS for Lingjun.
Initialisation des nœuds : Un nœud Lingjun doit être associé à un système de fichiers CPFS for Lingjun lors de son initialisation. Dans le cas contraire, le montage CSI échouera.
Drainage des nœuds : Avant de retirer un nœud Lingjun défectueux, drainez tous les pods qu'il héberge. Ignorer cette étape entraîne des incohérences dans les métadonnées du cluster et laisse des ressources de pods orphelines impossibles à nettoyer.
Un seul PV par instance CPFS : Le montage de plusieurs sous-répertoires d'un même système de fichiers CPFS en tant que PV distincts vers un seul pod n'est pas pris en charge. En raison des limitations du pilote, cela provoque l'échec du démarrage du pod. Créez un seul PV/PVC et utilisez volumeMounts.subPath pour monter les sous-répertoires. subPath utilise un bind mount léger, sans impact sur les performances.

Étape 1 : Créer un système de fichiers CPFS

Créez un système de fichiers CPFS for Lingjun et notez l'ID du système de fichiers.
(Facultatif) Pour les nœuds non-Lingjun, créez un point de montage VPC dans le même VPC que les nœuds de votre cluster et notez le nom de domaine du point de montage. Format : cpfs--vpc-.<Region>.cpfs.aliyuncs.com.

Non requis si les pods s'exécutent sur des nœuds Lingjun (le montage VSC est utilisé par défaut).

Étape 2 : Créer un PV et un PVC

Enregistrez le modèle suivant sous le nom bmcpfs-pv-pvc.yaml, en remplaçant les espaces réservés par l'ID de votre système de fichiers et, si nécessaire, le point de montage VPC.

Paramètres du PV

Paramètre	Description	Requis
`accessModes`	Mode d'accès au PV.	Oui
`capacity.storage`	Capacité de stockage déclarée. N'affecte pas la capacité réelle.	Oui
`csi.driver`	Type de pilote. Pour CPFS for Lingjun, utilisez `bmcpfsplugin.csi.alibabacloud.com`.	Oui
`csi.volumeHandle`	ID du système de fichiers CPFS for Lingjun.	Oui
`csi.volumeAttributes.vpcMountTarget`	Nom de domaine du point de montage VPC. Requis pour les nœuds non-Lingjun ; omettez-le si les pods sont planifiés uniquement sur des nœuds Lingjun.	Conditionnel
`csi.volumeAttributes.mountpointAutoSwitch`	Active le basculement automatique entre les points de montage VSC et VPC. À utiliser avec `vpcMountTarget`.	Non
`mountOptions`	Options de montage.	Non

Paramètres du PVC

Paramètre	Description	Requis
`accessModes`	Mode d'accès demandé par le PVC. Doit correspondre à celui du PV.	Oui
`resources.requests.storage`	Capacité de stockage allouée au pod. Ne doit pas dépasser la capacité du PV.	Oui
`volumeMode`	Mode de montage. Définissez sur `Filesystem`.	Oui
`volumeName`	Nom du PV à lier à ce PVC.	Oui

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:
      # Required if pods schedule to non-Lingjun nodes or cross-zone automatic VPC switching is enabled.
      # Omit if pods schedule only to Lingjun nodes.
      vpcMountTarget: cpfs-***-vpc-***.<Region>.cpfs.aliyuncs.com
      # Enables automatic switching between VSC and VPC mount points.
      # Use together with vpcMountTarget.
      mountpointAutoSwitch: "true"
    # Replace with your CPFS for Lingjun file system ID.
    volumeHandle: bmcpfs-*****
  mountOptions: []

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

Appliquez la configuration.
```
kubectl apply -f bmcpfs-pv-pvc.yaml
```

Confirmez que le PVC est lié au PV.

kubectl get pvc bmcpfs

Résultat attendu :

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

Le STATUS est Bound, ce qui confirme que le PVC est lié au PV.

Étape 3 : Déployer une charge de travail

Scénario 1 : Monter l'intégralité du système de fichiers CPFS

Utilisez cette approche lorsque tous les conteneurs nécessitent un accès complet au système de fichiers CPFS.

Enregistrez le modèle YAML suivant sous le nom 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

Créez le déploiement.
```
kubectl create -f cpfs-test.yaml
```

Vérifiez que les deux pods sont en cours d'exécution.

kubectl get pod -l app=cpfs-test

Résultat attendu :

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

Vérifiez le montage du volume CPFS à l'intérieur d'un pod.

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

Résultat attendu :

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)

Le type de montage fuse.aliyun-alinas-efc sur /data confirme que le volume CPFS est monté.

Scénario 2 : Monter des sous-répertoires pour l'isolation des données

Dans les scénarios de stockage partagé, tels que les environnements multi-locataires ou multitâches, plusieurs conteneurs peuvent partager un même volume CPFS tout en isolant les données dans des répertoires distincts. Utilisez volumeMounts.subPath pour monter différents sous-répertoires dans différents conteneurs à partir du même PVC.

Si un répertoire subPath (par exemple, workspace/alpha ) n'existe pas, il est créé automatiquement.

Enregistrez le modèle YAML suivant sous le nom pod.yaml. Ce pod exécute deux conteneurs, chacun montant un sous-répertoire différent du même PVC (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        # Mount path inside the container
          subPath: workspace/alpha          # Mount the workspace/alpha subdirectory only

    - name: task-beta-container
      image: busybox:1.35
      command: ["/bin/sh", "-c", "sleep 3600"]
      volumeMounts:
        - name: cpfs-storage
          mountPath: /data/workspace        # Mount paths can be identical across containers
          subPath: workspace/beta           # Mount the workspace/beta subdirectory only
  volumes:
    - name: cpfs-storage
      persistentVolumeClaim:
        claimName: bmcpfs                  # Reference the PVC created earlier

Déployez le pod.
```
kubectl apply -f pod.yaml
```
Vérifiez le montage et les permissions d'écriture pour task-alpha-container.
1. Connectez-vous au conteneur.
```
kubectl exec -it cpfs-subpath-demo-pod -c task-alpha-container -- /bin/sh
```
2. Confirmez que le volume CPFS est monté.
```
df -h
```
  Résultat attendu (répertoire partagé monté sur /data/workspace) :
```
Filesystem                Size      Used Available Use% Mounted on
...
192.XX.XX.0:/share          10.0T     1.0G     10.0T   0% /data/workspace
...
```
  L'entrée du système de fichiers sur /data/workspace confirme que le sous-répertoire CPFS est monté.
3. Vérifiez la structure du répertoire parent.
```
ls -l /data/
```
  Résultat attendu :
```
total 4
drwxr-xr-x    2 root     root          4096 Aug 15 10:00 workspace
```
4. Écrivez un fichier de test et quittez.
```
echo "hello from alpha" > /data/workspace/alpha.log
exit
```
Vérifiez le montage et l'isolation des données pour task-beta-container.
1. Connectez-vous au conteneur.
```
kubectl exec -it cpfs-subpath-demo-pod -c task-beta-container -- /bin/sh
```
2. Écrivez un fichier de test.
```
echo "hello from beta" > /data/workspace/beta.log
```
3. Listez les fichiers dans le point de montage.
```
ls -l /data/workspace/
```
  Résultat attendu :
```
total 4
-rw-r--r--    1 root     root            16 Aug 15 10:05 beta.log
```
  beta.log est présent mais alpha.log est absent, ce qui confirme l'isolation des données entre les conteneurs.