Atualizações de tempo de execução do Azure Operator Nexus

A atualização do runtime da plataforma Nexus é uma atualização disruptiva, gerida pelos clientes, para atualizar o software subjacente nos servidores em uma instância do Operador Nexus. A interrupção ocorre nos servidores de computação dentro de um rack que está sendo atualizado. As atualizações do servidor de gerenciamento são consideradas sem interrupções.

Escopo das versões de execução

A atualização de tempo de execução foi projetada para atualizar componentes fundamentais da plataforma para cada servidor na instância. Alguns exemplos de componentes atualizados durante a atualização em tempo de execução são o Sistema Operacional (SO), o cluster kubernetes undercloud, o firmware de computação, o cluster etcd e o CNI (Container Network Interface). Cada servidor é reformatado para carregar a imagem da versão de runtime selecionada.

Frequência de libertação

Lançamentos principais/secundários

Lançamentos menores de execução são produzidos para a infraestrutura de computação três vezes por ano em fevereiro, junho e outubro. Essas versões são suportadas por aproximadamente um ano após o lançamento e os clientes não podem pular versões secundárias.

Lançamentos de patches

A versão de tempo de execução do patch é produzida mensalmente entre as versões secundárias. Essas versões são opcionais, a menos que sejam direcionadas pela Microsoft para funcionalidades específicas ou questões de segurança.

Visão geral do fluxo de trabalho

Iniciar uma atualização de tempo de execução é definido em Atualizando o tempo de execução do cluster por meio da CLI do Azure.

A atualização de tempo de execução começa atualizando os três servidores de gerenciamento designados como nós do plano de controle. O servidor de plano de controle sobressalente é o primeiro servidor a ser atualizado. O último servidor do plano de controlo é desprovisionado e faz a transição para o estado Available. Esses servidores são atualizados em série e prosseguem somente quando cada um é concluído. Os servidores de gerenciamento restantes são segregados em dois grupos. A atualização de tempo de execução agora aproveitará dois grupos de gerenciamento, em vez de um único grupo. Cada grupo é melhorado em duas etapas, de forma sequencial, com uma percentagem mínima de sucesso de 50% em cada grupo. A introdução desse recurso 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. Para esta versão, cada CSN aproveitará essa funcionalidade colocando uma instância em cada grupo de gerenciamento. Nenhuma interação do cliente com esta funcionalidade. Pode haver rótulos adicionais vistos nos nós de gerenciamento para identificar os grupos.

Depois que todos os servidores de gerenciamento são atualizados, a atualização progride para os servidores de computação. Cada rack é atualizado em ordem alfanumérica, e há várias configurações que os clientes podem usar para ditar como os cálculos são atualizados para melhor limitar a interrupção. À medida que cada rack avança, são realizadas várias verificações de integridade para garantir que a versão seja atualizada com êxito e que um número suficiente de unidades de computação em um rack retorne ao estado operacional. Quando um rack é concluído, um tempo de espera definido pelo cliente começa a fornecer tempo extra para que as cargas de trabalho fiquem online. Depois que cada rack for atualizado, a atualização será concluída e o cluster retornará ao Running status.

As etapas para executar uma atualização de tempo de execução do cluster estão localizadas aqui.

Estratégias de atualização do ambiente de execução

Cada uma das estratégias explicadas fornece aos usuários vários controles sobre como e quando os racks de computação são atualizados. Esses valores são aplicáveis apenas aos servidores de computação e não aos servidores de gerenciamento. Cada estratégia usa um thresholdType e thresholdValue para definir o número ou a porcentagem de servidores de computação atualizados com êxito em um rack antes de prosseguir para o próximo rack.

Os valores limite são um cálculo realizado durante a atualização para determinar o número de servidores de computação disponíveis após a conclusão da atualização.

Rack por rack

O comportamento padrão para atualizações de tempo de execução itera em cada rack, um por um, até que todo o site seja atualizado à medida que os limites são atingidos.

Rack pausado

Esta estratégia pausará a atualização após o rack ter concluído a atualização. O próximo rack não será iniciado até que o cliente execute a API de atualização.

Detalhes sobre como executar uma atualização com pausa de rack estão localizados aqui.

Cargas de trabalho do locatário do Nexus durante a atualização do tempo de execução do cluster

Durante uma atualização em tempo de execução, os nós do Nexus Kubernetes Cluster em execução nos servidores agendados para atualização são isolados, drenados e, em seguida, desligados de forma controlada antes do início da atualização. O isolamento de um nó impede que novos pods sejam agendados nele, enquanto o esvaziamento permite que pods que executam cargas de trabalho de inquilinos se desloquem para outros nós disponíveis, minimizando a interrupção do serviço. A eficácia da drenagem depende da capacidade disponível dentro do cluster. Se o cluster estiver perto da capacidade total e não tiver espaço para realocação de pods, esses pods entrarão em um estado Pendente após a drenagem.

Após a conclusão das etapas de ordenação e drenagem, o nó será desligado como parte do processo de atualização. Após a atualização do servidor baremetal, o nó é reiniciado, reingressa no cluster e é descordonado, permitindo que os pods sejam agendados nele novamente.

Para VMs Nexus, o processo é semelhante. As VMs são desligadas antes da atualização do servidor baremetal e reiniciadas automaticamente quando o servidor está online novamente.

Cada nó de cluster do tenant tem até 20 minutos para concluir o processo de drenagem. Após essa janela, a atualização do servidor prossegue independentemente da conclusão do esvaziamento para assegurar o progresso. Os servidores são atualizados um rack de cada vez, com upgrades realizados em paralelo dentro do mesmo rack. A atualização do servidor não aguarda que os recursos do locatário estejam online antes de prosseguir com a atualização de tempo de execução de outros servidores no rack. Além do tempo limite de drenagem, há um tempo limite de 10 minutos alocado para desligamentos de VM. Essa abordagem garante que o tempo máximo de espera por rack permaneça em 30 minutos, específico para o procedimento de cordão, drenagem e desligamento, e não para a atualização geral.

É importante observar que, após a atualização do tempo de execução, pode haver uma instância em que um nó do Nexus Kubernetes Cluster permaneça isolado. Para este cenário, localize nós desbloqueados executando o seguinte comando.

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

Operações do conjunto de chaves BareMetalMachine (BMM) durante a atualização do tempo de execução do cluster

Quando um servidor é atualizado para utilizar um novo sistema operacional, os conjuntos de chaves BMM precisam ser restabelecidos com o novo software. Este processo é iniciado assim que a atualização do runtime é concluída para a instância. Os servidores que ainda não passaram por uma atualização de tempo de execução ainda podem ser acessados por meio do conjunto de chaves BMM. Se o acesso a uma máquina for necessário durante a atualização, o usuário do console estará disponível.

Servidores não atualizados com êxito

Um servidor permanece indisponível se falhar na atualização ou provisionamento devido a um possível problema de hardware durante a reinicialização ou problema com o cloud-init (rede, cronyd, etc.). A condição subjacente precisa ser resolvida e qualquer substituição/reimagem de máquina baremetal precisaria ser executada. Desbloquear manualmente o servidor não resolverá os problemas.