Compartir vía

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

  • Artículo

Un controlador de Container Storage Interface (CSI) para discos de Azure es un controlador compatible con la especificación de CSI que usa Azure Kubernetes Service (AKS) para administrar el ciclo de vida de los discos de Azure.

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). En este artículo, se describe cómo usar la versión 1 del controlador CSI para discos de Azure.

Nota:

El controlador de CSI v2 (versión preliminar) para discos de Azure mejora la escalabilidad y reduce la latencia de la conmutación por error del pod. Usa discos compartidos para aprovisionar réplicas de datos adjuntos en varios nodos de clúster, y se integra con el programador de pods para garantizar que se elige un nodo con una réplica de datos adjuntos en la conmutación por error del pod. El controlador de CSI v2 (versión preliminar) para discos de Azure también proporciona la capacidad de ajustar el rendimiento. Si le interesa participar en la versión preliminar, envíe una solicitud: https://aka.ms/DiskCSIv2Preview. Esta versión preliminar se proporciona sin ningún contrato de nivel de servicio, por lo que es posible que se produzcan cambios importantes mientras siga siendo preliminar. Esta versión no se recomienda para las cargas de trabajo de producción. Para más información, consulte Términos de uso complementarios de las Versiones Preliminares de Microsoft Azure.

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.

Características del controlador de CSI para discos de Azure

Además de las características del controlador en árbol, el controlador de CSI para discos de Azure incluye las siguientes características:

  • Mejoras del rendimiento durante la conexión y desconexión simultánea del disco
    • Los controladores en árbol conectan o desconectan los discos en serie, mientras que los controladores CSI conectan o desconectan los discos por lotes. Hay una mejora significativa cuando hay varios discos conectados a un nodo.
  • Se admiten SSD prémium v1 y v2.
    • PremiumV2_LRS solo admite el modo de almacenamiento en caché None
  • Compatibilidad con discos con almacenamiento con redundancia de zona (ZRS)
    • Se admiten los tipos de discos Premium_ZRS y StandardSSD_ZRS. El disco con ZRS se puede programar en el nodo de zona o sin zona, sin la restricción de que el volumen de disco se debe colocar en la misma zona que un nodo determinado. Para obtener más información, incluidas las regiones admitidas, consulte Almacenamiento con redundancia de zona para discos administrados.
  • Instantánea
  • Clonación de volumen
  • Cambio de tamaño de un volumen persistente sin tiempo de inactividad

Nota

En función de la SKU de máquina virtual que se use, el controlador de CSI para discos de Azure podría tener un límite de volumen por nodo. Para algunas máquinas virtuales eficaces (por ejemplo, de 16 núcleos), el límite es de 64 volúmenes por nodo. Para identificar el límite por SKU de máquina virtual, revise la columna Número máximo de discos de datos de cada SKU de máquina virtual ofrecida. Para obtener una lista de las SKU de máquina virtual que se ofrecen y sus límites de capacidad correspondientes detallados correspondientes, vea Tamaños de máquina virtual de uso general.

Use los volúmenes persistentes de CSI con discos de Azure

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. En este artículo se muestra cómo crear un volumen persistente de forma dinámica con discos de Azure para usarlos en un solo pod de un clúster de AKS. En el caso del aprovisionamiento estático, consulte Crear un volumen estático con discos de Azure.

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 discos de Azure mediante las clases de almacenamiento integradas

Una clase de almacenamiento se usa para definir cómo se crea dinámicamente una unidad de almacenamiento con un volumen persistente. Para obtener más información sobre las clases de almacenamiento de Kubernetes, vea Clases de almacenamiento de Kubernetes.

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

  • managed-csi: usa almacenamiento con redundancia local (LRS) SSD estándar de Azure para crear un disco administrado. A partir de la versión 1.29 de Kubernetes, en clústeres de Azure Kubernetes Service (AKS) implementados en varias zonas de disponibilidad, esta clase de almacenamiento usa el almacenamiento SSD estándar con redundancia de zona (ZRS) de Azure para crear discos administrados.
  • managed-csi-premium: usa LRS Premium de Azure para crear un disco administrado. A partir de la versión 1.29 de Kubernetes, en clústeres de Azure Kubernetes Service (AKS) implementados en varias zonas de disponibilidad, esta clase de almacenamiento usa el almacenamiento Premium con redundancia de zona (ZRS) de Azure para crear discos administrados.

