Volumes

Diese Seite bietet einen Überblick über Volumes in Kubernetes und ihre Verwendung mit Google Kubernetes Engine (GKE).

Übersicht

Für eine Anwendung ist es am einfachsten, Daten in Dateien zu schreiben, die sich auf einem Laufwerk in einem Container befinden. Allerdings hat diese Vorgehensweise ihre Nachteile. Wenn der Container aus irgendeinem Grund abstürzt oder beendet wird, gehen die Dateien verloren. Darüber hinaus sind Dateien in einem Container für andere Container, die im selben Pod ausgeführt werden, nicht zugänglich. Die Kubernetes-Volume-Abstraktion befasst sich mit diesen zwei Problemen.

Im Prinzip ist ein Volume ein Verzeichnis, auf das alle Container in einem Pod zugreifen können. Die in der Pod-Spezifikation deklarierte Volume-Quelle legt fest, wie das Verzeichnis erstellt wird, welches Speichermedium verwendet wird und was das Verzeichnis ursprünglich enthält. Ein Pod gibt an, welche Volumes in ihm enthalten sind und in welchem Pfad die Container das Volume bereitstellen.

Sitzungsspezifische Volume-Typen haben dieselbe Lebensdauer wie die Pods, in denen sie sich befinden. Diese Volumes werden beim Erstellen des Pods erstellt und bleiben auch nach Neustarts von Containern erhalten. Wenn der Pod beendet oder gelöscht wird, gilt dies auch für seine Volumes.

Andere Volume-Typen sind Schnittstellen zu langlebigen Speichern, die von Pods unabhängig sind. Im Gegensatz zu sitzungsspezifischen Volumes bleiben Daten in einem Volume mit langlebigem Speicher erhalten, wenn der Pod entfernt wird. Das Volume wird lediglich getrennt und die Daten können an einen anderen Pod übergeben werden. Verwenden Sie zum Verwalten des Lebenszyklus von langlebigen Speichertypen PersistentVolume-Ressourcen. Geben Sie sie nicht direkt an.

Volume-Typen

Volumes unterscheiden sich in ihrer Speicherimplementierung und ihrem ursprünglichen Inhalt. Sie können die Volume-Quelle auswählen, die für Ihren Anwendungsfall am besten geeignet ist. In den folgenden Abschnitten werden verschiedene gängige Volume-Quellen beschrieben: Eine vollständige Liste der Volume-Typen finden Sie in der Dokumentation zu Kubernetes-Volumes.

emptyDir

Das Volume emptyDir enthält ein leeres Verzeichnis, das Container im Pod lesen und schreiben können. Wenn der Pod aus irgendeinem Grund aus einem Knoten entfernt wird, werden die Daten im emptyDir endgültig gelöscht. Ein emptyDir-Volume wird auf dem Medium gespeichert, das den Knoten sichert. Je nach Umgebung kann es sich z. B. um ein Laufwerk, ein SSD oder einen Netzwerkspeicher handeln. emptyDir-Volumes eignen sich für den temporären Speicher und die gemeinsame Nutzung von Daten zwischen mehreren Containern in einem Pod.

Alle emptyDir-Bereitstellungen sind Teil des sitzungsspezifischen Knotenspeichers, der auch die beschreibbare Containerebene und Logs enthält. Standardmäßig setzt GKE Autopilot den sitzungsspezifischen Speicher auf 1 GiB, damit Ihre Anwendung genügend Platz zum Erstellen einiger Dateien hat. Wenn Sie mehr oder weniger benötigen, können Sie den sitzungsspezifischen Speicher in Ihrem Deployment optimieren, indem Sie eine Ressourcenanfrage für ephemeral-storage festlegen.

Wenn Sie Container mit Linux-Knotenpools verwenden, können Sie das Feld emptyDir.medium auf Memory setzen, um Kubernetes anzuweisen, ein tmpfs (RAM-gestütztes Dateisystem) bereitzustellen. In Windows Server-Containern wird dies jedoch nicht unterstützt.

ConfigMap

Mit einer ConfigMap-Ressource können Konfigurationsdaten in Pods eingefügt werden. Die in einem ConfigMap-Objekt gespeicherten Daten können in einem Volume vom Typ ConfigMap referenziert und dann über Dateien genutzt werden, die in einem Pod ausgeführt werden. Die Dateien in einem ConfigMap-Volume werden von einer ConfigMap-Ressource angegeben.

Secret

Ein Secret-Volume wird verwendet, um für Anwendungen vertrauliche Daten wie Passwörter, OAuth-Tokens und SSH-Schlüssel verfügbar zu machen. Die in einem Secret-Objekt gespeicherten Daten können in einem Volume vom Typ Secret referenziert und dann über Dateien genutzt werden, die in einem Pod ausgeführt werden.

downwardAPI

Das Volume downwardAPI stellt Anwendungen Downward API-Daten zur Verfügung. Diese Daten enthalten Informationen über den Pod und Container, in denen eine Anwendung ausgeführt wird. Beispielsweise kann ein Pod so konfiguriert werden, dass ein DownwardAPIVolumeFile eine Anwendung bereitstellt, die den Namespace und die IP-Adresse des Pods enthält. Eine vollständige Liste der Datentypen, die Sie hinzufügen können, finden Sie unter Capabilities of the Downward API.

PersistentVolumeClaim

Clusterbetreiber können ein PersistentVolumeClaim-Volume verwenden, um eine langfristige Speicherung für Anwendungen bereitzustellen. Ein Pod stellt mithilfe eines PersistentVolumeClaim ein Volume bereit, das von diesem langlebigen Speicher gestützt wird.