Actualización del entorno de ejecución del clúster desde la CLI de Azure

En esta guía se explican los pasos necesarios para instalar la CLI de Azure necesaria, así como las extensiones necesarias para interactuar con Operator Nexus.

Requisitos previos

• Se debe instalar la CLI de Azure.
• Se requiere la extensión de la CLI networkcloud. Si la extensión networkcloud no está instalada, se puede instalar siguiendo los pasos que se indican aquí.
• Acceso a Azure Portal para el clúster de destino que se va a actualizar.
• Debe iniciar sesión en la misma suscripción que el clúster de destino a través de az login.
• El clúster de destino debe estar en estado en ejecución, todos los nodos del plano de control deben funcionar a la perfección y más del 80 % de los nodos de proceso deben estar en buen estado y en funcionamiento.

Comprobación de la versión actual del entorno de ejecución

Compruebe la versión actual del entorno de ejecución del clúster antes de la actualización: Comprobación de la versión actual del entorno de ejecución del clúster.

Búsqueda de las versiones en tiempo de ejecución disponibles

Mediante el Portal de Azure

Para buscar las versiones del runtime que se puedan actualizar disponibles, vaya al clúster de destino en Azure Portal. En el panel de información general del clúster, vaya a la pestaña Versiones de actualización disponibles.

En ella podemos ver las distintas versiones del clúster que están disponibles actualmente para actualizar. El operador puede seleccionar en la lista las versiones del runtime de destino. Una vez seleccionadas, realice la actualización del clúster.

Con Azure CLI

Las actualizaciones disponibles se pueden recuperar mediante la CLI de Azure:

az networkcloud cluster show --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--subscription <subscriptionID>

En la salida, puede encontrar la propiedad availableUpgradeVersions y examinar el campo targetClusterVersion:

  "availableUpgradeVersions": [
    {
      "controlImpact": "True",
      "expectedDuration": "Upgrades may take up to 4 hours + 2 hours per rack",
      "impactDescription": "Workloads will be disrupted during rack-by-rack upgrade",
      "supportExpiryDate": "2023-07-31",
      "targetClusterVersion": "3.3.0",
      "workloadImpact": "True"
    }
  ],

Si no hay actualizaciones del clúster disponibles, la lista estará vacía.

Configuración de los parámetros del umbral de proceso para la actualización en tiempo de ejecución mediante los valores de updateStrategy del clúster

El siguiente comando de la CLI de Azure se usa para configurar los parámetros del umbral de proceso para que se realice una actualización del runtime:

az networkcloud cluster update /
--name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" /
threshold-value="<thresholdValue>" max-unavailable=<maxNodesOffline> /
wait-time-minutes=<waitTimeBetweenRacks> /
--subscription <subscriptionID>

Parámetros obligatorios:

• strategy-type: define la estrategia de actualización. Puede ser "Rack" (bastidor por bastidor) O "PauseAfterRack" (actualice un bastidor cada vez y después espere la confirmación antes de pasar al siguiente bastidor. El valor predeterminado es Rack. Para llevar a cabo una actualización en tiempo de ejecución de clúster mediante la estrategia "PauseRack" siga los pasos descritos en Actualización del entorno de ejecución del clúster con una estrategia de pausa de bastidor
• threshold-type: determina cómo se debe evaluar el umbral, aplicado en las unidades definidas por la estrategia. Puede ser "PercentSuccess" O "CountSuccess". El valor predeterminado es PercentSuccess.
• threshold-value: valor numérico de umbral que se usa para evaluar una actualización. El valor predeterminado es 80.

Parámetros opcionales:

• max-unavailable: el número máximo de nodos de trabajo que pueden estar a la vez sin conexión, es decir, el bastidor actualizado. El valor predeterminado es 32767.
• wait-time-minutes: retraso o período de espera antes de actualizar un bastidor. El valor predeterminado es 15.

El siguiente ejemplo es para un cliente usando la estrategia Bastidor por bastidor con un porcentaje de éxito del 60 % y una pausa de 1 minuto.

az networkcloud cluster update --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" /
threshold-value=60 wait-time-minutes=1 /
--subscription <subscriptionID>

Compruebe la actualización:

az networkcloud cluster show --resource-group "<resourceGroup>" /
--name "<clusterName>" /
--subscription <subscriptionID>| grep -a5 updateStrategy

      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 60,
      "waitTimeMinutes": 1

En este ejemplo, si menos del 60 % de los nodos de proceso que se aprovisionan en un bastidor no se pueden aprovisionar (en un rack por bastidor), se produce un error en la implementación del clúster. Si el 60 % o más de los nodos de proceso se aprovisionan correctamente, la implementación del clúster pasa al siguiente bastidor de nodos de proceso.

El ejemplo siguiente es para un cliente que usa la estrategia Bastidor por bastidor con un tipo de umbral CountSuccess de 10 nodos por bastidor y una pausa de 1 minuto.

az networkcloud cluster update --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="CountSuccess" /
threshold-value=10 wait-time-minutes=1 /
--subscription <subscriptionID>

Compruebe la actualización:

az networkcloud cluster show --resource-group "<resourceGroup>" /
--name "<clusterName>" /
--subscription <subscriptionID>| grep -a5 updateStrategy

      "strategyType": "Rack",
      "thresholdType": "CountSuccess",
      "thresholdValue": 10,
      "waitTimeMinutes": 1

En este ejemplo, si menos de 10 nodos de proceso que se están aprovisionando en un bastidor fallan en el aprovisionamiento (bastidor por bastidor), la implementación del clúster falla. Si se aprovisionan correctamente 10 o más nodos de proceso, la implementación del clúster pasa al siguiente bastidor de nodos de proceso.

Nota:

update-strategy no se puede cambiar después de que se haya iniciado la actualización del entorno de ejecución del clúster. Cuando se establece un valor de umbral por debajo de 100 %, es posible que los nodos incorrectos no se actualicen, pero el estado "Clúster" podría indicar que la actualización se realizó correctamente. Para solucionar problemas con las máquinas sin sistema operativo, consulte Solución de problemas del servidor Azure Operator Nexus

Actualización del runtime del clúster mediante la CLI

Para realizar una actualización del runtime, use el siguiente comando de la CLI de Azure:

az networkcloud cluster update-version --cluster-name "<clusterName>" /
--target-cluster-version "<versionNumber>" /
--resource-group "<resourceGroupName>" /
--subscription <subscriptionID>

La actualización del runtime es un proceso largo. En primer lugar, se actualizan los nodos de administración y, después, se actualizan secuencialmente los nodos de trabajo, bastidor por bastidor. La actualización se considera finalizada cuando el 80 % de los nodos de trabajo por bastidor y el 100 % de los nodos de administración se han actualizado correctamente. Es posible que las cargas de trabajo se vean afectadas si los nodos de trabajo de un bastidor están en proceso de actualización; sin embargo, las cargas de trabajo de los restantes bastidores no se verán afectadas. Se recomienda tener en cuenta la colocación de cargas de trabajo a la luz de este diseño de implementación.

La actualización de todos los nodos tarda varias horas, en función del número de bastidores que existen para el clúster. Dada la duración del proceso de actualización, se recomienda comprobar periódicamente el estado de detalle del clúster para conocer el estado actual de la actualización. Para comprobar el estado de la actualización, observe el estado detallado del clúster. Esta comprobación se puede realizar desde Azure Portal o desde la CLI de Azure.

Para ver el estado de actualización desde Azure Portal, vaya al recurso de clúster de destino. En la pantalla Información general del clúster, se proporciona el estado detallado, junto con un mensaje de estado detallado.

La actualización del clúster está en curso cuando detailedStatus está establecido en Updating y detailedStatusMessage muestra el progreso de la actualización. Algunos ejemplos de progreso de actualización, que se muestran en detailedStatusMessage, son Waiting for control plane upgrade to complete..., Waiting for nodepool "<rack-id>" to finish upgrading..., etc.

La actualización del clúster se completa cuando detailedStatus se establece en Running y detailedStatusMessage muestra el mensaje Cluster is up and running.

Para ver el estado de actualización a través de la CLI de Azure, use az networkcloud cluster show.

az networkcloud cluster show --cluster-name "<clusterName>" /
--resource-group "<resourceGroupName>" /
--subscription <subscriptionID>

La salida debe ser la información del clúster de destino y también deben estar presentes tanto el estado detallado del clúster como el mensaje de estado detallado. Para obtener información más detallada sobre el progreso de la actualización, se puede consultar el estado del nodo individual en cada bastidor. En la sección de referencia se proporciona un ejemplo de comprobación del estado en Roles de máquina BareMetal.

Preguntas más frecuentes

Identificación de que la actualización del clúster está detenida o bloqueada

Durante una actualización del runtime, se puede dar el caso de que no avance, pero que el estado detallado refleje que la actualización sigue en curso. Dado que la actualización del runtime puede tardar mucho tiempo en finalizar, actualmente no hay ningún tiempo de espera establecido. Por consiguiente, también es aconsejable comprobar periódicamente tanto los registros como el estado de detalle del clúster para determinar si la actualización está intentando actualizar indefinidamente.

Podemos identificar una situación de indefinitely attempting to upgrade examinando los registros del clúster, el mensaje detallado y el mensaje de estado detallado. Si se ha producido un tiempo de espera, observaríamos que el clúster se está reconciliando sobre lo mismo indefinidamente y, por tanto, no avanza. En ese momento, se recomienda comprobar los registros de clúster o la configuración para ver si hay algún error o si una actualización concreta impide el progreso de la operación.

Si el error es de hardware, no es preciso volver a ejecutar la actualización

Aunque se haya ha producido un error de hardware durante una actualización, la actualización del runtime continúa, siempre que se cumplan los umbrales establecidos para los nodos de proceso y de administración o control. Una vez que la máquina se corrige o se reemplaza, se aprovisiona con el sistema operativo del runtime de la plataforma actual, que contiene la versión de destino del runtime.

Si se produce un error de hardware y no se puede realizar la actualización del runtime porque no se cumplen los umbrales de los nodos de proceso y control, es posible que haya que volver a ejecutar la actualización del runtime. Dependiendo de cuándo se produjo el error y el estado de los servidores individuales en un bastidor. Si un bastidor se actualizó antes de un error, se usaría la versión del runtime actualizada cuando se vuelvan a aprovisionar los nodos. Si la especificación del bastidor no se ha actualizado a la nueva versión del runtime antes del error de hardware, la máquina se aprovisionaría con la versión anterior del runtime. Para actualizar a la nueva versión de runtime, envíe una nueva solicitud de actualización del clúster. Solo se actualizan los nodos con la versión anterior de runtime. Los hosts que se funcionaban correctamente en la acción de actualización anterior no lo harán ahora.

Después de una actualización del runtime, el clúster muestra el estado de aprovisionamiento "Con errores"

Durante una actualización en runtime, el clúster entra en un estado de Upgrading. Si se produce un error en la actualización de runtime, el clúster entra en un estado de aprovisionamiento de Failed. Los componentes de infraestructura (por ejemplo, el dispositivo de almacenamiento) pueden provocar errores durante la actualización. En algunos escenarios, puede ser necesario diagnosticar el error con el soporte técnico de Microsoft.