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.

Prerrequisitos

Instale la versión más reciente de las extensiones de la CLI adecuadas.
Se requiere la extensión de la CLI más reciente networkcloud. Se puede instalar siguiendo los pasos que se indican aquí.
Acceso de suscripción para ejecutar los comandos de extensión de la CLI de nube de red (NC) y tejido de red (NF) de Azure Operator Nexus.
Recopile la siguiente información:
- Identificador de suscripción (SUBSCRIPTION)
- Nombre del clúster (CLUSTER)
- Grupo de recursos (CLUSTER_RG)
El estado detallado del clúster debe ser Running.
La conectividad del clúster al Administrador de clústeres debe ser Connected.
En Servidores de proceso de carga de trabajo > de clúster >
- Tres de los cuatro nodos del plano de control deben estar en Estado de energía On, Estado de cordón Uncordoned, Estado de listo Yes, y Degradado No.
  - El nodo de reserva del plano de control debe estar en estado de Energía Off, estado Listo No, y Degradado No.
- Los servidores del plano de administración se dividen en dos grupos en bastidores impares y pares. Para cada grupo, al menos la mitad de los servidores debe estar en Estado de energía On, Estado de cordón Uncordoned, Estado listo Yes y Estado degradado No.
  - Se recomienda tener más de 50% de los servidores del plano de administración disponibles para mitigar cualquier riesgo.
- Los números de servidor del plano de proceso varían en función de la configuración del umbral de tiempo de ejecución del clúster individual. Los clientes deben determinar su número mínimo en función de su configuración, buscando el estado de energía On, estado de aislamiento Uncordoned, estado listo Yes y estado degradado No.
En Grupo de recursos administrados de clúster > , seleccione el nombre del grupo para ir a la página del grupo de recursos.
- En el grupo de recursos, busque Kubernetes - Azure Arc para identificar la información de Azure Arc y selecciónela. El estado debe ser Connected.
  - En la página De Azure Arc, seleccione Extensiones de configuración > .
    - nc-platform-extension debe estar en estado Succeeded.
  - nc-platform-runtime-extension debe estar en estado Succeeded.

Nota:

Estas mismas comprobaciones también deben realizarse después de realizar la actualización para asegurarse de que el clúster está en buen estado.

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 en tiempo de ejecución actualizables 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 la pestaña versiones de actualización disponibles , 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 seleccionado, continúe con la actualización del clúster.

Mediante la CLI de Azure

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

az networkcloud cluster show --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>" | grep -A8 availableUpgradeVersions

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 de clúster disponibles, la lista está vacía.

Configuración de los parámetros del umbral de proceso para la actualización del runtime mediante el clúster `updateStrategy`

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 "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--update-strategy strategy-type="<strategyType>" threshold-type="<thresholdType>" \
threshold-value="<thresholdValue>" max-unavailable="<maxNodesOffline>" \
wait-time-minutes="<waitTimeBetweenRacks>" \
--subscription "<SUBSCRIPTION>"

Parámetros obligatorios:

strategy-type: define la estrategia de actualización. La configuración usada es Rack (Rack-by-Rack) O PauseAfterRack (Pausar y esperar confirmación del usuario antes de que se inicie cada rack). El valor predeterminado es Rack. Para realizar una actualización en tiempo de ejecución de clúster mediante la PauseAfterRack estrategia, siga los pasos descritos en Upgrade Cluster Runtime with PauseAfterRack Strategy (Actualizar tiempo de ejecución del clúster con PauseAfterRack Strategy).
threshold-type: determina cómo se debe evaluar el umbral, aplicado en las unidades definidas por la estrategia. La configuración usada es PercentSuccess OR 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 rack actualizado. El valor predeterminado es 32767.
wait-time-minutes: retraso o período de espera antes de actualizar un rack. El valor predeterminado es 15.

El ejemplo siguiente es para un cliente que usa la estrategia Rack-by-Rack con un porcentaje de éxito de 60% y una pausa de 1 minuto.

az networkcloud cluster update --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" \
threshold-value=60 wait-time-minutes=1 \
--subscription "<SUBSCRIPTION>"

Compruebe la actualización:

az networkcloud cluster show --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>" | grep -A5 updateStrategy

  "updateStrategy": {
    "maxUnavailable": 32767,
      "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 rack no se pueden aprovisionar (bajo el criterio de Rack por rack), la actualización del clúster espera indefinidamente hasta que se cumpla la condición. Si se aprovisionan correctamente 60 % o más de los nodos de proceso, la implementación del clúster pasa al siguiente bastidor de nodos de proceso. Si hay demasiados fallos en el bastidor, el hardware debe repararse antes de que la actualización pueda continuar.

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

az networkcloud cluster update --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--update-strategy strategy-type="Rack" threshold-type="CountSuccess" \
threshold-value=10 wait-time-minutes=1 \
--subscription "<SUBSCRIPTION>"

Compruebe la actualización:

az networkcloud cluster show --name "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>" | grep -A5 updateStrategy

  "updateStrategy": {
    "maxUnavailable": 32767,
      "strategyType": "Rack",
      "thresholdType": "CountSuccess",
      "thresholdValue": 10,
      "waitTimeMinutes": 1

En este ejemplo, si menos del 10 nodos de proceso que se aprovisionan en un rack no se pueden aprovisionar (bajo el criterio de Rack por rack), la actualización del clúster espera indefinidamente hasta que se cumpla la condición. 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. Si hay demasiados fallos en el bastidor, el hardware debe repararse antes de que la actualización pueda continuar.

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" todavía podría indicar que la actualización se realizó correctamente. Para solucionar problemas con los equipos sin sistema operativo, consulte Solución de problemas del servidor Azure Operator Nexus

Actualización del entorno de ejecución 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 "<CLUSTER>" \
--target-cluster-version "<versionNumber>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>"

Este comando inicia el proceso de actualización en tiempo de ejecución para el clúster especificado. El propio comando se completa normalmente en unos 5 minutos, pero este comando solo inicia el proceso de actualización. La actualización en tiempo de ejecución real continúa ejecutándose en segundo plano y puede tardar varias horas en completarse, ya que actualiza los nodos en bastidor e instala la nueva versión del sistema operativo.

El estado detallado y la información de diagnóstico del paso de inicio están disponibles en el portal de Azure en el recurso del clúster (Operator Nexus). La siguiente información se incluye en la updateVersion entrada del properties.actionStates campo cuando se usa la versión 2025-07-01-preview de API o superior.

Hora de inicio y finalización de la acción.
Estado actual (Succeeded, Failedo InProgress).
Cualquier mensaje de error o contexto adicional asociado al estado actual.
Identificador de correlación de la operación original cluster update-version, tal como se muestra en el registro de actividad de Azure.
Lista ordenada de pasos individuales y su estado, por ejemplo Validate Cluster conditions and upgrade versions, y Initiate Platform Runtime Extension update.

Importante

La properties.actionStates entrada de updateVersion solo refleja la fase de inicio breve (validación e iniciación de solicitudes que normalmente se completa en ~5 minutos). No realiza un seguimiento del progreso por bastidor de la actualización principal. Para supervisar la actualización completa, utilice el estado detallado del clúster y el mensaje de estado detallado en la información general del recurso, o realice una consulta a través de az networkcloud cluster show.

Salida de ejemplo JSON View para el recurso Cluster (Operator Nexus):

{
  "properties": {
    "actionStates": [
      {
        "correlationId": "b66643b7-2e1d-4a5c-a954-ca0e38368984",
        "status": "Completed",
        "actionType": "Microsoft.NetworkCloud/clusters/updateVersion",
        "endTime": "2025-08-01T03:46:13Z",
        "message": "Cluster upgrade to 4.6.0 successfully initiated - monitor progress via cluster detailed status",
        "startTime": "2025-08-01T03:42:08Z",
        "stepStates": [
          {
            "status": "Completed",
            "endTime": "2025-08-01T03:42:08Z",
            "message": "Cluster validation and version checks passed",
            "startTime": "2025-08-01T03:42:08Z",
            "stepName": "Validate Cluster conditions and upgrade versions"
          },
          {
            "status": "Completed",
            "endTime": "2025-08-01T03:46:11Z",
            "message": "Platform Runtime Extension deployment initiated",
            "startTime": "2025-08-01T03:42:39Z",
            "stepName": "Initiate Platform Runtime Extension update"
          },
          {
            "status": "Completed",
            "endTime": "2025-08-01T03:46:11Z",
            "message": "Platform Runtime Extension installation completed",
            "startTime": "2025-08-01T03:46:11Z",
            "stepName": "Monitor Platform Runtime Extension readiness"
          },
          {
            "status": "Completed",
            "endTime": "2025-08-01T03:46:13Z",
            "message": "Platform Cluster version updated successfully",
            "startTime": "2025-08-01T03:46:13Z",
            "stepName": "Update Platform Cluster version specification"
          }
        ]
      }
    ]
  }
}

Una vez completado este comando, comienza el proceso de actualización en tiempo de ejecución completo. Este proceso puede tardar varias horas en completarse, en función del número de bastidores del clúster y del número de nodos de trabajo de cada bastidor.

En primer lugar, se actualizan los nodos de administración y, después, se actualizan secuencialmente los nodos de trabajo, Rack-by-Rack.
Los servidores de administración se separan en dos grupos, que se actualizan por separado. Este enfoque permite a los componentes que se ejecutan en los servidores de administración garantizar la resistencia durante la actualización en tiempo de ejecución aplicando reglas de afinidad.
Los CSN también aprovechan esta funcionalidad colocando una instancia en cada grupo de administración.
No hay ninguna interacción del cliente con esta funcionalidad. Sin embargo, es posible que haya etiquetas adicionales en los nodos de administración para identificar los grupos.

La actualización se considera finalizada cuando el 80 % de los nodos de trabajo por bastidor y el 50 % de los nodos de administración en cada grupo se han actualizado correctamente. Es posible que las cargas de trabajo se vean afectadas mientras los nodos de trabajo de un bastidor están en proceso de actualización, pero las cargas de trabajo de todos los demás bastidores no se ven 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 a través de Azure Portal, vaya al recurso clúster de destino. En la pantalla Información general del clúster, el estado detallado se proporciona 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 "<CLUSTER>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>"

La salida debe ser la información del clúster de destino y el estado detallado del clúster y el mensaje de estado detallado del clúster deben estar presentes. 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 en tiempo de ejecución puede tardar mucho tiempo en finalizar correctamente, no hay ningún tiempo de espera establecido especificado actualmente. 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.

Identificación de la actualización de equipos sin sistema operativo detenidos o bloqueados

Se proporciona una guía para la identificación de problemas con los nodos de trabajo en Solución de problemas de aprovisionamiento de equipos sin sistema operativo.

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 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 rack no se ha actualizado a la nueva versión del runtime antes del error de hardware, la máquina se aprovisiona con la versión anterior del runtime. La máquina se actualiza junto con el bastidor cuando el bastidor inicia su actualización.

Después de una actualización en tiempo de ejecución, el clúster muestra el estado de aprovisionamiento "fallido"

Durante una actualización en tiempo de ejecución, 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.

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2025-11-21