**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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#AvailableInstanceTypes), 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html), o [Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html) e o [Bottlerocket](https://aws.amazon.com/bottlerocket/faqs/). Antes de criar instâncias do Windows, consulte [Implantar nós do Windows em clusters de EKS](windows-support.md).
**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](eks-optimized-ami.md#arm-ami). Você precisa de instâncias criadas no Sistema Nitro ([Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances) ou [Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances)) ou que tenham recursos [acelerados](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/accelerated-computing-instances.html)? 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](https://aws.amazon.com/ec2/nitro/) 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](cni-increase-ip-addresses.md). 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](https://aws.amazon.com/ec2/nitro/) 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](cni-ipv6.md).
**Versão do complemento Amazon VPC CNI que você está executando**
A versão mais recente do [plug-in Amazon VPC CNI para Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) é compatível com [estes tipos de instância](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go). 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](managing-vpc-cni.md). 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](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/CHANGELOG.md) 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](security-groups-for-pods.md).
## 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](launch-templates.md#launch-template-custom-ami), 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`.
1. **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`.
1. **`maxPodsExpression` do nodeadm**: se você usar [https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/examples/#defining-a-max-pods-expression](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/examples/#defining-a-max-pods-expression) 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.
1. **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](launch-templates.md).
**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](launch-templates.md).
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.