Übersicht über das Deployment von Arbeitslasten

Zum Bereitstellen und Verwalten Ihrer containerisierten Anwendungen und anderer Arbeitslasten in Ihrem GKE-Cluster (Google Kubernetes Engine) verwenden Sie das Kubernetes-System, mit dem Sie Kubernetes-Controller-Objekte erstellen können. Diese Controller-Objekte stellen die Anwendungen, Daemons und Batch-Jobs dar, die in Ihren Clustern ausgeführt werden.

Sie können diese Controller-Objekte mit der Kubernetes API oder mit kubectl erstellen, eine von gcloud installierte Befehlszeile für Kubernetes. In der Regel erstellen Sie eine Darstellung des gewünschten Kubernetes-Controller-Objekts als YAML-Konfigurationsdatei. Diese verwenden Sie dann mit der Kubernetes API oder der Befehlszeile kubectl.

Arten von Arbeitslasten

Kubernetes bietet verschiedene Arten von Controller-Objekten für verschiedene Arten von Arbeitslasten, die Sie ausführen können. Einige Controller-Objekte eignen sich besser zur Darstellung bestimmter Arbeitslasten als andere. In den folgenden Abschnitten werden ein paar gängige Arbeitslasten und die entsprechenden Kubernetes-Controller-Objekte beschrieben, die Sie erstellen können, um die Arbeitslasten in Ihrem Cluster auszuführen. Dazu gehören:

  • Zustandslose Anwendungen
  • Zustandsorientierte Anwendungen
  • Batch-Jobs
  • Daemons

Zustandslose Anwendungen

Eine zustandslose Anwendung behält ihren Zustand nicht bei und speichert keine Daten im nichtflüchtigen Speicher – alle Nutzer- und Sitzungsdaten bleiben beim Client.

Beispiele für zustandslose Anwendungen sind Web-Front-Ends wie Nginx, Webserver wie Apache Tomcat und andere Webanwendungen.

Sie können ein Kubernetes-Deployment erstellen, um eine zustandslose Anwendung in einem Cluster bereitzustellen. Von Deployments erstellte Pods sind nicht eindeutig und behalten ihren Zustand nicht bei, wodurch das Skalieren und Aktualisieren zustandsloser Anwendungen vereinfacht wird.

Zustandsorientierte Anwendungen

Der Zustand einer zustandsorientierten Anwendung muss gespeichert werden oder dauerhaft sein. Zustandsorientierte Anwendungen nutzen nichtflüchtigen Speicher wie nichtflüchtige Volumes, um Daten zur Nutzung durch den Server oder durch andere Nutzer zu speichern.

Beispiele für zustandsorientierte Anwendungen sind Datenbanken wie MongoDB und Nachrichtenwarteschlangen wie Apache ZooKeeper.

Sie können ein Kubernetes-StatefulSet erstellen, um eine zustandsorientierte Anwendung bereitzustellen. Von StatefulSets erstellte Pods haben eindeutige Kennzeichnungen und können auf geordnete und sichere Weise aktualisiert werden.

Batch-Jobs

Batch-Jobs sind endliche, unabhängige und oft parallel laufende Aufgaben, die bis zu ihrem Abschluss ausgeführt werden. Beispiele für Batch-Jobs umfassen automatische oder geplante Aufgaben wie das Senden von E-Mails, das Rendern von Video und das Ausführen teurer Berechnungen.

Sie können einen Kubernetes-Job erstellen, um eine Batch-Aufgabe in einem Cluster auszuführen und zu verwalten. Sie können die Anzahl der Pods angeben, die ihre Aufgaben abschließen sollen, bevor der Job abgeschlossen ist, sowie die maximale Anzahl von Pods, die parallel ausgeführt werden sollen.

Daemons

Daemons führen in den zugewiesenen Knoten fortlaufende Hintergrundaufgaben aus, die keinen Eingriff des Nutzers erfordern. Beispiele für Daemons sind Log-Collector wie Fluentd und Monitoring-Dienste.

Sie können ein Kubernetes-DaemonSet erstellen, um einen Daemon in einem Cluster bereitzustellen. DaemonSets erstellen einen Pod pro Knoten. Sie können einen Knoten auswählen, in dem das DaemonSet bereitgestellt werden soll.

DaemonSets in GKE Autopilot

GKE verwaltet Knoten in Clustern, die Sie mit dem Autopilot-Betriebsmodus erstellen. Sie können die Knoten oder die zugrunde liegenden virtuellen Maschinen (VMs) von Compute Engine nicht manuell hinzufügen, entfernen oder ändern. Das Kubernetes-Knotenobjekt ist jedoch weiterhin sichtbar und Autopilot unterstützt DaemonSets als Arbeitslasten.

GKE Autopilot begrenzt einige administrative Funktionen, die alle Arbeitslast-Pods betreffen, einschließlich Pods, die von DaemonSets verwaltet werden. DaemonSets, die administrative Funktionen auf Knoten mit höheren Berechtigungen ausführen, z. B. den Sicherheitskontext privileged, werden nicht auf Autopilot-Clustern ausgeführt, es sei denn, sie sind ausdrücklich von GKE zugelassen.

Weitere Informationen zu den durch Autopilot erzwungenen Limits finden Sie unter Einschränkungen und Beschränkungen für Arbeitslasten. Sie können DaemonSets mit Arbeitslasten verwenden, die die von Autopilot festgelegten Einschränkungen sowie DaemonSets einiger Google Cloud-Partner erfüllen.

Best Practices für DaemonSets in Autopilot

GKE verwendet die Gesamtgröße der bereitgestellten Arbeitslasten, um die Größe der Knoten zu bestimmen, die Autopilot für den Cluster bereitstellt. Wenn Sie ein DaemonSet hinzufügen oder die Größe anpassen, nachdem Autopilot einen Knoten bereitgestellt hat, passt GKE die Größe vorhandener Knoten nicht an, um die neue Gesamtgröße der Arbeitslast zu berücksichtigen. DaemonSets mit Ressourcenanfragen, die die zuweisbare Kapazität vorhandener Knoten überschreiten, werden nach der Berücksichtigung der System-Pods ebenfalls nicht auf diesen Knoten geplant.

Ab der GKE-Version 1.27.6-gke.1248000 erkennen Cluster im Autopilot-Modus Knoten, die nicht alle DaemonSets unterbringen können, und migrieren Arbeitslasten im Laufe der Zeit zu größeren Knoten, die für alle DaemonSets geeignet sind. Dieser Vorgang dauert einige Zeit, insbesondere wenn die Knoten System-Pods ausführen, die zusätzliche Zeit für eine ordnungsgemäße Beendigung benötigen, damit es zu keiner Unterbrechung der Kernclusterfunktionen kommt.

In der GKE-Version 1.27.5-gke.200 oder früher empfehlen wir das Sperren und Per Drain beenden von Knoten, die nicht unterstützen DaemonSet-Pods.

Für alle GKE-Versionen empfehlen wir die folgenden Best Practices bei der Bereitstellung von DaemonSets im Autopilot-Modus:

  • DaemonSets vor allen anderen Arbeitslasten bereitstellen
  • Legen Sie eine höhere PriorityClass für DaemonSets als reguläre Pods fest. Mit der höheren Prioritätsklasse kann GKE Pods mit niedrigerer Priorität entfernen, um DaemonSet-Pods zu berücksichtigen, wenn der Knoten diese Pods berücksichtigen kann. Dadurch wird sichergestellt, dass das DaemonSet auf jedem Knoten vorhanden ist, ohne eine Neuerstellung des Knotens auszulösen.

Arbeitslastobjekte verwalten

Sie können Objekte mit imperativen und deklarativen Methoden erstellen, verwalten und löschen. In den nächsten Abschnitten werden diese Methoden sowie die folgenden Tools beschrieben, mit denen Sie die Methoden anwenden können:

Imperative Befehle

Imperative Befehle ermöglichen Ihnen, Objekte mit kubectl schnell zu erstellen, abzurufen, zu aktualisieren und zu löschen. Diese Befehle eignen sich für einmalige Aufgaben oder für Änderungen an aktiven Objekten in einem Cluster. Imperative Befehle werden häufig verwendet, um im Cluster bereitgestellte Liveobjekte zu bearbeiten.

kubectl bietet eine Reihe von verb-gesteuerten Befehlen zur Erstellung und Bearbeitung von Kubernetes-Objekten. Beispiel:

  • run: Erzeugt ein neues Objekt im Cluster. Sofern nicht anders angegeben, erstellt run ein Deployment-Objekt.
  • expose: Erstellt ein neues Dienstobjekt, um Traffic mithilfe von Load-Balancing auf eine Gruppe von mit Labels versehenen Pods zu verteilen.
  • autoscale: Erstellt ein neues Autoscaling-Objekt, um ein Controller-Objekt, etwa ein Deployment, automatisch horizontal zu skalieren.

Imperative Befehle können auch ohne umfangreiche Kenntnisse zu Objektschemas verwendet werden und erfordern keine Konfigurationsdateien.

Imperative Objektkonfiguration

Bei der imperativen Objektkonfiguration werden Objekte anhand von Konfigurationsdateien mit vollständig festgelegten Objektdefinitionen erstellt, aktualisiert und gelöscht. Das Speichern von Objektkonfigurationsdateien in Quellcode-Verwaltungssystemen und das Überprüfen von Änderungen ist einfacher als mit imperativen Befehlen.

Sie haben die Möglichkeit, die Vorgänge kubectl apply, delete und replace mit Konfigurationsdateien oder mit Verzeichnissen auszuführen, die Konfigurationsdateien enthalten.

Deklarative Objektkonfiguration

Die deklarative Objektkonfiguration basiert auf lokal gespeicherten Konfigurationsdateien, erfordert jedoch keine explizite Definition der auszuführenden Vorgänge. Stattdessen werden Vorgänge von kubectl automatisch pro Objekt erkannt. Dies ist nützlich, wenn Sie mit einem Verzeichnis von Konfigurationsdateien mit vielen verschiedenen Operationen arbeiten. Die deklarative Objektverwaltung erfordert ein ausgeprägtes Verständnis von Objektschemas und Konfigurationsdateien.

Sie können kubectl apply ausführen, um Objekte zu erstellen und Objekte deklaratorisch zu aktualisieren. apply aktualisiert Objekte. Dazu wird das gesamte Liveobjekt gelesen, bevor die Unterschiede berechnet und dann durch das Senden von Patch-Anfragen an den API-Server zusammengeführt werden.

Public Docker Hub-Images

Wenn Sie ein öffentliches Container-Image über Docker Hub bereitstellen, prüft GKE automatisch den Caching-Proxy mirror.gcr.io auf eine im Cache gespeicherte Kopie des Container-Images. Wenn keine im Cache gespeicherte Kopie verfügbar ist, ruft GKE das angeforderte Image von Docker Hub ab. Der Caching-Proxy speichert das Image möglicherweise zur späteren Verwendung im Cache. Weitere Informationen finden Sie unter Im Cache gespeicherte Images abrufen.

Console

Nachdem Sie eine Arbeitslast mit kubectl oder der API bereitgestellt haben, können Sie in der Google Cloud Console über das GKE-Menü Arbeitslasten Arbeitslasten prüfen, verwalten und bearbeiten, die auf den Clustern ausgeführt werden.

Das Menü bietet folgende Funktionen:

  • Sie können den YAML-basierten Texteditor verwenden, um Liveobjekte im Webbrowser zu bearbeiten.
  • Sie können detaillierte Informationen zu Objekten einsehen, einschließlich Überarbeitungsverlauf, aktuelle Ereignisse und Aktivitäten sowie zugehörige verwaltete Pods.
  • Sie können Deployments, Jobs und StatefulSets problemlos skalieren.
  • Sie können die automatische Skalierung verwenden, Rolling Updates auslösen und Deployments manuell über das Menü Aktionen skalieren.
  • Sie können Cloud Shell verwenden, um Objekte zu untersuchen, zu bearbeiten und zu löschen.

API

Sie können die GKE REST API und die Kubernetes API zusätzlich zu den Google Cloud-Clientbibliotheken verwenden, um Arbeitslasten programmatisch zu erstellen und zu verwalten.

Konfigurationsdateien

Wenn Sie eine Arbeitslast mit einer der zuvor beschriebenen Methoden bereitstellen, fügt GKE dem Cluster eine Konfigurationsdatei hinzu, die das Objekt darstellt.

Die Livekonfiguration eines Objekts unterscheidet sich möglicherweise von der entsprechenden lokalen Datei. YAML wird am häufigsten verwendet, um Kubernetes-Objekte zu erstellen und darzustellen. Sie können auch JSON verwenden.

Weitere Informationen zu Objektspezifikationen und Statusmeldungen von Kubernetes sowie der Kubernetes API finden Sie unter Understanding Kubernetes Objects und in der Referenz zur Kubernetes API.

Livekonfigurationen untersuchen

Console

Zum Prüfen der Livekonfiguration eines bereitgestellten Objekts führen Sie folgende Schritte aus:

  1. Öffnen Sie in der Google Cloud Console die Seite Arbeitslasten.

    Zu Arbeitslasten

  2. Wählen Sie die gewünschte Arbeitslast aus.

  3. Klicken Sie auf YAML.

gcloud

Führen Sie den folgenden Befehl aus, um die Livekonfiguration eines bereitgestellten Objekts zu untersuchen:

kubectl get [OBJECT_TYPE] [OBJECT_NAME] -o yaml

[OBJECT_TYPE] kann deployment, statefulset, job oder ein anderer Objekttyp sein. Beispiel:

kubectl get deployment my-stateless-app -o yaml

Ressourcennutzung mit Kontingenten verwalten

Wenn sich viele Nutzer oder Teams die Ressourcen in Ihrem Cluster teilen, besteht die Sorge, dass einige mehr als ihren gerechten Anteil nutzen könnten. Mit dem Kubernetes-Objekt ResourceQuota können Sie den Ressourcenverbrauch in bestimmten Namespaces begrenzen.

Außerdem wendet GKE ein unveränderliches gke-resource-quotas-Standardobjekt auf Namespaces in Clustern mit maximal 100 Knoten an, um Instabilität zu verhindern.

Mit GitLab in GKE bereitstellen

Wenn Sie GitLab für Continuous Integration verwenden, können Sie die GitLab-GKE-Komponente verwenden, um Ihre Arbeitslast in einem GKE-Cluster bereitzustellen.

Sie können auch die End-to-End-Anleitung zur Verwendung von GitLab mit Google Cloud ausprobieren.

Weitere Informationen finden Sie in der Übersicht zu GitLab on Google Cloud.

Nächste Schritte