Creación y administración de volúmenes persistentes con Azure Files en Azure Kubernetes Service (AKS)

Si varios pods necesitan acceso simultáneo al mismo volumen de almacenamiento, puede usar Azure Files para conectarse mediante el bloque de mensajes del servidor (SMB) o el protocolo NFS. En este artículo se muestra cómo crear de forma dinámica y estática un recurso compartido de Azure Files para su uso por varios pods en un clúster de Azure Kubernetes Service (AKS) mediante Azure Files.

Prerrequisitos

• La CLI de Azure, versión 2.0.59 o posterior, instalada y configurada. Busque la versión con el comando az --version. Para la instalación o la actualización, consulte Instalación de la CLI de Azure.
• El controlador CSI de Azure Files está habilitado en el clúster de AKS.
• Una cuenta de Almacenamiento de Azure.
• Al elegir entre recursos compartidos de archivos Estándar y Premium, es importante que comprenda el modelo de aprovisionamiento y los requisitos del patrón de uso esperado que planea ejecutar en Azure Files. Para más información, consulte Elección de un nivel de rendimiento de Azure Files en función de los patrones de uso.

Uso de clases de almacenamiento integradas para crear PVs dinámicos con Azure Files

Las clases de almacenamiento se usan para definir cómo se crea dinámicamente una unidad de almacenamiento con un volumen persistente. En el grupo de recursos node, se crea automáticamente una cuenta de almacenamiento para utilizarla con la clase de almacenamiento donde van a guardarse los recursos compartidos de archivos de Azure Files. Cuando se usan controladores CSI en AKS, hay dos componentes adicionales integrados StorageClasses que usan los controladores de almacenamiento CSI de Azure Files (las otras clases de almacenamiento 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 política de recuperación en ambas clases de almacenamiento garantiza que el recurso compartido de archivos subyacente de Azure Files se elimine cuando se elimine el Volumen Persistente (PV) correspondiente. 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.

Puede seleccionar una de las siguientes SKU de redundancia de almacenamiento de Azure para el parámetro skuname en la definición de clase de almacenamiento:

• Standard_LRS: almacenamiento con redundancia local estándar
• Standard_GRS: almacenamiento con redundancia geográfica estándar
• Standard_ZRS: almacenamiento con redundancia de zona estándar
• Standard_RAGRS: almacenamiento con redundancia geográfica con acceso de lectura estándar
• Standard_RAGZRS: almacenamiento estándar con redundancia de zona geográfica y acceso de lectura
• Premium_LRS: almacenamiento con redundancia local Premium
• Premium_ZRS: almacenamiento con redundancia de zona Premium

Creación de clases de almacenamiento personalizadas para máquinas virtuales dinámicas con Azure Files

Las clases de almacenamiento predeterminadas son adecuadas para la mayoría de los escenarios. En algunos casos, es posible que quiera tener su propia clase de almacenamiento personalizada con sus propios parámetros. Por ejemplo, es posible que desee configurar mountOptions del recurso compartido de archivos.

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

2. Cree la clase de almacenamiento mediante el kubectl apply comando :

   kubectl apply -f azure-file-sc.yaml
   

   La salida debería ser similar a la salida de ejemplo siguiente:

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

Parámetros de clase de almacenamiento para PVs dinámicos con Azure Files

En la tabla siguiente se incluyen parámetros que puede usar para definir una clase de almacenamiento personalizada para las solicitudes de volumen persistente (PVC) con Azure Files.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  skuName: Premium_LRS  # available values: Premium_LRS, Premium_ZRS, Standard_LRS, Standard_GRS, Standard_ZRS, Standard_RAGRS, Standard_RAGZRS
  networkEndpointType: privateEndpoint
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
  - dir_mode=0777  # modify this permission if you want to enhance the security
  - file_mode=0777
  - 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
  - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks

Crear un PVC con Azure Files

Una PVC utiliza el objeto de clase de almacenamiento para aprovisionar dinámicamente una compartición de archivos en Azure. Puede usar el manifiesto YAML de ejemplo de esta sección para crear una PVC con un tamaño de 100 GB y acceso ReadWriteMany. Para más información sobre los modos de acceso, consulte Modos de acceso PV de Kubernetes.

1. Cree un archivo denominado Azure-file-pvc.yaml y pegue el siguiente código YAML. Asegúrese de que storageClassName coincide con el nombre de la clase de almacenamiento existente.

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

   Nota:

   Si usa el SKU Premium_LRS para la clase de almacenamiento, el valor mínimo de storage debe ser 100Gi.

2. Cree el PVC mediante el comando kubectl apply.

   kubectl apply -f azure-file-pvc.yaml
   

3. Vea el estado de la PVC mediante el comando kubectl get:

   kubectl get pvc my-azurefile
   

   La salida debe ser similar al ejemplo de salida siguiente, que muestra que la PVC está en un estado Bound y que un PV se creó dinámicamente para satisfacer la solicitud.

   NAME           STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
   my-azurefile   Bound     pvc-aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb   100Gi       RWX            my-azurefile      5m
   

Uso de una PVC con Azure Files en un pod

El manifiesto YAML de ejemplo de esta sección crea un pod que usa la PVC my-Azurefile para montar el recurso compartido de archivos de Azure Files en la ruta /mnt/Azure. Para los contenedores de Windows Server, especifique un elemento mountPath con la convención de ruta de acceso de Windows, como "D:" .

1. Cree un archivo denominado Azure-pvc-files.yamly pegue el siguiente código YAML. Asegúrese de que claimName coincida con el nombre de su PVC existente.

   kind: Pod
   apiVersion: v1
   metadata:
     name: mypod
   spec:
     containers:
       - name: mypod
         image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
         resources:
           requests:
             cpu: 100m
             memory: 128Mi
           limits:
             cpu: 250m
             memory: 256Mi
         volumeMounts:
           - mountPath: /mnt/azure
             name: volume
             readOnly: false
     volumes:
      - name: volume
        persistentVolumeClaim:
          claimName: my-azurefile
   

2. Cree el pod mediante el comando kubectl apply.

   kubectl apply -f azure-pvc-files.yaml
   

3. Vea el estado del pod mediante el kubectl describe comando :

   kubectl describe pod mypod
   

   La salida debe ser similar al siguiente ejemplo, que muestra que el pod se está ejecutando y que el volumen se monta en la ruta correcta.

   Containers:
     mypod:
       Container ID:   docker://BB22CC33DD44EE55FF66AA77BB88CC99DD00EE11
       Image:          mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
       Image ID:       docker-pullable://nginx@sha256:AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00
       State:          Running
         Started:      Fri, 01 Mar 2019 23:56:16 +0000
       Ready:          True
       Mounts:
         /mnt/azure from volume (rw)
         /var/run/secrets/kubernetes.io/serviceaccount from default-token-8rv4z (ro)
   [...]
   Volumes:
     volume:
       Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
       ClaimName:  my-azurefile
       ReadOnly:   false
   [...]
   

Opciones de montaje para Azure Files

La ubicación para configurar las opciones de montaje (mountOptions) depende de si está aprovisionando volúmenes persistentes dinámicos o estáticos:

• Si va a aprovisionar dinámicamente un volumen con una clase de almacenamiento, especifique las opciones de montaje en el objeto de clase de almacenamiento (tipo: StorageClass).
• Si está aprovisionando estáticamente un volumen, especifique las opciones de montaje en el objeto PV (tipo: PersistentVolume).
• Si va a montar el recurso compartido de archivos como un volumen insertado, especifique las opciones de montaje en el objeto Pod (tipo: Pod).

Para obtener más información, vea Opciones de montaje.

El valor predeterminado de fileMode y dirMode es 0777 para las versiones 1.13.0 y posteriores de Kubernetes. En el ejemplo siguiente se establece 0777:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: my-azurefile
provisioner: file.csi.azure.com # replace with "kubernetes.io/azure-file" if aks version is less than 1.21
allowVolumeExpansion: true
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - uid=0
  - gid=0
  - mfsymlinks
  - cache=strict
  - actimeo=30
  - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks
parameters:
  skuName: Premium_LRS

Opciones de montaje recomendadas para recursos compartidos SMB

Las opciones de montaje recomendadas para recursos compartidos SMB se proporcionan en el siguiente ejemplo de clase de almacenamiento:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: azurefile-csi
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
    skuName: Premium_LRS  # available values: Premium_LRS, Premium_ZRS, Standard_LRS, Standard_GRS, Standard_ZRS, Standard_RAGRS, Standard_RAGZRS
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
    - dir_mode=0777  # modify this permission if you want to enhance the security
    - file_mode=0777 # modify this permission if you want to enhance the security
    - mfsymlinks    # support symbolic links
    - cache=strict  # https://linux.die.net/man/8/mount.cifs
    - nosharesock  # reduces probability of reconnect race
    - actimeo=30  # reduces latency for metadata-heavy workload
    - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks

Si está utilizando comparticiones de archivos Premium (SSD) y su carga de trabajo tiene muchos metadatos, debe registrarse para usar la característica de almacenamiento en caché de metadatos para mejorar el rendimiento.

Para más información, consulte cómo mejorar el rendimiento de los recursos compartidos de archivos de Azure SMB.

Opciones de montaje recomendadas para recursos compartidos NFS

Las opciones de montaje recomendadas para recursos compartidos NFS se proporcionan en el siguiente ejemplo de clase de almacenamiento:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: azurefile-csi-nfs
provisioner: file.csi.azure.com
parameters:
    protocol: nfs
    skuName: Premium_LRS     # available values: Premium_LRS, Premium_ZRS
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
    - nconnect=4  # improves performance by enabling multiple connections to share
    - noresvport  # improves availability
    - actimeo=30  # reduces latency for metadata-heavy workloads

Aumente el tamaño de prelectura para mejorar el rendimiento de lectura.

Aunque Azure Files admite la configuración de nconnect hasta el valor máximo de 16, se recomienda configurar las opciones de montaje con el valor óptimo de nconnect=4. Actualmente, no se obtienen beneficios que superen cuatro canales en la implementación de nconnect de Azure Files.

Creación de una instantánea de volumen a partir de una PVC con Azure Files

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.

1. 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 debería ser similar a la salida de ejemplo siguiente:

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

2. Cree una instantánea de volumen a partir de la PVC dinámica que creó anteriormente en este tutorial mediante el comando kubectl apply:

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

   La salida debería ser similar a la salida de ejemplo siguiente:

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

3. Vea el estado de la instantánea de volumen con el comando kubectl describe.

   kubectl describe volumesnapshot azurefile-volume-snapshot
   

   La salida debe ser similar a la siguiente salida de ejemplo, que muestra que la instantánea de volumen no está lista para usarse porque el controlador sigue creando la instantánea del recurso compartido de archivos de Azure subyacente:

   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:               00aa00aa-bb11-cc22-dd33-44ee44ee44ee
   Spec:
     Source:
       Persistent Volume Claim Name:  pvc-azurefile
     Volume Snapshot Class Name:      csi-azurefile-vsc
   Status:
     Bound Volume Snapshot Content Name:  snapcontent-00aa00aa-bb11-cc22-dd33-44ee44ee44ee
     Ready To Use:                        false
   Events:                                <none>
   

Cambio de tamaño de un volumen persistente con Azure Files

Puede solicitar un volumen mayor para una PVC editando el objeto de la PVC para especificar un tamaño mayor. Este cambio desencadena la expansión del volumen subyacente que respalda el PV. Nunca se crea un PV para satisfacer la notificación, sino que se cambia el tamaño de un volumen existente.

En AKS, la clase de almacenamiento integrada managed-csi ya admite la expansión, por lo que puede utilizar el PVC dinámico que creó anteriormente en este tutorial. La PVC solicitó un recurso compartido de archivos de 100 GiB.

1. Compruebe el tamaño actual de la PVC y el sistema de archivos dentro del pod mediante el comando kubectl exec para ejecutar el comando df -h dentro del pod:

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

   La salida debe ser similar a la siguiente salida de ejemplo, que muestra que el sistema de archivos tiene un tamaño de 100 GB:

   Filesystem                                                                                      Size  Used Avail Use% Mounted on
   //a123b4c567de89fghi01jk2.file.core.windows.net/pvc-00aa00aa-bb11-cc22-dd33-44ee44ee44ee  100G  128K  100G   1% /mnt/azurefile
   

2. Expanda la PVC aumentando el campo spec.resources.requests.storage mediante el comando kubectl patch. En este ejemplo, aumentamos la compartición de archivos a 200 GiB.

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

   La salida debe ser similar al siguiente ejemplo de salida, que muestra que el PVC se ha parcheado correctamente.

   persistentvolumeclaim/pvc-azurefile patched
   

3. Compruebe que la PVC se ha cambiado correctamente de tamaño y que el nuevo tamaño se refleja en el pod mediante los comandos kubectl get pvc y df -h dentro del pod.

   kubectl get pvc pvc-azurefile
   

   La salida debe ser similar al siguiente ejemplo, que muestra que el PVC sigue en el estado Bound y que la capacidad se actualizó a 200 GiB.

   NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS    AGE
   pvc-azurefile   Bound    pvc-00aa00aa-bb11-cc22-dd33-44ee44ee44ee   200Gi      RWX            azurefile-csi   64m
   

4. Compruebe el nuevo tamaño del sistema de archivos dentro del pod mediante el kubectl exec comando para ejecutar el df -h comando dentro del pod:

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

   La salida debe ser similar a la siguiente salida de ejemplo, que muestra que el sistema de archivos tiene ahora un tamaño de 200 GB:

   Filesystem                                                                                Size  Used Avail Use% Mounted on
   //a123b4c567de89fghi01jk2.file.core.windows.net/pvc-bbbbbbbb-1111-2222-3333-cccccccccccc  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. Al crear la clase de almacenamiento mediante el controlador CSI de Azure Files, debe especificar el parámetro networkEndpointType con el valor privateEndpoint y proporcionar los parámetros siguientes:

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

1. Cree un archivo denominado private-Azure-file-sc.yaml y pegue el siguiente manifiesto. Asegúrese de reemplazar los marcadores de posición 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
   

2. Cree la clase de almacenamiento mediante el kubectl apply comando :

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

   La salida debería ser similar a la salida de ejemplo siguiente:

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

3. Cree un archivo denominado private-pvc.yaml y pegue el siguiente manifiesto. Asegúrese de que storageClassName coincide con el nombre de la clase de almacenamiento existente.

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

4. Cree el PVC mediante el comando kubectl apply.

   kubectl apply -f private-pvc.yaml
   

Uso de Azure Files con 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. Después de tener un grupo de nodos de Windows, puede usar las clases de almacenamiento integradas como azurefile-csi o crear una personalizada. El StatefulSet basado en Windows de ejemplo de esta sección guarda las marcas de tiempo en un archivo data.txt cada segundo, que se monta en un recurso compartido de archivos de Azure mediante el controlador CSI de Azure Files.

1. Cree el conjunto con estado mediante el kubectl apply comando :

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

   La salida debería ser similar a la salida de ejemplo siguiente:

   statefulset.apps/busybox-azurefile created
   

2. Verifique que las marcas de tiempo se están escribiendo en el recurso compartido de archivos utilizando los siguientes comandos kubectl exec para ejecutar el comando cat dentro del pod:

   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 debería parecerse al siguiente ejemplo, que muestra que las marcas de tiempo se están escribiendo en la carpeta compartida cada segundo:

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

Uso del protocolo NFS con Azure Files

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.

Requisitos previos para usar recursos compartidos NFS con Azure Files

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

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 rsize opciones 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, las distribuciones modernas de Azure Files y Linux admiten tamaños de lectura y escritura de hasta 1048 576 bytes (1 MiB).

El rendimiento óptimo se basa en una comunicación eficaz entre cliente y servidor. Aumentar o reducir los valores de tamaño de las opciones de lectura y escritura de mount 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 rsize y el wsize podría mejorar el rendimiento de NFS en una red congestionada mediante el envío de paquetes más pequeños para cada respuesta de lectura NFS y solicitud de escritura. 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 encontrar un rsize y un wsize que mantengan una transferencia de paquetes eficaz, no reduzcan el rendimiento ni aumenten la latencia.

El manifiesto de ejemplo siguiente configura la mountOptions sección de una clase de almacenamiento en un máximo rsize y wsize de 256 KiB:

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

Para obtener una lista de mountOptions compatibles, consulte Opciones de montaje de NFS.

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

1. Cree un archivo denominado nfs-sc.yaml y pegue el siguiente manifiesto. Asegúrese de especificar protocol: nfs en la sección de parámetros y ajuste mountOptions según sea necesario para la carga de trabajo.

   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
   

2. Después de editar y guardar el archivo, cree la clase de almacenamiento mediante el kubectl apply comando .

   kubectl apply -f nfs-sc.yaml
   

   La salida debería ser similar a la salida de ejemplo siguiente:

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

Creación de un StatefulSet con un recurso compartido de archivos respaldado por NFS

1. Cree un archivo denominado nfs-ss.yaml y pegue el siguiente manifiesto. Esta configuración guarda las marcas de tiempo en un archivo data.txt.

   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
   

2. Cree el conjunto con estado mediante el kubectl apply comando .

   kubectl apply -f nfs-ss.yaml
   

   La salida debería ser similar a la salida de ejemplo siguiente:

   statefulset.apps/statefulset-azurefile created
   

3. Valide el contenido del volumen usando el siguiente comando kubectl exec para ejecutar el comando df -h dentro del pod:

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

   La salida debe parecerse al siguiente ejemplo, que muestra que el recurso compartido de archivos NFS se monta en la ruta correcta con el tamaño correcto.

   Filesystem      Size  Used Avail Use% Mounted on
   ...
   /dev/sda1                                                                                 29G   11G   19G  37% /etc/hosts
   accountname.file.core.windows.net:/accountname/pvc-cccccccc-2222-3333-4444-dddddddddddd  100G     0  100G   0% /mnt/azurefile
   ...
   

   Dado que el recurso compartido de archivos NFS está en una cuenta de almacenamiento Premium, el tamaño mínimo del recurso compartido de archivos es de 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)….

Cifrado en tránsito (EiT) para recursos compartidos de archivos NFS (versión preliminar)

El cifrado en tránsito (EiT) garantiza que todas las lecturas y escrituras en los recursos compartidos de archivos NFS dentro de la red virtual estén cifradas, lo que proporciona una capa adicional de seguridad.

Al establecer encryptInTransit: "true" en los parámetros de clase de almacenamiento, puede habilitar el cifrado de datos en tránsito para recursos compartidos de archivos de Azure NFS. Por ejemplo:

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

Uso de la identidad administrada para acceder al almacenamiento de Azure Files (versión preliminar)

Azure Files ahora admite la autenticación basada en identidad administrada para el acceso SMB. Esto permite que las aplicaciones accedan de forma segura a Azure Files sin almacenar ni administrar credenciales.

Requisitos previos para usar la identidad administrada para acceder al almacenamiento de Azure Files

• Asegúrese de que la identidad de Kubelet asignada por el usuario tenga el rol Storage File Data SMB MI Admin en la cuenta de almacenamiento.
  • Si usa su propia cuenta de almacenamiento, debe asignar un rol Storage File Data SMB MI Admin a la identidad de Kubelet asignada por el usuario en esa cuenta de almacenamiento.
  • Si el controlador CSI crea la cuenta de almacenamiento, conceda Storage File Data SMB MI Admin el rol al grupo de recursos donde reside la cuenta de almacenamiento.
  • Si simplemente utiliza la identidad de Kubelet predeterminada integrada asignada por el usuario, ya tiene el rol necesario Storage File Data SMB MI Admin en el grupo de recursos de nodo administrado.

Habilitación de la identidad administrada para PVs dinámicos con Azure Files

Para habilitar la identidad administrada para volúmenes aprovisionados dinámicamente, debe crear una nueva clase de almacenamiento con mountWithManagedIdentity: "true" e implementar el conjunto con estado mediante esta clase de almacenamiento.

El manifiesto de ejemplo siguiente configura una clase de almacenamiento para usar la identidad administrada para acceder a Azure Files:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: azurefile-csi
provisioner: file.csi.azure.com
parameters:
   resourceGroup: EXISTING_RESOURCE_GROUP_NAME   # optional, node resource group by default if it's not provided
   storageAccount: EXISTING_STORAGE_ACCOUNT_NAME # optional, a new account will be created if it's not provided
   mountWithManagedIdentity: "true"
   # optional, clientID of the managed identity, kubelet identity would be used by default if it's not provided
   clientID: "xxxxx-xxxx-xxx-xxx-xxxxxxx"
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
   - dir_mode=0777  # modify this permission if you want to enhance the security
   - 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
   - nobrl  # disable sending byte range lock requests to the server

Habilitación de la identidad administrada para PV estáticos con Azure Files

Para habilitar la identidad administrada para volúmenes estáticos, debe crear un PV con mountWithManagedIdentity: "true" y montar el PV en el pod de su aplicación.

El manifiesto de ejemplo siguiente configura un PV para usar la identidad administrada para acceder a Azure Files:

apiVersion: v1
kind: PersistentVolume
metadata:
   name: pv-azurefile
spec:
   capacity:
   storage: 100Gi
   accessModes:
   - ReadWriteMany
   persistentVolumeReclaimPolicy: Retain
   storageClassName: azurefile-csi
   mountOptions:
   - dir_mode=0777  # modify this permission if you want to enhance the security
   - 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
   - nobrl  # disable sending byte range lock requests to the server
   csi:
   driver: file.csi.azure.com
   # make sure volumeHandle is unique for every identical share in the cluster
   volumeHandle: "{resource-group-name}#{account-name}#{file-share-name}"
   volumeAttributes:
       resourceGroup: EXISTING_RESOURCE_GROUP_NAME   # optional, node resource group by default if it's not provided
       storageAccount: EXISTING_STORAGE_ACCOUNT_NAME # optional, a new account will be created if it's not provided
       shareName: EXISTING_FILE_SHARE_NAME
       mountWithManagedIdentity: "true"
       # optional, clientID of the managed identity, kubelet identity would be used by default if it's empty
       clientID: "xxxxx-xxxx-xxx-xxx-xxxxxxx"

Creación de un PV estático con Azure Files

En las secciones siguientes se proporcionan instrucciones para crear un PV estático con Azure Files. Un PV estático es un volumen persistente que un administrador crea manualmente. Este PV está disponible para su uso por parte de los pods del clúster. Para usar un PV estático, cree un PVC que haga referencia al PV y, a continuación, cree un pod que haga referencia al PVC.

Parámetros de clase de almacenamiento para PVs estáticos con Azure Files

En la tabla siguiente se incluyen parámetros que puede usar para definir una clase de almacenamiento personalizada para los PVC estáticos con Azure Files:

Creación de un recurso compartido de archivos de Azure

Para poder utilizar un recurso compartido de archivos de Azure Files como volumen de Kubernetes, es preciso crear una cuenta de Azure Storage y el recurso compartido de archivos.

1. Obtenga el nombre del grupo de recursos de nodos del clúster de AKS utilizando el comando con el parámetro az aks show--query nodeResourceGroup.

   az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv
   

   La salida del comando es similar al ejemplo siguiente:

   MC_myResourceGroup_myAKSCluster_eastus
   

2. Cree una cuenta de almacenamiento mediante el comando az storage account create con el parámetro --sku. El siguiente comando crea una cuenta de almacenamiento con el SKU Standard_LRS. Asegúrese de reemplazar los siguientes marcadores de posición:

   • myAKSStorageAccount con el nombre de la cuenta de almacenamiento
   • nodeResourceGroupName con el nombre del grupo de recursos en el que se hospedan los nodos del clúster de AKS
   • location con el nombre de la región en la que se va a crear el recurso. Debe ser la misma región que los nodos del clúster de AKS.

   az storage account create --name myAKSStorageAccount --resource-group nodeResourceGroupName --location location --sku Standard_LRS
   

3. Exporte la cadena de conexión como una variable de entorno, que usará para compartir archivos, mediante el comando [az storage account show-connection-string][az-storage-account-show-connection-string]. Asegúrese de reemplazar storageAccountName y resourceGroupName por el nombre de la cuenta de almacenamiento y el nombre del grupo de recursos.

   export AZURE_STORAGE_CONNECTION_STRING=$(az storage account show-connection-string --name storageAccountName --resource-group resourceGroupName -o tsv)
   

   Nota:

   Las cadenas de conexión deben protegerse mediante la rotación de claves o el almacenamiento en una instancia de Azure Key Vault. Para obtener más información sobre las cadenas de conexión, consulte Configuración de cadenas de conexión de Azure Storage y Administración de claves de acceso de la cuenta de almacenamiento. Para entornos de producción, Microsoft recomienda usar la autenticación Microsoft Entra ID. Para más información, consulte Autorización del acceso a datos en Azure Storage.

4. Cree el recurso compartido de archivos mediante la ejecución del comando az storage share create. Asegúrese de reemplazar shareName por el nombre del recurso compartido.

   az storage share create --name shareName --connection-string $AZURE_STORAGE_CONNECTION_STRING
   

5. Exporte la clave de la cuenta de almacenamiento como una variable de entorno mediante el comando [az storage account keys list][az-storage-account-keys-list]. Asegúrese de reemplazar storageAccountName y resourceGroupName por el nombre de la cuenta de almacenamiento y el nombre del grupo de recursos.

   STORAGE_KEY=$(az storage account keys list --resource-group nodeResourceGroupName --account-name myAKSStorageAccount --query "[0].value" -o tsv)
   

6. Imprima el nombre y la clave de la cuenta de almacenamiento mediante el siguiente comando. Anote la clave de la cuenta de almacenamiento, que se usa para crear un secreto de Kubernetes en el paso siguiente.

   echo Storage account key: $STORAGE_KEY
   

Creación de un secreto de Kubernetes

Kubernetes necesita credenciales para acceder al recurso compartido de archivos creado en el paso anterior. Estas credenciales se almacenan en un secreto de Kubernetes, al que se hace referencia al crear un pod de Kubernetes.

• Cree el secreto mediante el comando kubectl create secret. En el ejemplo siguiente se crea un secreto denominado Azure-secret y se rellena Azurestorageaccountname y Azurestorageaccountkey del paso anterior. Para usar una cuenta de almacenamiento de Azure existente, proporcione su nombre y su clave.

  kubectl create secret generic azure-secret --from-literal=azurestorageaccountname=myAKSStorageAccount --from-literal=azurestorageaccountkey=$STORAGE_KEY
  

Montaje de un recurso compartido de archivos como volumen persistente

1. Cree un archivo llamado azurefiles-pv.yaml y copie en él el siguiente contenido. En csi, actualice resourceGroup, volumeHandley shareName. Para las opciones de montaje, el valor predeterminado de fileMode y dirMode es 0777.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     annotations:
       pv.kubernetes.io/provisioned-by: file.csi.azure.com
     name: azurefile
   spec:
     capacity:
       storage: 5Gi
     accessModes:
       - ReadWriteMany
     persistentVolumeReclaimPolicy: Retain
     storageClassName: azurefile-csi
     csi:
       driver: file.csi.azure.com
       volumeHandle: "{resource-group-name}#{account-name}#{file-share-name}"  # make sure this volumeid is unique for every identical share in the cluster
       volumeAttributes:
         shareName: aksshare
       nodeStageSecretRef:
         name: azure-secret
         namespace: default
     mountOptions:
       - dir_mode=0777
       - file_mode=0777
       - uid=0
       - gid=0
       - mfsymlinks
       - cache=strict
       - nosharesock
       - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks
   

2. Cree el PV mediante el kubectl create comando .

   kubectl create -f azurefiles-pv.yaml
   

3. Cree un nuevo archivo denominado azurefiles-mount-options-pvc.yaml y pegue el contenido siguiente. Asegúrese de que storageClassName coincide con el nombre de la clase de almacenamiento existente y que volumeName coincide con el nombre del PV que creó en el paso anterior.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: azurefile
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: azurefile-csi
     volumeName: azurefile
     resources:
       requests:
         storage: 5Gi
   

4. Cree el PVC mediante el comando kubectl apply.

   kubectl apply -f azurefiles-mount-options-pvc.yaml
   

5. Compruebe que la PVC se ha creado y enlazado al PV mediante el comando kubectl get.

   kubectl get pvc azurefile
   

   La salida debe ser similar a la siguiente salida de ejemplo, que muestra que el PVC está en un Bound estado y está enlazado al PV denominado azurefile:

   NAME        STATUS   VOLUME      CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   azurefile   Bound    azurefile   5Gi        RWX            azurefile      5s
   

6. Actualice la especificación de contenedor para que haga referencia a la PVC y al pod en el archivo YAML. Por ejemplo:

   ...
     volumes:
     - name: azure
       persistentVolumeClaim:
         claimName: azurefile
   

7. No se puede actualizar una especificación de pod. Debe eliminar el pod mediante el comando kubectl delete y volver a crearlo mediante el comando kubectl apply.

   kubectl delete pod mypod
   kubectl apply -f azure-files-pod.yaml
   

Montaje de un recurso compartido de archivos como volumen insertado

Para montar el recurso compartido de archivos de Azure Files en el pod, configure el volumen en las especificaciones del contenedor.

1. Cree un archivo llamado Azure-files-pod.yaml y copie en él el siguiente contenido. Si ha cambiado el nombre del recurso compartido de Azure Files o el nombre del secreto, actualice los valores shareName y secretName. Puede actualizar el valor de mountPath, que es la ruta de acceso en la que se monta el recurso compartido de Azure Files en el pod. Para los contenedores de Windows Server, especifique un elemento mountPath con la convención de ruta de acceso de Windows, como "D:" .

   apiVersion: v1
   kind: Pod
   metadata:
     name: mypod
   spec:
     nodeSelector:
       kubernetes.io/os: linux
     containers:
       - image: 'mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine'
         name: mypod
         resources:
           requests:
             cpu: 100m
             memory: 128Mi
           limits:
             cpu: 250m
             memory: 256Mi
         volumeMounts:
           - name: azure
             mountPath: /mnt/azure
             readOnly: false
     volumes:
       - name: azure
         csi:
           driver: file.csi.azure.com
           volumeAttributes:
             secretName: azure-secret  # required
             shareName: aksshare  # required
             mountOptions: 'dir_mode=0777,file_mode=0777,cache=strict,actimeo=30,nosharesock,nobrl'  # optional
   

2. Cree el pod mediante el comando kubectl apply.

   kubectl apply -f azure-files-pod.yaml
   

3. Vea el estado del pod mediante el kubectl describe comando :

   kubectl describe pod mypod
   

Contenido relacionado

• Uso de etiquetas de Azure en Azure Kubernetes Service (AKS)