Containerarbeitslasten in GDC

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

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

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 deklarative und idempotente Kubernetes-Angebot betreiben und verwalten. GKE auf GDC wird ebenfalls über die GDC-Konsole, die gdcloud CLI und Terraform angeboten. Weitere Informationen zu GDC Kubernetes-Clustern finden Sie in der Übersicht über Kubernetes-Cluster. Weitere Informationen zu wichtigen Kubernetes-Konzepten finden Sie in der GKE-Dokumentation unter Kubernetes lernen.

Status der Containerarbeitslast

Container in GDC werden in Kubernetes-Clustern so bereitgestellt:

Sie können die Knoten Ihres GDC Kubernetes-Clusters entsprechend den Anforderungen Ihrer Containerarbeitslasten skalieren, auch nach der Clusterbereitstellung, 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 unter Arbeitslasten.

Zustandslose Arbeitslasten

Zustandslose Arbeitslasten sind Anwendungen, die weder Daten noch den Anwendungsstatus im Kubernetes-Cluster oder im nichtflüchtigen Speicher speichern. Stattdessen bleiben Daten und Anwendungsstatus beim Client. Das macht zustandslose Anwendungen skalierbarer. Bei einer zustandslosen Frontend-Anwendung zum Beispiel werden mehrere Replikate bereitgestellt, um ihre Verfügbarkeit zu erhöhen und bei geringem Bedarf wieder zu verringern. Die Replikate benötigen dabei keine eindeutigen Identitäten.

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

  • Die Anzahl der Pods, die zum Ausführen Ihrer Anwendung benötigt werden.
  • 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 sind das Gegenteil von zustandsorientierten Arbeitslasten, die nichtflüchtigen Speicher zum Speichern von Daten und des Anwendungsstatus verwenden.

Zustandsorientierte Arbeitslasten

Zustandsorientierte Arbeitslasten sind Anwendungen, die Daten auf nichtflüchtigen Speichern zur Verwendung durch den Server, durch Clients und andere Anwendungen speichern. 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, um zustandsorientierte Anwendungen bereitzustellen. Pods in StatefulSet-Ressourcen sind nicht austauschbar. Jeder Pod hat eine eindeutige Kennung, die beibehalten wird, unabhängig davon, wo der Pod geplant ist.

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

Nichtflüchtiger Speicher für Container

GDC bietet persistenten Block- und Dateispeicher über PersistentVolumeClaim-Objekte (PVC). Ein PVC ist eine Speicheranfrage, auf die von einem Pod-Objekt verwiesen wird. Ein Pod ist eine Gruppe aus einem oder mehreren Containern mit gemeinsam genutztem Speicher und Netzwerkressourcen. Ein PVC hat einen unabhängigen Lebenszyklus vom Pod, sodass es ü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 nach Bedarf erstellt werden. In GDC konfigurieren Sie die dynamische Bereitstellung, indem Sie eines der folgenden vorinstallierten StorageClass-Objekte erstellen:

  • standard-rwo: Die Block-Storage-Klasse ReadWriteOnce (RWO). Auf das Volume kann jeweils nur von einem Knoten zugegriffen werden. Diese Speicherklasse bietet eine garantierte und begrenzte Anzahl von Ein- und Ausgabevorgängen pro Sekunde (IOPS) von 3 IOPS pro GiB.

  • system-performance-rwo: Die ReadWriteOnce-Leistungsblockspeicherklasse. Diese Speicherklasse ist eine leistungsfähigere Version von RWO-Speicher mit einer IOPS-Garantie und einem Limit von 30 IOPS pro GiB.

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.

Nächste Schritte