Share via

Migrieren von Amazon EKS zu Azure Kubernetes Service (AKS)

  • Artikel

Dieser Artikel enthält Strategien für die Migration typischer zustandsloser und statusbasierter Workloads von Amazon EKS zu Azure Kubernetes Service (AKS).

Überlegungen

Der tatsächliche Bereitstellungsprozess eines realen Produktions-Workloads kann in Abhängigkeit von den folgenden Faktoren variieren:

  • Bereitstellungsstrategien: Die Wahl zwischen GitOps und traditionellen DevOps Continuous Integration/Continuous Deployment (CI/CD)-Methoden beeinflusst den Ansatz der Bereitstellung erheblich. GitOps legt den Schwerpunkt auf eine deklarative Infrastruktur, die über versionsbasierte Repositories verwaltet wird, während sich DevOps CI/CD auf automatisierte Workflows für die Anwendungsbereitstellung konzentriert.

  • Bereitstellungsartefakte: Die Auswahl der Bereitstellungsartefakte spielt eine entscheidende Rolle bei der Definition der Bereitstellungsstruktur. YAML-Dateien, Manifestdateien, Helm-Diagramme und Kustomize-Konfigurationen stellen verschiedene Ansätze für die Spezifikation und Anpassung von Bereitstellungseinstellungen dar, die jeweils ihre Stärken und Anwendungsfälle haben.

  • Workload-Authentifizierung und -Autorisierung: Je nach Einrichtung können sich die Authentifizierungs- und Autorisierungsmethoden unterscheiden. Sie können Amazon Web Services (AWS) IAM-Rollen (Identity and Access Management), Workload-Identitätsmechanismen oder Verbindungszeichenfolgen für die Zugriffssteuerung verwenden.

  • Überwachung: Die Implementierung von Überwachungslösungen ist ein wichtiger Aspekt, der verschiedene Tools und Methoden umfassen kann, um die Leistung und den Zustand der bereitgestellten Workloads sicherzustellen. Weitere Informationen darüber, wie die Überwachung von AKS im Vergleich zu EKS aussieht, finden Sie unter Kubernetes-Überwachung und -Protokollierung.

Bevor Sie mit der Migration beginnen, sollten Sie die folgenden allgemeinen Anleitungen und Ressourcen für bewährte Verfahren lesen:

  • Lesen Sie die Bewährten Verfahren für Cluster-Betreiber und Entwickler*in.
  • Definieren Sie die Überwachungs- und Warnhinweis-Strategie, um sicherzustellen, dass die Anwendung wie erwartet funktioniert.
  • Definieren Sie die Sicherheits- und Compliance-Anforderungen für die Anwendung und die AKS-Umgebung.
  • Definieren Sie die Richtlinien zur Zugriffssteuerung und wie sie durchgesetzt werden. Identifizieren Sie alle Compliance-Standards, die eingehalten werden müssen.
  • Definieren Sie den Notfallwiederherstellungs- und Business-Continuity-Plan für die AKS-Umgebung und die Anwendung.
  • Definieren Sie die Richtlinien und Verfahren für die Sicherung und Wiederherstellung. Identifizieren Sie das Recovery Time Objective (RTO) und Recovery Point Objective (RPO).
  • Identifizieren Sie alle Risiken und Herausforderungen, die bei der Bereitstellung auftreten können.
  • Testen Sie die Funktionalität, um sicherzustellen, dass die Anwendung wie erwartet funktioniert, bevor Sie den Datenverkehr auf den neuen AKS-Cluster umleiten.

Überlegungen zur Workload-Migration

In diesem Abschnitt gehen wir auf einige Dinge ein, die Sie vor der Migration Ihrer Workloads von Amazon EKS zu AKS beachten sollten.

Überblick über Ihre bestehende Amazon EKS-Umgebung

