Freigeben über

Speicheroptionen für einen Kubernetes-Cluster

In diesem Artikel werden die Speicherfunktionen von Amazon Elastic Kubernetes Service (EKS) und Azure Kubernetes Service (AKS) verglichen. Außerdem werden Speicheroptionen für Workloaddaten auf AKS beschrieben.

Hinweis

Dieser Artikel ist Teil einer Reihe von Artikeln , die Fachleuten helfen, die mit Amazon EKS vertraut sind, Azure Kubernetes Service (AKS) zu verstehen.

Amazon EKS-Speicheroptionen

Amazon EKS bietet verschiedene Arten von Speichervolumes für Anwendungen, die Datenspeicherung erfordern. Sie können diese Volumes für temporäre und langlebige Speicher verwenden.

Vergängliche Bände

Für Anwendungen, die temporäre lokale Volumes benötigen, bei denen die Daten aber nicht nach Neustarts erhalten bleiben müssen, verwenden Sie flüchtige Volumes. Kubernetes unterstützt verschiedene Arten von ephemeren Volumes, z. B. emptyDir, ConfigMap, downwardAPI, secret und hostPath. Um Kosteneffizienz und Leistung sicherzustellen, wählen Sie das am besten geeignete Hostvolume aus. In Amazon EKS können Sie gp3 als Hoststammvolume verwenden, was weniger als gp2-Volumes kostet.

Sie können auch Amazon EC2-Instanzspeicher verwenden, die temporären Speicher auf Blockebene für EC2-Instanzen bereitstellen. Diese Volumes werden physisch an die Hosts angeschlossen und sind nur während der Lebensdauer der Instanz verfügbar. Um lokale Speichervolumes in Kubernetes zu verwenden, müssen Sie die Datenträger mithilfe von Amazon EC2-Benutzerdaten partitionieren, konfigurieren und formatieren.

Persistente Volumes

In der Regel verwenden Sie Kubernetes, um zustandslose Anwendungen auszuführen, aber manchmal benötigen Sie beständigen Datenspeicher. Sie können Kubernetes persistente Volumes verwenden, um Daten unabhängig von Pods zu speichern, sodass die Daten über die Lebensdauer eines bestimmten Pods hinaus bestehen können. Amazon EKS unterstützt verschiedene Arten von Speicheroptionen für persistente Volumes, darunter Amazon EBS, Amazon Elastic File System (EFS), Amazon FSx für Lustre und Amazon FSx für NetApp ONTAP.

Verwenden Sie Amazon EBS-Volumes für den Speicher auf Blockebene und für Datenbanken und Durchsatzintensive Anwendungen. Amazon EKS-Benutzer können die neueste Generation von Blockspeicher gp3 für ein Gleichgewicht zwischen Preis und Leistung verwenden. Für Anwendungen mit höherer Leistung können Sie io2 Block Express-Volumes verwenden.

Amazon EFS ist ein serverloses, elastisches Dateisystem, das Sie über mehrere Container und Knoten hinweg freigeben können. Sie wird automatisch vergrößert und verkleinert, wenn Dateien hinzugefügt oder entfernt werden, was eine Kapazitätsplanung überflüssig macht. Der Amazon EFS Container Storage Interface (CSI)-Treiber integriert Amazon EFS in Kubernetes.

Amazon FSx für Lustre bietet leistungsstarke parallele Dateispeicherung. Verwenden Sie diesen Speichertyp für Szenarien, die einen hohen Durchsatz und Vorgänge mit geringer Latenz erfordern. Sie können diesen Dateispeicher mit einem Amazon S3-Daten-Repository verknüpfen, um große Datasets zu speichern. Amazon FSx für NetApp ONTAP ist eine vollständig verwaltete, gemeinsam genutzte Speicherlösung, die auf dem ONTAP-Dateisystem von NetApp basiert.

Verwenden Sie Tools wie AWS Compute Optimizer und Velero, um Speicherkonfigurationen zu optimieren und Sicherungen und Snapshots zu verwalten.

AKS-Speicheroptionen

Anwendungen, die in AKS ausgeführt werden, müssen möglicherweise Daten speichern und abrufen. Einige Anwendungsworkloads können lokalen, schnellen Speicher auf nicht benötigten, leeren Knoten verwenden. Andere Anwendungsworkloads erfordern jedoch Speicher, der auf regelmäßigeren Datenvolumes innerhalb der Azure-Plattform beibehalten wird. Mehrere Pods könnten dies benötigen:

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

In den folgenden Abschnitten werden die Speicheroptionen und Kernkonzepte vorgestellt, die Speicher für Ihre Anwendungen in AKS bereitstellen.

Volumetypen

Kubernetes-Volumes stellen mehr als nur einen herkömmlichen Datenträger zum Speichern und Abrufen von Informationen dar. Sie können auch Kubernetes Volumes verwenden, um Daten in einen Pod zu injizieren, die dann von den Containern verwendet werden können.

Allgemeine Volumetypen in Kubernetes umfassen emptyDirs, secrets und ConfigMaps.

EmptyDirs

Bei einem Pod, der ein emptyDir-Volume definiert, wird das Volume erstellt, wenn der Pod einem Knoten zugewiesen wird. Wie der Name schon sagt, ist das emptyDir-Volume zunächst leer. Alle Container im Pod können die gleichen Dateien im emptyDir-Volume lesen und schreiben, obwohl dieses Volume auf denselben oder unterschiedlichen Pfaden in jedem Container montiert werden kann. Wenn ein Pod aus irgendeinem Grund aus einem Knoten entfernt wird, werden die Daten im emptyDir dauerhaft gelöscht.

Geheimnisse

Ein Geheimschlüssel ist ein Objekt, das eine kleine Menge vertraulicher Daten enthält, z. B. ein Kennwort, ein Token oder einen Schlüssel. Wenn Sie keinen geheimen Schlüssel verwenden, sind diese Informationen in einer Podspezifikation oder einem Containerimage enthalten. Ein geheimer Schlüssel verhindert, dass vertrauliche Daten direkt in Den Anwendungscode eingebettet werden müssen. Sie können Secrets unabhängig von den Pods erstellen, die sie verwenden. Diese Vorgehensweise reduziert das Risiko, dass beim Erstellen, Anzeigen und Bearbeiten von Pods das Geheimnis und die zugehörigen Daten verfügbar sind. Kubernetes und die Anwendungen, die in Ihrem Cluster ausgeführt werden, können mit Secrets zusätzliche Vorsichtsmaßnahmen ergreifen, sodass z. B. verhindert wird, dass vertrauliche Daten in nichtflüchtigen Storage geschrieben werden. Geheime Schlüssel ähneln ConfigMaps, sind jedoch speziell darauf ausgelegt, vertrauliche Daten zu speichern.

Sie können geheime Schlüssel für die folgenden Zwecke verwenden:

Die Kubernetes-Steuerungsebene verwendet auch geheime Schlüssel wie Bootstrap-Tokenschlüssel, um die Knotenregistrierung zu automatisieren.

ConfigMaps

Bei einer ConfigMap handelt es sich um ein Kubernetes-Objekt, das Sie verwenden, um nichtkonfidentiale Daten in Schlüsselwertpaaren zu speichern. Pods können ConfigMaps als Umgebungsvariablen, als Befehlszeilenargumente oder als Konfigurationsdateien in einem Volume konsumieren. Sie können eine ConfigMap verwenden, um umgebungsspezifische Konfigurationen von Ihren Containerimages zu entkoppeln, wodurch Ihre Anwendungen problemlos portierbar sind.

ConfigMaps bieten keine Geheimhaltung oder Verschlüsselung. Wenn Sie vertrauliche Daten speichern möchten, verwenden Sie einen geheimen Schlüssel anstelle einer ConfigMap, oder verwenden Sie andere Partnertools, um Ihre Daten privat zu halten.

Sie können eine ConfigMap verwenden, um Konfigurationsdaten separat vom Anwendungscode festzulegen. Sie können z. B. eine Anwendung entwickeln, die auf Ihrem Computer für die Entwicklung ausgeführt und in der Cloud ausgeführt werden kann, um echten Datenverkehr zu verarbeiten. Sie können den Code schreiben, um in einer Umgebungsvariable mit dem Namen DATABASE_HOSTzu suchen. Legen Sie diese Variable lokal auf localhost. Legen Sie in der Cloud fest, dass er auf einen Kubernetes-Dienst verweist, der die Datenbankkomponente für Ihren Cluster verfügbar macht. Mit diesem Ansatz können Sie ein Containerimage abrufen, das in der Cloud ausgeführt wird, und bei Bedarf denselben Code lokal debuggen.

Persistente Volumes

Volumes, die als Teil des Pod-Lebenszyklus definiert und erstellt werden, sind nur 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 ist eine Speicherressource, die die Kubernetes-API erstellt und verwaltet. Ein persistentes Volume kann über die Lebensdauer eines einzelnen Pods hinaus bestehen. Sie können die folgenden Azure Storage-Tools verwenden, um das persistente Volume bereitzustellen:

Um zwischen Azure-Datenträgerspeicher oder Azure Files zu entscheiden, überlegen Sie, ob Ihre Anwendung gleichzeitigen Datenzugriff oder eine bestimmte Leistungsstufe benötigt.

Diagramm der persistenten Volumes in einem AKS-Cluster.

Ein Clusteradministrator kann statisch ein persistentes Volume erstellen, oder der Kubernetes-API-Server kann dynamisch ein Volume erstellen. Wenn ein Pod geplant ist und Speicher anfordert, der derzeit nicht verfügbar ist, kann Kubernetes den zugrunde liegenden Azure-Datenträger oder Dateispeicher erstellen und an den Pod anfügen. Bei der dynamischen Bereitstellung wird eine Speicherklasse zum Identifizieren des zu erstellenden Ressourcentyps verwendet.

Wichtig

Windows- und Linux-Pods können keine persistenten Volumes freigeben, da die Betriebssysteme unterschiedliche Dateisysteme unterstützen.

Wenn Sie eine vollständig verwaltete Lösung für den Zugriff auf Daten auf Blockebene benötigen, sollten Sie Azure Container Storage anstelle von CSI-Treibern verwenden. Azure Container Storage ist in Kubernetes integriert, um dynamische und automatische Bereitstellung persistenter Volumes bereitzustellen. Azure Container Storage unterstützt Azure-Datenträger, kurzlebige Datenträger und Azure Elastic SAN (Vorschau) als Sicherungsspeicher. Diese Optionen bieten Flexibilität und Skalierbarkeit für zustandsbehaftete Anwendungen, die auf Kubernetes-Clustern ausgeführt 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 ein persistentes Volume löschen, steuert die Zurückforderungsrichtlinie 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.

Cluster, die Azure Container Storage verwenden, weisen eine zusätzliche Speicherklasse auf acstor-<storage-pool-name>. Außerdem wird eine interne Speicherklasse erstellt.

Für Cluster, die CSI-Treiber verwenden, werden die folgenden zusätzlichen Speicherklassen erstellt:

Speicherklasse BESCHREIBUNG
managed-csi Verwendet Azure Standard SSD mit lokal redundantem Speicher (LRS), um einen verwalteten Datenträger zu erstellen. Die Richtlinie für die Zurückforderung stellt sicher, dass der zugrunde liegende Azure-Datenträger gelöscht wird, wenn das dauerhafte Volumen, das es genutzt hat, gelöscht wird. Die Speicherklasse konfiguriert auch die persistenten Volumes als erweiterbar. Sie können das PersistentVolumeClaim bearbeiten, um die neue Größe anzugeben.

Für Kubernetes Version 1.29 und höher verwendet diese Speicherklasse Standard-SSD mit zonenredundanten Speicher (ZRS), um verwaltete Datenträger für AKS-Cluster zu erstellen, die in mehreren Verfügbarkeitszonen bereitgestellt werden.
managed-csi-premium Verwendet Azure Premium SSD mit LRS zum Erstellen eines verwalteten Datenträgers. Die Richtlinie für die Zurückforderung stellt sicher, dass der zugrunde liegende Azure-Datenträger gelöscht wird, wenn das dauerhafte Volumen, das es genutzt hat, gelöscht wird. Mit dieser Speicherklasse können persistente Volumes erweitert werden.

Für Kubernetes, Version 1.29 und höher, verwendet diese Speicherklasse Premium-SSD mit ZRS, um verwaltete Datenträger für AKS-Cluster zu erstellen, die in mehreren Verfügbarkeitszonen bereitgestellt werden.
azurefile-csi Verwendet den Standard-SSD-Speicher, um eine Azure-Dateifreigabe zu erstellen. 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 Premium-SSD-Speicher, um eine Azure-Dateifreigabe zu erstellen. 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 Verwendet Premium-SSD-Speicher, um einen Blob Storage-Container zu erstellen und eine Verbindung über das Network File System (NFS) v3-Protokoll herzustellen. Die Richtlinie zur Zurückforderung stellt sicher, dass der zugrunde liegende Blob Storage-Container gelöscht wird, wenn das persistente Volume, das ihn verwendet hat, gelöscht wird.
azureblob-fuse-premium Verwendet Premium-SSD-Speicher, um einen Blob Storage-Container zu erstellen und über BlobFuse eine Verbindung herzustellen. Die Richtlinie zur Zurückforderung stellt sicher, dass der zugrunde liegende Blob Storage-Container gelöscht wird, wenn das persistente Volume, das ihn verwendet hat, gelöscht wird.

Sofern Sie keine Speicherklasse für ein persistentes Volume angeben, wird die Standardspeicherklasse verwendet. Stellen Sie sicher, dass Volumes den benötigten Speicher verwenden, wenn Sie persistente Volumes anfordern.

Wichtig

Für Kubernetes, Version 1.21 und höher, verwendet AKS standardmäßig CSI-Treiber, und die CSI-Migration ist aktiviert. Bestehende persistente In-Tree-Volumes funktionieren weiterhin, aber ab Version 1.26 unterstützt AKS keine Volumes mehr, die mithilfe des In-Tree-Treibers sowie Speicher, der für Dateien und Datenträger bereitgestellt wird, erstellt wurden.

Die default Klasse ist identisch mit der managed-csi Klasse.

Bei Kubernetes, Version 1.29 und höher, wenn Sie AKS-Cluster in mehreren Verfügbarkeitszonen bereitstellen, verwendet AKS ZRS, um verwaltete Datenträger in integrierten 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.

ZRS kostet jedoch mehr als LRS. Wenn die Kostenoptimierung eine Priorität hat, können Sie eine neue Speicherklasse erstellen, die den skuname Parameter auf LRS festgelegt hat. Anschließend können Sie die neue Speicherklasse in Ihrem dauerhaften Volumeanspruch verwenden.

Mithilfe von kubectl können Sie eine Speicherklasse für andere Anforderungen erstellen. Im folgenden Beispiel werden premiumverwaltete Datenträger verwendet und angegeben, dass der zugrunde liegende Azure-Datenträger beibehalten werden soll, wenn Sie den Pod löschen:

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

AKS versöhnt die Standardspeicherklassen und überschreibt alle Änderungen, die Sie an diesen Speicherklassen vornehmen.

Weitere Informationen finden Sie unter StorageClass in Kubernetes.

Ansprüche auf persistente Volumes

Ein persistenter Volumeanspruch fordert den Speicher einer bestimmten Speicherklasse, des Zugriffsmodus und der 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.

Die Pod-Definition enthält die Einbindung des Volumes, nachdem das Volume mit dem Pod verbunden wurde.

Diagramm der Claims für persistente Volumes in einem AKS Cluster.

Nachdem dem Pod eine verfügbare Speicherressource zugewiesen wurde, die Speicher anfordert, wird das persistente Volume an einen dauerhaften Volumeanspruch gebunden . Jedes persistente Volume ist einem beständigen Volumeanspruch zugeordnet, um dedizierten Speicher sicherzustellen.

Das folgende Beispiel für das YAML-Manifest zeigt ein persistentes Volume, das die managed-premium Speicherklasse verwendet und einen Azure-Datenträger anfordert, der eine Größe von 5Gi hat.

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 YAML-Manifest-Beispiel zeigt, wie der vorherige persistente Volume-Claim ein Volume unter /mnt/azure mounten kann:

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

Um ein Volume in einem Windows-Container zu mounten, geben Sie den Laufwerksbuchstaben und den Pfad an:

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

Kurzlebiger Betriebssystemdatenträger

Standardmäßig repliziert Azure automatisch den Betriebssystemdatenträger für einen virtuellen Computer (VM) in Azure Storage, um Datenverluste zu vermeiden, wenn der virtuelle Computer auf einen anderen Host verschoben wird. Container sind jedoch nicht so konzipiert, dass der lokale Zustand beibehalten wird, sodass dieses Verhalten begrenzte Werte und Nachteile bietet. Zu diesen Nachteilen gehören die langsamere Bereitstellung von Knoten und eine höhere Lese- und Schreiblatenz.

Im Gegensatz dazu werden kurzlebige Betriebssystemdatenträger nur auf dem Hostcomputer gespeichert, z. B. auf einem temporären Datenträger. Diese Konfiguration bietet niedrigere Lese- und Schreiblatenz und schnellere Knotenskalierung und Clusterupgrades.

Wenn Sie keine von Azure verwalteten Datenträger für das Betriebssystem anfordern, verwendet AKS standardmäßig kurzlebige Betriebssystemdatenträger, falls möglich für eine bestimmte Knotenpoolkonfiguration.

Informationen zu Größenanforderungen und Empfehlungen finden Sie unter Ephemeral-Betriebssystemdatenträger für Azure-VMs. Berücksichtigen Sie die folgenden Größenüberlegungen:

  • Wenn Sie die AKS-Standard-VM-Größe Standard_DS2_v2 SKU mit der Standardgröße des Betriebssystemdatenträgers von 100 GiB verwenden, unterstützt die standardgröße der VM ephemerale Betriebssystemdatenträger, verfügt jedoch nur über eine Cachegröße von 86 GiB. Diese Konfiguration wird standardmäßig auf verwalteten Datenträgern festgelegt, wenn Sie sie nicht angeben. Wenn Sie einen kurzlebigen Betriebssystemdatenträger anfordern, erhalten Sie einen Überprüfungsfehler.

  • Wenn Sie dieselbe Standard_DS2_v2 SKU 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 die maximale Cachegröße von 86 GiB.

  • Wenn Sie die Standard_D8s_v3 SKU mit einem Betriebssystemdatenträger von 100 GB auswählen, unterstützt diese VM-Größe kurzlebige Betriebssystemdatenträger und verfügt über eine Cachegröße von 200 GiB. Wenn Sie den Betriebssystemdatenträgertyp nicht angeben, empfängt der Knotenpool standardmäßig kurzlebige Betriebssystemdatenträger.

Die neueste Generation der VM-Serie verfügt nicht über einen dedizierten Cache und verfügt nur über temporären Speicher.

  • Wenn Sie die größe der Standard_E2bds_v5 VM mit der Standardgröße des Betriebssystemdatenträgers von 100 GiB auswählen, unterstützt die VM kurzlebige Betriebssystemdatenträger, verfügt jedoch nur über 75 GB temporären Speicher. Diese Konfiguration wird standardmäßig auf verwalteten Betriebssystemdatenträgern festgelegt, wenn Sie sie nicht angeben. Wenn Sie einen kurzlebigen Betriebssystemdatenträger anfordern, erhalten Sie einen Überprüfungsfehler.

  • Wenn Sie dieselbe Standard_E2bds_v5 VM-Größe 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 die Standard_E4bds_v5-SKU mit einem 100-GiB-Betriebssystemdatenträger auswählen, unterstützt diese VM-Größe kurzlebige Betriebssystemdatenträger und verfügt über 150 GiB temporären Speicher. Wenn Sie den Betriebssystemdatenträgertyp nicht angeben, stellt Azure einen kurzlebigen Betriebssystemdatenträger im Knotenpool bereit.

Vom Kunden verwaltete Schlüssel

Sie können die Verschlüsselung für Ihren kurzlebigen Betriebssystemdatenträger verwalten, indem Sie ihre eigenen Schlüssel auf einem AKS-Cluster verwenden. Weitere Informationen finden Sie unter Bringen Sie Ihre eigenen Schlüssel mit von Azure verwalteten Datenträgern in AKS.

Volumina

Kubernetes behandelt einzelne Pods in der Regel als kurzlebige, austauschbare Ressourcen. Anwendungen haben unterschiedliche Ansätze zum Verwenden und Speichern von Daten. Ein Volume stellt eine Möglichkeit dar, Daten über Pods hinweg während des Lebenszyklus der Anwendung zu speichern, abzurufen und aufrechtzuerhalten.

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ägerspeicher, Azure Files, Azure NetApp-Dateien oder Blob Storage verwenden.

Hinweis

Je nach VM-SKU verfügt der Azure-Datenträger-CSI-Treiber möglicherweise über ein Volumenlimit für jeden Knoten. Bei einigen leistungsstarken VMs, z. B. 16 Kernen, beträgt der Grenzwert 64 Volumes pro Knoten. Um den Grenzwert pro VM-SKU zu identifizieren, überprüfen Sie die Spalte "Max. Datenträger" für jede VM-SKU. Eine Liste der VM-SKUs und deren entsprechende Kapazitätsgrenzwerte finden Sie unter "Allgemeine VM-Größen".

