Teilen über

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:

Diagramm der Speicheroptionen für Anwendungen in einem Azure Kubernetes Service-Cluster (AKS).

Standarddimensionierung von Betriebssystemdatenträgern

Wenn Sie einen neuen Cluster erstellen oder einen neuen Knotenpool zu einem vorhandenen Cluster hinzufügen, bestimmt die Anzahl der vCPUs standardmäßig die Größe des Betriebssystemdatenträgers. Die Anzahl der vCPUs basiert auf der VM-SKU. In der folgenden Tabelle ist die Standardgröße des Betriebssystemdatenträgers für jede VM-SKU aufgeführt:

VM-SKU-Kerne (vCPUs) Standardebene von Betriebssystemdatenträgern Bereitgestellte IOPS Bereitgestellter Durchsatz (MBit/s)
1 bis 7 P10/128G 500 100
8 bis 15 P15/256G 1100 125
16 bis 63 P20/512G 2300 150
mehr als 64 P30/1024G 5.000 200

Wichtig

Die Standarddimensionierung der Betriebssystemdatenträger wird nur für neue Cluster oder Knotenpools verwendet, wenn kurzlebige Betriebssystemdatenträger nicht unterstützt werden und keine Standardgröße für Betriebssystemdatenträger angegeben wird. Die Standardgröße des Betriebssystemdatenträgers kann sich auf die Leistung oder die Kosten Ihres Clusters auswirken. Sie können die Größe des Betriebssystemdatenträgers nach der Erstellung von Cluster- oder Knotenpools nicht ändern. Diese Standarddatenträgergröße wirkt sich auf Cluster oder Knotenpools aus, die ab Juli 2022 erstellt wurden.

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.:

  • SSD Premium (empfohlen für die meisten Workloads)
  • Ultra-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 Freigabe mit SMB Version 3.1.1 (Server Message Block) oder mit NFS Version 4.1 (Network File System) bereitzustellen. 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 durch seine Container 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 die folgenden Azure Storage-Datendienste verwenden, um das persistente Volume bereitzustellen:

Wie im Abschnitt Volumes beschrieben, wird die Auswahl von Azure Disks oder Azure Files häufig von der Notwendigkeit des gleichzeitigen Zugriffs auf die Daten oder die Leistungsstufe bestimmt.

Diagramm der persistenten Volumes in einem Azure Kubernetes Service-Cluster (AKS).

Clusteradministratorinnen und -adminstratoren können statisch ein persistentes Volume erstellen. Das Volume kann aber auch dynamisch vom Kubernetes-API-Server erstellt werden. Wenn ein Pod geplant ist und derzeit nicht verfügbaren Speicher anfordert, kann Kubernetes den zugrunde liegenden Azure Disks- oder Azure Files-Speicher erstellen und an den Pod anfügen. Bei der dynamischen Bereitstellung wird eine Speicherklasse zum Identifizieren des zu erstellenden Ressourcentyps verwendet.

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

Um verschiedene Speicherebenen anzugeben, z. B. Premium oder Standard, können Sie eine Speicherklasse erstellen.

Eine Speicherklasse definiert auch eine Freigaberichtlinie. Wenn Sie das persistente Volume löschen, steuert die Freigaberichtlinie das Verhalten der zugrunde liegenden Azure Storage-Ressource. Die zugrunde liegende Ressource 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 Speicherklassen 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. Die Speicherklasse konfiguriert auch die persistenten Volumes als erweiterbar. Sie können den Anspruch für das persistente Volume bearbeiten, um die neue Größe anzugeben. Ab Kubernetes-Version 1.29 nutzt diese Speicherklasse in Azure Kubernetes Service (AKS)-Clustern, die über mehrere Verfügbarkeitszonen bereitgestellt werden, Azure SSD Stern Zone-Redundant Storage (ZRS), um verwaltete Datenträger zu erstellen.
managed-csi-premium Verwendet lokal redundanten Azure Premium-Speicher (LRS) zum Erstellen eines verwalteten Datenträgers. Mit der Freigaberichtlinie wird wieder 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. Ab Kubernetes-Version 1.29 nutzt diese Speicherklasse in Azure Kubernetes Service (AKS)-Clustern, die über mehrere Verfügbarkeitszonen bereitgestellt werden, Azure Premium Zone-Redundant Storage (ZRS), um verwaltete Datenträger zu erstellen.
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 Speicherklasse für ein persistentes Volume angeben, wird die Standardspeicherklasse 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.

Ab Kubernetes-Version 1.29 verwendet AKS bei der Bereitstellung von Azure Kubernetes Service (AKS)-Clustern über mehrere Verfügbarkeitszonen hinweg jetzt zonenredundanten Speicher (ZRS), um verwaltete Datenträger innerhalb integrierter Speicherklassen zu erstellen. ZRS stellt die synchrone Replikation Ihrer von Azure verwalteten Datenträger in mehreren Azure-Verfügbarkeitszonen in Ihrer ausgewählten Region sicher. Diese Redundanzstrategie verbessert die Resilienz Ihrer Anwendungen und schützt Ihre Daten vor Rechenzentrumsfehlern.

Es ist jedoch wichtig zu beachten, dass zonenredundanter Speicher (ZRS) im Vergleich zu lokal redundantem Speicher (LRS) höhere Kosten verursacht. Wenn die Kostenoptimierung Priorität hat, können Sie eine neue Speicherklasse erstellen, wobei der Parameter skuname auf LRS festgelegt ist. Anschließend können Sie die neue Speicherklasse in Ihrem Persistent Volume Claim (PVC) verwenden.

Mit kubectl können Sie eine Speicherklasse 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

Ein Anspruch für ein persistentes Volume (Persistent Volume Claim, PVC) fordert die Speicherung einer bestimmten Speicherklasse, eines Zugriffsmodus und einer Größe an. Der Kubernetes-API-Server kann die zugrunde liegende Azure Storage-Ressource dynamisch bereitstellen, wenn keine vorhandene Ressource den Anspruch basierend auf der definierten Speicherklasse erfüllen kann.

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

Diagramm der Ansprüche auf persistente Volumes in einem Azure Kubernetes Service-Cluster (AKS).

Nachdem dem anfordernden Pod eine verfügbare Speicherressource zugewiesen wurde, ist das persistente Volume an einen Anspruch für das persistente Volume gebunden. Persistente Volumes werden Ansprüchen direkt zugeordnet (1:1-Zuordnung).

Das folgende Beispiel eines YAML-Manifests zeigt einen Anspruch für ein persistentes Volume, der die Speicherklasse managed-premium verwendet und einen Azure-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
  • Die Volumebereitstellung 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: