**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.
# Simplificar o ciclo de vida dos nós com grupos de nós gerenciados
Os grupos de nós gerenciados do Amazon EKS automatizam o provisionamento e o gerenciamento do ciclo de vida dos nós (instâncias do Amazon EC2) para clusters de Kubernetes do Amazon EKS.
Com os grupos de nós gerenciados do Amazon EKS, não é necessário provisionar ou registrar separadamente as instâncias do Amazon EC2 que fornecem capacidade computacional para executar as aplicações do Kubernetes. Você pode criar, atualizar ou encerrar os nós para o cluster com uma única operação. As atualizações e terminações do nó esvaziam os nós automaticamente para garantir que as aplicações continuem disponíveis.
Todos os nós gerenciados são provisionados como parte de um grupo do Amazon EC2 Auto Scaling gerenciado pelo Amazon EKS para você. Todos os recursos, inclusive as instâncias e os grupos do Auto Scaling, são executados em sua conta da AWS. Cada grupo de nós é executado em várias zonas de disponibilidade definidas por você.
Os grupos de nós gerenciados também podem, opcionalmente, aproveitar o reparo automático de nós, que monitora continuamente a integridade dos nós. Ele reage automaticamente aos problemas detectados e substitui os nós quando possível. Isso ajuda na disponibilidade geral do cluster com o mínimo de intervenção manual. Para obter mais informações, consulte [Detectar problemas de integridade dos nós e habilitar o reparo automático dos nós](node-health.md).
Você pode adicionar um grupo de nós gerenciados a clusters novos ou existentes usando o console do Amazon EKS, o `eksctl`, a AWS CLI, a API da AWS ou a infraestrutura como ferramentas de código, incluindo o AWS CloudFormation. Os nós iniciados como parte de um grupo de nós gerenciados são marcados automaticamente para detecção automática pelo [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) do Kubernetes. É possível usar o grupo de nós para aplicar rótulos do Kubernetes aos nós e atualizá-los a qualquer momento.
Não há custos adicionais pelo uso dos grupos de nós gerenciados pelo Amazon EKS. Você só pagará pelos recursos da AWS que provisionar. Isso inclui as instâncias do Amazon EC2, os volumes do Amazon EBS, as horas de cluster do Amazon EKS e qualquer outra infraestrutura da AWS. Não há taxas mínimas nem compromissos antecipados.
Para começar a usar um novo cluster do Amazon EKS e um grupo de nós gerenciados, consulte [Comece a usar o Amazon EKS - Console de gerenciamento da AWS e AWS CLI](getting-started-console.md).
Para adicionar um grupo de nós gerenciados a um cluster existente, consulte [Criar um grupo de nós gerenciados para seu cluster](create-managed-node-group.md).
## Conceitos dos grupos de nós gerenciados
+ Os grupos de nós gerenciados do Amazon EKS criam e gerenciam instâncias do Amazon EC2 para você.
+ Todos os nós gerenciados são provisionados como parte de um grupo do Amazon EC2 Auto Scaling gerenciado pelo Amazon EKS para você. Além disso, todos os recursos, inclusive as instâncias do Amazon EC2 e os grupos do Auto Scaling, são executados em sua conta da AWS.
+ O grupo do Auto Scaling de um grupo de nós gerenciados abrange todas as sub-redes que você especificar ao criar o grupo.
+ O Amazon EKS marca recursos do grupo de nós gerenciados para que eles sejam configurados para usar o [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) do Kubernetes.
**Importante**
Se estiver executando uma aplicação com estado em várias zonas de disponibilidade com suporte de volumes do Amazon EBS e usando o [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) do Kubernetes, você deverá configurar vários grupos de nós, cada um com escopo de uma única zona de disponibilidade. Além disso, você deverá ativar o recurso `--balance-similar-node-groups`.
+ Você pode usar um modelo de execução personalizado para obter um nível maior de flexibilidade e personalização ao implantar nós gerenciados. Por exemplo, é possível especificar argumentos `kubelet` extras e usar uma AMI personalizada. Para obter mais informações, consulte [Personalizar nós gerenciados com modelos de execução](launch-templates.md). Se você não usar um modelo de execução personalizado ao criar primeiro um grupo de nós gerenciados, um modelo de execução será gerado automaticamente. Não modifique manualmente esse modelo gerado automaticamente, ou ocorrerão erros.
+ O Amazon EKS segue o modelo de responsabilidade compartilhada para CVEs e patches de segurança nos grupos de nós gerenciados. Quando os nós gerenciados executam uma AMI otimizada para o Amazon EKS, o Amazon EKS é responsável por criar versões da AMI com patches quando erros ou problemas forem relatados. Podemos publicar uma correção. No entanto, você é responsável por implantar essas versões de AMI com patches nos grupos de nós gerenciados. Quando os nós gerenciados executam uma AMI personalizada, você é responsável por criar versões da AMI com patches quando erros ou problemas forem relatados e, em seguida, implantar a AMI. Para obter mais informações, consulte [Atualizar um grupo de nós gerenciados para seu cluster](update-managed-node-group.md).
+ Os grupos de nós gerenciados do Amazon EKS podem ser executados em sub-redes públicas e privadas. Se você executar um grupo de nós gerenciados em uma sub-rede pública depois de 22 de abril de 2020, a sub-rede deverá ter o `MapPublicIpOnLaunch` definida como true para que as instâncias possam ingressar com êxito em um cluster. Se a sub-rede pública tiver sido criada usando `eksctl` ou os [modelos do Amazon EKS vended AWS CloudFormation](creating-a-vpc.md) em ou após 26 de março de 2020, essa configuração já estará definida como verdadeira. Se as sub-redes públicas foram criadas antes de 26 de março de 2020, será necessário alterar a configuração manualmente. Para obter mais informações, consulte [Modificar o atributo de endereçamento IPv4 público para a sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip).
+ Ao implantar um grupo de nós gerenciados em sub-redes privadas, certifique-se de que ele possa acessar o Amazon ECR para extrair imagens de contêiner. Você pode fazer isso conectando um gateway NAT à tabela de rotas da sub-rede ou adicionando os seguintes [endpoints de VPC do AWS PrivateLink](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create):
+ Interface do endpoint de API do Amazon ECR - `com.amazonaws.region-code.ecr.api`
+ Interface do endpoint de API do registro Docker do Amazon ECR - `com.amazonaws.region-code.ecr.dkr`
+ Endpoint de gateway do Amazon S3 - – `com.amazonaws.region-code.s3`
Para conhecer alguns serviços e endpoints frequentemente, consulte [Implementar clusters privados com acesso limitado à internet](private-clusters.md).
+ Os grupos de nós gerenciados não podem ser implantados no [AWS Outposts](eks-outposts.md) ou no [AWS Wavelength](https://docs.aws.amazon.com/wavelength/). Os grupos de nós gerenciados podem ser criados nas [Zonas locais da AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/). Para obter mais informações, consulte [Executar clusters do EKS de baixa latência com zonas locais da AWS](local-zones.md).
+ Você pode criar vários grupos de nós gerenciados em um único cluster. Por exemplo, é possível criar um grupo de nós com a AMI padrão do Amazon Linux otimizada para o Amazon EKS para algumas workloads e outro grupo com a variante de GPU para workloads que requerem suporte para GPU.
+ Se o grupo de nós gerenciados encontrar uma falha nas [verificações de status para as instâncias do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html), o Amazon EKS retornará um código de erro para ajudar você a diagnosticar o problema. Para obter mais informações, consulte [Códigos de erro para o grupo de nós gerenciados](troubleshooting.md#troubleshoot-managed-node-groups).
+ O Amazon EKS adiciona rótulos do Kubernetes a instâncias de grupo de nós gerenciados. Esses rótulos fornecidos pelo Amazon EKS são prefixados com `eks.amazonaws.com`.
+ O Amazon EKS drena automaticamente os nós usando a API do Kubernetes durante os encerramentos ou atualizações.
+ Os orçamentos de interrupção do pod não são respeitados ao encerrar um nó com `AZRebalance` ou reduzir a contagem de nós desejada. Essas ações tentam remover os pods no nó. Mas se demorar mais de 15 minutos, o nó será encerrado, independentemente de todos os pods no nó serem encerrados. Para estender o período até que o nó seja encerrado, adicione um hook do ciclo de vida ao grupo do Auto Scaling. Para obter mais informações, consulte [Adicionar ganchos de ciclo de vida](https://docs.aws.amazon.com/autoscaling/ec2/userguide/adding-lifecycle-hooks.html), no *Guia do usuário do Amazon EC2 Auto Scaling*.
+ Para executar o processo de drenagem corretamente após receber uma notificação de interrupção pontual ou uma notificação de rebalanceamento de capacidade, `CapacityRebalance` deve ser definido como `true`.
+ A atualização de grupos de nós gerenciados respeita os orçamentos de interrupções de pods definidos para os pods. Para obter mais informações, consulte [Entenda cada fase das atualizações de nós](managed-node-update-behavior.md).
+ Não há custos adicionais para o uso dos grupos de nós gerenciados do Amazon EKS. Você paga apenas pelo recursos da AWS que provisionar.
+ Se quiser criptografar volumes do Amazon EBS para os nós, você pode implantar os nós usando um modelo de execução. Para implantar nós gerenciados com volumes criptografados do Amazon EBS sem usar um modelo de execução, criptografe todos os novos volumes do Amazon EBS criados em sua conta. Para obter mais informações, consulte [Criptografia por padrão](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) no *Guia do usuário do Amazon EC2*.
## Tipos de capacidade do grupo de nós gerenciados
Ao criar um grupo de nós gerenciados, você pode escolher o tipo de capacidade sob demanda ou spot. O Amazon EKS implanta um grupo de nós gerenciados com um grupo do Amazon EC2 Auto Scaling que contém apenas instâncias spot sob demanda ou apenas instâncias spot do Amazon EC2. Você pode agendar pods para aplicações tolerantes a falhas em grupos de nós gerenciados Spot e aplicações não tolerantes a falhas para grupos de nós Sob demanda em um único cluster do Kubernetes. Por padrão, um grupo de nós gerenciados implanta instâncias do Amazon EC2 sob demanda.
### Sob demanda
Com o as instâncias sob demanda, você paga pela capacidade computacional por segundo, sem nenhum compromisso em longo prazo.
Por padrão, se você não especificar um **Tipo de capacidade**, o grupo de nós gerenciados será provisionado com instâncias sob demanda. Um grupo de nós gerenciados configura um grupo do Amazon EC2 Auto Scaling em seu nome com as seguintes configurações aplicadas:
+ A estratégia de alocação para provisionar capacidade sob demanda é definida como `prioritized`. O grupo de nós gerenciados usa a ordem dos tipos de instâncias transferidas na API para determinar qual tipo de instância usar primeiro para atender à capacidade sob demanda. Por exemplo, você pode especificar três tipos de instância na seguinte ordem: `c5.large`, `c4.large` e `c3.large`. Quando as instâncias sob demanda são iniciadas, o grupo de nós gerenciados atende à capacidade sob demanda, começando com o `c5.large`, depois o `c4.large` e, em seguida, o `c3.large`. Para obter mais informações, consulte [Grupo do Amazon EC2 Auto Scaling)](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-purchase-options.html#asg-allocation-strategies) no *Guia do usuário do Amazon EC2 Auto Scaling*.
+ O Amazon EKS adiciona o seguinte rótulo do Kubernetes a todos os nós do grupo de nós gerenciados que especifica o tipo de capacidade: `eks.amazonaws.com/capacityType: ON_DEMAND`. Você pode usar esse rótulo para agendar aplicações com estado ou intolerantes a falhas em nós sob demanda.
### Spot
As instâncias spot do Amazon EC2 representam uma capacidade sobressalente do Amazon EC2 que oferecem descontos substanciais nos preços sob demanda. As instâncias spot do Amazon EC2 podem ser interrompidas com um aviso de interrupção de dois minutos, quando o EC2 precisar da capacidade de volta. Para obter mais informações, consulte [Instâncias spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) no *Guia do usuário do Amazon EC2*. Você pode configurar um grupo de nós gerenciados com as instâncias spot do Amazon EC2 para otimizar os custos dos nós de computação em execução no cluster do Amazon EKS.
Para usar instâncias spot dentro de um grupo de nós gerenciados, crie o grupo definindo o tipo de capacidade como `spot`. Um grupo de nós gerenciados configura um grupo do Amazon EC2 Auto Scaling em seu nome com as seguintes práticas recomendadas Spot aplicadas:
+ Para garantir que os nós spot sejam provisionados nos pools de capacidade spot ideais, a estratégia de alocação é definida como uma das seguintes opções:
+ `price-capacity-optimized` (PCO): ao criar grupos de nós em um cluster com a versão `1.28` ou mais recente do Kubernetes, a estratégia de alocação é definida como `price-capacity-optimized`. No entanto, a estratégia de alocação não será alterada para grupos de nós já criados com `capacity-optimized` antes de os grupos de nós gerenciados pelo Amazon EKS começarem a oferecer suporte ao PCO.
+ `capacity-optimized` (CO): ao criar grupos de nós em um cluster com a versão `1.27` ou mais recente do Kubernetes, a estratégia de alocação é definida como `capacity-optimized`.
Para aumentar o número de grupos de capacidade spot disponíveis para alocação de capacidade, configure um grupo de nós gerenciados para usar vários tipos de instância.
+ O Rebalanceamento de capacidade spot do Amazon EC2 está habilitado para que o Amazon EKS possa drenar e reequilibrar os nós spot para minimizar a interrupção da aplicação quando um nó spot correr um risco alto de interrupção. Para obter mais informações, consulte [Rebalancear a capacidade do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/capacity-rebalance.html) no *Guia do usuário do Amazon EC2 Auto Scaling*.
+ Quando um nó spot recebe uma recomendação de rebalanceamento, o Amazon EKS tenta iniciar automaticamente um novo nó spot de substituição.
+ Se um aviso de interrupção do spot de dois minutos chegar antes que o nó spot de substituição esteja em um estado `Ready`, o Amazon EKS começa a drenar o nó spot que recebeu a recomendação de rebalanceamento. O Amazon EKS drena o nó da melhor forma possível. Como resultado, não há garantia de que o Amazon EKS aguardará que o nó de substituição se junte ao cluster antes de drenar o nó existente.
+ Quando um nó spot de substituição inclui o bootstrap no estado `Ready` no Kubernetes, o Amazon EKS isola e drena o nó spot que recebeu a recomendação de rebalanceamento. Isolar o nó spot garante que o controlador de serviço não envie novas solicitações para esse nó spot. Ele também o remove da lista de nós spot íntegros e ativos. Drenar o nó spot garante que os pods em execução sejam removidos de forma adequada.
+ O Amazon EKS adiciona o seguinte rótulo do Kubernetes a todos os nós do grupo de nós gerenciados que especifica o tipo de capacidade: `eks.amazonaws.com/capacityType: SPOT`. Você pode usar esse rótulo para agendar aplicações com estado ou intolerantes a falhas em nós spot.
**Importante**
O EC2 emite um [aviso de interrupção da instância spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html) dois minutos antes de encerrar a instância spot. No entanto, os pods presentes nos nós spot podem não dispor de toda a janela de dois minutos para realizar um encerramento sem interrupções. Após a emissão do aviso pelo EC2, há um atraso antes que o Amazon EKS comece a remoção dos pods. As remoções ocorrem de forma sequencial para proteger o servidor de APIs do Kubernetes, portanto, durante diversas recuperações simultâneas de instâncias spot, alguns pods podem receber avisos de remoção com atraso. Os pods podem ser encerrados abruptamente sem receber sinais de encerramento, especialmente em nós com alta densidade de pods, durante recuperações simultâneas ou ao usar períodos de carência prolongados para o encerramento. Para workloads spot, recomendamos projetar aplicações tolerantes a interrupções, empregando períodos de carência para o encerramento de 30 segundos ou menos, evitando hooks de interrupções antecipadas de longa duração e monitorando métricas de remoção de pods para compreender os períodos reais de carência nos clusters. Para workloads que exigem a garantia de um encerramento sem interrupções, recomendamos o uso da capacidade sob demanda em vez disso.
Ao decidir se deseja implantar um grupo de nós com capacidade sob demanda ou spot, você deve considerar as seguintes condições:
+ Convém usar instâncias spot para aplicações sem estado, com tolerância a falhas e flexíveis. Isso inclui workloads de treinamento em lote e de machine learning, ETLs de big data, como Apache Spark, aplicações de processamento de fila e endpoints de API sem estado. Como o spot é a capacidade sobressalente do Amazon EC2, que pode ser alterada ao longo do tempo, recomendamos usar a capacidade spot para workloads tolerantes a interrupções. Mais especificamente, a capacidade spot é adequada para workloads que podem tolerar períodos em que a capacidade necessária não está disponível.
+ Recomendamos usar On-Demand para aplicações que sejam intolerantes a falhas. Isso inclui ferramentas de gerenciamento de clusters, como ferramentas operacionais e de monitoramento, implantações que exigem `StatefulSets` e aplicações com estado, como bancos de dados.
+ Para maximizar a disponibilidade de suas aplicações ao usar instâncias spot, recomendamos que você configure um grupo de nós gerenciados spot para usar vários tipos de instância. Recomendamos aplicar as seguintes regras ao usar vários tipos de instância:
+ Dentro de um grupo de nós gerenciados, se você estiver usando o [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md), recomendamos o uso de um conjunto flexível de tipos de instância com a mesma quantidade de vCPU e recursos de memória. Isso serve para garantir que os nós de seu cluster escalem conforme o esperado. Por exemplo, se você precisar de quatro vCPUs e oito GiB de memória, use `c3.xlarge`, `c4.xlarge`, `c5.xlarge`, `c5d.xlarge`, `c5a.xlarge`, `c5n.xlarge` ou outros tipos de instância semelhantes.
+ Para melhorar a disponibilidade das aplicações, recomendamos implantar vários grupos de nós gerenciados pelo spot. Para isso, cada grupo deverá usar um conjunto flexível de tipos de instância que tenham os mesmos recursos de vCPU e memória. Por exemplo, se você precisar de 4 vCPUs e 8 GiB de memória, recomendamos que você crie um grupo de nós gerenciados com `c3.xlarge`, `c4.xlarge`, `c5.xlarge`, `c5d.xlarge`, `c5a.xlarge`, `c5n.xlarge` ou outros tipos de instância semelhantes, e um segundo grupo de nós gerenciados com `m3.xlarge`, `m4.xlarge`, `m5.xlarge`, `m5d.xlarge`, `m5a.xlarge`, `m5n.xlarge` ou outros tipos de instância semelhantes.
+ Ao implantar o grupo de nós com o tipo de capacidade spot que estiver usando um modelo de execução personalizado, use a API para passar vários tipos de instância. Não passe um único tipo de instância pelo modelo de execução. Para obter mais informações sobre como implantar um grupo de nós usando um modelo de execução, consulte [Personalizar nós gerenciados com modelos de execução](launch-templates.md).
# Criar um grupo de nós gerenciados para seu cluster
Este tópico descreve como iniciar grupos de nós gerenciados do Amazon EKS com nós registrados no cluster do Amazon EKS. Depois que os nós ingressam no cluster, você pode implantar aplicações do Kubernetes neles.
Se esta for a primeira vez que você inicia um grupo de nós gerenciados do Amazon EKS, recomendamos que você siga um de nossos guias em [Começar a usar o Amazon EKS](getting-started.md). Estes guias fornecem orientações para a criação de um cluster do Amazon EKS com nós.
**Importante**
Os nós do Amazon EKS são instâncias padrão do Amazon EC2. Você é cobrado com base nos preços normais do Amazon EC2. Para obter mais informações, consulte [Preço do Amazon EC2](https://aws.amazon.com/ec2/pricing/).
Não é possível criar nós gerenciados em uma região da AWS onde haja AWS Outposts ou AWS Wavelength habilitados. É possível criar nós autogerenciados em vez isso. Para obter mais informações, consulte [Criar nós autogerenciados do Amazon Linux](launch-workers.md), [Criar nós autogerenciados do Microsoft Windows](launch-windows-workers.md) e [Criar nós Bottlerocket autogerenciados do Bottlerocket](launch-node-bottlerocket.md). Você também pode criar um grupo de nós autogerenciado do Amazon Linux em um Outpost. Para obter mais informações, consulte [Criar nós Amazon Linux no AWS Outposts](eks-outposts-self-managed-nodes.md).
Se você não [especificar um ID da AMI](launch-templates.md#launch-template-custom-ami) para o arquivo `bootstrap.sh` incluso no Linux ou Bottlerocket otimizado para Amazon EKS, os grupos de nós gerenciados vão impor um número máximo no valor de `maxPods`. Para instâncias com menos de 30 vCPUs, o número máximo é `110`. Para instâncias com mais de 30 vCPUs, o número máximo aumenta para `250`. Essa imposição substitui outras configurações de `maxPods`, inclusive `maxPodsExpression`. Para obter mais informações sobre como `maxPods` é determinado e como personalizá-lo, consulte [Como maxPods é determinado](choosing-instance-type.md#max-pods-precedence).
+ Um cluster existente do Amazon EKS. Para implantar, consulte [Criar um cluster do Amazon EKS](create-cluster.md).
+ Um perfil do IAM existente para os nós usarem. Para criar uma, consulte [Perfil do IAM em nós do Amazon EKS](create-node-role.md). Se essa função não tiver nenhuma das políticas da VPC CNI, a função separada a seguir será necessária para os pods da VPC CNI.
+ (Opcional, mas recomendado) O complemento plug-in CNI da Amazon VPC para Kubernetes configurado com o seu próprio perfil do IAM que tem a política do IAM necessária anexada a ele. Para obter mais informações, consulte [Configurar o plug-in CNI da Amazon VPC para usar IRSA](cni-iam-role.md).
+ Familiaridade com as considerações listadas em [Escolher um tipo de instância de nó ideal do Amazon EC2](choosing-instance-type.md). Dependendo do tipo de instância que você escolher, pode ser que haja pré-requisitos adicionais para o seu cluster e VPC.
+ Para adicionar um grupo de nós gerenciados do Windows, primeiro é necessário habilitar o suporte do Windows para o cluster. Para obter mais informações, consulte [Implantar nós Windows em clusters EKS](windows-support.md).
É possível criar um grupo de nós gerenciados com uma das seguintes opções:
+ [`eksctl`](#eksctl_create_managed_nodegroup)
+ [Console de gerenciamento da AWS](#console_create_managed_nodegroup)
## `eksctl`
**Criar um grupo de nós gerenciados com o eksctl**
Este procedimento exige a versão `eksctl` `0.215.0` ou superior. É possível verificar a versão com o seguinte comando:
```
eksctl version
```
Para obter instruções sobre como instalar ou atualizar o `eksctl`, consulte [Instalação](https://eksctl.io/installation) na documentação do `eksctl`.
1. (Opcional) Se a política gerenciada do IAM **AmazonEKS\$1CNI\$1Policy** estiver anexada ao [perfil do IAM do nó do Amazon EKS](create-node-role.md), recomendamos atribuí-la a um perfil do IAM associado à conta de serviço do `aws-node` do Kubernetes. Para obter mais informações, consulte [Configurar o plug-in CNI da Amazon VPC para usar IRSA](cni-iam-role.md).
1. Crie o grupo de nós com ou sem o uso de um modelo de execução personalizado. A especificação manual de um modelo de lançamento permite uma maior personalização de um grupo de nós. Por exemplo, pode permitir a implantação de uma AMI personalizada ou fornecer argumentos para o script de `boostrap.sh` em uma AMI otimizada do Amazon EKS. Para obter uma lista completa de todas as opções e padrões disponíveis, insira o comando a seguir.
```
eksctl create nodegroup --help
```
No comando a seguir, substitua *my-cluster* pelo nome do seu cluster e *my-mng* pelo nome do seu grupo de nós. O nome do grupo de nós não pode exceder 63 caracteres. Deve começar com uma letra ou um dígito, mas pode incluir hifens e sublinhados para os demais caracteres.
**Importante**
Se você não usar um modelo de execução personalizado ao criar um grupo de nós gerenciados, não use um superiormente para o grupo de nós. Se você não especificou um modelo de execução personalizado, o sistema gerará automaticamente um modelo de execução que não é recomendável alterar manualmente. Modificar manualmente esse modelo de execução gerado poderá causar erros automaticamente.
**Sem um modelo de inicialização**
O `eksctl` cria um modelo de inicialização padrão do Amazon EC2 na sua conta e implanta o grupo de nós usando um modelo de inicialização que ele criou baseado nas opções que você especifica. Antes de especificar um valor para `--node-type`, consulte [Escolher um tipo de instância de nó do Amazon EC2 ideal](choosing-instance-type.md).
Substitua *ami-family* por uma palavra-chave permitida. Para obter mais informações, consulte [Setting the node AMI Family](https://eksctl.io/usage/custom-ami-support/#setting-the-node-ami-family) (Configurar a família de AMIs de nós) na documentação do `eksctl`. Substitua *my-key* pelo nome do seu par de chaves ou chave pública do Amazon EC2. Essa chave é usada para SSH em seus nós depois que eles forem iniciados.
**nota**
No Windows, esse comando não habilita o SSH. Em vez disso, ele associa seu par de chaves do Amazon EC2 à instância e permite que você faça RDP na instância.
Se ainda não tiver um par de chaves do Amazon EC2, será possível criar um no Console de gerenciamento da AWS. Para obter mais informações sobre o Linux, consulte [Amazon EC2 key pairs and Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) no *Guia do usuário do Amazon EC2*. Para obter informações sobre o Windows, consulte [Amazon EC2 key pairs and Windows instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) no *Guia do usuário do Amazon EC2*.
Recomendamos bloquear o acesso dos pods ao IMDS se as seguintes condições a forem verdadeiras:
+ Você planeja atribuir perfis do IAM a todas as suas contas de serviço do Kubernetes para que os pods tenham apenas as permissões mínimas de que precisam.
+ Nenhum pod no cluster exige acesso ao serviço de metadados de instância (IMDS) do Amazon EC2 por outros motivos, como recuperação da região atual da AWS.
Para obter mais informações, consulte [Restringir o acesso ao perfil da instância atribuído ao nó de processamento](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).
Se você quiser bloquear o acesso do pod ao IMDS, adicione a opção `--disable-pod-imds` ao comando a seguir.
```
eksctl create nodegroup \
--cluster my-cluster \
--region region-code \
--name my-mng \
--node-ami-family ami-family \
--node-type m5.large \
--nodes 3 \
--nodes-min 2 \
--nodes-max 4 \
--ssh-access \
--ssh-public-key my-key
```
As instâncias podem, opcionalmente, atribuir um número significativamente maior de endereços IP aos pods, atribuir endereços IP aos pods de um bloco CIDR diferente do da instância e ser implantadas em um cluster sem acesso à internet. Para obter mais informações, consulte [Atribuir mais endereços IP aos nós do Amazon EKS com prefixos](cni-increase-ip-addresses.md), [Implementar pods em sub-redes alternativas com rede personalizada](cni-custom-network.md), e consulte [Implementar clusters privados com acesso limitado à internet](private-clusters.md) para obter opções adicionais a serem incluídas no comando anterior.
Os grupos de nós gerenciados calculam e aplicam um único valor para o número máximo de pods que podem ser executados em cada nó do grupo de nós, com base no tipo de instância. Se você criar um grupo de nós com diferentes tipos de instância, o menor valor calculado em todos os tipos de instância será aplicado como o número máximo de pods que podem ser executados em cada tipo de instância no grupo de nós. Grupos de nós gerenciados calculam o valor usando o script referenciado em .
**Com um modelo de inicialização**
O modelo de lançamento já deve existir e deve atender aos requisitos especificados em [Fundamentos da configuração do modelo de lançamento](launch-templates.md#launch-template-basics). Recomendamos bloquear o acesso dos pods ao IMDS se as seguintes condições a forem verdadeiras:
+ Você planeja atribuir perfis do IAM a todas as suas contas de serviço do Kubernetes para que os pods tenham apenas as permissões mínimas de que precisam.
+ Nenhum pod no cluster exige acesso ao serviço de metadados de instância (IMDS) do Amazon EC2 por outros motivos, como recuperação da região atual da AWS.
Para obter mais informações, consulte [Restringir o acesso ao perfil da instância atribuído ao nó de processamento](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).
Se você quiser bloquear o acesso do pod ao IMDS, especifique as configurações necessárias no modelo de execução.
1. Copie o conteúdo a seguir para o seu dispositivo. Substitua os valores de exemplo e execute o comando modificado para criar o arquivo `eks-nodegroup.yaml`. Várias configurações que você especifica ao implantar sem um modelo de execução são movidas para o modelo de execução. Se você não especificar a `version`, a versão padrão do modelo será usada.
```
cat >eks-nodegroup.yaml <
**Crie um grupo de nós gerenciados usando o endereço Console de gerenciamento da AWS **
1. Aguarde até que o status do cluster seja exibido como `ACTIVE`. Não é possível criar um grupo de nós gerenciados para um cluster que ainda não esteja `ACTIVE`.
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Escolha o nome do cluster em que você deseja criar um grupo de nós gerenciados.
1. Selecione a guia **Compute** (Computação).
1. Escolha **Add Node Group** (Adicionar grupo de nós).
1. Na página **Configure node group (Configurar o grupo de nós)** preencha os parâmetros adequadamente e escolha **Next (Próximo)**.
+ **Name** (Nome) – Insira um nome exclusivo para o grupo de nós gerenciados. O nome do grupo de nós não pode exceder 63 caracteres. Deve começar com uma letra ou um dígito, mas pode incluir hifens e sublinhados para os demais caracteres.
+ **Node IAM role** (Perfil do IAM do nó): escolha a função da instância do nó a ser usada com o grupo de nós. Para obter mais informações, consulte [Perfil do IAM em nós do Amazon EKS](create-node-role.md).
**Importante**
Não é possível usar a mesma função usada para criar clusters.
Recomendamos usar um perfil que não esteja em uso atualmente por um grupo de nós autogerenciados. Caso contrário, planeje usar com um novo grupo de nós autogerenciados. Para obter mais informações, consulte [Excluir um grupo de nós gerenciados do seu cluster](delete-managed-node-group.md).
+ **Usar**: (opcional) escolha se deseja usar um modelo de execução existente. Selecione um **Nome de modelo de inicialização**. Depois, selecione **Launch template version** (Versão do modelo de inicialização). Se você não selecionar uma versão, o Amazon EKS usará a versão padrão do modelo. Os modelos de execução permitem uma maior personalização do grupo de nós, como, por exemplo, que você implante uma AMI personalizada, atribua um número significativamente maior de endereços IP a pods, atribua endereços IP a pods de um bloco CIDR diferente do da instância e implante nós em um cluster sem acesso à internet de saída. Para obter mais informações, consulte [Atribuir mais endereços IP aos nós do Amazon EKS com prefixos](cni-increase-ip-addresses.md), [Implementar pods em sub-redes alternativas com rede personalizada](cni-custom-network.md) e [Implementar clusters privados com acesso limitado à internet](private-clusters.md).
O modelo de inicialização deve atender aos requisitos em [Personalizar nós gerenciados com modelos de inicialização](launch-templates.md). Se você não usar seu próprio modelo de execução, a API do Amazon EKS criará um modelo de execução padrão do Amazon EC2 em sua conta e implantará o grupo de nós usando o modelo de execução padrão.
Se você implementar [perfis do IAM para contas de serviço](iam-roles-for-service-accounts.md), atribua as permissões necessárias diretamente a todos os pods que necessitam de acesso aos serviços da AWS, e nenhum pod em seu cluster requisitará acesso ao IMDS por outros motivos, como recuperar a região atual da AWS. Você também poderá desabilitar o acesso ao IMDS para pods que não usam redes de host em um modelo de execução. Para obter mais informações, consulte [Restringir o acesso ao perfil da instância atribuído ao nó de processamento](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).
+ **Rótulos do Kubernetes** – (Opcional) você pode optar por aplicar rótulos do Kubernetes aos nós no grupo de nós gerenciados.
+ **Taints do Kubernetes**: (opcional) você pode optar por aplicar taints do Kubernetes aos nós do seu grupo de nós gerenciados. As opções disponíveis naAs opções disponíveis no menu **Effect** (Efeito) são ` NoSchedule `, ` NoExecute ` e ` PreferNoSchedule `. Para obter mais informações, consulte [Receita: evitar que pods sejam agendados em nós específicos](node-taints-managed-node-groups.md).
+ **Etiquetas** – (Opcional) você pode optar por aplicar etiquetas ao grupo de nós gerenciados pelo Amazon EKS. Essas etiquetas não se propagam para outros recursos no grupo de nós, como instâncias ou grupos do Auto Scaling. Para obter mais informações, consulte [Organizar recursos do Amazon EKS com tags](eks-using-tags.md).
1. Na página **Set compute and scaling configuration** (Definir configuração de escalabilidade e computação), preencha os parâmetros adequadamente e escolha **Next** (Próximo).
+ **Tipo de AMI**: selecione um tipo de AMI. Se estiver implementando instâncias Arm, certifique-se de analisar as considerações em [AMIs Arm do Amazon Linux otimizadas do Amazon EKS](eks-optimized-ami.md#arm-ami) antes de implementar.
Se você especificou um modelo de inicialização na página anterior e especificou nele uma AMI, não poderá selecionar um valor. O valor do modelo é exibido. A AMI especificada no modelo deve atender aos requisitos em [Especificando uma AMI](launch-templates.md#launch-template-custom-ami).
+ **Tipo de capacidade** – Selecione um tipo de capacidade. Para obter mais informações sobre a escolha de um tipo de capacidade, consulte [Tipos de capacidade do grupo de nós gerenciados](managed-node-groups.md#managed-node-group-capacity-types). Não é possível misturar diferentes tipos de capacidade dentro do mesmo grupo de nós. Se você quiser usar os dois tipos de capacidade, crie grupos de nós separados, cada um com seus próprios tipos de capacidade e instância. Consulte [Reserva de GPUs para grupos de nós gerenciados](https://docs.aws.amazon.com/eks/latest/userguide/capacity-blocks-mng.html) para obter informações sobre provisionamento e o dimensionamento de nós de processamento acelerados por GPU.
+ **Tipos de instância**: por padrão, um ou mais tipos de instância são especificados. Para remover um tipo de instância padrão, selecione a caixa de seleção `X` no lado direito do tipo de instância. Escolha o tipo de instância a ser usado no grupo de nós gerenciados. Para obter mais informações, consulte [Escolher um tipo de instância de nó do Amazon EC2 ideal](choosing-instance-type.md).
O console exibe um conjunto de tipos de instância comumente usados. Se você precisar criar um grupo de nós gerenciados com um tipo de instância que não é exibido, use `eksctl`, a CLI AWS, AWS CloudFormation ou um SDK para criar o grupo de nós. Se você especificou um modelo de execução na página anterior, não será possível selecionar um valor, porque o tipo de instância deve ser especificado no modelo de execução. O valor do modelo de execução é exibido. Se você selecionou **Spot** para o **tipo de capacidade**, recomendamos especificar vários tipos de instância para melhorar a disponibilidade.
+ **Tamanho do disco**: insira o tamanho do disco (em GiB) a ser usado para o volume raiz do nó.
Se você especificou um modelo de execução na página anterior, não será possível selecionar um valor, porque ele deverá ser especificado no modelo de execução.
+ **Tamanho desejado** – Especifique o número atual de nós que o grupo de nós gerenciados deverá manter na inicialização.
**nota**
O Amazon EKS não reduz nem aumenta automaticamente a escala na horizontal do grupo de nós. No entanto, você pode configurar o Cluster Autoscaler do Kubernetes para fazer isso por você. Para obter mais informações, consulte [Autoscaler do cluster na AWS](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md).
+ **Tamanho mínimo** – Especifique o número mínimo de nós para o qual o grupo de nós gerenciados pode ser reduzido.
+ **Tamanho máximo** – Especifique o número máximo de nós para o qual o grupo de nós gerenciados pode ser expandido.
+ **Configuração da atualização de grupo de nós** – (Opcional) É possível selecionar o número ou porcentagem de nós a serem atualizados em paralelo. Esses nós estarão indisponíveis durante a atualização. Para o **Máximo disponível**, selecione uma das seguintes opções e especifique um **Valor**:
+ **Number** (Número): selecione e especifique o número de nós em seu grupo de nós que podem ser atualizados em paralelo.
+ **Percentage** (Porcentagem): selecione e especifique a porcentagem de nós em seu grupo de nós que podem ser atualizados em paralelo. Isso será útil se você tiver um grande número de nós em seu grupo de nós.
+ **Configuração de reparo automático de nós**: (opcional) se você ativar a caixa de seleção **Habilitar reparo automático de nós**, o Amazon EKS substituirá automaticamente os nós quando ocorrerem problemas. Para obter mais informações, consulte [Detectar problemas de integridade dos nós e habilitar o reparo automático dos nós](node-health.md).
1. Na página **Specify networking** (Especificar a rede), preencha os parâmetros conforme necessário e, em seguida, escolha **Next** (Próximo).
+ **Sub-redes** – Escolha as sub-redes nas quais iniciar os nós gerenciados.
**Importante**
Se estiver executando uma aplicação com estado em várias zonas de disponibilidade com suporte de volumes do Amazon EBS e usando o [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) do Kubernetes, será necessário configurar vários grupos de nós, cada um com escopo de uma única zona de disponibilidade. Além disso, será necessário ativar o recurso `--balance-similar-node-groups`.
**Importante**
Se você escolher uma sub-rede pública e o cluster tiver somente o endpoint do servidor de API público habilitado, a sub-rede deverá ter o `MapPublicIPOnLaunch` definido como `true` para que as instâncias ingressem com êxito em um cluster. Se a sub-rede tiver sido criada usando `eksctl` ou os [modelos do Amazon EKS vended AWS CloudFormation](creating-a-vpc.md) em ou após 26 de março de 2020, essa configuração já estará definida como `true`. Se as sub-redes foram criadas com `eksctl` ou com os modelos AWS CloudFormation antes de 26 de março de 2020, você precisará alterar a configuração manualmente. Para obter mais informações, consulte [Modificar o atributo de endereçamento IPv4 público para a sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip).
Se você usar um modelo de execução e especificar várias interfaces de rede, o Amazon EC2 não atribuirá automaticamente um endereço `IPv4` público, mesmo que o `MapPublicIpOnLaunch` seja definido como `true`. Para que os nós ingressem no cluster nesse cenário, é necessário habilitar o endpoint do servidor de API privado do cluster ou iniciar nós em uma sub-rede privada com acesso de saída à Internet fornecido por meio de um método alternativo, como um Gateway NAT. Para obter mais informações, consulte [Endereçamento de IP de instâncias do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html), no *Guia do usuário do Amazon EC2*.
+ **Configurar o acesso SSH aos nós** (opcional). Habilitar o SSH permite que você se conecte às suas instâncias e reúna informações de diagnóstico quando houver problemas. É altamente recomendado habilitar o acesso remoto ao criar o grupo de nós. Não será possível habilitar o acesso remoto depois que o grupo estiver criado.
Se você optou por usar um modelo de execução, essa opção não será exibida. Para habilitar o acesso remoto aos nós, especifique um par de chaves no modelo de execução e verifique se a porta adequada está aberta aos nós nos grupos de segurança especificados no modelo de execução. Para obter mais informações, consulte [Usar grupos de segurança personalizados](launch-templates.md#launch-template-security-groups).
**nota**
No Windows, esse comando não habilita o SSH. Em vez disso, ele associa seu par de chaves do Amazon EC2 à instância e permite que você faça RDP na instância.
+ Para o **par de chaves SSH** (Opcional), escolha uma chave SSH do Amazon EC2 para usar. Para obter mais informações sobre o Linux, consulte [Amazon EC2 key pairs and Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) no *Guia do usuário do Amazon EC2*. Para obter informações sobre o Windows, consulte [Amazon EC2 key pairs and Windows instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) no *Guia do usuário do Amazon EC2*. Se você optar por usar um modelo de execução, não será possível selecionar um. Quando uma chave SSH do Amazon EC2 é fornecida para grupos de nós que usam AMIs Bottlerocket, o contêiner administrativo também é habilitado. Para obter mais informações, consulte [Contêiner administrador](https://github.com/bottlerocket-os/bottlerocket#admin-container) no GitHub.
+ Para **Allow SSH remote access from** (Permitir o acesso remoto de SSH) se você quiser limitar o acesso a instâncias específicas, selecione os grupos de segurança associados a essas instâncias. Se você não selecionar grupos de segurança específicos, o acesso SSH será permitido de qualquer lugar na Internet (`0.0.0.0/0`).
1. Na página **Review and create (Revisar e criar)**, reveja a configuração do grupo de nós gerenciados e escolha **Create (Criar)**.
Se os nós não conseguirem se juntar ao cluster, consulte [Falha nos nós ao ingressar no cluster](troubleshooting.md#worker-node-fail) no capítulo Solução de problemas.
1. Observe o status de seus nós e aguarde até que eles atinjam o status `Ready`.
```
kubectl get nodes --watch
```
1. (Somente nós de GPU) Caso escolha um tipo de instância de GPU e a AMI acelerada otimizada para Amazon EKS, será necessário aplicar o [plug-in de dispositivo NVIDIA para Kubernetes](https://github.com/NVIDIA/k8s-device-plugin) como um DaemonSet no cluster. Substitua *vX.X.X* pela versão desejada [do NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin/releases) antes de executar o seguinte comando.
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/deployments/static/nvidia-device-plugin.yml
```
## Instalar complementos do Kubernetes
Agora que você tem um cluster do Amazon EKS com nós, já poderá iniciar a instalação dos complementos do Kubernetes e implantar as aplicações no cluster. Os seguintes tópicos de documentação ajudam a estender a funcionalidade do seu cluster:
+ A [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que criou o cluster é a única entidade que pode fazer chamadas para o servidor de API do Kubernetes com o `kubectl` ou o Console de gerenciamento da AWS. Se quiser que outras entidades principais do IAM tenham acesso ao cluster, será necessário adicioná-los. Para obter mais informações, consulte [Conceder aos usuários e perfis do IAM acesso às APIs do Kubernetes](grant-k8s-access.md) e [Permissões obrigatórias](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
+ Recomendamos bloquear o acesso dos pods ao IMDS se as seguintes condições a forem verdadeiras:
+ Você planeja atribuir perfis do IAM a todas as suas contas de serviço do Kubernetes para que os pods tenham apenas as permissões mínimas de que precisam.
+ Nenhum pod no cluster exige acesso ao serviço de metadados de instância (IMDS) do Amazon EC2 por outros motivos, como recuperação da região atual da AWS.
Para obter mais informações, consulte [Restringir o acesso ao perfil de instância atribuído ao nó de processamento](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).
+ Configure o [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) do Kubernetes para ajustar automaticamente o número de nós nos grupos de nós.
+ Implante uma [aplicação de exemplo](sample-deployment.md) no cluster.
+ [Organize e monitore os recursos do cluster](eks-managing.md) com ferramentas importantes para gerenciar seu cluster.
# Atualizar um grupo de nós gerenciados para seu cluster
Quando você inicia uma atualização de grupo de nós gerenciados, o Amazon EKS atualiza automaticamente os nós para você, concluindo as etapas listadas em [Entenda cada fase das atualizações de nós](managed-node-update-behavior.md). Se você estiver usando uma AMI otimizada do Amazon EKS, o Amazon EKS aplica automaticamente os patches de segurança mais recentes e as atualizações do sistema operacional aos nós como parte da versão mais recente da AMI.
Existem vários cenários nos quais é útil atualizar a versão ou a configuração do grupo de nós gerenciados do Amazon EKS:
+ Você atualizou a versão do Kubernetes para seu cluster do Amazon EKS e quer atualizar os nós para usar a mesma versão do Kubernetes.
+ Uma nova versão da AMI está disponível para o grupo de nós gerenciados. Para obter mais informações sobre as versões da AMI, consulte estas seções:
+ [Recuperar informações da versão da AMI do Amazon Linux](eks-linux-ami-versions.md)
+ [Criar nós com AMIs otimizadas do Bottlerocket](eks-optimized-ami-bottlerocket.md)
+ [Recuperar informações de versões de AMIs do Windows](eks-ami-versions-windows.md)
+ Você deseja ajustar a contagem mínima, máxima ou desejada das instâncias no seu grupo de nós gerenciados.
+ Você deseja adicionar ou remover os rótulos do Kubernetes das instâncias no seu grupo de nós gerenciados.
+ Você deseja adicionar ou remover as tags da AWS do seu grupo de nós gerenciados.
+ Você precisa implantar uma nova versão de um modelo de execução com alterações de configuração, como uma AMI personalizada atualizada.
+ Você implantou a versão `1.9.0` ou mais recente do complemento CNI da Amazon VPC, habilitou o complemento para delegação de prefixos e deseja novas instâncias do AWS Nitro System em um grupo de nós para ser compatível com um número significativamente maior de pods. Para obter mais informações, consulte [Atribuir mais endereços IP aos nós do Amazon EKS com prefixos](cni-increase-ip-addresses.md).
+ Você habilitou a delegação de prefixos IP para nós do Windows e deseja que novas instâncias do AWS Nitro System em um grupo de nós sejam compatíveis um número significativamente maior de pods. Para obter mais informações, consulte [Atribuir mais endereços IP aos nós do Amazon EKS com prefixos](cni-increase-ip-addresses.md).
Se houver uma nova versão da AMI mais recente do que a versão do Kubernetes do grupo de nós gerenciado, você poderá atualizar esta para usar a nova versão da AMI. Da mesma forma, se o cluster estiver executando uma versão mais recente do Kubernetes do que o grupo de nós, você poderá atualizar o grupo de nós para usar a versão mais recente da AMI correspondente à versão do Kubernetes do cluster.
Quando um nó em um grupo de nós gerenciados é encerrado por causa de uma operação de escalabilidade ou atualização, os pods nesse nó são drenados primeiro. Para obter mais informações, consulte [Entenda cada fase das atualizações de nós](managed-node-update-behavior.md).
## Atualizar uma versão do grupo de nós
Você pode atualizar a versão de um grupo de nós com uma das seguintes opções:
+ [`eksctl`](#eksctl_update_managed_nodegroup)
+ [Console de gerenciamento da AWS](#console_update_managed_nodegroup)
A versão para a qual você atualiza não pode ser superior à versão do ambiente de gerenciamento.
## `eksctl`
**Atualizar um grupo de nós gerenciados usando o `eksctl` **
Atualize um grupo de nós gerenciados para a versão mais recente da AMI da mesma versão do Kubernetes atualmente implantada nos nós com o comando a seguir. Substitua cada *valor de exemplo* por seus próprios valores.
```
eksctl upgrade nodegroup \
--name=node-group-name \
--cluster=my-cluster \
--region=region-code
```
**nota**
Se você estiver atualizando um grupo de nós implantado com um modelo de execução para uma nova versão do modelo de execução, adicione o `--launch-template-version version-number ` ao comando anterior. O modelo de inicialização deve atender aos requisitos descritos em [Personalizar nós gerenciados com modelos de inicialização](launch-templates.md). Se o modelo de inicialização incluir uma AMI personalizada, a AMI deverá atender aos requisitos em [Especificando uma AMI](launch-templates.md#launch-template-custom-ami). Quando você atualiza o grupo de nós para uma versão mais recente do modelo de execução, todos os nós são reciclados para corresponder à nova configuração da versão do modelo de execução especificado.
Não é possível atualizar diretamente um grupo de nós implantado sem um modelo de execução para uma nova versão do modelo de execução. Em vez disso, você deve implantar um novo grupo de nós usando o modelo de execução para atualizar o grupo de nós para uma nova versão de modelo de execução.
Você pode atualizar um grupo de nós para a mesma versão que a versão do Kubernetes do ambiente de gerenciamento. Por exemplo, se tiver um cluster executando o Kubernetes `1.35`, você poderá atualizar os nós que estão atualmente executando o Kubernetes `1.34` para a versão `1.35` com o comando a seguir.
```
eksctl upgrade nodegroup \
--name=node-group-name \
--cluster=my-cluster \
--region=region-code \
--kubernetes-version=1.35
```
## Console de gerenciamento da AWS
**Atualizar um grupo de nós gerenciados usando o Console de gerenciamento da AWS **
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Escolha o cluster que contém o grupo de nós a ser atualizado.
1. Se pelo menos um grupo de nós tiver uma atualização disponível, uma caixa será exibida na parte superior da página notificando você sobre a atualização disponível. Se você selecionar a guia **Compute** (Computação), verá a opção **Update now** (Atualizar agora) na coluna **AMI release version** (Versão de AMI) na tabela **Node Groups** (Grupos de nós) para o grupo de nós que tem atualizações disponíveis. Para atualizar o grupo de nós, selecione **Update now** (Atualizar agora).
Você não verá uma notificação para grupos de nós que foram implantados com uma AMI personalizada. Se os nós forem implantados com uma AMI personalizada, conclua as etapas a seguir para implantar uma nova AMI personalizada atualizada.
1. Crie uma nova versão da AMI.
1. Crie uma nova versão do modelo de execução com o novo ID da AMI.
1. Atualize os nós para a nova versão do modelo de execução.
1. Na caixa de diálogo **Update node group version** (Atualizar versão do grupo de nós), ative ou desative as seguintes opções:
+ **Update Node Group version** (Atualizar versão do grupo de nós): essa opção não estará disponível se você tiver implantado uma AMI personalizada ou se a AMI otimizada do Amazon EKS estiver atualmente na versão mais recente do cluster.
+ **Change launch template version** (Alterar versão do modelo de inicialização): essa opção não estará disponível se o grupo de nós for implantado sem um modelo de inicialização personalizado. Você só pode atualizar a versão do modelo de execução para um grupo de nós que tenha sido implantado com um modelo de execução personalizado. Selecione a **Launch template version** (Versão do modelo de inicialização) para a qual você deseja atualizar o grupo de nós. Se o grupo de nós estiver configurado com uma AMI personalizada, a versão selecionada também deverá especificar uma AMI. Quando você atualiza para uma versão mais recente do modelo de execução, todos os nós são reciclados para corresponder à nova configuração da versão do modelo de execução especificada.
1. Em **Update strategy** (Estratégia de atualização), selecione uma das seguintes opções:
+ **Atualização contínua**: esta opção respeita os orçamentos de interrupções de pods no cluster. As atualizações falharão se houver um problema de orçamento de interrupções de pods que faça com que o Amazon EKS não consiga drenar corretamente os pods que estão em execução no grupo de nós.
+ **Forçar atualização**: esta opção não respeita os orçamentos de interrupções de pods. As atualizações ocorrem independentemente de problemas de orçamento de interrupções de pods, forçando a reinicialização dos nós.
1. Selecione **Atualizar**.
## Editar uma configuração do grupo de nós
Você pode modificar algumas configurações de um grupo de nós gerenciados.
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Escolha o cluster que contém o grupo de nós a ser editado.
1. Selecione a guia **Compute** (Computação).
1. Selecione o grupo de nós a ser editado e escolha **Edit** (Editar).
1. (Opcional) Na página **Edit node group** (Editar grupo de nós) faça o seguinte:
1. Edite a **configuração de escalonamento do grupo de nós**.
+ **Tamanho desejado** – Especifique o número atual de nós que o grupo de nós gerenciados deve manter.
+ **Tamanho mínimo** – Especifique o número mínimo de nós para o qual o grupo de nós gerenciados pode ser reduzido.
+ **Tamanho máximo** – Especifique o número máximo de nós para o qual o grupo de nós gerenciados pode ser expandido. Para obter o número máximo de nós permitidos em um grupo de nós, consulte [Visualizar e gerenciar as cotas de serviço do Amazon EKS e do Fargate](service-quotas.md).
1. (Opcional) Adicione ou remova **rótulos do Kubernetes** dos nós no grupo de nós. Os rótulos mostrados aqui são apenas aqueles que você aplicou com o Amazon EKS. Outros rótulos que não são exibidos aqui podem existir nos nós.
1. (Opcional) Adicione ou remova **taints do Kubernetes** dos nós no grupo de nós. As taints adicionadas podem ter o efeito de ` NoSchedule `, ` NoExecute ` ou ` PreferNoSchedule `. Para obter mais informações, consulte [Receita: evitar que pods sejam agendados em nós específicos](node-taints-managed-node-groups.md).
1. (Opcional) Adicione ou remova **tags** do recurso de grupo de nós. Essas etiquetas são aplicadas somente ao grupo de nós do Amazon EKS. Não são propagadas em outros recursos como sub-redes ou instâncias do Amazon EC2 no grupo de nós.
1. (Opcional) Edite a **configuração da atualização do grupo de nós**. Selecione o **número** ou a **porcentagem**.
+ **Number** (Número): selecione e especifique o número de nós em seu grupo de nós que podem ser atualizados em paralelo. Esses nós estarão indisponíveis durante a atualização.
+ **Percentage** (Porcentagem): selecione e especifique a porcentagem de nós em seu grupo de nós que podem ser atualizados em paralelo. Esses nós estarão indisponíveis durante a atualização. Isso será útil se houver muitos nós em seu grupo de nós.
1. Quando terminar de editar, escolha **Salvar alterações**.
**Importante**
Ao atualizar a configuração do grupo de nós, a modificação de [https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html) não respeita os orçamentos de interrupções de pods (PDBs). Ao contrário do processo [de atualização do grupo de nós](managed-node-update-behavior.md) (que drena os nós e respeita os PDBs durante a fase de upgrade), a atualização da configuração de dimensionamento faz com que os nós sejam encerrados imediatamente por meio de uma chamada de redução de escala do Auto Scaling Group (ASG). Isso acontece sem considerar os PDBs, independentemente do tamanho para o qual você está reduzindo a escala. Isso significa que, quando você reduz o `desiredSize` de um grupo de nós gerenciados do Amazon EKS, os pods são removidos assim que os nós são encerrados, sem honrar nenhum PDB.
# Entenda cada fase das atualizações de nós
A estratégia de atualização do nó de processamento gerenciado do Amazon EKS tem quatro fases diferentes descritas nas seções a seguir.
## Fase de configuração
A fase de configuração contém estas etapas:
1. Ele cria uma nova versão do modelo de execução do Amazon EC2 para o grupo do Auto Scaling associado ao grupo de nós. A nova versão do modelo de inicialização usa a AMI de destino ou uma versão do modelo de inicialização personalizado para a atualização.
1. Ele atualiza o grupo do Auto Scaling para usar a versão mais recente do modelo de execução.
1. Ele determina a quantidade máxima de nós a serem atualizados em paralelo usando a propriedade `updateConfig` do grupo de nós. O máximo indisponível tem uma cota de 100 nós. O valor padrão é um nó. Para obter mais informações, consulte a propriedade [updateConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateNodegroupConfig.html#API_UpdateNodegroupConfig_RequestSyntax) na *Referência da API do Amazon EKS*.
## Fase de aumento de escala vertical
Na atualização de nós em um grupo de nós gerenciados, os nós atualizados são iniciados na mesma zona de disponibilidade daqueles que estão sendo atualizados. Para garantir esse posicionamento, usamos o rebalanceamento de zonas de disponibilidade do Amazon EC2. Para obter mais informações, consulte [Rebalanceamento de zonas de disponibilidade](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage) no * Guia do usuário do Amazon EC2 Auto Scaling*. Para atender a esse requisito, é possível a inicialização de até duas instâncias por zona de disponibilidade no grupo de nós gerenciados.
A fase de aumento de escala vertical tem estas etapas:
1. Ele aumenta o tamanho máximo do grupo do Auto Scaling e o tamanho desejado pelo que for maior:
+ Até duas vezes o número de zonas de disponibilidade em que o grupo do Auto Scaling está implantado.
+ O máximo indisponível de atualização.
Por exemplo, se o grupo de nós tiver cinco zonas de disponibilidade e `maxUnavailable` como um, o processo de atualização poderá iniciar no máximo dez nós. No entanto, se `maxUnavailable` for 20 (ou qualquer valor superior a 10), o processo iniciaria 20 novos nós.
1. Depois de escalar o grupo do Auto Scaling, ele verifica se os nós que usam a configuração mais recente estão presentes no grupo de nós. Essa etapa só é concluída corretamente quando atende a estes critérios:
+ Pelo menos um novo nó é iniciado em todas as zonas de disponibilidade em que o nó existe.
+ Cada novo nó deve estar no estado `Ready`.
+ Os novos nós devem ter rótulos aplicados ao Amazon EKS.
São os rótulos do Amazon EKS aplicados aos nós de processamento em um grupo de nós regulares:
+ `eks.amazonaws.com/nodegroup-image=$amiName`
+ `eks.amazonaws.com/nodegroup=$nodeGroupName`
São os rótulos do Amazon EKS aplicados aos nós de processamento em um modelo de execução personalizado ou em um grupo de nós da AMI:
+ `eks.amazonaws.com/nodegroup-image=$amiName`
+ `eks.amazonaws.com/nodegroup=$nodeGroupName`
+ `eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId`
+ `eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion`
1. Ele marca os nós como não agendáveis para evitar o agendamento de novos pods. Também rotula os nós com `node.kubernetes.io/exclude-from-external-load-balancers=true` para remover os nós antigos dos balanceadores de carga antes de encerrá-los.
A seguir, estão os motivos conhecidos que causam um erro `NodeCreationFailure` nesta fase:
**Capacidade insuficiente na zona de disponibilidade**
Existe a possibilidade de que a zona de disponibilidade não tenha capacidade dos tipos de instância solicitados. É recomendável configurar vários tipos de instância ao criar um grupo de nós gerenciados.
**Limites de instâncias do EC2 na sua conta**
Pode ser necessário aumentar o número de instâncias do Amazon EC2 que a conta pode executar simultaneamente usando o Service Quotas. Para obter mais informações, consulte [Service Quotas do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) no *Guia do usuário do Amazon Elastic Compute Cloud para instâncias Linux*.
**Dados de usuário personalizados**
Os dados de usuário personalizados às vezes podem interromper o processo de bootstrap. Esse cenário pode fazer com que o `kubelet` não seja iniciado no nó ou com que os nós não recebam os rótulos esperados do Amazon EKS. Para obter mais informações, consulte [Especificar uma AMI](launch-templates.md#launch-template-custom-ami).
**Quaisquer alterações que prejudiquem a integridade ou a prontidão de um nó**
Pressão no disco do nó, pressão na memória e condições semelhantes podem impedir que um nó passe para o estado `Ready`.
**Cada nó deve inicializar em até 15 minutos**
Se algum nó levar mais de 15 minutos para inicializar e ingressar no cluster, isso fará com que a atualização atinja o tempo limite. Este é o runtime total para inicializar um novo nó, calculado desde quando um novo nó é necessário até quando ele se junta ao cluster. Ao atualizar um grupo de nós gerenciados, o contador de tempo começa assim que o tamanho do grupo do Auto Scaling aumenta.
## Fase de atualização
A fase de atualização se comporta de duas maneiras diferentes, dependendo da *estratégia de atualização*. Há duas estratégias de atualização: **padrão** e **mínima**.
Recomendamos a estratégia padrão na maioria dos cenários. Ela cria novos nós antes de encerrar os antigos para que a capacidade disponível seja mantida durante a fase de atualização. A estratégia mínima é útil em cenários em que você está limitado a recursos ou custos, por exemplo, com aceleradores de hardware, como GPUs. Ela encerra os nós antigos antes de criar os novos para que a capacidade total nunca aumente além da quantidade configurada.
A estratégia de atualização *padrão* tem as seguintes etapas:
1. Ela aumenta a quantidade de nós (contagem desejada) no grupo do Auto Scaling, fazendo com que o grupo de nós crie nós adicionais.
1. Ele seleciona aleatoriamente um nó que precisa ser atualizado, até o máximo indisponível configurado para o grupo de nós.
1. Drena os pods do nó. Se os pods não saírem do nó em até 15 minutos e não houver um sinalizador de força, a fase de atualização falhará com um erro `PodEvictionFailure`. Para tal cenário, você pode aplicar o sinalizador de força com a solicitação `update-nodegroup-version` para excluir os pods.
1. Isola o nó após cada pod ser removido e aguarda 60 segundos. Isso é feito para que o controlador de serviço não envie novas solicitações para este nó e remova esse nó da lista de nós ativos.
1. Ele envia uma solicitação de encerramento para o grupo do Auto Scaling do nó isolado.
1. Ele repete as etapas de atualização anteriores até que não haja nós no grupo de nós implantados com a versão anterior do modelo de execução.
A estratégia de atualização *mínima* tem as seguintes etapas:
1. Ele isola todos os nós do grupo de nós no início para que o controlador de serviço não envie novas solicitações para esses nós.
1. Ele seleciona aleatoriamente um nó que precisa ser atualizado, até o máximo indisponível configurado para o grupo de nós.
1. Ele drena os pods dos nós selecionados. Se os pods não saírem do nó em até 15 minutos e não houver um sinalizador de força, a fase de atualização falhará com um erro `PodEvictionFailure`. Para tal cenário, você pode aplicar o sinalizador de força com a solicitação `update-nodegroup-version` para excluir os pods.
1. Depois que cada pod é removido e aguarda 60 segundos, ele envia uma solicitação de encerramento para o grupo do Auto Scaling dos nós selecionados. O grupo do Auto Scaling cria novos nós (o mesmo número de nós selecionados) para substituir a capacidade ausente.
1. Ele repete as etapas de atualização anteriores até que não haja nós no grupo de nós implantados com a versão anterior do modelo de execução.
### Erros `PodEvictionFailure` durante a fase de atualização
A seguir, estão os motivos conhecidos que causam um erro `PodEvictionFailure` nesta fase:
**PDB agressivo**
Um PDB agressivo está definido no pod, ou há vários PDBs apontando para o mesmo pod.
**Implantação que tolera todas as taints**
Depois que todos os pods são removidos, espera-se que o nó fique vazio porque o nó [sofreu taints](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) nas etapas anteriores. Porém, se a implantação tolerar todos os taints, é mais provável que o nó não esteja vazio, causando falha na remoção dos pods.
## Fase de redução de escala vertical
A fase de redução de escala vertical diminui o tamanho máximo do grupo do Auto Scaling e o tamanho desejado para retornar aos valores anteriores ao início da atualização.
Se o fluxo de trabalho Upgrade determinar que o Cluster Autoscaler está aumentando a escala na vertical do grupo de nós durante a fase de redução de escala na vertical do fluxo de trabalho, ele será encerrado imediatamente sem trazer o grupo de nós de volta ao tamanho original.
# Personalizar nós gerenciados com modelos de execução
Para obter o máximo de personalização, é possível implantar nós gerenciados com seu próprio modelo de execução, seguindo as etapas descritas nesta página. O uso de um modelo de execução permite, entre outras funcionalidades, fornecer argumentos de inicialização durante a implantação de um nó (por exemplo, argumentos extras do [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)), atribuir endereços IP aos pods de um bloco CIDR diferente daquele atribuído ao endereço IP do nó, implantar uma AMI ou uma CNI personalizadas com base nos seus requisitos para os nós.
Ao fornecer seu próprio modelo de execução na primeira criação de um grupo de nós gerenciados, você também terá maior flexibilidade posteriormente. Contanto que você implemente um grupo de nós gerenciados com seu próprio modelo de execução, é possível atualizá-lo iterativamente para uma versão diferente do mesmo modelo de execução. Quando você atualiza para o grupo de nós para uma versão mais recente do modelo de execução, todos os nós do grupo são reciclados para corresponder à nova configuração da versão do modelo de execução especificada.
Os grupos de nós gerenciados são sempre implantados com um modelo de execução do grupo do Amazon EC2 Auto Scaling. Quando você não fornece um modelo de execução, a API do Amazon EKS cria um modelo com valores padrão em sua conta automaticamente. No entanto, não recomendamos modificar os modelos de execução gerados automaticamente. Além disso, os grupos de nós existentes que não usarem um modelo de execução personalizado não poderão ser atualizados diretamente. Em vez disso, será necessário criar um novo grupo de nós com um modelo de execução personalizado para fazer isso.
## Conceitos básicos do modelo de execução
É possível criar um modelo de lançamento do Amazon EC2 Auto Scaling com o Console de gerenciamento da AWS, AWS CLI ou um AWS SDK. Para obter mais informações, consulte [Criação de um modelo de execução para um grupo do Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html) no *Guia do usuário do Amazon EC2 Auto Scaling*. Algumas das configurações em um modelo de execução são semelhantes às usadas para a configuração do nó gerenciado. Ao implantar ou atualizar um grupo de nós com um modelo de execução, algumas configurações devem ser especificadas na configuração do grupo de nós ou no modelo de execução. Não especifique uma configuração em ambos os locais. Se uma configuração existir onde não deveria, as operações, como criar ou atualizar um grupo de nós, falharão.
A tabela a seguir lista as configurações proibidas em um modelo de execução. Também são listadas configurações semelhantes, se houver, que são obrigatórias na configuração do grupo de nós gerenciados. As configurações listadas são as configurações que aparecem no console. Eles podem ter nomes semelhantes, mas diferentes, na CLI e no SDK do AWS.
| Modelo de execução – Proibido | Configuração do grupo de nós do Amazon EKS |
| --- | --- |
| **Subnet (Sub-rede)** em **Network interfaces** (Interfaces de rede) (**Adicionar interface de rede**) | **Subnet** (Sub-redes) em **Node Group network configuration** (Configuração de rede do grupo de nós) na página **Specify networking** (Especificar rede) |
| **IAM instance profile** (Perfil de instância do IAM) em **Advanced details** (Detalhes avançados) | **Node IAM Role** (Função do IAM do nó) em **Node Group configuration** (Configuração do grupo de nós) na página **Configure Node Group** (Configurar o grupo de nós) |
| **Shutdown behavior** (Comportamento de desligamento) e **Stop - Hibernate behavior** (Parar - comportamento de hibernação) em **Advanced details** (Detalhes avançados). Reter o padrão **Não incluir na configuração do modelo de execução** para as duas configurações. | Não há equivalente. O Amazon EKS deve controlar o ciclo de vida da instância, não o grupo Auto Scaling. |
A tabela a seguir lista as configurações proibidas em uma configuração de grupo de nós gerenciados. Também lista configurações semelhantes, se houver, que serão necessárias em um modelo de execução. As configurações listadas são as configurações que aparecem no console. Eles podem ter nomes semelhantes na CLI e no SDK do AWS.
| Configuração do grupo de nós do Amazon EKS - Proibidas | Modelo de execução |
| --- | --- |
| (Somente se você tiver especificado uma AMI personalizada em um modelo de execução) Em **Tipo de AMI**, na **Configuração de computação do grupo de nós**, na página **Definir configuração de computação e escalabilidade**, o console exibe **Especificado no modelo de execução** e o ID da AMI especificada. Se **Imagens de aplicações e sistemas operacionais (imagem de máquina da Amazon)** não tiver sido especificado no modelo de execução, será possível selecionar uma AMI na configuração do grupo de nós. | **Application and OS Images (Amazon Machine Image)** [Imagens de aplicações e sistemas operacionais (imagem de máquina da Amazon)] em **Launch template contents** (Conteúdo do modelo de execução): especifique um ID se você tiver um dos seguintes requisitos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/launch-templates.html) |
| **Tamanho do disco** em **Node Group compute configuration** (Configuração de computação do grupo de nós) a página **Set compute and scaling configuration** (Definir a configuração da computação e escalabilidade). Exibe o console **Especificado no modelo de execução**. | **Size** (Tamanho) em **Storage (Volumes)** Armazenamento (Volumes) (**Add New volume**) (Adicionar novo volume). É necessário especificar isso no modelo de execução. |
| **Par de chaves SSH** em **Node Group configuration** (Configuração do grupo de nós) na página **Specify Networking** (Especificar rede) — O console exibe a chave especificada no modelo de execução ou exibe **Not specified in launch template** (Não especificado no modelo de execução). | **Key pair name (Nome do par de chaves)** em **Key pair (login)** (Par de chaves). |
| Não é possível especificar grupos de segurança de origem que tenham permissão de acesso remoto ao usar um modelo de execução. | **Security groups** (Grupos de segurança) em **Network settings** (Configurações de rede) para a instância ou **Security groups** (Grupos de segurança) em **Network interfaces** (Interfaces de rede) (**Add network interface** (Adicionar interface de rede), mas não os dois. Para obter mais informações, consulte [Usar grupos de segurança personalizados](#launch-template-security-groups). |
**nota**
Se você implantar um grupo de nós usando um modelo de execução, especifique zero ou um **tipo de instância** em **Launch template contents** (Iniciar o conteúdo do modelo) em um modelo de execução. Se preferir, você pode especificar de 0 a 20 tipos de instância em **Instance types** (Tipos de instância) na página **Set compute and scaling configuration** (Definir configuração de computação e escalabilidade) no console. Ou você pode fazer isso com outras ferramentas que utilizam a API do Amazon EKS. Se você especificar um tipo de instância em um modelo de execução e usar esse modelo para implantar o grupo de nós, não será possível especificar nenhum tipo de instância no console ou usar outras ferramentas que usam a API do Amazon EKS. Se você não especificar um tipo de instância em um modelo de execução, no console ou usando outras ferramentas que usem a API do Amazon EKS, será usado o tipo de instância `t3.medium`. Se o grupo de nós estiver usando o tipo de capacidade spot, recomendamos especificar vários tipos de instância usando o console. Para obter mais informações, consulte [Tipos de capacidade do grupo de nós gerenciados](managed-node-groups.md#managed-node-group-capacity-types).
Se algum contêiner implantado no grupo de nós usar o Serviço de Metadados de Instância Versão 2, defina a propriedade **Metadata response hop limit** (Limite de salto de resposta) como `2` no modelo de execução. Para obter mais informações, consulte [Metadados da instância e dados do usuário](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) no *Manual do usuário do Amazon EC2*.
Os modelos de execução não são compatíveis com o recurso `InstanceRequirements` que permite a seleção flexível do tipo de instância.
## Etiquetar instâncias do Amazon EC2
É possível usar o parâmetro `TagSpecification` de um modelo de execução para especificar quais etiquetas serão aplicadas às instâncias do Amazon EC2 em seu grupo de nós. A entidade do IAM que chama o método das APIs `CreateNodegroup` ou `UpdateNodegroupVersion` devem ter permissões para `ec2:RunInstances` e `ec2:CreateTags`, e as etiquetas devem ser adicionadas ao modelo de execução.
## Usar grupos de segurança personalizados
É possível usar um modelo de execução para especificar os [grupos de segurança](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) do Amazon EC2 a serem aplicados às instâncias do grupo de nós. Isso pode ser no parâmetro dos grupos de segurança do nível de instância ou como parte dos parâmetros de configuração da interface de rede. Porém, não é possível criar um modelo de execução que especifique o nível da instância e os grupos de segurança da interface de rede. Considere as seguintes condições que se aplicam ao uso de grupos de segurança personalizados com grupos de nós gerenciados:
+ Quando o Console de gerenciamento da AWS é usado, o Amazon EKS permite modelos de execução somente com uma única especificação de interface de rede.
+ Por padrão, o Amazon EKS aplica o [Grupo de segurança de cluster](sec-group-reqs.md)para as instâncias no grupo de nós, a fim de facilitar a comunicação entre os nós e o ambiente de gerenciamento. Se você especificar grupos de segurança personalizados no modelo de execução usando uma das opções mencionadas anteriormente, o Amazon EKS não adicionará o grupo de segurança do cluster. Então, é necessário garantir que as regras de entrada e saída dos grupos de segurança permitam a comunicação com o endpoint do cluster. Se as regras do grupo de segurança estiverem incorretas, os nós de processamento não poderão ingressar no cluster. Para obter mais informações sobre regras do grupo de segurança, consulte [Exibir os requisitos para grupos de segurança do Amazon EKS em clusters](sec-group-reqs.md).
+ Se você precisar de acesso SSH às instâncias no grupo de nós, inclua um grupo de segurança que permita esse acesso.
## Dados do usuário do Amazon EC2
O modelo de execução contém uma seção para dados de usuário personalizados. É possível especificar configurações para o grupo de nós desta seção sem criar AMIs personalizadas individuais manualmente. Para obter mais informações sobre as configurações disponíveis para o Bottlerocket, consulte [Usar dados de usuário](https://github.com/bottlerocket-os/bottlerocket#using-user-data) no GitHub.
É possível fornecer dados de usuário do Amazon EC2 no modelo de execução usando `cloud-init` na inicialização das instâncias. Para obter mais informações, consulte a [documentação de cloud-init](https://cloudinit.readthedocs.io/en/latest/index.html). Os dados de usuário podem ser usados para executar operações de configuração comuns. Isso inclui as seguintes operações:
+ [Incluindo usuários ou grupos](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups)
+ [Instalar pacotes](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages)
Os dados de usuário do Amazon EC2 em modelo de execução que são usados com grupos de nós gerenciados devem estar no formato [arquivo MIME de várias partes](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive) para AMIs do Amazon Linux e em formato TOML para AMIs do Bottlerocket. Isso ocorre porque seus dados de usuário são mesclados com os dados de usuário do Amazon EKS necessários para que os nós participem do cluster. Não especifique nenhum comando nos dados de usuário que iniciem ou modifiquem `kubelet`. Isso é executado como parte dos dados de usuário mesclados pelo Amazon EKS. Certos parâmetros do `kubelet`, como a definição de rótulos em nós, podem ser configurados diretamente por meio da API de grupos de nós gerenciados.
**nota**
Para obter mais informações sobre personalização avançada do `kubelet`, inclusive para iniciá-la manualmente ou passar parâmetros de configuração personalizados, consulte [Especificar uma AMI](#launch-template-custom-ami). Seu um ID de AMI personalizada for especificado em um modelo de execução, o Amazon EKS não mesclará os dados de usuário.
Os detalhes a seguir fornecem mais informações sobre a seção de dados de usuário.
**Dados do usuário do Amazon Linux 2**
É possível combinar vários blocos de dados de usuário em um único arquivo MIME de várias partes. Por exemplo, você pode combinar um boothook de nuvem que configure o daemon do Docker com um script do shell de dados do usuário que instale um pacote personalizado. Um arquivo em várias partes MIME consiste nos seguintes componentes:
+ O tipo de conteúdo e a declaração de limite da parte: – `Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="`
+ A declaração da versão MIME: – `MIME-Version: 1.0`
+ Um ou mais blocos de dados do usuário, que contêm os seguintes componentes:
+ O limite de abertura, que sinaliza o início de um bloco de dados do usuário: `--==MYBOUNDARY==`
+ A declaração de tipo de conteúdo para o bloco: `Content-Type: text/cloud-config; charset="us-ascii"`. Para obter mais informações sobre os tipos de conteúdo, consulte a documentação do [cloud-init](https://cloudinit.readthedocs.io/en/latest/topics/format.html).
+ O conteúdo de dados de usuário (por exemplo, uma lista de comandos de shell ou diretivas `cloud-init`).
+ O limite de fechamento, que sinaliza o término do arquivo em várias partes MIME: `--==MYBOUNDARY==--`
Veja a seguir um exemplo de arquivo MIME com várias partes que você pode usar para criar seu próprio.
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
echo "Running custom user data script"
--==MYBOUNDARY==--
```
**Dados do usuário do Amazon Linux 2023**
O Amazon Linux 2023 (AL2023) introduz um novo processo de inicialização do nó `nodeadm` que usa um esquema de configuração YAML. Se estiver usando grupos de nós autogerenciados ou uma AMI com um modelo de inicialização, será necessário fornecer, de forma explícita, metadados de cluster adicionais ao criar um novo grupo de nós. Veja a seguir um [exemplo](https://awslabs.github.io/amazon-eks-ami/nodeadm/) dos parâmetros mínimos necessários, em que `apiServerEndpoint`, `certificateAuthority` e `cidr` do serviço passaram a ser necessários:
```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
```
Normalmente, você definirá essa configuração nos dados do usuário no estado em que se encontra ou incorporada em um documento MIME com várias partes:
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig spec: [...]
--BOUNDARY--
```
No AL2, os metadados desses parâmetros eram revelados na chamada de API `DescribeCluster` do Amazon EKS. Com o AL2023, esse comportamento foi alterado, uma vez que a chamada de API adicional corre o risco de sofrer controle de utilização durante grandes aumentos de escala vertical para nós. Essa alteração não afetará você se estiver usando grupos de nós gerenciados sem um modelo de inicialização ou se estiver usando o Karpenter. Para obter mais informações sobre `certificateAuthority` e sobre o serviço de `cidr`, consulte [https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html) na *Referência de API do Amazon EKS*.
Aqui está um exemplo completo dos dados do usuário do AL2023 que combinam um script de shell para personalizar o nó (como instalar pacotes ou pré-armazenar imagens de contêiner em cache) com a configuração de `nodeadm` necessária. Este exemplo mostra personalizações comuns, incluindo: \$1 Instalação de pacotes adicionais do sistema \$1 Pré-armazenamento em cache de imagens de contêiner para melhorar o tempo de inicialização do pod \$1 Configuração do proxy HTTP \$1 Configuração de sinalizadores `kubelet` para rotulagem de nós
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
set -o errexit
set -o pipefail
set -o nounset
# Install additional packages
yum install -y htop jq iptables-services
# Pre-cache commonly used container images
nohup docker pull public.ecr.aws/eks-distro/kubernetes/pause:3.2 &
# Configure HTTP proxy if needed
cat > /etc/profile.d/http-proxy.sh << 'EOF'
export HTTP_PROXY="http://proxy.example.com:3128"
export HTTPS_PROXY="http://proxy.example.com:3128"
export NO_PROXY="localhost,127.0.0.1,169.254.169.254,.internal"
EOF
--BOUNDARY
Content-Type: application/node.eks.aws
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
kubelet:
config:
clusterDNS:
- 10.100.0.10
flags:
- --node-labels=app=my-app,environment=production
--BOUNDARY--
```
**Dados do usuário do Bottlerocket**
O Bottlerocket estrutura dados de usuário no formato TOML. Informe os dados de usuário a serem mesclados com os dados de usuário fornecidos pelo Amazon EKS. Por exemplo, você pode fornecer outras configurações do `kubelet`.
```
[settings.kubernetes.system-reserved]
cpu = "10m"
memory = "100Mi"
ephemeral-storage= "1Gi"
```
Para obter mais informações sobre as configurações compatíveis, consulte a [documentação do Bottlerocket](https://github.com/bottlerocket-os/bottlerocket) do GitHub. É possível configurar rótulos de nós e [taints](node-taints-managed-node-groups.md) em seus dados de usuário. Porém, recomendamos configurá-los em seu grupo de nós. O Amazon EKS aplica essas configurações quando você faz isso.
Quando os dados de usuário são mesclados, a formatação não é preservada, mas o conteúdo permanece o mesmo. A configuração que você fornece nos dados de usuário substitui todas as configurações definidas pelo Amazon EKS. Dessa maneira, se você definir `settings.kubernetes.max-pods` ou `settings.kubernetes.cluster-dns-ip`, esses valores dos dados de usuário são aplicados aos nós.
O Amazon EKS não oferece suporte a todos os TOML válidos. Veja a seguir uma lista de formatos conhecidos não compatíveis:
+ Aspas em chaves entre aspas: `'quoted "value"' = "value"`
+ Aspas de escape em valores: `str = "I’m a string. \"You can quote me\""`
+ Floats mistos e números inteiros: `numbers = [ 0.1, 0.2, 0.5, 1, 2, 5 ]`
+ Tipos mistos em matrizes: `contributors = ["[foo@example.com](mailto:foo@example.com)", { name = "Baz", email = "[baz@example.com](mailto:baz@example.com)" }]`
+ Cabeçalhos entre colchetes com chaves entre aspas: `[foo."bar.baz"]`
**Dados do usuário do Windows**
Os dados do usuário do Windows usam os comandos do PowerShell. Ao criar um grupo de nós gerenciados, os dados de usuário personalizados se combinam com os dados de usuário gerenciados do Amazon EKS. Os comandos do PowerShell vêm em primeiro lugar, seguidos dos comandos de dados de usuário gerenciados, tudo em uma tag ``.
Ao criar grupos de nós do Windows, o Amazon EKS atualiza o `aws-auth` `ConfigMap` para permitir que os nós baseados em Linux façam parte do cluster. O serviço não configura automaticamente as permissões para AMIs do Windows. Se você estiver usando nós do Windows, precisará gerenciar o acesso por meio da API de entrada de acesso ou atualizando `aws-auth` `ConfigMap` diretamente. Para obter mais informações, consulte [Implantar nós Windows em clusters EKS](windows-support.md).
Quando nenhum ID de AMI for especificado no modelo de execução, não use o script de boostrap do Amazon EKS para Windows nos dados de usuário para configurar o Amazon EKS.
A seguir, um exemplo de dados do usuário.
```
Write-Host "Running custom user data script"
```
## Especificar uma AMI
Se você tiver um dos seguintes requisitos, especifique um ID de AMI na caixa `ImageId` do modelo de execução. Selecione o requisito que você tem para obter informações adicionais.
### Fornecer dados de usuário para passar argumentos para o arquivo `bootstrap.sh` incluído com uma AMI do Linux/Bottlerocket otimizada para Amazon EKS
Bootstrapping é um termo utilizado para descrever o processo de adicionar comandos que podem ser executados quando uma instância é iniciada. Por exemplo, o bootstrapping permite o uso de argumentos adicionais [do kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/). É possível passar os argumentos para o script `bootstrap.sh` usando `eksctl` sem especificar um modelo de inicialização. Ou faça isso especificando as informações na seção de dados de usuário de um modelo de execução.
**eksctl sem especificar um modelo de inicialização**
Crie um arquivo chamado *my-nodegroup.yaml* com o seguinte conteúdo. Substitua cada *valor de exemplo* por seus próprios valores. Os argumentos `--apiserver-endpoint`, `--b64-cluster-ca` e `--dns-cluster-ip` são opcionais. No entanto, defini-los permite que o script `bootstrap.sh` evite fazer uma chamada `describeCluster`. Isso é útil em configurações de cluster privado ou clusters em que há aumento e redução de escala na horizontal com frequência. Para obter mais informações sobre o script `bootstrap.sh`, consulte o arquivo [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) no GitHub.
+ O único argumento necessário é o nome do cluster*(my-cluster*).
+ Para recuperar um ID de AMI otimizado para `ami-1234567890abcdef0 `, consulte as seguintes seções:
+ [Recuperar IDs de AMI do Amazon Linux recomendadas](retrieve-ami-id.md)
+ [Recuperar IDs de AMI do Bottlerocket recomendadas](retrieve-ami-id-bottlerocket.md)
+ [Recuperar IDs de AMI do Microsoft Windows recomendadas](retrieve-windows-ami-id.md)
+ Para recuperar o *certificado de autoridade* do seu cluster, execute o seguinte comando.
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ Para recuperar o *api-server-endpoint* do seu cluster, execute o seguinte comando.
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ O valor para o `--dns-cluster-ip` é o serviço CIDR com `.10` no final. Para recuperar o *service-cidr* do seu cluster, execute o seguinte comando. Por exemplo, se o valor retornado para for `ipv4 10.100.0.0/16`, então seu valor é *10.100.0.10*.
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ Este exemplo fornece um argumento adicional do `kubelet` para definir um valor `max-pods` personalizado usando o valor do script `bootstrap.sh` incluído com a AMI otimizada para o Amazon EKS. O nome do grupo de nós não pode exceder 63 caracteres. Deve começar com uma letra ou um dígito, mas pode incluir hifens e sublinhados para os demais caracteres. Para ajuda com a seleção de *my-max-pods-value*, consulte . Para obter mais informações sobre como `maxPods` é determinado ao usar grupos de nós gerenciados, consulte [Como maxPods é determinado](choosing-instance-type.md#max-pods-precedence).
```
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: region-code
managedNodeGroups:
- name: my-nodegroup
ami: ami-1234567890abcdef0
instanceType: m5.large
privateNetworking: true
disableIMDSv1: true
labels: { x86-al2-specified-mng }
overrideBootstrapCommand: |
#!/bin/bash
/etc/eks/bootstrap.sh my-cluster \
--b64-cluster-ca certificate-authority \
--apiserver-endpoint api-server-endpoint \
--dns-cluster-ip service-cidr.10 \
--kubelet-extra-args '--max-pods=my-max-pods-value' \
--use-max-pods false
```
Para cada opção de arquivo `eksctl` `config` disponível, consulte [Esquema do arquivo config](https://eksctl.io/usage/schema/), na documentação do `eksctl`. O utilitário `eksctl` ainda cria um modelo de inicialização para você e preenche seus dados de usuário com dados fornecidos no arquivo `config`.
Crie um grupo de nós com o comando a seguir.
```
eksctl create nodegroup --config-file=my-nodegroup.yaml
```
**Dados do usuário em um modelo de lançamento**
Especifique as seguintes informações na seção de dados do usuário do modelo de execução. Substitua cada *valor de exemplo* por seus próprios valores. Os argumentos `--apiserver-endpoint`, `--b64-cluster-ca` e `--dns-cluster-ip` são opcionais. No entanto, defini-los permite que o script `bootstrap.sh` evite fazer uma chamada `describeCluster`. Isso é útil em configurações de cluster privado ou clusters em que há aumento e redução de escala na horizontal com frequência. Para obter mais informações sobre o script `bootstrap.sh`, consulte o arquivo [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) no GitHub.
+ O único argumento necessário é o nome do cluster*(my-cluster*).
+ Para recuperar o *certificado de autoridade* do seu cluster, execute o seguinte comando.
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ Para recuperar o *api-server-endpoint* do seu cluster, execute o seguinte comando.
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ O valor para o `--dns-cluster-ip` é o serviço CIDR com `.10` no final. Para recuperar o *service-cidr* do seu cluster, execute o seguinte comando. Por exemplo, se o valor retornado para for `ipv4 10.100.0.0/16`, então seu valor é *10.100.0.10*.
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ Este exemplo fornece um argumento adicional do `kubelet` para definir um valor `max-pods` personalizado usando o valor do script `bootstrap.sh` incluído com a AMI otimizada para o Amazon EKS. Para ajuda com a seleção de *my-max-pods-value*, consulte . Para obter mais informações sobre como `maxPods` é determinado ao usar grupos de nós gerenciados, consulte [Como maxPods é determinado](choosing-instance-type.md#max-pods-precedence).
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
set -ex
/etc/eks/bootstrap.sh my-cluster \
--b64-cluster-ca certificate-authority \
--apiserver-endpoint api-server-endpoint \
--dns-cluster-ip service-cidr.10 \
--kubelet-extra-args '--max-pods=my-max-pods-value' \
--use-max-pods false
--==MYBOUNDARY==--
```
### Fornecer dados de usuário para passar argumentos para o arquivo `Start-EKSBootstrap.ps1` incluído com uma AMI do Windows otimizada para Amazon EKS
Bootstrapping é um termo utilizado para descrever o processo de adicionar comandos que podem ser executados quando uma instância é iniciada. É possível passar os argumentos para o script `Start-EKSBootstrap.ps1` usando `eksctl` sem especificar um modelo de inicialização. Ou faça isso especificando as informações na seção de dados de usuário de um modelo de execução.
Se você quiser especificar um ID de AMI do Windows, tenha em mente as seguintes considerações:
+ É necessário usar um modelo de inicialização e fornecer os comandos de bootstrap necessários na seção de dados do usuário. Para recuperar o ID do Windows desejado, você pode usar a tabela em [Criar nós com AMIs otimizadas do Windows](eks-optimized-windows-ami.md).
+ Existem vários limites e condições. Por exemplo, é necessário adicionar `eks:kube-proxy-windows` ao mapa de configuração do AWS IAM Authenticator. Para obter mais informações, consulte [Limites e condições ao especificar uma ID de AMI](#mng-ami-id-conditions).
Especifique as seguintes informações na seção de dados do usuário do modelo de execução. Substitua cada *valor de exemplo* por seus próprios valores. Os argumentos `-APIServerEndpoint`, `-Base64ClusterCA` e `-DNSClusterIP` são opcionais. No entanto, defini-los permite que o script `Start-EKSBootstrap.ps1` evite fazer uma chamada `describeCluster`.
+ O único argumento necessário é o nome do cluster*(my-cluster*).
+ Para recuperar o *certificado de autoridade* do seu cluster, execute o seguinte comando.
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ Para recuperar o *api-server-endpoint* do seu cluster, execute o seguinte comando.
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ O valor para o `--dns-cluster-ip` é o serviço CIDR com `.10` no final. Para recuperar o *service-cidr* do seu cluster, execute o seguinte comando. Por exemplo, se o valor retornado para for `ipv4 10.100.0.0/16`, então seu valor é *10.100.0.10*.
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ Para obter argumentos adicionais, consulte [Parâmetros de configuração do script de bootstrap](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
**nota**
Se você estiver usando um CIDR de serviço personalizado, será necessário especificá-lo usando o parâmetro `-ServiceCIDR`. Do contrário, a resolução de DNS para pods no cluster falhará.
```
[string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1"
& $EKSBootstrapScriptFile -EKSClusterName my-cluster `
-Base64ClusterCA certificate-authority `
-APIServerEndpoint api-server-endpoint `
-DNSClusterIP service-cidr.10
```
### Executar uma AMI personalizada devido a requisitos específicos de segurança, conformidade ou política interna
Para obter mais informações, consulte [Imagens de máquina da Amazon (AMIs)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) no *Guia do usuário do Amazon EC2*. A especificação de compilação da AMI do Amazon EKS contém recursos e scripts de configuração para desenvolver uma AMI do Amazon EKS personalizada baseada no Amazon Linux. Para obter mais informações, consulte [Amazon EKS AMI Build Specification](https://github.com/awslabs/amazon-eks-ami/) (Especificação de compilação da AMI do Amazon EKS) no GitHub. Para criar AMIs personalizadas instaladas com outros sistemas operacionais, consulte [Amazon EKS Sample Custom AMIs](https://github.com/aws-samples/amazon-eks-custom-amis) (AMIs personalizadas de amostra do Amazon EKS) no GitHub.
Não é possível usar referências de parâmetros dinâmicos para IDs de AMI em Modelos de Lançamento usados com grupos de nós gerenciados.
**Importante**
Ao especificar uma AMI, o Amazon EKS não valida a versão do Kubernetes incorporada à sua AMI em relação à versão do ambiente de gerenciamento do seu cluster. Você é responsável por garantir que a versão do Kubernetes da sua AMI personalizada esteja em conformidade com a [política de distorção de versão do Kubernetes](https://kubernetes.io/releases/version-skew-policy):
A versão `kubelet` em seus nós não deve ser mais recente que a versão do cluster
A versão `kubelet` em seus nós deve ser igual ou até 3 versões secundárias atrás da versão do cluster (para a versão `1.28` ou posterior do Kubernetes) ou até 2 versões secundárias atrás da versão do cluster (para a versão `1.27` ou anterior do Kubernetes)
A criação de grupos de nós gerenciados com violações de distorção de versão pode resultar em:
Falha nos nós de operador ao ingressar no cluster
Comportamento indefinido ou incompatibilidades de API
Instabilidade do cluster ou falhas na workload
Ao especificar uma AMI, o Amazon EKS não mescla nenhum dado do usuário. Em vez disso, você é responsável por fornecer os comandos do `bootstrap` para que os nós se integrem ao cluster. Se os nós não conseguirem se integrar ao cluster, as ações do Amazon EKS `CreateNodegroup` e do `UpdateNodegroupVersion` também falharão.
## Limites e condições ao especificar uma ID de AMI
Estes são os limites e condições envolvidos na especificação de um ID de AMI com grupos de nós gerenciados:
+ É necessário criar um novo grupo de nós para alternar entre especificar um ID de AMI em um modelo de execução e não especificar um ID de AMI.
+ Você não é notificado no console quando uma versão mais recente da AMI estiver disponível. Para atualizar seu grupo de nós para uma versão mais recente da AMI, é necessário criar uma nova versão do modelo de execução com um ID de AMI atualizado. Em seguida, é necessário atualizar o grupo de nós com a nova versão do modelo de execução.
+ Os campos a seguir não podem ser definidos na API se você especificar um ID de AMI:
+ `amiType`
+ `releaseVersion`
+ `version`
+ Qualquer `taints` conjunto na API é aplicado de forma assíncrona se você especificar um ID de AMI. Para aplicar contaminações antes de um nó ingressar no cluster, é necessário transmiti-las para `kubelet` os dados do usuário usando a sinalização da linha de comando `--register-with-taints`. Para obter mais informações, consulte [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) na documentação do Kubernetes.
+ Ao especificar um ID de AMI personalizado para grupos de nós gerenciados do Windows, adicione `eks:kube-proxy-windows` ao mapa de configuração do AWS IAM Authenticator. Essa API é necessária para o DNS funcionar bem.
1. Abra o mapa de configuração do AWS IAM Authenticator para edição.
```
kubectl edit -n kube-system cm aws-auth
```
1. Adicione essa entrada à lista de `groups` abaixo de cada `rolearn` associado aos nós do Windows. Seu mapa de configuração deve ser semelhante a [aws-auth-cm-windows.yaml](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml).
```
- eks:kube-proxy-windows
```
1. Salve o arquivo e saia do seu editor de texto.
+ Para qualquer AMI que usa um modelo de execução personalizado, o `HttpPutResponseHopLimit` padrão para grupos de nós gerenciados é definido como `2`.
# Excluir um grupo de nós gerenciados do seu cluster
Este tópico descreve como você pode excluir um grupo de nós gerenciados do Amazon EKS. Quando você exclui um grupo de nós gerenciados, o Amazon EKS primeiro define o tamanho mínimo, máximo e desejado do grupo do Auto Scaling como zero. Isso faz com que seu grupo de nós reduza a escala na vertical.
Antes que cada instância seja encerrada, o Amazon EKS envia um sinal para que a drenagem desse nó seja realizada. Durante o processo de drenagem, o Kubernetes faz o seguinte para cada pod no nó: executa quaisquer ganchos do ciclo de vida `preStop` configurados, envia sinais `SIGTERM` para os contêineres e, em seguida, aguarda o `terminationGracePeriodSeconds` para um encerramento ordenado. Caso a drenagem do nó não seja concluída após cinco minutos, o Amazon EKS permite que o Auto Scaling dê prosseguimento ao encerramento forçado da instância. Depois que todas as instâncias forem encerradas, o grupo do Auto Scaling será excluído.
**Importante**
Se você excluir um grupo de nós gerenciado que usa um perfil do IAM do nó que não é usado por outro grupo de nós gerenciados no cluster, a função será removida do `ConfigMap` `aws-auth`. Se algum grupo de nós autogerenciados no cluster estiver usando a mesma função do IAM do nó, os nós autogerenciados serão movidos para o status `NotReady`. Além disso, a operação do cluster também é interrompida. Para adicionar um mapeamento para o perfil que você está usando somente para os grupos de nós autogerenciados, consulte [Criar entradas de acesso](creating-access-entries.md), se a versão da plataforma do seu cluster for pelo menos a versão mínima listada na seção de pré-requisitos de [Conceder aos usuários do IAM acesso ao Kubernetes com entradas de acesso EKS](access-entries.md). Se a versão da plataforma for anterior à versão mínima exigida para entradas de acesso, você poderá adicionar a entrada novamente ao `aws-auth` `ConfigMap`. Para obter mais informações, insira `eksctl create iamidentitymapping --help` no seu terminal.
Você pode excluir um grupo de nós gerenciados com:
+ [`eksctl`](#eksctl-delete-managed-nodegroup)
+ [Console de gerenciamento da AWS](#console-delete-managed-nodegroup)
+ [AWS CLI](#awscli-delete-managed-nodegroup)
## `eksctl`
**Excluir um grupo de nós gerenciados com `eksctl` **
Insira o comando a seguir. Substitua `` por seus próprios valores.
```
eksctl delete nodegroup \
--cluster \
--name \
--region
```
Para obter mais opções, consulte [Excluir e drenar grupos de nós](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups) na documentação do `eksctl`.
## Console de gerenciamento da AWS
**Excluir um grupo de nós gerenciados com Console de gerenciamento da AWS **
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Na página **Clusters**, escolha o cluster que contém o grupo de nós a ser excluído.
1. Na página do cluster selecionado, escolha a guia **Computação**.
1. Na seção **Node groups** (Grupos de nós), escolha o grupo de nós a ser excluído. Escolha **Excluir**.
1. Na caixa de diálogo de confirmação **Excluir grupo de nós**, insira o nome do grupo de nós. Escolha **Excluir**.
## AWS CLI
**Excluir um grupo de nós gerenciados com AWS CLI**
1. Insira o comando a seguir. Substitua `` por seus próprios valores.
```
aws eks delete-nodegroup \
--cluster-name \
--nodegroup-name \
--region
```
1. Se o parâmetro `cli_pager=` estiver definido na configuração da CLI, use as teclas de seta do teclado para navegar pelo conteúdo da resposta exibida. Pressione a tecla `q` quando terminar.
Para obter mais opções, consulte o comando ` [delete-nodegroup](https://docs.aws.amazon.com/cli/latest/reference/eks/delete-nodegroup.html) ` em * AWS CLI Command Reference*.