**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.
# Ciclo de vida e configuração do cluster do Amazon EKS
Esta seção fornece orientações detalhadas sobre o gerenciamento completo do ciclo de vida dos clusters Kubernetes e as diferentes maneiras de configurá-los. Ele abrange a criação de clusters, o monitoramento da integridade do cluster, a atualização de versões do Kubernetes e a exclusão de clusters. Além disso, inclui tópicos avançados sobre como configurar o acesso ao endpoint, habilitar ou desabilitar o suporte ao Windows, configurar clusters privados, implementar o ajuste de escala automático e como aumentar a resiliência com a mudança de zona para o redirecionamento de tráfego em configurações multi-AZ.
**Topics**
+ [Criar um cluster do Modo Automático do Amazon EKS](create-cluster-auto.md)
+ [Criar um cluster do Amazon EKS](create-cluster.md)
+ [Ambiente de gerenciamento provisionado do Amazon EKS](eks-provisioned-control-plane.md)
+ [Prepare-se para as atualizações da versão e a solução de problemas de configurações incorretas do Kubernetes com insights do cluster](cluster-insights.md)
+ [Atualizar um cluster existente para a nova versão do Kubernetes](update-cluster.md)
+ [Excluir um cluster](delete-cluster.md)
+ [Endpoint do servidor de API do cluster](cluster-endpoint.md)
+ [Implantar nós Windows em clusters EKS](windows-support.md)
+ [Desativar o suporte ao Windows](disable-windows-support.md)
+ [Implementar clusters privados com acesso limitado à internet](private-clusters.md)
+ [Escale a computação em cluster com o Karpenter e o Cluster Autoscaler](autoscaling.md)
+ [Saiba mais sobre a mudança de zona do Controlador de Recuperação de Aplicações da Amazon (ARC, na sigla em inglês) no Amazon EKS](zone-shift.md)
+ [Habilitação da mudança de zona do EKS para evitar zonas de disponibilidade comprometidas](zone-shift-enable.md)
# Criar um cluster do Modo Automático do Amazon EKS
Este tópico fornece instruções detalhadas para criar um cluster do Modo Automático do Amazon EKS usando opções avançadas de configuração. Ele aborda pré-requisitos, opções de rede e configurações de complementos. O processo inclui configurar perfis do IAM, definir configurações de cluster, especificar parâmetros de rede e selecionar complementos. Os usuários podem criar clusters usando o Console de gerenciamento da AWS ou a AWS CLI, com orientação passo a passo fornecida para ambos os métodos.
Para usuários que buscam um processo de configuração menos complexo, consulte o seguinte para ver etapas simplificadas da criação de um cluster:
+ [Criar um cluster do Modo Automático do EKS com a CLI do eksctl](automode-get-started-eksctl.md)
+ [Criar um cluster do Modo Automático do EKS com a AWS CLI](automode-get-started-cli.md)
+ [Criar um cluster do Modo Automático do EKS com o Console de gerenciamento da AWS](automode-get-started-console.md)
Este guia de configuração avançada é destinado a usuários que precisam de um controle mais granular sobre a configuração do cluster do Modo Automático do EKS e estão familiarizados com os conceitos e requisitos do Amazon EKS. Antes de prosseguir com a configuração avançada, certifique-se de ter atendido a todos os pré-requisitos e ter uma compreensão completa dos requisitos de rede e do IAM para clusters do Modo Automático do EKS.
O Modo Automático do EKS requer permissões adicionais do IAM. Para obter mais informações, consulte:
+ [Perfis do IAM de clusters do Modo Automático do EKS](automode-get-started-cli.md#auto-mode-create-roles)
+ [Saber mais sobre identidade e acesso no Modo Automático do EKS](auto-learn-iam.md)
**nota**
Se você quiser criar um cluster sem o Modo Automático do EKS, consulte [Criar um cluster do Amazon EKS](create-cluster.md).
Este tópico aborda a configuração avançada. Se você deseja começar a usar o Modo Automático do EKS, consulte [Criação de um cluster com o modo automático do Amazon EKS](create-auto.md).
## Pré-requisitos
+ Uma VPC e sub-redes existentes que atendem aos [requisitos do Amazon EKS](network-reqs.md). Antes de implantar um cluster para uso em ambientes de produção, convém ter uma compreensão integral dos requisitos da VPC e da sub-rede. Se você não tiver um VPC e sub-redes, poderá criá-los usando um [modelo do Amazon EKS fornecido pelo AWS CloudFormation](creating-a-vpc.md).
+ A ferramenta da linha de comando `kubectl` está instalada no seu dispositivo 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`, você poderá 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`. 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*.
+ Uma [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) com permissões para criar e modificar recursos do EKS e do IAM.
## Criar cluster - AWS console
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Escolha **Add cluster** (Adicionar cluster) e, em seguida, **Create** (Criar).
1. Em *Opções de configuração*, selecione **Configuração personalizada**.
+ Este tópico aborda a configuração personalizada. Para obter informações sobre a configuração rápida, consulte [Criar um cluster do Modo Automático do EKS com o Console de gerenciamento da AWS](automode-get-started-console.md).
1. Confirme se **Usar Modo Automático do EKS** está habilitado.
+ Este tópico aborda a criação de clusters com o Modo Automático do EKS. Para obter mais informações sobre como criar clusters sem o Modo Automático do EKS, consulte [Criar um cluster do Amazon EKS](create-cluster.md).
1. Na página **Configure cluster** (Configurar cluster), preencha os seguintes campos:
+ **Name** (Nome): um nome exclusivo para o cluster. O nome pode conter apenas caracteres alfanuméricos (diferencia maiúsculas de minúsculas), hifens e sublinhados. 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.
+ **Perfil do IAM do cluster**: escolha o perfil do IAM do cluster do Amazon EKS que você criou para permitir que o ambiente de gerenciamento do Kubernetes gerencie os recursos da AWS em seu nome. Se você ainda não criou um perfil do IAM do cluster para o Modo Automático do EKS, selecione o botão **Criar perfil recomendado** para criar o perfil com as permissões necessárias no console do IAM.
+ **Kubernetes version (Versão do Kubernetes)** – a versão do Kubernetes a ser usada para o cluster. Recomendamos que você selecione a versão mais recente, a menos que precise de uma versão anterior.
+ **Política de atualização**: a política de versão do Kubernetes que você deseja definir para o cluster. Se quiser que o cluster seja executado somente em uma versão com suporte padrão, você pode escolher **Padrão**. Se quiser que o cluster entre no suporte estendido ao final do suporte padrão para uma versão, você pode escolher **Estendido**. Caso selecione uma versão do Kubernetes que esteja atualmente com suporte estendido, você não poderá selecionar o suporte padrão como opção.
1. Na seção **Computação do Modo Automático** da página de configuração do cluster, preencha os seguintes campos:
+ **Grupos de nós**: determine se você deseja usar o build nos grupos de nós. Para obter mais informações, consulte [Habilitar ou desabilitar NodePools integrados](set-builtin-node-pools.md).
+ **Perfil do IAM do nó**: se habilitar qualquer um dos grupos de nós integrados, você precisará selecionar um perfil do IAM do nó. O Modo Automático do EKS atribuirá esse perfil a novos nós. Você não poderá alterar o valor depois que o cluster for criado. Se você ainda não criou um perfil do IAM do nó para o Modo Automático do EKS, selecione o botão Criar perfil recomendado para criar o perfil com as permissões necessárias. Para obter mais informações sobre essa função, consulte [Saber mais sobre identidade e acesso no Modo Automático do EKS](auto-learn-iam.md).
1. Na seção **Acesso ao cluster** da página de configuração do cluster, preencha os seguintes campos:
+ **Inicialização do acesso de administrador do cluster**: o criador do cluster é automaticamente um administrador do Kubernetes. Caso deseje desabilitar essa opção, selecione **Desabilitar acesso de administrador ao cluster**.
+ **Modo de autenticação do cluster**: o Modo Automático do EKS requer entradas de acesso ao EKS, o modo de autenticação da API do EKS. Opcionalmente, você pode habilitar o modo de autenticação `ConfigMap` selecionando **ConfigMap e API do EKS**.
1. Na página de configuração do cluster, preencha os seguintes campos:
+ **Secrets encryption** (Criptografia de segredos): (Opcional) Escolha habilitar a criptografia de segredos do Kubernetes usando uma chave do KMS. Também é possível isso depois de criar o cluster. Antes de habilitar esse recurso, familiarize-se com as informações em [Criptografar segredos do Kubernetes com o KMS em clusters existentes](enable-kms.md).
+ **Mudança de zona do ARC**: o Modo Automático do EKS não é compatível com a mudança de zona do ARC.
+ **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 que atenda aos [Requisitos de VPC do Amazon EKS](network-reqs.md#network-requirements-vpc) na qual criar o cluster. Antes de escolher uma VPC, recomendamos familiarizar-se com todos os requisitos e considerações em [Exibir os requisitos de rede do Amazon EKS para VPC e sub-redes](network-reqs.md). Não será possível alterar quais VPCs você deseja utilizar depois de criar o cluster. Se nenhuma VPC estiver listada, você precisará criar uma primeiro. Para obter mais informações, consulte [Criar uma Amazon VPC para o cluster do Amazon EKS](creating-a-vpc.md).
+ **Subnets** (Sub-redes): por padrão, as sub-redes disponíveis na VPC especificada no campo anterior são pré-selecionadas. É necessário selecionar pelo menos duas.
As sub-redes escolhidas devem atender aos [Requisitos para sub-redes do Amazon EKS](network-reqs.md#network-requirements-subnets). Antes de selecionar sub-redes, convém estar familiarizado com todos os [Requisitos e considerações sobre VPCs e sub-redes do Amazon EKS](network-reqs.md).
**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.
Independentemente de você escolher algum grupo de segurança, o Amazon EKS cria um grupo de segurança que permite comunicação entre seu cluster e sua 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.
+ **Escolher família de endereços IP do cluster**: é possível escolher **IPv4** e **IPv6**.
Por padrão, o Kubernetes atribui endereços `IPv4` aos pods e serviços. Antes de decidir usar a família `IPv6`, verifique se você está familiarizado com todas as considerações e requisitos dos tópicos [Requisitos e considerações da VPC](network-reqs.md#network-requirements-vpc), [Requisitos e considerações para sub-redes](network-reqs.md#network-requirements-subnets), [Exibir os requisitos para grupos de segurança do Amazon EKS em clusters](sec-group-reqs.md) e [Saiba mais sobre endereços IPv6 para clusters, pods e serviços](cni-ipv6.md). Caso escolha a família `IPv6`, você não poderá especificar um intervalo de endereços para o Kubernetes atribuir endereços de serviço `IPv6` da mesma forma que faz para a família `IPv4`. O Kubernetes atribui endereços de serviço do intervalo exclusivo de endereços locais (`fc00::/7`).
+ (Opcional) Escolha **Configurar intervalo de endereços IP do Kubernetes** e especifique um **Intervalo `IPv4` de serviços**.
Especificar seu próprio intervalo pode ajudar a evitar conflitos entre serviços do Kubernetes e outras redes com emparelhamento ou conectadas à VPC. Insira um intervalo em notação CIDR. Por exemplo: `10.2.0.0/16`.
O bloco CIDR deve atender aos seguintes requisitos:
+ Estar dentro de um dos seguintes intervalos: `10.0.0.0/8`, `172.16.0.0/12` ou `192.168.0.0/16`.
+ Ter um tamanho mínimo de `/24` e máximo de `/12`.
+ Não se sobrepor ao intervalo da VPC para seus recursos do Amazon EKS.
Apenas é possível especificar essa opção ao utilizar a família de endereços `IPv4` e somente ao criar o cluster. Se isso não for especificado, o Kubernetes atribuirá endereços IP de serviço de qualquer um dos blocos CIDR `10.100.0.0/16` ou `172.20.0.0/16`.
+ Para **Cluster endpoint access** (Acesso ao endpoint do cluster), selecione uma opção. Depois de criar o cluster, você poderá alterar essa opção. Antes de selecionar uma opção não padrão, familiarize-se com as opções e suas implicações. Para obter mais informações, consulte [Endpoint do servidor de API do cluster](cluster-endpoint.md).
Após terminar com essa página, escolha **Próximo**.
1. (Opcional) Na página **Configurar observabilidade**, escolha quais opções de **Métricas** e **Log do ambiente de gerenciamento** deseja ativar. Por padrão, o cada tipo de log está desativado.
+ Para obter mais informações sobre as opções 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 **Selecionar complementos**, escolha os complementos que você deseja adicionar ao cluster. Você pode escolher quantos **complementos do Amazon EKS** e ** do AWS Marketplace** desejar. Se os **complementos do AWS Marketplace** que você deseja instalar não estiverem listados, será possível clicar na numeração da página para visualizar resultados de páginas adicionais ou pesquisar os **complementos disponíveis no AWS Marketplace** inserindo algum texto na caixa de pesquisa. Você também poderá pesquisar por **categoria**, **fornecedor** ou **modelo de preços** e depois escolher os complementos nos resultados da pesquisa. Ao criar um cluster, é possível visualizar, selecionar e instalar qualquer complemento que ofereça suporte às Identidade de Pods do EKS, conforme detalhado em [Saiba como a Identidade de Pods do EKS concede aos pods acesso aos serviços da AWS](pod-identities.md).
+ O Modo Automático do EKS automatiza a funcionalidade de determinados complementos. Se você planeja implantar grupos de nós gerenciados pelo EKS no cluster do Modo Automático do EKS, selecione **Complementos adicionais do Amazon EKS** e analise as opções. Talvez seja necessário instalar complementos como o CoreDNS e kube-proxy. O EKS só vai instalar os complementos desta seção em nós e grupos de nós autogerenciados.
+ Após terminar com essa página, escolha **Próximo**.
1. Na página **Configurar opções de complementos selecionados**, selecione a versão que deseja instalar. Você sempre pode atualizar para uma versão posterior após a criação do cluster.
Para complementos com suporte para Identidade de Pods do EKS, é possível usar o console para gerar automaticamente o perfil com o nome, a política gerenciada pela AWS e a política de confiança pré-preenchidos especificamente para o complemento. É possível reutilizar perfis existentes ou criar novos perfis para complementos com suporte. Para obter as etapas de uso do console para criar perfis para complementos que ofereçam suporte às Identidades de Pods do EKS, consulte [Criar complemento (console do AWS)](creating-an-add-on.md#create_add_on_console). Se um complemento não oferecer suporte à Identidade de Pods do EKS, uma mensagem será exibida com instruções para usar o assistente para criar os perfis do IAM para contas de serviço (IRSA) após a criação do cluster.
Você pode atualizar a configuração de cada complemento após a criação do cluster. Para obter mais informações sobre a configuração de complementos, consulte [Atualizar um complemento do Amazon EKS](updating-an-add-on.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.
**nota**
Talvez você receba um erro porque uma das zonas de disponibilidade em sua solicitação não tem capacidade suficiente para criar um cluster do Amazon EKS. Se isso acontecer, o resultado do erro conterá as zonas de disponibilidade que são compatíveis com o novo cluster. Tente criar o cluster com pelo menos duas sub-redes que estejam localizadas nas zonas de disponibilidade compatíveis de sua conta. Para obter mais informações, consulte [Capacidade insuficiente](troubleshooting.md#ice).
O provisionamento de cluster leva alguns minutos.
## Crar cluster: AWS CLI
As instruções da CLI a seguir abrangem a criação de recursos do IAM e a criação do cluster.
### Criar um perfil do IAM do cluster do Modo Automático do EKS
#### Etapa 1: criar a política de confiança
Crie uma política de confiança para permitir que o serviço do Amazon EKS assuma o perfil. Salve a política como `trust-policy.json`:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
#### Etapa 2: criar o perfil do IAM
Use a política de confiança para criar o perfil do IAM do cluster:
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://trust-policy.json
```
#### Etapa 3: registre o ARN do perfil
Recupere e salve o ARN do novo perfil para uso nas etapas subsequentes:
```
aws iam get-role --role-name AmazonEKSAutoClusterRole --query "Role.Arn" --output text
```
#### Etapa 4: anexar as políticas necessárias
Anexe as seguintes políticas gerenciadas pela AWS ao perfil do IAM do cluster para conceder as permissões necessárias:
**AmazonEKSClusterPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
```
**AmazonEKSComputePolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSComputePolicy
```
**AmazonEKSBlockStoragePolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**AmazonEKSLoadBalancingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**AmazonEKSNetworkingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSNetworkingPolicy
```
### Criar um perfil do IAM do nó do Modo Automático do EKS
#### Etapa 1: criar a política de confiança
Crie uma política de confiança para permitir que o serviço do Amazon EKS assuma o perfil. Salve a política como `node-trust-policy.json`:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
#### Etapa 2: criar o perfil do IAM do nó
Use o arquivo **node-trust-policy.json** da etapa anterior para definir quais entidades podem assumir o perfil. Execute o seguinte comando para criar o perfil do IAM do nó:
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
#### Etapa 3: registre o ARN do perfil
Depois de criar o perfil, recupere e salve o ARN do perfil do IAM do nó. Você precisará desse ARN nas etapas subsequentes. Use o seguinte comando para obter o ARN:
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
#### Etapa 4: anexar as políticas necessárias
Anexe as seguintes políticas gerenciadas pela AWS ao perfil do IAM do nó para fornecer as permissões necessárias:
**AmazonEKSWorkerNodeMinimalPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
**AmazonEC2ContainerRegistryPullOnly**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
### Criação de cluster
1. Crie o cluster usando o comando a seguir. Antes da execução do comando, realize as seguintes substituições:
+ Substitua *region-code* pela região AWS na qual você deseja criar o cluster.
+ Substitua *my-cluster* por um nome para seu cluster. O nome pode conter apenas caracteres alfanuméricos (diferencia maiúsculas de minúsculas), hifens e sublinhados. Ele deve começar com um caractere alfanumérico e não pode ter mais de 100 caracteres. O nome deve ser exclusivo na região da AWS e na conta da AWS em que você está criando o cluster.
+ Substitua *1.30* por qualquer [versão compatível do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Substitua *111122223333* pelo ID da sua conta.
+ Se você criou perfis do IAM com nomes diferentes para os perfis de cluster e de nó, substitua os ARNs.
+ Substitua os valores de `subnetIds` pelos seus próprios valores. Também é possível adicionar outras IDs. Você deve especificar pelo menos dois IDs de sub-rede.
As sub-redes escolhidas devem atender aos [Requisitos para sub-redes do Amazon EKS](network-reqs.md#network-requirements-subnets). Antes de selecionar sub-redes, convém estar familiarizado com todos os [Requisitos e considerações sobre VPCs e sub-redes do Amazon EKS](network-reqs.md).
+ Se não quiser especificar um ID de grupo de segurança, remova `,securityGroupIds=sg-` do comando. Se quiser especificar um ou mais IDs de grupo de segurança, substitua os valores de `securityGroupIds` pelos seus próprios. Também é possível adicionar outras IDs.
Independentemente de você escolher algum grupo de segurança, o Amazon EKS cria um grupo de segurança que permite comunicação entre seu cluster e sua 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.
```
aws eks create-cluster \
--region region-code \
--name my-cluster \
--kubernetes-version 1.30 \
--role-arn arn:aws:iam::111122223333:role/AmazonEKSAutoClusterRole \
--resources-vpc-config '{"subnetIds": ["subnet-ExampleID1","subnet-ExampleID2"], "securityGroupIds": ["sg-ExampleID1"], "endpointPublicAccess": true, "endpointPrivateAccess": true}' \
--compute-config '{"enabled": true, "nodeRoleArn": "arn:aws:iam::111122223333:role/AmazonEKSAutoNodeRole", "nodePools": ["general-purpose", "system"]}' \
--kubernetes-network-config '{"elasticLoadBalancing": {"enabled": true}}' \
--storage-config '{"blockStorage": {"enabled": true}}' \
--access-config '{"authenticationMode": "API"}'
```
**nota**
Talvez você receba um erro porque uma das zonas de disponibilidade em sua solicitação não tem capacidade suficiente para criar um cluster do Amazon EKS. Se isso acontecer, o resultado do erro conterá as zonas de disponibilidade que são compatíveis com o novo cluster. Tente criar o cluster com pelo menos duas sub-redes que estejam localizadas nas zonas de disponibilidade compatíveis de sua conta. Para obter mais informações, consulte [Capacidade insuficiente](troubleshooting.md#ice).
Veja a seguir as configurações opcionais que, se necessário, devem ser adicionadas ao comando anterior. Apenas é possível habilitar essas opções ao criar o cluster, e não depois.
+ Se quiser especificar de qual bloco de Encaminhamento Entre Domínios Sem Classificação (CIDR) `IPv4` o Kubernetes atribui endereços IP de serviço, será necessário especificá-lo adicionando `--kubernetes-network-config serviceIpv4Cidr=` ao comando a seguir.
Especificar seu próprio intervalo pode ajudar a evitar conflitos entre serviços do Kubernetes e outras redes com emparelhamento ou conectadas à VPC. Insira um intervalo em notação CIDR. Por exemplo: `10.2.0.0/16`.
O bloco CIDR deve atender aos seguintes requisitos:
+ Estar dentro de um dos seguintes intervalos: `10.0.0.0/8`, `172.16.0.0/12` ou `192.168.0.0/16`.
+ Ter um tamanho mínimo de `/24` e máximo de `/12`.
+ Não se sobrepor ao intervalo da VPC para seus recursos do Amazon EKS.
Apenas é possível especificar essa opção ao utilizar a família de endereços `IPv4` e somente ao criar o cluster. Se isso não for especificado, o Kubernetes atribuirá endereços IP de serviço de qualquer um dos blocos CIDR `10.100.0.0/16` ou `172.20.0.0/16`.
+ Se estiver criando um cluster e quiser que o cluster atribua endereços `IPv6` a pods e serviços em vez de endereços `IPv4`, adicione `--kubernetes-network-config ipFamily=ipv6` ao comando a seguir.
Por padrão, o Kubernetes atribui endereços `IPv4` aos pods e serviços. Antes de decidir usar a família `IPv6`, verifique se você está familiarizado com todas as considerações e requisitos dos tópicos [Requisitos e considerações da VPC](network-reqs.md#network-requirements-vpc), [Requisitos e considerações para sub-redes](network-reqs.md#network-requirements-subnets), [Exibir os requisitos para grupos de segurança do Amazon EKS em clusters](sec-group-reqs.md) e [Saiba mais sobre endereços IPv6 para clusters, pods e serviços](cni-ipv6.md). Caso escolha a família `IPv6`, você não poderá especificar um intervalo de endereços para o Kubernetes atribuir endereços de serviço `IPv6` da mesma forma que faz para a família `IPv4`. O Kubernetes atribui endereços de serviço do intervalo exclusivo de endereços locais (`fc00::/7`).
1. Leva alguns minutos para provisionar o cluster. Você pode consultar o status do cluster com o comando a seguir.
```
aws eks describe-cluster --region region-code --name my-cluster --query "cluster.status"
```
## Próximas etapas
+ [Conecte o kubectl a um cluster de EKS criando um arquivo kubeconfig](create-kubeconfig.md)
+ [Conceder aos usuários do IAM acesso ao Kubernetes com entradas de acesso ao EKS](access-entries.md)
+ [Habilitar a criptografia de segredos para o seu cluster](enable-kms.md).
+ [Configurar o registro em log para o seu cluster](control-plane-logs.md).
+ [Adicionar nós ao seu cluster](eks-compute.md).
# Criar um cluster do Amazon EKS
**nota**
Este tópico aborda a criação de clusters do Amazon EKS sem o modo automático do EKS.
Para obter instruções detalhadas sobre como criar um cluster do Modo Automático do EKS, consulte [Criar um cluster do Modo Automático do Amazon EKS](create-cluster-auto.md).
Para começar a usar o Modo Automático do EKS, consulte [Conceitos básicos do Amazon EKS \$1 Modo Automático do EKS](getting-started-automode.md).
Este tópico dá uma visão geral das opções disponíveis e descreve o que deve ser considerado ao criar um cluster do Amazon EKS. Se você precisar criar um cluster com a infraestrutura on-premises como a computação para nós, consulte [Criar um cluster do Amazon EKS com nós híbridos](hybrid-nodes-cluster-create.md). Se esta for a primeira vez que você cria um cluster do Amazon EKS, recomendamos que siga um de nossos guias em [Começar a usar o Amazon EKS](getting-started.md). Esses guias ajudam a criar um cluster simples e padrão sem expandir para todas as opções que estão disponíveis.
## Pré-requisitos
+ Uma VPC e sub-redes existentes que atendem aos [requisitos do Amazon EKS](network-reqs.md). Antes de implantar um cluster para uso em ambientes de produção, convém ter uma compreensão integral dos requisitos da VPC e da sub-rede. Se você não tiver um VPC e sub-redes, poderá criá-los usando um [modelo do Amazon EKS fornecido pelo AWS CloudFormation](creating-a-vpc.md).
+ A ferramenta da linha de comando `kubectl` está instalada no seu dispositivo 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. 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) 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).
## Etapa 1: Criar perfil IAM de cluster
1. Se já tiver um perfil do IAM de cluster ou se for criar seu cluster com `eksctl`, você 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": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Crie o perfil do IAM do cluster do Amazon EKS. Se necessário, prefixe *eks-cluster-role-trust-policy.json* com o caminho no computador no qual você gravou o arquivo na etapa anterior. O comando associa a política de confiança criada na etapa anterior à função. 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 myAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Você pode atribuir a política gerenciada do Amazon EKS ou criar sua própria política personalizada. Para obter as permissões mínimas que você deve usar em sua política personalizada, consulte [Função do IAM do cluster do Amazon EKS](cluster-iam-role.md).
Anexe a política gerenciada do Amazon EKS chamada [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) à 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/AmazonEKSClusterPolicy --role-name myAmazonEKSClusterRole
```
### Perfil vinculado ao serviço
O Amazon EKS cria automaticamente um perfil vinculado ao serviço chamado `AWSServiceRoleForAmazonEKS`.
Isso é adicional ao perfil do IAM do cluster. A função vinculada ao serviço é um tipo exclusivo de função do IAM vinculada diretamente ao Amazon EKS. O perfil permite que o Amazon EKS gerencie clusters em sua conta. Para obter mais informações, consulte [Usar funções para clusters do Amazon EKS](using-service-linked-roles-eks.md).
A identidade do IAM que você usa para criar o cluster do EKS deve ter permissão para criar o perfil vinculado ao serviço. Isso inclui a permissão `iam:CreateServiceLinkedRole`.
Caso o perfil vinculado ao serviço não exista e seu perfil do IAM atual não tenha permissões suficientes para criá-lo, a operação de criação do cluster apresentará falhas.
## Etapa 2: Criar cluster
Você pode criar um cluster usando:
+ [`eksctl`](#step2-eksctl)
+ [o Console de gerenciamento da AWS](#step2-console)
+ [a AWS CLI](#step2-cli)
### Criar cluster - eksctl
1. Você precisa da 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. Crie um cluster `IPv4` do Amazon EKS com a versão padrão do Kubernetes para Amazon EKS em sua região padrão da AWS. Antes da execução do comando, realize as seguintes substituições:
1. Substitua *region-code* pela região AWS na qual você deseja criar o cluster.
1. 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.
1. Substitua *1.35* por qualquer [versão compatível do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
1. Altere os valores para `vpc-private-subnets` para atender às suas necessidades. Também é possível adicionar outras IDs. Você deve especificar pelo menos dois IDs de sub-rede. Se preferir especificar sub-redes públicas, poderá alterar `--vpc-private-subnets` para `--vpc-public-subnets`. Sub-redes públicas têm uma tabela de rotas associada a uma rota para um gateway da Internet, mas sub-redes privadas não têm tabelas de rotas associadas. Convém utilizar sub-redes privadas sempre que possível.
As sub-redes escolhidas devem atender aos [Requisitos para sub-redes do Amazon EKS](network-reqs.md#network-requirements-subnets). Antes de selecionar sub-redes, convém estar familiarizado com todos os [Requisitos e considerações sobre VPCs e sub-redes do Amazon EKS](network-reqs.md).
1. Execute o seguinte comando:
```
eksctl create cluster --name my-cluster --region region-code --version 1.35 --vpc-private-subnets subnet-ExampleID1,subnet-ExampleID2 --without-nodegroup
```
O provisionamento de cluster leva alguns minutos. Durante a criação do cluster, várias linhas de saída são exibidas. A última linha do resultado é semelhante ao exemplo de linha a seguir.
```
[✓] EKS cluster "my-cluster" in "region-code" region is ready
```
1. Continue com [Etapa 3: atualizar o kubeconfig](#step3)
#### Configurações opcionais
Para ver a maioria das opções que podem ser especificadas ao criar um cluster com `eksctl`, use o comando `eksctl create cluster --help`. Para ver todas as opções disponíveis, é possível utilizar um arquivo `config`. Para obter mais informações, consulte [Uso dos arquivos de configuração](https://eksctl.io/usage/creating-and-managing-clusters/#using-config-files) e o [esquema de arquivo de configuração](https://eksctl.io/usage/schema/) na documentação do `eksctl`. Você pode encontrar [exemplos de arquivos de configuração](https://github.com/weaveworks/eksctl/tree/master/examples) no GitHub.
Veja a seguir as configurações opcionais que, se necessário, devem ser adicionadas ao comando anterior. Apenas é possível habilitar essas opções ao criar o cluster, e não depois. Se precisar especificar essas opções, você deverá criar o cluster com um [arquivo de configuração eksctl](https://eksctl.io/usage/creating-and-managing-clusters/#using-config-files) e especificar as configurações, em vez de usar o comando anterior.
+ Se você quiser especificar um ou mais grupos de segurança que o Amazon EKS atribui às interfaces de rede que ele cria, especifique a opção [securityGroup](https://eksctl.io/usage/schema/#vpc-securityGroup).
Independentemente de você escolher algum grupo de segurança, o Amazon EKS cria um grupo de segurança que permite comunicação entre seu cluster e sua 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 quiser especificar de qual bloco `IPv4` de Encaminhamento Entre Domínios Sem Classificação (CIDR) o Kubernetes atribui endereços IP de serviço, especifique a opção [serviceIPv4CIDR](https://eksctl.io/usage/schema/#kubernetesNetworkConfig-serviceIPv4CIDR).
Especificar seu próprio intervalo pode ajudar a evitar conflitos entre serviços do Kubernetes e outras redes com emparelhamento ou conectadas à VPC. Insira um intervalo em notação CIDR. Por exemplo: `10.2.0.0/16`.
O bloco CIDR deve atender aos seguintes requisitos:
+ Estar dentro de um dos seguintes intervalos: `10.0.0.0/8`, `172.16.0.0/12` ou `192.168.0.0/16`.
+ Ter um tamanho mínimo de `/24` e máximo de `/12`.
+ Não se sobrepor ao intervalo da VPC para seus recursos do Amazon EKS.
Apenas é possível especificar essa opção ao utilizar a família de endereços `IPv4` e somente ao criar o cluster. Se isso não for especificado, o Kubernetes atribuirá endereços IP de serviço de qualquer um dos blocos CIDR `10.100.0.0/16` ou `172.20.0.0/16`.
+ Se estiver criando um cluster e quiser que ele atribua endereços `IPv6` a pods e serviços em vez de endereços `IPv4`, especifique a opção [ipFamily](https://eksctl.io/usage/schema/#kubernetesNetworkConfig-ipFamily).
Por padrão, o Kubernetes atribui endereços `IPv4` aos pods e serviços. Antes de optar por utilizar a família `IPv6`, familiarize-se com todas as considerações e requisitos nos tópicos [Requisitos e considerações para VPCs](network-reqs.md#network-requirements-vpc), [Requisitos e considerações para sub-redes](network-reqs.md#network-requirements-subnets), [Exibir os requisitos para grupos de segurança do Amazon EKS em clusters](sec-group-reqs.md) e [Saiba mais sobre endereços IPv6 para clusters, pods e serviços](cni-ipv6.md). Caso escolha a família `IPv6`, você não poderá especificar um intervalo de endereços para o Kubernetes atribuir endereços de serviço `IPv6` da mesma forma que faz para a família `IPv4`. O Kubernetes atribui endereços de serviço do intervalo exclusivo de endereços locais (`fc00::/7`).
### Criar cluster - AWS console
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Escolha **Add cluster** (Adicionar cluster) e, em seguida, **Create** (Criar).
1. Em **Opções de configuração**, selecione **Configuração personalizada**.
+ Para obter informações sobre como criar rapidamente um cluster com o Modo Automático do EKS, consulte [Criar um cluster do Modo Automático do EKS com o Console de gerenciamento da AWS](automode-get-started-console.md).
1. Em **Modo Automático do EKS**, desative a opção **Usar Modo Automático do EKS**.
+ Para obter informações sobre como criar um cluster do Modo Automático do EKS com configuração personalizada, consulte [Criar um cluster do Modo Automático do Amazon EKS](create-cluster-auto.md).
1. Na página **Configure cluster** (Configurar cluster), preencha os seguintes campos:
+ **Name** (Nome): um nome exclusivo para o cluster. O nome pode conter apenas caracteres alfanuméricos (diferencia maiúsculas de minúsculas), hifens e sublinhados. 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.
+ **Perfil do IAM do cluster**: escolha o perfil do IAM do cluster do Amazon EKS que você criou para permitir que o ambiente de gerenciamento do Kubernetes gerencie os recursos da AWS em seu nome.
+ **Kubernetes version (Versão do Kubernetes)** – a versão do Kubernetes a ser usada para o cluster. Recomendamos que você selecione a versão mais recente, a menos que precise de uma versão anterior.
+ **Tipo de suporte**: a política de versão do Kubernetes que você deseja definir para o cluster. Se desejar que seu cluster seja executado somente em uma versão com suporte padrão, escolher **Suporte padrão** é uma opção possível. Se desejar que seu cluster entre no suporte estendido ao final do suporte padrão para uma versão, escolha **Suporte estendido**. Caso selecione uma versão do Kubernetes que esteja atualmente com suporte estendido, você não poderá selecionar o suporte padrão como opção.
+ **Secrets encryption** (Criptografia de segredos): (Opcional) Escolha habilitar a criptografia de segredos do Kubernetes usando uma chave do KMS. Também é possível isso depois de criar o cluster. Antes de habilitar esse recurso, familiarize-se com as informações em [Criptografar segredos do Kubernetes com o KMS em clusters existentes](enable-kms.md).
+ **Tags** (Etiquetas) – (opcional) adicione etiquetas ao cluster. Para obter mais informações, consulte [Organizar recursos do Amazon EKS com tags](eks-using-tags.md).
+ **Mudança de zona do ARC**: (opcional) você pode usar o Controlador de Recuperação de Aplicações do Route 53 para mitigar zonas de disponibilidade prejudicadas. Para obter mais informações, consulte [Saiba mais sobre a mudança de zona do Controlador de Recuperação de Aplicações da Amazon (ARC, na sigla em inglês) no Amazon EKS](zone-shift.md).
1. Na seção **Acesso ao cluster** da página de configuração do cluster, preencha os seguintes campos:
+ **Inicialização do acesso de administrador do cluster**: o criador do cluster é automaticamente um administrador do Kubernetes. Caso deseje desabilitar essa opção, selecione **Desabilitar acesso de administrador ao cluster**.
+ **Modo de autenticação do cluster**: determine como você deseja conceder aos usuários e perfis do IAM acesso às APIs do Kubernetes. Para obter mais informações, consulte [Definir modo de autenticação do cluster](grant-k8s-access.md#set-cam).
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 que atenda aos [Requisitos de VPC do Amazon EKS](network-reqs.md#network-requirements-vpc) na qual criar o cluster. Antes de escolher uma VPC, recomendamos familiarizar-se com todos os requisitos e considerações em [Exibir os requisitos de rede do Amazon EKS para VPC e sub-redes](network-reqs.md). Não será possível alterar quais VPCs você deseja utilizar depois de criar o cluster. Se nenhuma VPC estiver listada, você precisará criar uma primeiro. Para obter mais informações, consulte [Criar uma Amazon VPC para o cluster do Amazon EKS](creating-a-vpc.md).
+ **Subnets** (Sub-redes): por padrão, as sub-redes disponíveis na VPC especificada no campo anterior são pré-selecionadas. É necessário selecionar pelo menos duas.
As sub-redes escolhidas devem atender aos [Requisitos para sub-redes do Amazon EKS](network-reqs.md#network-requirements-subnets). Antes de selecionar sub-redes, convém estar familiarizado com todos os [Requisitos e considerações sobre VPCs e sub-redes do Amazon EKS](network-reqs.md).
**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.
Independentemente de você escolher algum grupo de segurança, o Amazon EKS cria um grupo de segurança que permite comunicação entre seu cluster e sua 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.
+ **Escolher família de endereços IP do cluster**: é possível escolher **IPv4** e **IPv6**.
Por padrão, o Kubernetes atribui endereços `IPv4` aos pods e serviços. Antes de decidir usar a família `IPv6`, verifique se você está familiarizado com todas as considerações e requisitos dos tópicos [Requisitos e considerações da VPC](network-reqs.md#network-requirements-vpc), [Requisitos e considerações para sub-redes](network-reqs.md#network-requirements-subnets), [Exibir os requisitos para grupos de segurança do Amazon EKS em clusters](sec-group-reqs.md) e [Saiba mais sobre endereços IPv6 para clusters, pods e serviços](cni-ipv6.md). Caso escolha a família `IPv6`, você não poderá especificar um intervalo de endereços para o Kubernetes atribuir endereços de serviço `IPv6` da mesma forma que faz para a família `IPv4`. O Kubernetes atribui endereços de serviço do intervalo exclusivo de endereços locais (`fc00::/7`).
+ (Opcional) Escolha **Configurar intervalo de endereços IP do Kubernetes** e especifique um **Intervalo `IPv4` de serviços**.
Especificar seu próprio intervalo pode ajudar a evitar conflitos entre serviços do Kubernetes e outras redes com emparelhamento ou conectadas à VPC. Insira um intervalo em notação CIDR. Por exemplo: `10.2.0.0/16`.
O bloco CIDR deve atender aos seguintes requisitos:
+ Estar dentro de um dos seguintes intervalos: `10.0.0.0/8`, `172.16.0.0/12` ou `192.168.0.0/16`.
+ Ter um tamanho mínimo de `/24` e máximo de `/12`.
+ Não se sobrepor ao intervalo da VPC para seus recursos do Amazon EKS.
Apenas é possível especificar essa opção ao utilizar a família de endereços `IPv4` e somente ao criar o cluster. Se isso não for especificado, o Kubernetes atribuirá endereços IP de serviço de qualquer um dos blocos CIDR `10.100.0.0/16` ou `172.20.0.0/16`.
+ Para **Cluster endpoint access** (Acesso ao endpoint do cluster), selecione uma opção. Depois de criar o cluster, você poderá alterar essa opção. Antes de selecionar uma opção não padrão, familiarize-se com as opções e suas implicações. Para obter mais informações, consulte [Endpoint do servidor de API do cluster](cluster-endpoint.md).
Após terminar com essa página, escolha **Próximo**.
1. (Opcional) Na página **Configurar observabilidade**, escolha quais opções de **Métricas** e **Log do ambiente de gerenciamento** deseja ativar. Por padrão, o cada tipo de log está desativado.
+ Para obter mais informações sobre as opções 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 **Selecionar complementos**, escolha os complementos que você deseja adicionar ao cluster. Alguns complementos são pré-selecionados. Você pode escolher quantos **complementos do Amazon EKS** e ** do AWS Marketplace** desejar. Se os **complementos do AWS Marketplace** que você deseja instalar não estiverem listados, será possível clicar na numeração da página para visualizar resultados de páginas adicionais ou pesquisar os **complementos disponíveis no AWS Marketplace** inserindo algum texto na caixa de pesquisa. Você também poderá pesquisar por **categoria**, **fornecedor** ou **modelo de preços** e depois escolher os complementos nos resultados da pesquisa. Ao criar um cluster, é possível visualizar, selecionar e instalar qualquer complemento que ofereça suporte às Identidade de Pods do EKS, conforme detalhado em [Saiba como a Identidade de Pods do EKS concede aos pods acesso aos serviços da AWS](pod-identities.md).
Após terminar com essa página, escolha **Próximo**.
Alguns complementos, como Amazon VPC CNI, CoreDNS e kube-proxy, são instalados por padrão. Se você desabilitar qualquer um dos complementos padrão, isso poderá afetar sua capacidade de executar aplicações do Kubernetes.
1. Na página **Configurar opções de complementos selecionados**, selecione a versão que deseja instalar. Você sempre pode atualizar para uma versão posterior após a criação do cluster.
Para complementos com suporte para Identidade de Pods do EKS, é possível usar o console para gerar automaticamente o perfil com o nome, a política gerenciada pela AWS e a política de confiança pré-preenchidos especificamente para o complemento. É possível reutilizar perfis existentes ou criar novos perfis para complementos com suporte. Para obter as etapas de uso do console para criar perfis para complementos que ofereçam suporte às Identidades de Pods do EKS, consulte [Criar complemento (console do AWS)](creating-an-add-on.md#create_add_on_console). Se um complemento não oferecer suporte à Identidade de Pods do EKS, uma mensagem será exibida com instruções para usar o assistente para criar os perfis do IAM para contas de serviço (IRSA) após a criação do cluster.
Você pode atualizar a configuração de cada complemento após a criação do cluster. Para obter mais informações sobre a configuração de complementos, consulte [Atualizar um complemento do Amazon EKS](updating-an-add-on.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.
**nota**
Talvez você receba um erro porque uma das zonas de disponibilidade em sua solicitação não tem capacidade suficiente para criar um cluster do Amazon EKS. Se isso acontecer, o resultado do erro conterá as zonas de disponibilidade que são compatíveis com o novo cluster. Tente criar o cluster com pelo menos duas sub-redes que estejam localizadas nas zonas de disponibilidade compatíveis de sua conta. Para obter mais informações, consulte [Capacidade insuficiente](troubleshooting.md#ice).
O provisionamento de cluster leva alguns minutos.
1. Continue com [Etapa 3: atualizar o kubeconfig](#step3)
### Crar cluster: AWS CLI
1. Crie o cluster usando o comando a seguir. Antes da execução do comando, realize as seguintes substituições:
+ Substitua *region-code* pela região AWS na qual você deseja criar o cluster.
+ Substitua *my-cluster* por um nome para seu cluster. O nome pode conter apenas caracteres alfanuméricos (diferencia maiúsculas de minúsculas), hifens e sublinhados. Ele deve começar com um caractere alfanumérico e não pode ter mais de 100 caracteres. O nome deve ser exclusivo na região da AWS e na conta da AWS em que você está criando o cluster.
+ Substitua *1.35* por qualquer [versão compatível do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Substitua *111122223333* pelo ID da sua conta e *myAmazonEKSClusterRole* pelo nome do perfil IAM do cluster.
+ Substitua os valores de `subnetIds` pelos seus próprios valores. Também é possível adicionar outras IDs. Você deve especificar pelo menos dois IDs de sub-rede.
As sub-redes escolhidas devem atender aos [Requisitos para sub-redes do Amazon EKS](network-reqs.md#network-requirements-subnets). Antes de selecionar sub-redes, convém estar familiarizado com todos os [Requisitos e considerações sobre VPCs e sub-redes do Amazon EKS](network-reqs.md).
+ Se não quiser especificar um ID de grupo de segurança, remova `,securityGroupIds=sg-` do comando. Se quiser especificar um ou mais IDs de grupo de segurança, substitua os valores de `securityGroupIds` pelos seus próprios. Também é possível adicionar outras IDs.
Independentemente de você escolher algum grupo de segurança, o Amazon EKS cria um grupo de segurança que permite comunicação entre seu cluster e sua 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.
```
aws eks create-cluster --region region-code --name my-cluster --kubernetes-version 1.35 \
--role-arn arn:aws:iam::111122223333:role/myAmazonEKSClusterRole \
--resources-vpc-config subnetIds=subnet-ExampleID1,subnet-ExampleID2,securityGroupIds=sg-ExampleID1
```
**nota**
Talvez você receba um erro porque uma das zonas de disponibilidade em sua solicitação não tem capacidade suficiente para criar um cluster do Amazon EKS. Se isso acontecer, o resultado do erro conterá as zonas de disponibilidade que são compatíveis com o novo cluster. Tente criar o cluster com pelo menos duas sub-redes que estejam localizadas nas zonas de disponibilidade compatíveis de sua conta. Para obter mais informações, consulte [Capacidade insuficiente](troubleshooting.md#ice).
Veja a seguir as configurações opcionais que, se necessário, devem ser adicionadas ao comando anterior. Apenas é possível habilitar essas opções ao criar o cluster, e não depois.
+ Por padrão, o EKS instala vários complementos de rede durante a criação do cluster. Isso inclui o Amazon VPC CNI, o CoreDNS e o kube-proxy.
Se você quiser desabilitar a instalação desses complementos de rede padrão, use o parâmetro abaixo. Essa opção poderá ser usada para CNIs alternativos, como Cilium. Para obter mais informações, confira a [API Reference do EKS](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html).
`aws eks create-cluster --no-bootstrap-self-managed-addons …`
+ Se quiser especificar de qual bloco de Encaminhamento Entre Domínios Sem Classificação (CIDR) `IPv4` o Kubernetes atribui endereços IP de serviço, será necessário especificá-lo adicionando `--kubernetes-network-config serviceIpv4Cidr=` ao comando a seguir.
Especificar seu próprio intervalo pode ajudar a evitar conflitos entre serviços do Kubernetes e outras redes com emparelhamento ou conectadas à VPC. Insira um intervalo em notação CIDR. Por exemplo: `10.2.0.0/16`.
O bloco CIDR deve atender aos seguintes requisitos:
+ Estar dentro de um dos seguintes intervalos: `10.0.0.0/8`, `172.16.0.0/12` ou `192.168.0.0/16`.
+ Ter um tamanho mínimo de `/24` e máximo de `/12`.
+ Não se sobrepor ao intervalo da VPC para seus recursos do Amazon EKS.
Apenas é possível especificar essa opção ao utilizar a família de endereços `IPv4` e somente ao criar o cluster. Se isso não for especificado, o Kubernetes atribuirá endereços IP de serviço de qualquer um dos blocos CIDR `10.100.0.0/16` ou `172.20.0.0/16`.
+ Se estiver criando um cluster e quiser que o cluster atribua endereços `IPv6` a pods e serviços em vez de endereços `IPv4`, adicione `--kubernetes-network-config ipFamily=ipv6` ao comando a seguir.
Por padrão, o Kubernetes atribui endereços `IPv4` aos pods e serviços. Antes de decidir usar a família `IPv6`, verifique se você está familiarizado com todas as considerações e requisitos dos tópicos [Requisitos e considerações da VPC](network-reqs.md#network-requirements-vpc), [Requisitos e considerações para sub-redes](network-reqs.md#network-requirements-subnets), [Exibir os requisitos para grupos de segurança do Amazon EKS em clusters](sec-group-reqs.md) e [Saiba mais sobre endereços IPv6 para clusters, pods e serviços](cni-ipv6.md). Caso escolha a família `IPv6`, você não poderá especificar um intervalo de endereços para o Kubernetes atribuir endereços de serviço `IPv6` da mesma forma que faz para a família `IPv4`. O Kubernetes atribui endereços de serviço do intervalo exclusivo de endereços locais (`fc00::/7`).
1. Leva alguns minutos para provisionar o cluster. Você pode consultar o status do cluster com o comando a seguir.
```
aws eks describe-cluster --region region-code --name my-cluster --query "cluster.status"
```
Não prossiga para a próxima etapa até que a saída recebida esteja `ACTIVE`.
1. Continue com [Etapa 3: atualizar o kubeconfig](#step3)
## Etapa 3: atualizar o kubeconfig
1. Se você criou seu cluster usando `eksctl`, pode ignorar esta etapa. Isso ocorre porque `eksctl` já concluiu essa etapa para você. Habilite o `kubectl` para se comunicar com o cluster adicionando um novo contexto ao arquivo `kubectl` `config`. Para obter mais informaçõ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 um exemplo de saída abaixo.
```
Added new context arn:aws:eks:region-code:111122223333:cluster/my-cluster to /home/username/.kube/config
```
1. Confirme a comunicação com o cluster, executando o seguinte comando:
```
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
```
## Etapa 4: configuração do cluster
1. (Recomendado) Para usar alguns complementos do Amazon EKS ou para permitir que workloads individuais do Kubernetes tenham permissões específicas do AWS Identity and Access Management (IAM), [crie um provedor OpenID Connect (OIDC) do IAM](enable-iam-roles-for-service-accounts.md) para o cluster. Você só precisa criar um provedor OIDC do IAM para o cluster uma vez. Para saber mais sobre os complementos do Amazon EKS, consulte [Complementos do Amazon EKS](eks-add-ons.md). Para saber mais sobre a atribuição de permissões específicas do IAM às workloads, consulte [Funções do IAM para contas de serviço](iam-roles-for-service-accounts.md).
1. (Recomendado) Configure o cluster para o plug-in CNI da Amazon VPC para Kubernetes antes de implantar nós do Amazon EC2 no cluster. Por padrão, o plugin foi instalado com o seu cluster. Quando nós do Amazon EC2 são adicionados ao cluster, o plugin é implantado automaticamente em cada nó do Amazon EC2 que você adicionar. O plugin requer a anexação de uma das seguintes políticas do IAM a um perfil do IAM. Se o seu cluster usar a família `IPv4`, use a política do IAM gerenciada [AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html). Se o seu cluster usar a família `IPv6`, use uma [política do IAM criada por você](cni-iam-role.md#cni-iam-role-create-ipv6-policy).
O perfil do IAM ao qual a política é anexada pode ser o perfil do IAM do nó ou um perfil dedicado utilizado apenas para o plugin. Convém anexar a política a esse perfil. Para obter mais informações sobre como criar o perfil, consulte [Configurar o plug-in CNI da Amazon VPC para usar IRSA](cni-iam-role.md) ou [perfil do IAM de nó do Amazon EKS](create-node-role.md).
1. Se você implantou seu cluster usando o Console de gerenciamento da AWS, pode ignorar esta etapa. O Console de gerenciamento da AWS implanta os complementos CoreDNS, plug-in CNI da Amazon VPC para Kubernetes e `kube-proxy` do Amazon EKS por padrão.
Se você implementar o cluster usando o `eksctl` ou a AWS CLI, os complementos autogerenciados `kube-proxy`, CoreDNS e plug-in CNI da Amazon VPC para Kubernetes e serão implantados. É possível migrar os complementos autogerenciados `kube-proxy`, CoreDNS e plug-in CNI da Amazon VPC para Kubernetes que são implantados com o cluster, para complementos do Amazon EKS. Para obter mais informações, consulte [Complementos do Amazon EKS](eks-add-ons.md).
1. (Opcional) Se ainda não fez isso, você poderá habilitar as métricas do Prometheus para o cluster. Para obter mais informações, consulte [Criar um extrator](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-create) no *Guia do usuário do Amazon Managed Service for Prometheus*.
1. Caso planeje implementar workloads no cluster que usem volumes do Amazon EBS, você deverá instalar a [CSI do Amazon EBS](ebs-csi.md) no cluster antes de implementar as workloads.
## Próximas etapas
+ A [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que criou o cluster é a única que tem acesso ao cluster. [Conceda permissões a outras entidades principais do IAM](grant-k8s-access.md) para que elas possam acessar o cluster.
+ Se a entidade principal do IAM que criou o cluster tiver apenas as permissões mínimas do IAM referenciadas nos pré-requisitos, então talvez seja interessante adicionar mais permissões do Amazon EKS a essa entidade principal. Para obter mais informações sobre como conceder permissões do Amazon EKS a entidades principais do IAM, consulte [Identity and Access Management para o Amazon EKS](security-iam.md).
+ Se quiser que a entidade principal do IAM que criou o cluster, ou qualquer outra entidade principal, visualize 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.
+ Se quiser que os nós e as entidades principais do IAM acessem o cluster do dentro da VPC, habilite o endpoint privado do seu cluster. Por padrão, o endpoint público está habilitado. É possível desativar o endpoint público depois de habilitar o endpoint privado, se desejado. Para obter mais informações, consulte [Endpoint do servidor de API do cluster](cluster-endpoint.md).
+ [Habilitar a criptografia de segredos para o seu cluster](enable-kms.md).
+ [Configurar o registro em log para o seu cluster](control-plane-logs.md).
+ [Adicionar nós ao seu cluster](eks-compute.md).
# Ambiente de gerenciamento provisionado do Amazon EKS
## Visão geral
O ambiente de gerenciamento provisionado do Amazon EKS é um recurso que permite aos administradores de cluster selecionar entre diferentes níveis de escalabilidade, definindo o nível ideal para garantir que o ambiente de gerenciamento do cluster tenha alta performance e previsibilidade. Com isso, administradores de cluster podem assegurar que o ambiente de gerenciamento esteja sempre provisionado conforme a capacidade definida.
O Amazon EKS oferece dois modos de operação para o ambiente de gerenciamento do cluster. Por padrão, os clusters do Amazon EKS usam o **modo padrão**, no qual o ambiente de gerenciamento aumenta ou reduz a escala verticalmente, de forma automática, com base nas demandas da workload. O modo padrão aloca dinamicamente capacidade suficiente do ambiente de gerenciamento para atender às necessidades da workload e é a solução recomendada para a maioria dos casos de uso. No entanto, para workloads especializadas que não admitem qualquer variabilidade da performance devido à escalabilidade do ambiente de gerenciamento, ou para aquelas que exigem grandes quantidades de capacidade, é possível optar pelo **modo provisionado**. Com o modo provisionado, você pode realizar a alocação prévia da capacidade do ambiente de gerenciamento, garantindo prontidão para atender a demandas rigorosas da workload.
**nota**
O modo provisionado é um modo de operação adicional do ambiente de gerenciamento, disponível em conjunto com o modo padrão original. A introdução do modo provisionado não altera o comportamento do modo padrão.
Com o ambiente de gerenciamento provisionado do EKS, os administradores de cluster podem realizar o provisionamento prévio da capacidade desejada de forma antecipada, garantindo alta performance e previsibilidade constante ao ambiente de gerenciamento do cluster. O ambiente de gerenciamento provisionado do EKS também permite que os administradores de cluster provisionem a mesma capacidade do ambiente de gerenciamento em diversos ambientes, desde o ambiente de preparação até a produção e locais de recuperação de desastres. Isso é fundamental para assegurar a consistência e a previsibilidade da performance do ambiente de gerenciamento em todos os ambientes. Por fim, o ambiente de gerenciamento provisionado do EKS oferece acesso a níveis altíssimos de performance no ambiente de gerenciamento, permitindo a execução de workloads de IA com escalabilidade massiva, computação de alta performance e processamento de dados em grande escala no Kubernetes.
Por padrão, todos os clusters do Amazon EKS, tanto os novos quanto os já existentes, operam no modo padrão. Para clusters que requerem uma performance alta e previsível do ambiente de gerenciamento, você pode optar pelo recurso de ambiente de gerenciamento provisionado do EKS. A cobrança será feita com base na tarifa horária do nível de escalabilidade escolhido para o ambiente de gerenciamento, somada às taxas horárias do EKS para suporte padrão ou estendido. Para obter mais informações sobre preços, consulte [Preços do Amazon EKS](https://aws.amazon.com/eks/pricing/).
![\[Modos do ambiente de gerenciamento do Amazon EKS\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/control-plane-modes.png)
## Casos de uso
O ambiente de gerenciamento provisionado do EKS foi projetado para atender a cenários específicos em que a performance alta e previsível do ambiente de gerenciamento é fundamental para as operações. Compreender esses casos de uso pode ajudar você a determinar se o ambiente de gerenciamento provisionado do EKS é a solução ideal para as workloads.
**Workloads sensíveis à performance**: para as workloads que demandam baixa latência e máxima performance do ambiente de gerenciamento do Kubernetes, o ambiente de gerenciamento provisionado do EKS oferece uma capacidade que remove instabilidades causadas pela escalabilidade do ambiente de gerenciamento.
**Workloads com escalabilidade massiva**: se você executa workloads altamente escaláveis, como treinamento e inferência de IA, computação de alta performance ou processamento de dados em grande escala, que exigem um grande número de nós no cluster, o ambiente de gerenciamento provisionado fornece a capacidade necessária para suportar essas workloads exigentes.
**Eventos de alta demanda antecipados**: quando você espera um aumento súbito nas solicitações ao ambiente de gerenciamento devido a um evento próximo, como vendas ou promoções de comércio eletrônico, lançamentos de produtos, temporadas de compras ou grandes eventos esportivos e de entretenimento, o ambiente de gerenciamento provisionado permite ajustar a escalabilidade da capacidade antecipadamente. Essa abordagem proativa garante que o ambiente de gerenciamento esteja pronto para lidar com o aumento de carga, sem a necessidade de esperar que a escalabilidade automática responda à demanda.
**Consistência de ambientes**: o ambiente de gerenciamento provisionado permite replicar a capacidade e a performance do ambiente de gerenciamento entre os ambientes de preparação e de produção, ajudando você a identificar problemas potenciais antecipadamente, antes da implantação em produção. Ao manter o mesmo nível do ambiente de gerenciamento em diferentes ambientes, você garante que os resultados dos testes reflitam com precisão o comportamento em ambientes de produção, evitando imprevistos de performance no momento da implantação.
**Recuperação de desastres e continuidade de negócios**: para cenários de recuperação de desastres, o ambiente de gerenciamento provisionado permite que você provisione ambientes de failover com o mesmo nível de capacidade do ambiente primário. Isso garante o mínimo de interrupção e uma recuperação rápida durante eventos de failover, pois o cluster de recuperação de desastres terá características de performance do ambiente de gerenciamento idênticas às do cluster de produção desde o instante de sua ativação.
## Níveis de escalabilidade do ambiente de gerenciamento
O ambiente de gerenciamento provisionado do EKS oferece níveis de escalabilidade cujos nomes se baseiam nos tamanhos de camisetas (XL, 2XL, 4XL e 8XL). Cada nível define a capacidade por meio de três atributos principais do Kubernetes que determinam as características de performance do ambiente de gerenciamento do cluster. Compreender esses atributos ajuda você a selecionar o nível adequado para os requisitos da workload.
A **simultaneidade de solicitações de API** mede o número de solicitações que o servidor de API do ambiente de gerenciamento do Kubernetes pode processar simultaneamente, o que é fundamental para workloads com alto throughput.
A **taxa de agendamento de pods** indica a rapidez com que o agendador padrão do Kubernetes consegue agendar pods em nós, medida em pods por segundo.
O **tamanho do banco de dados do cluster** indica o espaço de armazenamento alocado para o etcd, o banco de dados que contém o estado e os metadados do cluster.
Ao provisionar o ambiente de gerenciamento do cluster em um determinado nível de escalabilidade usando o ambiente de gerenciamento provisionado, o EKS garante que o ambiente de gerenciamento mantenha os limites correspondentes a esse nível. Os limites dos níveis de escalabilidade do ambiente de gerenciamento variam conforme a versão do Kubernetes, como mostrado nas tabelas a seguir.
### EKS v1.28 e v1.29
| Nível de escalabilidade do ambiente de gerenciamento provisionado | Simultaneidade de solicitações de API (estações) | Taxa de agendamento de pods (pods por segundo) | Tamanho do banco de dados do cluster (GB) |
| --- | --- | --- | --- |
| XL | 1700 | 100 | 16 |
| 2XL | 3400 | 100 | 16 |
| 4XL | 6800 | 100 | 16 |
| 8XL | 13600 | 100 | 16 |
### EKS v1.30 e versões posteriores
| Nível de escalabilidade do ambiente de gerenciamento provisionado | Simultaneidade de solicitações de API (estações) | Taxa de agendamento de pods (pods por segundo) | Tamanho do banco de dados do cluster (GB) |
| --- | --- | --- | --- |
| XL | 1700 | 167 | 16 |
| 2XL | 3400 | 283 | 16 |
| 4XL | 6800 | 400 | 16 |
| 8XL | 13600 | 400 | 16 |
### Monitoramento da utilização do nível de escalabilidade do ambiente de gerenciamento
O Amazon EKS disponibiliza várias métricas que auxiliam no monitoramento do uso do nível de escalabilidade do ambiente de gerenciamento. Essas métricas são publicadas como [métricas do Amazon CloudWatch](cloudwatch.md) e estão acessíveis por meio dos consoles do CloudWatch e do EKS. Além disso, essas métricas podem ser coletadas via scraping do endpoint de Prometheus do cluster de EKS (acesse [aqui](prometheus.md)).
| | **Métricas do Prometheus** | **Métrica do CloudWatch** |
| --- | --- | --- |
| **Concorrência de solicitações de API** | apiserver\$1flowcontrol\$1current\$1executing\$1seats | apiserver\$1flowcontrol\$1current\$1executing\$1seats |
| **Taxa de agendamento de pods** | scheduler\$1schedule\$1attempts\$1total | scheduler\$1schedule\$1attempts\$1total, scheduler\$1schedule\$1attempts\$1SCHEDULED, scheduler\$1schedule\$1attempts\$1UNSCHEDULABLE |
| **Tamanho do banco de dados do cluster** | apiserver\$1storage\$1size\$1bytes | apiserver\$1storage\$1size\$1bytes |
É possível visualizar a utilização do ambiente de gerenciamento no console do Amazon EKS. Na página de visão geral do cluster, escolha **Monitorar cluster** para acessar o painel de observabilidade e, em seguida, selecione a guia **Monitoramento do ambiente de gerenciamento** para visualizar a utilização do ambiente de gerenciamento na seção **Escalabilidade do ambiente de gerenciamento**.
![\[Monitoramento do cluster de EKS\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/monitor-cluster.png)
![\[Monitoramento do ambiente de gerenciamento do EKS\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/control-plane-monitoring.png)
### Noções básicas sobre a diferença entre a capacidade do nível e a performance real
Ao selecionar um nível de escalabilidade do ambiente de gerenciamento provisionado, os atributos desse nível representam as configurações subjacentes que o Amazon EKS aplica ao ambiente de gerenciamento. Contudo, a performance real alcançada varia de acordo com os padrões da workload, as configurações e a aderência às práticas recomendadas do Kubernetes. Por exemplo, enquanto o nível 4XL define o recurso de prioridade e de equidade da API (APF, na sigla em inglês) com 6.800 estações de solicitações simultâneas, o throughput real de solicitações que você obtém do ambiente de gerenciamento depende dos tipos de operações realizadas. Por exemplo, o Kubernetes penaliza solicitações do tipo “list” mais do que as do tipo “get” e, por isso, o número efetivo de solicitações “list” processadas simultaneamente pelo ambiente de gerenciamento é menor do que o de solicitações “get” (confira [aqui](https://docs.aws.amazon.com/eks/latest/best-practices/scale-control-plane.html#_api_priority_and_fairness)). De forma semelhante, ainda que o QPS do agendador padrão seja 400 no nível 4XL, a taxa real de agendamento de pods depende de fatores como o estado de prontidão e a integridade dos nós para o agendamento. Para alcançar a performance ideal, certifique-se de que as aplicações sigam as práticas recomendadas do Kubernetes (confira [aqui](https://docs.aws.amazon.com/eks/latest/best-practices/scalability.html)) e estejam configuradas adequadamente para as características da workload.
## Considerações
+ **Capacidade do ambiente de gerenciamento padrão**: o modo padrão de ambiente de gerenciamento do EKS oferece a melhor relação entre custo e benefício e é a opção recomendada para a maioria dos casos de uso. No entanto, para workloads especializadas que não admitem qualquer variabilidade da performance devido à escalabilidade do ambiente de gerenciamento, ou para aquelas que exigem grandes quantidades de capacidade, considere usar o modo provisionado.
+ **Adesão necessária**: os clusters atuais não realizam o aumento da escala verticalmente de forma automática do ambiente de gerenciamento padrão para um nível com [preços](https://aws.amazon.com/eks/pricing/) superiores do ambiente de gerenciamento provisionado do EKS. É necessário aderir explicitamente a um dos novos níveis de escalabilidade do ambiente de gerenciamento provisionado do EKS.
+ **Restrição de saída**: o modo padrão do ambiente de gerenciamento fornece suporte a um tamanho de banco de dados do cluster (etcd) de até 8 GB. Se o tamanho do banco de dados do cluster exceder 8 GB durante o uso do modo provisionado, você não poderá retornar ao modo padrão até reduzir o tamanho do banco de dados para menos de 8 GB. Por exemplo, se você estiver usando 14 GB de armazenamento de banco de dados no modo provisionado, deverá primeiro reduzir a utilização do banco de dados para menos de 8 GB antes de retornar ao modo padrão.
+ **Não há escalabilidade automática de nível**: o ambiente de gerenciamento provisionado do EKS não realiza a transição automática entre os níveis. Após escolher um nível de escalabilidade, o ambiente de gerenciamento do cluster fica vinculado a esse nível, o que assegura uma performance constante e previsibilidade. No entanto, você tem a flexibilidade de implementar sua própria solução de ajuste de escala automático ao monitorar as métricas de utilização do nível e usar as APIs do ambiente de gerenciamento provisionado do EKS para reduzir ou aumentar a escala verticalmente quando as métricas ultrapassarem os limites definidos por você, garantindo total controle sobre a estratégia de escalabilidade e otimização de custos.
+ **Consulta do nível atual**: é possível usar o console do Amazon EKS, a Amazon Web Services CLI ou a API para verificar em qual nível de escalabilidade o ambiente de gerenciamento se encontra. Na CLI, você pode executar o comando `describe-cluster`: `aws eks describe-cluster --name cluster-name`
+ **Tempo de transição de nível**: você pode usar o console do Amazon EKS, as APIs do Amazon EKS ou a CLI para sair de um nível ou alternar entre os níveis de escalabilidade. O Amazon EKS introduziu um novo tipo de atualização de cluster chamado `ScalingTierConfigUpdate`, que você pode inspecionar para monitorar o progresso da transição. Após executar um comando de alteração de nível, é possível listar as atualizações no cluster para obter uma nova atualização do tipo `ScalingTierConfigUpdate` com o status `Updating`. Esse status passará para `Successful` quando a alteração for finalizada ou para `Failed` em caso de falha. O campo de erro na atualização indica o motivo da falha Não há restrições quanto à frequência com que você pode alternar entre os níveis. A alteração do nível do ambiente de gerenciamento leva alguns minutos para ser concluída. Não há tempo de inatividade dos servidores de API durante esse processo, pois o EKS inicia novos servidores de API antes de encerrar os antigos.
+ **Seleção do nível ideal**: para determinar o nível de escalabilidade do ambiente de gerenciamento provisionado ideal para o cluster, você pode realizar testes de carga provisionando o cluster no nível máximo (8XL). Depois, execute um teste de carga para simular o cenário de maior demanda no ambiente de gerenciamento do cluster. Monitore as métricas de utilização do nível do ambiente de gerenciamento no momento de carga máxima e empregue esses dados para escolher o nível de escalabilidade adequado no modo provisionado.
+ **Preços do ambiente de gerenciamento provisionado**: a cobrança será feita com base na taxa horária correspondente ao nível de escalabilidade do ambiente de gerenciamento provisionado em que o cluster estiver operando. Este valor é adicional às taxas horárias do suporte padrão ou do suporte estendido. Consulte a [página](https://aws.amazon.com/eks/pricing/) de preços do Amazon EKS para obter mais detalhes.
+ **Nível de escalabilidade superior**: se você pretende executar o cluster em um nível de escalabilidade superior ao 8XL, entre em contato com a equipe da conta da Amazon Web Services para obter informações adicionais sobre preços.
+ **Suporte a versões e regiões do Kubernetes**: o ambiente de gerenciamento provisionado do EKS é compatível com todas as regiões comerciais da Amazon Web Services, da GovCloud e da China. O ambiente de gerenciamento provisionado é compatível com o EKS na versão 1.28 ou em versões posteriores.
# Conceitos básicos do ambiente de gerenciamento provisionado do Amazon EKS
Este guia apresenta o passo a passo para configurar e usar o ambiente de gerenciamento provisionado do EKS por meio da AWS CLI e do Console de gerenciamento da AWS.
## Pré-requisitos
Antes de começar, verifique se você tem:
+ ** AWS CLI** - Uma ferramenta de linha de comando para trabalhar com os serviços AWS, incluindo o Amazon EKS. Para obter mais informações, consulte [Instalação](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) no *Guia do usuário da AWS Command Line Interface*. Depois de instalar a AWS CLI, recomendamos que você também a configure. Para obter mais informações, consulte [Configuração rápida com o comando “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*. Observe que o AWS CLI v2 é necessário para usar a opção **update-kubeconfig** mostrada nesta página.
+ **Permissões do IAM necessárias**: a entidade principal de segurança do IAM que você está usando deve ter permissões para trabalhar com perfis do IAM do Amazon EKS, perfis vinculadas a serviços, AWS CloudFormation, uma VPC e recursos relacionados. Para obter mais informações, consulte [Ações](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html) e [Uso de perfis vinculados ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) no *Guia do usuário do IAM*. É necessário concluir todas as etapas deste manual como o mesmo usuário. Execute o seguinte comando para verificar o usuário atual:
```
aws sts get-caller-identity
```
**nota**
Convém concluir as etapas neste tópico em um shell Bash. Se não estiver utilizando um shell Bash, alguns comandos de script, como caracteres de continuação de linha e a forma como as variáveis são definidas e utilizadas, exigirão o ajuste do seu shell. Além disso, as regras de citação e de escape do seu shell podem ser diferentes. Para obter mais informações, consulte [Usar de aspas com strings na AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-quoting-strings.html) no *Guia do usuário da AWS Command Line Interface*.
## Ambiente de gerenciamento provisionado do EKS: AWS CLI
### Crie um cluster com o nível de escalabilidade do ambiente de gerenciamento provisionado do EKS
```
aws eks create-cluster --name prod-cluster \
--role-arn arn:aws:iam::012345678910:role/eks-service-role-AWSServiceRoleForAmazonEKS-J7ONKE3BQ4PI \
--resources-vpc-config subnetIds=subnet-6782e71e,subnet-e7e761ac,securityGroupIds=sg-6979fe18 \
--control-plane-scaling-config tier=tier-xl
```
Resposta:
```
{
"cluster": {
"name": "my-eks-cluster",
"arn": "arn:aws:eks:us-east-2:111122223333:cluster/my-eks-cluster",
"createdAt": "2024-03-14T11:31:44.348000-04:00",
"version": "1.26",
"endpoint": "https://JSA79429HJDASKJDJ8223829MNDNASW.yl4.us-east-2.eks.amazonaws.com",
"roleArn": "arn:aws:iam::111122223333:role/eksctl-my-eks-cluster-cluster-ServiceRole-zMF6CBakwwbW",
"resourcesVpcConfig": {
"subnetIds": [
"subnet-0fb75d2d8401716e7",
"subnet-02184492f67a3d0f9",
"subnet-04098063527aab776",
"subnet-0e2907431c9988b72",
"subnet-04ad87f71c6e5ab4d",
"subnet-09d912bb63ef21b9a"
],
"securityGroupIds": [
"sg-0c1327f6270afbb36"
],
"clusterSecurityGroupId": "sg-01c84d09d70f39a7f",
"vpcId": "vpc-0012b8e1cc0abb17d",
"endpointPublicAccess": true,
"endpointPrivateAccess": true,
"publicAccessCidrs": [
"22.19.18.2/32"
]
},
"controlPlaneScalingConfig": {
"tier": "tier-xl"
},
"kubernetesNetworkConfig": {
"serviceIpv4Cidr": "10.100.0.0/16",
"ipFamily": "ipv4"
},
"logging": {
"clusterLogging": [
{
"types": [
"api",
"audit",
"authenticator",
"controllerManager",
"scheduler"
],
"enabled": true
}
]
},
"identity": {
"oidc": {
"issuer": "https://oidc.eks.us-east-2.amazonaws.com/id/JSA79429HJDASKJDJ8223829MNDNASW"
}
},
"status": "CREATING",
"certificateAuthority": {
"data": "CA_DATA_STRING..."
},
"platformVersion": "eks.14",
"tags": {
"aws:cloudformation:stack-name": "eksctl-my-eks-cluster-cluster",
"alpha.eksctl.io/cluster-name": "my-eks-cluster",
"karpenter.sh/discovery": "my-eks-cluster",
"aws:cloudformation:stack-id": "arn:aws:cloudformation:us-east-2:111122223333:stack/eksctl-my-eks-cluster-cluster/e752ea00-e217-11ee-beae-0a9599c8c7ed",
"auto-delete": "no",
"eksctl.cluster.k8s.io/v1alpha1/cluster-name": "my-eks-cluster",
"EKS-Cluster-Name": "my-eks-cluster",
"alpha.eksctl.io/cluster-oidc-enabled": "true",
"aws:cloudformation:logical-id": "ControlPlane",
"alpha.eksctl.io/eksctl-version": "0.173.0-dev+a7ee89342.2024-03-01T03:40:57Z",
"Name": "eksctl-my-eks-cluster-cluster/ControlPlane"
},
"health": {
"issues": []
},
"accessConfig": {
"authenticationMode": "API_AND_CONFIG_MAP"
}
}
}
```
### Visualize o nível de escalabilidade do ambiente de gerenciamento provisionado do cluster
```
aws eks describe-cluster --name prod-cluster
```
Resposta:
```
{
"cluster": {
"name": "my-eks-cluster",
"arn": "arn:aws:eks:us-east-2:111122223333:cluster/my-eks-cluster",
"createdAt": "2024-03-14T11:31:44.348000-04:00",
"version": "1.26",
"endpoint": "https://JSA79429HJDASKJDJ8223829MNDNASW.yl4.us-east-2.eks.amazonaws.com",
"roleArn": "arn:aws:iam::111122223333:role/eksctl-my-eks-cluster-cluster-ServiceRole-zMF6CBakwwbW",
"resourcesVpcConfig": {
"subnetIds": [
"subnet-0fb75d2d8401716e7",
"subnet-02184492f67a3d0f9",
"subnet-04098063527aab776",
"subnet-0e2907431c9988b72",
"subnet-04ad87f71c6e5ab4d",
"subnet-09d912bb63ef21b9a"
],
"securityGroupIds": [
"sg-0c1327f6270afbb36"
],
"clusterSecurityGroupId": "sg-01c84d09d70f39a7f",
"vpcId": "vpc-0012b8e1cc0abb17d",
"endpointPublicAccess": true,
"endpointPrivateAccess": true,
"publicAccessCidrs": [
"22.19.18.2/32"
]
},
"controlPlaneScalingConfig": {
"tier": "tier-xl"
},
"kubernetesNetworkConfig": {
"serviceIpv4Cidr": "10.100.0.0/16",
"ipFamily": "ipv4"
},
"logging": {
"clusterLogging": [
{
"types": [
"api",
"audit",
"authenticator",
"controllerManager",
"scheduler"
],
"enabled": true
}
]
},
"identity": {
"oidc": {
"issuer": "https://oidc.eks.us-east-2.amazonaws.com/id/JSA79429HJDASKJDJ8223829MNDNASW"
}
},
"status": "ACTIVE",
"certificateAuthority": {
"data": "CA_DATA_STRING..."
},
"platformVersion": "eks.14",
"tags": {
"aws:cloudformation:stack-name": "eksctl-my-eks-cluster-cluster",
"alpha.eksctl.io/cluster-name": "my-eks-cluster",
"karpenter.sh/discovery": "my-eks-cluster",
"aws:cloudformation:stack-id": "arn:aws:cloudformation:us-east-2:111122223333:stack/eksctl-my-eks-cluster-cluster/e752ea00-e217-11ee-beae-0a9599c8c7ed",
"auto-delete": "no",
"eksctl.cluster.k8s.io/v1alpha1/cluster-name": "my-eks-cluster",
"EKS-Cluster-Name": "my-eks-cluster",
"alpha.eksctl.io/cluster-oidc-enabled": "true",
"aws:cloudformation:logical-id": "ControlPlane",
"alpha.eksctl.io/eksctl-version": "0.173.0-dev+a7ee89342.2024-03-01T03:40:57Z",
"Name": "eksctl-my-eks-cluster-cluster/ControlPlane"
},
"health": {
"issues": []
},
"accessConfig": {
"authenticationMode": "API_AND_CONFIG_MAP"
}
}
}
```
### Atualize o cluster para usar o ambiente de gerenciamento provisionado do EKS
```
aws eks update-cluster-config --name prod-cluster \
--control-plane-scaling-config tier=tier-2xl
```
Resposta:
```
{
"update": {
"id": "7551c64b-1d27-4b1e-9f8e-c45f056eb6fd",
"status": "InProgress",
"type": "ScalingTierConfigUpdate",
"params": [
{
"type": "UpdatedTier",
"value": "tier-2xl"
},
{
"type": "PreviousTier",
"value": "tier-xl"
}
],
"createdAt": 1565807210.37,
"errors": []
}
}
```
### Visualize a atualização de escalabilidade do ambiente de gerenciamento provisionado
```
aws eks list-updates --name example
```
Resposta:
```
{
"updateIds": [
"7551c64b-1d27-4b1e-9f8e-c45f056eb6fd1"
]
}
```
### Migre do ambiente de gerenciamento provisionado para o ambiente de gerenciamento padrão
```
aws eks update-cluster-config --name prod-cluster \
--control-plane-scaling-config tier=standard
```
Resposta:
```
{
"update": {
"id": "7551c64b-1d27-4b1e-9f8e-c45f056eb6fd",
"status": "InProgress",
"type": "ScalingTierConfigUpdate",
"params": [
{
"type": "UpdatedTier",
"value": "standard"
},
{
"type": "PreviousTier",
"value": "tier-2xl"
}
],
"createdAt": 1565807210.37,
"errors": []
}
}
```
## Ambiente de gerenciamento provisionado do EKS: Console de gerenciamento da AWS
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Selecione **Criar cluster**.
1. Em *Opções de configuração*, selecione **Configuração personalizada**.
1. Role a tela para baixo até o **nível de escalabilidade do ambiente de gerenciamento**. Selecione **Usar um nível de escalabilidade** para habilitar o ambiente de gerenciamento provisionado.
1. Selecione o nível de escalabilidade do ambiente de gerenciamento que você deseja provisionar para o cluster entre as várias opções disponíveis, como XL, 2XL, 4XL e 8XL.
1. Escolha outras opções para a configuração do cluster conforme a necessidade. Na etapa final, selecione **Criar cluster**. Lembre-se de que a criação do cluster pode levar vários minutos para ser concluída.
# Prepare-se para as atualizações da versão e a solução de problemas de configurações incorretas do Kubernetes com insights do cluster
Os insights do cluster do Amazon EKS fornecem detecção de problemas e recomendações para resolvê-los e ajudar você a gerenciar o cluster. Cada cluster do Amazon EKS passa por verificações automáticas e recorrentes em relação a uma lista de insights com curadoria do Amazon EKS. Essas *verificações de insights* são totalmente gerenciadas pelo Amazon EKS e oferecem recomendações sobre como lidar com quaisquer descobertas.
## Tipos de insights de cluster
+ **Insights de configurações**: identificam configurações incorretas na configuração do EKS Hybrid Nodes que podem prejudicar a funcionalidade do cluster ou das workloads.
+ **Insights de atualizações**: identificam problemas que podem afetar a capacidade de atualizar para novas versões do Kubernetes.
## Considerações
+ **Frequência**: o Amazon EKS atualiza os insights do cluster a cada 24 horas, mas você também pode atualizá-los manualmente para ver o status mais recente. Por exemplo, você pode atualizar manualmente os insights do cluster depois de resolver um problema para ver se o problema foi resolvido.
+ **Permissões**: o Amazon EKS cria automaticamente uma entrada de acesso ao cluster para insights de cluster em cada cluster do EKS. Essa entrada dá permissão ao EKS para visualizar as informações sobre o cluster. O Amazon EKS usa essas informações para gerar os insights. Para obter mais informações, consulte [AmazonEKSClusterInsightsPolicy](access-policy-permissions.md#access-policy-permissions-AmazonEKSClusterInsightsPolicy).
## Casos de uso
Os insights de cluster no Amazon EKS fornecem verificações automatizadas para ajudar a manter a integridade, a confiabilidade e a configuração ideal de seus clusters Kubernetes. Abaixo estão os principais casos de uso para insights de cluster, incluindo prontidão para upgrade e solução de problemas de configuração.
### Insights de atualização
Os Insights de atualizações são um tipo específico de verificações de insights nos insights do cluster. Essas verificações retornam insights relacionados à prontidão para a atualização da versão do Kubernetes. O Amazon EKS executa verificações de insights de atualização em cada cluster do EKS.
**Importante**
O Amazon EKS reverteu temporariamente um recurso que exigia que você usasse um sinalizador `--force` para atualizar o cluster quando havia certos problemas de insights do cluster. Para obter mais informações, consulte [Temporary rollback of enforcing upgrade insights on update cluster version](https://github.com/aws/containers-roadmap/issues/2570) no GitHub.
Para obter mais informações sobre como atualizar o cluster, consulte [Etapa 3: atualizar o ambiente de gerenciamento do cluster](update-cluster.md#update-cluster-control-plane).
Antes de atualizar a versão do cluster do Kubernetes, é possível usar a guia **Insights sobre upgrade** do painel de observabilidade no [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). Se seu cluster identificou problemas, revise-os e faça as correções apropriadas. Os problemas incluem links para o Amazon EKS e a documentação do Kubernetes. Depois de corrigir o problema, atualize os insights do cluster sob demanda para obter os insights mais recentes. Se todos os problemas tiverem sido resolvidos, [atualize seu cluster](update-cluster.md).
O Amazon EKS retorna insights relacionados à prontidão para a atualização da versão do Kubernetes. Os insights de atualização identificam possíveis problemas que podem afetar as atualizações do cluster do Kubernetes. Isso minimiza o esforço que os administradores despendem na preparação das atualizações e aumenta a confiabilidade das aplicações nas versões mais recentes do Kubernetes. Os clusters são verificados automaticamente pelo Amazon EKS em relação a uma lista de possíveis problemas que afetam a atualização da versão do Kubernetes. O Amazon EKS atualiza frequentemente a lista de verificações de insights com base nas análises das alterações feitas em cada versão do Kubernetes.
Os insights de atualização do Amazon EKS aceleram o processo de teste e verificação de novas versões. Eles também permitem que administradores de clusters e desenvolvedores de aplicações aproveitem os recursos mais recentes do Kubernetes, destacando os problemas e oferecendo orientações sobre remediação.
### Insights de configuração
Os insights do cluster do EKS verificam automaticamente os clusters do Amazon EKS com nós híbridos para identificar problemas de configuração que prejudicam a comunicação entre webhook e o ambiente de gerenciamento do Kubernetes, os comandos do kubectl como exec e logs e muito mais. Os insights de configurações revelam problemas e fornecem recomendações de correção, acelerando o tempo necessário para uma configuração de nós híbridos totalmente funcionais.
## Conceitos básicos
Para ver a lista de verificações de insights realizadas e quaisquer problemas relevantes identificados pelo Amazon EKS, você usar o Console de gerenciamento da AWS, a AWS CLI, os SDKs da AWS e a operação da API `ListInsights` do Amazon EKS. Para começar, consulte o [Visualizar insights de clusters](view-cluster-insights.md).
# Visualizar insights de clusters
O Amazon EKS fornece dois tipos de insights: **Insights de configurações** e **Insights de atualizações**. Os **Insights de configurações** identificam configurações incorretas na configuração do EKS Hybrid Nodes que podem prejudicar a funcionalidade do cluster ou das workloads. Os **Insights de atualizações** identificam problemas que podem afetar a capacidade de atualizar para novas versões do Kubernetes.
Para ver a lista de verificações de insights realizadas e quaisquer problemas relevantes identificados pelo Amazon EKS, você pode chamar a aparência no Console de gerenciamento da AWS, a AWS CLI, os SDKs da AWS e a operação da API `ListInsights` do Amazon EKS.
## Visualizar insights de configurações (console)
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Na lista Clusters, selecione o nome do cluster de Amazon EK cujos insights deseja visualizar.
1. Escolha **Monitorar cluster**.
1. Escolha a guia **Integridade do cluster**.
1. Na tabela **Insights de configuração**, você verá as colunas a seguir:
+ **Nome**: a verificação que foi realizada pelo Amazon EKS em relação ao cluster.
+ **Status do insight**: um insight com status de `Error` significa que há uma configuração incorreta que provavelmente está afetando a funcionalidade do cluster. Um insight com status de `Warning` significa que a configuração não corresponde à abordagem documentada, mas que a funcionalidade do cluster poderá funcionar se você a tiver configurado intencionalmente. Um insight com status de `Passing` significa que o Amazon EKS não encontrou nenhum problema associado a essa verificação de insights no cluster.
+ **Versão**: a versão aplicável.
+ **Horário da última atualização**: a hora em que o status do insight foi atualizado pela última vez para o cluster.
+ **Descrição**: informações da verificação de insights, que incluem o alerta e as ações recomendadas para remediação.
## Visualizar insights de atualizações (console)
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Na lista Clusters, selecione o nome do cluster de Amazon EK cujos insights deseja visualizar.
1. Escolha **Monitorar cluster**.
1. Escolha a guia **Insights de atualização**.
1. Para visualizar os dados mais recentes, escolha o botão **Atualizar insights** e aguarde a conclusão da atualização.
1. Na tabela **Insights de atualização**, você verá as colunas a seguir:
+ **Nome**: a verificação que foi realizada pelo Amazon EKS em relação ao cluster.
+ **Status do insight**: um insight com status de "Erro" normalmente significa que a versão do Kubernetes afetada é N\$11 da versão atual do cluster, enquanto um status de "Aviso" significa que o insight se aplica a uma versão do Kubernetes futura N\$12 ou mais. Um insight com status de "Aprovado" significa que o Amazon EKS não encontrou nenhum problema associado a essa verificação de insights em seu cluster. Um status de insight de "Desconhecido" significa que o Amazon EKS não consegue determinar se seu cluster é afetado por essa verificação de insights.
+ **Versão**: a versão do Kubernetes que o insight verificou em busca de possíveis problemas.
+ **Horário da última atualização**: a hora em que o status do insight foi atualizado pela última vez para o cluster.
+ **Horário da última transição**: a hora em que o status do insight foi alterado pela última vez.
+ **Descrição**: informações da verificação de insights, que incluem o alerta e as ações recomendadas para remediação.
## Exibir insights do cluster (AWS CLI)
1. Para visualizar os dados mais recentes, atualize os insights de um cluster especificado. Faça as seguintes modificações no comando, conforme necessário, e execute o comando modificado.
+ Substitua *region-code* pelo código da sua região da AWS.
+ Substitua *my-cluster* pelo nome do cluster.
```
aws eks start-insights-refresh --region region-code --cluster-name my-cluster
```
1. Para acompanhar o status de uma atualização de insights, execute o comando a seguir. Substitua *my-cluster* pelo nome do cluster.
```
aws eks describe-insights-refresh --cluster-name my-cluster
```
Veja abaixo um exemplo de saída.
```
{
"message": "Insights refresh is in progress",
"status": "IN_PROGRESS",
"startedAt": "2025-07-30T13:36:09-07:00"
}
```
1. Liste todos os insights de um cluster especificado. Faça as seguintes modificações no comando, conforme necessário, e execute o comando modificado.
+ Substitua *region-code* pelo código da sua região da AWS.
+ Substitua *my-cluster* pelo nome do cluster.
```
aws eks list-insights --region region-code --cluster-name my-cluster
```
Veja abaixo um exemplo de saída.
```
{
"insights":
[
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"name": "Kubelet version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557309.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for kubelet versions of worker nodes in the cluster to see if upgrade would cause non compliance with supported Kubernetes kubelet version skew policy.",
"insightStatus":
{
"status": "UNKNOWN",
"reason": "Unable to determine status of node kubelet versions.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"name": "Cluster health issues",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for any cluster health issues that prevent successful upgrade to the next Kubernetes version on EKS.",
"insightStatus":
{
"status": "PASSING",
"reason": "No cluster health issues detected.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"name": "EKS add-on version compatibility",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks version of installed EKS add-ons to ensure they are compatible with the next version of Kubernetes. ",
"insightStatus": { "status": "PASSING", "reason": "All installed EKS add-on versions are compatible with next Kubernetes version."},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEccccc",
"name": "kube-proxy version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks version of kube-proxy in cluster to see if upgrade would cause non compliance with supported Kubernetes kube-proxy version skew policy.",
"insightStatus":
{
"status": "PASSING",
"reason": "kube-proxy versions match the cluster control plane version.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEddddd",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
],
"nextToken": null,
}
```
1. Para obter informações descritivas sobre um insight, execute o comando a seguir. Faça as seguintes modificações no comando, conforme necessário, e execute o comando modificado.
+ Substitua *region-code* pelo código da sua região da AWS.
+ Substitua *a1b2c3d4-5678-90ab-cdef-EXAMPLE22222* por um ID de insight recuperado da listagem dos insights do cluster.
+ Substitua *my-cluster* pelo nome do cluster.
```
aws eks describe-insight --region region-code --id a1b2c3d4-5678-90ab-cdef-EXAMPLE22222 --cluster-name my-cluster
```
Veja abaixo um exemplo de saída.
```
{
"insight":
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"name": "Kubelet version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "1.27",
"lastRefreshTime": 1734557309.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for kubelet versions of worker nodes in the cluster to see if upgrade would cause non compliance with supported Kubernetes kubelet version skew policy.",
"insightStatus":
{
"status": "UNKNOWN",
"reason": "Unable to determine status of node kubelet versions.",
},
"recommendation": "Upgrade your worker nodes to match the Kubernetes version of your cluster control plane.",
"additionalInfo":
{
"Kubelet version skew policy": "https://kubernetes.io/releases/version-skew-policy/#kubelet",
"Updating a managed node group": "https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html",
},
"resources": [],
"categorySpecificSummary":
{ "deprecationDetails": [], "addonCompatibilityDetails": [] },
},
}
```
# Atualizar um cluster existente para a nova versão do Kubernetes
**dica**
[Registre-se](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) para os próximos workshops do Amazon EKS.
Quando uma nova versão do Kubernetes está disponível no Amazon EKS, você pode atualizar o cluster do Amazon EKS para a versão mais recente.
**Importante**
Depois de atualizar um cluster, não é possível revertê-lo uma versão anterior. Antes de atualizar para uma nova versão do Kubernetes, recomendamos que você analise as informações indicadas em [Entender o ciclo de vida da versão do Kubernetes no EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) e também as etapas de atualização neste tópico.
Novas versões do Kubernetes às vezes introduzem alterações significativas. Assim, recomendamos que você teste o comportamento das aplicações com relação a uma nova versão do Kubernetes antes de atualizar os clusters de produção. É possível fazer isso, criando um fluxo de trabalho de integração contínua para testar o comportamento da aplicação antes de passar para uma nova versão do Kubernetes.
O processo de atualização consiste na execução de novos nós do servidor da API pelo Amazon EKS com a versão do Kubernetes atualizada para substituir as existentes. O Amazon EKS executa verificações padrão de integridade e prontidão da infraestrutura para o tráfego de rede nesses novos nós para confirmar que eles estão funcionando conforme o esperado. Porém, depois que você iniciou a atualização do cluster, não pode pausá-la nem interrompê-la. Se qualquer uma dessas verificações falhar, o Amazon EKS reverterá a implantação de infraestrutura e seu cluster permanecerá na versão do Kubernetes anterior. A execução de aplicações não será afetada e o cluster nunca será deixado em um estado irrecuperável ou não determinista. O Amazon EKS faz backup regularmente de todos os clusters gerenciados, além de ter mecanismos para recuperar clusters, se necessário. Estamos sempre avaliando e melhorando nossos processos de gerenciamento de infraestrutura do Kubernetes.
Para atualizar o cluster, o Amazon EKS requer até cinco endereços IP disponíveis das sub-redes que você especificou ao criar o cluster. O Amazon EKS cria novas interfaces de rede elásticas (interfaces de rede) de cluster em qualquer uma das sub-redes especificadas. Como as interfaces de rede podem ser criadas em sub-redes diferentes das interfaces de rede existentes, certifique-se de que as regras do grupo de segurança permitam a [comunicação de cluster necessária](sec-group-reqs.md) para qualquer uma das sub-redes que você especificou ao criar o cluster. Se alguma das sub-redes que você especificou ao criar o cluster não existir, não tiver endereços IP disponíveis suficientes ou não tiver regras de grupo de segurança que permitam a comunicação necessária do cluster, a atualização poderá falhar.
Para garantir que o endpoint do servidor de API do cluster sempre esteja acessível, o Amazon EKS fornece um ambiente de gerenciamento do Kubernetes com alta disponibilidade e executa atualizações contínuas das instâncias do servidor de API durante as operações de atualização. Para contabilizar a alteração de endereços IP das instâncias do servidor de API compatíveis com o endpoint do servidor de API do Kubernetes, é necessário garantir que seus clientes do servidor de API gerenciem as reconexões de modo eficaz. Versões recentes do `kubectl` e das [bibliotecas](https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api) de cliente do Kubernetes oficialmente compatíveis executam esse processo de reconexão de modo transparente.
**nota**
Para saber mais sobre o que acontece em uma atualização de cluster, consulte [Best Practices for Cluster Upgrades](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html) no Guia de práticas recomendadas do EKS. Esse recurso ajuda você a planejar uma atualização e a entender a estratégia de atualização de um cluster.
## Considerações sobre o Modo automático do Amazon EKS
+ A capacidade computacional do Modo automático do Amazon EKS controla a versão do Kubernetes dos nós. Depois de atualizar o ambiente de gerenciamento, o Modo automático do EKS começará a atualizar incrementalmente os nós gerenciados. O Modo automático do Amazon EKS respeita os orçamentos de interrupção de pods.
+ Você não precisa atualizar manualmente as capacidades do Modo automático do Amazon EKS, incluindo as capacidades de ajuste de escala automático de computação, armazenamento em blocos e balanceamento de carga.
## Resumo
Veja abaixo o resumo de alto nível do processo de atualização do cluster do Amazon EKS:
1. Certifique-se de que seu cluster esteja em um estado que seja compatível com uma atualização. Isso inclui verificar as APIs do Kubernetes usadas pelos recursos implantados no cluster, garantindo que o cluster não tenha qualquer problema de integridade. É necessário usar os insights de atualização do Amazon EKS ao avaliar a prontidão de atualização do cluster.
1. Atualize o ambiente de gerenciamento para a próxima versão secundária (por exemplo, de 1.34 para 1.35).
1. Atualize os nós no plano de dados para que correspondam aos do ambiente de gerenciamento.
1. Atualize todas as aplicações adicionais executadas no cluster (por exemplo, `cluster-autoscaler`).
1. Atualize os complementos fornecidos pelo Amazon EKS, como os incluídos por padrão:
+ [Versão recomendada da CNI da Amazon VPC](managing-vpc-cni.md)
+ [Versão recomendada do CoreDNS](managing-coredns.md)
+ [`kube-proxy` Versão recomendada de](managing-kube-proxy.md)
1. Atualize todos os clientes que se comunicam com o cluster (por exemplo, `kubectl`).
## Etapa 1: preparar-se para o upgrade
Compare a versão do Kubernetes do ambiente de gerenciamento de cluster com a versão do Kubernetes dos seus nós.
+ Obtenha a versão do Kubernetes do ambiente de gerenciamento do cluster.
```
kubectl version
```
+ Obtenha a versão do Kubernetes dos nós. Esse comando retorna todos os nós autogerenciados e gerenciados pelo Amazon EC2, do Fargate e híbridos. Cada pod do Fargate é listado como seu próprio nó.
```
kubectl get nodes
```
Antes de atualizar seu ambiente de gerenciamento para uma nova versão do Kubernetes, certifique-se de que a versão secundária do Kubernetes dos nós gerenciados e dos nós Fargate no seu cluster sejam iguais à versão do seu ambiente de gerenciamento. Por exemplo, se o ambiente de gerenciamento estiver executando a versão `1.29` e um dos nós estiver executando a versão `1.28`, será necessário atualizar os nós para a versão `1.29` antes de atualizar o ambiente de gerenciamento para 1.30. Também recomendamos que você atualize os nós autogerenciados e híbridos para a mesma versão do ambiente de gerenciamento antes de atualizá-lo. Para obter mais informações, consulte [Atualizar um grupo de nós gerenciados para seu cluster](update-managed-node-group.md), [Atualizar nós autogerenciados para seu cluster](update-workers.md) e [Atualizar os nós híbridos do cluster](hybrid-nodes-upgrade.md). Se você tiver nós do Fargate com uma versão secundária inferior à versão do ambiente de gerenciamento, primeiro exclua o pod que é representado pelo nó. Em seguida, atualize seu ambiente de gerenciamento. Todos os pods restantes serão atualizados para a nova versão depois de reimplantados.
## Etapa 2: analisar as considerações sobre o upgrade
Os insights do cluster do Amazon EKS verificam automaticamente os clusters em uma lista de possíveis problemas que afetam a atualização da versão do Kubernetes, como uso de APIs obsoletas do Kubernetes. O Amazon EKS atualiza periodicamente a lista de verificações de insights a serem realizadas com base nas avaliações das alterações no projeto do Kubernetes. O Amazon EKS também atualiza a lista de verificações de insights à medida que ocorrem alterações no serviço do Amazon EKS junto com as novas versões. Para obter mais informações, consulte [Prepare-se para as atualizações da versão e a solução de problemas de configurações incorretas do Kubernetes com insights do cluster](cluster-insights.md).
Analise o [Deprecated API Migration Guide](https://kubernetes.io/docs/reference/using-api/deprecation-guide/) na documentação do Kubernetes.
### Revisão dos insights de atualização
Use os insights de atualização do Amazon EKS para identificar problemas. Para obter mais informações, consulte [Visualizar insights de atualizações (console)](view-cluster-insights.md#view-upgrade-insights-console).
### Considerações detalhadas
+ Como o Amazon EKS executa um ambiente de gerenciamento de alta disponibilidade, você pode atualizar apenas uma versão secundária por vez. Para saber mais sobre esse requisito, consulte [Política de suporte da distorção da versão e da versão do Kubernetes](https://kubernetes.io/docs/setup/version-skew-policy/#kube-apiserver). Suponha que a versão atual do cluster seja a `1.28` e você queira atualizar para a versão `1.30`. É necessário primeiro atualizar o cluster versão `1.28` para versão `1.29` e depois atualizar o cluster versão `1.29` para a versão `1.30`.
+ Analise a distorção da versão entre o `kube-apiserver` do Kubernetes e o `kubelet` nos nós.
+ Com a versão `1.28` do Kubernetes e mais recentes, o `kubelet` pode ter até três versões secundárias anteriores ao do `kube-apiserver`. Consulte a [política de distorção de versão upstream do Kubernetes](https://kubernetes.io/releases/version-skew-policy/#kubelet).
+ Se o `kubelet` em seus nós gerenciados e do Fargate estiver na versão `1.25` ou mais recente do Kubernetes, será possível atualizar o cluster para até três versões à frente sem atualizar a versão do `kubelet`. Por exemplo, se a versão `1.25` do `kubelet` estiver ativa, será possível atualizar a versão do cluster do Amazon EKS de `1.25` para `1.26` e de `1.27` para `1.28`, enquanto o `kubelet` estiver na versão `1.25`.
+ Como prática recomendada, antes de iniciar uma atualização, verifique se o `kubelet` nos nós está na mesma versão do Kubernetes que a do seu ambiente de gerenciamento.
+ Se o cluster estiver configurado com uma versão do plug-in CNI da Amazon VPC para Kubernetes anterior à versão `1.8.0`, recomendamos atualizar o plug-in para a versão mais recente recomendada antes de atualizar o cluster. Para atualizar o plug-in, consulte [Atribuir IPs a pods com a CNI da Amazon VPC](managing-vpc-cni.md).
+ É possível fazer um backup do seu cluster do Amazon EKS para permitir a restauração do estado do cluster e do armazenamento persistente em caso de falhas durante o processo de atualização. Consulte [Backup dos clusters do EKS com o AWS Backup](integration-backup.md)
## Etapa 3: atualizar o ambiente de gerenciamento do cluster
**Importante**
O Amazon EKS reverteu temporariamente um recurso que exigia que você usasse um sinalizador `--force` para atualizar o cluster quando havia certos problemas de insights do cluster. Para obter mais informações, consulte [Temporary rollback of enforcing upgrade insights on update cluster version](https://github.com/aws/containers-roadmap/issues/2570) no GitHub.
O Amazon EKS atualiza um insight de cluster 24 horas após o "horário da última atualização". É possível comparar a hora em que resolveu um problema com a "hora da última atualização" do insight do cluster.
Além disso, pode levar até 30 dias para que o status do insight seja atualizado após resolver a questão do uso da API obsoleta. O insights de atualização sempre busca o uso de APIs obsoletas em um período contínuo de 30 dias.
É possível enviar a solicitação de atualização da versão do ambiente de gerenciamento do EKS usando:
+ [eksctl](#step3-eksctl)
+ [o console da AWS](#step3-console)
+ [a AWS CLI](#step3-cli)
### Atualizar o cluster: eksctl
Este procedimento exige a versão `eksctl` `0.215.0` ou superior. É possível verificar a versão com o seguinte comando:
```
eksctl version
```
Para obter instruções sobre como instalar e atualizar o `eksctl`, consulte [Instalação](https://eksctl.io/installation) na documentação do `eksctl`.
Atualize a versão do Kubernetes do ambiente de gerenciamento do Amazon EKS. Substitua `` pelo nome do cluster. Substitua `` pelo número da versão compatível com o Amazon EKS para a qual você deseja atualizar o cluster. Para obter a lista de números das versões compatíveis, consulte as [versões compatíveis com o Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
```
eksctl upgrade cluster --name --version --approve
```
O processo pode demorar alguns minutos para ser concluído.
Avance para [Etapa 4: atualizar componentes do cluster](#step4).
### Atualizar o cluster: console da AWS
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Escolha **Atualizar agora** para um cluster que você deseja atualizar.
1. Selecione a versão para a qual o cluster será atualizado e escolha **Atualizar**.
1. O processo pode demorar alguns minutos para ser concluído. Avance para [Etapa 4: atualizar componentes do cluster](#step4).
### Atualizar o cluster: AWS CLI
1. Verifique se a AWS CLI está instalada e se você se conectou. Para obter mais informações, consulte [Instalar ou atualizar a versão mais recente da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Atualize seu cluster do Amazon EKS com o seguinte comando da AWS CLI. Substitua `` e `` do cluster que você deseja atualizar. Substitua `` pelo número da versão compatível com o Amazon EKS para a qual você deseja atualizar o cluster. Para obter a lista de números das versões compatíveis, consulte as [versões compatíveis com o Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
```
aws eks update-cluster-version --name \
--kubernetes-version --region
```
Veja abaixo um exemplo de saída.
```
{
"update": {
"id": "",
"status": "InProgress",
"type": "VersionUpdate",
"params": [
{
"type": "Version",
"value": ""
},
{
"type": "PlatformVersion",
"value": "eks.1"
}
],
[...]
"errors": []
}
```
1. O processo pode demorar alguns minutos para ser concluído. Monitore o status do cluster com o comando a seguir. Além de usar o mesmo `` e ``, use o `` que o comando anterior retornou.
```
aws eks describe-update --name \
--region --update-id
```
Quando um status de `Successful` for exibido, significa que a atualização está concluída.
1. Avance para [Etapa 4: atualizar componentes do cluster](#step4).
## Etapa 4: atualizar componentes do cluster
1. Depois que a atualização do cluster for concluída, atualize os nós para a mesma versão secundária do Kubernetes do cluster atualizado. Para obter mais informações, consulte [Atualizar nós autogerenciados para seu cluster](update-workers.md), [Atualizar um grupo de nós gerenciados para seu cluster](update-managed-node-group.md) e [Atualizar os nós híbridos do cluster](hybrid-nodes-upgrade.md). Quaisquer novos pods iniciados no Fargate têm uma versão do `kubelet` que corresponde à versão do cluster. Os pods existentes do Fargate não são alterados.
1. (Opcional) Se você implantou o Kubernetes Cluster Autoscaler no cluster antes de atualizá-lo, atualize o Cluster Autoscaler para a versão mais recente que corresponde à versão principal e secundária do Kubernetes para a qual você atualizou.
1. Abra a página de [versões](https://github.com/kubernetes/autoscaler/releases) do Cluster Autoscaler em um navegador da web e encontre a versão mais recente do Cluster Autoscaler que corresponda às versões principal e secundária do Kubernetes do seu cluster. Por exemplo, se a versão do Kubernetes do cluster for `1.30`, localize a versão mais recente do Cluster Autoscaler que começa com `1.30`. Registre o número de versão semântico (`1.30.n`, por exemplo) dessa versão para usar na próxima etapa.
1. Defina a tag de imagem do Cluster Autoscaler como a versão que você registrou na etapa anterior com o comando a seguir. Se necessário, substitua `X.XX.X` pelo seu próprio valor.
```
kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=registry.k8s.io/autoscaling/cluster-autoscaler:vX.XX.X
```
1. (Somente clusters com nós de GPU) Se o cluster tiver grupos de nós compatíveis com GPU (por exemplo, `p3.2xlarge`), será necessário atualizar o [plug-in de dispositivo NVIDIA para Kubernetes](https://github.com/NVIDIA/k8s-device-plugin)DaemonSet no seu cluster. Substitua `` pela versão desejada de [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin/releases) antes de executar o comando a seguir.
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin//deployments/static/nvidia-device-plugin.yml
```
1. Atualize o plug-in CNI da Amazon VPC para Kubernetes, o CoreDNS e os complementos `kube-proxy`. Recomendamos atualizar os complementos para as versões mínimas listadas nos [tokens da conta de serviço](service-accounts.md#boundserviceaccounttoken-validated-add-on-versions).
+ Se estiver usando complementos do Amazon EKS, selecione **Clusters** no console do Amazon EKS e, em seguida, o nome do cluster que você atualizou no painel de navegação esquerdo. As notificações serão exibidas no console. Elas informam que uma nova versão está disponível para cada complemento que tenha uma atualização disponível. Para atualizar um complemento, selecione a guia **Complementos**. Em uma das caixas de um complemento que tenha uma atualização disponível, selecione **Atualizar agora**, depois, uma versão disponível e, em seguida, selecione **Atualizar**.
+ Como alternativa, você pode usar a AWS CLI ou o `eksctl` para atualizar os complementos. Para obter mais informações, consulte [Atualizar um complemento do Amazon EKS](updating-an-add-on.md).
1. Se necessário, atualize a versão do `kubectl`. É necessário usar uma versão do `kubectl` que esteja em uma versão secundária de diferença do ambiente de gerenciamento do cluster do Amazon EKS.
## Fazer o downgrade da versão do Kubernetes de um cluster do Amazon EKS
Não é possível fazer o downgrade do Kubernetes de um cluster do Amazon EKS. Em vez disso, crie um novo cluster em uma versão anterior do Amazon EKS e migre as workloads.
# Excluir um cluster
Quando terminar de usar um cluster do Amazon EKS, será necessário excluir os recursos associados a ele para não causar custos desnecessários.
É possível excluir um cluster com `eksctl`, Console de gerenciamento da AWS ou AWS CLI.
## Considerações
+ Se receber um erro porque o criador do cluster foi removido, consulte [este artigo](https://aws.amazon.com/premiumsupport/knowledge-center/eks-api-server-unauthorized-error) para resolvê-lo.
+ Os recursos do Amazon Managed Service for Prometheus estão fora do ciclo de vida do cluster e precisam ser mantidos separados do cluster. Ao excluir seu cluster, certifique-se de excluir também todos os extratores relevantes para interromper os custos aplicáveis. Para obter mais informações, consulte [Encontrar e excluir extratores](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-list-delete) no *Guia do usuário do Amazon Managed Service for Prometheus*.
+ Para remover um cluster conectado, consulte [Cancelar o registro de um cluster do Kubernetes no console do Amazon EKS](deregister-connected-cluster.md)
+ Antes de excluir um cluster, verifique se a proteção contra exclusão está desabilitada.
### Considerações para o Modo Automático do EKS
+ Todos os nós do Modo Automático do EKS serão excluídos, incluindo as instâncias gerenciadas pelo EC2
+ Todos os balanceadores de carga serão excluídos
Para obter mais informações, consulte [Desabilitar o Modo Automático do EKS](auto-disable.md).
## Etapas de pré-requisitos
Veja a seguir as etapas que devem ser executadas primeiro para poder excluir um cluster. Essas etapas se aplicam independentemente do método usado para excluir o cluster.
1. Liste todos os serviços em execução no cluster.
```
kubectl get svc --all-namespaces
```
1. Exclua todos os serviços que têm um valor `EXTERNAL-IP` associado. Esses serviços são liderados por um balanceador de carga do Elastic Load Balancing, e será necessário excluí-los no Kubernetes para permitir que o balanceador de carga e os recursos associados sejam liberados corretamente. Substitua *service-name* pelo nome de cada serviço listado, conforme descrito.
```
kubectl delete svc service-name
```
1. Exclua também quaisquer recursos de entrada. Se você não excluir os recursos de entrada, o application load balancer permanecerá, mesmo se você excluir o cluster. Substitua *ingress-name* pelo nome dos seus recursos de entrada.
```
kubectl get ingress --all-namespaces
```
```
kubectl delete ing ingress-name
```
## Excluir cluster (eksctl)
Este procedimento exige a versão `eksctl` `0.215.0` ou superior. É possível verificar a versão com o seguinte comando:
```
eksctl version
```
Para obter instruções sobre como instalar ou atualizar o `eksctl`, consulte [Instalação](https://eksctl.io/installation) na documentação do `eksctl`.
1. Siga as [etapas de pré-requisito](#prerequisite-steps). Depois de fazer isso, exclua seu cluster e seus nós associados com o comando a seguir, substituindo *prod* pelo nome do seu cluster.
```
eksctl delete cluster --name prod
```
Resultado:
```
[ℹ] using region region-code
[ℹ] deleting EKS cluster "prod"
[ℹ] will delete stack "eksctl-prod-nodegroup-standard-nodes"
[ℹ] waiting for stack "eksctl-prod-nodegroup-standard-nodes" to get deleted
[ℹ] will delete stack "eksctl-prod-cluster"
[✔] the following EKS cluster resource(s) for "prod" will be deleted: cluster. If in doubt, check CloudFormation console
```
## Excluir cluster (console do AWS)
1. Siga as [etapas de pré-requisito](#prerequisite-steps). Depois de fazer isso, exclua todos os grupos de nós e perfis do Fargate.
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. No painel de navegação à esquerda, escolha **Clusters** do Amazon EKS e, em seguida, na lista de clusters com guias, escolha o nome do cluster que você deseja excluir.
1. Escolha a guia **Compute** (Computação) e escolha um grupo de nós para exclusão. Escolha **Delete** (Excluir), insira o nome do grupo de nós e depois escolha **Delete** (Excluir). Exclua todos os grupos de nós no cluster.
**nota**
Os grupos de nós listados são somente [grupos de nós gerenciados](managed-node-groups.md) .
1. Escolha um **perfil do Fargate** para excluir, selecione **Delete** (Excluir), insira o nome do perfil e selecione **Delete** (Excluir). Exclua todos os perfis do Fargate no cluster.
1. Exclua todas as [pilhas do AWS CloudFormation de nós autogerenciados](https://docs.aws.amazon.com/eks/latest/userguide/worker).
1. Abra o console do [AWS CloudFormation](https://console.aws.amazon.com/cloudformation/).
1. Escolha a pilha de nós a ser excluída e, então, escolha **Delete** (Excluir).
1. Na caixa de diálogo de confirmação **Delete stack** (Excluir pilha), escolha **Delete stack** (Excluir pilha). Exclua todas as pilhas de nós autogerenciados do cluster.
1. Excluir o cluster.
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. escolha o cluster a ser excluído e escolha **Delete** (Excluir).
1. Na tela de confirmação de excluir cluster, selecione **Delete (Excluir)**.
1. (Opcional) Exclua a pilha do VPC AWS CloudFormation.
1. Abra o console do [AWS CloudFormation](https://console.aws.amazon.com/cloudformation/).
1. Selecione a pilha da VPC a ser excluída e, então, escolha **Delete** (Excluir).
1. Na caixa de diálogo de confirmação **Delete stack** (Excluir pilha), escolha **Delete stack** (Excluir pilha).
## Excluir cluster (AWS CLI)
1. Siga as [etapas de pré-requisito](#prerequisite-steps). Depois de fazer isso, exclua todos os grupos de nós e perfis do Fargate.
1. Liste os grupos de nós no cluster com o comando a seguir.
```
aws eks list-nodegroups --cluster-name my-cluster
```
**nota**
Os grupos de nós listados são somente [grupos de nós gerenciados](managed-node-groups.md) .
1. Exclua cada grupo de nós com o comando a seguir. Exclua todos os grupos de nós no cluster.
```
aws eks delete-nodegroup --nodegroup-name my-nodegroup --cluster-name my-cluster
```
1. Liste os perfis do Fargate no cluster com o comando a seguir.
```
aws eks list-fargate-profiles --cluster-name my-cluster
```
1. Exclua cada perfil do Fargate com o comando a seguir. Exclua todos os perfis do Fargate no cluster.
```
aws eks delete-fargate-profile --fargate-profile-name my-fargate-profile --cluster-name my-cluster
```
1. Exclua todas as [pilhas do AWS CloudFormation de nós autogerenciados](https://docs.aws.amazon.com/eks/latest/userguide/worker).
1. Liste suas pilhas disponíveis no AWS CloudFormation com o seguinte comando. Encontre o nome do modelo do nó no resultado.
```
aws cloudformation list-stacks --query "StackSummaries[].StackName"
```
1. Exclua a pilha de nós com o comando a seguir, substituindo *node-stack* pelo nome da sua pilha de nós. Exclua todas as pilhas de nós autogerenciados do cluster.
```
aws cloudformation delete-stack --stack-name node-stack
```
1. Exclua o cluster com o comando a seguir, substituindo *my-cluster* pelo nome do cluster.
```
aws eks delete-cluster --name my-cluster
```
1. (Opcional) Exclua a pilha do VPC AWS CloudFormation.
1. Liste suas pilhas disponíveis no AWS CloudFormation com o seguinte comando. Encontre o nome do modelo da VPC na saída resultante.
```
aws cloudformation list-stacks --query "StackSummaries[].StackName"
```
1. Exclua a pilha da VPC com o comando a seguir, substituindo *my-vpc-stack* pelo nome da pilha da VPC.
```
aws cloudformation delete-stack --stack-name my-vpc-stack
```
# Proteção dos clusters do EKS contra exclusão acidental
A exclusão acidental de um cluster do EKS pode prejudicar as operações do cluster do Kubernetes.
Agora é possível proteger clusters do EKS contra exclusão acidental. Se você habilitar a proteção contra exclusão em um cluster, primeiro será necessário desabilitar a proteção contra exclusão antes de poder excluir o cluster.
O objetivo da proteção contra exclusão é o de evitar acidentes. Você deve restringir cuidadosamente quem está autorizado a excluir clusters.
Se você tentar excluir um cluster ativo com a proteção de exclusão ativada, você receberá uma `InvalidRequestException`.
**Importante**
Se você habilitar a proteção contra exclusão em um cluster, deverá ter **ambas** as permissões do IAM UpdateClusterConfig e DeleteCluster para primeiramente remover a proteção contra exclusão e, finalmente, excluir o cluster.
**nota**
Se o estado do cluster for criando, falhando ou excluindo, será possível excluir o cluster mesmo se a proteção contra exclusão estiver ativada.
## Para habilitar a proteção contra exclusão para um cluster existente
Você só pode executar isso em um cluster no status ativo.
```
aws eks update-cluster-config --name --region --deletion-protection
```
## Para desabilitar a proteção contra exclusão para um cluster existente
```
aws eks update-cluster-config --name --region --no-deletion-protection
```
# Endpoint do servidor de API do cluster
Este tópico ajuda a habilitar o acesso privado ao endpoint do servidor de API do Kubernetes do cluster do Amazon EKS e limitar ou desabilitar completamente o acesso público pela internet.
Quando você cria um cluster, o Amazon EKS cria um endpoint para o servidor gerenciado de API do Kubernetes usado para se comunicar com o cluster (usando as ferramentas de gerenciamento do Kubernetes, como `kubectl`). Por padrão, esse endpoint do servidor de API é público para a internet, e o acesso ao servidor de API é protegido usando uma combinação do AWS Identity and Access Management (IAM) e do [Role Based Access Control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) nativo do Kubernetes. Esse endpoint é conhecido como o *endpoint de cluster público*. Também há um *endpoint de cluster privado*. Para obter mais informações sobre o endpoint privado do cluster, consulte a seção apresentada a seguir [Endpoint privado do cluster](#cluster-endpoint-private).
## Formato de endpoint de cluster `IPv6`
O EKS cria um endpoint exclusivo de pilha dupla no seguinte formato para novos clusters `IPv6` criados após outubro de 2024. Um *cluster IPv6* é um cluster que você seleciona `IPv6` na configuração da família de IP (`ipFamily`) do cluster.
**Example**
Endpoint público/privado do cluster do EKS: `eks-cluster.region.api.aws`
Endpoint público/privado do cluster do EKS: `eks-cluster.region.api.aws`
Endpoint público/privado do cluster do EKS: `eks-cluster---region---api.amazonwebservices.com.rproxy.goskope.com.cn`
**nota**
O endpoint de cluster de pilha dupla foi introduzido em outubro de 2024. Para obter mais informações sobre clusters `IPv6`, consulte [Saiba mais sobre endereços IPv6 para clusters, pods e serviços](cni-ipv6.md). Clusters criados antes de outubro de 2024 devem usar o seguinte formato de endpoint.
## Formato de endpoint de cluster `IPv4`
O EKS cria um endpoint exclusivo no formato a seguir para cada cluster que seleciona `IPv4` na configuração da família de IP (ipFamily) do cluster:
**Example**
Endpoint público/privado do cluster EKS `eks-cluster.region.eks.amazonaws.com`
Endpoint público/privado do cluster EKS `eks-cluster.region.eks.amazonaws.com`
Endpoint público/privado do cluster EKS `eks-cluster---region.amazonwebservices.com.rproxy.goskope.com.cn`
**nota**
Antes de outubro de 2024, os clusters `IPv6` também usavam esse formato de endpoint. Para eles, tanto o endpoint público quanto o privado têm apenas endereços `IPv4` resolvidos a partir desse endpoint.
## Endpoint privado do cluster
Você pode habilitar o acesso privado ao servidor de API do Kubernetes para que todas as comunicações entre os nós e o servidor de API fiquem na VPC. Você pode limitar os endereços IP que podem acessar o servidor de API pela Internet ou desativar completamente o acesso à Internet para o servidor de API.
**nota**
Como esse endpoint é para o servidor de API do Kubernetes e não um endpoint tradicional do AWS PrivateLink para se comunicar com uma API da AWS, ele não aparece como um endpoint no console da Amazon VPC.
Ao ativar o acesso privado ao endpoint para o cluster, o Amazon EKS cria uma zona hospedada privada do Route 53 em seu nome e a associa à VPC do cluster. Essa zona hospedada privada é gerenciada pelo Amazon EKS e não aparece nos recursos do Route 53 da sua conta. Para que a zona hospedada privada roteie o tráfego adequadamente para o seu servidor da API, a VPC deve ter `enableDnsHostnames` e `enableDnsSupport` definidos como `true`, e o conjunto de opções DHCP para sua VPC deve incluir `AmazonProvidedDNS` na lista de servidores de nome de domínio. Para obter mais informações, consulte [Updating DNS support for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) (Atualizar o suporte de DNS para VPC) no *Manual do usuário da Amazon VPC*.
É possível definir os requisitos de acesso ao endpoint do servidor de API ao criar um cluster, e você pode atualizar o acesso ao endpoint do servidor de API para um cluster a qualquer momento.
## Modificar o acesso ao endpoint do cluster
Use os procedimentos desta seção para modificar o acesso ao endpoint para um cluster existente. A tabela a seguir mostra as combinações compatíveis de acesso ao endpoint do servidor de API e seus comportamentos associados.
| Acesso público ao endpoint | Acesso privado ao endpoint | Comportamento |
| --- | --- | --- |
| Habilitado | Desabilitado | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/cluster-endpoint.html) |
| Habilitado | Habilitado | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/cluster-endpoint.html) |
| Desabilitado | Habilitado | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/cluster-endpoint.html) |
**Controles de acesso ao endpoint**
Lembre-se de que cada um dos métodos apresentados a seguir para controle de acesso ao endpoint afeta somente o respectivo endpoint.
*Security group de cluster*
O grupo de segurança do cluster controla dois tipos de conexões, as conexões com a *API do kubelet* e o endpoint privado. As conexões com a API do `kubelet` são usadas nos comandos `kubectl attach`, `kubectl cp`, `kubectl exec`, `kubectl logs` e `kubectl port-forward`. O grupo de segurança do cluster não tem impacto sobre o endpoint público.
*Blocos CIDR de acesso público*
Os *CIDRs de acesso público* controlam o acesso ao endpoint público por meio de uma lista de blocos CIDR. Lembre-se de que os blocos CIDR de acesso público não têm impacto no endpoint privado. Os CIDRs de acesso público comportam-se de forma diferente nos clusters `IPv6` e clusters `IPv4`, dependendo da data em que foram criados, conforme descrito a seguir:
**Blocos CIDR no endpoint público (cluster `IPv6`)**
Você pode adicionar blocos CIDR `IPv6` e `IPv4` ao endpoint público de um cluster `IPv6`, porque o endpoint público é de pilha dupla. Isso só se aplica a novos clusters com o `ipFamily` definido como `IPv6` que você criou em outubro de 2024 ou posteriormente. Você pode identificar esses clusters pelo novo nome de domínio do endpoint `api.aws`.
**Blocos CIDR no endpoint público (cluster `IPv4`)**
Você pode adicionar blocos CIDR `IPv4` ao endpoint público de um cluster `IPv4`. Você não pode adicionar blocos CIDR `IPv6` ao endpoint público de um cluster `IPv4`. Se você tentar, o EKS retornará a seguinte mensagem de erro: `The following CIDRs are invalid in publicAccessCidrs`
**Blocos CIDR no endpoint público (cluster `IPv6` criado antes de outubro de 2024)**
Você pode adicionar blocos CIDR `IPv4` ao endpoint público dos clusters `IPv6` antigos que você criou antes de outubro de 2024. Você pode identificar esses clusters pelo endpoint `eks.amazonaws.com`. Você não pode adicionar blocos CIDR `IPv6` ao endpoint público desses clusters `IPv6` antigos que você criou antes de outubro de 2024. Se você tentar, o EKS retornará a seguinte mensagem de erro: `The following CIDRs are invalid in publicAccessCidrs`
## Acessar um servidor de API somente privado
Se tiver desabilitado o acesso público do endpoint do servidor de API do Kubernetes do cluster, você só poderá acessar o servidor de API pela VPC ou por uma [rede conectada](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html). Veja a seguir algumas maneiras possíveis de acessar o endpoint do servidor de API do Kubernetes:
**Rede conectada**
Conecte a sua rede à VPC com um [gateway de trânsito da AWS](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) ou outra opção de [conectividade](https://docs.aws.amazon.com/aws-technical-content/latest/aws-vpc-connectivity-options/introduction.html) e depois use um computador na rede conectada. É necessário garantir que o grupo de segurança do plano de controle do Amazon EKS tenha regras para permitir o tráfego de entrada na porta 443 da rede conectada.
**Bastion host do Amazon EC2**
Você pode executar uma instância do Amazon EC2 em uma sub-rede pública na VPC do cluster e fazer login via SSH nessa instância para executar os comandos do `kubectl`. Para obter mais informações, consulte [Bastion hosts do Linux na AWS](https://aws.amazon.com/quickstart/architecture/linux-bastion/). É necessário garantir que o grupo de segurança do plano de controle do Amazon EKS tenha regras para permitir o tráfego de entrada na porta 443 do seu bastion host. Para obter mais informações, consulte [Exibir os requisitos para grupos de segurança do Amazon EKS em clusters](sec-group-reqs.md).
Quando você configurar `kubectl` para o bastion host, use credenciais da AWS que já estiverem mapeadas para a configuração do RBAC do cluster ou adicione a [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que o bastion usará para a configuração do RBAC antes de remover o acesso público ao endpoint. Para obter mais informações, consulte [Conceder aos usuários e perfis do IAM acesso às APIs do Kubernetes](grant-k8s-access.md) e [Acesso negado ou não autorizado (`kubectl`)](troubleshooting.md#unauthorized).
**IDE do AWS Cloud9**
AWS O Cloud9 é um ambiente de desenvolvimento integrado (IDE) baseado em nuvem que permite que você escreva, execute e depure seu código com apenas um navegador. Você pode criar um IDE do AWS Cloud9 na VPC do seu cluster e usar o IDE para se comunicar com o cluster. Para obter mais informações, consulte [Criação de um ambiente em AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/create-environment.html). É necessário garantir que o grupo de segurança do plano de controle do Amazon EKS contenha regras para permitir o tráfego de entrada na porta 443 do seu grupo de segurança IDE. Para obter mais informações, consulte [Exibir os requisitos para grupos de segurança do Amazon EKS em clusters](sec-group-reqs.md).
Quando você configurar o `kubectl` para o seu AWS Cloud9 IDE, certifique-se de usar as credenciais do AWS que já estão mapeadas na configuração RBAC do cluster ou adicione a entidade principal do IAM que o IDE usará à configuração RBAC antes de remover o acesso público ao endpoint. Para obter mais informações, consulte [Conceder aos usuários e perfis do IAM acesso às APIs do Kubernetes](grant-k8s-access.md) e [Acesso negado ou não autorizado (`kubectl`)](troubleshooting.md#unauthorized).
📝 [Editar esta página no GitHub](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23cluster-endpoint%5D&type=code)
# Configurar o acesso à rede para o endpoint do servidor de API do cluster
Você pode modificar o acesso ao endpoint do servidor de API do cluster usando o Console de gerenciamento da AWS ou a AWS CLI nas seções a seguir.
## Configure o acesso ao endpoint - AWS console
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Selecione o nome do cluster para exibir as informações dele.
1. Escolha a guia **Redes** e depois **Gerenciar acesso do endpoint**.
1. Em **Acesso privado**: escolha se deseja habilitar ou desabilitar o acesso privado para o endpoint do servidor de API do Kubernetes do cluster. Se você habilitar o acesso privado, as solicitações de API do Kubernetes originadas na VPC do cluster usarão o endpoint da VPC privado. É necessário habilitar o acesso privado para desabilitar o acesso público.
1. Em **Acesso público**: escolha se deseja habilitar ou desabilitar o acesso público para o endpoint do servidor de API do Kubernetes do cluster. Se você desabilitar o acesso público, o servidor de API do Kubernetes do cluster só poderá receber solicitações da VPC do cluster.
1. (Opcional) Se você habilitou o **Acesso público**, poderá especificar quais endereços da Internet podem se comunicar com o endpoint público. Selecione **Advanced Settings (Configurações avançadas)**. Insira um bloco CIDR, como *203.0.113.5/32*. O bloco não pode incluir [endereços reservados](https://en.wikipedia.org/wiki/Reserved_IP_addresses). É possível inserir blocos adicionais selecionando **Add Source (Adicionar origem)**. Há um número máximo de blocos CIDR que você pode especificar. Para obter mais informações, consulte [Visualizar e gerenciar as cotas de serviço do Amazon EKS e do Fargate](service-quotas.md). Se você não especificar nenhum bloco, então o endpoint do servidor de API público receberá solicitações de todos os endereços IP tanto para `IPv4` (`0.0.0.0/0`) como para `IPv6` (`::/0`) para o cluster `IPv6` de pilha dupla. Se você restringir o acesso ao endpoint público usando blocos CIDR, recomendamos habilitar também o acesso ao endpoint privado para que os nós e os Pods do Fargate (se você usá-los) possam se comunicar com o cluster. Sem o endpoint privado habilitado, suas origens CIDR de endpoint de acesso público devem incluir as origens de saída de sua VPC. Por exemplo, se você tiver um nó em uma sub-rede privada que se comunica com a Internet por meio de um gateway NAT, será necessário adicionar o endereço IP de saída do gateway NAT como parte de um bloco CIDR na lista de permissões no endpoint público.
1. Selecione **Update (Atualizar)** para concluir.
## Configurar o acesso ao endpoint - AWS CLI
Conclua as etapas a seguir usando a versão AWS CLI `1.27.160` ou posterior. É possível verificar sua versão atual com `aws --version`. Para instalar ou atualizar a AWS CLI, consulte [Instalar a AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html).
1. Atualize o acesso ao endpoint do servidor de API do cluster com o seguinte comando da CLI AWS. Substitua o nome do cluster e os valores desejados de acesso ao endpoint. Se você definir `endpointPublicAccess=true`, também poderá inserir um único bloco CIDR ou uma lista de blocos CIDR separados por vírgulas para `publicAccessCidrs`. Os blocos não podem incluir [endereços reservados](https://en.wikipedia.org/wiki/Reserved_IP_addresses). Se você especificar blocos CIDR, o endpoint do servidor de API público só receberá solicitações dos blocos listados. Há um número máximo de blocos CIDR que você pode especificar. Para obter mais informações, consulte [Visualizar e gerenciar as cotas de serviço do Amazon EKS e do Fargate](service-quotas.md). Se você restringir o acesso ao endpoint público usando blocos CIDR, é recomendável habilitar também o acesso ao endpoint privado para que os nós e os Pods do Fargate (se você usá-los) possam se comunicar com o cluster. Sem o endpoint privado habilitado, suas origens CIDR de endpoint de acesso público devem incluir as origens de saída de sua VPC. Por exemplo, se você tiver um nó em uma sub-rede privada que se comunica com a Internet por meio de um gateway NAT, será necessário adicionar o endereço IP de saída do gateway NAT como parte de um bloco CIDR na lista de permissões no endpoint público. Se você não especificar nenhum bloco CIDR, então o endpoint do servidor de API público receberá solicitações de todos os endereços IP (0.0.0.0/0) e do `IPv6` (`::/0`) para o cluster `IPv6` de pilha dupla.
**nota**
O comando a seguir permite acesso privado e acesso público a partir de um único endereço IP para o endpoint do servidor de API. Substitua *203.0.113.5/32* por um único bloco CIDR ou uma lista de blocos CIDR separados por vírgulas aos quais você deseja restringir o acesso à rede.
```
aws eks update-cluster-config \
--region region-code \
--name my-cluster \
--resources-vpc-config endpointPublicAccess=true,publicAccessCidrs="203.0.113.5/32",endpointPrivateAccess=true
```
Veja abaixo um exemplo de saída.
```
{
"update": {
"id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000",
"status": "InProgress",
"type": "EndpointAccessUpdate",
"params": [
{
"type": "EndpointPublicAccess",
"value": "true"
},
{
"type": "EndpointPrivateAccess",
"value": "true"
},
{
"type": "publicAccessCidrs",
"value": "[\"203.0.113.5/32\"]"
}
],
"createdAt": 1576874258.137,
"errors": []
}
}
```
1. Monitore o status da atualização do acesso ao endpoint com o comando a seguir, usando o nome do cluster e o ID da atualização retornado pelo comando anterior. Sua atualização estará concluída quando o status for exibido como `Successful`.
```
aws eks describe-update \
--region region-code \
--name my-cluster \
--update-id e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000
```
Veja abaixo um exemplo de saída.
```
{
"update": {
"id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000",
"status": "Successful",
"type": "EndpointAccessUpdate",
"params": [
{
"type": "EndpointPublicAccess",
"value": "true"
},
{
"type": "EndpointPrivateAccess",
"value": "true"
},
{
"type": "publicAccessCidrs",
"value": "[\"203.0.113.5/32\"]"
}
],
"createdAt": 1576874258.137,
"errors": []
}
}
```
📝 [Editar esta página no GitHub](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23config-cluster-endpoint%5D&type=code)
# Implantar nós Windows em clusters EKS
Saiba como habilitar e gerenciar o suporte do Windows para o cluster do Amazon EKS para executar contêineres do Windows junto com contêineres do Linux.
## Considerações
Antes de implantar nós do Windows, esteja ciente das seguintes considerações:
+ O Modo Automático do EKS não é compatível com nós do Windows
+ É possível usar rede de hosts nos nós do Windows usando `HostProcess` Pods. Para obter mais informações, consulte [Create a Windows HostProcessPod](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/) na documentação do Kubernetes.
+ Os clusters do Amazon EKS devem conter um ou mais nós do Linux ou do Fargate para executar pods do sistema de núcleo que só são executados no Linux, como o CoreDNS.
+ Os logs de eventos do `kubelet` e `kube-proxy` são redirecionados para o log de eventos do `EKS Windows` e são definidos com um limite de 200 MB.
+ Você não pode usar [Atribuir grupos de segurança a pods individuais](security-groups-for-pods.md) com pods em execução nos nós do Windows.
+ Você não pode usar [redes personalizadas](cni-custom-network.md) com nós do Windows.
+ Você não pode usar `IPv6` com nós do Windows.
+ Os nós o Windows oferecem suporte para uma interface de rede elástica por nó. Por padrão, o número de pods que podem ser executados por nó do Windows é igual ao número de endereços IP disponíveis por interface de rede elástica para o tipo de instância do nó, menos um. Para obter mais informações, consulte [Endereços IP por interface de rede por tipo de instância](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-eni.html#AvailableIpPerENI) no *Guia do usuário do Amazon EC2*.
+ Em um cluster do Amazon EKS, um único serviço com um balanceador de carga pode ser compatível com até 1.024 pods de backend. Cada pod tem seu próprio endereço IP exclusivo. O limite anterior de 64 pods não é mais o caso, depois de uma [atualização do Windows Server](https://github.com/microsoft/Windows-Containers/issues/93) a partir da [compilação do sistema operacional 17763.2746](https://support.microsoft.com/en-us/topic/march-22-2022-kb5011551-os-build-17763-2746-preview-690a59cd-059e-40f4-87e8-e9139cc65de4).
+ Contêineres do Windows não são compatíveis com os pods do Amazon EKS no Fargate.
+ Você não pode usar os Amazon EKS Hybrid Nodes com o Windows como sistema operacional para o host.
+ Não é possível recuperar logs do pod `vpc-resource-controller`. Antes, era possível implantar o controlador no plano de dados.
+ Há um período de resfriamento antes de um endereço `IPv4` ser atribuído a um novo pod. Isso evita que o tráfego flua para um pod antigo com o mesmo endereço `IPv4` por causa de regras `kube-proxy` obsoletas.
+ A fonte do controlador é gerenciada no GitHub. Para contribuir ou arquivar problemas sobre o controlador, acesse o [projeto](https://github.com/aws/amazon-vpc-resource-controller-k8s) no GitHub.
+ Ao especificar um ID de AMI personalizado para grupos de nós gerenciados do Windows, adicione `eks:kube-proxy-windows` ao mapa de configuração do AWS IAM Authenticator. Para obter mais informações, consulte [Limites e condições ao especificar uma ID de AMI](launch-templates.md#mng-ami-id-conditions).
+ Se preservar os endereços IPv4 disponíveis for crucial para sua sub-rede, consulte [IP Address Management em Windows Networking no Guia de práticas recomendadas do EKS](https://aws.github.io/aws-eks-best-practices/windows/docs/networking/#ip-address-management) para obter orientação.
+ Considerações sobre as entradas de acesso do EKS
+ As entradas de acesso para uso com os nós do Windows precisam do tipo `EC2_WINDOWS`. Para obter mais informações, consulte [Criar entradas de acesso](creating-access-entries.md).
Para criar uma entrada de acesso para um nó do Windows:
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/ --type EC2_Windows
```
## Pré-requisitos
+ Um cluster existente.
+ Seu cluster deve ter pelo menos um (recomendamos pelo menos dois) nó do Linux ou pod do Fargate para executar o CoreDNS. Se você habilitar o suporte legado do Windows, deverá usar um nó do Linux (não é possível usar um pod do Fargate) para executar o CoreDNS.
+ [Perfil do IAM existente do cluster do Amazon EKS](cluster-iam-role.md).
## Habilitar o suporte ao Windows
1. Se não houver nós do Amazon Linux no cluster e você usar grupos de segurança para pods, vá para a próxima etapa. Caso contrário, confirme se a política gerenciada `AmazonEKSVPCResourceController` está anexada à [função do cluster](cluster-iam-role.md). Substitua *eksClusterRole* com o nome da função do cluster.
```
aws iam list-attached-role-policies --role-name eksClusterRole
```
Veja abaixo um exemplo de saída.
```
{
"AttachedPolicies": [
{
"PolicyName": "AmazonEKSClusterPolicy",
"PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
},
{
"PolicyName": "AmazonEKSVPCResourceController",
"PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSVPCResourceController"
}
]
}
```
Se a política estiver anexada, como está na saída anterior, pule a próxima etapa.
1. Anexe a política gerenciada ** [AmazonEKSVPCResourceController](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html) ** ao seu [perfil do IAM de cluster do Amazon EKS.](cluster-iam-role.md) Substitua *eksClusterRole* com o nome da função do cluster.
```
aws iam attach-role-policy \
--role-name eksClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
```
1. Atualize o ConfigMap da CNI da VPC para habilitar o IPAM do Windows. Observe que, se a CNI da VPC estiver instalada no seu cluster usando um chart do Helm ou como um complemento do Amazon EKS, você talvez não consiga modificar diretamente o ConfigMap. Para obter informações sobre como configurar os complementos do Amazon EKS, consulte [Determinar os campos que podem ser personalizados para os complementos do Amazon EKS](kubernetes-field-management.md).
1. Crie um arquivo chamado *vpc-resource-controller-configmap.yaml* com o conteúdo a seguir.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-windows-ipam: "true"
```
1. Aplicar o `ConfigMap` ao seu cluster.
```
kubectl apply -f vpc-resource-controller-configmap.yaml
```
1. Se o cluster tiver o modo de autenticação definido para habilitar o configmap `aws-auth`:
+ Verifique se seu `ConfigMap` do `aws-auth` contém um mapeamento para o perfil de instância do nó do Windows para incluir o grupo de permissões `eks:kube-proxy-windows` do RBAC. O comando a seguir pode ser executado para verificar.
```
kubectl get configmap aws-auth -n kube-system -o yaml
```
Veja abaixo um exemplo de saída.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
- eks:kube-proxy-windows # This group is required for Windows DNS resolution to work
rolearn: arn:aws:iam::111122223333:role/eksNodeRole
username: system:node:{{EC2PrivateDNSName}}
[...]
```
Você deverá ver `eks:kube-proxy-windows` listado em grupos. Se o grupo não for especificado, será necessário atualizar seu `ConfigMap` ou criá-lo para incluir o grupo necessário. Para obter mais informações sobre o `ConfigMap` do `aws-auth`, consulte [Como aplicar o `ConfigMap` `aws-auth` ao seu cluster](auth-configmap.md#aws-auth-configmap).
1. Se o cluster tiver o modo de autenticação definido para desabilitar o configmap `aws-auth`, você poderá usar as entradas de acesso do EKS. Crie um perfil de nó para uso com instâncias do Windows, e o EKS criará automaticamente uma entrada de acesso do tipo `EC2_WINDOWS`.
## Implantar pods do Windows
Para implantar pods no cluster, será necessário especificar o sistema operacional que eles usam, se você estiver executando uma mistura de tipos de nós.
Para pods do Linux, use o texto do seletor de nó a seguir em seus manifestos.
```
nodeSelector:
kubernetes.io/os: linux
kubernetes.io/arch: amd64
```
Para pods do Windows, use o texto do seletor de nó a seguir em seus manifestos.
```
nodeSelector:
kubernetes.io/os: windows
kubernetes.io/arch: amd64
```
Você pode implantar uma [aplicação de exemplo](sample-deployment.md) para ver os seletores de nós em uso.
## Compatibilidade com uma maior densidade de pods em nós do Windows
No Amazon EKS, cada pod recebe um endereço `IPv4` da VPC. Como resultado, o número de pods que podem ser implantados em um nó é limitado pelos endereços IP disponíveis, mesmo que haja recursos suficientes para executar mais pods no nó. Como somente uma interface de rede elástica é aceita por cada nó do Windows, por padrão, o número máximo de endereços IP disponíveis em um nó do Windows é igual a:
```
Number of private IPv4 addresses for each interface on the node - 1
```
Um endereço IP é usado como endereço IP principal da interface de rede, e portanto, não pode ser alocado a pods.
É possível permitir uma maior densidade de pods em nós do Windows ao habilitar a delegação de prefixo de IP. Esse recurso permite atribuir um prefixo `IPv4` `/28` à interface de rede primária, em vez de atribuir endereços `IPv4` secundários. A atribuição de um prefixo IP aumenta o número máximo de endereços `IPv4` disponíveis no nó para:
```
(Number of private IPv4 addresses assigned to the interface attached to the node - 1) * 16
```
Com esse número significativamente maior de endereços IP disponíveis, eles não limitarão sua capacidade de escalar o número de pods em seus nós. Para obter mais informações, consulte [Atribuir mais endereços IP aos nós do Amazon EKS com prefixos](cni-increase-ip-addresses.md).
# Desativar o suporte ao Windows
1. Se o cluster contiver nós do Amazon Linux e você usar [grupos de segurança para pods](security-groups-for-pods.md) com eles, ignore esta etapa.
Remova a política do IAM `AmazonVPCResourceController` gerenciada da [função do cluster](cluster-iam-role.md). Substitua *eksClusterRole* pelo nome do perfil do cluster.
```
aws iam detach-role-policy \
--role-name eksClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
```
1. Desabilite o Windows IPAM no ConfigMap `amazon-vpc-cni`.
```
kubectl patch configmap/amazon-vpc-cni \
-n kube-system \
--type merge \
-p '{"data":{"enable-windows-ipam":"false"}}'
```
# Implementar clusters privados com acesso limitado à internet
Este tópico descreve como implantar um cluster do Amazon EKS que está implantado na nuvem AWS, mas não tem acesso à Internet de saída. Se você tiver um cluster local em AWS Outposts, consulte [Criar nós Amazon Linux no AWS Outposts](eks-outposts-self-managed-nodes.md), em vez deste tópico.
Se você não estiver familiarizado com a rede do Amazon EKS, consulte [De-mystifying cluster networking for Amazon EKS worker nodes](https://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes). Se o seu cluster não tiver acesso de saída à Internet, ele deverá atender aos seguintes requisitos:
## Requisitos de arquitetura do cluster
+ O cluster deve extrair imagens de um registro de contêiner que esteja na VPC. Você pode criar um Amazon Elastic Container Registry na VPC e copiar para ele as imagens de contêiner para que os nós as extrai dali. Para obter mais informações, consulte [Copiar uma imagem de contêiner de um repositório para outro](copy-image-to-repository.md).
+ O cluster deve ter acesso privado ao endpoint habilitado. Isso é necessário para que os nós sejam registrados no endpoint do cluster. O acesso público ao endpoint é opcional. Para obter mais informações, consulte [Endpoint do servidor de API do cluster](cluster-endpoint.md).
## Requisitos do nó
+ Os nós autogerenciados do Windows e do Linux devem incluir os seguintes argumentos de bootstrap antes de serem executados. Esses argumentos ignoram a introspecção do Amazon EKS e não exigem acesso à API do Amazon EKS de dento da VPC.
1. Determine o valor do endpoint do cluster com o comando a seguir. Substitua *my-cluster* pelo nome do cluster.
```
aws eks describe-cluster --name my-cluster --query cluster.endpoint --output text
```
Veja abaixo um exemplo de saída.
```
https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
```
1. Determine o valor da autoridade de certificação do cluster com o comando a seguir. Substitua *my-cluster* pelo nome do cluster.
```
aws eks describe-cluster --name my-cluster --query cluster.certificateAuthority --output text
```
A saída retornada é uma string longa.
1. Substitua os valores de `apiServerEndpoint` e `certificateAuthority` no objeto NodeConfig pelos valores retornados na saída dos comandos anteriores. Para obter mais informações sobre como especificar argumentos de inicialização ao executar nós gerenciados pelo cliente do Amazon Linux 2023, consulte [Criar nós autogerenciados do Amazon Linux](launch-workers.md) e [Criar nós autogerenciados do Microsoft Windows](launch-windows-workers.md).
+ Para nós do Linux:
```
---
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: [.replaceable]https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
certificateAuthority: [.replaceable]Y2VydGlmaWNhdGVBdXRob3JpdHk=
...
```
Para obter argumentos adicionais, consulte o [script de bootstrap](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) no GitHub.
+ Para nós do Windows:
**nota**
Se você estiver usando um CIDR de serviço personalizado, será necessário especificá-lo usando o parâmetro `-ServiceCIDR`. Do contrário, a resolução de DNS para pods no cluster falhará.
```
-APIServerEndpoint cluster-endpoint -Base64ClusterCA certificate-authority
```
Para obter argumentos adicionais, consulte [Parâmetros de configuração do script de bootstrap](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
+ O `ConfigMap` da `aws-auth` do cluster deve ser criado de dentro da VPC. Para obter mais informações sobre como criar e adicionar entradas ao `ConfigMap` `aws-auth`, insira `eksctl create iamidentitymapping --help` em seu terminal. Se o `ConfigMap` não existir no seu servidor, `eksctl` será criado quando você usar o comando para adicionar um mapeamento de identidade.
## Requisitos do Pod
+ **Identidade de Pods**: os pods configurados com a Identidade de Pods do EKS adquirem credenciais da API Auth do EKS. Se não houver acesso de saída à Internet, será necessário criar e usar um endpoint da VPC para a API Auth do EKS: `com.amazonaws.region-code.eks-auth`. Para obter mais informações sobre endpoints da VPC do EKS e o EKS Auth, consulte [Acessar o Amazon EKS usando o AWS PrivateLink](vpc-interface-endpoints.md).
+ **IRSA**: pods configurados com [perfis do IAM para contas de serviço](iam-roles-for-service-accounts.md) adquirem credenciais de uma chamada de API do AWS Security Token Service (AWS STS). Se não houver acesso de saída à Internet, você deverá criar e usar um endpoint AWS STS VPC em sua VPC. A maioria dos SDKs do AWS `v1` usa o endpoint global AWS STS por padrão (`sts.amazonaws.com`), que não usa o endpoint AWS STS VPC. Para usar o endpoint AWS STS VPC, talvez seja necessário configurar o SDK para usar o endpoint regional AWS STS (`sts.region-code.amazonaws.com`). Para obter mais informações, consulte [Configurar o endpoint do AWS Security Token Service para uma conta de serviço](configure-sts-endpoint.md).
+ As sub-redes da VPC do cluster devem ter um endpoint de interface da VPC para todos os serviços da AWS que os pods precisam acessar. Para obter mais informações, consulte [Acessar um serviço da AWS usando um endpoint da VPC de interface](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html). Alguns serviços e endpoints comumente usados estão listados na tabela a seguir. Para obter uma lista completa de endpoints, consulte [AWS services that integrate with AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html) no [AWS PrivateLink Guide](https://docs.aws.amazon.com/vpc/latest/privatelink/).
Recomendamos que você [habilite nomes de DNS privados](https://docs.aws.amazon.com/vpc/latest/privatelink/interface-endpoints.html#enable-private-dns-names) para seus endpoints da VPC, para que as workloads possam continuar usando endpoints de serviço da AWS públicos sem problemas.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/private-clusters.html)
+ Todos os nós autogerenciados devem ser implantados em sub-redes que tenham os endpoints de interface da VPC necessários. Se você criar um grupo de nós gerenciados, o grupo de segurança de endpoint de interface da VPC deverá aceitar o CIDR para as sub-redes ou será necessário adicionar o grupo de segurança do nó criado ao grupo de segurança do endpoint de interface da VPC.
+ **Armazenamento do EFS**: se os seus pods usarem volumes do Amazon EFS, antes de implantar a ação indicada em [Armazene um sistema de arquivos elástico com o Amazon EFS](efs-csi.md), o arquivo [kustomization.yaml](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/deploy/kubernetes/overlays/stable/kustomization.yaml) do driver deverá ser alterado para definir as imagens do contêiner para usar a mesma região da AWS que o cluster do Amazon EKS.
+ O Route 53 não é compatível com o AWS PrivateLink. Você não pode gerenciar registros DNS do Route 53 em um cluster privado do Amazon EKS. Isso afeta o [external-dns](https://github.com/kubernetes-sigs/external-dns) do Kubernetes.
+ Se você usa a AMI otimizada para EKS, deve habilitar o endpoint do `ec2` na tabela acima. Como alternativa, você pode definir manualmente o nome DNS do nó. A AMI otimizada usa APIs do EC2 para definir o nome DNS do nó automaticamente.
+ Você pode usar o [AWS Load Balancer Control](aws-load-balancer-controller.md) ler para implantar AWS Application Load Balancers (ALB) e Network Load Balancers em seu cluster privado. Ao implantá-lo, você deve usar [sinalizadores de linha de comando](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/configurations/#controller-command-line-flags) para definir `enable-shield`, `enable-waf` e `enable-wafv2` como falsos. [Detecção de certificados](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/cert_discovery/#discover-via-ingress-rule-host) com nomes de host de objetos de ingresso não é compatível. Isso ocorre porque o controlador precisa acessar o AWS Certificate Manager, que não tem um endpoint de interface VPC.
O controlador é compatível com balanceadores de carga de rede com destinos IP, que são necessários para uso com Fargate. Para obter mais informações, consulte [Roteamento de aplicações e tráfego HTTP com Application Load Balancers](alb-ingress.md) e [Criar um balanceador de carga da rede](network-load-balancing.md#network-load-balancer).
+ Há suporte para o [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md). Ao implantar pods do Cluster Autoscaler, certifique-se de que a linha de comandos inclua `--aws-use-static-instance-list=true`. Para obter mais informações, consulte [Usar lista de instâncias estáticas](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#use-static-instance-list) no GitHub. A VPC do nó de processamento também deve incluir o endpoint da VPC AWS STS e o endpoint VPC de escalabilidade automática.
+ Alguns produtos de software de contêiner utilizam chamadas de API que acessam o serviço AWS Marketplace para monitorar a utilização. Como os clusters privados não permitem essas chamadas, esses tipos de contêiner não podem ser usados nesses clusters.
# Escale a computação em cluster com o Karpenter e o Cluster Autoscaler
A escalação automática é uma função que aumenta ou reduz automaticamente a escala dos recursos para atender a alterações de demanda. É uma função importante do Kubernetes cuja execução manual exigiria extensos recursos humanos.
## Modo Automático do EKS
O Modo Automático do Amazon EKS escala automaticamente os recursos computacionais do cluster. Se um pod não se adaptar aos nós existentes, o Modo Automático do EKS criará um novo. O Modo Automático do EKS também consolida workloads e exclui nós. O Modo Automático do EKS é baseado no Karpenter.
Para obter mais informações, consulte:
+ [Automatizar a infraestrutura de clusters com o Modo Automático do EKS](automode.md)
+ [Criar um grupo de nós para o Modo Automático do EKS](create-node-pool.md)
+ [Implantar uma workload de ampliação de exemplo em um cluster do Modo Automático do Amazon EKS](automode-workload.md)
## Soluções adicionais
O Amazon EKS é compatível com dois produtos de ajuste de escala automático:
**Karpenter**
O Karpenter é um autoscaler de clusters do Kubernetes flexível e de alta performance que ajuda a melhorar a disponibilidade das aplicações e a eficiência do cluster. O Karpenter inicia recursos computacionais do tamanho certo (por exemplo, instâncias do Amazon EC2) em resposta à alteração da carga da aplicação em menos de um minuto. Com a integração do Kubernetes à AWS, o Karpenter pode provisionar recursos computacionais just-in-time que atendam aos requisitos de sua workload com precisão. O Karpenter provisiona automaticamente novos recursos de computação com base nos requisitos específicos das workloads de cluster. Isso inclui requisitos de computação, armazenamento, aceleração e agendamento. O Amazon EKS oferece suporte a clusters que usam o Karpenter, mas o Karpenter funciona com qualquer cluster do Kubernetes compatível. Para obter mais informações, consulte a documentação do [Karpenter](https://karpenter.sh/docs/).
O Karpenter é um software open-source que os clientes da AWS são responsáveis por instalar, configurar e gerenciar em clusters do Kubernetes. A AWS fornece suporte técnico quando o Karpenter é executado sem modificações usando uma versão compatível em clusters do Amazon EKS. É essencial que os clientes mantenham a disponibilidade e a segurança do controlador Karpenter, bem como os procedimentos de teste adequados ao atualizá-lo ou ao atualizar o cluster do Kubernetes no qual ele está sendo executado, assim como qualquer outro software gerenciado pelo cliente. Não há um acordo de serviço (SLA) da AWS para o Karpenter, e os clientes são responsáveis por garantir que as instâncias do EC2 iniciadas pelo Karpenter atendam aos seus requisitos comerciais.
**Autoscaler do cluster**
O Cluster Autoscaler do Kubernetes ajusta automaticamente o número de nós no cluster quando os pods falharem ou forem reagendados em outros nós. O Cluster Autoscaler usa grupos do Auto Scaling. Para obter mais informações, consulte [Autoscaler do cluster na AWS](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md).
# Saiba mais sobre a mudança de zona do Controlador de Recuperação de Aplicações da Amazon (ARC, na sigla em inglês) no Amazon EKS
O Kubernetes tem recursos nativos que permitem que você torne suas aplicações mais resilientes a eventos como a degradação da integridade ou a deficiência de uma zona de disponibilidade (AZ). Ao executar as workloads em um cluster do Amazon EKS, é possível aumentar ainda mais a tolerância a falhas do ambiente e a recuperação da aplicação usando a [mudança de zona do Controlador de Recuperação de Aplicações da Amazon (ARC, na sigla em inglês)](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.html) ou a [mudança de zona automática](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.html). A mudança de zona do ARC é uma medida temporária que possibilita desviar o tráfego de um recurso de uma AZ comprometida até a expiração ou o cancelamento da mudança de zona. É possível prolongar a mudança de zona, caso seja necessário.
Você pode iniciar uma mudança de zona em um cluster do EKS ou permitir que a AWS realize o deslocamento do tráfego por você ao habilitar a mudança de zona automática. Essa mudança atualiza o fluxo do tráfego de rede leste-oeste em seu cluster para considerar apenas os endpoints de rede para Pods em execução em nós de processamento em AZs íntegras. Além disso, qualquer ALB ou NLB que lide com o tráfego de entrada para aplicações no seu cluster do EKS encaminhará automaticamente o tráfego para destinos nas AZs íntegras. Para os clientes que buscam as metas de disponibilidade mais altas, no caso de uma AZ ser prejudicada, pode ser importante poder desviar todo o tráfego da AZ afetada até que ela se recupere. Para isso, você também pode [https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html).
## Noções básicas sobre o fluxo de tráfego de rede leste-oeste entre pods
O diagrama a seguir ilustra dois exemplos de workloads: Pedidos e Produtos. O objetivo desse exemplo é mostrar como as workloads e os pods em diferentes AZs se comunicam.
![\[Ilustração de tráfego de rede\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/zs-traffic-flow-before-1.png)
![\[Ilustração de tráfego de rede\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/zs-traffic-flow-before-2.png)
1. Para que o serviço Orders estabeleça comunicação com o Products, ele precisa primeiro resolver o nome de DNS do serviço de destino. O Orders se comunica com o CoreDNS para buscar o endereço IP virtual (IP do cluster) desse serviço. Após o Orders resolver o nome do serviço Products, ele envia o tráfego para esse endereço IP de destino.
1. O kube-proxy é executado em cada nó do cluster e monitora continuamente os [EndpointSlices](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/) para os serviços. Quando um serviço é criado, um EndpointSlice é criado e gerenciado em segundo plano pelo controlador de EndpointSlice. Cada EndpointSlice conta com uma lista ou com uma tabela de endpoints que contém um subconjunto de endereços de pods, juntamente com os nós em que eles estão sendo executados. O kube-proxy configura regras de roteamento para cada um desses endpoints de Pod usando `iptables` nos nós. O kube-proxy também é responsável por uma forma básica de balanceamento de carga, redirecionando o tráfego destinado ao endereço IP do cluster de um serviço para que seja enviado diretamente ao endereço IP de um pod. O kube-proxy realiza esse processo ao reescrever o endereço IP de destino na conexão de saída.
1. Em seguida, os pacotes de rede são enviados ao pod do Products na AZ 2 por meio das ENIs nos respectivos nós, como ilustrado no diagrama anterior.
### Noções básicas sobre a mudança de zona do ARC no Amazon EKS
Se houver um comprometimento de uma AZ em seu ambiente, você poderá iniciar uma mudança de zona para o ambiente do cluster do EKS. Como alternativa, é possível permitir que a AWS gerencie o deslocamento do tráfego para você com a mudança de zona automática. Com a mudança de zona automática, a AWS monitora a integridade geral das AZs e responde a um possível comprometimento de AZ mudando automaticamente o tráfego para fora da AZ comprometida no ambiente de cluster.
Após habilitar a mudança de zona com o ARC em seu cluster do Amazon EKS, você pode iniciar uma mudança de zona ou habilitar a mudança de zona automática pelo console do ARC, pela AWS CLI ou pelas APIs de mudança de zona e de mudança de zona automática. Durante uma mudança de zona do EKS, as seguintes ações são realizadas automaticamente:
+ Todos os nós da AZ comprometida serão isolados. Isso impede que o Agendador do Kubernetes agende novos pods em nós na AZ não íntegra.
+ Se você estiver usando [grupos de nós gerenciados](managed-node-groups.md), o [https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage) será suspenso e o grupo do Auto Scaling será atualizado para garantir que novos nós do plano de dados do EKS sejam iniciados apenas em AZs íntegras.
+ Os nós na AZ não íntegra não serão encerrados, e os pods não são removidos desses nós. Isso garante que, quando uma mudança de zona expirar ou for cancelada, o tráfego possa ser retornado com segurança à AZ para obter capacidade total.
+ O controlador de EndpointSlice identifica todos os endpoints de Pods na AZ comprometida e os remove dos EndpointSlices correspondentes. Isso garantirá que somente os endpoints do pod em AZs íntegras sejam direcionados para receber tráfego de rede. Quando uma mudança de zona for cancelada ou expirar, o controlador de EndpointSlice atualizará os EndpointSlices para incluir os endpoints da AZ restaurada.
Os diagramas a seguir fornecem uma visão geral de alto nível sobre como a mudança de zona do EKS garante que apenas endpoints de pod íntegros sejam selecionados em seu ambiente de cluster.
![\[Ilustração de tráfego de rede\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/zs-traffic-flow-after-1.png)
![\[Ilustração de tráfego de rede\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/zs-traffic-flow-after-2.png)
## Requisitos de mudança de zona do EKS
Para garantir o funcionamento da mudança de zona no EKS, é necessário configurar previamente o ambiente do cluster para que ele seja resiliente ao comprometimento de uma AZ. A seguir, apresentamos uma lista de opções de configuração que ajudam a garantir a resiliência.
+ Provisionar os nós de processamento do seu cluster em várias AZs
+ Provisionamento de capacidade de computação suficiente para atender à remoção de uma única AZ.
+ Escalabilidade prévia dos pods em todas as AZs, incluindo o CoreDNS.
+ Distribuição de várias réplicas de pods entre todas as AZs, auxiliando na garantia de que você ainda terá capacidade de escalabilidade suficiente após a mudança de zona de uma AZ individual.
+ Colocalização de pods interdependentes ou relacionados na mesma AZ.
+ Verificação se o ambiente de cluster opera conforme previsto na ausência de uma AZ, ao iniciar manualmente uma mudança de zona de uma AZ. Como alternativa, você pode habilitar a mudança de zona automática e contar com as execuções de teste de mudança de zona automática. Realizar testes com mudanças de zona manuais ou de prática não é obrigatório para que a mudança de zona funcione no EKS, mas é uma prática fortemente recomendada.
### Provisionamento de nós de processamento do EKS em várias zonas de disponibilidade
As regiões da AWS contam com diversos locais distintos que abrigam data centers físicos, conhecidos como zonas de disponibilidade (AZs). As AZs são projetadas para serem fisicamente isoladas umas das outras a fim de evitar impactos simultâneos que possam afetar toda uma região. Ao realizar o provisionamento de um cluster do EKS, a recomendação é implantar os nós de processamento por diversas AZs em uma região. Essa prática contribui para que o ambiente de cluster seja mais resiliente em caso do comprometimento de uma única AZ, permitindo que você mantenha a alta disponibilidade das aplicações em execução nas demais AZs. Ao iniciar uma mudança de zona para fora da AZ impactada, a rede interna do cluster do ambiente do EKS é atualizada automaticamente para usar apenas AZs íntegras, ajudando a manter a alta disponibilidade do cluster.
Garantir que você tenha uma configuração multi-AZ no ambiente do EKS aumenta a confiabilidade geral do sistema. Contudo, ambientes multi-AZ influenciam o processamento e a transferência de dados das aplicações, resultando em um impacto nos custos de rede do ambiente. Especificamente, o tráfego de saída frequente entre zonas (ou seja, o tráfego distribuído entre AZs) pode ter um grande impacto nos custos relacionados à rede. É possível aplicar estratégias diferentes para controlar a quantidade de tráfego entre zonas entre os pods no cluster do EKS e reduzir os custos associados. Para obter mais informações sobre como otimizar os custos de rede ao executar ambientes do EKS de alta disponibilidade, consulte [https://aws.github.io/aws-eks-best-practices/cost_optimization/cost_opt_networking/](https://aws.github.io/aws-eks-best-practices/cost_optimization/cost_opt_networking/).
O diagrama apresentado a seguir ilustra um ambiente do EKS de alta disponibilidade com três AZs íntegras.
![\[Ilustração de rede\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/zs-ha-before-failure.png)
O diagrama abaixo demonstra como um ambiente do EKS com três AZs é resiliente ao comprometimento de uma das zonas, mantendo a alta disponibilidade por meio das duas AZs íntegras remanescentes.
![\[Ilustração de rede\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/zs-ha-after-failure.png)
### Provisionamento de capacidade de computação suficiente para resistir à remoção de uma única zona de disponibilidade
A fim de otimizar a utilização de recursos e os custos da infraestrutura de computação no plano de dados do EKS, recomenda-se garantir a escalabilidade da capacidade de computação para que ela esteja alinhada às necessidades das workloads. No entanto, **se todos os seus nós de processamento estiverem com capacidade máxima**, você dependerá da adição de novos nós de processamento ao plano de dados do EKS antes que novos pods da workload possam ser agendados. Ao executar workloads críticas, geralmente é uma boa prática operar com capacidade redundante ativa para lidar com cenários como aumentos repentinos de carga e problemas de integridade dos nós. Ao optar pelo uso da mudança de zona, você está planejando a remoção da capacidade de uma zona de disponibilidade completa no caso do comprometimento. Isso implica ajustar a capacidade redundante de computação para que haja escalabilidade suficiente para suportar a carga, mesmo que uma das AZs não esteja ativa.
Ao escalar os recursos de computação, a inclusão de novos nós no plano de dados do EKS não é instantânea e requer um tempo de provisionamento. Isso pode ter implicações na performance em tempo real e na disponibilidade das aplicações, especialmente no caso do comprometimento da zona. O ambiente do EKS deve conseguir suportar a carga de trabalho caso uma AZ fique indisponível, sem comprometer a experiência dos seus usuários finais ou clientes. Isso significa minimizar ou eliminar o atraso entre o momento em que um novo pod é necessário e o momento em que ele é efetivamente agendado em um nó de processamento.
Além disso, em casos de comprometimento de uma zona, o objetivo deve ser evitar limitações de capacidade de computação que possam impedir que novos nós sejam integrados ao plano de dados do EKS nas zonas de disponibilidade que estiverem operando normalmente.
Para reduzir o risco desses potenciais impactos negativos, recomendamos que você provisione capacidade de computação excedente em parte dos nós de processamento em cada uma das AZs. Ao fazer isso, o Agendador do Kubernetes dispõe de capacidade disponível antecipadamente para novas alocações de pods, o que é especialmente importante quando você perde uma das AZs no ambiente.
### Execução e distribuição de diversas réplicas de pods entre as zonas de disponibilidade
O Kubernetes permite que você pré-escale suas workloads executando várias instâncias (réplicas de pod) de uma única aplicação. Executar diversas réplicas de pods para uma aplicação elimina pontos únicos de falha e aumenta a performance geral ao reduzir a sobrecarga de recursos em uma única réplica. No entanto, para garantir alta disponibilidade e tolerância a falhas aprimorada para as aplicações, recomendamos que você execute várias réplicas da aplicação e distribua essas réplicas por diferentes domínios de falha, também chamados de domínios de topologia. Os domínios de falha neste cenário são as zonas de disponibilidade. Ao utilizar [restrições de distribuição de topologia](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/), você pode configurar as aplicações para terem estabilidade estática já estabelecida. Assim, quando houver o comprometimento de uma AZ, seu ambiente terá réplicas suficientes em AZs íntegras para lidar imediatamente com quaisquer picos ou aumentos repentinos de tráfego.
O diagrama apresentado a seguir ilustra um ambiente do EKS com fluxo de tráfego leste-oeste quando todas as AZs estão íntegras.
![\[Ilustração de rede\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/zs-spread-constraints.png)
O diagrama abaixo demonstra um ambiente do EKS com fluxo de tráfego leste-oeste em um cenário de falha em uma única AZ e início da mudança de zona por parte do usuário.
![\[Ilustração de rede\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/zs-spread-constraints-2.png)
O trecho de código a seguir é um exemplo de como configurar a workload com várias réplicas no Kubernetes.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders
spec:
replicas: 9
selector:
matchLabels:
app:orders
template:
metadata:
labels:
app: orders
tier: backend
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: orders
```
Mais importante ainda, você deve executar várias réplicas do software do servidor de DNS (CoreDNS/kube-dns) e aplicar restrições de distribuição de topologia semelhantes, caso elas não estejam configuradas por padrão. Essa prática ajuda a assegurar que, se houver um comprometimento de uma única AZ, você tenha pods de DNS suficientes em AZs íntegras para continuar processando as solicitações de descoberta de serviços para outros pods em comunicação no cluster. O [complemento do CoreDNS para EKS](managing-coredns.md) conta com configurações padrão para os pods do CoreDNS que garantem que, se houver nós disponíveis em diversas AZs, eles sejam distribuídos entre as zonas de disponibilidade do cluster. Se desejar, você pode substituir essas definições padrão por configurações personalizadas.
Ao instalar o [CoreDNS usando o Helm](https://github.com/coredns/helm/tree/master), é possível atualizar o valor `replicaCount` no [arquivo values.yaml](https://github.com/coredns/helm/blob/master/charts/coredns/values.yaml) para assegurar a existência de réplicas suficientes em cada AZ. Além disso, para garantir que essas réplicas sejam distribuídas entre as diferentes AZs do ambiente de cluster, certifique-se de atualizar a propriedade `topologySpreadConstraints` no mesmo arquivo `values.yaml`. O trecho de código a seguir ilustra como configurar o CoreDNS para este propósito.
**CoreDNS Helm values.yaml**
```
replicaCount: 6
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
k8s-app: kube-dns
```
Caso ocorra o comprometimento de uma AZ, é possível absorver o aumento de carga nos pods do CoreDNS ao usar um sistema de ajuste de escala automático para o CoreDNS. A quantidade de instâncias de DNS necessária dependerá do volume de workloads em execução no cluster. O CoreDNS é limitado pela CPU, o que permite que ele seja escalado com base no uso de processamento, por meio do [autoescalador de pod horizontal (HPA, na sigla em inglês)](https://aws.github.io/aws-eks-best-practices/reliability/docs/application/#horizontal-pod-autoscaler-hpa). A seguir, apresentamos um exemplo que você pode modificar para atender às suas necessidades.
```
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: coredns
namespace: default
spec:
maxReplicas: 20
minReplicas: 2
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: coredns
targetCPUUtilizationPercentage: 50
```
Como alternativa, o EKS pode gerenciar o ajuste de escala automático da implantação do CoreDNS na versão do complemento do CoreDNS para o EKS. Esse autoscaler do CoreDNS monitora continuamente o estado do cluster, incluindo o número de nós e núcleos de CPU. Com base nessas informações, o controlador ajusta dinamicamente o número de réplicas da implantação do CoreDNS em um cluster do EKS.
Para habilitar a [configuração de ajuste de escala automático no complemento do CoreDNS para EKS](coredns-autoscaling.md), use a seguinte definição de configuração:
```
{
"autoScaling": {
"enabled": true
}
}
```
Você também pode usar o [DNS NodeLocal](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/) ou o [autoscaler proporcional ao cluster](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler) para dimensionar o CoreDNS. Para obter mais informações, consulte [Scaling CoreDNS horizontally](https://aws.github.io/aws-eks-best-practices/scalability/docs/cluster-services/#scale-coredns-horizontally).
### Colocalização de pods interdependentes na mesma zona de disponibilidade
Geralmente, as aplicações têm workloads distintas que precisam se comunicar entre si para concluir um processo de ponta a ponta com êxito. Caso essas aplicações distintas estejam distribuídas em várias AZs e não sejam alocadas na mesma zona, um problema em apenas uma dessas AZs poderá comprometer todo o processo de ponta a ponta. Por exemplo, se a **Aplicação A** tiver várias réplicas nas zonas de disponibilidade 1 e 2, mas a **Aplicação B** tiver todas as suas réplicas na zona de disponibilidade 3, a perda da zona 3 afetará os processos de ponta a ponta entre as duas workloads, **Aplicação **A e **Aplicação B**. Se você combinar restrições de distribuição de topologia com afinidade de pods, poderá aumentar a resiliência da aplicação distribuindo os pods por todas as zonas de disponibilidade. Além disso, essa definição estabelece uma conexão entre determinados pods para assegurar que sejam alocados no mesmo local.
Com [regras de afinidade de pod](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/), você pode definir relações entre workloads para influenciar o comportamento do Kubernetes Scheduler, de modo que ele coloque os pods no mesmo nó de processamento ou na mesma AZ. Você também pode configurar o quanto as restrições de agendamento devem ser rigorosas.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: products
namespace: ecommerce
labels:
app.kubernetes.io/version: "0.1.6"
spec:
serviceAccountName: graphql-service-account
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- orders
topologyKey: "kubernetes.io/hostname"
```
O diagrama apresentado a seguir mostra vários pods que foram alocados no mesmo local, no mesmo nó, com as regras de afinidade de pods.
![\[Ilustração de rede\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/zs-pod-affinity-rule.png)
### Teste para validar se o ambiente de cluster consegue lidar com a perda de uma AZ
Após concluir os requisitos descritos nas seções anteriores, a próxima etapa consiste em testar se você conta com capacidade de computação e de workload suficientes para lidar com a perda de uma AZ. Isso pode ser feito ao iniciar manualmente uma mudança de zona no EKS. Como alternativa, você pode habilitar a mudança de zona automática e configurar execuções práticas, que também verificam se as aplicações funcionam conforme o esperado com uma AZ a menos no ambiente do cluster.
## Perguntas frequentes
**Por que devo usar esse recurso?**
Ao usar a mudança de zona do ARC ou a mudança de zona automática no cluster do EKS, você pode manter melhor a disponibilidade das aplicações Kubernetes automatizando o processo de recuperação rápida de deslocamento do tráfego de rede no cluster para longe de uma AZ afetada. Com o ARC, é possível evitar etapas extensas e complexas que podem resultar em um período de recuperação prolongado durante eventos de AZ com falhas.
**Como esse recurso funciona com outros serviços do AWS?**
O EKS se integra ao ARC, que fornece a interface principal para você realizar operações de recuperação na AWS. Para garantir que o tráfego dentro do cluster seja direcionado corretamente para fora de uma AZ comprometida, o EKS faz alterações na lista de endpoints de rede dos pods que estão em execução no plano de dados do Kubernetes. Se você estiver usando o Elastic Load Balancing para direcionar tráfego externo para o cluster, é possível registrar os balanceadores de carga no ARC e iniciar uma mudança de zona neles para evitar que o tráfego seja enviado para a AZ degradada. Além disso, a mudança de zona é compatível com grupos do Amazon EC2 Auto Scaling criados por grupos de nós gerenciados do EKS. Para impedir que uma AZ degradada seja usada para criar novos pods do Kubernetes ou para iniciar novos nós, o EKS exclui a AZ comprometida dos grupos do Auto Scaling.
**Como esse recurso é diferente das proteções padrão do Kubernetes?**
Esse recurso funciona em conjunto com diversas proteções nativas do Kubernetes que ajudam na resiliência das aplicações dos clientes. Você pode configurar a prontidão do pod e as sondas de atividade que decidem quando um pod deve receber tráfego. Se essas sondas falharem, o Kubernetes retira esses pods da lista de destinos de um serviço, e o tráfego não é mais direcionado ao pod. Embora isso seja útil, não é simples para os clientes configurar essas verificações de integridade de modo que elas falhem garantidamente quando uma AZ estiver degradada. O recurso de mudança de zona do ARC oferece uma camada adicional de segurança que ajuda a isolar completamente uma AZ degradada quando as proteções nativas do Kubernetes não foram suficientes. Além disso, a mudança de zona fornece um método simples para verificar a prontidão operacional e a resiliência da arquitetura.
**A AWS pode iniciar uma mudança de zona em meu nome?**
Sim, se você quiser uma maneira totalmente automatizada de usar a mudança de zona do ARC, poderá habilitar a mudança de zona automática do ARC. Com a mudança de zona automática, você pode contar com a AWS para monitorar a integridade das AZs do cluster do EKS e iniciar automaticamente uma mudança de zona quando o comprometimento de uma AZ for detectado.
**O que acontecerá se eu usar esse recurso e meus nós de processamento e workloads não forem pré-escalonados?**
Caso não tenha escalado os recursos antecipadamente e precise provisionar nós ou pods adicionais durante uma mudança de zona, a recuperação do sistema poderá sofrer atrasos. O processo de adição de novos nós ao plano de dados do Kubernetes demora algum tempo, o que pode afetar a performance em tempo real e a disponibilidade das aplicações, especialmente quando há o comprometimento de uma AZ. Além disso, durante o comprometimento de uma AZ, pode haver uma restrição de capacidade de computação que impeça a inclusão de nós recém-requeridos nas AZs que estão operando normalmente.
Se as workloads não estiverem com recursos escalados antecipadamente e distribuídos por todas as AZs do cluster, um comprometimento de zona poderá afetar a disponibilidade de uma aplicação que esteja sendo executada apenas em nós de processamento na AZ impactada. Para reduzir o risco de uma interrupção completa da disponibilidade da sua aplicação, o EKS tem uma proteção contra falhas para que o tráfego seja enviado aos endpoints do Pod em uma zona afetada se essa workload tiver todos os seus endpoints na AZ não íntegra. Contudo, é altamente recomendável escalar recursos antecipadamente e distribuir aplicações entre todas as AZs, garantindo que o serviço mantenha a disponibilidade se houver falha em uma das zonas.
**Como isso funciona caso eu esteja executando uma aplicação com estado?**
Se você estiver executando uma aplicação com estado, deverá avaliar a tolerância a falhas com base no caso de uso e na arquitetura. Caso use um padrão ou uma arquitetura com ativo e em espera, pode haver situações em que o recurso ativo esteja em uma AZ comprometida. No nível da aplicação, se o recurso em espera não for devidamente ativado, você poderá enfrentar problemas com a aplicação. Você também pode enfrentar problemas quando novos pods do Kubernetes forem iniciados em AZs íntegras, já que esses pods não conseguirão se conectar aos volumes persistentes vinculados à AZ comprometida.
**Esse recurso funciona com o Karpenter?**
No momento, o suporte ao Karpenter não está disponível com a mudança de zona do ARC e a mudança de zona automática no EKS. Caso uma AZ esteja comprometida, é possível ajustar a configuração pertinente do NodePool do Karpenter ao remover a AZ que não está íntegra, garantindo que novos nós de processamento sejam iniciados somente nas demais AZs.
**Esse recurso funciona com o EKS Fargate?**
Esse recurso não funciona com o EKS Fargate. Por padrão, quando o EKS Fargate reconhecer um evento de integridade de zona, os pods preferirão ser executados nas outras AZs.
**O ambiente de gerenciamento do Kubernetes gerenciado pelo EKS será afetado?**
Não, por padrão, o Amazon EKS executa e dimensiona o ambiente de gerenciamento do Kubernetes em várias AZs para garantir alta disponibilidade. A mudança de zona e a mudança de zona automática do ARC operam somente no plano de dados do Kubernetes.
**Há algum custo associado a esse novo recurso?**
Você pode usar a mudança de zona do ARC e a mudança de zona automática no seu cluster do EKS sem custo adicional. No entanto, você continuará pagando pelas instâncias provisionadas. Portanto, recomendamos que realize a escala antecipada de recursos para o plano de dados do Kubernetes antes de utilizá-los. Você deve considerar um equilíbrio entre o custo e a disponibilidade da aplicação.
## Recursos adicionais
+ [Como funciona uma mudança de zona](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.how-it-works.html)
+ [Práticas recomendadas para mudanças de zona no ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.zonal-shifts.html#zonalshift.route53-arc-best-practices.zonal-shifts)
+ [Recursos e cenários suportados para deslocamento zonal e deslocamento automático zonal](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html)
+ [Operar workloads resilientes no Amazon EKS](https://aws.amazon.com/blogs/containers/operating-resilient-workloads-on-amazon-eks)
+ [Elimine o atraso no dimensionamento de nós do Kubernetes com prioridade de pods e o superprovisionamento](https://aws.amazon.com/blogs/containers/eliminate-kubernetes-node-scaling-lag-with-pod-priority-and-over-provisioning)
+ [Dimensione pods do CoreDNS para alto tráfego de DNS](coredns-autoscaling.md)
# Habilitação da mudança de zona do EKS para evitar zonas de disponibilidade comprometidas
O Amazon Application Recovery Controller (ARC) ajuda você a gerenciar e coordenar a recuperação de aplicações nas zonas de disponibilidade (AZs) e funciona com muitos serviços, incluindo o Amazon EKS. Com o suporte do EKS para a mudança de zona do ARC, é possível deslocar o tráfego de rede no cluster para longe de uma AZ com problemas. Você também pode autorizar o AWS a monitorar a integridade das suas AZs e desviar temporariamente o tráfego de rede de uma AZ não íntegra em seu nome.
**Como usar a mudança de zona do EKS:**
1. Habilite seu cluster do EKS com o Amazon Application Recovery Controller (ARC). Isso é feito no nível do cluster usando o Console do Amazon EKS, a AWS CLI, o CloudFormation ou o eksctl.
1. Uma vez habilitado, você pode gerenciar mudanças de zona ou mudanças de zona automáticas usando o console do ARC, a AWS CLI ou as APIs de mudança de zona e de mudança de zona automática.
Observe que, depois de registrar um cluster EKS no ARC, ainda é necessário configurar o ARC. Por exemplo, é possível utilizar o console do ARC para configurar a mudança de zona automática.
Para obter informações mais detalhadas sobre o funcionamento da mudança de zona do EKS e como estruturar as workloads para lidar com zonas de disponibilidade comprometidas, consulte [Saiba mais sobre a mudança de zona do Controlador de Recuperação de Aplicações da Amazon (ARC, na sigla em inglês) no Amazon EKS](zone-shift.md).
## Considerações
+ O modo automático do EKS não é compatível com o Controlador de Recuperação de Aplicações da Amazon, a mudança de zona e a mudança de zona automática.
+ Recomendamos esperar pelo menos 60 segundos entre as operações de mudança de zona para garantir o processamento adequado de cada solicitação.
Ao tentar realizar mudanças de zona em uma sucessão rápida (em até 60 segundos uma da outra), o serviço do Amazon EKS pode não processar adequadamente todas as solicitações de mudança. Isso se deve ao mecanismo de sondagem atual que atualiza o estado zonal do cluster. Se você precisar realizar várias mudanças de zona, certifique-se de que haja um tempo adequado entre as operações para que o sistema processe cada mudança.
## O que é o Amazon Application Recovery Controller?
O Amazon Application Recovery Controller (ARC) ajuda você a se preparar e a realizar uma recuperação mais rápida dos aplicações executados em AWS. A mudança de zona permite que você se recupere rapidamente de deficiências na zona de disponibilidade (AZ), movendo temporariamente o tráfego de um recurso compatível de uma AZ para AZs íntegras na região da AWS.
[Saiba mais sobre o Amazon Application Recovery Controller (ARC)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
## O que é mudança de zona?
A mudança de zona é um recurso do ARC que permite mover o tráfego de um recurso, como um cluster do EKS ou um Elastic Load Balancer, para fora de uma zona de disponibilidade em uma região da AWS para atenuar rapidamente um problema e recuperar rapidamente a aplicação. Você pode optar por mudar o tráfego, por exemplo, porque uma implantação ruim está causando problemas de latência ou porque a Availability Zone está afetada. Uma mudança de zona não exige nenhuma etapa de configuração prévia.
[Saiba mais sobre a mudança de zona do ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.how-it-works.html).
## O que é mudança de zona automática?
A mudança de zona automática é um recurso do ARC que você pode habilitar para autorizar a AWS a desviar o tráfego de uma AZ para recursos compatíveis, em seu nome, para AZs saudáveis na região da AWS. A AWS inicia uma transferência automática quando a telemetria interna indica que há uma deficiência em uma AZ em uma região que pode afetar potencialmente os clientes. A telemetria interna incorpora métricas de várias fontes, incluindo a rede AWS e os serviços Amazon EC2 e Elastic Load Balancing.
A AWS encerra as mudanças automáticas quando os indicadores mostram que não há mais um problema ou um problema em potencial.
[Saiba mais sobre a mudança de zona automática do ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.how-it-works.html).
## O que o EKS faz durante uma mudança automática?
O EKS atualiza as configurações de rede para evitar o direcionamento do tráfego para AZs com problemas. Além disso, se você estiver usando Grupos de nós gerenciados, o EKS só iniciará novos nós nas AZs íntegras durante uma mudança de zona. Quando a mudança expirar ou for cancelada, as configurações de rede serão restauradas para incluir a AZ que foi detectada anteriormente como não íntegra.
[Saiba mais sobre a mudança de zona do EKS](zone-shift.md).
## Registre o cluster EKS com o Amazon Application Recovery Controller (ARC) (console do AWS)
1. Encontre o nome e a região do cluster EKS que você deseja registrar no ARC.
1. Navegue até o [console do EKS](https://console.aws.amazon.com/eks) nessa região e selecione seu cluster.
1. Na página **de informações do cluster**, selecione a guia **Overview (Visão geral** ).
1. No título **Mudança de zona**, selecione o botão **Gerenciar**.
1. Selecione **habilitar** ou **desabilitar** para a *mudança de zona do EKS*.
Agora, seu cluster EKS está registrado no ARC.
Para que a AWS identifique e evite zonas de disponibilidade comprometidas, é necessário configurar a mudança de zona automática do ARC. Por exemplo, você pode fazer isso no console do ARC.
## Próximas etapas
+ Saiba como [habilitar a mudança de zona automática](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.start-cancel.html).
+ Saiba como [iniciar uma mudança de zona](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html) manualmente.