Compartir a través de

Administración de nodos y grupos de nodos de Kubernetes

La arquitectura de Kubernetes consta de dos capas: el plano de control y al menos un nodo de un grupo de nodos. En este artículo se describe y compara cómo Amazon Elastic Kubernetes Service (EKS) y Azure Kubernetes Service (AKS) administran nodos de agente y nodos de trabajo.

Nota:

Este artículo forma parte de una serie de artículos que ayudan a los profesionales que están familiarizados con Amazon EKS a comprender Azure Kubernetes Service (AKS).

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.

Diagrama que muestra el plano de control y los nodos en la arquitectura 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 las terminaciones de nodos acordonan y purgan automáticamente los nodos para ayudar a garantizar que las aplicaciones permanezcan disponibles.

Cada nodo administrado se aprovisiona como parte de un grupo de escalado automático 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. Puede configurar cada grupo de nodos para que se ejecute en varias zonas de disponibilidad dentro de una región.

Para obtener más información, 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 cómputo a demanda y del tamaño adecuado para contenedores. Para obtener más información, consulte Simplificación de la administración de procesos.

Karpenter

Karpenter es un proyecto de código abierto que ayuda a mejorar la administración del ciclo de vida de los nodos en clústeres de Kubernetes. Automatiza el aprovisionamiento y desaprovisionamiento de nodos en función de las necesidades de programación específicas de los contenedores, lo que mejora la escalabilidad y la optimización de costos. Use Karpenter para las siguientes funciones principales:

  • Supervise los pods que el programador de Kubernetes no puede programar debido a restricciones de recursos.

  • Evalúe los requisitos para la programación de pods no programables, como las solicitudes de recursos, selectores de nodos, afinidades y tolerancias.

  • Configure nuevos nodos que cumplan los requisitos de los pods no programados.

  • Quite los nodos cuando ya no los necesite.

Puede usar Karpenter para definir grupos de nodos que tienen restricciones en el aprovisionamiento de nodos, como taints, etiquetas, requisitos (tipos de instancia y zonas) y límites en el total de recursos aprovisionados. Al implementar cargas de trabajo, especifique varias restricciones de programación en las especificaciones del pod. Por ejemplo, puede especificar límites o solicitudes de recursos, selectores de nodo, afinidades de nodo o pod, tolerancias y restricciones de propagación de topología. Karpenter configura los nodos de tamaño correcto en función de estas especificaciones.

Antes del lanzamiento de Karpenter, los usuarios de Amazon EKS dependían principalmente de grupos de escalado automático de Amazon EC2 y del escalador automático del clúster de Kubernetes para ajustar dinámicamente la capacidad de proceso de sus clústeres. No es necesario crear docenas de grupos de nodos para lograr la flexibilidad y la diversidad que proporciona Karpenter. A diferencia del escalador automático del clúster de Kubernetes, Karpenter depende menos de las versiones de Kubernetes y no requiere transiciones entre las API de AWS y Kubernetes.

Karpenter consolida las responsabilidades de orquestación de instancias dentro de un único sistema, que es más sencillo, estable y compatible con clústeres. Karpenter ayuda a superar los desafíos del escalador automático del clúster al proporcionar formas simplificadas de:

  • Configurar nodos en función de los requisitos de carga de trabajo.

  • Cree diversas configuraciones de nodo por tipo de instancia mediante opciones de grupo de nodos flexibles. En lugar de administrar varios grupos de nodos personalizados específicos, use Karpenter para administrar la capacidad de carga de trabajo diversa mediante un único grupo de nodos flexible.

  • Consiga una programación mejorada de pods a escala mediante el inicio rápido de nodos y la programación de pods.

En comparación con los grupos de escalado automático y los grupos de nodos administrados, Karpenter integra la administración de escalado más estrechamente con las API nativas de Kubernetes. Los grupos de escalado automático y los grupos de nodos administrados son abstracciones nativas de AWS que desencadenan el escalado en función de las métricas de nivel de AWS, como la carga de CPU ec2. Aunque el escalador automático del clúster puentea abstracciones de Kubernetes a abstracciones de AWS, sacrifica cierta flexibilidad, como la programación de una zona de disponibilidad específica.

Karpenter simplifica la administración de nodos mediante la eliminación de componentes específicos de AWS, lo que proporciona mayor flexibilidad directamente dentro de Kubernetes. Utiliza Karpenter para clústeres que ejecutan cargas de trabajo que encuentran períodos de demanda elevada e intermitente o que tienen diversos requisitos de cómputo. Use grupos de nodos administrados y grupos de escalado automático para clústeres que ejecutan cargas de trabajo más estáticas y coherentes. En función de los requisitos, puede usar una combinación de nodos administrados de forma dinámica y estática.

