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

Artigo
02/20/2025

Aplica-se a: AKS na versão local do Azure 22H2, AKS no Windows Server

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

Especificações máximas

O AKS habilitado pelas implantações Arc foi validado com as seguintes configurações, incluindo os máximos especificados. Tenha em mente que exceder esses máximos é por sua conta e risco e pode levar a comportamentos inesperados e falhas. Este artigo fornece algumas orientações 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 o escritório local da Microsoft para obter assistência ou envie uma pergunta na comunidade local do Azure.

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

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

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

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

Chassis: Dell PowerEdge R650 Server ou similar.
RAM: RDIMM, 3200 MT / s, Dual Rank, 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: 8x HDDs (2 TB ou mais) e 2x NVMe de 1,6 TB para suportar configurações de armazenamento S2D.
Rede: Quatro (4) NICs de 100 Gbit (Mellanox ou Intel).

A engenharia da Microsoft testou o AKS habilitado pela 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 Local.

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 contínua, começando com os nós do plano de controle. Para cada nó no cluster Kubernetes, uma nova VM de nó é criada. A VM do nó antigo é restrita para evitar 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 de plano de controle, nós de trabalho do Linux e nós de trabalho do Windows estão disponíveis para o AKS no Azure Local. Embora tamanhos de VM, como Standard_K8S2_v1 e Standard_K8S_v1 , sejam suportados para testes e implantações de baixo requisito de recursos, use esses tamanhos com cuidado e aplique testes rigorosos, pois eles podem resultar em falhas inesperadas devido a condições de falta de memória.

Tamanho da VM	CPU	Memória (GB)	Tipo de GPU	Contagem de GPU
Predefinido	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 suportadas para registo do Azure

O AKS habilitado pelo Arc é suportado nas seguintes regiões do Azure:

Leste da Austrália
E.U.A. Leste
Sudeste Asiático
Europa Ocidental

Dimensionamento do AKS no Azure Local

Dimensionar uma implantação do AKS no Azure Local envolve planejar com antecedência, 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 total de núcleos 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 são implantadas na infraestrutura subjacente. A implantação de cargas de trabalho não AKS, como máquinas virtuais autônomas ou clusterizadas, ou servidores de banco de dados, reduz os recursos disponíveis para o AKS, que você deve levar em consideração.

Antes de começar, considere os seguintes pontos para determinar sua 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 serviços Kubernetes em um cluster de destino.
O número de pods que você precisa para executar suas cargas de trabalho.

Para determinar o tamanho da sua VM de Host de Serviço 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 de Host AKS. Por exemplo:

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

Nota

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

Além disso, para determinar o tamanho do nó do plano 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

Há configurações e configurações padrão atualmente não disponíveis para 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 pod CIDR atribuído a cada nó de trabalho em seu 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 da escala do Kubernetes recomenda que você não exceda 110 pods por nó por motivos de desempenho. Consulte Considerações para clusters grandes.

Outras considerações:

O número de endereços IP para serviços Kubernetes, fora do pool VIP que você alocou, 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 host AKS só pode ser definido na instalação, quando você executa Set-AksHciConfig pela primeira vez. Não é possível alterá-lo mais tarde.
Você só pode definir o tamanho do plano de controle do 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/casos de uso gerais:

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

Sugestões

Para um desempenho ideal, certifique-se de definir pelo menos 15% (100/8=12,5) da capacidade do cluster de lado 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 crescer além do limite de 200 VMs para um cluster local do Azure de oito (8) nós de tamanho máximo de hardware, aumente o tamanho da VM de host AKS. Dobrar de tamanho resulta em aproximadamente o dobro do número de VMs que ele pode gerenciar. Em um cluster Local do Azure de 8 nós, você pode obter 8.192 (8x1024) VMs com base nos limites de recursos recomendados do Azure Local 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 suportar um máximo de 1.600 nós.
Nota

Uma vez que esta configuração não foi testada extensivamente, 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.
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 plano de controle e usá Standard_D8s_v3.
Dependendo do número de serviços 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 o tráfego seja roteado de acordo.

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

Importante

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

Nota

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 dimensionar os pools de nós do cluster de destino em grandes números, leve em consideração os recursos físicos disponíveis, pois o AKS não verifica a disponibilidade de recursos para processos de criação/dimensionamento em execução paralela. Sempre garanta reserva suficiente para permitir upgrades e failover. Especialmente em ambientes muito grandes, essas operações, quando executadas em paralelo, podem levar ao rápido esgotamento de recursos.

Em caso de dúvida, contacte o escritório local da Microsoft para obter assistência ou publicar no fórum da comunidade local do Azure.

Próximos passos

Opções de armazenamento

Partilhar via