Arbeitslasttrennung entwerfen

In diesem Dokument finden Sie eine Übersicht zur Arbeitslastverwaltung in Google Distributed Cloud (GDC) mit Air Gap. Dabei werden die folgenden Themen behandelt:

Einige der Designs für die Bereitstellung von Arbeitslasten werden empfohlen, aber Sie müssen sie nicht genau so umsetzen, wie sie beschrieben sind. Jedes GDC-Universum hat eigene 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 Arbeitslasten für virtuelle Maschinen (VMs) und Container. 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 deren Bereitstellungslebenszyklus erläutert.

VM-basierte Arbeitslasten

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

Projekte, die nur VM-basierte Arbeitslasten enthalten, erfordern keinen Kubernetes-Cluster. 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 auf Organisationsebene, der sich über mehrere Projekte erstrecken kann und nicht von einem einzelnen Projekt verwaltet wird, sondern an diese angehängt ist.
  • Standardcluster: Ein Kubernetes-Cluster auf Projektebene, der Clusterressourcen innerhalb eines Projekts verwaltet und sich nicht über mehrere Projekte erstrecken kann.

Weitere Informationen finden Sie unter Kubernetes-Clusterkonfigurationen.

Kubernetes-Cluster bieten verschiedene Optionen für die Ressourcenhierarchie, da freigegebene Cluster auf Organisationsebene und Standardcluster auf Projektebene sind. Dies 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-Cluster infrastruktur 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, Vorabnutzung 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 zu Kubernetes-Clustern. 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 robustes Clusterdesign für den Lebenszyklus Ihrer Containerarbeitslast zu entwerfen.

Separate Cluster für jede Softwareentwicklungsumgebung erstellen

Neben separaten Projekten für jede Softwareentwicklungsumgebung, empfehlen wir, separate Kubernetes-Cluster für jede 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 jeden Cluster anhängen.

Wir empfehlen, in Lebenszyklen vor der Produktion Standardcluster zu verwenden, die auf ein einzelnes Projekt beschränkt sind, damit alle destruktiven Prozesse im Zusammenhang mit Tests von Produktionsprojekten isoliert werden können. Freigegebene Cluster sind ideal für Produktionsumgebungen, die sich über mehrere Projekte erstrecken können. Ein freigegebener Cluster, der Produktionsarbeitslasten hostet, 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.

Definierte Standardcluster für jede Softwareentwicklungsumgebung setzen voraus, dass Arbeitslasten vor der Produktion innerhalb einer Softwareentwicklungsumgebung auf diesen Cluster beschränkt sind. Ein Kubernetes-Cluster kann weiter in mehrere Knotenpools unterteilt werden oder Taints zur Isolierung von Arbeitslasten verwenden.

Durch die Trennung von Kubernetes-Clustern nach Softwareentwicklungsumgebung isolieren Sie den Ressourcenverbrauch, die Zugriffsrichtlinien, Wartungsereignisse und Konfigurationsänderungen auf Clusterebene zwischen Ihren Produktions- und Nicht-Produktionsarbeitslasten.

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

GDC-Clusterkonfiguration, die mehrere Softwareentwicklungsumgebungen umfasst.

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

Alternativ ist es für Containeroperationen wie in den folgenden Szenarien nützlich, mehrere Standardcluster pro Softwareentwicklungsumgebung zu entwerfen:

  • Einige Arbeitslasten sind an eine bestimmte Kubernetes-Version angepinnt, daher werden verschiedene Cluster mit unterschiedlichen Versionen verwaltet.
  • Einige Arbeitslasten erfordern unterschiedliche Clusterkonfigurationen, z. B. die Sicherungsrichtlinie, daher werden mehrere Cluster mit unterschiedlichen Konfigurationen erstellt.
  • Kopien eines Clusters werden parallel ausgeführt, um störende Versionsupgrades oder eine Blau/Grün-Bereitstellungsstrategie zu ermöglichen.
  • Sie erstellen eine experimentelle Arbeitslast, die den API-Server oder andere Single Points of Failure in einem Cluster drosseln könnte. Daher wird sie von vorhandenen Arbeitslasten isoliert.

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

Weniger Cluster erstellen

Für eine effiziente Ressourcennutzung empfehlen wir, die geringste Anzahl von Kubernetes-Clustern zu entwerfen, die Ihre Anforderungen an die Trennung von Softwareentwicklungsumgebungen und Containeroperationen erfüllen. Jeder zusätzliche Cluster verursacht zusätzlichen Ressourcenverbrauch, z. B. zusätzliche Knoten der Steuerungsebene. Daher nutzt ein größerer Cluster mit vielen Arbeitslasten die zugrunde liegenden Compute-Ressourcen effizienter als viele kleine Cluster.

Wenn mehrere Cluster mit ähnlichen Konfigurationen vorhanden sind, entsteht zusätzlicher Wartungsaufwand, um die Clusterkapazität zu überwachen und clusterübergreifende Abhängigkeiten zu planen.

Wenn sich ein Cluster der Kapazitätsgrenze nähert, empfehlen wir, dem 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, größere Knotenpools in einem Kubernetes-Cluster zu entwerfen.

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

Nächste Schritte