Contenedores Kata

Kata Containers es un proyecto de código abierto que proporciona un entorno de ejecución de contenedor muy seguro. Combina la naturaleza ligera de los contenedores con las ventajas de seguridad de las máquinas virtuales (VM). Kata Containers mejora el aislamiento y la seguridad de la carga de trabajo iniciando cada contenedor con un sistema operativo invitado diferente, a diferencia de los contenedores tradicionales que comparten el mismo kernel de Linux entre las cargas de trabajo. Kata Containers ejecuta contenedores en una máquina virtual compatible con Open Container Initiative (OCI), que proporciona un aislamiento estricto entre contenedores en la misma máquina host. Kata Containers proporciona las siguientes características:

  • Aislamiento mejorado de la carga de trabajo: Cada contenedor se ejecuta en su propia máquina virtual ligera para ayudar a garantizar el aislamiento en el nivel de hardware.

  • Seguridad mejorada: El uso de la tecnología de máquinas virtuales proporciona una capa adicional de seguridad, reduciendo el riesgo de escape de contenedores.

  • Compatibilidad con estándares del sector: Kata Containers se integra con herramientas estándar del sector, como el formato de contenedor OCI y la interfaz de tiempo de ejecución de contenedor de Kubernetes.

  • Compatibilidad con varias arquitecturas e hipervisores: Kata Containers admite arquitecturas AMD64 y ARM, y puede usarla con hipervisores como Hipervisor en la nube y Firecracker.

  • Implementación y administración sencillas: Kata Containers simplifica la orquestación de cargas de trabajo porque usa el sistema de orquestación de Kubernetes.

Para configurar y ejecutar contenedores kata en AWS, configure un clúster de Amazon EKS para usar Firecracker. Firecracker es una tecnología de virtualización de código abierto de Amazon que le ayuda a crear y administrar servicios seguros basados en contenedores multiinquilino y basados en funciones. Use Firecracker para implementar cargas de trabajo en máquinas virtuales ligeras, denominadas microVMs, que proporcionan un aislamiento mejorado de seguridad y carga de trabajo en comparación con las máquinas virtuales tradicionales. Los microVM también mejoran la velocidad y la eficiencia de los recursos de los contenedores. Siga los pasos para ejecutar Kata Containers en AWS EKS.

Servidores dedicados

Al usar Amazon EKS para implementar y ejecutar contenedores, puede ejecutar los contenedores en hosts dedicados de Amazon EC2. Sin embargo, esta característica solo está disponible para grupos de nodos autoadministrado. Por lo tanto, debe crear manualmente una plantilla de inicio y grupos de escalado automático. A continuación, registre los hosts dedicados, la plantilla de inicio y los grupos de escalado automático con el clúster de EKS. Para crear estos recursos, use el mismo método de escalado automático general de EC2.

Para obtener más información sobre cómo usar AWS EKS para ejecutar contenedores en hosts dedicados de EC2, consulte los siguientes recursos:

Nodos y grupos de nodos de AKS

Al crear un clúster de AKS automáticamente, crea y configura un plano de control, que proporciona servicios principales de Kubernetes y orquestación de cargas de trabajo de aplicaciones. La plataforma Azure proporciona el plano de control de AKS sin costo alguno como recurso administrado de Azure. El plano de control y sus recursos solo existen en la región donde se crea 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, administras y pagas por completo los nodos de agente que están asociados al clúster de AKS.

Para ejecutar aplicaciones y servicios auxiliares, un clúster de AKS necesita al menos un nodo, que es una máquina virtual de Azure que ejecuta 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 que tenga al menos un nodo.

AKS combina nodos de la misma configuración en grupos de nodos de máquinas virtuales que ejecutan cargas de trabajo de AKS. Use grupos de nodos del sistema para hospedar pods críticos del sistema, como CoreDNS. Use grupos de nodos de usuario para hospedar 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.

Diagrama que muestra un único nodo de Kubernetes.

También puede crear varios grupos de nodos de usuario para separar diferentes cargas de trabajo en distintos nodos. Este enfoque ayuda a evitar el problema de vecino ruidoso y admite aplicaciones que tienen diferentes demandas de proceso o almacenamiento.

Cada nodo de agente dentro de un grupo de nodos de usuario o del sistema es esencialmente una máquina virtual. Azure Virtual Machine Scale Sets configura las máquinas virtuales y el clúster de AKS los administra. Para obtener más información, consulte 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.

Importante

Para proporcionar una mejor latencia para las llamadas internas de nodo y las comunicaciones con servicios de plataforma, elija una serie de máquinas virtuales que admita redes aceleradas.

