Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Speicher

Übersicht

Es gibt Szenarien, in denen Sie möglicherweise Anwendungen ausführen möchten, die Daten kurz- oder langfristig aufbewahren müssen. Für solche Anwendungsfälle können Volumes von Pods definiert und bereitgestellt werden, sodass ihre Container unterschiedliche Speichermechanismen nutzen können. Kubernetes unterstützt verschiedene Arten von Volumes für kurzlebige und persistente Speicherung. Die Wahl des Speichers hängt weitgehend von den Anwendungsanforderungen ab. Jeder Ansatz hat Auswirkungen auf die Kosten, und die unten aufgeführten Methoden helfen Ihnen dabei, die Kosteneffizienz für Workloads zu erreichen, die in Ihren EKS-Umgebungen irgendeine Form von Speicher benötigen.

Kurzlebige Volumen

Ephemere Volumes eignen sich für Anwendungen, die vorübergehende lokale Volumes benötigen, bei denen jedoch keine Daten nach Neustarts dauerhaft gespeichert werden müssen. Beispiele hierfür sind Anforderungen an Scratch-Speicherplatz, Zwischenspeicherung und schreibgeschützte Eingabedaten wie Konfigurationsdaten und geheime Daten. Weitere Informationen zu kurzlebigen Kubernetes-Volumes finden Sie hier. Die meisten kurzlebigen Volumes (z. B. emptyDir, configMap, downwardAPI, secret, hostpath) werden von lokal angeschlossenen beschreibbaren Geräten (normalerweise der Root-Disk) oder RAM unterstützt. Daher ist es wichtig, das kostengünstigste und leistungsstärkste Host-Volume zu wählen.

EBS-Volumes verwenden

Wir empfehlen, mit gp3 als Host-Root-Volume zu beginnen. Es ist das neueste Allzweck-SSD-Volume, das von Amazon EBS angeboten wird, und bietet im Vergleich zu GP2-Volumes auch einen niedrigeren Preis (bis zu 20%) pro GB.

Amazon EC2 Instance Stores verwenden

Amazon EC2 Instance Stores bieten temporären Speicher auf Blockebene für Ihre EC2 Instances. Auf den von EC2 Instance-Speichern bereitgestellten Speicher kann über Festplatten zugegriffen werden, die physisch an die Hosts angeschlossen sind. Im Gegensatz zu Amazon EBS können Sie Instance-Speicher-Volumes nur anhängen, wenn die Instance gestartet wird, und diese Volumes existieren nur während der Lebensdauer der Instance. Sie können nicht getrennt und wieder an andere Instances angehängt werden. Sie können hier mehr über Amazon EC2 Instance Stores erfahren. Für das Volumen eines Instance-Speichers fallen keine zusätzlichen Gebühren an. Dadurch sind sie (Instance-Speicher-Volumes) kostengünstiger als allgemeine EC2 Instances mit großen EBS-Volumes.

Um lokale Speichervolumes in Kubernetes zu verwenden, sollten Sie die Festplatten anhand der EC2 Amazon-Benutzerdaten partitionieren, konfigurieren und formatieren, sodass Volumes wie HostPathin der Pod-Spezifikation bereitgestellt werden können. Alternativ können Sie den Local Persistent Volume Static Provisioner nutzen, um die lokale Speicherverwaltung zu vereinfachen. Mit dem statischen Local Persistent Volume Provisioner können Sie über die Standardschnittstelle von Kubernetes PersistentVolumeClaim (PVC) auf lokale Instance-Speicher-Volumes zugreifen. Darüber hinaus wird das Paket provision PersistentVolumes (PVs) bereitgestellt, das Informationen zur Knotenaffinität enthält, um Pods den richtigen Knoten zuzuordnen. Obwohl Kubernetes verwendet wird PersistentVolumes, sind EC2 Instance-Speicher-Volumes ihrer Natur nach kurzlebig. Daten, die auf kurzlebige Festplatten geschrieben wurden, sind nur während der Lebensdauer der Instanz verfügbar. Wenn die Instanz beendet wird, werden auch die Daten beendet. Weitere Informationen finden Sie in diesem Blog.

