Amazon EKS-Cluster für AI/ML Workloads mithilfe von CLIs einrichten

Dieser Abschnitt führt Sie durch die Schritte zur Erstellung der Infrastruktur, die für die Ausführung von Schulungs- oder Inferenz-Workloads auf Amazon EKS mithilfe von CLI-Befehlen erforderlich ist. Zu den Schritten gehören das Erstellen eines EKS-Clusters, GPU-enabled Knoten mit EKS Auto Mode oder Karpenter, ein Monitoring-Stack mit Prometheus und Grafana sowie Amazon S3-Speicher für Modellgewichte.

Weitere Informationen dazu, wie diese Funktionen EC2-Instances in EKS-Clustern bereitstellen und automatisch skalieren, finden Sie in der Dokumentation für EKS Auto Mode und Karpenter.

High-level Architektur und Arbeitsablauf

Das Diagramm zeigt die AWS allgemeine Architektur für das Setup dieses Abschnitts. Die nummerierten Schritte auf der rechten Seite geben die Reihenfolge an, in der Sie die Konfiguration in den folgenden Schritten abschließen.

Voraussetzungen

Überprüfen Sie Ihre eksctl Version:

eksctl version

Wenn Sie eine Version verwenden, die älter als 0.227.0 ist, folgen Sie der eksctl-Installationsanleitung, um auf die neueste Version zu aktualisieren.

Festlegen von Umgebungsvariablen

Achten Sie bei diesen Schritten darauf, dass der folgende Clustername und die folgende AWS Region konsistent sind. Eine Änderung kann dazu führen, dass nachfolgende Befehle auf den falschen EKS-Cluster abzielen.

export CLUSTER_NAME=ai-eks-docs
export AWS_REGION=us-east-2

Die Verwendung aller verfügbaren AZs verbessert die Fehlertoleranz und erhöht die Wahrscheinlichkeit, GPU-Kapazität zu erhalten:

export AZS=$(aws ec2 describe-availability-zones \
  --region ${AWS_REGION} \
  --query "AvailabilityZones[?ZoneId!='use1-az3' && ZoneId!='usw1-az2' && ZoneId!='cac1-az3'].ZoneName" \
  --output text | tr '\t' ',')
echo $AZS

Erwartete Ausgabe:

us-east-2a,us-east-2b,us-east-2c

Die AZs in der Ausgabe variieren je nach Region. Dieses Beispiel zeigt die verfügbaren AZs für die us-east-2 Region.

Cluster und GPU erstellen NodePool

Dieser Abschnitt enthält zwei Pfade zum Erstellen Ihres EKS-Clusters und Ihrer GPU-enabled EKS-Knoten, wie in der folgenden Abbildung dargestellt. Wählen Sie in der Anleitung nur eine Option aus.

EKS-Cluster-Optionen: EKS Auto Mode und selbstverwaltetes Karpenter

Wählen Sie in jedem der folgenden Schritte einen Pfad (EKS Auto Mode, Karpenter) und folgen Sie ihm durchgehend. Nachdem Sie die Schritte für den von Ihnen gewählten Pfad abgeschlossen haben, haben Sie einen EKS-Cluster mit einer GPU, die NodePool bereit ist, GPU-Workloads zu planen.

Schritt 1: Cluster erstellen

Erstellen Sie zunächst Ihren EKS-Cluster und installieren Sie die Cluster-Komponenten, die für GPU-Workloads benötigt werden.

Im EKS-Automatikmodus wird mit einem einzigen eksctl create cluster --enable-auto-mode Befehl ein EKS-Cluster bereitgestellt, der für GPU-Workloads bereit ist.

Bei selbstverwaltetem Karpenter stellt der eksctl create cluster Befehl die wichtigsten Netzwerk-Add-Ons bereit. Anschließend sind zusätzliche Schritte erforderlich, um die automatische Knotenreparatur über ein Karpenter Feature Gate zu aktivieren, den EKS-Node-Monitoring-Agenten zu installieren und das NVIDIA-Geräte-Plug-In zu installieren.

Richten Sie den Lastenausgleich ein

In späteren Schritten in diesem Handbuch wird Grafana (und in der Inferenz-Komplettlösung ein Modellendpunkt) über einen AWS Application Load Balancer (ALB) verfügbar gemacht. Richten Sie jetzt die Voraussetzungen für den Lastenausgleich ein, damit diese Abschnitte ohne weitere Einrichtung einen erstellen können. Ingress

Das ALB wird anhand von Ressourcen-Tags in Ihren VPC-Subnetzen platziert. AWS Öffentliche Subnetze, die für mit dem Internet verbundene Load Balancer verwendet werden, müssen mit kubernetes.io/role/elb = gekennzeichnet werden1, und private Subnetze, die für interne Load Balancer verwendet werden, müssen mit = gekennzeichnet sein. kubernetes.io/role/internal-elb 1 Da Sie diesen Cluster mit erstellt habeneksctl, sind diese Tags bereits in den erstellten Subnetzen vorhanden. eksctl Wenn Sie Ihre eigene VPC oder importierte Subnetze mitbringen, kennzeichnen Sie sie manuell. Details hierzu finden Sie unter Kennzeichnung von Subnetzen für EKS Auto Mode.

Erstellen Sie den Load Balancer IngressClass

Der Rest des Setups unterscheidet sich je nach Pfad. Der EKS-Automatikmodus enthält einen integrierten ALB-Controller, sodass Sie einen IngressClass selbst erstellen können. Self-managed Karpenter erfordert die Installation des Load AWS Balancer Controllers mit Helm, und das Helm-Diagramm erstellt den für Sie. IngressClass

Beide Pfade haben jetzt eine albIngressClass. Die Abschnitte Grafana und Inferenz verweisen auf das ALB-Schema, die Quell-IP-Zulassungsliste ingressClassName: alb und anderes Verhalten und legen diese durch Per-Annotationen fest. Ingress

Schritt 2: Dynamische GPU erstellen NodePool

Definieren Sie eine NodePool , die G-family GPU-Instances mit einer Generation von mehr als 4 und weniger als 7 dynamisch bereitstellt und Spot-Kapazität On-Demand als Fallback verwendet. Die Pfade EKS Auto Mode und Karpenter verwenden beide dieselbe NodePool API, mit dem einzigen Unterschied, dass NodeClass sie darauf verweist. Im EKS-Auto-Modus wählt das Paket default NodeClass bereits das richtige AMI aus und konfiguriert den SOCI-Parallel-Pull, sodass das das einzige Objekt NodePool ist, das Sie erstellen. Im selbstverwalteten Karpenter benötigen Sie außerdem ein benutzerdefiniertes System, EC2NodeClass das das AMI anheftet und SOCI optimiert.

Bestätigen Sie, NodePool dass das erstellt wurde:

kubectl get nodepool gpu-inf

Erwartete Ausgabe:

NAME      NODECLASS   NODES   READY   AGE
gpu-inf   default     0       True    8s

Auf dem selbstverwalteten Karpenter-Pfad wird in der Spalte NODECLASS anstelle von angezeigt. gpu-inf default

Schritt 3: Testen Sie mit einem Beispiel-Pod

Testen Sie Ihr NodePool GPU-Setup mit einem nvidia-smi Pod.

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: nvidia-smi
  labels:
    guide: ai-eks-docs
spec:
  tolerations:
    - key: "nvidia.com/gpu"
      operator: "Exists"
      effect: "NoSchedule"
  containers:
    - name: nvidia-smi
      image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
      command: ["nvidia-smi"]
      resources:
        limits:
          nvidia.com/gpu: 1
  restartPolicy: OnFailure
EOF

Vergewissern Sie sich, dass der Pod geplant ist und erfolgreich abgeschlossen wurde.

kubectl get pods

Erwartete Ausgabe:

NAME         READY   STATUS      RESTARTS   AGE
nvidia-smi   0/1     Completed   0          67s

Der STATUS: Abgeschlossen bedeutet, dass der Befehl nvidia-smi ausgeführt und beendet wurde. Sehen Sie in den Pod-Protokollen nach, welche GPU vom Knoten erkannt wurde.

kubectl logs nvidia-smi

Erwartete Ausgabe:

+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.159.03             Driver Version: 580.159.03     CUDA Version: 13.0     |
+-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA L4                      On  |   00000000:35:00.0 Off |                    0 |
| N/A   42C    P8             16W /   72W |       0MiB /  23034MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

Die Ausgabe zeigt das GPU-Modell, die Treiberversion, die CUDA-Version und den verfügbaren Speicher. In diesem Beispiel hat Karpenter eine G6-Instanz bereitgestellt, die über eine NVIDIA L4-GPU mit 24 GB Arbeitsspeicher verfügt. 42C ist die aktuelle GPU-Temperatur und P8 ist ein Leerlaufzustand mit geringem Stromverbrauch, was zu erwarten ist, da kein Workload die GPU nutzt. 16 W/72 W zeigen den aktuellen Stromverbrauch im Vergleich zur maximalen Leistungskapazität an, und 0 MiB/23034 MiB zeigt den aktuell genutzten GPU-Speicher im Vergleich zum verfügbaren Gesamtspeicher an. Da auf dem Pod gerade nvidia-smi ausgeführt und beendet wurde, wird die GPU von keiner Workload beansprucht, sodass der Arbeitsspeicher auf 0 steht und die Stromversorgung im Leerlauf ist. Die NVIDIA-GPU-Treiberversion (580.159.03) stammt aus dem Bottlerocket-AMI, während die CUDA-Version (13.0) aus dem Container-Image stammt. Das GPU-Modell und der Arbeitsspeicher variieren je nach dem Instanztyp, den Karpenter auswählt. G5-Instances haben NVIDIA A10G-GPUs (24 GB), G6-Instances haben NVIDIA L4-GPUs (24 GB) und G6e-Instances haben NVIDIA L40S-GPUs (48 GB).

Um zu verstehen, wie Karpenter und der Kubernetes-Scheduler die Bereitstellung eines Knotens und die Platzierung des Pods koordiniert haben, schauen Sie sich die Lebenszyklus-Ereignisse des Pods an:

kubectl describe po nvidia-smi

Erwartete Ausgabe:

Events:
  Type     Reason                  Age   From                   Message
  ----     ------                  ----  ----                   -------
  Warning  FailedScheduling        60s   default-scheduler      0/2 nodes are available: 2 node(s) had untolerated taint(s). no new claims to deallocate, preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.
  Normal   Nominated               59s   eks-auto-mode/compute  Pod should schedule on: nodeclaim/gpu-inf-vxcnj
  Normal   Scheduled               24s   default-scheduler      Successfully assigned default/nvidia-smi to i-0fb17a09bc4203164
  Warning  FailedCreatePodSandBox  21s   kubelet                Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "7f85e25b220c8fb245187758dbbbc8efb3d40f3e49e13054404880daf4c3b2f0": plugin type="aws-cni" name="aws-cni" failed (add): add cmd: failed to setup network policy
  Normal   Pulling                  7s   kubelet                spec.containers{nvidia-smi}: Pulling image "public.ecr.aws/amazonlinux/amazonlinux:2023-minimal"
  Normal   Pulled                   5s   kubelet                spec.containers{nvidia-smi}: Successfully pulled image "public.ecr.aws/amazonlinux/amazonlinux:2023-minimal" in 1.237s (1.237s including waiting). Image size: 37442701 bytes.
  Normal   Created                  5s   kubelet                spec.containers{nvidia-smi}: Container created
  Normal   Started                  5s   kubelet                spec.containers{nvidia-smi}: Container started

Diese Ereignisse zeigen die Reihenfolge der Pod-Planung: Der Pod kann zunächst nicht geplant werden, weil keine GPU-Knoten vorhanden sind (FailedScheduling), Karpenter nominiert einen neuen NodeClaim (Nominated), der Scheduler weist den Pod zu, sobald der Knoten bereit ist (Scheduled), und dann wird das Container-Image abgerufen und gestartet. Im EKS-Automatikmodus ist SOCI (Seekable OCI) Parallel Pull auf G-, P- und Trn-Instances sofort installiert und konfiguriert. Beachten Sie, dass das Container-Image aufgrund des SOCI-Parallel-Pulls in weniger als 2 Sekunden (1,237 s) aus dem ECR abgerufen wurde.

A NodeClaim ist eine Anfrage, die Karpenter erstellt, um einen bestimmten Knoten bereitzustellen. Es zeigt den Instanztyp, den Kapazitätstyp, AZ und ob der Knoten bereit ist.

kubectl get nodeclaims

Erwartete NodeClaim Ausgabe:

NAME            TYPE         CAPACITY   ZONE         NODE                  READY   AGE
gpu-inf-vxcnj   g6.4xlarge   spot       us-east-2c   i-0fb17a09bc4203164   True    51s

Der Instanztyp und AZ werden variieren. Jede G-family Instance mit einer Generation von mehr als 4 und weniger als 7 ist berechtigt.

Die FailedCreatePodSandBox Warnung in kubectl describe pod nvidia-smi ist vorübergehend und wird erwartet. Das VPC-CNI wird asynchron initialisiert, nachdem der Knoten beigetreten ist, und das Kubelet versucht es automatisch erneut. Wenn der Pod aktiv bleibt, überprüfen Sie die Knotenereignisse mit. ContainerCreating kubectl describe node <node-name>

kubectl get events | grep InsufficientCapacityError

Schritt 4: Fügen Sie reservierte Kapazität zur hinzu NodePool (optional)

Um die reservierte Kapazität zuerst mit Spot/On-Demand Fallback zu verwenden, erstellen Sie eine On-Demand Kapazitätsreservierung (ODCR) und fügen Sie sie Ihrer hinzu. Aktualisieren Sie dann die Dynamik NodePool aus Schritt 2 NodeClass, sodass auch Kapazität zugelassen reserved wird. Der Reservierungs-API-Aufruf ist für beide Pfade identisch. Der NodeClass Anhang unterscheidet sich, da EKS Auto Mode und selbstverwaltetes Karpenter unterschiedliche Typen verwenden. NodeClass

Erstellen Sie die Kapazitätsreservierung:

CR_AZ="us-east-2a"
INSTANCE_TYPE="g6e.4xlarge"

aws ec2 create-capacity-reservation \
  --instance-type $INSTANCE_TYPE \
  --instance-platform Linux/UNIX \
  --availability-zone "$CR_AZ" \
  --instance-count 1 \
  --instance-match-criteria open \
  --end-date-type unlimited

Wenn Sie eine InsufficientInstanceCapacity Fehlermeldung erhalten, wechseln Sie CR_AZ zu einer anderen AZ und versuchen Sie es erneut.

Suchen Sie die Kapazitätsreservierungs-ID und speichern Sie sie in einer Shell-Variablen für die folgenden Schritte:

CAPACITY_RESERVATION_ID=$(aws ec2 describe-capacity-reservations \
  --filters "Name=state,Values=active" "Name=instance-type,Values=${INSTANCE_TYPE}" \
  --query 'CapacityReservations[0].CapacityReservationId' \
  --output text \
  --region ${AWS_REGION})
echo "Capacity reservation ID: ${CAPACITY_RESERVATION_ID}"

Wenden Sie dann die NodePool Änderungen NodeClass und für Ihren Pfad an:

Karpenter betrachtet es reserved als die kostengünstigste Option und bringt sie zuerst auf den Markt. Sobald die Reservierung vollständig ist, fällt sie auf Spot oder zurück. On-Demand

cat << 'EOF' | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gpu-overflow-test
  labels:
    guide: ai-eks-docs
spec:
  replicas: 2
  selector:
    matchLabels:
      app: gpu-overflow-test
  template:
    metadata:
      labels:
        app: gpu-overflow-test
        guide: ai-eks-docs
    spec:
      tolerations:
        - key: nvidia.com/gpu
          operator: Exists
          effect: NoSchedule
      containers:
        - name: nvidia-smi
          image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
          command: ["sh", "-c", "nvidia-smi && sleep infinity"]
          resources:
            limits:
              nvidia.com/gpu: 1
EOF

kubectl get pods -l app=gpu-overflow-test -o wide

NAME                                 READY   STATUS    RESTARTS   AGE     IP                NODE                  NOMINATED NODE   READINESS GATES
gpu-overflow-test-59b97944fb-lq56c   1/1     Running   0          2m42s   192.168.186.240   i-057692590480155da   <none>           <none>
gpu-overflow-test-59b97944fb-z4zcx   1/1     Running   0          2m42s   192.168.130.64    i-0521ecd1849fa0578   <none>           <none>

kubectl get nodeclaims

NAME            TYPE          CAPACITY    ZONE         NODE                  READY   AGE
gpu-inf-shg5w   g6e.xlarge    reserved    us-east-2a   i-0ea91fdeef65b8cb6   True    2m2s
gpu-inf-ssnqf   g6e.2xlarge   spot        us-east-2b   i-00ccf7ce65cf3f6ca   True    112s

kubectl delete deployment gpu-overflow-test

Überwachen

Installieren Sie einen Monitoring-Stack, der Cluster-, Knoten- und GPU-Metriken in Amazon Managed Service for Prometheus (AMP) erfasst, und visualisieren Sie sie mit Grafana. Das Kube-Prometheus-Stack-Helm-Diagramm setzt Prometheus ein, um Metriken zu scrapen und per Fernzugriff auf AMP zu schreiben, sowie ein selbstverwaltetes Grafana für Dashboards. Der NVIDIA DCGM Exporter fügt Metriken hinzu (Auslastung, Speicher, Temperatur, Leistung, NVLink, Tensoraktivität). GPU-specific

Prometheus, Grafana und der Operator landen standardmäßig auf Nicht-GPU-Knoten, da GPU-Knoten den Fehler enthalten. nvidia.com/gpu:NoSchedule Node-exporter und der DCGM-Exporter laufen beide auf GPU-Knoten, sodass wir Host- und GPU-Metriken flottenweit auslesen können.

Wenn Sie ein neues Terminal geöffnet haben, legen Sie den Clusternamen und die Region fest:

export CLUSTER_NAME=ai-eks-docs
export AWS_REGION=us-east-2

Erstelle den AMP Workspace

Erstelle einen AMP-Workspace zum Speichern von Metriken:

aws amp create-workspace \
  --alias "amp-ws-${CLUSTER_NAME}" \
  --region ${AWS_REGION}

Hol dir die Workspace-ID:

AMP_WORKSPACE_ID=$(aws amp list-workspaces \
  --alias "amp-ws-${CLUSTER_NAME}" \
  --query 'workspaces[0].workspaceId' \
  --output text \
  --region ${AWS_REGION})

echo "AMP Workspace ID: ${AMP_WORKSPACE_ID}"

Ruft den Remote-Write-Endpunkt ab:

AMP_ENDPOINT=$(aws amp describe-workspace \
  --workspace-id ${AMP_WORKSPACE_ID} \
  --query 'workspace.prometheusEndpoint' \
  --output text \
  --region ${AWS_REGION})

echo "AMP Endpoint: ${AMP_ENDPOINT}"

Erstellen Sie eine IAM-Richtlinie und EKS Pod Identity-Zuordnungen

Erstellen Sie eine IAM-Richtlinie, die es Prometheus ermöglicht, Metriken per Fernzugriff zu schreiben und Grafana sie abzufragen:

ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

AMP_POLICY_ARN=$(aws iam create-policy \
  --policy-name "${CLUSTER_NAME}-amp-grafana-policy" \
  --policy-document "{\"Version\": \"2012-10-17\", \"Statement\": [{\"Sid\": \"AllowAMPReadWrite\", \"Effect\": \"Allow\", \"Action\": [\"aps:ListWorkspaces\", \"aps:DescribeWorkspace\", \"aps:GetMetricMetadata\", \"aps:GetSeries\", \"aps:QueryMetrics\", \"aps:RemoteWrite\", \"aps:GetLabels\"], \"Resource\": \"arn:aws:aps:${AWS_REGION}:${ACCOUNT_ID}:workspace/*\"}, {\"Sid\": \"AllowCloudWatchMetrics\", \"Effect\": \"Allow\", \"Action\": [\"cloudwatch:DescribeAlarmsForMetric\", \"cloudwatch:ListMetrics\", \"cloudwatch:GetMetricData\", \"cloudwatch:GetMetricStatistics\"], \"Resource\": \"*\"}]}" \
  --query 'Policy.Arn' \
  --output text)

echo "AMP Policy ARN: ${AMP_POLICY_ARN}"

Erstellen Sie den Monitoring-Namespace und die Dienstkonten für Prometheus und Grafana:

kubectl create namespace monitoring
kubectl create serviceaccount amp-iamproxy-ingest-service-account -n monitoring
kubectl create serviceaccount grafana-sa -n monitoring

Erstellen Sie EKS Pod Identity Associations, um die Dienstkonten mit der IAM-Richtlinie zu verknüpfen:

eksctl create podidentityassociation \
  --cluster ${CLUSTER_NAME} \
  --namespace monitoring \
  --service-account-name amp-iamproxy-ingest-service-account \
  --role-name "${CLUSTER_NAME}-amp-ingest-role" \
  --permission-policy-arns ${AMP_POLICY_ARN} \
  --region ${AWS_REGION}

eksctl create podidentityassociation \
  --cluster ${CLUSTER_NAME} \
  --namespace monitoring \
  --service-account-name grafana-sa \
  --role-name "${CLUSTER_NAME}-grafana-role" \
  --permission-policy-arns ${AMP_POLICY_ARN} \
  --region ${AWS_REGION}

Stellen Sie sicher, dass beide EKS-Pod Identity-Zuordnungen erstellt wurden:

eksctl get podidentityassociation --cluster ${CLUSTER_NAME} --region ${AWS_REGION}

Die erwartete Ausgabe sollte beide amp-iamproxy-ingest-service-account und grafana-sa im monitoring Namespace enthalten.

Installieren Sie kube-prometheus-stack

Füge das Helm-Repo hinzu:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

In dieser Wertedatei fehlt ein NodeSelector für Prometheus, Grafana und den Operator: Der Makel der GPU-Knoten hält sie von GPU-Knoten fern, sodass sie standardmäßig im System oder Allzweckpool landen. nvidia.com/gpu:NoSchedule Node-exporter verwendet eine Platzhaltertoleranz, sodass es auf jedem Knoten — einschließlich GPU-Knoten — ausgeführt wird, um Metriken flottenweit zu erfassen.

In der Wertedatei wird auch eine Grafana-Datei konfiguriert, Ingress sodass das Diagramm eine mit dem Internet verbundene ALB für den Browserzugriff bereitstellt. Dabei wird der ALB verwendet, den Sie unter Load Balancing einrichten erstellt haben. alb IngressClass Richten Sie den Lastenausgleich ein Die alb.ingress.kubernetes.io/inbound-cidrs Anmerkung beschränkt den Load Balancer auf Ihre eigene IP-Adresse. Stellen Sie sie daher vor der Installation ein.

Finden Sie Ihre öffentliche IP-Adresse und speichern Sie sie als /32 CIDR. Die Wertedatei liest dies aus der MY_CIDR Umgebungsvariablen:

export MY_CIDR="$(curl -s https://checkip.amazonaws.com)/32"
echo $MY_CIDR