Creación de un grupo de nodos

Al crear un nuevo grupo de nodos, el conjunto de escalado de máquinas virtuales asociado se crea en el grupo de recursos del nodo. Este grupo de recursos de Azure 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 del nodo cuando elimina un clúster. Debe usar este grupo de recursos solo para los recursos que comparten el ciclo de vida del clúster.

Para más información, consulte Creación de grupos de nodos para un clúster en AKS.

Adición de un grupo de nodos

Para agregar un grupo de nodos a un clúster de AKS nuevo o existente, use Azure Portal, la CLI de Azure o la API REST de AKS. También puede utilizar herramientas de infraestructura como código (IaC), tales como Bicep, plantillas de Azure Resource Manager o Terraform.

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 denominado mynodepool que tiene tres nodos. Agrega el grupo de nodos a un clúster de AKS existente llamado myAKSCluster en el myResourceGroup grupo de recursos.

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

Grupos de nodos spot

Un grupo de nodos de acceso puntual es un grupo de nodos de usuario en el que se utiliza un conjunto de escalado de máquinas virtuales de acceso puntual. Use máquinas virtuales de acceso puntual para los nodos del clúster de AKS para aprovechar la capacidad de Azure sin usar a un costo reducido. La cantidad de capacidad disponible sin usar varía en función de 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 la capacidad está disponible. Pero los nodos de acceso puntual no tienen un acuerdo de nivel de servicio (SLA). Un conjunto de escalado spot que respalda el conjunto de nodos spot se despliega en un único dominio de fallos y no proporciona garantías de alta disponibilidad. Cuando Azure necesita la capacidad, la infraestructura de Azure expulsa los nodos de acceso puntual. Recibirá un aviso de hasta 30 segundos antes de la expulsión. Un grupo de nodos de Spot no puede ser el predeterminado del clúster. Use un grupo de nodos de acceso puntual solo 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 obtener más información, consulte Limitaciones de la instancia de Spot.

El siguiente az aks nodepool add comando agrega un grupo de nodos de acceso puntual a un clúster existente que tiene habilitado el escalado automático.

  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 obtener más información, consulte Añadir un grupo de nodos Spot a un clúster de AKS.

Discos de sistema operativo efímero

De forma predeterminada, Azure replica automáticamente el disco del sistema operativo de la máquina virtual en Azure Storage. Este enfoque evita la pérdida de datos si la máquina virtual debe reubicarse en otro host. Pero los contenedores no están diseñados para conservar el estado local, por lo que almacenar el disco del sistema operativo en Azure Storage proporciona ventajas limitadas para AKS. Este enfoque puede provocar un aprovisionamiento de nodos más lento y una mayor latencia de lectura y escritura.

Por el contrario, los discos del sistema operativo efímeros solo se almacenan en el equipo host, como un disco temporal. También proporcionan una latencia de lectura y escritura más baja y un escalado de nodos y actualizaciones de clúster más rápidas. Al igual que un disco temporal, el precio de la máquina virtual incluye un disco de sistema operativo efímero, por lo que no incurre en costos de almacenamiento adicionales.

Importante

Si no se solicitan explícitamente discos administrados para el sistema operativo, AKS toma como valor predeterminado un sistema operativo efímero, siempre que sea posible, para una configuración de grupo de nodos determinada.

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 entrada y salida (E/S) como tamaño de caché en gibibytes (GiB).

Por ejemplo, el tamaño predeterminado de Standard_DS2_v2 máquina virtual de AKS con el tamaño de disco del sistema operativo predeterminado de 100 GB admite un sistema operativo efímero, pero solo tiene un tamaño de caché de 86 GB. Esta configuración tiene como valor predeterminado discos administrados 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 de sistema operativo de 100 GB admite un sistema operativo efímero y tiene un tamaño de caché de 200 GB. Si no especifica el tipo de disco del sistema operativo, un grupo de nodos obtiene de forma predeterminada un sistema operativo efímero.

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 obtener más información, consulte disco del sistema operativo efímero.

Grupos de nodos de Azure Virtual Machines en AKS

Cada grupo de nodos administrados de EKS está respaldado por un grupo de escalado automático de Amazon EC2 que administra Amazon EKS. Esta integración permite a EKS configurar y escalar automáticamente instancias ec2 dentro del grupo de nodos.

Puede configurar grupos de escalado automático para admitir varios tipos de instancia EC2, pero no puede especificar cuántos nodos crear o escalar para cada tipo de instancia. En su lugar, EKS administra el escalado del grupo de nodos en función de la configuración y las directivas deseadas. Este enfoque simplifica y automatiza el proceso de administración del grupo de nodos para que pueda elegir los tipos de instancia ec2 que se adapten a los requisitos de carga de trabajo. También puede iniciar nodos de Amazon Linux autoadministrados mediante la eksctl herramienta de línea de comandos o la consola de administración de AWS.

En el caso de los grupos de nodos de Azure Virtual Machines, AKS configura y arranca cada nodo del agente. En el caso de los grupos de nodos de Azure Virtual Machine Scale Sets, AKS administra el modelo de virtual Machine Scale Sets y lo usa para lograr la coherencia en todos los nodos del agente del grupo de nodos. Puede usar grupos de nodos de Máquinas virtuales para organizar el clúster con máquinas virtuales que mejor se adapten a las cargas de trabajo individuales. También puede especificar cuántos nodos se van a crear o escalar para cada tamaño de máquina virtual.

Un grupo de nodos consta de un conjunto de máquinas virtuales que tienen tamaños diferentes. Cada máquina virtual admite un tipo diferente de carga de trabajo. Estos tamaños de máquina virtual, denominados SKU, se clasifican en diferentes familias optimizadas para fines específicos. Para más información, consulte Tamaños de máquina virtual en Azure.

Para habilitar el escalado de varios tamaños de máquina virtual, el tipo de grupo de nodos de máquinas virtuales usa un ScaleProfile. Este perfil configura cómo se escala el grupo de nodos especificando el tamaño y el recuento de máquinas virtuales deseados. Es ManualScaleProfile un perfil de escalado que especifica el tamaño y el recuento de máquinas virtuales deseados. Solo se permite un tamaño de máquina virtual en .ManualScaleProfile Debe crear un ManualScaleProfile separado para cada tamaño de VM en el pool de nodos.

Al crear un nuevo grupo de nodos de Virtual Machines, necesita al menos uno ManualScaleProfile en ScaleProfile. Puede crear varios perfiles de escalado manual para un único grupo de nodos de Virtual Machines.

Entre las ventajas de los grupos de nodos de Máquinas virtuales se incluyen las siguientes:

  • Flexibilidad: Puede actualizar las especificaciones de nodo para satisfacer sus cargas de trabajo y necesidades.

  • Control ajustado: Los controles de nivel de nodo único ayudan a especificar y combinar nodos de distintas especificaciones para mejorar la coherencia.

  • Eficacia: Puede reducir la superficie del nodo del clúster para simplificar los requisitos operativos.

Los grupos de nodos de Virtual Machines proporcionan una mejor experiencia para cargas de trabajo dinámicas y requisitos de alta disponibilidad. Puede usarlos para configurar varias máquinas virtuales de la misma familia en un grupo de nodos y la carga de trabajo se programa automáticamente en los recursos disponibles que configure.

En la tabla siguiente se comparan los grupos de nodos de Virtual Machines con los grupos de nodos estándar de Virtual Machine Scale Sets .

Tipo de grupo de nodos Capacidades
Grupo de nodos de máquinas virtuales Puede agregar, quitar o actualizar nodos en un grupo de nodos. Los tipos de máquina virtual pueden ser cualquier máquina virtual del mismo tipo de familia, como la serie D o la serie A.
Grupo de nodos de Virtual Machine Scale Sets Puede agregar o quitar nodos del mismo tamaño y tipo en un grupo de nodos. Si agrega un nuevo tamaño de máquina virtual al clúster, debe crear un nuevo grupo de nodos.

Los grupos de nodos de Máquinas virtuales tienen las siguientes limitaciones:

  • No se admite el escalador automático del clúster .
  • InfiniBand no está disponible.
  • No se admiten los grupos de nodos de Windows.
  • Esta característica no está disponible en Azure Portal. Use la CLI de Azure o las API REST para realizar operaciones de creación, lectura, actualización y eliminación (CRUD) o administrar el grupo.
  • No se admite la instantánea del grupo de nodos.
  • Todos los tamaños de máquina virtual de un grupo de nodos deben ser de la misma familia de máquinas virtuales. Por ejemplo, no se puede combinar un tipo de máquina virtual de la serie N con un tipo de máquina virtual de la serie D en el mismo grupo de nodos.
  • Los grupos de nodos de máquinas virtuales permiten hasta cinco tamaños de máquina virtual diferentes por grupo de nodos.

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 ofrecen aprovisionamiento rápido de pods y se paga solo por cada segundo de 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. Solo los pods y nodos de Linux admiten nodos virtuales. 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, consulte Creación y configuración de un clúster de AKS para usar nodos virtuales.

Marcas y etiquetas

Al crear un grupo de nodos, puede agregar taints y etiquetas de Kubernetes y etiquetas de Azure. Cada taint, etiqueta o marcador se aplica a todos los nodos de ese grupo de instancias.

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, use el --labels parámetro y especifique 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.