Beachten Sie, dass bei der Verwendung von Amazon EC2 Instance Store-Volumes das gesamte IOPS-Limit mit dem Host geteilt wird und Pods an einen bestimmten Host gebunden werden. Sie sollten Ihre Workload-Anforderungen gründlich prüfen, bevor Sie Amazon EC2 Instance Store-Volumes einführen.

Persistente Volumes

Kubernetes wird in der Regel mit der Ausführung von zustandslosen Anwendungen in Verbindung gebracht. Es gibt jedoch Szenarien, in denen Sie möglicherweise Microservices ausführen möchten, die persistente Daten oder Informationen von einer Anfrage zur nächsten beibehalten müssen. Datenbanken sind ein gängiges Beispiel für solche Anwendungsfälle. Pods und die darin enthaltenen Behälter oder Prozesse sind jedoch kurzlebig. Um Daten über die Lebensdauer eines Pods hinaus beizubehalten, können Sie PVs damit den Zugriff auf den Speicher an einem bestimmten Ort definieren, der unabhängig vom Pod ist. Die damit PVs verbundenen Kosten hängen stark von der Art des verwendeten Speichers und der Art der Nutzung durch Anwendungen ab.

Hier sind verschiedene Arten von Speicheroptionen aufgeführt, die Kubernetes PVs auf Amazon EKS unterstützen. Die unten beschriebenen Speicheroptionen sind Amazon EBS, Amazon EFS, Amazon FSx for Lustre, Amazon FSx for NetApp ONTAP.

Volumen im Amazon Elastic Block Store (EBS)

Amazon EBS-Volumes können als Kubernetes genutzt werden, PVs um Speichervolumes auf Blockebene bereitzustellen. Diese eignen sich gut für Datenbanken, die auf zufälligen Lese- und Schreibvorgängen basieren, sowie für durchsatzintensive Anwendungen, die lange, kontinuierliche Lese- und Schreibvorgänge ausführen. Der Amazon Elastic Block Store Container Storage Interface (CSI) -Treiber ermöglicht es Amazon EKS-Clustern, den Lebenszyklus von Amazon EBS-Volumes für persistente Volumes zu verwalten. Das Container Storage Interface ermöglicht und erleichtert die Interaktion zwischen Kubernetes und einem Speichersystem. Wenn ein CSI-Treiber in Ihrem EKS-Cluster bereitgestellt wird, können Sie über die nativen Kubernetes-Speicherressourcen wie Persistent Volumes (PVs), Persistent Volume Claims () und Storage Classes (PVCs) auf seine Funktionen zugreifen. SCs Dieser Link enthält praktische Beispiele für die Interaktion mit Amazon EBS-Volumes mit dem Amazon EBS CSI-Treiber.

Auswahl des richtigen Volumes

Wir empfehlen die Verwendung der neuesten Generation von Blockspeicher (GP3), da diese das richtige Gleichgewicht zwischen Preis und Leistung bietet. Außerdem können Sie damit Volumen-IOPS und Durchsatz unabhängig von der Volume-Größe skalieren, ohne zusätzliche Blockspeicherkapazität bereitstellen zu müssen. Wenn Sie derzeit GP2-Volumes verwenden, empfehlen wir dringend, auf GP3-Volumes zu migrieren. Der Blogbeitrag Migration von Amazon EKS-Clustern von GP2- zu GP3-EBS-Volumes erklärt, wie Sie mit der Funktion CSI Volume Snapshots von GP2 auf GP3 auf Amazon EKS-Clustern mit Sicherung und Wiederherstellung migrieren, was Anwendungsausfälle erfordert.

Amazon EBS ermöglicht die Online-Änderung von Volumeneigenschaften wie Volumengröße, IOPS und Durchsatz. Mit dieser Funktion kann man ohne Anwendungsausfälle von gp2 auf gp3 migrieren, indem man entweder PVC-Anmerkungen verwendet, wie in diesem Blog beschrieben, was den EBS-CSI-Treiber v1.19.0+ erfordert, oder ab Amazon EKS v1.31 und EBS CSI-Treiber 1.35, indem man die hier beschriebene API verwendet. VolumeAttributesClass

Wenn Sie über Anwendungen verfügen, die eine höhere Leistung erfordern und Volumen benötigen, die größer sind als das, was ein einzelnes GP3-Volume unterstützen kann, sollten Sie die Verwendung von io2 Block Express in Betracht ziehen. Dieser Speichertyp ist ideal für Ihre größte, I/O intensivste und geschäftskritischste Bereitstellung wie SAP HANA oder andere große Datenbanken mit geringen Latenzanforderungen. Beachten Sie, dass die EBS-Leistung einer Instance durch die Leistungsgrenzen der Instance begrenzt ist, sodass nicht alle Instances io2 Block Express-Volumes unterstützen. In diesem Dokument finden Sie Informationen zu den unterstützten Instance-Typen und anderen Überlegungen.

Ein einzelnes GP3-Volume kann bis zu 16.000 maximale IOPS, einen maximalen Durchsatz von 1.000 und MiB/s maximal 16 TiB unterstützen. Die neueste Generation des bereitgestellten IOPS-SSD-Volumes, das bis zu 256.000 IOPS, 4.000 MiB/s Durchsatz und 64 TiB bietet.

Unter diesen Optionen sollten Sie Ihre Speicherleistung und Ihre Kosten am besten an die Anforderungen Ihrer Anwendungen anpassen.

Überwachen und optimieren Sie im Laufe der Zeit

Es ist wichtig, die Ausgangsleistung Ihrer Anwendung zu verstehen und sie für ausgewählte Volumes zu überwachen, um zu überprüfen, ob sie Ihren Anforderungen entspricht requirements/expectations oder ob sie überdimensioniert ist (z. B. ein Szenario, in dem bereitgestellte IOPS nicht vollständig genutzt werden).

Anstatt von Anfang an ein großes Volumen zuzuweisen, können Sie die Größe des Volumes schrittweise erhöhen, während Sie Daten ansammeln. Mithilfe der Funktion zur Volumengrößenänderung im Amazon Elastic Block Store CSI-Treiber (aws-ebs-csi-driver) können Sie die Größe von Volumes dynamisch ändern. Beachten Sie, dass Sie nur die Größe des EBS-Volumes erhöhen können.

Um hängengebliebene EBS-Volumes zu identifizieren und zu entfernen, können Sie die Kostenoptimierungskategorie von AWS Trusted Advisor verwenden. Diese Funktion hilft Ihnen dabei, nicht angehängte Volumes oder Volumes mit sehr geringer Schreibaktivität für einen bestimmten Zeitraum zu identifizieren. Es gibt ein cloudnatives, schreibgeschütztes Open-Source-Tool namens Popeye, das Kubernetes-Cluster in Echtzeit scannt und potenzielle Probleme mit bereitgestellten Ressourcen und Konfigurationen meldet. Es kann beispielsweise nach ungenutzten Dateien suchen PVs PVCs und prüfen, ob sie gebunden sind oder ob ein Fehler beim Einbinden des Volumes vorliegt.

Ausführliche Informationen zur Überwachung finden Sie im EKS-Leitfaden zur Kostenoptimierung zur Beobachtbarkeit.

Eine weitere Option, die Sie in Betracht ziehen können, sind die Amazon EBS-Volumenempfehlungen von AWS Compute Optimizer. Dieses Tool identifiziert automatisch die optimale Volume-Konfiguration und das richtige erforderliche Leistungsniveau. Es kann beispielsweise für optimale Einstellungen in Bezug auf bereitgestellte IOPS, Volume-Größen und Typen von EBS-Volumes verwendet werden, basierend auf der maximalen Auslastung in den letzten 14 Tagen. Es quantifiziert auch die potenziellen monatlichen Kosteneinsparungen, die sich aus den Empfehlungen ergeben. Weitere Informationen finden Sie in diesem Blog.

