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

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:

• Volumes
• Persistente Volumes
• Speicherklassen
• Ansprüche auf persistente Volumes

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:

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.

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.

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

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:

• Azure Disk
• Azure Files
• Azure Container Storage (Vorschau).

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.

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.

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:

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.

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

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.

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:

• CSI-Treibern (Container Storage Interface) für Azure-Datenträger, Azure Files und Azure Blob Storage in Azure Kubernetes Service
• Verwenden des CSI-Treibers für Azure-Datenträger in Azure Kubernetes Service
• Verwenden des CSI-Treibers von Azure Files in Azure Kubernetes Service
• Verwenden des CSI-Treibers von Azure Blob Storage in Azure Kubernetes Service
• Konfigurieren von Azure NetApp Files in Azure Kubernetes Service

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

• Kubernetes/AKS: Cluster und Workloads
• Kubernetes/AKS: Identität
• Kubernetes/AKS: Sicherheit
• Kubernetes/AKS: virtuelle Netzwerke
• Kubernetes/AKS: Skalierung