Los siguientes prefijos están reservados para el uso de AKS y no se pueden usar para los nodos:

  • 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 que no se pueden usar para los nodos. En la tabla, la columna Uso del nodo virtual especifica si los nodos virtuales admiten la etiqueta.

En la columna Uso del nodo virtual:

  • N/A significa que la propiedad no se aplica a los nodos virtuales porque requiere modificar el host.
  • Lo mismo significa que los valores esperados son los mismos para un grupo de nodos virtuales y un grupo de nodos estándar.
  • Virtual sustituye los valores de SKU de VM, ya que los pods de nodos virtuales no exponen las VM subyacentes.
  • 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 Container Instances.
  • Red virtual de nodo virtual es la red virtual que contiene la subred del nodo virtual.
Etiqueta Importancia Ejemplo o opciones Uso del nodo virtual
kubernetes.azure.com/agentpool <agent pool name> nodepool1 Iguales
kubernetes.io/arch amd64 runtime.GOARCH No disponible
kubernetes.io/os <OS type> Linux o Windows Linux
node.kubernetes.io/instance-type <VM size> Standard_NC6 Virtual
topology.kubernetes.io/region <Azure region> westus2 Iguales
topology.kubernetes.io/zone <Azure zone> 0 Iguales
kubernetes.azure.com/cluster <MC_RgName> MC_aks_myAKSCluster_westus2 Iguales
kubernetes.azure.com/mode <mode> User o System User
kubernetes.azure.com/role agent Agent Iguales
kubernetes.azure.com/scalesetpriority <scale set priority> Spot o Regular No disponible
kubernetes.io/hostname <hostname> aks-nodepool-00000000-vmss000000 Iguales
kubernetes.azure.com/storageprofile <OS disk storage profile> Managed No disponible
kubernetes.azure.com/storagetier <OS disk storage tier> Premium_LRS No disponible
kubernetes.azure.com/instance-sku <SKU family> Standard_N Virtual
kubernetes.azure.com/node-image-version <VHD version> AKSUbuntu-1804-2020.03.05 Versión del nodo virtual
kubernetes.azure.com/subnet <nodepool subnet name> subnetName Nombre de subred del nodo virtual
kubernetes.azure.com/vnet <nodepool virtual network name> vnetName Nodo virtual en red virtual
kubernetes.azure.com/ppg <nodepool ppg name> ppgName No disponible
kubernetes.azure.com/encrypted-set <nodepool encrypted-set name> encrypted-set-name No disponible
kubernetes.azure.com/accelerator <accelerator> nvidia No disponible
kubernetes.azure.com/fips_enabled <fips enabled> True No disponible
kubernetes.azure.com/os-sku <os/sku> Consulte Creación o actualización de la SKU de sistema operativo. SKU de Linux

Grupos de nodos de Windows

Puede usar AKS para crear y usar grupos de nodos de contenedor de Windows Server mediante el complemento de red azure Container Networking Interface . Para planear los intervalos de subred y las consideraciones de red necesarios, consulte Configuración de la interfaz de red de contenedor de Azure.

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 obtener más información sobre cómo crear un clúster de AKS que tenga 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 únicos o varios:

  • 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 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 un grupo de nodos deben estar en la misma red virtual.

  • Si crea varios grupos de nodos al crear un clúster, las versiones de Kubernetes para todos los grupos de nodos deben coincidir con la versión del plano de control. Para actualizar las versiones después de configurar el clúster, use 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. Para escalar o reducir manualmente el número de nodos hacia arriba o hacia abajo, use 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

AKS admite el escalado automático de grupos de nodos mediante el escalador automático del clúster. Habilite esta característica en cada grupo de nodos y defina 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 --enable-cluster-autoscaler parámetro habilita el escalador automático del clúster en el nuevo grupo de nodos. Los --min-count parámetros 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

Para deshabilitar el escalador automático del clúster, use el az aks nodepool update comando con el --disable-cluster-autoscaler parámetro .

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

Para volver a habilitar el escalador automático del clúster en un clúster existente, use el comando 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 Uso del escalador automático de clústeres en AKS.

Espacio seguro para pods

Para configurar y ejecutar fácilmente Kata Containers en AKS como una solución totalmente administrada, use Pod Sandboxing. Pod Sandboxing es una característica de AKS que crea un límite de aislamiento entre la aplicación contenedora y el kernel compartido y los recursos de proceso del host de contenedor, como CPU, memoria y redes.

Espacios aislados de pods complementa otras medidas de seguridad o controles de protección de datos para ayudar a las cargas de trabajo de los inquilinos a proteger la información confidencial y cumplir los requisitos normativos, industriales o de gobernanza. Estos requisitos incluyen el estándar de seguridad de datos del sector de tarjetas de pago (PCI DSS), la Organización Internacional de Normalización (ISO) 27001 y la Ley de portabilidad y responsabilidad del seguro de salud (HIPAA).

Implemente aplicaciones en clústeres o conjuntos de nodos independientes para ayudar a aislar las cargas de trabajo pertenecientes a distintos equipos o clientes. Puede usar varios clústeres y grupos de nodos si la organización o la solución de software como servicio (SaaS) las requiere. Pero algunos escenarios se benefician de un único clúster que tiene grupos de nodos de máquina virtual compartidos. Por ejemplo, podría usar un único clúster para ejecutar pods no fiables y fiables en el mismo nodo, o colocar DaemonSets y contenedores con privilegios en el mismo nodo para comunicarse más rápidamente de manera local y agruparse funcionalmente.

El espacio seguro para pods puede ayudarle a aislar efectivamente las aplicaciones de inquilino en los mismos nodos de clúster sin necesidad de ejecutar estas cargas de trabajo en clústeres o grupos de nodos independientes. Es posible que otros métodos requieran que vuelva a compilar el código o que puedan crear otros problemas de compatibilidad. El sandboxing de pods en AKS puede ejecutar cualquier contenedor sin modificar dentro de los límites mejorados de seguridad de una máquina virtual.

El espacio seguro para pods en AKS se basa en los contenedores kata que se ejecutan en el host de contenedor linux de Azure para la pila de AKS, con el fin de proporcionar un aislamiento aplicado por hardware. Los Kata Containers en AKS se basan en un hipervisor de Azure con seguridad reforzada. Logra el aislamiento de cada pod a través de una máquina virtual Kata (VM) anidada y ligera que utiliza recursos de un nodo de máquina virtual principal. En este modelo, cada pod kata obtiene su propio kernel en una máquina virtual invitada kata anidada. Use este modelo para colocar varios contenedores kata en una sola máquina virtual invitada mientras continúa ejecutando contenedores en la máquina virtual primaria. Este modelo proporciona un límite de aislamiento seguro en un clúster de AKS compartido.

Para obtener más información, consulte Compatibilidad con contenedores aislados de vm kata en AKS for Pod Sandboxing.

Host dedicado de Azure

El host dedicado de Azure es un servicio que proporciona servidores físicos dedicados a una sola suscripción de Azure para ayudar a garantizar el aislamiento de hardware en el nivel de servidor físico. Puede aprovisionar estos hosts dedicados dentro de una región, zona de disponibilidad y dominio de error. Puede colocar máquinas virtuales directamente en los hosts aprovisionados.

Use el host dedicado con AKS para proporcionar las siguientes ventajas:

  • El aislamiento de hardware garantiza que ninguna otra máquina virtual se coloque en los hosts dedicados, lo que proporciona una capa adicional de aislamiento para las cargas de trabajo de inquilino. Los hosts dedicados se implementan en los mismos centros de datos y comparten la misma red y la misma infraestructura de almacenamiento subyacente que otros hosts no aislados.

  • El host dedicado proporciona control sobre los eventos de mantenimiento que inicia la plataforma Azure. Puede elegir un periodo de mantenimiento para reducir el impacto en los servicios y contribuir a garantizar la disponibilidad y la privacidad de las cargas de trabajo de los clientes.

El host dedicado puede ayudar a los proveedores de SaaS a garantizar que las aplicaciones de inquilino cumplen los requisitos normativos, del sector y de cumplimiento de gobernanza para proteger la información confidencial. Para obtener más información, consulte Agregar host dedicado a un clúster de AKS.

Karpenter

Karpenter es un proyecto de administración del ciclo de vida de nodo de código abierto creado para Kubernetes. Agregue Karpenter a un clúster de Kubernetes para mejorar la eficacia y el costo de la ejecución de cargas de trabajo en ese clúster. Karpenter busca pods que el programador de Kubernetes marca como no programables. También aprovisiona y administra dinámicamente los nodos que pueden cumplir los requisitos del pod.

Karpenter proporciona un control específico sobre el aprovisionamiento de nodos y la colocación de cargas de trabajo en un clúster administrado. Este control optimiza la asignación de recursos, ayuda a garantizar el aislamiento entre las aplicaciones de cada inquilino y reduce los costos operativos, lo que mejora la multiinquilino. Al construir una solución multitenant en AKS, Karpenter proporciona capacidades útiles que permiten gestionar diferentes requisitos de aplicaciones para apoyar a distintos inquilinos.

