**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 Amazon Linux no AWS Outposts
**Importante**
Os clusters locais do Amazon EKS no Outposts fornecem suporte apenas nós criados com base nas seguintes AMIs do Amazon Linux 2023 otimizadas para o Amazon EKS:
Amazon Linux 2023 padrão (`amazon-linux-2023/x86_64/standard`)
Amazon Linux 2023 com aceleração para a NVIDIA (`amazon-linux-2023/x86_64/nvidia`)
Amazon Linux 2023 com aceleração para o Neuron (`amazon-linux-2023/x86_64/neuron`)
A AWS encerrou o suporte para as AMIs otimizadas e aceleradas para o AL2 do EKS, com efeito a partir de 26 de novembro de 2025. Embora você possa continuar usando as AMIs do AL2 do EKS após a data de fim do suporte (EOS) (26 de novembro de 2025), o EKS não lançará mais nenhuma nova versão do Kubernetes ou atualizações das AMIs do AL2, incluindo versões menores, patches e correções de bugs após essa data. Consulte [aqui](https://docs.aws.amazon.com/eks/latest/userguide/eks-ami-deprecation-faqs.html) para obter mais informações sobre a descontinuação do AL2.
Este tópico descreve como iniciar um grupo do Auto Scaling de nós do Amazon Linux em um Outpost que são registrados no cluster do Amazon EKS. O cluster pode estar na Nuvem AWS ou em um Outpost.
+ Um Outpost existente. Para obter mais informações, consulte [O que é AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html).
+ Um cluster existente do Amazon EKS. Para implementar um cluster no AWS Cloud, consulte [Criar um cluster do Amazon EKS](create-cluster.md). Para implantar um cluster em um Outpost, consulte [Crie clusters locais do Amazon EKS em AWS Outposts para alta disponibilidade](eks-outposts-local-cluster-overview.md).
+ Suponha que você esteja criando seus nós em um cluster na nuvem AWS e que tenha sub-redes na região AWS, na qual você tem AWS Outposts, AWS Wavelength ou AWS Local Zones ativados. Assim sendo, essas sub-redes não devem ter sido transmitidas quando você criou o cluster. Se você estiver criando nós em um cluster em um Outpost, deverá ter transmitido uma sub-rede do Outpost ao criar o cluster.
+ (Recomendado para clusters na Nuvem AWS) O plug-in CNI da Amazon VPC para o complemento do Kubernetes configurado com 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). Clusters locais não são compatíveis com perfis do IAM para contas de serviço.
É possível criar um grupo de nós do Amazon Linux autogerenciado com `eksctl` ou Console de gerenciamento da AWS (com um modelo AWS CloudFormation). Você também pode usar o Terraforma.
É possível criar um grupo de nós autogerenciados para o cluster local com as seguintes ferramentas descritas nesta página:
+ [`eksctl`](#eksctl_create_nodes_outpost)
+ [Console de gerenciamento da AWS](#console_create_nodes_outpost)
**Importante**
Um grupo de nós autogerenciados inclui instâncias do Amazon EC2 em sua conta. Essas instâncias não são atualizadas automaticamente quando você ou o Amazon EKS atualizam a versão do seu ambiente de gerenciamento em seu nome. Um grupo de nós autogerenciado não tem nenhuma indicação no console de que ele precisa ser atualizado. É possível visualizar a versão do `kubelet` instalada em um nó selecionando o nó na lista **Nodes** (Nós) da guia **Overview** (Visão geral) do cluster para determinar quais nós precisam ser atualizados. É necessário atualizar manualmente os nós. Para obter mais informações, consulte [Atualizar nós autogerenciados para seu cluster](update-workers.md).
Os certificados usados pelo kubelet em seus nós autogerenciados são emitidos com um ano de expiração. Por padrão, a rotação de certificados **não** está habilitada (consulte: https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/\$1kubelet-config-k8s-io-v1beta1-KubeletConfiguration). Isso significa que se você tiver um nó autogerenciado em execução por mais de um ano, ele não poderá mais se autenticar na API do Kubernetes.
Como prática recomendada, recomendamos que os clientes atualizem regularmente seus grupos de nós autogerenciados para receber CVEs e patches de segurança da AMI otimizada para Amazon EKS mais recente. A atualização da AMI usada em grupos de nós autogerenciados também aciona a recriação de nós e garante que eles não tenham problemas devido a certificados kubelet expirados.
Como alternativa, você também pode habilitar a rotação de certificados do cliente (consulte: https://kubernetes.io/docs/tasks/tls/certificate-rotation/) ao criar os grupos de nós autogerenciados para garantir que os certificados do kubelet sejam renovados à medida que o certificado atual se aproxima da expiração.
## `eksctl`
**Para 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. Se o cluster estiver na Nuvem AWS e a política do IAM gerenciada **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 que você associa à conta de serviço `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). Se o cluster estiver no Outpost, a política deverá estar anexada à função do nó.
1. O comando a seguir cria um grupo de nós em um cluster existente. O cluster dove ter sido criado usando `eksctl`. 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. Se o cluster estiver em um Outpost, substitua *id* pelo ID de uma sub-rede do Outpost. Se o seu cluster existir no AWS Cloud, substitua *id* pelo ID de uma sub-rede que você não especificou ao criar o cluster. Substitua os valores de exemplo restantes 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.
Substitua *instance-type* por um tipo de instância disponível no Outpost.
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, 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/UserGuide/ec2-key-pairs.html), no *Guia do usuário do Amazon EC2*.
Crie seu grupo de nós com o comando a seguir.
```
eksctl create nodegroup --cluster my-cluster --name al-nodes --node-type instance-type \
--nodes 3 --nodes-min 1 --nodes-max 4 --managed=false \
--node-volume-type gp2 --subnet-ids subnet-id \
--node-ami-family AmazonLinux2023
```
Se o seu cluster estiver implementado no AWS Cloud:
+ O grupo de nós que você implantar poderá atribuir endereços `IPv4` aos pods de um bloco CIDR diferente do bloco da instância. Para obter mais informações, consulte [Implementar pods em sub-redes alternativas com rede personalizada](cni-custom-network.md).
+ O grupo de nós que você implantar não exigirá acesso de saída à Internet. Para obter mais informações, 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, consulte [AWS Outposts Support](https://eksctl.io/usage/outposts/) na documentação `eksctl`.
+ Se os nós não conseguirem ingressar no cluster, consulte [Falha nos nós ao ingressar no cluster](troubleshooting.md#worker-node-fail) em [Solucionar problemas com clusters e nós do Amazon EKS](troubleshooting.md) e [Não é possível integrar nós a um cluster](eks-outposts-troubleshooting.md#outposts-troubleshooting-unable-to-join-nodes-to-a-cluster) em [Solucionar problemas de clusters locais do Amazon EKS no AWS Outposts](eks-outposts-troubleshooting.md).
+ 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.
## 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-24/amazon-eks-outpost-nodegroup.yaml
```
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). Selecione o arquivo `amazon-eks-nodegroup.yaml` que você baixou em uma etapa anterior e selecione **Next** (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 *al-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.
+ **ApiServerEndpoint**: informe o endpoint do servidor de APIs do Kubernetes, que pode ser visualizado no console do EKS ou por meio da API DescribeCluster.
+ **ClusterName**: insira o nome do cluster. Se esse nome não corresponder ao nome do cluster, os nós não poderão se integrar ao cluster.
+ **ClusterId**: informe o ID designado ao cluster pelo serviço EKS. Visível por meio da API DescribeCluster. Se este ID não corresponder ao ID do seu cluster, os nós não poderão ingressar no cluster.
+ **CertificateAuthority**: informe a string codificada em base64 da Autoridade de Certificação do Kubernetes. Visível no console do EKS ou por meio da API DescribeCluster.
+ **ServiceCidr**: informe o CIDR de serviços do Kubernetes. Visível no console do EKS ou por meio da API DescribeCluster.
+ **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**.
+ **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.
+ **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. Se o seu cluster estiver sendo executado no AWS Cloud, para obter mais informações, consulte [Escolher um tipo de instância de nó do Amazon EC2 ideal](choosing-instance-type.md). Se o cluster estiver sendo executado em um Outpost, você só poderá selecionar um tipo de instância que esteja disponível no Outpost.
+ **NodeImageIdSSMParam**: pré-preenchido com o parâmetro do Amazon EC2 Systems Manager de uma AMI recente otimizada para Amazon EKS, para 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.
Para usar uma AMI acelerada e otimizada para o Amazon EKS, atualize o valor de *NodeImageIdSSMParam* para o parâmetro do SSM desejado. Confira como recuperar IDs de AMIs do EKS usando o SSM [aqui](https://docs.aws.amazon.com/eks/latest/userguide/retrieve-ami-id.html).
**nota**
As AMIs dos nós do Amazon EKS são baseadas no Amazon Linux. É possível acompanhar os eventos de segurança ou privacidade do Amazon Linux no [centro de segurança do Amazon Linux](https://alas.aws.amazon.com/), selecionando a guia da versão desejada. Você também pode assinar o feed RSS aplicável. 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, 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/UserGuide/ec2-key-pairs.html), no *Guia do usuário do Amazon EC2*.
**nota**
Se você não fornecer um par de chaves aqui, a criação da pilha do AWS CloudFormation falhará.
+ **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 futuros nós e pods do grupo de nós usem IMDSv1, defina **DisableIMDSv1** como **true**. 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). Para obter mais informações sobre como restringir o acesso a ele em seus nós, 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).
+ **VpcId**: insira o ID da [VPC](creating-a-vpc.md) que você criou. Antes de escolher uma VPC, analise [os requisitos e as considerações da VPC](eks-outposts-vpc-subnet-requirements.md#outposts-vpc-requirements).
+ **Sub-redes**:se o cluster estiver em um Outpost, escolha pelo menos uma sub-rede privada na VPC. Antes de escolher as sub-redes, analise os [Requisitos e considerações para sub-redes](eks-outposts-vpc-subnet-requirements.md#outposts-subnet-requirements). É possível ver quais sub-redes são privadas abrindo cada link de sub-rede na guia **Networking** (Redes) do 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)**.
1. Registre o valor de **NodeInstanceRole** para o grupo de nós criado. Você precisará dele ao configurar os nós 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 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 `rolearn` para o valor **NodeInstanceRole** que você registrou no procedimento anterior. É possível 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 ingressar no cluster, consulte [Falha nos nós ao ingressar no cluster](troubleshooting.md#worker-node-fail) em [Solucionar problemas com clusters e nós do Amazon EKS](troubleshooting.md) e [Não é possível integrar nós a um cluster](eks-outposts-troubleshooting.md#outposts-troubleshooting-unable-to-join-nodes-to-a-cluster) em [Solucionar problemas de clusters locais do Amazon EKS no AWS Outposts](eks-outposts-troubleshooting.md).
1. Instale o driver da CSI do Amazon EBS. Para obter mais informações, consulte [Instalação](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md) no GitHub. Na seção **Set up driver permission** (Configurar permissão do driver), certifique-se de seguir as instruções para a opção **Using IAM instance profile** (Usar o perfil de instância do IAM). É necessário usar a classe de armazenamento `gp2`. A classe de armazenamento `gp3` não é compatível.
Para criar uma classe de armazenamento `gp2` no cluster, conclua as etapas a seguir.
1. Execute o seguinte comando para criar o arquivo `gp2-storage-class.yaml`.
```
cat >gp2-storage-class.yaml <