**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.
# 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. Para obter uma orientação prescritiva, consulte [https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html)
+ 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. **Modificar a política de retenção de volume**: altere a política `persistentVolumeReclaimPolicy` do PersistentVolume (PV) existente para `Retain` a fim de garantir que o volume do EBS subjacente 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.