Aiutaci 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à.
Migrazione da EKS Fargate alla modalità automatica EKS
Questo argomento illustra il processo di migrazione dei carichi di lavoro da EKS Fargate a Amazon EKS Auto Mode utilizzando. kubectl
La migrazione può essere eseguita gradualmente, consentendoti di spostare i carichi di lavoro secondo i tuoi ritmi, 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 doppia operazione aiuta a garantire una transizione fluida consentendovi di convalidare il comportamento del carico di lavoro in modalità automatica EKS prima di smantellare completamente EKS Fargate. È possibile migrare le 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. EKS Auto Mode è completamente conforme a Kubernetes e supporta tutte le primitive Kubernetes upstream e gli strumenti di piattaforma come Istio, che Fargate non è in grado di supportare. EKS Auto Mode supporta inoltre completamente tutte le opzioni EC2 di acquisto in fase di esecuzione, incluse GPU e istanze Spot, consentendo ai clienti di sfruttare EC2 sconti 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 standard di Kubernetes per garantire che ogni EC2 istanza esegua un singolo contenitore 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, pur mantenendo la facilità d'uso EC2 e l'astrazione dalla gestione dell'infrastruttura fornite da Fargate.
Prerequisiti
Prima di iniziare la migrazione, assicurati di
-
Configura un cluster con Fargate. Per ulteriori informazioni, consulta Inizia a usare AWS Fargate per il tuo cluster.
-
Installato e connesso
kubectl
al tuo cluster. Per ulteriori informazioni, consulta Configurazione per l'utilizzo di Amazon EKS.
Fase 1: Controllare il cluster Fargate
-
Controlla 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 <none> 25m v1.30.8-eks-2d5f260 fargate-ip-192-168-98-196.ec2.internal Ready <none> 24m v1.30.8-eks-2d5f260
-
Controlla i pod funzionanti:
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
-
Crea una distribuzione 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 la distribuzione:
kubectl apply -f deployment_fargate.yaml
deployment.apps/nginx-deployment created
-
Controlla i pod e le distribuzioni:
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
-
Controlla 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 <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
Passaggio 2: abilitare la modalità automatica EKS sul cluster
-
Abilita la modalità automatica EKS sul tuo cluster esistente utilizzando la AWS CLI o la console di gestione. Per ulteriori informazioni, consulta Abilita la modalità automatica EKS su un cluster esistente.
-
Controlla il nodepool:
kubectl get nodepool
NAME NODECLASS NODES READY AGE general-purpose default 1 True 6m58s system default 0 True 3d14h
Fase 3: Aggiornamento dei carichi di lavoro per la migrazione
Identifica e aggiorna i carichi di lavoro che desideri migrare alla modalità automatica EKS.
Per migrare un carico di lavoro da Fargate alla modalità automatica 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 Creare un pool di nodi per la modalità automatica EKS.
-
Modifica le tue distribuzioni (ad esempio, il
deployment_fargate.yaml
file) 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
-
Applica la distribuzione. 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 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 <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 la distribuzione sia in esecuzione nei nodi gestiti in modalità automatica EKS:
kubectl get node -owide
NAME 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: Migrazione graduale dei carichi di lavoro
Ripeti il passaggio 3 per ogni carico di lavoro che desideri migrare. 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 migrati tutti i carichi di lavoro, puoi rimuovere il profilo originale. fargate
Sostituisci <fargate profile name>
con il nome del tuo profilo Fargate:
aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --fargate-profile-name <fargate profile name>
Fase 6: Ridimensionamento di CoredNS
Poiché la modalità EKS Auto gestisce CoredNS, puoi ridimensionare coredns
la distribuzione fino a 0:
kubectl scale deployment coredns -n kube-system —replicas=0