Verwaltete Steuerungsebene für Bestandskunden

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

Wenn Sie weiterhin Traffic Director-Kunde oder Neukunde sind, gilt Folgendes: müssen 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 einem einzelnen Cluster. 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 ein 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 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 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 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. Diese Ereignisse neue Pods, die aufgrund von horizontalem Pod-Autoscaling gestartet oder beendet werden, und Pods werden mit neuen IP-Adressen neu gestartet, da sie an eine andere Knoten im Cluster.
  • 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 ein Traffic Director-Nutzer sind, bleibt Ihre Steuerungsebene unverändert. Ich müssen Sie 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, können Ihre vorhandenen werden Flotten auf die neue Steuerungsebene migriert, Cloud Service Mesh als verwaltete Steuerungsebene (Traffic Director, oder TD, Implementierung). Lesen Sie den folgenden Abschnitt: Steuerungsebene. Migration vorhandener Meshes und Flotten Wenn Sie ein Feature verwenden, das von Traffic Director nicht unterstützt wird Implementierung der Steuerungsebene verbleibend, können Sie vorübergehend die vorherige Steuerungsebene. Sie sollten diesen Leitfaden weiterlesen.
    • 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 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 erhalten neue Flotten die TD-Steuerungsebene.

Migration der Steuerungsebene für vorhandene Mesh-Netzwerke und Flotten

Ab dem 22. Juli 2024 aktualisiert Google vorhandene Cluster schrittweise, um die Verwendung der verwalteten Steuerungsebene mit TD-Implementierung. 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 eine Benachrichtigung erhalten, dass die Aktualisierung eines Clusters mindestens zwei Wochen vor dem Update. 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 Legacy-Cluster der verwalteten Steuerungsebene, die mit der Die meshconfig.googleapis.com API wird automatisch bei der Flotte registriert im Projekt des Clusters mit der gkehub.googleapis.com Membership API. 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 Anpassungen vornehmen möchten oder wenn Sie Fragen dazu haben, Funktionen.

Während der Migration erfolgen auf sichere und kontrollierte Weise die folgenden Änderungen Ort:

  • Um die Systemdiagnose zu aktivieren, wird das Daemonset snk im kube-system-Namespace des Clusters und eine Firewallregel pro Cluster ist erstellt.
  • So aktivieren Sie die Netzwerk-Endpunktgruppe (NEG): Aufnahme wird die Annotation cloud.google.com/neg allen Kubernetes-Instanzen hinzugefügt, Dienstleistungen.
  • Neue Google Cloud-Ressourcen wie Mesh, Routes, Back-End Dienstleistungen und Gesundheit Prüfungen in der Cluster.
  • 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

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 Mesh-Netzwerke

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 dem istiod Die Implementierung der Steuerungsebene ist nicht mit Traffic Director kompatibel Bei einer Implementierung ohne Änderungen wird weiterhin die istiod-Implementierung verwendet. bis zum 8. September 2024. Wenn dies auf Ihre Organisation zutrifft, haben Sie eine entsprechende Mitteilung 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 weiterhin Anthos Service Mesh-Kunde sind, finden Sie die 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.