Escolher um tipo de instância de nó do Amazon EC2 ideal - Amazon EKS
Como maxPods é determinadoConsiderações para o Modo Automático do EKS

Ajudar a melhorar esta página

Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.

Escolher um tipo de instância de nó do Amazon EC2 ideal

O Amazon EC2 fornece uma extensa seleção de tipos de instância para nós de processamento. Cada tipo de instância oferece diferentes capacidades de computação, memória, armazenamento e rede. Cada instância também é agrupada em famílias de acordo com esses recursos. Para obter uma lista, consulte Tipos de instância disponíveis, no Guia do usuário do Amazon EC2. O Amazon EKS lança diversas variações de AMIs do Amazon EC2 para permitir suporte. Para garantir que o tipo de instância selecionado seja compatível com o Amazon EKS, considere estes critérios.

  • As AMIs do Amazon EKS no momento não são compatíveis com a família mac.

  • Arm e AMIs do Amazon EKS não aceleradas não são compatíveis com as famílias g3, g4, inf e p.

  • AMIs aceleradas do Amazon EKS não têm suporte para as famílias a, c, hpc, m e t.

  • Para instâncias baseadas em Arm, o Amazon Linux 2023 (AL2023) é somente compatível com tipos de instância que usam processadores Graviton2 ou versões mais recentes. O AL2023 não é compatível com instâncias A1.

Ao escolher entre tipos de instância que têm suporte pelo Amazon EKS, considere os recursos a seguir de cada tipo.

Número de instâncias em um grupo de nós

Em geral, um número menor de instâncias maiores é melhor, especialmente se você tiver muitos DaemonSets. Cada instância requer chamadas de API para o servidor de API, portanto, quanto mais instâncias você tiver, maior a carga no servidor de APIs.

Sistema operacional

Revise os tipos de instância compatíveis com o Linux, o Windows e o Bottlerocket. Antes de criar instâncias do Windows, consulte Implantar nós do Windows em clusters de EKS.

Arquitetura de hardware

Você precisa de x86 ou Arm? Antes de implementar instâncias do Arm, analise as AMIs do Amazon EKS otimizadas para Arm Amazon Linux. Você precisa de instâncias criadas no Sistema Nitro (Linux ou Windows) ou que tenham recursos acelerados? Se você precisar de recursos acelerados, só poderá usar o Linux com o Amazon EKS.

Número máximo de pods

Como cada pod é atribuído ao seu próprio endereço IP, o número de endereços IP compatíveis com um tipo de instância é um fator para determinar o número de pods que podem ser executados em uma instância. Para determinar manualmente quantos pods um tipo de instância suporta, consulte .

Os tipos de instância do AWS Nitro System opcionalmente oferecem suporte a bem mais endereços IP do que os tipos de instância que não são do Nitro System. Contudo, nem todos os endereços IP atribuídos a uma instância estão disponíveis para pods. Para atribuir um número significativamente maior de endereços IP às suas instâncias, é necessário ter a versão 1.9.0 ou superior do complemento CNI da Amazon VPC instalado em seu cluster e configurado adequadamente. Para obter mais informações, consulte Atribuir mais endereços IP aos nós do Amazon EKS com prefixos. Para atribuir o maior número de endereços IP às suas instâncias, a versão 1.10.1 ou superior do complemento CNI da Amazon VPC deverá estar instalada em seu cluster e o cluster deverá ser implantado com a família IPv6.

Família IP

É possível usar qualquer tipo de instância compatível ao usar a família IPv4 para um cluster, o que permite ao cluster atribuir endereços IPv4 privados aos pods e serviços. Porém, se você deseja utilizar a família IPv6 para o seu cluster, deve usar tipos de instância do AWS Nitro System ou tipos de instância de bare metal. Somente o IPv4 é compatível com instâncias do Windows. O cluster deve executar a versão 1.10.1 ou posterior do complemento CNI da Amazon VPC. Para obter mais informações sobre o uso de IPv6, consulte Saiba mais sobre endereços IPv6 para clusters, pods e serviços.

Versão do complemento Amazon VPC CNI que você está executando

