Kanonischer Dienst

Hinweis: Kanonische Dienste werden in Cloud Service Mesh Version 1.6.8 und höher automatisch unterstützt.

Auf dieser Seite wird erläutert, was ein kanonischer Dienst in Cloud Service Mesh ist.

Was ist ein Kanonischer Dienst?

Cloud Service Mesh 1.6.8 bietet Unterstützung für kanonische Dienste, ein konzeptionelles Architekturmodell zur Darstellung Ihrer Produktionsarbeitslasten als einzelne einfacher zu beobachten und zu verwalten. Diese Arbeitslasten können mehrere Cluster, Back-End-Plattformen und unterschiedliche Schemas und Konfigurationen umfassen.

Für Kubernetes-Nutzer: Der kanonische Dienst entspricht in etwa dem Kubernetes-Konzept „app“ und der Anwendungs-CRD.

Für serverlose Nutzer: Der kanonische Dienst ähnelt den Konzepten des App Engine-Dienstes und des Cloud Run-Diensts. Der einzige Unterschied besteht darin, dass die serverlosen Dienste von Google von Natur aus regional sind, während kanonische Dienste eine globale / multiregionale Abstraktion sind.

In den folgenden Szenarien werden alle Möglichkeiten beschrieben, nach denen Sie sich auf einen kanonischen Dienst beziehen:

  • Ein Dienst ist ausgefallen.
  • Ein Dienst wird sowohl lokal als auch in einer öffentlichen Cloud ausgeführt.
  • Neue Überarbeitung eines Dienstes bereitstellen.
  • Der Dienst „Foo“ sendet zu viel Traffic und überschreitet möglicherweise unsere Kapazität.

Kanonische Dienste befinden sich in einem einzigen Mesh, was in Cloud Service Mesh bedeutet, dass auch innerhalb einer bestimmten Flotte und eine Google Cloud Projekt (alles ist 1:1 mit Mesh).

Eine bestimmte Arbeitslast kann nur Teil eines kanonischen Dienstes sein.

Sie können den vollständigen Umfang eines kanonischen Dienstes aus der Gruppe der Arbeitslasten bestimmen, die ihn definieren:

  • Hostnamen und IP-Adressen
  • Netzwerk(e)
  • Netzwerk- und Sicherheitsrichtlinien
  • Routing und Load-Balancing
  • VM- und Container-Images
  • Physische oder virtuelle Infrastruktur
  • Geografische Region(en)
  • CI/CD-System
  • Quellcode
  • Telemetrie
  • Service Level Objectives und Benachrichtigungen

Sie können auf der Seite „Dienste“ Dashboards aufrufen, in denen diese Betriebsdetails für jeden Dienst angezeigt werden.

Anforderungen und Einschränkungen für Kanonische Dienste

Kanonische Dienste sind nur in Cloud Service Mesh Version 1.6.8 und höher verfügbar.

Jeder kanonische Dienst ist in einem einzelnen Kubernetes/Istio-Namespace vorhanden und kann keine Namespace-Grenzen überschreiten.

Sie müssen einem kanonischen Dienst innerhalb des übergeordneten Namespace einen eindeutigen Namen geben. Weitere Informationen finden Sie unter Kanonischen Dienst definieren.

Kanonische Dienste können in mehreren Clustern und Regionen vorhanden sein. Während es möglich ist, Ressourcen und Telemetrie nach Cluster und Region aufzuschlüsseln, sind dies keine Faktoren, die den Umfang oder die Eindeutigkeit eines Dienstes bestimmen.

Die eindeutige Identität eines kanonischen Dienstes wird daher so bestimmt:

mesh id + namespace + canonical name.

Revisionen

Revisionen beziehen sich auf inkrementelle Änderungen eines Dienstes, mit denen Sie unterschiedliche „Versionen“ oder „Releases“ Ihrer Dienste unterscheiden können.

Sie können zwischen den Überarbeitungen eines kanonischen Dienstes unterscheiden. Kennzeichnen Sie dazu eine einzelne Arbeitslast mit ihrer „kanonischen Überarbeitung“. Dieses Label ist ein beliebiger String, den Sie festlegen können. Das Label wird in manchen Fällen automatisch festgelegt, aber Sie oder das CI/CD-System, das den Dienst bereitstellt, müssen das Label anwenden. Zur Orientierung: Informationen zum Festlegen dieses Labels finden Sie unter Kanonischen Dienst definieren.

Es können mehrere Revisionen gleichzeitig in der Produktion sein. Häufig wird durch den Einsatz mehrerer Revisionen gleichzeitig Folgendes erreicht:

  • Das schrittweise Rollout einer neuen Binärdatei, einer neuen Konfiguration oder beider in allen Instanzen eines Dienstes. In diesem Fall sind sowohl die alten als auch die neuen Revisionen während der Umstellung verfügbar.
  • Ein „A/B-Test“ oder „Live-Experiment“, in dem zwei verschiedene Versionen des Dienstes Untergruppen von nachgeschalteten Aufrufern ausgesetzt sind, um die Auswirkungen einer Änderung zu testen.

Nächste Schritte