Verwaltete Steuerungsebene für Bestandskunden

Dieses Dokument richtet sich an bestehende Anthos Service Mesh-Kunden, die die verwaltete Steuerungsebene oder die clusterinterne Steuerungsebene verwenden. In diesem Dokument wird die Implementierung Ihrer Steuerungsebene und die mögliche Migration Ihrer Steuerungsebene beschrieben.

Wenn Sie bereits Traffic Director-Kunde sind oder neu dazugekommen sind, müssen Sie dieses Dokument nicht lesen.

Steuerungsebene – Übersicht

In Service Meshes bietet die Steuerungsebene die Traffic-Verwaltung, die Proxy-Verwaltung, wenn der Envoy-Proxy verwendet wird, und andere Netzwerkfunktionen.

Anthos Service Mesh bot zwei Steuerungsebenen: eine verwaltete Steuerungsebene und eine clusterinterne Steuerungsebene. Als Datenebene werden nur Envoy-Proxys verwendet.

Neue verwaltete Steuerungsebene

Die neue verwaltete Steuerungsebene wird als Traffic Director-Implementierung (TD) bezeichnet. Was bedeutet die neue Steuerungsebene für Sie?

Eine der wichtigsten Änderungen vom Anthos Service Mesh-Produkt zu Cloud Service Mesh ist die Umstellung auf eine mehrmandantenfähige, globale Steuerungsebene.

Die in Anthos Service Mesh verwendete verwaltete Steuerungsebene ist für einen einzelnen Cluster vorgesehen. Obwohl die für GKE verwendeten APIs (Istio CRDs) identisch sind und die an die Sidecars gesendete xDS-Konfiguration ohne Verhaltensunterschiede kompatibel ist, führen die Unterschiede in der Steuerungsebene zu einigen Merkmalen, die für Sie als Endnutzer sichtbar sind.

  • Antwortzeit bei Konfigurationsänderungen Neue Dienstbereitstellungen oder Änderungen an Dienstrichtlinien dauern mit der neuen Steuerungsebene etwas länger.
    • Die Konfigurationspipeline führt aus Gründen der Zuverlässigkeit einen Konfigurationscommit mit zwei Durchgängen aus. Beim ersten Durchlauf werden Validierungen durchgeführt, um zu prüfen, ob die Konfiguration korrekt formatiert ist. In der nächsten Phase wird die Konfiguration global auf Ihre Dienstbereitstellungen angewendet. Damit Google Cloud-Dienste wie globales zonen- oder regionsübergreifendes Load Balancing, zentrale Systemdiagnose, verkehrsabhängiges Autoscaling und verwaltete Ratenbeschränkung verwendet werden können, wird die Konfiguration an diese Systeme übertragen und unabhängig auf Richtigkeit überprüft. Die Konfiguration wird auch intern so gespeichert, dass das Site Reliability Engineering-Team von Google bei Produktionsnotfällen zuverlässig und effizient Produktabläufe durchführen kann.
    • Diese Vorgänge bieten eine bessere Zuverlässigkeit, führen aber zu einem Konfigurationspush, der langsamer ist als die Latenz, die aktuelle Nutzer von Anthos Service Mesh beobachten.
    • Die Latenz, mit der ein neuer Pod die vorhandene Konfiguration abrufen kann, ist mit der neuen Steuerungsebene etwas besser. Der langsame Konfigurationspush dient der Erstübertragung aller neu erstellten Dienste oder neuer Richtlinien, die für den Dienst gesendet wurden. Die Latenzen bei der Endpunktweitergabe sind funktional ähnlich.
  • Geschwindigkeit von Skalierungsereignissen und anderen Änderungen an den Endpunkten Diese werden mit der neuen Steuerungsebene mindestens genauso schnell verarbeitet. Dazu gehören neue Pods, die aufgrund des horizontalen Pod-Autoscalings gestartet oder angehalten werden, und Pods, die mit neuen IP-Adressen neu gestartet werden, weil sie an einen anderen Knoten im Cluster verschoben wurden.
  • Anzahl der Endpunkte skalieren Mit der neuen globalen Steuerungsebene werden die Endpunkte des Mesh von allen Clustern im Mesh direkt von jedem Cluster an die Steuerungsebene gesendet. Dies ist ein einfacherer, schnellerer und skalierbarerer Ansatz als der der vorherigen verwalteten Steuerungsebene. Beim älteren Modell der verwalteten Steuerungsebene (dedizierte Steuerungsebene) muss jeder Istiod mit jedem anderen Cluster im Mesh kommunizieren, um die in jedem anderen Cluster verfügbaren Endpunkte zu ermitteln. Bei der globalen Steuerungsebene werden die Endpunkte direkt an die globale Steuerungsebene übertragen. Dies führt zu einer besseren Zuverlässigkeit und Leistung in Meshes mit einer großen Anzahl von Endpunkten und ermöglicht es, die Meshes auf eine größere Anzahl von Endpunkten zu skalieren.

Welche Auswirkungen hat die neue Steuerungsebene auf Sie?

Wie sich die neue Steuerungsebene auf Sie auswirkt, hängt von den von Ihnen verwendeten APIs und der Steuerungsebene ab.

  • Wenn Sie Traffic Director verwenden, bleibt Ihre Steuerungsebene unverändert. Sie müssen den Rest dieses Leitfadens nicht lesen. Die Dokumentation für Ihre Cloud Service Mesh-Implementierung finden Sie unter Mit Google Cloud APIs konfigurieren.
  • Wenn Sie Anthos Service Mesh verwenden, hängen die nächsten Schritte für die Steuerungsebene in Ihrer vorhandenen Bereitstellung davon ab, ob Sie die verwaltete Steuerungsebene oder die clusterinterne Steuerungsebene verwenden.
    • Wenn Sie die verwaltete Steuerungsebene verwenden, werden Ihre vorhandenen Flotten mit einigen Ausnahmen zur neuen Steuerungsebene migriert, die in Cloud Service Mesh als verwaltete Steuerungsebene (Traffic Director-Implementierung) bezeichnet wird. Weitere Informationen finden Sie im folgenden Abschnitt Steuerungsebene für vorhandene Meshes und Flotten migrieren. Wenn Sie eine Funktion verwenden, die von der Traffic Director-Steuerungsebene nicht unterstützt wird, bleiben Sie vorübergehend bei der vorherigen Steuerungsebene. Lesen Sie diese Anleitung weiter.
    • Wenn Sie die clusterinterne Steuerungsebene verwenden, bleibt sie unverändert. Sie müssen den Rest dieses Leitfadens nicht lesen.
    • Wenn Sie keine Google Cloud-Organisation haben und die verwaltete Steuerungsebene in einem organisationslosen Projekt verwenden, erhalten Sie die TD-Steuerungsebene.
  • Wenn Sie Anthos Service Mesh-Kunde sind und neue Flotten erstellen, erhalten Sie die Traffic Director-Steuerungsebene. Lesen Sie diesen Leitfaden weiter.
    • Sie werden über das Datum informiert, an dem neue Flotten die TD-Steuerungsebene erhalten.

Migration der Steuerungsebene für vorhandene Meshes und Flotten

Ab dem 22. Juli 2024 aktualisiert Google vorhandene Cluster schrittweise, um die verwaltete Steuerungsebene mit TD-Implementierung zu verwenden. Sie werden benachrichtigt, bevor wir Ihre 3D‑Modelle aktualisieren.

Die Funktionen der Istiod- und Traffic Director-Steuerungsebenen finden Sie auf der Seite Unterstützte Funktionen mit Istio APIs (verwaltete Steuerungsebene).

Sie sollten mindestens zwei Wochen vor der Aktualisierung benachrichtigt werden, dass ein Cluster aktualisiert werden soll. Benachrichtigungen sind in den Bedingungen für den Feature-Status auf Clusterebene verfügbar.

Verwenden Sie den folgenden Google Cloud CLI-Befehl, um die Benachrichtigung zu prüfen:

gcloud container hub mesh describe --project=[PROJECT_ID]

Die Ergebnisse sollten in etwa so aussehen:

membershipStates:
  projects/656460026795/locations/us-central1/memberships/cluster:
    servicemesh:
      conditions:
      - code: MODERNIZATION_SCHEDULED
        details: This cluster has been scheduled for modernization on or after (date ~ at least 2 weeks).
        documentationLink: 
        severity: INFO

Alle mit der meshconfig.googleapis.com API verwalteten Cluster der alten Steuerungsebene, die über die gkehub.googleapis.com Membership API eingerichtet wurden, werden automatisch in der Flotte des Projekts des Clusters registriert. Wenn Sie eine Automatisierung haben, die einen Cluster abmeldet, müssen Sie sie vor der Migration entfernen, da sonst Probleme auftreten. Damit das verwaltete Produkt funktioniert, muss es in einer Flotte registriert sein, in der die Mesh-Funktion aktiviert ist.

Wenden Sie sich an den Support, wenn Sie Ihre Migration anpassen möchten oder Fragen dazu haben, ob Sie nicht unterstützte Funktionen verwenden.

Während der Migration werden die folgenden Änderungen auf sichere und kontrollierte Weise vorgenommen:

  • Um die Systemdiagnose zu aktivieren, wird der snk-Daemonset im Namespace kube-system des Clusters erstellt und eine Cluster-Firewallregel wird erstellt.
  • Um die Aufnahme von Netzwerk-Endpunktgruppen (NEGs) zu aktivieren, wird allen Kubernetes-Diensten die Anmerkung cloud.google.com/neg hinzugefügt.
  • Im Cluster werden neue Google Cloud-Ressourcen wie Mesh, Routes, Backenddienste und Überprüfungen der Systemintegrität erstellt.
  • Von Kubernetes-Deployments verwaltete Pods werden neu gestartet, um eine Verbindung zur Traffic Director-Steuerungsebene wiederherzustellen.

Einige der neuen Ressourcen sind kontingentiert. Sie können Ihre Kontingente einsehen und bei Bedarf mehr anfordern.

Kompatibilität der Steuerungsebene prüfen

Sehen Sie sich die Unterschiede bei den unterstützten Funktionen zwischen den Implementierungen der verwalteten Steuerungsebene an, um festzustellen, ob Änderungen an Ihrer aktuellen Nutzung von Cloud Service Mesh erforderlich sind.

Steuerungsebene für neue Meshes

Ab dem 1. Juli 2024 erhalten die meisten Nutzer der verwalteten istiod-Steuerungsebene die aktualisierte verwaltete Steuerungsebene mit der weltweit verfügbaren Implementierung von Google – der Traffic Director-Steuerungsebene (TD) – in neuen Flotten.

Nutzer, deren bestehende Nutzung des verwalteten Cloud Service Mesh mit der istiod-Steuerungsebenenimplementierung nicht ohne Änderungen mit der Traffic Director-Implementierung kompatibel ist, erhalten die istiod-Implementierung bis zum 8. September 2024 weiter. Wenn dies auf Ihre Organisation zutrifft, haben Sie eine Servicemitteilung erhalten.

Wenn Sie eine neue Flotte in Cloud Service Mesh aufnehmen und diese Flotte sich nicht in einer Google Cloud-Organisation oder in einer neuen Google Cloud-Organisation befindet, erhalten Sie die neue verwaltete Steuerungsebene mit der TD-Implementierung ab dem Einführungsdatum von Cloud Service Mesh.

Nächste Schritte

  • Wenn Sie Anthos Service Mesh weiterhin nutzen, finden Sie die entsprechende Dokumentation im linken Inhaltsverzeichnis unter Service Mesh mit Istio APIs konfigurieren.
  • Wenn Sie bereits Traffic Director-Kunde sind, finden Sie die entsprechende Dokumentation unter Service Mesh mit Google Cloud APIs konfigurieren.