Funcionamiento de las actualizaciones de clústeres de Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) realiza actualizaciones graduales para minimizar la interrupción de las cargas de trabajo en ejecución.

Para la mayoría de las cargas de trabajo de producción, AKS Automatic es la opción predeterminada recomendada cuando sea aplicable. AKS Automatic incluye configuraciones predeterminadas listas para producción para las operaciones de actualización, como actualizaciones automáticas de la versión de Kubernetes, actualizaciones automáticas de las imágenes del sistema operativo (SO) de los nodos, operaciones administradas de los nodos del sistema y protecciones integradas que reducen el trabajo manual. Para obtener más información, consulte Introducción a AKS Automatic.

En este artículo se explica la mecánica de actualización de AKS y se resalta dónde difiere AKS Automatic y AKS Standard.

Prerrequisitos

Modelo de actualización: AKS Automatic y AKS Standard

Los modos de clúster de AKS Automatic y AKS Standard usan los mismos aspectos básicos de actualización de Kubernetes, pero difieren en los valores predeterminados y en la propiedad operativa.

Problema de actualización AKS Automatic AKS Standard
Posicionamiento de producción Valor predeterminado recomendado para la mayoría de las cargas de trabajo de producción cuando corresponda Modelo flexible con una configuración más manual de forma predeterminada
Actualizaciones de la versión secundaria de Kubernetes Canal de actualización automática preconfigurado Manual por defecto, canal automático opcional
Actualizaciones de imágenes del OS del nodo Canal de imagen del sistema operativo del nodo automático preconfigurado Manual por defecto, canal automático opcional
Operaciones del grupo de nodos del sistema Administrado por AKS Administrado por el cliente
Ventanas de mantenimiento planeado Disponible de forma predeterminada Configuración opcional
Controles de interrupción de la carga de trabajo Propiedad del cliente, incluida la estrategia de réplica, el comportamiento de disponibilidad y la política de interrupción Propiedad del cliente, incluida la estrategia de réplica, el comportamiento de disponibilidad y la política de interrupción

Note

AKS Automatic simplifica las operaciones de plataforma, pero todavía se aplica la responsabilidad compartida. El diseño de la disponibilidad a nivel de carga de trabajo y el comportamiento de la directiva de expulsión siguen siendo responsabilidad del cliente.

Comportamiento de actualización gradual en AKS

AKS actualiza los grupos de nodos de forma escalonada, manteniendo la capacidad mientras reemplaza los nodos o reinstala su imagen. Este comportamiento es el mismo en todos los modos de clúster de AKS.

A grandes rasgos, AKS:

  1. Agrega capacidad de sobrecarga temporal en función de la configuración de actualización.
  2. Marca los nodos como no programables y desaloja las cargas de trabajo para moverlas.
  3. Recrea la imagen de los nodos o los reemplaza por la versión de destino.
  4. Quita la capacidad de sobrecarga temporal después de la finalización.

Ejemplo de actualización gradual

En este ejemplo se muestra cómo actualizar un clúster de dos nodos de Kubernetes 1.30 a 1.31 con maxSurge establecido en 1.

Paso 1: Configuración inicial

El clúster comienza con dos nodos que ejecutan la versión 1.30, cada uno alojando pods de aplicación.

Diagrama que muestra la configuración inicial del clúster con dos nodos que ejecutan la versión 1.30, cada uno hospeda los pods de la aplicación y un nodo de sobrecarga recién creado.

  • Nodo 1: Pod A, Pod B
  • Nodo 2: Pod C, Pod D
  • Nodo de Expansión: vacío (excepto DaemonSets y nuevos Pods)

Paso 2: Aislar y purgar el primer nodo

AKS cordona el nodo 1 para evitar la programación de nuevos pods y, a continuación, vacía los pods existentes.

Diagrama que muestra que el Nodo 1 está aislado y vaciado, con los pods expulsados y reemplazados en otros nodos disponibles.

  • Pod A → expulsado y reemplazado en el Surge Node
  • Pod B → expulsado y reemplazado en el nodo 2

Paso 3: Actualizar el primer nodo

El nodo 1 se vuelve a crear con la versión 1.31 de Kubernetes, mientras que los pods continúan ejecutándose en otros nodos.

Diagrama que muestra el nodo 1 reinstalado con la versión 1.31 mientras los pods de aplicaciones continúan ejecutándose en el nodo 2 y el nodo adicional.

  • Nodo 1: actualizado a la versión 1.31
  • Nodo 2: Pod B, Pod C, Pod D
  • Nodo de sobrecarga: pod A

Paso 4: Aislar y drenar el segundo nodo

AKS repite el proceso para el Nodo 2, los pods se expulsan y el planificador los redistribuye a los nodos disponibles adecuados.

Diagrama en el que se muestra que el nodo 2 está acordonado y purgado, con pods expulsados y reemplazados en el nodo 1 actualizado y el nodo de sobrecarga.

  • Pod C, B → expulsada y reemplazada en el nodo 1
  • Pod D → expulsada y reemplazada en el nodo de sobrecarga
  • Nodo 2: aislado y reimaginado a v1.31

Paso 5: Eliminación del nodo de sobrecarga

Una vez actualizados todos los nodos permanentes, el nodo de sobrecarga se acordona, purga y elimina.

Diagrama en el que se muestra el Surge Node siendo vaciado y eliminado, con pods desalojados y reemplazados en los nodos permanentes actualizados.

  • Pod A → expulsada y reemplazada en el nodo 1
  • Pod D → expulsado y reemplazado en el nodo 2
  • Nodo de sobrecarga: eliminado

Estado final

Todos los nodos ahora ejecutan Kubernetes versión 1.31 con pods distribuidos en el clúster.

  • Nodo 1 (v1.31):Pod A, Pod C
  • Nodo 2 (v1.31):Pod B, Pod D

Comportamiento restrictivo del Pod Disruption Budget (PDB)

Si un PDB restrictivo bloquea la expulsión, se puede retrasar o evitar la purga de nodos. AKS puede usar el comportamiento Cordon de nodo no drenable para seguir actualizando otros nodos admisibles según la configuración establecida. Los nodos bloqueados pueden permanecer en una versión anterior hasta que se resuelva la condición de bloqueo.

Ejemplo de PDB restrictivo

En este ejemplo se muestra cómo actualizar un clúster de dos nodos de Kubernetes 1.30 a 1.31 con establecido maxSurge en 2 y una PDB que bloquea la operación de purga del primer nodo.

Paso 1: Configuración inicial con PDB restrictivo

El clúster comienza con dos nodos que ejecutan la versión 1.30, con una PDB que protege el pod A contra la expulsión.

Diagrama que muestra el clúster inicial con dos nodos, un nodo de sobrecarga y un presupuesto de interrupción del pod que protege el pod A frente a la expulsión.

  • Nodo 1: Pod A (protegido por PDB), Pod B
  • Nodo 2: Pod C, Pod D
  • Nodos de sobrecarga: 2 nodos recién creados
  • PDB: impide la expulsión del Pod

Paso 2: Intentar purgar el primer nodo (bloqueado)

AKS marca el nodo 1 como no programable, pero no puede desalojar el pod A debido a las restricciones de PDB.

Diagrama que muestra el Node 1 acordonado pero con el drenado bloqueado por el Presupuesto de interrupción de pods, con el Pod A atascado y el Pod B expulsado al Nodo de refuerzo.

  • Nodo 1: acordonado y marcado como en cuarentena (el Pod A bloqueado)
  • Pod B → expulsada y reemplazada en el nodo de sobrecarga 1, mientras que el nodo de sobrecarga 2 no se usa temporalmente
  • Estado: actualización del nodo 1 bloqueada

Paso 3: Continuar con el segundo nodo

Con el nodo 1 en cuarentena, AKS continúa actualizando el nodo 2.

Diagrama que muestra el nodo 1 en cuarentena mientras el nodo 2 se acordona y se purga correctamente, con los pods movidos al nodo de sobrecarga.

  • Nodo 1: permanece en cuarentena (v1.30)
  • Nodo 2: marcado y drenado correctamente
  • Pod C → expulsada y reemplazada en el nodo de sobrecarga 2
  • Pod D → expulsada y reemplazada en el nodo de sobrecarga 2

Paso 4: Actualización del segundo nodo

El nodo 2 se ha reinstalado correctamente con la versión 1.31 de Kubernetes.

Diagrama que muestra el nodo 2 actualizado correctamente a la versión 1.31, mientras que el nodo 1 permanece en cuarentena con pod A.

  • Nodo 1: todavía en cuarentena (v1.30) con pod A
  • Nodo 2: actualizado a la versión 1.31
  • Nodo de sobrecarga 1: pod B
  • Nodo de sobrecarga 2: pod C, pod D

Paso 5: Un nodo de sobrecarga se convierte en reemplazo permanente a medida que se quita otro

Dado que el nodo 1 permanece en cuarentena, el nodo de sobrecarga 1 se convierte en el reemplazo permanente que ejecuta v1.31 y se elimina el nodo de sobrecarga 2.

Diagrama que muestra que el nodo de sobrecarga se convierte en un reemplazo permanente que ejecuta la versión 1.31 mientras el nodo 1 permanece en cuarentena.

  • Nodo 1: en cuarentena (v1.30): requiere intervención manual
  • Pod C, pod D → expulsado del nodo de sobrecarga 2 y reemplazado en el nodo 2
  • Nodo de sobrecarga 1 (v1.31):Pod B (ahora permanente)
  • Nodo de sobrecarga 2 (v1.31):Eliminado

Estado final

La actualización se completa con un nodo en cuarentena que requiere intervención manual.

  • Nodo 1: en cuarentena (v1.30) con Pod A - El cliente debe resolverlo manualmente (consulte Resolución de nodos que no se pueden drenar).
  • Nodo 2 (v1.31):Ejecución normal
  • Nodo de sobrecarga anterior (v1.31):Ahora reemplazo permanente

Importante

El nodo en cuarentena (nodo 1) sigue siendo responsabilidad del cliente controlar. Debe hacer una de las siguientes opciones:

  • Ajusta la PDB para permitir la expulsión del pod A.
  • Elimine manualmente el pod A.
  • Elimine y vuelva a crear el nodo después de corregir la condición de bloqueo.

Consideraciones clave para las actualizaciones bloqueadas por PDB

  • Comportamiento de nodo no drenable: establézcalo en Cordon para el grupo de nodos a fin de habilitar este comportamiento de cuarentena.
  • Responsabilidad del cliente: los nodos en cuarentena requieren intervención manual para resolver.
  • Capacidad del clúster: el nodo de sobrecarga se vuelve permanente, lo que podría afectar al planeamiento de la capacidad del clúster.
  • Supervisión: realice un seguimiento de los nodos en cuarentena a través de Azure Monitor o kubectl para garantizar la resolución oportuna.

Sugerencia

Para evitar por completo la situación de cuarentena, puede usar la gestión automática de PDB para aumentar automáticamente las réplicas de la implementación de modo que se cumplan las restricciones de PDB antes de que comience el drenaje. Esto permite que la expulsión continúe sin bloqueo, lo que elimina la necesidad de resolución manual de cuarentena.

Actualizaciones azul-verde del grupo de nodos (control manual)

Las actualizaciones Blue-Green ofrecen un enfoque de actualización más controlado mediante la creación manual de un conjunto completo de nuevos grupos de nodos antes de migrar las cargas de trabajo. Este enfoque manual le proporciona control total sobre el proceso de actualización y el tiempo.

Para obtener más información, consulte actualizaciones Blue-Green del grupo de nodos en AKS.

Cuándo usar actualizaciones de Blue-Green

Las actualizaciones manuales Blue-Green del grupo de nodos son una estrategia avanzada para requisitos especializados, como puntos de comprobación de migración explícitos, controles de validación personalizados o transiciones estrictamente controladas.

Utilice Blue-Green manual cuando lo necesite:

  • Fases de migración controladas por el operador.
  • Criterios de validación y aceptación personalizados antes de la confirmación.
  • Coreografía de reversión explícita asociada a procedimientos operativos internos.

Para la mayoría de las cargas de trabajo de producción, cuando sea aplicable, el comportamiento de actualización predeterminado de AKS Automatic es el punto de partida preferido, y la implementación manual Blue-Green suele reservarse para casos excepcionales.

Conceptos clave

  • Grupo de nodos azules: el grupo de nodos existente que ejecuta la versión actual de Kubernetes.
  • Grupo de nodos verdes: nuevo grupo de nodos que se crea ejecutando la versión de Kubernetes de destino.
  • Control manual: administra todos los aspectos del proceso de migración.
  • Puntos de comprobación de validación: decide cuándo continuar, pausar o revertir.

Ventajas de las actualizaciones de Blue-Green

  • Control total: decide exactamente cuándo se produce cada paso.
  • Validación personalizada: implemente sus propios criterios de validación y tiempo.
  • Migración gradual: mueva las cargas de trabajo a su ritmo preferido.
  • Reversión sencilla: los nodos originales permanecen disponibles hasta que los elimine.

Consideraciones clave para las actualizaciones de Blue-Green

  • Esfuerzo manual: requiere administración activa durante todo el proceso.
  • Requisitos de cuota: se requiere el doble de la capacidad del nodo durante la actualización.
  • Planificación: documente los criterios de validación y los procedimientos de reversión.

Ejemplo de proceso de actualización manual Blue-Green

En este ejemplo se muestra cómo manualmente actualizar un clúster de dos nodos de Kubernetes 1.30 a 1.31 mediante implementación Blue-Green.

Paso 1: Creación de un grupo de nodos verdes

Para empezar, cree manualmente un nuevo grupo de nodos con la versión de Kubernetes de destino junto con el grupo de nodos existente.

Diagrama que muestra Blue-Green configuración inicial con el grupo de nodos azul que ejecuta la versión 1.30 y el grupo de nodos verdes recién creado que ejecuta la versión 1.31.

  • Grupo de nodos azules (v1.30):Pod A, Pod B, Pod C, Pod D (existente)
  • Grupo de nodos verdes (v1.31):vacío (creado manualmente por usted)
  • Acción: az aks nodepool add con la nueva versión de Kubernetes

Paso 2: acordonar los nodos azules manualmente

Aísla los nodos azules para evitar que se programen nuevos pods, manteniendo en ejecución los pods existentes.

  • Tu acción: kubectl cordon en cada nodo azul
  • Nodos azules: aislados, sin nuevos pods programados
  • Nodos verdes: listos para recibir cargas de trabajo

Paso 3: Purga manual de nodos azules (ritmo controlado)

Para controlar el ritmo de migración, se purgan manualmente los nodos uno a uno o en lotes.

Diagrama que muestra el nodo azul vaciándose, con los pods desalojados y reemplazados en el grupo de nodos verdes, y el segundo nodo azul vaciándose, con los pods restantes migrados al grupo de nodos verdes.

  • Tu acción: kubectl drain sobre los nodos azules seleccionados
  • Migración de pods: los pods se reprograman automáticamente en nodos verdes.
  • Validación: comprobación de cargas de trabajo en nodos verdes antes de continuar

Paso 4: Validar y decidir

Después de migrar las cargas de trabajo, valide el rendimiento de la aplicación en los nodos verdes.

Diagrama que muestra la fase de validación con todas las cargas de trabajo que se ejecutan en el grupo de nodos verde, mientras que el grupo de nodos azul permanece disponible para la reversión.

Durante esta fase, puede hacer lo siguiente:

  • Supervisión: comprobación de métricas y registros de aplicaciones
  • Prueba: Ejecución de pruebas de validación en el grupo de nodos verdes
  • Decidir: Comprometerse a verde o volver a azul

Paso 5: Confirmar o revertir

Basado en su validación, usted completa manualmente la actualización o la revierte.

Opción A - Confirmar (Éxito):

Diagrama que muestra la confirmación correcta con el grupo de nodos azul eliminado y el grupo de nodos verde se convierte en el grupo de nodos principal.

  • Acción: Eliminación del grupo de nodos azules mediante az aks nodepool delete
  • Resultado: El grupo de nodos verdes se convierte en principal

Opción B: reversión (problemas detectados):

Diagrama que muestra la reversión, con las cargas de trabajo volviendo al grupo de nodos azul y la eliminación del grupo de nodos verde.

  • Su acción: Quite el cordón de los nodos azules con kubectl uncordon, drene los nodos verdes con kubectl drain y elimine el grupo de nodos verdes con az aks nodepool delete
  • Resultado: Las cargas de trabajo vuelven a los nodos azules

Consideraciones de producción para el planeamiento de actualizaciones

  • Configuración de sobrecarga (maxSurge): controla el número de nodos de sobrecarga creados durante las actualizaciones. Los valores más altos aceleran las actualizaciones, pero consumen más recursos.
  • Presupuestos de interrupciones de pods (PDB): configure archivos PDB para garantizar la disponibilidad de las aplicaciones durante el proceso de actualización.
  • Actualizaciones del grupo de nodos: cada grupo de nodos se actualiza de forma independiente. Planee la estrategia de actualización en consecuencia.
  • Capacidad y cuota asignada: Validar los requisitos de capacidad temporales y en estado estable antes de las ventanas de actualización.
  • Supervisión y alertas: configure la supervisión y las alertas antes de que se inicie la actualización.

En AKS Automatic, varias opciones de actualización de nivel de plataforma están preconfiguradas para la preparación de producción. En AKS Estándar, los equipos suelen tomar estas opciones explícitamente.

Contenido relacionado

  • Last updated on