Unterstützung für die Verbesserung dieser Seite beitragen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Migration von EKS Fargate zu EKS Auto Mode

In diesem Thema wird der Prozess der Migration von Workloads von EKS Fargate zu Amazon EKS Auto Mode mithilfe von kubectl erläutert Die Migration kann schrittweise durchgeführt werden, sodass Sie Workloads in Ihrem eigenen Tempo verschieben können, während die Cluster-Stabilität und die Verfügbarkeit der Anwendungen während der gesamten Übergangsphase gewährleistet bleiben.

Der unten beschriebene step-by-step Ansatz ermöglicht es Ihnen, EKS Fargate und EKS Auto Mode während des Migrationszeitraums parallel auszuführen. Diese Dual-Betriebsstrategie trägt zu einem nahtlosen Übergang bei, indem sie Ihnen die Möglichkeit bietet, das Workload-Verhalten in EKS Auto Mode zu validieren, bevor Sie EKS Fargate vollständig außer Betrieb nehmen. Sie können Anwendungen einzeln oder in Gruppen migrieren, was Ihnen Flexibilität bietet, um Ihren spezifischen betrieblichen Anforderungen und Ihrer Risikotoleranz gerecht zu werden.

Vergleich von Amazon EKS Auto Mode und EKS mit AWS Fargate

Amazon EKS mit AWS Fargate bleibt eine Option für Kunden, die EKS ausführen möchten, aber Amazon EKS Auto Mode ist in Zukunft der empfohlene Ansatz. EKS Auto Mode ist vollständig Kubernetes-konform und unterstützt alle Upstream-Kubernetes-Primitive und Plattform-Tools wie Istio, die Fargate nicht unterstützen kann. EKS Auto Mode unterstützt außerdem alle EC2-Laufzeit-Kaufoptionen, einschließlich GPU- und Spot Instances, sodass Kunden verhandelte EC2-Rabatte und andere Sparmechanismen nutzen können. Diese Funktionen sind bei Verwendung von EKS mit Fargate nicht verfügbar.

Darüber hinaus können Kunden mit EKS Auto Mode dasselbe Isolationsmodell wie Fargate erzielen, indem sie die Standard-Planungsfunktionen von Kubernetes nutzen, um sicherzustellen, dass jede EC2-Instance einen einzelnen Anwendungs-Container ausführt. Durch die Einführung von Amazon EKS Auto Mode können Kunden alle Vorteile der Ausführung von Kubernetes nutzen AWS — eine vollständig Kubernetes-konforme Plattform, die die Flexibilität bietet, die gesamte Bandbreite von EC2 und Kaufoptionen zu nutzen und gleichzeitig die Benutzerfreundlichkeit und Abstraktion vom Infrastrukturmanagement beizubehalten, die Fargate bietet.

Erzielen einer Fargate-ähnlichen Isolierung im EKS-Automatikmodus

Um das Pod-Isolationsmodell von Fargate zu replizieren, bei dem jeder Pod auf seiner eigenen dedizierten Instanz ausgeführt wird, können Sie Spread-Beschränkungen der Kubernetes-Topologie verwenden. Dies ist der empfohlene Ansatz zur Steuerung der Pod-Verteilung zwischen den Knoten:

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 dieser Konfiguration:

Der automatische Modus von EKS stellt bei Bedarf automatisch neue EC2-Instances bereit, um diese Einschränkung zu erfüllen. Dabei wird dasselbe Isolationsmodell wie Fargate bereitgestellt, Sie haben jedoch Zugriff auf die gesamte Palette der EC2-Instance-Typen und Kaufoptionen.

Alternativ können Sie Pod-Anti-Affinitätsregeln für eine strengere Isolierung verwenden:

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

Die podAntiAffinity Regel mit requiredDuringSchedulingIgnoredDuringExecution stellt sicher, dass keine zwei Pods mit dem Label auf app: isolated-app demselben Knoten geplant werden können. Dieser Ansatz bietet harte Isolationsgarantien, die denen von Fargate ähneln.

Voraussetzungen

Stellen Sie vor Beginn der Migration sicher, dass Sie über Folgendes verfügen:

Schritt 1: Fargate-Cluster überprüfen

Schritt 2: EKS Auto Mode auf dem Cluster aktivieren

Schritt 3: Workloads für die Migration aktualisieren

Identifizieren und aktualisieren Sie die Workloads, die Sie in EKS Auto Mode migrieren möchten.

Um eine Workload von Fargate nach EKS Auto Mode zu migrieren, wenden Sie die Annotation eks.amazonaws.com/compute-type: ec2 an. Dadurch wird sichergestellt, dass die Arbeitslast trotz des Fargate-Profils nicht von Fargate geplant wird, sondern vom EKS-Automatikmodus übernommen wird. NodePool Weitere Informationen finden Sie unter Einen Knotenpool für EKS Auto Mode erstellen.

Schritt 4: Workloads schrittweise migrieren

Wiederholen Sie Schritt 3 für jede Workload, die Sie migrieren möchten. Auf diese Weise können Sie Workloads einzeln oder in Gruppen verschieben, je nach Ihren Anforderungen und Ihrer Risikotoleranz.

Schritt 5: Das ursprüngliche Fargate-Profil entfernen

Sobald alle Workloads migriert wurden, können Sie das ursprüngliche fargate-Profil entfernen. Ersetze es <fargate profile name> durch den Namen deines Fargate-Profils:

aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --fargate-profile-name <fargate profile name>

Schritt 6: CoreDNS herunterskalieren

Da EKS Auto Mode CoreDNS verwaltet, skalieren Sie die coredns-Bereitstellung auf 0 herunter:

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