Azure Operator Nexus-opslagapparaat

Artikel
05/07/2024

Azure Operator Nexus is gebouwd op basisconstructies zoals rekenservers, opslagapparaten en netwerkinfrastructuurapparaten. Azure Operator Nexus-opslagapparaten vertegenwoordigen permanente opslagapparaten in het rek.

Elk opslagapparaat bevat meerdere opslagapparaten, die worden samengevoegd om één opslaggroep te bieden. Deze opslaggroep wordt vervolgens uitgesneden in meerdere volumes, die worden gepresenteerd aan de rekenservers als blokopslagapparaten. De rekenservers kunnen deze blokopslagapparaten gebruiken als permanente opslag voor hun workloads. Elk Azure Operator Nexus-cluster wordt ingericht met één opslagapparaat dat wordt gedeeld in alle tenantworkloads.

Het opslagapparaat in een Azure Operator Nexus-exemplaar wordt weergegeven als een Azure-resource. Operators krijgen toegang om de kenmerken ervan weer te geven, zoals elke andere Azure-resource.

Kubernetes-opslagklassen

De Kubernetes-stack van De Azure Operator Nexus-software biedt twee typen opslag. Operators selecteren ze via het Kubernetes StorageClass-mechanisme.

StorageClass: nexus-volume

Het standaardopslagmechanisme, nexus-volume, is de voorkeurskeuze voor de meeste gebruikers. Het biedt de hoogste prestatie- en beschikbaarheidsniveaus. Volumes kunnen echter niet tegelijkertijd worden gedeeld over meerdere werkknooppunten. Operators kunnen deze volumes openen en beheren met behulp van de Azure-API en portal, via de volumeresource.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: testPvc
  namespace: default
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 107Mi
  storageClassName: nexus-volume
  volumeMode: Block
  volumeName: testVolume
status:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 107Mi
  phase: Bound

StorageClass: nexus-shared

In situaties waarin een gedeeld bestandssysteem is vereist, is de nexus-gedeelde opslagklasse beschikbaar. Deze opslagklasse biedt een gedeelde opslagoplossing door meerdere pods in hetzelfde Nexus Kubernetes-cluster in te schakelen om gelijktijdig toegang te krijgen tot hetzelfde volume en hetzelfde volume te delen. De nexus-gedeelde opslagklasse wordt ondersteund door een NFS-opslagservice. Deze NFS-opslagservice (opslaggroep is momenteel beperkt tot een maximale grootte van 1TiB) is beschikbaar per CSN (Cloud Service Network). Elk Nexus Kubernetes-cluster dat is gekoppeld aan het CSN kan permanent volume inrichten vanuit deze gedeelde opslaggroep. Nexus-gedeeld ondersteunt zowel LSU-toegangsmodi (Read Write Once) als Read Write Many (RWX). Dit betekent dat de workloadtoepassingen gebruik kunnen maken van een van deze toegangsmodi voor toegang tot de gedeelde opslag.

Hoewel de prestaties en beschikbaarheid van nexus-gedeeld voldoende zijn voor de meeste toepassingen, raden we aan dat workloads met zware I/O-vereisten de optie nexus-volume gebruiken voor optimale prestaties.

Schrijfbewerkingen eenmaal lezen (RWO)

In de modus Read Write Once (RWO) kan het nexus-gedeelde volume slechts door één knooppunt of eiser tegelijk worden gekoppeld. Met de readWriteOnce-toegangsmodus hebben meerdere pods nog steeds toegang tot het volume wanneer de pods op hetzelfde knooppunt worden uitgevoerd.

apiVersion: v1
items:
- apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: test-pvc
    namespace: default
  spec:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 5Gi
    storageClassName: nexus-shared
    volumeMode: Filesystem
    volumeName: TestVolume
  status:
    accessModes:
    - ReadWriteOnce
    capacity:
      storage: 5Gi
    phase: Bound

Lezen veel (RWX)

In de modus Read Write Many (RWX) kan het nexus-gedeelde volume tegelijkertijd worden gekoppeld door meerdere knooppunten of eisers.

apiVersion: v1
items:
- apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: test-pvc
    namespace: default
  spec:
    accessModes:
    - ReadWriteMany
    resources:
      requests:
        storage: 5Gi
    storageClassName: nexus-shared
    volumeMode: Filesystem
    volumeName: TestVolume
  status:
    accessModes:
    - ReadWriteMany
    capacity:
      storage: 5Gi
    phase: Bound

Voorbeelden

