Dispositivo de almacenamiento de Azure Operator Nexus

Artículo
05/10/2024

Azure Operator Nexus se basa en construcciones básicas como servidores de proceso, dispositivos de almacenamiento y dispositivos del tejido de red. Los dispositivos de almacenamiento de Azure Operator Nexus representan dispositivos de almacenamiento persistentes en el bastidor.

Cada dispositivo de almacenamiento contiene varios dispositivos de almacenamiento, que se agregan para proporcionar un solo bloque de almacenamiento. A continuación, dicho bloque de almacenamiento se divide en varios volúmenes, que se presentan a los servidores de proceso como dispositivos de almacenamiento en bloque. Los servidores de proceso pueden usar estos dispositivos de almacenamiento en bloque como almacenamiento persistente para sus cargas de trabajo. Cada clúster de Azure Operator Nexus se aprovisiona con un solo dispositivo de almacenamiento que se comparte en todas las cargas de trabajo del inquilino.

El dispositivo de almacenamiento de una instancia de Azure Operator Nexus se representa como un recurso de Azure. Los operadores obtienen acceso para ver sus atributos como cualquier otro recurso de Azure.

Clases de almacenamiento de Kubernetes

La pila de Kubernetes de software de Azure Operator Nexus ofrece dos tipos de almacenamiento. Los operadores los seleccionan a través del mecanismo StorageClass de Kubernetes.

StorageClass: nexus-volume

El mecanismo de almacenamiento predeterminado, nexus-volume, es la opción preferida para la mayoría de los usuarios. Proporciona los niveles más altos de rendimiento y disponibilidad. Sin embargo, los volúmenes no se pueden compartir simultáneamente entre varios nodos de trabajo. Los operadores pueden acceder a estos volúmenes y administrarlos mediante el portal y la API de Azure, a través del recurso de volumen.

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

En situaciones en las que se requiere un sistema de archivos compartido, la clase de almacenamiento nexus-shared está disponible. Esta clase de almacenamiento proporciona una solución de almacenamiento compartido al permitir que varios pods del mismo clúster de Nexus Kubernetes accedan simultáneamente al mismo volumen y lo compartan. La clase de almacenamiento nexus-shared está respaldada por un servicio de almacenamiento NFS. Este servicio de almacenamiento NFS (grupo de almacenamiento limitado actualmente a un tamaño máximo de 1TiB) está disponible por red de servicio en la nube (CSN). Cualquier clúster de Nexus Kubernetes conectado a la CSN puede aprovisionar el volumen persistente desde este grupo de almacenamiento compartido. Nexus-shared admite los modos de acceso Read Write Once (RWO) y Read Write Many (RWX). Eso significa que las aplicaciones de carga de trabajo pueden usar cualquiera de estos modos de acceso para acceder al almacenamiento compartido.

Aunque el rendimiento y la disponibilidad de nexus-shared son suficientes para la mayoría de las aplicaciones, se recomienda que las cargas de trabajo con requisitos de E/S intensiva usen la opción nexus-volume para lograr un rendimiento óptimo.

Read Write Once (RWO)

En el modo Read Write Once (RWO), el volumen nexus-shared se puede montar mediante un nodo o demandante cada vez. El modo de acceso ReadWriteOnce todavía permite que varios pods accedan al volumen cuando los pods se ejecutan en el mismo nodo.

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

Read Write Many (RWX)

En el modo Read Write Many (RWX), el volumen nexus-shared se puede montar mediante varios nodos o demandantes al mismo tiempo.

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

Ejemplos

Read Write Once (RWO) con la clase de almacenamiento nexus-volume

El manifiesto siguiente crea un objeto StatefulSet con PersistentVolumeClaimTemplate mediante la clase de almacenamiento nexus-volume en modo ReadWriteOnce.

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

Cada pod del objeto StatefulSet tendrá una notificación PersistentVolumeClaim creada.

# 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) con la clase de almacenamiento nexus-shared

El manifiesto siguiente crea una implementación con una notificación PersistentVolumeClaim (PVC) mediante la clase de almacenamiento nexus-shared en modo ReadWriteMany. Todos los pods de la implementación comparten la notificación PVC creada y pueden usarla para leer y escribir de forma simultánea.

---
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
...

Después de aplicarse, habrá tres réplicas de la implementación que comparten la misma notificación PVC.

# 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>

En el resultado siguiente se puede observar que todos los pods escriben en la misma notificación PVC.

# 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

Estado del dispositivo de almacenamiento

Las siguientes propiedades reflejan el estado operativo de un dispositivo de almacenamiento:

Status indica el estado como derivado del dispositivo de almacenamiento. El estado puede ser Available, Error o Provisioning.
Provisioning State proporciona el estado de aprovisionamiento actual del dispositivo de almacenamiento. El estado de aprovisionamiento puede ser Succeeded, Failed o InProgress.
Capacity proporciona la capacidad total y usada del dispositivo de almacenamiento.
Remote Vendor Management indica si la administración de proveedores de carácter remoto está habilitada o deshabilitada para el dispositivo de almacenamiento.

Operaciones del dispositivo de almacenamiento

Enumerar los dispositivos de almacenamiento: enumere los dispositivos de almacenamiento en el grupo de recursos o la suscripción proporcionados.
Mostrar el dispositivo de almacenamiento: obtenga las propiedades del dispositivo de almacenamiento proporcionado.
Actualizar el dispositivo de almacenamiento: actualice las propiedades o etiquetas del dispositivo de almacenamiento proporcionado.
Habilitar/deshabilitar la administración de proveedores de carácter remoto para el dispositivo de almacenamiento: habilite o deshabilite la administración de proveedores de carácter remoto para el dispositivo de almacenamiento proporcionado.

Nota:

Los clientes no pueden crear ni eliminar los dispositivos de almacenamiento directamente. Estos recursos solo se crean como la realización del ciclo de vida del clúster. La implementación bloquea las solicitudes de creación o eliminación de cualquier usuario y solo permite operaciones de creación o eliminación internas o controladas por la aplicación.

Share via