Uso del controlador de Container Storage Interface (CSI) de Azure Files en Azure Kubernetes Service (AKS)

El controlador Container Storage Interface (CSI) de Azure Files es un controlador compatible con la especificación CSI que usa Azure Kubernetes Service (AKS) para administrar el ciclo de vida de los recursos compartidos de Azure Files. CSI es un estándar para exponer sistemas de almacenamiento de archivos y bloques arbitrarios a cargas de trabajo en contenedores en Kubernetes.

Gracias a la adopción y al uso de CSI, AKS ahora puede escribir, implementar e iterar complementos para exponer nuevos sistemas de almacenamiento o mejorar los existentes en Kubernetes. El uso de controladores CSI en AKS evita tener que modificar el código principal de Kubernetes y esperar a su ciclo de versiones.

Para crear un clúster de AKS con compatibilidad con controladores CSI, consulte Controladores de Container Storage Interface (CSI) en Azure Kubernetes Service (AKS).

Nota

Los controladores en árbol hacen referencia a los controladores de almacenamiento actuales que forman parte del código principal de Kubernetes frente a los nuevos controladores CSI, que son complementos.

Nuevas características del controlador CSI de Azure Files

Además de las características originales del controlador en árbol, el controlador CSI de Azure Files admite las siguientes nuevas características:

• Network File System (NFS) versión 4.1
• Punto de conexión privado
• Creación de un montaje de gran tamaño de recursos compartidos de archivos en paralelo.

Uso de un volumen persistente con Azure Files

Un volumen persistente (PV) representa un fragmento de almacenamiento aprovisionado para su uso con pods de Kubernetes. Un PV puede usarse en uno o varios pods y puede aprovisionarse de forma dinámica o estática. Si varios pods necesitan acceso simultáneo al mismo volumen de almacenamiento, puede usar Azure Files para conectarse mediante el protocolo Bloque de mensajes del servidor (SMB) o el protocolo NFS. En este artículo se muestra cómo crear dinámicamente un recurso compartido de Azure Files para que lo usen varios pods en un clúster de AKS. En el caso del aprovisionamiento estático, vea Creación manual y uso de un volumen con un recurso compartido de Azure Files.

Nota:

Tenga en cuenta que el controlador CSI de Azure File solo permite el montaje de recursos compartidos de archivos SMB mediante la autenticación basada en claves (NTLM v2) y, por lo tanto, no admite el perfil de seguridad máximo de la configuración del recurso compartido de archivos de Azure. Por otro lado, el montaje de recursos compartidos de archivos NFS no requiere autenticación basada en claves.

Con recursos compartidos de Azure Files, no hay ningún límite en cuanto a cuántos se pueden montar en un nodo.

Para más información sobre los volúmenes de Kubernetes, consulte Opciones de almacenamiento para aplicaciones en AKS.

Creación dinámica de PV para Azure Files mediante las clases de almacenamiento integradas

Una clase de almacenamiento se utiliza para definir cómo se crea un recurso compartido de archivos de Azure. Se crea automáticamente una cuenta de almacenamiento en el grupo de recursos del nodo para usar con la clase de almacenamiento para mantener el recurso compartido de archivos de Azure. Seleccione una de las siguientes SKU de redundancia de Azure Storage para skuName:

• Standard_LRS: almacenamiento con redundancia local estándar
• Standard_GRS: almacenamiento con redundancia geográfica estándar
• Standard_ZRS: almacenamiento con redundancia de zona
• Standard_RAGRS: almacenamiento con redundancia geográfica con acceso de lectura estándar
• Standard_RAGZRS: almacenamiento estándar con redundancia de zona geográfica con acceso de lectura
• Premium_LRS: almacenamiento con redundancia local prémium
• Premium_ZRS: almacenamiento con redundancia de zona prémium (ZRS)

Nota:

Azure Files es compatible con recursos compartidos de Azure Premium. La capacidad mínima de los recursos compartidos de archivos es de 100 GiB. Se recomienda usar los recursos compartidos de Azure Premium en lugar de los recursos compartidos de Azure Estándar, ya que los recursos compartidos Premium ofrecen un mayor rendimiento y compatibilidad con discos de baja latencia para cargas de trabajo intensivas de E/S.