Informationen zur Entscheidung zwischen Azure Files und Azure NetApp Files finden Sie im Vergleich zu Azure Files und Azure NetApp Files.

Azure-Datenträgerspeicher

Standardmäßig verfügt ein AKS-Cluster über vordefinierte managed-csi Klassen und managed-csi-premium Speicherklassen, die Azure-Datenträgerspeicher verwenden. Ähnlich wie bei Amazon EBS werden diese Klassen erstellt, um einen verwalteten Datenträger oder ein Blockgerät bereitzustellen, das für den Zugriff durch Pods an den Knoten angebunden wird.

Die Datenträgerklassen ermöglichen sowohl die Bereitstellung statischer als auch dynamischer Volumes. Die Zurückforderungsrichtlinie stellt sicher, dass der Datenträger mit dem persistenten Volume gelöscht wird. Um den Datenträger zu erweitern, bearbeiten Sie den Claim für das persistente Volume.

Diese Speicherklassen verwenden von Azure verwaltete Datenträger mit LRS. Daten in LRS verfügen über drei synchrone Kopien innerhalb eines einzelnen physischen Standorts in einer primären Azure-Region. LRS ist die am wenigsten teure Replikationsoption, bietet jedoch keinen Schutz vor einem Rechenzentrumsfehler. Sie können benutzerdefinierte Speicherklassen definieren, die verwaltete ZRS-Datenträger verwenden.

ZRS repliziert Ihren von Azure verwalteten Datenträger synchron in drei Azure-Verfügbarkeitszonen in Ihrer Region. Jede Verfügbarkeitszone ist ein separater physischer Standort, der über unabhängige Leistung, Kühlung und Netzwerk verfügt. ZRS-Datenträger bieten eine Zuverlässigkeit von mindestens 99,9999999999 % über ein Jahr. Ein von ZRS verwalteter Datenträger kann von einem virtuellen Computer in einer anderen Verfügbarkeitszone angefügt werden. ZRS-Datenträger sind in allen Azure-Regionen nicht verfügbar. Weitere Informationen finden Sie unter ZRS-Optionen für Azure-Datenträger zur Verbesserung der Verfügbarkeit.

Um das Risiko eines Datenverlusts zu verringern, verwenden Sie die AKS-Sicherung , um regelmäßige Sicherungen oder Momentaufnahmen von Datenträgerspeicherdaten zu erstellen. Sie können auch Partnerlösungen wie Velero oder Azure Backup verwenden, die über integrierte Snapshot-Technologie verfügen.

Sie können azure disk storage verwenden, um eine Kubernetes DataDisk-Ressource zu erstellen. Sie können die folgenden Datenträgertypen verwenden:

Tipp

Verwenden Sie für die meisten Produktions- und Entwicklungsworkloads Premium SSD.

Ein Azure-Datenträger wird als ReadWriteOnce bereitgestellt, sodass er nur für einen einzelnen Knoten verfügbar ist. Verwenden Sie für Speichervolumes, auf die auf mehreren Knoten gleichzeitig zugegriffen werden kann, Azure Files.

SSD Premium v2-Datenträger

Premium SSD v2-Datenträger sind für eingabe-/output(I/O)-intensive Unternehmensworkloads ausgelegt. Sie bieten konsistente Submillisekunden-Datenträgerlatenz, hohe Eingabe-/Ausgabevorgänge pro Sekunde (IOPS) und hohen Durchsatz. Sie können die Leistung (Kapazität, IOPS und Durchsatz) von Premium SSD v2-Datenträgern jederzeit unabhängig konfigurieren. Sie können die Kosteneffizienz also einfach verbessern, während Sie die Leistungsanforderungen erfüllen. Weitere Informationen zum Konfigurieren eines neuen oder vorhandenen AKS-Clusters für die Verwendung von Azure Premium SSD v2-Datenträgern finden Sie unter Verwenden von Premium SSD v2-Datenträgern auf AKS.

Ultra-Disk-Speicher

Ultra Disk Storage ist eine azure-verwaltete Datenträgerebene, die hohen Durchsatz, hohe IOPS und konsistenten Datenträgerspeicher mit geringer Latenz für Azure-VMs bereitstellt. Verwenden Sie Ultra Disk Storage für datenintensive und transaktionsintensive Workloads. Wie andere Datenträgerspeicher-SKUs und Amazon EBS bindet Ultra Disk Storage jeweils nur einen Pod ein und bietet keinen gleichzeitigen Zugriff.

Verwenden Sie das Flag, um --enable-ultra-ssd.

Beachten Sie die Einschränkungen des Ultra Disk Storage, und wählen Sie eine kompatible VM-Größe aus. Ultra Disk Storage verfügt über LRS-Replikation.

Bringen Sie Ihre eigenen Schlüssel (BYOK)

Azure verschlüsselt alle Daten auf einem ruhenden verwalteten Datenträger, einschließlich des Betriebssystems und der Datenträger eines AKS-Clusters. Standardmäßig werden Daten mit von Microsoft verwalteten Schlüsseln verschlüsselt. Um mehr Kontrolle über Verschlüsselungsschlüssel zu erhalten, können Sie vom Kunden verwaltete Schlüssel bereitstellen, um ruhende Verschlüsselung sowohl für das Betriebssystem als auch für Datenträger in AKS-Clustern bereitzustellen. Weitere Informationen finden Sie unter BYOK mit von Azure verwalteten Datenträgern in AKS und serverseitiger Verschlüsselung von Azure-Datenträgerspeicher.

Azure Files

Datenträgerspeicher kann keinen gleichzeitigen Zugriff auf ein Volume bieten, Sie können jedoch Azure Files verwenden, um eine Server message Block (SMB)-Version 3.1.1-Freigabe oder NFS-Version 4.1-Freigabe bereitzustellen, die von Azure Storage unterstützt wird. Dieser Prozess bietet netzwerkgebundenen Speicher, der Amazon EFS ähnelt. Azure Files verfügt über zwei Speicheroptionen:

  • Azure Files Standard Storage sichert die Datenträgerfreigabe mit regulären Festplatten (HDDs).

  • Der Azure Files Premium-Speicher stützt die Dateifreigabe mit leistungsstarken SSDs (Solid-State-Drives). Die Mindestgröße der Dateifreigabe für Premium beträgt 100 GB.

Azure Files verfügt über die folgenden Speicherkontoreplikationsoptionen, um Ihre Daten zu schützen, wenn ein Fehler auftritt:

Um die Kosten für Azure Files zu optimieren, kaufen Sie Azure Files-Kapazitätsreservierungen.

Azure NetApp-Dateien

Azure NetApp Files ist ein unternehmensgerechter, hochleistungsfähiger, nutzungsbasierter Dateispeicherdienst, der auf Azure läuft und Volumes durch die Verwendung von NFS (NFSv3 oder NFSv4.1), SMB und Dual-Protokoll (NFSv3 und SMB oder NFSv4.1 und SMB) unterstützt. Im Hinblick auf die Verwendung von Azure NetApp Files-Volumes für Kubernetes-Workloads stehen Kubernetes-Benutzer*innen zwei Optionen zur Verfügung:

  • Erstellen Sie Azure NetApp Files-Volumes statisch. Erstellen Sie Volumes außerhalb von AKS über die Azure CLI oder das Azure-Portal. Nach der Erstellung werden diese Volumes für Kubernetes zur Verfügung gestellt, indem ein PersistentVolume erstellt wird. Statisch erstellte Azure NetApp Files-Volumes weisen viele Einschränkungen auf. Sie können beispielsweise nicht erweitert werden und müssen überprovisioniert werden. Es wird nicht empfohlen, statisch erstellte Volumes für die meisten Anwendungsfälle zu erstellen.

  • Erstellen Sie Azure NetApp Files-Volumes dynamisch über Kubernetes. Dies ist die bevorzugte Methode, um mehrere Volumes direkt über Kubernetes mithilfe von Astra Trident zu erstellen. Astra Trident ist ein CSI-kompatibler dynamischer Speicherorchestrator, der bei der nativen Bereitstellung von Volumes über Kubernetes hilft.

Weitere Informationen finden Sie unter Konfigurieren von Azure NetApp-Dateien für AKS.

Blob-Speicher

Der Blob Storage CSI-Treiber ist ein CSI-spezifikationskonformer Treiber, den AKS zum Verwalten des Lebenszyklus von Blob Storage verwendet. CSI ist ein Standard für die Bereitstellung beliebiger Block- und Dateispeichersysteme für containerisierte Workloads in Kubernetes.

Führen Sie den CSI ein und verwenden Sie ihn, damit AKS Plug-Ins schreiben, bereitstellen und iterieren kann. Die Plug-Ins können neue Speichersysteme einführen oder vorhandene Speichersysteme in Kubernetes verbessern. CSI-Treiber in AKS vermeiden die Notwendigkeit, den Kubernetes-Kerncode zu ändern und auf die Veröffentlichungszyklen zu warten.

Wenn Sie Blob Storage als Dateisystem in einem Container oder Pod bereitstellen, können Sie es mit Anwendungen verwenden, die große Mengen unstrukturierter Daten verarbeiten, z. B.:

  • Protokolldateidaten.
  • Bilder, Dokumente und Streaming von Video oder Audio.
  • Notfallwiederherstellungsdaten.

Anwendungen können über BlobFuse oder das NFS 3.0-Protokoll auf die Daten im Objektspeicher zugreifen. Vor der Einführung des Blob Storage CSI-Treibers bestand die einzige Option darin, manuell einen nicht unterstützten Treiber für den Zugriff auf Blob Storage von Ihrer Anwendung zu installieren, die auf AKS ausgeführt wird. Ein Blob Storage CSI-Treiber, der auf AKS aktiviert ist, verfügt über zwei integrierte Speicherklassen: azureblob-fuse-premium und azureblob-nfs-premium.

Informationen zum Erstellen eines AKS-Clusters mit CSI-Treiberunterstützung finden Sie unter CSI-Treiber auf AKS. Weitere Informationen finden Sie unter "Vergleichen des Zugriffs auf Azure Files", "Blob Storage" und "Azure NetApp Files" mit NFS.

Azure HPC-Cache

HPC Cache beschleunigt den Zugriff auf Ihre Daten für rechenintensive Aufgaben und bietet die Skalierbarkeit von Cloudlösungen. Wenn Sie diese Speicherlösung auswählen, stellen Sie sicher, dass Sie Ihren AKS-Cluster in einer Region bereitstellen, die HPC-Cache unterstützt.

NFS-Server

Für den freigegebenen NFS-Zugriff sollten Sie Azure Files oder Azure NetApp Files verwenden. Sie können auch einen NFS-Server auf einer Azure-VM erstellen , die Volumes exportiert.

Diese Option unterstützt nur die statische Bereitstellung. Sie müssen die NFS-Freigaben manuell auf dem Server bereitstellen. Sie können NFS-Freigaben nicht automatisch auf AKS bereitstellen.

Diese Lösung basiert auf Infrastructure-as-a-Service (IaaS), nicht auf Platform-as-a-Service (PaaS). Sie verwalten den NFS-Server, einschließlich Betriebssystemupdates, hoher Verfügbarkeit, Sicherungen, Notfallwiederherstellung und Skalierbarkeit.

Azure Container Storage (Speicherlösung für Container)

Azure Container Storage ist ein cloudbasierter Volumeverwaltungs-, Bereitstellungs- und Orchestrierungsdienst, der nativ für Container erstellt wurde. Es ist in Kubernetes integriert, sodass Sie persistente Volumes dynamisch und automatisch bereitstellen können, um Daten für zustandsbehaftete Anwendungen zu speichern, die auf Kubernetes-Clustern ausgeführt werden.

Azure Container Storage verwendet vorhandene Azure Storage-Angebote für die tatsächliche Datenspeicherung und bietet eine Volume-Orchestrierungs- und Verwaltungslösung, die speziell für Container erstellt wurde. Azure Container Storage unterstützt den folgenden Sicherungsspeicher:

  • Azure-Datenträger: Bieten Sie eine präzise Kontrolle über Speicher-SKUs und -Konfigurationen. Azure-Datenträger eignen sich für Datenbanken der Ebene 1 und allgemeine Zwecke.

  • Kurzlebige Datenträger: Verwenden Sie lokale Speicherressourcen auf AKS-Knoten (NVMe oder temp SSD). Ephemerale Datenträger eignen sich für Anwendungen, die keine Anforderungen an die Datenbeständigkeit haben oder über integrierte Unterstützung für die Datenreplikation verfügen. AKS ermittelt den verfügbaren kurzlebigen Speicher auf AKS-Knoten und ruft sie für die Volumebereitstellung ab.

  • Elastic SAN: Bereitstellen von on-demand, vollständig verwalteten Ressourcen. Elastic SAN eignet sich für allgemeine Datenbanken, Streaming- und Messagingdienste, kontinuierliche Integration und kontinuierliche Übermittlungsumgebungen und andere Arbeitslasten der Ebene 1 oder Ebene 2. Mehrere Cluster können gleichzeitig auf ein einzelnes Speicherbereichsnetzwerk (SAN) zugreifen. Persistente Datenvolumen können jedoch nur jeweils von einem Nutzer angefügt werden.

Bisher mussten Sie, um Cloudspeicher für Container bereitzustellen, einzelne CSI-Treiber verwenden, um Speicherdienste anzupassen, die für IaaS-zentrierte Workloads vorgesehen sind. Diese Methode hat betriebstechnischen Aufwand geschaffen und das Risiko von Problemen im Zusammenhang mit der Anwendungsverfügbarkeit, Skalierbarkeit, Leistung, Benutzerfreundlichkeit und Kosten erhöht.

Azure Container Storage ist von OpenEBS abgeleitet, einer Open-Source-Lösung, die Container-Speicherfunktionen für Kubernetes bietet. Azure Container Storage bietet eine verwaltete Volume-Orchestrierungslösung über mikroservicebasierte Speichercontroller in einer Kubernetes-Umgebung. Dieses Feature ermöglicht echten containereigenen Speicher.

Azure Container Storage passt zu den folgenden Szenarien:

  • Beschleunigen von VM-zu-Container-Initiativen: Azure Container Storage umfasst das gesamte Spektrum von Azure-Blockspeicherangeboten, die bisher nur für VMs verfügbar waren, und stellt sie für Container zur Verfügung. Dieser Speicher umfasst ephemeren Datenträgerspeicher, der extrem niedrige Latenz für Workloads wie Cassandra bietet. Es umfasst außerdem Elastic SAN, das native iSCSI-Ziele und gemeinsam bereitgestellte Ziele bietet.

  • Vereinfachen sie die Volumenverwaltung mit Kubernetes: Azure Container Storage bietet Volumen-Orchestrierung über die Kubernetes-Steuerebene. Dieses Feature vereinfacht die Bereitstellung und Verwaltung von Volumes in Kubernetes, ohne zwischen verschiedenen Steuerebenen wechseln zu müssen.

  • Reduzieren Sie die Gesamtbetriebskosten: Um die Kosteneffizienz zu verbessern, erhöhen Sie die Skalierung persistenter Volumes, die für jeden Pod oder Knoten unterstützt werden. Um die für die Zuweisung benötigten Speicherressourcen zu reduzieren, nutzen Sie Speicherressourcen dynamisch gemeinsam. Die Skalierungsunterstützung für den Speicherpool selbst ist nicht enthalten.

Azure Container Storage bietet die folgenden wichtigsten Vorteile:

  • Rasches Skalieren von statusbasierten Pods: Azure Container Storage bindet persistente Volumes über Netzwerk-Blockspeicherprotokolle wie z. B. NVMe-oF oder iSCSI ein. Diese Funktion ermöglicht die schnelle Anfügung und Trennung persistenter Volumes. Sie können klein anfangen und Ressourcen nach Bedarf bereitstellen, um sicherzustellen, dass Ihre Anwendungen während der Initialisierung oder im Livebetrieb nicht unterversorgt oder gestört werden. Wenn ein Pod im Cluster neu startet, muss das zugehörige persistente Volume schnell auf den neuen Pod verschoben werden, um die Resilienz der Anwendung zu erhalten. Durch die Verwendung von Remote-Netzwerkprotokollen ist Azure Container Storage eng mit dem Pod-Lebenszyklus gekoppelt, um hochgradig resiliente, statusbasierte Anwendungen auf Azure zu unterstützen.

  • Verbesserung der Leistung für zustandsbehaftete Workloads: Azure Container Storage ermöglicht eine überlegene Leseleistung und bietet Schreibvorgänge in nahezu Festplattengeschwindigkeit mithilfe von NVMe-oF über RDMA. Diese Funktion ermöglicht es Ihnen, die Leistungsanforderungen für verschiedene Containerarbeitslasten kosteneffizient zu erfüllen, einschließlich Tier-1-I/O-intensive, allgemeine, Durchsatzsensitive und Entwicklungs-/Testworkloads. Beschleunigen Sie die Zeit für das Zuordnen und Trennen von persistenten Volumes und minimieren Sie die Failover-Zeit des Pods.

  • Orchestrate Kubernetes-native Volumes: Erstellen Sie Speicherpools und persistente Volumes, erfassen Sie Momentaufnahmen und verwalten Sie den gesamten Lebenszyklus von Volumes mithilfe kubectl von Befehlen, ohne zwischen Toolsets für unterschiedliche Steuerungsebenenvorgänge zu wechseln.

Partnerlösungen

Wie Amazon EKS ist AKS eine Kubernetes-Implementierung, und Sie können Partner-Kubernetes-Storage-Lösungen integrieren. Hier sind einige Beispiele für Partnerspeicherlösungen für Kubernetes:

  • Rook wandelt verteilte Speichersysteme in self-managing Storage Services um, indem Azure Storage-Administratoraufgaben automatisiert werden. Rook liefert seine Dienste über einen Kubernetes-Betreiber für jeden Speicheranbieter.

  • GlusterFS ist ein kostenlose und skalierbares Open-Source-Netzwerkdateisystem (NFS), das gängige, handelsübliche Hardware verwendet, um große verteilte Speicherlösungen für daten- und bandbreitenintensive Aufgaben zu erstellen.

  • Ceph bietet einen zuverlässigen und skalierbaren einheitlichen Speicherdienst mit Objekt-, Block- und Dateischnittstellen aus einem einzelnen Cluster, der aus Rohstoffhardwarekomponenten erstellt wird.

  • Mit minIO Multicloud-Objektspeicher können Unternehmen AWS S3-kompatible Dateninfrastruktur in jeder Cloud erstellen. Sie bietet eine konsistente, tragbare Schnittstelle zu Ihren Daten und Anwendungen.

  • Portworx ist eine End-to-End-Speicher- und -Datenverwaltungslösung für Kubernetes-Projekte und containerbasierte Initiativen. Portworx bietet containerspezifischen Speicher, Notfallwiederherstellung, Datensicherheit und Multicloudmigrationen.

  • Quobyte bietet leistungsstarken Datei- und Objektspeicher, den Sie auf jedem Server oder in der Cloud bereitstellen können, um die Leistung zu skalieren, große Datenmengen zu verwalten und die Verwaltung zu vereinfachen.

  • Ondat bietet eine konsistente Speicherebene auf jeder Beliebigen Plattform. Sie können eine Datenbank oder beliebige persistente Workloads in einer Kubernetes-Umgebung ausführen, ohne die Speicherebene verwalten zu müssen.

Überlegungen zu Kubernetes-Speicher

Berücksichtigen Sie die folgenden Faktoren, wenn Sie eine Speicherlösung für Amazon EKS oder AKS auswählen.

Zugriffsmodi für Speicherklassen

In Kubernetes Version 1.21 und höher verwenden AKS und Amazon EKS-Speicherklassen standardmäßig nur CSI-Treiber .

Verschiedene Dienste unterstützen Speicherklassen, die unterschiedliche Zugriffsmodi haben.

Dienst ReadWriteOnce ReadOnlyMany ReadWriteMany
Azure-Datenträgerspeicher X
Azure Files X X X
Azure NetApp-Dateien X X X
NFS-Server X X X
HPC-Zwischenspeicher X X X

Dynamische und statische Bereitstellung

Stellen Sie Volumes dynamisch bereit, um den Verwaltungsmehraufwand bei der statischen Erstellung persistenter Volumes zu verringern. Legen Sie eine geeignete Reclaim-Richtlinie fest, um ungenutzte Datenträger zu entfernen, wenn Sie Pods löschen.

Datensicherung

Wählen Sie ein Tool aus, um persistente Daten zu sichern. Das Tool sollte ihrem Speichertyp entsprechen, z. B. Momentaufnahmen, Azure Backup, Velero oder Kasten.

Kostenoptimierung

Um die Azure Storage-Kosten zu optimieren, verwenden Sie Azure Reservations, wenn der Dienst sie unterstützt. Weitere Informationen finden Sie unter Kostenverwaltung für einen Kubernetes-Cluster.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

Andere Mitwirkende:

Um nichtöffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte