**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:
+ `maxSkew: 1`stellt sicher, dass der Unterschied in der Anzahl der Pods zwischen zwei beliebigen Knoten höchstens 1 beträgt, wodurch effektiv ein Pod pro Knoten verteilt wird
+ `topologyKey: kubernetes.io/hostname`definiert den Knoten als Topologiedomäne
+ `whenUnsatisfiable: DoNotSchedule`verhindert die Terminplanung, wenn die Einschränkung nicht eingehalten werden kann
+ `minDomains: 1`stellt vor der Planung sicher, dass mindestens eine Domäne (ein Knoten) vorhanden ist
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:
+ Richten Sie einen Cluster mit Fargate ein. Weitere Informationen finden Sie unter [Beginnen Sie mit AWS Fargate für Ihren Cluster](fargate-getting-started.md).
+ Installiert und `kubectl` mit Ihrem Cluster verbunden. Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md).
## Schritt 1: Fargate-Cluster überprüfen
1. Ausführung der EKS-Cluster mit Fargate überprüfen:
```
kubectl get node
```
```
NAME STATUS ROLES AGE VERSION
fargate-ip-192-168-92-52.ec2.internal Ready 25m v1.30.8-eks-2d5f260
fargate-ip-192-168-98-196.ec2.internal Ready 24m v1.30.8-eks-2d5f260
```
1. Ausgeführte Pods überprüfen:
```
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
```
1. Bereitstellung in einer Datei mit dem Namen `deployment_fargate.yaml` erstellen:
```
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
```
1. Bereitstellung durchführen:
```
kubectl apply -f deployment_fargate.yaml
```
```
deployment.apps/nginx-deployment created
```
1. Pods und Bereitstellungen überprüfen:
```
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
```
1. Knoten überprüfen:
```
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 31s v1.30.8-eks-2d5f260 192.168.111.43 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-117-130.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.117.130 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-74-140.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.74.140 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
```
## Schritt 2: EKS Auto Mode auf dem Cluster aktivieren
1. Aktivieren Sie den EKS-Automatikmodus auf Ihrem vorhandenen Cluster mithilfe der AWS CLI oder der Managementkonsole. Weitere Informationen finden Sie unter [Aktivierung von EKS Auto Mode in einem vorhandenen Cluster](auto-enable-existing.md).
1. Knoten-Pool überprüfen:
```
kubectl get nodepool
```
```
NAME NODECLASS NODES READY AGE
general-purpose default 1 True 6m58s
system default 0 True 3d14h
```
## 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](create-node-pool.md).
1. Ändern Sie Ihre Bereitstellungen (beispielsweise die `deployment_fargate.yaml`-Datei), um den Rechentyp auf `ec2` umzustellen:
```
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
```
1. Wenden Sie die Bereitstellung an. Durch diese Änderung kann die Workload auf den neuen EKS-Auto–Mode-Knoten geplant werden:
```
kubectl apply -f deployment_fargate.yaml
```
1. Überprüfen Sie, ob die Bereitstellung im EKS-Auto-Mode-Cluster ausgeführt wird:
```
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
nginx-deployment-97967b68d-mbcgj 1/1 Running 0 2m37s 192.168.43.241 i-0845aafcb51630ffb
nginx-deployment-97967b68d-qpd8x 1/1 Running 0 2m35s 192.168.43.242 i-0845aafcb51630ffb
```
1. Überprüfen Sie, ob kein Fargate-Knoten ausgeführt wird und keine Bereitstellung in den verwalteten Knoten in EKS Auto Mode ausgeführt wird:
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
i-0845aafcb51630ffb Ready 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
```
## 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 ** durch den Namen deines Fargate-Profils:
```
aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --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
```