Richtlinie zur Aufbewahrung von Backup

Sie können die Daten auf Ihren Amazon EBS-Volumes sichern, indem Sie point-in-time Snapshots erstellen. Der Amazon EBS CSI-Treiber unterstützt Volume-Snapshots. Mithilfe der hier beschriebenen Schritte erfahren Sie, wie Sie einen Snapshot erstellen und einen EBS-PV wiederherstellen.

Nachfolgende Snapshots sind inkrementelle Backups, d. h., dass nur die Blöcke auf dem Gerät gespeichert werden, die sich nach Ihrem letzten Snapshot geändert haben. Hierdurch wird die zum Erstellen des Snapshots erforderliche Zeit verringert und es werden Speicherkosten eingespart, weil keine Datenduplikate angelegt werden. Die zunehmende Anzahl alter EBS-Snapshots ohne angemessene Aufbewahrungsrichtlinien kann jedoch zu unerwarteten Kosten führen, wenn der Betrieb in großem Umfang erfolgt. Wenn Sie Amazon EBS-Volumes direkt über die AWS-API sichern, können Sie Amazon Data Lifecycle Manager (DLM) nutzen, der eine automatisierte, richtlinienbasierte Lifecycle-Management-Lösung für Amazon Elastic Block Store (EBS) -Snapshots und EBS-gestützte Amazon Machine Images () bietet. AMIs Die Konsole erleichtert die Automatisierung der Erstellung, Aufbewahrung und Löschung von EBS-Snapshots und. AMIs

In einer Kubernetes-Umgebung können Sie ein Open-Source-Tool namens Velero nutzen, um Ihre EBS Persistent Volumes zu sichern. Sie können ein TTL-Flag setzen, wenn Sie den Job so planen, dass Backups ablaufen. Hier ist ein Leitfaden von Velero als Beispiel.

Amazon Elastic File System (EFS)

Amazon Elastic File System (EFS) ist ein serverloses, vollständig elastisches Dateisystem, mit dem Sie Dateidaten über eine standardmäßige Dateisystemschnittstelle und Dateisystemsemantik für ein breites Spektrum von Workloads und Anwendungen gemeinsam nutzen können. Beispiele für Workloads und Anwendungen sind Wordpress und Drupal, Entwicklertools wie JIRA und Git und gemeinsam genutzte Notebook-Systeme wie Jupyter sowie Home-Verzeichnisse.

Einer der Hauptvorteile von Amazon EFS besteht darin, dass es von mehreren Containern bereitgestellt werden kann, die auf mehrere Knoten und mehrere Availability Zones verteilt sind. Ein weiterer Vorteil besteht darin, dass Sie nur für den Speicherplatz zahlen, den Sie tatsächlich nutzen. EFS-Dateisysteme werden beim Hinzufügen und Entfernen von Dateien automatisch vergrößert und verkleinert, sodass keine Kapazitätsplanung erforderlich ist.

Um Amazon EFS in Kubernetes zu verwenden, müssen Sie den Amazon Elastic File System Container Storage Interface (CSI) -Treiber verwenden. aws-efs-csi-driver Derzeit kann der Treiber Zugriffspunkte dynamisch erstellen. Das Amazon EFS-Dateisystem muss jedoch zuerst bereitgestellt und als Eingabe für den Kubernetes-Speicherklassenparameter bereitgestellt werden.

Auswahl der richtigen EFS-Speicherklasse

Amazon EFS bietet vier Speicherklassen.

Zwei Standard-Speicherklassen:

Zwei Speicherklassen für eine Zone:

Die Speicherklassen Infrequent Access (IA) sind kostenoptimiert für Dateien, auf die nicht täglich zugegriffen wird. Mit Amazon EFS Lifecycle Management können Sie Dateien, auf die während der Dauer der Lebenszyklusrichtlinie (7, 14, 30, 60 oder 90 Tage) nicht zugegriffen wurde, in die IA-Speicherklassen verschieben, wodurch die Speicherkosten im Vergleich zu den Speicherklassen EFS Standard und EFS One Zone um bis zu 92 Prozent gesenkt werden können.

Mit EFS Intelligent-Tiering überwacht das Lebenszyklusmanagement die Zugriffsmuster Ihres Dateisystems und verschiebt Dateien automatisch in die optimalste Speicherklasse.

Amazon FSx für Lustre

Lustre ist ein leistungsstarkes paralleles Dateisystem, das häufig in Workloads verwendet wird, die einen Durchsatz von bis zu Hunderten von GB/s und unter einer Millisekunde pro Vorgang erfordern. Es wird für Szenarien wie maschinelles Lernen, Finanzmodellierung, HPC und Videoverarbeitung verwendet. Amazon FSx for Lustre bietet einen vollständig verwalteten gemeinsamen Speicher mit Skalierbarkeit und Leistung, der nahtlos in Amazon S3 integriert ist.

Sie können persistente Kubernetes-Speichervolumes verwenden, die von for Lustre unterstützt werden, indem Sie den FSx FSx for Lustre CSI-Treiber von Amazon EKS oder Ihren selbstverwalteten Kubernetes-Cluster auf AWS verwenden. Weitere Informationen und Beispiele finden Sie in der Amazon EKS-Dokumentation.

Link zu Amazon S3

Es wird empfohlen, ein äußerst beständiges Langzeitdaten-Repository auf Amazon S3 mit Ihrem FSx for Lustre-Dateisystem zu verknüpfen. Nach der Verknüpfung werden große Datensätze nach Bedarf verzögert von Amazon S3 in die FSx for Lustre-Dateisysteme geladen. Sie können Ihre Analysen und Ergebnisse auch wieder in S3 ausführen und dann Ihr Lustre-Dateisystem löschen.

Auswahl der richtigen Bereitstellungs- und Speicheroptionen

FSx for Lustre bietet verschiedene Bereitstellungsoptionen. Die erste Option heißt Scratch und repliziert keine Daten, während die zweite Option als persistent bezeichnet wird, was, wie der Name schon sagt, Daten persistiert.

Die erste Option (Scratch) kann verwendet werden, um die Kosten für die temporäre Datenverarbeitung mit kürzerer Laufzeit zu senken. Die persistente Bereitstellungsoption ist für eine längerfristige Speicherung konzipiert, bei der Daten innerhalb einer AWS Availability Zone automatisch repliziert werden. Sie unterstützt auch sowohl SSD- als auch HDD-Speicher.

Sie können den gewünschten Bereitstellungstyp unter Parametern im Kubernetes des FSx For Lustre-Dateisystems konfigurieren. StorageClass Hier ist ein Link, der Beispielvorlagen bereitstellt.

Aktivieren Sie die Datenkomprimierung

Sie können die Datenkomprimierung auch in Ihrem Dateisystem aktivieren, indem Sie "LZ4" als Datenkomprimierungstyp angeben. Sobald sie aktiviert ist, werden alle neu geschriebenen Dateien FSx für Lustre automatisch komprimiert, bevor sie auf die Festplatte geschrieben und beim Lesen dekomprimiert werden. LZ4 Der Datenkomprimierungsalgorithmus ist verlustfrei, sodass die Originaldaten aus den komprimierten Daten vollständig rekonstruiert werden können.

Sie können den Datenkomprimierungstyp wie LZ4 unter den Parametern im Kubernetes des FSx For Lustre-Dateisystems konfigurieren. StorageClass Die Komprimierung ist deaktiviert, wenn der Wert auf NONE gesetzt ist, was die Standardeinstellung ist. Dieser Link enthält Beispielvorlagen.

Amazon FSx für NetApp ONTAP

