Compartir vía

Guía de actualización y aplicación de revisiones de Azure Kubernetes Service

  • Artículo

En esta sección de la guía de operaciones del día 2 de Azure Kubernetes Service (AKS) se describen las estrategias de actualización y aplicación de revisiones de los nodos de trabajo de AKS y las versiones de Kubernetes. Como operador de clústeres, debe tener un plan para mantener actualizados los clústeres y supervisar los cambios y retiradas de la API de Kubernetes a lo largo del tiempo.

Segundo plano y tipos de actualizaciones

Hay tres tipos de actualizaciones para AKS, cada uno de los cuales se basa en el siguiente:

Tipo de actualización Frecuencia de actualización Mantenimiento planeado admitido Métodos de operación admitidos Destino Vínculo a la documentación
Parches de seguridad del sistema operativo de nodo Por la noche Sí Automático (semanal), manual/no administrado (nocturno) Nodo Actualización automática de imágenes de nodo
Actualizaciones de la versión de la imagen de nodo Linux: semanal
Windows: mensual		 Sí Automático, manual Grupo de nodos Actualización de la imagen del nodo AKS
Actualizaciones de la versión (clúster) de Kubernetes Trimestral Sí Automático, manual Grupo de clústeres y nodos Actualización de un clúster de AKS

Actualización de los tipos

  • Parches de seguridad del sistema operativo de nodo (solo Linux). En el caso de los nodos de Linux, tanto Canonical Ubuntu como Azure Linux hacen que los parches de seguridad del sistema operativo estén disponibles una vez al día. Microsoft prueba y agrupa estas revisiones en las actualizaciones semanales de las imágenes de nodo.

  • Actualizaciones semanales de las imágenes de nodo. AKS proporciona actualizaciones semanales de las imágenes de nodo. Estas actualizaciones incluyen los últimos parches de seguridad del sistema operativo y AKS, correcciones de errores y mejoras. Las actualizaciones de nodo no cambian la versión de Kubernetes. El formato de las versiones se basa en la fecha (por ejemplo, 202311.07.0) para Linux y en la compilación y la fecha del sistema operativo Windows Server (por ejemplo, 20348.2113.231115) para Windows. Para obtener más información, consulte Estado de lanzamiento de AKS.

  • Versiones trimestrales de Kubernetes. AKS proporciona actualizaciones trimestrales para las versiones de Kubernetes. Estas actualizaciones permiten a los usuarios de AKS aprovechar las últimas características y mejoras de Kubernetes. Incluyen parches de seguridad y actualizaciones de imágenes de nodo. Para obtener más información, consulte Versiones de Kubernetes compatibles en AKS.

Consideraciones previas a las actualizaciones

Impacto general del clúster

  • Las actualizaciones locales (tanto del nodo como del clúster) afectan al rendimiento del entorno de Kubernetes mientras están en curso. Puede minimizar este efecto a través de la configuración adecuada de presupuestos de interrupciones de pods, la configuración de sobrecarga de nodo y el planeamiento adecuado.
  • El uso de una estrategia de actualización azul/verde en lugar de actualizar localmente elimina cualquier impacto en el rendimiento del clúster, pero aumenta el coste y la complejidad.
  • Independientemente de la estrategia de actualización y aplicación de revisiones, debe tener un proceso de prueba y validación sólidos para el clúster. Revise y actualice los entornos inferiores en primer lugar y realice una validación posterior al mantenimiento para comprobar el estado del clúster, el nodo, la implementación y la aplicación.

Procedimientos recomendados de cargas de trabajo de AKS

Para garantizar el buen funcionamiento del clúster de AKS durante el mantenimiento, siga estos procedimientos recomendados:

  • Definir presupuestos de interrupciones de pods (PDB). La configuración de presupuestos de interrupciones de pods para las implementaciones es esencial. Los PDB aplican un número mínimo de réplicas de aplicación disponibles para garantizar la funcionalidad continua durante los eventos de interrupciones. Los PDB ayudan a mantener la estabilidad del clúster durante los errores de mantenimiento o de nodo.

    Advertencia

    Los PDB con una configuración errónea pueden bloquear el proceso de actualización porque la API de Kubernetes impide el cordón y la purga necesarios que se producen con una actualización gradual de la imagen de nodo. Además, si se mueven simultáneamente demasiados pods, se puede producir una interrupción de la aplicación. La configuración de los PDB mitiga este riesgo.

  • Compruebe los límites de proceso y red disponibles. Compruebe los límites de proceso y red disponibles en la suscripción de Azure en la página de cuota de Azure Portal o mediante el comando az quota. Compruebe los recursos de proceso y red, especialmente las vCPU de VM para los nodos y el número de máquinas virtuales y conjuntos de escalado de máquinas virtuales. Si está cerca de un límite, solicite un aumento de cuota antes de actualizar.
  • Compruebe el espacio IP disponible en las subredes de nodo. Durante las actualizaciones, se crean nodos de sobrecarga adicionales en el clúster y los pods se mueven a estos nodos. Es importante supervisar el espacio de direcciones IP en las subredes del nodo para asegurarse de que haya suficiente espacio de direcciones para que se produzcan estos cambios. Las distintas configuraciones de red de Kubernetes tienen requisitos de IP diferentes. Como punto de partida, revise estas consideraciones:
    • Durante una actualización, el número de direcciones IP de nodo aumenta según el valor de sobrecarga. (El valor de sobrecarga mínimo es 1.)
    • Los clústeres basados en Azure CNI asignan direcciones IP a pods individuales, por lo que debe haber suficiente espacio IP para el movimiento del pod.
    • El clúster sigue funcionando durante las actualizaciones. Asegúrese de que queda suficiente espacio IP para permitir el escalado de nodos (si está habilitado).
  • Configure varios entornos. Se recomienda configurar entornos independientes, como desarrollo, almacenamiento provisional y producción, para permitirle probar y validar los cambios antes de implementarlos en producción.
  • Ajuste los valores de actualización de sobrecarga. De manera predeterminada, AKS tiene un valor de sobrecarga de 1, lo que significa que se crea un nodo adicional a la vez como parte del proceso de actualización. Aumente este valor para incrementar la velocidad de una actualización de AKS. Una sobrecarga del 33 % es el valor máximo recomendado para las cargas de trabajo que son sensibles a las interrupciones. Para más información, consulte Personalización de la actualización de sobrecarga de nodos.
  • Ajuste el tiempo de espera de purga de nodos. El tiempo de espera de purga de nodos especifica la cantidad máxima de tiempo que esperará un clúster para intentar volver a programar pods en un nodo que se está actualizando. El valor predeterminado es 30 minutos. En el caso de las cargas de trabajo que tienen dificultades para volver a programar pods, puede resultar útil ajustar este valor predeterminado.
  • Planee y programe ventanas de mantenimiento. Los procesos de actualización pueden afectar al rendimiento general del clúster de Kubernetes. Programe procesos de actualización local fuera de las ventanas de uso máximo y supervise el rendimiento del clúster para garantizar un ajuste de tamaño adecuado, especialmente durante los procesos de actualización.
  • Compruebe otras dependencias del clúster. Los operadores de Kubernetes suelen implementar otras herramientas en el clúster de Kubernetes como parte de las operaciones, como escaladores KEDA, Dapr y mallas de servicio. Al planear los procesos de actualización, compruebe las notas de la versión de los componentes que use para garantizar la compatibilidad con la versión de destino.

Administración de las actualizaciones semanales en imágenes de nodo

Microsoft crea una nueva imagen de nodo para los nodos de AKS aproximadamente una vez por semana. Una imagen de nodo contiene los más recientes parches de seguridad del sistema operativo, actualizaciones de kernel del sistema operativo, actualizaciones de seguridad de Kubernetes, versiones actualizadas de archivos binarios como kubelet y las actualizaciones de versiones de componentes que aparecen en las notas de la versión.

Cuando se actualiza una imagen de nodo, se desencadena una acción de cordón y purga en los nodos del grupo de nodos de destino:

  • Se agrega un nodo con la imagen actualizada al grupo de nodos. El número de nodos agregados a la vez se rige por el valor de sobrecarga.
  • Dependiendo del valor de sobrecarga, se acordona y purga un batch de nodos existentes. El cordón garantiza que el nodo no programe pods. La purga quita sus pods y los programa en otros nodos.
  • Una vez que estos nodos se drenan por completo, se eliminan del grupo de nodos. Los reemplaza los nodos actualizados que la sobrecarga ha agregado.
  • Este proceso se repite para cada batch de nodos que debe actualizarse en el grupo de nodos.

Se produce un proceso similar durante una actualización del clúster.

Actualizaciones automáticas de las imágenes de nodo

Por lo general, la mayoría de los clústeres deben usar el canal de actualización NodeImage. Este canal proporciona un VHD de imagen de nodo actualizado semanalmente y se actualiza según la ventana de mantenimiento del clúster.

Entre los canales disponibles se incluyen los siguientes:

  • None. Las actualizaciones no se aplican automáticamente.
  • Unmanaged. El sistema operativo aplica las actualizaciones de Ubuntu y Azure Linux por la noche. Los arranques deben administrarse por separado. AKS no puede probarlo ni controlar su cadencia.
  • SecurityPatch. Parches de seguridad del sistema operativo probados por AKS, totalmente administrados y aplicados con prácticas de implementación seguras. No contiene ninguna corrección de errores del sistema operativo, solo actualizaciones de seguridad.
  • NodeImage. AKS actualiza semanalmente los nodos con un VHD recién revisado que contiene correcciones de seguridad y de errores. Está totalmente probado y se ha implementado con prácticas de implementación seguras. Para obtener información en tiempo real sobre las imágenes de nodo implementadas actualmente, consulte Actualizaciones de imágenes de nodo de AKS.

Para comprender las cadencias predeterminadas sin una ventana de mantenimiento establecida, consulte Actualización de la propiedad y la cadencia.

Si elige el canal de actualización Unmanaged, debe administrar el proceso de arranque mediante una herramienta como kured. Unmanaged no incluye prácticas de implementación seguras proporcionadas por AKS y no funcionará en ventanas de mantenimiento. Si elige el canal de actualización SecurityPatch, las actualizaciones se pueden aplicar con una frecuencia semanal. Este nivel de revisión requiere que los VHD se almacenen en el grupo de recursos, lo que incurre en un cargo nominal. Controle cuándo se aplica SecurityPatch estableciendo un aksManagedNodeOSUpgradeSchedule adecuado que se alinee con una cadencia que funcione mejor para la carga de trabajo. Para obtener más información, consulte Creación de una ventana de mantenimiento. Si también necesita correcciones de errores que suelen incluir nuevas imágenes de nodo (VHD), debe elegir el canal NodeImage en lugar de SecurityPatch.

Como procedimiento recomendado, use el canal de actualización NodeImage y configure una ventana de mantenimiento aksManagedNodeOSUpgradeSchedule a la hora en que el clúster está fuera de las ventanas de uso máximo. Consulte Creación de una ventana de mantenimiento para ver los atributos que puede usar para configurar la ventana de mantenimiento del clúster. Los atributos clave son:

  • name. Use aksManagedNodeOSUpgradeSchedule para las actualizaciones del sistema operativo del nodo.
  • utcOffset. Configure la zona horaria.
  • startTime. Establezca la hora de inicio de la ventana de mantenimiento.
  • dayofWeek. Establezca los días de la semana para la ventana. Por ejemplo, Saturday.
  • schedule. Establezca la frecuencia de la ventana. Para las actualizacionesde NodeImage, se recomienda weekly.
  • durationHours. Establezca este atributo en al menos cuatro horas.

En este ejemplo se establece una ventana de mantenimiento semanal los sábados a las 20:00 h, hora del este:

az aks maintenanceconfiguration add -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule --utc-offset=-05:00 --start-time 20:00 --day-of-week Saturday --schedule-type weekly --duration 4

Para ver más ejemplos, consulte Adición de una configuración de ventana de mantenimiento con la CLI de Azure.

Idealmente, esta configuración se implementaría como parte de la implementación de infraestructura como código del clúster.

Puede comprobar si hay ventanas de mantenimiento configuradas mediante la CLI de Azure:

az aks maintenanceconfiguration list -g <ResourceGroupName> --cluster-name <AKSClusterName>

También puede comprobar los detalles de una ventana de mantenimiento específica mediante la CLI:

az aks maintenanceconfiguration show -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule

Si no se configura una ventana de mantenimiento del clúster, las actualizaciones de imágenes de nodo se producen cada dos semanas. En la medida de lo posible, el mantenimiento de AKS se produce dentro de la ventana configurada, pero el tiempo de mantenimiento no está garantizado.

Importante

Si tiene un grupo de nodos con un gran número de nodos, pero no está configurado con aumento de nodos, es posible que el evento de actualización automática no se desencadene. Las imágenes de nodo de un grupo de nodos solo se actualizarán mientras el tiempo total estimado de actualización sea inferior a 24 horas.

En esta situación, puede considerar una de las siguientes opciones:

  • dividir nodos en grupos de nodos diferentes si la cuota de vCPU está casi llena y no se puede aumentar la cuota de vCPU
  • configurar el aumento del nodo para reducir el tiempo de actualización estimado si la cuota de vCPU es suficiente

Puede comprobar el estado de los eventos de actualización a través de los registros de actividad de Azure o revisando los registros de recursos en el clúster.

Puede Suscribirse a eventos de Azure Kubernetes Service (AKS) con Azure Event Grid, que incluye eventos de actualización de AKS. Estos eventos pueden avisarle cuando hay disponible una nueva versión de Kubernetes y ayudar a realizar un seguimiento de los cambios de estado del nodo durante los procesos de actualización.

También puede administrar el proceso de actualización semanal mediante Acciones de GitHub. Este método proporciona un control más granular del proceso de actualización.

Proceso de actualización manual de nodos

Puede usar el comando kubectl describe nodes para determinar la versión del kernel del sistema operativo y la versión de la imagen del sistema operativo de los nodos del clúster:

kubectl describe nodes <NodeName>

Resultado de ejemplo (truncado):

System Info:
  Machine ID:                 bb2e85e682ae475289f2e2ca4ed6c579
  System UUID:                6f80de9d-91ba-490c-8e14-9e68b7b82a76
  Boot ID:                    3aed0fd5-5d1d-4e43-b7d6-4e840c8ee3cf
  Kernel Version:             5.15.0-1041-azure
  OS Image:                   Ubuntu 22.04.2 LTS
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.7.1+azure-1
  Kubelet Version:            v1.26.6
  Kube-Proxy Version:         v1.26.6

Use el comando az aks nodepool list de la CLI de Azure para determinar las versiones de imagen de nodo de los nodos de un clúster:

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,NodeImageVersion:nodeImageVersion}" --output table

Ejemplo:

Name       NodeImageVersion
---------  ---------------------------------------------
systempool  AKSUbuntu-2204gen2containerd-202307.12.0
usernodepool  AKSUbuntu-2204gen2arm64containerd-202307.12.0

Use el comando az aks nodepool get-upgrades para determinar la versión más reciente de imagen de nodo disponible de un grupo de nodos específico:

az aks nodepool get-upgrades \
   --resource-group <ResourceGroupName> \
   --cluster-name <AKSClusterName> \
   --nodepool-name <NodePoolName> --output table

Ejemplo:

KubernetesVersion    LatestNodeImageVersion                         Name     OsType
-------------------  ---------------------------------------------  -------  --------
1.26.6               AKSUbuntu-2204gen2arm64containerd-202308.10.0  default  Linux

Actualizaciones de clústeres

La Comunidad de Kubernetes publica versiones secundarias de Kubernetes aproximadamente cada tres meses. Para mantenerle informado sobre las nuevas versiones de AKS, la página de notas de la versión de AKS se actualiza periódicamente. También puede suscribirse al canal RSS de AKS de GitHub, que proporciona actualizaciones en tiempo real sobre cambios y mejoras.

AKS sigue una directiva de soporte técnico N - 2, lo que significa que se proporciona compatibilidad completa para la versión más reciente (N) y dos versiones secundarias anteriores. Para la tercera versión secundaria anterior se ofrece compatibilidad limitada con la plataforma. Para más información, consulte la política de compatibilidad de AKS.

Para asegurarse de que los clústeres de AKS siguen siendo compatibles, debe establecer un proceso de actualización continua del clúster. Este proceso implica probar nuevas versiones en entornos inferiores y planear la actualización a producción antes de que la nueva versión se convierta en la predeterminada. Este enfoque puede mantener la previsibilidad en el proceso de actualización y minimizar las interrupciones en las aplicaciones. Para más información, consulte Actualización de un clúster de Azure Kubernetes Service (AKS).

Si el clúster requiere un ciclo de actualización más largo, use versiones de AKS que admitan la opción de compatibilidad a largo plazo (LTS). Si habilita la opción LTS, Microsoft proporciona soporte extendido para las versiones de Kubernetes durante dos años, lo que permite un ciclo de actualización más prolongado y controlado. Para obtener más información, consulte Versiones de Kubernetes compatibles en AKS.

Las actualizaciones del clúster incluyen una actualización de nodo y usan un proceso de acordonamiento y purga similar.

Antes de actualizar

Como procedimiento recomendado, siempre debe actualizar y probar en entornos inferiores para minimizar el riesgo de interrupción en producción. Las actualizaciones de clúster requieren pruebas adicionales porque implican cambios de API, lo que puede afectar a las implementaciones de Kubernetes. Los siguientes recursos pueden ayudarle en el proceso de actualización:

  • Libro de AKS para las API en desuso. En la página de información general del clúster de Azure Portal, puede seleccionar Diagnosticar y resolver problemas, ir a la categoría Crear, actualizar, eliminar y escalar y, a continuación, seleccionar API de Kubernetes en desuso. Al hacerlo, se ejecuta un libro que comprueba si se usan versiones de API en desuso en el clúster. Para obtener más información, consulte Eliminación del uso de las API en desuso.
  • Página de notas de la versión de AKS. En esta página se proporciona información exhaustiva sobre las nuevas versiones de AKS. Revise estas notas para mantenerse informado sobre las últimas actualizaciones y cambios.
  • Página de notas de la versión de Kubernetes. En esta página se proporciona información detallada sobre las versiones más recientes de Kubernetes. Preste especial atención a las notas de actualización urgente, que resaltan información crítica que podría afectar al clúster de AKS.
  • Cambios importantes de los componentes de AKS por versión. En esta tabla se proporciona información general exhaustiva sobre los cambios importantes en los componentes de AKS, por versión. Si consulta esta guía, puede solucionar de forma proactiva los posibles problemas de compatibilidad antes del proceso de actualización.

Además de estos recursos de Microsoft, considere la posibilidad de usar herramientas de código abierto para optimizar el proceso de actualización del clúster. Una de estas herramientas es pluto, de Fairwinds, que puede examinar las implementaciones y los gráficos de Helm para las API de Kubernetes en desuso. Estas herramientas pueden ayudarle a garantizar que las aplicaciones sigan siendo compatibles con las versiones más recientes de Kubernetes.

Proceso de actualización

Para comprobar si el clúster precisa una actualización, puede usar el comando az aks get-upgrades y obtener una lista de las versiones de actualización disponibles para el clúster de AKS. A partir de los resultados, determine la versión de destino del clúster.

Este es un ejemplo:

az aks get-upgrades \
   --resource-group <ResourceGroupName> --name <AKSClusterName> --output table

Ejemplo:

MasterVersion  Upgrades
-------------  ---------------------------------
1.26.6         1.27.1, 1.27.3

Compruebe las versiones de Kubernetes de los nodos de sus grupos para determinar los grupos que deben actualizarse:

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,k8version:orchestratorVersion}" --output table

Ejemplo:

Name          K8version
------------  ------------
systempool    1.26.6
usernodepool  1.26.6

Actualización manual

Para minimizar las interrupciones y ayudar a garantizar una actualización sin problemas para el clúster de AKS, siga este enfoque de actualización:

  1. Actualice el plano de control de AKS. Empiece por actualizar el plano de control de AKS. Este paso implica actualizar los componentes del plano de control responsables de administrar y orquestar el clúster. La actualización del plano de control primero ayuda a garantizar la compatibilidad y la estabilidad antes de actualizar los grupos de nodos individuales.
  2. Actualice el grupo de nodos del sistema. Después de actualizar el plano de control, actualice el grupo de nodos del sistema en el clúster de AKS. Los grupos de nodos constan de las instancias de máquina virtual que ejecutan las cargas de trabajo de la aplicación. La actualización de los grupos de nodos por separado permite una actualización controlada y sistemática de la infraestructura subyacente que admite las aplicaciones.
  3. Actualice los grupos de nodos de usuario. Después de actualizar el grupo de nodos del sistema, actualice los grupos de nodos de usuario del clúster de AKS.

Al seguir este enfoque, puede minimizar las interrupciones durante el proceso de actualización y mantener la disponibilidad de las aplicaciones. Estos son los pasos detallados:

  1. Ejecute el comando az aks upgrade con la marca --control-plane-only para actualizar solo el plano de control del clúster y no los grupos de nodos de clúster asociados:

    az aks upgrade \
   --resource-group <ResourceGroupName> --name <AKSClusterName> \
   --control-plane-only \
   --kubernetes-version <KubernetesVersion>

  2. Ejecute el comando az aks nodepool upgrade para actualizar los grupos de nodos a la versión de destino:

    az aks nodepool upgrade \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> --name <NodePoolName> \
   --no-wait --kubernetes-version <KubernetesVersion>

    Durante la actualización del grupo de nodos, AKS crea un nodo de sobrecarga, acordona y purga pods en el nodo que se está actualizando, restablece la imagen inicial del nodo y, a continuación, descordona los pods. A continuación, este proceso se repite para cualquier otro nodo del grupo de nodos.

Puede comprobar el estado del proceso de actualización ejecutando kubectl get events. Para obtener información sobre la solución de problemas de actualización del clúster, consulte la documentación de solución de problemas de AKS.

Inscripción de clústeres en canales de versión de actualización automática

AKS también ofrece una solución de actualización automática de clústeres para mantener el clúster actualizado. Si usa esta solución, debe emparejarla con una ventana de mantenimiento para controlar el tiempo de actualización. La ventana de actualización debe ser de cuatro horas o más. Al inscribir un clúster en un canal de versión, Microsoft administra automáticamente la cadencia de versión y actualización para el clúster y sus grupos de nodos.

La actualización automática del clúster ofrece diferentes opciones de canal de versión. Esta es una configuración de canal de versión y entorno recomendada:

Entorno Canal de actualización Descripción
Producción stable En el caso de la estabilidad y la madurez de la versión, use el canal estable o normal para cargas de trabajo de producción.
Almacenamiento provisional, pruebas, desarrollo Igual que la producción Para garantizar que las pruebas sean indicativas de la versión a la que se actualizará el entorno de producción, use el mismo canal de versión que la producción.
Valor controlado rapid Para probar las versiones más recientes de Kubernetes y las nuevas características o las API de AKS, use el canal rapid. Es posible mejorar el tiempo de comercialización cuando la versión de rapid se promueve al canal que usa para producción.

Consideraciones

En la tabla siguiente se describen las características de diversos escenarios de actualización y aplicación de revisiones de AKS:

Escenario Iniciado por el usuario Actualización de Kubernetes Actualización del kernel del SO Actualización de la imagen de nodo
Aplicación de revisiones de seguridad No No Sí, después del arranque. Sí
Creación de clústeres Sí Es posible Sí, si una imagen de nodo actualizada usa un kernel actualizado. Sí, con respecto a un clúster existente si hay disponible una nueva versión.
Actualización de Kubernetes del plano de control Sí Sí No No
Actualización de Kubernetes del grupo de nodos Sí Sí Sí, si una imagen de nodo actualizada usa un kernel actualizado. Sí, si hay disponible una nueva versión.
Escalado vertical del grupo de nodos Sí No N.º No
Actualización de la imagen de nodo Sí No Sí, si una imagen de nodo actualizada usa un kernel actualizado. Sí
Actualización automática del clúster No Sí Sí, si una imagen de nodo actualizada usa un kernel actualizado. Sí, si hay disponible una nueva versión.
  • Es posible que un parche de seguridad del sistema operativo aplicado como parte de una actualización de imágenes de nodo instale una versión posterior del kernel a la que se instalaría si se crea un nuevo clúster.
  • El escalado vertical del grupo de nodos usa el modelo asociado actualmente al conjunto de escalado de máquinas virtuales. Los kernels del sistema operativo se actualizan cuando se aplican parches de seguridad y se arrancan los nodos.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Otros colaboradores:

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

Pasos siguientes