Migration von Istio vorbereiten

Die Migration von Istio zu Anthos Service Mesh erfordert eine gewisse Planung. Auf dieser Seite finden Sie Informationen, die Ihnen bei der Vorbereitung auf die Migration helfen.

Profile überprüfen

Die von Anthos Service Mesh bereitgestellten Konfigurationsprofile unterscheiden sich vom Open-Source-Framework Istio. Bei der Installation von Anthos Service Mesh wird ein Konfigurationsprofil verwendet, das für Ihre Umgebung geeignet ist:

  • asm-gcp: Verwenden Sie dieses Profil für Installationen in GKE für ein Mesh-Netzwerk, das entweder einen einzelnen Cluster oder mehrere Cluster im selben Google Cloud-Projekt enthält.

  • asm-gcp-multiproject Beta: Verwenden Sie dieses Profil für Installationen in GKE mit Clustern in verschiedenen Google Cloud-Projekten.

  • asm-multicloud: Verwenden Sie dieses Profil für Installationen in den folgenden Umgebungen.

    • GKE on VMware
    • GKE on AWS
    • Amazon Elastic Kubernetes Service (Amazon EKS)
    • Microsoft Azure Kubernetes Service (Microsoft AKS)

Die unterstützten Anthos Service Mesh-Features unterscheiden sich je nach Profil. Sehen Sie sich die unterstützten Funktionen des Profils an, das für Ihre Konfiguration geeignet ist.

Profile vergleichen

Sie können das Konfigurationsprofil, mit dem Sie Istio installiert haben, mit dem Anthos Service Mesh-Profil vergleichen, das Sie verwenden möchten:

  1. Folgen Sie den Schritten unter Installationsdatei herunterladen, um die Installations- und Signaturdateien herunterzuladen, den Inhalt zu extrahieren und den Pfad so festzulegen, dass aus der Downloaddatei die Version istioctl verwendet wird.

  2. Generieren Sie ein Manifest für das Anthos Service Mesh-Profil, das Sie verwenden möchten:

    istioctl manifest generate -f manifests/profiles/ASM_PROFLE > a.yaml

  3. Suchen Sie das Profil, mit dem Sie Istio installiert haben. Da Profile je nach Istio-Version wechseln können, benötigen Sie das Profil aus dem Installationspaket, das Ihrer Version von Istio entspricht.

  4. Generieren Sie ein Manifest für das Profil, mit dem Sie Istio installiert haben:

    istioctl manifest generate -f ISTIO_PROFILE > b.yaml

  5. Vergleichen Sie die Manifeste:

    istioctl manifest diff a.yaml b.yaml

Konfigurationsdateien vorbereiten

Wenn Sie die Istio-Installation angepasst haben, müssen Sie für die Migration zu Anthos Service Mesh die gleichen Anpassungen vornehmen. Wenn Sie die Installation durch Anfügen des Flags --set values angepasst haben, empfehlen wir, dass Sie diese Einstellungen einer IstioOperator-Konfigurationsdatei hinzufügen. Sie geben die Konfigurationsdatei an, indem Sie beim Ausführen des Befehls istioctl install das Flag -f zusammen mit der Konfigurationsdatei verwenden.

Zertifizierungsstelle auswählen

Sie können für das Ausstellen gegenseitiger TLS-Zertifikate (mTLS) weiterhin Citadel (jetzt in istiod eingebunden) als Zertifizierungsstelle (Certificate Authority, CA) verwenden oder Sie können zur Anthos Service Mesh-Zertifizierungsstelle (Mesh-CA) migrieren.

Im Allgemeinen empfehlen wir, Mesh-CA zu verwenden, denn:

  • Mesh CA ist ein zuverlässiger und skalierbarer Dienst, der für dynamisch skalierte Arbeitslasten in Google Cloud optimiert ist.
  • Mit Mesh CA verwaltet Google die Sicherheit und Verfügbarkeit des CA-Back-Ends.
  • Mesh CA ermöglicht es Ihnen, sich für alle Cluster auf eine einzige Root of Trust zu verlassen.

In einigen Fällen ist es jedoch ratsam, Citadel zu verwenden. Hier einige Beispiele:

  • Mit einer benutzerdefinierten Zertifizierungsstelle.
  • Sie können keine Ausfallzeiten für die Migration zu Mesh-CA planen. Obwohl wir die Verwendung von Mesh-CA empfehlen, müssen Sie für die Migration eine Ausfallzeit einplanen, da mTLS-Traffic fehlschlägt, bis Sie alle Pods in allen Namespaces neu starten.

Migrationsprozess überprüfen

Folgen Sie für die Migration von Istio dem Upgradeprozess für die duale Steuerungsebene (in der Istio-Dokumentation als Canary-Upgrades bezeichnet). Mit einem Upgrade der dualen Steuerungsebene installieren Sie eine neue Version der Steuerungsebene neben der vorhandenen Steuerungsebene. Fügen Sie bei der Installation der neuen Version das Label revision ein, das die Version der neuen Steuerungsebene angibt. Jede Überarbeitung ist eine vollständige Implementierung der Anthos Service Mesh-Steuerungsebene mit eigenem Deployment und Dienst.

Anschließend migrieren Sie zur neuen Version. Legen Sie dazu für Ihre Arbeitslasten dasselbe revision-Label fest, das auf die neue Steuerungsebene verweist, und führen Sie einen rollierenden Neustart durch, um die neue Anthos Service Mesh-Version in die Proxys einzufügen. Bei diesem Ansatz können Sie die Auswirkungen des Upgrades auf einen kleinen Prozentsatz Ihrer Arbeitslasten überwachen. Nachdem Sie Ihre Anwendung getestet haben, können Sie den gesamten Traffic zur neuen Version migrieren. Dieser Ansatz ist wesentlich sicherer als ein direktes Upgrade, bei dem eine neue Steuerungsebene die vorherige Version der Steuerungsebene ersetzt.

Wenn Sie für Blau/Grün-Bereitstellungen keinen Load-Balancer oder Router eingerichtet haben, empfehlen wir Ihnen, die Migration zu testen und Pods in einer Staging-Umgebung neu zu starten. So lässt sich überprüfen, ob Ihre Dienste eine mögliche Unterbrechung von Traffic verarbeiten können.