Verwenden Sie die CSI-Topologie
Astra Trident kann Volumes selektiv erstellen und zu Nodes in einem Kubernetes Cluster verbinden, indem der verwendet wird "Funktion CSI Topology".
Überblick
Mithilfe der CSI Topology-Funktion kann der Zugriff auf Volumes auf einen Teil von Nodes basierend auf Regionen und Verfügbarkeitszonen begrenzt werden. Cloud-Provider ermöglichen Kubernetes-Administratoren inzwischen das Erstellen von Nodes, die zonenbasiert sind. Die Nodes können sich in verschiedenen Verfügbarkeitszonen innerhalb einer Region oder über verschiedene Regionen hinweg befinden. Astra Trident verwendet CSI Topology, um die Provisionierung von Volumes für Workloads in einer Multi-Zone-Architektur zu vereinfachen.
|
Erfahren Sie mehr über die Funktion CSI Topology "Hier". |
Kubernetes bietet zwei unterschiedliche Modi für die Volume-Bindung:
-
Mit
VolumeBindingMode
Auf einstellenImmediate
, Astra Trident erstellt das Volume ohne Topologiebewusstsein. Die Volume-Bindung und die dynamische Bereitstellung werden bei der Erstellung des PVC behandelt. Dies ist die StandardeinstellungVolumeBindingMode
Und ist für Cluster geeignet, die keine Topologiebeschränkungen mehr durchsetzen. Persistente Volumes werden erstellt, ohne dass sie von den Planungsanforderungen des anfragenden Pods abhängig sind. -
Mit
VolumeBindingMode
Auf einstellenWaitForFirstConsumer
, Die Erstellung und Bindung eines Persistent Volume für ein PVC wird verzögert, bis ein Pod, der die PVC verwendet, geplant und erstellt wird. Auf diese Weise werden Volumes erstellt, um Planungseinschränkungen zu erfüllen, die durch Topologieanforderungen durchgesetzt werden.
|
Der WaitForFirstConsumer Für den Bindungsmodus sind keine Topologiebeschriftungen erforderlich. Diese kann unabhängig von der CSI Topology Funktion verwendet werden.
|
Für die Verwendung von CSI Topology benötigen Sie Folgendes:
-
Einen Kubernetes-Cluster mit einem "Unterstützte Kubernetes-Version"
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"}
-
Nodes im Cluster sollten über Labels verfügen, die eine Topologiebewusstsein einführen (
topology.kubernetes.io/region
Undtopology.kubernetes.io/zone
). Diese Labels * sollten auf Knoten im Cluster vorhanden sein* bevor Astra Trident installiert ist, damit Astra Trident Topologieorientiert ist.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"}]
Schritt 1: Erstellen Sie ein Topologieorientiertes Backend
Astra Trident Storage-Back-Ends können für die selektive Bereitstellung von Volumes basierend auf Verfügbarkeitszonen ausgelegt werden. Jedes Backend kann optional mittragen supportedTopologies
Block, der eine Liste der zu unterstützenden Zonen und Regionen darstellt. Bei StorageClasses, die ein solches Backend nutzen, wird ein Volume nur erstellt, wenn es von einer Applikation angefordert wird, die in einer unterstützten Region/Zone geplant ist.
Hier ist eine Beispiel-Backend-Definition:
--- 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
{ "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"} ] }
|
supportedTopologies Wird verwendet, um eine Liste von Regionen und Zonen pro Backend bereitzustellen. Diese Regionen und Zonen stellen die Liste der zulässigen Werte dar, die in einer StorageClass bereitgestellt werden können. Bei StorageClasses, die einen Teil der Regionen und Zonen enthalten, die in einem Backend bereitgestellt werden, erstellt Astra Trident ein Volume im Backend.
|
Sie können definieren supportedTopologies
Auch pro Storagepool. Das folgende Beispiel zeigt:
--- 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 region: Iowa-DC zone: Iowa-DC-A supportedTopologies: - topology.kubernetes.io/region: us-central1 topology.kubernetes.io/zone: us-central1-a - labels: workload: dev region: Iowa-DC zone: Iowa-DC-B supportedTopologies: - topology.kubernetes.io/region: us-central1 topology.kubernetes.io/zone: us-central1-b
In diesem Beispiel ist der region
Und zone
Etiketten stehen für die Position des Speicherpools. topology.kubernetes.io/region
Und topology.kubernetes.io/zone
Vorgeben, woher die Speicherpools verbraucht werden können.
Schritt: Definition von StorageClasses, die sich der Topologie bewusst sind
Auf der Grundlage der Topologiebeschriftungen, die den Nodes im Cluster zur Verfügung gestellt werden, können StorageClasses so definiert werden, dass sie Topologieinformationen enthalten. So werden die Storage-Pools festgelegt, die als Kandidaten für PVC-Anfragen dienen, und die Untergruppe der Nodes, die die von Trident bereitgestellten Volumes nutzen können.
Das folgende Beispiel zeigt:
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: netapp-san-us-east1 provisioner: csi.trident.netapp.io volumeBindingMode: WaitForFirstConsumer allowedTopologies: - matchLabelExpressions: - key: topology.kubernetes.io/zone values: - us-east1-a - us-east1-b - key: topology.kubernetes.io/region values: - us-east1 parameters: fsType: "ext4"
In der oben angegebenen StorageClass-Definition volumeBindingMode
Ist auf festgelegt WaitForFirstConsumer
. VES, die mit dieser StorageClass angefordert werden, werden erst dann gehandelt, wenn sie in einem Pod referenziert werden. Und allowedTopologies
Stellt die Zonen und die Region bereit, die verwendet werden sollen. Der netapp-san-us-east1
StorageClass erstellt VES auf dem san-backend-us-east1
Back-End oben definiert.
Schritt 3: Erstellen und verwenden Sie ein PVC
Wenn die StorageClass erstellt und einem Backend zugeordnet wird, können Sie jetzt PVCs erstellen.
Siehe Beispiel spec
Unten:
--- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: pvc-san spec: accessModes: - ReadWriteOnce resources: requests: storage: 300Mi storageClassName: netapp-san-us-east1
Das Erstellen eines PVC mithilfe dieses Manifests würde Folgendes zur Folge haben:
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
Verwenden Sie für Trident, ein Volume zu erstellen und es an die PVC zu binden, das in einem Pod verwendet wird. Das folgende Beispiel zeigt:
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
Diese PodSpec beauftragt Kubernetes, den Pod auf Nodes zu planen, die in vorhanden sind us-east1
Wählen Sie einen beliebigen Knoten aus, der im vorhanden ist us-east1-a
Oder us-east1-b
Zonen:
Siehe die folgende Ausgabe:
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
Aktualisieren Sie Back-Ends, um einzuschließen supportedTopologies
Vorhandene Back-Ends können mit einer Liste von aktualisiert werden supportedTopologies
Wird verwendet tridentctl backend update
. Dies wirkt sich nicht auf Volumes aus, die bereits bereitgestellt wurden und nur für nachfolgende VES verwendet werden.