**Ayude a mejorar esta página**
Para contribuir a esta guía del usuario, elija el enlace **Edit this page on GitHub** que se encuentra en el panel derecho de cada página.
# Migración de EKS Fargate a los nodos del modo automático de EKS
En esta sección, se explica el proceso para migrar cargas de trabajo de EKS Fargate al modo automático de Amazon EKS mediante `kubectl`. La migración se puede realizar de forma gradual, lo que le permite trasladar las cargas de trabajo a su propio ritmo y, al mismo tiempo, mantener la estabilidad del clúster y la disponibilidad de las aplicaciones durante la transición.
El enfoque paso a paso que se describe a continuación permite ejecutar EKS Fargate y el modo automático de EKS paralelamente durante el periodo de migración. Esta estrategia de doble operación ayuda a garantizar una transición fluida, ya que permite validar el comportamiento de la carga de trabajo en el modo automático de EKS antes de desmantelar completamente EKS Fargate. Puede migrar aplicaciones individualmente o en grupos, lo que proporciona flexibilidad para acomodar los requisitos operativos específicos y el nivel de tolerancia al riesgo.
## Comparación entre el modo automático de Amazon EKS y EKS con AWS Fargate
Amazon EKS con AWS Fargate sigue siendo una opción para los clientes que desean utilizar EKS, pero el modo automático de Amazon EKS es el enfoque recomendado en el futuro. El modo automático de EKS es totalmente compatible con Kubernetes y con todas las primitivas y herramientas de plataforma originales de Kubernetes, como Istio, que Fargate no admite. El modo automático de EKS también es totalmente compatible con todas las opciones de compra en tiempo de ejecución de EC2, incluidas las instancias de GPU y de spot, lo que permite a los clientes aprovechar los descuentos negociados de EC2 y otros mecanismos de ahorro. Estas funciones no están disponibles cuando se utiliza EKS con Fargate.
Además, el modo automático de EKS permite a los clientes lograr el mismo modelo de aislamiento que Fargate, utilizando las capacidades de programación estándar de Kubernetes para garantizar que cada instancia de EC2 ejecute un único contenedor de aplicaciones. Al adoptar el modo automático de Amazon EKS, los clientes pueden aprovechar todas las ventajas de ejecutar Kubernetes en AWS, una plataforma totalmente compatible con Kubernetes que ofrece la flexibilidad necesaria para aprovechar toda la gama de EC2 y las opciones de compra, al tiempo que conserva la facilidad de uso y la abstracción de la administración de infraestructuras que ofrece Fargate.
### Cómo lograr un aislamiento similar a Fargate en el modo automático de EKS
Para replicar el modelo de aislamiento de pods de Fargate, donde cada pod se ejecuta en su propia instancia dedicada, puede utilizar restricciones de dispersión de topología de Kubernetes. Este es el enfoque recomendado para controlar la distribución de pods entre nodos:
```
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
```
En esta configuración:
+ `maxSkew: 1` garantiza que la diferencia en el número de pods entre cualesquiera dos nodos sea como máximo 1, lo que distribuye efectivamente un pod por nodo.
+ `topologyKey: kubernetes.io/hostname` define el nodo como el dominio de topología
+ `whenUnsatisfiable: DoNotSchedule` impide la programación si no se puede cumplir la restricción
+ `minDomains: 1` garantiza que exista al menos un dominio (nodo) antes de la programación
El modo automático de EKS aprovisionará automáticamente nuevas instancias de EC2 según sea necesario para satisfacer esta restricción, lo que proporciona el mismo modelo de aislamiento que Fargate y da acceso a toda la gama de tipos de instancias de EC2 y opciones de compra.
Como alternativa, puede utilizar reglas de antiafinidad de pods para un aislamiento más estricto:
```
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
```
La regla `podAntiAffinity` con `requiredDuringSchedulingIgnoredDuringExecution` garantiza que no se puedan programar dos pods con la etiqueta `app: isolated-app` en el mismo nodo. Este enfoque proporciona garantías estrictas de aislamiento similares a las de Fargate.
## Requisitos previos
Antes de iniciar la migración, asegúrese de que ha hecho lo siguiente:
+ Configurar un clúster con Fargate. Para obtener más información, consulte [Introducción a AWS Fargate para un clúster](fargate-getting-started.md).
+ Instalar y conectar `kubectl` al clúster. Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md).
## Paso 1: Revisión del clúster de Fargate
1. Revise si el clúster de EKS con Fargate está en ejecución:
```
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. Revise los pods en ejecución:
```
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. Cree una implementación en un archivo llamado `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 la implementación:
```
kubectl apply -f deployment_fargate.yaml
```
```
deployment.apps/nginx-deployment created
```
1. Revise los pods y las implementaciones:
```
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. Revise el nodo:
```
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
```
## Paso 2: Habilitación del modo automático de EKS en el clúster
1. Habilite el modo automático de EKS en el clúster existente mediante AWS CLI o la Consola de administración. Para obtener más información, consulte [Cómo habilitar el modo automático de EKS en un clúster existente](auto-enable-existing.md).
1. Revise el nodepool:
```
kubectl get nodepool
```
```
NAME NODECLASS NODES READY AGE
general-purpose default 1 True 6m58s
system default 0 True 3d14h
```
## Paso 3: Actualización de las cargas de trabajo para la migración
Identifique y actualice las cargas de trabajo que desea migrar al modo automático de EKS.
Para migrar una carga de trabajo de Fargate al modo automático de EKS, aplique la anotación `eks.amazonaws.com/compute-type: ec2`. Esto garantiza que Fargate no programará la carga de trabajo, a pesar del perfil de Fargate, y que lo hará el NodePool del modo automático de EKS. Para obtener más información, consulte [Creación de un grupo de nodos para el modo automático de EKS](create-node-pool.md).
1. Modifique las implementaciones (por ejemplo, el archivo `deployment_fargate.yaml`) para cambiar el tipo de procesamiento a `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 la implementación. Este cambio permite programar la carga de trabajo en los nuevos nodos del modo automático de EKS:
```
kubectl apply -f deployment_fargate.yaml
```
1. Verifique que la implementación se esté ejecutando en el clúster del modo automático de 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 que no haya ningún nodo Fargate en ejecución ni ninguna implementación en ejecución en los nodos administrados del modo automático de 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
```
## Paso 4: Migración de las cargas de trabajo de forma gradual
Repita el paso 3 para cada carga de trabajo que desee migrar. Esto permite trasladar las cargas de trabajo de forma individual o en grupos, según los requisitos y la tolerancia al riesgo.
## Paso 5: Eliminación del perfil original de Fargate
Una vez que se hayan migrado todas las cargas de trabajo, podrá eliminar el perfil original de `fargate`. Reemplace ** por el nombre de su perfil de Fargate:
```
aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --fargate-profile-name
```
## Paso 6: Reducción vertical de CoreDNS
Como el modo automático de EKS gestiona CoreDNS, puede reducir la implementación de `coredns` a 0:
```
kubectl scale deployment coredns -n kube-system —-replicas=0
```