Administración de grupos de nodos para un clúster en Azure Kubernetes Service (AKS)
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. Cuando crea un clúster de AKS, define el número de nodos y su tamaño (SKU) inicial. A medida que cambian las demandas de la aplicación, es posible que tenga que cambiar la configuración de los grupos de nodos. Por ejemplo, puede que tenga que escalar el número de nodos de un grupo de nodos o actualizar la versión de Kubernetes de un grupo de nodos.
Este artículo le muestra cómo administrar uno o más grupos de nodos en un clúster de AKS.
- Consulte Creación de grupos de nodos para un clúster en Azure Kubernetes Service (AKS) para aprender a crear grupos de nodos para los clústeres de AKS.
- 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. - Revise Opciones de almacenamiento de las aplicaciones de Azure Kubernetes Service para planear la configuración de almacenamiento.
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).
- Los grupos del sistema deben contener al menos un nodo mientras que los grupos de nodos del usuario pueden contener varios nodos o ninguno.
- No puede cambiar el tamaño de VM de un grupo de nodos después de crearlo.
- 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. Puede realizar actualizaciones después de aprovisionar el clúster mediante operaciones por grupo de nodos.
- No se pueden ejecutar simultáneamente operaciones de actualización y escalado en un clúster o grupo de nodos. Si intenta ejecutarlos al mismo tiempo, recibirá un error. Cada tipo de operación debe completarse en el recurso de destino antes de la siguiente solicitud en ese mismo recurso. Para más información, consulte la guía para la solución de problemas.
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.
En este ejemplo, actualizamos el grupo de nodos mynodepool. Dado que hay dos grupos de nodos, debemos usar el comando az aks nodepool upgrade
para actualizar.
Compruebe si hay actualizaciones disponibles mediante el comando
az aks get-upgrades
.az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster
Actualice el grupo de nodos mynodepool mediante el comando
az aks nodepool upgrade
.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 mediante el comando
az aks nodepool list
.az aks nodepool list --resource-group myResourceGroup --cluster-name myAKSCluster
En la salida de ejemplo siguiente, se muestra que mynodepool se encuentra en el estado Actualizando:
[ { ... "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.
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. En los demás grupos de nodos se establece su 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:
- El plano de control del clúster con una versión de Kubernetes y
- Un grupo de nodos con una versión de Kubernetes.
El 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.
az aks upgrade
actualiza el plano de control y todos los grupos de nodos del clúster a la misma versión de Kubernetes.az aks upgrade
con la marca--control-plane-only
actualiza solo el plano de control del clúster y deja todos los grupos de nodos sin cambios.az aks nodepool upgrade
actualiza solo el grupo de nodos de destino con la versión de Kubernetes especificada.
Las actualizaciones de Kubernetes para el plano de control y los grupos de nodos de un clúster se validan usando 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. En las plantillas de Resource Manager, la declaración recurre a la versión existente definida para el grupo de nodos. Si no se establece nada, usa la versión del plano de control en la que revertir.
- No se pueden enviar simultáneamente varias operaciones en un único plano de control o recurso de grupo de nodos. Puede actualizar o escalar un plano de control o un grupo de nodos en un momento dado.
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.
Escale el número de nodos de un grupo de nodos mediante el comando
az aks node pool scale
.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 mediante el comando
az aks node pool list
.az aks nodepool list --resource-group myResourceGroup --cluster-name myAKSCluster
La salida de ejemplo siguiente muestra que mynodepool está en el estado Escalando con un nuevo recuento de cinco nodos:
[ { ... "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.
Escalabilidad automática de un grupo de nodos específico mediante 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. Puede habilitar esta característica con recuentos únicos de escalabilidad mínima y máxima por grupo de nodos.
Para más información, consulte Uso de la escalabilidad automática del clúster.
Para obtener más información, consulte Supresión de máquinas virtuales específicas de un conjunto de nodos existente.
A medida que cambian las demandas de carga de trabajo, puede asociar grupos de reservas de capacidad existentes a grupos de nodos para garantizar la capacidad asignada para los grupos de nodos.
Use la versión 2.56 o posterior de la CLI y la versión 2023-10-01 o posterior de la API.
El grupo de reserva de capacidad ya debe existir, y debe contener una reserva de capacidad como mínimo. De lo contrario, el grupo de nodos se agrega al clúster con una advertencia y no se asocia ningún grupo de reserva de capacidad. Para más información, consulte Grupos de reserva de capacidad.
Debe crear una identidad administrada asignada por el usuario para el grupo de recursos que contiene el grupo de reservas de capacidad (CRG). Las identidades administradas asignadas por el sistema no funcionarán para esta característica. En el ejemplo siguiente, reemplace las variables de entorno por sus propios valores.
IDENTITY_NAME=myID RG_NAME=myResourceGroup CLUSTER_NAME=myAKSCluster VM_SKU=Standard_D4s_v3 NODE_COUNT=2 LOCATION=westus2 az identity create --name $IDENTITY_NAME --resource-group $RG_NAME IDENTITY_ID=$(az identity show --name $IDENTITY_NAME --resource-group $RG_NAME --query identity.id -o tsv)
Tiene que asignar el rol
Contributor
a la identidad asignada por el usuario que se creó anteriormente. Para más información, consulte Pasos para asignar un rol de Azure.Cree un nuevo clúster y asigne la identidad recién creada.
az aks create \ --resource-group $RG_NAME \ --name $CLUSTER_NAME \ --location $LOCATION \ --node-vm-size $VM_SKU --node-count $NODE_COUNT \ --assign-identity $IDENTITY_ID \ --generate-ssh-keys
También puede asignar la identidad administrada por el usuario en un clúster administrado existente con el comando update.
az aks update \ --resource-group $RG_NAME \ --name $CLUSTER_NAME \ --location $LOCATION \ --node-vm-size $VM_SKU \ --node-count $NODE_COUNT \ --enable-managed-identity \ --assign-identity $IDENTITY_ID
Asocie un grupo de reservas de capacidad existente a un grupo de nodos mediante el comando az aks nodepool add
y especifique un grupo de reservas de capacidad con la marca --crg-id
. En el ejemplo siguiente se supone que tiene un CRG denominado "myCRG".
RG_NAME=myResourceGroup
CLUSTER_NAME=myAKSCluster
NODEPOOL_NAME=myNodepool
CRG_NAME=myCRG
CRG_ID=$(az capacity reservation group show --capacity-reservation-group $CRG_NAME --resource-group $RG_NAME --query id -o tsv)
az aks nodepool add --resource-group $RG_NAME --cluster-name $CLUSTER_NAME --name $NODEPOOL_NAME --crg-id $CRG_ID
Para asociar un grupo de reservas de capacidad existente a un grupo de nodos del sistema, asocie el clúster a la identidad asignada por el usuario con el rol Colaborador en el CRG y el propio CRG durante la creación del clúster. Use el comando az aks create
con las marcas --assign-identity
y --crg-id
.
IDENTITY_NAME=myID
RG_NAME=myResourceGroup
CLUSTER_NAME=myAKSCluster
NODEPOOL_NAME=myNodepool
CRG_NAME=myCRG
CRG_ID=$(az capacity reservation group show --capacity-reservation-group $CRG_NAME --resource-group $RG_NAME --query id -o tsv)
IDENTITY_ID=$(az identity show --name $IDENTITY_NAME --resource-group $RG_NAME --query identity.id -o tsv)
az aks create \
--resource-group $RG_NAME \
--cluster-name $CLUSTER_NAME \
--crg-id $CRG_ID \
--assign-identity $IDENTITY_ID \
--generate-ssh-keys
Nota
La eliminación de un grupo de nodos disocia el grupo de nodos implícitamente de cualquier grupo de reserva de capacidad asociado, antes de la eliminación del grupo de nodos. La eliminación de un clúster disocia implícitamente todos los grupos de nodos de un clúster de los grupos de reserva de capacidad asociados.
Nota
No puede actualizar un grupo de nodos existente con un grupo de reserva de capacidad. El enfoque recomendado es asociar un grupo de reserva de capacidad durante la creación del grupo de nodos.
Es posible que tenga que 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 la sección siguiente, se usan valores taint y toleration 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, se crea un grupo de nodos basado en GPU que usa el tamaño de máquina virtual Standard_NC6s_v3. Estas máquinas virtuales disponen de una tarjeta Tesla K80 de NVIDIA. Para más información, consulte Tamaños disponibles de las máquinas virtuales Linux en Azure.
Cree un grupo de nodos mediante el comando
az aks node pool add
. 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_NC6s_v3 \ --no-wait
Compruebe el estado del grupo de nodos con el comando
az aks nodepool list
.az aks nodepool list --resource-group myResourceGroup --cluster-name myAKSCluster
En la siguiente salida de ejemplo se muestra que el grupo de nodos gpunodepool está Creando nodos con el VmSize especificado:
[ { ... "count": 1, ... "name": "gpunodepool", "orchestratorVersion": "1.15.7", ... "provisioningState": "Creating", ... "vmSize": "Standard_NC6s_v3", ... }, { ... "count": 2, ... "name": "nodepool1", "orchestratorVersion": "1.15.7", ... "provisioningState": "Succeeded", ... "vmSize": "Standard_DS2_v2", ... } ]
Tarda unos minutos en crear correctamente gpunodepool.
Al crear un grupo de nodos, puede agregarle valores taint o etiquetas. 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 usar kubectl
para aplicar valores taint o etiquetas a nodos individuales de un grupo de nodos.
AKS admite dos tipos de contaminación de nodos: contaminación de nodo y contaminación de inicialización de nodo (versión preliminar). Para obtener más información, consulte Uso de etiquetas de nodo en un clúster de Azure Kubernetes Service (AKS)..
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 al crear el grupo de nodos. El siguiente manifiesto YAML 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
.kubectl apply -f nginx-toleration.yaml
Se tarda unos segundos en programar el pod y extraer la imagen NGINX.
Compruebe el estado con el comando
kubectl describe pod
.kubectl describe pod mypod
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:
[...] 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 programa en el grupo de nodos nodepool1. Si crea grupos de nodos adicionales, puede usar valores taint y toleration para limitar los pods que se pueden programar en esos recursos del nodo.
Para más información, consulte Uso de etiquetas en un clúster de Azure Kubernetes Service (AKS).
Para obtener más información, consulte Uso de etiquetas de Azure en Azure Kubernetes Service (AKS).
Cuando usa una plantilla de Azure Resource Manager para crear y administrar recursos, puede cambiar la configuración de la plantilla y volver a implementarla para actualizar los recursos. Con grupos de nodos de AKS, no se puede actualizar el perfil del grupo de nodos inicial 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, después, volver a implementar la plantilla. En su lugar, debe crear una plantilla de Resource Manager independiente que actualice los grupos de nodos del clúster de AKS existente.
Cree una plantilla como
aks-agentpools.json
y pegue el siguiente ejemplo de manifiesto. Asegúrese de editar los valores según sea necesario. 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.
{ "$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]", "type": "VirtualMachineScaleSets", "vnetSubnetID": "[variables('agentPoolProfiles').vnetSubnetId]", "orchestratorVersion": "1.15.7" } } ] }
Implemente la plantilla mediante el comando
az deployment group create
.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.
- 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).
- Use grupos con ubicación por proximidad para disminuir la latencia de las aplicaciones de AKS.
- Use direcciones IP públicas de nivel de instancia para permitir que los nodos atiendan el tráfico directamente.
Comentarios de Azure Kubernetes Service
Azure Kubernetes Service es un proyecto de código abierto. Seleccione un vínculo para proporcionar comentarios: