Containerarbeitslasten in GDC

Auf dieser Übersichtsseite wird das Betriebsmodell für Containerarbeitslasten in einem GDC-Kubernetes-Cluster (Google Distributed Cloud) mit Air Gap erläutert. GDC bietet einen verwalteten Kubernetes-Dienst, der Kubernetes-native Containeranwendungen unterstützt, die in Google Kubernetes Engine (GKE) weit verbreitet und unterstützt werden.

Diese Seite richtet sich an Entwickler in der Gruppe der Anwendungsoperatoren, die für die Verwaltung von Anwendungsarbeitslasten für ihre Organisation verantwortlich sind. Weitere Informationen finden Sie unter Dokumentation zu Zielgruppen für GDC mit Air Gap.

Kubernetes-Anwendungen für eine Umgebung ohne Internetverbindung

GKE on GDC ist ein verwalteter Kubernetes-Dienst, der standardmäßig viele GKE-Funktionen in Ihre GDC-Umgebung einbindet. Mit diesem Dienst müssen Sie Open-Source-Kubernetes nicht selbst installieren, aktualisieren, integrieren und ausführen. Sie können die bereitgestellte Kubernetes-Distribution mit einer Standard-KRM-API wie jedes andere Kubernetes-Angebot betreiben und verwalten, das deklarativ und idempotent ist. GKE auf GDC wird ebenfalls über die GDC-Konsole, die gdcloud CLI und Terraform angeboten. Weitere Informationen zu GDC-Kubernetes-Clustern finden Sie unter Kubernetes-Cluster – Übersicht. Weitere Informationen zu wichtigen Kubernetes-Konzepten finden Sie in der GKE-Dokumentation unter Kubernetes lernen.

Status der Containerarbeitslast

Container in GDC werden als Folgendes in Kubernetes-Clustern bereitgestellt:

Sie können die Knoten Ihres GDC Kubernetes-Clusters entsprechend den Anforderungen Ihrer Containerarbeitslasten horizontal skalieren, auch nachdem der Cluster bereitgestellt wurde, wenn sich Ihre Rechenanforderungen ändern.

Kubernetes bietet mehrere integrierte Arbeitslastressourcen, mit denen Sie den gewünschten Status Ihrer Containeranwendung erreichen können. Weitere Informationen finden Sie in der Kubernetes-Dokumentation zu Arbeitslasten.

Zustandslose Arbeitslasten

Zustandslose Arbeitslasten sind Anwendungen, die keine Daten oder den Anwendungsstatus im Kubernetes-Cluster oder im nichtflüchtigen Speicher speichern. Stattdessen bleiben Daten und Anwendungsstatus beim Client. Das macht zustandslose Anwendungen skalierbarer. Eine Frontend-Anwendung kann beispielsweise zustandslos sein: Sie stellen mehrere Replikate bereit, um die Verfügbarkeit der Anwendung zu erhöhen und bei geringer Nachfrage herunterzuskalieren. Für die Replikate sind keine eindeutigen Identitäten erforderlich.

Kubernetes verwendet die Deployment-Ressource zum Bereitstellen zustandsloser Anwendungen als einheitliche, nicht eindeutige Pods. Deployments verwalten den gewünschten Status Ihrer Anwendung, z. B. die folgenden:

  • Die Anzahl der Pods, die zum Ausführen Ihrer Anwendung erforderlich sind.
  • Die Version des Container-Images, das ausgeführt werden soll.
  • Die Labels der Pods.

Sie können den gewünschten Status dynamisch ändern, indem Sie die Pod-Spezifikation der Deployment-Ressource aktualisieren.

Zustandslose Anwendungen stehen im Gegensatz zu zustandsorientierten Arbeitslasten, bei denen nichtflüchtiger Speicher zum Speichern von Daten und des Anwendungsstatus verwendet wird.

Zustandsorientierte Arbeitslasten

Zustandsorientierte Arbeitslasten sind Anwendungen, die Daten auf nichtflüchtigem Speicher speichern, damit sie vom Server, von Clients und von anderen Anwendungen verwendet werden können. Beispiele für zustandsorientierte Anwendungen sind Datenbanken oder Schlüssel/Wert-Speicher, in denen Daten gespeichert und von anderen Anwendungen abgerufen werden. Sie müssen nichtflüchtigen Speicher für Ihre zustandsbehaftete Anwendung bereitstellen.

Kubernetes verwendet die Ressource StatefulSet zum Bereitstellen zustandsorientierter Anwendungen. Pods in StatefulSet-Ressourcen sind nicht austauschbar: Jeder Pod hat eine eindeutige Kennung, die unabhängig davon beibehalten wird, wo er geplant ist.

Zustandsorientierte Anwendungen unterscheiden sich von zustandslosen Arbeitslasten, bei denen Clientdaten zwischen Sitzungen nicht auf dem Server gespeichert werden.

Nichtflüchtiger Speicher für Container

GDC bietet nichtflüchtigen Blockspeicher über PersistentVolumeClaim-Objekte (PersistentVolumeClaim). Ein PVC ist eine Speicheranfrage, auf die von einem Pod-Objekt verwiesen wird. Ein Pod ist eine Gruppe von einem oder mehreren Containern mit gemeinsam genutztem Speicher und Netzwerkressourcen. Ein PVC hat einen unabhängigen Lebenszyklus vom Pod, sodass er über einen einzelnen Pod hinaus bestehen bleibt.

Sie können nichtflüchtigen Speicher für Ihre zustandsorientierten Arbeitslasten dynamisch bereitstellen, sodass die zugrunde liegenden Volumes bei Bedarf erstellt werden. In GDC konfigurieren Sie die dynamische Bereitstellung, indem Sie das vorinstallierte StorageClass-Objekt standard-rwo erstellen. Das standard-rwo-Objekt ist eine ReadWriteOnce-Blockspeicherklasse (ReadWriteOnce, RWO), die es ermöglicht, dass auf ein Volume jeweils nur über einen Knoten zugegriffen werden kann.

Sie können auch ein VolumeSnapshot-Objekt erstellen, um das Speichervolume Ihrer Containeranwendung zu einem bestimmten Zeitpunkt zu kopieren, ohne ein völlig neues Volume zu erstellen. Ein Datenbankadministrator kann beispielsweise einen Volume-Snapshot erstellen, um Datenbanken zu sichern, bevor er Änderungen vornimmt oder sie löscht.

Nächste Schritte