**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.
# Implantar o Amazon EKS on-premises com o AWS Outposts
Você pode usar o Amazon EKS para executar aplicações on-premises do Kubernetes no AWS Outposts. É possível implantar o Amazon EKS no Outposts das seguintes maneiras:
+ **Clusters estendidos**: execute o ambiente de gerenciamento do Kubernetes em uma região da AWS e em nós no Outpost.
+ **Clusters locais**: execute os nós e o ambiente de gerenciamento do Kubernetes no Outpost.
Para ambas as opções de implantação, o ambiente de gerenciamento do Kubernetes é totalmente gerenciado pela AWS. É possível utilizar as mesmas APIs, ferramentas e console do Amazon EKS utilizados na nuvem para criar e executar o Amazon EKS no Outposts.
O diagrama a seguir mostra essas opções de implantação.
![\[Opções de implantação do Outpost\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/outposts-deployment-options.png)
## Quando usar cada opção de implantação
Os clusters locais e estendidos são opções de implantação de uso geral e podem ser usados para uma variedade de aplicações.
Os clusters locais permitem que você execute todo o cluster do Amazon EKS localmente no Outposts. Isso ajuda a reduzir o risco de tempo de inatividade das aplicações que pode resultar de perdas temporárias de conexão da rede com a nuvem. Essas desconexões da rede podem ser causadas por cortes de fibra ou eventos climáticos. Como todo o cluster do Amazon EKS é executado localmente no Outposts, as aplicações permanecem disponíveis. Você pode executar operações de cluster durante as desconexões da rede com a nuvem. Para obter mais informações, consulte [Prepare clusters locais do Amazon EKS em AWS Outposts para desconexões de rede](eks-outposts-network-disconnects.md). Se a qualidade da conexão de rede entre os postos avançados e a região da AWS principal for uma preocupação e você precisar de alta disponibilidade por meio de desconexões de rede, use a opção de implantação de cluster local.
Com clusters estendidos, você pode economizar capacidade no Outpost porque o ambiente de gerenciamento do Kubernetes é executado na região da principal da AWS. Essa opção é adequada se você puder investir em conectividade de rede confiável e redundante do seu Outpost para a região da AWS. A qualidade da conexão de rede é fundamental para essa opção. A forma como o Kubernetes lida com as desconexões da rede entre os nós e o ambiente de gerenciamento do Kubernetes pode resultar em tempo de inatividade das aplicações. Para obter mais informações sobre o comportamento do Kubernetes, consulte [Programação, preempção e remoção](https://kubernetes.io/docs/concepts/scheduling-eviction/) na documentação do Kubernetes.
## Comparar as opções de implantação
A tabela a seguir compara as diferenças entre as duas opções.
| Recurso | Cluster estendido | Cluster local |
| --- | --- | --- |
| Localização do ambiente de gerenciamento do Kubernetes | Região da AWS | Outpost |
| Conta do ambiente de gerenciamento do Kubernetes | Conta da AWS | Sua conta |
| Disponibilidade regional | Consulte [Endpoints de serviço](https://docs.aws.amazon.com/general/latest/gr/eks.html#eks_region) | Leste dos EUA (Ohio), Leste dos EUA (Norte da Virgínia), Oeste dos EUA (N. da Califórnia), Oeste dos EUA (Oregon), Ásia-Pacífico (Seul), Ásia-Pacífico (Singapura), Ásia-Pacífico (Sydney), Ásia-Pacífico (Tóquio) Canadá (Central), Europa (Frankfurt), Europa (Irlanda), Europa (Londres), Oriente Médio (Bahrein) e América do Sul (São Paulo) |
| Versões secundárias do Kubernetes | eks/latest/userguide/kubernetes-versions.html [Versões com suporte no Amazon EKS, type="documentation"]. | eks/latest/userguide/kubernetes-versions.html [Versões com suporte no Amazon EKS, type="documentation"]. |
| Versões da plataforma | Consulte [Versões da plataforma do EKS](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) | Consulte [Saiba mais sobre as versões das plataformas do Kubernetes e do Amazon EKS para AWS Outposts](eks-outposts-platform-versions.md) |
| Fatores de formato do Outpost | Racks do Outpost | Racks do Outpost |
| Interfaces do usuário | Console de gerenciamento da AWS, AWS CLI, API do Amazon EKS, `eksctl`, AWS CloudFormation e Terraform | Console de gerenciamento da AWS, AWS CLI, API do Amazon EKS, `eksctl`, AWS CloudFormation e Terraform |
| Políticas gerenciadas | [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy) e [Política gerenciada pela AWS: AmazonEKSServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy) | [AmazonEKSLocalOutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) e [Política gerenciada pela AWS: AmazonEKSLocalOutpostServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) |
| VPC e sub-redes de clusters | Consulte [Exibir os requisitos de rede do Amazon EKS para VPC e sub-redes](network-reqs.md) | Consulte [Criar um VPC e sub-redes para clusters do Amazon EKS em AWS Outposts](eks-outposts-vpc-subnet-requirements.md) |
| Acesso ao endpoint do cluster | Público ou privado ou ambos | Privado apenas |
| Autenticação do servidor de API do Kubernetes | AWS Identity and Access Management (IAM) e OIDC | IAM e certificados `x.509` |
| Tipos de nó | Somente autogerenciado | Somente autogerenciado |
| Tipos de computação de nós | Amazon EC2 sob demanda | Amazon EC2 sob demanda |
| Tipos de armazenamento de nós | Amazon EBS `gp2` e SSD de NVMe local | Amazon EBS `gp2` e SSD de NVMe local |
| AMIs otimizadas para o Amazon EKS | Amazon Linux, Windows e Bottlerocket | Somente para Amazon Linux |
| Versões de IP | Somente `IPv4` | Somente `IPv4` |
| Complementos | Complementos do Amazon EKS ou complementos autogerenciados | Somente complementos autogerenciados |
| Container Network Interface padrão | Plug-in CNI da Amazon VPC para Kubernetes | Plug-in CNI da Amazon VPC para Kubernetes |
| Logs do ambiente de gerenciamento do Kubernetes | Amazon CloudWatch Logs | Amazon CloudWatch Logs |
| Balanceamento de carga | Use o [AWS Load Balancer Control](aws-load-balancer-controller.md) ler para provisionar somente os balanceadores de carga de aplicações (sem balanceadores de carga de rede) | Use o [AWS Load Balancer Control](aws-load-balancer-controller.md) ler para provisionar somente os balanceadores de carga de aplicações (sem balanceadores de carga de rede) |
| Criptografia envelopada de segredos | Consulte [Criptografar segredos do Kubernetes com o KMS em clusters existentes](enable-kms.md) | Não compatível |
| Perfis do IAM para contas de serviço | Consulte [Funções do IAM para contas de serviço](iam-roles-for-service-accounts.md) | Não compatível |
| Solução de problemas | Consulte [Solucionar problemas com clusters e nós do Amazon EKS](troubleshooting.md) | Consulte [Solucionar problemas de clusters locais do Amazon EKS em AWS Outposts](eks-outposts-troubleshooting.md) |
**Topics**
# Crie clusters locais do Amazon EKS em AWS Outposts para alta disponibilidade
Você pode usar clusters locais para executar todo o seu cluster do Amazon EKS localmente em AWS Outposts. Isso ajuda a reduzir o risco de tempo de inatividade da aplicação, que pode resultar de desconexões temporárias da rede com a nuvem. Essas desconexões podem ser causadas por cortes de fibra ou eventos climáticos. Como o cluster inteiro do Kubernetes é executado localmente no Outposts, as aplicações permanecem disponíveis. Você pode executar operações de cluster durante as desconexões da rede com a nuvem. Para ter mais informações, consulte [Prepare clusters locais do Amazon EKS em AWS Outposts para desconexões de rede](eks-outposts-network-disconnects.md). O diagrama a seguir mostra a implantação de um cluster local.
![\[Cluster local do Outpost\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/outposts-local-cluster.png)
Clusters locais geralmente estão disponíveis para uso com racks do Outposts.
## Regiões do AWS compatíveis
Você pode criar clusters locais nas seguintes regiões AWS: Leste dos EUA (Ohio), Leste dos EUA (N. Virgínia), Oeste dos EUA (N. Califórnia), Oeste dos EUA (Oregon), Ásia-Pacífico (Seul), Ásia-Pacífico (Cingapura), Ásia-Pacífico (Sydney), Ásia-Pacífico (Tóquio), Canadá (Central), Europa (Frankfurt), Europa (Irlanda), Europa (Londres), Oriente Médio (Bahrein) e América do Sul (São Paulo). Para obter informações sobre os recursos compatíveis, consulte [Comparar as opções de implantação](eks-outposts.md#outposts-overview-comparing-deployment-options).
**Topics**
# Implantar um cluster do Amazon EKS em AWS Outposts
Este tópico fornece uma visão geral do que deve ser considerado ao executar um cluster local em um Outpost. O tópico também fornece instruções sobre como implantar um cluster local em um Outpost.
**Importante**
Essas considerações não são replicadas na documentação relacionada do Amazon EKS. Se outros tópicos da documentação do Amazon EKS entrarem em conflito com as considerações aqui apresentadas, siga estas considerações.
Essas considerações estão sujeitas a alterações, que podem ocorrer com frequência. Portanto, recomendamos que você revise este tópico periodicamente.
Muitas das considerações são diferentes das considerações para a criação de um cluster no AWS Cloud.
+ Os clusters locais somente são compatíveis com racks do Outpost. Um único cluster local pode ser executado em vários racks físicos do Outpost que incluem um único Outpost lógico. Um único cluster local não pode ser executado em vários Outposts lógicos. Cada Outpost lógico tem um único ARN de Outpost.
+ Clusters locais executam e gerenciam o ambiente de gerenciamento do Kubernetes na sua conta no Outpost. Você não pode executar workloads nas instâncias do ambiente de gerenciamento do Kubernetes nem modificar os componentes dele. Esses nós são gerenciados pelo serviço do Amazon EKS. As alterações no ambiente de gerenciamento do Kubernetes não persistem por meio de ações automáticas de gerenciamento do Amazon EKS, como aplicação de patches.
+ Os clusters locais são compatíveis com complementos autogerenciados e grupos de nós autogerenciados do Amazon Linux. O plug-in [Amazon VPC CNI para Kubernetes](managing-vpc-cni.md), o [kube-proxy](managing-kube-proxy.md) e os complementos [CoreDNS](managing-coredns.md) são instalados automaticamente nos clusters locais.
+ Os clusters locais exigem o uso do Amazon EBS no Outposts. O Outpost deve ter o Amazon EBS disponível para o armazenamento do ambiente de gerenciamento do Kubernetes. O Outposts somente é compatível com volumes `gp2` do Amazon EBS.
+ Os `PersistentVolumes` do Kubernetes baseados no Amazon EBS são compatíveis com o uso do driver CSI do Amazon EBS.
+ As instâncias do ambiente de gerenciamento dos clusters locais são configuradas em uma [topologia empilhada altamente disponível](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/). Duas das três instâncias do ambiente de gerenciamento devem estar sempre íntegras para manter o quórum. Se o quórum for perdido, entre em contato com o suporte da AWS, pois algumas ações do lado do serviço serão necessárias para habilitar as novas instâncias gerenciadas.
**Pré-requisitos**
+ Familiaridade com as [opções de implementação do Outposts](eks-outposts.md#outposts-overview-comparing-deployment-options), [Selecione tipos de instância e grupos de posicionamento para clusters do Amazon EKS no AWS Outposts com base em considerações de capacidade](eks-outposts-capacity-considerations.md) e [requisitos e considerações de VPC](eks-outposts-vpc-subnet-requirements.md).
+ 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).
+ A ferramenta da linha de comando `kubectl` está instalada no seu computador ou no AWS CloudShell. A versão pode ser a mesma ou até uma versão secundária anterior ou posterior à versão do Kubernetes do seu cluster. Por exemplo, se a versão do cluster for a `1.29`, será possível usar o `kubectl` versão `1.28`, `1.29` ou `1.30` com ele. Para instalar ou atualizar o `kubectl`, consulte [Configurar o `kubectl` e o `eksctl`](install-kubectl.md).
+ Versão `2.12.3` ou posterior ou versão `1.27.160` ou posterior da AWS Command Line Interface (AWS CLI) instalada e configurada no seu dispositivo ou no AWS CloudShell. Para verificar sua versão atual, use `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Os gerenciadores de pacotes, como `yum`, `apt-get` ou Homebrew para macOS, geralmente estão várias versões atrás da versão mais recente da AWS CLI. Para instalar a versão mais recente, consulte [Installing](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [Quick configuration with aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config), no *Guia do usuário da AWS Command Line Interface*. A versão da AWS CLI instalada no AWS CloudShell também pode estar várias versões atrás da versão mais recente. Para atualizá-lo, consulte [Instalar a AWS CLI no seu diretório pessoal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software), no * Guia do usuário do AWS CloudShell*.
+ Uma entidade principal do IAM (usuário ou perfil) com permissões para `create` e `describe` um cluster do Amazon EKS. Para obter mais informações, consulte [Criar um cluster local do Kubernetes em um Outpost](security-iam-id-based-policy-examples.md#policy-create-local-cluster) e [Listar ou descrever todos os clusters](security-iam-id-based-policy-examples.md#policy-example2).
Quando um cluster local do Amazon EKS é criado, a [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que cria o cluster é adicionada permanentemente. A entidade principal é adicionada especificamente à tabela de autorização RBAC do Kubernetes como administradora. Esta entidade tem permissões `system:masters`. A identidade desta entidade não fica visível na configuração do seu cluster. Por isso, é importante observar a entidade que criou o cluster e garantir que ela nunca tenha sido excluída. Inicialmente, somente a entidade principal que criou o servidor poderá fazer chamadas para o servidor de API do Kubernetes usando o `kubectl`. Se usar o console para criar o cluster, você deverá se certificar de que as mesmas credenciais do IAM estejam na cadeia de credenciais do AWS SDK quando executar os comandos `kubectl` no cluster. Depois de criar o cluster, você poderá conceder acesso a ele para outras entidades do IAM.
## Criar um cluster local do Amazon EKS
Você pode criar um cluster local com as seguintes ferramentas descritas nesta página:
+ [`eksctl`](#eksctl_create_cluster_outpost)
+ [Console de gerenciamento da AWS](#console_create_cluster_outpost)
Além disso, é possível usar a [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/eks/create-cluster.html), a [API do Amazon EKS](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html), os [AWS SDKs](https://aws.amazon.com/developer/tools/), o [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-eks-cluster-outpostconfig.html) ou o [Terraform](https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest) para a criação de clusters no Outposts.
### `eksctl`
**Para criar um cluster local com `eksctl` **
1. Instale a versão `0.215.0` ou posterior da ferramenta de linha de comando `eksctl` em seu dispositivo ou AWS CloudShell. Para instalar ou atualizar o `eksctl`, consulte [Instalação](https://eksctl.io/installation) na documentação do `eksctl`.
1. Copie o conteúdo a seguir no seu dispositivo. Substitua os valores a seguir e execute o comando modificado para criar o arquivo `outpost-control-plane.yaml`:
+ Substitua *region-code* pela [região AWS suportada](eks-outposts-local-cluster-overview.md#outposts-control-plane-supported-regions) na qual você deseja criar o cluster.
+ Substitua *my-cluster* por um nome para seu 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. O nome deve ser exclusivo na região da AWS e na conta da AWS em que você está criando o cluster.
+ Substitua *vpc-ExampleID1* e *subnet-ExampleID1* pelos IDs da sua VPC e da sub-rede existentes. A VPC e a sub-rede devem atender aos requisitos em [Criar uma VPC e sub-redes para clusters do Amazon EKS no AWS Outposts](eks-outposts-vpc-subnet-requirements.md).
+ Substitua *uniqueid* pelo ID do seu Outpost.
+ Substitua *m5.large* por um tipo de instância disponível no seu Outpost. Antes de escolher um tipo de instância, consulte [Selecione tipos de instância e grupos de posicionamento para clusters do Amazon EKS em AWS Outposts com base em considerações de capacidade](eks-outposts-capacity-considerations.md). Três instâncias do ambiente de gerenciamento são implantadas. Não é possível alterar esse número.
```
cat >outpost-control-plane.yaml <
**Para criar o cluster com a Console de gerenciamento da AWS **
1. Você precisa de uma VPC e uma sub-rede existentes que atendam aos requisitos do Amazon EKS. Para obter mais informações, consulte [Criar um VPC e sub-redes para clusters do Amazon EKS em AWS Outposts](eks-outposts-vpc-subnet-requirements.md).
1. Se você já tiver um perfil do IAM do cluster local ou se for criar seu cluster com `eksctl`, poderá ignorar essa etapa. Por padrão, `eksctl` cria um perfil para você.
1. Execute o comando a seguir para criar um arquivo JSON de política de confiança do IAM:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Crie o perfil do IAM do cluster do Amazon EKS. Para criar um perfil do IAM, a [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que estiver criando o perfil deverá ser atribuída à seguinte ação `iam:CreateRole` (permissão):
```
aws iam create-role --role-name myAmazonEKSLocalClusterRole --assume-role-policy-document file://"eks-local-cluster-role-trust-policy.json"
```
1. Anexe a política gerenciada do Amazon EKS denominada [AmazonEKSLocalOutpostClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostClusterPolicy.html) ao perfil. Para anexar uma política do IAM a uma [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) a entidade principal do IAM que está anexando a política deve receber uma das seguintes ações do IAM (permissões): `iam:AttachUserPolicy` ou `iam:AttachRolePolicy`.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSLocalOutpostClusterPolicy --role-name myAmazonEKSLocalClusterRole
```
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Na parte superior da tela do console, certifique-se de ter selecionado uma [região compatível com AWS](eks-outposts-local-cluster-overview.md#outposts-control-plane-supported-regions).
1. Escolha **Add cluster** (Adicionar cluster) e, em seguida, **Create** (Criar).
1. Na página **Configure cluster** (Configurar cluster), insira ou selecione valores para os seguintes campos:
+ **Localização do ambiente de gerenciamento do Kubernetes**: escolha AWS Outposts.
+ **Outpost ID** (ID do Outpost): escolha o ID do Outpost no qual você deseja criar seu ambiente de gerenciamento.
+ Em **Instance type** (Tipo de instância): selecione um tipo de instância. Somente os tipos de instância disponíveis no seu Outpost são exibidos. Na lista suspensa, cada tipo de instância descreve para quantos nós o tipo de instância é recomendado. Antes de escolher um tipo de instância, consulte [Selecione tipos de instância e grupos de posicionamento para clusters do Amazon EKS em AWS Outposts com base em considerações de capacidade](eks-outposts-capacity-considerations.md). Todas as réplicas são implantadas com o uso do mesmo tipo de instância. Você não poderá alterar o tipo de instância depois que seu cluster for criado. Três instâncias do ambiente de gerenciamento são implantadas. Não é possível alterar esse número.
+ **Name** (Nome): um nome exclusivo para o cluster. Ele deve ser exclusivo na sua conta da AWS. 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. O nome deve ser exclusivo na região da AWS e na conta da AWS em que você está criando o cluster.
+ **Versão do Kubernetes**: escolha a versão do Kubernetes que você deseja usar para o cluster. A menos que precise usar uma versão anterior, recomendamos que você selecione a versão mais recente.
+ **Perfil de serviço do cluster**: escolha o perfil do IAM do cluster do Amazon EKS criado em uma etapa anterior para permitir que o ambiente de gerenciamento do Kubernetes gerencie os recursos da AWS.
+ **Acesso de administrador do cluster do Kubernetes**: se quiser que a entidade principal do IAM (perfil ou usuário) que está criando o cluster tenha acesso de administrador aos objetos Kubernetes no cluster, aceite o padrão (permitir). O Amazon EKS cria uma entrada de acesso para a entidade principal do IAM e concede permissões de administrador do cluster à entrada de acesso. Para obter mais informações sobre as entradas de acesso, consulte [Conceder aos usuários do IAM acesso ao Kubernetes com entradas de acesso ao EKS](access-entries.md).
Se você quiser que uma entidade principal do IAM diferente daquela que está criando o cluster tenha acesso de administrador aos objetos do Kubernetes do cluster, escolha a opção de não permitir. Após a criação do cluster, qualquer entidade principal do IAM que tenha permissões do IAM para criar entradas de acesso poderá adicionar uma entrada de acesso para qualquer entidade principal do IAM que precise acessar os objetos do Kubernetes do cluster. Para obter mais informações sobre as permissões necessárias do IAM, consulte [Ações definidas pelo Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) na Referência de autorização de serviço. Se você escolher a opção de não permitir e não criar nenhuma entrada de acesso, nenhuma entidade principal do IAM terá acesso aos objetos do Kubernetes no cluster.
+ **Tags** (Etiquetas) – (opcional) adicione etiquetas ao cluster. Para obter mais informações, consulte [Organizar recursos do Amazon EKS com tags](eks-using-tags.md). Após terminar com essa página, escolha **Próximo**.
1. Na página **Specify networking** (Especificar redes), selecione valores para os seguintes campos:
+ **VPC**: escolha uma VPC existente. A VPC deve ter uma quantidade suficiente de endereços IP disponíveis para o cluster, todos os nós e outros recursos Kubernetes que você deseja criar. Sua VPC deve atender aos requisitos em [Requisitos e considerações da VPC](eks-outposts-vpc-subnet-requirements.md#outposts-vpc-requirements).
+ **Subnets** (Sub-redes): por padrão, as sub-redes disponíveis na VPC especificada no campo anterior são pré-selecionadas. As sub-redes que você escolher devem atender aos requisitos em [Requisitos e considerações da sub-rede](eks-outposts-vpc-subnet-requirements.md#outposts-subnet-requirements).
+ **Security groups** (Grupos de segurança) (Opcional): especifique um ou mais grupos de segurança que você deseja que o Amazon EKS associe às interfaces de rede que ele cria. O Amazon EKS cria automaticamente um grupo de segurança que permite a comunicação entre o cluster e a VPC. O Amazon EKS associa esse grupo de segurança, e qualquer um que você escolher, às interfaces de rede que ele cria. Para saber mais sobre o grupo de segurança de cluster criado pelo Amazon EKS, consulte [Exibir os requisitos para grupos de segurança do Amazon EKS em clusters](sec-group-reqs.md). É possível modificar as regras no grupo de segurança do cluster criado pelo Amazon EKS. Se optar por adicionar seus próprios grupos de segurança, você não poderá alterar os escolhidos após a criação desse cluster. Para que os hosts on-premises se comuniquem com o endpoint do cluster, você deve permitir tráfego de entrada do grupo de segurança do cluster. Para clusters que não têm uma conexão de internet de entrada e saída (também conhecidos como clusters privados), você deve fazer o seguinte:
+ Adicione o grupo de segurança associado aos endpoints da VPC necessários. Para obter mais informações sobre os endpoints necessários, consulte [Usar VPC endpoints da interface do](eks-outposts-vpc-subnet-requirements.md#vpc-subnet-requirements-vpc-endpoints) em [Acesso da sub-rede a serviços da AWS](eks-outposts-vpc-subnet-requirements.md#subnet-access-to-services).
+ Modifique o grupo de segurança que o Amazon EKS criou para permitir tráfego do grupo de segurança associado aos endpoints da VPC. Após terminar com essa página, escolha **Próximo**.
1. Na página **Configurar observabilidade**, é possível escolher opcionalmente quais opções de **Métricas** e **Log do ambiente de gerenciamento** você deseja ativar. Por padrão, o cada tipo de log está desativado.
+ Para obter mais informações sobre a opção de métricas do Prometheus, consulte [Etapa 1: ativar as métricas do Prometheus](prometheus.md#turn-on-prometheus-metrics).
+ Para obter mais informações sobre as opções do **Log do ambiente de gerenciamento**, consulte [Enviar logs do ambiente de gerenciamento para o CloudWatch Logs](control-plane-logs.md). Após terminar com essa página, escolha **Próximo**.
1. Na página **Review and create (Revisar e criar)**, revise as informações que você inseriu ou selecionou nas páginas anteriores. Se precisar fazer alterações, escolha **Edit** (Editar). Quando estiver satisfeito, escolha **Criar**. O campo **Status** mostra o campo **CREATING** (Criando) enquanto o cluster é provisionado.
O provisionamento de cluster leva alguns minutos.
## Visualizar seu cluster local do Amazon EKS
1. Depois que o cluster for criado, você poderá visualizar as instâncias do ambiente de gerenciamento do Amazon EC2 que foram criadas.
```
aws ec2 describe-instances --query 'Reservations[*].Instances[*].{Name:Tags[?Key==`Name`]|[0].Value}' | grep my-cluster-control-plane
```
Veja um exemplo de saída abaixo.
```
"Name": "my-cluster-control-plane-id1"
"Name": "my-cluster-control-plane-id2"
"Name": "my-cluster-control-plane-id3"
```
Cada instância recebeu taints com o `node-role.eks-local.amazonaws.com/control-plane` para que nenhuma workload seja programada nas instâncias do ambiente de gerenciamento. Para obter mais informações sobre taints, consulte [Taints e Tolerâncias](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) na documentação do Kubernetes. O Amazon EKS monitora continuamente o estado dos clusters locais. Executamos ações automáticas de gerenciamento, como patches de segurança e reparo de instâncias não íntegras. Quando os clusters locais são desconectados da nuvem, executamos ações para garantir que o cluster seja reparado para um estado íntegro após a reconexão.
1. Se você criou seu cluster usando `eksctl`, pode ignorar esta etapa. O `eksctl` completa esta etapa para você. Habilite o `kubectl` para se comunicar com o cluster adicionando um novo contexto ao arquivo `kubectl` `config`. Para obter instruções sobre como criar e atualizar o arquivo, consulte [Conecte o kubectl a um cluster de EKS criando um arquivo kubeconfig](create-kubeconfig.md).
```
aws eks update-kubeconfig --region region-code --name my-cluster
```
Veja abaixo um exemplo de saída.
```
Added new context arn:aws:eks:region-code:111122223333:cluster/my-cluster to /home/username/.kube/config
```
1. Para se conectar ao servidor de API do Kubernetes do cluster local, você deve ter acesso ao gateway local da sub-rede ou conectar-se de dentro da VPC. Para obter mais informações sobre como conectar um rack de Outpost à sua rede on-premises, consulte [Como funcionam gateways locais para racks](https://docs.aws.amazon.com/outposts/latest/userguide/how-racks-work.html) no Guia do usuário do AWS Outposts. Se você usar roteamento direto da VPC e a sub-rede do Outpost tiver uma rota para o gateway local, os endereços IP privados das instâncias do ambiente de gerenciamento do Kubernetes serão transmitidos automaticamente pela rede local. O endpoint do servidor de API do Kubernetes do cluster local está hospedado no Amazon Route 53 (Route 53). O endpoint do serviço de API pode ser resolvido por servidores DNS públicos para os endereços IP privados dos servidores de API do Kubernetes.
As instâncias do ambiente de gerenciamento do Kubernetes dos clusters locais são configuradas com interfaces de rede elásticas estáticas com endereços IP privados fixos que não mudam durante o ciclo de vida do cluster. As máquinas que interagem com o servidor de API do Kubernetes podem não ter conectividade com o Route 53 durante as desconexões da rede. Se for esse o caso, recomendamos configurar `/etc/hosts` com os endereços IP privados estáticos para operações contínuas. Também recomendamos configurar servidores DNS locais e conectá-los ao Outpost. Para obter mais informações, consulte a [documentação doAWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/how-outposts-works.html#dns). Execute o comando a seguir para confirmar que a comunicação foi estabelecida com o cluster.
```
kubectl get svc
```
Veja abaixo um exemplo de saída.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.100.0.1 443/TCP 28h
```
1. (Opcional) Teste a autenticação em seu cluster local quando ele estiver em um estado desconectado do AWS Cloud. Para instruções, consulte [Prepare clusters locais do Amazon EKS em AWS Outposts para desconexões de rede](eks-outposts-network-disconnects.md).
### Recursos internos
O Amazon EKS cria os seguintes recursos no seu cluster. Os recursos são para uso interno do Amazon EKS. Para o funcionamento adequado do cluster, não edite nem modifique esses recursos.
+ Os seguintes [pods de espelho](https://kubernetes.io/docs/reference/glossary/?all=true#term-mirror-pod):
+ `aws-iam-authenticator-node-hostname `
+ `eks-certificates-controller-node-hostname `
+ `etcd-node-hostname `
+ `kube-apiserver-node-hostname `
+ `kube-controller-manager-node-hostname `
+ `kube-scheduler-node-hostname `
+ Os seguintes complementos autogerenciados:
+ `kube-system/coredns`
+ `kube-system/` `kube-proxy` (só será criado quando você adicionar seu primeiro nó)
+ `kube-system/aws-node` (só será criado quando você adicionar seu primeiro nó). Clusters locais usam o plug-in CNI da Amazon VPC para o plug-in do Kubernetes de redes de clusters. Não altere a configuração das instâncias do ambiente de gerenciamento (pods denominados `aws-node-controlplane-*`). Há variáveis de configuração que você pode usar para alterar o valor padrão para quando o plug-in criar novas interfaces de rede. Para obter mais informações, consulte a [documentação](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) sobre o GitHub.
+ Os seguintes serviços:
+ `default/kubernetes`
+ `kube-system/kube-dns`
+ Um `PodSecurityPolicy` denominado `eks.system`
+ Um `ClusterRole` denominado `eks:system:podsecuritypolicy`
+ Um `ClusterRoleBinding` denominado `eks:system`
+ Além do [grupo de segurança do cluster](sec-group-reqs.md), o Amazon EKS cria um grupo de segurança em sua conta AWS chamado `eks-local-internal-do-not-use-or-edit-cluster-name-uniqueid `. Esse grupo de segurança permite que o tráfego flua livremente entre os componentes do Kubernetes em execução nas instâncias do ambiente de gerenciamento.
Próximas etapas recomendadas:
+ [Conceda à entidade principal do IAM que criou o cluster as permissões necessárias para visualizar os recursos do Kubernetes no Console de gerenciamento da AWS](view-kubernetes-resources.md#view-kubernetes-resources-permissions)
+ [Conceda acesso para entidades do IAM ao cluster](grant-k8s-access.md). Se quiser que as entidades visualizem os recursos do Kubernetes no console do Amazon EKS, conceda as [permissões necessárias](view-kubernetes-resources.md#view-kubernetes-resources-permissions) às entidades.
+ [Configurar o registro em log para o seu cluster](control-plane-logs.md)
+ Familiarize-se com o que acontece durante [desconexões de rede](eks-outposts-network-disconnects.md).
+ [Adicionar nós ao seu cluster](eks-outposts-self-managed-nodes.md)
+ Pense em configurar um plano de backup para seu `etcd`. O Amazon EKS não é compatível com backup e restauração automatizadas do `etcd` para clusters locais. Para obter mais informações, consulte [Backing up an etcd cluster](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) na documentação do Kubernetes. As duas principais opções estão usando o `etcdctl` para automatizar a captura de snapshots ou o uso do backup de volume de armazenamento do Amazon EBS.
# Saiba mais sobre as versões das plataformas do Kubernetes e do Amazon EKS para AWS Outposts
As versões da plataforma do cluster local representam os recursos do cluster Amazon EKS no AWS Outposts. As versões incluem os componentes que são executados no ambiente de gerenciamento do Kubernetes e quais sinalizadores do servidor de API do Kubernetes estão habilitados. Também incluem a versão atual do patch do Kubernetes. Cada versão secundária do Kubernetes tem uma ou mais versões de plataforma do associadas. As versões da plataforma para diferentes versões secundárias do Kubernetes são independentes. As versões de plataforma para clusters locais e clusters do Amazon EKS na nuvem são independentes.
Quando uma nova versão secundária do Kubernetes está disponível para clusters locais, como `1.31`, a versão inicial da plataforma para essa versão secundária do Kubernetes começa em `eks-local-outposts.1`. No entanto, o Amazon EKS lança novas versões de plataforma periodicamente para habilitar novas configurações do ambiente de gerenciamento do Kubernetes e para fornecer correções de segurança.
Quando novas versões da plataforma do cluster local são disponibilizadas para uma versão secundária:
+ O número da versão da plataforma é incrementado (`eks-local-outposts.n+1`).
+ O Amazon EKS atualiza automaticamente todos os clusters locais existentes para a versão mais recente da plataforma disponível para a versão secundária correspondente do Kubernetes. Atualizações automáticas de versões de plataforma existentes do são implementadas de forma incremental. O processo de implantação consiste na substituição das instâncias gerenciadas do ambiente de gerenciamento do Kubernetes em execução no Outpost, uma por vez, até que todas as três instâncias sejam substituídas por novas.
+ O processo de substituição da instância do ambiente de gerenciamento do Kubernetes interromperá o andamento se houver risco de interrupção do serviço. O Amazon EKS só tentará substituir uma instância caso as outras duas instâncias do ambiente de gerenciamento do Kubernetes estejam íntegras e aprovadas quanto a todas as condições de prontidão como um nó de cluster.
+ A implantação de uma versão da plataforma normalmente leva menos de 30 minutos para ser concluída. Se um cluster permanecer no estado `UPDATING` por um longo período de tempo, consulte [Solucionar problemas de clusters locais do Amazon EKS em AWS Outposts](eks-outposts-troubleshooting.md) e obtenha ajuda do AWS Support. Nunca encerre manualmente as instâncias do ambiente de gerenciamento do Kubernetes, a menos que seja instruído pelo AWS Support.
+ O Amazon EKS pode publicar uma nova AMI do nó com uma versão de patch correspondente. Todas as versões de patch são compatíveis entre o ambiente de gerenciamento do Kubernetes e as AMIs dos nós para uma única versão secundária do Kubernetes.
Novas versões de plataforma não apresentam alterações que podem causar interrupções nem causam interrupções de serviço.
Os clusters locais são sempre criados com a versão da plataforma mais recente disponível (`eks-local-outposts.n`) para a versão especificada do Kubernetes.
As versões recentes e atuais da plataforma estão descritas nas tabelas a seguir.
Para receber notificações de todas as alterações do arquivo de origem nesta página específica da documentação, você pode se inscrever no seguinte URL com um leitor de RSS:
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/outposts/eks-outposts-platform-versions.adoc.atom
```
## Versão do Kubernetes `1.31`
Os seguintes controladores de admissão estão habilitados para todas as versões da plataforma `1.31`: `CertificateApproval`, `CertificateSigning`, `CertificateSubjectRestriction`, `ClusterTrustBundleAttest`, `DefaultIngressClass`, `DefaultStorageClass`, `DefaultTolerationSeconds`, `ExtendedResourceToleration`, `LimitRanger`, `MutatingAdmissionWebhook`, `NamespaceLifecycle`, `NodeRestriction`, `PersistentVolumeClaimResize`, `PodSecurity`, `Priority`, `ResourceQuota`, `RuntimeClass`, `ServiceAccount`, `StorageObjectInUseProtection`, `TaintNodesByCondition`, `ValidatingAdmissionPolicy` e `ValidatingAdmissionWebhook`.
| Versão do Kubernetes | Versão da plataforma Amazon EKS | Notas da versão | Data de lançamento |
| --- | --- | --- | --- |
| `1.31.14` | `eks-local-outposts.8` | Nova versão da plataforma com correções de segurança e melhorias. kube-proxy atualizado para `v1.31.14`. AWS IAM Authenticator atualizado para `v0.7.8`. Plug-in da CNI da Amazon VPC para Kubernetes atualizada para `v1.20.4`. Versão do Bottlerocket atualizada para `v1.52.0`. | 23 de dezembro de 2025 |
| `1.31.12` | `eks-local-outposts.5` | Nova versão da plataforma com correções de segurança e melhorias. kube-proxy atualizado para `v1.31.10`. AWS IAM Authenticator atualizado para `v0.7.4`. Plug-in da CNI da Amazon VPC para Kubernetes atualizada para `v1.20.2`. Versão do Bottlerocket atualizada para `v1.47.0`. | 3 de outubro de 2025 |
| `1.31.9` | `eks-local-outposts.4` | Nova versão da plataforma com correções de segurança e melhorias. kube-proxy atualizado para `v1.31.9`. AWS IAM Authenticator atualizado para `v0.7.2`. Plug-in da CNI da Amazon VPC para Kubernetes atualizado para a versão `v1.20.0`. Versão do Bottlerocket atualizada para a versão `v1.43.0`. | 9 de agosto de 2025 |
| `1.31.7` | `eks-local-outposts.3` | Nova versão da plataforma com correções de segurança e melhorias. kube-proxy atualizado para `v1.31.9`. AWS IAM Authenticator atualizado para `v0.7.1`. Plug-in da CNI da Amazon VPC para Kubernetes atualizada para `v1.19.5`. Versão do Bottlerocket atualizada para `v1.40.0`. | 19 de junho de 2025 |
| `1.31.6` | `eks-local-outposts.2` | Nova versão da plataforma com correções de segurança e melhorias. Versão do Bottlerocket atualizada para `v1.36.0`. | 24 de abril de 2025 |
| `1.31.6` | `eks-local-outposts.1` | Lançamento inicial do Kubernetes versão `v1.31` para clusters locais do Amazon EKS no Outposts | 9 de abril de 2025 |
## Versão do Kubernetes `1.30`
Os seguintes controladores de admissão estão habilitados para todas as versões da plataforma `1.30`: `CertificateApproval`, `CertificateSigning`, `CertificateSubjectRestriction`, `ClusterTrustBundleAttest`, `DefaultIngressClass`, `DefaultStorageClass`, `DefaultTolerationSeconds`, `ExtendedResourceToleration`, `LimitRanger`, `MutatingAdmissionWebhook`, `NamespaceLifecycle`, `NodeRestriction`, `PersistentVolumeClaimResize`, `PodSecurity`, `Priority`, `ResourceQuota`, `RuntimeClass`, `ServiceAccount`, `StorageObjectInUseProtection`, `TaintNodesByCondition`, `ValidatingAdmissionPolicy` e `ValidatingAdmissionWebhook`.
| Versão do Kubernetes | Versão da plataforma Amazon EKS | Notas da versão | Data de lançamento |
| --- | --- | --- | --- |
| `1.30.14` | `eks-local-outposts.10` | Nova versão da plataforma com correções de segurança e melhorias. AWS IAM Authenticator atualizado para `v0.7.8`. Plug-in da CNI da Amazon VPC para Kubernetes atualizada para `v1.20.4`. Versão do Bottlerocket atualizada para `v1.52.0`. | 23 de dezembro de 2025 |
| `1.30.14` | `eks-local-outposts.7` | Nova versão da plataforma com correções de segurança e melhorias. kube-proxy atualizado para `v1.30.14`. AWS IAM Authenticator atualizado para `v0.7.4`. Plug-in da CNI da Amazon VPC para Kubernetes atualizada para `v1.20.2`. Versão do Bottlerocket atualizada para `v1.47.0`. | 3 de outubro de 2025 |
| `1.30.13` | `eks-local-outposts.6` | Nova versão da plataforma com correções de segurança e melhorias. kube-proxy atualizado para `v1.30.13`. AWS IAM Authenticator atualizado para `v0.7.2`. Plug-in da CNI da Amazon VPC para Kubernetes atualizada para `v1.20.0`. Versão do Bottlerocket atualizada para `v1.43.0`. | 09 de agosto de 2025 |
| `1.30.11` | `eks-local-outposts.5` | Nova versão da plataforma com correções de segurança e melhorias. kube-proxy atualizado para `v1.30.11`. AWS IAM Authenticator atualizado para `v0.7.1`. Plug-in da CNI da Amazon VPC para Kubernetes atualizado para a versão `v1.19.5`. Versão do Bottlerocket atualizada para a versão `v1.40.0`. | 19 de junho de 2025 |
| `1.30.10` | `eks-local-outposts.4` | Nova versão da plataforma com correções de segurança e melhorias. Versão do Bottlerocket atualizada para `v1.36.0`. | 24 de abril de 2025 |
| `1.30.10` | `eks-local-outposts.3` | Nova versão da plataforma com correções de segurança e melhorias. kube-proxy atualizado para `v1.30.10`. AWS IAM Authenticator atualizado para `v0.6.29`. Plug-in da CNI da Amazon VPC para Kubernetes atualizada para `v1.19.2`. CoreDNS atualizado para `v1.11.4`. AWS Cloud Controller Manager atualizado para `v1.30.8`. Versão do Bottlerocket atualizada para `v1.34.0`. | 27 de março de 2025 |
| `1.30.7` | `eks-local-outposts.2` | Nova versão da plataforma com correções de segurança e melhorias. kube-proxy atualizado para `v1.30.7`. AWS IAM Authenticator atualizado para `v0.6.28`. Plug-in da CNI da Amazon VPC para Kubernetes atualizada para `v1.19.0`. Versão do Bottlerocket atualizada para `v1.29.0`. | 10 de janeiro de 2025 |
| `1.30.5` | `eks-local-outposts.1` | Lançamento inicial do Kubernetes versão `v1.30` para clusters locais do Amazon EKS no Outposts | 13 de novembro de 2024 |
## Versão do Kubernetes `1.29`
Os seguintes controladores de admissão estão habilitados para todas as versões da plataforma `1.29`: `CertificateApproval`, `CertificateSigning`, `CertificateSubjectRestriction`, `ClusterTrustBundleAttest`, `DefaultIngressClass`, `DefaultStorageClass`, `DefaultTolerationSeconds`, `ExtendedResourceToleration`, `LimitRanger`, `MutatingAdmissionWebhook`, `NamespaceLifecycle`, `NodeRestriction`, `PersistentVolumeClaimResize`, `PodSecurity`, `Priority`, `ResourceQuota`, `RuntimeClass`, `ServiceAccount`, `StorageObjectInUseProtection`, `TaintNodesByCondition`, `ValidatingAdmissionPolicy` e `ValidatingAdmissionWebhook`.
| Versão do Kubernetes | Versão da plataforma Amazon EKS | Notas da versão | Data de lançamento |
| --- | --- | --- | --- |
| `1.29.15` | `eks-local-outposts.13` | Nova versão da plataforma com correções de segurança e melhorias. AWS IAM Authenticator atualizado para `v0.7.8`. Plug-in da CNI da Amazon VPC para Kubernetes atualizada para `v1.20.4`. Versão do Bottlerocket atualizada para `v1.52.0`. | 23 de dezembro de 2025 |
| `v1.29.15` | `eks-local-outposts.10` | Nova versão da plataforma com correções de segurança e melhorias. AWS IAM Authenticator atualizado para `v0.7.4`. Plug-in da CNI da Amazon VPC para Kubernetes atualizada para `v1.20.2`. Versão do Bottlerocket atualizada para `v1.47.0`. | 3 de outubro de 2025 |
| `v1.29.15` | `eks-local-outposts.9` | Nova versão da plataforma com correções de segurança e melhorias. AWS IAM Authenticator atualizado para `v0.7.2`. Plug-in da CNI da Amazon VPC para Kubernetes atualizada para `v1.20.0`. Versão do Bottlerocket atualizada para `v1.43.0`. | 9 de agosto de 2025 |
| `v1.29.15` | `eks-local-outposts.8` | Nova versão da plataforma com correções de segurança e melhorias. kube-proxy atualizado para `v1.29.15`. AWS IAM Authenticator atualizado para `v0.7.1`. Plug-in da CNI da Amazon VPC para Kubernetes atualizada para `v1.19.5`. Versão do Bottlerocket atualizada para `v1.40.0`. | 19 de junho de 2025 |
| `v1.29.14` | `eks-local-outposts.7` | Nova versão da plataforma com correções de segurança e melhorias. Versão do Bottlerocket atualizada para `v1.36.0`. | 24 de março de 2025 |
| `v1.29.14` | `eks-local-outposts.6` | Nova versão da plataforma com correções de segurança e melhorias. kube-proxy atualizado para `v1.29.14`. Plug-in da CNI da Amazon VPC para Kubernetes atualizada para `v1.19.2`. CoreDNS atualizado para `v1.11.4`. AWS Cloud Controller Manager atualizado para `v1.29.8`. Versão do Bottlerocket atualizada para `v1.34.0`. | 27 de março de 2025 |
| `v1.29.11` | `eks-local-outposts.5` | Nova versão da plataforma com correções de segurança e melhorias. kube-proxy atualizado para `v1.29.11`. Plug-in da CNI da Amazon VPC para Kubernetes atualizada para `v1.19.0`. A imagem do CoreDNS foi atualizada para a versão `v1.11.3`. Versão do Bottlerocket atualizada para `v1.29.0`. | 10 de janeiro de 2025 |
| `1.29.9` | `eks-local-outposts.4` | Nova versão da plataforma com correções de segurança e melhorias. kube-proxy atualizado para `v1.29.9`. AWS IAM Authenticator atualizado para `v0.6.26`. Versão do Bottlerocket atualizada para `v1.26.0`. | 8 de novembro de 2024 |
| `1.29.6` | `eks-local-outposts.3` | Nova versão da plataforma com correções de segurança e melhorias. Versão do Bottlerocket atualizada para `v1.22.0`. | 22 de outubro de 2024 |
| `1.29.6` | `eks-local-outposts.2` | Nova versão da plataforma com correções de segurança e melhorias. Versão do Bottlerocket atualizada para `v1.21.0`. | 27 de agosto de 2024 |
| `1.29.6` | `eks-local-outposts.1` | Lançamento inicial do Kubernetes versão `v1.29` para clusters locais do Amazon EKS no Outposts | 20 de agosto de 2024 |
# Criar um VPC e sub-redes para clusters do Amazon EKS em AWS Outposts
Ao criar um cluster local, você especifica uma VPC e pelo menos uma sub-rede privada que é executada no Outposts. Este tópico fornece uma visão geral dos requisitos e considerações sobre a VPC e as sub-redes para o cluster local.
## Requisitos e considerações para VPCs
Quando você cria um cluster local, a VPC especificada deve atender aos requisitos e considerações a seguir:
+ Certifique-se de que a VPC tenha endereços IP suficientes para o cluster local, para todos os nós e para outros recursos do Kubernetes que você queira criar. Se a VPC que você deseja usar não tiver endereços IP suficientes, tente aumentar a quantidade de endereços IP disponíveis. É possível fazer isso [associando blocos de Encaminhamento Entre Domínios Sem Classificação (CIDR)](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#add-ipv4-cidr) com sua VPC. É possível associar blocos CIDR privados (RFC 1918) e públicos (não RFC 1918) à VPC antes ou depois de criar o cluster. Um cluster pode levar até cinco horas para reconhecer um bloco CIDR que você associou a uma VPC.
+ A VPV não pode ter prefixos IP ou blocos CIDR IPv6 atribuídos. Devido a essas restrições, as informações abordadas em [Atribuir mais endereços IP aos nós do Amazon EKS com prefixos](cni-increase-ip-addresses.md) e [Saiba mais sobre endereços IPv6 para clusters, pods e serviços](cni-ipv6.md) não se aplicam à sua VPC.
+ A VPC tem um nome de host DNS e a resolução de DNS habilitados. Sem esses recursos, haverá falha na criação do cluster e será necessário habilitar os recursos e recriar o cluster. Para mais informações, consulte [Atributos de DNS para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html), no Guia do usuário da Amazon VPC.
+ Para acessar o cluster local pela rede local, a VPC deve estar associada à tabela de rotas do gateway local do Outpost. Para obter mais informações, consulte [Associações de VPC](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html#vpc-associations) no Guia do Usuário do AWS Outposts.
## Requisitos e considerações para sub-redes
Quando você criar o cluster, especifique pelo menos uma sub-rede privada. Se você especificar mais de uma sub-rede, as instâncias do ambiente de gerenciamento do Kubernetes serão distribuídas uniformemente pelas sub-redes. Se mais de uma sub-rede for especificada, as sub-redes deverão estar no mesmo Outpost. Além disso, as sub-redes também devem ter rotas adequadas e permissões de grupo de segurança para se comunicarem entre si. As sub-redes que você especificar ao criar um cluster local devem atender aos requisitos a seguir:
+ As sub-redes devem estar todas no mesmo Outpost lógico.
+ Juntas, as sub-redes devem ter pelo menos três endereços IP disponíveis para as instâncias do ambiente de gerenciamento do Kubernetes. Se três sub-redes forem especificadas, cada uma delas deverá ter pelo menos um endereço IP disponível. Se duas sub-redes forem especificadas, cada uma delas deverá ter pelo menos dois endereços IP disponíveis. Se uma sub-rede for especificada, ela deverá ter pelo menos três endereços IP disponíveis.
+ As sub-redes têm uma rota para o [gateway local](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html) do rack do Outpost para acessar o servidor de API do Kubernetes pela rede local. Se as sub-redes não tiverem uma rota para o gateway local do rack do Outpost, você deverá se comunicar com o servidor de API do Kubernetes de dentro da VPC.
+ As sub-redes devem utilizar uma nomenclatura baseada em endereço IP. A [nomenclatura baseada em recursos](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html#instance-naming-rbn) do Amazon EC2 não é compatível com o Amazon EKS.
## Acesso à sub-rede a serviços da AWS
As sub-redes privadas do cluster local nos postos avançados devem ser capazes de se comunicar com os serviços regionais do AWS. É possível conseguir isso ao usar um [gateway NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) para acesso de saída à Internet ou, caso deseje manter todo o tráfego privado em sua VPC, ao usar [endpoints da VPC de interface](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html).
### Como usar um gateway NAT
As sub-redes privadas do cluster local no Outposts devem ter uma tabela de rotas associada que tenha uma rota para um gateway NAT em uma sub-rede pública que esteja na zona de disponibilidade principal do Outpost. A sub-rede pública deve ter uma rota para um [gateway da Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html). O gateway NAT permite acesso de saída à Internet e impede conexões de entrada não solicitadas da Internet para instâncias no Outpost.
### Usar VPC endpoints da interface do
Se as sub-redes privadas do cluster local no Outposts não tiverem uma conexão de saída com a Internet ou se você desejar manter todo o tráfego privado em sua VPC, crie os endpoints da VPC de interface e o [endpoint do gateway](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html) a seguir em uma sub-rede regional antes de criar seu cluster.
| Endpoint | Tipo de endpoint |
| --- | --- |
| `com.amazonaws.region-code.ssm` | Interface |
| `com.amazonaws.region-code.ssmmessages` | Interface |
| `com.amazonaws.region-code.ec2messages` | Interface |
| `com.amazonaws.region-code.ec2` | Interface |
| `com.amazonaws.region-code.secretsmanager` | Interface |
| `com.amazonaws.region-code.logs` | Interface |
| `com.amazonaws.region-code.sts` | Interface |
| `com.amazonaws.region-code.ecr.api` | Interface |
| `com.amazonaws.region-code.ecr.dkr` | Interface |
| `com.amazonaws.region-code.s3` | Gateway |
Os endpoints devem atender aos seguintes requisitos:
+ Ter sido criado em uma sub-rede privada localizada na zona de disponibilidade principal do Outpost.
+ Ter nomes DNS privados habilitados.
+ Ter um grupo de segurança anexado que permita o tráfego HTTPS de entrada do intervalo CIDR da sub-rede privada do Outpost.
A criação de endpoints gera cobranças. Para obter mais informações, consulte [Preços do AWS PrivateLink](https://aws.amazon.com/privatelink/pricing/). Se o pod precisar de acesso a outros serviços da AWS, será necessário criar endpoints adicionais. Para obter uma lista abrangente de endpoints, consulte [AWS services that integrate with AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html).
## Crie uma VPC
Você pode criar uma VPC que atenda aos requisitos anteriores usando um dos seguintes modelos do AWS CloudFormation:
+ **[Modelo 1](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-09-20/amazon-eks-local-outposts-vpc-subnet.yaml)**: esse modelo cria uma VPC com uma sub-rede privada no Outpost e uma sub-rede pública na região da AWS. A sub-rede privada tem uma rota para a Internet por meio de um gateway NAT que reside na sub-rede pública na região AWS. Esse modelo pode ser usado para criar um cluster local em uma sub-rede com acesso de egresso à Internet.
+ **[Modelo 2](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-03-20/amazon-eks-local-outposts-fully-private-vpc-subnet.yaml)**: esse modelo cria uma VPC com uma sub-rede privada no Outpost e o conjunto mínimo de endpoints de VPC necessários para criar um cluster local em uma sub-rede que não tenha acesso à Internet de entrada ou saída (também chamada de sub-rede privada).
# Prepare clusters locais do Amazon EKS em AWS Outposts para desconexões de rede
Se a sua rede local tiver perdido a conectividade com o AWS Cloud, você poderá continuar a usar o cluster local do Amazon EKS em um Outpost. Este tópico aborda como você pode preparar o cluster local para desconexões de rede e as considerações relacionadas.
+ Clusters locais permitem estabilidade e operações contínuas durante desconexões temporárias e não planejadas da rede. AWS O Outposts continua sendo uma oferta totalmente conectada que atua como uma extensão da Nuvem AWS no seu data center. Em caso de desconexão da rede entre o Outpost e o AWS Cloud, recomendamos tentar restaurar a conexão. Para obter instruções, consulte [a lista de verificação de solução de problemas da rede do rack do AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/network-troubleshoot.html) no *Guia do usuário do AWS Outposts*. Para obter informações sobre como solucionar problemas de clusters locais, consulte [Solucionar problemas de clusters locais do Amazon EKS em AWS Outposts](eks-outposts-troubleshooting.md).
+ Os Outposts emitem uma métrica `ConnectedStatus` que você pode usar para monitorar o estado da conectividade do Outpost. Para obter mais informações, consulte [Outposts Metrics](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-cloudwatch-metrics.html#outposts-metrics) no *Guia do usuário do AWS Outposts*.
+ Os clusters locais usam o IAM como mecanismo de autenticação padrão usando o [autenticador do AWS Identity and Access Management para Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator). O IAM não está disponível durante desconexões de rede. Assim, os clusters locais são compatíveis com um mecanismo de autenticação alternativo usando certificados `x.509` que você pode usar para se conectar ao cluster durante desconexões de rede. Para obter informações sobre como obter e usar um certificado `x.509` para o cluster, consulte [Autenticar no cluster local durante uma desconexão de rede](#outposts-network-disconnects-authentication).
+ Caso não você consiga acessar o Route 53 durante desconexões de rede, considere o uso de servidores DNS locais no ambiente on-premises. As instâncias do ambiente de gerenciamento do Kubernetes usam endereços IP estáticos. Você pode configurar os hosts que usa para se conectar ao cluster com o nome do host do endpoint e os endereços IP como uma alternativa ao uso de servidores DNS locais. Para obter mais informações, consulte [DNS](https://docs.aws.amazon.com/outposts/latest/userguide/how-outposts-works.html#dns) no *Guia do usuário do AWS Outposts*.
+ Se você esperar aumentos no tráfego das aplicações durante desconexões de rede, pode provisionar capacidade computacional adicional no cluster quando estiver conectado à nuvem. As instâncias do Amazon EC2 estão incluídas no preço do AWS Outposts. Portanto, a execução de instâncias adicionais não afeta o custo de uso da AWS.
+ Durante desconexões de rede para permitir operações de criação, atualização e escalação de workloads, as imagens de contêiner da aplicação devem estar acessíveis pela rede local e o cluster deve ter capacidade suficiente. Os clusters locais não hospedam um registro de contêiner para você. Se os pods foram executados anteriormente nesses nós, as imagens de contêineres estão armazenadas em cache nos nós. Se você normalmente extrair imagens de contêiner da aplicação do Amazon ECR na nuvem, considere executar um cache ou registro local. Um cache ou registro local será útil se você precisar de operações de criação, atualização e escalação para recursos de workload durante desconexões de rede.
+ Os clusters locais usam o Amazon EBS como a classe de armazenamento padrão para volumes persistentes e o driver da CSI do Amazon EBS para gerenciar o ciclo de vida dos volumes persistentes do Amazon EBS. Durante as desconexões de rede, os pods que são baseados no Amazon EBS não podem ser criados, atualizados nem escalados. Isso porque essas operações exigem chamadas para a API do Amazon EBS na nuvem. Se você estiver implantando workloads com estado em clusters locais e precisar de operações de criação, atualização ou escalabilidade durante desconexões de rede, considere usar um mecanismo de armazenamento alternativo.
+ Os snapshots do Amazon EBS não poderão ser criados ou excluídos se o AWS Outposts não puder acessar as APIs relevantes da região do AWS (como as APIs do Amazon EBS ou do Amazon S3).
+ Ao integrar o ALB (Ingress) com o AWS Certificate Manager (ACM), os certificados são enviados e armazenados na memória da instância do AWS Outposts ALB Compute. A terminação TLS atual continuará a funcionar no caso de uma desconexão da região AWS. As operações de mutação nesse contexto falharão (como novas definições de entrada, novas operações de API de certificados baseados em ACM, escala de computação do ALB ou rotação de certificados). Para obter mais informações, consulte [Solução de problemas de renovação de certificados gerenciados](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-renewal.html) no *Guia do usuário do AWS Certificate Manager*.
+ Os logs do ambiente de gerenciamento do Amazon EKS são armazenados em cache localmente nas instâncias do ambiente de gerenciamento do Kubernetes durante as desconexões de rede. Após a reconexão, os logs são enviados para o CloudWatch Logs na região da AWS principal. Você pode usar o [Prometheus](https://prometheus.io/), o [Grafana](https://grafana.com/) ou as soluções de parceiros do Amazon EKS para monitorar o cluster localmente usando o endpoint de métricas do servidor de API do Kubernetes ou usando o Fluent Bit para logs.
+ Se você estiver usando o AWS Load Balancer Controller no Outposts para tráfego das aplicações, os pods existentes comandados pelo AWS Load Balancer Controller continuarão a receber tráfego durante as desconexões de rede. Os novos pods criados durante as desconexões de rede não recebem tráfego até que o Outpost seja reconectado à Nuvem AWS. Considere a possibilidade de definir a contagem de réplicas para suas aplicações enquanto estiver conectado ao AWS Cloud para acomodar suas necessidades de dimensionamento durante as desconexões de rede.
+ O plug-in CNI da Amazon VPC para Kubernetes usa como padrão o [modo IP secundário](https://aws.github.io/aws-eks-best-practices/networking/vpc-cni/#overview). Ele é configurado com `WARM_ENI_TARGET` = `1`, o que permite que o plug-in mantenha disponível “uma interface de rede totalmente elástica” de endereços IP. Considere mudar os valores `WARM_ENI_TARGET`,`WARM_IP_TARGET` e `MINIMUM_IP_TARGET` de acordo com suas necessidades de escalonamento durante um estado desconectado. Para obter mais informações, consulte o arquivo [readme](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) do plug-in no GitHub. Para obter uma lista do número máximo de pods que é compatível com cada tipo de instância, consulte o arquivo [eni-max-pods.txt](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/misc/eni-max-pods.txt) no GitHub.
## Autenticar no cluster local durante uma desconexão de rede
O AWS Identity and Access Management (IAM) não está disponível durante desconexões de rede. Você não pode autenticar no cluster local usando credenciais do IAM enquanto está desconectado. Porém, você pode se conectar ao cluster pela rede local usando certificados `x509` quando estiver desconectado. Você precisa baixar e armazenar o certificado `X509` de um cliente para usar durante as desconexões. Neste tópico, você aprenderá a criar e usar o certificado para autenticação no cluster quando ele está em um estado desconectado.
1. Crie uma solicitação de assinatura do certificado.
1. Gere uma solicitação de assinatura do certificado.
```
openssl req -new -newkey rsa:4096 -nodes -days 365 \
-keyout admin.key -out admin.csr -subj "/CN=admin"
```
1. Crie uma solicitação de assinatura do certificado no Kubernetes.
```
BASE64_CSR=$(cat admin.csr | base64 -w 0)
cat << EOF > admin-csr.yaml
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
name: admin-csr
spec:
signerName: kubernetes.io/kube-apiserver-client
request: ${BASE64_CSR}
usages:
- client auth
EOF
```
1. Crie uma solicitação de assinatura do certificado usando o `kubectl`.
```
kubectl create -f admin-csr.yaml
```
1. Verifique o status da solicitação de assinatura do certificado.
```
kubectl get csr admin-csr
```
Veja um exemplo de saída abaixo.
```
NAME AGE REQUESTOR CONDITION
admin-csr 11m kubernetes-admin Pending
```
O Kubernetes criou a solicitação de assinatura do certificado.
1. Aprove a solicitação de assinatura do certificado.
```
kubectl certificate approve admin-csr
```
1. Verifique novamente o status da solicitação de assinatura do certificado para aprovação.
```
kubectl get csr admin-csr
```
Veja um exemplo de saída abaixo.
```
NAME AGE REQUESTOR CONDITION
admin-csr 11m kubernetes-admin Approved
```
1. Recupere e verifique o certificado.
1. Recupere o certificado.
```
kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt
```
1. Verifique o certificado.
```
cat admin.crt
```
1. Crie uma vinculação de função de cluster para um usuário `admin`.
```
kubectl create clusterrolebinding admin --clusterrole=cluster-admin \
--user=admin --group=system:masters
```
1. Gere um kubeconfig com escopo de usuário para um estado desconectado.
Você pode gerar um arquivo `kubeconfig` usando os certificados `admin` baixados. Substitua *my-cluster* e *apiserver-endpoint* nos comandos a seguir.
```
aws eks describe-cluster --name my-cluster \
--query "cluster.certificateAuthority" \
--output text | base64 --decode > ca.crt
```
```
kubectl config --kubeconfig admin.kubeconfig set-cluster my-cluster \
--certificate-authority=ca.crt --server apiserver-endpoint --embed-certs
```
```
kubectl config --kubeconfig admin.kubeconfig set-credentials admin \
--client-certificate=admin.crt --client-key=admin.key --embed-certs
```
```
kubectl config --kubeconfig admin.kubeconfig set-context admin@my-cluster \
--cluster my-cluster --user admin
```
```
kubectl config --kubeconfig admin.kubeconfig use-context admin@my-cluster
```
1. Visualize o arquivo `kubeconfig`.
```
kubectl get nodes --kubeconfig admin.kubeconfig
```
1. Se você já tiver serviços em produção no Outpost, pule esta etapa. Se o Amazon EKS for o único serviço em execução no Outpost e o Outpost não estiver em produção no momento, você poderá simular uma desconexão de rede. Antes de entrar em produção com o cluster local, simule uma desconexão para ter certeza de que pode acessar o cluster mesmo quando ele está no estado desconectado.
1. Aplique regras de firewall nos dispositivos de rede que conectam seu Outpost à região da AWS. Com isso, o link de serviço do Outpost é desconectado. Você não pode criar novas instâncias. As instâncias em execução no momento perdem a conectividade com a região AWS e a Internet.
1. Você pode testar a conexão com o cluster local enquanto estiver desconectado usando o certificado `x509`. Certifique-se de alterar o `kubeconfig` para o `admin.kubeconfig` que você criou em uma etapa anterior. Substitua *my-cluster* pelo nome do cluster local.
```
kubectl config use-context admin@my-cluster --kubeconfig admin.kubeconfig
```
Se você notar algum problema com os clusters locais enquanto eles estiverem no estado desconectado, será recomendável abrir um tíquete de suporte.
# Selecione tipos de instância e grupos de posicionamento para clusters do Amazon EKS em AWS Outposts com base em considerações de capacidade
Este tópico fornece orientação para a seleção de tipo de instância do ambiente de gerenciamento do Kubernetes e (opcionalmente) o uso de grupos de posicionamento para atender aos requisitos de alta disponibilidade do cluster local do Amazon EKS em um Outpost.
Antes de selecionar um tipo de instância (como `m5`, `c5` ou `r5`) para usar no ambiente de gerenciamento do Kubernetes do cluster local no Outposts, confirme os tipos de instâncias que estão disponíveis na configuração do Outpost. Depois que você identificar os tipos de instância disponíveis, selecione o tamanho da instância (por exemplo, `large`, `xlarge` ou `2xlarge`) com base no número de nós que as workloads exigem. A tabela a seguir fornece recomendações para a escolha do tamanho de uma instância.
**nota**
Os tamanhos das instâncias devem ser alocados nos Outposts. Certifique-se de ter capacidade suficiente para três instâncias do tamanho disponível no Outposts durante a vida útil do cluster local. Para obter uma lista dos tipos de instância do Amazon EC2 disponíveis, consulte as seções de computação e armazenamento nos [recursos de rack do AWS Outposts](https://aws.amazon.com/outposts/rack/features/).
| Número de nós | Tamanho da instância do ambiente de gerenciamento do Kubernetes |
| --- | --- |
| 1–20 | `large` |
| 21–100 | `xlarge` |
| 101–250 | `2xlarge` |
| 251–500 | `4xlarge` |
O armazenamento para o ambiente de gerenciamento do Kubernetes requer 246 GB de armazenamento do Amazon EBS para cada cluster local para atender ao IOPS necessário para `etcd`. Na criação do cluster local, os volumes do Amazon EBS são provisionados automaticamente.
## Posicionamento do ambiente de gerenciamento
Quando você não especifica um grupo de posicionamento com a propriedade `OutpostConfig.ControlPlanePlacement.GroupName`, as instâncias do Amazon EC2 provisionadas para o ambiente de gerenciamento do Kubernetes não recebem nenhuma imposição específica de posicionamento de hardware em toda a capacidade subjacente disponível no Outpost.
Você pode usar grupos de posicionamento para atender aos requisitos de alta disponibilidade do cluster local do Amazon EKS em um Outpost. Ao especificar um grupo de posicionamento durante a criação do cluster, você influencia o posicionamento das instâncias do ambiente de gerenciamento do Kubernetes. As instâncias são distribuídas pelo hardware subjacente independente (racks ou hosts), minimizando o impacto das instância correlacionadas no caso de falhas de hardware.
O tipo de distribuição que você pode configurar depende do número de racks do Outpost que você tem na implantação.
+ **Implantações com um ou dois racks físicos em um único Outpost lógico**: é necessário ter pelo menos três hosts configurados com o tipo de instância que você escolher para as suas instâncias do ambiente de gerenciamento do Kubernetes. Um grupo com posicionamento *distribuído* usando a *distribuição em nível de host* garante que todas as instâncias do ambiente de gerenciamento do Kubernetes sejam executadas em hosts distintos, em todos os racks subjacentes disponíveis na implantação do Outpost.
+ **Implantações com três ou mais racks físicos em um único Outpost lógico**: é necessário ter, pelo menos, três hosts configurados com o tipo de instância que você escolher para as suas instâncias do ambiente de gerenciamento do Kubernetes. Um grupo com posicionamento *distribuído* usando a *distribuição em nível de rack* garante que todas as instâncias do ambiente de gerenciamento do Kubernetes sejam executadas em racks distintos na implantação do Outpost. Ou então, você pode usar o grupo de posicionamento de *distribuição no nível dos hosts*, conforme descrito na opção anterior.
Você é responsável por criar o grupo de posicionamento desejado. Você especifica o grupo de posicionamento ao chamar a API `CreateCluster`. Para obter mais informações sobre grupos de posicionamento e como criá-los, consulte [Grupos de posicionamento](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) no Guia do usuário do Amazon EC2.
+ Quando um grupo de posicionamento é especificado, deve haver capacidade disponível alocada no Outpost para a criação bem-sucedida de um cluster local do Amazon EKS. A capacidade varia dependendo do tipo de distribuição que você usa: distribuição em hosts ou em racks. Se não houver capacidade suficiente, o cluster permanecerá no estado `Creating`. Você pode verificar o endereço `Insufficient Capacity Error` no campo health da resposta da API [DescribeCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html). Você deve liberar capacidade para que o processo de criação prossiga.
+ Durante as atualizações de versão e plataforma do cluster local do Amazon EKS, as instâncias do ambiente de gerenciamento do Kubernetes do cluster são substituídas por novas instâncias usando uma estratégia de atualização contínua. Durante esse processo de substituição, cada instância do ambiente de gerenciamento é encerrada, liberando o slot correspondente. Uma nova instância atualizada é provisionada em seu lugar. A instância atualizada pode ser posicionada no slot que foi liberado. Se o slot for consumido por outra instância não relacionada e não restar mais capacidade para atender ao requisito de topologia de distribuição, o cluster permanecerá no estado `Updating`. Você pode ver o respectivo `Insufficient Capacity Error` no campo health da resposta da API [DescribeCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html). Você deve liberar capacidade para que o processo de atualização possa prosseguir e restabelecer os altos níveis de disponibilidade anteriores.
+ É possível criar até 500 grupos de posicionamento por conta em cada região da AWS. Para obter mais informações, consulte [Regras gerais e limitações](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#placement-groups-limitations-general) no Guia do usuário do Amazon EC2.
# Solucionar problemas de clusters locais do Amazon EKS em AWS Outposts
Este tópico aborda alguns erros comuns que você pode encontrar ao usar clusters locais e como solucionar esses problemas. Os clusters locais são semelhantes aos clusters do Amazon EKS na nuvem, mas existem algumas diferenças na forma como eles são gerenciados pelo Amazon EKS.
**Importante**
Nunca encerre nenhuma instância do ambiente de gerenciamento do `Kubernetes` do cluster local gerenciado do EKS em execução no Outpost, a menos que seja explicitamente instruído pelo AWS Support. O encerramento dessas instâncias representa um risco à disponibilidade do serviço de cluster local, incluindo a perda do cluster local caso várias instâncias sejam encerradas simultaneamente. As instâncias do ambiente de gerenciamento do `Kubernetes` de cluster local do EKS são identificadas pela tag `eks-local:controlplane-name` no console de instâncias do EC2.
## Comportamento da API
Os clusters locais são criados por meio da API do Amazon EKS, mas são executados de maneira assíncrona. Isso significa que as solicitações à API do Amazon EKS retornam imediatamente para os clusters locais. Porém, essas solicitações podem ser bem-sucedidas, antecipar-se à falha devido a erros de validação de entrada ou falhar e ter erros de validação descritivos. Esse comportamento é semelhante ao da API do Kubernetes.
Os clusters locais não fazem a transição para um status `FAILED`. O Amazon EKS tenta continuamente reconciliar o estado do cluster com o estado desejado solicitado pelo usuário. Como resultado, um cluster local pode permanecer no estado `CREATING` por um período prolongado até que o problema subjacente seja resolvido.
## Descrever o campo de integridade do cluster
Os problemas do cluster local podem ser descobertos usando o comando [describe-cluster do](https://docs.aws.amazon.com/cli/latest/reference/eks/describe-cluster.html) Amazon EKS AWS CLI. Problemas de cluster local são revelados pelo campo `cluster.health` da resposta do comando `describe-cluster`. A mensagem contida nesse campo inclui um código de erro, uma mensagem descritiva e IDs de recursos relacionados. Essas informações estão disponíveis somente por meio da API do Amazon EKS e da AWS CLI. No exemplo a seguir, substitua *my-cluster* pelo nome do cluster local.
```
aws eks describe-cluster --name my-cluster --query 'cluster.health'
```
Veja um exemplo de saída abaixo.
```
{
"issues": [
{
"code": "ConfigurationConflict",
"message": "The instance type 'm5.large' is not supported in Outpost 'my-outpost-arn'.",
"resourceIds": [
"my-cluster-arn"
]
}
]
}
```
Se o problema não puder ser reparado, talvez seja necessário excluir o cluster local e criar um novo. Por exemplo, tentar provisionar um cluster com um tipo de instância que não está disponível no Outpost. A tabela a seguir inclui erros comuns relacionados à integridade.
| Cenário de erro | Código | Mensagem | ResourceIds |
| --- | --- | --- | --- |
| Não foi possível encontrar as sub-redes fornecidas. | `ResourceNotFound` | `The subnet ID subnet-id does not exist` | Todos os IDs de sub-rede fornecidos |
| As sub-redes fornecidas não pertencem à mesma VPC. | `ConfigurationConflict` | `Subnets specified must belong to the same VPC` | Todos os IDs de sub-rede fornecidos |
| Algumas sub-redes fornecidas não pertencem ao Outpost especificado. | `ConfigurationConflict` | `Subnet subnet-id expected to be in outpost-arn, but is in other-outpost-arn ` | ID de sub-rede problemática |
| Algumas sub-redes fornecidas não pertencem a nenhum Outpost. | `ConfigurationConflict` | `Subnet subnet-id is not part of any Outpost` | ID de sub-rede problemática |
| Algumas sub-redes fornecidas não têm endereços livres suficientes para a criação de interfaces de rede elásticas para as instâncias do ambiente de gerenciamento. | `ResourceLimitExceeded` | `The specified subnet does not have enough free addresses to satisfy the request.` | ID de sub-rede problemática |
| O tipo de instância do ambiente de gerenciamento especificado não é compatível com o Outpost. | `ConfigurationConflict` | `The instance type type is not supported in Outpost outpost-arn ` | ARN do cluster |
| Você encerrou uma instância do Amazon EC2 do ambiente de gerenciamento ou `run-instance` teve êxito, mas o estado sofreu alterações para `Terminated`. Isso pode acontecer por um período após a reconexão do Outpost e os erros internos do Amazon EBS causarem uma falha no fluxo de trabalho interno do Amazon EC2. | `InternalFailure` | `EC2 instance state "Terminated" is unexpected` | ARN do cluster |
| Você não tem capacidade suficiente no Outpost. Isso também pode acontecer quando um cluster estiver sendo criado se um Outpost for desconectado da região da AWS. | `ResourceLimitExceeded` | `There is not enough capacity on the Outpost to launch or start the instance.` | ARN do cluster |
| A conta excedeu a cota de grupo de segurança. | `ResourceLimitExceeded` | Mensagem de erro retornada pela API do Amazon EC2 | ID da VPC de destino |
| A conta excedeu a cota de interface de rede elástica. | `ResourceLimitExceeded` | Mensagem de erro retornada pela API do Amazon EC2 | ID da sub-rede de destino |
| As instâncias do ambiente de gerenciamento não eram acessíveis por meio do AWS Systems Manager. Para saber a resolução, consulte [As instâncias do ambiente de gerenciamento não podem ser acessadas por meio do AWS Systems Manager](#outposts-troubleshooting-control-plane-instances-ssm). | `ClusterUnreachable` | As instâncias do ambiente de gerenciamento do Amazon EKS não podem ser acessadas por meio do SSM. Verifique a configuração do SSM e da rede e consulte a documentação de solução de problemas do EKS no Outposts. | IDs de instâncias do Amazon EC2 |
| Ocorreu um erro ao obter detalhes de um grupo de segurança gerenciado ou de uma interface de rede elástica. | Com base no código de erro do cliente Amazon EC2. | Mensagem de erro retornada pela API do Amazon EC2 | Todos os IDs de grupos de segurança gerenciados |
| Ocorreu um erro ao autorizar ou revogar as regras de ingresso de grupo de segurança. Isso se aplica aos grupos de segurança do cluster e do ambiente de gerenciamento. | Com base no código de erro do cliente Amazon EC2. | Mensagem de erro retornada pela API do Amazon EC2 | ID de grupo de segurança problemático |
| Ocorreu um erro ao excluir uma interface de rede elástica de uma instância do ambiente de gerenciamento. | Com base no código de erro do cliente Amazon EC2. | Mensagem de erro retornada pela API do Amazon EC2 | ID de interface de rede elástica problemática |
A tabela a seguir lista os erros de outros serviços do AWS que são apresentados no campo health da resposta do `describe-cluster`.
| Código de erro do Amazon EC2 | Código de problema de integridade do cluster | Descrição |
| --- | --- | --- |
| `AuthFailure` | `AccessDenied` | Esse erro pode ocorrer por vários motivos. O motivo mais comum é que você acidentalmente removeu do serviço do ambiente de gerenciamento uma tag que o serviço usa para reduzir o escopo da política de perfil vinculada. Se isso ocorrer, o Amazon EKS não poderá mais gerenciar e monitorar esses recursos da AWS. |
| `UnauthorizedOperation` | `AccessDenied` | Esse erro pode ocorrer por vários motivos. O motivo mais comum é que você acidentalmente removeu do serviço do ambiente de gerenciamento uma tag que o serviço usa para reduzir o escopo da política de perfil vinculada. Se isso ocorrer, o Amazon EKS não poderá mais gerenciar e monitorar esses recursos da AWS. |
| `InvalidSubnetID.NotFound` | `ResourceNotFound` | Esse erro ocorre quando o ID da sub-rede para as regras de ingresso de um grupo de segurança não pode ser encontrado. |
| `InvalidPermission.NotFound` | `ResourceNotFound` | Esse erro ocorre quando as permissões para as regras de ingresso de um grupo de segurança não estão corretas. |
| `InvalidGroup.NotFound` | `ResourceNotFound` | Esse erro ocorre quando o grupo das regras de ingresso de um grupo de segurança não pode ser encontrado. |
| `InvalidNetworkInterfaceID.NotFound` | `ResourceNotFound` | Esse erro ocorre quando o ID da interface de rede para as regras de ingresso de um grupo de segurança não pode ser encontrado. |
| `InsufficientFreeAddressesInSubnet` | `ResourceLimitExceeded` | Esse erro ocorre quando a cota de recursos da sub-rede é excedida. |
| `InsufficientCapacityOnOutpost` | `ResourceLimitExceeded` | Esse erro ocorre quando a cota de capacidade do outpost é excedida. |
| `NetworkInterfaceLimitExceeded` | `ResourceLimitExceeded` | Esse erro ocorre quando a cota de interface de rede elástica é excedida. |
| `SecurityGroupLimitExceeded` | `ResourceLimitExceeded` | Esse erro ocorre quando a cota de capacidade do grupo de segurança é excedida. |
| `VcpuLimitExceeded` | `ResourceLimitExceeded` | Isso é observado na criação de uma instância do Amazon EC2 em uma nova conta. O procedimento pode ser semelhante ao seguinte: "`You have requested more vCPU capacity than your current vCPU limit of 32 allows for the instance bucket that the specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit."` |
| `InvalidParameterValue` | `ConfigurationConflict` | O Amazon EC2 retornará esse código de erro se não houver suporte no Outpost para o tipo de instância especificado. |
| Todas as outras falhas | `InternalFailure` | Nenhum |
## Impossível criar ou modificar clusters
Os clusters locais exigem permissões e políticas diferentes das exigidas pelos clusters do Amazon EKS hospedados na nuvem. Quando a criação do cluster falhar e gera um erro `InvalidPermissions`, verifique novamente se o perfil do cluster que você está usando tem a política gerenciada [AmazonEKSLocalOutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) anexada a ele. Todas as outras chamadas de API exigem o mesmo conjunto de permissões que os clusters do Amazon EKS na nuvem.
## O cluster está travado no estado `CREATING`
O tempo necessário para criar um cluster local varia dependendo de vários fatores. Esses fatores incluem a configuração da rede, a configuração do Outpost e a configuração do cluster. Em geral, um cluster local é criado e passa para o status `ACTIVE` dentro de 15 a 20 minutos. Se um cluster local permanecer no estado `CREATING`, você poderá chamar `describe-cluster` para obter informações sobre a causa no campo de saída `cluster.health`.
Os problemas mais comuns são os seguintes:
+ Seu cluster não pode se conectar à instância do ambiente de gerenciamento da região AWS em que o Systems Manager está. Você pode verificar isso chamando `aws ssm start-session --target instance-id ` em um bastion host na região. Se esse comando não funcionar, verifique se o Systems Manager está sendo executado na instância do ambiente de gerenciamento. Outra solução de contorno é excluir o cluster e depois recriá-lo.
+ As instâncias do ambiente de gerenciamento falham na criação devido às permissões da chave do KMS para volumes do EBS. Com chaves do KMS gerenciadas pelo usuário para volumes criptografados do EBS, as instâncias do ambiente de gerenciamento serão encerradas se a chave não estiver acessível. Se as instâncias forem encerradas, alterne para uma chave do KMS gerenciada pela AWS ou garanta que sua política de chaves gerenciadas pelo usuário conceda as permissões necessárias para o perfil do cluster.
+ As instâncias do ambiente de gerenciamento do Systems Manager podem não ter acesso à Internet. Verifique se a sub-rede que você forneceu ao criar o cluster tem um gateway NAT e uma VPC com um gateway da internet. Use o analisador de acessibilidade da VPC para verificar se a instância do ambiente de gerenciamento pode acessar o gateway da Internet. Para obter mais informações, consulte [Getting started with VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/getting-started.html) (Conceitos básicos do VPC Reachability Analyzer).
+ O ARN de perfil fornecido não tem políticas. Verifique se a [política gerenciada da AWS: AmazonEKSLocalOutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) foi removida do perfil. Isso também pode ocorrer se uma pilha do AWS CloudFormation estiver mal configurada.
+ Todas as sub-redes fornecidas devem estar associadas ao mesmo Outpost e devem alcançar umas às outras. Quando várias sub-redes são especificadas durante a criação do cluster, o Amazon EKS tenta distribuir as instâncias do ambiente de gerenciamento entre várias sub-redes.
+ Os grupos de segurança gerenciados pelo Amazon EKS são aplicados à interface de rede elástica. No entanto, outros elementos da configuração, como regras de firewall NACL, podem entrar em conflito com as regras da interface de rede elástica.
**A VPC e o DNS da sub-rede estão mal configurados ou falta a configuração**
Revisão [Crie um VPC e sub-redes para clusters do Amazon EKS em AWS Outposts](eks-outposts-vpc-subnet-requirements.md).
## O cluster está travado no estado `UPDATING`
O Amazon EKS atualiza automaticamente todos os clusters locais existentes para a versão mais recente da plataforma para a versão secundária correspondente do Kubernetes. Para obter mais informações sobre versões da plataforma, consulte [Saiba mais sobre as versões das plataformas do Kubernetes e do Amazon EKS para AWS Outposts](eks-outposts-platform-versions.md).
Durante a implantação automática da versão da plataforma, o status do cluster muda para `UPDATING`. O processo de atualização consiste na substituição de todas as instâncias do ambiente de gerenciamento do Kubernetes por novas contendo os patches de segurança e correções de bugs mais recentes lançados para a respectiva versão secundária do Kubernetes. Em geral, um processo de atualização da plataforma do cluster local é concluído em menos de trinta minutos, e o cluster volta ao status `ACTIVE`. Se um cluster local permanecer no estado `UPDATING` por um período prolongado, você poderá chamar `describe-cluster` para verificar as informações sobre a causa no campo de saída `cluster.health`.
O Amazon EKS garante que pelo menos duas em cada três instâncias do ambiente de gerenciamento do Kubernetes sejam nós de cluster íntegros e operacionais para manter a disponibilidade do cluster local e evitar a interrupção do serviço. Se um cluster local estiver paralisado no estado `UPDATING`, geralmente é porque há algum problema de infraestrutura ou configuração que impede que a disponibilidade mínima de duas instâncias seja garantida caso o processo continue. Portanto, o processo de atualização para de avançar para proteger o cluster local contra a interrupção do serviço.
É importante solucionar o problema de um cluster local preso no status `UPDATING` e tratar a causa raiz para que o processo de atualização possa ser concluído, e restaurar o cluster local de volta ao status `ACTIVE` com a alta disponibilidade de três instâncias do ambiente de gerenciamento do Kubernetes.
Não encerre nenhuma instância do `Kubernetes` gerenciada do cluster local do EKS no Outposts, a menos que seja explicitamente instruído pelo AWS Support. Isso é especialmente importante para clusters locais presos no estado `UPDATING`, pois há uma grande probabilidade de que outros nós do ambiente de gerenciamento não estejam completamente íntegros, e o encerramento da instância errada pode causar interrupção do serviço e risco de perda de dados do cluster local.
Os problemas mais comuns são os seguintes:
+ Uma ou mais instâncias do ambiente de gerenciamento não conseguem se conectar ao Systems Manager devido a uma alteração na configuração de rede desde que o cluster local foi criado pela primeira vez. Você pode verificar isso chamando `aws ssm start-session --target instance-id ` em um bastion host na região. Se esse comando não funcionar, verifique se o Systems Manager está sendo executado na instância do ambiente de gerenciamento.
+ As novas instâncias do ambiente de gerenciamento falham ao serem criadas devido às permissões da chave do KMS para volumes do EBS. Com chaves do KMS gerenciadas pelo usuário para volumes criptografados do EBS, as instâncias do ambiente de gerenciamento serão encerradas se a chave não estiver acessível. Se as instâncias forem encerradas, alterne para uma chave do KMS gerenciada pela AWS ou garanta que sua política de chaves gerenciadas pelo usuário conceda as permissões necessárias para o perfil do cluster.
+ As instâncias do ambiente de gerenciamento do Systems Manager podem não ter perdido o acesso à internet. Verifique se a sub-rede que você forneceu ao criar o cluster tem um gateway NAT e uma VPC com um gateway da internet. Use o analisador de acessibilidade da VPC para verificar se a instância do ambiente de gerenciamento pode acessar o gateway da Internet. Para obter mais informações, consulte [Getting started with VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/getting-started.html) (Conceitos básicos do VPC Reachability Analyzer). Se as redes privadas não tiverem conexão de saída com a internet, certifique-se de que todos os endpoints da VPC e endpoints de gateway necessários ainda estejam presentes na sub-rede regional do cluster (consulte [Acesso à sub-rede a serviços da AWS](eks-outposts-vpc-subnet-requirements.md#subnet-access-to-services)).
+ O ARN de perfil fornecido não tem políticas. Verifique se a [política gerenciada da AWS: AmazonEKSLocalOutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) foi removida do perfil.
+ Uma das novas instâncias do ambiente de gerenciamento do Kubernetes pode ter sofrido uma falha inesperada de inicialização. Crie um tíquete no [AWS Support Center](https://console.aws.amazon.com/support/home) para obter mais orientações sobre solução de problemas e a coleta de logs neste caso excepcional.
## Não é possível integrar nós a um cluster
+ Problemas de AMI:
+ Você está usando uma AMI incompatível. Somente AMIs do Amazon Linux 2 otimizadas para o Amazon EKS são compatíveis (`amazon-linux-2`, `amazon-linux-2-gpu` e `amazon-linux-2-arm64`). Se tentar integrar nós do AL2023 a LocalClusters do EKS no AWS Outposts, os nós falharão ao ingressar no cluster. Para mais informações, consulte [Criar nós Amazon Linux no AWS Outposts](eks-outposts-self-managed-nodes.md).
+ Se você usou um modelo do AWS CloudFormation para criar seus nós, verifique se ele não estava usando uma AMI sem suporte.
+ O `ConfigMap` do autenticador do AWS IAM está ausente: nesse caso, é necessário criá-lo. Para ter mais informações, consulte [Como aplicar o `ConfigMap` `aws-auth` ao seu cluster](auth-configmap.md#aws-auth-configmap) .
+ O grupo de segurança errado é usado: certifique-se de usar `eks-cluster-sg-cluster-name-uniqueid ` para o grupo de segurança dos nós de processamento. O grupo de segurança selecionado é alterado pelo AWS CloudFormation para permitir um novo grupo de segurança sempre que a pilha for usada.
+ Seguir etapas inesperadas de uma VPC de link privado: são especificados dados de CA (`--b64-cluster-ca`) ou endpoint de API (`--apiserver-endpoint`) incorretos.
## Coletar logs
Quando um Outpost é desconectado da região da AWS à qual está associado, o cluster do Kubernetes provavelmente continuará funcionando normalmente. No entanto, se o cluster não funcionar corretamente, siga as etapas de solução de problemas em [Preparar clusters locais do Amazon EKS no AWS Outposts para desconexões de rede](eks-outposts-network-disconnects.md). Se encontrar outros problemas, entre em contato com o suporte AWS. AWS O suporte pode orientar você sobre como baixar e executar uma ferramenta de coleta de logs. Dessa forma, você pode coletar logs das instâncias do ambiente de gerenciamento do cluster do Kubernetes e enviá-los para o AWS Support para uma investigação adicional.
## As instâncias do ambiente de gerenciamento não podem ser acessadas por meio do AWS Systems Manager
Quando as instâncias do ambiente de gerenciamento do Amazon EKS não podem ser acessadas pelo AWS Systems Manager (Systems Manager), o Amazon EKS exibe o seguinte erro para o seu cluster.
```
Amazon EKS control plane instances are not reachable through SSM. Please verify your SSM and network configuration, and reference the EKS on Outposts troubleshooting documentation.
```
Para resolver esse problema, verifique se a VPC e as sub-redes atendem aos requisitos em [Criar uma VPC e sub-redes para clusters do Amazon EKS em AWS Outposts](eks-outposts-vpc-subnet-requirements.md) e se você concluiu as etapas em [Configurar o Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html) no Guia do usuário do AWS Systems Manager.
# 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 <