Opciones de actualización para clústeres de Azure Kubernetes Service (AKS)

En este artículo se describen las distintas opciones de actualización de los clústeres de AKS. Para realizar una actualización básica de la versión de Kubernetes, consulte Actualización de un clúster de AKS.

Para los clústeres de AKS que usan varios grupos de nodos o nodos de Windows Server, consulte Actualización de un grupo de nodos en AKS. Para actualizar un grupo de nodos específico sin realizar una actualización del clúster de Kubernetes, consulte Actualización de un grupo de nodos específico.

Realizar actualizaciones manuales

Puede realizar actualizaciones manuales para controlar cuándo se actualiza el clúster a una nueva versión de Kubernetes. Las actualizaciones manuales son útiles cuando desea probar una nueva versión de Kubernetes antes de actualizar el clúster de producción. También puede usar actualizaciones manuales para actualizar el clúster a una versión específica de Kubernetes que no sea la versión disponible más reciente.

Para realizar actualizaciones manuales, consulte los artículos siguientes:

• Actualización de un clúster de AKS
• Actualización de la imagen de nodo
• Personalización de la actualización de sobrecargas de nodo
• Procesamiento de actualizaciones de sistema operativo del nodo

Configuración de actualizaciones automáticas

Puede configurar las actualizaciones automáticas para actualizar automáticamente el clúster a la versión más reciente de Kubernetes disponible. Las actualizaciones automáticas son útiles cuando desea asegurarse de que el clúster siempre ejecute la versión más reciente de Kubernetes. También puede usar actualizaciones automáticas para asegurarse de que el clúster siempre ejecuta una versión de Kubernetes compatible.

Para configurar las actualizaciones automáticas, consulte los siguientes artículos:

• Actualización automática de un clúster de AKS
• Uso del mantenimiento planeado para programar y controlar las actualizaciones de los clústeres de AKS
• Detener las actualizaciones del clúster automáticamente en los cambios importantes de la API (versión preliminar)
• Actualización automática de las imágenes del sistema operativo del nodo de clúster de AKS
• Aplicación de actualizaciones de seguridad a los nodos de AKS automáticamente mediante Acciones de GitHub

Consideraciones especiales para los grupos de nodos que abarcan varias zonas de disponibilidad

AKS usa el equilibrio de zona de mejor esfuerzo en grupos de nodos. Durante una sobrecarga de actualización, las zonas de los nodos de sobrecarga en Virtual Machine Scale Sets son desconocidas con antelación, lo que puede provocar temporalmente una configuración de zona desequilibrada durante una actualización. Sin embargo, AKS elimina los nodos de sobrecarga una vez completada la actualización y conserva el equilibrio de zona original. Si quiere mantener equilibradas las zonas durante las actualizaciones, puede aumentar la sobrecarga en un múltiplo de tres nodos y Virtual Machine Scale Sets equilibra los nodos en las zonas de disponibilidad con equilibrio de zona de mejor esfuerzo. Con la mejor opción de equilibrio de zonas, el conjunto de escalado intenta aumentarse y reducirse horizontalmente, y conserva el equilibrio. Sin embargo, si por alguna razón no es posible (por ejemplo, que una zona deje de funcionar, y, como consecuencia, el conjunto de escala no pueda crear una máquina virtual en esa zona), el conjunto de escalado permite el desequilibrio temporal para realizar correctamente el aumento o la reducción horizontal.

Las notificaciones de volumen persistente (PVC) respaldadas por discos de almacenamiento con redundancia local (LRS) de Azure están enlazadas a una zona determinada y podrían no recuperarse inmediatamente si el nodo de sobrecarga no coincide con la zona del PVC. Si las zonas no coinciden, podría haber un tiempo de inactividad en la aplicación cuando la operación de actualización continúa purgando nodos, pero los PV están enlazados a una zona. Para controlar este caso y mantener la alta disponibilidad, configure un presupuesto de interrupciones de pods en la aplicación para permitir que Kubernetes respete los requisitos de disponibilidad durante la operación de purga.

Optimización de las actualizaciones para mejorar el rendimiento y minimizar las interrupciones

La combinación de la ventana de mantenimiento planeado, el aumento máximo, el presupuesto de interrupción de pods , el tiempo de espera de purga de nodosy el tiempo de inmersión de nodos (versión preliminar) puede aumentar significativamente la probabilidad de que las actualizaciones de nodos se completen con éxito al final de la ventana de mantenimiento, al tiempo que también minimizan las interrupciones.

• La ventana de mantenimiento planeado permite a los equipos de servicio programar la actualización automática durante una ventana predefinida, normalmente un periodo de poco tráfico, para minimizar el impacto en la carga de trabajo. Se recomienda una duración de al menos cuatro horas.

• El aumento máximo en el grupo de nodos permite solicitar una cuota adicional durante el proceso de actualización y limita el número de nodos seleccionados para la actualización simultáneamente. Un aumento máximo mayor da como resultado un proceso de actualización más rápido. No se recomienda establecerlo en el 100 %, ya que actualiza todos los nodos simultáneamente, lo que puede provocar interrupciones en las aplicaciones en ejecución. Se recomienda una cuota de aumento máxima del 33 % para los grupos de nodos de producción.

• El presupuesto de interrupciones de pods se establece para las aplicaciones de servicio y limita el número de pods que se pueden reducir durante las interrupciones voluntarias, como las actualizaciones de nodo controladas por AKS. Puede configurarse como réplicas minAvailable, indicando el número mínimo de pods de aplicación que deben estar activos o réplicas maxUnavailable, indicando el número máximo de pods de aplicación que pueden darse de baja, garantizando una alta disponibilidad para la aplicación. Consulte la guía proporcionada para configurar los presupuestos de interrupción de pods (PDB). Los valores de PDB deben validarse para determinar la configuración que mejor funciona para su servicio específico.

• El tiempo de espera de purga de nodos en el grupo de nodos permite configurar la duración de espera para la expulsión de pods y la terminación correcta por nodo durante una actualización. Esta opción es útil cuando se trabaja con cargas de trabajo de larga duración. Cuando se especifica el tiempo de espera de purga del nodo (en minutos), AKS respeta la espera de presupuestos de interrupciones del pod. Si no se especifica, el tiempo de espera predeterminado es de 30 minutos.

• El tiempo de inmersión del nodo (versión preliminar) ayuda a escalonar las actualizaciones de nodos de forma controlada y puede minimizar el tiempo de inactividad de la aplicación durante una actualización. Puede especificar un tiempo de espera, preferiblemente lo más cercano posible a 0 minutos, para comprobar el estado de preparación de la aplicación entre actualizaciones de nodos. Si no se especifica, el valor predeterminado es 0 minutos. El tiempo de inmersión de nodos está asociado a las propiedades de sobrecarga máxima y tiempo de espera de purga de nodos disponibles en el grupo de nodos para ofrecer los resultados correctos en términos de velocidad de actualización y disponibilidad de la aplicación.

  Nota:

  Para usar la duración del inmersión de nodos (versión preliminar), debe tener instalada la extensión de aks-preview la CLI de Azure 0.5.173 o posterior.

Pasos siguientes

En este artículo se listan diferentes opciones de actualización para clústeres de AKS. Para obtener una explicación detallada de los procedimientos recomendados de actualización y otras consideraciones, consulte Guía de actualización y revisión de AKS.