Einführung in Environ

Environs sind ein Google Cloud-Konzept für die logische Organisation von Clustern und anderen Ressourcen, mit dem Sie Multi-Cluster-Funktionen nutzen und verwalten sowie einheitliche Richtlinien auf Ihre Systeme anwenden können. Environs sind ein wesentlicher Bestandteil der Multi-Cluster-Funktionalität für Unternehmen in Anthos. Sie werden auch für verschiedene Features von Google Kubernetes Engine (GKE) verwendet.

Dieser Leitfaden bietet eine Einführung in Environs. Sie erfahren darin, was unter einem Environ zu verstehen ist, wo ein Environ in unseren Komponenten verwendet wird und wie Sie Ihre Systeme einrichten, um die Features von Environs nutzen zu können. Außerdem enthält er einige Beispiele, die zeigen, wie Environs die Cluster- und Systemverwaltung vereinfachen, sowie Best Practices für die Erstellung und Nutzung von Multi-Cluster-Systemen mit Environs.

Der Leitfaden richtet sich an technisch orientierte Leser, darunter Systemarchitekten, Plattformbetreiber und Dienstbetreiber, die mehrere Cluster und die zugehörige Infrastruktur nutzen möchten. Die Konzepte sind überall dort hilfreich, wo in Ihrer Organisation mehrere Cluster ausgeführt werden, ob in Google Cloud, für mehrere Cloud-Anbieter oder lokal.

Sie sollten mit grundlegenden Kubernetes-Konzepten wie Cluster vertraut sein. Ist dies nicht der Fall, finden Sie entsprechende Informationen unter Kubernetes-Grundlagen, in der GKE-Dokumentation und unter Anwendung für Anthos Service Mesh vorbereiten.

Wenn Sie mehr über Anthos und die Komponenten, die Environs verwenden, wissen möchten, lesen Sie die technische Übersicht von Anthos und nutzen Sie die Anleitung Anthos kennenlernen. Für diesen Leitfaden müssen Sie aber nicht mit Anthos vertraut sein.

Einführung

Unternehmen, die cloudnative Technologien wie Container, Containerorchestrierung und Service Meshes nutzen, kommen in der Regel an einen Punkt, an dem ein einzelner Cluster nicht mehr ausreicht. Organisationen entscheiden sich aus unterschiedlichen Gründen für die Bereitstellung mehrerer Cluster, um ihre technischen und geschäftlichen Ziele zu erreichen. Dazu gehört beispielsweise die Trennung der Produktion von Nicht-Produktionsumgebungen oder die Trennung von Diensten für verschiedene Ebenen, Regionen oder Teams. Weitere Informationen über die Vor- und Nachteile von Multi-Cluster-Ansätzen finden Sie unter Multi-Cluster-Anwendungsfälle.

Mit zunehmender Anzahl an Clustern wird die Verwaltung und Governance für diese Cluster und die darin enthaltenen Ressourcen immer schwieriger. Oft greifen Organisationen dann auf benutzerdefinierte Tools und Betriebsrichtlinien zurück um das erforderliche Maß an Kontrolle zu gewährleisten.

Google Cloud bietet das Konzept der Environs, um Administratoren bei der Verwaltung mehrerer Cluster zu unterstützen. Mit einem Environ können Sie Cluster logisch gruppieren und normalisieren und so die Verwaltung der Infrastruktur vereinfachen. Environs können im Kontext von Anthos wie von GKE verwendet werden. Im Abschnitt Environ-fähige Komponenten weiter unten in diesem Dokument finden Sie eine Liste der Anthos- und GKE-Komponenten, die Environs nutzen können.

Durch Implementierung von Environs können Sie die Verwaltung von einzelnen Clustern bis hin zu ganzen Clustergruppen optimieren. Darüber hinaus bietet die für Environs erforderliche Normalisierung Ihren Teams die Möglichkeit, die Best Practices von Google anzuwenden. Ein Environ ist die Basis für die Verwaltung mehrerer Cluster, so wie die Organisationsressource der Stammknoten der Ressourcenhierarchie von Google Cloud ist und für Richtlinien bzw. zur Steuerung von darin gruppierten Ressourcen verwendet wird.

Terminologie

Im Folgenden finden Sie einige wichtige Begriffe, die im Zusammenhang mit Environs verwendet werden.

Environ-fähige Ressourcen

Environ-fähige Ressourcen sind Google Cloud-Projektressourcen, die sich logisch gruppieren und als Environs verwalten lassen. Derzeit können nur Kubernetes-Cluster Environ-Mitglieder sein, auch wenn es VM-Instanzen und möglicherweise weitere Ressourcen gibt, die in künftigen Plattformversionen in der Lage sein werden, Environs einzubinden. Google Cloud bietet einen Connect-Dienst, um Ressourcen als Environ-Mitglieder zu registrieren.

Envoy-Hostprojekt

Die Implementierung von Environs erfolgt wie bei vielen anderen Google Cloud-Ressourcen in einem Google Cloud-Projekt, das als Environ-Hostprojekt bezeichnet wird. Einem Cloud-Projekt kann immer nur ein einziges Environ (oder kein Environ) zugeordnet sein. Diese Einschränkung fördert die Nutzung von Cloud-Projekten, um Ressourcen stärker zu trennen, die nicht gemeinsam gesteuert oder genutzt werden.

Environ-fähige Komponenten

Die im Folgenden aufgeführten Anthos- und GKE-Komponenten basieren auf Environ-Konzepten wie Namespace- und Identitätsgleichheit, die die Arbeit mit Clustern und Diensten vereinfachen sollen. Informationen zu den aktuellen Anforderungen oder Einschränkungen für die Verwendung von Environs mit den einzelnen Komponenten finden Sie unter Komponentenanforderungen.

  • Workload Identity-Pools (Anthos- und GKE-Cluster)
    Eine Umgebung bietet einen gemeinsamen Workload Identity-Pool, der zur einheitlichen Authentifizierung und Autorisierung von Arbeitslasten innerhalb eines Service Mesh und an externe Dienste verwendet werden kann.

  • Anthos Service Mesh (Anthos)
    Anthos Service Mesh besteht aus einer Reihe von Tools, mit denen Sie ein betriebssicheres Service Mesh in Google Cloud oder lokal überwachen bzw. verwalten können. Sie haben die Möglichkeit, ein Service Mesh für alle Ressourcen (z. B. Cluster und VMs) zu bilden, die Teil desselben Environ sind.

  • Anthos Config Management (Anthos) und Config Sync (GKE)
    Mit Anthos Config Management können Sie deklarative Richtlinien- und Konfigurationsänderungen für ein System in einem zentralen Git-Repository bereitstellen bzw. überwachen und dafür die grundlegende Kubernetes-Konzepte wie Namespaces, Labels und Annotationen nutzen. Mit Anthos Config Management und mit seinem Schwesterprodukt Config Sync für Nicht-Anthos-Cluster werden Richtlinie und Konfiguration für das gesamte Environ definiert, aber lokal in jeder Mitgliederressource angewendet und erzwungen.

  • Multi-Cluster Ingress (Anthos)
    Multi-Cluster Ingress verwendet das Environ, um Cluster und Dienstendpunkte zu definieren, für die ein Load-Balancing des Traffics erfolgen kann. Dies ermöglicht eine niedrige Latenz und Dienste mit Hochverfügbarkeit.

Infrastruktur gruppieren

Das erste zentrale Konzept für Environs ist das Konzept der Gruppierung. Dabei wird ausgewählt, welche Elemente von zugehörigen Environ-fähigen Ressourcen Teil eines Environs sein sollen. Um festzulegen, welche Elemente gruppiert werden, müssen folgende Fragen beantwortet werden:

  • Sind die Ressourcen miteinander verbunden?
    • Ressourcen mit einem hohen Maß an dienstübergreifender Kommunikation profitieren am meisten von der gemeinsamen Verwaltung in einem Environ.
    • Ressourcen in derselben Bereitstellungsumgebung (z. B. in der Produktionsumgebung) sollten in einem Environ gemeinsam verwaltet werden.
  • Wer verwaltet die Ressourcen?
    • Eine einheitliche (oder zumindest als vertrauenswürdig eingestufte) Kontrolle der Ressourcen ist entscheidend für die Gewährleistung der Integrität des Environ.

Zur Veranschaulichung dieses Aspekts betrachten wir eine Organisation mit mehreren Geschäftszweigen (Lines of Business, LOBs). In einem solchen Fall kommunizieren Dienste selten über LOB-Grenzen hinweg. Die Dienste in den verschiedenen LOBs werden in der Regel unterschiedlich verwaltet (z. B. können sich die Upgrade-Phasen von LOBs unterscheiden) und haben möglicherweise auch unterschiedliche Administratoren für jede LOB. In diesem Fall kann es sinnvoll sein, Environs LOB-weise zu verwenden. Außerdem ist es möglich, dass jede LOB mehrere Environs verwendet, um die Produktions- und Nicht-Produktionsdienste voneinander zu trennen.

In den folgenden Abschnitten werden weitere Environ-Konzepte erläutert. Je nach den spezifischen Anforderungen an Ihre Organisation kann es weitere Gründe für das Erstellen mehrerer Environs geben.

Gleichheit

Ein wichtiges Konzept ist das Konzept der Gleichheit. Damit ist gemeint, dass einige Kubernetes-Objekte, z. B. Cluster, mit demselben Namen in unterschiedlichen Kontexten identisch behandelt werden. Diese Normalisierung soll die Verwaltung von Environ-Ressourcen vereinfachen. Sie dient als Hilfsmittel zum Einrichten von Namespaces, Diensten und Identitäten. Dabei wird auch berücksichtigt, was die meisten Organisationen selbst implementieren.

Namespace-Gleichheit

Das grundlegende Beispiel für Gleichheit in einem Environ ist die Namespace-Gleichheit. Namespaces mit dem gleichen Namen in unterschiedlichen Clustern werden von vielen Komponenten als identisch eingestuft. Für dieses Attribut muss beachtet werden, dass ein Namespace logisch für ein komplettes Environ definiert wird, auch wenn die Instanziierung des Namespaces nur in einer Teilmenge der Environ-Ressourcen erfolgt.

Betrachten wir das folgende backend-Namespace-Beispiel. Obwohl der Namespace nur in den Clustern A und B instanziiert wird, wird er implizit für Cluster C reserviert. Damit ist es bei Bedarf möglich, den backend-Dienst auch in Cluster C zu terminieren. Dies bedeutet, dass Namespaces dem gesamten Environ und nicht einzelnen Cluster zugewiesen werden. Daher erfordert die Namespace-Gleichheit einheitliche Namespace-Eigentumsrechte im gesamten Environ.

Diagramm zur Namespace-Gleichheit in einem Environ
Namespace-Gleichheit in einem Environ

Dienstgleichheit

Anthos Service Mesh und Multi-Cluster-Ingress nutzen das Prinzip der Gleichheit von Diensten innerhalb eines Namespace. Ebenso wie bei der Namespace-Gleichheit bedeutet dies, dass Dienste mit dem gleichen Namespace und Dienstnamen als ein Dienst behandelt werden.

Die Dienstendpunkte können im Fall von Anthos Service Mesh für das gesamte Netzwerk zusammengeführt werden. Bei Multi-Cluster-Ingress macht eine MCS-Ressource (MultiClusterService) das Zusammenführen der Endpunkte expliziter. Wir empfehlen aber die Verwendung ähnlicher Verfahren unter Berücksichtigung der Benennung. Deshalb sollten Sie dafür sorgen, dass identisch benannte Dienstnamen innerhalb eines Namespace tatsächlich identisch sind.

Im folgenden Beispiel wird für den Internettraffic über einen gleichnamigen Dienst im Namespace frontend ein Load-Balancing in den Clustern B und C ausgeführt. Ebenso kann der frontend-Dienst mithilfe der Service Mesh-Attribute innerhalb des Environ den identisch benannten Dienst im Namespace auth in den Clustern A und C erreichen.

Diagramm zur Dienstgleichheit in einem Environ
Dienstgleichheit in einem Environ

Identitätsgleichheit beim Zugriff auf externe Ressourcen

Dienste innerhalb eines Environ können eine gemeinsame Identität nutzen, wenn sie auf externe Ressourcen wie Google Cloud-Dienste, Objektspeicher usw. zugreifen. Diese gemeinsame Identität ermöglicht es den Diensten in einem Environ einmal auf eine externe Ressource und nicht auf jeden Cluster einzeln zuzugreifen.

Das folgende Beispiel veranschaulicht diesen Aspekt. Die Cluster A, B und C sind mit einer gemeinsamen Identität innerhalb ihres Environ registriert. Wenn Dienste im Namespace backend auf Google Cloud-Ressourcen zugreifen, werden ihre Identitäten einem allgemeinen Google Cloud-Dienstkonto namens back zugeordnet. Das Google Cloud-Dienstkonto back kann von beliebig vielen verwalteten Diensten autorisiert werden, von Cloud Storage bis Cloud SQL. Wenn neue Environ-Ressourcen wie Cluster zum Namespace backend hinzugefügt werden, übernehmen sie automatisch die Gleichheitsattribute der Arbeitslastidentität.

Aufgrund der Identitätsgleichheit ist es wichtig, dass alle Ressourcen in einem Environ vertrauenswürdig sind und richtig kontrolliert werden. Wenn im vorherigen Beispiel Cluster C zu einem separaten, nicht vertrauenswürdigen Team gehört, kann dieses auch einen backend-Namespace erstellen und auf verwaltete Dienste zugreifen, als wäre es backend in Cluster A oder B.

Diagramm zur Identitätsgleichheit beim Zugriff auf Ressourcen außerhalb eines Environ
Identitätsgleichheit beim Zugriff auf Ressourcen außerhalb eines Environ

Identitätsgleichheit innerhalb eines Environ

Die Identitätsgleichheit wird innerhalb des Environ wie die zuvor erläuterte externe Identitätsgleichheit angewendet. So wie Environ-Dienste einmal für einen externen Dienst autorisiert werden, können sie ebenfalls intern autorisiert werden.

Im folgenden Beispiel wird Anthos Service Mesh verwendet, um ein Multi-Cluster-Service Mesh zu erstellen, in dem frontend Zugriff auf backend hat. Bei Anthos Service Mesh und Environs müssen Sie nicht angeben, dass frontend in den Clustern B und C auf backend in den Clustern A und B zugreifen kann. Stattdessen wird einfach festgelegt, dass frontend im Environ Zugriff auf backend im Environ hat. Durch dieses Attribut wird nicht nur die Autorisierung einfacher, auch die Ressourcengrenzen werden flexibler. Arbeitslasten können jetzt ganz einfach von Cluster zu Cluster verschoben werden, ohne dass sich dies auf ihre Autorisierung auswirkt. Wie bei der Gleichheit der Arbeitslastidentität ist die Governance der Environ-Ressourcen für die Integrität der Dienst-zu-Dienst-Kommunikation entscheidend.

Diagramm zur Darstellung der Identitätsgleichheit in einem Environ
Identitätsgleichheit innerhalb eines Environ

Exklusivität

Environ-fähige Ressourcen können jeweils immer nur einem einzigen Environ angehören. Diese Beschränkung wird von Google Cloud-Tools und -Komponenten erzwungen. Sie gewährleistet, dass es für die Steuerung eines Clusters nur eine einzige Quelle gibt. Ohne Exklusivität werden selbst die einfachsten Komponenten zu komplex für die Verwendung. Ihre Organisation müsste dann festlegen, wie verschiedene Komponenten aus verschiedenen Environs miteinander kommunizieren.

Hohe Vertrauensebene

Dienstgleichheit, Gleichheit der Arbeitslastidentität und Gleichheit der Mesh- Identität basieren auf dem Prinzip einer hohen Vertrauensebene zwischen Mitgliedern eines Environ. Dieses Vertrauen ermöglicht eine optimierte Verwaltung dieser Ressourcen für das gesamte Environ, anstatt sie ressourcenweise zu verwalten, also clusterweise für Kubernetes-Ressourcen. Außerdem spielen dann auch Clustergrenzen eine geringere Rolle.

Anders ausgedrückt bieten Cluster innerhalb eines Environ Schutz vor „Blast-Radius“-Problemen, Verfügbarkeit (sowohl der Steuerungsebene als auch der zugrunde liegenden Infrastruktur), Schutz vor Noisy Neighbor-Effekten und vieles mehr. Sie bilden jedoch keine strikte Trenngrenze für Richtlinien und Governance, da Administratoren eines Mitglieds in einem Environ den Betrieb der Dienste in anderen Mitgliedern des Environ potenziell beeinflussen können.

Aus diesem Grund empfehlen wir, dass Ressourcen, die vom Environ-Administrator als nicht vertrauenswürdig eingestuft werden, in einem eigenen Environ platziert werden, um sie zu isolieren. Bei Bedarf können einzelne Dienste über die Environ-Grenze hinaus autorisiert werden.

Nächste Schritte

Möchten Sie diese Konzepte für Ihre Systeme anwenden? Weitere Informationen finden Sie unter Anforderungen für Environ und Best Practices.