Posicionamento de recursos no Operador do Azure Nexus Kubernetes
As instâncias do Nexus do operador são implantadas nas instalações do cliente. Cada instância compreende um ou mais racks de servidores bare metal.
Quando um usuário cria um Nexus Kubernetes Cluster (NKS), ele especifica uma contagem e uma unidade de manutenção de estoque (SKU) 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 nos quais 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 é lançada.
Como a plataforma Nexus agenda uma VM de cluster Nexus Kubernetes
O Nexus primeiro identifica o conjunto de potenciais servidores bare metal que atendem a todos os requisitos de recursos do NKS VM SKU. Por exemplo, se o usuário especificou uma NC_G48_224_v1 VM SKU para seu pool de agentes, o Nexus coleta os servidores bare metal que têm capacidade disponível para 48 vCPU, 224Gi de RAM, etc.
Em seguida, o Nexus examina o AvailabilityZones campo para o Pool de Agentes ou Plano de Controle que está sendo agendado. Se este campo não estiver vazio, o Nexus filtrará a lista de potenciais servidores bare metal apenas para os servidores nas zonas de disponibilidade especificadas (racks). Esse comportamento é uma restrição de agendamento difícil. 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.
Uma vez que o Nexus identifica uma lista de potenciais 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 deste cluster NKS. Em outras palavras, espalhe as VMs NKS para um cluster NKS entre as zonas de disponibilidade.
Prefira servidores bare metal dentro de uma única zona de disponibilidade (rack) que não tenham outras VMs NKS do mesmo cluster NKS. Em outras palavras, espalhe as VMs NKS para um cluster NKS em servidores bare metal dentro de uma zona de disponibilidade.
Se o NKS VM SKU for ou
NC_G48_224_v1NC_P46_224_v1, prefira servidores bare metal que já abrigamNC_G48_224_v1ouNC_P46_224_v1VMs NKS de outros clusters NKS. Em outras palavras, agrupe as VMs extragrandes de diferentes clusters NKS nos mesmos servidores bare metal. Esta regra "empacota" as VMs extragrandes para reduzir a fragmentação dos recursos de computação disponíveis.A regra de "empacotamento de lixo" mencionada acima também se aplica a VMs menores, além de VMs grandes.Isso ajuda a "empacotar" VMs menores de clusters diferentes nas mesmas máquinas baremetal, aumentando a eficiência geral de posicionamento. Por exemplo, nós de plano de controle & nós de SKU pequenos (pool de agentes) de clusters diferentes afinam juntos.
Exemplos de cenários de posicionamento
As seções a seguir destacam o comportamento que os usuários do Nexus devem esperar ao criar clusters NKS em um ambiente Nexus do operador.
Dica: Você pode ver para qual servidor bare metal suas VMs NKS foram agendadas examinando a
nodes.bareMetalMachineIdpropriedade do recurso NKS KubernetesCluster ou exibindo a coluna "Host" na exibição de Nós de Cluster Kubernetes do Portal do Azure.
O exemplo de ambiente Operator Nexus tem estas especificações:
- Oito racks de 16 servidores bare metal
- Cada servidor bare metal contém duas células NUMA (Non-Uniform Memory Access )
- Cada célula NUMA fornece 48 CPU e 224Gi RAM
Ambiente vazio
Dado um ambiente Nexus de operador vazio com a capacidade dada, criamos três clusters Nexus Kubernetes de tamanho diferente.
Os Clusters NKS têm essas especificações, e assumimos para os fins deste exercício que o usuário cria os três Clusters na seguinte ordem:
Agrupamento A
- Plano de controle,
NC_G12_56_v1SKU, três contagens - Pool de agentes #1,
NC_P46_224_v1SKU, contagem de 24 - Pool de agentes #2,
NC_G6_28_v1SKU, contagem de seis
Cluster B
- Plano de controle,
NC_G24_112_v1SKU, cinco contagens - Pool de agentes #1,
NC_P46_224_v1SKU, contagem de 48 - Pool de agentes #2,
NC_P22_112_v1SKU, contagem de 24
Cluster C
- Plano de controle,
NC_G12_56_v1SKU, três contagens - Pool de agentes #1,
NC_P46_224_v1SKU, contagem de 12,AvailabilityZones = [1,4]
Aqui está uma tabela resumindo o que o usuário deve ver depois de iniciar os Clusters A, B e C em um ambiente vazio do Operator Nexus.
| Cluster | Conjunto | SKU | Contagem Total | Esperado # Racks | Racks reais # | # VMs esperadas por rack | # VMs reais por rack |
|---|---|---|---|---|---|---|---|
| A | Plano de Controlo | NC_G12_56_v1 |
3 | 3 | 3 | 1 | 1 |
| A | Pool de Agentes #1 | NC_P46_224_v1 |
24 | 8 | 8 | 3 | 3 |
| A | Pool de Agentes #2 | NC_G6_28_v1 |
6 | 6 | 6 | 1 | 1 |
| N | Plano de Controlo | NC_G24_112_v1 |
5 | 5 | 5 | 1 | 1 |
| N | Pool de Agentes #1 | NC_P46_224_v1 |
48 | 8 | 8 | 6 | 6 |
| N | Pool de Agentes #2 | NC_P22_112_v1 |
24 | 8 | 8 | 3 | 3 |
| C | Plano de Controlo | NC_G12_56_v1 |
3 | 3 | 3 | 1 | 1 |
| C | Pool de Agentes #1 | NC_P46_224_v1 |
12 | 2 | 2 | 6 | 6 |
Há oito racks para que as VMs de cada pool sejam distribuídas em até oito racks. Pools com mais de oito VMs exigem várias VMs por rack espalhadas por diferentes servidores bare metal.
O Pool de Agentes do Cluster C #1 tem 12 VMs restritas a AvailabilityZones [1, 4], portanto, tem 12 VMs em 12 servidores bare metal, seis em cada um dos racks 1 e 4.
VMs extragrandes (a NC_P46_224_v1 SKU) de clusters diferentes são colocadas nos mesmos servidores bare metal (consulte a regra #3 em Como a plataforma Nexus agenda uma VM de cluster Nexus Kubernetes).
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 lançamento de outro cluster NKS quando o ambiente de destino está meio cheio. O ambiente de destino fica meio cheio depois que os clusters A, B e C são implantados no ambiente de destino.
O cluster D tem as seguintes especificações:
- Plano de controle,
NC_G24_112_v1SKU, cinco contagens - Pool de agentes #1,
NC_P46_224_v1SKU, contagem de 24,AvailabilityZones = [7,8] - Pool de agentes #2,
NC_P22_112_v1SKU, contagem de 24
Aqui está uma tabela resumindo o que o usuário deve ver depois de iniciar o Cluster D no ambiente Nexus do Operador meio cheio que existe após a inicialização dos Clusters A, B e C.
| Cluster | Conjunto | SKU | Contagem Total | Esperado # Racks | Racks reais # | # VMs esperadas por rack | # VMs reais por rack |
|---|---|---|---|---|---|---|---|
| D | Plano de Controlo | NC_G12_56_v1 |
5 | 5 | 5 | 1 | 1 |
| D | Pool de Agentes #1 | NC_P46_224_v1 |
24 | 2 | 2 | 12 | 12 |
| D | Pool de Agentes #2 | NC_P22_112_v1 |
24 | 8 | 8 | 3 | 3 |
O Cluster D Agent Pool #1 tem 12 VMs restritas a AvailabilityZones [7, 8], portanto, tem 12 VMs em 12 servidores bare metal, seis em cada um dos racks 7 e 8. Essas VMs pousam em servidores bare metal que também abrigam VMs extragrandes de outros clusters devido à regra de classificação que agrupa VMs extragrandes de clusters diferentes nos mesmos servidores bare metal.
Se uma VM do plano de controle do Cluster D pousar no rack 7 ou 8, é provável que uma VM do Pool de Agentes do Cluster D #1 pouse no mesmo servidor bare metal que essa VM do plano de controle do Cluster D. Esse comportamento é devido ao Agent Pool #1 ser "fixado" nos racks 7 e 8. As restrições de capacidade nesses racks fazem com que o agendador coloque uma VM de plano de controle e uma VM do Pool de Agentes #1 do mesmo Cluster NKS.
O Pool de Agentes #2 do Cluster D tem três VMs em servidores bare metal diferentes em cada um dos oito racks. As restrições de capacidade resultaram da fixação do Pool de Agentes #1 do Cluster D aos racks 7 e 8. Portanto, as VMs do Pool de Agentes #1 e do Pool de Agentes #2 do Cluster D 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 o Cluster D no ambiente de destino.
Ambiente quase cheio
Em nosso ambiente de destino de exemplo, quatro dos oito racks estão próximos da capacidade. Vamos tentar iniciar outro cluster NKS.
O cluster E tem as seguintes especificações:
- Plano de controle,
NC_G24_112_v1SKU, cinco contagens - Pool de agentes #1,
NC_P46_224_v1SKU, contagem de 32
Aqui está uma tabela resumindo o que o usuário deve ver depois de iniciar o Cluster E no ambiente de destino.
| Cluster | Conjunto | SKU | Contagem Total | Esperado # Racks | Racks reais # | # VMs esperadas por rack | # VMs reais por rack |
|---|---|---|---|---|---|---|---|
| E | Plano de Controlo | NC_G24_112_v1 |
5 | 5 | 5 | 1 | 1 |
| E | Pool de Agentes #1 | NC_P46_224_v1 |
32 | 8 | 8 | 4 | 3, 4 ou 5 |
O Pool de Agentes #1 do Cluster E se espalhará de forma desigual por todos os oito racks. Os racks 7 e 8 terão três VMs NKS do Pool de Agentes #1 em vez das quatro VMs NKS esperadas porque não há mais capacidade para as VMs SKU extragrandes nesses racks após o agendamento dos Clusters A a D. Como os racks 7 e 8 não têm capacidade para o quarto SKU extragrande no Agent Pool #1, cinco VMs NKS pousam nos dois racks menos utilizados. No nosso exemplo, os 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 o Cluster E no ambiente de destino.
Posicionamento durante uma atualização de tempo de execução
A partir de abril de 2024 (versão Network Cloud 2304.1), as atualizações de tempo de execução são realizadas usando uma estratégia rack-by-rack. Os servidores bare metal no rack 1 são recriados de uma só vez. O processo de atualização é pausado até que todos os servidores bare metal reiniciem com êxito e digam ao Nexus que estão prontos para receber cargas de trabalho.
Nota
É possível instruir o Operador Nexus a recriar apenas uma imagem de uma parte dos servidores bare metal em um rack de uma só vez, no entanto, o padrão é recriar a imagem de todos os servidores bare metal em um rack em paralelo.
Quando um servidor bare metal individual é recriado, 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 executados em VMs NKS, por sua vez, perderão energia e conectividade. Após um minuto sem conseguir alcançar esses contêineres de carga de trabalho, o Plano de Controle Kubernetes do Cluster NKS marcará os Pods correspondentes como não íntegros. Se os Pods forem membros de um Deployment ou StatefulSet, o Plano de Controle Kubernetes do Cluster NKS tentará iniciar Pods de substituição para trazer a contagem de réplicas observada do Deployment ou StatefulSet de volta à contagem de réplicas desejada.
Novos Pods só são iniciados se houver capacidade disponível para o Pod nas VMs NKS saudáveis restantes. A partir de abril de 2024 (versão Network Cloud 2304.1), novas VMs NKS não serão criadas para substituir VMs NKS que estavam no servidor bare metal que está sendo recriado.
Quando o servidor bare metal é recriado com êxito e pode aceitar novas VMs NKS, as VMs NKS que estavam originalmente no mesmo servidor bare metal são reiniciadas no servidor bare metal recém-recriado. Os contêineres de carga de trabalho podem 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.
Nota
Esse comportamento pode parecer para o usuário como se as VMs NKS não "se movessem" 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-recriado que manteve o mesmo nome de servidor bare metal como antes da reimagem.
Melhores práticas
Ao trabalhar com o Operator Nexus, tenha em mente as seguintes práticas recomendadas.
- Evite especificar
AvailabilityZonespara um pool de agentes. - Inicie clusters NKS maiores antes dos menores.
- Reduza a contagem do pool de agentes antes de reduzir o tamanho da SKU da VM.
Evite especificar AvailabilityZones para um pool de agentes
Como você pode ver 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 aterrissar.
Portanto, nossa primeira prática recomendada é 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 pode ocorrer.
A única exceção a essa prática recomendada é quando você tem um cenário com apenas duas ou três VMs em um pool de agentes. Você pode considerar a configuração AvailabilityZones desse pool de agentes para [1,3,5,7] ou [0,2,4,6] para aumentar a disponibilidade durante as atualizações de tempo de execução.
Inicie clusters NKS maiores antes dos menores
A partir de abril de 2024 e da versão Network Cloud 2403.1, os clusters NKS são agendados na ordem em que são criados. Para empacotar seu ambiente de destino de forma mais eficiente, recomendamos que você crie clusters NKS maiores antes de clusters menores. Da mesma forma, recomendamos que você agende Pools de Agentes maiores antes de grupos menores.
Essa recomendação é importante para Pools de Agentes que usam o extragrande NC_G48_224_v1 ou NC_P46_224_v1 SKU. Agendar os Pools de Agentes com a maior contagem dessas VMs de SKU extragrandes cria um conjunto maior de servidores bare metal no qual outras VMs de SKU extragrandes de Pools de Agentes em outros Clusters NKS podem se agrupar.
Reduza a contagem do pool de agentes antes de reduzir o tamanho da SKU da VM
Se você tiver 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 do SKU da VM. Por exemplo, se você tentar criar um Cluster NKS com um Pool de Agentes com tamanho de SKU de VM e NC_P46_224_v1 uma Contagem de 24 e recuperar uma falha no provisionamento do Cluster NKS devido a recursos insuficientes, poderá ficar tentado a usar um Tamanho de SKU de NC_P36_168_v1 VM e continuar com uma Contagem de 24. No entanto, devido aos requisitos para que as VMs de carga de trabalho sejam alinhadas a uma única célula NUMA em um servidor bare metal, é provável que essa mesma solicitação resulte em falhas de recursos insuficientes semelhantes. Em vez de reduzir o tamanho da SKU da VM, considere reduzir a contagem do pool de agentes para 20. Há uma chance maior de sua solicitação se encaixar na capacidade de recursos do ambiente de destino e sua implantação geral ter mais núcleos de CPU do que se você reduzisse o tamanho da SKU da VM.
SKUs de VM com otimização de memória
NC_E94_448_v1 consome todos os recursos disponíveis para o cliente da máquina física. NC_E70_336_v1 consome 75% dos recursos disponíveis para os clientes, no entanto, não é garantido que sejam exatamente células NUMA cheias e meia. Isso significa que um NC_G24_112_v1 pode ou não ser capaz de agendar em uma máquina executando um NC_E70_336_v1 dependendo de como a VM NC_E70_336_v1 é agendada nas células NUMA.