**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. # Fazer a manutenção dos nós por conta própria com nós autogerenciados Um cluster contém um ou mais nós do Amazon EC2 em que os pods estão agendados. Os nós do Amazon EKS são executados na conta da AWS e se conectam ao ambiente de gerenciamento do cluster pelo endpoint do servidor da API do cluster. Você é cobrado por elas com base nos preços do Amazon EC2. Para obter mais informações, consulte [Definição de preço do Amazon EC2](https://aws.amazon.com/ec2/pricing/). Um cluster pode conter vários grupos de nós. Cada grupo de nós contém um ou mais nós que são implantados em um [grupo do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html). O tipo de instância dos nós dentro do grupo pode variar, por exemplo, ao usar [a seleção de tipo de instância baseada em atributos](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html) com o [Karpenter](https://karpenter.sh/). Todas as instâncias de um grupo de nós devem usar a [perfil do IAM de nós do Amazon EKS](create-node-role.md). O Amazon EKS fornece imagens de máquina da Amazon (AMI) especializada que são chamadas de AMIs otimizadas do Amazon EKS. As AMIs estão configuradas para funcionar com o Amazon EKS. Seus componentes incluem `containerd`, `kubelet` e o AWS IAM Authenticator. As AMIs também contêm um [script de bootstrap](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) especializado que permite que ele descubra e conecte-se ao ambiente de gerenciamento do cluster automaticamente. Se você restringir o acesso ao endpoint público do cluster usando blocos CIDR, é recomendável também habilitar o acesso ao endpoint privado. Isso serve para que os nós possam se comunicar com o cluster. Sem o endpoint privado ativado, os blocos CIDR especificados para acesso público devem incluir as origens de saída da VPC. Para obter mais informações, consulte [Endpoint do servidor de API do cluster](cluster-endpoint.md). Para adicionar nós autogerenciados ao cluster do Amazon EKS, consulte os tópicos a seguir. Caso execute os nós autogerenciados manualmente, adicione a tag a seguir a cada nó, verificando se `` corresponde ao cluster. Para obter mais informações, consulte [Adicionar e excluir tags em um recurso individual](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). Se você seguir as etapas nos guias a seguir, a etiqueta necessária será adicionada ao nó para você. | Chave | Valor | | --- | --- | | `kubernetes.io/cluster/` | `owned` | **Importante** As tags no serviço de metadados de instância (IMDS) do Amazon EC2 não são compatíveis com os nós do EKS. Quando as tags de metadados de instância estão habilitadas, não é possível o uso de barras ('/') nos valores das tags. Essa limitação pode causar falhas na inicialização de instâncias, principalmente ao usar ferramentas de gerenciamento de nós, como o Karpenter ou o Cluster Autoscaler, pois esses serviços dependem de tags que contêm barras para um funcionamento adequado. Para obter mais informações sobre nós, de um ponto de vista geral do Kubernetes, consulte [Nodes](https://kubernetes.io/docs/concepts/architecture/nodes/) (Nós) na documentação do Kubernetes. **Topics** + [Criar nós autogerenciados do Amazon Linux](launch-workers.md) + [Criar nós Bottlerocket autogerenciados do Bottlerocket](launch-node-bottlerocket.md) + [Criar nós autogerenciados do Microsoft Windows](launch-windows-workers.md) + [Criar nós autogerenciados do Ubuntu Linux](launch-node-ubuntu.md) + [Atualizar nós autogerenciados para seu cluster](update-workers.md) # Criar nós autogerenciados do Amazon Linux Este tópico descreve como iniciar grupos do Auto Scaling de nós do Linux que são registrados no cluster do Amazon EKS. Depois que os nós ingressam no cluster, você pode implantar aplicações do Kubernetes neles. Além disso, é possível iniciar nós autogerenciados do Amazon Linux ao usar `eksctl` ou o Console de gerenciamento da AWS. Se você precisar lançar nós em AWS Outposts, consulte [Criar nós Amazon Linux no AWS Outposts](eks-outposts-self-managed-nodes.md). + Um cluster existente do Amazon EKS. Para implantar, consulte [Criar um cluster do Amazon EKS](create-cluster.md). Se você tiver sub-redes na região AWS em que AWS Outposts, AWS Wavelength ou AWS Local Zones estiverem ativados, essas sub-redes não devem ter sido passadas quando você criou o cluster. + 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. Você pode iniciar nós do Linux autogerenciados usando uma das seguintes opções: + [`eksctl`](#eksctl_create_managed_amazon_linux) + [Console de gerenciamento da AWS](#console_create_managed_amazon_linux) ## `eksctl` **Iniciar nós autogerenciados do Linux usando `eksctl`** 1. Instale a versão `0.215.0` ou posterior da ferramenta de linha de comando da `eksctl` instalada no seu dispositivo ou AWS CloudShell. Para 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. O comando a seguir cria um grupo de nós em um cluster existente. Substitua *al-nodes* por um nome para o 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. Substitua *my-cluster* pelo nome do cluster. O nome só pode conter caracteres alfanuméricos (sensíveis a maiúsculas e minúsculas) e hifens. Ele deve começar com um caractere alfanumérico e não pode ter mais de 100 caracteres. O nome deve ser exclusivo na região da AWS e na conta da AWS em que você está criando o cluster. Substitua o *valor de exemplo* restante por seus próprios valores. Os nós são criados com a mesma versão do Kubernetes que o plano de controle, por padrão. Antes de escolher um valor para `--node-type`, revise [Escolher um tipo ideal de instância de nó do Amazon EC2](choosing-instance-type.md). 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. Se ainda não tiver um par de chaves do Amazon EC2, você poderá criar um no Console de gerenciamento da AWS. Para obter mais informações, consulte [Pares de chaves do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html), no *Guia do usuário do Amazon EC2*. Crie seu grupo de nós com o comando a seguir. **Importante** Se você quiser implantar um grupo de nós nas sub-redes AWS Outposts, Wavelength ou Local Zone, há outras considerações a serem feitas: As sub-redes não devem ter passado quando você criou o cluster. É necessário criar o grupo de nós com um arquivo config que especifique as sub-redes e ` [volumeType](https://eksctl.io/usage/schema/#nodeGroups-volumeType): gp2`. Para obter mais informações, consulte [Criar um grupo de nós em um arquivo de configuração](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) e [Esquema de arquivo Config](https://eksctl.io/usage/schema/) na documentação do `eksctl`. ``` eksctl create nodegroup \ --cluster my-cluster \ --name al-nodes \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --ssh-access \ --managed=false \ --ssh-public-key my-key ``` Para implantar um grupo de nós que: + Possa atribuir um número significativamente maior de endereços IP as pods do que a configuração padrão, consulte [Atribuir mais endereços IP aos nós do Amazon EKS com prefixos](cni-increase-ip-addresses.md). + Possa atribuir endereços `IPv4` aos pods de um bloco CIDR diferente do bloco da instância, consulte [Implementar pods em sub-redes alternativas com rede personalizada](cni-custom-network.md). + Possa atribuir endereços `IPv6` aos pods e serviços, consulte [Saiba mais sobre endereços IPv6 para clusters, pods e serviços](cni-ipv6.md). + Não tenha acesso de saída à Internet, consulte [Implementar clusters privados com acesso limitado à internet](private-clusters.md). Para obter uma lista completa de todas as opções e padrões disponíveis, digite o comando a seguir. ``` eksctl create nodegroup --help ``` 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. Veja abaixo um exemplo de saída. Várias linhas são emitidas enquanto os nós são criados. Uma das últimas linha de saída é o exemplo de linha a seguir. ``` [✔] created 1 nodegroup(s) in cluster "my-cluster" ``` 1. (Opcional) Implante uma [aplicação de exemplo](sample-deployment.md) para testar o cluster e os nós do Linux. 1. 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). ## Console de gerenciamento da AWS **Etapa 1: iniciar nós autogerenciados do Linux usando Console de gerenciamento da AWS** 1. Baixe a versão mais recente do modelo do AWS CloudFormation. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-26/amazon-eks-nodegroup.yaml ``` 1. Aguarde até que o status do cluster seja exibido como `ACTIVE`. Se você executar os nós antes que o cluster esteja ativo, o registro dos nós no cluster falhará, e você terá de executá-los novamente. 1. Abra o console do [AWS CloudFormation](https://console.aws.amazon.com/cloudformation/). 1. Selecione **Create stack** (Criar pilha) e **With new resources (standard)** (Com novos recursos, padrão). 1. Para **Specify template** (Especificar modelo), selecione **Upload a template file ** (Fazer upload de um arquivo de modelo) e depois **Choose file** (Escolher arquivo). 1. Selecione o arquivo `amazon-eks-nodegroup.yaml` que você baixou. 1. Escolha **Próximo**. 1. Na página **Specify stack details** (Especificar detalhes da pilha), insira os parâmetros de acordo e escolha **Next** (Próximo): + **Nome da pilha**: escolha um nome para a pilha do AWS CloudFormation. Por exemplo, você pode chamá-lo de *my-cluster-nodes*. O nome só pode conter caracteres alfanuméricos (sensíveis a maiúsculas e minúsculas) e hifens. Ele deve começar com um caractere alfanumérico e não pode ter mais de 100 caracteres. O nome deve ser exclusivo na região da AWS e na conta da AWS em que você está criando o cluster. + **ClusterName**: insira o nome que você usou ao criar o cluster do Amazon EKS. Esse nome deve ser igual ao nome do cluster, ou seus nós não poderão ingressar no cluster. + **ClusterControlPlaneSecurityGroup**: Escolha o valor **SecurityGroups** da saída do AWS CloudFormation que você gerou ao criar sua [VPC](creating-a-vpc.md). As etapas a seguir mostram uma operação para recuperar o grupo aplicável. 1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Escolha o nome do cluster. 1. Escolha a guia **Redes**. 1. Use o valor de **Additional security group** (Grupos de segurança adicionais) como referência ao selecionar na lista suspensa **ClusterControlPlaneSecurityGroup**. + **ApiServerEndpoint**: informe o endpoint do servidor de API do cluster do EKS. É possível encontrar essa informação na seção Detalhes do console do cluster do EKS. + **CertificateAuthorityData**: informe os dados da Autoridade de Certificação codificados em base64, que também podem ser encontrados na seção Detalhes do console do cluster do EKS. + **ServiceCidr**: informe o intervalo CIDR usado para alocar endereços IP aos serviços Kubernetes dentro do cluster. É possível encontrar essa informação na guia Redes do console do cluster do EKS. + **AuthenticationMode**: selecione o modo de autenticação em uso no cluster do EKS, consultando a guia Acesso no console do cluster do EKS. + **NodeGroupName**: insira um nome para o grupo de nós. Esse nome poderá ser usado superiormente para identificar o grupo de nós do Auto Scaling que for criado para os 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. + **NodeAutoScalingGroupMinSize**: digite o número mínimo de nós para o qual o grupo Auto Scaling de nós pode ser escalado. + **NodeAutoScalingGroupDesiredCapacity**: insira o número desejado de nós para o qual dimensionar quando a pilha for criada. + **NodeAutoScalingGroupMaxSize**: digite o número máximo de nós para o qual o grupo Auto Scaling de nós pode ser escalado. + **NodeInstanceType**: escolha um tipo de instância para os nós. Para obter mais informações, consulte [Escolher um tipo de instância de nó do Amazon EC2 ideal](choosing-instance-type.md). + **NodeImageIdSSMParam**: preenchido previamente com o parâmetro do gerenciador de sistemas do Amazon EC2 de uma AMI do Amazon Linux 2023 otimizada para o Amazon EKS mais recente, que é compatível com uma versão variável do Kubernetes. Para usar uma versão secundária diferente do Kubernetes compatível com o Amazon EKS, substitua *1.XX* por uma [versão compatível](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) diferente. Recomendamos especificar a mesma versão do Kubernetes que seu cluster. Você também pode substituir *o amazon-linux-2023* por um tipo diferente de AMI. Para obter mais informações, consulte [Recuperar IDs de AMI do Amazon Linux recomendadas](retrieve-ami-id.md). **nota** As AMIs dos nós do Amazon EKS são baseadas no Amazon Linux. Você pode monitorar eventos de segurança ou privacidade para o Amazon Linux 2023 no [Centro de segurança do Amazon Linux](https://alas.aws.amazon.com/alas2023.html) ou fazendo a assinatura do [feed RSS](https://alas.aws.amazon.com/AL2023/alas.rss) associado. Os eventos de segurança e privacidade incluem uma visão geral do problema, quais pacotes são afetadas e como atualizar suas instâncias para corrigir o problema. + **NodeImageId**: (opcional) se estiver usando sua própria AMI personalizada (em vez da AMI otimizada do Amazon EKS), insira um ID de AMI de nó para a região da AWS. Se você especificar um valor aqui, ele substituirá todos os valores no campo **NodeImageIdSSMParam**. + **NodeVolumeSize**: especifique um tamanho de volume raiz para os nós, em GiB. + **NodeVolumeType**: especifique um tipo de volume raiz para os nós. + **KeyName**: insira o nome de um par de chaves SSH do Amazon EC2; que você pode usar para conectar-se usando SSH em seus nós, depois de iniciados. Se ainda não tiver um par de chaves do Amazon EC2, você poderá criar um no Console de gerenciamento da AWS. Para obter mais informações, consulte [Pares de chaves do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html), no *Guia do usuário do Amazon EC2*. + **VpcId**: insira o ID da [VPC](creating-a-vpc.md) que você criou. + **Sub-redes**: escolha as sub-redes criadas para a sua VPC. Se você criou sua VPC usando as etapas descritas em [Criar uma Amazon VPC para seu cluster do Amazon EKS](creating-a-vpc.md), especifique apenas as sub-redes privadas dentro da VPC para que seus nós sejam iniciados. É possível ver quais sub-redes são privadas abrindo cada link de sub-rede na guia **Networking** (Redes) do cluster. **Importante** Se alguma das sub-redes for pública, ela deverá ter a atribuição automática de atribuição de endereço IP público habilitada. Se a configuração não estiver habilitada para a sub-rede pública, os nós implantados nessa sub-rede pública não receberão um endereço IP público e não poderão se comunicar com o cluster nem com outros produtos da AWS. Se a sub-rede tiver sido implantada antes de 26 de março de 2020 usando um dos [modelos de VPC do Amazon EKS AWS CloudFormation](creating-a-vpc.md) ou usando `eksctl`, a atribuição automática de endereço IP público estará desativada para sub-redes públicas. Para obter informações sobre como habilitar a atribuição de endereço IP público para uma sub-rede, 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 o nó for implantado em uma sub-rede privada, ele poderá se comunicar com o cluster e com outros produtos da AWS por um gateway NAT. Se as sub-redes não tiverem acesso à Internet, certifique-se de estar ciente das considerações e etapas adicionais em [Implantar clusters privados com acesso limitado à Internet](private-clusters.md). Se você selecionar as sub-redes AWS Outposts, Wavelength ou Local Zone, as sub-redes não devem ter sido passadas quando você criou o cluster. 1. Selecione as opções desejadas na página **Configure stack options** (Configurar opções de pilha) e depois escolha **Next** (Próximo). 1. Marque a caixa de seleção à esqu **erda de I acknowledge that AWS CloudFormation might create IAM resources. (Eu reconheço que o CloudFormation pode criar recursos de IAM**) e, em seguida, selecione **Create stack (Criar pilha**). 1. Quando a criação da pilha for concluída, selecione-a no console e escolha **Outputs (Saídas)**. Se você estiver usando os modos de autenticação `EKS API` ou `EKS API and ConfigMap`, esta é a última etapa. 1. Se você estiver usando o modo de autenticação `ConfigMap`, registre o **NodeInstanceRole** do grupo de nós criado. **Etapa 2: habilite os nós para participar do cluster** **nota** As próximas duas etapas são necessárias somente se o modo de autenticação ConfigMap estiver em uso no cluster do EKS. Além disso, caso os nós tenham sido executados em uma VPC privada sem acesso de saída à internet, certifique-se de permitir que os nós se conectem ao cluster usando a VPC. 1. Verifique se você já tem um `aws-auth` `ConfigMap`. ``` kubectl describe configmap -n kube-system aws-auth ``` 1. Se você receber um `aws-auth` `ConfigMap`, atualize-o conforme necessário. 1. Abra o `ConfigMap` para edição. ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. Adicione uma nova `mapRoles` entrada conforme necessário. Defina o valor `rolearn` para o valor **NodeInstanceRole** que você registrou no procedimento anterior. ``` [...] data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes [...] ``` 1. Salve o arquivo e saia do seu editor de texto. 1. Se você recebeu um erro informando "`Error from server (NotFound): configmaps "aws-auth" not found`, aplique o estoque`ConfigMap`. 1. Faça download do mapa de configuração. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml ``` 1. No arquivo `aws-auth-cm.yaml`, configure o valor `rolearn` para o valor **NodeInstanceRole** que você registrou no procedimento anterior. Você pode fazer isso com um editor de texto ou substituindo *my-node-instance-role* e executando o seguinte comando: ``` sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml ``` 1. Aplique a configuração. Esse comando pode demorar alguns minutos para ser concluído. ``` kubectl apply -f aws-auth-cm.yaml ``` 1. Observe o status de seus nós e aguarde até que eles atinjam o status `Ready`. ``` kubectl get nodes --watch ``` Insira `Ctrl`\$1`C` para retornar a um prompt de shell. **nota** Se você receber qualquer erro de autorização ou de tipo de recurso, consulte [Acesso negado ou não autorizado (`kubectl`)](troubleshooting.md#unauthorized) no tópico de solução de problemas. 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. (Somente nós de GPU) Caso escolha um tipo de instância de GPU e a AMI acelerada otimizada para Amazon EKS, você deverá 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 ``` **Etapa 3: Ações adicionais** 1. (Opcional) Implante uma [aplicação de exemplo](sample-deployment.md) para testar o cluster e os nós do Linux. 1. (Opcional) Se a política do IAM gerenciada **AmazonEKS\$1CNI\$1Policy** (caso você tenha um cluster `IPv4`) ou *AmazonEKS\$1CNI\$1IPv6\$1Policy* (que você [criou de forma independente](cni-iam-role.md#cni-iam-role-create-ipv6-policy), caso tenha um cluster `IPv6`) estiver anexada ao [perfil do IAM dos nós do Amazon EKS](create-node-role.md), recomendamos atribuí-la a um perfil do IAM que possa ser associado à conta de serviço do Kubernetes `aws-node`. Para obter mais informações, consulte [Configurar o plug-in CNI da Amazon VPC para usar IRSA](cni-iam-role.md). 1. 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). # Criar nós Bottlerocket autogerenciados do Bottlerocket **nota** Os grupos de nós gerenciados podem oferecer algumas vantagens para seu caso de uso. Para obter mais informações, consulte [Simplificar o ciclo de vida dos nós com grupos de nós gerenciados](managed-node-groups.md). Este tópico descreve como iniciar grupos do Auto Scaling de nós do [Bottlerocket](https://aws.amazon.com/bottlerocket/) que são registrados no cluster do Amazon EKS. O Bottlerocket é um sistema operacional de código aberto baseado em Linux da AWS que você pode usar para executar contêineres em máquinas virtuais ou hosts bare metal. Depois que os nós ingressam no cluster, você pode implantar aplicações do Kubernetes neles. Para obter mais informações sobre o Bottlerocket, consulte [Usar uma AMI do Bottlerocket com o Amazon EKS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-EKS.md) no GitHub e [Suporte à AMI personalizada](https://eksctl.io/usage/custom-ami-support/) na documentação do `eksctl`. Para obter informações sobre atualizações no local, consulte [Operador de atualização do Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-update-operator) no GitHub. **Importante** Os nós do Amazon EKS são instâncias padrão do Amazon EC2, e você é cobrado por eles com base nos preços normais das instâncias do Amazon EC2. Para obter mais informações, consulte [Definição de preço do Amazon EC2](https://aws.amazon.com/ec2/pricing/). Você pode iniciar nós do Bottlerocket em clusters estendidos do Amazon EKS em Outposts da AWS, mas não pode iniciá-los em clusters locais no AWS Outposts. Para obter mais informações, consulte [Implantar o Amazon EKS on-premises com o AWS Outposts](eks-outposts.md). Você pode implantar em instâncias do Amazon EC2 com processadores `x86` ou Arm. Porém, não é possível implantar em instâncias que tenham chips Inferentia. O Bottlerocket é compatível com o AWS CloudFormation. No entanto, não há um modelo oficial do CloudFormation que possa ser copiado para implantar nós do Bottlerocket para Amazon EKS. As imagens do Bottlerocket não vêm com um servidor ou shell SSH. Você pode usar métodos de acesso fora de banda para permitir que o SSH habilite o contêiner do administrador e passar algumas etapas de configuração de bootstrapping com dados de usuário. Para mais informações, consulte essas seções no [bottlerocket README.md](https://github.com/bottlerocket-os/bottlerocket) no GitHub: [Exploration (Exploração](https://github.com/bottlerocket-os/bottlerocket#exploration) [Admin container (Contêiner Admin](https://github.com/bottlerocket-os/bottlerocket#admin-container) [Kubernetes settings (Configurações do Kubernetes](https://github.com/bottlerocket-os/bottlerocket#kubernetes-settings) 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 `eksctl`, consulte [Instalação](https://eksctl.io/installation) na documentação do `eksctl`. OBSERVAÇÃO: esse procedimento apenas funciona para clusters que foram criados com o `eksctl`. 1. Copie o conteúdo a seguir para o seu dispositivo. Substitua *my-cluster* pelo nome do cluster. O nome só pode conter caracteres alfanuméricos (sensíveis a maiúsculas e minúsculas) e hifens. Ele deve começar com um caractere alfanumérico e não pode ter mais de 100 caracteres. O nome deve ser exclusivo na região da AWS e na conta da AWS em que você está criando o cluster. Substitua *ng-bottlerocket* por um nome para 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. Para implementar em instâncias Arm, substitua *m5.large* por um tipo de instância Arm. Substitua *my-ec2-keypair-name* pelo nome de um par de chaves SSH do Amazon EC2 que você pode usar para se conectar usando SSH em seus nós após o lançamento. Se ainda não tiver um par de chaves do Amazon EC2, você poderá criar um no Console de gerenciamento da AWS. Para obter mais informações, consulte [Pares de chaves do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html), no *Guia do usuário do Amazon EC2*. Substitua todos os valores de exemplo restantes por seus próprios valores. Depois de fazer as substituições, execute o comando modificado para criar o arquivo `bottlerocket.yaml`. Se estiver especificando um tipo de instância Arm do Amazon EC2, analise as considerações em [AMIs Amazon Linux Arm otimizadas para Amazon EKS](eks-optimized-ami.md#arm-ami) antes da implementação. Para obter instruções sobre como implantar usando uma AMI personalizada, consulte [Criar Bottlerocket no GitHub](https://github.com/bottlerocket-os/bottlerocket/blob/develop/BUILDING.md) e [Suporte à AMI personalizada](https://eksctl.io/usage/custom-ami-support/) na documentação do `eksctl`. Para implantar um grupo de nós gerenciados, implante uma AMI personalizada usando um modelo de execução. Para obter mais informações, consulte [Personalizar nós gerenciados com modelos de execução](launch-templates.md). **Importante** Para implantar um grupo de nós nas sub-redes do AWS Outposts, do AWS Wavelength ou das zonas locais da AWS, não passe as sub-redes do AWS Outposts, do AWS Wavelength ou das zonas locais da AWS ao criar o cluster. É necessário especificar as sub-redes no exemplo a seguir. Para obter mais informações, consulte [Create a nodegroup from a config file](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) (Criar um grupo de nós em um arquivo de configuração) e [Config file schema](https://eksctl.io/usage/schema/) (Esquema de arquivo de configuração) na documentação do `eksctl`. Substitua *region-code* pela região da AWS em que seu cluster se encontra. ``` cat >bottlerocket.yaml < Este tópico descreve como iniciar grupos do Auto Scaling de nós Windows que são registrados no seu cluster do Amazon EKS. Depois que os nós ingressam no cluster, você pode implantar aplicações do Kubernetes neles. **Importante** Os nós do Amazon EKS são instâncias padrão do Amazon EC2, e você é cobrado por eles com base nos preços normais das instâncias do Amazon EC2. Para obter mais informações, consulte [Definição de preço do Amazon EC2](https://aws.amazon.com/ec2/pricing/). É possível iniciar nós do Windows em clusters estendidos do Amazon EKS no AWS Outposts, mas não pode iniciá-los em clusters locais no AWS Outposts. Para obter mais informações, consulte [Implantar o Amazon EKS on-premises com o AWS Outposts](eks-outposts.md). Habilite o suporte ao Windows para o cluster. Recomendamos revisar considerações importantes antes de iniciar um grupo de nós do Windows. Para obter mais informações, consulte [Habilitar o suporte ao Windows](windows-support.md#enable-windows-support). É possível iniciar nós do autogerenciados do Windows com uma das seguintes opções: + [`eksctl`](#eksctl_create_windows_nodes) + [Console de gerenciamento da AWS](#console_create_windows_nodes) ## `eksctl` **Iniciar nós autogerenciados do Windows usando `eksctl`** Este procedimento exige que você instale o `eksctl` e que a versão do `eksctl` seja pelo menos a `0.215.0`. É possível verificar a versão com o comando a seguir. ``` 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`. **nota** Este procedimento funciona apenas para clusters que foram criados com o `eksctl`. 1. (Opcional) Se a política do IAM gerenciada **AmazonEKS\$1CNI\$1Policy** (se você tiver um cluster do `IPv4`) ou a política *AmazonEKS\$1CNI\$1IPv6\$1Policy* (que você [mesmo criou](cni-iam-role.md#cni-iam-role-create-ipv6-policy) caso tenha um cluster do `IPv6`) estiver anexada ao [perfil 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. Esse procedimento pressupõe que você tem um cluster existente. Se você ainda não tiver um cluster do Amazon EKS e um grupo de nós do Amazon Linux ao qual adicionar um grupo de nós do Windows, recomendamos seguir [Conceitos básicos do Amazon EKS: `eksctl`](getting-started-eksctl.md). Este guia fornece um passo a passo completo sobre como criar um cluster do Amazon EKS com nós do Amazon Linux. Crie seu grupo de nós com o comando a seguir. Substitua *region-code* pela região da AWS em que seu cluster se encontra. Substitua *my-cluster* pelo nome do cluster. O nome só pode conter caracteres alfanuméricos (sensíveis a maiúsculas e minúsculas) e hifens. Ele deve começar com um caractere alfanumérico e não pode ter mais de 100 caracteres. O nome deve ser exclusivo na região da AWS e na conta da AWS em que você está criando o cluster. Substitua *ng-windows* por um nome para 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. É possível substituir *2019* por `2022` usar o Windows Server 2022 ou por `2025` usar o Windows Server 2025. Substitua o restante dos valores de exemplo por seus próprios valores. **Importante** Para implantar um grupo de nós nas sub-redes AWS Outposts, AWS Wavelength ou AWS Local Zone, não passe as sub-redes AWS Outposts, Wavelength ou Local Zone ao criar o cluster. Crie o grupo de nós com um arquivo de configuração, especificando as sub-redes AWS Outposts, Wavelength ou Local Zone. Para obter mais informações, consulte [Criar um grupo de nós em um arquivo de configuração](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) e [Esquema de arquivo Config](https://eksctl.io/usage/schema/) na documentação do `eksctl`. ``` eksctl create nodegroup \ --region region-code \ --cluster my-cluster \ --name ng-windows \ --node-type t2.large \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --managed=false \ --node-ami-family WindowsServer2019FullContainer ``` **nota** Se os nós não conseguirem juntar-se ao cluster, consulte [Falha nos nós ao ingressar no cluster](troubleshooting.md#worker-node-fail) no manual Troubleshooting (Solução de problemas). Para ver as opções disponíveis para os comandos `eksctl`, insira o comando a seguir. ``` eksctl command -help ``` Veja um exemplo de saída abaixo. Várias linhas são emitidas enquanto os nós são criados. Uma das últimas linha de saída é o exemplo de linha a seguir. ``` [✔] created 1 nodegroup(s) in cluster "my-cluster" ``` 1. (Opcional) Implante uma [aplicação de exemplo](sample-deployment.md) para testar o cluster e os nós do Windows. 1. 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). ## Console de gerenciamento da AWS **Pré-requisitos** + Um cluster existente do Amazon EKS e um grupo de nós do Linux. Se você não tiver esses recursos, recomendamos que os crie usando um de nossos guias em [Começar a usar o Amazon EKS](getting-started.md). Estes guias descrevem como criar um cluster do Amazon EKS com nós Linux. + Uma VPC e um grupo de segurança existentes que atendem aos requisitos de um cluster do Amazon EKS. Para obter mais informações, consulte [Exibir os requisitos de rede do Amazon EKS para VPC e sub-redes](network-reqs.md) e [Exibir os requisitos para grupos de segurança do Amazon EKS em clusters](sec-group-reqs.md). Os guias em [Começar a usar o Amazon EKS](getting-started.md) criam uma VPC que atende aos requisitos. Como alternativa, você também pode seguir [Criar uma Amazon VPC para seu cluster do Amazon EKS](creating-a-vpc.md) para criar uma manualmente. + Um cluster existente do Amazon EKS que usa uma VPC e um grupo de segurança que atendam aos requisitos de um cluster do Amazon EKS. Para obter mais informações, consulte [Criar um cluster do Amazon EKS](create-cluster.md). Se você tiver sub-redes na região AWS em que AWS Outposts, AWS Wavelength ou AWS Local Zones estiverem ativados, essas sub-redes não deverão ter sido transmitidas quando você criou o cluster. **Etapa 1: Inicie nós Windows autogerenciados usando o Console de gerenciamento da AWS ** 1. Aguarde até que o status do cluster seja exibido como `ACTIVE`. Se você executar os nós antes que o cluster esteja ativo, o registro dos nós no cluster falhará, e você terá de executá-los novamente. 1. Abra o [console do AWS CloudFormation](https://console.aws.amazon.com/cloudformation/). 1. Selecione **Criar pilha**. 1. Em **Specify template**, selecione **URL do modelo do Amazon S3**. 1. Copie a URL a seguir e cole-a no **URL do Amazon S3**. ``` https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-02-09/amazon-eks-windows-nodegroup.yaml ``` 1. Escolha **Next** (Avançar) duas vezes. 1. Na página **Quick create stack** (Criar pilha rapidamente), insira os parâmetros a seguir de forma adequada: + **Nome da pilha**: escolha um nome para a pilha do AWS CloudFormation. Por exemplo, você pode chamar de `my-cluster-nodes`. + **ClusterName**: insira o nome que você usou ao criar o cluster do Amazon EKS. **Importante** Esse nome deve corresponder exatamente ao nome que você usou na [Etapa 1: criar seu cluster do Amazon EKS](getting-started-console.md#eks-create-cluster). Caso contrário, seus nós não poderão ser incorporados ao cluster. + **ClusterControlPlaneSecurityGroup**: Escolha o grupo de segurança na saída do AWS CloudFormation que você gerou ao criar sua [VPC](creating-a-vpc.md). As etapas a seguir mostram um método de recuperar o grupo aplicável. 1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Escolha o nome do cluster. 1. Escolha a guia **Redes**. 1. Use o valor de **Additional security group** (Grupos de segurança adicionais) como referência ao selecionar na lista suspensa **ClusterControlPlaneSecurityGroup**. + **NodeGroupName**: insira um nome para o grupo de nós. Esse nome poderá ser usado superiormente para identificar o grupo de nós do Auto Scaling que for criado para os 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. + **NodeAutoScalingGroupMinSize**: digite o número mínimo de nós para o qual o grupo Auto Scaling de nós pode ser escalado. + **NodeAutoScalingGroupDesiredCapacity**: insira o número desejado de nós para o qual dimensionar quando a pilha for criada. + **NodeAutoScalingGroupMaxSize**: digite o número máximo de nós para o qual o grupo Auto Scaling de nós pode ser escalado. + **NodeInstanceType**: escolha um tipo de instância para os nós. Para obter mais informações, consulte [Escolher um tipo de instância de nó do Amazon EC2 ideal](choosing-instance-type.md). **nota** Os tipos de instâncias compatíveis com a versão mais recente do [plugin Amazon VPC CNI para o Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) estão listados em [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) no GitHub. Talvez seja necessário atualizar a versão da CNI para usar os tipos de instâncias compatíveis mais recentes. Para obter mais informações, consulte [Atribuir IPs a pods com a CNI da Amazon VPC](managing-vpc-cni.md). + **NodeImageIdSSMParam**: pré-preenchido com o parâmetro do Amazon EC2 Systems Manager do ID da principal AMI do Windows otimizada para Amazon EKS recomendada atualmente. Para usar a versão completa do Windows, substitua *Core* por `Full`. + **NodeImageId**: (opcional) se estiver usando sua própria AMI personalizada (em vez da AMI otimizada do Amazon EKS), insira um ID de AMI de nó para a região da AWS. Se você especificar um valor para este campo, ele substituirá todos os valores no campo **NodeImageIdSSMParam**. + **NodeVolumeSize**: especifique um tamanho de volume raiz para os nós, em GiB. + **KeyName**: insira o nome de um par de chaves SSH do Amazon EC2; que você pode usar para conectar-se usando SSH em seus nós, depois de iniciados. 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, consulte [Pares de chaves do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html), no *Guia do usuário do Amazon EC2*. **nota** Se você não fornecer um par de chaves aqui, a pilha do AWS CloudFormation não será criada. + **BootstrapArguments**: especifique argumentos opcionais para passar para o script de bootstrap do nó, como argumentos `kubelet` adicionais usando `-KubeletExtraArgs`. + **DisableIMDSv1**: por padrão, cada nó oferece suporte ao serviço de metadados de instância versão 1 (IMDSv1) e IMDSv2. É possível desabilitar IMDSv1. Para evitar que nós e pods futuros no grupo de nós usem o MDSv1, defina **DisableIMDSv1** como **true**. Para obter mais informações, consulte [Configuring the instance metadata service](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) (Configurar o serviço de metadados de instância). + **VpcId**: selecione o ID para a [VPC](creating-a-vpc.md) que você criou em . + **NodeSecurityGroups**: selecione o grupo de segurança que foi criado para o grupo de nós do Linux quando você criou a [VPC](creating-a-vpc.md). Se os nós do Linux tiverem mais de um grupo de segurança anexado a eles, especifique todos eles. Isso serve, por exemplo, quando o grupo de nós do Linux foi criado com `eksctl`. + **Subnets** (Sub-redes): escolha as sub-redes que você criou. Se você criou sua VPC usando as etapas em [Criar uma Amazon VPC para seu cluster do Amazon EKS](creating-a-vpc.md), especifique apenas as sub-redes privadas dentro da VPC para que seus nós sejam iniciados. **Importante** Se alguma das sub-redes for pública, ela deverá ter a atribuição automática de atribuição de endereço IP público habilitada. Se a configuração não estiver habilitada para a sub-rede pública, os nós implantados nessa sub-rede pública não receberão um endereço IP público e não poderão se comunicar com o cluster nem com outros produtos da AWS. Se a sub-rede tiver sido implantada antes de 26 de março de 2020 usando um dos [modelos de VPC do Amazon EKS AWS CloudFormation](creating-a-vpc.md) ou usando `eksctl`, a atribuição automática de endereço IP público estará desativada para sub-redes públicas. Para obter informações sobre como habilitar a atribuição de endereço IP público para uma sub-rede, 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 o nó for implantado em uma sub-rede privada, ele poderá se comunicar com o cluster e com outros produtos da AWS por um gateway NAT. Se as sub-redes não tiverem acesso à Internet, certifique-se de que você está ciente das considerações e etapas adicionais em [Implantar clusters privados com acesso limitado à Internet](private-clusters.md). Se você selecionar as sub-redes AWS Outposts, Wavelength ou Local Zone, as sub-redes não deverão ter sido passadas quando você criou o cluster. 1. Confirme que a pilha pode criar recursos do IAM e escolha **Create stack** (Criar pilha). 1. Quando a criação da pilha for concluída, selecione-a no console e escolha **Outputs (Saídas)**. 1. Registre o valor de **NodeInstanceRole** para o grupo de nós criado. Você precisará dele ao configurar os nós de Windows do Amazon EKS. **Etapa 2: habilite os nós para participar do cluster** 1. Verifique se você já tem um `aws-auth` `ConfigMap`. ``` kubectl describe configmap -n kube-system aws-auth ``` 1. Se você receber um `aws-auth` `ConfigMap`, atualize-o conforme necessário. 1. Abra o `ConfigMap` para edição. ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. Adicione novas `mapRoles` entradas conforme necessário. Defina os valores `rolearn` para os valores **NodeInstanceRole** que você registrou no procedimento anterior. ``` [...] data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - eks:kube-proxy-windows [...] ``` 1. Salve o arquivo e saia do seu editor de texto. 1. Se você recebeu um erro informando "`Error from server (NotFound): configmaps "aws-auth" not found`, aplique o estoque`ConfigMap`. 1. Faça download do mapa de configuração. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml ``` 1. No arquivo `aws-auth-cm-windows.yaml`, configure os valores `rolearn` para os valores **NodeInstanceRole** aplicáveis que você registrou nos procedimentos anteriores. É possível fazer isso com um editor de texto ou substituindo os valores de exemplo e executando o seguinte comando: ``` sed -i.bak -e 's||my-node-linux-instance-role|' \ -e 's||my-node-windows-instance-role|' aws-auth-cm-windows.yaml ``` **Importante** Não modifique outras linhas do arquivo. Não use o mesmo perfil do IAM para nós do Windows e Linux. 1. Aplique a configuração. Esse comando pode levar alguns minutos para ser concluído. ``` kubectl apply -f aws-auth-cm-windows.yaml ``` 1. Observe o status de seus nós e aguarde até que eles atinjam o status `Ready`. ``` kubectl get nodes --watch ``` Insira `Ctrl`\$1`C` para retornar a um prompt de shell. **nota** Se você receber qualquer erro de autorização ou de tipo de recurso, consulte [Acesso negado ou não autorizado (`kubectl`)](troubleshooting.md#unauthorized) no tópico de solução de problemas. 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. **Etapa 3: Ações adicionais** 1. (Opcional) Implante uma [aplicação de exemplo](sample-deployment.md) para testar o cluster e os nós do Windows. 1. (Opcional) Se a política do IAM gerenciada **AmazonEKS\$1CNI\$1Policy** (caso você tenha um cluster `IPv4`) ou *AmazonEKS\$1CNI\$1IPv6\$1Policy* (que você [criou de forma independente](cni-iam-role.md#cni-iam-role-create-ipv6-policy), caso tenha um cluster `IPv6`) estiver anexada ao [perfil do IAM dos nós do Amazon EKS](create-node-role.md), recomendamos atribuí-la a um perfil do IAM que possa ser associado à conta de serviço do Kubernetes `aws-node`. Para obter mais informações, consulte [Configurar o plug-in CNI da Amazon VPC para usar IRSA](cni-iam-role.md). 1. 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). # Criar nós autogerenciados do Ubuntu Linux **nota** Os grupos de nós gerenciados podem oferecer algumas vantagens para seu caso de uso. Para obter mais informações, consulte [Simplificar o ciclo de vida dos nós com grupos de nós gerenciados](managed-node-groups.md). Este tópico descreve como iniciar grupos do Auto Scaling de nós do [Ubuntu no Amazon Elastic Kubernetes Service (EKS)](https://cloud-images.ubuntu.com/aws-eks/) ou [Ubuntu Pro no Amazon Elastic Kubernetes Service (EKS)](https://ubuntu.com/blog/ubuntu-pro-for-eks-is-now-generally-available) que se registram no cluster Amazon EKS. O Ubuntu e o Ubuntu Pro para EKS são baseados no Ubuntu Minimal LTS oficial, incluem o kernel personalizado da AWS, que é desenvolvido em conjunto com a AWS, e foram criados especificamente para o EKS. O Ubuntu Pro adiciona cobertura de segurança adicional ao oferecer suporte a períodos de suporte estendidos do EKS, livepatch do kernel, conformidade com FIPS e a capacidade de executar contêineres Pro ilimitados. Depois que os nós ingressam no cluster, você pode implantar aplicações em contêiner neles. Para obter mais informações, via documentação do [Ubuntu em AWS](https://documentation.ubuntu.com/aws/en/latest/) e [o suporte a AMIs personalizadas](https://eksctl.io/usage/custom-ami-support/) na documentação `eksctl`. **Importante** Os nós do Amazon EKS são instâncias padrão do Amazon EC2, e você é cobrado por eles com base nos preços normais das instâncias do Amazon EC2. Para obter mais informações, consulte [Definição de preço do Amazon EC2](https://aws.amazon.com/ec2/pricing/). Você pode iniciar nós do Ubuntu em clusters estendidos do Amazon EKS no AWS Outposts, mas não pode iniciá-los em clusters locais no AWS Outposts. Para obter mais informações, consulte [Implantar o Amazon EKS on-premises com o AWS Outposts](eks-outposts.md). Você pode implantar em instâncias do Amazon EC2 com processadores `x86` ou Arm. No entanto, as instâncias que têm chips Inferentia talvez precisem instalar o [SDK do Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/) primeiro. 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 `eksctl`, consulte [Instalação](https://eksctl.io/installation) na documentação do `eksctl`. OBSERVAÇÃO: esse procedimento apenas funciona para clusters que foram criados com o `eksctl`. 1. Copie o conteúdo a seguir para o seu dispositivo. Substitua o `my-cluster` pelo nome do cluster. O nome só pode conter caracteres alfanuméricos (sensíveis a maiúsculas e minúsculas) e hifens. Ele deve começar com um caractere alfabético e não pode ter mais de 100 caracteres. Substitua `ng-ubuntu` por um nome para o 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. Para implantar em instâncias do Arm, substitua `m5.large` por um tipo de instância Arm. Substitua `my-ec2-keypair-name` pelo nome de um par de chaves SSH do Amazon EC2; que você pode usar para conectar-se usando SSH em seus nós, depois de iniciados. Se ainda não tiver um par de chaves do Amazon EC2, você poderá criar um no Console de gerenciamento da AWS. Para obter mais informações, consulte [Pares de chaves do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html), no Guia do usuário do Amazon EC2. Substitua todos os valores de exemplo restantes por seus próprios valores. Depois de fazer as substituições, execute o comando modificado para criar o arquivo `ubuntu.yaml`. **Importante** Para implantar um grupo de nós nas sub-redes do AWS Outposts, do AWS Wavelength ou das zonas locais da AWS, não passe as sub-redes do AWS Outposts, do AWS Wavelength ou das zonas locais da AWS ao criar o cluster. É necessário especificar as sub-redes no exemplo a seguir. Para obter mais informações, consulte [Create a nodegroup from a config file](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) (Criar um grupo de nós em um arquivo de configuração) e [Config file schema](https://eksctl.io/usage/schema/) (Esquema de arquivo de configuração) na documentação do `eksctl`. Substitua *region-code* pela região da AWS em que seu cluster se encontra. ``` cat >ubuntu.yaml < Quando uma nova AMI otimizada para Amazon EKS for lançada, considere substituir os nós no grupo de nós autogerenciados pela nova AMI. Da mesma forma, se você tiver atualizado a versão do Kubernetes para o cluster do Amazon EKS, atualize os nós para usá-los com a mesma versão do Kubernetes. **Importante** Este tópico aborda as atualizações do nó para nós autogerenciados. Se você estiver usando [grupos de nós gerenciados](managed-node-groups.md), consulte [Atualizar um grupo de nós gerenciados para seu cluster](update-managed-node-group.md). Há duas maneiras básicas de atualizar grupos de nós autogerenciados em seus clusters para usar uma nova AMI: ** [Migrar aplicações para um novo grupo de nós](migrate-stack.md) ** Crie um novo grupo de nós e migre os pods para esse grupo. A migração para um novo grupo de nós é mais simples do que simplesmente atualizar a ID da AMI em uma pilha existente do AWS CloudFormation. Isso ocorre porque o processo de migração [marca](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) o grupo de nós antigo como `NoSchedule` e drena os nós depois que uma nova pilha está pronta para aceitar a workload do pod existente. ** [Atualizar uma pilha de nós do AWS CloudFormation](update-stack.md) ** Atualize a pilha do AWS CloudFormation para um grupo de nós existente para usar a nova AMI. Esse método não é compatível com grupos de nós que foram criados com o `eksctl`. # Migrar aplicações para um novo grupo de nós Este tópico descreve como criar um novo grupo de nós, migrar facilmente as aplicações existentes para o novo grupo e remover o grupo de nós antigo do cluster. Você pode migrar para um novo grupo de nós usando o `eksctl` ou o Console de gerenciamento da AWS. + [`eksctl`](#eksctl_migrate_apps) + [Console de gerenciamento da AWS e AWS CLI](#console_migrate_apps) ## `eksctl` **Migre suas aplicações para um novo grupo de nós com `eksctl` ** Para obter mais informações sobre o uso do eksctl para migração, consulte [Unmanaged nodegroups](https://eksctl.io/usage/nodegroup-unmanaged/) (Grupos de nós não gerenciados) na documentação do `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`. **nota** Este procedimento funciona apenas para clusters e grupos de nós que foram criados com o `eksctl`. 1. Recupere o nome dos grupos de nós existentes, substituindo *my-cluster* pelo nome do cluster. ``` eksctl get nodegroups --cluster=my-cluster ``` Veja abaixo um exemplo de saída. ``` CLUSTER NODEGROUP CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID default standard-nodes 2019-05-01T22:26:58Z 1 4 3 t3.medium ami-05a71d034119ffc12 ``` 1. Inicie um novo grupo de nós com `eksctl` usando o comando a seguir. No comando, substitua cada *valor de exemplo* por seus próprios valores. O número da versão não pode ser superior à versão do Kubernetes do ambiente de gerenciamento. Além disso, não pode ultrapassar duas versões secundárias anteriores à versão do Kubernetes do ambiente de gerenciamento. Recomendamos usar a mesma versão do ambiente de gerenciamento. 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). Para bloquear o acesso do pod ao IMDS, adicione a opção `--disable-pod-imds` ao comando a seguir. **nota** Para obter mais sinalizadores disponíveis e suas descrições, consulte https://eksctl.io/. ``` eksctl create nodegroup \ --cluster my-cluster \ --version 1.35 \ --name standard-nodes-new \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --managed=false ``` 1. Quando o comando anterior for concluído, verifique se todos os nós atingiram o estado `Ready` com o seguinte comando: ``` kubectl get nodes ``` 1. Exclua cada grupo de nós original usando o comando a seguir. No comando, substitua cada *valor de exemplo* pelos nomes do seu cluster e grupo de nós: ``` eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old ``` ## Console de gerenciamento da AWS e AWS CLI **Migre suas aplicações para um novo grupo de nós com a CLI Console de gerenciamento da AWS e AWS** 1. Inicie um novo grupo de nós seguindo as etapas descritas em [Criar nós autogerenciados do Amazon Linux](launch-workers.md). 1. Quando a criação da pilha for concluída, selecione-a no console e escolha **Outputs (Saídas)**. 1. Registre o valor de **NodeInstanceRole** para o grupo de nós criado. Você precisará dele para adicionar os novos nós do Amazon EKS ao cluster. **nota** Se você anexou qualquer outra política do IAM ao perfil do IAM do antigo grupo de nós, anexe essas mesmas políticas ao perfil do IAM do novo grupo de nós para manter essa funcionalidade no novo grupo. Isso se aplica a você se você adicionou permissões para o [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) do Kubernetes, por exemplo. 1. Atualize os grupos de segurança para ambos os grupos de nós, para que eles possam se comunicar um com o outro. Para obter mais informações, consulte [Exibir os requisitos para grupos de segurança do Amazon EKS em clusters](sec-group-reqs.md). 1. Registre os IDs do grupo de segurança de ambos os grupos de nós. Isso é mostrado como o valor **NodeSecurityGroup** nas saídas da pilha do AWS CloudFormation. Você pode usar os seguintes comandos da CLI AWS para obter os IDs de grupo de segurança dos nomes de pilha. Nesses comandos, `oldNodes` é o nome da pilha do AWS CloudFormation para a pilha de nós mais antiga e `newNodes` é o nome da pilha para a qual você está migrando. Substitua cada *valor de exemplo* por seus próprios valores. ``` oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) ``` 1. Adicione regras de entrada a cada grupo de segurança do nó para que eles aceitem o tráfego uns dos outros. Os seguintes comandos da CLI AWS adicionam regras de entrada a cada grupo de segurança que permitem todo o tráfego em todos os protocolos do outro grupo de segurança. Essa configuração permite que os pods em cada grupo de nós se comuniquem entre si enquanto estiver migrando a workload para o novo grupo. ``` aws ec2 authorize-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 authorize-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1 ``` 1. Edite o configmap do `aws-auth` para mapear o novo perfil da instância do nó no RBAC. ``` kubectl edit configmap -n kube-system aws-auth ``` Adicione uma nova entrada `mapRoles` para o novo grupo do nós. ``` apiVersion: v1 data: mapRoles: | - rolearn: ARN of instance role (not instance profile) username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes> - rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes ``` Substitua o snippet *ARN do perfil da instância (não do perfil da instância)* pelo valor **NodeInstanceRole** que você registrou em uma [etapa anterior](#node-instance-role-step). Então, salve e feche o arquivo para aplicar o configmap atualizado. 1. Observe o status dos nós e aguarde até que os novos nós ingressem no cluster e atinjam o status `Ready`. ``` kubectl get nodes --watch ``` 1. (Opcional) Se você estiver usando o [Cluster Autoscaler do Kubernetes](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), reduza a implantação para zero (0) réplica para evitar ações de escalabilidade conflitantes. ``` kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system ``` 1. Use o comando a seguir para aplicar taint em cada um dos nós que deseja remover com `NoSchedule`. Isso serve para que novos pods não sejam agendados ou reagendados nos nós que você está substituindo. Para obter mais informações, consulte [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) na documentação do Kubernetes. ``` kubectl taint nodes node_name key=value:NoSchedule ``` Se você estiver atualizando os nós para uma nova versão do Kubernetes, será possível identificar e aplicar taints em todos os nós de determinada versão do Kubernetes (neste caso, `1.33`) com o trecho de código a seguir. O número da versão não pode ser superior à versão do Kubernetes do ambiente de gerenciamento. Também não pode ultrapassar duas versões secundárias anteriores à versão do Kubernetes do ambiente de gerenciamento. Recomendamos usar a mesma versão do ambiente de gerenciamento. ``` K8S_VERSION=1.33 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Tainting $node" kubectl taint nodes $node key=value:NoSchedule done ``` 1. Determine o provedor DNS do cluster. ``` kubectl get deployments -l k8s-app=kube-dns -n kube-system ``` Veja abaixo um exemplo de saída. O cluster está usando o CoreDNS para a resolução de DNS, mas o cluster pode retornar `kube-dns`. ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m ``` 1. Se a implantação atual estiver executando menos de duas réplicas, expanda-a para duas réplicas. Substitua *coredns* por `kubedns` se a saída do comando anterior tiver retornado isso. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. Drene cada um dos nós que você deseja remover do cluster com o seguinte comando: ``` kubectl drain node_name --ignore-daemonsets --delete-local-data ``` Se você estiver atualizando os nós para uma nova versão do Kubernetes, identifique e drene todos os nós de uma determinada versão do Kubernetes (neste caso, *1.33*) com o trecho de código a seguir. ``` K8S_VERSION=1.33 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Draining $node" kubectl drain $node --ignore-daemonsets --delete-local-data done ``` 1. Depois que os antigos nós forem esvaziados, revogue as regras de entrada do grupo de segurança que você autorizou anteriormente. Em seguida, exclua a pilha do AWS CloudFormation para encerrar as instâncias. **nota** Se você anexou alguma política IAM adicional à perfil IAM do grupo de nós antigo, como a adição de permissões para o [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), desanexe essas políticas adicionais do perfil antes de excluir a pilha do AWS CloudFormation. 1. Revogue as regras de entrada criadas anteriormente para os grupos de segurança do nó. Nesses comandos, `oldNodes` é o nome da pilha do AWS CloudFormation para sua pilha de nós mais antiga e `newNodes` é o nome da pilha para a qual você está migrando. ``` oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) aws ec2 revoke-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 revoke-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1 ``` 1. Abra o console do [AWS CloudFormation](https://console.aws.amazon.com/cloudformation/). 1. Selecione a pilha antiga do nó. 1. Escolha **Excluir**. 1. Na caixa de diálogo de confirmação **Delete stack** (Excluir pilha), escolha **Delete stack** (Excluir pilha). 1. Edite o configmap do `aws-auth` para remover o antigo perfil da instância do nó do RBAC. ``` kubectl edit configmap -n kube-system aws-auth ``` Exclua a entrada `mapRoles` do antigo grupo nós. ``` apiVersion: v1 data: mapRoles: | - rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-W70725MZQFF8 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: arn:aws:iam::111122223333:role/nodes-1-15-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes> ``` Salve e feche o arquivo para aplicar o configmap atualizado. 1. (Opcional) Se você estiver usando o [Autoscaler do cluster](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) do Kubernetes, reduza a implantação para uma réplica. **nota** Você também deve etiquetar o novo grupo do Auto Scaling corretamente (por exemplo, `k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster`) e atualizar o comando da implantação do Cluster Autoscaler de modo a apontar para o grupo do Auto Scaling recém-marcado. Para obter mais informações, consulte [Autoscaler do cluster na AWS](https://github.com/kubernetes/autoscaler/tree/cluster-autoscaler-release-1.3/cluster-autoscaler/cloudprovider/aws). ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (Opcional) Verifique se você está usando a versão mais recente do [plugin CNI da Amazon VPC para Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s). Talvez seja necessário atualizar a versão da CNI para usar os tipos de instâncias compatíveis mais recentes. Para obter mais informações, consulte [Atribuir IPs a pods com a CNI da Amazon VPC](managing-vpc-cni.md). 1. Se o seu cluster estiver usando o `kube-dns` para resolução de DNS (consulte [[migrate-determine-dns-step]](#migrate-determine-dns-step)), dimensione a implantação do `kube-dns` para uma réplica. ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` # Atualizar uma pilha de nós do AWS CloudFormation Este tópico descreve como você pode atualizar uma pilha de nós autogerenciados do AWS CloudFormation existente com uma nova AMI. Você pode usar esse procedimento para atualizar os nós para uma nova versão do Kubernetes após uma atualização do cluster. Senão, é possível atualizar para a AMI otimizada do Amazon EKS mais recente para uma versão existente do Kubernetes. **Importante** Este tópico aborda as atualizações do nó para nós autogerenciados. Para obter informações sobre como usar [Simplificar o ciclo de vida dos nós com grupos de nós gerenciados](managed-node-groups.md), consulte [Atualizar um grupo de nós gerenciados para seu cluster](update-managed-node-group.md). O modelo padrão mais recente do Amazon EKS node AWS CloudFormation está configurado para iniciar uma instância com a nova AMI em seu cluster antes de remover uma antiga, uma de cada vez. Essa configuração garante que você esteja com a contagem desejada do grupo do Auto Scaling de instâncias ativas no cluster durante a implantação da atualização. **nota** Esse método não é compatível com grupos de nós que foram criados com o `eksctl`. Se você criou o cluster ou o grupo de nós com o `eksctl`, consulte [Migrar aplicações para um novo grupo de nós](migrate-stack.md). 1. Determine o provedor DNS de seu cluster. ``` kubectl get deployments -l k8s-app=kube-dns -n kube-system ``` Veja abaixo um exemplo de saída. O cluster está usando o CoreDNS para a resolução de DNS, mas, em vez disso, o cluster pode retornar `kube-dns`. Sua saída pode parecer diferente dependendo da versão do `kubectl` que você está usando. ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m ``` 1. Se a implantação atual estiver executando menos de duas réplicas, expanda-a para duas réplicas. Substitua *coredns* por `kube-dns` se a saída do comando anterior tiver retornado isso. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. (Opcional) Se você estiver usando o [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) do Kubernetes, reduza a implantação para zero (0) réplica para evitar ações de escalabilidade conflitantes. ``` kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system ``` 1. Determine o tipo de instância e a contagem de instâncias desejada do grupo de nós atual. Esses valores são inseridos posteriormente quando você atualiza o modelo do AWS CloudFormation para o grupo. 1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/. 1. No painel de navegação à esquerda, escolha **Launch Configurations** (Configurações de execução) e anote o tipo de instância da configuração de execução do nó existente. 1. No painel de navegação à esquerda, escolha **Grupos do Auto Scaling** e observe a contagem de instâncias **Desejadas** para o grupo do Auto Scaling do nó existente. 1. Abra o console do [AWS CloudFormation](https://console.aws.amazon.com/cloudformation/). 1. Selecione a pilha do grupo de nós e escolha **Atualizar**. 1. Selecione **Substituir modelo atual** e selecione **URL do Amazon S3**. 1. Para o **URL do Amazon S3**, cole o seguinte URL na área de texto para garantir que você esteja usando a versão mais recente do modelo do node AWS CloudFormation. Depois, escolha **Próximo**: ``` https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml ``` 1. Na página **Especificar detalhes da pilha**, preencha os parâmetros a seguir e escolha **Próximo**: + **NodeAutoScalingGroupDesiredCapacity**: insira a contagem de instâncias desejada que você registrou em uma [etapa anterior](#existing-worker-settings-step). Ou insira o novo número desejado de nós para o qual escalar quando a pilha for criada. + **NodeAutoScalingGroupMaxSize**: digite o número máximo de nós para o qual o grupo Auto Scaling de nós pode ser aumentado. Esse valor deve ser pelo menos um nó a mais do que a capacidade desejada. Assim, você pode realizar uma atualização contínua dos nós sem reduzir a contagem de nós durante a atualização. + **NodeInstanceType**: escolha o tipo de instância registrada em uma [etapa anterior](#existing-worker-settings-step). Se preferir, escolha um tipo de instância diferente para os nós. Antes de escolher um tipo de instância diferente, consulte [Escolha um tipo ideal de instância de nó do Amazon EC2](choosing-instance-type.md). Cada tipo de instância do Amazon EC2 suporta um número máximo de interfaces elásticas de rede (interfaces de rede) e cada interface de rede oferece suporte a um número máximo de endereços IP. Como cada nó de processamento e pod recebe seu próprio endereço IP, é importante escolher um tipo de instância que ofereça suporte ao número máximo de pods que você deseja executar em cada nó do Amazon EC2. Para obter uma lista do número de interfaces de rede e endereços IP compatíveis com tipos de instância, consulte [Endereços IP por interface de rede por tipo de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI). Por exemplo, o tipo de instância `m5.large` é compatível com um máximo de trinta endereços IP para o nó de processamento e pods. **nota** Os tipos de instâncias compatíveis com a versão mais recente do [plugin CNI da Amazon VPC para Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) estão exibidos em [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) no GitHub. Talvez seja necessário atualizar o plug-in CNI da Amazon VPC para Kubernetes para usar os tipos de instâncias compatíveis mais recentes. Para obter mais informações, consulte [Atribuir IPs a pods com a CNI da Amazon VPC](managing-vpc-cni.md). **Importante** Alguns tipos de instância podem não estar disponíveis em todas as regiões da AWS. + **NodeImageIdSSMParam**: o parâmetro do Amazon EC2 Systems Manager do ID da AMI para o qual você deseja atualizar. O valor a seguir usa a AMI otimizada para o Amazon EKS mais recente para a versão do Kubernetes `1.35`. ``` /aws/service/eks/optimized-ami/1.35/amazon-linux-2/recommended/image_id ``` É possível substituir *1.35* por uma [versão da plataforma](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) que seja a mesma. Ou deve ser até uma versão anterior à versão do Kubernetes em execução no ambiente de gerenciamento. Recomendamos que você mantenha seus nós na mesma versão do ambiente de gerenciamento. Você também pode substituir *o amazon-linux-2* por um tipo diferente de AMI. Para obter mais informações, consulte [Recuperar IDs de AMI do Amazon Linux recomendadas](retrieve-ami-id.md). **nota** O uso do parâmetro do Amazon EC2 Systems Manager permite atualizar os nós no futuro sem precisar pesquisar e especificar um ID de AMI. Se a pilha do AWS CloudFormation estiver usando esse valor, qualquer atualização da pilha sempre executará a AMI otimizada para Amazon EKS recomendada para a versão específica do Kubernetes. Isso se aplica mesmo que você não altere nenhum valor no template. + **NodeImageId**: para usar sua própria AMI personalizada, insira o ID da AMI a ser usada. **Importante** Esse valor substitui qualquer valor especificado para **NodeImageIdSSMParam**. Se você quiser usar o valor de **NodeImageIdSSMParam**, verifique se o valor de **NodeImageId** está em branco. + **DisableIMDSv1**: por padrão, cada nó oferece suporte ao serviço de metadados de instância versão 1 (IMDSv1) e IMDSv2. No entanto, você pode desabilitar o IMDSv1. Selecione **true** se você não quiser que nós ou pods agendados no grupo de nós usem IMDSv1. Para obter mais informações, consulte [Configurar o serviço de metadados da instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). Você implementou perfis do IAM para contas de serviço e atribuiu as permissões necessárias diretamente a todos os pods que exigem acesso aos serviços da AWS. Dessa forma, nenhum pod no cluster precisa acessar o IMDS por outros motivos, como recuperar a região atual da AWS. Então, você também pode desabilitar o acesso ao IMDSv2 para pods que não usam redes de host. 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). 1. (Opcional) Na página **Opções**, marque os recursos da sua pilha. Escolha **Próximo**. 1. Na página **Review** (Revisão), analise suas informações, confirme se a pilha pode criar recursos do IAM e selecione **Update stack** (Atualizar pilha). **nota** A atualização de cada nó no cluster leva vários minutos. Aguarde até que a atualização de todos os nós seja concluída antes de executar as próximas etapas. 1. Se o seu provedor de DNS do cluster for `kube-dns`, reduza a escala horizontalmente da implantação de `kube-dns` para uma réplica. ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` 1. (Opcional) Se você estiver usando o [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) do Kubernetes, reduza a implantação para a quantidade de réplicas desejada. ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (Opcional) Verifique se você está usando a versão mais recente do [plugin CNI da Amazon VPC para Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s). Talvez seja necessário atualizar o plug-in CNI da Amazon VPC para Kubernetes para usar os tipos de instâncias compatíveis mais recentes. Para obter mais informações, consulte [Atribuir IPs a pods com a CNI da Amazon VPC](managing-vpc-cni.md).