Protección de nodos (versión preliminar) en Azure Kubernetes Service (AKS)

Node Hardening es una función opcional para grupos de nodos de Linux que protege la estabilidad del nodo cuando las cargas de trabajo someten a los nodos a presión de CPU, memoria o disco. Al habilitar La protección de nodos en un clúster, AKS cambia la forma en que cada nodo reserva y aplica recursos para los componentes de Kubernetes y los servicios del host, y cómo el kubelet expulsa los pods cuando los recursos escasean.

En este artículo se explica qué cambios realiza Node Hardening, compara los valores predeterminados protegidos con los valores predeterminados estándar de AKS y muestra cómo habilitar, comprobar, personalizar y deshabilitar la característica.

Ventajas del fortalecimiento de nodos

En nodos ocupados o de ráfaga, las cargas de trabajo pueden consumir recursos que necesitan el kubelet, el entorno de ejecución del contenedor y los servicios de host. Cuando esto sucede, los nodos pueden dejar de responder, informar de un estado NotReady o finalizar los pods abruptamente. La protección de nodos reduce estos riesgos de las siguientes maneras:

• Reservas forzadas: De forma predeterminada, AKS usa valores de kube-reserved solo para calcular la capacidad que el programador puede asignar a los pods. Mediante el refuerzo de nodos, el kubelet también aplica la capacidad kube-reserved y system-reserved a través de grupos de control de Linux (cgroups). El kubelet y containerd se ejecutan en un grupo cgroup dedicado kubereserved.slice, por lo que mantienen su recurso compartido de CPU reservado y memoria incluso cuando los pods saturan el nodo.
• Capacidad dedicada para los servicios del host: El refuerzo de nodos agrega una asignación reservada del sistema para los servicios del sistema operativo del host, que se ejecutan en system.slice.
• Más margen de memoria: El umbral estricto de expulsión para la memoria disponible se ajusta en función de la memoria del nodo, por lo que el kubelet expulsa los pods antes de que al nodo le quede muy poca memoria.
• Desalojo ordenado: Los umbrales de desalojo flexibles permiten al kubelet desalojar los pods de forma ordenada, con un período de gracia de terminación, cuando la memoria o el espacio en disco se agotan. El desalojo forzoso, que finaliza inmediatamente los pods, actúa como último recurso.
• Reservas en función de la densidad de pods: El cálculo de la memoria reservada para kube aumenta en función del número máximo de pods por nodo, lo que tiene en cuenta la sobrecarga de kubelet y containerd de ejecutar más pods.

¿Qué cambia al habilitar Node Hardening?

En las tablas siguientes se comparan los valores predeterminados estándar para los nodos de Linux que ejecutan Kubernetes 1.29 o versiones posteriores con los valores predeterminados que AKS aplica cuando se habilita la protección de nodos.

Reservas de recursos

Umbrales de desalojo

Aplicación de cgroups

Dado que Node Hardening reserva más capacidad, los nodos notifican menos capacidad asignable para los pods. Por ejemplo, en un nodo con 4 vCPU y 16 GiB de memoria que usa Azure CNI, al habilitar el endurecimiento de nodos se reduce la capacidad asignable de la siguiente manera:

• Con el máximo predeterminado de 250 pods por nodo, unos 570 MiB de memoria más, 100 millicores de CPU y 1 GiB de almacenamiento efímero.
• Con un máximo de 30 pods por nodo, limitado a aproximadamente 1,3 GiB de memoria, 100 millicores de CPU y 1 GiB de almacenamiento efímero.

Los umbrales de desalojo no estrictos no reducen la capacidad asignable. Solo cambian cuando el kubelet comienza a expulsar pods.

Considerations

Tenga en cuenta las siguientes consideraciones antes de habilitar Node Hardening:

• Habilita la protección de nodos en el nivel de clúster y se aplica a todos los grupos de nodos de Linux del clúster. No se puede habilitar para grupos de nodos individuales y no afecta a Windows grupos de nodos.
• Los nodos notifican una capacidad asignable menor, por lo que es posible que los pods que caben en un nodo antes de habilitar Node Hardening no se ajusten después. Revise las solicitudes de recursos de pod y los tamaños del grupo de nodos.
• Los servicios de host en system.slice comparten un límite de memoria dura igual a la memoria reservada del sistema. Si ejecuta sus propios agentes en nodos como servicios de systemd, como seguridad, supervisión o agentes de reenvío de registros, esos agentes se contabilizan en este límite. Valide el uso de memoria y la estabilidad antes de usar Node Hardening en producción.
• Los valores establecidos en la configuración de kubelet personalizada de un grupo de nodos anulan los valores predeterminados correspondientes de Node Hardening. Para obtener más información, consulte Personalizar la configuración de protección de nodos.
• Si deshabilita Node Hardening más adelante, los grupos de nodos existentes mantienen la configuración reforzada de expulsión temporal, incluso después de que se les reinstale la imagen a sus nodos. Para quitar esta configuración, debe crear nuevos grupos de nodos. Para obtener más información, consulte Deshabilitar la protección de nodos.
• Los valores predeterminados pueden cambiar mientras la característica está en versión preliminar. Comience con un clúster que no sea de producción y valide las cargas de trabajo en condiciones representativas de presión de nodo.

Prerequisites

• Una suscripción a Azure. Si no tiene una, cree una cuenta gratuita.
• Un clúster de AKS con grupos de nodos de Linux o permisos para crear uno.
• La aks-preview extensión de CLI de Azure y la CustomNodeConfigPreview marca de función, como se describe en las secciones siguientes.

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

1. Instale la aks-preview extensión mediante el az extension add comando .

   az extension add --name aks-preview
   

2. Actualice a la versión más reciente de la extensión mediante el az extension update comando .

   az extension update --name aks-preview
   

Registro de la marca de característica CustomNodeConfigPreview

1. Registre el indicador de función CustomNodeConfigPreview con el comando az feature register.

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

   Tarda unos minutos en que el estado muestre Registrado.

2. Compruebe el estado del registro mediante el az feature show comando .

   az feature show --namespace "Microsoft.ContainerService" --name "CustomNodeConfigPreview"
   

3. Cuando el estado muestre Registrado, actualice la inscripción del proveedor de recursos Microsoft.ContainerService mediante el comando az provider register.

   az provider register --namespace "Microsoft.ContainerService"
   

Activar la protección de nodos

En la versión preliminar, Node Hardening no está habilitado de forma predeterminada.

Habilitar la protección de nodos en un clúster nuevo

Cree un clúster con Node Hardening habilitado mediante el comando az aks create con el parámetro --enable-node-hardening.

Este comando requiere la extensión aks-preview y el indicador de característica CustomNodeConfigPreview. Para obtener más información, consulte Requisitos previos.

az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --enable-node-hardening \
    --generate-ssh-keys

Para confirmar el cambio, consulte Verificar la configuración de protección del nodo.

Habilitar la protección de nodos en un clúster existente

Habilite La protección de nodos en un clúster existente mediante el az aks update comando con el --enable-node-hardening parámetro .

Este comando requiere la extensión aks-preview y el indicador de función CustomNodeConfigPreview. Para obtener más información, consulte Requisitos previos.

az aks update \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --enable-node-hardening

Para confirmar el cambio, consulte Verificar la configuración de protección de nodos.

Verificar la configuración de hardening de nodos

1. Obtenga las credenciales del clúster mediante el comando az aks get-credentials.

   az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>
   

2. Revise la configuración efectiva de reserva y desalojo de kubelet en un nodo consultando el punto de conexión de configuración de kubelet.

   kubectl get --raw "/api/v1/nodes/<node-name>/proxy/configz" | jq '.kubeletconfig | {kubeReserved, systemReserved, evictionHard, evictionSoft, evictionSoftGracePeriod, evictionMaxPodGracePeriod, enforceNodeAllocatable}'
   

   En un nodo protegido, systemReserved y evictionSoft contienen valores, e enforceNodeAllocatable incluye kube-reserved y system-reserved.

3. Compare la capacidad del nodo con sus recursos asignables.

   kubectl get node <node-name> -o jsonpath='{.status.capacity}{"\n"}{.status.allocatable}{"\n"}'
   

   En un nodo protegido, la CPU, la memoria y el almacenamiento efímero asignables son inferiores a la capacidad. La diferencia es igual a los valores de kube-reserved y system-reserved en Reservas de recursos, además de los umbrales de expulsión duros en Umbrales de expulsión. Por ejemplo, en un nodo con 4 vCPU y 16 GiB de memoria que usa Azure CNI, la CPU asignable es 240 millicores inferior a la capacidad: 140 millicores de CPU reservada para kube y 100 millicores de CPU reservada por el sistema.

Personalizar la configuración de protección de nodos

Puede anular los valores predeterminados de kube-reserved y de expulsión de un grupo de nodos Linux mediante una configuración personalizada de kubelet. Esta configuración requiere el indicador de función CustomNodeConfigPreview. Puede usarlos tanto si el endurecimiento de nodos está habilitado en el clúster como si no. AKS administra los valores reservados por el sistema y la aplicación de cgroup, y no puedes personalizarlos.

Cada configuración sobrescribe una fila en las tablas Reservas de recursos o Umbrales de expulsión. Las filas reservadas de Kube corresponden a las configuraciones de kubeReserved. Las filas de expulsión dura corresponden a las configuraciones de hardEvictionThreshold. Las filas de desalojo suave corresponden a las opciones softEvictionThreshold y softEvictionGracePeriod. El período máximo de gracia de terminación del pod corresponde a evictionMaxPodGracePeriodInSeconds.

Puede configurar las siguientes opciones:

• Para conocer los valores permitidos, los mínimos y las reglas de validación para cada configuración, consulte Parámetros de configuración de nodos personalizados para AKS.
• Para cada señal de expulsión, establezca el umbral de desalojo flexible y su período de gracia coincidente y asegúrese de que cada umbral de desalojo flexible sea mayor que el umbral de desalojo estricto para la misma señal.

1. Cree un archivo de configuración de kubelet, como nodehardening-kubelet.json, con la configuración que desea personalizar. En el ejemplo siguiente se establecen todos los valores configurables. Establece kube-reserved en 200 millicores de CPU y 1024 MiB de memoria. Establece umbrales de expulsión duros de 512Mi de la memoria disponible, 10% del espacio disponible del sistema de archivos y 5% de inodos libres. Establece umbrales de expulsión temporal de 1Gi, 12%y 7% con períodos de gracia de 30 segundos, 2 minutos y 2 minutos. También establece un período de gracia de terminación de pod máximo de 60 segundos.

   {
     "kubeReserved": {
       "cpuMillicores": 200,
       "memoryMB": 1024
     },
     "hardEvictionThreshold": {
       "memoryAvailable": "512Mi",
       "nodeFsAvailable": "10%",
       "nodeFsInodesFree": "5%"
     },
     "softEvictionThreshold": {
       "memoryAvailable": "1Gi",
       "nodeFsAvailable": "12%",
       "nodeFsInodesFree": "7%"
     },
     "softEvictionGracePeriod": {
       "memoryAvailable": "30s",
       "nodeFsAvailable": "2m",
       "nodeFsInodesFree": "2m"
     },
     "evictionMaxPodGracePeriodInSeconds": 60
   }
   

2. Cree un grupo de nodos de Linux que use el archivo de configuración mediante el comando az aks nodepool add con el parámetro --kubelet-config.

   az aks nodepool add \
       --resource-group <resource-group-name> \
       --cluster-name <cluster-name> \
       --name <node-pool-name> \
       --kubelet-config ./nodehardening-kubelet.json
   

   También puede usar el --kubelet-config parámetro con el az aks create comando para aplicar la configuración al grupo de nodos inicial del clúster.

Deshabilitar el endurecimiento de nodos

Deshabilite la protección de nodos mediante el comando az aks update con el parámetro --disable-node-hardening.

Este comando requiere la extensión aks-preview y el indicador de función CustomNodeConfigPreview. Para obtener más información, consulte Requisitos previos.

az aks update \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --disable-node-hardening

Deshabilitar la protección de nodos desactiva la configuración de nivel de clúster, pero no se aplica inmediatamente a los nodos existentes. Los nodos existentes mantienen toda la configuración protegida hasta que se reinstale la imagen, por ejemplo, durante una actualización de la imagen del nodo. Después de volver a crear una imagen de nodo, se aplican los siguientes cambios:

• Se revierte a los valores predeterminados estándar de AKS: Recursos reservados y reservados por el sistema de Kube, umbrales de expulsión duros y cumplimiento de cgroup. La capacidad asignable del nodo aumenta en consecuencia.
• Conservado: Los umbrales de expulsión no estricta, los períodos de gracia de expulsión no estricta y el período máximo de gracia de terminación del pod durante la expulsión no estricta.

Puede establecer una configuración de kubelet personalizada solo al crear un clúster o grupo de nodos, por lo que no se puede quitar la configuración de expulsión temporal retenida de un grupo de nodos existente. Para quitarlos, cree un nuevo grupo de nodos que anule su configuración explícitamente, mueva las cargas de trabajo al nuevo grupo de nodos y, a continuación, elimine el grupo de nodos antiguo.

1. Cree un archivo de configuración de kubelet, como remove-soft-eviction.json. En el ejemplo siguiente se establecen todos los umbrales de desalojo flexible y todos los períodos de gracia en una cadena vacía, lo que desactiva el desalojo flexible para esa señal. También establece el período máximo de gracia de terminación del pod en 0, que es el valor predeterminado estándar de AKS.

   {
     "softEvictionThreshold": {
       "memoryAvailable": "",
       "nodeFsAvailable": "",
       "nodeFsInodesFree": ""
     },
     "softEvictionGracePeriod": {
       "memoryAvailable": "",
       "nodeFsAvailable": "",
       "nodeFsInodesFree": ""
     },
     "evictionMaxPodGracePeriodInSeconds": 0
   }
   

2. Cree un grupo de nodos de Linux que use el archivo de configuración mediante el comando az aks nodepool add con el parámetro --kubelet-config.

   az aks nodepool add \
       --resource-group <resource-group-name> \
       --cluster-name <cluster-name> \
       --name <node-pool-name> \
       --kubelet-config ./remove-soft-eviction.json
   

3. Mueva las cargas de trabajo al nuevo grupo de nodos y elimine el grupo de nodos anterior. Para obtener más información, consulte Cambiar el tamaño de los grupos de nodos en AKS.

Para confirmar la configuración en un nodo, consulte Comprobación de la configuración de protección de nodos. En los nodos del nuevo grupo de nodos, el valor de evictionSoft está vacío.

Contenido relacionado

• Reservas de recursos de nodo en AKS
• Personaliza la configuración del nodo para grupos de nodos de AKS
• Parámetros de configuración de nodo personalizados para AKS
• Desalojo por presión del nodo en Kubernetes
• Reserva de recursos de cómputo para demonios del sistema en Kubernetes