Analysieren Sie die bestehende EKS-Umgebung, um die aktuelle Architektur, Ressourcen und Konfigurationen zu erfassen.

  • Prüfen Sie die EKS-Konfiguration: Nehmen Sie eine Bestandsaufnahme der EKS-Cluster-Konfiguration vor, wie z. B. Knotentypen, Anzahl der Knoten, Kubernetes-Version und Support-Richtlinie und Skalierungskonfiguration.

    Hinweis

    EKS ermöglicht die Erstellung von angepassten AMI-Images für EKS-Knoten. AKS bietet keine Möglichkeit, angepasste Images für Knoten zu verwenden. Wenn Ihre Bereitstellung eine Anpassung der Knoten erfordert, können Sie die kubelet-Anpassung und/oder DaemonSets anwenden, um Ihre Knoten anzupassen.

  • Überprüfen Sie die Anwendungs-Workloads: Identifizieren Sie alle Kubernetes-Workloads, die auf dem EKS-Cluster ausgeführt werden, einschließlich Bereitstellungen, Diensten, statusbasierten Sets, Ingress-Konfigurationen und persistenten Volumes. Stellen Sie sicher, dass Sie eine vollständige Liste der Anwendungen und der zugehörigen Ressourcen haben.

  • Überprüfen Sie die Abhängigkeiten: Identifizieren Sie alle Abhängigkeiten von AWS-Diensten, die speziell für EKS gelten.

    AWS-Dienst Abhängigkeit
    AWS Secret Manager Azure Key Vault
    AWS Guard Duty Agent Microsoft Defender für Container
    EKS Pod Identity Agent Microsoft Entra ID-Workload-Identität
    Amazon Elastic File System (EFS) oder Elastic Block Store (EBS) Container Storage Interface (CSI) Treiber AKS CSI-Treiber

  • Sicherung des EKS-Clusters: Sie können ein nicht von Microsoft stammendes Tool wie Velero verwenden, um Kubernetes-Ressourcen und persistente Volumes zu sichern und zu migrieren.

Vorbereiten der AKS-Umgebung

Das Amazon Virtual Private Cloud (VPC) Container Networking Interface (CNI) ist das standardmäßige Networking-Plugin, das von EKS unterstützt wird. Ein AKS-Cluster unterstützt mehrere Networking-Plugins und -Methoden, um einen Cluster in einem virtuellen Netzwerk bereitzustellen, darunter:

Um Ihren AKS-Cluster vorzubereiten, gehen Sie folgendermaßen vor:

  1. Erstellen Sie einen neuen AKS-Cluster in Azure, und konfigurieren Sie die gewünschten Networking-Einstellungen, die Ihren Anforderungen entsprechen.
  2. Überprüfen Sie Ihre Kubernetes-Manifeste und YAML-Dateien, die in EKS verwendet werden. Prüfen Sie, ob es möglicherweise Inkompatibilitäten mit der Kubernetes-API-Version oder bestimmte EKS-Konfigurationen gibt, die von AKS nicht unterstützt werden.
  3. Stellen Sie sicher, dass Ihre Docker-Images und der Speicherort der Container-Image-Registry vom AKS-Cluster aus zugänglich sind. Überprüfen Sie die Netzwerkkonnektivität und alle erforderlichen Authentifizierungs- und Autorisierungseinstellungen für den Zugriff auf die Images.

Wenn Sie diese Schritte befolgen, können Sie erfolgreich einen AKS-Cluster erstellen und die Kompatibilität Ihrer Kubernetes-Manifeste und Docker-Images sicherstellen, was einen reibungslosen Migrationsprozess von EKS zu AKS gewährleistet.

Übersicht zur Migration

Die Migration von Amazon EKS zu AKS umfasst mehrere Schritte, wie z. B.:

  • Migration von Container-Images: Die Migration von Container-Images ist ein entscheidender Schritt beim Wechsel von EKS zu AKS. Sie können Tools wie kubectl, Docker oder Container-Registries verwenden, um Images zu exportieren und zu importieren.

    1. Images aus EKS exportieren.
    2. Richten Sie eine Azure Container Registry ein, und weisen Sie sie AKS zu, falls Sie das noch nicht getan haben.
    3. Pushen Sie Images in die Container-Registry.

    Container-Images können auch direkt von einem öffentlichen oder privaten Repository, das nicht zu Azure gehört, in die Container-Registry importiert werden. Weitere Informationen finden Sie unter Importieren von Container-Images.

  • Kubernetes-Manifest-Migration: AKS verwendet das Kubernetes-YAML-Datei-Manifest, um Kubernetes-Objekte zu definieren. Bereitstellungen werden normalerweise mit kubectl create oder kubectl apply erstellt und verwaltet. Erstellen Sie eine Bereitstellung, indem Sie eine Manifestdatei im YAML-Format definieren. Weitere Informationen finden Sie in diesem Beispiel zu einem AKS-Manifest. Mehr über die Funktionsweise von YAML-Dateien in Kubernetes erfahren Sie unter Bereitstellungen und YAML-Manifeste.

  • Datenmigration: Planen Sie die Migration von statusbasierten Anwendungen sorgfältig, um Datenverluste oder unerwartete Ausfallzeiten zu vermeiden. Weitere Informationen finden Sie im Abschnitt Überlegungen zur Migration statusbasierter Workloads.