Cuando se usan controladores CSI de almacenamiento en AKS, hay dos clases StorageClasses integradas adicionales que usan los controladores de almacenamiento CSI de Azure Files. Las otras clases de almacenamiento de CSI se crean con el clúster junto con las clases de almacenamiento predeterminadas en árbol.

• azurefile-csi: utiliza Azure Standard Storage para crear un recurso compartido de archivos de Azure.
• azurefile-csi-premium: utiliza Azure Premium Storage para crear un recurso compartido de archivos de Azure.

La directiva de recuperación en ambas clases de almacenamiento garantiza que el recurso compartido de archivos de Azure subyacente se elimine cuando se elimine el PV respectivo. Las clases de almacenamiento también configuran los recursos compartidos de archivos para que se puedan expandir; solo es necesario editar la notificación de volumen persistente (PVC) con el nuevo tamaño.

Para usar estas clases de almacenamiento, cree una PVC y el pod correspondiente que haga referencia a ellas y las use. Una PVC se usa para aprovisionar automáticamente el almacenamiento en función de una clase de almacenamiento. Una PVC puede usar una de las clases de almacenamiento creadas previamente o una clase de almacenamiento definida por el usuario para crear un recurso compartido de archivos de Azure para la SKU y el tamaño deseado. Cuando se crea una definición de pod, se especifica la PVC para solicitar el almacenamiento deseado.

Cree una PVC y un pod de ejemplo que imprima la fecha actual en un elemento outfile mediante la ejecución de los comandos kubectl apply:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/pvc-azurefile-csi.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/nginx-pod-azurefile.yaml

La salida del comando es similar al ejemplo siguiente:

persistentvolumeclaim/pvc-azurefile created
pod/nginx-azurefile created

Una vez que el pod esté en estado de ejecución, puede comprobar si el recurso compartido de archivos está montado correctamente con la ejecución del siguiente comando y la verificación de que la salida contiene el elemento outfile:

kubectl exec nginx-azurefile -- ls -l /mnt/azurefile

La salida del comando es similar al ejemplo siguiente:

total 29
-rwxrwxrwx 1 root root 29348 Aug 31 21:59 outfile

Creación de una clase de almacenamiento personalizada

Las clases de almacenamiento predeterminadas se adaptan a los escenarios más comunes, pero no a todos. En algunos casos, puede que quiera tener una clase de almacenamiento propia personalizada con sus propios parámetros. Por ejemplo, use el siguiente manifiesto para configurar el parámetro mountOptions del recurso compartido de archivos.

El valor predeterminado de fileMode y dirMode es 0777 para los recurso compartido de archivos montados en Kubernetes. Puede especificar las diferentes opciones de montaje en el objeto de clase de almacenamiento.

Cree un archivo denominado azure-file-sc.yaml y pegue el siguiente manifiesto de ejemplo:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: my-azurefile
provisioner: file.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
  - dir_mode=0640
  - file_mode=0640
  - uid=0
  - gid=0
  - mfsymlinks
  - cache=strict # https://linux.die.net/man/8/mount.cifs
  - nosharesock
parameters:
  skuName: Standard_LRS

Cree la clase de almacenamiento mediante la ejecución del comando kubectl apply:

kubectl apply -f azure-file-sc.yaml

La salida del comando es similar al ejemplo siguiente:

storageclass.storage.k8s.io/my-azurefile created

El controlador de CSI para Azure Files admite la creación de instantáneas de volúmenes persistentes y los recursos compartidos de archivo subyacentes.

Cree una clase de instantánea de volumen con el comando kubectl apply:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/snapshot/volumesnapshotclass-azurefile.yaml

La salida del comando es similar al ejemplo siguiente:

volumesnapshotclass.snapshot.storage.k8s.io/csi-azurefile-vsc created

Cree una instantánea de volumen de la PVC creada dinámicamente al principio de este tutorial, pvc-azurefile.

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/snapshot/volumesnapshot-azurefile.yaml

La salida del comando es similar al ejemplo siguiente:

volumesnapshot.snapshot.storage.k8s.io/azurefile-volume-snapshot created

