**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.

# Aktivierung von EKS Auto Mode in vorhandenen EKS-Clustern
<a name="migrate-auto"></a>

Sie können EKS Auto Mode in vorhandenen EKS-Clustern aktivieren.

 ** AWS unterstützt die folgenden Migrationen:** 
+ Migration von Karpenter zu Knoten in EKS Auto Mode. Weitere Informationen finden Sie unter [Migration von Karpenter zu EKS Auto Mode mithilfe von kubectl](auto-migrate-karpenter.md).
+ Migration von EKS-verwalteten Knotengruppen zu Knoten in EKS Auto Mode. Weitere Informationen finden Sie unter [Migration von EKS-verwalteten Knotengruppen zu EKS Auto Mode](auto-migrate-mng.md).
+ Migration von EKS Fargate zu EKS Auto Mode. Weitere Informationen finden Sie unter [Migration von EKS Fargate zu EKS Auto Mode](auto-migrate-fargate.md).

 ** AWS unterstützt die folgenden Migrationen nicht:** 
+ Migration von Volumes vom EBS CSI-Controller (mithilfe des Amazon EKS-Add-ons) zum EKS Auto Mode EBS CSI-Controller (verwaltet von EKS Auto Mode). PVCs Die Daten, die mit einem erstellt wurden, können nicht vom anderen bereitgestellt werden, da sie zwei verschiedene Kubernetes-Volume Provisioner verwenden.
  + Das [https://github.com/awslabs/eks-auto-mode-ebs-migration-tool](https://github.com/awslabs/eks-auto-mode-ebs-migration-tool)(AWS Labs-Projekt) ermöglicht die Migration zwischen Standard-EBS CSI StorageClass (`ebs.csi.aws.com`) und EKS Auto EBS CSI (). StorageClass `ebs.csi.eks.amazonaws.com` Beachten Sie, dass für die Migration das Löschen und Neuerstellen vorhandener PersistentVolumeClaim/PersistentVolume Ressourcen erforderlich ist. Daher ist vor der Implementierung eine Validierung in einer Umgebung außerhalb der Produktion unerlässlich.
+ Migration von Load Balancers vom Load AWS Balancer Controller in den EKS-Automatikmodus

  Sie können den Load AWS Balancer Controller auf einem Amazon EKS Auto Mode-Cluster installieren. Verwenden Sie die Optionen `IngressClass` oder `loadBalancerClass`, um Service- und Ingress-Ressourcen entweder dem Load Balancer Controller oder EKS Auto Mode zuzuordnen. Eine präskriptive Anleitung finden Sie unter [https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-nginx-ingress-controller-eks-auto-mode.html) 
+ Migration von EKS-Clustern mit alternativen CNIs oder anderen nicht unterstützten Netzwerkkonfigurationen

## Migrationsreferenz
<a name="migration-reference"></a>

Verwenden Sie die folgende Migrationsreferenz, um Kubernetes-Ressourcen so zu konfigurieren, dass sie entweder selbstverwalteten Controllern oder EKS Auto Mode zugeordnet sind.


| Funktion | Ressource | Feld | Selbstverwaltet | EKS Auto Mode | 
| --- | --- | --- | --- | --- | 
|  Blockspeicher  |   `StorageClass`   |   `provisioner`   |   `ebs.csi.aws.com`   |   `ebs.csi.eks.amazonaws.com`   | 
|  Lastausgleich  |   `Service`   |   `loadBalancerClass`   |   `service.k8s.aws/nlb`   |   `eks.amazonaws.com/nlb`   | 
|  Lastausgleich  |   `IngressClass`   |   `controller`   |   `ingress.k8s.aws/alb`   |   `eks.amazonaws.com/alb`   | 
|  Lastausgleich  |   `IngressClassParams`   |   `apiversion`   |   `elbv2.k8s.aws/v1beta1`   |   `eks.amazonaws.com/v1`   | 
|  Lastausgleich  |   `TargetGroupBinding`   |   `apiversion`   |   `elbv2.k8s.aws/v1beta1`   |   `eks.amazonaws.com/v1`   | 
|  Datenverarbeitung  |   `NodeClass`   |   `apiVersion`   |   `karpenter.sh/v1`   |   `eks.amazonaws.com/v1`   | 

## Migration von EBS-Volumes
<a name="_migrating_ebs_volumes"></a>

Bei der Migration von Workloads in EKS Auto Mode ist es aufgrund unterschiedlicher CSI-Treiber-Bereitsteller erforderlich, die Migration von EBS-Volumes zu berücksichtigen:
+ EKS-Auto-Mode-Bereitsteller: `ebs.csi.eks.amazonaws.com` 
+ Open-Source-EBS-CSI-Bereitsteller: `ebs.csi.aws.com` 

Führen Sie die folgenden Schritte aus, um Ihre persistenten Volumes zu migrieren:

1.  **Volume-Aufbewahrungsrichtlinie ändern**: Ändern Sie die vorhandenen Plattformversionen (PVs) `persistentVolumeReclaimPolicy` in `Retain`, um sicherzustellen, dass das zugrunde liegende EBS-Volume nicht gelöscht wird.

1.  **PV aus Kubernetes entfernen**: Löschen Sie die alte PV-Ressource, während das aktuelle EBS-Volume erhalten bleibt.

1.  **Neue PV mit statischer Bereitstellung erstellen**: Erstellen Sie eine neue PV, die auf dasselbe EBS-Volume verweist, jedoch mit dem Ziel-CSI-Treiber funktioniert.

1.  **An ein neues PVC binden**: Erstellen Sie ein neues PVC, die mithilfe des Feldes `volumeName` speziell auf Ihre PV verweist.

### Überlegungen
<a name="_considerations"></a>
+ Stellen Sie sicher, dass Ihre Anwendungen beendet sind, bevor Sie mit dieser Migration beginnen.
+ Sichern Sie Ihre Daten, bevor Sie mit dem Migrationsprozess beginnen.
+ Dieser Vorgang muss für jedes persistente Volume durchgeführt werden.
+ Die Workload muss aktualisiert werden, um das neue PVC zu verwenden.

## Migration von Load Balancern
<a name="_migrating_load_balancers"></a>

Sie können vorhandene Load Balancer nicht direkt vom selbstverwalteten AWS Load Balancer-Controller in den EKS-Automatikmodus übertragen. Stattdessen müssen Sie eine Blau-Grün-Bereitstellungsstrategie implementieren. Dabei wird die vorhandene Load-Balancer-Konfiguration beibehalten, während neue Load Balancer unter dem verwalteten Controller erstellt werden.

Um Service Unterbrechungen zu minimieren, empfehlen wir einen DNS-basierten Ansatz zur Datenverkehrsverlagerung. Erstellen Sie zunächst neue Load Balancer in EKS Auto Mode, während Ihre vorhandene Konfiguration betriebsbereit bleibt. Verwenden Sie anschließend DNS-Routing (z. B. Route 53), um den Datenverkehr schrittweise von den alten Load Balancern auf die neuen umzuleiten. Sobald der Datenverkehr erfolgreich migriert wurde und Sie die neue Konfiguration überprüft haben, können Sie die alten Load Balancer und den selbstverwalteten Controller außer Betrieb nehmen.