Das Ergebnis sieht so aus203.0.113.4/32. Wenn Ihr Netzwerk Adressen dynamisch zuweist, kann sich Ihre IP-Adresse im Laufe der Zeit ändern. Erwägen Sie daher, einen breiteren Bereich festzulegen, z. B. 203.0.113.0/24

Erstellen Sie die Wertedatei:

cat << EOF > /tmp/kube-prometheus-values.yaml
alertmanager:
  enabled: false

prometheus-adapter:
  enabled: false

prometheus:
  serviceAccount:
    create: false
    name: amp-iamproxy-ingest-service-account
  prometheusSpec:
    serviceAccountName: amp-iamproxy-ingest-service-account
    enableRemoteWriteReceiver: true
    retention: 2h
    scrapeInterval: 30s
    evaluationInterval: 30s
    podMonitorSelectorNilUsesHelmValues: false
    serviceMonitorSelectorNilUsesHelmValues: false
    resources:
      requests:
        cpu: 500m
        memory: 1Gi
      limits:
        memory: 8Gi
    remoteWrite:
      - url: "${AMP_ENDPOINT}api/v1/remote_write"
        sigv4:
          region: "${AWS_REGION}"
        queueConfig:
          maxSamplesPerSend: 1000
          maxShards: 200
          capacity: 2500

prometheusOperator:
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      memory: 256Mi

kube-state-metrics:
  resources:
    requests:
      cpu: 50m
      memory: 128Mi
    limits:
      memory: 512Mi

grafana:
  enabled: true
  ingress:
    enabled: true
    ingressClassName: alb
    labels:
      guide: ai-eks-docs
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/inbound-cidrs: ${MY_CIDR}
      alb.ingress.kubernetes.io/load-balancer-name: grafana-ai-eks-docs
      alb.ingress.kubernetes.io/healthcheck-path: /api/health
  serviceAccount:
    create: false
    name: grafana-sa
  resources:
    requests:
      cpu: 100m
      memory: 256Mi
    limits:
      memory: 1Gi
  grafana.ini:
    auth.sigv4:
      enabled: true
  sidecar:
    datasources:
      defaultDatasourceEnabled: false
  plugins:
    - grafana-amazonprometheus-datasource
  additionalDataSources:
    - name: Amazon-Managed-Prometheus
      type: grafana-amazonprometheus-datasource
      access: proxy
      url: "${AMP_ENDPOINT}"
      isDefault: true
      jsonData:
        sigV4Auth: true
        defaultRegion: "${AWS_REGION}"
        sigV4Region: "${AWS_REGION}"
      editable: true
  dashboardProviders:
    dashboardproviders.yaml:
      apiVersion: 1
      providers:
        - name: default
          orgId: 1
          folder: 'GPU Monitoring'
          type: file
          disableDeletion: false
          editable: true
          options:
            path: /var/lib/grafana/dashboards/default
  dashboards:
    default:
      nvidia-dcgm:
        gnetId: 25261
        revision: 1
        datasource:
          - name: DS_PROMETHEUS
            value: Amazon-Managed-Prometheus
      vllm:
        gnetId: 25263
        revision: 1
        datasource:
          - name: DS_PROMETHEUS
            value: Amazon-Managed-Prometheus
      vllm-load-analysis:
        gnetId: 25494
        revision: 1
        datasource:
          - name: DS_PROMETHEUS
            value: Amazon-Managed-Prometheus

prometheus-node-exporter:
  resources:
    requests:
      cpu: 50m
      memory: 64Mi
    limits:
      memory: 128Mi
  tolerations:
    - operator: Exists
EOF

Überprüfen Sie, ob die Variablen korrekt gefüllt wurden:

grep -E "url:|region:" /tmp/kube-prometheus-values.yaml

Du solltest die vollständige AMP-Endpunkt-URL (beginnend mithttps://aps-workspaces…​) und deine Region sehen. Wenn eine der Variablen leer ist, exportiere die Variablen erneut und erstelle die Datei neu.

Installieren Sie das Diagramm:

helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  -f /tmp/kube-prometheus-values.yaml

Stellen Sie sicher, dass die Pods ausgeführt werden:

kubectl get pods -n monitoring

Erwartete Ausgabe:

NAME                                                       READY   STATUS    RESTARTS   AGE
kube-prometheus-stack-grafana-7c58f54f77-rftrj             3/3     Running   0          4m
kube-prometheus-stack-kube-state-metrics-d68dcbc84-5smxq   1/1     Running   0          4m
kube-prometheus-stack-operator-5895df479f-ttm47            1/1     Running   0          4m
kube-prometheus-stack-prometheus-node-exporter-t9q7s       1/1     Running   0          4m
kube-prometheus-stack-prometheus-node-exporter-x6vfb       1/1     Running   0          4m
prometheus-kube-prometheus-stack-prometheus-0              2/2     Running   0          4m

Der Stack stellt die folgenden Komponenten bereit:

Alertmanager ist in diesem Setup deaktiviert.

Greifen Sie auf Grafana zu

Sie greifen über einen mit dem Internet verbundenen AWS Application Load Balancer (ALB) auf Grafana zu. Sie erstellen es nicht hier. Das Kube-Prometheus-Stack-Diagramm stellt es aus der grafana.ingress Konfiguration in der Wertedatei bereit und verwendet dabei das Formular Setup Load Balancing. alb IngressClass Richten Sie den Lastenausgleich ein Das Grafana-Helm-Diagramm verfügt über eine integrierte Ingress Unterstützung, sodass kein separates Manifest erforderlich ist. Das ALB hat einen Namengrafana-ai-eks-docs, trägt das Label und ist auf die IP-Adresse beschränktguide: ai-eks-docs, die Sie MY_CIDR bei der Installation eingegeben haben.

Drucken Sie die Load Balancer-URL aus. Der Load Balancer wird asynchron erstellt. Warten Sie also ein oder zwei Minuten:

echo "http://$(kubectl get ingress kube-prometheus-stack-grafana -n monitoring -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')"

Öffnen Sie die URL in Ihrem Browser. Loggen Sie sich mit dem Benutzernamen admin und dem Passwort aus dem folgenden Befehl ein:

kubectl --namespace monitoring get secrets kube-prometheus-stack-grafana -o jsonpath="{.data.admin-password}" | base64 -d ; echo

Um zu überprüfen, ob die Metrik-Pipeline durchgängig funktioniert:

Wenn Ergebnisse up angezeigt werden, funktioniert die Pipeline (Cluster → Prometheus → AMP → Grafana).

Stellen Sie den DCGM-Exporter für GPU-Metriken bereit

Der Kube-Prometheus-Stack erfasst CPU- und Speichermetriken auf Knotenebene, aber keine GPU-Metriken. Der NVIDIA DCGM Exporter fügt GPU-Auslastung, Speichernutzung, Temperatur, Stromverbrauch, NVLink-Bandbreite und Tensoraktivität hinzu.

helm repo add gpu-helm-charts https://nvidia.github.io/dcgm-exporter/helm-charts
helm repo update

Stellen Sie den GPU-Knotenauswahlschlüssel für Ihren Pfad ein. EKS Auto Mode und selbstverwaltetes Karpenter verwenden unterschiedliche Labelschlüssel für den GPU-Hersteller.

Erstellen Sie die DCGM-Exportwertedatei:

cat << EOF > /tmp/dcgm-exporter-values.yaml
resources:
  requests:
    memory: "512Mi"
    cpu: "100m"
  limits:
    memory: "1Gi"
    cpu: "500m"

serviceMonitor:
  enabled: true
  additionalLabels:
    release: kube-prometheus-stack

nodeSelector:
  ${GPU_NODE_SELECTOR_KEY}: nvidia

tolerations:
  - key: "nvidia.com/gpu"
    operator: "Exists"
    effect: "NoSchedule"

customMetrics: |
  # Clocks
  DCGM_FI_DEV_SM_CLOCK,  gauge, SM clock frequency (in MHz).
  DCGM_FI_DEV_MEM_CLOCK, gauge, Memory clock frequency (in MHz).
  # Temperature
  DCGM_FI_DEV_MEMORY_TEMP, gauge, Memory temperature (in C).
  DCGM_FI_DEV_GPU_TEMP,    gauge, GPU temperature (in C).
  # Power
  DCGM_FI_DEV_POWER_USAGE,              gauge, Power draw (in W).
  DCGM_FI_DEV_TOTAL_ENERGY_CONSUMPTION, counter, Total energy consumption since boot (in mJ).
  # PCIe
  DCGM_FI_PROF_PCIE_TX_BYTES,  counter, Number of bytes transmitted through PCIe TX (in KB) via NVML.
  DCGM_FI_PROF_PCIE_RX_BYTES,  counter, Number of bytes received through PCIe RX (in KB) via NVML.
  DCGM_FI_DEV_PCIE_REPLAY_COUNTER, counter, Total number of PCIe retries.
  # Utilization (the sample period varies depending on the product)
  DCGM_FI_DEV_GPU_UTIL,      gauge, GPU utilization (in %).
  DCGM_FI_DEV_MEM_COPY_UTIL, gauge, Memory utilization (in %).
  DCGM_FI_DEV_ENC_UTIL,      gauge, Encoder utilization (in %).
  DCGM_FI_DEV_DEC_UTIL,      gauge, Decoder utilization (in %).
  # Errors and violations
  DCGM_FI_DEV_XID_ERRORS,            gauge, Value of the last XID error encountered.
  DCGM_EXP_XID_ERRORS_COUNT,         gauge, Value of count of XID errors encountered.
  DCGM_FI_DEV_POWER_VIOLATION,       counter, Throttling duration due to power constraints (in us).
  DCGM_FI_DEV_THERMAL_VIOLATION,     counter, Throttling duration due to thermal constraints (in us).
  DCGM_FI_DEV_SYNC_BOOST_VIOLATION,  counter, Throttling duration due to sync-boost constraints (in us).
  DCGM_FI_DEV_BOARD_LIMIT_VIOLATION, counter, Throttling duration due to board limit constraints (in us).
  DCGM_FI_DEV_LOW_UTIL_VIOLATION,    counter, Throttling duration due to low utilization (in us).
  DCGM_FI_DEV_RELIABILITY_VIOLATION, counter, Throttling duration due to reliability constraints (in us).
  # Memory usage
  DCGM_FI_DEV_FB_FREE, gauge, Framebuffer memory free (in MiB).
  DCGM_FI_DEV_FB_USED, gauge, Framebuffer memory used (in MiB).
  # Retired pages
  DCGM_FI_DEV_RETIRED_SBE,     counter, Total number of retired pages due to single-bit errors.
  DCGM_FI_DEV_RETIRED_DBE,     counter, Total number of retired pages due to double-bit errors.
  DCGM_FI_DEV_RETIRED_PENDING, counter, Total number of pages pending retirement.
  # NVLink
  DCGM_FI_DEV_NVLINK_BANDWIDTH_TOTAL, counter, Total number of NVLink bandwidth counters for all lanes.
  DCGM_FI_PROF_NVLINK_TX_BYTES,       counter, The rate of data transmitted over NVLink not including protocol headers in bytes per second.
  DCGM_FI_PROF_NVLINK_RX_BYTES,       counter, The rate of data received over NVLink not including protocol headers in bytes per second.
  # DCP metrics
  DCGM_FI_PROF_GR_ENGINE_ACTIVE,   gauge, Ratio of time the graphics engine is active (in %).
  DCGM_FI_PROF_SM_ACTIVE,          gauge, The ratio of cycles an SM has at least 1 warp assigned (in %).
  DCGM_FI_PROF_SM_OCCUPANCY,       gauge, The ratio of number of warps resident on an SM (in %).
  DCGM_FI_PROF_PIPE_TENSOR_ACTIVE, gauge, Ratio of cycles the tensor (HMMA) pipe is active (in %).
  DCGM_FI_PROF_DRAM_ACTIVE,        gauge, Ratio of cycles the device memory interface is active sending or receiving data (in %).
  DCGM_FI_DEV_CLOCK_THROTTLE_REASONS, gauge, Current clock throttle reasons (bitmask of DCGM_CLOCKS_THROTTLE_REASON_*).
  DCGM_FI_DEV_GPU_NVLINK_ERRORS,      gauge, Identifies a GPU NVLink error type returned by DCGM_FI_DEV_GPU_NVLINK_ERRORS.
  ## NVLink
  DCGM_FI_DEV_NVLINK_BANDWIDTH_L0, counter, The number of bytes of active NVLink rx or tx data including both header and payload.
  ## Remapped rows
  DCGM_FI_DEV_UNCORRECTABLE_REMAPPED_ROWS, counter, Number of remapped rows for uncorrectable errors.
  DCGM_FI_DEV_CORRECTABLE_REMAPPED_ROWS, counter, Number of remapped rows for correctable errors.
  DCGM_FI_DEV_ROW_REMAP_FAILURE, gauge, whether remapping of rows has failed.
  ## Profiling metrics
  DCGM_FI_PROF_PIPE_FP64_ACTIVE, gauge, Ratio of cycles the fp64 pipes are active (in %).
  DCGM_FI_PROF_PIPE_FP32_ACTIVE, gauge, Ratio of cycles the fp32 pipes are active (in %).
  DCGM_FI_PROF_PIPE_FP16_ACTIVE, gauge, Ratio of cycles the fp16 pipes are active (in %).
  # ECC
  DCGM_FI_DEV_ECC_SBE_VOL_TOTAL, counter, Total number of single-bit volatile ECC errors.
  DCGM_FI_DEV_ECC_DBE_VOL_TOTAL, counter, Total number of double-bit volatile ECC errors.
EOF

Das customMetrics Feld überschreibt den Standard-Metriksatz des DCGM-Exporters durch einen erweiterten Metriksatz, der NVLink-Bandbreite, Tensoraktivität, PCIe-Durchsatz, ECC-Fehler und thermische Drosselung umfasst. Bei Inferenz-Workloads helfen Ihnen diese dabei, zu verstehen, ob die GPU-Recheneinheiten voll ausgelastet sind, ob die GPU aufgrund niedriger Batchgrößen zwischen Anfragen im Leerlauf ist, ob die Datenübertragung zwischen CPU und GPU ein Engpass ist, ob thermische Drosselung Latenzspitzen verursacht und wie viel GPU-Speicher für größere Batches noch verfügbar ist.

Installieren Sie den DCGM-Exporter:

helm install dcgm-exporter gpu-helm-charts/dcgm-exporter \
  --namespace monitoring \
  -f /tmp/dcgm-exporter-values.yaml

tolerationsDadurch kann der Exporter auf den GPU-tainted Knoten ausgeführt werden, die Sie in Schritt 2 bereitgestellt haben. Das serviceMonitor mit dem release: kube-prometheus-stack Etikett stellt sicher, dass Prometheus es automatisch erkennt und löscht.

Überprüfen Sie den DCGM-Exporter: DaemonSet

kubectl get daemonset dcgm-exporter -n monitoring

Sobald ein GPU-Knoten läuft, sollten Sie einen fertigen Pod sehen. Um DCGM-Metriken zu validieren, navigieren Sie in Grafana zu Drilldown > Metriken und suchen Sie nach. DCGM_

Validieren Sie die DCGM-Metriken in Grafana

Um das Dashboard anzuzeigen, navigieren Sie zu Dashboards > GPU-Überwachung > NVIDIA DCGM Exporter-Dashboard.

Das NVIDIA DCGM Exporter-Dashboard in Grafana

Das Modell wiegt den S3-Eimer

Erstellen Sie einen Amazon S3-Bucket zum Speichern von Modellgewichten und konfigurieren Sie eine EKS Pod Identity Association, damit Workload-Pods darauf lesen und schreiben können.

Wenn Sie ein neues Terminal geöffnet haben, legen Sie den Clusternamen und die Region fest:

export CLUSTER_NAME=ai-eks-docs
export AWS_REGION=us-east-2

Erstellen Sie den S3-Bucket

Erstellen Sie den Bucket mit einem zufälligen Suffix, um Namenskollisionen zu vermeiden:

BUCKET_SUFFIX=$(head -c 4 /dev/urandom | od -An -tx1 | tr -d ' \n')
MODEL_BUCKET="${CLUSTER_NAME}-models-${BUCKET_SUFFIX}"

aws s3 mb s3://${MODEL_BUCKET} --region ${AWS_REGION}

Bei S3-Buckets, die nach Januar 2023 erstellt wurden, sind die serverseitige Verschlüsselung (AES256) und die Sperrung des öffentlichen Zugriffs standardmäßig aktiviert.

Konfigurieren Sie EKS Pod Identity für den S3-Zugriff

Erstellen Sie model-storage-sa ServiceAccount im default Namespace eine IAM-Richtlinie für den Modell-Bucket und eine EKS Pod Identity Association, die sie verknüpft. Diese Workload-Pods serviceAccountName: model-storage-sa werden in der Lage sein, den Bucket zu lesen und in ihn zu schreiben.

kubectl create serviceaccount model-storage-sa

Erstellen Sie die IAM-Richtlinie:

POLICY_ARN=$(aws iam create-policy \
  --policy-name "${CLUSTER_NAME}-model-storage-policy" \
  --policy-document "{\"Version\": \"2012-10-17\", \"Statement\": [{\"Effect\": \"Allow\", \"Action\": [\"s3:GetObject\", \"s3:PutObject\", \"s3:ListBucket\", \"s3:DeleteObject\"], \"Resource\": [\"arn:aws:s3:::${MODEL_BUCKET}\", \"arn:aws:s3:::${MODEL_BUCKET}/*\"]}]}" \
  --query 'Policy.Arn' \
  --output text)

echo "Policy ARN: ${POLICY_ARN}"

Erstellen Sie die EKS Pod Identity Association. eksctlerstellt die IAM-Rolle mit der richtigen Vertrauensrichtlinie und verknüpft sie mit: ServiceAccount

eksctl create podidentityassociation \
  --cluster ${CLUSTER_NAME} \
  --namespace default \
  --service-account-name model-storage-sa \
  --role-name "${CLUSTER_NAME}-model-storage-role" \
  --permission-policy-arns ${POLICY_ARN} \
  --region ${AWS_REGION}

Überprüfen Sie die Zuordnung:

eksctl get podidentityassociation --cluster ${CLUSTER_NAME} --region ${AWS_REGION}

Die Ausgabe sollte die model-storage-sa Assoziation im default Namespace enthalten.

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: s3-test
  labels:
    guide: ai-eks-docs
spec:
  serviceAccountName: model-storage-sa
  containers:
    - name: aws-cli
      image: public.ecr.aws/aws-cli/aws-cli:2.27.0
      command:
        - sh
        - -c
        - |
          echo "=== Caller Identity ==="
          aws sts get-caller-identity
          echo ""
          echo "=== S3 Write Test ==="
          echo "pod identity works" | aws s3 cp - s3://${MODEL_BUCKET}/test.txt
          echo ""
          echo "=== S3 List Test ==="
          aws s3 ls s3://${MODEL_BUCKET}/
          echo ""
          echo "=== S3 Delete Test ==="
          aws s3 rm s3://${MODEL_BUCKET}/test.txt
  restartPolicy: Never
EOF

kubectl wait --for=jsonpath='{.status.phase}'=Succeeded pod/s3-test --timeout=300s
kubectl logs s3-test

=== Caller Identity ===
{
    "UserId": "AROA...:eks-ai-eks-docs-model-s-...",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/ai-eks-docs-model-storage-role/eks-ai-eks-docs-model-s-..."
}

=== S3 Write Test ===
upload: - to s3://ai-eks-docs-models-01234567/test.txt

=== S3 List Test ===
2026-05-04 12:00:00         19 test.txt

=== S3 Delete Test ===
delete: s3://ai-eks-docs-models-01234567/test.txt

kubectl delete pod s3-test

Nächste Schritte

Wenn Ihr Cluster bereit ist, können Sie mit Load & Serve Model fortfahren, um ein umfangreiches Sprachmodell bereitzustellen und mit dem Inferenzendpunkt zu interagieren.

Bereinigen

export CLUSTER_NAME=ai-eks-docs
export AWS_REGION=us-east-2

kubectl delete pod nvidia-smi --ignore-not-found
kubectl delete deployment gpu-overflow-test --ignore-not-found

INSTANCE_TYPE="g6e.4xlarge"
CAPACITY_RESERVATION_ID=$(aws ec2 describe-capacity-reservations \
  --filters "Name=state,Values=active" "Name=instance-type,Values=${INSTANCE_TYPE}" \
  --query 'CapacityReservations[0].CapacityReservationId' \
  --output text \
  --region ${AWS_REGION})
echo "Capacity reservation ID: ${CAPACITY_RESERVATION_ID}"

aws ec2 cancel-capacity-reservation --capacity-reservation-id ${CAPACITY_RESERVATION_ID}

AMP_POLICY_ARN=$(aws iam list-policies \
  --scope Local \
  --query "Policies[?PolicyName=='${CLUSTER_NAME}-amp-grafana-policy'].Arn" \
  --output text)
echo "AMP Policy ARN: ${AMP_POLICY_ARN}"

AMP_WORKSPACE_ID=$(aws amp list-workspaces \
  --alias "amp-ws-${CLUSTER_NAME}" \
  --query 'workspaces[0].workspaceId' \
  --output text \
  --region ${AWS_REGION})
echo "AMP Workspace ID: ${AMP_WORKSPACE_ID}"

helm uninstall dcgm-exporter -n monitoring

helm uninstall kube-prometheus-stack -n monitoring

eksctl delete podidentityassociation \
  --cluster ${CLUSTER_NAME} \
  --namespace monitoring \
  --service-account-name amp-iamproxy-ingest-service-account \
  --region ${AWS_REGION}

eksctl delete podidentityassociation \
  --cluster ${CLUSTER_NAME} \
  --namespace monitoring \
  --service-account-name grafana-sa \
  --region ${AWS_REGION}

aws iam delete-policy --policy-arn ${AMP_POLICY_ARN}

aws amp delete-workspace --workspace-id ${AMP_WORKSPACE_ID} --region ${AWS_REGION}

kubectl delete namespace monitoring

MODEL_BUCKET=$(aws s3api list-buckets \
  --query "Buckets[?starts_with(Name, '${CLUSTER_NAME}-models-')].Name | [0]" \
  --output text)
echo "Model bucket: ${MODEL_BUCKET}"

POLICY_ARN=$(aws iam list-policies \
  --scope Local \
  --query "Policies[?PolicyName=='${CLUSTER_NAME}-model-storage-policy'].Arn" \
  --output text)
echo "Policy ARN: ${POLICY_ARN}"

aws s3 rb s3://${MODEL_BUCKET} --force

eksctl delete podidentityassociation \
  --cluster ${CLUSTER_NAME} \
  --namespace default \
  --service-account-name model-storage-sa \
  --region ${AWS_REGION}

aws iam delete-policy --policy-arn ${POLICY_ARN}

kubectl delete serviceaccount model-storage-sa

kubectl delete nodepool gpu-inf --ignore-not-found
kubectl delete nodeclass gpu-inf --ignore-not-found
kubectl delete ec2nodeclass gpu-inf --ignore-not-found
eksctl delete cluster --name=$CLUSTER_NAME --region=$AWS_REGION