Überlegungen zum Speicher für Azure Kubernetes Service (AKS)

  • Artikel

Zum Ausführen bestimmter Anwendungsworkloads muss Ihre Organisation oder Ihr Unternehmen geeignete AKS-Funktionen (Azure Kubernetes Service) auf Plattformebene entwerfen. Diese Workloads weisen wahrscheinlich unterschiedliche Speicheranforderungen auf. Bei der Auswahl der richtigen Speicherlösung für Ihre Anwendung müssen Sie mehrere Aspekte berücksichtigen, einschließlich Leistung, Verfügbarkeit, Wiederherstellbarkeit, Sicherheit und Kosten. Das Ziel dieses Artikels besteht darin, Sie bei der Auswahl der richtigen Option oder Kombination von Optionen für Ihre Workload zu unterstützen.

Kubernetes kann sowohl zustandslose als auch zustandsbehaftete Workloads ausführen. Zustandsbehaftete Workloads erfordern oftmals eine Speicherlösung zum Speichern des Zustands. AKS unterstützt mehrere integrierte Optionen für nativen Speicher, zu denen verwaltete Datenbanken, Datenträger (oder Blöcke) sowie Dateien und Blob-Speicher (oder Objektspeicher) gehören. Jede dieser Optionen bietet unterschiedliche SKUs, Größen und Leistungseigenschaften. Die Auswahl der richtigen Option erfordert eine sorgfältige Abwägung.

In diesem Artikel werden die Faktoren und Optionen beschrieben, die Sie unter Auswählen des richtigen Speicherdiensts und Entwurfsüberlegungen berücksichtigen müssen. Er gibt unter Entwurfsempfehlungen spezifische Empfehlungen.

Auswählen des richtigen Speicherdiensts

Die Auswahl der richtigen SKUs und Größen für Ihre Erstbereitstellungen erfordert einige Bewertungen und möglicherweise eine Proof-of-Concept- oder Testumgebung. Im Folgenden finden Sie allgemeine Richtlinien, die Ihnen bei den ersten Schritten mit Speicher für AKS helfen sollen:

  • Strukturierte Daten. Für strukturierte Daten, die Ihre Anwendung in einer verwalteten Datenbank speichern kann, die auf der Plattform verfügbar ist (z. B. Azure SQL), wird die Verwendung einer verwalteten Datenbank empfohlen.

  • Unstrukturierte Daten. Für unstrukturierte Daten wie Fotos, Videos und Textdokumente sollten Sie Blob-Speicher verwenden. Dazu kann Ihre Anwendung Blobs verwenden, die als Dateien über das Netzwerkdateisystem (NFS) eingebunden sind oder als virtuelles Dateisystem mithilfe von BlobFuse aufgerufen werden. Alternativ kann Ihre Anwendung direkt aus Blob-Speicher lesen und in ihn schreiben.

  • Freigegebene Anwendungsdaten. Verwenden Sie für freigegebene Anwendungsdaten, die eine hohe Leistung erfordern, entweder Azure NetApp Files oder den Premium-Tarif von Azure Files. Verwenden Sie für freigegebene Konfigurationsdaten, für die nur eine eingeschränkte Leistung erforderlich ist, den Standard-Tarif von Azure Files.

  • Bandbreite für Anwendungs- und Speicheranforderungen. Vergewissern Sie sich, dass Ihre Knoten über ausreichend Netzwerkbandbreite verfügen, um sowohl Anwendungs- als auch Speicheranforderungen verarbeiten zu können. Speicherdatenverkehr wird über den Netzwerkstapel abgewickelt, unabhängig davon, ob das Protokoll für Übertragungen SMB (Server Message Block) oder NFS ist.

  • Niedrige Latenz, hohe IOPS. Verwenden Sie Datenträger für den Speicher, wenn Ihre Anwendung eine konstant niedrige Latenz für Messaginganwendungen und Vorgänge mit hoher E/A pro Sekunde (IOPS) sowie einen hohen Durchsatz benötigt, um Ihre eigenen Datenbanken auf Kubernetes auszuführen. Zum Erzielen der besten Leistung sollten Sie Azure SSD Premium, Azure SSD Premium v2 oder Azure Disk Storage Ultra verwenden.

Überlegungen zum Entwurf

Die folgenden Überlegungen beziehen sich auf das Entwerfen von Speicher für AKS. Überlegen Sie, wo Speicher in Ihrer AKS-Umgebung erforderlich ist, und bestimmen Sie die beste Lösung für jede Anforderung.

Betriebssystemdatenträger

Berücksichtigen Sie für Betriebssystemdatenträger die folgenden Faktoren:

  • Kurzlebige Betriebssystemdatenträger. Jeder virtuelle Computer (VM) in Azure benötigt einen Datenträger für sein Betriebssystem. Da Kubernetes-Knoten kurzlebig sind, verwendet AKS standardmäßig kurzlebige Betriebssystemdatenträger für die unterstützten VM-Größen. Weitere Informationen zu kurzlebigen Betriebssystemdatenträgern finden Sie unter Kurzlebiges Betriebssystem.

  • Verwaltete Betriebssystemdatenträger. Wenn Ihre Workload diese erfordert, können Sie stattdessen reguläre verwaltete Datenträger für die Knoten in Ihrem AKS-Cluster verwenden. Auf diese Weise lassen sich Workloads unterstützen, für die beständige Daten auf dem Betriebssystemlaufwerk erforderlich sind. Weitere Informationen zu Optionen für beständigen Speicher finden Sie unter Speicheroptionen für Anwendungen in Azure Kubernetes Service (AKS).

  • Dimensionierung von verwalteten Datenträgern. Wenn Sie einen verwalteten Datenträger als Betriebssystemdatenträger wählen, achten Sie darauf, dass er entsprechend dimensioniert ist, um die Anforderungen des Betriebssystems, des Kubernetes-Systems und Ihrer Workload zu unterstützen. Weitere Informationen zu Optionen und Unterschieden finden Sie unter Verwaltete Azure-Datenträgertypen.

Anwendungsdaten

Einige Workloads benötigen einen konstanten Datenspeicher für die Speicherung von Anwendungsdaten. Wenn Ihre Anwendung eine Datenbank benötigt, sollten Sie die verwalteten Datenbanken in Azure in Erwägung ziehen, die die folgenden Optionen bieten:

Speicherlösungen in AKS

Wenn eine verwaltete Datenbank die Anforderungen Ihrer Anwendung nicht erfüllt, sollten Sie für die Speicherung von konsistenten Daten eine andere Speicheroption verwenden, die für AKS verfügbar ist. Zu den Optionen zählen datenträgerbasierte Lösungen, kurzlebige Datenträger, dateibasierte Lösungen, Blob-Speicher und weitere Optionen, die in diesem Artikel nicht behandelt werden.

Datenträgerbasierte Lösungen

Datenträger oder Blockspeicher eignen sich ideal zum direkten Speichern von Daten auf einem rohen, blockbasierten Gerät. Datenträgerbasierter Speicher eignet sich ideal zum Speichern von Daten für Datenbanken, die von Ihrem Kubernetes-Cluster gehostet werden. In Azure stellen verwaltete Datenträger die Lösung zum Erwerb von blockbasiertem Speicher dar.

Lösungen für kurzlebige Datenträger

Überlegen Sie, ob Ihre Anwendung nicht-beständigen, temporären Speicher benötigt oder an welchen Stellen Sie die Hochleistungslaufwerke auf den speicheroptimierten VMs einsetzen möchten. Zum Herstellen einer Verbindung mit einem kurzlebigen Volume können Sie entweder die Option emptyDir in Kubernetes oder den Treiber für ein kurzlebiges lokales CSI-Volume verwenden. Wir empfehlen emptyDir für kurzlebige Daten, z. B. einen temporären Speicherbereich. Für den Speicher der speicheroptimierten VM-Reihe empfiehlt sich der Einsatz von CSI mit einem kurzlebigen lokalen Volume. Weitere Informationen zu CSI-Treibern finden Sie unter CSI-Treiber (Container Storage Interface) auf Azure Kubernetes Service (AKS).

Dateibasierte Lösungen

Überlegen Sie, ob Ihre Pods ein gemeinsames Dateisystem benötigen. Ein freigegebenes Dateisystem eignet sich ideal für Anwendungs- und Konfigurationsdaten, die von mehreren Pods in Ihrem Kubernetes-Cluster gelesen und gemeinsam verwendet werden. Dateispeicher macht ein freigegebenes Dateisystem entweder über NFS oder SMB/CFIS (Common Internet File System) verfügbar. Azure bietet über zwei Lösungen für dateibasierten Speicher: Azure Files und Azure NetApp Files.

Azure Files

Für Azure Files sollten Sie die folgenden Optionen in Betracht ziehen:

  • Statisch oder dynamisch erstellte Dateifreigabe. Überlegen Sie, ob Sie eine statische Dateifreigabe verwenden möchten, die außerhalb von AKS erstellt wird, oder ob AKS die Dateifreigabe dynamisch in Ihrem Auftrag erstellen soll. Weitere Informationen finden Sie unter

  • Standard- oder Premium-Leistung. Bewerten Sie, ob die Standardleistung ausreichend ist oder ob Sie Premiumleistung von Azure Files benötigen.

  • SMB/CIFS oder NFS. Bewerten Sie für den Zugriff auf Azure Files, ob Ihre Workload die API für das Standardprotokoll SMB/CIFS verwenden soll oder ob Ihre Workload NFS-Unterstützung erfordert.

  • Netzwerkmodell für den Zugriff. Betrachten Sie das Netzwerkmodell, das Sie verwenden möchten, um auf Azure Files zuzugreifen: Direkter Zugriff über eine öffentliche IP-Adresse, Zugriff über einen Dienstendpunkt oder über eine private Verbindung.

Azure NetApp Files

Für Azure NetApp Files sollten Sie die folgenden Optionen in Betracht ziehen:

Blob Storage

Berücksichtigen Sie die Menge unstrukturierter Daten, die Ihre Anwendung speichern muss. Auf Azure Blob Storage kann über eine HTTP-API oder über die SDKs zugegriffen werden. Das Einbinden von Blobspeicher als Dateisystem in einen Container oder Pod eignet sich ideal für Anwendungsworkloads, die große Mengen unstrukturierter Daten enthalten, wie Protokolldateien, Bilder, Dokumente, Streamingmedien und Notfallwiederherstellungsdaten.

  • Datenredundanz. Überlegen Sie, welche Form von Datenredundanz zu Ihrer Anwendung passt. Weitere Informationen finden Sie unter Azure Storage-Redundanz. Datenredundanz wird auf der Ebene des Speicherkontos ausgewählt.

  • Leistungsstufe. Überlegen Sie, welche Leistungsstufe von Blobspeicher für Ihre Anwendung erforderlich ist. Weitere Informationen finden Sie unter Zugriffsebenen „Heiß“, „Kalt“ und „Archiv“ für Blobdaten.

  • Authentifizierungsmethode für den Zugriff. Überlegen Sie, welche Authentifizierungsmethode Ihre Anwendung für den Zugriff auf Blob-Speicher verwenden sollte: Speicherschlüssel, SAS oder Microsoft Entra ID. Weitere Informationen finden Sie unter Autorisieren des Zugriffs auf Daten in Azure Storage.

  • API zum Abstrahieren von Blob-Speicher. Überlegen Sie, welche API verwendet werden soll. In der Regel verwenden Anwendungen, die auf Blob-Speicher zugreifen, die API in der Anwendung über eines der SDKs, wodurch die Interaktion mit Blob-Speicher aus dem Kubernetes-Cluster abstrahiert wird. Weitere Informationen zu Bibliotheken für verschiedene Programmiersprachen finden Sie unter Einführung in Azure Blob Storage.

  • Statisch oder dynamisch erstellter Blob-Speicher. Überlegen Sie, ob Sie einen statischen Blob-Speichercontainer verwenden möchten, der außerhalb von AKS erstellt wird, oder ob AKS den Blob-Speichercontainer dynamisch in Ihrem Auftrag erstellen soll. Weitere Informationen finden Sie unter

  • Treiber für den Speicherzugriff. Überlegen Sie, wie Ihre Anwendung auf Blob-Speicher zugreifen soll. Für den Zugriff auf Blob-Speicher als Dateisystem können Sie den Blob-CSI-Treiber in Kubernetes verwenden. Dieser Treiber ermöglicht den Zugriff auf Blob-Speicher entweder über das NFSv3-Protokoll oder über einen FUSE-Treiber.

Andere Speicherlösungen

Ziehen Sie andere Speichertypen in Betracht, wenn Ihre Anwendung etwas erfordert, das nicht in diesem Artikel beschrieben wird. Es gibt mehrere spezialisierte Speicherlösungen in Azure, die in Kubernetes integriert werden können. Diese werden nicht in diesem Artikel behandelt, aber in der folgenden Liste werden mögliche Lösungen aufgeführt:

  • Azure HPC-Cache. HPC Cache beschleunigt den Zugriff auf Ihre Daten für HPC-Aufgaben (High Performance Computing). Aufgrund der Zwischenspeicherung von Dateien in Azure ermöglicht Azure HPC Cache für Ihren vorhandenen Workflow die Skalierbarkeit des Cloud Computing. Weitere Informationen dazu finden Sie unter Integrieren von Azure HPC Cache in Azure Kubernetes Service.

  • Azure Data Lake Storage Gen2. Data Lake Storage Gen2 ist eine spezielle Art von Blob-Speicher, die für Big Data-Workloads wie Hadoop und Spark optimiert ist. Weitere Informationen hierzu finden Sie unter Einführung in Azure Data Lake Storage Gen2.

Entwurfsempfehlungen

Dieser Abschnitt enthält Empfehlungen, die auf Lösungen basieren, die sich für Azure-Kunden als effektiv erwiesen haben.

  • Verwenden von Azure Private Link. Aus Sicherheitsgründen empfiehlt sich die Verwendung von Azure Private Link für alle Speicherlösungen, die dies unterstützen. Azure Private Link ermöglicht den Zugriff auf Azure-Dienste wie Azure Storage und SQL-Datenbank sowie auf von Azure gehostete Dienste über einen privaten Endpunkt in Ihrem virtuellen Netzwerk. Weitere Informationen finden Sie unter Was ist Azure Private Link?.

  • Verwenden kurzlebiger Betriebssystemdatenträger. Für Betriebssystemdatenträger wird die Verwendung kurzlebiger Datenträger empfohlen. Wenn Sie die Vorzüge dieses Features nutzen möchten, wählen Sie eine VM-Größe aus, die über einen ausreichend großen temporären Datenträger verfügt. Weitere Informationen finden Sie unter Kurzlebige Betriebssystemdatenträger für virtuelle Azure-Computer.

  • Verwenden verwalteter Datenbanken. Für Anwendungsdaten empfiehlt sich die Verwendung verwalteter Datenbanken. Eine Liste der Datenbankoptionen finden Sie unter Typen von Datenbanken in Azure.

In den folgenden Abschnitten werden weitere Empfehlungen für Azure-Datenträger, Azure Files und Blob-Speicher beschrieben.

Azure-Datenträger

Für Azure-Datenträger empfehlen wir die folgenden Entwurfsoptionen:

  • Verwenden von Premium- oder Ultra-Datenträgern. In den meisten Fällen empfehlen wir Premium- oder Ultra-Datenträger, um eine angemessene Leistung sicherzustellen. Weitere Informationen finden Sie unter Azure Disk Storage.

  • Dimensionieren des Knotens für Datenträger und Durchsatz. Es empfiehlt sich, sicherzustellen, dass Ihr Kubernetes-Knoten groß genug ist, um die Anzahl der Datenträger und den aggregierten Durchsatz zu unterstützen. Informationen zu Größen und Merkmalen finden Sie unter Größen für virtuelle Computer in Azure.

  • Erstellen von Momentaufnahmen persistenter Volumes. Es empfiehlt sich, Momentaufnahmen persistenter Volumes zu erstellen, um entweder neue Volumes bereitzustellen, die mit den Daten der Momentaufnahmen voraufgefüllt sind, oder um ein vorhandenes Volume mithilfe der Momentaufnahmefunktion des Azure Disks CSI-Treibers in einem früheren Zustand wiederherzustellen. Weitere Informationen finden Sie unter Volumemomentaufnahmen.

  • Vermeiden von datenträgerübergreifendem Striping. Es empfiehlt sich, in Kubernetes Striping über mehrere Datenträger zu vermeiden.

  • Verwenden von PV/PVC. Wir empfehlen die Verwendung von PV und PVC in Kubernetes, um Datenträger bei Bedarf dynamisch zu erstellen. Weitere Informationen zu beständigem Speicher finden Sie unter Speicheroptionen für Anwendungen in Azure Kubernetes Service (AKS).