Read Write Once (RWO) met nexus-volumeopslagklasse

Het onderstaande manifest maakt een StatefulSet met PersistentVolumeClaimTemplate met behulp van de nexus-volumeopslagklasse in de ReadWriteOnce-modus.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: test-sts-rwo
  labels:
    app: test-sts-rwo
spec:
  serviceName: test-sts-rwo-svc
  replicas: 3
  selector:
    matchLabels:
      app: test-sts-rwo
  template:
    metadata:
      labels:
        app: test-sts-rwo
    spec:
      containers:
      - name: busybox
        command:
        - "/bin/sh"
        - "-c"
        - while true; do echo "$(date) -- $(hostname)" >> /mnt/hostname.txt; sleep 1; done
        image: busybox
        volumeMounts:
        - name: test-volume-rwo
          mountPath: /mnt/
  volumeClaimTemplates:
    - metadata:
        name: test-volume-rwo
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 10Gi
        storageClassName: nexus-volume

Elke pod van de StatefulSet heeft één PersistentVolumeClaim gemaakt.

# kubectl get pvc
NAME                             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
test-volume-rwo-test-sts-rwo-0   Bound    pvc-e41fec47-cc43-4cd5-8547-5a4457cbdced   10Gi       RWO            nexus-volume   8m17s
test-volume-rwo-test-sts-rwo-1   Bound    pvc-1589dc79-59d2-4a1d-8043-b6a883b7881d   10Gi       RWO            nexus-volume   7m58s
test-volume-rwo-test-sts-rwo-2   Bound    pvc-82e3beac-fe67-4676-9c61-e982022d443f   10Gi       RWO            nexus-volume   12s

# kubectl get pods -o wide -w
NAME             READY   STATUS    RESTARTS   AGE     IP              NODE                                         NOMINATED NODE   READINESS GATES
test-sts-rwo-0   1/1     Running   0          8m31s   10.245.231.74   nexus-cluster-6a8c4018-agentpool2-md-vhhv6   <none>           <none>
test-sts-rwo-1   1/1     Running   0          8m12s   10.245.126.73   nexus-cluster-6a8c4018-agentpool1-md-27nw4   <none>           <none>
test-sts-rwo-2   1/1     Running   0          26s     10.245.183.9    nexus-cluster-6a8c4018-agentpool1-md-4jprt   <none>           <none>

# kubectl exec test-sts-rwo-0 -- cat /mnt/hostname.txt
Thu Nov  9 21:57:25 UTC 2023 -- test-sts-rwo-0
Thu Nov  9 21:57:26 UTC 2023 -- test-sts-rwo-0
Thu Nov  9 21:57:27 UTC 2023 -- test-sts-rwo-0

# kubectl exec test-sts-rwo-1 -- cat /mnt/hostname.txt
Thu Nov  9 21:57:19 UTC 2023 -- test-sts-rwo-1
Thu Nov  9 21:57:20 UTC 2023 -- test-sts-rwo-1
Thu Nov  9 21:57:21 UTC 2023 -- test-sts-rwo-1

# kubectl exec test-sts-rwo-s -- cat /mnt/hostname.txt
Thu Nov  9 21:58:32 UTC 2023 -- test-sts-rwo-2
Thu Nov  9 21:58:33 UTC 2023 -- test-sts-rwo-2
Thu Nov  9 21:58:34 UTC 2023 -- test-sts-rwo-2

Read Write Many (RWX) met nexus-gedeelde opslagklasse

Het onderstaande manifest maakt een implementatie met een PersistentVolumeClaim (PVC) met behulp van de nexus-gedeelde opslagklasse in de readWriteMany-modus. Het PVC dat is gemaakt, wordt gedeeld door alle pods van de implementatie en kan worden gebruikt om ze allemaal tegelijkertijd te lezen en te schrijven.

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-volume-rwx
spec:
  accessModes:
    - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 3Gi
  storageClassName: nexus-shared
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: test-deploy-rwx
  name: test-deploy-rwx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: test-deploy-rwx
  template:
    metadata:
      labels:
        app: test-deploy-rwx
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: kubernetes.azure.com/agentpool
                operator: Exists
                values: []
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: busybox
        command:
        - "/bin/sh"
        - "-c"
        - while true; do echo "$(date) -- $(hostname)" >> /mnt/hostname.txt; sleep 1; done
        image: busybox
        volumeMounts:
        - name: test-volume-rwx
          mountPath: /mnt/
      volumes:
      - name: test-volume-rwx
        persistentVolumeClaim:
          claimName: test-volume-rwx
