Arbeitslasttrennung entwerfen

Dieses Dokument bietet einen Überblick über die Verwaltung von Arbeitslasten in Google Distributed Cloud (GDC) mit Air Gap. Dabei werden die folgenden Themen behandelt:

Einige der Designs für die Bereitstellung von Arbeitslasten werden zwar empfohlen, es ist jedoch nicht erforderlich, sie genau wie beschrieben zu befolgen. Für jedes GDC-Universum gelten individuelle Anforderungen und Überlegungen, die von Fall zu Fall erfüllt werden müssen.

Dieses Dokument richtet sich an IT-Administratoren in der Gruppe der Plattformadministratoren, die für die Verwaltung von Ressourcen in ihrer Organisation verantwortlich sind, und an Anwendungsentwickler in der Gruppe der Anwendungsoperatoren, die für die Entwicklung und Wartung von Anwendungen in einem GDC-Universum verantwortlich sind.

Weitere Informationen finden Sie unter Dokumentation zu Zielgruppen für GDC mit Air Gap.

Wo Arbeitslasten bereitgestellt werden

Auf der GDC-Plattform unterscheiden sich die Vorgänge zum Bereitstellen von VM-Arbeitslasten und Containerarbeitslasten. Das folgende Diagramm veranschaulicht die Trennung von Arbeitslasten in der Datenebene Ihrer Organisation.

Arbeitslasttrennung in der Datenebene der Organisation.

VM-basierte Arbeitslasten werden in einer VM ausgeführt. Containerarbeitslasten werden dagegen in einem Kubernetes-Cluster ausgeführt. Die grundlegende Trennung zwischen VMs und Kubernetes-Clustern bietet Isolationsgrenzen zwischen Ihren VM-Arbeitslasten und Containerarbeitslasten. Weitere Informationen finden Sie unter Ressourcenhierarchie.

In den folgenden Abschnitten werden die Unterschiede zwischen den einzelnen Arbeitslasttypen und ihrem Bereitstellungslebenszyklus beschrieben.

VM-basierte Arbeitslasten

Sie können VMs erstellen, um Ihre VM-basierten Arbeitslasten zu hosten. Sie haben viele Konfigurationsoptionen für die Form und Größe Ihrer VM, um die Anforderungen Ihrer VM-basierten Arbeitslast bestmöglich zu erfüllen. Sie müssen eine VM in einem Projekt erstellen, das viele VM-Arbeitslasten haben kann. VMs sind untergeordnete Ressourcen eines Projekts. Weitere Informationen finden Sie in der VM-Übersicht.

Für Projekte, die nur VM-basierte Arbeitslasten enthalten, ist kein Kubernetes-Cluster erforderlich. Daher müssen Sie keine Kubernetes-Cluster für VM-basierte Arbeitslasten bereitstellen.

Containerbasierte Arbeitslasten

Sie können containerbasierte Arbeitslasten in einem Pod in einem Kubernetes-Cluster bereitstellen. Ein Kubernetes-Cluster besteht aus den folgenden Knotentypen:

  • Knoten der Steuerungsebene: Führt die Verwaltungsdienste aus, z. B. Planung, etcd und einen API-Server.

  • Worker-Knoten: Führt Ihre Pods und Containeranwendungen aus.

Kubernetes-Clusterarchitektur

Es gibt zwei Konfigurationstypen für Kubernetes-Cluster:

  • Freigegebene Cluster: Ein Kubernetes-Cluster mit Organisationsbereich, der sich über mehrere Projekte erstrecken kann und nicht von einem einzelnen Projekt verwaltet, sondern daran angehängt wird.
  • Standardcluster: Ein Kubernetes-Cluster auf Projektebene, der Clusterressourcen innerhalb eines Projekts verwaltet und nicht über mehrere Projekte hinweg verwendet werden kann.

Weitere Informationen finden Sie unter Kubernetes-Clusterkonfigurationen.

Kubernetes-Cluster bieten verschiedene Optionen für die Ressourcenhierarchie, da freigegebene Cluster organisationsbezogen und Standardcluster projektbezogen sind. Das ist ein grundlegender Unterschied zwischen Kubernetes-Clustern und VMs. Eine VM ist eine untergeordnete Ressource eines Projekts und kann nicht so konfiguriert werden, dass sie außerhalb eines Projekts ausgeführt wird. Weitere Informationen zum Entwerfen Ihrer Kubernetes-Clusterinfrastruktur finden Sie unter Best Practices für das Entwerfen von Kubernetes-Clustern.

Für die Pod-Planung in einem Kubernetes-Cluster verwendet GDC die allgemeinen Kubernetes-Konzepte für Planung, Vorabzuweisung und Entfernung. Best Practices für die Planung von Pods in einem Cluster variieren je nach den Anforderungen Ihrer Arbeitslast.

Weitere Informationen zu Kubernetes-Clustern finden Sie in der Übersicht über Kubernetes-Cluster. Weitere Informationen zum Verwalten von Containern in einem Kubernetes-Cluster finden Sie unter Containerarbeitslasten in GDC.

Best Practices für das Entwerfen von Kubernetes-Clustern

In diesem Abschnitt werden Best Practices für das Entwerfen von Kubernetes-Clustern vorgestellt:

Berücksichtigen Sie jede Best Practice, um ein stabiles Clusterdesign für den Lebenszyklus Ihrer Containerarbeitslast zu entwickeln.

Separate Cluster für jede Softwareentwicklungsumgebung erstellen

Zusätzlich zu separaten Projekten pro Softwareentwicklungsumgebung empfehlen wir, separate Kubernetes-Cluster pro Softwareentwicklungsumgebung zu entwerfen. Eine Softwareentwicklungsumgebung ist ein Bereich in Ihrem GDC-Universum, der für alle Vorgänge vorgesehen ist, die einer bestimmten Lebenszyklusphase entsprechen. Wenn Sie beispielsweise drei Softwareentwicklungsumgebungen mit den Namen development, staging und production in Ihrer Organisation haben, können Sie für jede Umgebung einen separaten Satz von Kubernetes-Clustern erstellen und Projekte nach Bedarf an die einzelnen Cluster anhängen.

Wir empfehlen, in Vorproduktionslebenszyklen Standardcluster zu verwenden, die auf ein einzelnes Projekt beschränkt sind. So können alle destruktiven Prozesse im Zusammenhang mit Tests von Produktionsprojekten isoliert werden. Freigegebene Cluster sind ideal für Produktionsumgebungen, die sich über mehrere Projekte erstrecken können. Ein freigegebener Cluster, auf dem Produktionsarbeitslasten gehostet werden, die sich über mehrere Projekte erstrecken, bietet einen gemeinsamen Bereitstellungsbereich, in dem Standardcluster, die auf ein einzelnes Projekt beschränkt sind, ihre Arbeitslasten direkt in die Produktionsumgebung übertragen können.

Durch die Definition von Standardclustern für jede Softwareentwicklungsumgebung wird davon ausgegangen, dass Vorproduktionsarbeitslasten in einer Softwareentwicklungsumgebung auf diesen Cluster beschränkt sind. Ein Kubernetes-Cluster kann weiter in mehrere Knotenpools unterteilt werden oder Markierungen zur Isolierung von Arbeitslasten verwenden.

Wenn Sie Kubernetes-Cluster nach Softwareentwicklungsumgebung trennen, isolieren Sie den Ressourcenverbrauch, die Zugriffsrichtlinien, die Wartungsereignisse und die Konfigurationsänderungen auf Clusterebene zwischen Ihren Produktions- und Nichtproduktionsarbeitslasten.

Das folgende Diagramm zeigt ein Beispiel für das Design eines Kubernetes-Clusters für mehrere Arbeitslasten, die sich über Projekte, Cluster, Softwareentwicklungsumgebungen und Maschinenklassen erstrecken, die von unterschiedlichen Knotenpools bereitgestellt werden.

GDC-Clusterkonfiguration, die mehrere Softwareentwicklungsumgebungen umfasst.

Bei dieser Beispielarchitektur wird davon ausgegangen, dass Arbeitslasten in den Softwareentwicklungsumgebungen für Entwicklung, Staging und Produktion Cluster gemeinsam nutzen können. Jede Umgebung hat einen separaten Standardcluster, der in mehrere Knotenpools für unterschiedliche Anforderungen an die Maschinenklasse unterteilt ist. Der gemeinsam genutzte Cluster umfasst alle Softwareentwicklungsumgebungen und bietet einen gemeinsamen Bereitstellungsbereich für alle Umgebungen.

Alternativ kann es für Containeroperationen wie in den folgenden Szenarien sinnvoll sein, mehrere Standardcluster pro Softwareentwicklungsumgebung zu entwerfen:

  • Sie haben einige Arbeitslasten an eine bestimmte Kubernetes-Version angepinnt und verwalten daher verschiedene Cluster mit unterschiedlichen Versionen.
  • Sie haben einige Arbeitslasten, für die unterschiedliche Clusterkonfigurationen erforderlich sind, z. B. die Sicherungsrichtlinie. Daher erstellen Sie mehrere Cluster mit unterschiedlichen Konfigurationen.
  • Sie führen Kopien eines Clusters parallel aus, um disruptive Versionsupgrades oder eine Blau/Grün-Bereitstellungsstrategie zu ermöglichen.
  • Sie erstellen eine experimentelle Arbeitslast, die das Risiko birgt, dass der API-Server oder andere Single Points of Failure in einem Cluster gedrosselt werden. Daher isolieren Sie sie von vorhandenen Arbeitslasten.

Sie müssen Ihre Softwareentwicklungsumgebungen an die Anforderungen Ihrer Containeroperationen anpassen.

Weniger Cluster erstellen

Für eine effiziente Ressourcennutzung empfehlen wir, die Anzahl der Kubernetes-Cluster so gering wie möglich zu halten, die Ihre Anforderungen an die Trennung von Softwareentwicklungs- und Containerbetriebsumgebungen erfüllen. Jeder zusätzliche Cluster führt zu einem zusätzlichen Ressourcenverbrauch, z. B. durch zusätzliche Knoten der Steuerungsebene. Daher werden die zugrunde liegenden Rechenressourcen in einem größeren Cluster mit vielen Arbeitslasten effizienter genutzt als in vielen kleinen Clustern.

Wenn es mehrere Cluster mit ähnlichen Konfigurationen gibt, entsteht zusätzlicher Wartungsaufwand für die Überwachung der Clusterkapazität und die Planung von clusterübergreifenden Abhängigkeiten.

Wenn ein Cluster sich der Kapazitätsgrenze nähert, empfehlen wir, einem Cluster zusätzliche Knoten hinzuzufügen, anstatt einen neuen Cluster zu erstellen.

Weniger Knotenpools in einem Cluster erstellen

Für eine effiziente Ressourcennutzung empfehlen wir, weniger, aber größere Knotenpools in einem Kubernetes-Cluster zu erstellen.

Die Konfiguration mehrerer Knotenpools ist nützlich, wenn Sie Pods planen müssen, die eine andere Maschinenklasse als andere benötigen. Erstellen Sie für jede Maschinenklasse, die für Ihre Arbeitslasten erforderlich ist, einen Knotenpool und legen Sie die Knotenkapazität auf Autoscaling fest, um eine effiziente Nutzung der Rechenressourcen zu ermöglichen.

Nächste Schritte