Verwaltete Steuerungsebene

Achtung:Verwaltetes Cloud Service Mesh mit der ISTIOD-Steuerungsebene ist eingestellt. Sie müssen alle verwalteten ISTIOD-Flotten auf die TRAFFIC_DIRECTOR-Implementierung umstellen.

In diesem Dokument werden die architektonischen Unterschiede zwischen der eingestellten ISTIOD-Steuerungsebene und der modernen TRAFFIC_DIRECTOR-Steuerungsebene von Google beschrieben. Außerdem werden die nächsten Schritte erläutert, wenn in Ihren Clustern noch eine eingestellte Steuerungsebene verwendet wird.

Übersicht über die Steuerungsebene

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

Cloud Service Mesh mit Istio APIs in GKE-Clustern bietet eine vollständig unterstützte Implementierung der Istio APIs. Die APIs werden von der vollständig verwalteten und in Cloud Networking integrierten TRAFFIC_DIRECTOR-Steuerungsebene implementiert und unterstützt. Bisher wurden zwei zusätzliche Implementierungen der Steuerungsebene unterstützt:

• Die eingestellte verwaltete ISTIOD-Implementierung, in der eine dedizierte Steuerungsebene für einen einzelnen Cluster ausgeführt wird.
• Die eingestellte clusterinterne ISTIOD-Implementierung, bei der Komponenten der kundenverwalteten Steuerungsebene in Ihrem Cluster ausgeführt werden.

Betriebsmerkmale der TRAFFIC_DIRECTOR-Steuerungsebene

Bei Cloud Service Mesh mit der TRAFFIC_DIRECTOR-Steuerungsebene wird die verwaltete Netzwerkinfrastruktur von Google Cloudanstelle von Steuerungsebeneninstanzen pro Cluster verwendet.

Die Istio-APIs (CRDs) und die an Envoy-Sidecars gesendete xDS-Konfiguration bleiben kompatibel, aber Sie sollten mit den folgenden Betriebseigenschaften rechnen:

• Weitergabe von Richtlinien und Dienstkonfigurationen:Wenn Sie neue Dienste erstellen oder Routing- und Sicherheitsrichtlinien aktualisieren, wird die Konfiguration validiert und über Google Cloud Systeme hinweg weitergegeben, bevor sie sich auf Sidecars auswirkt. Daher dauert die anfängliche Richtlinien- und Dienstweitergabe länger als bei clusterinternen oder ISTIOD-Steuerungsebenen. Informationen zum Optimieren von Bereitstellungs-Workflows finden Sie unter Konfigurationsübertragung.
• Pod-Skalierung und Endpunktaktualisierungen:Änderungen an Arbeitslastendpunkten, z. B. neue Pods, die durch horizontales Pod-Autoscaling erstellt werden, oder Pods, die mit neuen IP-Adressen neu gestartet werden, werden direkt von der Steuerungsebene weitergegeben, ohne die Latenz, die mit Richtlinienaktualisierungen verbunden ist. Vorhandene Pods, die eine vorhandene Konfiguration abrufen, werden sofort gestartet.
• Multi-Cluster-Endpunkterkennung:In Multi-Cluster-Meshes geben Cluster ihre Endpunkte direkt über Google Cloud weiter, anstatt sie punktweise zwischen jeder Kombination von Clustern zu synchronisieren. So wird sichergestellt, dass der Endpunktstatus clusterübergreifend schneller und konsistenter konvergiert, wenn Ihr Mesh skaliert wird.

Welche Auswirkungen hat das für Sie?

Ihre nächsten Schritte hängen davon ab, welche Implementierung der Steuerungsebene von Cloud Service Mesh in Ihren Clustern verwendet wird:

• Verwaltete Steuerungsebene (TRAFFIC_DIRECTOR-Implementierung):
  • Sie verwenden bereits die aktuelle, global skalierbare Architektur (unabhängig davon, ob sie mit Istio APIs, Gateway API oder Google CloudAPIs konfiguriert wurde).
  • Sie müssen nichts weiter tun.
• Verwaltete Steuerungsebene (ISTIOD-Implementierung):
  • Diese Implementierung ist veraltet.
  • Sie müssen Maßnahmen ergreifen, um Ihre Flotte auf Kompatibilitätsblocker zu prüfen, Ihre Konfiguration zu aktualisieren und die Modernisierung der verwalteten Steuerungsebene abzuschließen oder verwaltetes Cloud Service Mesh zu deinstallieren.
• Clusterinterne Steuerungsebene:
  • Die Clusterinterne Steuerungsebene in GKE ist eingestellt.
  • In-Cluster-Installationen können nicht direkt modernisiert werden. Sie müssen Maßnahmen ergreifen, um die clusterinterne Steuerungsebene auf einem neuen Cluster zur verwalteten Steuerungsebene zu migrieren oder Cloud Service Mesh zu deinstallieren.

Modernisierung der Steuerungsebene für verwaltetes Cloud Service Mesh mit der ISTIOD-Implementierung

Alle verwalteten Flotten, die die eingestellte ISTIOD-Implementierung verwenden, müssen vor dem im Einstellungs-Hinweis angegebenen End-of-Support-Datum auf die TRAFFIC_DIRECTOR-Implementierung umgestellt werden. Sie können Ihre Flotte entweder mit kundeninitiierten Modernisierungen (empfohlen für die Steuerung pro Cluster und die stufenweise Umstellung des Traffics) oder mit von Google initiierten Modernisierungen (automatisierte Rollouts für berechtigte Flotten) modernisieren.

Eine detaillierte Anleitung finden Sie unter Modernisierung der verwalteten Steuerungsebene.

Kompatibilität der Steuerungsebene prüfen

Informationen dazu, wie Sie Ihre Flotte anhand der unterstützten Funktionen bewerten und Konfigurationsblocker vor der Modernisierung ermitteln können, finden Sie unter:

• Cloud Service Mesh-Kompatibilität
• Konfigurationsupdates für die Modernisierung

Anhang: Zeitachse für die Einführung und Einstellung der Steuerungsebene

Die Umstellung von ISTIOD-Steuerungsebenen auf die verwaltete TRAFFIC_DIRECTOR-Steuerungsebene erfolgte gemäß diesem Zeitplan:

• 23. Mai 2024: Anthos Service Mesh und Traffic Director wurden in Cloud Service Mesh zusammengeführt. Dabei wurde die TRAFFIC_DIRECTOR-Steuerungsebene für Istio APIs eingeführt.
• 1. Juli 2024: TRAFFIC_DIRECTOR-Implementierung wird standardmäßig für neue Flotten verwendet, die in verwaltetes Cloud Service Mesh eingebunden werden.
• 8. September 2024:Die Bereitstellung der ISTIOD-Implementierung für neue Flotten wurde für die allgemeine Verfügbarkeit beendet (mit vorübergehenden Ausnahmen für bestimmte Organisationen auf einer Zulassungsliste).
• 28. September 2026: Die formelle Einstellung wird sowohl für die Implementierung der verwalteten ISTIOD-Steuerungsebene als auch für die In-Cluster-Steuerungsebene in GKE angekündigt.