Verwalten von Podspeicher in Kubernetes-Clustern
Die meisten Anwendungen, die Sie in AKS in Azure Stack HCI bereitstellen möchten, sind zwar zustandslos, aber Contoso-Entwickler haben einige zustandsbehaftete Workloads identifiziert, die sie in Container packen möchten. Um diese Anforderung zu erfüllen, müssen Sie die Unterstützung der Beibehaltung des Zustands ausgeführter Pods mithilfe persistenter Kubernetes-Volumes untersuchen.
Implementieren persistenter Volumes für AKS in Azure Stack HCI
Standardmäßig fungieren einzelne Pods als zustandslose Ressourcen. Wenn ein Pod, der Teil einer Bereitstellung ist, aus beliebigem Grund ausfällt, erstellt der Kubernetes-Planer automatisch einen neuen, der die entsprechenden Funktionen bereitstellt, um sicherzustellen, dass die containerisierte Anwendung verfügbar bleibt. Ohne zusätzliche Bestimmungen zum Beibehalten des Zustands gehen jedoch alle Daten verloren, die der fehlerhafte Pod möglicherweise bearbeitet hat.
In manchen Szenarien müssen Pods in der Lage sein, ihre Daten und ihren Zustand dauerhaft zu speichern und freizugeben. In diesen Szenarien können Sie persistente Volumes verwenden, bei denen es sich um Clusterressourcen handelt, die das Speichern von Daten von Containerworkloads über die Lebensdauer einzelner Pods hinaus ermöglichen.
Um ein Volume in einem Kubernetes-Cluster zu implementieren, müssen Sie zunächst einen Anspruch auf ein persistentes Volume für eine spezifische Speicherklasse definieren. Eine Speicherklasse stellt die Merkmale des zugrunde liegenden Speichers dar, z. B. Leistung oder Unterstützung für gemeinsamen Zugriff. Der Anspruch auf persistente Volumes enthält Informationen zum erforderlichen Zugriffsmodus und zur Volumegröße. Der Kubernetes-API-Server stellt mithilfe der Anspruchsdefinition für persistente Volumes dynamisch ein geeignetes Speichervolumen bereit, wenn dies für bereitgestellte Pods erforderlich ist.
Hinweis
AKS in Azure Stack HCI bietet die Standardspeicherklasse, die VHDX-basierte Datenträger implementiert.
Definieren Sie die Speicheranforderungen bereitgestellter Pods, indem Sie Spezifikationen für persistente Volumes in die entsprechenden Manifestdateien einbeziehen. Dadurch wird nicht nur die dynamische Bereitstellung ausgelöst, sondern auch das Volume automatisch in die Pods eingebunden.
Das folgende Manifest definiert beispielsweise einen Anspruch auf ein persistentes Volume für einen nicht freigegebenen Datenträger mit 100 GB, der die Standardspeicherklasse verwendet.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-akshci
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 100Gi
Um diesen Anspruch auf ein persistentes Volume zu implementieren, können Sie dieses Manifest als YAML-Datei speichern und das Befehlszeilen-Hilfsprogramm kubectl ausführen, um die entsprechende Ressource zu erstellen (wobei pvc_definition.yaml die YAML-Datei darstellt):
kubectl create -f pvc_definition.yaml
Um ein entsprechendes persistentes Volume für einen Pod zu definieren, könnten Sie das folgende Manifest verwenden:
kind: Pod
apiVersion: v1
metadata:
name: win-appserver
spec:
containers:
- name: win-appserver
image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
volumeMounts:
- name: akshciscsi
mountPath: "/mnt/akshciscsi"
volumes:
- name: akshciscsi
persistentVolumeClaim:
claimName: pvc-akshci
nodeSelector:
kubernetes.io/os: windows
Um dieses persistente Volume auch zu implementieren, können Sie das Podmanifest als YAML-Datei speichern und das Befehlszeilen-Hilfsprogramm kubectl ausführen, um das Volume bereitzustellen und einzubinden (wobei pv_definition.yaml die YAML-Datei darstellt):
kubectl create -f pv_definition.yaml
Der resultierende Pod hat ein Volume mit einer Größe von 100 GB, das in den durch den Wert des Elements mountPath festgelegten Dateisystempfad eingebunden wird.
Um den Anspruch auf persistente Volumes zu löschen, müssen Sie zunächst alle Pods und Bereitstellungen löschen, für die er derzeit gilt. An diesem Punkt können Sie zum Abschließen der Aufgabe den Befehl kubectl delete PersistentVolumeClaim gefolgt vom Namen des Anspruchs auf persistente Volumes verwenden.