Amazon FSx for NetApp ONTAP ist ein vollständig verwalteter gemeinsam genutzter Speicher, der auf dem NetApp ONTAP-Dateisystem basiert. FSx for ONTAP bietet funktionsreichen, schnellen und flexiblen gemeinsamen Dateispeicher, auf den von Linux-, Windows- und macOS-Recheninstanzen aus, die in AWS oder vor Ort ausgeführt werden, umfassend zugegriffen werden kann.

Amazon FSx für NetApp ONTAP unterstützt zwei Speicherstufen: 1 primäre Stufe und 2 Speicherkapazitätspoolstufe.

Die primäre Stufe ist eine bereitgestellte, leistungsstarke SSD-basierte Stufe für aktive, latenzempfindliche Daten. Der vollständig elastische Kapazitätspool-Tier ist kostenoptimiert für Daten, auf die selten zugegriffen wird, wird automatisch skaliert, wenn die Daten darauf verteilt werden, und bietet eine praktisch unbegrenzte Kapazität im Petabyte-Bereich. Sie können Datenkomprimierung und Deduplizierung im Kapazitätspoolspeicher aktivieren und so den Speicherverbrauch Ihrer Daten weiter reduzieren. NetAppDie systemeigene, richtlinienbasierte FabricPool Funktion überwacht kontinuierlich die Datenzugriffsmuster und überträgt Daten automatisch bidirektional zwischen Speicherebenen, um Leistung und Kosten zu optimieren.

NetAppAstra Trident bietet dynamische Speicherorchestrierung mithilfe eines CSI-Treibers, der es Amazon EKS-Clustern ermöglicht, den Lebenszyklus persistenter Volumes zu verwalten, die von Amazon FSx für NetApp ONTAP-Dateisysteme PVs unterstützt werden. Erste Schritte finden Sie unter Verwenden von Astra Trident mit Amazon FSx für NetApp ONTAP in der Astra Trident-Dokumentation.

Weitere Überlegungen

Minimiere die Größe des Container-Images

Sobald Container bereitgestellt sind, werden Container-Images auf dem Host in mehreren Layern zwischengespeichert. Durch die Reduzierung der Größe von Bildern kann der auf dem Host benötigte Speicherplatz reduziert werden.

Indem Sie von Anfang an abgespeckte Basis-Images wie Scratch-Images oder Container-Images ohne Distribution (die nur Ihre Anwendung und ihre Laufzeitabhängigkeiten enthalten) verwenden, können Sie die Speicherkosten senken und zusätzlich weitere Vorteile wie die Verringerung der Angriffsfläche und kürzere Abrufzeiten von Images nutzen.

Sie sollten auch die Verwendung von Open-Source-Tools wie Slim.ai in Betracht ziehen, die eine einfache und sichere Methode zur Erstellung minimaler Images bieten.

Mehrere Ebenen von Paketen, Tools, Anwendungsabhängigkeiten und Bibliotheken können die Größe des Container-Images leicht erhöhen. Durch die Verwendung mehrstufiger Builds können Sie Artefakte selektiv von einer Phase in eine andere kopieren und dabei alles, was nicht benötigt wird, aus dem endgültigen Image ausschließen. Weitere bewährte Methoden zur Image-Erstellung finden Sie hier.

Eine weitere Sache, die Sie berücksichtigen sollten, ist, wie lange zwischengespeicherte Bilder gespeichert werden sollen. Möglicherweise möchten Sie die veralteten Bilder aus dem Image-Cache löschen, wenn eine bestimmte Menge an Speicherplatz belegt ist. Auf diese Weise können Sie sicherstellen, dass genügend Speicherplatz für den Betrieb des Hosts zur Verfügung steht. Standardmäßig führt das Kubelet alle fünf Minuten eine Garbage-Collection für unbenutzte Bilder und jede Minute für unbenutzte Container durch.

Um Optionen für die Garbage-Collection von ungenutzten Containern und Bildern zu konfigurieren, optimieren Sie das Kubelet mithilfe einer Konfigurationsdatei und ändern Sie die Parameter für die Garbage-Collection anhand des Ressourcentyps. KubeletConfiguration

In der Kubernetes-Dokumentation erfahren Sie mehr darüber.