**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. # 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).