Por ejemplo, es posible que necesite algunas aplicaciones de inquilinos para ejecutarse en grupos de nodos optimizados para GPU y otros para ejecutarse en grupos de nodos optimizados para memoria. Si la aplicación requiere una latencia baja para el almacenamiento, puede usar Karpenter para indicar que un pod requiere un nodo que se ejecuta en una zona de disponibilidad específica. A continuación, puede colocar el nivel de almacenamiento y aplicación.

AKS habilita el aprovisionamiento automático de nodos en clústeres de AKS a través de Karpenter. La mayoría de los usuarios deben usar el modo de aprovisionamiento automático de nodos para habilitar Karpenter como complemento administrado. Para obtener más información, consulte aprovisionamiento automático de nodos. Si necesitas una personalización más avanzada, puedes autohospedar Karpenter. Para obtener más información, consulte Proveedor de AKS Karpenter.

Máquinas virtuales confidenciales

La computación confidencial es una medida de seguridad que ayuda a proteger los datos mientras se usan a través del aislamiento y el cifrado asistidos por software o asistidos por hardware. Esta tecnología agrega una capa adicional de seguridad a los enfoques tradicionales, lo que ayuda a proteger los datos en reposo y los datos en tránsito.

La plataforma AWS admite la computación confidencial a través de Nitro Enclaves, que están disponibles en instancias EC2 y Amazon EKS. Las instancias de Amazon EC2 también admiten la paginación anidada segura de virtualización cifrada segura (AMD Secure Encrypted Virtualization Secure Nested Paging -SEV-SNP). El repositorio de GitHub de certificación en tiempo de ejecución proporciona artefactos para compilar e implementar una Amazon Machine Image para EKS con soporte para AMD SEV-SNP.

Azure proporciona a los clientes máquinas virtuales confidenciales para ayudar a cumplir los estrictos requisitos de aislamiento, privacidad y seguridad dentro de un clúster de AKS. Estas máquinas virtuales confidenciales usan un entorno de ejecución de confianza basado en hardware. En concreto, las máquinas virtuales confidenciales de Azure usan la tecnología AMD SEV-SNP. Esta tecnología deniega al hipervisor y a otro código de administración de host acceso a la memoria y el estado de la máquina virtual. Use este enfoque para agregar una capa adicional de defensa y protección contra el acceso de operadores. Para más información, consulte Uso de máquinas virtuales confidenciales en un clúster de AKS e Información general sobre máquinas virtuales confidenciales en Azure.

Estándares federales del proceso de información

Federal Information Process Standards (FIPS) 140-3 es un estándar del gobierno estadounidense que define los requisitos mínimos de seguridad para los módulos criptográficos en los productos y sistemas de tecnología de la información. Al habilitar el cumplimiento de FIPS para grupos de nodos de AKS, puede mejorar el aislamiento, la privacidad y la seguridad de las cargas de trabajo del inquilino. El cumplimiento de FIPS ayuda a garantizar el uso de módulos criptográficos validados para el cifrado, el hash y otras operaciones relacionadas con la seguridad. Use grupos de nodos de AKS habilitados para FIPS para emplear sólidos algoritmos criptográficos y mecanismos, que ayudan a cumplir los requisitos normativos y de cumplimiento del sector. Para obtener más información sobre cómo reforzar la posición de seguridad de los entornos de AKS multiinquilino, consulte Habilitación de FIPS para grupos de nodos de AKS.

Cifrado basado en host

En EKS, la arquitectura puede usar las siguientes características para mejorar la seguridad de los datos:

El cifrado basado en host en AKS refuerza aún más el aislamiento, la privacidad y la seguridad de la carga de trabajo del inquilino. Al habilitar el cifrado basado en host, AKS cifra los datos en reposo en las máquinas host subyacentes. Este enfoque ayuda a proteger la información confidencial del inquilino frente al acceso no autorizado. Al habilitar el cifrado de un extremo a otro, los discos temporales y los discos del sistema operativo efímeros se cifran en reposo a través de claves administradas por la plataforma.

En AKS, los discos del sistema operativo y los discos de datos usan el cifrado del lado servidor a través de claves administradas por la plataforma de forma predeterminada. Las memorias caché de estos discos se cifran en reposo a través de claves administradas por la plataforma. Puede usar su propia clave de cifrado de claves para cifrar la clave de protección de datos. Este método se denomina cifrado envolvente o envoltura. La clave de cifrado que especifique también cifra la memoria caché de los discos del sistema operativo y los discos de datos.

El cifrado basado en host agrega una capa de seguridad para entornos multiinquilino. Los datos de cada inquilino en el disco del sistema operativo y las cachés de discos de datos se cifran en reposo a través de claves administradas por el cliente o administradas por la plataforma, en función del tipo de cifrado de disco seleccionado. Para obtener más información, consulte los siguientes recursos:

