Atualizar a execução do Cluster através da CLI do Azure

Este guia de instruções explica as etapas para instalar a CLI do Azure necessária e as extensões necessárias para interagir com o Operator Nexus.

Pré-requisitos

1. Instale a versão mais recente das extensões CLI apropriadas.
2. É necessária a mais recente extensão networkcloud CLI. Ele pode ser instalado seguindo as etapas listadas aqui.
3. Acesso por assinatura para executar os comandos de extensão da CLI da malha de rede (NF) e da nuvem de rede (NC) do Azure Operator Nexus.
4. Colete as seguintes informações:
   • ID da subscrição (SUBSCRIPTION)
   • Nome do cluster (CLUSTER)
   • Grupo de recursos (CLUSTER_RG)
5. O estado detalhado do cluster deve ser Running.
6. A conectividade entre o Cluster e o Gestor de Cluster deve ser Connected.
7. Em Clusters > de Servidores de Computação > para Carga de Trabalho
   • Três dos quatro nós do plano de controlo devem ser Estado de Energia On, Estado de Isolamento Uncordoned, Estado Pronto Yes e Degradado No.
     • O nó suplente do plano de controlo deve estar no estado de Energia Off, no estado Pronto No e no estado Degradado No.
   • Os servidores do plano de gestão estão divididos em dois grupos em racks ímpares e pares. Para cada grupo, pelo menos metade dos servidores deve estar em Estado de Potência On, Estado de Cordão Uncordoned, Estado Pronto Yes e Degradado No.
     • Recomenda-se ter mais de 50% dos servidores do plano de gestão disponíveis para mitigar qualquer risco.
   • O número de servidores do plano de cálculo varia consoante os limites de execução individuais do cluster. Os clientes precisam determinar o seu número mínimo com base nas definições, verificando o estado de energia elétrica On, o estado de isolamento Uncordoned, o estado de pronto Yes e o estado degradado No.
8. Em Grupo de Recursos Geridos por Cluster > , selecione o nome do grupo para ir à página do grupo de recursos.
   • No grupo de recursos, procure Kubernetes - Azure Arc para identificar a informação do Azure Arc e selecione-a. O estado deve ser Connected.
     • Na página Azure Arc, selecione Definições > Extensões.
       • nc-platform-extension deve estar em estado Succeeded.
     • nc-platform-runtime-extension deve estar em estado Succeeded.

Verificando a versão atual do tempo de execução

Verifique a versão atual do tempo de execução do cluster antes da atualização: Como verificar a versão atual do tempo de execução do cluster.

Localizando versões de tempo de execução disponíveis

Através do portal do Azure

Para encontrar versões de tempo de execução atualizáveis disponíveis, navegue até o Cluster de destino no portal do Azure. No painel Visão geral do Cluster, navegue até ao separador Versões de atualização disponíveis.

Na guia Versões de Atualização Disponíveis, podemos ver as diferentes versões de Cluster que estão atualmente disponíveis para atualização. O operador pode selecionar entre as versões de tempo de execução de destino listadas. Uma vez selecionado, prossiga para atualizar o Cluster.

Através da CLI do Azure

As atualizações disponíveis podem ser recuperadas por meio da CLI do Azure:

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

Na saída, pode-se encontrar a availableUpgradeVersions propriedade e ver o targetClusterVersion campo:

  "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"
    }
  ],

Se não houver atualizações de cluster disponíveis, a lista estará vazia.

Configurar parâmetros de limite de computação para atualização de tempo de execução usando o Cluster updateStrategy

O seguinte comando da CLI do Azure é usado para configurar os parâmetros de limite de computação para uma atualização de tempo de execução:

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 necessários:

• strategy-type: Define a estratégia de atualização. As configurações usadas são Rack (Rack-by-Rack) OU PauseAfterRack (Pausar para o utilizador antes de cada Rack começar). O valor predefinido é Rack. Para executar uma atualização de tempo de execução do Cluster usando a estratégia PauseAfterRack, siga as etapas descritas em Upgrade Cluster Runtime with PauseAfterRack Strategy.
• tipo de limiar: Determina como o limiar deve ser avaliado, aplicado nas unidades definidas pela estratégia. As configurações usadas são PercentSuccess OU CountSuccess. O valor predefinido é PercentSuccess.
• valor-limite: o valor do limite numérico usado para avaliar uma atualização. O valor predefinido é 80.

