Escolha os tipos de instância ECS para nós worker e master do ACK conforme a carga de trabalho, a tolerância a falhas e a escala do cluster.
Tipos de instância não suportados pelo ACK
Os tipos de instância a seguir não são compatíveis como nós worker ou master do ACK.
Restrições gerais
|
Família de instâncias não suportada |
Exemplo |
Motivo |
|
t5, burstable |
ecs.t5-lc2m1.nano |
Desempenho instável pode causar instabilidade no cluster |
|
t6, burstable |
ecs.t6-c4m1.large |
Desempenho instável pode causar instabilidade no cluster |
|
Tipos de instância com menos de 4 vCPUs |
ecs.g6.large |
Especificações insuficientes para operação estável do cluster |
|
c6t, computação otimizada com segurança aprimorada |
ecs.c6t.large |
Não suportado |
|
g6t, uso geral com segurança aprimorada |
ecs.g6t.large |
Não suportado |
|
Super Computing Cluster (SCC) |
ecs.sccg7.32xlarge |
Não suportado |
Para usar tipos de instância com especificações reduzidas, envie uma solicitação no Quota Center .
Para cargas de trabalho GPU, consulte Famílias de instâncias aceleradas por GPU suportadas pelo ACK.
Restrições do plugin de rede Terway
No Terway, a capacidade de pods por nó depende da quantidade de elastic network interfaces (ENIs) suportadas pelo tipo de instância. Tipos abaixo do limiar mínimo de pods são incompatíveis.
Modo ENI inclusivo ou Shared ENI + Trunk ENI mode: O limite de pods por nó deve exceder 11. Fórmula:
(Number of ENIs - 1) × Number of private IPs per ENI > 11Exemplo: a ecs.g6.large suporta 2 ENIs com 6 endereços IPv4 privados cada. Limite de pods =(2 - 1) × 6 = 6. Este tipo é incompatível.Exclusive ENI mode: O limite de pods por nó deve exceder 6. Fórmula:
Number of ENIs - 1 > 6Exemplo: a ecs.g6.xlarge suporta 3 ENIs. Limite de pods =3 - 1 = 2. Este tipo é incompatível.
Para verificar os tipos de instância compatíveis por modo do Terway, consulte Usar o plugin de rede Terway.
Por que poucas instâncias maiores oferecem melhor desempenho
Todo nó reserva CPU, memória e disco para gerenciar o cluster. Em instâncias pequenas, essas reservas consomem grande parte da capacidade total e deixam menos espaço para as cargas de trabalho.
A fragmentação agrava esse cenário. Após alocar recursos para um contêiner, o restante disponível em uma instância pequena pode ser insuficiente para outro contêiner e ficar ocioso.
Instâncias maiores resolvem ambos os problemas:
Maior eficiência de rede: Mais contêineres compartilham uma única instância, o que reduz o tráfego entre nós. Instâncias grandes também oferecem maior largura de banda de rede.
Download de imagem mais rápido: O nó baixa a imagem de contêiner apenas uma vez e a compartilha entre os contêineres. Com muitas instâncias pequenas, cada uma precisa baixar a mesma imagem, o que torna o scale-out mais lento.
Selecione as especificações dos nós worker
Especificações mínimas
Use tipos de instância com pelo menos 4 vCPUs e 8 GB de memória.
Dimensionamento para tolerância a falhas
Calcule o total de vCPUs necessárias para sua carga de trabalho diária e dimensione os nós para absorver falhas de instância sem interromper o serviço.
Exemplo:
|
Meta de tolerância a falhas |
Quantidade de nós |
Tamanho do nó |
Carga operacional máxima |
|
10% (um nó pode falhar) |
pelo menos 10 |
16 vCPUs |
144 núcleos (160 × 90%) |
|
20% (um nó pode falhar) |
pelo menos 5 |
32 vCPUs |
128 núcleos (160 × 80%) |
Se uma instância falhar, as demais continuam atendendo à carga de pico.
Proporção entre CPU e memória
Escolha a proporção adequada ao seu tipo de carga de trabalho:
1:2 ou 1:4: Cargas de trabalho de uso geral
1:8: Aplicações intensivas em memória, como serviços Java
Cargas de trabalho GPU
Para garantir agendamento estável, não misture tipos de instância com GPU e sem GPU no mesmo node pool.
Instâncias otimizadas para memória persistente
Famílias de instâncias como re6p usam arquitetura híbrida que combina memória comum e persistente. Para ativar o armazenamento persistente, consulte Volumes de memória não volátil. Consulte Famílias de instâncias para ver os tipos suportados.
Clusters de grande escala: ECS Bare Metal Instances
Para uma escala diária de aproximadamente 1.000 vCPUs, use ECS Bare Metal Instances. Uma única instância fornece pelo menos 96 vCPUs; portanto, um cluster de 1.000 núcleos requer apenas 10 a 11 nós. Consulte ECS Bare Metal Instances.
Selecione as especificações dos nós master
Os nós master executam etcd, kube-apiserver e kube-controller. Em clusters dedicados ACK de produção, dimensione os nós master conforme a escala do cluster.
O tamanho do cluster aqui é medido pela quantidade de nós. Na prática, a quantidade de pods, a frequência de deploy e o volume de requisições também são métricas válidas de dimensionamento.
Use instâncias pequenas apenas para testes. Para clusters de produção, selecione as especificações dos nós master na tabela a seguir.
|
Número de nós |
Especificações recomendadas para o nó master |
|
1–5 |
4 vCPUs, 8 GB de memória (2 vCPUs/4 GB ou menos não recomendado) |
|
6–20 |
4 vCPUs, 16 GB de memória |
|
21–100 |
8 vCPUs, 32 GB de memória |
|
100–200 |
16 vCPUs, 64 GB de memória |
|
200–500 (avalie o risco de blast radius) |
64 vCPUs, 128 GB de memória |
ECS Bare Metal Instances
Baseadas na virtualização 2.0 da Alibaba Cloud, as ECS Bare Metal Instances combinam a elasticidade de VMs com o desempenho de servidores físicos e suportam virtualização aninhada.
As ECS Bare Metal Instances são ideais para computação dedicada, computação criptografada e implantações de nuvem híbrida. Consulte Visão geral das ECS Bare Metal Instances para ver as famílias de instâncias suportadas.
Quando usar ECS Bare Metal Instances:
Grande escala de cluster: Para uma escala diária de aproximadamente 1.000 vCPUs, cada instância fornece pelo menos 96 núcleos e exige apenas 10 a 11 nós.
Picos de tráfego que exigem scale-out rápido: As ECS Bare Metal Instances superam servidores físicos com especificações equivalentes e escalam para milhões de vCPUs diante de picos repentinos de tráfego, como promoções de e-commerce.