**Contribuisci a migliorare questa pagina**
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina.
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Eseguire la migrazione da EKS Fargate alla modalità automatica di EKS
Questo argomento descrive il processo di migrazione dei carichi di lavoro da EKS Fargate alla modalità automatica di Amazon EKS utilizzando `kubectl`. La migrazione può essere eseguita gradualmente, consentendo di spostare i carichi di lavoro al proprio ritmo, mantenendo al contempo la stabilità del cluster e la disponibilità delle applicazioni durante la transizione.
L' step-by-stepapproccio descritto di seguito consente di eseguire EKS Fargate e EKS Auto Mode fianco a fianco durante il periodo di migrazione. Questa strategia a doppio funzionamento aiuta a garantire una transizione fluida consentendo di convalidare il comportamento del carico di lavoro in modalità automatica di EKS prima di disattivare completamente EKS Fargate. Puoi eseguire la migrazione delle applicazioni singolarmente o in gruppo, garantendo la flessibilità necessaria per soddisfare i requisiti operativi specifici e la tolleranza al rischio.
## Confronto tra Amazon EKS Auto Mode ed EKS e AWS Fargate
Amazon EKS con AWS Fargate rimane un'opzione per i clienti che desiderano utilizzare EKS, ma Amazon EKS Auto Mode è l'approccio consigliato in futuro. La modalità automatica di EKS è completamente conforme a Kubernetes e supporta tutte le primitive Kubernetes a monte e gli strumenti di piattaforma come Istio, che Fargate non è in grado di supportare. Inoltre, modalità automatica di EKS supporta completamente tutte le opzioni di acquisto del runtime EC2, incluse GPU e istanze Spot, consentendo ai clienti di sfruttare gli sconti EC2 negoziati e altri meccanismi di risparmio. Queste funzionalità non sono disponibili quando si utilizza EKS con Fargate.
Inoltre, modalità automatica di EKS consente ai clienti di ottenere lo stesso modello di isolamento di Fargate, utilizzando le funzionalità di pianificazione di Kubernetes standard per garantire che ogni istanza EC2 esegua un singolo container di applicazioni. Adottando la modalità Auto di Amazon EKS, i clienti possono sfruttare tutti i vantaggi dell'esecuzione di Kubernetes su AWS una piattaforma completamente conforme a Kubernetes che offre la flessibilità necessaria per sfruttare l'intera gamma di opzioni di acquisto e EC2, pur mantenendo la facilità d'uso e l'astrazione dalla gestione dell'infrastruttura fornite da Fargate.
### Raggiungere un isolamento simile a quello di Fargate in modalità automatica EKS
Per replicare il modello di isolamento dei pod di Fargate, in cui ogni pod viene eseguito su una propria istanza dedicata, puoi utilizzare i vincoli di diffusione della topologia di Kubernetes. Questo è l'approccio consigliato per controllare la distribuzione dei pod tra i nodi:
```
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
```
In questa configurazione:
+ `maxSkew: 1`assicura che la differenza nel numero di pod tra due nodi qualsiasi sia al massimo 1, distribuendo efficacemente un pod per nodo
+ `topologyKey: kubernetes.io/hostname`definisce il nodo come dominio della topologia
+ `whenUnsatisfiable: DoNotSchedule`impedisce la pianificazione se il vincolo non può essere soddisfatto
+ `minDomains: 1`assicura l'esistenza di almeno un dominio (nodo) prima della pianificazione
EKS Auto Mode eseguirà automaticamente il provisioning di nuove istanze EC2 secondo necessità per soddisfare questo vincolo, fornendo lo stesso modello di isolamento di Fargate e dandoti accesso all'intera gamma di tipi di istanze EC2 e opzioni di acquisto.
In alternativa, puoi utilizzare le regole anti-affinità dei pod per un isolamento più rigoroso:
```
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 `podAntiAffinity` regola `requiredDuringSchedulingIgnoredDuringExecution` garantisce che non sia `app: isolated-app` possibile programmare due pod con l'etichetta sullo stesso nodo. Questo approccio offre garanzie di isolamento rigide simili a quelle di Fargate.
## Prerequisiti
Prima di iniziare la migrazione, assicurarti di aver:
+ configurato un cluster con Fargate. Per ulteriori informazioni, consulta [Inizia a usare AWS Fargate per il tuo cluster](fargate-getting-started.md);
+ installato e connesso `kubectl` al cluster. Per ulteriori informazioni, consulta [Configurazione per l’utilizzo di Amazon EKS](setting-up.md).
## Fase 1: Verificare il cluster Fargate
1. Verifica se il cluster EKS con Fargate è in esecuzione:
```
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. Verifica i pod in esecuzione:
```
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. Create un’implementazione in un file chiamato `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. Applica l’implementazione:
```
kubectl apply -f deployment_fargate.yaml
```
```
deployment.apps/nginx-deployment created
```
1. Verifica i pod e le implementazioni:
```
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. Verifica il 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
```
## Fase 2: Abilitare modalità automatica di EKS sul cluster
1. Abilita la modalità automatica EKS sul tuo cluster esistente utilizzando la AWS CLI o la console di gestione. Per ulteriori informazioni, consulta [Abilita modalità automatica di EKS su un cluster esistente](auto-enable-existing.md).
1. Verifica il nodepool:
```
kubectl get nodepool
```
```
NAME NODECLASS NODES READY AGE
general-purpose default 1 True 6m58s
system default 0 True 3d14h
```
## Fase 3: Aggiornare i carichi di lavoro per la migrazione
Identifica e aggiorna i carichi di lavoro che desideri migrare alla modalità automatica di EKS .
Per eseguire la migrazione di un carico di lavoro da Fargate alla modalità automatica di EKS , applica l’annotazione `eks.amazonaws.com/compute-type: ec2`. Ciò garantisce che il carico di lavoro non venga programmato da Fargate, nonostante il profilo Fargate, e venga interrotto dalla modalità automatica EKS. NodePool Per ulteriori informazioni, consulta [Crea un pool di nodi per EKS Auto Mode](create-node-pool.md).
1. Modifica le implementazioni (ad esempio, il file `deployment_fargate.yaml`) per cambiare il tipo di elaborazione in `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. Applica l’implementazione. Questa modifica consente di pianificare il carico di lavoro sui nuovi nodella modalità automatica di EKS:
```
kubectl apply -f deployment_fargate.yaml
```
1. Verifica che l’implementazione sia in esecuzione nel cluster della modalità automatica di 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. Verifica che non sia in esecuzione alcun nodo Fargate e che l’implementazione sia in esecuzione nei nodi gestiti dalla modalità automatica di 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
```
## Fase 4: Migrare gradualmente i carichi di lavoro
Ripeti la fase 3 per ogni carico di lavoro di cui desideri eseguire la migrazione. Ciò consente di spostare i carichi di lavoro individualmente o in gruppo, in base ai requisiti e alla tolleranza al rischio.
## Fase 5: Rimuovere il profilo Fargate originale
Una volta eseguita la migrazione di tutti i carichi di lavoro, puoi rimuovere il profilo `fargate` originale. Sostituisci ** con il nome del tuo profilo Fargate:
```
aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --fargate-profile-name
```
## Fase 6: Ridurre verticalmente CoreDNS
Poiché modalità automatica di EKS gestisce CoreDNS, puoi ridurre verticalmente l’implementazione `coredns` fino a 0:
```
kubectl scale deployment coredns -n kube-system —-replicas=0
```