Compartir a través de

Actualización de un clúster de Kubernetes del operador de Azure Nexus

  • Artículo

En este artículo se proporcionan instrucciones sobre cómo actualizar un clúster de Kubernetes de Operador Nexus para obtener las características y actualizaciones de seguridad más recientes. Parte del ciclo de vida del clúster de Kubernetes implica realizar actualizaciones periódicas a la versión más reciente de Kubernetes. Es importante que aplique las versiones de seguridad más recientes o que actualice el software para obtener las últimas características. En este artículo se muestra cómo comprobar, configurar y aplicar actualizaciones al clúster de Kubernetes.

Limitaciones

  • El proceso de actualización predeterminado del clúster es un enfoque de escalado horizontal, lo que significa que se agrega al menos un nodo adicional (o tantos nodos como configurados en aumento máximo). Si no hay suficiente capacidad disponible, la actualización no se realizará correctamente.
  • Cuando haya nuevas versiones de Kubernetes disponibles, los clústeres de inquilinos no se someten a actualizaciones automáticas. Los usuarios deben iniciar la actualización cuando todas las funciones de red del clúster estén listas para admitir la nueva versión de Kubernetes. Para más información, consulte Actualización del clúster.
  • Operador Nexus ofrece actualizaciones en todo el clúster, lo que garantiza la coherencia en todos los grupos de nodos. No se admite la actualización de un único grupo de nodos. Además, la imagen del nodo se actualiza como parte de la actualización del clúster cuando hay disponible una nueva versión.
  • Las personalizaciones realizadas en los nodos del agente se perderán durante las actualizaciones del clúster. Se recomienda colocar estas personalizaciones en DaemonSetlugar de realizar cambios manuales en la configuración del nodo para conservarlas después de la actualización.
  • Las modificaciones realizadas en las configuraciones de complementos principales se restauran a la configuración de complemento predeterminada como parte del proceso de actualización del clúster. Evite personalizar la configuración del complemento (por ejemplo, Calico, etc.) para evitar posibles errores de actualización. Si la restauración de la configuración del complemento encuentra problemas, podría provocar errores de actualización.
  • Al actualizar el clúster de Kubernetes Operador Nexus, no se pueden omitir las versiones secundarias de Kubernetes. Debe hacer las actualizaciones secuencialmente con arreglo al número de versión principal. Por ejemplo, se admiten las actualizaciones entre 1.14.x y >1.15.x o 1.15.x a >1.16.x, pero no 1.14.x a >1.16.x. Si la versión está detrás de más de una versión principal, debe realizar varias actualizaciones secuenciales.
  • Los valores máximos de sobrecarga o máximo no disponible deben establecerse durante la creación del clúster. No puede cambiar estos valores después de crear el clúster. Para más información, consulte upgradeSettings en Creación de un clúster de Kubernetes del operador de Azure Nexus.

Requisitos previos

  • Un clúster de Kubernetes de Azure Operator Nexus desplegado en un grupo de recursos en su suscripción Azure.
  • Si usa la CLI de Azure, este artículo requiere que ejecute la versión más reciente de la CLI de Azure. Si necesita instalarla o actualizarla, consulte Instalación de la CLI de Azure
  • Versión mínima necesaria networkcloud de la extensión az-cli: 2.0.b3
  • Comprenda el concepto de agrupaciones de versiones. Para más información, consulte Paquetes de versiones de Nexus Kubernetes.

Comprobación de las actualizaciones disponibles

Para comprobar qué versiones de Kubernetes están disponibles para su clúster, use los pasos siguientes:

Uso de CLI de Azure

El siguiente comando de la CLI de Azure devuelve las actualizaciones disponibles para el clúster:

az networkcloud kubernetescluster show --name <NexusK8sClusterName> --resource-group <ResourceGroup> --output json --query availableUpgrades

Salida del ejemplo:

[
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.4-4"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.6-1"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.26.3-1"
  }
]

Uso de Azure Portal

  1. Inicie sesión en Azure Portal.
  2. Ir al clúster de Operador Nexus Kubernetes.
  3. En Información general, seleccione la pestaña Actualizaciones disponibles.

Captura de pantalla de las actualizaciones disponibles.

Elegir una versión a la que actualizar

La salida de actualización disponible indica que hay varias versiones entre las que elegir para actualizar. En este escenario específico, el clúster actual funciona en la versión v1.25.4-3. Como resultado, las opciones de actualización disponibles incluyen v1.25.4-4 y la versión de revisión más reciente v1.25.6-1. Además, también hay disponible una nueva versión secundaria.