La directiva de recuperación de ambas clases de almacenamiento garantiza que los discos de Azure subyacentes se eliminen cuando se elimine el PV correspondiente. Las clases de almacenamiento también configuran los PV de modo que se puedan expandir. Solo tiene que 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 disco administrado de Azure para el tamaño y el SKU deseados. Cuando se crea una definición de pod, se especifica la PVC para solicitar el almacenamiento deseado.

Cree un pod de ejemplo y la PVC respectiva mediante la ejecución del comando kubectl apply:

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

La salida del comando es similar al ejemplo siguiente:

persistentvolumeclaim/pvc-azuredisk created
pod/nginx-azuredisk created

Una vez que el pod esté en estado de ejecución, ejecute el siguiente comando para crear un nuevo archivo llamado test.txt.

kubectl exec nginx-azuredisk -- touch /mnt/azuredisk/test.txt

Para validar que el disco se haya montado correctamente, ejecute el siguiente comando y compruebe que ve el archivo test.txt en la salida:

kubectl exec nginx-azuredisk -- ls /mnt/azuredisk

lost+found
outfile
test.txt

Creación de una clase de almacenamiento personalizada

Las clases de almacenamiento predeterminadas son adecuadas para los escenarios más comunes. En algunos casos, puede que quiera tener una clase de almacenamiento propia personalizada con sus propios parámetros. Por ejemplo, es posible que desee cambiar la clase volumeBindingMode.

Puede usar una clase volumeBindingMode: Immediate, que garantiza su ejecución inmediatamente después de crear la PVC. En los casos en los que los grupos de nodos tienen restricciones de topología (por ejemplo, cuando se usan zonas de disponibilidad), los PV se enlazarían o aprovisionarían sin conocimiento de los requisitos de programación del pod.

Para resolver este escenario, puede usar volumeBindingMode: WaitForFirstConsumer, que retrasa el enlace y el aprovisionamiento de un PV hasta que se crea un pod que usa la PVC. De esta manera, el PV se ajusta y se aprovisiona en la zona de disponibilidad (u otra topología) especificada mediante las restricciones de programación del pod. Las clases de almacenamiento predeterminadas usan la clase volumeBindingMode: WaitForFirstConsumer.

Cree un archivo llamado sc-azuredisk-csi-waitforfirstconsumer.yaml y pegue el manifiesto siguiente. La clase de almacenamiento es la misma que la clase de almacenamiento managed-csi, pero con una clase volumeBindingMode diferente.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azuredisk-csi-waitforfirstconsumer
provisioner: disk.csi.azure.com
parameters:
  skuname: StandardSSD_LRS
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Cree la clase de almacenamiento mediante la ejecución del comando kubectl apply y especifique el archivo sc-azuredisk-csi-waitforfirstconsumer.yaml:

kubectl apply -f sc-azuredisk-csi-waitforfirstconsumer.yaml

La salida del comando es similar al ejemplo siguiente:

storageclass.storage.k8s.io/azuredisk-csi-waitforfirstconsumer created

Instantáneas de volumen

El controlador de CSI para discos de Azure admite la creación de instantáneas de volúmenes persistentes. Como parte de esta capacidad, el controlador puede realizar instantáneas incrementales o completas en función del valor establecido en el parámetro incremental (de manera predeterminada, es true).

En la tabla siguiente, se proporcionan detalles para todos los parámetros.