Überlegungen zur Migration zustandsloser Workloads

Die Migration Ihrer Kubernetes-Manifeste beinhaltet die Anpassung der Konfiguration an die Umgebung von Azure, einschließlich dieser Schritte:

  1. Manifeste aktualisieren: Aktualisieren Sie Ihre Kubernetes-Manifeste, damit sie die neuen Speicherorte der Images in der Container-Registry verwenden. Ersetzen Sie die Image-Verweise in Ihren YAML-Dateien durch den Pfad in der Container-Registry.

    1. Überprüfen Sie Ihre bestehenden Kubernetes-Manifestdateien auf AWS-spezifische Konfigurationen, wie VPC- und IAM-Rollen.
    2. Überprüfen Sie die EKS-IAM-Rollen, die mit Knoten, Dienstkonten und anderen Ressourcen verbunden sind. Ordnen Sie sie den entsprechenden AKS-Rollen für die rollenbasierten Zugriffssteuerungen (RBAC) zu. Weitere Informationen finden Sie unter Kubernetes-Workload-Identität und -Zugriff.
    3. Ändern Sie die Manifestdateien, um AWS-spezifische Einstellungen durch Azure-spezifische Einstellungen, wie Anmerkungen, zu ersetzen.

  2. Wenden Sie Manifeste auf AKS an:

    1. Verbinden Sie sich mit dem AKS-Cluster.
    2. Wenden Sie die geänderten Kubernetes-Manifestdateien mit kubectl apply -f an.

Überlegungen zur Migration von statusbasierten Workloads

Wenn Ihre Anwendungen Persistent Volumes (PVs) oder Persistent Volume Claims (PVCs) für die Datenspeicherung verwenden, stellen Sie sicher, dass Sie diese Daten sichern. Sie können Tools wie Velero verwenden, um Cluster-Sicherungen durchzuführen, auch für PVs und PVCs Daten. Weitere Informationen finden Sie unter Sicherung und Wiederherstellung Ihrer Amazon-EKS-Cluster-Ressourcen mit Velero.

Statusbasierte Anwendungen benötigen in der Regel einen persistenten Speicher, was den Migrationsprozess komplexer macht. Einen Vergleich der Funktionalitäten für Speicher von Amazon EKS und AKS finden Sie unter Speicheroptionen für einen Kubernetes-Cluster.

Folgen Sie diesen Schritten, um persistente Daten zu sichern:

  1. Richten Sie Velero im AKS- und EKS-Cluster ein.
  2. Führen Sie eine Sicherung Ihres EKS-Clusters durch.
  3. Kopieren Sie die Sicherung von Velero aus dem S3-Bucket in Azure Blob Storage, indem Sie den Befehl az copy verwenden.
  4. Da AKS und EKS möglicherweise unterschiedliche storageClassNames für die Claims der persistenten Volumes verwenden, erstellen Sie ein configMap, das die Quelle storageClassNames in einen AKS-kompatiblen Klassennamen übersetzt. Sie können diesen Schritt ignorieren, wenn Sie auf dem EKS- und dem AKS-Kubernetes-Cluster die gleiche Speicherlösung verwenden.
  5. Stellen Sie die Sicherung in AKS wieder her (mit dem Befehl Velero restore).
  6. Nehmen Sie die notwendigen Änderungen an den wiederhergestellten Objekten vor, z. B. Verweise auf Container-Images in Amazon Elastic Container Registry (ECR) oder Zugriff auf Secrets.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

  • Dixit Arora | Senior Customer Engineer, ISV DN CoE
  • Ketan Chawda | Senior Customer Engineer, ISV DN CoE

Andere Mitwirkende:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte