Kanonischer Dienst – Best Practices

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

Mit kanonischen Diensten können Sie viele verschiedene Konfigurationen aufrufen. Um die Dienste von Cloud Service Mesh-Dashboards optimal zu nutzen, sollten Sie beim Einrichten Ihrer Dienste die folgenden Standardverfahren befolgen:

  • Einen bestimmten Dienst [Namespace, Name] für das gesamte Mesh-Netzwerk reservieren
  • Eine Softwareanwendung pro kanonischem Dienst definieren
    • Kanonische Dienste nicht über Umgebungen hinweg gruppieren (z. B. prod/stage/dev).
    • Cloud Monitoring-Dashboards für übergeordnete Ansichten mehrerer Dienste verwenden
  • Kanonische Dienste für lange Verwendung planen

Einen bestimmten Dienst [Namespace, Name] für das gesamte Mesh-Netzwerk reservieren

Wenn ein in einem Cluster oder einer Region bereitgestellter kanonischer Dienst denselben Kubernetes-Namespace und kanonischen Dienstnamen hat wie ein in einem anderen Cluster oder einer anderen Region bereitgestellter Dienst, nimmt Cloud Service Mesh an, dass es sich um denselben logischen Dienst handelt.

Dieses Verhalten entspricht dem Flottenprinzip der „Gleichheit“, das besagt, dass ein Namespace die gleiche Bedeutung haben und dieselbe Entität in der gesamten Flotte darstellen soll.

Eine Softwareanwendung pro kanonischem Dienst

Kanonische Dienste sollen einen einzelnen logischen Dienst oder Mikrodienst repräsentieren. Sie haben die Kontrolle über homogene Binärdateien/Arbeitslasten, die dieselbe Softwareanwendung und Geschäftsfunktion repräsentieren.

Sie könnten zwar einen kanonischen Dienst definieren, um mehrere konzeptionell unterschiedliche Microservices zusammenzufassen, aber die Service Dashboards würden nicht ihren vollen Wert liefern. Die Service Dashboards würden eine Aggregation von unterschiedlichen Komponenten anzeigen, die individuell sehr unterschiedlich funktionieren und konfiguriert sein können. Es wäre schwierig oder gar unmöglich, den Zustand, die Leistung und die Konfiguration des gesamten Systems zu verstehen.

Von den folgenden Vorgehensweisen wird nicht unbedingt abgeraten, aber der kanonische Dienst ist in diesen Fällen möglicherweise zu groß:

  • Es gibt Netzwerk-Traffic zwischen verschiedenen Arbeitslasten innerhalb eines einzigen kanonischen Diensts.
  • Ein kanonischer Dienst umfasst mehrere Arbeitslasten, die in unterschiedlichen Veröffentlichungszeitplänen bereitgestellt werden.
  • Verschiedene Teams in Ihrem Unternehmen sind für die Ausführung verschiedener Teile eines kanonischen Diensts zuständig.

Kanonischen Dienst nicht umgebungsübergreifend gruppieren

Viele Technologieunternehmen verwenden mehrere Bereitstellungsumgebungen, um die Qualität der Software sicherzustellen und das Risiko zu begrenzen. Diese Umgebungen enthalten meistens Entwicklungs-, Test-, Staging-, Produktions- oder andere Teilumgebungen.

Auch wenn Sie für verschiedene Umgebungen den gleichen konzeptionellen Dienst bereitstellen, ist nicht zu empfehlen, ihn als einen kanonischen Dienst zu erstellen. Diese Dienste sind nicht identisch und haben nicht die entsprechende operative Bedeutung. Auch repräsentieren sie nicht denselben Stellenwert für Ihr Unternehmen.

Zum Beispiel kann der Ausfall eines kritischen Produktionsdienstes Warnmeldungen um 3 Uhr morgens und Feuerwehreinsätze bedeuten. Es muss niemand benachrichtigt werden, nur weil die „dev“-Bereitstellung nachts ausfällt. Dies gilt auch für das Verständnis von Leistung, Kapazität und Releasesicherheit.

Im Spektrum von einfach, aber am wenigsten effektiv, bis aufwändig, aber am effektivsten gibt es drei Möglichkeiten, Dienste auf verschiedene Umgebungen aufzuteilen:

  1. Trennung mithilfe verschiedener Dienstnamen, z. B. payments-prod und payments-test
  2. Trennung mithilfe verschiedener Namespaces, zum Beispiel billing-team und billing-team-test
  3. Trennung mithilfe mehrerer Flotten, d. h. pro Umgebung eine

Benutzerdefinierte Cloud Monitoring-Dashboards für beliebige Zusammenfassungen bevorzugen

Nutzen Sie die Cloud Monitoring-Dashboards, um übergeordnete Ansichten mehrerer logischer Dienste auf einmal zu erstellen, anstatt die kanonischen Dienste künstlich in größere Bereiche für aggregierte Daten zu erweitern.

Kanonische Dienste sollen langlebig sein

Außerhalb der Entwicklungs-, Experimentierungs- und Testanwendungsfälle sollten kanonische Dienste globale, allgemeine logische Dienste repräsentieren. Diese Dienste ändern sich nur selten und sind meist langlebig. Diese Langlebigkeit umfasst auch das Nicht-Ändern von Dienstnamen. Sie können die Namen zwar ändern, aber dies wirkt sich auf Messwerte, SLOs und Logs aus. Sie können das Feld Display name jedoch problemlos individuell anpassen.

Ein neuer kanonischer Dienst repräsentiert häufig neue oder aktualisierte Software, während ein verworfener kanonischer Dienst häufig einen eingestellten Dienst repräsentiert. Ihre Möglichkeit, die bisherige Leistung Ihrer Dienst-, Plan- und Projektkapazität anzuzeigen, hängt davon ab, dass nur ein Konzept dieses Diensts in Cloud Service Mesh für seine Lebensdauer umgesetzt wird.

Beachten Sie, dass dies im Gegensatz zu untergeordneten Ressourcen wie VM-Instanzen, Kubernetes-Pods/-Deployments und auch ganzen Clustern steht. Diese werden häufig im Rahmen der Aktualisierung und Wartung von Produktionssystemen veröffentlicht.

Nächste Schritte