Para comprobar que la instantánea se haya creado correctamente, ejecute el siguiente comando:

kubectl describe volumesnapshot azurefile-volume-snapshot

La salida del comando es similar al ejemplo siguiente:

Name:         azurefile-volume-snapshot
Namespace:    default
Labels:       <none>
Annotations:  API Version:  snapshot.storage.k8s.io/v1beta1
Kind:         VolumeSnapshot
Metadata:
  Creation Timestamp:  2020-08-27T22:37:41Z
  Finalizers:
    snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
    snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
  Generation:        1
  Resource Version:  955091
  Self Link:         /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/azurefile-volume-snapshot
  UID:               c359a38f-35c1-4fb1-9da9-2c06d35ca0f4
Spec:
  Source:
    Persistent Volume Claim Name:  pvc-azurefile
  Volume Snapshot Class Name:      csi-azurefile-vsc
Status:
  Bound Volume Snapshot Content Name:  snapcontent-c359a38f-35c1-4fb1-9da9-2c06d35ca0f4
  Ready To Use:                        false
Events:                                <none>

Cambio de tamaño de un volumen persistente

Puede solicitar un volumen mayor para una PVC. Edite el objeto PVC y especifique un tamaño mayor. Este cambio desencadena la expansión del volumen subyacente que respalda el PV.

Nota

Nunca se crea un PV para satisfacer la notificación, sino que se cambia el tamaño de un volumen existente.

Actualmente no se admite la reducción de volúmenes persistentes.

En AKS, la clase de almacenamiento azurefile-csi integrada ya permite la expansión, así que use la PVC creada anteriormente con esta clase de almacenamiento. La PVC solicitó un recurso compartido de archivos de 100 GiB. Eso se puede confirmar mediante la ejecución de:

kubectl exec -it nginx-azurefile -- df -h /mnt/azurefile

La salida del comando es similar al ejemplo siguiente:

Filesystem                                                                                Size  Used Avail Use% Mounted on
//f149b5a219bd34caeb07de9.file.core.windows.net/pvc-5e5d9980-da38-492b-8581-17e3cad01770  100G  128K  100G   1% /mnt/azurefile

Expanda la PVC mediante el aumento del campo spec.resources.requests.storage:

kubectl patch pvc pvc-azurefile --type merge --patch '{"spec": {"resources": {"requests": {"storage": "200Gi"}}}}'

La salida del comando es similar al ejemplo siguiente:

persistentvolumeclaim/pvc-azurefile patched

Compruebe que tanto la PVC como el sistema de archivos dentro del pod muestran el nuevo tamaño:

kubectl get pvc pvc-azurefile
NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS    AGE
pvc-azurefile   Bound    pvc-5e5d9980-da38-492b-8581-17e3cad01770   200Gi      RWX            azurefile-csi   64m

kubectl exec -it nginx-azurefile -- df -h /mnt/azurefile
Filesystem                                                                                Size  Used Avail Use% Mounted on
//f149b5a219bd34caeb07de9.file.core.windows.net/pvc-5e5d9980-da38-492b-8581-17e3cad01770  200G  128K  200G   1% /mnt/azurefile

Uso de un volumen persistente con almacenamiento privado de Azure Files (punto de conexión privado)

Si los recursos de Azure Files están protegidos con un punto de conexión privado, tendrá que crear una clase de almacenamiento. Asegúrese de que ha configurado la configuración de DNS para resolver la dirección IP del punto de conexión privado en el FQDN de la cadena de conexión. Personalice estos parámetros:

• resourceGroup: grupo de recursos donde se implementa la cuenta de almacenamiento.
• storageAccount: nombre de la cuenta de almacenamiento.
• server: FQDN del punto de conexión privado de la cuenta de almacenamiento.

Cree el archivo private-azure-file-sc.yaml y pegue el siguiente manifiesto de ejemplo en él. Reemplace los valores de <resourceGroup> y <storageAccountName>.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: private-azurefile-csi
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  resourceGroup: <resourceGroup>
  storageAccount: <storageAccountName>
  server: <storageAccountName>.file.core.windows.net
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - uid=0
  - gid=0
  - mfsymlinks
  - cache=strict  # https://linux.die.net/man/8/mount.cifs
  - nosharesock  # reduce probability of reconnect race
  - actimeo=30  # reduce latency for metadata-heavy workload

Cree la clase de almacenamiento con el comando kubectl apply:

kubectl apply -f private-azure-file-sc.yaml

La salida del comando es similar al ejemplo siguiente:

storageclass.storage.k8s.io/private-azurefile-csi created

Cree el archivo private-pvc.yaml y pegue el siguiente manifiesto de ejemplo en él:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: private-azurefile-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: private-azurefile-csi
  resources:
    requests:
      storage: 100Gi

Cree la instancia de PVC con el comando kubectl apply:

kubectl apply -f private-pvc.yaml

Recursos compartidos de archivos NFS

Azure Files admite el protocolo NFS v4.1. La compatibilidad con la versión 4.1 de NFS para Azure Files proporciona un sistema de archivos NFS totalmente administrado como un servicio basado en una plataforma de almacenamiento resistente distribuida de alta disponibilidad y alta durabilidad.

Esta opción está optimizada para cargas de trabajo de acceso aleatorio con actualizaciones de datos en contexto y proporciona compatibilidad completa con el sistema de archivos POSIX. En esta sección se muestra cómo usar recursos compartidos de archivos NFS con el controlador CSI de Azure Files en un clúster de AKS.

Prerrequisitos

• La identidad del plano de control del clúster de AKS (es decir, el nombre del clúster de AKS) se agrega al rol Colaborador en la red virtual y NetworkSecurityGroup.
• Se deben agregar la identidad de servicio administrada o la entidad de servicio del clúster de AKS al rol de Colaborador en la cuenta de almacenamiento.

Nota

Puede usar un punto de conexión privado, en lugar de permitir el acceso a la red virtual seleccionada.

Optimización de las opciones de tamaño de lectura y escritura

En esta sección se proporciona información sobre cómo abordar el ajuste del rendimiento NFS con el controlador CSI de Azure Files con las opciones rsize y wsize. Las opciones rsize y wsize establecen el tamaño máximo de transferencia de una operación NFS. Si rsize o wsize no se especifican en el montaje, el cliente y el servidor negocian el mayor tamaño que admiten ambos. Actualmente, tanto Azure NetApp Files como las distribuciones modernas de Linux admiten tamaños de lectura y escritura de hasta 1 048 576 bytes (1 MiB).

El rendimiento óptimo se basa en una comunicación eficaz entre cliente y servidor. Aumentar o disminuir los valores de tamaño de opción de lectura y escritura de montaje puede mejorar el rendimiento de NFS. El tamaño predeterminado de los paquetes de lectura y escritura transferidos entre el cliente y el servidor es de 8 KB para NFS versión 2 y 32 KB para NFS versión 3 y 4. Estos valores predeterminados pueden ser demasiado grandes o demasiado pequeños. Reducir el tamaño de rsize y wsize podría mejorar el rendimiento de NFS en una red congestionada mediante el envío de paquetes más pequeños para cada solicitud de respuesta y escritura de lectura de NFS. Sin embargo, esto puede aumentar el número de paquetes necesarios para enviar datos a través de la red, lo que aumenta el tráfico total de red y el uso de CPU en el cliente y el servidor.

Es importante que realice pruebas para buscar un tamaño de rsize y wsize que mantenga la transferencia de paquetes eficiente, donde no disminuye el rendimiento y aumenta la latencia.

Para obtener más información sobre cómo optimizar rsize y wsize, consulte Procedimientos recomendados de opciones de montaje NFS de Linux para Azure NetApp Files.

Por ejemplo, para configurar un tamaño máximo de rsize y wsize de 256 KiB, configure mountOptions en la clase de almacenamiento de la siguiente manera:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-nfs
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  protocol: nfs
mountOptions:
  - nconnect=4
  - noresvport
  - actimeo=30
  - rsize=262144
  - wsize=262144

Creación de una clase de almacenamiento de recursos compartidos de archivos NFS

Cree un archivo llamado nfs-sc.yaml y copie el siguiente manifiesto. Para obtener una lista de mountOptions compatibles, consulte Opciones de montaje de NFS.

Nota:

vers, minorversion, sec están configurados por el controlador CSI de archivo de Azure. No se admite especificar un valor en el manifiesto para estas propiedades.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-nfs
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  protocol: nfs
mountOptions:
  - nconnect=4
  - noresvport
  - actimeo=30

Después de editar y guardar el archivo, cree la clase de almacenamiento con el comando kubectl apply:

kubectl apply -f nfs-sc.yaml

La salida del comando es similar al ejemplo siguiente:

storageclass.storage.k8s.io/azurefile-csi-nfs created

Creación de una implementación con un recurso compartido de archivos con copia de seguridad NFS

Puede implementar un conjunto con estado de ejemplo que guarde marcas de tiempo en el archivo data.txt con el comando kubectl apply:

kubectl apply -f

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: statefulset-azurefile
  labels:
    app: nginx
spec:
  podManagementPolicy: Parallel  # default is OrderedReady
  serviceName: statefulset-azurefile
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      nodeSelector:
        "kubernetes.io/os": linux
      containers:
        - name: statefulset-azurefile
          image: mcr.microsoft.com/oss/nginx/nginx:1.19.5
          command:
            - "/bin/bash"
            - "-c"
            - set -euo pipefail; while true; do echo $(date) >> /mnt/azurefile/outfile; sleep 1; done
          volumeMounts:
            - name: persistent-storage
              mountPath: /mnt/azurefile
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: nginx
  volumeClaimTemplates:
    - metadata:
        name: persistent-storage
      spec:
        storageClassName: azurefile-csi-nfs
        accessModes: ["ReadWriteMany"]
        resources:
          requests:
            storage: 100Gi

La salida del comando es similar al ejemplo siguiente:

statefulset.apps/statefulset-azurefile created

Para validar el contenido del volumen, ejecute el siguiente comando:

kubectl exec -it statefulset-azurefile-0 -- df -h

La salida del comando es similar al ejemplo siguiente:

Filesystem      Size  Used Avail Use% Mounted on
...
/dev/sda1                                                                                 29G   11G   19G  37% /etc/hosts
accountname.file.core.windows.net:/accountname/pvc-fa72ec43-ae64-42e4-a8a2-556606f5da38  100G     0  100G   0% /mnt/azurefile
...

Nota

Tenga en cuenta que, al estar en una cuenta Premium, el tamaño mínimo del recurso compartido de archivos NFS es 100 GiB. Si crea una PVC con un tamaño de almacenamiento pequeño, puede que reciba un error similar al siguiente: No se pudo crear el recurso compartido de archivos… tamaño (5)….

Contenedores de Windows

El controlador de CSI para Azure Files también admite nodos y contenedores de Windows. Para usar contenedores Windows, siga el inicio rápido sobre contenedores Windows para agregar un grupo de nodos con Windows.

Una vez que tenga un grupo de nodos con Windows, utilice las clases de almacenamiento integradas, como azurefile-csi, o cree una personalizada. Puede implementar un conjunto con estado basado en Windows de ejemplo que guarde marcas de tiempo en el archivo data.txt mediante la ejecución del comando kubectl apply:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/windows/statefulset.yaml

La salida del comando es similar al ejemplo siguiente:

statefulset.apps/busybox-azurefile created

Para validar el contenido del volumen, ejecute el siguiente comando kubectl exec:

kubectl exec -it busybox-azurefile-0 -- cat c:\\mnt\\azurefile\\data.txt # on Linux/MacOS Bash
kubectl exec -it busybox-azurefile-0 -- cat c:\mnt\azurefile\data.txt # on Windows Powershell/CMD

La salida de los comandos es similar al ejemplo siguiente:

2020-08-27 22:11:01Z
2020-08-27 22:11:02Z
2020-08-27 22:11:04Z
(...)

Pasos siguientes

• Para obtener información sobre cómo usar un controlador CSI para discos de Azure, vea Uso de discos de Azure con controladores CSI.
• Para obtener información sobre cómo usar el controlador CSI para Azure Blob Storage, consulte Uso de Azure Blob Storage con controladores CSI.
• Para más información sobre los procedimientos recomendados, consulte Procedimientos recomendados para el almacenamiento y las copias de seguridad en Azure Kubernetes Service.