...

Zodra dit is toegepast, zijn er drie replica's van de implementatie die hetzelfde PVC delen.

# kubectl get pvc
NAME                             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
test-volume-rwx                  Bound    pvc-32f0717e-6b63-4d64-a458-5be4ffe21d37   3Gi        RWX            nexus-shared   6s

# kubectl get pods -o wide -w
NAME                             READY   STATUS    RESTARTS   AGE     IP               NODE                                         NOMINATED NODE   READINESS GATES
test-deploy-rwx-fdb8f49c-86pv4   1/1     Running   0          18s     10.245.224.140   nexus-cluster-6a8c4018-agentpool1-md-s2dh7   <none>           <none>
test-deploy-rwx-fdb8f49c-9zsjf   1/1     Running   0          18s     10.245.126.74    nexus-cluster-6a8c4018-agentpool1-md-27nw4   <none>           <none>
test-deploy-rwx-fdb8f49c-wdgw7   1/1     Running   0          18s     10.245.231.75    nexus-cluster-6a8c4018-agentpool2-md-vhhv6   <none>           <none>

Het kan worden waargenomen uit de onderstaande uitvoer dat alle pods in hetzelfde PVC schrijven.

# kubectl exec test-deploy-rwx-fdb8f49c-86pv4 -- cat /mnt/hostname.txt
Thu Nov  9 21:51:41 UTC 2023 -- test-deploy-rwx-fdb8f49c-86pv4
Thu Nov  9 21:51:41 UTC 2023 -- test-deploy-rwx-fdb8f49c-9zsjf
Thu Nov  9 21:51:41 UTC 2023 -- test-deploy-rwx-fdb8f49c-wdgw7
Thu Nov  9 21:51:42 UTC 2023 -- test-deploy-rwx-fdb8f49c-86pv4

# kubectl exec test-deploy-rwx-fdb8f49c-9zsjf -- cat /mnt/hostname.txt
Thu Nov  9 21:51:41 UTC 2023 -- test-deploy-rwx-fdb8f49c-86pv4
Thu Nov  9 21:51:41 UTC 2023 -- test-deploy-rwx-fdb8f49c-9zsjf
Thu Nov  9 21:51:41 UTC 2023 -- test-deploy-rwx-fdb8f49c-wdgw7
Thu Nov  9 21:51:42 UTC 2023 -- test-deploy-rwx-fdb8f49c-86pv4

# kubectl exec test-deploy-rwx-fdb8f49c-wdgw7 -- cat /mnt/hostname.txt
Thu Nov  9 21:51:41 UTC 2023 -- test-deploy-rwx-fdb8f49c-86pv4
Thu Nov  9 21:51:41 UTC 2023 -- test-deploy-rwx-fdb8f49c-9zsjf
Thu Nov  9 21:51:41 UTC 2023 -- test-deploy-rwx-fdb8f49c-wdgw7
Thu Nov  9 21:51:42 UTC 2023 -- test-deploy-rwx-fdb8f49c-86pv4

Status van opslagapparaat

De volgende eigenschappen weerspiegelen de operationele status van een opslagapparaat:

Status geeft de status aan die is afgeleid van het opslagapparaat. De status kan Availablezijn, Errorof Provisioning.
Provisioning State biedt de huidige inrichtingsstatus van het opslagapparaat. De inrichtingsstatus kan Succeeded, Failedof InProgress.
Capacity biedt de totale en gebruikte capaciteit van het opslagapparaat.
Remote Vendor Management geeft aan of extern leverancierbeheer is ingeschakeld of uitgeschakeld voor het opslagapparaat.

Bewerkingen van opslagapparaat

Lijst met opslagapparaten: opslagapparaten weergeven in de opgegeven resourcegroep of het opgegeven abonnement.
Opslagapparaat weergeven: Eigenschappen van het opgegeven opslagapparaat ophalen.
Opslagapparaat bijwerken: werk eigenschappen of tags van het opgegeven opslagapparaat bij.
Extern leverancierbeheer in- of uitschakelen voor opslagapparaat: schakel extern leverancierbeheer in of uit voor het opgegeven opslagapparaat.

Notitie

Klanten kunnen opslagapparaten niet rechtstreeks maken of verwijderen. Deze resources worden alleen gemaakt als de realisatie van de levenscyclus van het cluster. Implementatie blokkeert het maken of verwijderen van aanvragen van elke gebruiker en maakt alleen interne/toepassingsgestuurde creatie- of verwijderingsbewerkingen mogelijk.

Share via