Nombre Significado Valor disponible Mandatory Valor predeterminado
resourceGroup Grupo de recursos para almacenar instantáneas GRUPO DE RECURSOS EXISTENTE No Si no se especifica, la instantánea se almacenará en el mismo grupo de recursos que los discos de Azure de origen.
incrementales Tomar una instantánea completa o incremental true, false No true
etiquetas Etiquetas de discos de Azure Formato de etiqueta: "key1=val1,key2=val2" No ""
userAgent Agente de usuario utilizado para la atribución de uso del cliente No Agente de usuario generado con formato driverName/driverVersion compiler/version (OS-ARCH)
subscriptionID Especifique el identificador de suscripción de Azure donde se crearán los discos de este. Identificador de suscripción de Azure No Si no está vacío, se debe proporcionar resourceGroup y incremental se debe establecer como false.

Creación de una instantánea de volumen

Nota

Antes de continuar, asegúrese de que la aplicación no esté escribiendo datos en el disco de origen.

Para obtener un ejemplo de esta capacidad, cree una clase de instantánea de volumen con el comando kubectl apply:

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

La salida del comando es similar al ejemplo siguiente:

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

Ahora vamos a crear una instantánea de volumen de la PVC creada dinámicamente al principio de este tutorial, pvc-azuredisk.

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

La salida del comando es similar al ejemplo siguiente:

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

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

kubectl describe volumesnapshot azuredisk-volume-snapshot

La salida del comando es similar al ejemplo siguiente:

Name:         azuredisk-volume-snapshot
Namespace:    default
Labels:       <none>
Annotations:  API Version:  snapshot.storage.k8s.io/v1
Kind:         VolumeSnapshot
Metadata:
  Creation Timestamp:  2020-08-27T05:27:58Z
  Finalizers:
    snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
    snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
  Generation:        1
  Resource Version:  714582
  Self Link:         /apis/snapshot.storage.k8s.io/v1/namespaces/default/volumesnapshots/azuredisk-volume-snapshot
  UID:               dd953ab5-6c24-42d4-ad4a-f33180e0ef87
Spec:
  Source:
    Persistent Volume Claim Name:  pvc-azuredisk
  Volume Snapshot Class Name:      csi-azuredisk-vsc
Status:
  Bound Volume Snapshot Content Name:  snapcontent-dd953ab5-6c24-42d4-ad4a-f33180e0ef87
  Creation Time:                       2020-08-31T05:27:59Z
  Ready To Use:                        true
  Restore Size:                        10Gi
Events:                                <none>

Creación de una nueva PVC basada en una instantánea de volumen

Puede crear una nueva PVC basada en una instantánea de volumen. Use la instantánea creada en el paso anterior y cree una nueva PVC y un nuevo pod para consumirla.

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

La salida del comando es similar al ejemplo siguiente:

persistentvolumeclaim/pvc-azuredisk-snapshot-restored created
pod/nginx-restored created

Por último, vamos a asegurarnos de que es la misma PVC creada antes; para ello, se comprueba el contenido ejecutando el siguiente comando:

kubectl exec nginx-restored -- ls /mnt/azuredisk

La salida del comando es similar al ejemplo siguiente:

lost+found
outfile
test.txt

Como era de esperar, todavía se puede ver el archivo test.txt creado anteriormente.

Clonación de volúmenes

Un volumen clonado se define como un duplicado de un volumen de Kubernetes existente. Para obtener más información sobre la clonación de volúmenes en Kubernetes, vea la documentación conceptual sobre clonación de volúmenes.

El controlador de CSI para discos de Azure admite la clonación de volúmenes. Para demostrarlo, cree un volumen clonado de la azuredisk-pvc creada anteriormente y un nuevo pod para consumirla.

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

La salida del comando es similar al ejemplo siguiente:

persistentvolumeclaim/pvc-azuredisk-cloning created
pod/nginx-restored-cloning created

Puede comprobar el contenido del volumen clonado al ejecutar el siguiente comando y confirmar que se ha creado test.txt el archivo.

kubectl exec nginx-restored-cloning -- ls /mnt/azuredisk

La salida del comando es similar al ejemplo siguiente:

lost+found
outfile
test.txt

Cambio del tamaño de un volumen persistente sin tiempo de inactividad

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.

En AKS, la clase de almacenamiento managed-csi integrada ya permite la expansión, así que use la PVC creada anteriormente con esta clase de almacenamiento. La PVC ha solicitado un volumen persistente de 10 GB. Ejecute el comando siguiente para confirmarlo:

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

La salida del comando es similar al ejemplo siguiente:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc        9.8G   42M  9.8G   1% /mnt/azuredisk

Para expandir la PVC, aumente el campo spec.resources.requests.storage mediante la ejecución del siguiente comando:

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

Nota:

Actualmente no se admite la reducción de volúmenes persistentes. Al intentar aplicar revisiones a un PVC existente con un tamaño menor que el actual, se producirá el siguiente mensaje de error: The persistentVolumeClaim "pvc-azuredisk" is invalid: spec.resources.requests.storage: Forbidden: field can not be less than previous value.

La salida del comando es similar al ejemplo siguiente:

persistentvolumeclaim/pvc-azuredisk patched

Ejecute el siguiente comando para confirmar que haya aumentado el tamaño del volumen:

kubectl get pv

La salida del comando es similar al ejemplo siguiente:

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                     STORAGECLASS   REASON   AGE
pvc-391ea1a6-0191-4022-b915-c8dc4216174a   15Gi       RWO            Delete           Bound    default/pvc-azuredisk                     managed-csi             2d2h
(...)

Después de unos minutos, ejecute los siguientes comandos para confirmar el tamaño de la PVC:

kubectl get pvc pvc-azuredisk

La salida del comando es similar al ejemplo siguiente:

NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-azuredisk   Bound    pvc-391ea1a6-0191-4022-b915-c8dc4216174a   15Gi       RWO            managed-csi    2d2h

Ejecute el siguiente comando para confirmar el tamaño del disco dentro del pod:

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

La salida del comando es similar al ejemplo siguiente:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc         15G   46M   15G   1% /mnt/azuredisk

Expansión a petición

El modelo de expansión de disco a petición permite expansiones de disco cada vez que sus necesidades superen su capacidad actual. Este modelo genera cargos adicionales cada vez que el disco se expande. La expansión bajo demanda solo está disponible para los SSD premium de más de 512 GiB. Para más información sobre las IOPS y el rendimiento aprovisionados de los SSD Premium por disco, consulte Tamaño del SSD Premium. Como alternativa, está la expansión basada en crédito, en la que el disco solo se expandirá si tiene créditos de expansión acumulados en su cubo de crédito. La expansión basada en crédito no genera cargos adicionales cuando el disco se expande. La expansión basada en crédito solo está disponible para los SSD premium de 512 GiB e inferiores y los SSD estándar de 1024 GiB e inferiores. Para más información sobre la expansión a petición, consulte Expansión a petición.

Importante

La clase de almacenamiento predeterminada managed-csi-premium tiene la expansión a petición deshabilitada y usa la expansión basada en crédito. Cualquier SSD Premium creado dinámicamente por una notificación de volumen persistente basada en la clase de almacenamiento predeterminada managed-csi-premium también tiene deshabilitada la expansión a petición.

Para crear un volumen persistente SSD Premium con la expansión a petición habilitada, puede crear una nueva clase de almacenamiento con el parámetro enableBursting establecido en true, tal como se muestra en la siguiente plantilla de YAML. Para más información sobre la expansión a petición, consulte Expansión a petición. Para más información sobre cómo crear su propia clase de almacenamiento con la expansión a petición habilitada, consulte Creación de una clase de almacenamiento Premium CSI administrada ampliable.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: burstable-managed-csi-premium
provisioner: disk.csi.azure.com
parameters:
  skuname: Premium_LRS
  enableBursting: "true"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Contenedores de Windows

El controlador de CSI para discos de Azure admite nodos y contenedores de Windows. Si quiere 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 de Windows, puede usar las clases de almacenamiento integradas como managed-csi. 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 siguiente comando kubectl apply:

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

La salida del comando es similar al ejemplo siguiente:

statefulset.apps/busybox-azuredisk created

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

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

La salida del comando es similar al ejemplo siguiente:

2020-08-27 08:13:41Z
2020-08-27 08:13:42Z
2020-08-27 08:13:44Z
(...)

Pasos siguientes