Actualizaciones y mejoras

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, 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. Para las actualizaciones que afectan a las máquinas virtuales hospedadas, Azure minimiza los casos que requieren reinicios pausando la máquina virtual al actualizar el host o migrar la máquina virtual en vivo a un host ya actualizado.

Si una actualización requiere un reinicio, Azure proporciona una notificación y un período de tiempo cuando puede iniciar la actualización. 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. Administre las notificaciones de mantenimiento planeado mediante la CLI de Azure, Azure PowerShell o Azure Portal. El mantenimiento planeado detecta si usa automáticamente la característica de actualización automática del clúster y programa las actualizaciones durante la ventana de mantenimiento. Para obtener más información, consulte Uso del mantenimiento planeado para programar ventanas de mantenimiento para el clúster de AKS y el comando az aks maintenanceconfiguration.

Actualizaciones de Kubernetes

Parte del ciclo de vida del clúster de AKS incluye la actualización periódica a la versión más reciente de Kubernetes. Debe aplicar actualizaciones para obtener las últimas características y versiones de seguridad. 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 las configuraciones de max-surge minimiza la interrupción de la carga de trabajo. Esta configuración crea un nodo adicional para reemplazar los nodos con versiones anteriores antes de acordonar o purgar las aplicaciones existentes. Puede personalizar el max-surge valor por grupo de nodos para optimizar el equilibrio entre la velocidad de actualización y la interrupción de la actualización. Un valor mayor max-surge aumenta la velocidad del proceso de actualización, pero un valor grande para max-surge podría provocar interrupciones durante el proceso de actualización.

Por ejemplo, un max-surge valor de 100% proporciona el proceso de actualización más rápido posible duplicando el número de nodos. Pero este valor también purga todos los nodos del grupo de nodos simultáneamente. Es posible que desee utilizar este valor elevado para las pruebas, pero para los grupos de nodos de producción, use un ajuste de max-surge 33%.

AKS acepta valores enteros y porcentuales para el max-surge valor. Un entero, como 5, indica un incremento de cinco nodos adicionales. Puede establecer el valor de porcentaje de max-surge de 1% a 100%, redondeado al número de nodos más cercano. Un valor de 50% indica un valor de aumento de la mitad del número actual de nodos en el grupo.

Durante una actualización, puede establecer el valor de max-surge a un mínimo de 1 y a un valor máximo que sea igual al número de nodos en el clúster de nodos. Puede establecer valores más grandes, pero el número máximo de nodos para max-surge no puede superar el número de nodos del grupo.

Importante

En las operaciones de actualización, las sobrecargas de nodos necesitan suficiente cuota de suscripción para el recuento de max-surge solicitado. Por ejemplo, un clúster que tiene cinco grupos de nodos, cada uno con cuatro nodos, tiene un total de 20 nodos. Si cada grupo de nodos tiene un max-surge valor de 50%, necesita un proceso adicional y una cuota de IP de 10 nodos, o dos nodos veces cinco grupos, para completar la actualización.

Si usa la interfaz de red de contenedor de Azure, asegúrese de que tiene suficientes direcciones IP en la subred para cumplir los requisitos de AKS.

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>

Para actualizar un único grupo de nodos, use az aks nodepool upgrade.

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

Para obtener más información, consulte los siguientes recursos:

Consideraciones de actualización

Tenga en cuenta los siguientes procedimientos recomendados al actualizar la versión de Kubernetes en un clúster de AKS:

  • Debe 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 actualizaciones 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, las actualizaciones automáticas también se inician durante la ventana de mantenimiento especificada. Para más información, consulte Actualización de un clúster de Azure Kubernetes Service.

  • El az aks upgrade comando con la --control-plane-only marca actualiza el plano de control del clúster y no cambia 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 obtener más información, consulte Aumentar las cuotas regionales de vCPU.

  • Configure el max-surge parámetro en función de sus necesidades. Use un valor entero o de porcentaje. 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 la interfaz de red de contenedor de Azure, asegúrese de que la subred tenga suficientes direcciones IP privadas disponibles para los nodos adicionales que cree la max-surge configuración. Para obtener más información, consulte configurar la interfaz de redes de contenedores de Azure en AKS.

  • Si los grupos de nodos de clúster abarcan varias zonas de disponibilidad dentro de una región, el proceso de actualización puede crear temporalmente una configuración de zona desequilibrada. Para más información, consulte Grupos de nodos que abarcan varias zonas de disponibilidad.

Colaboradores

Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.

Autores principales:

Otros colaboradores:

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

Pasos siguientes