Skip to main content
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Utiliser la topologie CSI

Contributeurs netapp-aruldeepa
PDF

Trident peut créer et attacher sélectivement des volumes aux nœuds présents dans un cluster Kubernetes en utilisant "Fonctionnalité de topologie CSI" .

Aperçu

À l’aide de la fonctionnalité Topologie CSI, l’accès aux volumes peut être limité à un sous-ensemble de nœuds, en fonction des régions et des zones de disponibilité. Les fournisseurs de cloud permettent aujourd'hui aux administrateurs Kubernetes de créer des nœuds basés sur des zones. Les nœuds peuvent être situés dans différentes zones de disponibilité au sein d’une région ou dans plusieurs régions. Pour faciliter le provisionnement des volumes pour les charges de travail dans une architecture multizone, Trident utilise la topologie CSI.

Astuce Découvrez plus d'informations sur la fonctionnalité de topologie CSI "ici" .

Kubernetes propose deux modes de liaison de volumes uniques :

  • Avec VolumeBindingMode défini à Immediate Trident crée le volume sans aucune connaissance de la topologie. La liaison de volumes et le provisionnement dynamique sont gérés lors de la création du PVC. Il s'agit de la valeur par défaut. VolumeBindingMode et convient aux clusters qui n'imposent pas de contraintes de topologie. Les volumes persistants sont créés sans aucune dépendance aux exigences de planification du pod demandeur.

  • Avec VolumeBindingMode défini à WaitForFirstConsumer La création et la liaison d'un volume persistant pour un PVC sont retardées jusqu'à ce qu'un pod utilisant le PVC soit planifié et créé. De cette façon, les volumes sont créés pour répondre aux contraintes de planification imposées par les exigences de topologie.

Remarque Le WaitForFirstConsumer Le mode de liaison ne nécessite pas d'étiquettes de topologie. Cette fonctionnalité peut être utilisée indépendamment de la fonction de topologie CSI.
Ce dont vous aurez besoin

Pour utiliser la topologie CSI, vous avez besoin des éléments suivants :

  • Un cluster Kubernetes exécutant un"Version Kubernetes prise en charge"

    kubectl version
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.3", GitCommit:"1e11e4a2108024935ecfcb2912226cedeafd99df", GitTreeState:"clean", BuildDate:"2020-10-14T12:50:19Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.3", GitCommit:"1e11e4a2108024935ecfcb2912226cedeafd99df", GitTreeState:"clean", BuildDate:"2020-10-14T12:41:49Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}

  • Les nœuds du cluster doivent avoir des étiquettes qui permettent de prendre en compte la topologie.(topology.kubernetes.io/region et topology.kubernetes.io/zone ). Ces étiquettes doivent être présentes sur les nœuds du cluster avant l'installation de Trident pour que ce Trident puisse prendre en compte la topologie.

    kubectl get nodes -o=jsonpath='{range .items[*]}[{.metadata.name}, {.metadata.labels}]{"\n"}{end}' | grep --color "topology.kubernetes.io"
[node1, {"beta.kubernetes.io/arch":"amd64","beta.kubernetes.io/os":"linux","kubernetes.io/arch":"amd64","kubernetes.io/hostname":"node1","kubernetes.io/os":"linux","node-role.kubernetes.io/master":"","topology.kubernetes.io/region":"us-east1","topology.kubernetes.io/zone":"us-east1-a"}]
[node2, {"beta.kubernetes.io/arch":"amd64","beta.kubernetes.io/os":"linux","kubernetes.io/arch":"amd64","kubernetes.io/hostname":"node2","kubernetes.io/os":"linux","node-role.kubernetes.io/worker":"","topology.kubernetes.io/region":"us-east1","topology.kubernetes.io/zone":"us-east1-b"}]
[node3, {"beta.kubernetes.io/arch":"amd64","beta.kubernetes.io/os":"linux","kubernetes.io/arch":"amd64","kubernetes.io/hostname":"node3","kubernetes.io/os":"linux","node-role.kubernetes.io/worker":"","topology.kubernetes.io/region":"us-east1","topology.kubernetes.io/zone":"us-east1-c"}]

Étape 1 : Créer un backend prenant en compte la topologie

Les systèmes de stockage Trident peuvent être conçus pour provisionner sélectivement des volumes en fonction des zones de disponibilité. Chaque serveur dorsal peut contenir une option supportedTopologies Bloc représentant la liste des zones et régions prises en charge. Pour les StorageClasses qui utilisent un tel backend, un volume ne sera créé que s'il est demandé par une application planifiée dans une région/zone prise en charge.

Voici un exemple de définition de backend :

YAML
---
version: 1
storageDriverName: ontap-san
backendName: san-backend-us-east1
managementLIF: 192.168.27.5
svm: iscsi_svm
username: admin
password: password
supportedTopologies:
  - topology.kubernetes.io/region: us-east1
    topology.kubernetes.io/zone: us-east1-a
  - topology.kubernetes.io/region: us-east1
    topology.kubernetes.io/zone: us-east1-b
JSON
{
  "version": 1,
  "storageDriverName": "ontap-san",
  "backendName": "san-backend-us-east1",
  "managementLIF": "192.168.27.5",
  "svm": "iscsi_svm",
  "username": "admin",
  "password": "password",
  "supportedTopologies": [
    {
      "topology.kubernetes.io/region": "us-east1",
      "topology.kubernetes.io/zone": "us-east1-a"
    },
    {
      "topology.kubernetes.io/region": "us-east1",
      "topology.kubernetes.io/zone": "us-east1-b"
    }
  ]
}
Remarque `supportedTopologies`sert à fournir une liste de régions et de zones par serveur dorsal. Ces régions et zones représentent la liste des valeurs autorisées qui peuvent être fournies dans une StorageClass. Pour les StorageClasses qui contiennent un sous-ensemble des régions et zones fournies dans un backend, Trident crée un volume sur le backend.