Azure Files

Für Azure Files empfehlen wir die folgenden Entwurfsoptionen:

  • Entscheidung für Premium. Wenn die Leistung entscheidend ist, empfehlen wir die Verwendung des Premium-Tarifs.

  • Erstellen dedizierter Speicherkonten. Es empfiehlt sich, dedizierte Speicherkonten für Ihre Dateifreigaben bereitzustellen.

  • Entscheidung für statisch oder dynamisch erstellte Dateifreigaben. Es empfiehlt sich, sorgfältig abzuwägen, ob AKS die Dateifreigaben erstellen soll oder ob Sie sie statisch außerhalb von Kubernetes erstellen möchten. Speicher, der dynamisch erstellt wird, kann auch dynamisch gelöscht werden. Weitere Informationen zur dynamischen Erstellung von Dateifreigaben durch AKS finden Sie unter Dynamisches Erstellen und Verwenden eines permanenten Volumes mit Azure Files.

Azure NetApp Files

Für Azure NetApp Files empfehlen wir die folgenden Entwurfsoptionen:

  • Wählen Sie eine Leistungsebene ausgehend von den Anwendungsanforderungen aus. Azure NetApp Files bietet 3 Leistungsstufen, die unterschiedliche Leistungsklassen bieten. Weitere Informationen finden Sie unter Überlegungen zur Leistung für Azure NetApp Files.

  • Erstellen Sie Kapazitätspools in derselben Azure-Region wie der AKS-Cluster. Weitere Informationen finden Sie unter Erstellen eines Kapazitätspools für Azure NetApp Files.

  • Verwenden des QoS-Typs „Automatisch“ für Kapazitätspools.

  • Planen Ihres Netzwerks. Für den Netzwerkentwurf gibt es zwei Optionen:

    1. Wenn Sie dasselbe VNET für AKS und Azure NetApp Files verwenden, erstellen Sie ein dediziertes Subnetz für Azure NetApp Files, und delegieren Sie das Subnetz an Microsoft.NetApp/Volumes.
    2. Wenn Sie verschiedene VNETs verwenden, richten Sie zwischen ihnen VNET-Peering ein.

Blob Storage

Für Blob-Speicher empfehlen wir die folgenden Entwurfsoptionen:

  • Verwenden eines SDK als Schnittstelle zum Speicher. Wir empfehlen die Verwendung eines SDK auf Anwendungsebene als Schnittstelle mit Blob-Speicher.

  • Verwenden von CSI mit NFS als Schnittstelle zum Speicher. Wenn Sie kein SDK auf Anwendungsebene als Schnittstelle mit Blob-Speicher verwenden können, empfiehlt sich die Verwendung der NFS v3-Option im Blob-CSI-Treiber. Weitere Informationen finden Sie unter Verwenden des CSI-Treibers (Container Storage Interface) von Azure Blob Storage.

  • Verwenden Sie Microsoft Entra ID für den Zugriff. Wir empfehlen, Microsoft Entra ID für die Autorisierung des Zugriffs auf Blob-Speicher zu verwenden. Vermeiden Sie die Verwendung eines freigegebenen Speicherkontoschlüssels. Weitere Informationen finden Sie unter Autorisieren des Zugriffs auf Blobs mit Microsoft Entra ID.

  • Anpassen von Zugriffsebenen. Wir empfehlen die Verwendung von Richtlinien zur Lebenszyklusverwaltung, um selten abgerufene Daten auf eine kühlere Zugriffsebene zu verschieben. Weitere Informationen finden Sie unter Zugriffsebenen „Heiß“, „Kalt“ und „Archiv“ für Blobdaten.

Nächste Schritte

Erfahren Sie, wie Sie in AKS die Kostenzuordnung mithilfe von Kubecost auf eine Bereitstellung, einen Dienst, eine Bezeichnung, einen Pod oder einen Namespace festlegen.

Kostengovernance mit Kubecost