AWS eks documentation change
Summary
Restructured sections on optimizing container startup times, including renaming sections and moving content about reducing container image sizes under a new section about optimizing image pull times.
Security assessment
Changes focus on performance optimization for container startup in EKS for AI/ML workloads. No evidence of addressing security vulnerabilities or adding security features.
Diff
diff --git a/eks/latest/best-practices/aiml-performance.md b/eks/latest/best-practices/aiml-performance.md index c6f6d5102..621263f24 100644 --- a//eks/latest/best-practices/aiml-performance.md +++ b//eks/latest/best-practices/aiml-performance.md @@ -5 +5 @@ -Managing ML Artifacts, Serving Frameworks, and Startup OptimizationPre-caching Container ImagesUse NVMe for kubelet and containerd storage +Managing ML Artifacts, Serving Frameworks, and Startup OptimizationOptimizing container image pull timesConsider NVMe for kubelet and containerd storage @@ -13,4 +12,0 @@ Deploying machine learning (ML) models on Amazon EKS requires thoughtful conside -### Reducing Container Image Sizes - -Reducing the size of container images during startup is another way to make images smaller. You can make reductions at every step of the container image build process. To start, choose base images that contain the least number of dependencies required. During image builds, include only the essential libraries and artifacts that are required. When building images, try combining multiple `RUN` or `COPY` commands to create a smaller number of larger layers. For AI/ML frameworks, use multi-stage builds to separate build and runtime, copying only required artifacts (e.g., via `COPY —from=` for registries or local contexts), and select variants like runtime-only images (e.g., `pytorch/pytorch:2.7.1-cuda11.8-cudnn9-runtime` at 3.03 GB vs. devel at 6.66 GB). To learn more, see [Reducing container image size](https://awslabs.github.io/ai-on-eks/docs/guidance/container-startup-time/reduce-container-image-size) in the AI on EKS Workshop. - @@ -67 +63 @@ Deploying and serving machine learning (ML) models on Amazon EKS requires select -## Pre-caching Container Images +## Optimizing container image pull times @@ -69 +65,5 @@ Deploying and serving machine learning (ML) models on Amazon EKS requires select -Large container images (such as those containing models like PyTorch) can cause cold start delays that impact latency. For latency-sensitive workloads, like real-time inference workloads scaled horizontally and quick pod startup is critical, we recommend preloading container images to minimize initialization delays. Consider the following approaches from least to most recommended: +Large container images can cause cold start delays that impact pod start-up latency. For latency-sensitive workloads, like real-time inference workloads scaled horizontally, quick pod startup is critical. Consider the following approaches to optimize container image pull times: + +### Reducing Container Image Sizes + +Reducing the size of container images during startup is another way to make images smaller. You can make reductions at every step of the container image build process. To start, choose base images that contain the least number of dependencies required. During image builds, include only the essential libraries and artifacts that are required. When building images, try combining multiple `RUN` or `COPY` commands to create a smaller number of larger layers. For AI/ML frameworks, use multi-stage builds to separate build and runtime, copying only required artifacts (e.g., via `COPY —from=` for registries or local contexts), and select variants like runtime-only images (e.g., `pytorch/pytorch:2.7.1-cuda11.8-cudnn9-runtime` at 3.03 GB vs. devel at 6.66 GB). To learn more, see [Reducing container image size](https://awslabs.github.io/ai-on-eks/docs/guidance/container-startup-time/reduce-container-image-size) in the AI on EKS Workshop. @@ -114 +114 @@ See [AWS GitHub repository](https://github.com/aws-samples/aws-do-eks/tree/main/ -## Use NVMe for kubelet and containerd storage +## Consider NVMe for kubelet and containerd storage