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.

Wo Arbeitslasten bereitgestellt werden

Auf der GDC-Plattform unterscheiden sich die Vorgänge zum Bereitstellen von VM-Arbeitslasten und Containerarbeitslasten. In diesem Abschnitt werden die Unterschiede und die Bereitstellung der einzelnen Ressourcen 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. Ein Projekt kann viele VMs und VM-Arbeitslasten enthalten. 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. Kubernetes-Cluster können einem oder mehreren Projekten zugeordnet werden, sind aber keine untergeordnete Ressource eines Projekts. Wir empfehlen, Cluster nur an Projekte in der entsprechenden Bereitstellungsumgebung anzuhängen. Beispiel: Ein Cluster für Produktionsarbeitslasten ist an ein Projekt für Produktionsarbeitslasten angehängt.

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 in der Übersicht über Container-Arbeitslasten.

Best Practices für das Entwerfen von Kubernetes-Clustern

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

Separate Cluster pro Bereitstellungsumgebung erstellen

Zusätzlich zu separaten Projekten pro Bereitstellungsumgebung empfehlen wir, separate Kubernetes-Cluster pro Bereitstellungsumgebung zu entwerfen. Wenn Sie sowohl den Kubernetes-Cluster als auch das Projekt pro Umgebung 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, Bereitstellungsumgebungen und Maschinenklassen erstrecken.

GDC-Konfiguration

Bei dieser Beispielarchitektur wird davon ausgegangen, dass Arbeitslasten in einer Bereitstellungsumgebung Cluster gemeinsam nutzen dürfen. Jede Bereitstellungsumgebung hat eine separate Gruppe von Kubernetes-Clustern. Anschließend weisen Sie Projekte dem Kubernetes-Cluster der entsprechenden Bereitstellungsumgebung zu. Ein Kubernetes-Cluster kann für unterschiedliche Anforderungen an die Maschinenklasse in mehrere Knotenpools unterteilt werden.

Alternativ ist es für Container-Vorgänge wie die folgenden Szenarien sinnvoll, mehrere Kubernetes-Cluster 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, den API-Server oder andere Single Points of Failure in einem Cluster zu drosseln. Daher isolieren Sie sie von vorhandenen Arbeitslasten.

Das folgende Diagramm zeigt ein Beispiel, in dem mehrere Cluster pro Bereitstellungsumgebung konfiguriert sind. Das kann aufgrund von Anforderungen wie den im vorherigen Abschnitt beschriebenen Containeroperationen erforderlich sein.

GDC-Konfiguration

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 Bereitstellungsumgebungen und Containeroperationen 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.