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:

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:

Fase 1: Verificare il cluster Fargate

Fase 2: Abilitare modalità automatica di EKS sul cluster

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.

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 tuo 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é modalità automatica di EKS gestisce CoreDNS, puoi ridurre verticalmente l’implementazione coredns fino a 0:

kubectl scale deployment coredns -n kube-system —-replicas=0