Uso de clases de almacenamiento personalizadas en AKS para consumir almacenamiento externo (SAN) en Azure Local

Overview

En este documento se proporcionan instrucciones paso a paso para configurar un clúster de AKS en Azure Local para consumir recursos externos de red de área de almacenamiento (SAN) a través de clases de almacenamiento de Kubernetes personalizadas y volúmenes persistentes. El mecanismo subyacente es la interfaz de almacenamiento de contenedores (CSI), que permite que Kubernetes interactúe con una amplia gama de back-ends de almacenamiento de forma estandarizada. Al definir una clase StorageClass personalizada que se asigna al aprovisionamiento de SAN, las cargas de trabajo pueden solicitar y enlazar dinámicamente el almacenamiento persistente sin intervención manual del administrador para cada volumen.

Prerequisites

• Un clúster local de Azure implementado y registrado en Azure.
• CLI de Azure instalada con las extensiones aksarc y connectedk8s.
• Una ubicación personalizada configurada para el clúster local de Azure.
• Una red lógica (vnet) creada para el clúster de AKS.
• Un grupo de Microsoft Entra con acceso de administrador de clústeres.
• Acceso al almacenamiento SAN externo (por ejemplo, NetApp, Pure Storage, Hitachi) aprovisionado y accesible desde los nodos del clúster local de Azure.
• kubectl instalado localmente.

Paso 1: Creación de un clúster de AKS

Opción A: Azure Portal

• Vaya al clúster local de Azure en Azure Portal.
• En el menú izquierdo, haga clic en Recursos → clústeres de Kubernetes.
• Haga clic en Crear clúster de Kubernetes.
• Especifique un nombre de clúster, seleccione la ubicación personalizada del clúster local de Azure y rellene los campos restantes.
• Avanza con el asistente y haz clic en Crear.

Opción B: CLI de Azure

Instale las extensiones necesarias de la CLI de Azure antes de ejecutar el comando siguiente. Inicie sesión en Azure y establezca la suscripción de destino y, a continuación, ejecute:

az aksarc create \
  -n $aksclustername \
  -g $resource_group \
  --custom-location $customlocationID \
  --vnet-ids $logicnetId \
  --aad-admin-group-object-ids $aadgroupID \
  --generate-ssh-keys

Paso 2: Conexión al clúster de Kubernetes

Conéctese al clúster recién creado ejecutando el comando az connectedk8s proxy en una ventana de terminal. Esto establece un proxy local en el clúster conectado a Arc. A continuación, abra una nueva ventana de PowerShell que apunte a la misma carpeta de trabajo.

Para todos los comandos kubectl posteriores que operan en el clúster, es posible que tenga que especificar explícitamente el archivo de configuración de Kubernetes anexando la marca siguiente:

--kubeconfig .\aks-arc-kube-config

Paso 3: Crear una clase de almacenamiento personalizada para discos

Una clase StorageClass personalizada es cómo Kubernetes asigna una solicitud de almacenamiento a un tipo de disco con respaldo SAN específico disponible en Azure Local. La definición de StorageClass especifica el aprovisionador de CSI, la política de recuperación, el modo de enlace y cualquier parámetro específico de SAN necesario para el controlador CSI del proveedor de almacenamiento.

Siga la documentación de Microsoft Learn para crear una clase de almacenamiento personalizada para discos: Uso de controladores de disco de la interfaz de almacenamiento de contenedores (CSI) en AKS habilitados por Azure Arc: AKS habilitado por Azure Arc | Microsoft Learn

Como alternativa, use Azure Portal: vaya a la página del clúster de AKS y haga clic en Recursos de Kubernetes → Storage. En esta página puede crear y administrar clases de almacenamiento, reclamaciones de volúmenes persistentes y volúmenes persistentes.

Paso 4: Crear una Reclamación de Volumen Persistente (PVC)

Una vez que se haya creado el StorageClass, defina una solicitud de volumen persistente (PVC) para solicitar un volumen persistente vinculado a su recurso de almacenamiento SAN. En el ejemplo siguiente se solicita un volumen de 1 GiB mediante la clase de almacenamiento personalizada:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: aks-hci-vhdx
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: <your custom storage class name>
  resources:
    requests:
      storage: 1Gi

Paso 5: Usar el Volumen Persistente en un Pod

Haga referencia al PVC en la definición del pod mediante volumeMount. En el ejemplo siguiente se implementa un contenedor nginx que monta el volumen respaldado por SAN en /mnt/aks-hci, donde la aplicación puede leer y escribir datos:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      volumeMounts:
      - mountPath: "/mnt/aks-hci"
        name: volume
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: aks-hci-vhdx

Paso 6: Implementar una aplicación de ejemplo con volúmenes persistentes

El siguiente manifiesto completo implementa la aplicación Azure Vote, que consta de un back-end de Redis y un front-end web. Ambos componentes montan volúmenes persistentes respaldados por SAN, lo que muestra la integración de un extremo a otro con almacenamiento externo en Azure Local.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: azure-vote-back
spec:
  replicas: 1
  selector:
    matchLabels:
      app: azure-vote-back
  template:
    metadata:
      labels:
        app: azure-vote-back
    spec:
      nodeSelector:
        "kubernetes.io/os": linux
      containers:
      - name: azure-vote-back
        image: mcr.microsoft.com/oss/bitnami/redis:6.0.8
        env:
        - name: ALLOW_EMPTY_PASSWORD
          value: "yes"
        ports:
        - containerPort: 6379
          name: redis
        volumeMounts:
        - mountPath: "/mnt/aks-hci"
          name: volume1
      volumes:
        - name: volume1
          persistentVolumeClaim:
            claimName: aks-hci-vhdx-1
---
apiVersion: v1
kind: Service
metadata:
  name: azure-vote-back
spec:
  ports:
  - port: 6379
  selector:
    app: azure-vote-back
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: azure-vote-front
spec:
  replicas: 1
  selector:
    matchLabels:
      app: azure-vote-front
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: azure-vote-front
    spec:
      nodeSelector:
        "kubernetes.io/os": linux
      containers:
      - name: azure-vote-front
        image: lgmorand/azure-vote-front:v1
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
          limits:
            cpu: 500m
        env:
        - name: REDIS
          value: "azure-vote-back"
        volumeMounts:
        - mountPath: "/mnt/aks-hci"
          name: volume2
      volumes:
        - name: volume2
          persistentVolumeClaim:
            claimName: aks-hci-vhdx-2
---
apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front