Parâmetros opcionais:

• max-unavailable: o número máximo de nós de trabalho que podem estar offline, isto é, racks a serem atualizados ao mesmo tempo. O valor predefinido é 32767.
• wait-time-minutes: O atraso ou período de espera antes de atualizar um rack. O valor predefinido é 15.

O exemplo a seguir é para um cliente que usa a estratégia Rack-by-Rack com uma porcentagem de sucesso de 60% e uma 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>"

Verifique a atualização:

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

Neste exemplo, se menos de 60% dos nós de computação que estão sendo provisionados em um rack falharem no provisionamento (em uma base rack-by-rack), a atualização do cluster aguardará indefinidamente até que a condição seja atendida. Se 60% ou mais dos nós de computação forem provisionados com êxito, a implantação do cluster passará para o próximo rack de nós de computação. Se houver muitas falhas no rack, o hardware deve ser reparado antes que a atualização possa continuar.

O exemplo a seguir é para um cliente que usa a estratégia Rack-by-Rack com um tipo de limite CountSuccess de 10 nós por rack e uma 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>"

Verifique a atualização:

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

Neste exemplo, se menos de 10 nós de computação que estão sendo provisionados em um rack falharem no provisionamento (em uma base rack a rack), a atualização do cluster aguardará indefinidamente até que a condição seja atendida. Se 10 ou mais dos nós de computação forem provisionados com êxito, a implantação do Cluster passará para o próximo rack de nós de computação. Se houver muitas falhas no rack, o hardware deve ser reparado antes que a atualização possa continuar.

Atualizar o tempo de execução do cluster usando a CLI

Para executar uma atualização do tempo de execução, use o seguinte comando da CLI do Azure:

az networkcloud cluster update-version --cluster-name "<CLUSTER>" \
--target-cluster-version "<versionNumber>" \
--resource-group "<CLUSTER_RG>" \
--subscription "<SUBSCRIPTION>"

Este comando inicia o processo de atualização de tempo de execução para o cluster especificado. O comando em si normalmente é concluído em cerca de 5 minutos, mas este comando apenas inicia o processo de atualização. A atualização do tempo de execução real continua a ser executada em segundo plano e pode levar várias horas para ser concluída, pois atualiza os nós rack por rack e instala a nova versão do sistema operacional.

Informações detalhadas de status e diagnóstico para a etapa de iniciação estão disponíveis no portal do Azure no JSON View recurso do Cluster (Operator Nexus). As informações a seguir são incluídas na updateVersion entrada do campo, ao usar a properties.actionStates versão 2025-07-01-preview da API ou superior.

• Hora de início e fim da ação.
• Situação atual (Succeeded, Failed, ou InProgress).
• Qualquer contexto extra ou mensagem de erro associada ao status atual.
• A ID de Correlação para a operação original cluster update-version , conforme também mostrado no log de Atividades do Azure.
• Uma lista ordenada de etapas individuais e seu status - por exemplo Validate Cluster conditions and upgrade versions, e Initiate Platform Runtime Extension update.

Exemplo JSON View de saída para o 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"
          }
        ]
      }
    ]
  }
}

Quando esse comando estiver concluído, o processo de atualização do tempo de execução completo será iniciado. Esse processo pode levar várias horas para ser concluído, dependendo do número de racks no cluster e do número de nós de trabalho em cada rack.

• A atualização primeiro atualiza os nós de gestão e, em seguida, sequencialmente rack a rack para os nós de trabalho.
• Os servidores de gerenciamento são segregados em dois grupos, que são atualizados separadamente. Essa abordagem permite que os componentes executados nos servidores de gerenciamento garantam resiliência durante a atualização de tempo de execução aplicando regras de afinidade.
• As CSNs também aproveitam essa funcionalidade colocando uma instância em cada grupo de gerenciamento.
• Não há interação do cliente com essa funcionalidade. No entanto, pode haver rótulos adicionais vistos nos nós de gerenciamento para identificar os grupos.

A atualização é considerada concluída quando 80% dos nós de trabalho por rack e 50% dos nós de gerenciamento em cada grupo são atualizados com êxito. As cargas de trabalho podem ser afetadas enquanto os nós de trabalho em um rack estão em processo de atualização, no entanto, as cargas de trabalho em todos os outros racks não são afetadas. É encorajada a consideração da colocação da carga de trabalho à luz desta conceção de implementação.

A atualização de todos os nós leva várias horas, dependendo do número de racks existentes para o Cluster. Devido à duração do processo de atualização, o status de detalhes do cluster deve ser verificado periodicamente para o estado atual da atualização. Para verificar o status da atualização, observe o status detalhado do Cluster. Esta verificação pode ser feita através do portal ou az CLI.

Para exibir o status da atualização por meio do portal do Azure, navegue até o recurso de Cluster de destino. Na tela de Visão geral do Cluster , o status detalhado é fornecido juntamente com uma mensagem de status detalhada.

A atualização de cluster está em andamento quando detailedStatus é definido como Updating e detailedStatusMessage mostra o progresso da atualização. Alguns exemplos de progresso de atualização mostrados em detailedStatusMessage são Waiting for control plane upgrade to complete..., Waiting for nodepool "<rack-id>" to finish upgrading..., etc.

A atualização do cluster é concluída quando detailedStatus é definido como Running e detailedStatusMessage mostra a mensagem Cluster is up and running

Para exibir o status da atualização por meio da CLI do Azure, use az networkcloud cluster show.

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

A saída deve ser a informação do Cluster de destino, incluindo o estado detalhado do Cluster e a mensagem correspondente. Para obter informações mais detalhadas sobre o progresso da atualização, pode verificar o estado do nó individual em cada rack. Um exemplo de verificação do estado é fornecido na seção de referência em Funções de Máquina BareMetal.

Perguntas Frequentes

Identificação da atualização de cluster paralisada/bloqueada

Durante uma atualização em tempo de execução, é possível que a atualização não avance, mas o status de detalhes reflete que a atualização ainda está em andamento. Como a atualização em tempo de execução pode levar muito tempo para ser concluída com êxito, não há um tempo limite definido atualmente especificado. Portanto, é aconselhável também verificar periodicamente o estado e os logs detalhados do seu cluster para determinar se a atualização está a tentar prosseguir indefinidamente.

Podemos identificar uma indefinitely attempting to upgrade situação observando os logs do Cluster, a mensagem detalhada e a mensagem de estado detalhada. Se ocorrer um tempo limite, observaremos que o Cluster está continuamente se reconciliando com o mesmo indefinidamente e sem avançar. A partir daqui, recomendamos verificar os logs de cluster ou o LAW configurado para ver se há uma falha ou uma atualização específica que esteja causando a falta de progresso.

Identificando a atualização da máquina bare metal paralisada/presa

Um guia para identificar problemas com o provisionamento de nós de trabalho está disponível em "Solução de problemas de provisionamento de máquinas 'bare metal'".

Falha de hardware não requer reexecução de atualização

Se ocorrer uma falha de hardware durante uma atualização, a atualização em tempo de execução continuará desde que os limites definidos sejam atingidos para os nós de computação e gerenciamento/controle. Assim que a máquina é reparada ou substituída, ela é provisionada com o sistema operativo da plataforma de runtime atual, que contém a versão alvo do runtime. Se um rack foi atualizado antes de uma falha, a versão de tempo de execução atualizada será usada quando os nós forem reprovisionados. Se a especificação do rack não foi atualizada para a versão de tempo de execução atualizada antes da falha de hardware, a máquina será provisionada com a versão de tempo de execução anterior quando o hardware for reparado. A máquina é atualizada junto com o rack quando o rack inicia sua atualização.

Após uma atualização do ambiente de execução, o cluster mostra o estado de provisionamento "Com Falha"

Durante uma atualização de tempo de execução, o Cluster entra num estado de Upgrading. Se a atualização de tempo de execução falhar, o Cluster entrará em um estado de provisionamento Failed. Os componentes da infraestrutura (por exemplo, o Storage Appliance) podem causar falhas durante o upgrade. Em alguns cenários, pode ser necessário diagnosticar a falha com o suporte da Microsoft.