Limites de recursos, tamanhos de VM e regiões do AKS ativados 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 Azure Kubernetes Service (AKS) ativado pelo Azure Arc. Os testes utilizaram a versão mais recente do AKS no Azure Stack HCI.
Especificações máximas
O AKS ativado pelas implementações do Arc foi validado com as seguintes configurações, incluindo os máximos especificados. Tenha em atenção que exceder estes máximos está por sua conta e risco e pode levar a comportamentos e falhas inesperados. Este artigo fornece algumas orientações sobre como evitar erros de configuração comuns e pode ajudá-lo a criar uma configuração maior. Em caso de dúvida, contacte o seu escritório local da Microsoft para obter assistência ou submeta 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 máquina virtual (VM) predefinidos, com base na seguinte tabela:
| Função de sistema | Tamanho da VM |
|---|---|
| AKS-Host | Standard_A4_v2 |
| Nó Plano de Controlo 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 do Azure Stack HCI é 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, Cache de 30M, Turbo, HT (150 W) DDR4-2666.
- Disco: HDDs 8x (2 TB ou superior) e NVMe de 1,6 TB 2x para suportar configurações de armazenamento S2D.
- Rede: quatro (4) NICs de 100 Gbit (Mellanox ou Intel).
A engenharia da Microsoft testou o AKS ativado pelo Arc com a configuração acima. Para um único nó. 2 nós, 4 nós e 8 clusters de ativação pós-falha do Windows. Se tiver um requisito para exceder a configuração testada, veja Dimensionar o AKS no Azure Stack HCI.
Importante
Quando atualiza uma implementação do AKS, os recursos adicionais são temporariamente consumidos. Cada máquina virtual é atualizada num fluxo de atualização sem interrupção, começando pelos nós do plano de controlo. Para cada nó no cluster do Kubernetes, é criada uma nova VM de nó. A VM do nó antigo é restrita para impedir que as cargas de trabalho sejam implementadas na mesma. Em seguida, a VM restrita é drenada de todos os contentores para distribuir os contentores por outras VMs no sistema. Em seguida, a VM drenada é removida do cluster, encerrada e substituída pela nova VM atualizada. Este processo repete-se até que todas as VMs sejam atualizadas.
Tamanhos de VM disponíveis
Os seguintes tamanhos de VM para nós do plano de controlo, 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 suportados para testes e implementações de requisitos de recursos baixos, utilize estes tamanhos com cuidado e aplique testes rigorosos, uma vez que 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 GPUs |
|---|---|---|---|---|
| Predefiniçã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 suportadas para o registo do Azure
O AKS ativado pelo Arc é suportado nas seguintes regiões do Azure:
- Leste da Austrália
- E.U.A. Leste
- Sudeste Asiático
- Europa Ocidental
Dimensionar o AKS no Azure Stack HCI
Dimensionar uma implementação do AKS no Azure Stack HCI envolve planear antecipadamente ao conhecer as cargas de trabalho e a utilização do cluster de destino. Além disso, considere os recursos de hardware na sua infraestrutura subjacente, como o total de núcleos de CPU, memória total, armazenamento, Endereços IP, etc.
Os exemplos seguintes partem do princípio de que apenas as cargas de trabalho baseadas no AKS são implementadas na infraestrutura subjacente. A implementação de cargas de trabalho não AKS, como máquinas virtuais autónomas ou em cluster, ou servidores de bases de dados, reduz os recursos disponíveis para o AKS, que tem de ter em conta.
Antes de começar, considere os seguintes pontos para determinar a escala máxima e o número de clusters de destino que precisa de suportar:
- O número de endereços IP que tem disponíveis para pods num cluster de destino.
- O número de endereços IP disponíveis para os serviços do Kubernetes num cluster de destino.
- O número de pods de que precisa para executar as cargas de trabalho.
Para determinar o tamanho da VM do anfitrião Azure Kubernetes Service, tem de saber o número de nós de trabalho e clusters de destino, pois determina o tamanho da VM do Anfitrião do AKS. Por exemplo:
- O número de clusters de destino no sistema implementado final.
- O número de nós, incluindo o plano de controlo, o balanceador de carga e os nós de trabalho em todos os clusters de destino.
Nota
Um único anfitrião do AKS só pode gerir clusters de destino na mesma plataforma.
Além disso, para determinar o tamanho do nó do plano de controlo do cluster de destino, tem de saber o número de pods, contentores e nós de trabalho que está a planear implementar em cada cluster de destino.
Predefinições que atualmente não podem ser alteradas no AKS
Atualmente, existem configurações e definições predefinidas que não estão disponíveis para o controlo do cliente durante ou após a implementação. Estas definições podem limitar o dimensionamento de um determinado cluster de destino.
- O número de endereços IP para pods do Kubernetes num cluster de destino está limitado à sub-rede
10.244.0.0/16. Ou seja, podem ser utilizados 255 endereços IP por nó de trabalho em todos os espaços de nomes do Kubernetes para pods. Para ver o CIDR do pod atribuído a cada nó de trabalho no cluster, utilize 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, pode ver três nós com três CIDRs, cada um com capacidade para alojar 254 pods. A documentação de dimensionamento do Kubernetes recomenda que não exceda 110 pods por nó por motivos de desempenho. Veja Considerações para clusters grandes.
Outras considerações:
- O número de endereços IP dos serviços do Kubernetes, fora do conjunto VIP que alocou, provém do
10.96.0.0/16conjunto de endereços. O sistema consome um dos 255 endereços disponíveis para o servidor da API do Kubernetes. - O tamanho da VM do anfitrião do AKS só pode ser definido na instalação, quando executa Set-AksHciConfig pela primeira vez. Não pode alterá-lo mais tarde.
- Só pode definir o tamanho do plano de controlo do cluster de destino e das VMs do balanceador de carga no momento da criação do cluster de destino.
Exemplo de dimensionamento
O exemplo de dimensionamento seguinte baseia-se nestes pressupostos gerais/casos de utilização:
- Quer ser capaz de tolerar completamente a perda de um nó físico no cluster do Azure Stack HCI.
- Quer suportar a atualização de clusters de destino para versões mais recentes.
- Quer permitir uma elevada disponibilidade dos nós do plano de controlo do cluster de destino e dos nós do balanceador de carga.
- Quer reservar uma parte da capacidade global do Azure Stack HCI para estes casos.
Sugestões
Para um desempenho ideal, certifique-se de que define, pelo menos, 15 por cento (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. Esta configuração garante que tem alguma reserva disponível para efetuar uma atualização ou outras operações do AKS no segundo dia.
Se quiser crescer para além do limite de 200 VMs para um cluster de oito (8) nós de tamanho máximo do Azure Stack HCI, aumente o tamanho da VM do anfitrião do AKS. Duplicar o tamanho resulta em aproximadamente o dobro do número de VMs que pode gerir. Num cluster do Azure Stack HCI de 8 nós, pode obter 8192 VMs (8x1024) com base nos limites de recursos recomendados do Azure Stack HCI documentados nas Especificações máximas de hardware suportadas. Deve reservar aproximadamente 30% da capacidade, o que o deixa com um limite teórico de 5734 VMs em todos os nós.
- Standard_D32s_v3, para o anfitrião do AKS com 32 núcleos e 128 GB, pode suportar um máximo de 1600 nós.
Nota
Uma vez que esta configuração não foi testada extensivamente, requer uma abordagem e validação cuidadosas.
Numa escala como esta, poderá querer dividir o ambiente em, pelo menos, 8 clusters de destino com 200 nós de trabalho cada.
Para executar 200 nós de trabalho num cluster de destino, pode utilizar o plano de controlo predefinido e o tamanho do balanceador de carga. Consoante o número de pods por nó, pode subir pelo menos um tamanho no plano de controlo e utilizar Standard_D8s_v3.
Dependendo do número de serviços do Kubernetes alojados em cada cluster de destino, poderá ter de aumentar o tamanho da VM do balanceador de carga, bem como na criação do cluster de destino, para garantir que os serviços podem ser alcançados com elevado desempenho e que o tráfego é encaminhado em conformidade.
A implementação do AKS ativada pelo Arc distribui os nós de trabalho por cada conjunto de nós num cluster de destino através dos nós do Azure Stack HCI disponíveis com a lógica de colocação 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 restantes nós de cluster.
Nota
Não execute mais do que quatro criações de clusters de destino ao mesmo tempo se o cluster físico já estiver 50% cheio, uma vez que isso pode levar à contenção temporária de recursos. Ao aumentar verticalmente os conjuntos de nós de cluster de destino em grandes números, tenha em conta os recursos físicos disponíveis, uma vez que o AKS não verifica a disponibilidade dos recursos para processos paralelos de criação/dimensionamento em execução. Garanta sempre reserva suficiente para permitir atualizações e ativação pós-falha. Especialmente em ambientes muito grandes, estas operações, quando executadas em paralelo, podem levar a um rápido esgotamento de recursos.
Em caso de dúvida, contacte o microsoft office local para obter assistência ou publicar no fórum da comunidade do Azure Stack HCI.