A versão mais recente do plug-in Amazon VPC CNI para Kubernetes é compatível com estes tipos de instância. Talvez seja necessário atualizar a versão do complemento Amazon VPC CNI para poder aproveitar os tipos de instância mais recentes com suporte. Para obter mais informações, consulte Atribuir IPs a pods com a CNI da Amazon VPC. A versão mais recente suporta os recursos mais recentes para serem usados com o Amazon EKS. As versões anteriores não suportam todos os recursos. É possível visualizar os recursos suportados por diferentes versões no Changelog no GitHub.

AWS Região da em que você está criando seus nós

Nem todos os tipos de instâncias estão disponíveis em todas as regiões da AWS.

Se você estiver usando grupos de segurança para pods

Se você estiver usando grupos de segurança para pods, apenas determinados tipos de instância serão compatíveis. Para obter mais informações, consulte Atribuir grupos de segurança a pods individuais.

Como maxPods é determinado

O valor final de maxPods aplicado a um nó depende de vários componentes que interagem em uma ordem específica de precedência. Compreender esse pedido ajuda a evitar comportamentos inesperados durante a personalização de maxPods.

Ordem de precedência (de maior para menor):

  1. Aplicação de grupos de nós gerenciados: quando você usa um grupo de nós gerenciados sem uma AMI personalizada, o Amazon EKS impõe uma restrição a maxPods nos dados do usuário do nó. Para instâncias com menos de 30 vCPUs, a restrição é 110. Para instâncias com mais de 30 vCPUs, a restrição é 250. Esse valor tem precedência sobre qualquer outra configuração de maxPods, inclusive maxPodsExpression.

  2. Configuração de maxPods do kubelet: se você definir maxPods diretamente na configuração do kubelet (por exemplo, por meio de um modelo de execução com uma AMI personalizada), esse valor terá precedência sobre maxPodsExpression.

  3. maxPodsExpression do nodeadm: se você usar maxPodsExpression em seu NodeConfig, o nodeadm avaliará a expressão para calcular maxPods. Essa ação só é efetiva quando o valor ainda não está definido por uma fonte de maior precedência.

  4. Cálculo padrão baseado em ENI: se nenhum outro valor for definido, a AMI calculará maxPods com base no número de interfaces de rede elástica e endereços IP com suporte no tipo de instância. Isso é equivalente à fórmula (number of ENIs × (IPs per ENI − 1)) + 2. As contas + 2 do CNI da Amazon VPC e kube-proxy em execução em todos os nós, o que não consome um endereço IP do pod.

Importante

Se você usar um grupo de nós gerenciados e definir maxPodsExpression em NodeConfig, a imposição do grupo de nós gerenciados substituirá sua expressão. Para usar um valor de maxPods personalizado com grupos de nós gerenciados, é necessário especificar uma AMI personalizada em seu modelo de execução e configurar maxPods diretamente. Para obter mais informações, consulte Personalizar nós gerenciados com modelos de execução.

Grupos de nós gerenciados versus nós autogerenciados

Com grupos de nós gerenciados (sem uma AMI personalizada), o Amazon EKS injeta o valor maxPods nos dados de bootstrap do usuário do nó. Isso significa que:

  • O valor maxPods é sempre restrito a 110 ou 250 depende do tamanho da instância.

  • Todas as maxPodsExpression que você configurar serão substituídas por esse valor injetado.

  • Para usar um valor de maxPods diferente, especifique uma AMI personalizada em seu modelo de execução e passe --use-max-pods false junto com --kubelet-extra-args '--max-pods=my-value' ao script bootstrap.sh. Para obter exemplos, consulte Personalizar nós gerenciados com modelos de execução.

Com os nós autogerenciados, você tem controle total sobre o processo de bootstrap. É possível usar maxPodsExpression em seu NodeConfig ou passar --max-pods diretamente para bootstrap.sh.

Considerações para o Modo Automático do EKS

O Modo Automático do EKS limita o número de pods nos nós inferior:

  • À capacidade fixa de 110 pods

  • Ao resultado do cálculo do máximo de pods descrito acima.