AWS eks documentation change
Summary
Updated Karpenter configuration to support multiple instance types, simplified containerd configuration, added Prometheus/Grafana resource limits and node selectors, disabled unnecessary components, and improved ODCR cleanup instructions.
Security assessment
The change introduces resource limits and node selectors for monitoring components (Prometheus, Grafana) which improve cluster stability and prevent resource exhaustion attacks. Disabling unused components (Alertmanager, Prometheus-adapter) reduces attack surface. No specific vulnerability is addressed.
Diff
diff --git a/eks/latest/userguide/ml-cluster-setup-cli.md b/eks/latest/userguide/ml-cluster-setup-cli.md index 0b2ae28d3..4bb6b1567 100644 --- a//eks/latest/userguide/ml-cluster-setup-cli.md +++ b//eks/latest/userguide/ml-cluster-setup-cli.md @@ -179 +179 @@ Store your Karpenter version in an environment variable for later use. For the l - instanceType: m6i.2xlarge + instanceTypes: ["m6i.2xlarge", "m5.2xlarge", "m6a.2xlarge", "m5a.2xlarge", "m7i.2xlarge"] @@ -192,0 +193,5 @@ Store your Karpenter version in an environment variable for later use. For the l +The `system` managed node group lists several instance types of the same size (8 vCPU, 32 GiB) rather than a single type. If one type is temporarily unavailable in an Availability Zone, the node group’s Auto Scaling group falls back to another type, which avoids `InsufficientInstanceCapacity` launch failures. For an On-Demand managed node group, all listed instance types must have the same vCPU and memory so the node size is uniform. + +Create the cluster with the config file: + + @@ -368,7 +372,0 @@ Self-managed Karpenter does not include a default NodeClass. You first create an - MIME-Version: 1.0 - Content-Type: multipart/mixed; boundary="BOUNDARY" - - --BOUNDARY - Content-Type: application/node.eks.aws - - --- @@ -380,10 +377,0 @@ Self-managed Karpenter does not include a default NodeClass. You first create an - containerd: - config: | - [plugins."io.containerd.snapshotter.v1.soci"] - [plugins."io.containerd.snapshotter.v1.soci".blob] - max_concurrent_downloads_per_image = 20 - concurrent_download_chunk_size = "16mb" - max_concurrent_unpacks_per_image = 12 - discard_unpacked_layers = true - - --BOUNDARY-- @@ -394,12 +382 @@ Self-managed Karpenter does not include a default NodeClass. You first create an -The `FastImagePull` feature gate enables SOCI snapshotter parallel pull mode, which downloads and unpacks image layers concurrently. This matches the EKS Auto Mode behavior on G, P, and Trn instance families. The `containerd.config` block tunes the SOCI snapshotter for ECR-hosted images: - - * `max_concurrent_downloads_per_image: 20` allows up to 20 layer downloads in parallel per image. Default is 3 on Bottlerocket and 20 on AL2023. Recommended value for ECR. - - * `concurrent_download_chunk_size: "16mb"` splits each layer into 16 MB chunks downloaded in parallel via HTTP range requests. Recommended for registries that support range GETs (ECR does). - - * `max_concurrent_unpacks_per_image: 12` unpacks up to 12 layers at once. Default is 1 on Bottlerocket and 12 on AL2023. - - * `discard_unpacked_layers: true` deletes compressed layer blobs after unpacking to save disk space. - - - +The `FastImagePull` feature gate enables SOCI snapshotter parallel pull mode, which downloads and unpacks image layers concurrently. This matches the EKS Auto Mode behavior on G, P, and Trn instance families. @@ -586 +563 @@ Spot instances launched by Karpenter will not appear in the EC2 Spot Requests co -To use reserved capacity first with Spot/On-Demand fallback, create an ODCR and attach it to your NodeClass, then update the dynamic NodePool from Step 2 to also allow `reserved` capacity. The reservation API call is the same for both paths; the NodeClass attachment differs because EKS Auto Mode and self-managed Karpenter use different NodeClass kinds. +To use reserved capacity first with Spot/On-Demand fallback, create an On-Demand Capacity Reservation (ODCR) and attach it to your NodeClass, then update the dynamic NodePool from Step 2 to also allow `reserved` capacity. The reservation API call is the same for both paths; the NodeClass attachment differs because EKS Auto Mode and self-managed Karpenter use different NodeClass kinds. @@ -718,7 +694,0 @@ For self-managed Karpenter, re-apply the `EC2NodeClass` you created in Step 2 wi - MIME-Version: 1.0 - Content-Type: multipart/mixed; boundary="BOUNDARY" - - --BOUNDARY - Content-Type: application/node.eks.aws - - --- @@ -730,10 +699,0 @@ For self-managed Karpenter, re-apply the `EC2NodeClass` you created in Step 2 wi - containerd: - config: | - [plugins."io.containerd.snapshotter.v1.soci"] - [plugins."io.containerd.snapshotter.v1.soci".blob] - max_concurrent_downloads_per_image = 20 - concurrent_download_chunk_size = "16mb" - max_concurrent_unpacks_per_image = 12 - discard_unpacked_layers = true - - --BOUNDARY-- @@ -959,0 +920,6 @@ Create the values file: + alertmanager: + enabled: false + + prometheus-adapter: + enabled: false + @@ -965,0 +932,12 @@ Create the values file: + enableRemoteWriteReceiver: true + retention: 2h + scrapeInterval: 30s + evaluationInterval: 30s + podMonitorSelectorNilUsesHelmValues: false + serviceMonitorSelectorNilUsesHelmValues: false + resources: + requests: + cpu: 500m + memory: 1Gi + limits: + memory: 8Gi @@ -974,5 +952,2 @@ Create the values file: - retention: 5h - scrapeInterval: 30s - evaluationInterval: 30s - podMonitorSelectorNilUsesHelmValues: false - serviceMonitorSelectorNilUsesHelmValues: false + nodeSelector: + node-role: system @@ -980,2 +955,23 @@ Create the values file: - alertmanager: - enabled: false + prometheusOperator: + resources: + requests: + cpu: 100m + memory: 128Mi + limits: + memory: 256Mi + nodeSelector: + node-role: system + admissionWebhooks: + patch: + nodeSelector: + node-role: system + + kube-state-metrics: + resources: + requests: + cpu: 50m + memory: 128Mi + limits: + memory: 512Mi + nodeSelector: + node-role: system @@ -987,0 +984,8 @@ Create the values file: + resources: + requests: + cpu: 100m + memory: 256Mi + limits: + memory: 1Gi + nodeSelector: + node-role: system @@ -1032,0 +1037,6 @@ Create the values file: + vllm-load-analysis: + gnetId: 25494 + revision: 1 + datasource: + - name: DS_PROMETHEUS + value: Amazon-Managed-Prometheus @@ -1034,0 +1045,6 @@ Create the values file: + resources: + requests: + cpu: 50m + memory: 64Mi + limits: + memory: 128Mi @@ -1042 +1058 @@ Validate the variables were populated correctly: - grep -E "url:|region:|tolerations:" /tmp/kube-prometheus-values.yaml + grep -E "url:|region:" /tmp/kube-prometheus-values.yaml @@ -1044 +1060 @@ Validate the variables were populated correctly: -You should see the full AMP endpoint URL (starting with `https://aps-workspaces…`), your region, and the node-exporter `tolerations:` line. If anything is empty, re-export the variables and recreate the file. +You should see the full AMP endpoint URL (starting with `https://aps-workspaces…`) and your region. If either is empty, re-export the variables and recreate the file. @@ -1399 +1415 @@ If you plan to continue with the next sections of this guide, skip the full clea -If you created an ODCR, cancel it first: +If you created an ODCR, cancel it first. Look up the reservation ID: @@ -1407,0 +1424,5 @@ If you created an ODCR, cancel it first: + echo "Capacity reservation ID: ${CAPACITY_RESERVATION_ID}" + +Cancel the reservation: + +