Limites de recursos, tamanhos de VM e regiões para AKS habilitados pelo Azure Arc

Artigo
12/22/2023

Aplica-se a: AKS no Azure Stack HCI 22H2, AKS no Windows Server

Este artigo fornece informações sobre configurações testadas, limites de recursos, tamanhos de VM e regiões para Serviço de Kubernetes do Azure (AKS) habilitado pelo Azure Arc. Os testes usaram a versão mais recente do AKS no Azure Stack HCI.

Especificações máximas

O AKS habilitado pelas implantações do Arc foi validado com as configurações a seguir, incluindo os máximos especificados. Tenha em mente que exceder esses máximos está em seu próprio risco e pode levar a comportamentos e falhas inesperados. Este artigo fornece algumas diretrizes sobre como evitar erros comuns de configuração e pode ajudá-lo a criar uma configuração maior. Em caso de dúvida, entre em contato com seu escritório local da Microsoft para obter assistência ou envie uma pergunta na comunidade do Azure Stack HCI.

Recurso	Máximo
Servidores físicos por cluster	8
Número total de VMs	200

Os limites recomendados foram testados com os tamanhos de VM (máquina virtual) padrão, com base na tabela a seguir:

Função do sistema	Tamanho da VM
AKS-Host	Standard_A4_v2
Nó do Plano de Controle de Cluster de Destino	Default
Balanceador de carga HAProxy do cluster de destino (opcional)	Standard_A4_v2
Nó de trabalho do Linux do cluster de destino	Standard_K8S3_v1
Nó de trabalho do Windows cluster de destino	Standard_K8S3_v1

A configuração de hardware de cada nó físico no cluster do Azure Stack HCI é a seguinte:

Chassi: Dell PowerEdge R650 Server ou similar.
RAM: RDIMM, 3200 MT/s, Classificação Dupla, total de 256 GB.
CPU: Dois (2) Intel Xeon Silver 4316 2.3G, 20C/40T, 10.4 GT/s, 30M Cache, Turbo, HT (150 W) DDR4-2666.
Disco: HDDs 8x (2 TB ou maior) e NVMe de 1,6 TB de 2x para dar suporte a configurações de armazenamento S2D.
Rede: quatro (4) NICs de 100 Gbits (Mellanox ou Intel).

A engenharia da Microsoft testou o AKS habilitado pelo Arc usando a configuração acima. Para um único nó. Clusters de failover do Windows de 2 nós, 4 nós e 8 nós. Se você tiver um requisito para exceder a configuração testada, consulte Dimensionamento do AKS no Azure Stack HCI.

Importante

Quando você atualiza uma implantação do AKS, recursos extras são consumidos temporariamente. Cada máquina virtual é atualizada em um fluxo de atualização sem interrupção, começando com os nós do painel de controle. Para cada nó no cluster do Kubernetes, uma nova VM de nó é criada. A VM do nó antigo é restrita para impedir que cargas de trabalho sejam implantadas nela. A VM restrita é então drenada de todos os contêineres para distribuir os contêineres para outras VMs no sistema. A VM drenada é então removida do cluster, desligada e substituída pela nova VM atualizada. Esse processo se repete até que todas as VMs sejam atualizadas.

Tamanhos de VM disponíveis

Os seguintes tamanhos de VM para nós do painel de controle, nós de trabalho do Linux e nós de trabalho do Windows estão disponíveis para o AKS no Azure Stack HCI. Embora os tamanhos de VM, como Standard_K8S2_v1 e Standard_K8S_v1 , sejam compatíveis com testes e implantações de requisitos de recursos baixos, use esses tamanhos com cuidado e aplique testes rigorosos, pois eles podem resultar em falhas inesperadas devido a condições de memória insuficiente.

Tamanho da VM	CPU	Memória (GB)	Tipo de GPU	Contagem de GPU
Default	4	4
Standard_A2_v2	2	4
Standard_A4_v2	4	8
Standard_D2s_v3	2	8
Standard_D4s_v3	4	16
Standard_D8s_v3	8	32
Standard_D16s_v3	16	64
Standard_D32s_v3	32	128
Standard_DS2_v2	2	7
Standard_DS3_v2	2	14
Standard_DS4_v2	8	28
Standard_DS5_v2	16	56
Standard_DS13_v2	8	56
Standard_K8S_v1	4	2
Standard_K8S2_v1	2	2
Standard_K8S3_v1	4	6
Standard_NK6	6	12	Tesla T4	1
Standard_NK12	12	24	Tesla T4	2

Regiões do Azure com suporte para registro do Azure

O AKS habilitado pelo Arc tem suporte nas seguintes regiões do Azure:

Leste da Austrália
Leste dos EUA
Sudeste Asiático
Europa Ocidental

Dimensionamento do AKS no Azure Stack HCI

O dimensionamento de uma implantação do AKS no Azure Stack HCI envolve o planejamento antecipado conhecendo suas cargas de trabalho e a utilização do cluster de destino. Além disso, considere os recursos de hardware em sua infraestrutura subjacente, como núcleos totais de CPU, memória total, armazenamento, endereços IP e assim por diante.

Os exemplos a seguir pressupõem que apenas cargas de trabalho baseadas em AKS sejam implantadas na infraestrutura subjacente. A implantação de cargas de trabalho não AKS, como máquinas virtuais autônomas ou clusterizados ou servidores de banco de dados, reduz os recursos disponíveis para o AKS, que você deve levar em conta.

Antes de começar, considere os seguintes pontos para determinar a escala máxima e o número de clusters de destino aos quais você precisa dar suporte:

O número de endereços IP disponíveis para pods em um cluster de destino.
O número de endereços IP disponíveis para os serviços do Kubernetes em um cluster de destino.
O número de pods necessários para executar suas cargas de trabalho.

Para determinar o tamanho da VM do host Serviço de Kubernetes do Azure, você precisa saber o número de nós de trabalho e clusters de destino, pois isso determina o tamanho da VM host do AKS. Por exemplo:

O número de clusters de destino no sistema implantado final.
O número de nós, incluindo painel de controle, balanceador de carga e nós de trabalho em todos os clusters de destino.

Observação

Um único host do AKS só pode gerenciar clusters de destino na mesma plataforma.

Além disso, para determinar o tamanho do nó do painel de controle do cluster de destino, você precisa saber o número de pods, contêineres e nós de trabalho que planeja implantar em cada cluster de destino.

Configurações padrão que atualmente não podem ser alteradas no AKS

Atualmente, há configurações e configurações padrão que não estão disponíveis para o controle do cliente durante ou após a implantação. Essas configurações podem limitar a escala para um determinado cluster de destino.

O número de endereços IP para pods do Kubernetes em um cluster de destino é limitado à sub-rede 10.244.0.0/16. Ou seja, 255 endereços IP por nó de trabalho em todos os namespaces do Kubernetes podem ser usados para pods. Para ver o CIDR do pod atribuído a cada nó de trabalho no cluster, use o seguinte comando no PowerShell:

