Windows-Containerspeicher mit Azure Kubernetes Service
In der vorherigen Lektion haben wir erfahren, wie Kubernetes Ihre containerbasierten Anwendungen und ihre zugehörigen Speicherkomponenten verwaltet und koordiniert. Darüber hinaus haben wir die Kubernetes-Clusterarchitektur kennengelernt, die aus einer Steuerungsebene für Kerndienste und Knoten für Anwendungsressourcen besteht.
Azure Kubernetes Service (AKS) vereinfacht die Bereitstellung eines Managed Kubernetes-Clusters in Azure, indem der betriebliche Aufwand in Azure ausgelagert wird. Azure führt als gehosteter Kubernetes-Dienst wichtige Aufgaben aus, z. B. Systemüberwachung und Wartung.
Wenn Sie einen AKS-Cluster erstellen, wird automatisch eine Steuerungsebene erstellt und konfiguriert. Diese Steuerungsebene wird kostenlos als verwaltete Azure-Ressource bereitgestellt, die für den Benutzer abstrahiert wird. Sie zahlen nur für die Knoten, die an den AKS-Cluster angefügt sind, und verwalten nur diese.
Das folgende Diagramm zeigt, wie die Steuerungsebene, die die wichtigsten Kubernetes-Dienste und die Orchestrierung von Anwendungsworkloads bereitstellt, von AKS verwaltet wird, während Sie die Knoten verwalten, die die Anwendungsworkloads enthalten.
AKS-Cluster
Wenn Sie einen AKS-Cluster bereitstellen, geben Sie die Anzahl und Größe der Knoten an, und AKS stellt die Kubernetes-Steuerungsebene und die Knoten bereit und konfiguriert sie.
Das folgende Diagramm zeigt die Architektur eines AKS Clusters.
AKS-Knoten werden auf virtuellen Azure-Computern (VMs) ausgeführt. Standardmäßig repliziert Azure automatisch den Betriebssystemdatenträger (Betriebssystemdatenträger) für einen virtuellen Computer (virtueller Computer) in Azure Storage, um Datenverluste zu vermeiden, wenn der virtuelle Computer auf einen anderen Host verschoben wird. Wie wir bereits gelernt haben, sind Container jedoch nicht darauf ausgelegt, dass der lokale Zustand beibehalten wird. Dieses Verhalten bietet also begrenzten Wert und bietet Nachteile wie langsamere Knotenbereitstellung und höhere Lese-/Schreiblatenz.
AKS verwendet hingegen kurzlebige Betriebssystemdatenträger. Diese Datenträger werden nur auf dem Hostcomputer gespeichert, genau wie ein temporärer Datenträger. Diese Konfiguration verringert die Latenz bei Lese-/Schreibvorgängen und ermöglicht gleichzeitig eine schnellere Knotenskalierung sowie schnellere Clusterupgrades.
Volumespeicher in AKS
In AKS werden herkömmliche Volumes 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. Um diese Volumes zu Azure Storage zuzuordnen, verwendet AKS die CSI (Container Storage Interface).
CSI ist ein Standard für die Bereitstellung beliebiger Block- und Dateispeichersysteme für containerisierte Workloads in Kubernetes.
Durch die Einführung und Verwendung von CSI kann Azure Kubernetes Service (AKS) Plug-Ins schreiben, bereitstellen und durchlaufen, um neue Speichersysteme in Kubernetes verfügbar zu machen oder vorhandene Speichersysteme in Kubernetes zu verbessern, ohne den Kerncode von Kubernetes zu ändern und die Releasezyklen abwarten zu müssen.
Die Unterstützung des CSI-Speichertreibers in AKS ermöglicht die native Verwendung von Folgendem:
- Azure Disk kann zum Erstellen einer Kubernetes-DataDisk-Ressource verwendet werden. Datenträger können auf Hochleistungs-SSDs basierenden Speicher vom Typ „Azure Storage Premium“ oder auf regulären HHDs (Hard Disk Drives) Festplatten oder Standard-SSDs basierenden Speicher vom Typ „Azure Storage Standard“ nutzen. Für die meisten Produktions- und Entwicklungsworkloads wird die Verwendung von Storage Premium empfohlen. Azure-Datenträger werden als ReadWriteOnce eingebunden und sind nur für einen einzelnen Knoten in AKS verfügbar. Verwenden Sie für die Speichervolumes, auf die mehrere Knoten gleichzeitig zugreifen können, Azure Files.
- Mit Azure Files kann eine SMB 3.0/3.1-Einbindung bereitgestellt werden, die durch ein Azure Storage-Konto auf Pods gesichert ist. Mit Azure Files können Daten über mehrere Knoten und Pods hinweg gemeinsam genutzt werden. Azure Files kann auf regulären Festplattenlaufwerken basierenden Azure Standard-Speicher oder auf Hochleistungs-SSDs basierenden Azure Premium-Speicher verwenden.
- Azure Blob Storage kann verwendet werden, um einen Blobspeicher (oder Objektspeicher) als Dateisystem in einem Container oder Pod einzubinden. Durch die Verwendung von Blob Storage kann Ihr Cluster Anwendungen unterstützen, die mit großen unstrukturierten Datasets wie Protokolldateien, Bildern oder Dokumenten, HPC-Daten und mehr arbeiten. Darüber hinaus können Sie, wenn Sie Daten in Azure Data Lake-Speicher erfassen, direkt bereitstellen und in AKS verwenden, ohne ein anderes Zwischendateisystem zu konfigurieren.
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.
Persistente Volumes
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. Im Azure Kubernetes Service können Sie Azure-Datenträger oder Azure Files verwenden, um die PersistentVolume bereitzustellen. Ihre Auswahl von Datenträgern oder Dateien für das Volume wird häufig durch die Notwendigkeit des gleichzeitigen Zugriffs auf die Daten oder die erforderliche Leistungsstufe bestimmt.
Ein Clusteradministrator kann statisch eine PersistentVolume erstellen, oder das Volume wird dynamisch vom Kubernetes-API-Server erstellt. Wenn ein Pod geplant ist und derzeit nicht verfügbaren Speicher anfordert, kann Kubernetes den zugrunde liegenden Azure Disk Storage oder Azure File Storage erstellen und dem Pod anfügen. Dynamische Bereitstellung verwendet eine StorageClass zum Identifizieren des Azure-Speichertyps, der erstellt werden muss.
Speicherklassen in AKS
Sie können zum Definieren verschiedener Speicherstufen, z.B. „Premium“ und „Standard“, eine StorageClass erstellen. Die StorageClass definiert auch die reclaimPolicy. Wenn Sie das persistente Volume löschen, steuert die reclaimPolicy das Verhalten der zugrunde liegenden Azure-Speicherressource. Die zugrunde liegende Speicherressource kann entweder gelöscht oder für die Verwendung mit einem zukünftigen Pod beibehalten werden.
Für Cluster mit CSI-Treibern hat AKS folgendes extra StorageClasses erstellt:
| Berechtigung | `Reason` |
|---|---|
| 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. Mit der Speicherklasse werden auch die persistenten Volumes so konfiguriert, dass sie erweiterbar sind. Sie müssen lediglich den Anspruch der persistenten Volumes entsprechend der neuen Größe anpassen. |
| managed-csi-premium | Verwendet lokal redundanten Azure Premium-Speicher (LRS) zum Erstellen eines verwalteten Datenträgers. Mit der Freigaberichtlinie wird 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 dauerhaften Volumes. |
| azurefile-csi | Verwendet Azure Storage Standard zum Erstellen einer Azure-Dateifreigabe. Mit der Freigaberichtlinie wird sichergestellt, dass die zugrunde liegende Azure-Dateifreigabe gelöscht wird, wenn das persistente Volume gelöscht wird, das sie verwendet hat. |
| azurefile-csi-premium | Verwendet Azure Storage Premium zum Erstellen einer Azure-Dateifreigabe. Mit der Freigaberichtlinie wird sichergestellt, dass die zugrunde liegende Azure-Dateifreigabe gelöscht wird, wenn das persistente Volume gelöscht wird, das sie verwendet hat. |
| azureblob-nfs-premium | Verwendet Azure Premium-Speicher, um einen Azure Blob Storage-Container zu erstellen und eine Verbindung mit dem NFS (Network File System) v3-Protokoll herzustellen. Mit der Freigaberichtlinie wird sichergestellt, dass der zugrunde liegende Azure-Blobspeichercontainer gelöscht wird, wenn das persistente Volume gelöscht wird, das ihn verwendet hat. |
| azureblob-fuse-premium | Azure Storage Premium wird verwendet, um einen Azure-Blobspeichercontainer zu erstellen und mit BlobFuse eine Verbindung herzustellen. Mit der Freigaberichtlinie wird sichergestellt, dass der zugrunde liegende Azure-Blobspeichercontainer gelöscht wird, wenn das persistente Volume gelöscht wird, das ihn verwendet hat. |
Sofern Sie keine StorageClass für ein persistentes Volume angeben, wird die Standard-StorageClass verwendet. Stellen Sie beim Anfordern von persistenten Volumes sicher, dass sie den Speicher verwenden, den Sie benötigen. Die Standardklasse ist mit managed-csi identisch.
Ansprüche auf persistente Volumes
Eine PersistentVolumeClaim Anforderungsspeicherung eines bestimmten Zugriffsmodus und einer bestimmten StorageClassGröße. Wie bereits erwähnt, kann der Kubernetes-API-Server die zugrunde liegende Azure-Speicherressource dynamisch bereitstellen, wenn basierend auf der definierten StorageClass keine Ressourcen den Anspruch erfüllen kann.
Sobald die Verbindung des Volumes mit dem Pod hergestellt ist, enthält die Poddefinition die Volumebereitstellung.
Das folgende Diagramm zeigt, wie ein PVC innerhalb eines AKS-Clusters funktioniert:
