Creación y administración de varios grupos de nodos para un clúster de Azure Kubernetes Service (AKS)

Artículo
06/24/2022
Tiempo de lectura: 31 minutos

En Azure Kubernetes Service, los nodos de la misma configuración se agrupan en grupos de nodos. Estos grupos de nodos contienen las máquinas virtuales subyacentes que ejecutan las aplicaciones. El número de nodos y su tamaño (SKU) inicial se definen al crear un clúster de AKS, lo cual crea un grupo de nodos del sistema. Para admitir aplicaciones con diferentes necesidades de proceso o almacenamiento, puede crear grupos de nodos de usuario. Los grupos de nodos del sistema tienen el propósito principal de hospedar los pods críticos del sistema, como CoreDNS y tunnelfront. Los grupos de nodos de usuario tienen el propósito principal de hospedar los pods de aplicación. Sin embargo, se pueden programar pods de aplicación en grupos de nodos del sistema si quiere tener solo un grupo en el clúster de AKS. En los grupos de nodos del usuario es donde se colocan los pods específicos de la aplicación. Por ejemplo, puede usar estos grupos de nodos de usuario adicionales para proporcionar GPU para aplicaciones de proceso intensivo o acceso a almacenamiento SSD de alto rendimiento.

Nota:

Esta característica le permite obtener un mayor control sobre cómo crear y administrar varios grupos de nodos. Como resultado, se requieren comandos independientes para crear, actualizar y eliminar. Anteriormente, las operaciones de clúster a través de az aks create o az aks update usaban la API managedCluster y eran la única opción para cambiar el plano de control y un grupo de nodo único. Esta característica expone un conjunto de operaciones independiente para los grupos de agentes a través de la API agentPool y requiere el uso del conjunto de comandos az aks nodepool para ejecutar operaciones en un grupo de nodos individual.

Este artículo le muestra cómo crear y administrar grupos de varios nodos en un clúster de AKS.

Antes de empezar

Es preciso que esté instalada y configurada la versión 2.2.0 de la CLI de Azure, o cualquier otra posterior. Ejecute az --version para encontrar la versión. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.

Limitaciones

Se aplican las siguientes limitaciones cuando crea y administra clústeres de AKS que admiten varios grupos de nodos:

Consulte Cuotas, restricciones de tamaño de máquinas virtuales y disponibilidad de regiones en Azure Kubernetes Service (AKS).
Puede eliminar grupos de nodos del sistema, siempre que disponga de otro grupo de nodos del sistema que ocupe su lugar en el clúster de AKS.
Los grupos del sistema deben contener al menos un nodo mientras que los grupos de nodos del usuario pueden contener varios nodos o ninguno.
El clúster de AKS debe usar el equilibrador de carga de SKU estándar para usar varios grupos de nodos; la característica no es compatible con los equilibradores de carga de SKU básica.
El clúster de AKS debe usar conjuntos de escalado de máquinas virtuales para los nodos.
No puede cambiar el tamaño de VM de un grupo de nodos después de crearlo.
El nombre de un grupo de nodos solo puede contener caracteres alfanuméricos en minúsculas y debe comenzar con una letra minúscula. En el caso de los grupos de nodos de Linux, la longitud debe estar comprendida entre 1 y 12 caracteres. Para los grupos de nodos de Windows, la longitud debe estar comprendida entre 1 y 6 caracteres.
Todos los grupos de nodos deben residir en la misma red virtual.
Al crear varios grupos de nodos durante la creación del clúster, todas las versiones de Kubernetes que se usen en los grupos de nodos deben coincidir con la versión establecida para el plano de control. Se puede actualizar después de aprovisionar el clúster mediante operaciones en función del grupo de nodos.

Creación de un clúster de AKS

Importante

Si ejecuta un único grupo de nodos del sistema para el clúster de AKS en un entorno de producción, se recomienda usar al menos tres nodos para el grupo de nodos.

Para empezar, cree un clúster de AKS con un grupo de nodo único. El ejemplo siguiente usa el comando az group create para crear un grupo de recursos denominado myResourceGroup en la región eastus. Se crea un clúster de AKS denominado myAKSCluster mediante el comando az aks create.

Nota

No se admite la SKU Básico del equilibrador de carga cuando se usan varios grupos de nodos. De forma predeterminada, los clústeres de AKS se crean con el SKU de equilibrador de carga Estándar de la CLI de Azure y Azure Portal.

# Create a resource group in East US
az group create --name myResourceGroup --location eastus

# Create a basic single-node AKS cluster
az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --vm-set-type VirtualMachineScaleSets \
    --node-count 2 \
    --generate-ssh-keys \
    --load-balancer-sku standard

La operación de creación del clúster tarda unos minutos.

Nota

Para asegurarse de que el clúster funciona de forma confiable, debe ejecutar al menos dos nodos en el grupo de nodos predeterminado, ya que los servicios esenciales del sistema se ejecutan en este grupo de nodos.

Cuando el clúster esté listo, utilice el comando az aks get-credentials para obtener las credenciales del clúster para su uso con kubectl:

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

Adición de un grupo de nodos

El clúster creado en el paso anterior tiene un grupo de nodo único. Vamos a agregar un segundo grupo de nodos mediante el comando az aks node pool add. En el ejemplo siguiente se crea un grupo de nodos denominado mynodepool que ejecuta 3 nodos:

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 3

Nota

El nombre de un grupo de nodos debe empezar con una letra minúscula y solo puede contener caracteres alfanuméricos. En el caso de los grupos de nodos de Linux, la longitud debe estar comprendida entre 1 y 12 caracteres. Para los grupos de nodos de Windows, la longitud debe estar comprendida entre 1 y 6 caracteres.

Para ver el estado de los grupos de nodos, use el comando az aks node pool list y especifique el nombre del clúster y del grupo de recursos:

az aks nodepool list --resource-group myResourceGroup --cluster-name myAKSCluster

En la siguiente salida de ejemplo se puede ver que mynodepool se ha creado correctamente con tres nodos en el grupo de nodos. Cuando se creó el clúster de AKS en el paso anterior, también se creó un grupo de nodos predeterminado denominado nodepool1 con 2 nodos.

[
  {
    ...
    "count": 3,
    ...
    "name": "mynodepool",
    "orchestratorVersion": "1.15.7",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  },
  {
    ...
    "count": 2,
    ...
    "name": "nodepool1",
    "orchestratorVersion": "1.15.7",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  }
]

Sugerencia

Si no se especifica VmSize al agregar un grupo de nodos, el tamaño predeterminado será Standard_D2s_v3 para los grupos de nodos de Windows y Standard_DS2_v2 para los grupos de nodos de Linux. Si no se especifica OrchestratorVersion, se establecerá de forma predeterminada en la misma versión que el plano de control.

Adición de un grupo de nodos de ARM64 (versión preliminar)

El procesador ARM64 proporciona proceso de bajo consumo para las cargas de trabajo de Kubernetes. Para crear un grupo de nodos de ARM64, deberá elegir una [SKU de instancia compatible con ARM][arm-sku-vm].

Importante

Las características en versión preliminar de AKS están disponibles como opción de participación y autoservicio. Las versiones preliminares se proporcionan "tal cual" y "como están disponibles", y están excluidas de los Acuerdos de nivel de servicio y la garantía limitada. Las versiones preliminares de AKS reciben cobertura parcial del soporte al cliente en la medida de lo posible. Por lo tanto, estas características no están diseñadas para su uso en producción. Para más información, consulte los siguientes artículos de soporte:

Instalación de la CLI de Azure `aks-preview`

También se necesita la versión 0.5.23 o posterior de la extensión aks-preview de la CLI de Azure. Instale la extensión de la CLI de Azure aks-preview mediante el comando az extension add. También puede instalar las actualizaciones disponibles mediante el comando az extension update.

# Install the aks-preview extension
az extension add --name aks-preview
# Update the extension to make sure you have the latest version installed
az extension update --name aks-preview

Registro de la característica en vista previa (GB) `AKSARM64Preview`

Para usar la característica, también debe habilitar la marca de característica AKSARM64Preview en la suscripción.

Registre la marca de la característica AKSARM64Preview con el comando AKSARM64Preview, como se muestra en el siguiente ejemplo:

az feature register --namespace "Microsoft.ContainerService" --name "AKSARM64Preview"

Tarda unos minutos en que el estado muestre Registrado. Puede comprobar el estado de registro con el comando az feature list:

az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/AKSARM64Preview')].{Name:name,State:properties.state}"

Cuando haya terminado, actualice el registro del proveedor de recursos Microsoft.ContainerService con el comando az provider register:

az provider register --namespace Microsoft.ContainerService

Use el comando az aks nodepool add para agregar un grupo de nodos de ARM64.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name armpool \
    --node-count 3 \
    --node-vm-size Standard_Dpds_v5

Adición de un grupo de nodos con una subred única

Una carga de trabajo puede requerir la división de los nodos de un clúster en grupos independientes para el aislamiento lógico. Este aislamiento se puede admitir con subredes independientes dedicadas a cada grupo de nodos del clúster. Esto puede satisfacer requisitos tales como tener un espacio de direcciones de red virtual no contiguo para dividirlo en grupos de nodos.

Nota:

Asegúrese de que su versión de la CLI de Azure sea la 2.35.0 o posterior.

Limitaciones

Todas las subredes asignadas a grupos de nodos deben pertenecer a la misma red virtual.
Los pods del sistema deben tener acceso a todos los nodos o pods del clúster para proporcionar funcionalidad crítica, como la resolución de DNS y la tunelización de logs/exec/port-forward proxy de kubectl.
Si expande la red virtual después de crear el clúster, debe actualizarlo (es decir, debe realizar cualquier operación de clúster administrado, aunque no cuentan las operaciones del grupo de nodos) antes de agregar una subred fuera del CIDR original. AKS generará un error con la opción Agregar ahora en el grupo de agentes aunque originalmente se hubiera permitido. La extensión aks-preview de la CLI de Azure (versión 0.5.66 y posteriores) ahora admite la ejecución az aks update -g <resourceGroup> -n <clusterName> sin argumentos opcionales. Este comando realizará una operación de actualización sin hacer ningún cambio, lo que puede recuperar un clúster bloqueado en un estado de error.
En clústeres con versiones de Kubernetes anteriores a 1.23.3, kube-proxy iniciará el tráfico SNAT desde subredes nuevas, lo que puede hacer que la directiva de Azure Network elimine los paquetes.
Los nodos de Windows dirigirán el tráfico SNAT a las nuevas subredes hasta que se vuelva a restablecer la imagen inicial del grupo de nodos.
Los equilibradores de carga internos usan de forma predeterminada una de las subredes del grupo de nodos (normalmente, la primera subred del grupo de nodos al crear el clúster). Para invalidar este comportamiento, puede especificar explícitamente la subred del equilibrador de carga mediante una anotación.

