**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
<a name="worker"></a>

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 `<cluster-name>` 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/<cluster-name>`  |  `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)