Atualizar o runtime do cluster da CLI do Azure

  • Artigo

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 Nexus do Operador.

Pré-requisitos

  1. A CLI do Azure de Instalação deve ser instalada.
  2. A extensão CLI networkcloud é necessária. Se a extensão networkcloud não estiver instalada, ela poderá ser instalada seguindo as etapas listadas aqui.
  3. Acesso ao portal do Azure para que o cluster de destino seja atualizado.
  4. Você deve estar conectado à mesma assinatura do cluster de destino por meio de az login
  5. O cluster de destino deve estar em um estado de execução, com todos os nós do plano de controle íntegros e 80% dos nós de computação em um estado em execução e íntegro.

Localizando versões de runtime disponíveis

Via Portal

Para encontrar versões de runtime atualizáveis disponíveis, navegue até o cluster de destino no portal do Azure. No painel de visão geral do cluster, navegue até a guia Versões de atualização disponíveis.

Captura de tela do portal do Azure mostrando a guia correta para identificar as atualizações de cluster disponíveis.

Na guia versões de atualização disponíveis, podemos ver as diferentes versões de cluster que estão disponíveis para atualização no momento. O operador pode selecionar entre as versões de runtime de destino listadas. Depois de selecionado, prossiga para atualizar o cluster.

Captura de tela do portal do Azure mostrando as atualizações de cluster disponíveis.

Via CLI do Azure

As atualizações disponíveis são recuperáveis por meio da CLI do Azure:

az networkcloud cluster show --name "clusterName" --resource-group "resourceGroup"

Na saída, você pode encontrar a propriedade availableUpgradeVersions e examinar o 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"
    }
  ],

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

Atualizando o runtime do cluster usando a CLI

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

az networkcloud cluster update-version --cluster-name "clusterName" --target-cluster-version
  "versionNumber" --resource-group "resourceGroupName"

A atualização de runtime é um processo longo. A atualização primeiro atualiza os nós de gerenciamento e, em seguida, sequencialmente rack por rack para os nós de trabalho. A atualização é considerada concluída quando 80% dos nós de trabalho por rack e 100% dos nós de gerenciamento foram 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 serão afetadas. A consideração do posicionamento da carga de trabalho à luz desse design de implementação é incentivada.

A atualização de todos os nós leva várias horas, mas pode levar mais se outros processos, como atualizações de firmware, também fizerem parte da atualização. Devido à duração do processo de atualização, é recomendável verificar periodicamente o status de detalhes do Cluster quanto ao estado atual da atualização. Para verificar o status da atualização, observe o status detalhado do cluster. Essa verificação pode ser feita por meio do portal ou da CLI az.

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

A atualização do cluster está em andamento quando detailedStatus está 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 está definido como Running e detailedStatusMessage mostra a mensagem Cluster is up and running

Captura de tela do portal do Azure mostrando a atualização do cluster em andamento.

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

az networkcloud cluster show --cluster-name "clusterName" --resource-group "resourceGroupName"

A saída deve ser as informações do cluster de destino e a mensagem detalhada de status e status de detalhes do cluster deve estar presente. Para obter informações mais detalhadas sobre o progresso da atualização, o BMM individual em cada Rack pode ser verificado quanto ao status. Exemplo disso é fornecido na seção de referência em Funções de computador BareMetal.

Configurar parâmetros de limite de computação para atualização de runtime 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 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>

Parâmetros requeridos:

  • strategy-type: define a estratégia de atualização. Nesse caso, "Rack" significa que as atualizações ocorrem rack por rack. O valor padrão é “Rack”.
  • threshold-type: determina como o limite deve ser avaliado, aplicado nas unidades definidas pela estratégia. O valor padrão é "PercentSuccess".
  • threshold-value: o valor de limite numérico usado para avaliar uma atualização. O valor padrão é 80.

Parâmetros opcionais:

  • max-unavailable: o número máximo de nós de trabalho que podem ser offline, ou seja, rack atualizado por vez. O valor padrão é 32767.
  • wait-time-minutes: o período de atraso ou espera antes de atualizar um rack. O valor padrão é 15.

Um exemplo de uso do comando é o seguinte:

az networkcloud cluster update --name "cluster01" --resource-group "cluster01-rg" --update-strategy strategy-type="Rack" threshold-type="PercentSuccess" threshold-value=70 max-unavailable=16 wait-time-minutes=15

Após a execução bem-sucedida do comando, os valores updateStrategy especificados serão aplicados ao cluster:

    "updateStrategy": {
      "maxUnavailable": 16,
      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 70,
      "waitTimeMinutes": 15,
    }

Observação

Quando um valor limite abaixo de 100% é definido é possível que os nós não íntegros não sejam atualizados, mas o status “Cluster” ainda pode indicar que a atualização foi bem-sucedida. Para solucionar problemas com computadores bare-metal, consulte Solucionar problemas do servidor Nexus do Operador do Azure

Atualizar com a estratégia PauseRack

A partir da versão de API 2024-06-01-preview, as atualizações de runtime podem ser disparadas usando uma estratégia “PauseRack”. Quando você executa uma atualização de runtime de cluster com a estratégia “PauseRack”, ela atualizará um rack de cada vez no cluster e, em seguida, irá parar, aguardando a confirmação antes de prosseguir para o próximo rack. Todos os limites existentes continuarão a ser respeitados com a estratégia “PauseRack”. Para realizar uma atualização de runtime de cluster usando a estratégia “PauseRack”, siga as etapas descritas em Atualização do runtime de cluster com uma estratégia “PauseRack”

Perguntas frequentes

Identificando a Atualização de Cluster Travada/Paralisada

Durante uma atualização de runtime, é 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 de runtime pode levar muito tempo para ser concluída com êxito, não há nenhum tempo limite definido especificado no momento. Portanto, é aconselhável também verificar periodicamente o status e os logs de detalhes do cluster para determinar se a atualização está tentando atualizar indefinidamente.

Podemos identificar quando esse é o caso examinando os logs do Cluster, a mensagem detalhada e a mensagem de status detalhada. Se um tempo limite tiver ocorrido, observaremos que o Cluster está se reconciliando continuamente sobre o mesmo indefinidamente e não seguindo em frente. 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.

Falha de hardware não requer a re-execução da atualização

Se ocorrer uma falha de hardware durante uma atualização, a atualização de runtime continuará desde que os limites definidos sejam atendidos para os nós de computação e gerenciamento/controle. Depois que o computador é corrigido ou substituído, ele é provisionado com o sistema operacional do runtime da plataforma atual, que contém a versão de destino do runtime.

Se ocorrer uma falha de hardware e a atualização de runtime falhar porque os limites não foram atendidos para nós de computação e controle, a re-execução da atualização de runtime poderá ser necessária dependendo de quando a falha ocorreu e do estado dos servidores individuais em um rack. Se um rack tiver sido atualizado antes de uma falha, a versão de runtime atualizada será usada quando os nós forem reprovisionados. Se a especificação do rack não foi atualizada para a versão de runtime atualizada antes da falha de hardware, o computador seria provisionado com a versão anterior do runtime. Para atualizar para a nova versão de runtime, envie uma nova solicitação de atualização de cluster e somente os nós com a versão anterior do runtime serão atualizados. Os hosts que foram bem-sucedidos na ação de atualização anterior não serão.

Após uma atualização de runtime, o cluster mostra o estado de provisionamento "Com falha"

Durante uma atualização de runtime, o cluster entra em um estado de Upgrading. No caso de uma falha na atualização do runtime, o cluster entrará em um estado de provisionamento Failed. Falhas durante a atualização podem ser causadas por componentes de infraestrutura (por exemplo, o Dispositivo de Armazenamento). Em alguns cenários, pode ser necessário diagnosticar a falha com o suporte da Microsoft.

Impacto nas cargas de trabalho do locatário do Nexus Kubernetes durante a atualização do runtime do cluster

Durante uma atualização de runtime, os nós de cluster do Nexus Kubernetes são isolados e esvaziados antes que os hosts de computadores bare-metal (BMH) sejam atualizados. O isolamento do nó de cluster do Kubernetes impede que novos pods sejam agendados nele e o esvaziamento do nó de cluster do Kubernetes permite que os pods que executam cargas de trabalho de locatário sejam transferidos para outro nó de cluster do Kubernetes disponível, o que ajuda a reduzir o impacto nos serviços. A eficácia do mecanismo de esvaziamento depende da capacidade disponível no cluster do Nexus Kubernetes. Se o cluster do Kubernetes estiver próximo da capacidade total e não houver espaço para os pods serem realocados, ele fará a transição para um estado Pendente após o processo de esvaziamento.

Após a conclusão do processo de isolamento e esvaziamento do nó do cluster do locatário, a atualização do BMH continuará. Cada nó de cluster de locatário tem permissão de até 10 minutos para que o processo de esvaziamento seja concluído, após o qual a atualização do BMH será iniciada. Isso garante que a atualização do BMH fará progresso. Os BMHs são atualizados um rack de cada vez e as atualizações são executadas em paralelo dentro do mesmo rack. A atualização do BMH não aguarda que os recursos de locatário fiquem online antes de continuar com a atualização de runtime de BMHs no rack que está sendo atualizado. O benefício disso é que o tempo máximo de espera geral para uma atualização de rack é mantido em 10 minutos, independentemente de quantos nós estejam disponíveis. Esse tempo de espera máximo é específico para o procedimento de isolamento e esvaziamento e não é aplicado ao procedimento de atualização geral. Após a conclusão de cada atualização do BMH, o nó do cluster do Nexus Kubernetes é iniciado, retorna novamente ao cluster e é liberado, permitindo que os pods sejam agendados no nó mais uma vez.

É importante observar que o nó do cluster do Nexus Kubernetes não será desligado após o processo de isolamento e esvaziamento. O BMH é reinicializado com a nova imagem assim que todos os nós do cluster do Nexus Kubernetes são isolados e esvaziados, após 10 minutos se o processo de esvaziamento não for concluído. Além disso, o isolamento e o esvaziamento não são iniciados para ações de desligamento ou reinicialização do BMH; ele é ativado exclusivamente durante uma atualização de runtime.

É importante observar que, após a atualização do runtime, poderá haver instâncias em que um nó do cluster do Nexus Kubernetes permaneça isolado. Para esse cenário, você pode liberar manualmente o nó executando o comando a seguir

az networkcloud baremetalmachine list -g $mrg --subscription $sub --query "sort_by([].{name:name,kubernetesNodeName:kubernetesNodeName,location:location,readyState:readyState,provisioningState:provisioningState,detailedStatus:detailedStatus,detailedStatusMessage:detailedStatusMessage,powerState:powerState,tags:tags.Status,machineRoles:join(', ', machineRoles),cordonStatus:cordonStatus,createdAt:systemData.createdAt}, &name)" 
--output table