Verwaltete Steuerungsebene für fortlaufende Kunden

Dieses Dokument richtet sich an Sie, wenn Sie Anthos Service Mesh-Kunde sind und die verwaltete Steuerungsebene oder die clusterinterne Steuerungsebene verwenden. In diesem Dokument werden die Implementierung der Steuerungsebene und die mögliche Migration der Steuerungsebene erläutert.

Wenn Sie weiterhin Traffic Director-Kunde oder Neukunde sind, müssen Sie dieses Dokument nicht lesen.

Steuerungsebene

In Service Meshes bietet die Steuerungsebene Trafficverwaltung, Proxyverwaltung bei Verwendung des Envoy-Proxys und andere Netzwerkfunktionen.

Anthos Service Mesh bietet 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 (TD)-Implementierung bezeichnet. Was bedeutet die neue Steuerungsebene für Sie?

Eine der bedeutendsten Ä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 zugewiesen. Obwohl die für GKE verwendeten APIs (Looker-CRDs) identisch sind und die an die Sidecars gesendete xDS-Konfiguration ohne Verhaltensunterschiede kompatibel ist, ergeben die Unterschiede der Steuerungsebene einige Merkmale, die für Sie als Endnutzer 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 einen Konfigurations-Commit mit zwei Durchgängen durch. Beim ersten Durchlauf wird geprüft, ob die Konfiguration wohlgeformt ist. In der nachfolgenden Phase wird die Konfiguration global an Ihre Dienstbereitstellungen weitergegeben. Zum Aktivieren der Nutzung von Google Cloud-Diensten wie globales zonales oder regionenübergreifendes Load-Balancing, zentrale Systemdiagnose, verkehrsgesteuertes Autoscaling und verwaltete Ratenbegrenzung wird die Konfiguration an diese Systeme weitergegeben und unabhängig auf Richtigkeit überprüft. Die Konfiguration wird auch intern auf eine Weise gespeichert, die es Google Site Reliability Engineering ermöglicht, Produktvorgänge in Produktionsnotfällen zuverlässig und effizient auszuführen.
    • Diese Vorgänge bieten eine höhere Zuverlässigkeit, führen jedoch zu einem Konfigurations-Push, der langsamer ist als die Latenz, die von aktuellen Nutzern von Anthos Service Mesh beobachtet wird.
    • Die Latenz für einen neuen Pod zum Abrufen einer vorhandenen Konfiguration wird mit der neuen Steuerungsebene als etwas besser gemessen. Der langsame Konfigurations-Push findet bei der ersten Weitergabe neu erstellter Dienste oder neuer Richtlinien statt, die für den Dienst übertragen werden. Die Latenzen bei der Endpunktweitergabe sind funktional ähnlich.
  • Geschwindigkeit von Skalierungsereignissen und anderen Änderungen an den Endpunkten. Diese werden mit der neuen Steuerungsebene mindestens so schnell verarbeitet. Zu diesen Ereignissen gehören neue Pods, die aufgrund von horizontalem Pod-Autoscaling gestartet oder beendet werden, sowie Pods mit neuen IP-Adressen, die auf einen anderen Knoten im Cluster verschoben wurden.
  • Anzahl der Endpunkte skalieren Mit der neuen globalen Steuerungsebene werden die Endpunkte des Mesh-Netzwerks von allen Clustern im Mesh direkt von jedem Cluster an die Steuerungsebene gesendet. Dies ist ein einfacherer, schnellerer und skalierbarerer Ansatz als die vorherige verwaltete Steuerungsebene. Im älteren Modell der verwalteten Steuerungsebene (dedizierte Steuerungsebene) muss jedes Istio-Objekt mit jedem anderen Cluster im Mesh-Netzwerk kommunizieren, um die in jedem anderen Cluster verfügbaren Endpunkte zu bestimmen. Bei der globalen Steuerungsebene werden die Endpunkte direkt an die globale Steuerungsebene weitergegeben. Dies verbessert die Zuverlässigkeit und Leistung in Mesh-Netzwerken mit einer großen Anzahl von Endpunkten und ermöglicht die Skalierung der Mesh-Netzwerke auf eine größere Anzahl von Endpunkten.

Welche Auswirkungen hat die neue Steuerungsebene auf Sie?

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

  • Wenn Sie Traffic Director-Nutzer sind, bleibt die Steuerungsebene gleich. 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, 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 im Cloud Service Mesh als verwaltete Steuerungsebene (Traffic Director oder TD-Implementierung) bezeichnet wird. Lesen Sie den folgenden Abschnitt Migration der Steuerungsebene für vorhandene Mesh-Netzwerke und Flotten. Wenn Sie ein Feature verwenden, das von der Implementierung der Traffic Director-Steuerungsebene nicht unterstützt wird, bleiben Sie vorübergehend auf der vorherigen Steuerungsebene. Dieses Handbuch sollten Sie weiter lesen.
    • Wenn Sie die clusterinterne Steuerungsebene verwenden, bleibt die Steuerungsebene gleich. Sie müssen den Rest dieses Leitfadens nicht lesen.
    • Wenn Sie keine Google Cloud-Organisation haben und die verwaltete Steuerungsebene für ein Projekt ohne Organisation verwenden, erhalten Sie die TD-Steuerungsebene.
  • Wenn Sie Anthos Service Mesh-Kunde sind und neue Flotten erstellen, erhalten Sie die Implementierung der Traffic Director-Steuerungsebene. Sie sollten diesen Leitfaden weiter lesen.
    • 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 Mesh-Netzwerke aktualisieren.

Sie können die Funktionen der Steuerungsebenen von Istiod und Traffic Director auf der Seite überprüfen, auf der Unterstützte Features mit Istio APIs (verwaltete Steuerungsebene) beschrieben werden.

Sie sollten mindestens zwei Wochen vor der Aktualisierung eine Benachrichtigung erhalten, dass die Aktualisierung eines Clusters geplant ist. Benachrichtigungen sind in den Bedingungen für den Featurestatus 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 verwalteten Legacy-Cluster der Steuerungsebene, die mit der meshconfig.googleapis.com API eingerichtet wurden, werden automatisch mit der gkehub.googleapis.com Membership API bei der Flotte im Projekt des Clusters registriert. Wenn bei einer Automatisierung die Registrierung eines Clusters aufgehoben wird, müssen Sie ihn vor der Migration entfernen. Andernfalls treten bei der Migration Probleme auf. Damit das verwaltete Produkt funktioniert, muss es bei einer Flotte mit aktiviertem Mesh-Feature registriert sein.

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

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

  • Zum Aktivieren der Systemdiagnose wird das DaemonSet snk im Namespace kube-system des Clusters erstellt und es wird für jeden Cluster eine Firewallregel erstellt.
  • Zum Aktivieren der Aufnahme einer Netzwerk-Endpunktgruppe (NEG) wird allen Kubernetes-Diensten die Annotation cloud.google.com/neg hinzugefügt.
  • Neue Google Cloud-Ressourcen wie Mesh, Routes, Back-End-Dienste und Systemdiagnosen werden im Cluster erstellt.
  • Von Kubernetes-Deployments verwaltete Pods werden neu gestartet, um die Verbindung zur Traffic Director-Steuerungsebene wiederherzustellen.

Einige der neuen Ressourcen sind kontingentiert. Sie können Kontingente ansehen und bei Bedarf weitere anfordern.

Steuerungsebene für neue Mesh-Netzwerke

Ab dem 22. Juni 2024 erhalten alle Flotten, in denen Sie ein neues Mesh bereitstellen, die aktualisierte verwaltete Steuerungsebene mit der global verfügbaren Implementierung von Google: der Traffic Director-Steuerungsebene (TD).

Wenn Sie eine neue Flotte im verwalteten Cloud Service Mesh aufnehmen und sich diese Flotte 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 des Cloud Service Mesh.

Nächste Schritte

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