Speicheroptionen für Anwendungen in AKS, die von Azure Arc aktiviert sind
Gilt für: AKS auf Azure Stack HCI 22H2, AKS unter Windows Server
Anwendungen, die in AKS-Bereitstellungen mit aktiviertem Azure Kubernetes-Dienst von Azure Arc ausgeführt werden, müssen möglicherweise Daten speichern und abrufen. Bei einigen Anwendungsworkloads können die Daten lokalen, schnellen Speicher auf einem nicht benötigten Knoten verwenden, wenn die Pods gelöscht werden (Kubernetes verwendet Pods für die Ausführung einer Instanz einer Anwendung).
Andere Workloads erfordern möglicherweise Speicher, der auf regelmäßigeren Datenvolumes beibehalten wird. Mehrere Pods müssen möglicherweise dieselben Datenvolumes gemeinsam nutzen oder Datenvolumes erneut anfügen, wenn der Pod auf einem anderen Knoten neu geplant wird. Außerdem benötigen Sie möglicherweise eine Speicheroption, wenn die Pods vertrauliche Daten oder Anwendungskonfigurationsinformationen enthalten.
In diesem Artikel werden die Kernkonzepte vorgestellt, die Speicher für Ihre Anwendungen in AKS Arc bereitstellen, einschließlich:
- Volumes
- Persistente Volumes
- Speicherklassen
- Ansprüche auf persistente Volumes (PVC)
Volumes
Anwendungen müssen häufig Daten speichern und abrufen können. Da Kubernetes einzelne Pods in der Regel als temporäre, verwerfbare Ressourcen behandelt, stehen verschiedene Ansätze zur Verfügung, wie Anwendungen Daten verwenden und beibehalten können. Ein Volume stellt eine Möglichkeit dar, Daten podübergreifend und während des Anwendungslebenszyklus zu speichern, abzurufen und dauerhaft zu speichern.
In Kubernetes können Volumes mehr als nur eine herkömmliche Information darstellen, auf der Informationen gespeichert und abgerufen werden. Kubernetes-Volumes können auch als Möglichkeit zum Einfügen von Daten in einen Pod für zu verwendende Container genutzt werden. Einige gängige Kubernetes-Volumetypen umfassen Folgendes:
emptyDir: Dieses Volume wird häufig als temporärer Speicher für einen Pod verwendet. Alle Container in einem Pod können auf die Daten des Volumes zugreifen. Auf diesen Volumetyp geschriebene Daten werden nur für die Lebensdauer des Pods beibehalten – wenn der Pod gelöscht wird, wird das Volume gelöscht. Dieses Volume verwendet in der Regel den zugrunde liegenden lokalen Knotendatenträgerspeicher, obwohl es auch nur im Arbeitsspeicher des Knotens vorhanden sein kann.
geheim – Dieses Volume wird verwendet, um vertrauliche Daten, z. B. Kennwörter, in Pods einzuschließen. Sie erstellen zunächst ein Geheimnis mit der Kubernetes-API. Wenn Sie Ihren Pod oder die Bereitstellung definieren, können Sie ein bestimmtes Geheimnis anfordern. Geheime Schlüssel werden nur für Knoten mit einem geplanten Pod bereitgestellt, der dies erfordert, und der geheime Schlüssel wird in tmpfs gespeichert, nicht auf den Datenträger geschrieben. Wenn der letzte Pod auf einem Knoten, der einen geheimen Schlüssel erfordert, gelöscht wird, wird der geheime Schlüssel aus den Tmpfs des Knotens gelöscht. Geheimnisse werden in einem bestimmten Namespace gespeichert, und nur Pods im gleichen Namespace können darauf zugreifen.
ConfigMap: Dieser Volumetyp wird verwendet, um Schlüssel-Wert-Paar-Eigenschaften in Pods einzufügen, z.B. Informationen zur Anwendungskonfiguration. Anstatt Informationen zur Anwendungskonfiguration in einem Containerimage zu definieren, können Sie sie als Kubernetes-Ressource definieren, die problemlos aktualisiert und bei deren Bereitstellung auf neue Instanzen von Pods angewendet werden kann. Ähnlich wie bei der Verwendung eines geheimen Schlüssels erstellen Sie zunächst eine ConfigMap mit der Kubernetes-API. Diese ConfigMap kann dann angefordert werden, wenn Sie einen Pod oder eine Bereitstellung definieren. ConfigMaps werden in einem bestimmten Namespace gespeichert und können nur von Pods innerhalb desselben Namespaces aufgerufen werden.
Persistente Volumes
Volumes werden als Teil des Podlebenszyklus definiert und erstellt und sind nur solange vorhanden, bis der Pod gelöscht wird. Wenn Pods während eines Wartungsereignisses auf einem anderen Host neu eingeplant werden, erwarten sie häufig, dass ihr Speicher erhalten bleibt, insbesondere in StatefulSets. Ein persistentes Volume ist eine von der Kubernetes-API erstellte und verwaltete Speicherressource, die unabhängig von der Lebensdauer eines einzelnen Pods vorhanden sein kann.
Sie können AKS-Datenträgervolumes verwenden, die von VHDX unterstützt werden, die als ReadWriteOnce bereitgestellt werden und gleichzeitig auf einen einzelnen Knoten zugreifen können. Sie können auch AKS-Dateivolumes verwenden, die von SMB- oder NFS-Dateifreigaben unterstützt werden. Diese werden als ReadWriteMany eingebunden und sind für mehrere Knoten gleichzeitig verfügbar.
Ein Clusteradministrator kann statisch ein persistentes Volume erstellen, oder das Volume kann dynamisch vom Kubernetes-API-Server erstellt werden. Wenn ein Pod geplant ist und Speicher anfordert, der zurzeit nicht verfügbar ist, kann Kubernetes die zugrunde liegende VHDX-Datei erstellen und dann an den Pod anfügen. Dynamische Bereitstellung verwendet eine StorageClass zum Identifizieren des zu erstellenden Speichertyps.
Speicherklassen
Um verschiedene Ebenen (und Speicherort) des Speichers zu definieren, können Sie eine StorageClass erstellen. Die StorageClass definiert auch die "reclaimPolicy". Diese ReclaimPolicy steuert das Verhalten der zugrunde liegenden Speicherressource, wenn der Pod gelöscht wird und das persistente Volume möglicherweise nicht mehr erforderlich ist. Die zugrunde liegende Speicherressource kann gelöscht oder für die Verwendung mit einem zukünftigen Pod beibehalten werden.
In AKS Arc wird die Standardspeicherklasse automatisch erstellt und verwendet CSV zum Erstellen von VHDX-gesicherten Volumes. Mit der Freigaberichtlinie wird sichergestellt, dass das zugrunde liegende VHDX gelöscht wird, wenn das persistente Volume gelöscht wird, das es verwendet hat. Mit der Speicherklasse werden auch die persistenten Volumes so konfiguriert, dass sie erweiterbar sind. Sie müssen lediglich den Anspruch der persistenten Volumes entsprechend der neuen Größe anpassen.
Wenn für ein persistentes Volume keine StorageClass angegeben ist, wird die Standardspeicherklasse verwendet. Stellen Sie beim Anfordern dauerhafter Volumes sicher, dass sie den entsprechenden Speicher verwenden. Sie können eine StorageClass für zusätzliche Anforderungen erstellen.
Ansprüche auf persistente Volumes
A PersistentVolumeClaim requests either ReadWriteOnce or ReadWriteMany storage of a particular StorageClass and size. Der Kubernetes-API-Server kann die zugrunde liegende Speicherressource in AKS Arc dynamisch bereitstellen, wenn keine Ressource vorhanden ist, um den Anspruch basierend auf der definierten StorageClass zu erfüllen. Sobald die Verbindung des Volumes mit dem Pod hergestellt ist, enthält die Poddefinition die Volumebereitstellung.
Ein PersistentVolume ist an ein PersistentVolumeClaim gebunden, sobald eine verfügbare Speicherressource dem Pod zugewiesen ist, der sie anfordert. Es gibt eine 1:1-Zuordnung persistenter Volumes zu Ansprüchen.
Das folgende Beispiel für das YAML-Manifest zeigt einen persistenten Volumeanspruch an, der die Standardspeicherklasse verwendet und einen 5Gi-Datenträger anfordert:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: aks-hci-vhdx
spec:
accessModes:
- ReadWriteOnce
storageClassName: default
resources:
requests:
storage: 5Gi
Wenn Sie eine Poddefinition erstellen, geben Sie den persistenten Volumeanspruch an, um den gewünschten Speicher anzufordern. Anschließend geben Sie die volumeMount Anwendungen zum Lesen und Schreiben von Daten an. Das folgende Beispiel eines YAML-Manifests zeigt, wie der vorherige Anspruch auf ein persistentes Volume verwendet werden kann, um ein Volume unter/mnt/aks-hci einzubinden:
kind: Pod
apiVersion: v1
metadata:
name: nginx
spec:
containers:
- name: myfrontend
image: k8s.gcr.io/nginx
volumeMounts:
- mountPath: "/mnt/aks-hci"
name: volume
nodeSelector:
kubernetes.io/os: linux
volumes:
- name: volume
persistentVolumeClaim:
claimName: aks-hci-vhdx
Das folgende Beispiel zeigt, wie Sie ein Volume in einem Windows-Container bereitstellen und den Laufwerkbuchstaben und Pfad angeben:
volumeMounts:
- mountPath: "d:"
name: volume
- mountPath: "c:\k"
name: k-dir