Posicionamento de recursos no Kubernetes do Nexus do Operador do Azure
As instâncias do Nexus do Operador são implantadas no local do cliente. Cada instância é composta por um ou mais racks de servidores bare-metal.
Quando um usuário cria um Cluster kubernetes do Nexus (NKS), ele especifica uma contagem e uma SKU (unidade de manutenção de estoque) para máquinas virtuais (VM) que compõem o Plano de Controle do Kubernetes e um ou mais Pools de Agentes. Os pools de agentes são o conjunto de nós de trabalho no qual as funções de rede conteinerizadas de um cliente são executadas.
A plataforma Nexus é responsável por decidir o servidor bare-metal no qual cada VM NKS é iniciada.
Como a plataforma Nexus agenda uma VM do Cluster Kubernetes do Nexus
Primeiro, o Nexus identifica o conjunto de possíveis servidores bare metal que atendem a todos os requisitos de recursos da SKU de VM do NKS. Por exemplo, se o usuário especificou um SKU de VM NC_G48_224_v1 para o pool de agentes, o Nexus coleta os servidores bare-metal que têm capacidade disponível para 48 vCPU, 224 Gi de RAM etc.
Em seguida, o Nexus analisa o campo AvailabilityZones do pool de agentes ou do painel de controle que está sendo agendado. Se esse campo não estiver vazio, o Nexus filtrará a lista de servidores bare-metal em potencial apenas para esses servidores nas zonas de disponibilidade especificadas (racks). Esse comportamento é uma restrição de agendamento rígido. Se não houver servidores bare-metal na lista filtrada, o Nexus não agendará a VM NKS e o cluster não será provisionado.
Depois que o Nexus identifica uma lista de possíveis servidores bare-metal nos quais colocar a VM NKS, o Nexus escolhe um dos servidores bare-metal depois de aplicar as seguintes regras de classificação:
Prefira servidores bare-metal em zonas de disponibilidade (racks) que não tenham VMs NKS desse cluster NKS. Em outras palavras, espalhe as VMs NKS para um cluster NKS entre zonas de disponibilidade.
Prefira servidores bare-metal em uma única zona de disponibilidade (rack) que não tenham outras VMs NKS do mesmo cluster NKS. Em outras palavras, espalhe as VMs do NKS para um cluster NKS entre servidores bare-metal dentro de uma zona de disponibilidade.
Se o SKU da VM do NKS for
NC_G48_224_v1,NC_P46_224_v1,NC_G56_224_v1ouNC_P54_224_v1, prefira servidores bare metal que já tenham as VMs do NKSNC_G48_224_v1,NC_P46_224_v1,NC_G56_224_v1ouNC_P54_224_v1de outros clusters do NKS. Em outras palavras, agrupe as VMs extra-grandes de diferentes clusters NKS nos mesmos servidores bare-metal. Essa regra “empacota” as VMs extragrandes a fim de reduzir a fragmentação dos recursos de computação disponíveis.A regra de "bin packing" mencionada acima também se aplica a VMs menores, além de VMs grandes. Isso ajuda a "empacotar" VMs menores de diferentes clusters nas mesmas máquinas baremetal, aumentando a eficiência geral de posicionamento. Por exemplo, nós do plano de controle e nós de SKUs pequenos (pool de agentes) de diferentes clusters são afins.
Cenários de posicionamento de exemplo
As seções a seguir destacam o comportamento que os usuários do Nexus devem esperar ao criar clusters NKS em um ambiente do Operator Nexus.
Dica: você pode ver para qual servidor bare-metal suas VMs NKS foram agendadas examinando a propriedade
nodes.bareMetalMachineIddo recurso KubernetesCluster do NKS ou exibindo a coluna "Host" na exibição de Nós de Cluster do Kubernetes no Portal do Azure.
O exemplo de ambiente Nexus do Operador traz estas especificações:
- Oito racks de 16 servidores bare-metal
- Cada servidor bare-metal contém duas células NUMA
- Cada célula NUMA fornece 48 CPU e 224 Gi de RAM
Ambiente vazio
Considerando um ambiente do Nexus do Operador vazio com a capacidade fornecida, criamos três clusters do Kubernetes do Nexus de diferentes tamanhos.
Os Clusters NKS têm essas especificações e presumimos para fins deste exercício que o usuário cria os três Clusters na seguinte ordem:
Cluster A
- Painel de controle, SKU
NC_G12_56_v1, três contagens - Pool de agentes nº 1,
NC_P46_224_v1SKU, 24 contagens - Pool de agentes nº 2,
NC_G6_28_v1SKU, seis contagens
Cluster B
- Painel de controle, SKU
NC_G24_112_v1, cinco contagens - Pool de agentes nº 1,
NC_P46_224_v1SKU, 48 contagens - Pool de agentes nº 2, SKU
NC_P22_112_v1, 24 contagens
Cluster C
- Painel de controle, SKU
NC_G12_56_v1, três contagens - Pool de agentes nº 1,
NC_P46_224_v1SKU, 12 contagens,AvailabilityZones = [1,4]
Aqui está uma tabela resumindo o que o usuário precisa ver depois de iniciar os Clusters A, B e C em um ambiente vazio do Nexus do Operador.
| Cluster | pool | SKU | Contagem total | Nº de racks esperados | Nº de racks reais | Nº de VMs esperadas por rack | Nº de VMs reais por rack |
|---|---|---|---|---|---|---|---|
| Um | Painel de Controle | NC_G12_56_v1 |
3 | 3 | 3 | 1 | 1 |
| Um | Pool de agentes nº 1 | NC_P46_224_v1 |
24 | 8 | 8 | 3 | 3 |
| Um | Pool de agentes nº 2 | NC_G6_28_v1 |
6 | 6 | 6 | 1 | 1 |
| B | Painel de Controle | NC_G24_112_v1 |
5 | 5 | 5 | 1 | 1 |
| B | Pool de agentes nº 1 | NC_P46_224_v1 |
48 | 8 | 8 | 6 | 6 |
| B | Pool de agentes nº 2 | NC_P22_112_v1 |
24 | 8 | 8 | 3 | 3 |
| C | Painel de Controle | NC_G12_56_v1 |
3 | 3 | 3 | 1 | 1 |
| C | Pool de agentes nº 1 | NC_P46_224_v1 |
12 | 2 | 2 | 6 | 6 |
Há oito racks, de modo que as VMs para cada pool sejam distribuídas em até oito racks. Os pools com mais de oito VMs exigem várias VMs por rack distribuídas em diferentes servidores bare-metal.
O pool de agentes nº 1 do Cluster C tem 12 VMs restritas a AvailabilityZones [1, 4]. Portanto, ele tem 12 VMs em 12 servidores bare-metal, seis em cada um dos racks 1 e 4.
VMs extra-grandes (a SKU NC_P46_224_v1) de clusters diferentes são colocadas nos mesmos servidores bare-metal (consulte a regra nº 3 em Como a plataforma Nexus agenda uma VM do Cluster Kubernetes do Nexus).
Aqui está uma visualização de um layout que o usuário pode ver depois de implantar os Clusters A, B e C em um ambiente vazio.
Ambiente meio cheio
Agora, executamos um exemplo de como iniciar outro Cluster NKS quando o ambiente de destino estiver meio cheio. O ambiente de destino fica preenchido pela metade depois que os Clusters A, B e C são implantados nele.
O Cluster D tem as seguintes especificações:
- Painel de controle, SKU
NC_G24_112_v1, cinco contagens - Pool de agentes nº 1,
NC_P46_224_v1SKU, 24 contagens,AvailabilityZones = [7,8] - Pool de agentes nº 2, SKU
NC_P22_112_v1, 24 contagens
Aqui está uma tabela resumindo o que o usuário precisa ver depois de iniciar o Cluster D no ambiente do Nexus do Operador preenchido pela metade que é criado após a inicialização dos Clusters A, B e C.
| Cluster | pool | SKU | Contagem total | Nº de racks esperados | Nº de racks reais | Nº de VMs esperadas por rack | Nº de VMs reais por rack |
|---|---|---|---|---|---|---|---|
| D | Painel de Controle | NC_G12_56_v1 |
5 | 5 | 5 | 1 | 1 |
| D | Pool de agentes nº 1 | NC_P46_224_v1 |
24 | 2 | 2 | 12 | 12 |
| D | Pool de agentes nº 2 | NC_P22_112_v1 |
24 | 8 | 8 | 3 | 3 |
O pool de agentes nº 1 do Cluster D tem 12 VMs restritas a AvailabilityZones [7, 8]. Portanto, ele tem 12 VMs em 12 servidores bare-metal, seis em cada um dos racks 7 e 8. Essas VMs chegam em servidores bare-metal que também hospedam VMs extragrandes de outros clusters, devido à regra de classificação que agrupa as VMs extragrandes de diferentes clusters nos mesmos servidores bare-metal.
Se uma VM do painel de controle do Cluster D chegar no rack 7 ou 8, será provável que uma VM do pool de agentes nº 1 do Cluster D chegue no mesmo servidor bare-metal da VM do painel de controle do Cluster D. Esse comportamento ocorre devido ao pool de agentes nº 1 ser “fixado” nos racks 7 e 8. As restrições de capacidade nesses racks fazem com que o agendador colecione uma VM do plano de controle e uma VM do Pool de Agentes nº 1 do mesmo cluster NKS.
O pool de agentes nº 2 do Cluster D tem três VMs em diferentes servidores bare-metal em cada um dos oito racks. Como resultado, há restrições de capacidade devido ao fato de o pool de agentes nº 1 do Cluster D estar fixado nos racks 7 e 8. Portanto, as VMs do pool de agentes nº 1 do Cluster D e do pool de agentes nº 2 são colocadas nos mesmos servidores bare-metal, nos racks 7 e 8.
Aqui está uma visualização de um layout que o usuário pode ver depois de implantar os Clusters D no ambiente de destino.
Ambiente quase completo
Em nosso exemplo de ambiente de destino, quatro dos oito racks estão perto do limite de capacidade. Vamos tentar iniciar outro Cluster NKS.
O Cluster E tem as seguintes especificações:
- Painel de controle, SKU
NC_G24_112_v1, cinco contagens - Pool de agentes nº 1,
NC_P46_224_v1SKU, 32 contagens
Aqui está uma tabela resumindo o que o usuário precisa ver depois de iniciar o Cluster E no ambiente de destino.
| Cluster | pool | SKU | Contagem total | Nº de racks esperados | Nº de racks reais | Nº de VMs esperadas por rack | Nº de VMs reais por rack |
|---|---|---|---|---|---|---|---|
| E | Painel de Controle | NC_G24_112_v1 |
5 | 5 | 5 | 1 | 1 |
| E | Pool de agentes nº 1 | NC_P46_224_v1 |
32 | 8 | 8 | 4 | 3, 4 ou 5 |
O pool de agentes nº 1 do Cluster E será distribuído de maneira irregular em todos os oito racks. Os racks 7 e 8 terão três VMs NKS do Pool de Agentes nº 1 em vez das quatro VMs NKS esperadas porque não há mais capacidade para as VMs de SKU extra-grandes nesses racks depois de agendar clusters A a D. Como os racks 7 e 8 não têm capacidade para o quarto SKU extra-grande no Pool de Agentes nº 1, cinco VMs NKS cairão nos dois racks menos utilizados. No exemplo, esses racks menos utilizados eram os racks 3 e 6.
Aqui está uma visualização de um layout que o usuário pode ver depois de implantar os Clusters E no ambiente de destino.
Posicionamento durante uma atualização de runtime
Desde abril de 2024 (Nuvem de Rede versão 2304.1), as atualizações de runtime são feitas por meio de uma estratégia rack a rack. A imagem dos servidores bare-metal do rack 1 é refeita de uma só vez. O processo de atualização é colocado em pausa até que todos os servidores bare-metal sejam reiniciados com êxito e informem ao Nexus que estão prontos para receber cargas de trabalho.
Observação
É possível instruir o Operador Nexus a apenas refazer a imagem de uma parte dos servidores bare-metal em um rack de uma só vez, no entanto, o padrão é refazer a imagem de todos os servidores bare-metal em um rack em paralelo.
Quando um servidor bare-metal individual é reimageado, todas as cargas de trabalho em execução nesse servidor bare-metal, incluindo todas as VMs NKS, perdem energia e conectividade. Os contêineres de carga de trabalho em execução em VMs NKS, por sua vez, perderão energia e conectividade. Após um minuto sem conseguir acessar esses contêineres de carga de trabalho, o plano de controle do Kubernetes do cluster NKS marcará os pods correspondentes como não saudáveis. Se os pods forem membros de um Deployment ou StatefulSet, o plano de controle do Kubernetes do cluster NKS tentará iniciar pods de substituição para trazer a contagem de réplicas observada do Implantação ou StatefulSet de volta à contagem de réplicas desejada.
Os novos Pods só serão iniciados se houver capacidade disponível para o Pod nas VMs NKS íntegras restantes. A partir de abril de 2024 (versão 2304.1 do Network Cloud), novas VMs NKS não são criadas para substituir as VMs NKS que estavam no servidor bare metal que está sendo recriado.
Quando o servidor bare metal for recriado com êxito e puder aceitar novas VMs NKS, as VMs NKS que estavam originalmente no mesmo servidor bare metal serão reiniciadas no servidor bare metal recém-recuperado. Os contêineres de carga de trabalho podem então ser agendados para essas VMs NKS, potencialmente restaurando as Implantações ou StatefulSets que tinham Pods em VMs NKS que estavam no servidor bare-metal.
Observação
Esse comportamento pode parecer para o usuário como se as VMs NKS não tivessem sido "movidas" do servidor bare metal, quando, na verdade, uma nova instância de uma VM NKS idêntica foi iniciada no servidor bare metal recém-reimageado que manteve o mesmo nome de servidor bare metal de antes do reimageamento.
Práticas recomendadas
Ao trabalhar com o Nexus do Operador, tenha em mente as melhores práticas a seguir.
- Evite especificar
AvailabilityZonespara um pool de agentes. - Inicie clusters NKS maiores antes dos menores.
- Reduza a contagem de pool de agentes antes de reduzir o tamanho do SKU da VM.
Evite especificar AvailabilityZones para um pool de agentes
Como você pode dizer nos cenários de posicionamento acima, especificar AvailabilityZones para um Pool de Agentes é o principal motivo pelo qual as VMs NKS do mesmo cluster NKS acabariam no mesmo servidor bare-metal. Ao especificar AvailabilityZones, você "fixa" o Pool de Agentes em um subconjunto de racks e, portanto, limita o número de servidores bare-metal potenciais nesse conjunto de racks para outros clusters NKS e outras VMs do Pool de Agentes no mesmo cluster NKS para pousar.
Portanto, nossa primeira melhor prática é evitar especificar AvailabilityZones para um pool de agentes. Se você precisar fixar um pool de agentes em um conjunto de Zonas de Disponibilidade, torne esse conjunto o maior possível para minimizar o desequilíbrio que poderá ocorrer.
A única exceção a essa melhor prática é quando você tem um cenário com apenas duas ou três VMs em um pool de agentes. Você pode considerar a configuração de AvailabilityZones para esse pool de agentes como [1,3,5,7] ou [0,2,4,6] para aumentar a disponibilidade durante as atualizações de runtime.
Iniciar clusters NKS maiores antes dos menores
A partir de abril de 2024 e da versão do Network Cloud 2403.1, os clusters NKS são agendados na ordem em que são criados. Para empacotar com mais eficiência seu ambiente de destino, recomendamos que você crie clusters NKS maiores antes dos menores. Da mesma forma, recomendamos que você agende pools de agentes maiores antes dos menores.
Essa recomendação é importante para os pools de agentes que usam o SKU NC_G48_224_v1 ou NC_P46_224_v1 extragrande. Agendar os Pools de Agentes com a maior contagem dessas VMs de SKU extra-grandes cria um conjunto maior de servidores bare-metal sobre os quais outras VMs de SKU extra-grandes de Pools de Agentes em outros Clusters NKS podem agrupar.
Reduzir a contagem do Pool de Agentes antes de reduzir o tamanho da SKU da VM
Se você encontrar restrições de capacidade ao iniciar um cluster NKS ou pool de agentes, reduza a contagem do pool de agentes antes de ajustar o tamanho da SKU da VM. Por exemplo, se você tentar criar um cluster NKS com um pool de agentes com tamanho de SKU de VM NC_P46_224_v1 e uma Contagem de 24 e receber de volta uma falha ao provisionar o cluster NKS devido a recursos insuficientes, talvez você fique tentado a usar um tamanho de SKU de VM NC_P36_168_v1 e continuar com uma Contagem de 24. No entanto, devido aos requisitos para que as VMs de carga de trabalho sejam alinhadas a uma só célula NUMA em um servidor bare-metal, é provável que essa mesma solicitação resulte em falhas semelhantes de recursos insuficientes. Em vez de reduzir o tamanho do SKU da VM, considere a redução da contagem do pool de agentes para 20. Há uma chance melhor de a sua solicitação se ajustar à capacidade de recurso do ambiente de destino e a implantação geral ter mais núcleos de CPU do que se você reduzisse o SKU da VM.
SKUs da VM otimizada para memória
NC_E110_448_v1 (em execução nos nós do hardware Sapphire Rapids) ou NC_E94_448_v1 consomem todos os recursos disponíveis para o cliente no computador físico. NC_E70_336_v1 consome 75% dos recursos disponíveis para o cliente, mas não há garantia de que isso será exatamente uma célula NUMA e meia.
Isso significa que um NC_G24_112_v1 pode ou não ser agendado em um computador que está executando um NC_E70_336_v1, dependendo de como a VM NC_E70_336_v1 é agendada nas células NUMA.