Para crear un grupo de nodos con una subred dedicada, pase el identificador de recurso de subred como parámetro adicional al crear un grupo de nodos.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 3 \
    --vnet-subnet-id <YOUR_SUBNET_RESOURCE_ID>

Actualización de un grupo de nodos

Nota

Las operaciones de actualización y escalado en un grupo de clústeres o nodos no se pueden realizar simultáneamente. Si se intenta, se devuelve un error. En su lugar, cada tipo de operación debe completarse en el recurso de destino antes de la siguiente solicitud en ese mismo recurso. Obtenga más información al respecto en nuestra guía de solución de problemas.

Los comandos de esta sección explican cómo actualizar un único grupo de nodos específico. La relación entre actualizar la versión de Kubernetes del plano de control y el grupo de nodos se explica en la sección que tiene a continuación.

Nota

La versión de la imagen del sistema operativo del grupo de nodos está vinculada a la versión de Kubernetes del clúster. Solo obtendrá actualizaciones de la imagen del sistema operativo cuando se haya realizado una actualización del clúster.

Como en este ejemplo hay dos grupos de nodos, debemos usar az aks nodepool upgrade para actualizar un grupo de nodos. Para ver las actualizaciones disponibles, use az aks get-upgrades

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster

Vamos a actualizar mynodepool. Use el comando az aks nodepool upgrade para actualizar el grupo de nodos tal como se muestra en el ejemplo siguiente:

az aks nodepool upgrade \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --kubernetes-version KUBERNETES_VERSION \
    --no-wait

Muestre el estado de los grupos de nodos de nuevo mediante el comando az aks node pool list. En el ejemplo siguiente, se muestra que mynodepool se encuentra en el estado Actualizando a KUBERNETES_VERSION:

az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster

[
  {
    ...
    "count": 3,
    ...
    "name": "mynodepool",
    "orchestratorVersion": "KUBERNETES_VERSION",
    ...
    "provisioningState": "Upgrading",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  },
  {
    ...
    "count": 2,
    ...
    "name": "nodepool1",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Succeeded",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  }
]

Tarda unos minutos en actualizar los nodos a la versión especificada.

Se recomienda que actualice todos los grupos de nodos de un clúster de AKS a la misma versión de Kubernetes. El comportamiento predeterminado de az aks upgrade es actualizar todos los grupos de nodos junto con el plano de control para lograr esta alineación. La posibilidad de actualizar grupos de nodos individuales le permite realizar una actualización gradual y programar pods entre grupos de nodos para mantener el tiempo de actividad de las aplicaciones dentro de las restricciones antes mencionadas.

Actualización del plano de control de un clúster con varios grupos de nodos

Nota

Kubernetes usa el esquema de versiones estándar de Versionamiento Semántico. El número de versión se expresa como x.y.z, donde x es la versión principal, y es la versión secundaria y z es la versión de revisión. Por ejemplo, en la versión 1.12.6, 1 es la versión principal, 12 es la versión secundaria y 6 es la versión de revisión. Las versiones de Kubernetes del plano de control y del grupo de nodos inicial se establecen durante la creación del clúster. Todos los grupos de nodos adicionales tienen establecida la versión de Kubernetes cuando se agregan al clúster. Las versiones de Kubernetes pueden diferir entre los grupos de nodos, así como entre un grupo de nodos y el plano de control.

Un clúster de AKS tiene dos objetos de recursos de clúster con las versiones de Kubernetes asociadas.

Un plano de control del clúster con una versión de Kubernetes.
Un grupo de nodos con una versión de Kubernetes.

Un plano de control se asigna a uno o varios grupos de nodos. El comportamiento de una operación de actualización depende del comando de la CLI de Azure que se use.

La actualización de un plano de control de AKS requiere el uso de az aks upgrade. Este comando actualiza la versión del plano de control y todos los grupos de nodos del clúster.

Si se emite el comando az aks upgrade con la marca --control-plane-only, solo se actualiza el plano de control del clúster. No se cambia ninguno de los grupos de nodos asociados del clúster.

La actualización de los grupos de nodos individuales requiere el uso de az aks nodepool upgrade. Este comando actualiza solo el grupo de nodos de destino con la versión de Kubernetes especificada.

Reglas de validación para actualizaciones

Las actualizaciones válidas de Kubernetes del plano de control o de los grupos de nodos de un clúster se validan mediante los siguientes conjuntos de reglas.

Reglas de versiones válidas para actualizar grupos de nodos:
- La versión del grupo de nodos debe tener la misma versión principal que el plano de control.
- La versión del grupo de nodos secundaria debe estar dentro de dos versiones secundarias de la versión del plano de control.
- La versión del grupo de nodos no puede ser mayor que la versión major.minor.patch de control.
Reglas para enviar una operación de actualización:
- No se puede cambiar a la versión anterior de Kubernetes en el plano de control ni en el grupo de nodos.
- Si no se especifica una versión de Kubernetes del grupo de nodos, el comportamiento depende del cliente que se use. La declaración en las plantillas de Resource Manager revierte a versión existente definida para el grupo de nodos. Si no se establece ninguna, se usa la versión del plano de control para la reversión.
- Puede actualizar o escalar un plano de control o un grupo de nodos en un momento dado, pero no puede enviar simultáneamente varias operaciones en un único recurso de plano de control o de grupo de nodos.

Escalado manual de un grupo de nodos

A medida que la carga de trabajo de las aplicaciones cambia, puede que tenga que escalar el número de nodos de un grupo de nodos. El número de nodos se puede escalar o reducir verticalmente.

Para escalar el número de nodos de un grupo de nodos, use el comando az aks node pool scale. En el ejemplo siguiente se escala el número de nodos de mynodepool a 5:

az aks nodepool scale \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 5 \
    --no-wait

Muestre el estado de los grupos de nodos de nuevo mediante el comando az aks node pool list. El ejemplo siguiente muestra que mynodepool está en el estado Escalando con un nuevo recuento de 5 nodos:

az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster

[
  {
    ...
    "count": 5,
    ...
    "name": "mynodepool",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Scaling",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  },
  {
    ...
    "count": 2,
    ...
    "name": "nodepool1",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Succeeded",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  }
]

La operación de escalado tarda unos minutos en completarse.

Escalar un grupo de nodos específico automáticamente habilitando para ello la escalabilidad automática del clúster

AKS ofrece una característica independiente para escalar automáticamente grupos de nodos con una característica denominada cluster autocaler. Esta característica se puede habilitar en función del grupo de nodos con recuentos de escala mínimos y máximos únicos por grupo de nodos. Aprenda a usar la escalabilidad automática del clúster en función del grupo de nodos.

Eliminación de un grupo de nodos

Si ya no necesita un grupo, puede eliminarlo y quitar los nodos de máquinas virtuales subyacentes. Para eliminar un grupo de nodos, use el comando az aks node pool delete y especifique el nombre del grupo de nodos. El ejemplo siguiente elimina el grupo mynodepool que se creó en los pasos anteriores:

Precaución

Cuando se elimina un grupo de nodos, AKS no realiza acordono y purga, y no hay ninguna opción de recuperación para la pérdida de datos que puede producirse al eliminar un grupo de nodos. Si no se pueden programar pods en otros grupos de nodos, esas aplicaciones dejarán de estar disponibles. Asegúrese de que no elimina un grupo de nodos si las aplicaciones en uso no disponen de copias de seguridad de los datos o de la posibilidad de ejecutarse en otros grupos de nodos del clúster. Para minimizar la interrupción de los pods de reprogramación que se ejecutan actualmente en el grupo de nodos que va a eliminar, realice un acordonamiento y purga en todos los nodos del grupo de nodos antes de eliminarlos. Para obtener más información, consulte Acordonamiento/Purga de los nodos existentes.

az aks nodepool delete -g myResourceGroup --cluster-name myAKSCluster --name mynodepool --no-wait

En la siguiente salida de ejemplo del comando az aks node pool list se puede ver que mynodepool se encuentra en el estado Eliminando:

az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster

[
  {
    ...
    "count": 5,
    ...
    "name": "mynodepool",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Deleting",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  },
  {
    ...
    "count": 2,
    ...
    "name": "nodepool1",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Succeeded",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  }
]

Tarda unos minutos en eliminar los nodos y el grupo de nodos.

Asociación de grupos de reserva de capacidad para grupos de nodos (versión preliminar)

Importante

A medida que las cargas de trabajo de la aplicación lo exijan, puede asociar grupos de nodos a grupos de reserva de capacidad creados con anterioridad. De este modo, se asegura que la capacidad garantizada se asigne a los grupos de nodos.

Para más información sobre los grupos de reserva de capacidad, consulte Grupos de reserva de capacidad.

Asociar un grupo de nodos a un grupo existente de reserva de capacidad es posible mediante el comando az aks nodepool add y la especificación de un grupo de reserva de capacidad con la marca --capacityReservationGroup. El grupo de reserva de capacidad debería existir previamente. De lo contrario, el grupo de nodos se agregará al clúster con una advertencia y no se asociará ningún grupo de reserva de capacidad.

az aks nodepool add -g MyRG --cluster-name MyMC -n myAP --capacityReservationGroup myCRG

La asociación de un grupo de nodos del sistema con un grupo de reserva de capacidad existente se puede realizar mediante el comando az aks create. Si el grupo de reserva de capacidad especificado no existe, se emitirá una advertencia, y el clúster se creará sin ninguna asociación de grupo de reserva de capacidad.

az aks create -g MyRG --cluster-name MyMC --capacityReservationGroup myCRG

La eliminación de un comando de grupo de nodos disociará el grupo de nodos implícitamente de cualquier grupo de reserva de capacidad asociado, antes de la eliminación del grupo de nodos.

az aks nodepool delete -g MyRG --cluster-name MyMC -n myAP

La eliminación de un comando de clúster disociará implícitamente todos los grupos de nodos de un clúster de los grupos de reserva de capacidad asociados.

az aks delete -g MyRG --cluster-name MyMC

Especificación de un tamaño de máquina virtual para un grupo de nodos

En los ejemplos anteriores para crear un grupo de nodos, se usó un tamaño de máquina virtual predeterminado para los nodos creados en el clúster. Un escenario habitual consiste en crear grupos de nodos con diferentes tamaños y funcionalidades de máquina virtual. Por ejemplo, puede crear un grupo de nodos que contenga nodos con grandes cantidades de memoria o CPU, o un grupo de nodos que proporcione compatibilidad con GPU. En el paso siguiente, se usan taints y tolerations para indicar al programador de Kubernetes cómo limitar el acceso a los pods que se pueden ejecutar en esos nodos.

En el ejemplo siguiente, cree un grupo de nodos basado en GPU que use el tamaño de máquina virtual Standard_NC6. Estas máquinas virtuales disponen de una tarjeta Tesla K80 de NVIDIA. Para más información sobre los tamaños de máquina virtual disponibles, consulte Tamaños de las máquinas virtuales Linux en Azure.

Cree un grupo de nodos mediante el comando az aks node pool add de nuevo. Esta vez, especifique el nombre gpunodepool y use el parámetro --node-vm-size para especificar el tamaño Standard_NC6:

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name gpunodepool \
    --node-count 1 \
    --node-vm-size Standard_NC6 \
    --no-wait

En la siguiente salida de ejemplo del comando az aks node pool list se puede ver que gpunodepool está Creando nodos con el VmSize especificado:

az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster

[
  {
    ...
    "count": 1,
    ...
    "name": "gpunodepool",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Creating",
    ...
    "vmSize": "Standard_NC6",
    ...
  },
  {
    ...
    "count": 2,
    ...
    "name": "nodepool1",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Succeeded",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  }
]

Tarda unos minutos en crear correctamente gpunodepool.

Especificación de un valor taint o una etiqueta para un grupo de nodos

Al crear un grupo de nodos, puede agregar valores taint o etiquetas a ese grupo de nodos. Al agregar un valor taint o una etiqueta, todos los nodos de ese grupo de nodos también obtienen ese valor taint o etiqueta.

Importante

Se deben agregar valores taint o etiquetas a los nodos para todo el grupo de nodos mediante az aks nodepool. No se recomienda aplicar valores taint o etiquetas a nodos individuales de un grupo de nodos mediante kubectl.

Configuración de las intolerancias de un grupo de nodos

Para crear un grupo de nodos con un valor taint, use az aks nodepool add. Especifique el nombre taintnp y use el parámetro --node-taints para especificar sku=gpu:NoSchedule para el valor taint.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name taintnp \
    --node-count 1 \
    --node-taints sku=gpu:NoSchedule \
    --no-wait

En la siguiente salida de ejemplo del comando az aks nodepool list se puede ver que taintnp está creando (Creating) nodos con el valor nodeTaints especificado:

az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster

[
  {
    ...
    "count": 1,
    ...
    "name": "taintnp",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Creating",
    ...
    "nodeTaints":  [
      "sku=gpu:NoSchedule"
    ],
    ...
  },
 ...
]

La información del valor taint está visible en Kubernetes para controlar las reglas de programación de los nodos. El programador de Kubernetes puede utilizar taints y tolerations para limitar las cargas de trabajo que se pueden ejecutar en los nodos.

Un valor taint se aplica a un nodo que indica que solo se pueden programar pods específicos en él.
Luego se aplica un valor toleration a un pod que le permite tolerar el valor taint de un nodo.

Para más información sobre cómo usar las características avanzadas programadas de Kubernetes, consulte Best practices for advanced scheduler features in AKS (Procedimientos recomendados para las características avanzadas del programador en AKS).

En el paso anterior, aplicó el valor taint sku=gpu:NoSchedule cuando creó el grupo de nodos. El siguiente manifiesto YAML básico de ejemplo usa un valor toleration para permitir al programador de Kubernetes ejecutar un pod NGINX en un nodo de ese grupo de nodos.

Cree un archivo denominado nginx-toleration.yaml y cópielo en el ejemplo siguiente de YAML:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - image: mcr.microsoft.com/oss/nginx/nginx:1.15.9-alpine
    name: mypod
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 1
        memory: 2G
  tolerations:
  - key: "sku"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"

Programe el pod mediante el comando kubectl apply -f nginx-toleration.yaml:

kubectl apply -f nginx-toleration.yaml

Se tarda unos segundos en programar el pod y extraer la imagen NGINX. Use el comando kubectl describe pod para ver el estado del pod. En la siguiente salida de ejemplo reducida se puede ver que se aplica el valor sku=gpu:NoSchedule a toleration. En la sección de eventos, el programador ha asignado el pod al nodo aks-taintnp-28993262-vmss000000:

kubectl describe pod mypod

[...]
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
                 sku=gpu:NoSchedule
Events:
  Type    Reason     Age    From                Message
  ----    ------     ----   ----                -------
  Normal  Scheduled  4m48s  default-scheduler   Successfully assigned default/mypod to aks-taintnp-28993262-vmss000000
  Normal  Pulling    4m47s  kubelet             pulling image "mcr.microsoft.com/oss/nginx/nginx:1.15.9-alpine"
  Normal  Pulled     4m43s  kubelet             Successfully pulled image "mcr.microsoft.com/oss/nginx/nginx:1.15.9-alpine"
  Normal  Created    4m40s  kubelet             Created container
  Normal  Started    4m40s  kubelet             Started container

Solo los pods a los que se ha aplicado este valor toleration se pueden programar en los nodos de taintnp. Cualquier otro pod se tendría que programar en el grupo de nodos nodepool1. Si crea grupos de nodos adicionales, puede usar valores taint y toleration adicionales para limitar los pods que se pueden programar en esos recursos del nodo.

Configuración de etiquetas de grupos de nodos

Para obtener más información sobre cómo usar etiquetas con grupos de nodos, consulte Uso de etiquetas en un clúster de Azure Kubernetes Service (AKS).

Configuración de etiquetas de Azure para grupos de nodos

Para obtener más información sobre cómo usar etiquetas de Azure con grupos de nodos, consulte Uso de etiquetas de Azure en Azure Kubernetes Service (AKS).

Adición de un grupo de nodos habilitado para FIPS

El Estándar federal de procesamiento de información (FIPS) 140-2 es un estándar del gobierno de EE. UU. que define los requisitos mínimos de seguridad para los módulos criptográficos en sistemas y productos de tecnologías de la información. AKS permite crear grupos de nodos basados en Linux con FIPS 140-2 habilitado. Las implementaciones que se ejecutan en grupos de nodos habilitados para FIPS pueden usar esos módulos criptográficos para proporcionar mayor seguridad y ayudar a cumplir los controles de seguridad como parte del cumplimiento de FedRAMP. Para obtener más información sobre FIPS 140-2, consulte Estándar federal de procesamiento de información (FIPS) 140-2.

Requisitos previos

Es preciso que esté instalada y configurada la CLI de Azure, versión 2.32.0 o superior. Ejecute az --version para encontrar la versión. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.

Los grupos de nodos con FIPS habilitado tienen las siguientes limitaciones:

Actualmente, solo puede tener grupos de nodos basados en Linux con FIPS habilitado que se ejecutan en Ubuntu 18.04.
Los grupos de nodos con FIPS habilitado requieren la versión 1.19 de Kubernetes, y cualquier versión posterior.
Para actualizar los paquetes o módulos subyacentes que se usan para FIPS, debe utilizar Node Image Upgrade.
Las imágenes de contenedor en los nodos FIPS no se han evaluado para comprobar el cumplimiento de FIPS.

Importante

La imagen de Linux con FIPS habilitado es una imagen diferente de la imagen de Linux predeterminada que se usa para los grupos de nodos basados en Linux. Para habilitar FIPS en un grupo de nodos, debe crear un grupo de nodos basado en Linux. FIPS no se puede habilitar en grupos de nodos existentes.

Las imágenes de nodos con FIPS habilitado pueden tener números de versión diferentes, como la versión del kernel, que las imágenes que no están habilitadas para FIPS. Además, el ciclo de actualización de los grupos de nodos con FIPS habilitado y las imágenes de nodo pueden diferir de los grupos de nodos y las imágenes que no tengan FIPS habilitado.

Para crear un grupo de nodos con FIPS habilitado, use az aks nodepool add con el parámetro --enable-fips-image al crear un grupo de nodos.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name fipsnp \
    --enable-fips-image

Nota

También puede usar el parámetro --enable-fips-image con az aks create al crear un clúster para habilitar FIPS en el grupo de nodos predeterminado. Al agregar grupos de nodos a un clúster creado de esta forma, debe seguir utilizando el parámetro --enable-fips-image al agregar grupos de nodos para crear un grupo de nodos con FIPS habilitado.

Para comprobar que el grupo de nodos tiene FIPS habilitado, use az aks show para comprobar el valor enableFIPS en agentPoolProfiles.

az aks show --resource-group myResourceGroup --name myAKSCluster --query="agentPoolProfiles[].{Name:name enableFips:enableFips}" -o table

La siguiente salida de ejemplo muestra que el grupo de nodos fipsnp tiene FIPS habilitado, pero nodepool1 no.

Name       enableFips
---------  ------------
fipsnp     True
nodepool1  False

También puede comprobar que las implementaciones tienen acceso a las bibliotecas criptográficas de FIPS mediante kubectl debug en un nodo del grupo de nodos con FIPS habilitado. Use kubectl get nodes para enumerar los nodos:

$ kubectl get nodes
NAME                                STATUS   ROLES   AGE     VERSION
aks-fipsnp-12345678-vmss000000      Ready    agent   6m4s    v1.19.9
aks-fipsnp-12345678-vmss000001      Ready    agent   5m21s   v1.19.9
aks-fipsnp-12345678-vmss000002      Ready    agent   6m8s    v1.19.9
aks-nodepool1-12345678-vmss000000   Ready    agent   34m     v1.19.9

En el ejemplo anterior, los nodos que empiezan por aks-fipsnp forman parte del grupo de nodos con FIPS habilitado. Use kubectl debug para ejecutar una implementación con una sesión interactiva en uno de los nodos del grupo de nodos con FIPS habilitado.

kubectl debug node/aks-fipsnp-12345678-vmss000000 -it --image=mcr.microsoft.com/dotnet/runtime-deps:6.0

Desde la sesión interactiva, puede comprobar que las bibliotecas criptográficas de FIPS están habilitadas:

root@aks-fipsnp-12345678-vmss000000:/# cat /proc/sys/crypto/fips_enabled
1

Los grupos de nodos con FIPS habilitado también tienen la etiqueta kubernetes.azure.com/fips_enabled=true, que las implementaciones pueden usar para dirigirse a esos grupos de nodos.

Administración de grupos de nodos con una plantilla de Resource Manager

Cuando usa una plantilla de Azure Resource Manager para crear y administrar recursos, normalmente puede actualizar la configuración de la plantilla y volver a implementarla para actualizar el recurso. Con grupos de nodos de AKS, el perfil del grupo de nodos inicial no se podrá actualizar una vez que se haya creado el clúster de AKS. Este comportamiento significa que no se puede actualizar una plantilla de Resource Manager existente, realizar un cambio en los grupos de nodos y volver a implementar. En su lugar, debe crear una plantilla de Resource Manager independiente que actualice solo los grupos de nodos de un clúster de AKS existente.

Cree una plantilla como aks-agentpools.json y pegue el siguiente ejemplo de manifiesto. Esta plantilla de ejemplo configura los valores siguientes:

Actualiza el grupo de nodos de Linux denominado myagentpool para que ejecute tres nodos.
Establece los nodos del grupo para ejecutar la versión de Kubernetes 1.15.7.
Define el tamaño del nodo como Standard_DS2_v2.

Edite estos valores para actualizar, agregar o eliminar grupos de nodos según sea necesario:

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "clusterName": {
            "type": "string",
            "metadata": {
                "description": "The name of your existing AKS cluster."
            }
        },
        "location": {
            "type": "string",
            "metadata": {
                "description": "The location of your existing AKS cluster."
            }
        },
        "agentPoolName": {
            "type": "string",
            "defaultValue": "myagentpool",
            "metadata": {
                "description": "The name of the agent pool to create or update."
            }
        },
        "vnetSubnetId": {
            "type": "string",
            "defaultValue": "",
            "metadata": {
                "description": "The Vnet subnet resource ID for your existing AKS cluster."
            }
        }
    },
    "variables": {
        "apiVersion": {
            "aks": "2020-01-01"
        },
        "agentPoolProfiles": {
            "maxPods": 30,
            "osDiskSizeGB": 0,
            "agentCount": 3,
            "agentVmSize": "Standard_DS2_v2",
            "osType": "Linux",
            "vnetSubnetId": "[parameters('vnetSubnetId')]"
        }
    },
    "resources": [
        {
            "apiVersion": "2020-01-01",
            "type": "Microsoft.ContainerService/managedClusters/agentPools",
            "name": "[concat(parameters('clusterName'),'/', parameters('agentPoolName'))]",
            "location": "[parameters('location')]",
            "properties": {
                "maxPods": "[variables('agentPoolProfiles').maxPods]",
                "osDiskSizeGB": "[variables('agentPoolProfiles').osDiskSizeGB]",
                "count": "[variables('agentPoolProfiles').agentCount]",
                "vmSize": "[variables('agentPoolProfiles').agentVmSize]",
                "osType": "[variables('agentPoolProfiles').osType]",
                "storageProfile": "ManagedDisks",
                "type": "VirtualMachineScaleSets",
                "vnetSubnetID": "[variables('agentPoolProfiles').vnetSubnetId]",
                "orchestratorVersion": "1.15.7"
            }
        }
    ]
}

Implemente esta plantilla mediante el comando az deployment group create, tal como se muestra en el ejemplo siguiente. Se le solicitará el nombre y la ubicación del clúster de AKS existente:

az deployment group create \
    --resource-group myResourceGroup \
    --template-file aks-agentpools.json

Sugerencia

Para agregar una etiqueta al grupo de nodos, utilice la propiedad tag en la plantilla, tal y como se muestra en el ejemplo siguiente.

...
"resources": [
{
  ...
  "properties": {
    ...
    "tags": {
      "name1": "val1"
    },
    ...
  }
}
...

Puede que tarde unos minutos en actualizarse el clúster de AKS según la configuración del grupo de nodos y las operaciones que defina en la plantilla de Resource Manager.

Asignación de una dirección IP pública por cada nodo para el grupo de nodos

Los nodos de AKS no necesitan sus propias direcciones IP públicas para la comunicación. Sin embargo, los escenarios pueden requerir que los nodos de un grupo de nodos reciban sus propias direcciones IP públicas dedicadas. Un escenario común es para las cargas de trabajo de juegos, en las que se necesita una consola para tener una conexión directa a una máquina virtual en la nube para minimizar los saltos. Este escenario se puede conseguir en AKS mediante el uso de la dirección IP pública del nodo.

En primer lugar, cree un nuevo grupo de recursos.

az group create --name myResourceGroup2 --location eastus

Cree un clúster de AKS y conecte una dirección IP pública para los nodos. Cada uno de los nodos del grupo de nodos recibe una dirección IP pública única. Puede comprobarlo si examina las instancias del conjunto de escalado de máquinas virtuales.

az aks create -g MyResourceGroup2 -n MyManagedCluster -l eastus  --enable-node-public-ip

En el caso de los clústeres de AKS que ya existan, también puede agregar un nuevo grupo de nodos y asociar una dirección IP pública para los nodos.

az aks nodepool add -g MyResourceGroup2 --cluster-name MyManagedCluster -n nodepool2 --enable-node-public-ip

Uso de un prefijo de dirección IP pública

Existen varias ventajas al usar un prefijo de dirección IP pública. AKS admite el uso de direcciones de un prefijo de dirección IP pública existente para los nodos pasando el identificador de recurso con la marca node-public-ip-prefix al crear un nuevo clúster o agregar un grupo de nodos.

En primer lugar, cree un prefijo de dirección IP pública mediante az network public-ip prefix create:

az network public-ip prefix create --length 28 --location eastus --name MyPublicIPPrefix --resource-group MyResourceGroup3

Vea la salida y tome nota de id para el prefijo:

{
  ...
  "id": "/subscriptions/<subscription-id>/resourceGroups/myResourceGroup3/providers/Microsoft.Network/publicIPPrefixes/MyPublicIPPrefix",
  ...
}

Por último, al crear un nuevo clúster o al agregar un nuevo grupo de nodos, use la marca node-public-ip-prefix y pase el identificador de recurso del prefijo:

az aks create -g MyResourceGroup3 -n MyManagedCluster -l eastus --enable-node-public-ip --node-public-ip-prefix /subscriptions/<subscription-id>/resourcegroups/MyResourceGroup3/providers/Microsoft.Network/publicIPPrefixes/MyPublicIPPrefix

Búsqueda de direcciones IP públicas para nodos

Puede buscar las direcciones IP públicas de los nodos de varias maneras:

Use el comando az vmss list-instance-public-ips de la CLI de Azure.
Use comandos de PowerShell o Bash.
También puede ver las direcciones IP públicas en Azure Portal visualizando las instancias del conjunto de escalado de máquinas virtuales.

Importante

El grupo de recursos de nodo contiene los nodos y sus direcciones IP públicas. Use el grupo de recursos de nodo al ejecutar comandos para buscar las direcciones IP públicas de los nodos.

az vmss list-instance-public-ips -g MC_MyResourceGroup2_MyManagedCluster_eastus -n YourVirtualMachineScaleSetName

Limpieza de recursos

En este artículo, ha creado un clúster de AKS que incluye nodos basados en GPU. Para reducir costos innecesarios, puede que desee eliminar gpunodepool o todo el clúster de AKS.

Para eliminar el grupo de nodos basado en GPU, use el comando az aks nodepool delete tal como se muestra en el ejemplo siguiente:

az aks nodepool delete -g myResourceGroup --cluster-name myAKSCluster --name gpunodepool

Para eliminar el clúster propiamente dicho, use el comando az group delete para eliminar el grupo de recursos de AKS:

az group delete --name myResourceGroup --yes --no-wait

También puede eliminar el clúster adicional que creó para el escenario de IP pública de los grupos de nodos.

az group delete --name myResourceGroup2 --yes --no-wait

Pasos siguientes

Más información sobre los grupos de nodos del sistema.

En este artículo ha aprendido a crear y administrar grupos de varios nodos en un clúster de AKS. Para más información sobre cómo controlar pods en grupos de nodos, consulte Best practices for advanced scheduler features in AKS (Procedimientos recomendados para las características avanzadas del programador en AKS).

Para crear y usar grupos de nodos de contenedores de Windows Server, consulte Creación de un contenedor de Windows Server en AKS.

Use grupos con ubicación por proximidad para disminuir la latencia de las aplicaciones de AKS.

Creación y administración de varios grupos de nodos para un clúster de Azure Kubernetes Service (AKS)

Antes de empezar

Limitaciones

Creación de un clúster de AKS

Adición de un grupo de nodos

Adición de un grupo de nodos de ARM64 (versión preliminar)

Instalación de la CLI de Azure aks-preview

Registro de la característica en vista previa (GB) AKSARM64Preview

Adición de un grupo de nodos con una subred única

Limitaciones

Actualización de un grupo de nodos

Actualización del plano de control de un clúster con varios grupos de nodos

Reglas de validación para actualizaciones

Escalado manual de un grupo de nodos

Escalar un grupo de nodos específico automáticamente habilitando para ello la escalabilidad automática del clúster

Eliminación de un grupo de nodos

Asociación de grupos de reserva de capacidad para grupos de nodos (versión preliminar)

Especificación de un tamaño de máquina virtual para un grupo de nodos

Especificación de un valor taint o una etiqueta para un grupo de nodos

Configuración de las intolerancias de un grupo de nodos

Configuración de etiquetas de grupos de nodos

Configuración de etiquetas de Azure para grupos de nodos

Adición de un grupo de nodos habilitado para FIPS

Requisitos previos

Administración de grupos de nodos con una plantilla de Resource Manager

Asignación de una dirección IP pública por cada nodo para el grupo de nodos

Uso de un prefijo de dirección IP pública

Búsqueda de direcciones IP públicas para nodos

Limpieza de recursos

Pasos siguientes

Instalación de la CLI de Azure `aks-preview`

Registro de la característica en vista previa (GB) `AKSARM64Preview`