Contribuisci a migliorare questa pagina
Per contribuire a questa guida per l’utente, seleziona il link Edit this page on GitHub che si trova nel riquadro destro di ogni pagina.
Eseguire la migrazione da EKS Fargate a EKS Auto Mode
Questo argomento descrive il processo di migrazione dei carichi di lavoro da EKS Fargate ad Amazon EKS Auto Mode 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’approccio dettagliato descritto di seguito ti consente di eseguire EKS Fargate ed EKS Auto Mode in parallelo 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 EKS Auto Mode 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 con 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. EKS Auto Mode è 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, EKS Auto Mode 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, EKS Auto Mode 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 Amazon EKS Auto Mode, 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 ed EC2, pur mantenendo la facilità d’uso e l’astrazione dalla gestione dell’infrastruttura fornite da Fargate.
Prerequisiti
Prima di iniziare la migrazione, assicurarti di aver:
-
configurato un cluster con Fargate. Per ulteriori informazioni, consulta Iniziare a utilizzare AWS Fargate con il cluster;
-
installato e connesso
kubectlal cluster. Per ulteriori informazioni, consulta Configurazione per l’utilizzo di Amazon EKS.
Fase 1: Verificare il cluster Fargate
-
Verifica se il cluster EKS con Fargate è in esecuzione:
kubectl get nodeNAME STATUS ROLES AGE VERSION fargate-ip-192-168-92-52.ec2.internal Ready <none> 25m v1.30.8-eks-2d5f260 fargate-ip-192-168-98-196.ec2.internal Ready <none> 24m v1.30.8-eks-2d5f260
-
Verifica i pod in esecuzione:
kubectl get pod -ANAMESPACE 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
-
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 -
Applica l’implementazione:
kubectl apply -f deployment_fargate.yamldeployment.apps/nginx-deployment created
-
Verifica i pod e le implementazioni:
kubectl get pod,deployNAME 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
-
Verifica il nodo:
kubectl get node -owideNAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME fargate-ip-192-168-111-43.ec2.internal Ready <none> 31s v1.30.8-eks-2d5f260 192.168.111.43 <none> Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25 fargate-ip-192-168-117-130.ec2.internal Ready <none> 36s v1.30.8-eks-2d5f260 192.168.117.130 <none> Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25 fargate-ip-192-168-74-140.ec2.internal Ready <none> 36s v1.30.8-eks-2d5f260 192.168.74.140 <none> Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
Fase 2: Abilitare EKS Auto Mode sul cluster
-
Abilita EKS Auto Mode sul cluster esistente utilizzando AWS CLI o la console di gestione. Per ulteriori informazioni, consulta Abilita EKS Auto Mode su un cluster esistente.
-
Verifica il nodepool:
kubectl get nodepoolNAME 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 a EKS Auto Mode.
Per eseguire la migrazione di un carico di lavoro da Fargate a EKS Auto Mode, applica l’annotazione eks.amazonaws.com/compute-type: ec2. Ciò garantisce che il carico di lavoro non venga pianificato da Fargate, nonostante il profilo Fargate, e venga gestito da EKS Auto Mode NodePool. Per ulteriori informazioni, consulta Crea un pool di nodi per EKS Auto Mode.
-
Modifica le implementazioni (ad esempio, il file
deployment_fargate.yaml) per cambiare il tipo di elaborazione inec2: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 -
Applica l’implementazione. Questa modifica consente di pianificare il carico di lavoro sui nuovi nodi EKS Auto Mode:
kubectl apply -f deployment_fargate.yaml -
Verifica che l’implementazione sia in esecuzione nel cluster EKS Auto Mode:
kubectl get pod -o wideNAME 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 <none> <none> nginx-deployment-97967b68d-mbcgj 1/1 Running 0 2m37s 192.168.43.241 i-0845aafcb51630ffb <none> <none> nginx-deployment-97967b68d-qpd8x 1/1 Running 0 2m35s 192.168.43.242 i-0845aafcb51630ffb <none> <none>
-
Verifica che non sia in esecuzione alcun nodo Fargate e che l’implementazione sia in esecuzione nei nodi gestiti da EKS Auto Mode:
kubectl get node -owideNAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME i-0845aafcb51630ffb Ready <none> 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 <fargate profile name> con il nome del profilo Fargate:
aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --fargate-profile-name <fargate profile name>
Fase 6: Ridurre verticalmente CoreDNS
Poiché EKS Auto Mode gestisce CoreDNS, puoi ridurre verticalmente l’implementazione coredns fino a 0:
kubectl scale deployment coredns -n kube-system —-replicas=0