**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.
# 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
```