kubectl get nodes -o json | findstr 'hostname podCIDR'

                    "kubernetes.io/hostname": "moc-lip6cotjt0f",
                                "f:podCIDR": {},
                                "f:podCIDRs": {
                                    "f:kubernetes.io/hostname": {},
                "podCIDR": "10.244.2.0/24",
                "podCIDRs": [
                    "kubernetes.io/hostname": "moc-lmb6zqozk4m",
                                "f:podCIDR": {},
                                "f:podCIDRs": {
                                    "f:kubernetes.io/hostname": {},
                "podCIDR": "10.244.4.0/24",
                "podCIDRs": [
                    "kubernetes.io/hostname": "moc-wgwhhijxtfv",
                                "f:podCIDR": {},
                                "f:podCIDRs": {
                                    "f:kubernetes.io/hostname": {},
                "podCIDR": "10.244.5.0/24",
                "podCIDRs": [

No exemplo, você pode ver três nós com três CIDRs, cada um capaz de hospedar 254 pods. A documentação de escala do Kubernetes recomenda que você não exceda 110 pods por nó por motivos de desempenho. Confira Considerações para clusters grandes.

Outras considerações:

O número de endereços IP para serviços do Kubernetes, fora do pool de VIP alocado, vem do 10.96.0.0/16 pool de endereços. O sistema consome um dos 255 endereços disponíveis para o servidor de API do Kubernetes.
O tamanho da VM de host do AKS só pode ser definido na instalação, quando você executa Set-AksHciConfig pela primeira vez. Não é possível alterá-lo posteriormente.
Você só pode definir o tamanho do plano de controle de cluster de destino e das VMs do balanceador de carga no momento da criação do cluster de destino.

Exemplo de escala

O exemplo de dimensionamento a seguir baseia-se nessas suposições gerais/casos de uso:

Você deseja ser capaz de tolerar completamente a perda de um nó físico no cluster do Azure Stack HCI.
Você deseja dar suporte à atualização de clusters de destino para versões mais recentes.
Você deseja permitir a alta disponibilidade dos nós do painel de controle de cluster de destino e dos nós do balanceador de carga.
Você deseja reservar uma parte da capacidade geral do Azure Stack HCI para esses casos.

Sugestões

Para obter um desempenho ideal, defina pelo menos 15% (100/8=12,5) de capacidade de cluster à parte para permitir que todos os recursos de um nó físico sejam redistribuídos para os outros sete (7) nós. Essa configuração garante que você tenha alguma reserva disponível para fazer uma atualização ou outras operações do segundo dia do AKS.
Se você quiser aumentar além do limite de 200 VMs para um cluster máximo de oito (8) nós do Azure Stack HCI, aumente o tamanho da VM host do AKS. Dobrar o tamanho resulta em aproximadamente o dobro do número de VMs que ela pode gerenciar. Em um cluster do Azure Stack HCI de 8 nós, você pode acessar 8.192 VMs (8x1024) com base nos limites de recursos recomendados do Azure Stack HCI documentados nas Especificações máximas de hardware com suporte. Você deve reservar aproximadamente 30% da capacidade, o que o deixa com um limite teórico de 5.734 VMs em todos os nós.
- Standard_D32s_v3, para o host aks com 32 núcleos e 128 GB , pode dar suporte a um máximo de 1.600 nós.
Observação

Como essa configuração não foi testada extensivamente, ela requer uma abordagem cuidadosa e validação.
Em uma escala como essa, talvez você queira dividir o ambiente em pelo menos 8 clusters de destino com 200 nós de trabalho cada um.
Para executar 200 nós de trabalho em um cluster de destino, você pode usar o plano de controle padrão e o tamanho do balanceador de carga. Dependendo do número de pods por nó, você pode subir pelo menos um tamanho no painel de controle e usar Standard_D8s_v3.
Dependendo do número de serviços do Kubernetes hospedados em cada cluster de destino, talvez seja necessário aumentar o tamanho da VM do balanceador de carga, bem como na criação do cluster de destino para garantir que os serviços possam ser alcançados com alto desempenho e que o tráfego seja roteado adequadamente.

A implantação do AKS habilitado pelo Arc distribui os nós de trabalho para cada pool de nós em um cluster de destino entre os nós disponíveis do Azure Stack HCI usando a lógica de posicionamento do Azure Stack HCI.

Importante

O posicionamento do nó não é preservado durante as atualizações da plataforma e do AKS e será alterado ao longo do tempo. Um nó físico com falha também afetará a distribuição de máquinas virtuais nos nós de cluster restantes.

Observação

Não execute mais de quatro criações de cluster de destino ao mesmo tempo se o cluster físico já estiver 50% cheio, pois isso pode levar à contenção temporária de recursos. Ao escalar verticalmente os pools de nós de cluster de destino em números grandes, leve em conta os recursos físicos disponíveis, pois o AKS não verifica a disponibilidade de recursos para processos paralelos de criação/dimensionamento em execução. Sempre certifique-se de reservar o suficiente para permitir atualizações e failover. Especialmente em ambientes muito grandes, essas operações, quando executadas em paralelo, podem levar ao esgotamento rápido de recursos.

Em caso de dúvida, entre em contato com seu escritório local da Microsoft para obter assistência ou postar no fórum da comunidade do Azure Stack HCI.

Próximas etapas

Opções de armazenamento

Share via