Directiva de interrupción del nodo en Azure Kubernetes Service (AKS) (versión preliminar)

A medida que administra y mantiene los clústeres de AKS, determinados cambios de configuración requieren que se vuelva a crear una imagen de los nodos. Esta operación de regeneración de imagen desencadena una actualización gradual que recrea los nodos. Durante una operación de regeneración de imagen, AKS marca el nodo como no programable (evita la programación de nuevos pods), desaloja los pods existentes (expulsándolos y reprogramándolos en otros nodos disponibles, respetando los presupuestos de interrupción de pods) y, a continuación, regenera la imagen del nodo con la configuración actualizada. Este proceso es una recreación completa del nodo, no un reinicio: la máquina virtual subyacente se vuelve a aprovisionar con una imagen nueva del sistema operativo. Aunque los volúmenes persistentes configurados correctamente (mediante discos de Azure, Azure Files u otro almacenamiento externo) no se ven afectados, los datos almacenados en el almacenamiento efímero local del nodo (como volúmenes EmptyDir o rutas de acceso locales) se pierden permanentemente. Estas operaciones son necesarias para aplicar actualizaciones importantes, pero pueden interrumpir la ejecución de cargas de trabajo y afectar a la disponibilidad de las aplicaciones. La directiva de interrupción del nodo proporciona un control específico sobre cuándo estas operaciones perjudiciales pueden continuar, lo que le ayuda a equilibrar la necesidad de actualizaciones con estabilidad operativa.

Importante

Las características en versión preliminar de AKS están disponibles en modalidad de autoservicio y previa suscripción. Las versiones preliminares se proporcionan "tal cual" y "como están disponibles", y están excluidas de los Acuerdos de nivel de servicio y la garantía limitada. Las versiones preliminares de AKS cuentan con soporte parcial por parte del servicio al cliente en la medida de lo posible. Por lo tanto, estas características no están diseñadas para su uso en producción. Para más información, consulte los siguientes artículos de soporte:

¿Qué es la política de disrupción de nodos?

La directiva de interrupción del nodo es una configuración de nivel de clúster que rige cuando se pueden ejecutar las operaciones que requieren la nueva imagen del nodo y la reimplementación. Actúa como una puerta de control, lo que le permite:

  • Alinee las operaciones disruptivas con las ventanas de mantenimiento.
  • Bloquee los cambios de configuración durante períodos empresariales críticos, a la vez que permite que las actualizaciones de imágenes de nodo y las revisiones de seguridad continúen.
  • Mantenga el comportamiento predecible del clúster durante eventos de alto tráfico.

La directiva se aplica a los cambios de configuración iniciados por el usuario que requieren la recreación del nodo, como actualizar certificados de confianza de entidad de certificación (CA) personalizados, modificar la configuración del perfil de seguridad o cambiar la configuración del sistema operativo del nodo.

Note

Es importante destacar que la política no bloquea las actualizaciones de la versión de la imagen del nodo (incluidos los canales de actualización SecurityPatch y NodeImage) ni las actualizaciones de la versión de Kubernetes. Estas operaciones siguen ejecutándose según la programación configurada incluso cuando la directiva está establecida en Block. Para obtener más información, consulte Operaciones de actualización no controladas por la directiva de interrupción del nodo. Además, algunas operaciones de recuperación no están controladas por esta directiva para garantizar el estado y la disponibilidad del clúster. Para obtener más información, consulte Operaciones de recuperación no controladas por la directiva de interrupción del nodo.

Cómo funciona la política de interrupción de nodos

La directiva de interrupción del nodo se configura a nivel de clúster a través de la propiedad nodeDisruptionProfile. Cuando intenta realizar una operación que requiere volver a crear la imagen del nodo, AKS comprueba la configuración actual de la directiva:

  • Evaluación de directivas: AKS evalúa si la operación se permite en función de la directiva actual.
  • Comprobación de la ventana de mantenimiento (si procede): si usa AllowDuringMaintenanceWindow, AKS comprueba si la hora actual se encuentra dentro de la ventana de mantenimiento configurada.
  • Ejecución o bloqueo de la operación: la operación de interrupción del nodo continúa si se permite o se rechaza con un mensaje de error si está bloqueado.

Opciones de directiva

La directiva de interrupción del nodo admite tres configuraciones de directiva:

Policy Description Caso de uso
Allow Permite realizar en cualquier momento las operaciones que requieran recrear la imagen de un nodo. Este es el comportamiento predeterminado. Use cuando quiera priorizar la aplicación de actualizaciones rápidamente y puede tolerar interrupciones de la carga de trabajo.
AllowDuringMaintenanceWindow Bloquea las operaciones que requieren la reconfiguración de imagen del nodo, salvo que tengan lugar dentro de la ventana de mantenimiento aksManagedNodeOSUpgradeSchedule. Use cuando desee limitar las interrupciones a ventanas de mantenimiento específicas que se alineen con la programación operativa.
Block Bloquea todas las operaciones que requieren la recreación de imagen del nodo. Use cuando necesite evitar interrupciones de nodo, como durante períodos empresariales críticos o eventos de alto tráfico.

Note

Al usar AllowDuringMaintenanceWindow, debe configurar una aksManagedNodeOSUpgradeSchedule ventana de mantenimiento. Para obtener más información sobre cómo configurar ventanas de mantenimiento, consulte Uso del mantenimiento planeado para programar y controlar las actualizaciones del clúster de Azure Kubernetes Service. Si no configuras la ventana de mantenimiento, se permiten las operaciones que interrumpen el nodo.

Considerations

Tenga en cuenta las siguientes consideraciones al usar la directiva de interrupción del nodo:

Operaciones cubiertas por la directiva de interrupción del nodo

Operaciones de nivel de clúster

Habilitación de directivas de red y actualización de Azure CNI Overlay

Para instalar los componentes de red necesarios y configurar las reglas de red que protegen y administran la comunicación de pod a pod, es necesario reinstalar la imagen de los nodos.

En la siguiente tabla se muestran las actualizaciones de la política de red que provocan la reinstalación de la imagen:

De En
Ninguno (sin directiva de red) directiva de red de Azure
Ninguno (sin directiva de red) Calico
Azure CNI Azure CNI Overlay
directiva de red de Azure Ninguno (sin directiva de red)
Calico Ninguno (sin directiva de red)

Note

Cambiar entre las directivas de red de Azure y Calico una vez que una de ellas ya está habilitada no requiere volver a crear la imagen.

Cambios en el canal de actualización del sistema operativo del nodo

Cada canal usa una infraestructura de parcheo del sistema operativo y una configuración diferentes que no se pueden modificar en los nodos en funcionamiento.

En la tabla siguiente se muestran los cambios en el canal de actualización del sistema operativo del nodo que desencadenan la recreación de la imagen:

De En
No administrado Ninguno
Sin especificar No administrado
Parche de Seguridad No administrado
NodeImage No administrado
Ninguno No administrado
Sin especificar No administrado
No administrado Parche de Seguridad
No administrado NodeImage

Habilitación de IPv6 de doble pila

Para admitir la comunicación de doble pila, los nodos necesitan configuraciones IP de IPv4 e IPv6 y actualizaciones de la pila de red (como las reglas de nftables).

La siguiente tabla resume la configuración de IP y las actualizaciones de la pila de red que desencadenan la recreación de la imagen:

De En
Solo IPv4 IPv4 + IPv6 (pila doble)

Cambios en el plano de datos de Cilium

Debe instalar o quitar programas eBPF que controlan el procesamiento de paquetes en el nivel de kernel.

La siguiente tabla muestra los cambios en el plano de datos de Cilium que desencadenan la recreación de la imagen:

De En
Ninguno Cilium
Cilium Ninguno

Actualizaciones de configuración del proxy HTTP

Todos los componentes de nodo (contenedor, kubelet, servicios del sistema) necesitan la configuración de proxy actualizada aplicada en todo el sistema. Al actualizar la configuración del proxy HTTP, AKS vuelve a crear imágenes automáticamente de todos los grupos de nodos del clúster.

La política de interrupción de nodos provoca la recreación de la imagen cuando modifica cualquiera de las siguientes propiedades de configuración del proxy HTTP o realiza cualquiera de las siguientes operaciones:

  • httpProxy: dirección URL de proxy para conexiones HTTP
  • httpsProxy: dirección URL de proxy para conexiones HTTPS
  • noProxy: lista de destinos que se excluirán del uso del proxy
  • trustedCa: certificado alternativo de CA codificado en Base64
  • Habilitación del proxy HTTP en un clúster (con --enable-http-proxy)
  • Deshabilitación del proxy HTTP en un clúster (con --disable-http-proxy)
  • Volver a habilitar el proxy HTTP en un clúster que anteriormente lo había deshabilitado

Actualizaciones de certificados de CA personalizados

Debe instalar nuevos certificados de CA en el almacén de confianza del sistema operativo para que afecten a la validación TLS de los servicios internos y los repositorios privados.

La política de interrupción del nodo provoca la recreación de la imagen cuando se agregan, eliminan o actualizan certificados de CA personalizados.

Cambios en la identidad de Kubelet

Debe aplicar nuevas credenciales de identidad a la configuración del nodo. Esto incluye la asignación inicial de identidad, las actualizaciones de identidad y el restablecimiento del perfil de entidad de servicio.

La Directiva de interrupción de nodos provoca la recreación de la imagen cuando actualiza una identidad administrada o una identidad administrada asignada por el usuario del kubelet.

cambios de zona de DNS privado

Debe actualizar la configuración del solucionador DNS para resolver el punto de conexión del servidor de API privado mediante la nueva zona DNS.

La política de interrupción de nodos inicia la regeneración de imagen cuando modifica la configuración de una zona DNS privada en un clúster privado.

Habilitación de la integración con red virtual de API Server

Debe volver a configurar los nodos para comunicarse con el servidor de API a través de la dirección IP del equilibrador de carga interno que se proyecta en la subred delegada.

La directiva de interrupción de nodos provoca una regeneración de imagen al habilitar la integración de VNet del servidor de API en un clúster existente que no la utilizaba anteriormente. Este cambio corresponde a cambiar la propiedad apiServerAccessProfile.enableVnetIntegration (internamente, el campo privateConnectProfile.enabled) de false (o sin establecer) a true:

De En
apiServerAccessProfile.enableVnetIntegration: false o no establecido apiServerAccessProfile.enableVnetIntegration: true

Cambios en el enrutamiento del host de eBPF

Debe instalar o quitar programas eBPF que proporcionen reenvío de paquetes de alto rendimiento (modo de aceleración BpfVeth).

En la siguiente tabla se detallan los cambios en el enrutamiento del host de eBPF que obligan a reinstalar la imagen:

De En
Enrutamiento estándar Enrutamiento de host eBPF habilitado
Enrutamiento del host con eBPF habilitado Enrutamiento estándar

Operaciones de nivel de grupo de nodos

Estas operaciones solo afectan a los grupos de nodos específicos en los que se realizan cambios. Inician una recreación gradual de la imagen en esos grupos de nodos:

Actualizaciones del perfil DNS local

Debe aplicar cambios al demonio de almacenamiento en caché de DNS y a las reglas de reenvío de DNS en el nivel de nodo.

La directiva de interrupción de nodos desencadena la recreación de la imagen al modificar la configuración de un perfil de LocalDNS.

Cambios de seguridad de Trusted Launch

No se puede cambiar la configuración del firmware de la máquina virtual ni la configuración del proceso de arranque en las máquinas virtuales en ejecución. Estos cambios requieren que vuelva a crear las máquinas virtuales.

En la tabla siguiente se muestran los cambios de seguridad de Trusted Launch que obligan a recrear la imagen:

Configuration De En
vTPM (módulo de plataforma segura virtual) Disabled Habilitado
vTPM (módulo de plataforma segura virtual) Habilitado Disabled
Arranque seguro Disabled Habilitado
Arranque seguro Habilitado Disabled

Cambios en la transmisión de artefactos

Debe instalar o eliminar componentes de transmisión de artefactos para permitir una extracción más rápida de imágenes de contenedor mediante la transmisión de capas de imagen bajo demanda.

En la siguiente tabla se muestran los cambios en la transmisión de artefactos que obligan a recrear la imagen:

De En
Disabled Habilitado
Habilitado Disabled

Actualizaciones del perfil de Windows GMSA (solo para grupos de nodos de Windows)

Debe aplicar la nueva configuración de gMSA, la configuración del servidor DNS y las credenciales para unirse al dominio para la integración con Active Directory en los nodos de Windows.

La directiva de interrupción de nodos desencadena la regeneración de imagen de los grupos de nodos de Windows cuando un cambio en GMSA requiere aplicar una nueva configuración de nodo:

De En Inicia la regeneración de la imagen
GMSA deshabilitado GMSA activada
GMSA activado (servidor DNS o dominio raíz configurado o modificado) GMSA habilitada con el servidor DNS actualizado o el dominio raíz
GMSA habilitado (servidor DNS configurado) GMSA deshabilitado
GMSA habilitado (sin servidor DNS configurado) GMSA deshabilitado No (no hay ninguna configuración de nodo que se aplique)

Datos adjuntos del grupo de reserva de capacidad

Debe volver a crear las máquinas virtuales subyacentes para que se asignen a partir de la capacidad reservada en el grupo de reserva de capacidad (CRG). Los nodos existentes no se aprovisionaron con el CRG, por lo que AKS debe regenerar la imagen del grupo de nodos para asociar esos nodos a la reserva.

La política de interrupción de nodos provoca la recreación de la imagen al adjuntar un grupo de reserva de capacidad a un grupo de nodos existente que todavía no tiene asociado ninguno.

De En Inicia la reinstalación de la imagen
No hay ningún grupo de reserva de capacidad asociado Grupo de reserva de capacidad adjunto

Operaciones que aún no están cubiertas por la directiva de interrupción del nodo

Los siguientes cambios de configuración requieren la recreación de la imagen del nodo, pero todavía no están contemplados por la Política de interrupción de nodos. Una futura actualización de la versión secundaria de Kubernetes abarcará estos cambios a medida que este cambio introduce un nuevo comportamiento.
Después de realizar estos cambios de configuración, debe ejecutar az aks nodepool upgrade manualmente con --node-image-only para aplicar los cambios a los nodos.

  • Cambios en la configuración de SSH: cambio de los métodos de acceso SSH (SSH deshabilitado, Entra ID SSH basado en SSH o SSH de usuario local) o actualización de claves públicas SSH en grupos de nodos.
  • Cambios de restricción de IMDS: habilitación o deshabilitación de la restricción de Instance Metadata Service (IMDS) para bloquear el acceso del pod al punto de conexión de IMDS.
  • Cambios en el perfil de arranque: cambiar el perfil de arranque, como cambiar el artifactSource entre Direct y Cache, o cambiar el containerRegistryId (el Azure Container Registry utilizado para clústeres con aislamiento de red).
  • Cambios en el tipo de salida: Modificación del tipo de conectividad de salida del clúster (loadBalancer, userDefinedRouting, managedNATGateway o userAssignedNATGateway).

Operaciones de actualización no controladas por la directiva de interrupción del nodo

La directiva de interrupción del nodo no controla las siguientes operaciones de actualización. Estas operaciones de actualización continúan independientemente de la configuración de directiva. Las actualizaciones son iniciadas por el cliente o iniciadas por AKS dentro de las ventanas de mantenimiento planeado. Para permitir que estas operaciones continúen según lo programado, manténgalas fuera intencionadamente del ámbito de la directiva de interrupción del nodo. Además, si las operaciones cubiertas por la directiva de interrupción del nodo se incluyen en los mismos cambios de configuración con actualizaciones, no se controlarán mediante la directiva de interrupción del nodo.

  • Actualizaciones de la versión de la imagen de nodo: actualización a una nueva versión de imagen del sistema operativo del nodo (manualmente o a través de canales de actualización automática). Esta operación es la operación de recreación de imagen más común e incluye parches de seguridad, actualizaciones del sistema operativo y versiones de imagen de nodo de AKS.
  • Actualizaciones de la versión de Kubernetes: actualización de la versión de Kubernetes en un grupo de nodos, que aplica nuevos archivos binarios de Kubernetes, configuración de kubelet actualizada y cambios de nivel de sistema operativo.

Operaciones de recuperación no controladas por la directiva de interrupción del nodo

La directiva de interrupción del nodo no controla las siguientes operaciones de recuperación automatizadas. Estas operaciones pueden producirse independientemente de la configuración de directiva para garantizar el estado y la recuperación del clúster.

  • Reversión de la configuración del grupo de nodos: cuando se produce un error en una operación de actualización del grupo de nodos debido a problemas de configuración o infraestructura no válidos, AKS revierte automáticamente al último estado correcto conocido y vuelve a crear una imagen de los nodos para revertir la configuración.
  • Operaciones de restauración administrativa de clústeres: cuando los ingenieros de soporte técnico de Azure realizan la restauración administrativa de clústeres durante la resolución de incidentes, los nodos se reprovisionan para garantizar la coherencia entre el estado del plano de control y la configuración de los nodos.
  • Actualizaciones de credenciales de identidad de nodo: AKS actualiza periódicamente las credenciales de identidad del nodo para la seguridad y el cumplimiento. Estas actualizaciones iniciadas por el sistema desencadenan la recreación de los nodos para aplicar las nuevas credenciales en todos los grupos de nodos.

Integración con mantenimiento planeado

La política de interrupción de nodos funciona perfectamente con las ventanas de mantenimiento programado de AKS. Cuando establece la directiva en AllowDuringMaintenanceWindow, las operaciones disruptivas se ajustan a su aksManagedNodeOSUpgradeSchedule periodo de mantenimiento, lo que garantiza que:

  • Los cambios solo se producen durante las ventanas de tiempo aprobadas.
  • Las operaciones se coordinan con otro mantenimiento programado.
  • Los equipos son conscientes de cuándo pueden producirse interrupciones.

Esta integración proporciona un enfoque completo para administrar los cambios del clúster y minimizar el impacto en las cargas de trabajo en ejecución.

Note

Al usar AllowDuringMaintenanceWindow, debe configurar una aksManagedNodeOSUpgradeSchedule ventana de mantenimiento. El uso de la default ventana de mantenimiento o aksManagedAutoUpgradeSchedule (actualización automática del clúster) no satisface este requisito. Si establece AllowDuringMaintenanceWindow sin tener configurada una ventana aksManagedNodeOSUpgradeSchedule, se permiten todas las operaciones disruptivas (la política no tiene ninguna ventana con la que restringirlas). Para obtener más información sobre cómo configurar ventanas de mantenimiento, consulte Uso del mantenimiento planeado para programar y controlar las actualizaciones del clúster de Azure Kubernetes Service.

procedimientos recomendados

Tenga en cuenta estas recomendaciones al implementar la directiva de interrupción del nodo:

  • Use AllowDuringMaintenanceWindow para producción: combínelo con ventanas de mantenimiento planificadas para controlar cuándo se producen interrupciones en entornos de producción.
  • Establecer Block durante períodos críticos: bloquee temporalmente las operaciones disruptivas durante eventos de tráfico alto, lanzamientos de productos o respuesta a incidentes. No utilice Block indefinidamente. Aunque Block es adecuado para bloqueos a corto plazo (eventos planificados, respuesta a incidentes).
  • Permitir flexibilidad en entornos que no son de producción: use Allow en entornos de desarrollo y pruebas en los que la iteración rápida es más importante que la estabilidad.
  • Comunicar los cambios de directiva: asegúrese de que el equipo comprende la directiva actual y sabe cuándo se pueden bloquear las operaciones.
  • Planear las ventanas de mantenimiento adecuadamente: ajuste el tamaño de las ventanas de mantenimiento para adaptarse a las operaciones que necesita realizar.
  • Probar el comportamiento de la directiva: valide los ajustes de la directiva en entornos que no sean de producción antes de aplicarlos a clústeres de producción.
  • Supervisión de operaciones bloqueadas: realice un seguimiento de cuándo se bloquean las operaciones para optimizar la programación de mantenimiento.