Vous pouvez définir supportedTopologies par pool de stockage également. Voir l’exemple suivant :

---
version: 1
storageDriverName: ontap-nas
backendName: nas-backend-us-central1
managementLIF: 172.16.238.5
svm: nfs_svm
username: admin
password: password
supportedTopologies:
  - topology.kubernetes.io/region: us-central1
    topology.kubernetes.io/zone: us-central1-a
  - topology.kubernetes.io/region: us-central1
    topology.kubernetes.io/zone: us-central1-b
storage:
  - labels:
      workload: production
    supportedTopologies:
      - topology.kubernetes.io/region: us-central1
        topology.kubernetes.io/zone: us-central1-a
  - labels:
      workload: dev
    supportedTopologies:
      - topology.kubernetes.io/region: us-central1
        topology.kubernetes.io/zone: us-central1-b

Dans cet exemple, le region et zone Les étiquettes indiquent l'emplacement du bassin de stockage. topology.kubernetes.io/region et topology.kubernetes.io/zone indiquer d'où les pools de stockage peuvent être utilisés.

Étape 2 : Définir des StorageClasses prenant en compte la topologie

En fonction des étiquettes de topologie fournies aux nœuds du cluster, les StorageClasses peuvent être définies pour contenir des informations de topologie. Cela déterminera les pools de stockage qui peuvent servir de candidats pour les demandes de PVC effectuées, ainsi que le sous-ensemble de nœuds qui peuvent utiliser les volumes provisionnés par Trident.

Voir l’exemple suivant :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata: null
name: netapp-san-us-east1
provisioner: csi.trident.netapp.io
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
  - matchLabelExpressions: null
  - key: topology.kubernetes.io/zone
    values:
      - us-east1-a
      - us-east1-b
  - key: topology.kubernetes.io/region
    values:
      - us-east1
parameters:
  fsType: ext4

Dans la définition de StorageClass fournie ci-dessus, volumeBindingMode est réglé sur WaitForFirstConsumer . Les PVC demandés avec cette StorageClass ne seront pas traités tant qu'ils ne seront pas référencés dans un pod. Et, allowedTopologies indique les zones et la région à utiliser. Le netapp-san-us-east1 StorageClass crée des PVC sur le san-backend-us-east1 Le backend est défini ci-dessus.

Étape 3 : Créer et utiliser un PVC

Une fois la StorageClass créée et associée à un backend, vous pouvez désormais créer des PVC.

Voir l'exemple spec ci-dessous:

---
kind: PersistentVolumeClaim
apiVersion: v1
metadata: null
name: pvc-san
spec: null
accessModes:
  - ReadWriteOnce
resources:
  requests:
    storage: 300Mi
storageClassName: netapp-san-us-east1

La création d'un PVC à l'aide de ce manifeste donnerait le résultat suivant :

kubectl create -f pvc.yaml
persistentvolumeclaim/pvc-san created
kubectl get pvc
NAME      STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS          AGE
pvc-san   Pending                                      netapp-san-us-east1   2s
kubectl describe pvc
Name:          pvc-san
Namespace:     default
StorageClass:  netapp-san-us-east1
Status:        Pending
Volume:
Labels:        <none>
Annotations:   <none>
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode:    Filesystem
Mounted By:    <none>
Events:
  Type    Reason                Age   From                         Message
  ----    ------                ----  ----                         -------
  Normal  WaitForFirstConsumer  6s    persistentvolume-controller  waiting for first consumer to be created before binding

Pour que Trident puisse créer un volume et le lier au PVC, utilisez le PVC dans une capsule. Voir l’exemple suivant :

apiVersion: v1
kind: Pod
metadata:
  name: app-pod-1
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: topology.kubernetes.io/region
            operator: In
            values:
            - us-east1
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: topology.kubernetes.io/zone
            operator: In
            values:
            - us-east1-a
            - us-east1-b
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  volumes:
  - name: vol1
    persistentVolumeClaim:
      claimName: pvc-san
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: vol1
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

Ce podSpec indique à Kubernetes de planifier le pod sur les nœuds présents dans le us-east1 et choisissez parmi tous les nœuds présents dans la région us-east1-a ou us-east1-b zones.

Voir le résultat suivant :

kubectl get pods -o wide
NAME        READY   STATUS    RESTARTS   AGE   IP               NODE              NOMINATED NODE   READINESS GATES
app-pod-1   1/1     Running   0          19s   192.168.25.131   node2             <none>           <none>
kubectl get pvc -o wide
NAME      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS          AGE   VOLUMEMODE
pvc-san   Bound    pvc-ecb1e1a0-840c-463b-8b65-b3d033e2e62b   300Mi      RWO            netapp-san-us-east1   48s   Filesystem

Mettre à jour les backends pour inclure supportedTopologies

Les backends préexistants peuvent être mis à jour pour inclure une liste de supportedTopologies en utilisant tridentctl backend update . Cela n'affectera pas les volumes déjà provisionnés et ne sera utilisé que pour les PVC ultérieurs.

Trouver plus d'informations