Speicheroptionen für Anwendungen in Azure Kubernetes Service (AKS)

  • Artikel

Anwendungen, die in Azure Kubernetes Service (AKS) ausgeführt werden, müssen möglicherweise Daten speichern und abrufen. Während einige Anwendungsworkloads lokale, schnelle Speicherung auf nicht benötigten, geleerten Knoten verwenden können, erfordern andere Speicher, der auf reguläreren Datenvolumes innerhalb der Azure-Plattform beibehalten wird.

Mehrere Pods erfordern möglicherweise Folgendes:

  • Gemeinsame Nutzung der gleichen Datenvolumes
  • Erneutes Anfügen von Datenvolumes, wenn der Pod auf einem anderen Knoten neu geplant wird

Möglicherweise müssen Sie auch vertrauliche Daten oder Informationen zur Anwendungskonfiguration in Pods erfassen uns speichern.

In diesem Artikel werden die wichtigsten Konzepte vorgestellt, mit denen Sie für Ihre Anwendungen in AKS Speicher bereitstellen:

Storage options for applications in an Azure Kubernetes Services (AKS) cluster

Kurzlebiger Betriebssystemdatenträger

Standardmäßig repliziert Azure den Betriebssystemdatenträger für eine VM automatisch in Azure Storage, um Datenverluste zu vermeiden, wenn die VM auf einen anderen Host verschoben wird. Da Container jedoch nicht für die Speicherung des lokalen Zustands vorgesehen sind, hat dieses Verhalten einen begrenzten Nutzen und einige Nachteile. Zu diesen Nachteilen gehören unter anderem eine langsamere Knotenbereitstellung und eine geringere Wartezeit bei Lese-/Schreibvorgängen.

Im Gegensatz dazu werden kurzlebige Betriebssystemdatenträger genau wie ein temporärer Datenträger nur auf dem Hostcomputer gespeichert. Diese Konfiguration verringert die Latenz bei Lese-/Schreibvorgängen und ermöglicht gleichzeitig eine schnellere Knotenskalierung sowie schnellere Clusterupgrades.

Hinweis

Wenn Sie nicht explizit verwaltete Azure-Datenträger für das Betriebssystem anfordern, verwendet AKS standardmäßig (soweit möglich) ein kurzlebiges Betriebssystem für eine bestimmte Knotenpoolkonfiguration.

Größenanforderungen und Empfehlungen für kurzlebige Betriebssystemdatenträger werden in der Azure-VM-Dokumentation beschrieben. Im Folgenden sind allgemeine Überlegungen zur Größe aufgeführt:

  • Wenn Sie die AKS-VM-Standardgröße zum Standard_DS2_v2-Tarif mit der standardmäßigen Betriebssystemdatenträger-Größe von 100 GB verwenden möchten, unterstützt die VM-Standardgröße das kurzlebige Betriebssystem, hat aber nur eine Cachegröße von 86 GiB. Diese Konfiguration ist standardmäßig auf verwaltete Datenträger festgelegt, wenn Sie nicht explizit etwas anderes angeben. Wenn Sie ein kurzlebiges Betriebssystem anfordern, erhalten Sie einen Überprüfungsfehler.

  • Wenn Sie denselben Standard_DS2_v2-Tarif mit einem 60 GiB-Betriebssystemdatenträger anfordern, würde diese Konfiguration standardmäßig das kurzlebige Betriebssystem verwenden. Die angeforderte Größe von 60 GiB ist kleiner als die maximale Cachegröße von 86 GiB.

  • Wenn Sie den Standard_D8s_v3-Tarif mit einem 100 GB-Betriebssystemdatenträger auswählen, unterstützt diese VM-Größe das kurzlebige Betriebssystem und verfügt über einen Cachespeicher von 200 GiB. Wenn Sie den Typ des Betriebssystemdatenträgers nicht angeben, erhält der Knotenpool standardmäßig das kurzlebige Betriebssystem.

Die neueste Generation von VM-Serien verfügt nicht über einen dedizierten Cache, sondern nur über temporären Speicher. Wenn Sie beispielsweise die VM-Größe Standard_E2bds_v5 mit der standardmäßigen Betriebssystemdatenträger-Größe von 100 GiB ausgewählt haben, werden kurzlebige Betriebssystemdatenträger unterstützt, allerdings nur mit einem temporären Speicher von 75 GB. Diese Konfiguration ist standardmäßig auf verwaltete Betriebssystemdatenträger festgelegt, wenn Sie nicht explizit etwas anderes angeben. Wenn Sie einen kurzlebigen Betriebssystemdatenträger anfordern, erhalten Sie einen Überprüfungsfehler.

  • Wenn Sie dieselbe VM-Größe Standard_E2bds_v5 mit einem 60 GiB-Betriebssystemdatenträger anfordern, wird diese Konfiguration standardmäßig auf kurzlebige Betriebssystemdatenträger festgelegt. Die angeforderte Größe von 60 GiB ist kleiner als der maximale temporäre Speicher von 75 GiB.

  • Wenn Sie den Tarif Standard_E4bds_v5 mit einem 100 GiB-Betriebssystemdatenträger verwenden möchten, unterstützt diese VM-Größe das kurzlebige Betriebssystem und hat einen temporären Speicher von 150 GiB. Wenn Sie den Betriebssystemdatenträgertyp nicht angeben, stellt Azure standardmäßig einen kurzlebigen Betriebssystemdatenträger für den Knotenpool bereit.

Vom Kunden verwaltete Schlüssel

Sie können die Verschlüsselung für Ihren kurzlebigen Betriebssystemdatenträger mit Ihren eigenen Schlüsseln in einem AKS-Cluster verwalten. Weitere Informationen finden Sie unter Verwenden des kundenseitig verwalteten Schlüssels mit Azure-Datenträgern auf AKS.

Volumes

Kubernetes behandelt einzelne Pods in der Regel als kurzlebige, verwerfbare Ressourcen. Anwendungen stehen verschiedene Methoden zur Verwendung und Beibehaltung von Daten zur Verfügung. Ein Volume ist eine Möglichkeit, Daten während des Lebenszyklus der Anwendung Pods übergreifend zu speichern, abzurufen und beizubehalten.

Herkömmliche Volumes werden als Kubernetes-Ressourcen erstellt, die von Azure Storage unterstützt werden. Sie können Datenvolumes manuell erstellen, damit sie Pods direkt zugewiesen werden, oder durch Kubernetes automatisch erstellen lassen. Datenvolumes können Azure-Datenträger, Azure Files, Azure NetApp Files oder Azure-Blobs verwenden.

Hinweis

Abhängig von der verwendeten VM-SKU kann der Azure Disk-CSI-Treiber ein Volumenlimit pro Knoten haben. Für einige leistungsstarke VMs (z. B. mit 16 Kernen) beträgt der Grenzwert 64 Volumes pro Knoten. Um das Limit pro VM-SKU zu ermitteln, überprüfen Sie die Spalte Max. Datenträger für jede angebotene VM-SKU. Eine Liste der angebotenen VM-SKUs mit deren entsprechenden detaillierten Kapazitätslimits finden Sie unter Universelle VM-Größen.

Um herauszufinden, ob sich Azure Files oder Azure NetApp Files für Ihre Workload am besten eignet, lesen Sie die Informationen im Artikel Vergleich von Azure Files und Azure NetApp Files.

Azure-Datenträger

Verwenden Sie Azure-Datenträger zum Erstellen einer Kubernetes-DataDisk-Ressource. Zu diesen Datenträgertypen gehören u. a.:

  • Ultra-Datenträger
  • SSD Premium-Datenträger
  • SSD Standard-Datenträger
  • HDD Standard-Datenträger

Tipp

Für die meisten Produktions- und Entwicklungsworkloads wird die Verwendung von SSD Premium empfohlen.

Da Azure-Datenträger als ReadWriteOnce eingebunden werden, sind sie nur für einen einzelnen Knoten verfügbar. Verwenden Sie für die Speichervolumes, auf die Pods auf mehreren Knoten gleichzeitig zugreifen können, Azure Files.

Azure Files

Verwenden Sie Azure Files, um eine SMB-Freigabe (Server Message Block) der Version 3.1.1 oder eine NFS-Freigabe (Network File System) der Version 4.1 in Pods einzubinden, die durch ein Azure-Speicherkonto gesichert ist. Mit Azure Files können Sie Daten für mehrere Knoten und Pods übergreifend freigeben und Folgendes verwenden:

  • Azure Storage Premium, von Hochleistungs-SSDs unterstützt
  • Azure Storage Standard, von regulären HDDs unterstützt

Azure NetApp Files

  • Storage Ultra
  • Storage Premium
  • Standardspeicher

Azure Blob Storage

Verwenden Sie Azure Blob Storage, um einen Blobspeichercontainer zu erstellen und diesen mit dem NFS v3.0-Protokoll oder BlobFuse einzubinden.

  • Blockblobs

Volumetypen

Kubernetes-Volumes stellen mehr als nur einen herkömmlichen Datenträger zum Speichern und Abrufen von Informationen dar. Kubernetes-Volumes können auch als Möglichkeit zum Einfügen von Daten in einen Pod zur Verwendung von den Containern genutzt werden.

Zu den üblichen Volumetypen in Kubernetes gehören:

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. Sobald Sie den Pod löschen, wird das Volume gelöscht. Dieses Volume verwendet in der Regel den zugrunde liegenden lokalen Knotendatenträger-Speicher, obwohl es auch nur im Arbeitsspeicher des Knotens vorhanden sein kann.

secret

secret-Volumes werden verwendet, um sensible Daten, wie z. B. Kennwörter, in Pods einzufügen.

  1. Erstellen Sie ein Geheimnis mit der Kubernetes-API.
  2. Definieren Sie Ihren Pod oder Ihre Bereitstellung, und fordern Sie ein bestimmtes Geheimnis an.
    • Geheimnisse werden nur für Knoten mit einem geplanten Pod bereitgestellt, der diese erfordert.
    • Das Geheimnis wird in tmpfs gespeichert und nicht auf den Datenträger geschrieben.
  3. Wenn Sie den letzten Pod auf einem Knoten löschen, der ein Geheimnis erfordert, wird das Geheimnis aus „tmpfs“ des Knotens gelöscht.
    • Geheimnisse werden in einem bestimmten Namespace gespeichert und sind nur für Pods im gleichen Namespace zugänglich.

configMap

Mit ConfigMap werden Schlüssel-Wert-Paar-Eigenschaften in Pods eingefügt, z. B. Informationen zur Anwendungskonfiguration. Definieren Sie Informationen zur Anwendungskonfiguration als eine Kubernetes-Ressource, die problemlos aktualisiert und auf neue Instanzen von Pods bei deren Bereitstellung angewendet werden kann.

Etwa mithilfe eines Geheimnisses:

  1. Erstellen Sie eine ConfigMap mithilfe der Kubernetes-API.
  2. Fordern Sie die ConfigMap an, wenn Sie einen Pod oder eine Bereitstellung definieren.
    • ConfigMaps werden in einem bestimmten Namespace gespeichert und nur Pods im gleichen Namespace können darauf zugreifen.

Persistente Volumes

Volumes, die als Teil des Podlebenszyklus definiert und erstellt werden, sind nur solange vorhanden, bis Sie den Pod löschen. 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 (PV) 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 Azure-Datenträger oder Azure Files zum Bereitstellen des persistenten Volumes verwenden. Wie im Abschnitt Volumes erwähnt, wird die Auswahl von Azure Disks oder Azure Files häufig von der Notwendigkeit des gleichzeitigen Zugriffs auf die Daten oder die Leistungsstufe bestimmt.

Persistent volumes in an Azure Kubernetes Services (AKS) cluster

Ein Clusteradministrator kann statisch ein PersistentVolume erstellen oder das Volume wird dynamisch vom Kubernetes-API-Server erstellt. Wenn ein Pod geplant ist und derzeit nicht verfügbaren Speicher anfordert, kann Kubernetes den zugrunde liegenden Azure Disk Storage oder Azure File Storage erstellen und dem Pod anfügen. Dynamische Bereitstellung verwendet eine StorageClass zum Identifizieren des Azure-Speichertyps, der erstellt werden muss.

Wichtig

Persistente Volumes können aufgrund von Unterschieden bei der Dateisystemunterstützung zwischen den beiden Betriebssystemen nicht von Windows- und Linux-Pods gemeinsam genutzt werden.

Speicherklassen

Sie können zum Definieren verschiedener Speicherstufen, z.B. „Premium“ und „Standard“, eine StorageClass erstellen.

Die StorageClass definiert auch die reclaimPolicy. Wenn Sie das persistente Volume löschen, steuert die reclaimPolicy das Verhalten der zugrunde liegenden Azure-Speicherressource. Die zugrunde liegende Speicherressource kann entweder gelöscht oder für die Verwendung mit einem zukünftigen Pod beibehalten werden.

Für Cluster, die die CSI-Treiber (Container Storage Interface) verwenden, werden die folgenden zusätzlichen StorageClasses erstellt:

Speicherklasse Beschreibung
managed-csi Verwendet lokal redundanten Azure SSD Standard-Speicher (LRS) zum Erstellen eines verwalteten Datenträgers. Mit der Freigaberichtlinie wird sichergestellt, dass der zugrunde liegende Azure Disk-Datenträger gelöscht wird, wenn das persistente Volume gelöscht wird, das ihn 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.
managed-csi-premium Verwendet lokal redundanten Azure Premium-Speicher (LRS) zum Erstellen eines verwalteten Datenträgers. Mit der Freigaberichtlinie wird wiederum sichergestellt, dass der zugrunde liegende Azure Disk-Datenträger gelöscht wird, wenn das persistente Volume gelöscht wird, das ihn verwendet hat. Zudem ermöglicht diese Speicherklasse auch eine Erweiterung von persistenten Volumes.
azurefile-csi Verwendet Azure Storage Standard zum Erstellen einer Azure-Dateifreigabe. Mit der Freigaberichtlinie wird sichergestellt, dass die zugrunde liegende Azure-Dateifreigabe gelöscht wird, wenn das persistente Volume gelöscht wird, das sie verwendet hat.
azurefile-csi-premium Verwendet Azure Storage Premium zum Erstellen einer Azure-Dateifreigabe. Mit der Freigaberichtlinie wird sichergestellt, dass die zugrunde liegende Azure-Dateifreigabe gelöscht wird, wenn das persistente Volume gelöscht wird, das sie verwendet hat.
azureblob-nfs-premium Azure Storage Premium wird verwendet, um einen Azure-Blobspeichercontainer zu erstellen und eine Verbindung über das NFS v3-Protokoll herzustellen. Mit der Freigaberichtlinie wird sichergestellt, dass der zugrunde liegende Azure-Blobspeichercontainer gelöscht wird, wenn das persistente Volume gelöscht wird, das ihn verwendet hat.
azureblob-fuse-premium Azure Storage Premium wird verwendet, um einen Azure-Blobspeichercontainer zu erstellen und mit BlobFuse eine Verbindung herzustellen. Mit der Freigaberichtlinie wird sichergestellt, dass der zugrunde liegende Azure-Blobspeichercontainer gelöscht wird, wenn das persistente Volume gelöscht wird, das ihn verwendet hat.

Sofern Sie keine StorageClass für ein persistentes Volume angeben, wird die Standard-StorageClass verwendet. Stellen Sie sicher, dass Sie beim Anfordern persistenter Volumes den entsprechenden Speicher verwenden.

Wichtig

Ab Kubernetes Version 1.21 verwendet AKS standardmäßig nur CSI-Treiber, und CSI-Migration ist aktiviert. Vorhandene persistente Volumes in der Struktur funktionieren zwar weiterhin, aber ab Version 1.26 unterstützt AKS keine Volumes mehr, die mit dem strukturinternen Treiber erstellt wurden, und auch keinen Speicher, der für Dateien und Datenträger bereitgestellt wird.

Die default-Klasse entspricht managed-csi.

Mit kubectl können Sie eine StorageClass für zusätzliche Anforderungen erstellen. Im folgenden Beispiel wird Managed Disks Premium verwendet und festgelegt, dass der zugrunde liegende Azure-Datenträger beim Löschen des Pods beibehalten werden soll:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_ZRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Hinweis

AKS stimmt die Standardspeicherklassen ab und überschreibt alle Änderungen, die Sie an diesen Speicherklassen vornehmen.

Weitere Informationen zu Speicherklassen finden Sie unter Speicherklassen in Kubernetes.

Ansprüche auf persistente Volumes

PersistentVolumeClaim fordert Speicher von einer bestimmten Speicherklasse (StorageClass), bestimmtem Zugriffsmodus und bestimmter Größe an. Der Kubernetes-API-Server kann die zugrunde liegende Azure-Speicherressource dynamisch bereitstellen, wenn keine vorhandene Ressource den Anspruch basierend auf der definierten StorageClass erfüllen kann.

Sobald die Verbindung des Volumes mit dem Pod hergestellt ist, enthält die Poddefinition die Volumebereitstellung.

Persistent volume claims in an Azure Kubernetes Services (AKS) cluster

Sobald dem anfordernden Pod eine verfügbare Speicherressource zugewiesen wurde, ist ein PersistentVolume an einen PersistentVolumeClaim gebunden. Persistente Volumes werden Ansprüchen 1:1 zugeordnet.

Das folgende Beispiel eines YAML-Manifests zeigt einen Anspruch eines persistenten Volumes, der die StorageClass managed-premium verwendet und einen Datenträger der Größe 5Gi anfordert:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-premium-retain
  resources:
    requests:
      storage: 5Gi

Wenn Sie eine Poddefinition erstellen, geben Sie auch Folgendes an:

  • Den Anspruch auf ein persistentes Volume zum Anfordern des gewünschten Speichers
  • volumeMount zum Lesen und Schreiben von Daten für Ihre Anwendungen

Das folgende Beispiel-YAML-Manifest zeigt, wie der vorherige Anspruch auf ein persistentes Volume verwendet werden kann, um ein Volume unter /mnt/azure einzubinden:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      volumeMounts:
      - mountPath: "/mnt/azure"
        name: volume
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: azure-managed-disk

Geben Sie zum Einbinden eines Volumes in einen Windows-Container den Laufwerkbuchstaben und Pfad an. Beispiel:

...      
       volumeMounts:
        - mountPath: "d:"
          name: volume
        - mountPath: "c:\k"
          name: k-dir
...

Nächste Schritte

Entsprechenden bewährte Methoden finden Sie unter Bewährte Methoden für die Speicherung und Sicherungen in AKS und Speicheraspekte für AKS.

Informationen zur Verwendung von CSI-Treibern finden Sie in den folgenden Anleitungen:

Weitere Informationen zu den wesentlichen Konzepten von Kubernetes und AKS finden Sie in den folgenden Artikeln: