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.

Antes de empezar

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

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

Actualización de un grupo de nodos único

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.

1. Compruebe si hay actualizaciones disponibles mediante el comando az aks get-upgrades.

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

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

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

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

1. El plano de control del clúster con una versión de Kubernetes y
2. 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.

Reglas de validación para actualizaciones

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.

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.

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

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

Supresión de máquinas virtuales específicas del conjunto de nodos existente

Nota:

Al eliminar una máquina virtual con este comando, AKS no realiza acordonar ni purgar. Para minimizar la interrupción de los pods que se están ejecutando actualmente en la máquina virtual que planea eliminar, realice un acordonamiento y purga en la máquina virtual antes de eliminarla. Puede obtener más información sobre cómo acordonar y purgar mediante el escenario de ejemplo proporcionado en el tutorial sobre el cambio de tamaño de los grupos de nodos.

1. Enumera los nodos existentes utilizando el comando kubectl get nodes.

   kubectl get nodes
   

   El resultado debería ser similar al ejemplo siguiente:

   NAME                                 STATUS   ROLES   AGE   VERSION
   aks-mynodepool-20823458-vmss000000   Ready    agent   63m   v1.21.9
   aks-mynodepool-20823458-vmss000001   Ready    agent   63m   v1.21.9
   aks-mynodepool-20823458-vmss000002   Ready    agent   63m   v1.21.9
   

2. Elimine las máquinas virtuales especificadas mediante el comando az aks nodepool delete-machines . Asegúrese de sustituir los marcadores de posición por sus propios valores.

   az aks nodepool delete-machines \
       --resource-group <resource-group-name> \
       --cluster-name <cluster-name> \
       --name <node-pool-name>
       --machine-names <vm-name-1> <vm-name-2>
   

3. Compruebe que las máquinas virtuales se eliminaron correctamente mediante el comando kubectl get nodes.

   kubectl get nodes
   

   La salida ya no debe incluir las máquinas virtuales que especificó en el comando az aks nodepool delete-machines.

Asociación de grupos de reserva de capacidad para grupos de nodos

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.

Requisitos previos para usar los grupos de reserva de capacidad con AKS

• 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         
  

Asociación de un grupo de reservas de capacidad existente a un grupo de nodos

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

Asociación de un grupo de reservas de capacidad existente a un grupo de nodos del sistema

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.

Especificación de un tamaño de máquina virtual para un 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.

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

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

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

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.

Establecimiento de valores taint del 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).

Establecimiento de valores toleration de grupo de nodos

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.

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

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

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

Establecimiento de etiquetas del grupo de nodos

Para más información, 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, consulte Uso de etiquetas de Azure en Azure Kubernetes Service (AKS).

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

1. 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"
               }
           }
       ]
   }
   

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

Pasos siguientes

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