Kubernetes Volumes ermöglichen das Speichern und Teilen von Daten über Container-Instanzen hinweg und bieten durch diverse Implementierungsoptionen mit unterschiedlichen Backends eine starke Abstraktionsebene für Speicheranforderungen. Sie sind entscheidend für die Handhabung von stateful und stateless Anwendungen: Während stateless Anwendungen meist temporäre Speicher nutzen, erfordern stateful Anwendungen persistente Volumes zur Verwaltung von Zustandsdaten. Ein fundiertes Verständnis dieser Konzepte ist für das effektive Aufsetzen und Verwalten von Kubernetes-Clustern unabdingbar.
Ein Volume kann in der Pod-Spezifikation wie folgt definiert werden:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image
volumeMounts:
- name: my-volume
mountPath: /path/in/container
volumes:
- name: my-volume
emptyDir: {}| Schlüsselwort | Beschreibung |
|---|---|
volumeMounts |
Gibt an, wo das Volume im Container eingehängt wird. |
mountPath |
Der Pfad im Container, an dem das Volume eingehängt wird. |
volumes |
Definiert die Volumen, die dem Pod zur Verfügung stehen. |
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1GiMit StorageClasses können Administratoren verschiedene Arten von Speicher mit unterschiedlichen Eigenschaften definieren.
In Kubernetes werden Anwendungen entweder als stateful oder stateless kategorisiert. Diese Kategorisierung hat direkte Auswirkungen auf die Art und Weise, wie Volumes verwendet werden. In diesem Artikel wird der Fokus auf die Rolle von Volumes in stateful und stateless Anwendungen gelegt.
Stateless Anwendungen speichern keinen Zustand zwischen den Sitzungen. Jede Anfrage ist unabhängig, und die Anwendung benötigt keine dauerhafte Speicherung.
Im Gegensatz dazu behalten stateful Anwendungen einen Zustand zwischen den Sitzungen bei. Sie erfordern eine Form der dauerhaften Speicherung.
StatefulSets sind ein Kubernetes-Controller, der speziell für stateful Anwendungen entwickelt wurde. Sie verwalten den Lebenszyklus von Pods und zugehörigen PVs und PVCs.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
serviceName: "nginx"
replicas: 3
template:
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: my-storage-class
resources:
requests:
storage: 1GiEmptyDir ist ein ephemeres Volume in Kubernetes, das temporären Speicherplatz für die Laufzeit eines Pods bereitstellt und nach dessen Löschung entfernt wird. Es ermöglicht den Datenaustausch zwischen Containern eines Pods, wobei die Begrenzung der Datenhaltbarkeit und Speicherkapazität zu beachten ist.
Im folgenden Beispiel wird ein Pod mit zwei Containern erstellt. Beide Container verwenden ein gemeinsames EmptyDir-Volumen.
apiVersion: v1
kind: Pod
metadata:
name: my-shared-pod
spec:
containers:
- name: producer
image: alpine
command: ["/bin/sh", "-c"]
args: ["echo 'Hello, World!' > /data/hello.txt"]
volumeMounts:
- name: shared-data
mountPath: /data
- name: consumer
image: alpine
command: ["/bin/sh", "-c"]
args: ["cat /data/hello.txt"]
volumeMounts:
- name: shared-data
mountPath: /data
volumes:
- name: shared-data
emptyDir: {}In diesem Beispiel:
producer-Container erstellt eine Datei namens
hello.txt im gemeinsamen EmptyDir-Volumen.consumer-Container liest die Datei
hello.txt aus dem gemeinsamen EmptyDir-Volumen.HostPath ist ein Volume-Typ in Kubernetes, der den Zugriff auf Dateisysteme des Host-Computers innerhalb eines Pods ermöglicht, was eine enge Kopplung mit dem Host-Knoten zur Folge hat. Sie sind für bestimmte Anwendungsfälle vorgesehen, bei denen der Zugriff auf Host-Ressourcen unerlässlich ist, sollten aber aufgrund potenzieller Risiken und Einschränkungen bedacht eingesetzt werden.
Im folgenden Beispiel wird ein Pod erstellt, der ein HostPath-Volume verwendet, um auf ein Verzeichnis des Host-Systems zuzugreifen.
apiVersion: v1
kind: Pod
metadata:
name: my-hostpath-pod
spec:
containers:
- name: my-container
image: alpine
command: ["/bin/sh", "-c"]
args: ["ls /host-data"]
volumeMounts:
- name: host-volume
mountPath: /host-data
volumes:
- name: host-volume
hostPath:
path: /var/lib/some-data
type: DirectoryIn diesem Beispiel:
/host-data
eingehängt.ls /host-data aus, um
den Inhalt des Host-Verzeichnisses /var/lib/some-data
aufzulisten.