Tiene la flexibilidad de actualizar a cualquiera de las versiones disponibles. Sin embargo, el curso de acción recomendado es realizar la actualización a la versión de major-minor-patch-versionbundle más reciente disponible.

Nota:

El formato de entrada de la versión es major.minor.patch o major.minor.patch-versionbundle. La entrada de versión debe ser una de las versiones de actualización disponibles. Por ejemplo, si la versión actual del clúster es 1.1.1-1, las entradas de versión válidas se 1.1.1-2 o 1.1.1-x. Aunque 1.1.1 es un formato válido, no desencadenará ninguna actualización porque la versión actual ya es 1.1.1. Para iniciar una actualización, puede especificar la versión completa con la agrupación de versiones, como 1.1.1-2. Sin embargo, 1.1.2 y 1.2.x son una entrada válida y usarán el paquete de versiones más reciente disponible para 1.1.2 o 1.2.x.

Actualización del clúster

Durante el proceso de actualización del clúster, Operador Nexus realiza las siguientes operaciones:

  • Agregue un nuevo nodo de plano de control con la versión de Kubernetes especificada al clúster.
  • Una vez agregado el nuevo nodo, acordonar y purgar uno de los nodos antiguos del plano de control, lo que garantiza que las cargas de trabajo que se ejecutan en él se muevan correctamente a otros nodos del plano de control correctos.
  • Una vez que se ha purgado el nodo del plano de control anterior, se quita y se agrega un nuevo nodo del plano de control al clúster.
  • Este proceso se repite hasta que se hayan actualizado todos los nodos del plano de control del clúster.
  • Si actualiza los nodos de trabajo a través del aumento (valor predeterminado):
    • Para cada grupo de agentes del clúster, agregue un nuevo nodo de trabajo (o tantos nodos como configurados en aumento máximo) con la versión de Kubernetes especificada. Varios grupos de agentes se actualizan simultáneamente.
    • Acordonar y purgar uno de los nodos de trabajo antiguos para minimizar la interrupción de las aplicaciones en ejecución. Si usa el aumento máximo, acordona y purga tantos nodos de trabajo al mismo tiempo como el número de nodos de búfer especificados.
    • Una vez que se ha purgado el nodo de trabajo anterior, se quita y se agrega un nuevo nodo de trabajo con la nueva versión de Kubernetes al clúster (o tantos nodos como configurados en aumento máximo)
  • Si actualiza nodos de trabajo sin sobrecarga:
    • Para cada grupo de agentes del clúster, un nodo de trabajo antiguo (o tantos nodos configurados por máximo no disponible) se acordona, purga y, a continuación, se quita, antes de reemplazarlo por un nuevo nodo de trabajo por la versión de Kubernetes especificada. Varios grupos de agentes se actualizan simultáneamente.
    • Durante la actualización, habrá una reducción temporal en la capacidad del clúster, ya que los pods purgados del nodo de trabajo antiguo no tendrán inmediatamente un nuevo nodo al que moverse. Esto puede hacer que los pods entren en un estado pendiente si no hay suficiente capacidad. Por lo tanto, es fundamental diseñar el clúster para cumplir los requisitos de capacidad de la aplicación, especialmente durante las actualizaciones sin sobrecarga.
  • Este proceso se repite hasta que se hayan actualizado todos los nodos de trabajo del clúster.

Nota:

La actualización del clúster no creará nodos nuevos y reemplazará a los antiguos si la versión de imagen del sistema operativo (SO) y la versión de Kubernetes siguen siendo las mismas entre los conjuntos de versiones. Este es el comportamiento esperado, ya que la actualización solo puede incluir actualizaciones a las versiones de Addon en lugar de nuevas versiones del sistema operativo o K8s. Dado que no hay ninguna actualización gradual implicada, no hay ningún cable y purga en los nodos, por lo que no se producirán interrupciones del pod.

Importante

Asegúrese de que cualquier PodDisruptionBudgets (PDB) permita al menos unaréplica de pod que se mueva en un momento; de lo contrario, se producirá un error en la operación de purga o desalojado. Si se produce un error en la operación de purga, también se producirá un error en la operación de actualización para asegurarse de que las aplicaciones no se interrumpen. Corrija lo que hizo que la operación se detenga (es decir, archivos PDF incorrectos, falta de cuota, etcétera) y vuelva a probar la operación. También es posible configurar un tiempo de espera de purga por grupo de nodos de trabajo, después del cual se quitará el nodo incluso si los pods aún no han terminado de purgar. Esto puede impedir que las actualizaciones se bloqueen mediante archivos PDF mal configurados. El valor de tiempo de espera de purga se configura en segundos y el valor predeterminado es 1800.

  1. Actualice el clúster mediante el comando networkcloud kubernetescluster update.
