Limites de recursos, tamanhos de VM e regiões para o AKS habilitado pelo Azure Arc
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 o AKS (Serviço de Kubernetes do Azure) habilitado pelo Azure Arc. Os testes usaram a versão mais recente do AKS no Azure Local.
Especificações máximas
O AKS habilitado por implantações do Arc foi validado com as configurações a seguir, incluindo os máximos especificados. Lembre-se de que exceder esses máximos é por sua conta e risco e pode levar a comportamentos e falhas inesperados. 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 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 do 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 do cluster de destino | Standard_K8S3_v1 |
A configuração de hardware de cada nó físico no cluster local do Azure é a seguinte:
- Chassi: Servidor Dell PowerEdge R650 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: 8 HDDs (2 TB ou mais) e 2 NVMe de 1,6 TB para oferecer suporte a configurações de armazenamento S2D.
- Rede: Quatro (4) NICs de 100 Gbit (Mellanox ou Intel).
A engenharia da Microsoft testou o AKS habilitado pelo Arc usando a configuração acima. Para nó único. 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 Dimensionando o 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 sem interrupção, começando com os nós do plano 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 VM nova e 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 Local. Embora os tamanhos de VM, como Standard_K8S2_v1 e Standard_K8S_v1 , tenham suporte para testes e implantações com 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 |
|---|---|---|---|---|
| Padrão | 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
Dimensionando o 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 conta.
Antes de começar, considere os seguintes pontos para determinar sua escala máxima e o número de clusters de destino que você precisa suportar:
- 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 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 do 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 do Host do 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.
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 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
Atualmente, há configurações e definições padrão não disponíveis para controle do cliente durante ou após a implantação. Essas configurações podem limitar a escala de 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. Consulte Considerações para clusters grandes.
Outras considerações:
- O número de endereços IP para serviços do Kubernetes, fora do pool VIP alocado, vem do
10.96.0.0/16pool de endereços. O sistema consome um dos 255 endereços disponíveis para o servidor de API do Kubernetes. - O tamanho da VM do 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 das VMs do plano de controle do cluster de destino e do balanceador de carga no momento da criação do cluster de destino.
Exemplo de escala
O exemplo de dimensionamento a seguir é baseado nestas 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 dar 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 do 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 obter o desempenho ideal, certifique-se de definir pelo menos 15% (100/8=12,5) da capacidade do cluster 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 de segundo dia do AKS.
Se você quiser aumentar 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 do host do 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 de hardware com suporte máximo. Você deve reservar aproximadamente 30% da capacidade, o que deixa você 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 e validação cuidadosas.
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 aumentar pelo menos um tamanho no plano 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 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 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 será alterado com o 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 por números grandes, 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 atualizações 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, entre em contato com o escritório local da Microsoft para obter assistência ou poste no fórum da comunidade local do Azure.