Leistung - Amazon EKS
Skalierung und Leistung von Anwendungen

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.

Leistung

Skalierung und Leistung von Anwendungen

Verwaltung von ML-Artefakten, Bereitstellung von Frameworks und Startoptimierung

Die Bereitstellung von Modellen für maschinelles Lernen (ML) auf Amazon EKS erfordert eine sorgfältige Überlegung, wie Modelle in Container-Images und Laufzeitumgebungen integriert werden. Dies gewährleistet Skalierbarkeit, Reproduzierbarkeit und effiziente Ressourcennutzung. In diesem Thema werden die verschiedenen Ansätze zum Umgang mit ML-Modellartefakten, zur Auswahl von Serving-Frameworks und zur Optimierung der Startzeiten von Containern mithilfe von Techniken wie Pre-Caching beschrieben, die allesamt darauf zugeschnitten sind, die Startzeiten von Containern zu verkürzen.

Reduzierung der Größe von Container-Bildern

  • Das Reduzieren der Größe von Container-Images beim Start ist eine weitere Möglichkeit, Bilder zu verkleinern. Sie können bei jedem Schritt des Container-Image-Erstellungsprozesses Kürzungen vornehmen. Wählen Sie zunächst Basis-Images aus, die die geringste Anzahl an erforderlichen Abhängigkeiten enthalten. Schließen Sie bei der Image-Erstellung nur die wesentlichen Bibliotheken und Artefakte ein, die erforderlich sind. Versuchen Sie beim Erstellen von Images, mehrere RUN- oder COPY-Befehle zu kombinieren, um eine geringere Anzahl größerer Ebenen zu erstellen. Das Erstellen kleinerer Bilder hat die folgenden Vor- und Nachteile:

  • Vorteile:

    • Das Abrufen von Bildern ist schneller und es wird insgesamt weniger Speicherplatz benötigt.

    • Kleinere Bilder haben einen geringeren Angriffsvektor.

  • Nachteile:

    • Da Container-Images immer optimierter geworden sind, müssen Sie mehrere Images erstellen, um den Anforderungen für die Ausführung in unterschiedlichen Umgebungen gerecht zu werden.

    • Größeneinsparungen durch die Kombination von Befehlen können manchmal vernachlässigbar sein. Sie sollten daher verschiedene Build-Ansätze testen, um herauszufinden, was die besten Ergebnisse bringt. Wählen Sie für AI/ML Frameworks Varianten wie reine Runtime-Images (z. B. mit 3,03 GB gegenüber devel mit 6,66 GB), pytorch/pytorch:2.7.1-cuda11.8-cudnn9-runtime aber Benchmark-Workloads als kleinere Images können die JIT-Kompilierung überspringen, was zu langsameren Codepfaden führt. Verwenden Sie mehrstufige Builds, um Build und Runtime zu trennen, und kopieren Sie nur benötigte Artefakte (z. B. über COPY —from= für Registries oder lokale Kontexte). Nutzen Sie die Ebenenoptimierung, indem Sie COPY in einer Assemblierungsphase für weniger Ebenen kombinieren. Dies wirkt sich jedoch negativ auf die geringere Cache-Effizienz und längere Build-Zeiten aus.

Umgang mit ML-Modellartefakten in Bereitstellungen

Eine wichtige Entscheidung ist, wie mit den ML-Modellartefakten (z. B. Gewichten, Konfigurationen) selbst umgegangen werden soll. Die Wahl wirkt sich auf die Image-Größe, die Bereitstellungsgeschwindigkeit, die Häufigkeit der Modellaktualisierungen und den betrieblichen Aufwand aus. Wenn wir uns auf das Speichern des „Modells“ beziehen, beziehen wir uns nicht auf die Modellartefakte (z. B. trainierte Parameter, Modellgewichte). Es gibt drei Ansätze für den Umgang mit ML-Modellartefakten in Amazon EKS. Jeder hat seine Nachteile, und der beste hängt von der Größe Ihres Modells, der Aktualisierungsfrequenz und den Infrastrukturanforderungen ab — von der geringsten bis zur am meisten empfohlenen Liste:

Das Modell in das Container-Image einbinden Kopieren Sie die Modelldateien (z. B. .safetensors, .pth, .h5) während der Image-Erstellung in das Container-Image (z. B. Dockerfile). Das Modell ist Teil des unveränderlichen Images. Wir empfehlen, diesen Ansatz für kleinere Modelle mit seltenen Updates zu verwenden.

  • Vorteile: Sorgt für Konsistenz und Reproduzierbarkeit, verhindert Ladeverzögerungen und vereinfacht das Abhängigkeitsmanagement.

  • Nachteile: Führt zu größeren Image-Größen, verlangsamt Builds und Pushs, erfordert Neuaufbau und erneute Bereitstellung für Modellaktualisierungen. Aufgrund des Durchsatzes beim Abrufen der Registrierung nicht ideal für große Modelle. Darüber hinaus kann dies aufgrund des komplexeren Setups zu längeren Feedback-Schleifen beim Experimentieren, Debuggen und Testen führen und die Speicherkosten erhöhen, wenn mehrere Images gleichzeitig gespeichert werden.

Modell zur Laufzeit herunterladen Beim Start des Containers lädt die Anwendung das Modell über Skripts in einem Init-Container oder Entrypoint von einem externen Speicher herunter (z. B. Amazon S3, unterstützt von S3 CRT für optimierte Übertragungen mit hohem Durchsatz mithilfe von Methoden wie Mountpoint for S3 CSI Driver, AWS S3 CLI oder s5cmd OSS CLI). Für große Modelle mit häufigen Updates empfehlen wir, mit diesem Ansatz zu beginnen.

  • Vorteile: Konzentriert Container-Images auf das code/runtime, enables easy model updates without rebuilds, supports versioning via storage metadata. It also allows for A/B Testen, Hot-Swapping oder Rollback von Modellen, ohne die Größe des Container-Images zu erhöhen, und bietet die Möglichkeit, Modelle zwischen verschiedenen Anwendungen gemeinsam zu nutzen, ohne sie in alle Container-Images packen zu müssen. Darüber hinaus führt es zu minimalen Änderungen an den Workflows von ML- oder Anwendungsteams und ermöglicht schnellere Container-Builds, um Experimente und Tests zu erleichtern. Die Verwendung von S3-CRT-gestützten Tools wie der AWS-CLI, s5cmd oder dem Mountpoint S3 CSI-Treiber kann die Download-Latenz erheblich reduzieren und die Leistung für große Dateien verbessern, was je nach Netzwerk- und Registry-Leistung häufig zu kürzeren Gesamtstartzeiten des Pods führt als das Abrufen großer gebackener Container-Images aus Registern wie ECR.

  • Nachteile: Führt zu potenziellen Netzwerkausfällen (erfordert Wiederholungslogik) und erfordert Authentifizierung und Zwischenspeicherung. Zusätzliche betriebliche Komplexität entsteht durch die Handhabung des Download-Vorgangs, einschließlich Wiederholungen, Fehlerbehandlung und Backoff, sowie durch zusätzliches Speicher- und Bereinigungsmanagement, das die ECR-Funktionalität repliziert.

Mounten des Modells über persistente Volumes Speichern Sie das Modell in einem externen Speicher (z. B. Amazon EFS, EBS, FSx für NetApp ONTAP, FSx für Lustre, FSx für OpenZFS oder S3 über den Mountpoint S3 CSI-Treiber) und mounten Sie es als Kubernetes (PV). PersistentVolume Dies sind die Dateien und Daten, die während des Trainingsprozesses des Modells generiert werden und es ermöglichen, Vorhersagen oder Schlüsse zu ziehen. Wir empfehlen, diesen Ansatz für gemeinsam genutzte Modelle in Pods oder Clustern zu verwenden.

  • Vorteile: Entkoppelt das Modell vom Image für den gemeinsamen Zugriff, erleichtert Aktualisierungen ohne Neustarts (sofern von Ihrem Framework unterstützt) und verarbeitet große Datensätze effizient. Es ermöglicht auch Kubernetes-gesteuerte Bereitstellung und Zugriffskontrolle über Funktionen wie Klonen, Teilen und Snapshots, wodurch die Notwendigkeit reduziert wird, Modelle zu kopieren und neue Operationen zu erstellen. POSIX-basierte Zugriffskontrolle auf Modelle ist ebenso möglich wie die Möglichkeit, Modellversionen getrennt von der Anwendung zu aktualisieren, ohne das Container-Image neu erstellen zu müssen, und schnellere Container-Builds für Experimente und Tests. Bei AI/ML Inferenzanwendungen, die Artefakte in den Speicher einlesen, ermöglicht dies das direkte Laden der Daten aus dem externen Dateisystem, ohne dass sie zwischengespeichert werden müssen, was die Ladeleistung verbessert. Darüber hinaus bieten Dienste wie NetApp ONTAP und Lustre FSx für die Speicherung großer Modelle Techniken zur Speicheroptimierung (z. B. Deduplizierung, Komprimierung, Thin Provisioning), Versionierung über Snapshots und Unterstützung für die Wiederverwendung derselben Datei, ohne Speicherplatz zu verschwenden. FSx Andere Dienste, wie S3, bieten native Versionierung. Dieser Ansatz kann sich je nach Replikationskonfiguration auch über Cluster und potenziell Regionen erstrecken (z. B. asynchrone Replikation in FSx oder regionsübergreifende Replikation in S3 und EFS).

  • Nachteile: Kann die I/O Latenz erhöhen, wenn eine Verbindung zum Netzwerk besteht, erfordert Speicherbereitstellung und Zugriffskontrollen, ist möglicherweise weniger portabel (z. B. EBS), wenn der Speicher clusterspezifisch ist. Zu den Kompromissen gehören die zusätzliche betriebliche Komplexität im Zusammenhang mit CI/CD Änderungen und der Wartung von Loader-Prozessen, die Notwendigkeit maßgeschneiderter TTL/retention Mechanismen zur Senkung der Speicherkosten und eine komplexere regionsübergreifende Replikation. Die Leseleistung für Modellartefakte sollte anhand der Downloadzeit von Container-Images gemessen werden.

Bereitstellung von ML-Modellen

Die Bereitstellung und Bereitstellung von Modellen für maschinelles Lernen (ML) auf Amazon EKS erfordert die Auswahl eines geeigneten Model-Serving-Ansatzes, um Latenz, Durchsatz, Skalierbarkeit und einfache Bedienung zu optimieren. Die Wahl hängt von Ihrem Modelltyp (z. B. Sprache, Visionsmodell), den Arbeitslastanforderungen (z. B. Echtzeit-Inferenz) und der Expertise Ihres Teams ab. Zu den gängigen Ansätzen gehören Python-basierte Setups für das Prototyping, dedizierte Modellserver für Funktionen in Produktionsqualität und spezialisierte Inferenz-Engines für hohe Leistung und Effizienz. Jede Methode beinhaltet Kompromisse bei der Komplexität der Einrichtung, der Leistung und der Ressourcennutzung. Beachten Sie, dass die Bereitstellung von Frameworks die Größe von Container-Images aufgrund von Abhängigkeiten (um ein Vielfaches GBs) erhöhen kann, was sich möglicherweise auf die Startzeiten auswirkt. Ziehen Sie eine Entkopplung mithilfe von Techniken zur Behandlung von Artefakten in Betracht, um dieses Problem zu minimieren. Die Optionen sind von den am wenigsten empfohlenen bis hin zu den am meisten empfohlenen Optionen aufgeführt:

Verwenden von Python-Frameworks (z. B. FastAPI, HuggingFace Transformers with PyTorch) Entwickeln Sie eine benutzerdefinierte Anwendung mithilfe von Python-Frameworks und betten Sie Modelldateien (Gewichte, Konfiguration, Tokenizer) in ein containerisiertes Knoten-Setup ein.

  • Vorteile: Einfaches Prototyping, nur Python ohne zusätzliche Infrastruktur, kompatibel mit allen HuggingFace Modellen, einfache Kubernetes-Bereitstellung.

  • Nachteile: Beschränkt auf request/simple Einzelstapelverarbeitung, langsame Token-Generierung (keine optimierten Kernel), ineffizienter Speicher, fehlende Skalierung/Überwachung und lange Startzeiten.

  • Empfehlung: Wird für die erste Prototypenentwicklung oder für Einzelknotenaufgaben verwendet, die eine benutzerdefinierte Logikintegration erfordern.

Verwenden Sie spezielle Model-Serving-Frameworks (z. B. TensorRT-LLM, TGI) Verwenden Sie spezialisierte Server wie TensorRT-LLM oder TGI für ML-Inferenz und verwalten Sie das Laden, Routing und Optimierung von Modellen. Diese unterstützen Formate wie Safetensors mit optionaler Kompilierung oder Plugins.

  • Vorteile: Bietet Batching (Parallelität). static/in-flight or continuous), quantization (INT8, FP8, GPTQ), hardware optimizations (NVIDIA, AMD, Intel, Inferentia), and multi-GPU support (Tensor/Pipeline TensorRT-LLM unterstützt verschiedene Modelle (LLMs, Encoder-Decoder), während TGI die Integration nutzt. HuggingFace

  • Nachteile: TensorRT-LLM muss kompiliert werden und ist nur für NVIDIA verfügbar; TGI ist möglicherweise weniger effizient beim Batching; beide erhöhen den Konfigurationsaufwand und sind möglicherweise nicht für alle Modelltypen geeignet (z. B. Nicht-Transformatoren).

  • Empfehlung: Geeignet für PyTorch/TensorFlow Modelle, die Produktionskapazitäten wie Tests oder hohen Durchsatz mit kompatibler Hardware benötigen. A/B

Verwendung spezialisierter Inferenz-Engines mit hohem Durchsatz (z. B. vLLM) Nutzen Sie fortschrittliche Inferenz-Engines wie vLLM und optimieren Sie die LLM-Bereitstellung mit, die Batching während des Fluges und die Quantisierung ( PagedAttention, -KV, AWQ), die in die automatische Skalierung von EKS integriert werden können. INT8 FP8

  • Vorteile: Hoher Durchsatz und Speichereffizienz (40-60% VRAM-Einsparungen), dynamische Bearbeitung von Anfragen, Token-Streaming, Tensor Parallel Multi-GPU-Unterstützung mit einem Knoten und umfassende Hardwarekompatibilität.

  • Nachteile: Optimiert für reine Decoder-Transformatoren (z. B. LLa MA), weniger effektiv für Modelle ohne Transformator, erfordert kompatible Hardware (z. B. NVIDIA) und Einrichtungsaufwand. GPUs

  • Empfehlung: Erste Wahl für LLM-Inferenz mit hohem Volumen und geringer Latenz auf EKS, wodurch Skalierbarkeit und Leistung maximiert werden.

Container-Images vor dem Zwischenspeichern

Große Container-Images (z. B. Modelle wie PyTorch) können zu Kaltstartverzögerungen führen, die sich auf die Latenz auswirken. Für latenzempfindliche Workloads wie horizontal skalierte Echtzeit-Inferenz-Workloads, bei denen ein schneller Pod-Start entscheidend ist, empfehlen wir, Container-Images vorab zu laden, um Verzögerungen bei der Initialisierung zu minimieren. Ziehen Sie die folgenden Ansätze in Betracht, von den am wenigsten empfohlenen bis hin zu den am meisten empfohlenen:

Verwenden des Container-Runtime-Cache zum Pre-Pull von Images

  • Sie können Container-Images mithilfe von Kubernetes-Ressourcen (z. B. DaemonSet oder Deployment) vorab auf Knoten abrufen, um den Container-Runtime-Cache des Knotens zu füllen. Der Container-Runtime-Cache ist der lokale Speicher, der von der Container-Laufzeit verwaltet wird (z. B. [containerd] (https://containerd.io/)), in dem Bilder gespeichert werden, nachdem sie aus einer Registrierung abgerufen wurden. Durch das Pre-Pull wird sichergestellt, dass Bilder lokal verfügbar sind, wodurch Verzögerungen beim Herunterladen beim Pod-Start vermieden werden. Dieser Ansatz ist nützlich, wenn EBS-Snapshots nicht vorkonfiguriert sind oder wenn das Vorabziehen von Images bevorzugt wird. Beispiele für Pre-Pull-Images finden Sie im [AWS Samples GitHub Repository] (https://github.com/aws-samples/aws-do-eks/tree/main/Container-Root/eks/deployment/prepull). Beachten Sie, dass Alternativen wie Lazy Loading mit dem [SOCI Snapshotter] (https://github.com/awslabs/soci-snapshotter) (einem Container-Plugin für partielle Bildabrufe) diese Methoden ergänzen können, obwohl dafür eine benutzerdefinierte Einrichtung erforderlich ist und möglicherweise nicht für alle Szenarien geeignet ist. Die Verwendung des Container-Runtime-Cache hat die folgenden Vor- und Nachteile:

  • Vorteile:

    • EBS-Snapshots müssen nicht verwaltet werden.

    • DaemonSets Sie erhalten immer die neueste Container-Image-Version.

    • Flexibler, da Bilder aktualisiert werden können, ohne dass Schnappschüsse neu erstellt werden müssen.

    • Reduziert dennoch die Startzeit des Pods, indem sichergestellt wird, dass sich die Bilder bereits auf dem Knoten befinden.

  • Nachteile:

    • Das anfängliche Abrufen großer Bilder kann immer noch einige Zeit in Anspruch nehmen, obwohl dies im Voraus erfolgt.

    • Möglicherweise nicht so effizient wie EBS-Snapshots für sehr große Bilder (über 10 GB), da das Abrufen immer noch erforderlich ist, allerdings nicht beim Start des Pods.

    • Bei DaemonSets wird ein Image vorab auf alle Knoten geladen, auf denen der Pod möglicherweise ausgeführt wird. Wenn beispielsweise auf 1000 Knoten nur eine Instanz eines Pods ausgeführt wird, wird auf allen 1000 Knoten Speicherplatz verbraucht, nur um die eine Instanz auf einem Knoten auszuführen.

    • Bei Inferenz-Workloads in Echtzeit, bei denen Knoten ein- oder ausgeschaltet werden, können neue Knoten, die mit Tools wie Cluster Autoscaler hinzugefügt werden, Workload-Pods planen, bevor der Pre-Pull das Abrufen des Images abgeschlossen hat. DaemonSet Dies kann dazu führen, dass der erste Pod auf dem neuen Knoten den Pull trotzdem auslöst, was den Start möglicherweise verzögert und sich auf Anforderungen mit niedriger Latenz auswirkt.

    • Die Garbage-Collection von Kubelet-Images kann sich auf vorab abgerufene Images auswirken, indem ungenutzte Images entfernt werden, wenn die Festplattennutzung bestimmte Schwellenwerte überschreitet oder wenn sie ein konfiguriertes Höchstalter für unbenutzte Dateien überschreiten. Bei Scale-In/Out-Mustern kann dies dazu führen, dass Bilder auf inaktiven Knoten entfernt werden, was bei nachfolgenden Skalierungen erneut abgerufen werden muss und die Zuverlässigkeit des Caches bei ausgelasteten Workloads beeinträchtigt wird.

EBS-Snapshots verwenden

  • Sie können einen Amazon Elastic Block Store (EBS) -Snapshot von zwischengespeicherten Container-Images erstellen und diesen Snapshot für EKS-Worker-Knoten wiederverwenden. Dadurch wird sichergestellt, dass die Bilder beim Start des Nodes lokal vorab abgerufen werden, wodurch die Pod-Initialisierungszeit reduziert wird. Weitere Informationen zur Verwendung von Karpenter und diesen EKS Terraform Blueprints für verwaltete Knotengruppen finden Sie unter Reduzieren Sie die Container-Startzeit auf Amazon EKS mit Bottlerocket-Datenvolumen. Wir empfehlen, die Erstellung von EBS-Snapshots als Teil Ihrer CI/CD Pipeline zu automatisieren, damit sie stets auf dem neuesten Stand der Container-Image-Versionen sind. up-to-date Die Verwendung von EBS-Snapshots hat die folgenden Vor- und Nachteile:

  • Vorteile:

    • Macht das Abrufen großer Container-Images beim Pod-Start überflüssig, wodurch die Startzeit erheblich reduziert wird (z. B. von 10-15 Minuten auf Sekunden für Bilder, die größer als 10 GB sind).

    • Stellt sicher, dass Bilder beim Start des Knotens lokal verfügbar sind.

    • Besonders vorteilhaft für Inferenz-Workloads mit großen Container-Images.

  • Nachteile:

    • Erfordert die Wartung und Aktualisierung von EBS-Snapshots bei jedem Image- oder Versionsupgrade.

    • Erfordert zusätzliche Schritte, um sicherzustellen, dass alle Ihre Workloads die neueste Container-Image-Version verwenden.

    • Beinhaltet zusätzliche betriebliche Aktivitäten zur Erstellung und Verwaltung von Snapshots.

    • Kann unnötige Images enthalten, wenn sie nicht ordnungsgemäß verwaltet werden. Dies kann jedoch durch die richtige Konfiguration des Knotenpools behoben werden.

Optimieren Sie die Leistung beim Abrufen von Bildern

Wir empfehlen dringend, die Leistung beim Abrufen von Container-Images für Amazon EKS-Cluster zu optimieren, auf denen AI/ML Workloads ausgeführt werden. Die Verwendung großer, nicht optimierter Basis-Images oder eine ineffiziente Layer-Reihenfolge können zu langsamen Pod-Startzeiten, erhöhtem Ressourcenverbrauch und verminderter Inferenzlatenz führen. Um dieses Problem zu lösen, sollten Sie kleine, schlanke Basis-Images mit minimalen Abhängigkeiten verwenden, die auf Ihre Workloads zugeschnitten sind. Sie können auch die AWS Deep Learning Containers (DLCs) in Betracht ziehen, bei denen es sich um vorgefertigte Container-Images handelt, die die Ausführung beliebter Deep-Learning-Frameworks (z. B. PyTorchund TensorFlow) erleichtern. Weitere Informationen zum Erstellen eines benutzerdefinierten Images finden Sie unter Anpassen von Deep Learning Containers. Wenn Sie benutzerdefinierte Images erstellen, sollten Sie einfache Basis-Images in Betracht ziehen und nur die benötigten Bibliotheken hinzufügen, um die Bilder schlank zu halten. Verwenden Sie mehrstufige Builds, um die Ebenengröße zu reduzieren und die Reihenfolge der Ebenen für effizientes Caching zu optimieren. Weitere Informationen finden Sie in den Docker Best Practices für die Erstellung von Images.

Reduzieren Sie die Startzeiten von Containern, indem Sie Container-Images vorab in Datenvolumes laden

Für Machine-Learning-Workloads, die eine geringe Latenz beim Pod-Start erfordern, wie z. B. Inferenz in Echtzeit, empfehlen wir, Container-Images vorab zu laden, um Verzögerungen bei der Initialisierung zu minimieren. Große Container-Images können den Pod-Start verlangsamen, insbesondere auf Knoten mit begrenzter Bandbreite. Neben der Verwendung minimaler Basis-Images, mehrstufiger Builds und Lazy-Loading-Techniken sollten Sie auch die folgenden Ansätze zum Vorladen von Images in Amazon EKS in Betracht ziehen. Ziehen Sie neben der Verwendung von Minimal-Base-Images, mehrstufigen Builds und Lazy-Loading-Techniken auch die folgenden Optionen in Betracht:

  • Bilder mithilfe von EBS-Snapshots vorab laden: Erstellen Sie einen Amazon Elastic Block Store (EBS) -Snapshot von zwischengespeicherten Container-Images und verwenden Sie diesen Snapshot für EKS-Worker-Knoten erneut. Dies fügt zwar zusätzliche betriebliche Aktivitäten hinzu, stellt aber sicher, dass die Images beim Start des Nodes lokal vorab abgerufen werden, wodurch die Pod-Initialisierungszeit reduziert wird. Weitere Informationen zur Verwendung von Karpenter und diesen EKS Terraform Blueprints für verwaltete Knotengruppen finden Sie unter Reduzieren Sie die Container-Startzeit auf Amazon EKS mit Bottlerocket-Datenvolumen.

  • Pre-Pull von Images in den Container-Runtime-Cache: Mithilfe von Kubernetes-Ressourcen (z. B. Deployment) werden Container-Images vorab auf Knoten abgerufen, DaemonSet um den Container-Runtime-Cache des Knotens zu füllen. Der Container-Runtime-Cache ist der lokale Speicher, der von der Container-Laufzeit (z. B. containerd) verwaltet wird und in dem Bilder gespeichert werden, nachdem sie aus einer Registrierung abgerufen wurden. Durch das Pre-Pull wird sichergestellt, dass Bilder lokal verfügbar sind, wodurch Verzögerungen beim Herunterladen beim Pod-Start vermieden werden. Dieser Ansatz ist nützlich, wenn EBS-Snapshots nicht vorkonfiguriert sind oder wenn das Vorabziehen von Images bevorzugt wird. Testen Sie diesen Ansatz in einer Staging-Umgebung, um Verbesserungen der Latenz zu überprüfen. Beispiele für Pre-Pull-Images finden Sie im GitHub AWS-Beispiel-Repository.