az networkcloud kubernetescluster update --name myNexusK8sCluster --resource-group myResourceGroup --kubernetes-version v1.26.3
  1. Confirme que la actualización se completó correctamente con el comando show.
az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output json --query kubernetesVersion

En la salida de ejemplo siguiente se muestra que el clúster ahora se ejecuta v1.26.3:

"v1.26.3"
  1. Asegúrese de que el clúster está en buen estado.
az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output table

En la salida de ejemplo siguiente se muestra que el clúster está en buen estado:

Name                 ResourceGroup          ProvisioningState    DetailedStatus    DetailedStatusMessage             Location
------------------   ---------------------  -------------------  ----------------  --------------------------------  --------------
myNexusK8sCluster    myResourceGroup        Succeeded            Available         Cluster is operational and ready  southcentralus

Personalización del aumento de nodos o actualización de falta de disponibilidad

De forma predeterminada, Operador Nexus configura las actualizaciones para aumentar con un nodo de trabajo adicional. Un valor predeterminado de uno para la configuración de sobrecarga máxima permite al Operador Nexus minimizar la interrupción de la carga de trabajo mediante la creación de un nodo adicional antes de la acordonación o purga de las aplicaciones existentes para reemplazar un nodo con versiones anteriores. El valor de sobrecarga máxima se puede personalizar por grupo de nodos para permitir un equilibrio entre la velocidad de actualización y la interrupción de la actualización. Al aumentar el valor máximo de sobrecarga, el proceso de actualización se completa más rápido. Si establece un valor grande para la sobrecarga máxima, es posible que experimente interrupciones durante el proceso de actualización.

Por ejemplo, un valor de sobrecarga máxima del 100 % proporciona el proceso de actualización más rápido posible (se duplica el número de nodos), pero también hace que todos los nodos del grupo de nodos se purguen simultáneamente. Es posible que quiera usar un valor más alto, como este, para los entornos de prueba. En el caso de los grupos de nodos de producción, se recomienda un valor de sobrecarga máxima del 33 %.

No siempre es adecuado actualizar a través del aumento, por ejemplo, en entornos restringidos de recursos. Las actualizaciones también pueden continuar sin sobrecarga, donde primero se quita un nodo de trabajo y, a continuación, se reemplaza. Esto significa que no se necesita ningún recurso adicional, pero conduce a períodos de capacidad reducida en los que es posible que los pods no puedan programarse en un nodo. El valor máximo no disponible controla este tipo de actualización por grupo de nodos. De forma predeterminada, el valor máximo no disponible se establece en 0. Esto indica que, como máximo, 0 nodos pueden no estar disponibles, es decir, este tipo de actualización no se producirá de forma predeterminada.

La API acepta valores enteros y un valor de porcentaje para el aumento máximo y el máximo no disponible. Un entero como 5 indica que se pueden aumentar o no estar disponibles cinco nodos. Un valor del 50 % indica un valor de sobrecarga o falta de disponibilidad de la mitad del número de nodos actual del grupo.

Uno de los picos máximos o máximos no disponibles debe ser al menos 1 (o 1%), de lo contrario, no habría ningún mecanismo por el que se pudiera actualizar el clúster. Un valor de porcentaje se redondea al número de nodos más próximo. Tanto el aumento máximo como el máximo no disponible se pueden establecer en un máximo de 100 %. Si el valor máximo de sobrecarga es mayor que el número necesario de nodos que se van a actualizar, el número de nodos que se actualicen se usa como valor máximo de sobrecarga.

El aumento máximo y el máximo no disponible se pueden configurar al mismo tiempo, en cuyo caso la actualización continuará a través de una combinación de sobrecarga y falta de disponibilidad.

Importante

Las cargas de trabajo de Kubernetes estándar recorren de forma nativa los nuevos nodos cuando se purgan de los nodos que se están descomponiéndose. Tenga en cuenta que Operador Nexus Kubernetes service no puede hacer promesas de carga de trabajo para comportamientos de Kubernetes no estándar.

Pasos siguientes

  • Obtenga más información sobre los conjuntos de versiones de Nexus kubernetes.