Administración de nodos y grupos de nodos de Kubernetes

La arquitectura de Kubernetes se basa en dos capas: el plano de control y uno o varios nodos de los grupos de nodos. En este artículo se describe y compara cómo Amazon Elastic Kubernetes Service (Amazon EKS) y Azure Kubernetes Service (AKS) administran los nodos de trabajo o agente.

En Amazon EKS y AKS, la plataforma de nube proporciona y administra la capa del plano de control, y el cliente administra la capa de nodo. En el diagrama siguiente se muestra la relación entre el plano de control y los nodos en la arquitectura de Kubernetes de AKS.

Grupos de nodos administrados de Amazon EKS

Los grupos de nodos administrados de Amazon EKS automatizan el aprovisionamiento y la administración del ciclo de vida de los nodos de trabajo de Amazon Elastic Compute Cloud (EC2) en clústeres de Amazon EKS. Los usuarios de Amazon Web Services (AWS) pueden usar la utilidad de línea de comandos eksctl para crear, actualizar o finalizar nodos de sus clústeres de EKS. Las actualizaciones y finalizaciones de nodos acordonan y purgan automáticamente los nodos para asegurarse de que las aplicaciones permanecen disponibles.

Cada nodo administrado se aprovisiona como parte de un grupo de escalabilidad automática de Amazon EC2 que Amazon EKS opera y controla. El escalador automático de clústeres de Kubernetes ajusta automáticamente el número de nodos de trabajo de un clúster cuando se produce un error en los pods o se vuelven a programar en otros nodos. Cada grupo de nodos se puede configurar para ejecutarse en varias instancias de Availability Zones dentro de una región.

Para más información sobre los nodos administrados de Amazon EKS, consulte Creación de un grupo de nodos administrados y Actualización de un grupo de nodos administrados.

También puede ejecutar pods de Kubernetes en AWS Fargate. Fargate proporciona capacidad de proceso a petición y del tamaño adecuado para los contenedores. Para más información sobre cómo usar Fargate con Amazon EKS, consulte AWS Fargate.

Nodos y grupos de nodos de AKS

La creación de un clúster de AKS crea y configura automáticamente un plano de control, que proporciona servicios básicos de Kubernetes y orquestación de las cargas de trabajo de aplicaciones. La plataforma Azure proporciona el plano de control de AKS sin costo alguno como recurso de Azure administrado. El plano de control y sus recursos solo existen en la región en la que creó el clúster.

Los nodos, también llamados nodos de agente o nodos de trabajo, hospedan las cargas de trabajo y las aplicaciones. En AKS, los clientes administran por completo los nodos de agente asociados al clúster de AKS y pagan por ellos.

Para ejecutar aplicaciones y servicios auxiliares, un clúster de AKS necesita al menos un nodo: una máquina virtual (VM) de Azure para ejecutar los componentes del nodo de Kubernetes y el entorno de ejecución del contenedor. Cada clúster de AKS debe contener al menos un grupo de nodos del sistema con al menos un nodo.

AKS agrupa los nodos de la misma configuración en grupos de nodos de máquinas virtuales que ejecutan cargas de trabajo de AKS. Los grupos de nodos del sistema tienen el propósito principal de hospedar los pods críticos del sistema, como CoreDNS. Los grupos de nodos de usuario tienen el propósito principal de hospedar los pods de carga de trabajo. Si solo quiere tener un grupo de nodos en el clúster de AKS, por ejemplo, en un entorno de desarrollo, puede programar pods de aplicación en el grupo de nodos del sistema.

También puede crear varios grupos de nodos de usuario para separar diferentes cargas de trabajo de distintos nodos a fin de evitar el problema de vecino ruidoso o para admitir aplicaciones con diferentes exigencias de proceso o almacenamiento.

Cada nodo de agente de un grupo de nodos de usuario o del sistema es una máquina virtual aprovisionada como parte de Azure Virtual Machine Scale Sets y administrada por el clúster de AKS. Para más información, consulte Nodos y grupos de nodos.

Puede definir el número inicial y el tamaño de los nodos de trabajo al crear un clúster de AKS o al agregar nuevos nodos y grupos de nodos a un clúster de AKS existente. Si no especifica un tamaño de máquina virtual, el tamaño predeterminado es Standard_D2s_v3 para grupos de nodos de Windows y Standard_DS2_v2 para grupos de nodos de Linux.

Creación de grupos de nodos

Puede agregar un grupo de nodos a un clúster de AKS nuevo o existente mediante Azure Portal, la CLI de Azure, la API REST de AKS o las herramientas de infraestructura como código (IaC), como Bicep, plantillas de Azure Resource Manager o Terraform. Para más información sobre cómo agregar grupos de nodos a un clúster de AKS existente, consulte Creación y administración de varios grupos de nodos en un clúster de Azure Kubernetes Service (AKS).

Al crear un grupo de nodos, el conjunto de escalado de máquinas virtuales asociado se crea en el grupo de recursos de nodo, un grupo de recursos de Azure que contiene todos los recursos de infraestructura del clúster de AKS. Estos recursos incluyen los nodos de Kubernetes, recursos de red virtual, identidades administradas y almacenamiento.

De forma predeterminada, el grupo de recursos del nodo tiene un nombre como MC_<resourcegroupname>_<clustername>_<location>. AKS elimina automáticamente el grupo de recursos de nodo al eliminar un clúster, por lo que debe usar este grupo de recursos solo para los recursos que comparten el ciclo de vida del clúster.

Adición de un grupo de nodos

En el ejemplo de código siguiente se usa el comando az aks nodepool add de la CLI de Azure para agregar un grupo de nodos llamado mynodepool con tres nodos a un clúster de AKS existente llamado myAKSCluster en el grupo de recursos myResourceGroup.

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

Grupos de nodos de acceso puntual

Un grupo de nodos de Spot está respaldado por un conjunto de escalado de máquinas virtuales de Spot. El uso de máquinas virtuales de acceso puntual con nodos del clúster de AKS permite aprovechar la capacidad no utilizada en Azure y así obtener un importante ahorro en los costos. La capacidad disponible no utilizada variará en función de muchos factores, como el tamaño del nodo, la región y la hora del día.

Al implementar un grupo de nodos de acceso puntual, Azure asigna los nodos de acceso puntual si hay capacidad disponible. Sin embargo, no hay ningún acuerdo de nivel de servicio (SLA) para los nodos de acceso puntual. Un conjunto de escalado de acceso puntual que respalda el grupo de nodos de acceso puntual se implementa en un solo dominio de error y no ofrece garantías de alta disponibilidad. Cuando Azure necesita recuperar la capacidad, la infraestructura de Azure expulsa los nodos de acceso puntual y recibe como máximo un aviso de 30 segundos antes de la expulsión. Tenga en cuenta que un grupo de nodos de acceso puntual no puede ser el grupo de nodos predeterminado del clúster. Un grupo de nodos de acceso puntual solo se puede usar como grupo secundario.

Los nodos de acceso puntual son para cargas de trabajo que controlen las interrupciones, las finalizaciones tempranas o las expulsiones. Por ejemplo, los trabajos de procesamiento por lotes, los entorno de desarrollo y pruebas y las cargas de trabajo de proceso de gran tamaño son buenos candidatos para la programación en un grupo de nodos de acceso puntual. Para más información, consulte las limitaciones de la instancia de acceso puntual.

El comando siguiente az aks nodepool add agrega un grupo de nodos de acceso puntual a un clúster existente con la escalabilidad automática habilitada.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name myspotnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --priority Spot \
      --eviction-policy Delete \
      --spot-max-price -1 \
      --enable-cluster-autoscaler \
      --min-count 1 \
      --max-count 3 \
      --no-wait

Para más información sobre los grupos de nodos de acceso puntual, consulte Adición de un grupo de nodos de acceso puntual a un clúster de Azure Kubernetes Service (AKS).

Discos de sistema operativo efímero

De manera predeterminada, Azure replica automáticamente el disco del sistema operativo de una máquina virtual en Azure Storage con el fin de evitar la pérdida de datos si hay que reubicar la máquina virtual en otro host. Sin embargo, dado que los contenedores no están diseñados para conservar el estado local, mantener el disco del sistema operativo en el almacenamiento ofrece un valor limitado para AKS. Hay algunas desventajas, como el aprovisionamiento de nodos más lento y una mayor latencia de lectura y escritura.

En contraposición, los discos de SO efímeros solo se almacenan en la máquina host, como un disco temporal, y proporcionan una latencia de lectura y escritura más baja, así como escalado de nodos y actualizaciones de clúster más rápidas. Al igual que sucede con un disco temporal, un disco de SO efímero está incluido en el precio de la máquina virtual, por lo que no lleva asociado ningún costo adicional de almacenamiento.

Para usar un sistema operativo efímero, el disco del sistema operativo debe caber en la caché de la máquina virtual. La documentación de la máquina virtual de Azure muestra el tamaño de la caché de máquinas virtuales entre paréntesis junto al rendimiento de E/S como tamaño de caché en gibibytes (GiB).

Por ejemplo, el tamaño de máquina virtual Standard_DS2_v2 predeterminado de AKS con el tamaño de disco del sistema operativo predeterminado de 100 GB admite el sistema operativo efímero, pero solo tiene 86 GB de tamaño de caché. Esta configuración toma como valor predeterminado el disco administrado si no especifica explícitamente lo contrario. Si solicita explícitamente un sistema operativo efímero para este tamaño, obtendrá un error de validación.

Si solicita la misma máquina virtual Standard_DS2_v2 con un disco del sistema operativo de 60 GB, obtendrá de forma predeterminada el sistema operativo efímero. El tamaño del sistema operativo solicitado de 60 GB es menor que el tamaño máximo de caché de 86 GB.

Standard_D8s_v3 con un disco del sistema operativo de 100 GB admite el sistema operativo efímero y tiene 200 GB de espacio en caché. Si un usuario no especifica el tipo de disco del sistema operativo, el grupo de nodos recibe un sistema operativo efímero de manera predeterminada.

El comando siguiente az aks nodepool add muestra cómo agregar un nuevo grupo de nodos a un clúster existente con un disco de SO efímero. El parámetro --node-osdisk-type establece el tipo de disco de sistema operativo en Ephemeral y el parámetro --node-osdisk-size define el tamaño del disco de sistema operativo.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynewnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --node-osdisk-type Ephemeral \
      --node-osdisk-size 48

Para más información sobre los discos de SO efímeros, consulte Sistema operativo efímero.

Nodos virtuales

Puede usar nodos virtuales para escalar horizontalmente las cargas de trabajo de aplicaciones de forma rápida en un clúster de AKS. Los nodos virtuales proporcionan aprovisionamiento rápido de pods y solo se paga por segundo en tiempo de ejecución. No es necesario esperar a que el escalador automático de clústeres implemente nuevos nodos de trabajo para ejecutar más réplicas de pod. Los nodos virtuales solo son compatibles con nodos y pods de Linux. El complemento de nodos virtuales para AKS se basa en el proyecto de código abierto Virtual Kubelet.

La funcionalidad del nodo virtual depende de Azure Container Instances. Para más información sobre los nodos virtuales, consulte Creación y configuración de un clúster de Azure Kubernetes Services (AKS) para usar nodos virtuales.

Marcas y etiquetas

Al crear un grupo de nodos, puede agregar marcas y etiquetas de Kubernetes, y etiquetas de Azure, a ese grupo de nodos. Al agregar una marca o una etiqueta, todos los nodos de ese grupo de nodos también la obtienen.

Para crear un grupo de nodos con una marca, puede usar el comando az aks nodepool add con el parámetro --node-taints. Para etiquetar los nodos de un grupo de nodos, puede usar el parámetro --labels y especificar una lista de etiquetas, como se muestra en el código siguiente:

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynodepool \
      --node-vm-size Standard_NC6 \
      --node-taints sku=gpu:NoSchedule \
      --labels dept=IT costcenter=9999

Para más información, consulte Especificación de un valor taint o una etiqueta para un grupo de nodos.

Etiquetas reservadas del sistema

Amazon EKS agrega etiquetas de Kubernetes automatizadas a todos los nodos de un grupo de nodos administrados, como eks.amazonaws.com/capacityType, que especifica el tipo de capacidad. AKS también agrega automáticamente etiquetas del sistema a los nodos de agente.

AKS reserva la siguiente lista de prefijos para su uso y no se pueden emplear con ningún nodo:

• kubernetes.azure.com/
• kubernetes.io/

Para ver otros prefijos reservados, consulte Etiquetas, anotaciones y marcas conocidas de Kubernetes.

En la tabla siguiente se enumeran las etiquetas reservadas para el uso de AKS y no se pueden emplear con ningún nodo. En la tabla, la columna Uso del nodo virtual especifica si la etiqueta se admite en los nodos virtuales.

En la columna Uso del nodo virtual:

• N/A significa que la propiedad no se aplica a los nodos virtuales porque sería necesario modificar el host.
• Lo mismo significa que los valores esperados son los mismos para un grupo de nodos virtuales que para un grupo de nodos estándar.
• Virtual reemplaza los valores de SKU de máquina virtual, ya que los pods de nodo virtual no exponen ninguna máquina virtual subyacente.
• La versión del nodo virtual hace referencia a la versión actual de la versión del conector virtual de Kubelet-ACI.
• Nombre de subred del nodo virtual es el nombre de la subred que implementa los pods de nodo virtual en Azure Container Instances.
• Red virtual de nodo virtual es la red virtual que contiene la subred del nodo virtual.

Grupos de nodos de Windows

AKS admite la creación y el uso de grupos de nodos de contenedor de Windows Server mediante el complemento de red Interfaz de red de contenedor (CNI) de Azure. Para planear los intervalos de subred necesarios y las consideraciones de red, consulte Configuración de redes de Azure CNI.

El comando siguiente az aks nodepool add agrega un grupo de nodos que ejecuta contenedores de Windows Server.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mywindowsnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --os-type Windows \
      --node-count 1

El comando anterior usa la subred predeterminada de la red virtual del clúster de AKS. Para más información sobre cómo crear un clúster de AKS con un grupo de nodos de Windows, consulte Creación de un contenedor de Windows Server en AKS.

Consideraciones sobre los grupos de nodos

Se aplican las siguientes consideraciones y limitaciones al crear y administrar grupos de nodos y varios grupos de nodos:

• Las cuotas, las restricciones de tamaño de máquina virtual y la disponibilidad de regiones se aplican a los grupos de nodos de AKS.

• Los grupos del sistema deben contener al menos un nodo. Puede eliminar grupos de nodos del sistema si dispone de otro grupo de nodos del sistema que ocupe su lugar en el clúster de AKS. Los grupos de nodos de usuario pueden contener cero o más nodos.

• No puede cambiar el tamaño de VM de un grupo de nodos después de crearlo.

• Para varios grupos de nodos, el clúster de AKS debe usar los equilibradores de carga de SKU estándar. Los equilibradores de carga de SKU básica no admiten varios grupos de nodos.

• Todos los grupos de nodos de clúster deben estar en la misma red virtual y todas las subredes asignadas a cualquier grupo de nodos deben estar en la misma red virtual.

• Si crea varios grupos de nodos en el momento de la creación del clúster, las versiones de Kubernetes para todos los grupos de nodos deben coincidir con la versión del plano de control. Puede actualizar las versiones después de aprovisionar el clúster mediante operaciones por grupo de nodos.

Escalado de grupos 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. Puede escalar o reducir verticalmente el número de nodos de forma manual mediante el comando az aks nodepool scale. En el ejemplo siguiente se escala el número de nodos de mynodepool a cinco:

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

Escalado automático de grupos de nodos mediante el escalador automático de clústeres

AKS admite el escalado automático de grupos de nodos con el escalador automático de clústeres. Esta característica se habilita en cada grupo de nodos, y se define un número mínimo y máximo de nodos.

El comando siguiente az aks nodepool add agrega un nuevo grupo de nodos llamado mynodepool a un clúster existente. El parámetro --enable-cluster-autoscaler habilita el escalador automático de clústeres en el nuevo grupo de nodos y los parámetros --min-count y --max-count especifican el número mínimo y máximo de nodos del grupo.

  az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --node-vm-size Standard_D8ds_v4 \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 5

El siguiente comando az aks nodepool update actualiza el número mínimo de nodos de uno a tres para el grupo de nodos mynewnodepool.

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --update-cluster-autoscaler \
  --min-count 1 \
  --max-count 3

Puede deshabilitar el escalador automático de clústeres con az aks nodepool update pasando el parámetro --disable-cluster-autoscaler.

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynodepool \
  --disable-cluster-autoscaler

Para volver a habilitar el escalador automático de clústeres en un clúster existente, use az aks nodepool update, y especifique los parámetros --enable-cluster-autoscaler, --min-count y --max-count.

Para más información sobre cómo usar el escalador automático de clústeres para grupos de nodos individuales, consulte Escalado automático de un clúster para satisfacer las demandas de la aplicación en Azure Kubernetes Service (AKS).

Actualizaciones

Azure actualiza periódicamente su plataforma de hospedaje de máquinas virtuales para mejorar la confiabilidad, el rendimiento y la seguridad. Estas actualizaciones van desde la aplicación de revisiones a componentes de software en el entorno de hospedaje hasta la actualización de los componentes de red o la retirada de hardware. Para más información sobre cómo Azure actualiza las máquinas virtuales, consulte Mantenimiento de máquinas virtuales en Azure.

Las actualizaciones de infraestructura de hospedaje de máquinas virtuales no suelen afectar a las máquinas virtuales hospedadas, como los nodos de agente de los clústeres de AKS existentes. En el caso de las actualizaciones que afectan a las máquinas virtuales hospedadas, Azure minimiza los casos que requieren reinicios pausando la máquina virtual mientras se actualiza el host o migrando en vivo la máquina virtual a un host ya actualizado.

Si una actualización requiere un reinicio, Azure proporciona una notificación y una ventana de tiempo para que pueda iniciar la actualización cuando le convenga. La ventana de mantenimiento automático de las máquinas host es normalmente de 35 días, a menos que la actualización sea urgente.

Puede usar el mantenimiento planeado para actualizar las máquinas virtuales y administrar las notificaciones de mantenimiento planeado con la CLI de Azure, PowerShell o Azure Portal. El mantenimiento planeado detecta si usa la actualización automática de clústeres y programa las actualizaciones durante la ventana de mantenimiento automáticamente. Para más información sobre el mantenimiento planeado, consulte el comando az aks maintenanceconfiguration y el artículo Uso del mantenimiento planeado a fin de programar ventanas de mantenimiento para el clúster de Azure Kubernetes Service (AKS).

Actualizaciones de Kubernetes

Parte del ciclo de vida del clúster de AKS es la actualización periódica a la versión más reciente de Kubernetes. Es importante aplicar actualizaciones para obtener las versiones y características de seguridad más recientes. Para actualizar la versión de Kubernetes de las máquinas virtuales del grupo de nodos existentes, debe acordonar y purgar los nodos y reemplazarlos por nuevos nodos basados en una imagen de disco de Kubernetes actualizada.

De manera predeterminada, AKS configura las actualizaciones para la sobrecarga con un nodo adicional. Un valor predeterminado de uno para la configuración max-surge minimiza la interrupción de la carga de trabajo al crearse un nodo adicional para reemplazar los nodos con versiones anteriores antes de acordonar o purgar las aplicaciones existentes. Puede personalizar el valor max-surge por grupo de nodos para permitir un equilibrio entre la velocidad de actualización y la interrupción de la actualización. Al aumentar el valor max-surge, el proceso de actualización se completa más rápido; sin embargo, un valor grande de max-surge podría provocar interrupciones durante el proceso de actualización.

Por ejemplo, un valor de max-surge del 100 % proporciona el proceso de actualización más rápido posible al duplicarse el número de nodos, pero también hace que todos los nodos del grupo de nodos se purguen a la vez. Es posible que quiera usar este valor alto para las pruebas, pero para los grupos de nodos de producción es mejor un valor max-surge del 33 %.

AKS acepta valores enteros y porcentuales para max-surge. Un entero, como 5, indica una sobrecarga de cinco nodos adicionales. Los valores porcentuales de max-surge pueden ser un mínimo de 1% y un máximo de 100%, redondeados al número de nodos más cercano. Un valor de 50% indica un valor de sobrecarga de la mitad del número de nodos actual del grupo.

Durante una actualización, el valor max-surge puede ser 1 como mínimo y un valor máximo igual al número de nodos del grupo de nodos. Aunque puede establecer valores mayores, el número máximo de nodos que se usan para max-surge no será mayor que el número de nodos del grupo.

Actualización de grupos de nodos

Para ver las actualizaciones disponibles, use az aks get-upgrades.

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

Para ver el estado de los grupos de nodos, use az aks nodepool list.

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

El siguiente comando usa az aks nodepool upgrade para actualizar un único grupo de nodos.

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

Para más información sobre cómo actualizar la versión de Kubernetes para un plano de control de clúster y grupos de nodos, consulte:

• Actualización de la imagen de nodos de Azure Kubernetes Service (AKS)
• Actualización del plano de control de un clúster con varios grupos de nodos

Consideraciones sobre la actualización

Tenga en cuenta estos procedimientos recomendados y consideraciones para actualizar la versión de Kubernetes en un clúster de AKS.

• Se recomienda actualizar 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 actualiza todos los grupos de nodos y el plano de control.

• Realice la actualización manualmente o establezca un canal de actualización automática en el clúster. Si usa el mantenimiento planeado para aplicar revisiones a las máquinas virtuales, también se inician actualizaciones automáticas durante la ventana de mantenimiento especificada. Para más información, consulte Actualización de un clúster de Azure Kubernetes Service (AKS).

• El comando az aks upgrade con la marca --control-plane-only actualiza solo el plano de control del clúster y no cambia ninguno de los grupos de nodos asociados del clúster. Para actualizar grupos de nodos individuales, especifique el grupo de nodos de destino y la versión de Kubernetes en el comando az aks nodepool upgrade.

• Una actualización del clúster de AKS desencadena un acordonamiento y purga de los nodos. Si tiene una cuota de proceso baja disponible, se puede producir un error en la actualización. Para más información sobre cómo aumentar la cuota, consulte Aumento de las cuotas de vCPU regionales.

• Configure el parámetro max-surge en función de sus necesidades, mediante un valor entero o porcentual. En el caso de los grupos de nodos de producción, use un valor max-surge del 33 %. Para más información, consulte Personalización de la actualización de sobrecarga de nodos.

• Al actualizar un clúster de AKS que usa redes de CNI, asegúrese de que la subred tenga suficientes direcciones IP privadas disponibles para los nodos adicionales que se creen con el valor max-surge. Para más información, consulte Configuración de redes de Azure CNI en Azure Kubernetes Service (AKS).

• Si los grupos de nodos de clúster abarcan varias instancias de Availability Zones dentro de una región, el proceso de actualización puede provocar temporalmente una configuración de zona desequilibrada. Para más información, consulte Consideraciones especiales para grupos de nodos que abarcan varias instancias de Availability Zones.

Redes virtuales de nodo

Cuando se crea un clúster o se agrega un nuevo grupo de nodos a un clúster existente, se especifica el identificador de recurso de una subred dentro de la red virtual del clúster donde se implementan los nodos de agente. 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 lograr con subredes independientes, cada una dedicada a un grupo de nodos distinto. Cada una de las máquinas virtuales del grupo de nodos obtiene una dirección IP privada de su subred asociada.

AKS admite dos complementos de red:

• Kubenet es un complemento de red básico y sencillo para Linux. Con kubenet, los nodos obtienen una dirección IP privada de la subred de la red virtual de Azure. Los pods obtienen una dirección IP de un espacio de direcciones lógicamente diferente. La traducción de direcciones de red (NAT) permite que los pods lleguen a los recursos de la red virtual de Azure mediante la traducción de la dirección IP del tráfico de origen a la dirección IP principal del nodo. Este enfoque reduce el número de direcciones IP que se deben reservar en el espacio de red para los pods.

• Azure Container Networking Interface (CNI) proporciona a cada pod una dirección IP para llamar y acceder directamente. Estas direcciones IP deben ser únicas en el espacio de red. Cada nodo tiene un parámetro de configuración para el número máximo de pods que admite. El número equivalente de direcciones IP por nodo se reserva entonces por adelantado para ese nodo. Este enfoque requiere planeamiento avanzado y puede llevar al agotamiento de direcciones IP o a la necesidad de recompilar los clústeres en una subred mayor, a medida que crecen las exigencias de la aplicación.

  Al crear un clúster o agregar un nuevo grupo de nodos a un clúster que usa Azure CNI, puede especificar el identificador de recurso de dos subredes distintas, una para los nodos y otra para los pods. Para más información, consulte Asignación dinámica de direcciones IP y compatibilidad con subred mejorada.

Asignación dinámica de direcciones IP

Los pods que usan Azure CNI obtienen direcciones IP privadas de una subred del grupo de nodos de hospedaje. La asignación dinámica de direcciones IP de Azure CNI puede asignar direcciones IP privadas a pods de una subred que está separada de la subred que hospeda el grupo de nodos. Esta característica proporciona las siguientes ventajas:

• La subred de pods asigna dinámicamente direcciones IP a los pods. La asignación dinámica proporciona un mejor uso de las direcciones IP en comparación con la solución CNI tradicional, que realiza una asignación estática de direcciones IP para cada nodo.

• Puede escalar y compartir subredes de nodo y pod de forma independiente. Puede compartir una sola subred de pod entre varios grupos de nodos o clústeres implementados en la misma red virtual. También puede configurar una subred de pod independiente para un grupo de nodos.

• Dado que los pods tienen direcciones IP privadas de red virtual, tienen conectividad directa con otros pods y recursos de clúster de la red virtual. Esta capacidad permite mejorar el rendimiento de los clústeres muy grandes.

• Si los pods tienen una subred independiente, puede configurar directivas de red virtual para los pods que sean diferentes de las directivas de nodo. Tener distintas directivas favorece muchas situaciones útiles, como permitir la conectividad a Internet solo para pods y no para nodos, corregir la IP de origen para pods de un grupo de nodos mediante una instancia de NAT Gateway y usar grupos de seguridad de red (NSG) para filtrar el tráfico entre grupos de nodos.

• Tanto Directiva de red como las directivas de red de Kubernetes de Calico funcionan con asignación dinámica de direcciones IP.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

• Paolo Salvatori | Ingeniero de sistemas principal

Otros colaboradores:

• Laura Nicolas | Ingeniera de software sénior
• Chad Kittel | Ingeniero principal de software
• Ed Price | Responsable sénior de programas de contenido
• Theano Petersen | Escritor técnico

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

• AKS para profesionales de Amazon EKS
• Administración de identidades y acceso de Kubernetes
• Supervisión y registro de Kubernetes
• Protección del acceso de red a Kubernetes
• Opciones de almacenamiento para un clúster de Kubernetes
• Administración de costos para Kubernetes
• Gobernanza de clústeres
• Recorrido de la solución Azure Kubernetes Service (AKS)
• Guía de operaciones del día 2 de Azure Kubernetes Service
• Elección de una instancia de Kubernetes en la opción Proceso de Edge
• GitOps para Azure Kubernetes Service

Recursos relacionados

• Procedimientos recomendados para clústeres de AKS
• Creación de un clúster de AKS privado con una zona DNS pública
• Creación de un clúster de Azure Kubernetes Service privado mediante Terraform y Azure DevOps
• Creación de un clúster de Azure Kubernetes Service público o privado con Azure NAT Gateway y Azure Application Gateway
• Uso de puntos de conexión privados con un clúster de AKS privado
• Creación de un clúster de Azure Kubernetes Service con el controlador de entrada de Application Gateway
• Introducción a Kubernetes
• Introducción a Kubernetes en Azure
• Implementación de Azure Kubernetes Service (AKS)
• Desarrollo e implementación de aplicaciones en Kubernetes
• Optimización de los costos de proceso en Azure Kubernetes Service (AKS)