Verwaltete Steuerungsebene für Bestandskunden

Dieses Dokument richtet sich an Sie, wenn Sie weiterhin Anthos Service Mesh-Kunde sind über die verwaltete oder clusterinterne Steuerungsebene. Dieses Dokument wird die Implementierung der Steuerungsebene und die mögliche Migration Steuerungsebene.

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

Übersicht über die Steuerungsebene

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 an: eine verwaltete Steuerungsebene und eine der clusterinternen 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 einem einzelnen Cluster. Obwohl die für GKE verwendeten APIs (Istio-CRDs) identisch sind und die xDS die an die Sidecars gesendete Konfiguration kompatibel ist und keine Verhaltensunterschiede aufweist. Die Unterschiede der Steuerungsebene führen zu einigen Eigenschaften, die die für Sie als Endanwendende sichtbar sind.

  • Reaktionszeit 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 ein Konfigurationscommit mit zwei Durchgängen aus. Beim ersten Durchlauf werden Validierungen durchgeführt, um zu prüfen, ob die Konfiguration korrekt formatiert ist. Die nachfolgende Phase überträgt die Konfiguration global an Ihre Dienstbereitstellungen. Damit Google Cloud-Dienste wie globales zonen- oder regionsübergreifendes Load Balancing, zentrale Systemdiagnose, verkehrsabhängiges Autoscaling und verwaltete Ratenbegrenzung verwendet werden können, wird die Konfiguration an diese Systeme übertragen und unabhängig auf Richtigkeit geprü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 höhere Zuverlässigkeit, führen aber zu einer Konfiguration Push-Übertragung, die langsamer ist als die von aktuellen Anthos-Nutzern beobachtete Latenz Service Mesh.
    • Die Latenz, mit der neue Pods die vorhandene Konfiguration abrufen, beträgt mit der neuen Steuerungsebene etwas besser gemessen werden. Der langsame Konfigurationspush dient der Erstweitergabe aller neu erstellten Dienste oder neuer Richtlinien, die für den Dienst gesendet wurden. Endpunktweitergabe Latenzen funktionell ähnlich sind.
  • Geschwindigkeit von Skalierungsereignissen und anderen Änderungen an den Endpunkten Dies sind mit der neuen Steuerungsebene mindestens genauso schnell bearbeitet werden. 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. In älteren verwalteten Steuerungsebenenmodells (dedizierte Steuerungsebene) Kommunikation mit allen anderen Clustern im Mesh-Netzwerk, um die Endpunkte zu ermitteln die in jedem anderen Cluster verfügbar sind. 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-Nutzer sind: die nächsten Schritte für die Steuerungsebene in Ihrer vorhandenen Bereitstellung abhängig davon, ob Sie das verwaltete Steuerelement oder der clusterinternen Steuerungsebene.
    • 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, nicht identisch sind. Den Rest dieses Leitfadens müssen Sie nicht lesen.
    • Wenn Sie keine Google Cloud-Organisation haben und das verwalteten Steuerungsebene in einem Projekt ohne Organisation haben, TD-Steuerungsebene.
  • Wenn Sie Anthos Service Mesh-Kunde sind und neue Flotten erstellen, erhalten Sie die Implementierung der Traffic Director-Steuerungsebene. Ich sollten Sie diesen Leitfaden weiterlesen.
    • Sie werden über das Datum informiert, an dem neue Flotten die TD-Steuerungsebene erhalten.

Migration der Steuerungsebene für vorhandene Mesh-Netzwerke 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.

Prüfen Sie die Benachrichtigung mit dem folgenden Google Cloud CLI-Befehl:

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 Wenn Sie eine Automatisierung haben, die die Registrierung eines Clusters aufhebt, müssen Sie ihn vor dem oder bei der Migration auftreten. Für das verwaltete Produkt funktioniert, muss es bei einer Flotte mit der Mesh-Funktion registriert sein. aktiviert.

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 erfolgen auf sichere und kontrollierte Weise die folgenden Änderungen Ort:

  • 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 die Verbindung wiederherzustellen Traffic Director-Steuerungsebene.

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

Kompatibilität der Steuerungsebene prüfen

Unterschiede der unterstützten Funktionen zwischen verwalteten Steuerungsebenen kennenlernen Implementierung, um festzustellen, ob Ihre aktuelle Nutzung von Cloud Service Mesh Änderungen erfordert.

Steuerungsebene für neue Meshes

Ab dem 1. Juli 2024 haben die meisten bestehenden Nutzer der verwalteten istiod-Steuerung Die Implementierung der Ebene erhält die aktualisierte verwaltete Steuerungsebene. mit der global verfügbaren Implementierung von Google, dem Traffic Director (TD) Steuerungsebenen 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.

Wenn Sie eine neue Flotte in das verwaltete Cloud Service Mesh aufnehmen und diese Flotte nicht in einer Google Cloud-Organisation oder in einer neuen Google Cloud-Organisation erhalten Sie die neue verwaltete Steuerungsebene mit der TD-Implementierung das 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.