**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.
# Automatizar a infraestrutura de clusters com o Modo Automático do EKS
**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 Modo Automático do Amazon EKS.
O Modo Automático do EKS estende o gerenciamento da AWS dos clusters do Kubernetes além do próprio cluster, o que possibilita que a AWS também configure e gerencie a infraestrutura que permite o bom funcionamento das workloads. É possível delegar as principais decisões de infraestrutura e aproveitar a experiência da AWS para as operações diárias. A infraestrutura de clusters gerenciada pela AWS inclui muitos recursos do Kubernetes como componentes principais, em vez de complementos, como ajuste de escala automático de computação, rede de pods e serviços, balanceamento de carga de aplicações, DNS de cluster, armazenamento em blocos e suporte a GPU.
Para começar, você pode implantar um novo cluster do Modo Automático do EKS ou habilitar o Modo Automático do EKS em um cluster existente. É possível implantar, atualizar ou modificar os clusters do Modo Automático do EKS usando o eksctl, a AWS CLI, o Console de gerenciamento da AWS, as APIs do EKS ou as ferramentas de preferência de infraestrutura como código.
Com o Modo Automático do EKS, você pode continuar usando as ferramentas de preferência compatíveis com o Kubernetes. O Modo Automático do EKS se integra aos serviços da AWS, como o Amazon EC2, Amazon EBS e ELB, aproveitando os recursos da Nuvem AWS que seguem as práticas recomendadas. Esses recursos são escalados automaticamente, otimizados em termos de custo e atualizados regularmente para ajudar a minimizar os custos operacionais e as despesas gerais.
## Recursos
O Modo Automático do EKS oferece os seguintes recursos de alto nível:
**Simplificar o gerenciamento de clusters do Kubernetes**: o Modo Automático do EKS simplifica o gerenciamento do EKS fornecendo clusters prontos para produção com o mínimo de sobrecarga operacional. Com o Modo Automático do EKS, você pode executar workloads exigentes e dinâmicas com confiança, sem precisar ter uma profunda experiência no EKS.
**Disponibilidade de aplicações**: o Modo Automático do EKS adiciona ou remove dinamicamente nós no cluster de EKS com base nas demandas das aplicações do Kubernetes. Isso minimiza a necessidade de planejamento manual de capacidade e garante a disponibilidade das aplicações.
**Eficiência**: o Modo Automático do EKS foi projetado para otimizar os custos de computação e, ao mesmo tempo, aderir à flexibilidade definida pelos requisitos do NodePool e das workloads. Ele também encerra instâncias não utilizadas e consolida workloads em outros nós para melhorar a eficiência de custos.
**Segurança**: o Modo Automático do EKS usa AMIs que são tratadas como imutáveis para os nós. Essas AMIs impõem software bloqueado, habilitam controles de acesso obrigatórios do SELinux e fornecem sistemas de arquivos raiz somente leitura. Além disso, os nós executados pelo Modo Automático do EKS têm uma vida útil máxima de 21 dias (que você pode reduzir), após a qual são automaticamente substituídos por novos nós. Essa abordagem aprimora sua postura de segurança ao alternar os nós regularmente, alinhando-se às práticas recomendadas já adotadas por muitos clientes.
**Atualizações automatizadas**: o Modo Automático do EKS mantém o cluster, os nós e componentes relacionados do Kubernetes atualizados com os patches mais recentes, respeitando os orçamentos de interrupção de pods (PDBs) e os orçamentos de interrupção de NodePool (NDBs) configurados. Até o tempo de vida máximo de 21 dias, poderá ser necessária uma intervenção se PDBs de bloqueio ou outras configurações impedirem as atualizações.
**Componentes gerenciados**: o Modo Automático do EKS inclui recursos do Kubernetes e da Nuvem AWS como componentes principais que, de outra forma, precisariam ser gerenciados como complementos. Isso inclui suporte integrado para atribuições de endereço IP de pods, políticas de rede de pods, serviços DNS locais, plug-ins de GPU, verificadores de integridade e armazenamento da CSI do EBS.
**NodePools e NodeClasses personalizáveis**: se a workload exigir alterações nas configurações de armazenamento, computação ou rede, será possível criar NodePools e NodeClasses personalizados usando o Modo Automático do EKS. Embora não seja recomendado editar NodePools e NodeClasses padrão, é possível adicionar novos NodePools ou NodeClasses personalizados junto com as configurações padrão para atender a requisitos específicos.
## Componentes automatizados
O Modo Automático do EKS simplifica a operação dos clusters do Amazon EKS automatizando os componentes-chave da infraestrutura. Habilitar o Modo Automático do EKS reduz ainda mais as tarefas para gerenciar os clusters de EKS.
Veja abaixo uma lista dos componentes do plano de dados que são automatizados:
+ **Computação**: para muitas workloads, com o Modo Automático do EKS, você não precisa se preocupar com muitos aspectos da computação nos clusters de EKS. Isso inclui:
+ **Nós**: os nós do Modo Automático do EKS são projetados para serem tratados como dispositivos. O Modo Automático do EKS faz o seguinte:
+ Escolhe uma AMI apropriada que esteja configurada com muitos serviços necessários para executar as workloads sem intervenção.
+ Bloqueia o acesso a arquivos na AMI usando o modo de imposição do SELinux e um sistema de arquivos raiz somente leitura.
+ Impede o acesso direto aos nós ao desabilitar o acesso por SSH ou SSM.
+ Inclui suporte para GPU, com drivers de kernel e plug-ins separados para GPUs NVIDIA e Neuron, possibilitando workloads de alta performance.
+ Lida automaticamente com os [avisos de interrupção de instâncias spot do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html) e os eventos de integridade das instâncias do EC2
+ **Ajuste de escala automático**: com base no ajuste de escala automático do [Karpenter](https://karpenter.sh/docs/), o Modo Automático do EKS monitora pods não programáveis e possibilita a implantação de novos nós para executá-los. À medida que as workloads são encerradas, o Modo Automático do EKS interrompe e encerra dinamicamente os nós quando eles não são mais necessários, otimizando o uso de recursos.
+ **Atualizações**: assumir o controle dos nós otimiza a capacidade do Modo Automático do EKS de fornecer patches de segurança e atualizações do sistema operacional e de componentes, conforme necessário. Essas atualizações são projetadas para proporcionar o mínimo de interrupção das workloads. O Modo Automático do EKS impõe uma vida útil máxima de 21 dias para os nós, a fim de garantir software e APIs atualizados.
+ **Balanceamento de carga**: o Modo Automático do EKS otimiza o balanceamento de carga ao se integrar ao serviço do Elastic Load Balancing da Amazon, automatizando o provisionamento e a configuração de balanceadores de carga para serviços do Kubernetes e recursos de entrada. Ele é compatível com recursos avançados para Application e Network Load Balancers, gerencia seus ciclos de vida e os escala para atender às demandas do cluster. Essa integração fornece uma solução de balanceamento de carga pronta para produção que segue as práticas recomendadas da AWS, permitindo que você se concentre nas aplicações e não no gerenciamento da infraestrutura.
+ **Armazenamento**: o Modo Automático do EKS configura o armazenamento efêmero para você, configurando tipos de volume, tamanhos de volume, políticas de criptografia e políticas de exclusão após o encerramento dos nós.
+ **Rede**: o Modo Automático do EKS automatiza tarefas críticas de rede para conectividade de pods e serviços. Isso inclui suporte a IPv4 e IPv6 e o uso de blocos CIDR secundários para estender espaços de endereços IP.
+ **Identity and Access Management**: você não precisa instalar o agente da Identidade de Pods do EKS nos clusters do Modo Automático do EKS.
Para mais informações sobre esses componentes, consulte [Saiba como o Modo Automático do EKS funciona](auto-reference.md).
## Configuração
Embora o Modo Automático do EKS gerencie com eficácia a maioria dos serviços do plano de dados sem sua intervenção, poderá haver momentos em que você deseje mudar o comportamento de alguns desses serviços. É possível modificar a configuração dos clusters do Modo Automático do EKS das seguintes maneiras:
+ **DaemonSets do Kubernetes**: em vez de modificar os serviços instalados nos nós, você pode usar os DaemonSets do Kubernetes. Os DaemonSets são projetados para serem gerenciados pelo Kubernetes, mas executados em todos os nós no cluster. Dessa forma, você pode adicionar serviços especiais para monitorar ou supervisionar os nós.
+ **NodePools e NodeClasses personalizados**: os NodePools e NodeClasses padrão são configurados pelo modo automático do EKS e não devem ser editados diretamente. Para personalizar o comportamento do nó, você pode criar NodePools ou NodeClasses adicionais para casos de uso como:
+ Selecionar tipos de instância específicos (por exemplo, processadores acelerados ou instâncias spot do EC2).
+ Isolar workloads para fins de segurança ou rastreamento de custos.
+ Configurar definições de armazenamento efêmero como IOPS, tamanho e throughput.
+ **Balanceamento de carga**: alguns serviços, como balanceamento de carga, que o Modo Automático do EKS executa como objetos do Kubernetes, podem ser configurados diretamente nos clusters do Modo Automático do EKS.
Para obter mais informações sobre as opções de configuração do Modo Automático do EKS, consulte [Configurar as configurações do modo automático do EKS](settings-auto.md).
## Modelo de responsabilidade compartilhada
O Modelo de responsabilidade compartilhada da AWS define as responsabilidades de segurança e conformidade entre a AWS e os clientes. As imagens e o texto abaixo comparam e contrastam como as responsabilidades do cliente e da AWS diferem entre o Modo Automático do EKS e o modo padrão do EKS.
![\[Modelo de responsabilidade compartilhada com o Modo Automático e o modo padrão do EKS\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/eksautosrm.png)
O Modo Automático do EKS transfere grande parte da responsabilidade compartilhada pela infraestrutura do Kubernetes dos clientes para a AWS. Com o Modo Automático do EKS , a AWS assume mais responsabilidade pela segurança na nuvem, que antes era responsabilidade do cliente e agora é compartilhada. Agora, os clientes podem se concentrar mais em suas aplicações enquanto a AWS gerencia a infraestrutura subjacente.
**Responsabilidade do cliente**
No Modo Automático do EKS, os clientes continuam a manter a responsabilidade pelos contêineres de aplicações, incluindo disponibilidade, segurança e monitoramento. Eles também mantêm o controle sobre a infraestrutura da VPC e a configuração do cluster de EKS. Esse modelo permite que os clientes se concentrem nas preocupações específicas da aplicação enquanto delegam o gerenciamento da infraestrutura de cluster para a AWS. Recursos opcionais por nó podem ser incluídos em clusters por meio de complementos da AWS.
** AWS Responsabilidade da**
Com o Modo Automático do EKS , a AWS expande sua responsabilidade para incluir o gerenciamento de vários componentes críticos adicionais em comparação com aqueles já gerenciados em clusters de EKS que não usem o Modo Automático. Em particular, o Modo Automático do EKS assume a configuração, o gerenciamento, a segurança e o ajuste de escala das instâncias do EC2 lançadas, bem como os recursos de cluster para balanceamento de carga, gerenciamento de endereços IP, política de rede e armazenamento em blocos. Os componentes a seguir são gerenciados pela AWS no Modo Automático do EKS:
+ **Instâncias EC2 lançadas no Modo Automático**: a AWS gerencia o ciclo de vida completo dos nós utilizando as instâncias gerenciadas do Amazon EC2. As instâncias gerenciadas do EC2 são responsáveis pela configuração, aplicação de patches, monitoramento e manutenção da integridade do sistema operacional. Nesse modelo, tanto a instância em si quanto o sistema operacional convidado em execução nela são de responsabilidade da AWS. Os nós usam variantes das AMIs do [Bottlerocket](https://aws.amazon.com/bottlerocket) que são otimizadas para executar contêineres. As AMIs da Bottlerocket têm software bloqueado, sistemas de arquivos raiz imutáveis e acesso seguro à rede (para evitar comunicações diretas por meio de SSH ou SSM).
+ **Capacidades de cluster**: a AWS gerencia o ajuste de escala automático da computação, redes de pod com aplicação de políticas de rede, integração com o Elastic Load Balancing e configuração de drivers de armazenamento.
+ **Plano de controle de cluster**: a AWS continua gerenciando o servidor da API Kubernetes, os ENIs entre contas e o banco de dados etcd, como no EKS padrão.
+ **Serviços básicos e Infraestrutura global**: a AWS mantém a responsabilidade pelos serviços subjacentes de computação, armazenamento, rede e monitoramento, bem como pela infraestrutura global de regiões, zonas locais e locais da borda.
# Criação de um cluster com o modo automático do Amazon EKS
Este capítulo explica como criar um cluster do Amazon EKS com o Modo Automático habilitado usando várias ferramentas e interfaces. O Modo Automático simplifica a criação de clusters configurando e gerenciando automaticamente a infraestrutura de computação, rede e armazenamento do cluster. Você aprenderá a criar um cluster do Modo Automático usando a AWS CLI, o Console de gerenciamento da AWS ou a ferramenta de linha de comandos do eksctl.
**nota**
O Modo Automático do EKS requer a versão 1.29 ou superior do Kubernetes.
Escolha a ferramenta de preferência com base em suas necessidades: o Console de gerenciamento da AWS fornece uma interface visual ideal para aprender sobre os recursos do Modo Automático do EKS e criar clusters individuais. A AWS CLI é mais adequada para tarefas de script e automação, especialmente ao integrar a criação de clusters em fluxos de trabalho ou pipelines de CI/CD existentes. A CLI do eksctl oferece uma experiência nativa do Kubernetes e é recomendada para usuários familiarizados com as ferramentas do Kubernetes que desejam operações de linha de comando simplificadas com padrões adequados.
Antes de começar, verifique se você tem os pré-requisitos necessários instalados e configurados, incluindo as permissões apropriadas do IAM para criar clusters do EKS. Para saber como instalar ferramentas da CLI, como `kubectl`, `aws` e `eksctl`, consulte [Configurar para usar o Amazon EKS](setting-up.md).
Você pode usar a AWS CLI, o Console de gerenciamento da AWS ou a CLI do eksctl para criar um cluster com o Modo Automático do Amazon EKS.
**Topics**
+ [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)
# Criar um cluster do Modo Automático do EKS com a CLI do eksctl
Este tópico mostra como criar um cluster do Modo Automático do Amazon EKS usando a interface de linha de comandos (CLI) do eksctl. Você pode criar um cluster do Modo Automático executando um único comando da CLI ou aplicando um arquivo de configuração YAML. Ambos os métodos fornecem a mesma funcionalidade, com a abordagem de YAML oferecendo um controle mais granular das configurações do cluster.
A CLI do eksctl simplifica o processo de criação e gerenciamento de clusters do Modo Automático do EKS ao lidar com a criação e configuração de recursos subjacentes da AWS. Antes de prosseguir, certifique-se de ter as credenciais e permissões da AWS necessárias configuradas na máquina local. Este guia pressupõe que você esteja familiarizado com os conceitos básicos do Amazon EKS e já tenha instalado as ferramentas de CLI necessárias.
**nota**
Você deve instalar a versão `0.195.0` ou superior do eksctl. Para obter mais informações, consulte as [versões do eksctl](https://github.com/eksctl-io/eksctl/releases) no GitHub.
## Criar um cluster do Modo Automático do EKS com um comando da CLI
Você deve ter as ferramentas da `aws` e do `eksctl` instaladas. Você deve estar conectado à AWS CLI com permissões suficientes para gerenciar recursos da AWS, incluindo: instâncias do EC2, redes do EC2, clusters do EKS e perfis do IAM. Para ter mais informações, consulte [Configurar para usar o Amazon EKS](setting-up.md).
Execute o comando a seguir para criar um cluster do Modo Automático do EKS com
```
eksctl create cluster --name= --enable-auto-mode
```
## Crie um cluster do Modo Automático do EKS com um arquivo YAML
Você deve ter as ferramentas da `aws` e do `eksctl` instaladas. Você deve estar conectado à AWS CLI com permissões suficientes para gerenciar recursos da AWS, incluindo: instâncias do EC2, redes do EC2, clusters do EKS e perfis do IAM. Para ter mais informações, consulte [Configurar para usar o Amazon EKS](setting-up.md).
Analise as opções de configuração do Modo Automático do EKS no exemplo do recurso ClusterConfig abaixo. Para conferir a especificação completa do ClusterConfig, consulte a [documentação do eksctl](https://eksctl.io/usage/creating-and-managing-clusters/).
AWS sugere habilitar o Modo Automático do EKS. Se esta for a primeira vez que você cria um cluster do Modo Automático do EKS, deixe o `nodeRoleARN` não especificado criar um perfil do IAM do nó para o Modo Automático do EKS. Caso já tenha um perfil do IAM do nó na conta da AWS, a AWS sugere reutilizá-la.
AWS sugere não especificar nenhum valor para `nodePools`. O Modo Automático do EKS criará grupos de nós padrão. Você pode usar a API do Kubernetes para criar grupos de nós adicionais.
```
# cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name:
region:
iam:
# ARN of the Cluster IAM Role
# optional, eksctl creates a new role if not supplied
# suggested to use one Cluster IAM Role per account
serviceRoleARN:
autoModeConfig:
# defaults to false
enabled: boolean
# optional, defaults to [general-purpose, system].
# suggested to leave unspecified
# To disable creation of nodePools, set it to the empty array ([]).
nodePools: []string
# optional, eksctl creates a new role if this is not supplied
# and nodePools are present.
nodeRoleARN: string
```
Salve o arquivo `ClusterConfig` como `cluster.yaml` e use o seguinte comando para criar o cluster:
```
eksctl create cluster -f cluster.yaml
```
# Criar um cluster do Modo Automático do EKS com a AWS CLI
Os clusters de modo automático do EKS automatizam as tarefas de rotina de gerenciamento de clusters para computação, armazenamento e rede. Por exemplo, os clusters do Modo Automático do EKS detectam automaticamente quando nós adicionais são necessários e provisionam novas instâncias do EC2 para atender às demandas de workloads.
Este tópico orienta você na criação de um novo cluster do Modo Automático do EKS usando a AWS CLI e, opcionalmente, na implantação de uma workload de exemplo.
## Pré-requisitos
+ A versão mais recente da AWS Command Line Interface (AWS CLI) instalada e configurada no seu dispositivo. Para verificar sua versão atual, use `aws --version`. Para instalar a versão mais recente, consulte [Instalar](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) e [Configuração rápida com aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config), no Guia do usuário da AWS Command Line Interface.
+ Faça login na CLI com permissões suficientes do IAM para criar recursos da AWS, incluindo políticas do IAM, perfis do IAM e clusters do EKS.
+ A ferramenta de linha de comando do kubectl instalada no dispositivo. A AWS sugere que você use a mesma versão do kubectl que a versão do Kubernetes do cluster do EKS. Para instalar ou atualizar o kubectl, consulte [Configurar o `kubectl` e o `eksctl`](install-kubectl.md).
## Especificar sub-redes da VPC
O Modo Automático do Amazon EKS implanta nós em sub-redes da VPC. Ao criar um cluster do EKS, você deve especificar as sub-redes da VPC nas quais os nós serão implantados. Você pode usar as sub-redes da VPC padrão na conta da AWS ou criar uma VPC dedicada para workloads críticas.
+ A AWS sugere a criação de uma VPC dedicada para o cluster. Saiba como [Criar uma Amazon VPC para o cluster do Amazon EKS](creating-a-vpc.md).
+ O console do EKS ajuda na criação de uma nova VPC. Saiba como [Criar um cluster do Modo Automático do EKS com o Console de gerenciamento da AWS](automode-get-started-console.md).
+ Como alternativa, você pode usar a VPC padrão da conta da AWS. Use as instruções a seguir para encontrar os IDs de sub-rede.
### Para encontrar os IDs de sub-redes da VPC padrão
**Usar a AWS CLI:**
1. Execute o comando a seguir para listar a VPC padrão e suas sub-redes:
```
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$(aws ec2 describe-vpcs --query 'Vpcs[?IsDefault==`true`].VpcId' --output text)" --query 'Subnets[*].{ID:SubnetId,AZ:AvailabilityZone}' --output table
```
1. Salve a saída e anote os **IDs das sub-redes**.
Exemplo de resultado:
```
----------------------------------------
| DescribeSubnets |
----------------------------------------
| SubnetId | AvailabilityZone |
|--------------------|---------------------|
| subnet-012345678 | us-west-2a |
| subnet-234567890 | us-west-2b |
| subnet-345678901 | us-west-2c |
----------------------------------------
```
## Perfis do IAM de clusters do Modo Automático do EKS
### Perfil do IAM do cluster
O Modo Automático do EKS exige um perfil do IAM do cluster para realizar ações na conta da AWS, como provisionar novas instâncias do EC2. Você deve criar esse perfil para conceder ao EKS as permissões necessárias. A AWS recomenda anexar as seguintes políticas gerenciadas pela AWS ao perfil do IAM do cluster:
+ [AmazonEKSComputePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [AmazonEKSNetworkingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
### Perfil do IAM do nó
Ao criar um cluster do Modo Automático do EKS, você especifica um perfil do IAM do nó. Quando o Modo Automático do EKS cria nós para processar workloads pendentes, cada novo nó de instância do EC2 recebe o perfil do IAM do nó. Esse perfil permite que o nó se comunique com o EKS, mas geralmente não é acessado pelas workloads em execução no nó.
Se você quiser conceder permissões para workloads em execução em um nó, use a Identidade de Pods do EKS. Para obter mais informações, consulte [Saiba como a Identidade de Pods do EKS concede aos pods acesso aos serviços da AWS](pod-identities.md).
Você deve criar esse perfil e anexar a seguinte política gerenciada pela AWS:
+ [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
O Modo Automático do EKS também requer um perfil vinculado ao serviço, que é criado e configurado automaticamente pela AWS. Para obter mais informações, consulte [AWSServiceRoleForAmazonEKS](using-service-linked-roles-eks.md).
## 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
```
## Criar um cluster do Modo Automático do EKS
### Visão geral
Para criar um cluster de Modo Automático do EKS usando a AWS CLI, você precisará dos seguintes parâmetros:
+ `cluster-name`: o nome do cluster.
+ `k8s-version`: a versão do Kubernetes (por exemplo, 1.31).
+ `subnet-ids`: IDs de sub-rede identificados nas etapas anteriores.
+ `cluster-role-arn`: ARN do perfil do IAM do cluster.
+ `node-role-arn`: ARN do perfil do IAM do nó.
#### Configurações padrão do cluster
Analise estes valores e recursos padrão antes de criar o cluster:
+ `nodePools`: o Modo Automático do EKS inclui grupos de nós de uso geral e padrão do sistema. Saiba mais sobre [Grupos de nós](create-node-pool.md).
**Observação:** os grupos de nós no Modo Automático do EKS diferem dos grupos dos nós gerenciados pelo Amazon EKS, mas podem coexistir no mesmo cluster.
+ `computeConfig.enabled`: automatiza tarefas computacionais de rotina, como criar e excluir instâncias do EC2.
+ `kubernetesNetworkConfig.elasticLoadBalancing.enabled`: automatiza as tarefas de balanceamento de carga, incluindo a criação e exclusão de Elastic Load Balancers.
+ `storageConfig.blockStorage.enabled`: automatiza tarefas de armazenamento, como criar e excluir volumes do Amazon EBS.
+ `accessConfig.authenticationMode`: requer entradas de acesso do EKS. Saiba mais sobre os [modos de autenticação do EKS](grant-k8s-access.md).
#### Executar o comando
Use o seguinte comando para criar o cluster:
```
aws eks create-cluster \
--region ${AWS_REGION} \
--cli-input-json \
"{
\"name\": \"${CLUSTER_NAME}\",
\"version\": \"${K8S_VERSION}\",
\"roleArn\": \"${CLUSTER_ROLE_ARN}\",
\"resourcesVpcConfig\": {
\"subnetIds\": ${SUBNETS_JSON},
\"endpointPublicAccess\": true,
\"endpointPrivateAccess\": true
},
\"computeConfig\": {
\"enabled\": true,
\"nodeRoleArn\":\"${NODE_ROLE_ARN}\",
\"nodePools\": [\"general-purpose\", \"system\"]
},
\"kubernetesNetworkConfig\": {
\"elasticLoadBalancing\": {
\"enabled\": true
}
},
\"storageConfig\": {
\"blockStorage\": {
\"enabled\": true
}
},
\"accessConfig\": {
\"authenticationMode\": \"API\"
}
}"
```
### Verificar o status do cluster
#### Etapa 1: verificar a criação do cluster
Execute o comando a seguir para verificar o status do cluster. A criação do cluster normalmente leva cerca de 15 minutos.
```
aws eks describe-cluster --name "${CLUSTER_NAME}" --output json
```
#### Etapa 2: atualizar o kubeconfig
Quando o cluster estiver pronto, atualize o arquivo kubeconfig local para permitir que o `kubectl` se comunique com o cluster. Esta configuração usa a AWS CLI para autenticação.
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
#### Etapa 3: verificar grupos de Node
Listar os grupos de nós no cluster com o comando a seguir:
```
kubectl get nodepools
```
## Próximas etapas
+ Saiba como [implantar uma workload de exemplo](automode-workload.md) no novo cluster do Modo Automático do EKS.
# Criar um cluster do Modo Automático do EKS com o Console de gerenciamento da AWS
Criar um cluster do Modo Automático do EKS no Console de gerenciamento da AWS requer menos configuração do que outras opções. O EKS se integra ao AWS IAM e à rede de VPC para ajudar a criar os recursos associados a um cluster do EKS.
Você tem duas opções para criar um cluster no console:
+ Configuração rápida (com o Modo Automático do EKS)
+ Configuração personalizada
Neste tópico, você aprenderá como criar um cluster do Modo Automático do EKS usando a opção Configuração rápida.
## Criar um Modo Automático do EKS usando a opção de configuração rápida
Você deve estar conectado ao Console de gerenciamento da AWS com permissões suficientes para gerenciar recursos da AWS, incluindo: instâncias do EC2, redes do EC2, clusters do EKS e perfis do IAM.
1. Navegue até o console do EKS.
1. Clique em **Criar cluster**.
1. Confirme se a opção **Configuração rápida** está selecionada.
1. Determine os valores a seguir ou use os padrões para um cluster de teste.
+ **Nome** do cluster
+ Versão do Kubernetes
1. Selecione o perfil do IAM do cluster. Se esta for a primeira vez que você cria um cluster do Modo Automático do EKS, use a opção **Criar perfil recomendado**.
+ Opcionalmente, você pode reutilizar um único perfil do IAM do cluster na conta da AWS para todos os clusters do Modo Automático do EKS.
+ O perfil do IAM do cluster inclui as permissões necessárias para o Modo Automático do EKS gerenciar recursos, incluindo instâncias do EC2, volumes do EBS e balanceadores de carga do EC2.
+ A opção **Criar perfil recomendado** preenche previamente todos os campos com valores recomendados. Selecione **Próximo** e, em seguida, **Criar**. O perfil usará o nome `AmazonEKSAutoClusterRole` sugerido.
+ Se você criou recentemente um novo perfil, use o ícone de **Atualizar** para recarregar a lista suspensa de seleção de perfis.
1. Selecione o perfil do IAM do nó. Se esta for a primeira vez que você cria um cluster do Modo Automático do EKS, use a opção **Criar perfil recomendado**.
+ Opcionalmente, você pode reutilizar um único perfil do IAM do nó na conta da AWS para todos os clusters do Modo Automático do EKS.
+ O perfil do IAM do nó inclui as permissões necessárias para que os nós do Modo Automático se conectem ao cluster. O perfil do IAM do nó deve incluir permissões para recuperar imagens do ECR para os contêineres.
+ A opção **Criar perfil recomendado** preenche previamente todos os campos com valores recomendados. Selecione **Próximo** e, em seguida, **Criar**. O perfil usará o nome `AmazonEKSAutoNodeRole` sugerido.
+ Se você criou recentemente um novo perfil, use o ícone de **Atualizar** para recarregar a lista suspensa de seleção de perfis.
1. Selecione a VPC para o cluster do Modo Automático do EKS. Escolha **Criar VPC** para criar uma VPC para o EKS, ou escolha uma VPC que você criou anteriormente para o EKS.
+ Se você usar o console da VPC para criar uma VPC, a AWS sugere que você crie pelo menos um gateway NAT por zona de disponibilidade. Do contrário, você pode usar todos os outros padrões.
+ Para obter mais informações e detalhes sobre os requisitos do cluster IPv6, consulte [Criar uma Amazon VPC para o cluster do Amazon EKS](creating-a-vpc.md).
1. (opcional) O Modo Automático do EKS preenche automaticamente as sub-redes privadas da VPC selecionada. Você pode remover as sub-redes indesejadas.
+ O EKS seleciona automaticamente sub-redes privadas da VPC seguindo as práticas recomendadas. Opcionalmente, você pode selecionar sub-redes adicionais da VPC, como sub-redes públicas.
1. (opcional) Selecione **Visualizar padrões de configuração rápida** para analisar todos os valores de configuração do novo cluster. A tabela indica que alguns valores não são editáveis após a criação do cluster.
1. Selecione **Create cluster** (Criar cluster). Observe que a conclusão da criação do cluster pode levar quinze minutos.
## Próximas etapas
+ Saiba como [implantar uma workload de exemplo no cluster do Modo Automático do EKS](sample-storage-workload.md)
# Habilitar o Modo Automático do EKS em clusters existentes do EKS
Você pode habilitar o Modo Automático do EKS em clusters existentes do EKS.
**A AWS oferece suporte às seguintes migrações:**
+ Migração do Karpenter para os nós do Modo Automático do EKS. Para obter mais informações, consulte [Migrar do Karpenter para o Modo Automático do EKS usando o kubectl](auto-migrate-karpenter.md).
+ Migração dos grupos de nós gerenciados pelo EKS para os nós do Modo Automático do EKS. Para obter mais informações, consulte [Migrar dos grupos de nós gerenciados pelo EKS para o Modo Automático do EKS](auto-migrate-mng.md).
+ Migração do EKS Fargate para o Modo Automático do EKS. Para obter mais informações, consulte [Migrar do EKS Fargate para o Modo Automático do EKS](auto-migrate-fargate.md).
**A AWS não oferece suporte às seguintes migrações:**
+ Migração de volumes do controlador EBS CSI (usando o complemento do Amazon EKS) para o controlador EBS CSI para o Modo Automático do EKS (gerenciado pelo Modo Automático do EKS). Os PVCs realizados com um não podem ser montados pelo outro, porque usam dois provisionadores de volume diferentes do Kubernetes.
+ O [https://github.com/awslabs/eks-auto-mode-ebs-migration-tool](https://github.com/awslabs/eks-auto-mode-ebs-migration-tool) (projeto AWS Labs) permite a migração entre o EBS CSI StorageClass padrão (`ebs.csi.aws.com`) e o EKS Auto EBS CSI StorageClass (`ebs.csi.eks.amazonaws.com`). Observe que a migração exige a exclusão e a recriação dos recursos existentes de PersistentVolumeClaim/PersistentVolume, portanto, a validação em um ambiente que não seja de produção é essencial antes da implementação.
+ Migrar balanceadores de carga do AWS Load Balancer Controller para o Modo Automático do EKS
Você pode instalar o AWS Load Balancer Controller em um cluster do Modo Automático do Amazon EKS. Use as opções `IngressClass` ou `loadBalancerClass` para associar recursos de serviço e entrada ao Load Balancer Controller ou ao Modo Automático do EKS.
+ Migração de clusters do EKS com CNIs alternativas ou outras configurações de rede não compatíveis
## Referência de migração
Use a referência de migração a seguir para configurar recursos do Kubernetes para serem de propriedade de controladores autogerenciados ou do Modo Automático do EKS.
| Recurso | Recurso | Campo | Autogerenciado | Modo Automático do EKS |
| --- | --- | --- | --- | --- |
| Armazenamento em bloco | `StorageClass` | `provisioner` | `ebs.csi.aws.com` | `ebs.csi.eks.amazonaws.com` |
| Balanceamento de carga | `Service` | `loadBalancerClass` | `service.k8s.aws/nlb` | `eks.amazonaws.com/nlb` |
| Balanceamento de carga | `IngressClass` | `controller` | `ingress.k8s.aws/alb` | `eks.amazonaws.com/alb` |
| Balanceamento de carga | `IngressClassParams` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| Balanceamento de carga | `TargetGroupBinding` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| Computação | `NodeClass` | `apiVersion` | `karpenter.sh/v1` | `eks.amazonaws.com/v1` |
## Migração de volumes do EBS
Ao migrar workloads para o Modo Automático do EKS, você precisa lidar com a migração de volumes do EBS devido aos diferentes provisionadores de drivers CSI:
+ Provisionador do Modo Automático do EKS: `ebs.csi.eks.amazonaws.com`
+ Provisionador do EBS CSI de código aberto: `ebs.csi.aws.com`
Siga estas etapas para migrar os volumes persistentes:
1. **Modifique a política de retenção de volume**: altere a versão existente da plataforma (PV) `persistentVolumeReclaimPolicy` para `Retain` para garantir que o volume subjacente do EBS não seja excluído.
1. **Remova o PV do Kubernetes**: exclua o recurso PV antigo enquanto mantém o volume real do EBS intacto.
1. **Crie um novo PV com provisionamento estático**: crie um novo PV que faça referência ao mesmo volume do EBS, mas que funcione com o driver CSI de destino.
1. **Vincular a um novo PVC**: crie um novo PVC que faça referência específica ao seu PV usando o campo `volumeName`.
### Considerações
+ Certifique-se de que suas aplicações sejam interrompidas antes de iniciar a migração.
+ Faça backup dos dados antes de iniciar o processo de migração.
+ Esse processo precisa ser executado para cada volume persistente.
+ A workload deve ser atualizada para usar o novo PVC.
## Migração de balanceadores de carga
Você não pode transferir diretamente os balanceadores de carga existentes do controlador autogerenciado de balanceadores de carga da AWS para o Modo Automático do EKS. Em vez disso, você deve implementar uma estratégia de implantação azul/verde. Isso envolve manter a configuração atual do balanceador de carga enquanto cria balanceadores de carga no controlador gerenciado.
Para minimizar a interrupção do serviço, recomendamos uma abordagem de mudança de tráfego baseada em DNS. Primeiro, crie balanceadores de carga usando o Modo Automático do EKS, mantendo a configuração operacional existente. Em seguida, use o roteamento de DNS (como o Route 53) para transferir gradualmente o tráfego dos balanceadores de carga antigos para os novos. Depois que o tráfego tiver sido migrado com êxito e você tiver verificado a nova configuração, será possível desativar os balanceadores de carga antigos e o controlador autogerenciado.
# Habilitar o Modo Automático do EKS em um cluster existente
Este tópico descreve como habilitar o Modo Automático do EKS nos clusters existentes no Amazon EKS. Habilitar o Modo Automático em um cluster existente requer a atualização das permissões do IAM e a configuração das principais configurações do Modo Automático do EKS. Depois de habilitado, você pode começar a migrar as workloads computacionais existentes para aproveitar as operações simplificadas e o gerenciamento automatizado da infraestrutura do Modo Automático.
**Importante**
Verifique se você tem a versão mínima necessária de determinados complementos do Amazon EKS instalada antes de habilitar o Modo Automático do EKS. Para obter mais informações, consulte [Versões de complementos necessárias](#auto-addons-required).
Antes de começar, certifique-se de ter acesso de administrador ao seu cluster do Amazon EKS e permissões para modificar os perfis do IAM. As etapas neste tópico orientam você a habilitar o Modo Automático usando o Console de gerenciamento da AWS ou a AWS CLI.
## Console de gerenciamento da AWS
Você deve estar conectado ao Console da AWS com permissão para gerenciar recursos do IAM, EKS e EC2.
**nota**
O perfil do IAM do cluster de um cluster do EKS não pode ser alterado após a criação do cluster. O Modo Automático do EKS requer permissões adicionais nesse perfil. Você deve anexar políticas adicionais ao perfil atual.
### Atualizar perfil do IAM do cluster
1. Abra a página de visão geral do cluster no Console de gerenciamento da AWS.
1. Em **ARN do perfil do IAM do cluster**, selecione **Visualizar no IAM**.
1. Na lista suspensa **Adicionar permissões**, selecione **Anexar políticas**.
1. Use a caixa **Pesquisar** para encontrar e selecionar as seguintes políticas:
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
1. Selecione **Adicionar permissões**.
1. Na guia **Relacionamentos de confiança**, selecione **Editar política de confiança**.
1. Insira a política de confiança a seguir do perfil do IAM do cluster e selecione **Atualizar política**
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### Habilitar o Modo Automático do EKS
1. Abra a página de visão geral do cluster no Console de gerenciamento da AWS.
1. Em **Modo Automático do EKS**, selecione **Gerenciar**.
1. Alterne o **Modo Automático do EKS** para ativado.
1. No menu suspenso **Grupo de nós do EKS**, selecione os grupos de nós padrão que você deseja criar.
+ Saiba mais sobre grupos de nós no Modo Automático do EKS. Para obter mais informações, consulte [Criar um grupo de nós para o Modo Automático do EKS](create-node-pool.md).
1. Se você já criou um perfil do IAM do nó do Modo Automático do EKS nesta conta da AWS, selecione-a no menu suspenso **Perfil do IAM do nó**. Se você ainda não criou esse perfil, selecione **Criar perfil recomendado** e siga as etapas.
## AWS CLI
### Pré-requisitos
+ O perfil do IAM do cluster do cluster existente do EKS deve incluir permissões suficientes para o Modo Automático do EKS, como as seguintes políticas:
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
+ O perfil do IAM do cluster deve ter uma política de confiança atualizada, incluindo a ação `sts:TagSession`. Para obter mais informações sobre como criar um perfil do IAM do cluster, consulte [Criar um cluster do Modo Automático do EKS com a AWS CLI](automode-get-started-cli.md).
+ `aws` CLI instalada, com login efetuado e em uma versão suficiente. Você deve ter permissão para gerenciar recursos do IAM, EKS e EC2. Para obter mais informações, consulte [Configurar para usar o Amazon EKS](setting-up.md).
### Procedimento
Use os comandos a seguir para habilitar o Modo Automático do EKS em um cluster existente.
**nota**
Os recursos de computação, armazenamento em blocos e balanceamento de carga devem estar todos habilitados ou desabilitados na mesma solicitação.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=true \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{"blockStorage":{"enabled": true}}'
```
## Versões de complementos necessárias
Se você planeja habilitar o Modo Automático do EKS em um cluster existente, talvez seja necessário atualizar alguns complementos. Observação:
+ Isso se aplica somente aos clusters existentes em transição para o Modo Automático do EKS.
+ Novos clusters criados com o Modo Automático do EKS habilitado não exigem essas atualizações.
Se você tiver algum dos seguintes complementos instalados, verifique se eles estão pelo menos na versão mínima especificada:
| Nome do complemento | Versão mínima necessária |
| --- | --- |
| Plug-in CNI da Amazon VPC para Kubernetes | v1.19.0-eksbuild.1 |
| Kube-proxy | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/auto-enable-existing.html) |
| Driver da CSI do Amazon EBS | v1.37.0-eksbuild.1 |
| Controlador de snapshots da CSI | v8.1.0-eksbuild.2 |
| Atendente de Identidade de Pods do EKS | v1.3.4-eksbuild.1 |
Para obter mais informações, consulte [Atualizar um complemento do Amazon EKS](updating-an-add-on.md).
## Próximas etapas
+ Para migrar as workloads de Gerenciar grupos de nós, consulte [Migrar dos grupos de nós gerenciados pelo EKS para o Modo Automático do EKS](auto-migrate-mng.md).
+ Para migrar do Karpenter autogerenciado, consulte [Migrar do Karpenter para o Modo Automático do EKS usando o kubectl](auto-migrate-karpenter.md).
# Migrar do Karpenter para o Modo Automático do EKS usando o kubectl
Este tópico orienta você pelo processo de migração de workloads do Karpenter para o Modo Automático do Amazon EKS usando o kubectl. A migração pode ser realizada gradualmente, permitindo que você mova as workloads no seu próprio ritmo, mantendo a estabilidade do cluster e a disponibilidade das aplicações durante a transição.
A abordagem passo a passo descrita abaixo permite que você execute o Karpenter e o Modo Automático do EKS lado a lado durante o período de migração. Essa estratégia de operação dupla ajuda a garantir uma transição suave, permitindo que você valide o comportamento da workload no Modo Automático do EKS antes de desativar completamente o Karpenter. Você pode migrar aplicações individualmente ou em grupos, oferecendo flexibilidade para acomodar seus requisitos operacionais específicos e a tolerância a riscos.
## Pré-requisitos
Antes de iniciar a migração, verifique se você tem:
+ Karpenter v1.1 ou posterior instalado no cluster. Para obter mais informações, consulte [Upgrading to 1.1.0\$1](https://karpenter.sh/docs/upgrading/upgrade-guide/#upgrading-to-110) na documentação do Karpenter.
+ `kubectl` instalado e conectado ao cluster. Para obter mais informações, consulte [Configurar para usar o Amazon EKS](setting-up.md).
Este tópico pressupõe que você esteja familiarizado com o Karpenter e NodePools. Para obter mais informações, consulte a [documentação do Karpenter.](https://karpenter.sh/)
## Etapa 1: habilitar o modo automático do EKS no cluster
Habilite o Modo Automático do EKS no cluster existente usando a CLI ou o Console de Gerenciamento da AWS. Para obter mais informações, consulte [Habilitar o Modo Automático do EKS em um cluster existente](auto-enable-existing.md).
**nota**
Ao ativar o Modo Automático do EKS, não habilite o nodepool `general purpose` neste estágio durante a transição. Esse grupo de nós não é seletivo.
Para obter mais informações, consulte [Habilitar ou desabilitar NodePools integrados](set-builtin-node-pools.md).
## Etapa 2: criar um NodePool com taint do Modo Automático do EKS
Crie um NodePool para o Modo Automático do EKS com um taint. Isso garante que os pods existentes não sejam programados automaticamente nos novos nós do Modo Automático do EKS. Esse grupo de nós usa o `NodeClass` `default` criado no Modo Automático do EKS. Para obter mais informações, consulte [Criar uma classe de nó para o Amazon EKS](create-node-class.md).
Exemplo de grupo de nós com taint:
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
taints:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
Atualize os requisitos do grupo de nós para que correspondam à configuração do Karpenter da qual você está migrando. Você precisa de pelo menos um requisito.
## Etapa 3: atualizar workloads para migração
Identifique e atualize as workloads que você deseja migrar para o Modo Automático do EKS. Adicione tolerâncias e seletores de nós às workloads:
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
Essa alteração permite que a workload seja programada nos novos nós do Modo Automático do EKS.
O Modo Automático do EKS usa rótulos diferentes do Karpenter. Os rótulos relacionados às instâncias gerenciadas pelo EC2 começam com `eks.amazonaws.com`. Para obter mais informações, consulte [Criar um grupo de nós para o Modo Automático do EKS](create-node-pool.md).
## Etapa 4: migrar gradualmente as workloads
Repita a Etapa 3 para cada workload que você deseja migrar. Isso permite que você mova workloads individualmente ou em grupos, com base nos requisitos e tolerância a riscos.
## Etapa 5: remover o NodePool original do Karpenter
Depois que todas as workloads tiverem sido migradas, você poderá remover o NodePool original do Karpenter:
```
kubectl delete nodepool
```
## Etapa 6: remover o taint do NodePool do Modo Automático do EKS (opcional)
Se você quiser que o Modo Automático do EKS se torne o padrão para novas workloads, você pode remover o taint do NodePool do Modo Automático do EKS:
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
# Remove the taints section
```
## Etapa 7: remover os seletores de nós das workloads (opcional)
Se você removeu o taint do NodePool do Modo Automático do EKS, você pode, opcionalmente, remover os seletores de nós das workloads, já que o Modo Automático do EKS agora é o padrão:
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
# Remove the nodeSelector section
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
## Etapa 8: desinstalar o Karpenter do cluster
As etapas para remover o Karpenter dependem de como você o instalou. Para obter mais informações, consulte as [instruções de instalação do Karpenter](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#create-a-cluster-and-add-karpenter).
# Migrar dos grupos de nós gerenciados pelo EKS para o Modo Automático do EKS
Ao fazer a transição do cluster do Amazon EKS para usar o Modo Automático do EKS, você pode migrar facilmente as workloads existentes de grupos de nós gerenciados (MNGs) usando a ferramenta eksctl da CLI. Esse processo garante a disponibilidade contínua da aplicação, enquanto o Modo Automático do EKS otimiza os recursos computacionais. A migração pode ser realizada com o mínimo de interrupção nas aplicações em execução.
Este tópico mostra as etapas para drenar com segurança os pods dos grupos de nós gerenciados existentes e permitir que o Modo Automático do EKS os reprograme em instâncias recém-provisionadas. Seguindo esse procedimento, você pode aproveitar a consolidação inteligente de workloads do Modo Automático do EKS e, ao mesmo tempo, manter a disponibilidade da aplicação durante a migração.
## Pré-requisitos
+ Cluster com o Modo Automático do EKS habilitado
+ `eksctl` CLI instalada e conectada ao cluster. Para obter mais informações, consulte [Configurar para usar o Amazon EKS](setting-up.md).
+ O Karpenter não está instalado no cluster.
## Procedimento
Use o comando `eksctl` da CLI a seguir para iniciar a drenagem de pods das instâncias existentes do grupo de nós gerenciados. O Modo Automático do EKS criará nós para dar suporte aos pods deslocados.
```
eksctl delete nodegroup --cluster= --name=
```
Você precisará executar esse comando para cada grupo de nós gerenciados no cluster.
Para obter mais informações sobre esse comando, consulte [Deleting and draining nodegroups](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups) na documentação do eksctl.
# Migrar do EKS Fargate para o Modo Automático do EKS
Este tópico orienta você pelo processo de migração de workloads do EKS Fargate para o Modo Automático do Amazon EKS usando o `kubectl`. A migração pode ser realizada gradualmente, permitindo que você mova as workloads no seu próprio ritmo, mantendo a estabilidade do cluster e a disponibilidade das aplicações durante a transição.
A abordagem passo a passo descrita abaixo permite que você execute o EKS Fargate e o Modo Automático do EKS lado a lado durante o período de migração. Essa estratégia de operação dupla ajuda a garantir uma transição suave, permitindo que você valide o comportamento da workload no Modo Automático do EKS antes de desativar completamente o EKS Fargate. É possível migrar aplicações individualmente ou em grupos, oferecendo flexibilidade para acomodar seus requisitos operacionais específicos e a tolerância a riscos.
## Comparação do Modo Automático do Amazon EKS com o EKS com o AWS Fargate
O Amazon EKS com o AWS Fargate continua sendo uma opção para os clientes que desejam executar o EKS, mas o Modo Automático do Amazon EKS é a abordagem recomendada no futuro. O Modo Automático do EKS é totalmente compatível com o Kubernetes, oferecendo suporte a todas as ferramentas de plataforma e primitivas upstream do Kubernetes, como o Istio, com o qual o Fargate não é compatível. O Modo Automático do EKS também tem compatibilidade total com todas as opções de compra de runtime do EC2, incluindo instâncias de GPU e spot, permitindo que os clientes aproveitem descontos negociados do EC2 e outros mecanismos de economia. Esses recursos não estão disponíveis ao usar o EKS com o Fargate.
Além disso, o Modo Automático do EKS permite que os clientes obtenham o mesmo modelo de isolamento do Fargate, usando recursos de programação padrão do Kubernetes para garantir que cada instância do EC2 execute um único contêiner de aplicação. Ao adotar o Modo Automático do EKS, os clientes podem aproveitar todos os benefícios de executar o Kubernetes na AWS: uma plataforma totalmente compatível com o Kubernetes que oferece a flexibilidade de aproveitar toda a gama de opções de compras e do EC2, preservando a facilidade de uso e a abstração do gerenciamento de infraestrutura que o Fargate oferece.
### Obtenção de isolamento semelhante ao do Fargate no Modo Automático do EKS
Para replicar o modelo de isolamento de pod do Fargate, em que cada pod é executado em sua própria instância dedicada, é possível usar as restrições de dispersão da topologia do Kubernetes. Esta é a abordagem recomendada para controlar a distribuição de pods entre os nós:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: isolated-app
minDomains: 1
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
Nesta configuração:
+ `maxSkew: 1` garante que a diferença na contagem de pods entre quaisquer dois nós seja no máximo 1, distribuindo efetivamente um pod por nó
+ `topologyKey: kubernetes.io/hostname` define o nó como o domínio da topologia
+ `whenUnsatisfiable: DoNotSchedule` impede a programação se a restrição não puder ser atendida
+ `minDomains: 1` garante que exista pelo menos um domínio (nó) antes da programação
O Modo Automático do EKS provisionará automaticamente novas instâncias do EC2 conforme necessário para satisfazer essa restrição, fornecendo o mesmo modelo de isolamento do Fargate e oferecendo acesso a toda a variedade de tipos de instâncias do EC2 e opções de compra.
Como alternativa, é possível usar as regras de antiafinidade do pod para um isolamento mais rígido:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- isolated-app
topologyKey: kubernetes.io/hostname
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
A regra `podAntiAffinity` com `requiredDuringSchedulingIgnoredDuringExecution` garante que dois pods com o rótulo `app: isolated-app` não possam ser programados no mesmo nó. Essa abordagem fornece garantias rígidas de isolamento semelhantes às do Fargate.
## Pré-requisitos
Antes de iniciar a migração, verifique se você tem:
+ Configure um cluster com o Fargate. Para obter mais informações, consulte [Comece a usar o AWS Fargate em seu cluster](fargate-getting-started.md).
+ O `kubectl` instalado e conectado ao cluster. Para obter mais informações, consulte [Configurar para usar o Amazon EKS](setting-up.md).
## Etapa 1: verificar o cluster do Fargate
1. Verifique se o cluster de EKS com o Fargate está em execução:
```
kubectl get node
```
```
NAME STATUS ROLES AGE VERSION
fargate-ip-192-168-92-52.ec2.internal Ready 25m v1.30.8-eks-2d5f260
fargate-ip-192-168-98-196.ec2.internal Ready 24m v1.30.8-eks-2d5f260
```
1. Verifique os pods em execução:
```
kubectl get pod -A
```
```
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-6659cb98f6-gxpjz 1/1 Running 0 26m
kube-system coredns-6659cb98f6-gzzsx 1/1 Running 0 26m
```
1. Crie uma implantação em um arquivo denominado `deployment_fargate.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: fargate
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. Aplique a implantação:
```
kubectl apply -f deployment_fargate.yaml
```
```
deployment.apps/nginx-deployment created
```
1. Confira os pods e as implantações:
```
kubectl get pod,deploy
```
```
NAME READY STATUS RESTARTS AGE
pod/nginx-deployment-5c7479459b-6trtm 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-g8ssb 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-mq4mf 1/1 Running 0 61s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-deployment 3/3 3 3 61s
```
1. Verifique o nó:
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
fargate-ip-192-168-111-43.ec2.internal Ready 31s v1.30.8-eks-2d5f260 192.168.111.43 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-117-130.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.117.130 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-74-140.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.74.140 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
```
## Etapa 2: habilitar o Modo Automático do EKS no cluster
1. Habilite o Modo Automático do EKS no cluster existente usando a CLI ou o Console de Gerenciamento da AWS. Para obter mais informações, consulte [Habilitar o Modo Automático do EKS em um cluster existente](auto-enable-existing.md).
1. Confira o nodepool:
```
kubectl get nodepool
```
```
NAME NODECLASS NODES READY AGE
general-purpose default 1 True 6m58s
system default 0 True 3d14h
```
## Etapa 3: atualizar workloads para migração
Identifique e atualize as workloads que você deseja migrar para o Modo Automático do EKS.
Para migrar uma workload do Fargate para o Modo Automático do EKS, aplique a anotação `eks.amazonaws.com/compute-type: ec2`. Isso garante que a workload não seja programada pelo Fargate, apesar do perfil do Fargate, e que seja detectada pelo NodePool do Modo Automático do EKS. Para obter mais informações, consulte [Criar um grupo de nós para o Modo Automático do EKS](create-node-pool.md).
1. Modifique as implantações (por exemplo, o arquivo `deployment_fargate.yaml`) para alterar o tipo de computação para `ec2`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. Aplique a implantação. Essa alteração permite que a workload seja programada nos novos nós do Modo Automático do EKS:
```
kubectl apply -f deployment_fargate.yaml
```
1. Verifique se a implantação está em execução no cluster do Modo Automático do EKS:
```
kubectl get pod -o wide
```
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-97967b68d-ffxxh 1/1 Running 0 3m31s 192.168.43.240 i-0845aafcb51630ffb
nginx-deployment-97967b68d-mbcgj 1/1 Running 0 2m37s 192.168.43.241 i-0845aafcb51630ffb
nginx-deployment-97967b68d-qpd8x 1/1 Running 0 2m35s 192.168.43.242 i-0845aafcb51630ffb
```
1. Verifique se não há nenhum nó do Fargate nem nenhuma implantação em execução nos nós gerenciados pelo Modo Automático do EKS:
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
i-0845aafcb51630ffb Ready 3m30s v1.30.8-eks-3c20087 192.168.41.125 3.81.118.95 Bottlerocket (EKS Auto) 2025.3.14 (aws-k8s-1.30) 6.1.129 containerd://1.7.25+bottlerocket
```
## Etapa 4: migrar gradualmente as workloads
Repita a Etapa 3 para cada workload que você deseja migrar. Isso permite que você mova workloads individualmente ou em grupos, com base nos requisitos e tolerância a riscos.
## Etapa 5: remover o perfil original do Fargate
Depois que todas as workloads tiverem sido migradas, será possível remover o perfil original do `fargate`. Substitua ** pelo nome do seu perfil do Fargate:
```
aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --fargate-profile-name
```
## Etapa 6: reduzir a escala verticalmente do CoreDNS
Como o Modo Automático do EKS processa o CoreDNS, você reduz a escala verticalmente da implantação do `coredns` para 0:
```
kubectl scale deployment coredns -n kube-system —-replicas=0
```
# Execução de workloads de amostra em clusters do modo automático do EKS
Este capítulo fornece exemplos de como implantar diferentes tipos de workloads em clusters do Amazon EKS executados no Modo Automático. Os exemplos demonstram os principais padrões de workloads, incluindo aplicações de exemplo, aplicações Web com balanceamento de carga, workloads com estado usando armazenamento persistente e workloads com requisitos específicos de posicionamento de nós. Cada exemplo inclui manifestos completos e instruções de implantação passo a passo que você pode usar como modelos para suas próprias aplicações.
Antes de prosseguir com os exemplos, certifique-se de que você tenha um cluster do EKS em execução no Modo Automático e que tenha instalado a AWS CLI e o kubectl. Para obter mais informações, consulte [Configurar para usar o Amazon EKS](setting-up.md). Os exemplos pressupõem familiaridade básica com os conceitos do Kubernetes e comandos do kubectl.
Você pode usar essas amostras baseadas em casos de uso para executar workloads em clusters do Modo Automático do EKS.
[Implantar uma workload de ampliação de exemplo em um cluster do Modo Automático do Amazon EKS](automode-workload.md)
Mostra como implantar uma workload de exemplo em um cluster do Modo Automático do EKS usando comandos do `kubectl`.
[Implantação de uma workload de amostra do balanceador de carga no modo automático do EKS](auto-elb-example.md)
Mostra como implantar uma versão em contêiner do jogo 2048 no Amazon EKS.
[Implantar uma workload com estado de exemplo no Modo Automático do EKS](sample-storage-workload.md)
Mostra como implantar uma aplicação com estado de exemplo em um cluster do Modo Automático do EKS.
[Implementar uma workload acelerada](auto-accelerated.md)
Mostra como implantar workloads com aceleração de hardware em nós gerenciados pelo modo automático do EKS.
[Controlar se uma workload é implantada nos nós do Modo Automático do EKS](associate-workload.md)
Mostra como usar uma anotação para controlar se uma workload estiver implantada em nós gerenciados pelo Modo Automático do EKS.
# Implantar uma workload de ampliação de exemplo em um cluster do Modo Automático do Amazon EKS
Neste tutorial, você aprenderá como implantar uma workload de exemplo em um cluster do Modo Automático do EKS e observará como ela provisiona automaticamente os recursos computacionais necessários. Você usará os comandos do `kubectl` para observar o comportamento do cluster e acompanhar de perto como o Modo Automático simplifica as operações do Kubernetes na AWS. Ao final deste tutorial, você saberá como o Modo Automático do EKS responde às implantações de workloads gerenciando automaticamente os recursos computacionais subjacentes, sem exigir a configuração manual do grupo de nós.
## Pré-requisitos
+ Um cluster do Modo Automático do Amazon EKS. Registre o nome e a região da AWS do cluster.
+ Uma entidade principal do IAM, como um usuário ou perfil, com permissões suficientes para gerenciar recursos de rede, de computação e do EKS.
+ Para obter mais informações, consulte a [Criar perfis e anexar políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) no Guia do usuário do IAM.
+ `aws` CLI instalada e configurada com uma identidade do IAM.
+ `kubectl` CLI instalada e conectada ao cluster.
+ Para obter mais informações, consulte [Configurar para usar o Amazon EKS](setting-up.md).
## Etapa 1: analisar os recursos computacionais existentes (opcional)
Primeiro, use `kubectl` para listar os grupos de nós no cluster.
```
kubectl get nodepools
```
Exemplo de saída:
```
general-purpose
```
Neste tutorial, implantaremos uma workload configurada para usar o grupo de nós `general-purpose`. Esse grupo de nós é incorporado ao Modo Automático do EKS e inclui padrões razoáveis para workloads gerais, como microsserviços e aplicações Web. Você pode criar seu próprio grupo de nós. Para obter mais informações, consulte [Criar um grupo de nós para o Modo Automático do EKS](create-node-pool.md).
Depois, use `kubectl` para listar os nós conectados ao cluster.
```
kubectl get nodes
```
Caso tenha acabado de criar um cluster do Modo Automático do EKS, você não terá nós.
Neste tutorial, você implantará uma workload de exemplo. Se você não tiver nós ou se a workload não se adequar aos nós existentes, o Modo Automático do EKS provisionará um novo nó.
## Etapa 2: implantar uma aplicação de exemplo no cluster.
Analise a implantação do Kubernetes a seguir e salve-a como `inflate.yaml`
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate
spec:
replicas: 1
selector:
matchLabels:
app: inflate
template:
metadata:
labels:
app: inflate
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
containers:
- name: inflate
image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
resources:
requests:
cpu: 1
securityContext:
allowPrivilegeEscalation: false
```
Observe que o seletor `eks.amazonaws.com/compute-type: auto` requer que a workload seja implantada em um nó do Modo Automático do Amazon EKS.
Aplique a implantação ao cluster.
```
kubectl apply -f inflate.yaml
```
## Etapa 3: observar os eventos do Kubernetes
Use o comando a seguir para observar os eventos do Kubernetes, incluindo a criação de um nó. Use `ctrl+c` para parar de observar os eventos.
```
kubectl get events -w --sort-by '.lastTimestamp'
```
Use `kubectl` para listar novamente os nós conectados ao cluster. Registre o nó recém-criado.
```
kubectl get nodes
```
## Etapa 4: visualizar nós e instâncias no console da AWS
Você pode visualizar os nós do Modo Automático do EKS no console do EKS e as instâncias associadas do EC2 no console do EC2.
As instâncias do EC2 implantadas pelo Modo Automático do EKS são restritas. Você não pode executar comandos arbitrários nos nós do Modo Automático do EKS.
## Etapa 5: excluir a implantação
Use `kubectl` para excluir uma implantação de exemplo
```
kubectl delete -f inflate.yaml
```
Se você não tiver outras workloads implantadas no cluster, o nó criado pelo Modo Automático do EKS ficará vazio.
Na configuração padrão, o Modo Automático do EKS detecta nós que ficaram vazios por trinta segundos e os encerra.
Use `kubectl` ou o console do EC2 para confirmar que a instância associada foi excluída.
# Implantação de uma workload de amostra do balanceador de carga no modo automático do EKS
Este guia orienta você na implantação de uma versão em contêiner do jogo 2048 no Amazon EKS, completa com balanceamento de carga e acessibilidade à internet.
## Pré-requisitos
+ Um cluster do Modo Automático do EKS
+ `kubectl` configurado para interagir com o cluster
+ Permissões do IAM apropriadas para criar recursos do ALB
## Etapa 1: criar o namespace
Primeiro, crie um namespace dedicado para a aplicação do jogo 2048.
Crie um arquivo chamado `01-namespace.yaml`:
```
apiVersion: v1
kind: Namespace
metadata:
name: game-2048
```
Aplique a configuração do namespace:
```
kubectl apply -f 01-namespace.yaml
```
## Etapa 2: implantar uma aplicação
A aplicação executa várias réplicas do contêiner do jogo 2048.
Crie um arquivo chamado `02-deployment.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: game-2048
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 5
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
resources:
requests:
cpu: "0.5"
```
**nota**
Se você receber um erro ao carregar a imagem `public.ecr.aws/l6m2t8p7/docker-2048:latest`, verifique se o perfil do IAM do nó tem permissões suficientes para extrair imagens do ECR. Para obter mais informações, consulte [Perfil do IAM do nó](auto-learn-iam.md#auto-learn-node-iam-role). A imagem de `docker-2048` no exemplo também é uma imagem de `x86_64` e não será executada em outras arquiteturas.
**Principais componentes:**
+ Implanta cinco réplicas da aplicação
+ Usa uma imagem pública do ECR
+ Solicita 0,5 núcleo de CPU por pod
+ Expõe a porta 80 para o tráfego HTTP
Aplique a implantação:
```
kubectl apply -f 02-deployment.yaml
```
## Etapa 3: criar o serviço
O serviço expõe a implantação à rede do cluster.
Crie um arquivo chamado `03-service.yaml`:
```
apiVersion: v1
kind: Service
metadata:
namespace: game-2048
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
selector:
app.kubernetes.io/name: app-2048
```
**Principais componentes:**
+ Cria um serviço do NodePort
+ Mapeia a porta 80 para a porta 80 do contêiner
+ Usa o seletor de rótulos para encontrar pods
Aplique o serviço:
```
kubectl apply -f 03-service.yaml
```
## Etapa 4: configurar o balanceamento de carga
Você vai configurar uma entrada para expor a aplicação à internet.
Primeiro, crie a `IngressClass`. Crie um arquivo chamado `04-ingressclass.yaml`:
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
labels:
app.kubernetes.io/name: LoadBalancerController
name: alb
spec:
controller: eks.amazonaws.com/alb
```
**nota**
O Modo Automático do EKS precisa de tags de sub-rede para identificar sub-redes públicas e privadas.
Se você criou o cluster com o `eksctl`, você já tem essas tags.
Aprenda como [Marcar sub-redes para o Modo Automático do EKS](tag-subnets-auto.md).
Em seguida, crie o recurso Ingress. Crie um arquivo chamado `05-ingress.yaml`:
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: game-2048
name: ingress-2048
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-2048
port:
number: 80
```
**Principais componentes:**
+ Cria um ALB voltado para a internet
+ Usa o tipo de destino IP para roteamento direto de pods
+ Roteia todo o tráfego (/) para o serviço do jogo
Aplique as configurações de entrada:
```
kubectl apply -f 04-ingressclass.yaml
kubectl apply -f 05-ingress.yaml
```
## Etapa 5: verificar a implantação
1. Verifique se todos os pods estão em execução:
```
kubectl get pods -n game-2048
```
1. Verifique se o serviço foi criado:
```
kubectl get svc -n game-2048
```
1. Obtenha o endpoint do ALB:
```
kubectl get ingress -n game-2048
```
O campo ADDRESS na saída da entrada mostrará o endpoint do ALB. Aguarde de dois a três minutos para que o ALB provisione e registre todos os destinos.
## Etapa 6: acessar o jogo
Abra seu navegador da Web e navegue até o URL do endpoint do ALB da etapa anterior. Você deve ver a interface do jogo 2048.
## Etapa 7: limpeza
Para remover todos os recursos criados neste tutorial:
```
kubectl delete namespace game-2048
```
Isso excluirá todos os recursos no namespace, incluindo os recursos de implantação, serviço e entrada.
## O que está acontece por detrás
1. A implantação cria cinco pods que executam o jogo 2048
1. O serviço fornece acesso de rede estável a esses pods
1. Modo Automático do EKS:
+ Cria um Application Load Balancer na AWS
+ Configura grupos de destino para os pods
+ Configura as regras de roteamento para direcionar o tráfego ao serviço
## Solução de problemas
Se o jogo não carregar:
+ Certifique-se de que todos os pods estejam em execução: `kubectl get pods -n game-2048`
+ Verifique o status de entrada: `kubectl describe ingress -n game-2048`
+ Confira as verificações de integridade do ALB: consulte a integridade do grupo de destino no Console da AWS
# Implantar uma workload com estado de exemplo no Modo Automático do EKS
Este tutorial o orientará na implantação de uma aplicação com estado de exemplo no cluster do Modo Automático do EKS. A aplicação grava carimbos de data e hora em um volume persistente, demonstrando os recursos automáticos de provisionamento e persistência de volume do EBS do Modo Automático do EKS.
## Pré-requisitos
+ Um cluster do Modo Automático do EKS
+ A AWS CLI configurada com as permissões apropriadas
+ `kubectl` instalado e configurado
+ Para ter mais informações, consulte [Configurar para usar o Amazon EKS](setting-up.md).
## Etapa 1: configurar o ambiente
1. Defina as variáveis de ambiente:
```
export CLUSTER_NAME=my-auto-cluster
export AWS_REGION="us-west-2"
```
1. Atualize o kubeconfig:
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
## Etapa 2: criar a classe de armazenamento
A `StorageClass` define como o Modo Automático do EKS provisionará volumes do EBS.
O Modo Automático do EKS não cria uma `StorageClass` para você. Você deve criar uma `StorageClass` referenciando `ebs.csi.eks.amazonaws.com` para usar o recurso de armazenamento do Modo Automático do EKS.
1. Crie um arquivo chamado `storage-class.yaml`:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
1. Aplique a `StorageClass`:
```
kubectl apply -f storage-class.yaml
```
**Principais componentes:**
+ `provisioner: ebs.csi.eks.amazonaws.com`: usa o Modo Automático do EKS
+ `volumeBindingMode: WaitForFirstConsumer`: atrasa a criação do volume até que um pod precise dele
+ `type: gp3`: especifica o tipo de volume do EBS
+ `encrypted: "true"`: o EBS usará a chave `aws/ebs` padrão para criptografar volumes criados com essa classe. Isso é opcional, mas recomendado.
+ `storageclass.kubernetes.io/is-default-class: "true"`: o Kubernetes usará essa classe de armazenamento por padrão, a menos que você especifique uma classe de volume diferente em uma reivindicação de volume persistente. Tenha cuidado ao definir esse valor se estiver migrando de outro controlador de armazenamento. (opcional)
## Etapa 3: criar a declaração de volume persistente
A PVC solicita armazenamento da `StorageClass`.
1. Crie um arquivo chamado `pvc.yaml`:
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: auto-ebs-claim
spec:
accessModes:
- ReadWriteOnce
storageClassName: auto-ebs-sc
resources:
requests:
storage: 8Gi
```
1. Aplique a PVC:
```
kubectl apply -f pvc.yaml
```
**Principais componentes:**
+ `accessModes: ReadWriteOnce`: o volume pode ser montado por um nó por vez
+ `storage: 8Gi`: solicita um volume de 8 GiB
+ `storageClassName: auto-ebs-sc`: faz referência à `StorageClass` que criamos
## Etapa 4: implantar uma aplicação
A implantação executa um contêiner que grava carimbos de data e hora no volume persistente.
1. Crie um arquivo chamado `deployment.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate-stateful
spec:
replicas: 1
selector:
matchLabels:
app: inflate-stateful
template:
metadata:
labels:
app: inflate-stateful
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
containers:
- name: bash
image: public.ecr.aws/docker/library/bash:4.4
command: ["/usr/local/bin/bash"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 60; done"]
resources:
requests:
cpu: "1"
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: auto-ebs-claim
```
1. Aplique a implantação:
```
kubectl apply -f deployment.yaml
```
**Principais componentes:**
+ Contêiner bash simples que grava carimbos de data e hora em um arquivo
+ Monta o PVC em `/data`
+ Solicita um núcleo de CPU
+ Usa o seletor de nós para nós gerenciados pelo EKS
## Etapa 5: verificar a configuração
1. Verifique se o pod está em execução:
```
kubectl get pods -l app=inflate-stateful
```
1. Verifique se a PVC está vinculada:
```
kubectl get pvc auto-ebs-claim
```
1. Verifique o volume do EBS:
```
# Get the PV name
PV_NAME=$(kubectl get pvc auto-ebs-claim -o jsonpath='{.spec.volumeName}')
# Describe the EBS volume
aws ec2 describe-volumes \
--filters Name=tag:CSIVolumeName,Values=${PV_NAME}
```
1. Verifique se os dados estão sendo gravados:
```
kubectl exec "$(kubectl get pods -l app=inflate-stateful \
-o=jsonpath='{.items[0].metadata.name}')" -- \
cat /data/out.txt
```
## Etapa 6: limpeza
Execute o comando a seguir para remover todos os recursos criados neste tutorial:
```
# Delete all resources in one command
kubectl delete deployment/inflate-stateful pvc/auto-ebs-claim storageclass/auto-ebs-sc
```
## O que está acontece por detrás
1. A PVC solicita armazenamento da `StorageClass`
1. Quando o pod está programado:
1. O Modo Automático do EKS provisiona um volume do EBS
1. Cria um PersistentVolume
1. Anexa o volume ao nó
1. O pod monta o volume e começa a gravar carimbos de data e hora
## Controlador de snapshots
O Modo Automático do EKS é compatível com o Kubernetes CSI Snapshotter, também conhecido como controlador de snapshots. No entanto, o Modo Automático do EKS não inclui o controlador de snapshots. Você é responsável por instalar e configurar o controlador de snapshots. Para ter mais informações, consulte [Habilitar a funcionalidade de snapshot para volumes CSI](csi-snapshot-controller.md).
Analise a `VolumeSnapshotClass` a seguir que faz referência à capacidade de armazenamento do Modo Automático do EKS.
```
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: auto-ebs-vsclass
driver: ebs.csi.eks.amazonaws.com
deletionPolicy: Delete
```
[Saiba mais sobre o Kubernetes CSI Snapshotter.](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage)
# Implementar uma workload acelerada
Este tutorial demonstra como o modo automático do Amazon EKS simplifica a inicialização de workloads com a aceleração de hardware. O Modo Automático do Amazon EKS simplifica as operações além do próprio cluster, automatizando os principais componentes da infraestrutura e fornecendo recursos de computação, rede, balanceamento de carga, armazenamento e do Identity and Access Management prontos para uso.
O Modo Automático do Amazon EKS inclui os drivers e plug-ins de dispositivos necessários para determinados tipos de instância, como drivers NVIDIA e AWS Neuron. Você não precisa instalar ou atualizar esses componentes.
O Modo Automático do EKS gerencia automaticamente os drivers destes aceleradores:
+ [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/)
+ [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/)
+ [GPUs NVIDIA em instâncias aceleradas do Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html)
**nota**
O Modo Automático do EKS inclui o plug-in de dispositivo NVIDIA para o Kubernetes. Esse plug-in é executado automaticamente e não fica visível como um conjunto de daemons no cluster.
Suporte adicional de rede:
+ [Elastic Fabric Adapter (EFA)](https://aws.amazon.com/hpc/efa/)
O Modo Automático do Amazon EKS elimina o trabalho de gerenciamento de drivers de aceleradores e plug-ins de dispositivos.
Você também pode aproveitar uma redução de custos escalando o cluster para zero. Você pode configurar o Modo Automático do EKS para encerrar instâncias quando nenhuma workload estiver em execução. Essa configuração é útil para workloads de inferência baseadas em lotes.
Veja a seguir um exemplo de como executar workloads aceleradas com o Modo Automático do Amazon EKS.
## Pré-requisitos
+ Um cluster do Kubernetes com o Modo Automático do Amazon EKS configurado.
+ Uma classe de nó `default` do EKS conforme criada quando os grupos de nós gerenciados `general-purpose` ou `system` estão habilitados.
## Etapa 1: implantar uma workload de GPU
Neste exemplo, você criará um NodePool para workloads baseadas em NVIDIA que requer 45 GB de memória de GPU. Com o Modo Automático do EKS, você usa as restrições de agendamento do Kubernetes para definir os requisitos de sua instância.
Para implantar o `NodePool` do Modo Automático do Amazon EKS e o exemplo de `workload`, consulte a seguinte definição de NodePool e pod e salve como `nodepool-gpu.yaml` e `pod.yaml`:
**nodepool-gpu.yaml**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
taints:
- key: nvidia.com/gpu
effect: NoSchedule
terminationGracePeriod: 24h0m0s
```
**pod.yaml**
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Observe que o seletor `eks.amazonaws.com/compute-type: auto` requer que a workload seja implantada em um nó do Modo Automático do Amazon EKS. O NodePool também define uma taint que só permite que pods com tolerâncias para GPUs Nvidia sejam programados.
Aplique o NodePool e a workload ao cluster.
```
kubectl apply -f nodepool-gpu.yaml
kubectl apply -f pod.yaml
```
A seguinte saída deverá ser mostrada:
```
nodepool.karpenter.sh/gpu configured created
pod/nvidia-smi created
```
Aguarde alguns segundos e verifique os nós no cluster. Agora você deve ver um novo nó provisionado no cluster do Modo Automático do Amazon EKS:
```
> kubectl get nodes
NAME TYPE CAPACITY ZONE NODE READY AGE
gpu-dnknr g6e.2xlarge on-demand us-west-2b i-02315c7d7643cdee6 True 76s
```
## Etapa 2: validar
Você pode ver que o Modo Automático do Amazon EKS executou `g6e.2xlarge` em vez de `g6.2xlarge`, pois a workload exigia uma instância com `GPU` l40s, de acordo com as seguintes restrições de programação do Kubernetes:
```
...
nodeSelector:
eks.amazonaws.com/instance-gpu-name: l40s
...
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
```
Agora, veja os logs dos contêineres executando o seguinte comando:
```
kubectl logs nvidia-smi
```
Exemplo de resultado:
```
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.230.02 Driver Version: 535.230.02 CUDA Version: 12.2 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 NVIDIA L40S On | 00000000:30:00.0 Off | 0 |
| N/A 27C P8 23W / 350W | 0MiB / 46068MiB | 0% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| No running processes found |
+---------------------------------------------------------------------------------------+
```
Você pode ver que o contêiner detectou que está sendo executado em uma instância com uma GPU `NVIDIA` e que você não precisou instalar nenhum driver de dispositivo, pois é gerenciado pelo Modo Automático do Amazon EKS.
## Etapa 3: limpar
Para remover todos os objetos criados, use o `kubectl` para excluir a implantação da amostra e o NodePool para que o nó seja encerrado:
```
kubectl delete -f nodepool-gpu.yaml
kubectl delete -f pod.yaml
```
## Exemplo de referência de NodePools
### Criar um NodePool NVIDIA
O seguinte NodePool define:
+ Executa somente instâncias da família `g6e` e `g6`
+ Consolida os nós quando estiverem vazios por uma hora
+ O valor de 1 hora para `consolodateAfter` é compatível com workloads elevadas e reduz a rotatividade de nós. Você pode ajustar `consolidateAfter` com base em seus requisitos de workload.
**Exemplo de NodePool com consolidação e família de instâncias de GPU**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
terminationGracePeriod: 24h0m0s
```
Em vez de definir `eks.amazonaws.com/instance-gpu-name`, você pode usar `eks.amazonaws.com/instance-family` para especificar a família de instâncias. Para outros rótulos conhecidos que influenciam a revisão da programação, consulte [Rótulos compatíveis com o Modo Automático do EKS](create-node-pool.md#auto-supported-labels).
Se você tiver requisitos específicos de armazenamento, poderá ajustar `iops`, `size` e `throughput` do armazenamento temporário de nós criando o próprio [NodeClass](create-node-class.md) para referência no NodePool. Saiba mais sobre as [opções configuráveis do NodeClass](create-node-class.md).
**Exemplo de configuração de armazenamento para NodeClass**
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
ephemeralStorage:
iops: 3000
size: 80Gi
throughput: 125
```
### Definir um AWS Trainium e AWS Inferentia NodePool
O NodePool abaixo tem uma configuração de `eks.amazonaws.com/instance-category` que instrui a executar apenas instâncias da família Inferentia e Trainium:
```
- key: "eks.amazonaws.com/instance-category"
operator: In
values:
- inf
- trn
```
# Configurar as configurações do modo automático do EKS
Este capítulo descreve como configurar aspectos específicos dos clusters do Modo automático do Amazon Elastic Kubernetes Service (EKS). Embora o Modo automático do EKS gerencie a maioria dos componentes da infraestrutura automaticamente, você pode personalizar certos recursos para atender aos requisitos de workloads.
Usando as opções de configuração descritas neste tópico, você pode modificar as configurações de rede, os recursos computacionais e os comportamentos de balanceamento de carga, mantendo os benefícios do gerenciamento automatizado da infraestrutura. Antes de fazer qualquer alteração na configuração, analise as opções disponíveis nas seções a seguir para determinar qual abordagem melhor atende às suas necessidades.
| Quais recursos você deseja configurar? | Opção de configuração |
| --- | --- |
| **Rede e armazenamento de nós** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/settings-auto.html) | [Criar uma classe de nó para o Amazon EKS](create-node-class.md) |
| **Recursos de computação de nós** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/settings-auto.html) | [Criar um grupo de nós para o Modo Automático do EKS](create-node-pool.md) |
| **Grupos de nós de capacidade estática** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/settings-auto.html) | [Grupos de nós de capacidade estática no modo automático do EKS](auto-static-capacity.md) |
| **Configurações do Application Load Balancer** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/settings-auto.html) | [Criar uma IngressClass para configurar um Application Load Balancer](auto-configure-alb.md) |
| **Configurações do Network Load Balancer** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/settings-auto.html) | [Usar anotações de serviço para configurar Network Load Balancers](auto-configure-nlb.md) |
| **Configurações da classe de armazenamento** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/settings-auto.html) | [Criar uma classe de armazenamento](create-storage-class.md) |
| **Controlar o uso de ODCRs** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/settings-auto.html) | [Controle da implantação de workloads em reservas de capacidade com o modo automático do EKS](auto-odcr.md) |
| **Segurança de nós avançada** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/settings-auto.html) | [Definição de configurações avançadas de segurança para nós](auto-advanced-security.md) |
# Criar uma classe de nó para o Amazon EKS
As classes de nós do Amazon EKS são modelos que fornecem controle granular sobre a configuração dos nós gerenciados pelo Modo automático do EKS. Uma classe de nó define as configurações no nível de infraestrutura que se aplicam a grupos de nós no cluster de EKS, incluindo configuração de rede, configurações de armazenamento e marcação de recursos. Este tópico explica como criar e configurar uma classe de nó para atender aos requisitos operacionais específicos.
Quando você precisa personalizar como o Modo automático do EKS provisiona e configura instâncias do EC2 além das configurações padrão, a criação de uma classe de nó oferece controle preciso sobre os parâmetros críticos da infraestrutura. Por exemplo, você pode especificar o posicionamento em sub-rede privada para aumentar a segurança, configurar o armazenamento efêmero da instância para workloads sensíveis à performance ou aplicar marcações personalizadas para alocação de custos.
## Criar uma classe de nó
Para criar um `NodeClass`, siga estas etapas:
1. Criar um arquivo YAML (por exemplo, `nodeclass.yaml`) com sua configuração de classe de nó
1. Aplicar a configuração ao cluster usando o `kubectl`
1. Faça referência à classe de nó na configuração do grupo de nós. Para obter mais informações, consulte [Criar um grupo de nós para o Modo Automático do EKS](create-node-pool.md).
Você precisa ter o `kubectl` instalado e configurado. Para obter mais informações, consulte [Configurar para usar o Amazon EKS](setting-up.md).
### Exemplo básico de classe de nó
Veja a seguir um exemplo de classe de nó:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: private-compute
spec:
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
ephemeralStorage:
size: "160Gi"
```
Essa NodeClass aumenta a quantidade de armazenamento efêmero no nó.
Aplique essa configuração usando:
```
kubectl apply -f nodeclass.yaml
```
Em seguida, faça referência à classe de nó na configuração do grupo de nós. Para obter mais informações, consulte [Criar um grupo de nós para o Modo Automático do EKS](create-node-pool.md).
## Criar entrada de acesso de classe de nós
Se você criar uma classe de nós personalizada, precisará criar uma entrada de acesso do EKS para permitir que os nós se juntem ao cluster. O EKS cria automaticamente entradas de acesso quando você usa a classe de nós e os pools de nós integrados.
Para obter informações sobre como as entradas de acesso funcionam, consulte [Conceder aos usuários do IAM acesso ao Kubernetes com entradas de acesso ao EKS](access-entries.md).
Ao criar entradas de acesso para as classes de nós do Modo automático do EKS, você precisa usar o tipo de entrada de acesso do `EC2`.
### Criar entrada de acesso com a CLI
**Para criar uma entrada de acesso para os nós do EC2 e associar a política de nós automáticos do EKS:**
Atualize os comandos da CLI a seguir com o nome do cluster e o ARN do perfil do nó. O ARN do perfil de nó é especificado no YAML da classe de nós.
```
# Create the access entry for EC2 nodes
aws eks create-access-entry \
--cluster-name \
--principal-arn \
--type EC2
# Associate the auto node policy
aws eks associate-access-policy \
--cluster-name \
--principal-arn \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
--access-scope type=cluster
```
### Criar entrada de acesso com o CloudFormation
**Para criar uma entrada de acesso para os nós do EC2 e associar a política de nós automáticos do EKS:**
Atualize o CloudFormation a seguir com o nome do cluster e o ARN do perfil do nó. O ARN do perfil de nó é especificado no YAML da classe de nós.
```
EKSAutoNodeRoleAccessEntry:
Type: AWS::EKS::AccessEntry
Properties:
ClusterName:
PrincipalArn:
Type: "EC2"
AccessPolicies:
- AccessScope:
Type: cluster
PolicyArn: arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
DependsOn: [ ] # previously defined in CloudFormation
```
Para obter informações sobre a implantação de pilhas do CloudFormation, consulte [Conceitos básicos do CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html)
## Especificação das classes de nós
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Required fields
# role and instanceProfile are mutually exclusive fields.
role: MyNodeRole # IAM role for EC2 instances
# instanceProfile: eks-MyNodeInstanceProfile # IAM instance-profile for EC2 instances
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
# Alternative using direct subnet ID
# - id: "subnet-0123456789abcdef0"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Alternative approaches:
# - id: "sg-0123456789abcdef0"
# - name: "eks-cluster-security-group"
# Optional: Pod subnet selector for advanced networking
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
# Alternative using direct subnet ID
# - id: "subnet-0987654321fedcba0"
# must include Pod security group selector also
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
# Alternative using direct security group ID
# - id: "sg-0123456789abcdef0"
# Optional: Selects on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
Name: "targeted-odcr"
# Optional owning account ID filter
owner: "012345678901"
# Optional fields
snatPolicy: Random # or Disabled
networkPolicy: DefaultAllow # or DefaultDeny
networkPolicyEventLogs: Disabled # or Enabled
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# Optional KMS key for encryption
kmsKeyID: "arn:aws:kms:region:account:key/key-id"
# Accepted formats:
# KMS Key ID
# KMS Key ARN
# Key Alias Name
# Key Alias ARN
advancedNetworking:
# Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass.
# If not set, defaults to the MapPublicIpOnLaunch setting on the subnet.
associatePublicIPAddress: false
# Optional: Forward proxy, commonly requires certificateBundles as well
# for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters
#httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use []
noProxy: #Max 50 entries
- localhost #Max 255 characters each
- 127.0.0.1
#- ::1 # IPv6 localhost
#- 0:0:0:0:0:0:0:1 # IPv6 localhost
- 169.254.169.254 # EC2 Instance Metadata Service
#- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service
# Domains to exclude, put all VPC endpoints here
- .internal
- .eks.amazonaws.com
# ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode.
ipv4PrefixSize: Auto # or "32"
# enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters
enableV4Egress: false
advancedSecurity:
# Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs.
fips: false
# Optional: Custom certificate bundles.
certificateBundles:
- name: "custom-cert"
data: "base64-encoded-cert-data"
# Optional: Additional EC2 tags (with restrictions)
tags:
Environment: "production"
Team: "platform"
# Note: Cannot use restricted tags like:
# - kubernetes.io/cluster/*
# - karpenter.sh/provisioner-name
# - karpenter.sh/nodepool
# - karpenter.sh/nodeclaim
# - karpenter.sh/managed-by
# - eks.amazonaws.com/nodeclass
```
## Considerações
+ Se você quiser verificar a quantidade de armazenamento local de uma instância, é possível descrever o nó para ver o recurso de armazenamento efêmero.
+ **Criptografia de volume**: o EKS usa a chave do KMS personalizada configurada para criptografar o volume raiz somente leitura da instância e o volume de dados de leitura/gravação.
+ **Substituir o perfil do IAM do nó**: caso altere o perfil do IAM do nó associado a um `NodeClass`, você precisará criar uma nova entrada de acesso. O EKS cria automaticamente uma entrada de acesso para o perfil do IAM do nó durante a criação do cluster. O perfil do IAM do nó requer a política de acesso `AmazonEKSAutoNodePolicy` do EKS. Para obter mais informações, consulte [Conceder aos usuários do IAM acesso ao Kubernetes com entradas de acesso ao EKS](access-entries.md).
+ **Densidade máxima dos pods**: o EKS limita o número máximo de pods em um nó a 110. Esse limite é aplicado após o cálculo do máximo de pods existentes. Para obter mais informações, consulte [Escolher um tipo de instância de nó do Amazon EC2 ideal](choosing-instance-type.md).
+ **Tags**: caso queira propagar tags do Kubernetes para o EC2, você precisará configurar permissões adicionais do IAM. Para obter mais informações, consulte [Saber mais sobre identidade e acesso no Modo Automático do EKS](auto-learn-iam.md).
+ **Classe de nó padrão**: não nomeie sua classe de nó personalizada `default`. Isso ocorre porque o Modo automático do EKS inclui um `NodeClass` denominado `default` que é provisionado automaticamente quando você habilita pelo menos um `NodePool` integrado. Para obter informações sobre como habilitar `NodePools` integrados, consulte [Habilitar ou desabilitar NodePools integrados](set-builtin-node-pools.md).
+ **Comportamento dos `subnetSelectorTerms` com várias sub-redes**: se houver várias sub-redes que correspondam às condições dos `subnetSelectorTerms` ou que você forneça por ID, o Modo automático do EKS criará nós distribuídos pelas sub-redes.
+ Se as sub-redes estiverem em zonas de disponibilidade (AZ) diferentes, será possível usar recursos do Kubernetes, como [Restrições de distribuição da topologia de pods](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints) e [Roteamento com reconhecimento de topologia](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/), para distribuir os pods e o tráfego pelas zonas, respectivamente.
+ Se houver várias sub-redes *na mesma AZ* que correspondam aos `subnetSelectorTerms`, o Modo automático do EKS criará pods em cada nó distribuídos pelas sub-redes nessa AZ. O Modo automático do EKS cria interfaces de rede secundárias em cada nó nas outras sub-redes na mesma AZ. Ele escolhe com base no número de endereços IP disponíveis em cada sub-rede para usar as sub-redes com mais eficiência. No entanto, você não pode especificar qual sub-rede o Modo automático do EKS usará para cada pod; se você precisar que os pods sejam executados em sub-redes específicas, então use o [Sub-redes e grupos de segurança separados para Pods](#pod-subnet-selector).
## Sub-redes e grupos de segurança separados para Pods
Os campos `podSubnetSelectorTerms` e `podSecurityGroupSelectorTerms` permitem configurações avançadas de rede, possibilitando que os pods sejam executados em sub-redes e grupos de segurança diferentes de seus nós. Os dois campos devem ser especificados juntos. Essa separação fornece controle aprimorado do roteamento do tráfego de rede e das políticas de segurança.
**nota**
Esse recurso difere do recurso [Grupos de Segurança para Pods](security-groups-for-pods.md) (SGPP) utilizado com o AWS VPC CNI para instâncias de computação que não estão no Modo Automático do EKS. O SGPP não é compatível com o Modo automático do EKS. Em vez disso, use `podSecurityGroupSelectorTerms` no `NodeClass` para aplicar grupos de segurança distintos ao tráfego do Pod. Os grupos de segurança se aplicam no nível `NodeClass`, ou seja, todos os pods nos nós que os usam `NodeClass` compartilham os mesmos grupos de segurança do pod.
### Como funciona
Quando você configura `podSubnetSelectorTerms` e `podSecurityGroupSelectorTerms`:
1. A ENI primária do nó usa as sub-redes e os grupos de segurança de `subnetSelectorTerms` e `securityGroupSelectorTerms`. Apenas o endereço IP do próprio nó é atribuído a esta interface.
1. O Modo Automático do EKS cria ENIs secundárias nas sub-redes correspondentes a `podSubnetSelectorTerms`, com os grupos de segurança de `podSecurityGroupSelectorTerms` associados. Os endereços IP dos pods são atribuídos a partir dessas ENIs secundárias usando prefixos /28 por padrão, com recurso automático para IPs secundárias (/32) quando não há um bloco de prefixos contíguo disponível. Se `ipv4PrefixSize` estiver definido como `"32"` em `advancedNetworking`, somente IPs secundários serão usados.
1. Os grupos de segurança especificados em `podSecurityGroupSelectorTerms` aplicam-se ao tráfego de pod na VPC. Para o tráfego destinado a destinos fora da VPC, os Pods utilizam a ENI primária do nó (e seus grupos de segurança), pois a tradução de endereços de rede de origem (SNAT) converte o IP do Pod para o IP do nó. Você pode modificar esse comportamento com o campo `snatPolicy` no `NodeClass`.
### Casos de uso
Use `podSubnetSelectorTerms` e `podSecurityGroupSelectorTerms` quando você precisar:
+ Aplicar diferentes grupos de segurança para controlar o tráfego de nós e pods separadamente.
+ Separar o tráfego de infraestrutura (comunicação de nó a nó) do tráfego de aplicações (comunicação de pod a pod).
+ Aplicar configurações de rede diferentes às sub-redes de nós e às sub-redes de pods.
+ Configurar proxies reversos ou filtragem de rede especificamente para o tráfego de nós sem afetar o tráfego de pods. Use `advancedNetworking` e `certificateBundles` para definir seu proxy reverso e quaisquer certificados autoassinados ou privados para o proxy.
### Exemplo de configuração
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
# Subnets and security groups for EC2 instances (nodes)
subnetSelectorTerms:
- tags:
Name: "node-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Separate subnets and security groups for Pods
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
```
### Considerações sobre sub-redes e grupos de segurança separados para Pods
+ **Escopo do grupo de segurança**: os grupos de segurança de `podSecurityGroupSelectorTerms` são anexados às ENIs secundárias e se aplicam ao tráfego de pod dentro da VPC. Quando o SNAT está habilitado (o padrão `snatPolicy: Random`), o tráfego que sai da VPC é redirecionado para o endereço IP da ENI primária do nó; assim, os grupos de segurança do nó de `securityGroupSelectorTerms` passam a ser aplicados a esse tráfego. Se você definir `snatPolicy: Disabled`, os Pods usarão seus próprios endereços IP para todo o tráfego, e você deverá garantir que o roteamento e os grupos de segurança estejam configurados adequadamente.
+ **Granularidade no nível da NodeClass**: Os grupos de segurança de Pods se aplicam a todos os Pods agendados nos nós usando o `NodeClass`. Para aplicar diferentes grupos de segurança a diferentes workloads, crie recursos `NodeClass` e `NodePool` separados e utilize taints, tolerações ou seletores de nó para agendar as workloads nos nós apropriados.
+ **Densidade reduzida de pods**: é possível executar menos Pods em cada nó, pois a interface de rede principal do nó é reservada para o endereço IP do próprio nó e não pode ser usada para Pods.
+ **Limitações do seletor de sub-rede**: as configurações padrão de `subnetSelectorTerms` e `securityGroupSelectorTerms` não se aplicam à seleção de sub-rede ou grupo de segurança de pods.
+ **Planejamento de rede**: garanta um espaço de endereços IP adequado nas sub-redes de nós e de pods para ser compatível com os seus requisitos de workload.
+ **Configuração de roteamento**: verifique se a tabela de rotas e a lista de controle de acesso (ACL) de rede das sub-redes de pods estão configuradas corretamente para comunicação entre as sub-redes de nós e de pods.
+ **Zonas de disponibilidade**: verifique se você criou sub-redes de pod em várias AZs. Se você estiver usando uma sub-rede específica de pod, ela deve estar na mesma AZ que a sub-rede do nó.
## Modo de IP secundário para pods
O campo `ipv4PrefixSize` permite configurações avançadas de rede, permitindo somente a alocação de endereços IP secundários aos nós. Esse atributo não aloca prefixos (/28) aos nós e mantém somente um IP secundário como MinimalIPTarget.
### Casos de uso
Use os `ipv4PrefixSize` quando precisar:
+ **Utilização reduzida de IP**: somente um endereço IP será aquecido em cada nó.
+ **Menor taxa de agitação de pods**: a velocidade de criação de pods não é uma grande preocupação.
+ **Sem fragmentação de prefixo**: a fragmentação causada pelo prefixo é uma grande preocupação ou impedimento para usar o modo automático.
### Exemplo de configuração
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
ipv4PrefixSize: "32"
```
### Considerações sobre o modo de IP secundário
+ **Velocidade reduzida de criação de pods**: como apenas um IP secundário é aquecido, o serviço IPAM precisa de mais tempo para provisionar IPs na criação de mais pods.
## Desabilite a saída de IPv4 dos pods IPv6 em clusters de IPv6.
O campo `enableV4Egress` é `true` por padrão. Para clusters IPv6 em modo automático, é possível desativar esse recurso para que o modo automático não crie uma interface IPv4 apenas de saída para pods IPv6. Isso é importante porque a interface de saída IPv4 não está sujeita à aplicação da política de rede. As políticas de rede são aplicadas apenas na interface principal do Pod (eth0).
### Casos de uso
Use os `enableV4Egress` quando precisar:
+ **Use o cluster IPv6**: o tráfego de saída IPv4 é permitido por padrão.
+ **Usar política de rede**: atualmente, a Política de Rede do EKS não oferece suporte ao dual-stack. A desativação de `enableV4Egress` pode impedir que o tráfego do pod saia inesperadamente pelo IPv4.
### Exemplo de configuração
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
enableV4Egress: false
```
### Considerações para desabilitar o EnableV4egress
+ **Política de rede no cluster IPv6**: clusters IPv6 permitem tráfego de IPv4 por padrão. A configuração `enableV4Egress: false` bloqueia o tráfego de saída IPv4, fornecendo segurança aprimorada, especialmente quando usada com políticas de rede.
# Criar um grupo de nós para o Modo Automático do EKS
Os grupos de nós do Amazon EKS oferecem uma forma flexível de gerenciar recursos computacionais no cluster do Kubernetes. Este tópico demonstra como criar e configurar grupos de nós usando o Karpenter, uma ferramenta de provisionamento de nós que ajuda a otimizar a escalabilidade de clusters e a utilização de recursos. Com o recurso NodePool do Karpenter, você pode definir requisitos específicos para os recursos computacionais, incluindo tipos de instância, zonas de disponibilidade, arquiteturas e tipos de capacidade.
Você não pode modificar os grupos de nós integrados `system` e `general-purpose`. Você não pode habilitá-los nem desabilitá-los. Para obter mais informações, consulte [Habilitar ou desabilitar NodePools integrados](set-builtin-node-pools.md).
A especificação NodePool permite um controle refinado sobre os recursos computacionais do cluster do EKS por meio de vários rótulos e requisitos compatíveis. Isso inclui opções para especificar categorias de instâncias do EC2, configurações de CPU, zonas de disponibilidade, arquiteturas (ARM64/AMD64) e tipos de capacidade (spot ou sob demanda). Você também pode definir limites de recursos para o uso de CPU e memória, garantindo que o cluster permaneça dentro dos limites operacionais desejados.
O Modo Automático do EKS utiliza rótulos conhecidos do Kubernetes para fornecer maneiras consistentes e padronizadas de identificar as características dos nós. Esses rótulos, como `topology.kubernetes.io/zone` para zonas de disponibilidade e `kubernetes.io/arch` para arquitetura de CPU, seguem as convenções estabelecidas do Kubernetes. Além disso, rótulos específicos do EKS (prefixados com `eks.amazonaws.com/`) ampliam essa funcionalidade com atributos específicos da AWS, como tipos de instância, fabricantes de CPU, recursos de GPU e especificações de rede. Esse sistema de rotulagem padronizado permite uma integração perfeita com as ferramentas existentes do Kubernetes, ao mesmo tempo em que fornece uma integração profunda da infraestrutura da AWS.
## Criar um NodePool
Siga estas etapas para criar um NodePool para o cluster do Amazon EKS:
1. Crie um arquivo YAML denominado `nodepool.yaml` com a configuração necessária do NodePool. Você pode usar o exemplo de configuração abaixo.
1. Aplique o NodePool ao cluster:
```
kubectl apply -f nodepool.yaml
```
1. Verifique se o NodePool foi criado com êxito:
```
kubectl get nodepools
```
1. (Opcional) Monitore o status do NodePool:
```
kubectl describe nodepool default
```
Certifique-se de que o NodePool faça referência a um NodeClass válido que exista no cluster. O NodeClass define as configurações específicas da AWS para os recursos computacionais. Para obter mais informações, consulte [Criar uma classe de nó para o Amazon EKS](create-node-class.md).
## Exemplo de NodePool
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
billing-team: my-team
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b"]
- key: "kubernetes.io/arch"
operator: In
values: ["arm64", "amd64"]
limits:
cpu: "1000"
memory: 1000Gi
```
## Rótulos compatíveis com o Modo Automático do EKS
O Modo Automático do EKS é compatível com os rótulos conhecidos a seguir.
**nota**
O Modo Automático do EKS usa rótulos diferentes do Karpenter. Os rótulos relacionados às instâncias gerenciadas pelo EC2 começam com `eks.amazonaws.com`.
| Rótulo | Exemplo | Descrição |
| --- | --- | --- |
| topology.kubernetes.io/zone | us-east-2a | Região AWS |
| node.kubernetes.io/instance-type | g4dn.8xlarge | Tipo de instância AWS |
| kubernetes.io/arch | amd64 | As arquiteturas são definidas pelos [valores GOARCH](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58) na instância |
| karpenter.sh/capacity-type | spot | Os tipos de capacidade incluem `spot`, `on-demand` |
| eks.amazonaws.com/instance-hypervisor | nitro | Tipos de instância que usam um hipervisor específico |
| eks.amazonaws.com/compute-type | auto | Identifica os nós gerenciados pelo Modo Automático do EKS |
| eks.amazonaws.com/instance-encryption-in-transit-supported | true | Tipos de instância que são compatíveis (ou não) com a criptografia em trânsito |
| eks.amazonaws.com/instance-category | g | Tipos de instância da mesma categoria, geralmente a string antes do número de geração |
| eks.amazonaws.com/instance-generation | 4 | Número de geração do tipo de instância em uma categoria de instância |
| eks.amazonaws.com/instance-family | g4dn | Tipos de instância de propriedades semelhantes, mas com quantidades de recursos diferentes |
| eks.amazonaws.com/instance-size | 8xlarge | Tipos de instância com quantidades de recursos semelhantes, mas com propriedades diferentes |
| eks.amazonaws.com/instance-cpu | 32 | Número de CPUs na instância |
| eks.amazonaws.com/instance-cpu-manufacturer | `aws` | Nome do fabricante da CPU |
| eks.amazonaws.com/instance-memory | 131072 | Número de mebibytes de memória na instância |
| eks.amazonaws.com/instance-ebs-bandwidth | 9500 | Número de [megabits máximos](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance) do EBS disponíveis na instância |
| eks.amazonaws.com/instance-network-bandwidth | 131072 | Número de [megabits de linha de base](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) disponíveis na instância |
| eks.amazonaws.com/instance-gpu-name | t4 | Nome da GPU na instância, se disponível |
| eks.amazonaws.com/instance-gpu-manufacturer | nvidia | Nome do fabricante da GPU |
| eks.amazonaws.com/instance-gpu-count | 1 | Número de GPUs na instância |
| eks.amazonaws.com/instance-gpu-memory | 16384 | Número de mebibytes de memória na GPU |
| eks.amazonaws.com/instance-local-nvme | 900 | Número de gibibytes de armazenamento NVMe local na instância |
**nota**
O Modo Automático do EKS é compatível apenas com determinadas instâncias e tem requisitos mínimos de tamanho. Para obter mais informações, consulte [Referência de instâncias compatíveis com o Modo automático do EKS](automode-learn-instances.md#auto-supported-instances).
## Rótulos não compatíveis com o Modo Automático do EKS
O Modo Automático do EKS não é compatível com os rótulos a seguir.
+ O Modo Automático do EKS é compatível apenas com o Linux
+ `node.kubernetes.io/windows-build`
+ `kubernetes.io/os`
## Desabilitar pools de nós integrados
Se você criar pools de nós personalizados, poderá desabilitar os pools de nós integrados. Para obter mais informações, consulte [Habilitar ou desabilitar NodePools integrados](set-builtin-node-pools.md).
## Cluster sem pools de nós integrados
Você pode criar um cluster sem os pools de nós integrados. Isso é útil quando sua organização criou pools de nós personalizados.
**nota**
Quando você cria um cluster sem grupos de nós integrados, o NodeClass `default` não é provisionado automaticamente. Você precisará criar um NodeClass personalizado. Para obter mais informações, consulte [Criar uma classe de nó para o Amazon EKS](create-node-class.md).
**Visão geral:**
1. Crie um cluster do EKS com os valores de `nodePools` e `nodeRoleArn` vazios.
+ Exemplo de `autoModeConfig` eksctl:
```
autoModeConfig:
enabled: true
nodePools: []
# Do not set a nodeRoleARN
```
Para obter mais informações, consulte [Criar um cluster do Modo Automático do EKS com a CLI do eksctl](automode-get-started-eksctl.md).
1. Crie uma classe de nós personalizada com um ARN de perfil de nó
+ Para obter mais informações, consulte [Criar uma classe de nó para o Amazon EKS](create-node-class.md).
1. Crie uma entrada de acesso para a classe de nós personalizada
+ Para obter mais informações, consulte [Criar entrada de acesso de classe de nós](create-node-class.md#auto-node-access-entry).
1. Crie um pool de nós personalizado, conforme descrito acima.
## Interrupção
Você pode configurar o Modo Automático do EKS para interromper os nós por meio do seu NodePool de várias maneiras. Você pode usar `spec.disruption.consolidationPolicy`, `spec.disruption.consolidateAfter` ou `spec.template.spec.expireAfter`. Você também pode limitar a taxa de interrupção do Modo Automático do EKS por meio de `spec.disruption.budgets` do NodePool. Você também pode controlar as janelas de tempo e o número de nós interrompidos simultaneamente. Para obter instruções sobre como configurar esse comportamento, consulte [Interrupção](https://karpenter.sh/docs/concepts/disruption/) na documentação do Karpenter.
Você pode configurar a interrupção de pools de nós para:
+ Identifique quando as instâncias estão subutilizadas e consolide as workloads.
+ Crie um orçamento de interrupção de pools de nós para limitar a taxa de encerramentos de nós devido à oscilação, a um vazio e à consolidação.
Por padrão, o Modo Automático do EKS:
+ Consolida instâncias subutilizadas.
+ Encerra as instâncias após 336 horas.
+ Define um único orçamento de interrupção de 10% dos nós.
+ Permite que os nós sejam substituídos devido ao desvio quando uma nova AMI do Modo Automático é lançada, o que ocorre aproximadamente uma vez por semana.
## Término do período de carência
Quando o `terminationGracePeriod` não está explicitamente definido em um NodePool automático do EKS, o sistema aplica automaticamente um período de carência padrão com término em 24 horas ao NodeClaim associado. Embora os clientes do Modo Automático do EKS não vejam um padrão de `terminationGracePeriod` em suas configurações personalizadas do NodePool, eles constatarão esse valor padrão no NodeClaim. A funcionalidade permanece consistente, independentemente de o período de carência ser definido explicitamente no NodePool ou ser padronizado no NodeClaim, garantindo um comportamento previsível de encerramento do nó em todo o cluster.
# Grupos de nós de capacidade estática no modo automático do EKS
O modo automático do Amazon EKS oferece suporte a grupos de nós de capacidade estática que mantêm um número fixo de nós, independentemente da demanda de pods. Os grupos de nós com capacidade estática são úteis para workloads que demandam previsibilidade de capacidade, instâncias reservadas ou requisitos de conformidade específicos nos quais é necessário manter uma área de ocupação de infraestrutura consistente.
Ao contrário dos grupos de nós dinâmicos que escalam com base nas demandas de agendamento de pods, os grupos de nós de capacidade estática mantêm o número de nós que você configurou.
## Configuração de um grupo de nós de capacidade estática
Para criar um grupo de nós de capacidade estática, defina o campo `replicas` em sua especificação de NodePool. O campo `replicas` define o número exato de nós que o grupo de nós manterá. Veja [Exemplos](#static-capacity-examples) para saber como configurar `replicas`.
## Considerações sobre o conjunto de nós de capacidade estática
Os grupos de nós de capacidade estática apresentam vários comportamentos e restrições importantes:
**Restrições de configuração:**
+ **Não é possível alternar modos**: depois de definir o campo `replicas` em um grupo de nós, você não pode removê-lo. O grupo de nós não pode alternar entre os modos estático e dinâmico.
+ **Limites de recursos limitados**: há suporte apenas para o campo `limits.nodes` na seção de limites. Os limites de CPU e de memória não são aplicáveis.
+ **Ausência do campo destinado ao peso**: não é possível configurar o campo `weight` em grupos de nós com capacidade estática, já que a seleção de nós não ocorre por prioridade.
**Comportamento operacional:**
+ **Sem consolidação**: nós em conjuntos de capacidade estática não são considerados para consolidação.
+ **Operações de escalabilidade**: as operações de escalabilidade ignoram os orçamentos de interrupção de nós, mas continuam respeitando os PodDisruptionBudgets.
+ **Substituição de nós**: os nós ainda são substituídos por desvio (como atualizações de AMI) e expiração com base na sua configuração.
## Práticas recomendadas
**Planejamento de capacidade:**
+ Defina `limits.nodes` como um valor superior a `replicas` para permitir a escalabilidade temporária durante as operações de substituição de nós.
+ Considere a capacidade máxima necessária durante o desvio de nós ou as atualizações de AMI ao definir os limites.
**Seleção de instâncias:**
+ Use tipos de instância específicos quando você tiver instâncias reservadas ou requisitos de hardware específicos.
+ Evite requisitos excessivamente restritivos que possam limitar a disponibilidade de instâncias durante a escalabilidade.
**Gerenciamento de interrupções:**
+ Configure orçamentos de interrupção apropriados para equilibrar a disponibilidade com as operações de manutenção.
+ Considere a tolerância da aplicação para a substituição de nós ao definir as porcentagens do orçamento.
**Como monitorar o:**
+ Monitore regularmente o campo `status.nodes` para garantir que sua capacidade desejada seja mantida.
+ Configure alertas para quando a contagem real de nós divergir das réplicas desejadas.
**Distribuição de zonas:**
+ Para obter alta disponibilidade, distribua a capacidade estática por várias zonas de disponibilidade.
+ Quando você cria um grupo de nós de capacidade estática que abrange várias zonas de disponibilidade, o modo automático do EKS distribui os nós entre as zonas especificadas, mas não há garantia de que a distribuição será uniforme.
+ Para obter uma distribuição previsível e uniforme entre as zonas de disponibilidade, crie grupos de nós de capacidade estática separados, cada um fixado a uma zona de disponibilidade específica usando o requisito `topology.kubernetes.io/zone`.
+ Se você precisar de 12 nós distribuídos uniformemente em três zonas, crie três grupos de nós com quatro réplicas cada, em vez de um único grupo de nós com 12 réplicas abrangendo as três zonas.
## Escalabilidade de um grupo de nós de capacidade estática
É possível alterar o número de réplicas em um grupo de nós de capacidade estática usando o comando `kubectl scale`:
```
# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5
```
Ao reduzir a escala verticalmente, o modo automático do EKS encerra os nós de maneira controlada, respeitando os PodDisruptionBudgets e possibilitando o reagendamento dos pods em execução nos nós remanescentes.
## Monitoramento dos grupos de nós de capacidade estática
Use os seguintes comandos para monitorar os grupos de nós de capacidade estática:
```
# View node pool status
kubectl get nodepool static-nodepool
# Get detailed information including current node count
kubectl describe nodepool static-nodepool
# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'
```
O campo `status.nodes` mostra o número atual de nós gerenciados pelo grupo de nós, que deve corresponder à sua contagem de `replicas` desejada em condições normais.
## Solução de problemas
**Nós não atingem o número de réplicas desejado:**
+ Verifique se o valor de `limits.nodes` é suficiente
+ Verifique se seus requisitos não estão restringindo excessivamente a seleção de instâncias
+ Revise as cotas de serviço da AWS para os tipos de instância e regiões que você está usando
**Substituição de nós demorando muito:**
+ Ajuste os orçamentos de interrupção para permitir mais substituições simultâneas
+ Verifique se os PodDisruptionBudgets estão impedindo o encerramento dos nós
**Encerramento inesperado de nós:**
+ Analise as configurações `expireAfter` e `terminationGracePeriod`
+ Verifique se houve encerramentos manuais de nós ou eventos de manutenção da AWS
## Exemplos
### Grupo de nós de capacidade estática básico
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: basic-static
spec:
replicas: 5
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["m"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a"]
limits:
nodes: 8 # Allow scaling up to 8 during operations
```
### Capacidade estática com tipos de instância específicos
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: reserved-instances
spec:
replicas: 20
template:
metadata:
labels:
instance-type: reserved
cost-center: production
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: ["m5.2xlarge"] # Specific instance type
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
limits:
nodes: 25
disruption:
# Conservative disruption for production workloads
budgets:
- nodes: 10%
```
### Grupo de nós de capacidade estática em diversas zonas
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: multi-zone-static
spec:
replicas: 12 # Will be distributed across specified zones
template:
metadata:
labels:
availability: high
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["8", "16"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
limits:
nodes: 15
disruption:
budgets:
- nodes: 25%
```
### Capacidade estática com reserva de capacidade
O exemplo a seguir mostra como usar um pool de nós de capacidade estática com uma Reserva de Capacidade do EC2. Para obter mais informações sobre como usar as Reservas de Capacidade do EC2 com o Modo Automático do EKS, consulte [Controle da implantação de workloads em reservas de capacidade com o modo automático do EKS](auto-odcr.md).
`NodeClass` definindo `capacityReservationSelectorTerms`
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: capacity-reservation-nodeclass
spec:
role: AmazonEKSNodeRole
securityGroupSelectorTerms:
- id: sg-0123456789abcdef0
subnetSelectorTerms:
- id: subnet-0123456789abcdef0
capacityReservationSelectorTerms:
- id: cr-0123456789abcdef0
```
`NodePool` referenciando `NodeClass` acima e usando `karpenter.sh/capacity-type: reserved`.
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: static-capacity-reservation-nodepool
spec:
replicas: 5
limits:
nodes: 8 # Allow scaling up to 8 during operations
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: capacity-reservation-nodeclass
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ['reserved']
```
# Criar uma IngressClass para configurar um Application Load Balancer
O Modo automático do EKS automatiza tarefas de rotina de balanceamento de carga, incluindo a exposição de aplicações de cluster à internet.
A AWS sugere o uso de Application Load Balancers (ALB) para fornecer tráfego HTTP e HTTPS. Os Application Load Balancers podem rotear solicitações com base no conteúdo da solicitação. Para obter mais informações sobre Application Load Balancers, consulte [What is Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html).
O Modo automático do EKS cria e configura Application Load Balancers (ALBs). Por exemplo, o Modo automático do EKS cria um balanceador de carga quando você cria um objeto `Ingress` do Kubernetes e o configura para rotear o tráfego para a workload do cluster.
**Visão geral**
1. Crie uma workload que você deseja expor à internet.
1. Crie um recurso `IngressClassParams`, especificando valores de configuração da AWS específicos, como o certificado a ser usado para sub-redes SSL/TLS e VPC.
1. Crie um recurso `IngressClass`, especificando que o Modo automático do EKS será o controlador do recurso.
1. Crie um recurso `Ingress` que associe um caminho HTTP e uma porta a uma workload do cluster.
O Modo automático do EKS criará um Application Load Balancer que aponte para a workload específica no recurso `Ingress`, usando a configuração do balanceador de carga específica no recurso `IngressClassParams`.
## Pré-requisitos
+ Modo automático do EKS habilitado em um cluster do Amazon EKS
+ Kubectl configurado para se conectar ao cluster
+ Você pode usar `kubectl apply -f ` para aplicar os arquivos YAML de configuração de exemplo abaixo ao cluster.
**nota**
O Modo automático do EKS precisa de tags de sub-rede para identificar sub-redes públicas e privadas.
Se você criou o cluster com o `eksctl`, você já tem essas tags.
Saiba como [Marcar sub-redes para o Modo Automático do EKS](tag-subnets-auto.md).
## Etapa 1: criar uma workload
Para começar, crie uma workload que você deseja expor à internet. Pode ser qualquer recurso do Kubernetes que envia tráfego HTTP, como um Deployment e um Service.
Este exemplo usa um serviço HTTP simples, chamado `service-2048`, que atua como receptor na porta `80`. Crie este serviço e a sua implantação aplicando o seguinte manifesto, `2048-deployment-service.yaml`:
```
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 2
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: app-2048
```
Aplicar a configuração ao cluster:
```
kubectl apply -f 2048-deployment-service.yaml
```
Os recursos listados acima serão criados no namespace padrão. Você pode verificar isso executando o seguinte comando:
```
kubectl get all -n default
```
## Etapa 2: criar IngressClassParams
Crie um objeto `IngressClassParams` para especificar as opções de configuração da AWS específicas do Application Load Balancer. Neste exemplo, criamos um recurso `IngressClassParams` denominado `alb` (que você usará na próxima etapa) que especifica o esquema do balanceador de carga como `internet-facing` em um arquivo nomeado como `alb-ingressclassparams.yaml`.
```
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
name: alb
spec:
scheme: internet-facing
```
Aplicar a configuração ao cluster:
```
kubectl apply -f alb-ingressclassparams.yaml
```
## Etapa 3: criar IngressClass
Crie um `IngressClass` que faça referência aos valores de configuração específicos da AWS definidos no recurso `IngressClassParams` em um arquivo nomeado como `alb-ingressclass.yaml`. Registre o nome da `IngressClass`. Neste exemplo, tanto `IngressClass` como `IngressClassParams` são denominados `alb`.
Use a anotação `is-default-class` para controlar se os recursos `Ingress` devem usar essa classe por padrão.
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: alb
annotations:
# Use this annotation to set an IngressClass as Default
# If an Ingress doesn't specify a class, it will use the Default
ingressclass.kubernetes.io/is-default-class: "true"
spec:
# Configures the IngressClass to use EKS Auto Mode
controller: eks.amazonaws.com/alb
parameters:
apiGroup: eks.amazonaws.com
kind: IngressClassParams
# Use the name of the IngressClassParams set in the previous step
name: alb
```
Para obter mais informações sobre as opções de configuração, consulte [Referência IngressClassParams](#ingress-reference).
Aplicar a configuração ao cluster:
```
kubectl apply -f alb-ingressclass.yaml
```
## Etapa 4: criar Ingress
Crie um recurso `Ingress` em um arquivo nomeado como `alb-ingress.yaml`. O objetivo desse recurso é associar caminhos e portas no Application Load Balancer às workloads no cluster. Neste exemplo, criamos um recurso `Ingress` denominado `2048-ingress` que roteia o tráfego para um serviço denominado `service-2048` na porta 80.
Para obter mais informações sobre como configurar esse recurso, consulte [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) na documentação do Kubernetes.
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: 2048-ingress
spec:
# this matches the name of IngressClass.
# this can be omitted if you have a default ingressClass in cluster: the one with ingressclass.kubernetes.io/is-default-class: "true" annotation
ingressClassName: alb
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: service-2048
port:
number: 80
```
Aplicar a configuração ao cluster:
```
kubectl apply -f alb-ingress.yaml
```
## Etapa 5: verificar o status
Use `kubectl` para encontrar o status de `Ingress`. Pode levar alguns minutos para que o balanceador de carga esteja disponível.
Use o nome do recurso `Ingress` que você definiu na etapa anterior. Por exemplo:
```
kubectl get ingress 2048-ingress
```
Quando o recurso estiver pronto, recupere o nome de domínio do balanceador de carga.
```
kubectl get ingress 2048-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
```
Para visualizar o serviço em um navegador da Web, analise a porta e o caminho especificados no recurso `Ingress`.
## Etapa 6: limpeza
Para limpar o balanceador de carga, use o seguinte comando:
```
kubectl delete ingress 2048-ingress
kubectl delete ingressclass alb
kubectl delete ingressclassparams alb
```
O Modo automático do EKS excluirá automaticamente o balanceador de carga associado na conta da AWS.
## Referência IngressClassParams
A tabela abaixo é uma referência rápida das opções de configuração mais usadas.
| Campo | Descrição | Valor de exemplo |
| --- | --- | --- |
| `scheme` | Define se o ALB é interno ou voltado para a internet | `internet-facing` |
| `namespaceSelector` | Restringe quais namespaces podem usar esta IngressClass | `environment: prod` |
| `group.name` | Agrupa várias entradas para compartilhar um único ALB | `retail-apps` |
| `ipAddressType` | Define o tipo de endereço IP para o ALB | `dualstack` |
| `subnets.ids` | Lista de IDs de sub-rede para implantação do ALB | `subnet-xxxx, subnet-yyyy` |
| `subnets.tags` | Filtros de tag para selecionar sub-redes do ALB | `Environment: prod` |
| `certificateARNs` | ARNs de certificados SSL para usar | ` arn:aws:acm:region:account:certificate/id` |
| `tags` | Tags personalizadas de recursos da AWS | `Environment: prod, Team: platform` |
| `loadBalancerAttributes` | Atributos específicos do balanceador de carga | `idle_timeout.timeout_seconds: 60` |
## Considerações
+ Você não pode usar Anotações em uma IngressClass para configurar balanceadores de carga com o Modo automático do EKS. A configuração da IngressClass deve ser feita por meio do IngressClassParams. No entanto, você pode usar anotações em recursos individuais do Ingress para configurar o comportamento do balanceador de carga (como `alb.ingress.kubernetes.io/security-group-prefix-lists` ou `alb.ingress.kubernetes.io/conditions.*`).
+ Você não pode definir [ListenerAttribute](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ListenerAttribute.html) com o modo automático do EKS.
+ Você deve atualizar o perfil do IAM do cluster para permitir a propagação de tags do Kubernetes para os recursos do AWS Load Balancer. Para obter mais informações, consulte [Tags da AWS personalizadas para recursos do Modo Automático do EKS.](auto-learn-iam.md#tag-prop).
+ Para obter informações sobre como associar recursos ao Modo automático do EKS ou ao AWS Load Balancer Controller autogerenciado, consulte [Referência de migração](migrate-auto.md#migration-reference).
+ Para obter informações sobre como corrigir problemas com balanceadores de carga, consulte [Solucionar problemas do Modo Automático do EKS](auto-troubleshoot.md).
+ Para obter mais considerações sobre o uso do recurso de balanceamento de carga do Modo automático do EKS, consulte [Balanceamento de carga](auto-networking.md#auto-lb-consider).
As tabelas a seguir fornecem uma comparação detalhada das alterações nas configurações de IngressClassParams, anotações de Ingress e TargetGroupBinding do Modo automático do EKS. Essas tabelas destacam as principais diferenças entre a capacidade de balanceamento de carga do Modo automático do EKS e o controlador de balanceador de carga de código aberto, incluindo alterações na versão da API, recursos obsoletos e nomes de parâmetros atualizados.
### IngressClassParams
| Anterior | Novo | Descrição |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Alteração de versão da API |
| `spec.certificateArn` | `spec.certificateARNs` | Compatibilidade com vários ARNs de certificados |
| `spec.subnets.tags` | `spec.subnets.matchTags` | Esquema de correspondência de sub-rede alterado |
| `spec.listeners.listenerAttributes` | Não compatível | Ainda não há suporte para o modo automático do EKS |
### Anotações de Ingress
| Anterior | Novo | Descrição |
| --- | --- | --- |
| `kubernetes.io/ingress.class` | Não compatível | Use `spec.ingressClassName` em objetos Ingress |
| `alb.ingress.kubernetes.io/group.name` | Não compatível | Especifique grupos somente em IngressClass |
| `alb.ingress.kubernetes.io/waf-acl-id` | Não compatível | Use WAF v2 em vez disso |
| `alb.ingress.kubernetes.io/web-acl-id` | Não compatível | Use WAF v2 em vez disso |
| `alb.ingress.kubernetes.io/shield-advanced-protection` | Não compatível | Integração com Shield desabilitada |
| `alb.ingress.kubernetes.io/auth-type: oidc` | Não compatível | No momento, o tipo OIDC Auth não é compatível. |
### TargetGroupBinding
| Anterior | Novo | Descrição |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Alteração de versão da API |
| `spec.targetType` opcional | `spec.targetType` obrigatório | Especificação explícita do tipo de destino |
| `spec.networking.ingress.from` | Não compatível | Não oferece mais compatibilidade com NLB sem grupos de segurança |
Para usar o recurso personalizado TargetGroupBinding, é necessário marcar o grupo de destino com a etiqueta “eks:eks-cluster-name” contendo o nome do cluster para conceder ao controlador as permissões do IAM necessárias. Esteja ciente de que o controlador excluirá o grupo de destino quando o recurso TargetGroupBinding ou o cluster for excluído.
# Usar anotações de serviço para configurar Network Load Balancers
Saiba como configurar Network Load Balancers (NLB) no Amazon EKS usando anotações de serviço do Kubernetes. Este tópico explica as anotações compatíveis com o Modo Automático do EKS para personalizar o comportamento do NLB, incluindo acessibilidade à internet, verificações de integridade, terminação SSL e TLS e modos de direcionamento IP.
Quando você cria um serviço do Kubernetes do tipo `LoadBalancer` no Modo Automático do EKS, o EKS provisiona e configura automaticamente um AWS Network Load Balancer com base nas anotações que você especifica. Essa abordagem declarativa permite que você gerencie as configurações do balanceador de carga diretamente por meio dos manifestos do Kubernetes, mantendo práticas de infraestrutura como código.
O Modo Automático do EKS gerencia o provisionamento do Network Load Balancer por padrão para todos os serviços do tipo LoadBalancer. Nenhuma instalação ou configuração adicional de controlador é necessária. A especificação `loadBalancerClass: eks.amazonaws.com/nlb` é automaticamente definida como padrão do cluster, simplificando o processo de implantação e mantendo a compatibilidade com as workloads existentes do Kubernetes.
**nota**
O Modo Automático do EKS precisa de tags de sub-rede para identificar sub-redes públicas e privadas.
Se você criou o cluster com o `eksctl`, você já tem essas tags.
Saiba como [Marcar sub-redes para o Modo Automático do EKS](tag-subnets-auto.md).
## Serviço de exemplo
Para obter mais informações sobre o recurso `Service` do Kubernetes, consulte [a documentação do Kubernetes](https://kubernetes.io/docs/concepts/services-networking/service/).
Analise o recurso `Service` de exemplo abaixo:
```
apiVersion: v1
kind: Service
metadata:
name: echoserver
annotations:
# Specify the load balancer scheme as internet-facing to create a public-facing Network Load Balancer (NLB)
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
selector:
app: echoserver
ports:
- port: 80
targetPort: 8080
protocol: TCP
type: LoadBalancer
# Specify the new load balancer class for NLB as part of EKS Auto Mode feature
# For clusters with Auto Mode enabled, this field can be omitted as it's the default
loadBalancerClass: eks.amazonaws.com/nlb
```
## Anotações comumente usadas
A tabela a seguir lista as anotações comumente usadas compatíveis com o Modo Automático do EKS. Observe que o Modo Automático do EKS pode não ser compatível com todas as anotações.
**dica**
Todas as anotações a seguir precisam ser prefixadas com `service.beta.kubernetes.io/`
| Campo | Descrição | Exemplo |
| --- | --- | --- |
| `aws-load-balancer-type` | Especifica o tipo de balanceador de carga. Use `external` para novas implantações. | `external` |
| `aws-load-balancer-nlb-target-type` | Especifica se o tráfego deve ser roteado para instâncias de nós ou diretamente para IPs de pod. Use `instance` para implantações padrão ou `ip` para roteamento direto de pods. | `instance` |
| `aws-load-balancer-scheme` | Controla se o balanceador de carga é interno ou voltado para a internet. | `internet-facing` |
| `aws-load-balancer-healthcheck-protocol` | Protocolo de verificação de integridade do grupo de destino. As opções comuns são `TCP` (padrão) ou `HTTP`. | `HTTP` |
| `aws-load-balancer-healthcheck-path` | O caminho HTTP para verificações de integridade ao usar o protocolo HTTP e HTTPS. | `/healthz` |
| `aws-load-balancer-healthcheck-port` | Porta usada para verificações de integridade. Pode ser um número de porta específico ou `traffic-port`. | `traffic-port` |
| `aws-load-balancer-subnets` | Especifica em quais sub-redes criar o balanceador de carga. Pode usar IDs ou nomes de sub-rede. | `subnet-xxxx, subnet-yyyy` |
| `aws-load-balancer-ssl-cert` | ARN do certificado SSL do AWS Certificate Manager para HTTPS e TLS. | ` arn:aws:acm:region:account:certificate/cert-id` |
| `aws-load-balancer-ssl-ports` | Especifica quais portas devem usar SSL e TLS. | `443, 8443` |
| `load-balancer-source-ranges` | Intervalos CIDR permitidos para acessar o balanceador de carga. | `10.0.0.0/24, 192.168.1.0/24` |
| `aws-load-balancer-additional-resource-tags` | Tags adicionais da AWS a serem aplicadas ao balanceador de carga e aos recursos relacionados. | `Environment=prod,Team=platform` |
| `aws-load-balancer-ip-address-type` | Especifica se o balanceador de carga usa IPv4 ou pilha dupla (IPv4 \$1 IPv6). | `ipv4` ou `dualstack` |
## Considerações
+ Você deve atualizar o perfil do IAM do cluster para permitir a propagação de tags do Kubernetes para os recursos do AWS Load Balancer. Para obter mais informações, consulte [Tags da AWS personalizadas para recursos do Modo Automático do EKS.](auto-learn-iam.md#tag-prop).
+ Para obter informações sobre como associar recursos ao Modo automático do EKS ou ao AWS Load Balancer Controller autogerenciado, consulte [Referência de migração](migrate-auto.md#migration-reference).
+ Para obter informações sobre como corrigir problemas com balanceadores de carga, consulte [Solucionar problemas do Modo Automático do EKS](auto-troubleshoot.md).
+ Para obter mais considerações sobre o uso do recurso de balanceamento de carga do Modo Automático do EKS, consulte [Balanceamento de carga](auto-networking.md#auto-lb-consider).
Ao migrar para o Modo Automático do EKS de balanceamento de carga, várias alterações nas anotações de serviço e nas configurações de recursos são necessárias. As tabelas a seguir descrevem as principais diferenças entre as implementações anteriores e as novas, incluindo opções não compatíveis e alternativas recomendadas.
### Anotações do serviço
| Anterior | Novo | Descrição |
| --- | --- | --- |
| `service.beta.kubernetes.io/load-balancer-source-ranges` | Não compatível | Use `spec.loadBalancerSourceRanges` no serviço |
| `service.beta.kubernetes.io/aws-load-balancer-type` | Não compatível | Use `spec.loadBalancerClass` no serviço |
| `service.beta.kubernetes.io/aws-load-balancer-internal` | Não compatível | Use `service.beta.kubernetes.io/aws-load-balancer-scheme` |
| `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol` | Não compatível | Use `service.beta.kubernetes.io/aws-load-balancer-target-group-attributes` em vez disso |
| Vários atributos do balanceador de carga | Não compatível | Use `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` | Não compatível | Use `service.beta.kubernetes.io/aws-load-balancer-attributes` em vez disso |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` | Não compatível | Use `service.beta.kubernetes.io/aws-load-balancer-attributes` em vez disso |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` | Não compatível | Use `service.beta.kubernetes.io/aws-load-balancer-attributes` em vez disso |
| `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled` | Não compatível | Use `service.beta.kubernetes.io/aws-load-balancer-attributes` em vez disso |
Para migrar das anotações de atributos obsoletas do balanceador de carga, consolide essas configurações na anotação `service.beta.kubernetes.io/aws-load-balancer-attributes`. Essa anotação aceita uma lista de pares chave/valor separados por vírgula de vários atributos do balanceador de carga. Por exemplo, para especificar o registro de acesso em log e o balanceamento de carga entre zonas, use o seguinte formato:
```
service.beta.kubernetes.io/aws-load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=my-bucket,access_logs.s3.prefix=my-prefix,load_balancing.cross_zone.enabled=true
```
Esse formato consolidado fornece uma maneira mais consistente e flexível de configurar os atributos do balanceador de carga e, ao mesmo tempo, reduz o número de anotações individuais necessárias. Analise suas configurações de serviço existentes e atualize-as para usar esse formato consolidado.
### TargetGroupBinding
| Anterior | Novo | Descrição |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Alteração de versão da API |
| `spec.targetType` opcional | `spec.targetType` obrigatório | Especificação explícita do tipo de destino |
| `spec.networking.ingress.from` | Não compatível | Não oferece mais compatibilidade com NLB sem grupos de segurança |
Observação: para usar o recurso personalizado TargetGroupBinding, é necessário marcar o grupo de destino com a etiqueta `eks:eks-cluster-name` contendo o nome do cluster para conceder ao controlador as permissões do IAM necessárias. Esteja ciente de que o controlador excluirá o grupo de destino quando o recurso TargetGroupBinding ou o cluster for excluído.
# Criar uma classe de armazenamento
Uma `StorageClass` no Modo automático do Amazon EKS define como os volumes do Amazon EBS são provisionados automaticamente quando as aplicações solicitam armazenamento persistente. Esta página explica como criar e configurar uma `StorageClass` que funcione com o Modo automático do Amazon EKS para provisionar volumes do EBS.
Ao configurar uma `StorageClass`, você pode especificar as configurações padrão para os volumes do EBS, incluindo tipo de volume, criptografia, IOPS e outros parâmetros de armazenamento. Você também pode configurar a `StorageClass` para usar chaves do AWS KMS para gerenciamento de criptografia.
O Modo automático do EKS não cria uma `StorageClass` para você. Você deve criar uma `StorageClass` referenciando `ebs.csi.eks.amazonaws.com` para usar o recurso de armazenamento do Modo automático do EKS.
Primeiro, crie um arquivo denominado `storage-class.yaml`:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
allowedTopologies:
- matchLabelExpressions:
- key: eks.amazonaws.com/compute-type
values:
- auto
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
Segundo, aplique a classe de armazenamento ao cluster.
```
kubectl apply -f storage-class.yaml
```
**Principais componentes:**
+ `provisioner: ebs.csi.eks.amazonaws.com`: usa o modo automático do EKS
+ `allowedTopologies`: especificar `matchLabelExpressions` para combinar com `eks.amazonaws.com/compute-type:auto` garantirá que, se seus pods precisarem de um volume provisionado automaticamente usando o Modo automático, os pods não serão agendados em nós não automáticos.
+ `volumeBindingMode: WaitForFirstConsumer`: atrasa a criação do volume até que um pod precise dele
+ `type: gp3`: especifica o tipo de volume do EBS
+ `encrypted: "true"`: o EBS criptografará todos os volumes criados usando a `StorageClass`. O EBS usará o alias de chave `aws/ebs` padrão. Para obter mais informações, consulte [How Amazon EBS encryption works](https://docs.aws.amazon.com/ebs/latest/userguide/how-ebs-encryption-works.html) no Guia do usuário do Amazon EBS. Este valor é opcional, mas sugerido.
+ `storageclass.kubernetes.io/is-default-class: "true"`: o Kubernetes usará essa classe de armazenamento por padrão, a menos que você especifique uma classe de volume diferente em uma reivindicação de volume persistente. Este valor é opcional. Tenha cuidado ao definir esse valor se estiver migrando de um controlador de armazenamento diferente.
## Usar uma chave autogerenciada do KMS para criptografar volumes do EBS
Para usar uma chave autogerenciada do KMS para criptografar volumes do EBS automatizados pelo Modo automático do EKS, você precisa:
1. Criar uma chave autogerenciada do KMS.
+ Para obter mais informações, consulte [Create a symmetric encryption KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html) ou [How Amazon Elastic Block Store (Amazon EBS) uses KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html) no Guia do usuário do KMS.
1. Crie uma nova política que permita o acesso à chave do KMS.
+ Use o exemplo de política do IAM abaixo para criar a política. Insira o ARN da nova chave autogerenciada do KMS. Para obter mais informações, consulte a seção [Criar perfis e anexar políticas (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) do Guia do usuário do AWS IAM.
1. Anexe a política ao perfil do cluster do EKS.
+ Use o console da AWS para encontrar o ARN do perfil do cluster do EKS. As informações do perfil estão visíveis na seção **Visão geral**. Para obter mais informações, consulte [Função do IAM do cluster do Amazon EKS](cluster-iam-role.md).
1. Atualize a `StorageClass` para fazer referência ao ID da chave do KMS no campo `parameters.kmsKeyId`.
### Exemplo de política do IAM autogerenciada do KMS
Atualize os seguintes valores na política abaixo:
+ ``: o ID da conta da AWS, como `111122223333`
+ ``: a região da AWS do cluster, como `us-west-2`
```
{
"Version":"2012-10-17",
"Id": "key-auto-policy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:CallerAccount": "123456789012",
"kms:ViaService": "ec2.us-east-1.amazonaws.com"
}
}
}
]
}
```
### Exemplo da `StorageClass` autogerenciada do KMS
```
parameters:
type: gp3
encrypted: "true"
kmsKeyId:
```
## Referência a parâmetros da `StorageClass`
Para obter informações gerais sobre os recursos da `StorageClass` do Kubernetes, consulte [Storage Classes](https://kubernetes.io/docs/concepts/storage/storage-classes/) na documentação do Kubernetes.
A seção `parameters` do recurso `StorageClass` é específica para a AWS. Use a tabela a seguir para analisar as opções disponíveis.
| Parâmetros | Valores | Padrão | Descrição |
| --- | --- | --- | --- |
| "csi.storage.k8s.io/fstype" | xfs, ext2, ext3, ext4 | ext4 | Tipo de sistema de arquivos que será formatado durante a criação do volume. Esse parâmetro diferencia maiúsculas de minúsculas. |
| "type" | io1, io2, gp2, gp3, sc1, st1, standard, sbp1, sbg1 | gp3 | Tipo de volume do EBS. |
| "iopsPerGB" | | | Operações de E/S por segundo por GiB. Pode ser especificado para volumes IO1, IO2 e GP3. |
| "allowAutoIOPSPerGBIncrease" | true, false | false | Quando `"true"`, o driver CSI aumenta o IOPS para um volume quando `iopsPerGB * ` está muito baixo para se enquadrar na faixa de IOPS compatível com a AWS. Isso permite que o provisionamento dinâmico sempre tenha êxito, mesmo quando o usuário especificar uma capacidade de PVC ou valor de `iopsPerGB` muito pequeno. Por outro lado, isso pode introduzir custos adicionais, pois esses volumes têm IOPS mais alto do que o solicitado em `iopsPerGB`. |
| "iops" | | | Operações de E/S por segundo. Pode ser especificado para volumes IO1, IO2 e GP3. |
| "throughput" | | 125 | Throughput em MiB/s. Eficaz somente quando o tipo de volume gp3 é especificado. |
| "encrypted" | true, false | false | Especifica se o volume deve ser criptografado ou não. Os valores válidos são "true" ou "false". |
| "blockExpress" | true, false | false | Permite a criação de volumes io2 Block Express. |
| "kmsKeyId" | | | O ARN completo da chave a ser usada ao criptografar o volume. Se não for especificado, a AWS usará a chave padrão do KMS para a região em que o volume está. Será uma chave gerada automaticamente, denominada `/aws/ebs` caso não seja alterada. |
| "blockSize" | | | O tamanho do bloco a ser usado ao formatar o sistema de arquivos subjacente. Compatível apenas com nós Linux e com o fstype `ext2`, `ext3`, `ext4` ou `xfs`. |
| "inodeSize" | | | O tamanho do inode a ser usado ao formatar o sistema de arquivos subjacente. Compatível apenas com nós Linux e com o fstype `ext2`, `ext3`, `ext4` ou `xfs`. |
| "bytesPerInode" | | | O `bytes-per-inode` a ser usado ao formatar o sistema de arquivos subjacente. Compatível apenas com nós Linux e com o fstype `ext2`, `ext3`, `ext4`. |
| "numberOfInodes" | | | O `number-of-inodes` a ser usado ao formatar o sistema de arquivos subjacente. Compatível apenas com nós Linux e com o fstype `ext2`, `ext3`, `ext4`. |
| "ext4BigAlloc" | true, false | false | Altera o sistema de arquivos `ext4` para usar a alocação de blocos em cluster habilitando a opção de formatação `bigalloc`. Aviso: `bigalloc` pode não ser totalmente compatível com o Kernel Linux do nó. |
| "ext4ClusterSize" | | | O tamanho do cluster a ser usado ao formatar um sistema de arquivos `ext4` quando o recurso `bigalloc` está habilitado. Observação: o parâmetro `ext4BigAlloc` deve ser definido como true. |
Para obter mais informações, consulte [AWS EBS CSI Driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md) no GitHub.
## Considerações
**nota**
Você só pode implantar workloads que dependam das StorageClasses no Modo automático do EKS em nós do Modo automático do EKS. Se você tiver um cluster com tipos mistos de nós, precisará configurar suas workloads para serem executadas somente em nós do Modo automático do EKS. Para obter mais informações, consulte [Controlar se uma workload é implantada nos nós do Modo Automático do EKS](associate-workload.md).
A capacidade de armazenamento em blocos do Modo automático do EKS é diferente do driver CSI do EBS.
+ Provisionamento estático
+ Caso queira usar volumes do EBS criados externamente com o Modo automático do EKS, você precisará adicionar manualmente uma tag da AWS com a chave `eks:eks-cluster-name` e o valor do nome do cluster.
+ Taint de inicialização de nós
+ Você não pode usar o recurso de taint de inicialização de nós para impedir a programação de pods antes que a capacidade de armazenamento esteja pronta.
+ Tags personalizadas em volumes provisionados dinamicamente
+ Você não pode usar o sinalizador extra-tag da CLI para configurar tags personalizadas em volumes do EBS provisionados dinamicamente
+ Você pode usar a marcação de `StorageClass` para adicionar tags personalizadas. O Modo automático do EKS adicionará tags aos recursos associados da AWS. Você precisará atualizar o perfil do IAM do cluster para tags personalizadas. Para obter mais informações, consulte [Tags da AWS personalizadas para recursos do Modo Automático do EKS.](auto-learn-iam.md#tag-prop).
+ Métricas de performance detalhadas do EBS
+ Você não pode acessar as métricas do Prometheus da performance detalhada do EBS
## Instalar o complemento do Controlador de Snapshots da CSI
O Modo automático do EKS é compatível com o complemento do Controlador de Snapshots da CSI do Amazon EKS.
A AWS sugere que você configure esse complemento para ser executado no grupo de nós `system` integrado.
Para obter mais informações, consulte:
+ [Executar complementos críticos em instâncias dedicadas](critical-workload.md)
+ [Habilitar ou desabilitar NodePools integrados](set-builtin-node-pools.md)
+ [Habilitar a funcionalidade de snapshot para volumes CSI](csi-snapshot-controller.md)
### Para instalar o controlador de snapshots no grupo de nós do sistema
1. Abra o cluster do EKS no console da AWS
1. Na guia **Complementos**, selecione **Obter mais complementos**
1. Selecione **Controlador de Snapshots da CSI** e depois **Próximo**
1. Na página **Configurar definições de complementos selecionados**, selecione **Configurações opcionais** para visualizar o **Esquema de configuração do complemento**
1. Insira o YAML a seguir para associar o controlador de snapshots ao grupo de nós `system`. O controlador de snapshots inclui uma tolerância ao taint `CriticalAddonsOnly`.
```
{
"nodeSelector": {
"karpenter.sh/nodepool": "system"
}
}
```
1. Selecione **Próximo**.
1. Revise a configuração do complemento e selecione **Criar**
# Desabilitar o Modo Automático do EKS
Você pode desabilitar o Modo Automático do EKS em um cluster existente do EKS. É uma operação destrutiva.
+ O EKS encerrará todas as instâncias do EC2 operadas pelo Modo Automático do EKS.
+ O EKS excluirá todos os balanceadores de carga operados pelo Modo Automático do EKS.
+ O EKS **não** excluirá volumes do EBS provisionados pelo Modo Automático do EKS.
O modo automático do EKS foi projetado para gerenciar completamente os recursos que cria. As intervenções manuais podem fazer com que o modo automático do EKS não consiga limpar completamente esses recursos quando for desabilitado. Por exemplo, se você referenciar um grupo de segurança gerenciado a partir de regras externas do grupo de segurança e esquecer de remover essa referência antes de desabilitar o modo automático do EKS para um cluster, o grupo de segurança gerenciado “vazará” (não será excluído). As etapas abaixo descrevem como remover um grupo de segurança vazado, caso isso aconteça.
## Desabilitar o Modo Automático do EKS (console da AWS)
1. Abra a página de visão geral do cluster no Console de gerenciamento da AWS.
1. Em **Modo Automático do EKS**, selecione **Gerenciar**.
1. Alterne o **Modo Automático do EKS** para `off`.
Se algum grupo de segurança gerenciado não for excluído ao final deste processo, é possível excluí-lo manualmente usando as descrições da página [Exclua um grupo de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/deleting-security-groups.html).
## Desabilitar o Modo Automático do EKS (AWS CLI)
Use o comando a seguir para desabilitar o Modo Automático do EKS em um cluster existente.
Você precisa ter a `aws` CLI instalada e estar logado com permissões suficientes para gerenciar clusters do EKS. Para obter mais informações, consulte [Configurar para usar o Amazon EKS](setting-up.md).
**nota**
Os recursos de computação, armazenamento em blocos e balanceamento de carga devem estar todos habilitados ou desabilitados na mesma solicitação.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=false \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": false}}' \
--storage-config '{"blockStorage":{"enabled": false}}'
```
É possível verificar se um grupo de segurança vazado do modo automático do EKS não foi excluído após desabilitar o modo automático do EKS da seguinte maneira:
```
aws ec2 describe-security-groups \
--filters Name=tag:eks:eks-cluster-name,Values= Name=tag-key,Values=ingress.eks.amazonaws.com/resource,service.eks.amazonaws.com/resource --query "SecurityGroups[*].[GroupName]"
```
Para, em seguida, excluir o grupo de segurança:
```
aws ec2 delete-security-group --group-name=
```
# Atualizar a versão do Kubernetes de um cluster do Modo Automático do EKS.
Este tópico explica como atualizar a versão do Kubernetes do cluster no Modo Automático. O Modo Automático simplifica o processo de atualização de versões gerenciando a coordenação das atualizações do ambiente de gerenciamento com as substituições de nós, mantendo a disponibilidade de workloads por meio de orçamentos de interrupção de pods.
Ao atualizar um cluster do Modo Automático, muitos componentes que tradicionalmente exigiam atualizações manuais agora são gerenciados como parte do serviço. Compreender os aspectos automatizados do processo de atualização e suas responsabilidades ajuda a garantir uma transição suave de versão do cluster.
## Saber mais sobre as atualizações com o Modo Automático do EKS
Depois de iniciar uma atualização do ambiente de gerenciamento, o Modo Automático do EKS atualizará os nós no cluster. À medida que os nós expiram, o Modo Automático do EKS os substitui por novos nós. Os novos nós têm a nova versão correspondente do Kubernetes. O Modo Automático do EKS observa os orçamentos de interrupção de pods ao atualizar os nós.
Além disso, não é mais necessário atualizar componentes como:
+ CNI da Amazon VPC
+ AWS Load Balancer Controller
+ CoreDNS
+ `kube-proxy`
+ Karpenter
+ Driver CSI do AWS EBS
O Modo Automático do EKS substitui esses componentes pela funcionalidade de serviço.
Você ainda é responsável por atualizar:
+ Aplicações e workloads implantadas no cluster
+ Complementos e controladores autogerenciados
+ Complementos do Amazon EKS
+ Saiba como [Atualizar um complemento do Amazon EKS](updating-an-add-on.md)
Conheça as [práticas recomendadas para atualizações de clusters](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)
## Iniciar atualização do cluster
Para iniciar uma atualização de cluster, consulte [Atualizar um cluster existente para a nova versão do Kubernetes](update-cluster.md).
# Habilitar ou desabilitar NodePools integrados
O Modo Automático do EKS tem dois NodePools integrados. Você pode habilitar ou desabilitar esses NodePools usando o console da AWS, a CLI ou a API.
## Referência de NodePool integrado
+ `system`
+ Esse NodePool tem um taint `CriticalAddonsOnly`. Muitos complementos do EKS, como o CoreDNS, toleram esse taint. Use esse grupo de nós do sistema para separar aplicações críticas de clusters.
+ É compatível com as arquiteturas `amd64` e `arm64`.
+ `general-purpose`
+ Esse NodePool oferece suporte para iniciar nós de workloads de uso geral no cluster.
+ Usa somente arquitetura `amd64`.
Os dois NodePools integrados:
+ Usam o NodeClass padrão do EKS
+ Usam somente a capacidade sob demanda do EC2
+ Usam as famílias de instâncias C, M e R do EC2
+ Requerem instâncias da 5.ª geração ou mais recentes do EC2
**nota**
É necessário habilitar pelo menos um NodePool integrado para que o EKS provisione o NodeClass “default”. Caso desabilite todos os NodePools integrados, você precisará criar um NodeClass personalizado e configurar um NodePool para usá-lo. Para obter mais informações NodeClasses, consulte [Criar uma classe de nó para o Amazon EKS](create-node-class.md).
## Procedimento
### Pré-requisitos
+ A versão mais recente da AWS Command Line Interface (AWS CLI) instalada e configurada no seu dispositivo. Para verificar sua versão atual, use `aws --version`. Para instalar a versão mais recente, consulte [Instalar](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) e [Configuração rápida com aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config), no Guia do usuário da AWS Command Line Interface.
+ Faça login na CLI com permissões suficientes do IAM para criar recursos da AWS, incluindo políticas do IAM, perfis do IAM e clusters do EKS.
### Habilitar com a AWS CLI
Use o seguinte comando para habilitar os dois NodePools integrados:
```
aws eks update-cluster-config \
--name \
--compute-config '{
"nodeRoleArn": "",
"nodePools": ["general-purpose", "system"],
"enabled": true
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}
}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
Você pode modificar o comando para habilitar seletivamente os NodePools.
### Desabilitar com a AWS CLI
Use o seguinte comando para desabilitar os dois NodePools integrados:
```
aws eks update-cluster-config \
--name \
--compute-config '{
"enabled": true,
"nodePools": []
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
# Controlar se uma workload é implantada nos nós do Modo Automático do EKS
Ao executar workloads em um cluster do EKS com o Modo Automático do EKS, talvez você precise controlar se workloads específicas são executadas nos nós do Modo Automático do EKS ou em outros tipos de computação. Este tópico descreve como usar seletores de nós e regras de afinidade para garantir que as workloads sejam agendadas na infraestrutura de computação pretendida.
Os exemplos neste tópico demonstram como usar o rótulo `eks.amazonaws.com/compute-type` para exigir ou impedir a implantação de uma workload nos nós do Modo Automático do EKS. Isso é particularmente útil em clusters de modo misto em que você está executando o Modo Automático do EKS e outros tipos de computação, como provisionadores do Karpenter autogerenciados ou grupos de nós gerenciados pelo EKS.
Os nós do Modo Automático do EKS definiram o valor do rótulo `eks.amazonaws.com/compute-type` como `auto`. Você pode usar esse rótulo para controlar se uma workload é implantada em nós gerenciados pelo Modo Automático do EKS.
## Exigir que uma workload seja implantada nos nós do Modo Automático do EKS
**nota**
Esse valor de `nodeSelector` não é necessário para o Modo Automático do EKS. Esse valor de `nodeSelector` só será relevante se você estiver executando um cluster em um modo misto, com tipos de nós não gerenciados pelo Modo Automático do EKS. Por exemplo, você pode ter capacidade computacional estática implantada no cluster com grupos de nós gerenciados pelo EKS e capacidade computacional dinâmica gerenciada pelo Modo Automático do EKS.
Você pode adicionar esse `nodeSelector` às implantações ou a outras workloads para exigir que o Kubernetes as programe nos nós do Modo Automático do EKS.
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
## Exigir que uma workload não seja implantada nos nós do Modo Automático do EKS
Você pode adicionar esse `nodeAffinity` às implantações ou a outras workloads para exigir que o Kubernetes **não** as programe nos nós do Modo Automático do EKS.
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- auto
```
# Executar complementos críticos em instâncias dedicadas
Neste tópico, você aprenderá como implantar uma workload com uma tolerância `CriticalAddonsOnly` para que o Modo Automático do EKS a programe no grupo de nós `system`.
O grupo de nós `system` integrado do Modo Automático do EKS foi projetado para executar complementos críticos em instâncias dedicadas. Essa segmentação garante que os componentes essenciais tenham recursos dedicados e fiquem isolados das workloads gerais, aprimorando a estabilidade e a performance gerais do cluster.
Este guia demonstra como implantar complementos no grupo de nós `system` usando a tolerância `CriticalAddonsOnly` e os seletores de nós apropriados. Seguindo estas etapas, você pode garantir que as aplicações críticas sejam programadas nos nós `system` dedicados, aproveitando os benefícios de isolamento e alocação de recursos fornecidos pela estrutura especializada de grupo de nós do Modo Automático do EKS.
O Modo Automático do EKS tem dois grupos de nós integrados: `general-purpose` e `system`. Para ter mais informações, consulte [Habilitar ou desabilitar NodePools integrados](set-builtin-node-pools.md).
O objetivo do grupo de nós `system` é segregar complementos críticos em nós diferentes. Os nós provisionados pelo grupo de nós `system` têm um taint `CriticalAddonsOnly` do Kubernetes. O Kubernetes apenas programará pods nesses nós se eles tiverem uma tolerância correspondente. Para obter mais informações, consulte [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) na documentação do Kubernetes.
## Pré-requisitos
+ Cluster do Modo Automático do EKS com o grupo de nós `system` integrado habilitado. Para ter mais informações, consulte [Habilitar ou desabilitar NodePools integrados](set-builtin-node-pools.md).
+ `kubectl` instalado e configurado. Para ter mais informações, consulte [Configurar para usar o Amazon EKS](setting-up.md).
## Procedimento
Analise o exemplo de YAML abaixo. Observe as seguintes configurações:
+ `nodeSelector`: associa a workload ao grupo de nós `system` integrado. Esse grupo de nós deve ser habilitado com a API da AWS. Para ter mais informações, consulte [Habilitar ou desabilitar NodePools integrados](set-builtin-node-pools.md).
+ `tolerations`: esta tolerância supera o taint `CriticalAddonsOnly` nos nós do grupos de nós `system`.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
nodeSelector:
karpenter.sh/nodepool: system
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- name: app
image: nginx:latest
resources:
requests:
cpu: "500m"
memory: "512Mi"
```
Para atualizar uma workload para executar no grupo de nós `system`, você precisa:
1. Atualizar a workload existente para adicionar as seguintes configurações descritas acima:
+ `nodeSelector`
+ `tolerations`
1. Implantar a workload atualizada no cluster com `kubectl apply`
Depois de atualizar a workload, ela será executada em nós dedicados.
# Usar políticas de rede com o Modo Automático do EKS
## Visão geral
À medida que os clientes escalam os ambientes de aplicação usando o EKS, o isolamento do tráfego de rede torna-se cada vez mais fundamental para evitar o acesso não autorizado a recursos internos e externos ao cluster. Isso é especialmente importante em um ambiente de multilocação, no qual diversas workloads distintas são executadas simultaneamente no mesmo cluster. As políticas de rede do Kubernetes permitem reforçar a postura de segurança de rede das workloads do Kubernetes, incluindo integrações com endpoints externos ao cluster. O modo automático do EKS oferece suporte a diversos tipos de políticas de rede.
### Isolamento nas camadas 3 e 4
As políticas de rede padrão do Kubernetes operam nas camadas 3 e 4 do modelo de rede OSI e permitem que você controle o fluxo de tráfego no nível de endereço IP ou de porta dentro do cluster do Amazon EKS.
#### Casos de uso
+ Realize a segmentação do tráfego de rede entre as workloads para assegurar que a comunicação ocorra apenas entre aplicações relacionadas.
+ Realize o isolamento dos locatários por namespace, usando políticas para garantir a separação de rede.
### Aplicação baseada em DNS
É comum que os clientes implementem workloads no EKS integradas a ambientes distribuídos maiores, sendo que algumas delas devem estabelecer comunicação com sistemas e serviços externos ao cluster (tráfego em direção ao norte). Esses sistemas e serviços podem estar localizados na Nuvem AWS ou completamente fora do ambiente da AWS. As políticas baseadas em Sistema de Nomes de Domínio (DNS) permitem que você fortaleça a postura de segurança ao adotar uma abordagem mais estável e previsível a fim de evitar o acesso não autorizado de pods a recursos ou a endpoints externos ao cluster. Este mecanismo elimina a necessidade de rastrear e de permitir manualmente endereços IP específicos nas listas de permissões. Ao proteger os recursos com uma abordagem baseada em DNS, você também tem mais flexibilidade para atualizar a infraestrutura externa sem precisar flexibilizar a postura de segurança ou modificar as políticas de rede devido a mudanças nas versões originais de servidores e hosts. É possível filtrar o tráfego de saída para endpoints externos utilizando um Nome de Domínio Totalmente Qualificado (FQDN, na sigla em inglês) ou um padrão de correspondência de nome de domínio do DNS. Isso proporciona ainda mais flexibilidade ao ampliar o acesso para diversos subdomínios vinculados a um endpoint específico externo ao cluster.
#### Casos de uso
+ Adote o padrão de abordagem baseada em DNS para filtrar o acesso de um ambiente do Kubernetes a endpoints externos ao cluster.
+ Garanta a segurança do acesso aos serviços da AWS em ambientes com múltiplos locatários.
+ Gerencie o acesso da rede de pods a workloads on-premises em seus ambientes de nuvem híbrida.
### Regras administrativas (ou com abrangência de cluster)
Em alguns casos, como em cenários multilocatários, os clientes podem ter o requisito de aplicar um padrão de segurança de rede que seja válido em todo o cluster. Em vez de criar e gerenciar uma política diferente para cada namespace de forma repetitiva, é possível usar uma política única para o controle centralizado do acesso à rede de diversas workloads no cluster, independentemente do namespace em que estejam. Esses tipos de políticas permitem que você amplie o escopo de aplicação para as regras de filtragem de rede aplicadas nas camadas 3 e 4 ou por meio de regras de DNS.
#### Casos de uso
+ Gerencie de forma centralizada o acesso à rede de todas as workloads (ou de um grupo específico delas) no seu cluster de EKS.
+ Defina uma postura de segurança de rede padrão em todo o cluster.
+ Amplie os padrões de segurança organizacionais ao escopo do cluster com maior eficiência operacional.
## Introdução
### Pré-requisitos
+ Um cluster do Amazon EKS com o Modo Automático do EKS habilitado
+ kubectl configurado para se conectar ao cluster
### Etapa 1: habilitar o Network Policy Controller
Para usar políticas de rede com o Modo Automático do EKS, primeiro você precisa habilitar o Network Policy Controller aplicando um ConfigMap ao cluster.
1. Crie um arquivo chamado `enable-network-policy.yaml` com o seguinte conteúdo:
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. Aplicar o ConfigMap ao cluster:
```
kubectl apply -f enable-network-policy.yaml
```
### Etapa 2: criar e testar políticas de rede
O cluster do Modo Automático do EKS agora está configurado para ser compatível com as políticas de rede do Kubernetes. É possível testar isso com [Demonstração Stars da política de redes do Amazon EKS](network-policy-stars-demo.md).
### Etapa 3: ajustar a configuração do agente de política de rede na classe de nó (opcional)
Como opção, você pode criar uma nova classe de nó para alterar o comportamento padrão do agente de política de rede nos nós ou habilitar o registro em log de eventos de política de rede. Para isso, siga estas etapas:
1. Crie ou edite um arquivo YAML da classe de nó (por exemplo, `nodeclass-network-policy.yaml`) com o seguinte conteúdo:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: network-policy-config
spec:
# Optional: Changes default network policy behavior
networkPolicy: DefaultAllow
# Optional: Enables logging for network policy events
networkPolicyEventLogs: Enabled
# Include other Node Class configurations as needed
```
1. Aplique a configuração da classe de nó ao cluster:
```
kubectl apply -f nodeclass-network-policy.yaml
```
1. Verifique se a classe de nó foi criada:
```
kubectl get nodeclass network-policy-config
```
1. Atualize o grupo de nós para usar essa classe de nó. Para obter mais informações, consulte [Criar um grupo de nós para o Modo Automático do EKS](create-node-pool.md).
## Como funciona?
### Política de rede baseada em DNS
![\[Ilustração do fluxo de trabalho quando uma política baseada em DNS é aplicada no modo automático do EKS\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/apply-dns-policy-1.png)
![\[Ilustração do fluxo de trabalho quando uma política baseada em DNS é aplicada no modo automático do EKS\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/apply-dns-policy-2.png)
1. A equipe responsável pela plataforma aplica uma política baseada em DNS ao cluster de EKS.
1. O Network Policy Controller é responsável por monitorar a criação de políticas no cluster e, em seguida, reconciliar os endpoints das políticas. Neste caso de uso, o Network Policy Controller orienta o agente do nó a realizar a filtragem das solicitações de DNS, seguindo a lista de domínios autorizados na política correspondente. Os nomes de domínio são incluídos na lista de permissões usando o FQDN ou um nome de domínio que corresponda a um padrão definido na configuração de recursos do Kubernetes.
1. A Workload A faz uma tentativa de resolução de IP para um endpoint externo ao cluster. A solicitação de DNS é enviada primeiro a um proxy, que realiza a filtragem das solicitações com base na lista de permissões aplicada por meio da política de rede.
1. Uma vez que a solicitação de DNS é aprovada pela lista de permissões do filtro, ela é encaminhada ao CoreDNS.
1. O CoreDNS, por sua vez, envia a solicitação ao resolvedor de DNS externo (Amazon Route 53 Resolver) para obter a lista de endereços IP associados ao nome de domínio.
1. Os endereços IP resolvidos, juntamente com o TTL, são enviados de volta como resposta à solicitação de DNS. Em seguida, esses IPs são gravados em um mapa eBPF, que é utilizado na etapa seguinte para a aplicação da política na camada de IP.
1. As sondas eBPF anexadas à interface Veth do pod filtrarão o tráfego de saída da Workload A para o endpoint externo ao cluster, com base nas regras em vigor. Isso garante que os pods possam enviar tráfego externo ao cluster apenas para os IPs dos domínios incluídos na lista de permissões. O tempo de validade desses endereços IP baseia-se no TTL retornado pelo resolvedor de DNS externo (Amazon Route 53 Resolver).
#### Uso da Application Network Policy
A `ApplicationNetworkPolicy` combina as funcionalidades das políticas de rede padrão do Kubernetes com a filtragem baseada em DNS no nível do namespace, utilizando uma única definição de recurso personalizado (CRD, na sigla em inglês). Portanto, a `ApplicationNetworkPolicy` pode ser usada para:
1. Definir restrições nas camadas 3 e 4 da pilha de rede usando blocos de IP e números de porta.
1. Definir regras que operam na camada 7 da pilha de rede e permitem filtrar o tráfego com base em FQDNs.
**Importante**
As regras baseadas em DNS definidas por meio do `ApplicationNetworkPolicy` são aplicáveis apenas a workloads em execução em instâncias do EC2 iniciadas no Modo Automático do EKS. O `ApplicationNetworkPolicy` aceita todos os campos do Kubernetes padrão `NetworkPolicy`, com um filtro FQDN adicional para regras de saída.
**Atenção**
Não utilize o mesmo nome para um `ApplicationNetworkPolicy` e um `NetworkPolicy` dentro do mesmo namespace. Se os nomes forem iguais, os objetos `PolicyEndpoints` resultantes podem não refletir corretamente nenhuma das políticas. Ambos os recursos são aceitos sem erros, o que torna difícil diagnosticar esse problema.
Para resolver um conflito de nomenclatura, renomeie `ApplicationNetworkPolicy` ou `NetworkPolicy` para que sejam exclusivos no namespace e verifique se os objetos `PolicyEndpoints` correspondentes foram atualizados corretamente.
#### Exemplo
Você tem uma workload em seu cluster no modo automático do EKS que precisa se comunicar com uma aplicação on-premise, a qual usa um balanceador de carga com um nome de DNS. É possível implementar essa configuração usando a seguinte política de rede:
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
name: my-onprem-app-egress
namespace: galaxy
spec:
podSelector:
matchLabels:
role: backend
policyTypes:
- Egress
egress:
- to:
- domainNames:
- "myapp.mydomain.com"
ports:
- protocol: TCP
port: 8080
```
No nível de rede do Kubernetes, isso permitiria a saída de quaisquer pods no namespace “galaxy” rotulados com `role: backend` para se conectarem ao nome de domínio **myapp.mydomain.com** na porta TCP 8080. Além disso, seria necessário estabelecer a conectividade de rede para que o tráfego seja enviado da VPC em direção ao data center corporativo.
![\[Ilustração de uma workload no modo automático do EKS se comunicando com aplicações on-premises\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/eks-auto-to-on-prem.png)
### Política de rede do administrador (ou do cluster)
![\[Ilustração da ordem de avaliação das políticas de rede no EKS\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/images/evaluation-order.png)
#### Uso da Cluster Network Policy
Quando se usa uma `ClusterNetworkPolicy`, as políticas da camada Administrador têm prioridade na avaliação e não podem ser sobrescritas. Após a avaliação das políticas do nível de Administrador, as políticas padrão com escopo de namespace são utilizadas para executar as regras de segmentação de rede aplicadas. É possível fazer isso usando a `ApplicationNetworkPolicy` ou `NetworkPolicy`. Por fim, as regras do nível Linha de Base, que definem as restrições de rede padrão para as workloads do cluster, serão aplicadas. Essas regras do nível de Linha de Base **podem** ser substituídas pelas políticas com escopo de namespace, se necessário.
#### Exemplo
Imagine que você tem uma aplicação no cluster e deseja isolá-la das workloads pertencentes a outros locatários. É possível bloquear explicitamente o tráfego do cluster proveniente de outros namespaces para impedir o acesso de rede ao namespace da workload sensível.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## Considerações
### Compreensão da ordem de avaliação das políticas
As funcionalidades da política de rede disponíveis no EKS seguem uma ordem de avaliação específica, garantindo que o gerenciamento do tráfego seja sempre seguro e previsível. Dessa forma, compreender o fluxo de avaliação é essencial para projetar uma estratégia de segurança de rede eficiente em seu ambiente.
1. **Políticas do nível de Administrador (avaliadas primeiro)**: todas as ClusterNetworkPolicies do nível de Administrador são avaliadas antes de quaisquer outras políticas. No nível de Administrador, o processamento das políticas segue a ordem de prioridade (o menor número de prioridade tem precedência). O tipo de ação determina o que acontece em seguida no processamento.
+ **Ação de negação (maior precedência)**: quando uma política de Administrador com uma ação de negação corresponde ao tráfego, esse tráfego é bloqueado imediatamente, independentemente de quaisquer outras políticas. O processamento de quaisquer outras regras de ClusterNetworkPolicy ou NetworkPolicy é interrompido. Isso garante que os controles de segurança de nível organizacional não possam ser substituídos por políticas de nível de namespace.
+ **Ação de permissão**: uma vez avaliadas as regras de negação, as políticas de Administrador com a ação de permissão entram em processamento seguindo a ordem de prioridade (o menor número de prioridade tem precedência). Se o tráfego coincidir com uma regra de permissão, ele é liberado imediatamente e o processo de avaliação de políticas é encerrado. Essas políticas podem conceder acesso entre diversos namespaces com base em seletores de rótulos, oferecendo controle centralizado sobre quais workloads podem acessar recursos específicos.
+ **Ação de aprovação**: as ações de aprovação nas políticas do nível de Administrador delegam a tomada de decisão para os níveis inferiores. Quando o tráfego corresponde a uma regra de aprovação, a avaliação ignora todas as regras restantes do nível de Administrador para esse tráfego e prossegue diretamente para o nível de NetworkPolicy. Dessa forma, os administradores conseguem transferir formalmente o controle de padrões específicos de tráfego para as equipes responsáveis pelas aplicações. Por exemplo, é possível usar regras de aprovação para delegar o gerenciamento do tráfego interno do namespace aos administradores do namespace, enquanto mantém controles rígidos sobre o acesso externo.
1. **Nível de política de rede**: se nenhuma política do nível de Administrador corresponder às ações de negação ou de aprovação, ou se uma ação de aprovação for acionada, os recursos de ApplicationNetworkPolicy com escopo de namespace e as NetworkPolicy tradicionais são avaliados em seguida. Essas políticas oferecem controle granular nos namespaces individuais e são gerenciadas pelas equipes responsáveis pela aplicação. As políticas com escopo de namespace conseguem apenas aumentar a restrição imposta pelas políticas de Administrador. Eles não podem substituir a decisão de negação de uma política de Administrador, mas podem restringir ainda mais o tráfego que foi permitido ou aprovado pelas políticas de Administrador.
1. **Políticas de Administrador do nível de Linha de Base**: se nenhuma política do nível de Administrador ou de escopo de namespace corresponder ao tráfego, as ClusterNetworkPolicies do nível de Linha de Base são avaliadas. Estas políticas fornecem posturas de segurança padrão que podem ser substituídas por políticas com escopo de namespace, permitindo que os administradores definam padrões para toda a organização, enquanto oferecem flexibilidade às equipes para realizar personalizações conforme necessário. A avaliação das políticas de Linha de Base respeita a ordem de prioridade, na qual o menor número de prioridade tem precedência.
1. **Negação padrão (se nenhuma política corresponder)**: este comportamento de negação por padrão garante que apenas conexões explicitamente permitidas sejam autorizadas, mantendo uma postura de segurança robusta.
### Aplicação do princípio de privilégio mínimo
+ **Comece com políticas restritivas e adicione permissões gradualmente conforme necessário**: inicie implementando políticas de negação por padrão no nível do cluster e, em seguida, adicione regras de permissão incrementalmente à medida que validar os requisitos legítimos de conectividade. Essa abordagem obriga as equipes a justificarem explicitamente cada conexão externa, criando um ambiente mais seguro e auditável.
+ **Audite regularmente e remova regras de política não utilizadas**: as políticas de rede podem se acumular com o tempo à medida que as aplicações evoluem, deixando para trás regras obsoletas que expandem desnecessariamente a superfície de ataque. Implemente um processo de análise regular para identificar e remover regras de política que não são mais necessárias, garantindo que sua postura de segurança permaneça rígida e sustentável.
+ **Use nomes de domínio específicos em vez de padrões abrangentes sempre que possível**: embora padrões com caracteres curinga, como `*.amazonaws.com`, ofereçam conveniência, eles também concedem acesso a uma ampla variedade de serviços. Sempre que viável, especifique nomes de domínio exatos, como `s3.us-west-2.amazonaws.com`, para limitar o acesso apenas aos serviços específicos que suas aplicações exigem, reduzindo o risco de movimentação lateral caso uma workload seja comprometida.
### Uso de políticas baseadas em DNS no EKS
+ As regras baseadas em DNS, definidas por meio da `ApplicationNetworkPolicy`, são aplicáveis somente a workloads executadas em instâncias do EC2 iniciadas pelo modo automático do EKS. Se você estiver operando um cluster em modo misto (composto por nós de processamento do modo automático do EKS e sem ser nós do modo automático do EKS), as regras baseadas em DNS serão eficazes apenas nos nós de processamento do modo do EKS (instâncias gerenciadas do EC2).
### Validação das políticas de DNS
+ **Use clusters de preparação que espelhem a topologia de rede da produção para testes**: o ambiente de preparação deve replicar a arquitetura de rede, as dependências externas e os padrões de conectividade da produção para garantir testes de política precisos. Isso inclui configurações de VPC compatíveis, comportamento de resolução de DNS e acesso aos mesmos serviços externos que as workloads de produção exigem.
+ **Implemente testes automatizados para caminhos de rede críticos**: desenvolva testes automatizados que validem a conectividade com serviços externos essenciais como parte do pipeline de CI/CD. Esses testes devem verificar se os fluxos de tráfego legítimos são permitidos enquanto as conexões não autorizadas são bloqueadas, fornecendo validação contínua de que as políticas de rede mantêm a postura de segurança correta à medida que sua infraestrutura evolui.
+ **Monitore o comportamento da aplicação após alterações de política**: após implantar políticas de rede novas ou modificadas em ambientes de produção, monitore minuciosamente os logs da aplicação, as taxas de erro e as métricas de performance para identificar rapidamente quaisquer problemas de conectividade. Estabeleça procedimentos claros de reversão para que você possa reverter rapidamente as alterações de política caso elas causem comportamento inesperado da aplicação ou interrupções de serviço.
### Interação com o firewall de DNS do Amazon Route 53
A avaliação das políticas de Administrador e de rede do EKS ocorre primeiro no nível do pod, assim que o tráfego é gerado. Se uma política de rede do EKS permitir a saída para um domínio específico, o pod realiza então uma consulta ao DNS que é encaminhada ao Route 53 Resolver. Nesse ponto, as regras do firewall de DNS do Route 53 são avaliadas. Se o firewall de DNS bloquear a consulta do domínio, a resolução de DNS falha e a conexão não pode ser estabelecida, mesmo que a política de rede do EKS a tenha permitido. Isso cria camadas de segurança complementares. As políticas de rede baseadas em DNS do EKS fornecem controle de saída em nível de pod para requisitos de acesso específicos da aplicação e limites de segurança multilocatários, enquanto o firewall de DNS oferece proteção em toda a VPC contra domínios mal-intencionados conhecidos e aplica listas de bloqueio em toda a organização.
# Marcar sub-redes para o Modo Automático do EKS
Se você usa o recurso de balanceamento de carga do Modo Automático do EKS, é necessário adicionar tags da AWS às sub-redes da VPC.
## Contexto
Essas tags identificam as sub-redes como associadas ao cluster e, o mais importante, se a sub-rede é pública ou privada.
Sub-redes públicas têm acesso direto à internet por meio de um gateway da internet. Elas são usadas para recursos que precisam estar acessíveis ao público, como balanceadores de carga.
As sub-redes privadas não têm acesso direto à internet e usam gateways NAT para tráfego de saída. Elas são usadas para recursos internos, como nós do EKS que não precisam de IPs públicos.
Para saber mais sobre gateways NAT e gateways da internet, consulte [Conectar sua VPC a outras redes](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html) no Guia do usuário da Amazon Virtual Private Cloud (VPC).
## Requisito
No momento, as sub-redes usadas para balanceamento de carga pelo Modo Automático do EKS precisam ter uma das tags a seguir.
### Sub-redes públicas
As sub-redes públicas são usadas para balanceadores de carga voltados para a internet. Essas sub-redes devem ter as tags a seguir:
| Chave | Valor |
| --- | --- |
| `kubernetes.io/role/elb` | `1` ou `` |
### Sub-redes privadas
As sub-redes privadas são usadas para balanceadores de carga internos. Essas sub-redes devem ter as tags a seguir:
| Chave | Valor |
| --- | --- |
| `kubernetes.io/role/internal-elb` | `1` ou `` |
## Procedimento
Antes de começar, identifique quais sub-redes são públicas (com acesso ao gateway da internet) e quais são privadas (usando o gateway NAT). Você precisará de permissões para modificar os recursos da VPC.
### Console de gerenciamento da AWS
1. Abra o console da Amazon VPC e navegue até **Sub-redes**.
1. Selecione a sub-rede a aplicar tags.
1. Escolha a guia **Tags** e selecione **Adicionar tag**.
1. Adicione a tag apropriada:
+ Para sub-redes públicas: Key=`kubernetes.io/role/elb`
+ Para sub-redes privadas: Key=`kubernetes.io/role/internal-elb`
1. Defina **Valor** como `1` ou deixe em branco.
1. Salve e repita para as sub-redes restantes.
### AWS CLI
Para sub-redes públicas:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/elb,Value=1
```
Para sub-redes privadas:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/internal-elb,Value=1
```
Substitua `subnet-ID` pelo ID da sub-rede atual.
# Gerar relatórios de conformidade do CIS de nós do Kubernetes usando o comando kubectl debug
Este tópico descreve como gerar relatórios de conformidade do CIS (Center for Internet Security) para os nós do Amazon EKS usando o comando `kubectl debug`. O comando permite criar temporariamente um contêiner de depuração em um nó do Kubernetes e executar verificações de conformidade do CIS usando a ferramenta `apiclient`. A ferramenta `apiclient` faz parte do sistema operacional do Bottlerocket, o sistema operacional usado pelos nós do Modo Automático do EKS.
## Pré-requisitos
Antes de começar, verifique se você tem:
+ Acesso a um cluster do Amazon EKS com o `kubectl` configurado (a versão deve ser pelo menos v1.32.0; digite `kubectl version` para verificar).
+ As permissões apropriadas do IAM para depurar nós.
+ Um perfil válido que permita operações de depuração (por exemplo, `sysadmin`).
Para obter mais informações sobre como usar perfis de depuração com o `kubectl`, consulte [Depuração de um Pod ou Nó aplicando um perfil](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles) na documentação do Kubernetes.
## Procedimento
1. Determine o ID da instância da AWS do nó em que você deseja executar o relatório. Use o comando a seguir para listar todos os nós no cluster. O ID da instância pode ser encontrado na coluna de nome e começa com `i-`:
```
kubectl get nodes
```
```
NAME STATUS ROLES AGE VERSION
i-0ea0ba0f8ef9ad609 Ready 62s v1.30.10-eks-1a9dacd
```
1. Execute o seguinte comando, substituindo `` pelo ID da instância do nó que você deseja consultar:
```
kubectl debug node/ -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 -- bash -c "yum install -q -y util-linux-core; nsenter -t 1 -m apiclient report cis --level 1 --format text"
```
Os componentes desse comando incluem:
+ `kubectl debug node/`: cria uma sessão de depuração no ID da instância especificada do EC2.
+ `-it`: aloca um TTY (shell de linha de comando) e mantém o stdin aberto para uso interativo.
+ `--profile=sysadmin`: usa o perfil especificado do `kubectl` com as permissões apropriadas.
+ `--image=public.ecr.aws/amazonlinux/amazonlinux:2023`: usa `amazonlinux:2023` como a imagem do contêiner para depuração.
+ `bash -c "…"`: executa os seguintes comandos em um shell bash:
+ `yum install -q -y util-linux-core`: instala silenciosamente o pacote de utilitários necessário.
+ `nsenter -t 1 -m`: executa `nsenter` para inserir o namespace do processo de host (PID 1).
+ `apiclient report cis --level 1 --format text`: executa o relatório de conformidade do CIS no nível 1 com saída de texto.
1. Analise a saída de texto do relatório.
## Interpretar a saída
O comando gera um relatório baseado em texto mostrando o status de conformidade de vários controles do CIS. A saída inclui:
+ IDs individuais de controles do CIS
+ Descrição de cada controle
+ Status de aprovado, reprovado ou ignorado para cada verificação
+ Detalhes que explicam quaisquer problemas de conformidade
Veja abaixo um exemplo da saída do relatório executado em uma instância do Bottlerocket:
```
Benchmark name: CIS Bottlerocket Benchmark
Version: v1.0.0
Reference: https://www.cisecurity.org/benchmark/bottlerocket
Benchmark level: 1
Start time: 2025-04-11T01:40:39.055623436Z
[SKIP] 1.2.1 Ensure software update repositories are configured (Manual)
[PASS] 1.3.1 Ensure dm-verity is configured (Automatic)[PASS] 1.4.1 Ensure setuid programs do not create core dumps (Automatic)
[PASS] 1.4.2 Ensure address space layout randomization (ASLR) is enabled (Automatic)
[PASS] 1.4.3 Ensure unprivileged eBPF is disabled (Automatic)
[PASS] 1.5.1 Ensure SELinux is configured (Automatic)
[SKIP] 1.6 Ensure updates, patches, and additional security software are installed (Manual)
[PASS] 2.1.1.1 Ensure chrony is configured (Automatic)
[PASS] 3.2.5 Ensure broadcast ICMP requests are ignored (Automatic)
[PASS] 3.2.6 Ensure bogus ICMP responses are ignored (Automatic)
[PASS] 3.2.7 Ensure TCP SYN Cookies is enabled (Automatic)
[SKIP] 3.4.1.3 Ensure IPv4 outbound and established connections are configured (Manual)
[SKIP] 3.4.2.3 Ensure IPv6 outbound and established connections are configured (Manual)
[PASS] 4.1.1.1 Ensure journald is configured to write logs to persistent disk (Automatic)
[PASS] 4.1.2 Ensure permissions on journal files are configured (Automatic)
Passed: 11
Failed: 0
Skipped: 4
Total checks: 15
```
Para obter informações sobre a avaliação comparativa, consulte [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) do Center for Internet Security (CIS).
## Recursos relacionados
+ [Bottlerocket CIS Benchmark](https://bottlerocket.dev/en/os/1.34.x/api/reporting/cis/) na documentação do sistema operacional do Bottlerocket.
+ [Depuração de Pods em Execução](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/) na documentação do Kubernetes.
+ [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) do Center for Internet Security (CIS)
# Habilitar a criptografia de volume do EBS com chaves do KMS gerenciadas pelo cliente para o modo automático do EKS
Você pode criptografar o volume raiz efêmero das instâncias do modo automático do EKS com uma chave do KMS gerenciada pelo cliente.
O modo automático do Amazon EKS usa perfis vinculados a serviços para delegar permissões a outros serviços da AWS ao gerenciar volumes criptografados do EBS para seus clusters do Kubernetes. Este tópico descreve como configurar a política de chaves necessária para especificar uma chave gerenciada pelo cliente para criptografia do Amazon EBS com o modo automático do EKS.
Considerações:
+ O modo automático do EKS não precisa de autorização adicional para usar a chave gerenciada pela AWS padrão para proteger os volumes criptografados em sua conta.
+ Este tópico aborda a criptografia de volumes efêmeros, os volumes raiz para instâncias do EC2. Para obter mais informações sobre a criptografia de volumes de dados usados em workloads, consulte [Criar uma classe de armazenamento](create-storage-class.md).
## Visão geral
As seguintes chaves do AWS KMS podem ser usadas para criptografia do volume raiz do Amazon EBS quando o modo automático do EKS executa instâncias:
+ **Chave gerenciada pela AWS**: uma chave de criptografia em sua conta que é criada por, pertencente a e é gerenciada pelo Amazon EBS. Essa é a chave de criptografia padrão para uma nova conta.
+ **Chave gerenciada pelo cliente**: uma chave de criptografia personalizada que você cria, possui e gerencia.
**nota**
A chave deve ser simétrica. O Amazon EBS não oferece suporte a chaves gerenciadas pelo cliente assimétricas.
## Etapa 1: configurar a política de chave
Suas chaves do KMS devem ter uma política de chaves que permita que o modo automático do EKS execute instâncias com volumes do Amazon EBS criptografados com uma chave gerenciada pelo cliente.
Configure sua política de chaves com a seguinte estrutura:
**nota**
Esta política inclui apenas permissões para o modo automático do EKS. A política de chaves poderá precisar de permissões adicionais se outras identidades precisarem usar a chave ou gerenciar concessões.
```
{
"Version":"2012-10-17",
"Id": "MyKeyPolicy",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
Certifique-se de substituir `` pelo ID real da sua conta da AWS.
Ao configurar a política de chaves:
+ O `ClusterServiceRole` deve ter as permissões do IAM necessárias para usar a chave do KMS para operações de criptografia
+ A condição `kms:GrantIsForAWSResource` garante que concessões só possam ser criadas para serviços da AWS
## Etapa 2: configurar o NodeClass com sua chave gerenciada pelo cliente
Depois de configurar a política de chaves, faça referência à chave do KMS na configuração NodeClass do modo automático do EKS:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Insert existing configuration
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# KMS key for encryption
kmsKeyID: "arn:aws:kms:::key/"
```
Substitua os valores dos espaços reservados por seus valores reais:
+ `` com sua região da AWS
+ `` com o ID da sua conta da AWS
+ `` com o ID da sua chave do KMS
Você pode especificar a chave do KMS usando qualquer um dos seguintes itens:
+ ID da chave do KMS: `1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ ARN da chave KMS: ` arn:aws:kms:us-west-2:111122223333:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ Nome do alias da chave: `alias/eks-auto-mode-key`
+ ARN do alias da chave: ` arn:aws:kms:us-west-2:111122223333:alias/eks-auto-mode-key`
Aplique a configuração de NodeClass usando kubectl:
```
kubectl apply -f nodeclass.yaml
```
## Recursos relacionados
+ [Criar uma classe de nó para o Amazon EKS](create-node-class.md)
+ Veja mais informações no Guia do desenvolvedor do AWS Key Management Service.
+ [Permissões para serviços da AWS em políticas de chaves](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-services.html)
+ [Alterar uma política de chave](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)
+ [Concessões no AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)
# Atualizar os controles da organização para o Modo Automático do EKS
Alguns controles organizacionais podem impedir que o Modo Automático do EKS funcione corretamente. Nesse caso, é necessário atualizar esses controles para permitir que o Modo Automático do EKS tenha as permissões necessárias para gerenciar instâncias do EC2 em seu nome.
O Modo Automático do EKS usa um perfil de serviço para inicializar as instâncias do EC2 que dão suporte aos nós do Modo Automático do EKS. Um perfil de serviço é um [perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) criado em sua conta que um serviço assume para realizar ações em seu nome na sua conta. As [políticas de controle de serviço](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCPs) sempre se aplicam às ações realizadas com perfis de serviço. Isso permite que uma SCP iniba as operações do Modo Automático. A ocorrência mais comum é quando uma SCP é usada para restringir as imagens de máquina da Amazon (AMIs) que podem ser executadas. Para permitir que o Modo Automático do EKS funcione, modifique a SCP para permitir a execução de AMIs de contas do Modo Automático do EKS.
Você também pode usar o recurso de [AMIs permitidas pelo EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) para limitar a visibilidade das AMIs em outras contas. Se usar esse recurso, será necessário expandir os critérios de imagens para incluir também as contas das AMIs do Modo Automático do EKS nas regiões de interesse.
## Exemplo de SCP para bloquear todas as AMIs, exceto as AMIs do Modo Automático do EKS
A SCP abaixo impede chamadas a `ec2:RunInstances`, a menos que a AMI pertença à conta da AMI do Modo Automático do EKS para us-west-2 ou us-east-1.
**nota**
É importante **não** usar a chave de contexto `ec2:Owner`. A Amazon possui as contas das AMIs do Modo Automático do EKS, e o valor dessa chave sempre será `amazon`. A criação de uma SCP que permita a execução de AMIs, se o `ec2:Owner` for `amazon`, permitirá a execução de qualquer AMI de propriedade da Amazon, não apenas as do Modo Automático do EKS.\$1
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAMI",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:*:ec2:*::image/ami-*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"767397842682",
"992382739861"
]
}
}
}
]
}
```
## Contas de AMIs do Modo Automático do EKS
Contas da AWS que variam de acordo com a região hospedam as AMIs públicas do Modo Automático do EKS.
| | |
| --- |--- |
| Região da AWS | Conta |
| af-south-1 | 471112993317 |
| ap-east-1 | 590183728416 |
| ap-east-2 | 381492200852 |
| ap-northeast-1 | 851725346105 |
| ap-northeast-2 | 992382805010 |
| ap-northeast-3 | 891377407544 |
| ap-south-1 | 975049899075 |
| ap-south-2 | 590183737426 |
| ap-southeast-1 | 339712723301 |
| ap-southeast-2 | 058264376476 |
| ap-southeast-3 | 471112941769 |
| ap-southeast-4 | 590183863144 |
| ap-southeast-5 | 654654202513 |
| ap-southeast-6 | 905418310314 |
| ap-southeast-7 | 533267217478 |
| ca-central-1 | 992382439851 |
| ca-west-1 | 767397959864 |
| eu-central-1 | 891376953411 |
| eu-central-2 | 381492036002 |
| eu-north-1 | 339712696471 |
| eu-south-1 | 975049955519 |
| eu-south-2 | 471112620929 |
| eu-west-1 | 381492008532 |
| eu-west-2 | 590184142468 |
| eu-west-3 | 891376969258 |
| il-central-1 | 590183797093 |
| me-central-1 | 637423494195 |
| me-south-1 | 905418070398 |
| mx-central-1 | 211125506622 |
| sa-east-1 | 339712709251 |
| us-east-1 | 992382739861 |
| us-east-2 | 975050179949 |
| us-west-1 | 975050035094 |
| us-west-2 | 767397842682 |
| us-gov-east-1 | 446077414359 |
| us-gov-west-1 | 446098668741 |
## Associação de um endereço IP público
Quando `ec2:RunInstances` é chamado, o campo `AssociatePublicIpAddress` para o lançamento de uma instância é determinado automaticamente pelo tipo de sub-rede na qual a instância está sendo lançada. Um SCP pode ser usado para garantir que esse valor seja explicitamente definido como falso, independentemente do tipo de sub-rede na qual está sendo iniciada. Nesse caso, o campo `spec.advancedNetworking.associatePublicIPAddress` do NodeClass também pode ser definido como falso para satisfazer os requisitos do SCP.
```
{
"Sid": "DenyPublicEC2IPAddesses",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:network-interface/*",
"Condition": {
"BoolIfExists": {
"ec2:AssociatePublicIpAddress": "true"
}
}
}
```
# Controle da implantação de workloads em reservas de capacidade com o modo automático do EKS
É possível controlar a implantação de workloads em [reservas de capacidade](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html). O modo automático do EKS oferece suporte a reservas de capacidade sob demanda (ODCRs, na sigla em inglês) do EC2 e a blocos de capacidade do EC2 para ML.
**dica**
Por padrão, o Modo Automático do EKS pode iniciar em ODCRs abertos por meio da correspondência de aberturas, mas não lhes dá prioridade. As instâncias iniciadas por meio do open-matching são rotuladas como `karpenter.sh/capacity-type: on-demand`, e não `reserved`. Para priorizar o uso do ODCR e ter instâncias rotuladas como `karpenter.sh/capacity-type: reserved`, configure `capacityReservationSelectorTerms` na definição NodeClass. Os blocos de capacidade para ML sempre exigem `capacityReservationSelectorTerms` e não são usados automaticamente.
## Reservas de capacidade sob demanda (ODCRs) do EC2
As reservas de capacidade sob demanda (ODCRs) do EC2 permitem que você reserve capacidade computacional para suas instâncias do Amazon EC2 em uma determinada zona de disponibilidade por qualquer duração. Ao usar o Modo Automático do EKS, talvez você queira controlar se suas workloads do Kubernetes serão implantadas nessas instâncias reservadas para maximizar a utilização da capacidade pré-adquirida ou para garantir que workloads críticas tenham acesso aos recursos garantidos.
Por padrão, o Modo Automático do EKS é inicializado automaticamente em ODCRs abertas. No entanto, ao configurar `capacityReservationSelectorTerms` em um NodeClass, você pode controlar explicitamente quais ODCRs suas workloads usam. Os nós provisionados usando ODCRs configuradas terão `karpenter.sh/capacity-type: reserved` e serão priorizados em relação aos sob demanda e spot. Depois que esse recurso for habilitado, o Modo Automático do EKS não usará mais automaticamente ODCRs abertas. Elas deverão ser selecionadas explicitamente por um NodeClass, oferecendo controle preciso sobre o uso da reserva de capacidade em todo o cluster.
**Atenção**
Se você configurar `capacityReservationSelectorTerms` em um NodeClass em um cluster, o Modo Automático do EKS não usará mais automaticamente ODCRs abertas para *nenhum* NodeClass no cluster.
### NodeClass de exemplo
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
# Optional: Selects upon on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
app: "my-app"
# Optional owning account ID filter
owner: "012345678901"
```
Este exemplo de NodeClass demonstra duas abordagens para selecionar ODCRs. O primeiro método faz referência direta a uma ODCR específica pelo seu ID (`cr-56fac701cc1951b03`). O segundo método usa a seleção baseada em tags, visando ODCRs com a tag `Name: "targeted-odcr"`. Você também pode, opcionalmente, filtrar pela conta da AWS proprietária da reserva, o que é particularmente útil em cenários entre contas ou ao trabalhar com reservas de capacidade compartilhada.
## Blocos de capacidade do EC2 para ML
Os blocos de capacidade para ML reservam instâncias de computação acelerada baseadas em GPU em uma data futura para fornecer suporte às workloads de machine learning (ML) de curta duração. As instâncias executadas em um bloco de capacidade são automaticamente colocadas próximas umas das outras nos Amazon EC2 UltraClusters para redes sem bloqueio de baixa latência com escala de petabits.
Para obter mais informações sobre as plataformas e os tipos de instância compatíveis, consulte [Blocos de capacidade para ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) no Guia do usuário do EC2.
Você pode criar uma NodeClass para o modo automático do EKS que usa um bloco de capacidade para ML, semelhante a um ODCR (descrito anteriormente).
As seguintes definições de amostra criam três recursos:
1. Uma NodeClass que faz referência à sua reserva de bloco de capacidade
1. Um NodePool que usa a NodeClass e aplica um taint
1. Uma especificação de pod com tolerância a taint e que solicita recursos de GPU
### NodeClass de exemplo
Esta NodeClass faz referência a um bloco de capacidade específico para ML por meio do ID de reserva. Você pode obter esse ID no console do EC2.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
```
Para obter mais informações, consulte [Criar uma classe de nó para o Amazon EKS](create-node-class.md).
### Exemplo de NodePool
Este NodePool se refere a NodeClass da `gpu` e especifica configurações importantes:
+ Utiliza **apenas** a capacidade reservada, definindo `karpenter.sh/capacity-type: reserved`
+ Solicita famílias de instâncias de GPU específicas, apropriadas para workloads de ML
+ Aplica um taint `nvidia.com/gpu` para garantir que apenas workloads de GPU sejam agendadas nesses nós
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: gpu
requirements:
- key: eks.amazonaws.com/instance-family
operator: In
values:
- g6
- p4d
- p4de
- p5
- p5e
- p5en
- p6
- p6-b200
- key: karpenter.sh/capacity-type
operator: In
values:
- reserved
# Enable other capacity types
# - on-demand
# - spot
taints:
- effect: NoSchedule
key: nvidia.com/gpu
```
Para obter mais informações, consulte [Criar um grupo de nós para o Modo Automático do EKS](create-node-pool.md).
### Exemplo de pod
Este exemplo de pod demonstra como configurar uma workload para ser executada nos nós do bloco de capacidade:
+ Usa um **nodeSelector** para direcionar tipos específicos de GPU (neste caso, GPUs H200)
+ Inclui uma **tolerância** para o taint `nvidia.com/gpu` aplicado pelo NodePool
+ **Solicita explicitamente recursos de GPU** usando o tipo de recurso `nvidia.com/gpu`
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
# Select specific GPU type - uncomment as needed
# eks.amazonaws.com/instance-gpu-name: l4
# eks.amazonaws.com/instance-gpu-name: a100
eks.amazonaws.com/instance-gpu-name: h200
# eks.amazonaws.com/instance-gpu-name: b200
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
# Uncomment if needed
# memory: "30Gi"
# cpu: "3500m"
nvidia.com/gpu: 1
limits:
# Uncomment if needed
# memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Para obter mais informações, consulte [Pods](https://kubernetes.io/docs/concepts/workloads/pods/) na documentação do Kubernetes.
### Recursos relacionados
+ [Blocos de capacidade para ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) no Guia do usuário do Amazon EC2
+ [Encontrar e comprar blocos de capacidade](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html) no Guia do usuário do Amazon EC2
+ [Gerencie recursos computacionais para workloads de IA/ML no Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ [Otimização de recursos de GPU e gerenciamento de custos](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management) no Guia de práticas recomendadas do EKS
# Implantação de nós do modo automático do EKS em zonas locais
O modo automático do EKS fornece gerenciamento simplificado de clusters com provisionamento automático de nós. As zonas locais da AWS ampliam a infraestrutura da AWS para locais geográficos mais próximos dos seus usuários finais, reduzindo a latência para aplicações sensíveis a esse atraso. Este guia orienta você no processo de implantação de nós do modo automático do EKS em zonas locais da AWS, permitindo a execução de aplicações conteinerizadas com menor latência para usuários em áreas geográficas específicas.
Este guia também demonstra como usar taints e tolerâncias do Kubernetes para garantir que apenas workloads específicas sejam executadas em nós das zonas locais, ajudando você a controlar custos e otimizar o uso de recursos.
## Pré-requisitos
Antes de começar a implantar nós do modo automático do EKS em zonas locais, certifique-se de que os seguintes pré-requisitos estejam configurados:
+ [Um cluster existente no modo automático do EKS](create-auto.md)
+ [Zonas locais ativadas em sua conta da AWS](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone)
## Etapa 1: criação de uma sub-rede na zona local
A primeira etapa para a implantação de nós do modo automático do EKS em uma zona local é criar uma sub-rede nessa zona local. Essa sub-rede fornece a infraestrutura de rede aos seus nós e permite que eles se comuniquem com o restante da VPC. Siga as instruções presentes em [Criação de uma sub-rede em uma zona local](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet) (no Guia do usuário das zonas locais da AWS) para criar uma sub-rede na zona local escolhida.
**dica**
Anote o nome da sua sub-rede da zona local.
## Etapa 2: criação de uma NodeClass para a sub-rede na zona local
Após criar a sub-rede da zona local, é necessário definir uma NodeClass que faça referência a essa sub-rede. A NodeClass é um recurso personalizado do Kubernetes que especifica os atributos de infraestrutura para os seus nós, incluindo quais sub-redes, grupos de segurança e configurações de armazenamento devem ser usados. No exemplo abaixo, criamos uma NodeClass chamada “local-zone” que direciona para uma sub-rede da zona local com base em seu nome. Você também pode usar o ID da sub-rede. Será necessário adaptar essa configuração para direcionar para a sua sub-rede da zona local.
Para obter mais informações, consulte [Criar uma classe de nó para o Amazon EKS](create-node-class.md).
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: local-zone
spec:
subnetSelectorTerms:
- id:
```
## Etapa 3: criação do NodePool com NodeClass e Taint
Com sua NodeClass configurada, agora você precisa criar um NodePool que utilize essa NodeClass. Um NodePool define as características de computação dos seus nós, incluindo os tipos de instância. O NodePool emprega a NodeClass como referência para determinar em qual local as instâncias devem ser iniciadas.
No exemplo abaixo, criamos um NodePool que faz referência à NodeClass “local-zone”. Também adicionamos um taint aos nós para garantir que apenas pods com uma tolerância correspondente possam ser agendados nesses nós das zonas locais. Isso é particularmente importante para nós das zonas locais, que normalmente têm custos mais elevados e devem ser usados apenas por workloads que se beneficiam especificamente da latência reduzida.
Para obter mais informações, consulte [Criar um grupo de nós para o Modo Automático do EKS](create-node-pool.md).
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
node-type: local-zone
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: local-zone
taints:
- key: "aws.amazon.com/local-zone"
value: "true"
effect: NoSchedule
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
```
O taint com a chave `aws.amazon.com/local-zone` e o efeito `NoSchedule` garante que pods sem uma tolerância correspondente não sejam agendados nesses nós. Isso evita que workloads comuns sejam executadas acidentalmente na zona local, o que poderia gerar custos inesperados.
## Etapa 4: implantação de workloads com tolerância e afinidade de nó
Para um controle ideal sobre a alocação de workloads em nós das zonas locais, use taints e tolerâncias e a afinidade de nó simultaneamente. Essa abordagem combinada oferece os seguintes benefícios:
1. **Controle de custos**: o taint garante que apenas pods com tolerâncias explícitas possam usar recursos das zonas locais, que podem ser mais caros.
1. **Posicionamento garantido**: a afinidade de nó garante que suas aplicações sensíveis à latência sejam executadas exclusivamente na zona local, e não em nós comuns do cluster.
A seguir, apresentamos um exemplo de uma Deployment configurada para ser executada especificamente em nós das zonas locais:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: low-latency-app
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: low-latency-app
template:
metadata:
labels:
app: low-latency-app
spec:
tolerations:
- key: "aws.amazon.com/local-zone"
operator: "Equal"
value: "true"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "node-type"
operator: "In"
values: ["local-zone"]
containers:
- name: application
image: my-low-latency-app:latest
resources:
limits:
cpu: "1"
memory: "1Gi"
requests:
cpu: "500m"
memory: "512Mi"
```
Esta Deployment conta com duas configurações de agendamento fundamentais:
1. A **tolerância** permite que os pods sejam agendados em nós que contam com o taint `aws.amazon.com/local-zone`.
1. O requisito de **afinidade de nó** garante que esses pods sejam executados apenas em nós com o rótulo `node-type: local-zone`.
Juntas, essas configurações garantem que sua aplicação sensível à latência seja executada apenas em nós das zonas locais, e que as aplicações comuns não consumam os recursos dessas zonas locais, a menos que sejam explicitamente configuradas para isso.
## Etapa 5: verificação com o Console da AWS
Após configurar a NodeClass, o NodePool e as Deployments, você deve verificar se os nós estão sendo provisionados na zona local conforme o esperado e se as workloads estão sendo executadas neles. É possível usar o Console de Gerenciamento da AWS para verificar se as instâncias do EC2 estão sendo iniciadas na sub-rede mais adequada da zona local.
Além disso, você pode verificar a lista de nós do Kubernetes usando o comando `kubectl get nodes -o wide` para confirmar se os nós estão sendo integrados ao cluster com os rótulos e os taints configurados corretamente:
```
kubectl get nodes -o wide
kubectl describe node | grep -A 5 Taints
```
Você também pode verificar se os pods das workloads estão agendados nos nós das zonas locais:
```
kubectl get pods -o wide
```
Essa abordagem garante que apenas workloads com tolerância específica para o taint da zona local sejam agendadas nesses nós, ajudando você a controlar custos e a fazer o uso mais eficiente dos seus recursos de zonas locais.
# Definição de configurações avançadas de segurança para nós
Este tópico descreve como definir configurações avançadas de segurança para os nós do modo automático do Amazon EKS usando a especificação `advancedSecurity` em sua classe de nós.
## Pré-requisitos
Antes de começar, verifique se você tem:
+ Um cluster do Modo Automático do Amazon EKS. Para obter mais informações, consulte [Criação de um cluster com o modo automático do Amazon EKS](create-auto.md).
+ `kubectl` instalado e configurado. Para obter mais informações, consulte [Configurar para usar o Amazon EKS](setting-up.md).
+ Compreensão da configuração da classe de nós. Para obter mais informações, consulte [Criar uma classe de nó para o Amazon EKS](create-node-class.md).
## Definição de configurações avançadas de segurança
Para definir configurações avançadas de segurança para seus nós, defina os campos `advancedSecurity` em sua especificação de classe de nó:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: security-hardened
spec:
role: MyNodeRole
subnetSelectorTerms:
- tags:
Name: "private-subnet"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
advancedSecurity:
# Enable FIPS-compliant AMIs (US regions only)
fips: true
# Configure kernel lockdown mode
kernelLockdown: "integrity"
```
Aplique essa configuração:
```
kubectl apply -f nodeclass.yaml
```
Faça referência a essa classe de nó na configuração do grupo de nós. Para obter mais informações, consulte [Criar um grupo de nós para o Modo Automático do EKS](create-node-pool.md).
## Descrições do campo
+ `fips` (booleano, opcional): quando definido como `true`, provisiona nós usando AMIs com módulos criptográficos validados pelo FIPS 140-2. Essa configuração seleciona AMIs compatíveis com FIPS; os clientes são responsáveis por gerenciar seus requisitos de conformidade. Para obter mais informações, consulte [Conformidade com o AWS FIPS](https://aws.amazon.com/compliance/fips/). Padrão: `false`.
+ `kernelLockdown` (string, opcional): controla o modo do módulo de segurança de bloqueio do kernel. Valores aceitos:
+ `integrity`: bloqueia métodos para sobrescrever a memória do kernel ou modificar o código do kernel. Impede que módulos de kernel não assinados sejam carregados.
+ `none`: desabilita a proteção de bloqueio do kernel.
Para obter mais informações, consulte a [documentação de bloqueio do kernel Linux](https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html).
## Considerações
+ As AMIs compatíveis com FIPS estão disponíveis nas regiões AWS Leste/Oeste dos EUA, AWS GovCloud (EUA) e AWS Canadá (Central/Oeste). Para obter mais informações, consulte [Conformidade com o AWS FIPS](https://aws.amazon.com/compliance/fips/).
+ Ao usar `kernelLockdown: "integrity"`, certifique-se de que suas workloads não exijam o carregamento de módulos de kernel não assinados ou a modificação da memória do kernel.
## Recursos relacionados
+ [Criar uma classe de nó para o Amazon EKS](create-node-class.md): guia completo de configuração da classe de nó
+ [Criar um grupo de nós para o Modo Automático do EKS](create-node-pool.md): configuração do grupo de nós
# Saiba como o Modo Automático do EKS funciona
Use este capítulo para saber mais sobre como os componentes dos clusters do Modo Automático do Amazon EKS funcionam.
**Topics**
+ [Saiba mais sobre as instâncias gerenciadas do modo automático do Amazon EKS](automode-learn-instances.md)
+ [Saber mais sobre identidade e acesso no Modo Automático do EKS](auto-learn-iam.md)
+ [Saiba mais sobre as redes de VPC e sobre o balanceamento de carga no modo automático do EKS](auto-networking.md)
# Saiba mais sobre as instâncias gerenciadas do modo automático do Amazon EKS
Este tópico explica como o Modo automático do Amazon EKS gerencia as instâncias do Amazon EC2 no cluster de EKS. Quando você habilita o Modo automático do EKS, os recursos computacionais do cluster são automaticamente provisionados e gerenciados pelo EKS, mudando a forma como você interage com as instâncias do EC2 que servem como nós no cluster.
Entender como o Modo automático do Amazon EKS gerencia as instâncias é essencial para planejar a estratégia de implantação de workloads e procedimentos operacionais. Diferentemente das instâncias do EC2 tradicionais ou dos grupos de nós gerenciados, essas instâncias seguem um modelo de ciclo de vida diferente, em que o EKS assume a responsabilidade por muitos aspectos operacionais, ao mesmo tempo em que restringe certos tipos de acesso e personalização.
O Modo automático do Amazon EKS automatiza tarefas de rotina para criar novas instâncias do EC2 e as anexa como nós ao cluster de EKS. O Modo automático do EKS detecta quando uma workload não cabe nos nós existentes e cria uma instância do EC2.
O Modo automático do Amazon EKS é responsável por criar, excluir e aplicar patches em instâncias do EC2. Você é responsável pelos contêineres e pods implantados na instância.
As instâncias do EC2 criadas pelo Modo automático do EKS são diferentes das outras instâncias do EC2. Elas são instâncias gerenciadas. Essas instâncias gerenciadas são de propriedade do EKS e são mais restritas. Você não pode acessar diretamente ou instalar software em instâncias gerenciadas pelo Modo automático do EKS.
A AWS sugere executar o Modo automático do EKS ou o Karpenter autogerenciado. É possível instalar ambos durante uma migração ou em uma configuração avançada. Se você tiver ambos instalados, configure os grupos de nós para que as workloads sejam associadas ao Karpenter ou ao Modo automático do EKS.
Para obter mais informações, consulte [Amazon EC2 managed instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html) no Guia do usuário do Amazon EC2.
## Tabela de comparação
| Instância padrão do EC2 | Instância gerenciada do Modo automático do EKS |
| --- | --- |
| Você é responsável por aplicar patches e atualizar a instância. | A AWS aplica patches e atualiza automaticamente a instância. |
| O EKS não é responsável pelo software na instância. | O EKS é responsável por determinados softwares na instância, como `kubelet`, o runtime do contêiner e o sistema operacional. |
| É possível excluir a instância do EC2 usando a API do EC2. | O EKS determina o número de instâncias implantadas na conta. Se você excluir uma workload, o EKS reduzirá o número de instâncias na conta. |
| É possível usar o SSH para acessar a instância do EC2. | É possível implantar pods e contêineres na instância gerenciada. |
| Você determina o sistema operacional e a imagem (AMI). | A AWS determina o sistema operacional e a imagem. |
| É possível implantar workloads que dependam da funcionalidade do Windows ou do Ubuntu. | É possível implantar contêineres baseados em Linux, mas sem dependências específicas do sistema operacional. |
| Você determina qual família e tipo de instância executar. | A AWS determina qual família e tipo de instância executar. É possível usar um grupo de nós para limitar os tipos de instância selecionados pelo Modo automático do EKS. |
A seguinte funcionalidade funciona tanto para instâncias gerenciadas quanto para instâncias padrão do EC2:
+ É possível visualizar a instância no console da AWS.
+ É possível usar o armazenamento de instâncias como armazenamento efêmero para workloads.
### Compatibilidade com a AMI
Com o Modo automático do EKS, a AWS determina a imagem (AMI) usada para seus nós de computação. A AWS monitora o lançamento das novas versões de AMIs do Modo automático do EKS. Se você tiver problemas com as workloads relacionados a uma versão de AMI, crie um caso de suporte. Para obter mais informações, consulte [Creating support cases and case management](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) no Guia do usuário do AWS Support.
Geralmente, o EKS lança uma nova AMI toda semana contendo um CVE e correções de segurança.
## Referência de instâncias compatíveis com o Modo automático do EKS
O Modo automático do EKS cria apenas instâncias de tipos compatíveis e que atendem a um requisito de tamanho mínimo.
O modo automático do EKS é compatível com os seguintes tipos de instância:
| Família | Tipos de instância |
| --- | --- |
| Otimizada para computação (C) | c8i, c8i-flex, c8gd, c8gn, c8g, c7a, c7g, c7gn, c7gd, c7i, c7i-flex, c6a, c6g, c6i, c6gn, c6id, c6in, c6gd, c5, c5a, c5d, c5ad, c5n, c4 |
| Uso geral (M) | m8i, m8i-flex, m8a, m8gn, m8gb, m8gd, m8g, m7i, m7a, m7g, m7gd, m7i-flex, m6a, m6i, m6in, m6g, m6idn, m6id, m6gd, m5, m5a, m5ad, m5n, m5dn, m5d, m5zn, m4 |
| Otimizada para memória (R) | r8i, r8i-flex, r8gn, r8gb, r8gd, r8g, r7a, r7iz, r7gd, r7i, r7g, r6a, r6i, r6id, r6in, r6idn, r6g, r6gd, r5, r5n, r5a, r5dn, r5b, r5ad, r5d, r4 |
| Com capacidade de intermitência (T) | t4g, t3, t3a, t2 |
| Alta memória (Z/X) | z1d, x8g, x2gd |
| Otimizada para armazenamento (I/D) | i8ge, i7i, i8g, i7ie, i4g, i4i, i3, i3en, is4gen, d3, d3en, im4gn |
| Computação acelerada (P/G/Inf/Trn) | p5, p4d, p4de, p3, p3dn, gr6, g6, g6e, g5g, g5, g4dn, inf2, inf1, trn1, trn1n |
| Computação de alta performance (X2) | x2iezn, x2iedn, x2idn |
Além disso, o Modo automático do EKS só criará instâncias do EC2 que atendam aos seguintes requisitos:
+ Mais de uma CPU
+ O tamanho da instância não é nano, micro ou pequeno
Para obter mais informações, consulte [Convenções de nomenclatura de tipos de instância do Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html).
## Serviço de metadados da instância
+ O Modo automático do EKS impõe o IMDSv2 com um limite de salto de um por padrão, aderindo às práticas recomendadas de segurança da AWS.
+ Essa configuração padrão não pode ser modificada no Modo automático.
+ Para complementos que normalmente exigem acesso ao IMDS, forneça parâmetros (como região da AWS) durante a instalação para evitar consultas ao IMDS. Para obter mais informações, consulte [Determinar os campos que podem ser personalizados para os complementos do Amazon EKS](kubernetes-field-management.md).
+ Se for absolutamente necessário que um pod tenha acesso ao IMDS ao ser executado no Modo automático, ele deverá ser configurado para ser executado com `hostNetwork: true`. Isso permite que o pod acesse diretamente o serviço de metadados da instância.
+ Considere as implicações de segurança ao conceder aos pods acesso aos metadados da instância.
Para obter mais informações sobre o serviço de metadados de instância (IMDS) do Amazon EC2, consulte [Configurar as opções de serviço de metadados de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html) no *Guia do usuário do Amazon EC2*.
## Considerações
+ Se o armazenamento efêmero configurado no NodeClass for menor do que o armazenamento local NVMe da instância, o Modo automático do EKS eliminará a necessidade de configuração manual executando automaticamente as seguintes ações:
+ Usa um volume de dados menor (20 GiB) do Amazon EBS para reduzir custos.
+ Formata e configura o armazenamento local NVMe para uso efêmero de dados. Isso inclui a configuração de uma matriz RAID 0 se houver várias unidades NVMe.
+ Quando `ephemeralStorage.size` for igual ou exceder a capacidade local do NVMe, as seguintes ações ocorrerão:
+ O modo automático ignora o pequeno volume de EBS.
+ Drives NVMe são diretamente expostos à sua workload.
+ O modo automático do Amazon EKS não é compatível com as seguintes ações do Serviço de Injeção de Falhas da AWS:
+ `ec2:RebootInstances`
+ `ec2:SendSpotInstanceInterruptions`
+ `ec2:StartInstances`
+ `ec2:StopInstances`
+ `ec2:TerminateInstances`
+ `ec2:PauseVolumeIO`
+ O modo automático do Amazon EKS é compatível com as ações de pod do EKS do Serviço de Injeção de Falhas da AWS. Para obter mais informações, consulte [Gerenciamento de experimentos do Serviço de Injeção de Falhas](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html) e [Uso das ações aws:eks:pod do AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html#configure-service-account) no Guia do usuário do Hub de Resiliência da AWS.
+ Você não precisa instalar o `Neuron Device Plugin` nos nós do Modo automático do EKS.
Caso tenha outros tipos de nós no cluster, você precisará configurar o plug-in Neuron Device para não ser executado em nós do Modo automático. Para obter mais informações, consulte [Controlar se uma workload é implantada nos nós do Modo Automático do EKS](associate-workload.md).
# Saber mais sobre identidade e acesso no Modo Automático do EKS
Este tópico descreve os perfis e as permissões do Identity and Access Management (IAM) necessários para usar o Modo Automático do EKS. O Modo Automático do EKS usa dois perfis principais do IAM: um perfil do IAM do cluster e um perfil do IAM do nó. Esses perfis trabalham em conjunto com a Identidade de Pods do EKS e as entradas de acesso do EKS para fornecer gerenciamento de acesso abrangente para os clusters do EKS.
Ao configurar o Modo Automático do EKS, você precisará configurar esses perfis do IAM com permissões específicas que permitam que os serviços da AWS interajam com os recursos do cluster. Isso inclui permissões para gerenciar recursos computacionais, volumes de armazenamento, balanceadores de carga e componentes de rede. Compreender essas configurações de perfil é essencial para a operação e a segurança adequadas do cluster.
No Modo Automático do EKS, os perfis do AWS IAM são mapeados automaticamente para as permissões do Kubernetes por meio de entradas de acesso do EKS, eliminando a necessidade de configuração manual de ConfigMaps `aws-auth` ou vinculações personalizadas. Quando você cria um novo cluster no modo automático, o EKS cria automaticamente as permissões correspondentes do Kubernetes usando entradas de acesso, garantindo que os componentes do cluster e serviços da AWS tenham os níveis de acesso apropriados nos sistemas de autorização da AWS e do Kubernetes. Essa integração automatizada reduz a complexidade da configuração e ajuda a evitar problemas relacionados a permissões que geralmente ocorrem ao gerenciar clusters do EKS.
## Função do IAM do cluster
O perfil do IAM do cluster é um perfil do AWS Identity and Access Management (IAM) usado pelo Amazon EKS para gerenciar permissões para clusters do Kubernetes. Esse perfil concede ao Amazon EKS as permissões necessárias para interagir com outros serviços da AWS em nome do cluster, e é configurado automaticamente com as permissões do Kubernetes usando entradas de acesso do EKS.
+ Você também deve anexar políticas do AWS IAM ao perfil.
+ O Modo Automático do EKS anexa permissões do Kubernetes a esse perfil automaticamente usando entradas de acesso do EKS.
+ Com o Modo Automático do EKS, a AWS sugere a criação de um único perfil do IAM do cluster por conta da AWS.
+ A AWS sugere nomear esse perfil `AmazonEKSAutoClusterRole`.
+ Esse perfil exige permissões para vários serviços da AWS gerenciarem recursos, incluindo volumes do EBS, Elastic Load Balancers e instâncias do EC2.
+ A configuração sugerida para esse perfil inclui várias políticas do IAM gerenciadas pela AWS, relacionadas aos diferentes recursos do Modo Automático do EKS.
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
Para obter mais informações sobre o perfil do IAM do cluster e políticas do IAM gerenciadas pela AWS, consulte:
+ [Políticas gerenciadas pela AWS para o Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md)
+ [Função do IAM do cluster do Amazon EKS](cluster-iam-role.md)
Para obter mais informações sobre o acesso do Kubernetes, consulte:
+ [Analisar permissões da política de acesso](access-policy-permissions.md)
## Perfil do IAM do nó
O perfil do IAM do nó é um perfil do AWS Identity and Access Management (IAM) usado pelo Amazon EKS para gerenciar permissões para nós de processamento em clusters do Kubernetes. Esse perfil concede às instâncias do EC2 executadas como nós do Kubernetes as permissões necessárias para interagir com os serviços e recursos da AWS, e é configurado automaticamente com permissões de RBAC do Kubernetes usando entradas de acesso do EKS.
+ Você também deve anexar políticas do AWS IAM ao perfil.
+ O Modo Automático do EKS anexa permissões de RBAC do Kubernetes a esse perfil automaticamente usando entradas de acesso do EKS.
+ A AWS sugere nomear esse perfil `AmazonEKSAutoNodeRole`.
+ Com o Modo Automático do EKS, a AWS sugere a criação de um único perfil do IAM do nó por conta da AWS.
+ Esse perfil tem permissões limitadas. As principais permissões incluem assumir um perfil de Identidade de Pods e extrair imagens do ECR.
+ A AWS sugere as seguintes políticas do IAM gerenciadas pela AWS:
+ `AmazonEKSWorkerNodeMinimalPolicy`
+ `AmazonEC2ContainerRegistryPullOnly`
Para obter mais informações sobre o perfil do IAM do cluster e políticas do IAM gerenciadas pela AWS, consulte:
+ [Políticas gerenciadas pela AWS para o Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md)
+ [Perfil do IAM em nós do Amazon EKS](create-node-role.md)
Para obter mais informações sobre o acesso do Kubernetes, consulte:
+ [Analisar permissões da política de acesso](access-policy-permissions.md)
## Perfil vinculado a serviço
O Amazon EKS usa um perfil vinculado ao serviço (SLR) para determinadas operações. A função vinculada ao serviço é um tipo exclusivo de função do IAM vinculada diretamente ao Amazon EKS. As funções vinculadas a serviços são predefinidas pelo Amazon EKS e incluem todas as permissões que o serviço requer para chamar outros serviços da AWS em seu nome.
A AWS cria e configura automaticamente o SLR. Você poderá excluir um SLR somente depois de primeiro excluir seus recursos relacionados. Isso protege seus recursos do Amazon EKS, pois você não pode remover por engano as permissões para acessar os recursos.
A política de SLR concede ao Amazon EKS permissões para observar e excluir os principais componentes da infraestrutura: recursos do EC2 (instâncias, interfaces de rede, grupos de segurança), recursos do ELB (balanceadores de carga, grupos de destino), recursos do CloudWatch (registro em log e métricas) e perfis do IAM com o prefixo "eks". Também habilita a rede de endpoints privados por meio da associação da VPC e zona hospedada e inclui permissões para o monitoramento do EventBridge e limpeza dos recursos marcados com o EKS.
Para obter mais informações, consulte:
+ [Política gerenciada pela AWS: AmazonEKSServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy)
+ [Permissões de função vinculada ao serviço para o Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks)
## Tags da AWS personalizadas para recursos do Modo Automático do EKS.
Por padrão, as políticas gerenciadas relacionadas ao Modo Automático do EKS não permitem a aplicação de tags definidas pelo usuário aos recursos da AWS provisionados pelo Modo Automático. Caso queira aplicar tags definidas pelo usuário aos recursos da AWS, você deverá anexar permissões adicionais ao perfil do IAM do cluster com permissões suficientes para criar e modificar tags nos recursos da AWS. Segue abaixo um exemplo de uma política que permitirá acesso irrestrito à marcação:
### Visualizar exemplo de política de tags personalizadas
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Compute",
"Effect": "Allow",
"Action": [
"ec2:CreateFleet",
"ec2:RunInstances",
"ec2:CreateLaunchTemplate"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-node-class-name": "*",
"aws:RequestTag/eks:kubernetes-node-pool-name": "*"
}
}
},
{
"Sid": "Storage",
"Effect": "Allow",
"Action": [
"ec2:CreateVolume",
"ec2:CreateSnapshot"
],
"Resource": [
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:snapshot/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "Networking",
"Effect": "Allow",
"Action": "ec2:CreateNetworkInterface",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-cni-node-name": "*"
}
}
},
{
"Sid": "LoadBalancer",
"Effect": "Allow",
"Action": [
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateRule",
"ec2:CreateSecurityGroup"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldProtection",
"Effect": "Allow",
"Action": [
"shield:CreateProtection"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldTagResource",
"Effect": "Allow",
"Action": [
"shield:TagResource"
],
"Resource": "arn:aws:shield::*:protection/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
}
]
}
```
## Referência de política de acesso
Para obter mais informações sobre as permissões do Kubernetes usadas pelo Modo Automático do EKS, consulte [Analisar permissões da política de acesso](access-policy-permissions.md).
# Saiba mais sobre as redes de VPC e sobre o balanceamento de carga no modo automático do EKS
Este tópico explica como configurar os recursos de balanceamento de carga e rede da Virtual Private Cloud (VPC) no Modo Automático do EKS. Embora o Modo Automático do EKS gerencie a maioria dos componentes de rede automaticamente, você ainda pode personalizar certos aspectos da configuração de rede do cluster por meio dos recursos do `NodeClass` e das anotações do balanceador de carga.
Quando você usa o Modo Automático do EKS, a AWS gerencia a configuração da interface de rede de contêineres (CNI) da VPC e o provisionamento de balanceador de carga para o cluster. Você pode influenciar os comportamentos de rede definindo objetos `NodeClass` e aplicando anotações específicas aos seus recursos de Service e Ingress, mantendo o modelo operacional automatizado fornecido pelo Modo Automático do EKS.
## Funcionalidade de redes
O modo automático do EKS oferece uma nova funcionalidade de redes para gerenciar a rede de nós e de pods. É possível configurá-la criando um objeto `NodeClass` no Kubernetes.
As opções de configuração para o plug-in CNI da AWS VPC anterior não se aplicarão ao modo automático do EKS.
### Configurar a rede com um `NodeClass`
O recurso `NodeClass` no Modo Automático do EKS possibilita a personalização de determinados aspectos dos recursos de redes. Por meio do `NodeClass`, você pode especificar seleções de grupos de segurança, controlar o posicionamento dos nós em sub-redes da VPC, definir políticas de SNAT, configurar políticas de rede e habilitar o registro em log de eventos de rede. Essa abordagem mantém o modelo operacional automatizado do Modo Automático do EKS e, ao mesmo tempo, fornece flexibilidade para a personalização da rede.
Você pode usar um `NodeClass` para:
+ Selecionar um grupo de segurança para nós
+ Controlar como os nós são posicionados nas sub-redes da VPC
+ Definir a política de SNAT do nó como `random` ou `disabled`
+ Habilitar as *políticas de rede* do Kubernetes, incluindo:
+ Definir a política de rede como Negar por padrão ou Permitir por padrão
+ Habilite o registro em log de eventos de rede em um arquivo.
+ Isole o tráfego de pods do tráfego de nós anexando os pods a sub-redes diferentes.
Saiba como [Criar um NodeClass do Amazon EKS](create-node-class.md).
### Considerações
Modo Automático do EKS é compatível com:
+ Políticas de rede do EKS.
+ As opções `HostPort` e `HostNetwork` para pods do Kubernetes.
+ Pods e nós em sub-redes públicas ou privadas.
+ Armazenamento em cache de consultas ao DNS no nó.
O Modo Automático do EKS **não** é compatível com:
+ Grupos de segurança por pod (SGPP). Para aplicar grupos de segurança distintos ao tráfego do Pod no Modo Automático, use `podSecurityGroupSelectorTerms` no `NodeClass` em vez disso. Para obter mais informações, consulte [Sub-redes e grupos de segurança separados para Pods](create-node-class.md#pod-subnet-selector).
+ Rede personalizada no `ENIConfig`. Você pode colocar pods em várias sub-redes ou isolá-los exclusivamente do tráfego de nós com [Sub-redes e grupos de segurança separados para Pods](create-node-class.md#pod-subnet-selector).
+ Configurações de IP warm, prefixo warm e ENI warm.
+ Configuração de destinos de IP mínimos.
+ Outras configurações compatíveis com a CNI de código aberto da AWS VPC.
+ Configurações de política de rede, como personalização do temporizador conntrack (o padrão é 300 s).
+ Exportação de logs de eventos de rede para o CloudWatch.
### Gerenciamento de recursos de rede
O Modo Automático do EKS lida com o gerenciamento de prefixo, endereçamento IP e interface de rede monitorando os recursos do NodeClass para as configurações de rede. O serviço executa várias operações importantes automaticamente:
**Delegação de prefixo**
O modo automático do EKS utiliza por padrão a delegação de prefixos (prefixos /28) para a rede dos pods e mantém um grupo de recursos IP definido previamente que é escalado com base no número de pods agendados. Quando é detectada fragmentação da sub-rede do pod, o modo automático provisiona endereços IP secundários (prefixos /32). Devido a esse algoritmo de rede de pods padrão, o modo automático calcula o número máximo de pods por nó com base na quantidade de ENIs e de IPs com suporte por tipo de instância (considerando o pior cenário de fragmentação). Para obter mais informações sobre o número máximo de ENIs e de IPs com suporte por tipo de instância, consulte [Máximo de endereços IP por interface de rede](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html) no Guia do usuário do EC2. As famílias de instâncias da geração mais recente (Nitro v6 e versões posteriores) geralmente têm um número maior de ENIs e de IPs com suporte por tipo de instância, e o modo automático ajusta o cálculo do número máximo de pods de acordo.
Para clusters IPv6, apenas a delegação de prefixo é utilizada, e o modo automático sempre usa um limite máximo de 110 pods por nó.
**Gerenciamento do período de espera**
O serviço implementa um grupo de espera para prefixos ou endereços IPv4 secundários que não estão mais em uso. Depois que o período de espera expirar, esses recursos serão liberados de volta para a VPC. No entanto, se os pods reutilizarem esses recursos durante o período de espera, eles serão restaurados do grupo de espera.
**Compatibilidade com IPv6**
Para clusters IPv6, o Modo Automático do EKS provisiona um prefixo IPv6 `/80` por nó na interface de rede primária. Ao usar `podSubnetSelectorTerms`, o prefixo é alocado em uma interface de rede secundária na sub-rede do pod.
O serviço também garante o gerenciamento adequado e a coleta de resíduos de todas as interfaces de rede.
## Balanceamento de carga
Você configura os AWS Elastic Load Balancers provisionados pelo Modo Automático do EKS usando anotações nos recursos de Service e Ingress.
Para ter mais informações, consulte [Criar uma IngressClass para configurar um Application Load Balancer](auto-configure-alb.md) ou [Usar anotações de serviço para configurar Network Load Balancers](auto-configure-nlb.md).
### Considerações sobre o balanceamento de carga com o Modo Automático do EKS
+ O modo de direcionamento padrão é o modo de IP, não o modo de instância.
+ O Modo Automático do EKS é compatível apenas com o modo de grupo de segurança para Network Load Balancers.
+ A AWS não é compatível com a migração de balanceadores de carga do controlador de balanceador de carga autogerenciado da AWS para o gerenciamento pelo Modo Automático do EKS.
+ O campo `networking.ingress.ipBlock` na especificação `TargetGroupBinding` não é compatível.
+ Se os nós de processamento usarem grupos de segurança personalizados (não o padrão de nomenclatura `eks-cluster-sg- `), o perfil do cluster precisará de permissões adicionais do IAM. A política padrão gerenciada pelo EKS só permite que o EKS modifique grupos de segurança denominados `eks-cluster-sg-`. Sem permissão para modificar os grupos de segurança personalizados, o EKS não pode adicionar as regras de entrada necessárias que permitem que o tráfego de ALB e NLB chegue aos pods.
#### Considerações sobre o CoreDNS
O modo automático do EKS não usa a implantação tradicional do CoreDNS para fornecer resolução de DNS dentro do cluster. Em vez disso, os nós do modo automático empregam o CoreDNS, que é executado como um serviço do sistema diretamente em cada nó. Ao migrar um cluster tradicional para o modo automático, você pode remover a implantação do CoreDNS do cluster assim que as workloads forem movidas para os nós do modo automático.
**Importante**
Se você planeja manter um cluster com nós no modo automático e nós que não estejam no modo automático, deve manter a implantação do CoreDNS. Os nós que não operam no modo automático dependem dos pods do CoreDNS tradicionais para a resolução de DNS, pois não têm acesso ao serviço de DNS em nível de nó fornecido pelo modo automático.
# Observabilidade para o Modo Automático do EKS
Use este capítulo para saber mais sobre as opções de observabilidade para clusters do Modo Automático do Amazon EKS.
**Topics**
+ [Acesso a logs de componentes gerenciados pela AWS para o EKS Auto](auto-managed-component-logs.md)
# Acesso a logs de componentes gerenciados pela AWS para o EKS Auto
É possível acessar logs de componentes gerenciados pela AWS do Modo Automático do EKS para obter uma observabilidade mais profunda em suas operações de cluster. O Modo Automático do EKS oferece suporte a logs para as fontes a seguir:
+ Escalabilidade automática de computação - Karpenter
+ Armazenamento em bloco - EBS CSI
+ Balanceamento de carga - controlador de balanceador de carga da AWS
+ Rede de pods - gerenciamento de endereços IP de CNI de VPC
Os logs podem ser entregues em um [destino de entrega](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html) de sua escolha.
Ao criar um cluster de EKS Auto, há a opção de habilitar o registro em log do ambiente de gerenciamento (servidor de API, auditoria, autenticador, gerenciador de controladores, agendador). Os logs de componentes gerenciados pelo EKS Auto (como computação, armazenamento em blocos, balanceamento de carga e IPAM) exigem configuração separada por meio da entrega de logs.
## Configurando a entrega do log
Para configurar a entrega de logs de componentes gerenciados pela AWS para seu cluster do Modo Automático do EKS, use a API Amazon CloudWatch Logs. Para obter instruções de configuração detalhadas, consulte [Habilitação do registro em log de serviços da AWS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-vended-logs-permissions-V2.html) no Guia do usuário do Amazon CloudWatch Logs. Cada funcionalidade do Modo Automático pode ser configurada como uma fonte de entrega individual do CloudWatch Vended Logs, permitindo que você selecione a quais registros você gostaria de ter acesso.
O Modo Automático do EKS oferece suporte aos tipos de instâncias a seguir:
+ **AUTO\$1MODE\$1COMPUTE\$1LOGS**
+ **AUTO\$1MODE\$1BLOCK\$1STORAGE\$1LOGS**
+ **AUTO\$1MODE\$1LOAD\$1BALANCING\$1LOGS**
+ **AUTO\$1MODE\$1IPAM\$1LOGS**
### Uso de APIS do Amazon CloudWatch Logs
A configuração do registro em log requer três etapas:
1. Crie uma fonte de entrega para o recurso usando a API PutDeliverySource do CloudWatch
1. Crie um destino de entrega com PutDeliveryDestination.
1. Crie uma entrega para conectar a origem e o destino usando CreateDelivery
É possível configurar os detalhes do destino dos logs do Modo Automático usando o objeto DeliveryDestinationConfiguration na API PutDeliveryDestination do CloudWatch. Ele usa o ARN de um grupo de logs do CloudWatch, bucket do S3 ou stream de entrega do Kinesis Data Firehose.
É possível configurar uma única funcionalidade de Modo Automático (fonte de entrega) para enviar logs para vários destinos criando várias entregas. Também é possível criar várias entregas para configurar várias fontes de entrega para enviar logs para o mesmo destino de entrega.
### permissões do IAM
Dependendo do destino selecionado, talvez seja necessário configurar políticas ou perfis do IAM para o grupo de logs do CloudWatch, o bucket do S3 e o Kinesis Data Firehose para garantir a entrega com êxito de logs. Além disso, se você estiver enviando logs entre contas da AWS, precisará usar a API PutDeliveryDestinationPolicy para configurar uma política do IAM que permita a entrega ao destino. Consulte a [documentação de permissões do CloudWatch Vended Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-CloudWatchLogs) para obter informações adicionais.
## Visualização dos logs
Depois que a entrega de logs for configurada, os logs serão entregues ao destino especificado. O método para acessar os logs depende do tipo de destino escolhido:
+ **CloudWatch Logs**: visualize logs no console do CloudWatch Logs, use comandos da CLI da AWS ou consulte com o CloudWatch Logs Insights
+ **Amazon S3**: acesse logs como objetos em seu bucket do S3 por meio do console do S3, da CLI da AWS ou de ferramentas de análise, como o Amazon Athena
+ **Amazon Data Firehose**: os logs são transmitidos para seu destino configurado do Firehose (como S3, OpenSearch Service, Redshift etc.)
## Preços
As cobranças do CloudWatch Vended Logs se aplicam à entrega e armazenamento de logs com base no destino de entrega escolhido. O CloudWatch Vended Logs permite a entrega confiável e segura de logs com autenticação e autorização da AWS integradas, a um preço reduzido em comparação com o CloudWatch Logs padrão. Consulte a [seção Vended Logs da página de definição de preços do CloudWatch](https://aws.amazon.com/cloudwatch/pricing/) para obter mais detalhes.
### Recursos relacionados
+ [Registro em log do ambiente de gerenciamento do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html)
+ [API PutDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html) na referência de API do CloudWatch Logs
+ [API PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html) na referência de API do CloudWatch Logs
+ [API CreateDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html) na referência de API do CloudWatch Logs
# Solucionar problemas do Modo Automático do EKS
Com o Modo Automático do EKS, a AWS assume mais responsabilidade pelas instâncias do EC2 na conta da AWS. O EKS assume a responsabilidade pelo runtime do contêiner nos nós, pelo sistema operacional nos nós e por determinados controladores. Isso inclui um controlador de armazenamento em blocos, um controlador de balanceamento de carga e um controlador de computação.
Você deve usar as APIs da AWS e do Kubernetes para solucionar problemas de nós. É possível:
+ Use um recurso `NodeDiagnostic` do Kubernetes para recuperar os logs dos nós usando o [Agente de monitoramento de nós](#auto-node-monitoring-agent). Para conferir as etapas, consulte [Recuperar logs de nós de um nó gerenciado usando kubectl e S3](auto-get-logs.md).
+ Use o comando `get-console-output` da CLI do AWS EC2 para recuperar a saída do console dos nós. Para conferir as etapas, consulte [Obter a saída do console de uma instância gerenciada do EC2 usando a CLI do AWS EC2](#auto-node-console).
+ Use os *contêineres de depuração* do Kubernetes para recuperar os logs dos nós. Para conferir as etapas, consulte [Obter logs de nós usando *contêineres de depuração* e a CLI do `kubectl`](#auto-node-debug-logs).
**nota**
O Modo Automático do EKS usa instâncias gerenciadas pelo EC2. Você não pode acessar diretamente as instâncias gerenciadas pelo EC2, inclusive por SSH.
Você pode ter os seguintes problemas que têm soluções específicas para os componentes do Modo Automático do EKS:
+ Pods presos no estado `Pending`, que não estão sendo agendados nos nós do Modo Automático. Para conferir as soluções, consulte [Solucionar problemas de pods com falhas ao agendar o nó do Modo Automático](#auto-troubleshoot-schedule).
+ Instâncias gerenciadas do EC2 que não se juntam ao cluster como nós do Kubernetes. Para conferir as soluções, consulte [Solucionar problemas de nós que não estão se associando ao cluster](#auto-troubleshoot-join).
+ Erros e problemas com `NodePools`, `PersistentVolumes` e `Services` que usam os controladores incluídos no Modo Automático do EKS. Para conferir as soluções, consulte [Solucionar problemas de controladores incluídos no Modo Automático](#auto-troubleshoot-controllers).
+ A segurança aprimorada de pods impede o compartilhamento de volumes entre pods. Para conferir as soluções, consulte [Compartilhar volumes entre pods](#auto-troubleshoot-share-pod-volumes).
Você pode usar os seguintes métodos para solucionar problemas de componentes do Modo Automático do EKS:
+ [Obter a saída do console de uma instância gerenciada do EC2 usando a CLI do AWS EC2](#auto-node-console)
+ [Obter logs de nós usando *contêineres de depuração* e a CLI do `kubectl`](#auto-node-debug-logs)
+ [Visualizar recursos associados ao Modo Automático do EKS no Console da AWS](#auto-node-ec2-web)
+ [Visualizar erros do IAM na conta da AWS](#auto-node-iam)
+ [Detectar problemas de conectividade de nós com o `VPC Reachability Analyzer`](#auto-node-reachability)
## Agente de monitoramento de nós
O Modo Automático do EKS inclui o agente de monitoramento de nós do Amazon EKS. Você pode usar esse agente para visualizar informações de solução de problemas e depuração sobre os nós. O agente de monitoramento de nós publica os `events` do Kubernetes e as `conditions` dos nós. Para obter mais informações, consulte [Detectar problemas de integridade dos nós e habilitar o reparo automático dos nós](node-health.md).
## Obter a saída do console de uma instância gerenciada do EC2 usando a CLI do AWS EC2
Este procedimento ajuda na solução de problemas de tempo de inicialização ou no nível do kernel.
Primeiro, você precisa determinar o ID da instância do EC2 associada à workload. Depois, use a AWS CLI para recuperar a saída do console.
1. Confirme se você tem o `kubectl` instalado e se está conectado ao cluster.
1. (Opcional) Use o nome de uma implantação do Kubernetes para listar os pods associados.
```
kubectl get pods -l app=
```
1. Use o nome do pod do Kubernetes para determinar o ID da instância do EC2 do nó associado.
```
kubectl get pod -o wide
```
1. Use o ID da instância do EC2 para recuperar a saída do console.
```
aws ec2 get-console-output --instance-id --latest --output text
```
## Obter logs de nós usando *contêineres de depuração* e a CLI do `kubectl`
A forma recomendada de recuperar logs de um nó do Modo Automático do EKS é usar o recurso `NodeDiagnostic`. Para conferir essas etapas, consulte [Recuperar logs de nós de um nó gerenciado usando kubectl e S3](auto-get-logs.md).
No entanto, você pode transmitir logs ao vivo de uma instância usando o comando `kubectl debug node`. Esse comando inicia um novo pod no nó que você deseja depurar e que pode ser usado interativamente.
1. Inicie um contêiner de depuração. O comando a seguir usa `i-01234567890123456` para o ID da instância do nó, `-it` aloca um `tty` e anexa `stdin` para uso interativo e usa o perfil `sysadmin` do arquivo kubeconfig.
```
kubectl debug node/i-01234567890123456 -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023
```
Veja abaixo um exemplo de saída.
```
Creating debugging pod node-debugger-i-01234567890123456-nxb9c with container debugger on node i-01234567890123456.
If you don't see a command prompt, try pressing enter.
bash-5.2#
```
1. No shell, agora você pode instalar o `util-linux-core`, que fornece o comando `nsenter`. Use `nsenter` para inserir o namespace de montagem do PID 1 (`init`) no host e execute o comando `journalctl` para transmitir logs do `kubelet`:
```
yum install -y util-linux-core
nsenter -t 1 -m journalctl -f -u kubelet
```
Por segurança, a imagem do contêiner do Amazon Linux não instala muitos binários por padrão. Você pode usar o comando `yum whatprovides` para identificar o pacote que deve ser instalado para fornecer um determinado binário.
```
yum whatprovides ps
```
```
Last metadata expiration check: 0:03:36 ago on Thu Jan 16 14:49:17 2025.
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : @System
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : amazonlinux
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
```
## Visualizar recursos associados ao Modo Automático do EKS no Console da AWS
Você pode usar o Console da AWS para visualizar o status dos recursos associados ao cluster do Modo Automático do EKS.
+ [Volumes do EBS](https://console.aws.amazon.com/ec2/home#Volumes)
+ Visualize os volumes do Modo Automático do EKS pesquisando pela chave de tag `eks:eks-cluster-name`
+ [Load balancers](https://console.aws.amazon.com/ec2/home#LoadBalancers)
+ Visualize os balanceadores de carga do Modo Automático do EKS pesquisando pela chave de tag `eks:eks-cluster-name`
+ [Instâncias do EC2](https://console.aws.amazon.com/ec2/home#Instances)
+ Visualize as instâncias do Modo Automático do EKS pesquisando pela chave de tag `eks:eks-cluster-name`
## Visualizar erros do IAM na conta da AWS
1. Navegue até o console do CloudTrail
1. Selecione "Histórico de eventos" no painel de navegação à esquerda
1. Aplique filtros de código de erro:
+ AccessDenied
+ UnauthorizedOperation
+ InvalidClientTokenId
Procure erros relacionados ao cluster do EKS. Use as mensagens de erro para atualizar as entradas de acesso ao EKS, o perfil do IAM do cluster ou o perfil do IAM do nó. Pode ser necessário anexar uma nova política a esses perfis com permissões para o Modo Automático do EKS.
## Solucionar problemas de pods com falhas ao agendar o nó do Modo Automático
Caso os pods estejam ficando no estado `Pending` e não estejam sendo agendados no nó do modo automático, verifique se o seu manifesto de pod ou de implantação contém um `nodeSelector`. Se um `nodeSelector` estiver presente, certifique-se de que ele esteja usando `eks.amazonaws.com/compute-type: auto` para ser agendado em nós criados pelo Modo Automático do EKS. Para obter mais informações sobre os rótulos dos nós usados pelo Modo Automático do EKS, consulte [Controlar se uma workload é implantada nos nós do Modo Automático do EKS](associate-workload.md).
## Solucionar problemas de nós que não estão se associando ao cluster
O Modo Automático do EKS configura automaticamente novas instâncias do EC2 com as informações corretas para se associar ao cluster, incluindo o endpoint do cluster e a autoridade de certificação (CA) do cluster. No entanto, essas instâncias ainda podem falhar ao se associarem ao cluster do EKS como um nó. Execute os seguintes comandos para identificar as instâncias que não se associaram ao cluster:
1. Execute `kubectl get nodeclaim` para verificar os `NodeClaims` que são `Ready = False`.
```
kubectl get nodeclaim
```
1. Execute `kubectl describe nodeclaim ` e verifique a seção **Status** para identificar possíveis problemas que impedem o nó de se associar ao cluster.
```
kubectl describe nodeclaim
```
**Mensagens de erro comuns:**
`Error getting launch template configs`
Você pode receber esse erro caso esteja configurando tags personalizadas no `NodeClass` com as permissões padrão do perfil do IAM do cluster. Consulte [Saber mais sobre identidade e acesso no Modo Automático do EKS](auto-learn-iam.md).
`Error creating fleet`
Pode ocorrer um problema de autorização ao fazer a chamada `RunInstances` da API do EC2. Verifique o AWS CloudTrail em busca de erros e consulte [Perfil do IAM do cluster do Modo Automático do Amazon EKS](auto-cluster-iam-role.md) para obter as permissões necessárias do IAM.
### Detectar problemas de conectividade de nós com o `VPC Reachability Analyzer`
**nota**
Há uma cobrança por cada análise executada no VPC Reachability Analyzer. Para obter detalhes dos preços, consulte [Preços da Amazon VPC](https://aws.amazon.com/vpc/pricing/).
Um dos motivos pelos quais uma instância não se associou ao cluster é um problema de conectividade de rede que a impede de acessar o servidor da API. Para diagnosticar esse problema, você pode usar o [VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) para realizar uma análise da conectividade entre um nó que não está conseguindo se associar ao cluster e o servidor de API. Você precisará de duas informações:
+ **ID da instância** de um nó que não consegue se associar ao cluster
+ Endereço IP do **endpoint do servidor de API do Kubernetes**
Para obter o **ID da instância**, você precisará criar uma workload no cluster para fazer com que o Modo Automático do EKS inicie uma instância do EC2. Isso também cria um objeto `NodeClaim` no seu cluster que terá o ID da instância. Execute `kubectl get nodeclaim -o yaml` para imprimir todos os `NodeClaims` no cluster. Cada `NodeClaim` contém o ID da instância como um campo, e novamente no providerID:
```
kubectl get nodeclaim -o yaml
```
Veja abaixo um exemplo de saída.
```
nodeName: i-01234567890123456
providerID: aws:///us-west-2a/i-01234567890123456
```
Você pode determinar o **endpoint do servidor de API do Kubernetes** executando `kubectl get endpoint kubernetes -o yaml`. Os endereços estão no campo de endereços:
```
kubectl get endpoints kubernetes -o yaml
```
Veja abaixo um exemplo de saída.
```
apiVersion: v1
kind: Endpoints
metadata:
name: kubernetes
namespace: default
subsets:
- addresses:
- ip: 10.0.143.233
- ip: 10.0.152.17
ports:
- name: https
port: 443
protocol: TCP
```
Com essas duas informações, você pode realizar a análise. Primeiro, navegue até o VPC Reachability Analyzer no Console de gerenciamento da AWS.
1. Clique em "Criar e analisar caminho"
1. Forneça um nome para a análise (por exemplo, "Falha na associação do nó")
1. Para o "Tipo de origem", selecione "Instâncias"
1. Insira o ID da instância do nó com falha como a "Origem"
1. Para o "Destino do caminho", selecione "Endereço IP"
1. Insira um dos endereços IP do servidor da API como "Endereço de destino"
1. Expanda a "Seção de configuração adicional do cabeçalho de pacote"
1. Insira uma "Porta de destino" de 443
1. Selecione "Protocolo" como TCP caso ainda não tenha selecionado
1. Clique em “Criar e analisar caminho”.
1. A análise pode levar alguns minutos para ser concluída. Se os resultados da análise indicarem falha na acessibilidade, eles indicarão onde a falha ocorreu no caminho da rede para que você possa resolver o problema.
## Compartilhar volumes entre pods
Os nós do Modo Automático do EKS são configurados com o SELinux no modo de imposição, o que fornece mais isolamento entre os pods que estão sendo executados no mesmo nó. Quando o SELinux está habilitado, a maioria dos pods sem privilégios terá automaticamente seu próprio rótulo de segurança de várias categorias (MCS) aplicado a eles. Esse rótulo MCS é exclusivo por pod e foi projetado para garantir que um processo em um pod não possa manipular um processo em nenhum outro pod ou no host. Mesmo que um pod rotulado seja executado como raiz e tenha acesso ao sistema de arquivos do host, ele não conseguirá manipular arquivos, fazer chamadas de sistema sensíveis no host, acessar o runtime do contêiner ou obter o material da chave secreta do kubelet.
Devido a essa questão, você pode encontrar problemas ao tentar compartilhar dados entre pods. Por exemplo, um `PersistentVolumeClaim` com um modo de acesso de `ReadWriteOnce` não permitirá que vários pods acessem o volume simultaneamente.
Para habilitar esse compartilhamento entre pods, você pode usar as `seLinuxOptions` do pod para configurar o mesmo rótulo MCS nesses pods. Neste exemplo, atribuímos as três categorias `c123,c456,c789` ao pod. Isso não entrará em conflito com nenhuma categoria atribuída automaticamente aos pods no nó, pois eles só receberão duas categorias.
```
securityContext:
seLinuxOptions:
level: "s0:c123,c456,c789"
```
## Exibir eventos do Karpenter nos logs do ambiente de gerenciamento
Para clusters do EKS com logs do ambiente de gerenciamento habilitados, é possível obter informações sobre as ações e o processo de tomada de decisão do Karpenter consultando os logs. Isso pode ser particularmente útil para solucionar problemas do Modo Automático do EKS relacionados ao provisionamento, ajuste de escala e encerramento de nós. Para visualizar eventos relacionados ao Karpenter, use a seguinte consulta do CloudWatch Logs Insights:
```
fields @timestamp, @message
| filter @logStream like /kube-apiserver-audit/
| filter @message like 'DisruptionBlocked'
or @message like 'DisruptionLaunching'
or @message like 'DisruptionTerminating'
or @message like 'DisruptionWaitingReadiness'
or @message like 'Unconsolidatable'
or @message like 'FailedScheduling'
or @message like 'NoCompatibleInstanceTypes'
or @message like 'NodeRepairBlocked'
or @message like 'Disrupted'
or @message like 'Evicted'
or @message like 'FailedDraining'
or @message like 'TerminationGracePeriodExpiring'
or @message like 'TerminationFailed'
or @message like 'FailedConsistencyCheck'
or @message like 'InsufficientCapacityError'
or @message like 'UnregisteredTaintMissing'
or @message like 'NodeClassNotReady'
| sort @timestamp desc
```
Essa consulta filtra [eventos relacionados ao Karpenter](https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/events/reason.go) específicos nos logs de auditoria do kube-apiserver. Os eventos incluem vários estados de interrupção, falhas de agendamento, problemas de capacidade e problemas relacionados ao nó. Ao analisar esses logs, é possível compreender melhor:
+ Por que Karpenter está tomando certas ações.
+ Qualquer problema que impeça o provisionamento, o ajuste de escala ou o encerramento adequados dos nós.
+ Possíveis problemas de capacidade ou compatibilidade com tipos de instância.
+ Eventos do ciclo de vida do nó, como interrupções, remoções ou encerramentos.
Para usar essa consulta:
1. Navegue até o console do CloudWatch
1. No painel de navegação à esquerda, selecione "Logs Insights"
1. Escolha o grupo de logs para os logs do ambiente de gerenciamento do seu cluster do EKS
1. Cole a consulta no editor de consultas
1. Ajuste o intervalo de tempo conforme necessário
1. Execute a consulta
Os resultados mostrarão um cronograma de eventos relacionados ao Karpenter, ajudando você a solucionar problemas e a entender o comportamento do Modo Automático do EKS em seu cluster. Para revisar as ações do Karpenter em um nó específico, é possível adicionar o filtro de linha abaixo especificando o ID da instância à consulta mencionada acima:
```
|filter @message like /[.replaceable]`i-12345678910123456`/
```
**nota**
Para usar essa consulta, os logs do ambiente de gerenciamento devem estar habilitados em seu cluster do EKS. Se você ainda não fez isso, consulte [Enviar logs do ambiente de gerenciamento para o CloudWatch Logs](control-plane-logs.md).
## Solucionar problemas de controladores incluídos no Modo Automático
Caso tenha um problema com um controlador, você deve pesquisar:
+ Se os recursos associados a esse controlador estão devidamente formatados e válidos.
+ Se os recursos de RBAC do AWS IAM e do Kubernetes estão configurados corretamente para o cluster. Para obter mais informações, consulte [Saber mais sobre identidade e acesso no Modo Automático do EKS](auto-learn-iam.md).
## Recursos relacionados
Use estes artigos do AWS re:Post para obter etapas avançadas de solução de problemas:
+ [How to troubleshoot common scaling issues in EKS Auto-Mode?](https://repost.aws/articles/ARLpQOknr5Rb-w5iAT9sUBpQ)
+ [How do I troubleshoot custom nodepool and nodeclass provisioning issues in Amazon EKS Auto Mode?](https://repost.aws/articles/ARPcmFS1POTgqPCBdcZFp6BQ)
+ [How do I troubleshoot EKS Auto Mode built-in node pools with Unknown Status?](https://repost.aws/en/articles/ARLhrdl45TRASGkvViwtBG0Q)
# Analisar as notas de release do Modo automático do EKS
Esta página documenta as atualizações do Modo automático do Amazon EKS. É possível verificar periodicamente esta página para ver anúncios sobre recursos, correções de erros, problemas conhecidos e funcionalidades obsoletas.
Para receber notificações de todas as alterações do arquivo de origem nesta página específica da documentação, você pode se inscrever no seguinte URL com um leitor de RSS:
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/automode/auto-change.adoc.atom
```
## 2 de fevereiro de 2026
**Atributo**: foi adicionado suporte para desabilitar o tráfego v4egress de pods IPv6 em clusters IPv6 de modo automático do EKS. Para obter mais informações, consulte [Desabilite a saída de IPv4 dos pods IPv6 em clusters de IPv6.](create-node-class.md#enableV4Egress).
## 19 de dezembro de 2025
**Atributo**: foi adicionado suporte para o modo IP secundário que provisiona endereços IP secundários em vez de prefixar os nós automáticos. O modo mantém um IP secundário como MinimalIPTarget e economiza recursos de IP para clientes que não precisem aquecer mais IPs ou prefixos secundários. Para obter mais informações, consulte [Especificação das classes de nós](create-node-class.md#auto-node-class-spec) e [Modo de IP secundário para pods](create-node-class.md#secondary-IP-mode).
## 19 de novembro de 2025
**Recurso**: habilitamos a disponibilização e a descompactação em paralelo de Seekable OCI (SOCI) para as famílias de instâncias G, P e Trn que contam com o armazenamento NVMe local. A disponibilização e o desempacotamento paralelos de SOCI são sempre usados para essas famílias de instâncias com o modo automático do EKS, e não são necessárias alterações de configuração para ativá-los. Para obter mais informações sobre o SOCI, consulte o [blog de lançamento](https://aws.amazon.com/blogs/containers/introducing-seekable-oci-parallel-pull-mode-for-amazon-eks/).
## 19 de novembro de 2025
**Recurso**: adicionamos suporte para grupos de nós de capacidade estática que mantêm um número fixo de nós. Para obter mais informações, consulte [Grupos de nós de capacidade estática no modo automático do EKS](auto-static-capacity.md).
## 23 de outubro de 2025
**Recurso:** os usuários com clusters em regiões dos EUA agora podem solicitar o uso de AMIs compatíveis com FIPS especificando `spec.advancedSecurity.fips` na definição de NodeClass.
## 1.º de outubro de 2025
**Recurso:** o modo automático do EKS agora fornece suporte para a implantação de nós em zonas locais da AWS. Para obter mais informações, consulte [Implantação de nós do modo automático do EKS em zonas locais](auto-local-zone.md).
## 30 de setembro de 2025
**Recurso:** adicionamos suporte para instanceProfile ao `spec.instanceProfile` da NodeClass, que é mutuamente exclusivo em relação ao campo `spec.role`.
## 29 de setembro de 2025
No momento, o DRA não é compatível com o modo automático do EKS.
## 10 de setembro de 2025
**Obrigação:** os eventos disparados pelo controlador de computação do modo automático do EKS agora usarão o nome `eks-auto-mode/compute` em vez de `karpenter`.
## 24 de agosto de 2025
**Correção de erro:** as VPCs que usavam um conjunto de opções DHCP com um nome de domínio personalizado contendo letras maiúsculas faziam com que os nós não conseguissem se juntar ao cluster devido à geração de um nome de host inválido. Isso foi resolvido e nomes de domínio com letras maiúsculas agora funcionam corretamente.
## 15 de agosto de 2025
**Correção de erro:** o Atendente de Identidade de Pods agora só escuta no endereço local do link IPv4 em um cluster de EKS IPv4 para evitar problemas em que o pod não consiga acessar o endereço IPv6.
## 6 de agosto de 2025
**Recurso:** adicionada nova configuração em `spec.advancedNetworking.associatePublicIPAddress` no NodeClass que pode ser usada para evitar que endereços IP públicos sejam atribuídos aos nós do modo automático do EKS
## 30 de junho de 2025
**Atributo:** o NodeClass do modo automático agora usa a chave do KMS personalizada configurada para criptografar o volume raiz somente para leitura da instância, além do volume de dados de leitura/gravação. Anteriormente, a chave do KMS personalizada era usada somente para criptografar o volume de dados.
## 20 de junho de 2025
**Recurso:** suporte para controlar a implantação de workloads em reservas de capacidade sob demanda (ODCRs) do EC2. Isso adiciona a chave opcional `capacityReservationSelectorTerms` ao NodeClass, permitindo que você controle explicitamente quais ODCRs suas workloads usam. Para obter mais informações, consulte [Controle da implantação de workloads em reservas de capacidade com o modo automático do EKS](auto-odcr.md).
## 13 de junho de 2025
**Recurso:** suporte para sub-redes de pod separadas no `NodeClass`. Isso adiciona as chaves opcionais ``podSubnetSelectorTerms` e `podSecurityGroupSelectorTerms` para definir as sub-redes e os grupos de segurança para os pods. Para obter mais informações, consulte [Sub-redes e grupos de segurança separados para Pods](create-node-class.md#pod-subnet-selector).
## 30 de abril de 2025
**Recurso:** suporte para proxies de rede de encaminhamento no `NodeClass`. Isso adiciona a chave opcional `advancedNetworking` para configurar seu proxy HTTPS. Para obter mais informações, consulte [Especificação das classes de nós](create-node-class.md#auto-node-class-spec).
## 18 de abril de 2025
**Funcionalidade:** suporte para resolver domínios locais (normalmente reservados para DNS multicast) via DNS unicast.
## 11 de abril de 2025
**Funcionalidade:** adicionados `certificateBundles` e `ephemeralStorage.kmsKeyID` ao `NodeClass`. Para obter mais informações, consulte [Especificação das classes de nós](create-node-class.md#auto-node-class-spec).
**Funcionalidade:** velocidade de extração de imagens aprimorada, especialmente para tipos de instância com armazenamento de instância local que podem aproveitar a descompactação mais rápida da imagem.
**Correção de erro:** resolvida uma condição de corrida que causava FailedCreatePodSandBox , Error while dialing: dial tcp 127.0.0.1:50051: connect: a conexão, às vezes, não ocorria para a programação de pods para um nó imediatamente na inicialização.
## 04 de abril de 2025
**Funcionalidade:** aumento de `registryPullQPS` de 5 para 25 e de `registryBurst` de 10 para 50 para reduzir a controle de utilização de extração de imagens imposta pelo cliente (`Failed to pull image xyz: pull QPS exceeded`)
## 31 de março de 2025
**Correção de erro:** corrigiu um problema em que, se um pod central do DNS estivesse sendo executado em um nó do Modo automático, as consultas ao DNS dos pods no nó atingiriam esse pod central do DNS em vez do servidor DNS local do nó. As consultas ao DNS de pods em um nó do Modo automático sempre irão para o DNS local do nó.
## 21 de março de 2025
**Correção de erro:** os nós do Modo automático agora resolvem `kube-dns.kube-system.svc.cluster.local` corretamente quando não há um serviço de `kube-dns` instalado no cluster. Resolve o problema \$12546 do GitHub [\$12546](https://github.com/aws/containers-roadmap/issues/2546).
## 14 de março de 2025
**Funcionalidade**: saída `IPv4` habilitada em clusters `IPv6`. O tráfego `IPv4` que sai dos clusters `IPv6` do Modo automático agora será convertido automaticamente para o endereço `v4` da ENI primária do nó.