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. # Stellen Sie mit kubectl Modelle aus dem lokalen NVMe-Speicher bereit In diesem Thema erfahren Sie, wie Sie Inferenzendpunkte auf Amazon bereitstellen SageMaker HyperPod, die Modellgewichte aus dem lokalen NVMe-Speicher eines Knotens laden, anstatt sie von Amazon S3 oder Amazon FSx über das Netzwerk abzurufen. Durch das lokale Lesen von Gewichten entfällt der Netzwerk-Hop beim Pod-Start, wodurch die Kaltstartzeit des Inferenz-Pods reduziert wird. Dies ist nützlich für automatische Skalierung von Ereignissen, für Workloads, bei denen die Skalierung von Null aus erfolgt, und für latenzempfindliche Failover. Verwenden Sie oder und überspringen Sie dieses Thema für Workloads, bei denen die Kaltstartlatenz kein Problem darstellt. `modelSourceType: s3` `fsx` Lokales NVMe ist knotenlokal und kurzlebig: Daten auf NVMe gehen verloren, wenn ein Knoten ausgetauscht wird, z. B. bei einer punktuellen Unterbrechung, einem Hardwarefehler oder einer AMI-Aktualisierung. Die Ansätze in diesem Thema behandeln dies unterschiedlich — bei einigen müssen Sie jeden Knoten vorab auffüllen, bei anderen wird automatisch auf Amazon S3 zurückgegriffen, wenn das Modell nicht lokal zwischengespeichert wird. Lokaler NVMe-Instance-Speicher befindet sich in der Regel in den Instance-Familien P, G und Trn. Sehen Sie sich die [Spezifikationen des Amazon EC2 EC2-Instance-Speichers](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html#ac_instance-store) an, um die Verfügbarkeit für Ihren Instance-Typ zu überprüfen. Je nach Ihren Speicheranforderungen können Sie zwischen den folgenden Ansätzen wählen: **Ansätze zur NVMe-Bereitstellung** | \# | Ansatz | Description | | --- | --- | --- | | 1 | Kubernetes-Volume (kein Fallback) | Wird verwendet, wenn auf jedem Knoten Modellgewichte auf NVMe vorhanden sind. Einfachste Einrichtung, bei der keine Amazon S3-, Amazon FSx- oder InitContainer erforderlich sind. PV/PVC | | 2 | Kubernetes-Volume mit Fallback | Verwenden Sie diese Option, wenn das Modell möglicherweise nicht auf jedem Knoten auf NVMe vorhanden ist. Sie stellen ein benutzerdefiniertes System bereitinitContainer, das zuerst NVMe überprüft und mit IRSA-Anmeldeinformationen von Amazon S3 herunterlädt, falls das Modell fehlt. | | 3 | Amazon S3 mit Prefetch und Fallback | Verwenden Sie diese Option, wenn Sie Modellgewichte für den Pod-Start im RAM speichern möchten. Sie stellen eine benutzerdefinierte Option bereitinitContainer, die zuerst NVMe überprüft und dann auf das Kopieren aus dem vom Betreiber bereitgestellten Amazon S3 S3-Mount zurückgreift, wenn das Modell nicht lokal zwischengespeichert ist. | ## Voraussetzungen Bevor Sie beginnen, stellen Sie sicher, dass Sie: + Richten Sie Inferenzfunktionen auf Ihren SageMaker HyperPod Amazon-Clustern ein. Weitere Informationen finden Sie unter [Einrichtung Ihrer HyperPod Cluster für die Modellbereitstellung](sagemaker-hyperpod-model-deployment-setup.md). + [Das [kubectl-Hilfsprogramm](https://kubernetes.io/docs/reference/kubectl/) wurde installiert und jq in Ihrem Terminal konfiguriert.](https://jqlang.org/) + Pre-populated modellieren Sie Gewichte auf dem lokalen NVMe-Speicher Ihrer Zielknoten (Anweisungen finden Sie unter[Laden Sie Modellgewichte vorab auf NVMe](#sagemaker-hyperpod-model-deployment-deploy-nvme-preload)). ## Wählen Sie Ihren Bereitstellungsansatz Verwenden Sie den folgenden Entscheidungsablauf, um zu ermitteln, welcher Ansatz für Ihren Anwendungsfall geeignet ist. ``` ┌────────────────────────────┐ │ Want to use a volume of │ │ your choice, e.g. NVMe? │ └─────┬──────────────┬───────┘ YES │ │ NO ▼ ▼ ┌──────────────────────┐ Use S3/FSx/HF │ Are you sure EVERY │ as-is (no volume │ node has the model │ override needed) │ on NVMe? │ └─────┬──────────┬─────┘ YES │ │ NO ▼ ▼ ┌─────────────────┐ ┌───────────────────────────────┐ │ Approach 1 │ │ Do you need the operator to │ │ │ │ create S3/FSx PVCs as a │ │ Use k8sVolume │ │ fallback when the model is │ │ field in CRD to │ │ missing on a node? │ │ read from NVMe │ └──────┬────────────────┬───────┘ │ directly. │ YES │ │ NO └─────────────────┘ ▼ ▼ ┌──────────────────┐ ┌──────────────────────┐ │ Approach 3 │ │ Approach 2 │ │ │ │ │ │ Use S3 with │ │ Use k8sVolume with a │ │ prefetch enabled.│ │ custom initContainer │ │ Custom │ │ you create that │ │ initContainer │ │ checks NVMe first │ │ checks NVMe │ │ and downloads from │ │ first, falls │ │ S3 via IRSA if the │ │ back to S3, and │ │ model is missing. │ │ copies to RAM. │ └──────────────────────┘ └──────────────────┘ ``` ## Verwenden Sie ein Kubernetes-Volume (kein Fallback) Verwenden Sie diesen Ansatz, wenn Sie auf jedem Knoten Modellgewichte auf NVMe haben und die einfachste Einrichtung wünschen — keine Amazon S3- oder Amazon FSx-Konfiguration PV/PVC, nein und keine InitContainer. Bei der Einstellung überspringt `modelSourceType: kubernetesVolume` der Operator die Erstellung vollständig. PV/PVC Es wird kein CSI-Treiber, kein Amazon S3 S3-Sicherungshalter oder kein Amazon FSx-Mount verwendet. Das vom Kunden bereitgestellte `model-weights` Volume wird direkt in der Pod-Spezifikation verwendet, und der Worker liest Modelldaten von NVMe unter. `/opt/ml/model` **Wichtig** Bei der Verwendung `modelSourceType: kubernetesVolume` leitet der Operator den erwarteten Volume-Namen aus Ihrer Worker-Konfiguration ab`modelVolumeMount.name`. `kubernetes.volumes`muss ein Volume mit demselben Namen enthalten. Der Operator bestätigt dies und lehnt die Bereitstellung mit der `KubernetesVolumeValidationFailed` Bedingung ab, dass kein passendes Volumen gefunden wird. In den folgenden Beispielen verwenden beide. `model-weights` 1. Erstellen Sie die `InferenceEndpointConfig` YAML-Datei. Ersetzen Sie die Platzhalterwerte durch Ihre tatsächlichen Ressourcen-IDs. ``` cat < deploy_nvme_k8s_volume.yaml apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: InferenceEndpointConfig metadata: name: nvme-k8s-volume namespace: default spec: endpointName: nvme-k8s-volume modelName: Qwen2.5-VL-7B-Instruct invocationEndpoint: v1/chat/completions replicas: 1 modelSourceConfig: modelSourceType: kubernetesVolume kubernetes: volumes: - name: model-weights hostPath: path: /opt/dlami/nvme/ type: Directory loadBalancer: healthCheckPath: /health worker: image: lmcache/vllm-openai:latest args: - /opt/ml/model - --max-model-len - "15000" - --tensor-parallel-size - "1" modelInvocationPort: containerPort: 8000 name: http modelVolumeMount: name: model-weights mountPath: /opt/ml/model resources: limits: nvidia.com/gpu: "1" requests: cpu: "6" memory: 30Gi nvidia.com/gpu: "1" environmentVariables: - name: PYTHONHASHSEED value: "123" - name: VLLM_REQUEST_TIMEOUT value: "600" EOF ``` 1. Stellen Sie die bereit. `InferenceEndpointConfig` ``` kubectl apply -f deploy_nvme_k8s_volume.yaml ``` 1. Überprüfen Sie den Bereitstellungsstatus. ``` kubectl describe InferenceEndpointConfig nvme-k8s-volume -n default ``` ## Verwenden Sie ein Kubernetes-Volume mit Fallback Verwenden Sie diesen Ansatz, wenn sich das Modell auf einem bestimmten Knoten möglicherweise auf NVMe befindet oder nicht. Ein `hostPath` Volume funktioniert nur auf Knoten, auf denen die Daten vorhanden sind. Pods, die auf anderen Knoten geplant sind, würden einen leeren oder nicht vorhandenen Pfad bereitstellen, was zum Ausfall des Modellservers führen würde. Bei diesem Ansatz legen Sie einen benutzerdefinierten Wert fest `modelSourceType: kubernetesVolume` und stellen ihn bereit`initContainer`, der zuerst NVMe überprüft und dann mithilfe von IRSA-Anmeldeinformationen von Amazon S3 herunterlädt, falls das Modell fehlt. ### Richten Sie IRSA ein Konfigurieren Sie vor der Bereitstellung IAM Roles for Service Accounts (IRSA) so, dass Ihre Pods Anmeldeinformationen für das Herunterladen von Amazon S3 erhalten. 1. Rufen Sie die OIDC-Provider-ID für Ihren Cluster ab. ``` aws eks describe-cluster --name --region \ --query "cluster.identity.oidc.issuer" --output text ``` 1. Erstellen Sie eine IAM-Vertrauensrichtlinie. Speichern Sie Folgendes unter und ersetzen Sie `trust-policy.json` dabei die Platzhalterwerte. ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam:::oidc-provider/oidc.eks..amazonaws.com/id/" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "oidc.eks..amazonaws.com/id/:sub": "system:serviceaccount::", "oidc.eks..amazonaws.com/id/:aud": "sts.amazonaws.com" } } }] } ``` **Warnung** Richten Sie die Vertrauensrichtlinie immer auf einen bestimmten Namespace und ServiceAccount Namen ein. Verwenden Sie niemals Platzhalter in der Betreffbedingung (z. B.`system:serviceaccount:*:*`), da dadurch jeder ServiceAccount in einem beliebigen Namespace die Rolle übernehmen könnte. 1. Erstellen Sie die IAM-Rolle und fügen Sie eine bereichsbezogene Amazon S3-Leserichtlinie für Ihren Modell-Bucket an. ``` aws iam create-role --role-name \ --assume-role-policy-document file://trust-policy.json aws iam put-role-policy --role-name \ --policy-name S3ModelReadAccess \ --policy-document '{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::", "arn:aws:s3::://*" ] }] }' ``` 1. Erstellen Sie das Kubernetes-Dienstkonto mit der IRSA-Anmerkung. ``` kubectl create sa -n kubectl annotate sa -n \ eks.amazonaws.com/role-arn=arn:aws:iam:::role/ ``` ### Bereitstellen des Modells 1. Erstellen Sie die YAML-Datei`InferenceEndpointConfig`. Ersetzen Sie die Platzhalterwerte durch Ihre tatsächlichen Ressourcen-IDs. ``` cat < deploy_nvme_k8s_volume_fallback.yaml apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: InferenceEndpointConfig metadata: name: nvme-k8s-volume-fallback namespace: default spec: endpointName: nvme-k8s-volume-fallback modelName: Qwen2.5-VL-7B-Instruct invocationEndpoint: v1/chat/completions replicas: 1 modelSourceConfig: modelSourceType: kubernetesVolume kubernetes: serviceAccountName: initContainers: - name: smart-loader image: public.ecr.aws/aws-cli/aws-cli:latest command: ["/bin/bash", "-c"] args: - | if [ "$(ls -A /model)" ]; then echo "NVMe hit — model already present ($(du -sh /model | cut -f1))" else echo "NVMe miss — downloading from S3" aws s3 sync s3://// /model/ fi volumeMounts: - name: model-weights mountPath: /model volumes: - name: model-weights hostPath: path: /opt/dlami/nvme/ type: DirectoryOrCreate loadBalancer: healthCheckPath: /health worker: image: lmcache/vllm-openai:latest args: - /opt/ml/model - --max-model-len - "15000" - --tensor-parallel-size - "1" modelInvocationPort: containerPort: 8000 name: http modelVolumeMount: name: model-weights mountPath: /opt/ml/model resources: limits: nvidia.com/gpu: "1" requests: cpu: "6" memory: 30Gi nvidia.com/gpu: "1" environmentVariables: - name: PYTHONHASHSEED value: "123" EOF ``` 1. Stellen Sie die bereit. `InferenceEndpointConfig` ``` kubectl apply -f deploy_nvme_k8s_volume_fallback.yaml ``` 1. Überprüfen Sie den Bereitstellungsstatus. ``` kubectl describe InferenceEndpointConfig nvme-k8s-volume-fallback -n default ``` ## Bereitstellung mithilfe von Amazon S3 mit Prefetch und NVMe-Fallback Verwenden Sie diesen Ansatz, wenn Sie die Leistung ableiten möchten, indem Sie Modellgewichte im RAM bereitstellen und automatisch auf Amazon S3 zurückgreifen, wenn das Modell nicht lokal auf NVMe zwischengespeichert wird. Wenn Sie die Einstellung auf einstellen`prefetchEnabled: true`, `modelSourceType: s3` erstellt der Operator automatisch zwei Volumes: + Ein Volumen, das nach Ihrem `modelVolumeMount.name` (normalerweise`model-weights`) benannt ist — einer Amazon S3 S3-CSI-Sicherungshalterung, die Ihr Modell enthält + `model-weights-copy`— ein RAM-backed `emptyDir` Ort, aus dem der Mitarbeiter liest Sie fügen ein benutzerdefiniertes `nvme-cache` Volume hinzu, das auf den lokalen NVMe-Speicher des Knotens verweist, und ein benutzerdefiniertes, `initContainer` das: + Wenn das Modell auf NVMe existiert, kopiert es von NVMe in den RAM (`model-weights-copy`), wobei das Netzwerk vollständig übersprungen wird. + Wenn das Modell fehlt, wird auf das Kopieren vom Amazon S3 S3-Mount (`model-weights`) in den RAM (`model-weights-copy`) zurückgegriffen. Kopiert optional nach NVMe, sodass nachfolgende Pod-Starts auf demselben Knoten den schnellen lokalen Pfad verwenden. **Wichtig** `kubernetes.volumes`Wenn Sie diesen Ansatz verwenden, `model-weights` sollten Sie den Wert nicht überschreiben. Der Operator erstellt einen `model-weights` Verweis auf das Amazon S3 CSI-Volume. Wenn Sie es überschreiben, wird das vom Operator bereitgestellte Volume entfernt, das Ihr InitContainer als Fallback benötigt. Verwenden Sie einen separaten Volume-Namen (z. B.) für Ihren NVMe HostPath. `nvme-cache` **Wichtig** Nicht einbeziehen `model-weights-copy` in. `kubernetes.volumes` Es ist ein reservierter Name, der automatisch vom Betreiber erstellt wird. Ihr InitContainer kann darauf verweisen, darf ihn `volumeMounts` aber nicht als Volume deklarieren. 1. Erstellen Sie die `InferenceEndpointConfig` YAML-Datei. Ersetzen Sie die Platzhalterwerte durch Ihre tatsächlichen Ressourcen-IDs. ``` cat < deploy_nvme_s3_prefetch_fallback.yaml apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: InferenceEndpointConfig metadata: name: nvme-s3-prefetch-fallback namespace: default spec: endpointName: nvme-s3-prefetch-fallback modelName: Qwen2.5-VL-7B-Instruct invocationEndpoint: v1/chat/completions replicas: 1 modelSourceConfig: modelSourceType: s3 s3Storage: bucketName: region: prefetchEnabled: true kubernetes: serviceAccountName: initContainers: - name: smart-loader image: public.ecr.aws/aws-cli/aws-cli:latest command: ["/bin/bash", "-c"] args: - | # Check NVMe first, fall back to S3 mount, then copy to RAM if [ "$(ls -A /nvme)" ]; then echo "NVMe hit ($(du -sh /nvme | cut -f1))" echo "Copying model from NVMe to RAM..." cp -r /nvme/* /model/ else echo "NVMe miss — copying from S3 mount to NVMe, then NVMe to RAM" cp -r /s3-model/* /nvme/ cp -r /nvme/* /model/ fi echo "Done. $(du -sh /model | cut -f1) in RAM." volumeMounts: - name: model-weights mountPath: /s3-model - name: nvme-cache mountPath: /nvme - name: model-weights-copy mountPath: /model volumes: - name: nvme-cache hostPath: path: /opt/dlami/nvme/ type: DirectoryOrCreate loadBalancer: healthCheckPath: /health worker: image: lmcache/vllm-openai:latest args: - /opt/ml/model - --max-model-len - "15000" - --tensor-parallel-size - "1" modelInvocationPort: containerPort: 8000 name: http modelVolumeMount: name: model-weights mountPath: /opt/ml/model resources: limits: nvidia.com/gpu: "1" requests: cpu: "6" memory: 30Gi nvidia.com/gpu: "1" environmentVariables: - name: PYTHONHASHSEED value: "123" - name: VLLM_REQUEST_TIMEOUT value: "600" EOF ``` 1. Stellen Sie die bereit. `InferenceEndpointConfig` ``` kubectl apply -f deploy_nvme_s3_prefetch_fallback.yaml ``` 1. Überprüfen Sie den Bereitstellungsstatus. ``` kubectl describe InferenceEndpointConfig nvme-s3-prefetch-fallback -n default ``` ## Grundlegendes zu Modellgewichten und Modellgewichten mit Prefetch Bei der Verwendung von Prefetch erstellt der Operator zwei modellbezogene Volumes: + Ein Volumen, das nach Ihrem `modelVolumeMount.name` (normalerweise`model-weights`) benannt ist — einer Amazon S3 S3-CSI-Sicherungshalterung, die Ihr Modell enthält + `model-weights-copy`— ein RAM-backed EmptyDir, aus dem der Worker tatsächlich liest In deinem `InferenceEndpointConfig` definierst du: ``` modelVolumeMount: name: model-weights mountPath: /opt/ml/model ``` Während Sie angeben`model-weights`, wann`prefetchEnabled: true`, ist es tatsächlich `model-weights-copy` das, was `/opt/ml/model` im Worker-Container montiert wird. Wenn Sie einen benutzerdefinierten InitContainer verwenden, stellen Sie sicher, dass Sie die Daten in das aufgerufene Volume kopieren `model-weights-copy` — dort erwartet der Worker, sie zu finden. Wenn `prefetchEnabled: false` es nur ein Volume gibt (das nach Ihrem benannt ist`modelVolumeMount.name`) und es ist direkt darauf gemountet. `/opt/ml/model` ## Konfigurieren Sie ein benutzerdefiniertes Dienstkonto Sie können Ihren Inferenzendpunkt-Pods mithilfe des `spec.kubernetes.serviceAccountName` Felds im ein benutzerdefiniertes Kubernetes ServiceAccount zuweisen. `InferenceEndpointConfig` Dies ist nützlich, um AWS Anmeldeinformationen über IRSA (IAM Roles for Service Accounts) für Ihre Worker- oder Init-Container bereitzustellen — zum Beispiel, um Modellgewichte von Amazon S3 in einem Fallback-Szenario herunterzuladen. **Wichtig** Die Unterstützung für benutzerdefinierte Dienstkonten ist standardmäßig deaktiviert und muss vor der Verwendung ausdrücklich von einem Clusteradministrator aktiviert werden. Detaillierte Anweisungen finden Sie unter [Aktivieren Sie benutzerdefinierte Dienstkonten](#sagemaker-hyperpod-model-deployment-deploy-nvme-sa-enable). Wenn Sie keine angeben ServiceAccount, wird die Standardeinstellung des ServiceAccount Namespaces verwendet. ### Aktivieren Sie benutzerdefinierte Dienstkonten Die Unterstützung für benutzerdefinierte Dienstkonten ist standardmäßig deaktiviert. Ein Clusteradministrator muss es in der Helm-Konfiguration des Operators aktivieren, bevor Benutzer ServiceAccounts in ihrer Konfiguration auf benutzerdefinierte Einstellungen verweisen können`InferenceEndpointConfig`. + Aktualisieren Sie die Helm-Werte des Operators, um die Funktion zu aktivieren. Wenn Sie den Operator über Helm bereitgestellt haben, führen Sie das Upgrade mit dem folgenden Flag durch: ``` helm upgrade hyperpod-inference-operator \ --set enableCustomServiceAccounts=true \ --reuse-values ``` + Wenn Sie den Operator als Amazon EKS-Add-on bereitgestellt haben, aktualisieren Sie die Add-On-Konfiguration, sodass sie `enableCustomServiceAccounts: true` in den erweiterten Konfigurationseinstellungen enthalten ist. + Stellen Sie sicher, dass für den Operator-Pod die Umgebungsvariable gesetzt ist: ``` kubectl get deployment hyperpod-inference-operator-controller-manager \ -n hyperpod-inference-system \ -o jsonpath='{.spec.template.spec.containers[0].env}' | jq '.[] | select(.name=="ENABLE_CUSTOM_SERVICE_ACCOUNTS")' ``` Sie sollten Folgendes sehen: ``` { "name": "ENABLE_CUSTOM_SERVICE_ACCOUNTS", "value": "true" } ``` **Wichtig** Wenn diese Funktion nicht aktiviert ist, wird alles`InferenceEndpointConfig`, was angegeben `kubernetes.serviceAccountName` wird, mit einem `DeploymentFailed` Status und der Meldung abgelehnt:`kubernetes.serviceAccountName is not enabled. Requires addon configuration (enableCustomServiceAccounts: true)`. ### Benennen Sie das Dienstkonto Bevor Sie auf ein benutzerdefiniertes Objekt verweisen können ServiceAccount, muss ein Clusteradministrator es als vom Benutzer zuweisbar kennzeichnen: ``` kubectl label serviceaccount \ sagemaker.amazonaws.com/user-assignable=true \ -n ``` Nur ServiceAccounts mit dieser Bezeichnung können Inferenzendpunkte auf sie verweisen. Dies ist eine Sicherheitskontrolle, um eine unbefugte Rechteerweiterung zu verhindern. ### Geben Sie das Dienstkonto in Ihrer Konfiguration an Fügen Sie das `serviceAccountName` Feld unten `spec.kubernetes` zu Ihrem hinzu`InferenceEndpointConfig`: ``` apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: InferenceEndpointConfig metadata: name: my-inference-endpoint namespace: my-namespace spec: kubernetes: serviceAccountName: my-inference-sa # ... rest of your config ``` ### Validierungsregeln Der Operator validiert das `serviceAccountName` Feld sowohl bei Erstellungs- als auch bei Aktualisierungsvorgängen. Ihre Bereitstellung wird mit einem `DeploymentFailed` Status abgelehnt, wenn eine der folgenden Bedingungen erfüllt ist: + Das ServiceAccount ist im Namespace nicht vorhanden — `serviceAccountName "X" not found in namespace "Y"` + Dem ServiceAccount fehlt das erforderliche Label — `serviceAccountName "X" is not labeled as user-assignable (requires label sagemaker.amazonaws.com/user-assignable=true)` + Das ServiceAccount ist das System des Betreibers ServiceAccount — `serviceAccountName must not reference the operator's service account` **Anmerkung** Alle Container im Inferenz-Pod (Worker-, Init-Container und Sidecars) erben die Berechtigungen der angegebenen. ServiceAccount Wenn der mit annotiert ServiceAccount ist`eks.amazonaws.com/role-arn`, erhält der Pod temporäre AWS Anmeldeinformationen für diese IAM-Rolle. Clusteradministratoren sollten sich erst dann ServiceAccounts als vom Benutzer zuweisbar kennzeichnen, nachdem sie die zugehörigen RBAC-Rollen und IAM-Berechtigungen überprüft haben. **Anmerkung** Wenn a gelöscht ServiceAccount wird, während ein bereits `InferenceEndpointConfig` läuft, werden vorhandene Pods mit ihren aktuellen Anmeldeinformationen weiter ausgeführt, bis sie neu gestartet werden. Die Erstellung neuer Pods (z. B. während der Skalierung oder Neuplanung) schlägt jedoch fehl, da der nicht ServiceAccount mehr vorhanden ist. Der Operator überprüft, ServiceAccount wann die Bereitstellung zum ersten Mal erstellt wird und wann die IEC-Spezifikation aktualisiert wird — er überwacht das nicht kontinuierlich. ServiceAccount Die Aktualisierung der IEC-Spezifikation nach dem Löschen der SA führt zu einem Status. `DeploymentFailed` ### Bewährte Sicherheitsmethoden für benutzerdefinierte Dienstkonten Wenn Sie einen benutzerdefinierten Wert ServiceAccount mit Inferenzendpunkten verwenden, erstellt der HyperPod Inferenzoperator Deployments in Ihrem Namen. Alle Container im Inferenz-Pod — einschließlich Worker, Init-Container und Sidecars — erben die Berechtigungen der angegebenen. ServiceAccount Folgen Sie diesen bewährten Methoden, um Ihren Cluster zu schützen. **Sperren Sie RBAC-Berechtigungen** + Erstellen Sie ServiceAccount für jeden Inferenz-Workload einen eigenen Workload. Nicht für ServiceAccounts Workloads verwenden, die nichts miteinander zu tun haben. + Binden Sie nur die mindestens erforderlichen RBAC-Berechtigungen. Wenn Ihr Init-Container beispielsweise nur aus Amazon S3 lesen muss, ServiceAccount sollte er nicht berechtigt sein, Kubernetes-Ressourcen aufzulisten oder zu ändern. ``` # Example: minimal Role for an inference workload that only needs S3 access via IRSA # No Kubernetes API permissions needed — IRSA provides AWS credentials directly apiVersion: v1 kind: ServiceAccount metadata: name: my-inference-sa namespace: my-namespace labels: sagemaker.amazonaws.com/user-assignable: "true" annotations: eks.amazonaws.com/role-arn: arn:aws:iam:::role/ ``` + Vermeiden Sie es, clusterweite Berechtigungen (ClusterRoleBindings) für die Nutzung durch Inferenz-Pods zu ServiceAccounts gewähren. **Geltungsbereich: IRSA IAM-Rollen** + Achten Sie beim Kommentieren eines ServiceAccount mit darauf`eks.amazonaws.com/role-arn`, dass die IAM-Rolle den Prinzipien der geringsten Rechte folgt. + Beschränken Sie die Amazon S3 S3-Berechtigungen auf den spezifischen Bucket und das Präfix, das Ihre Modellgewichte enthält. ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::", "arn:aws:s3::://*" ] }] } ``` + Verwenden Sie keine breit angelegten verwalteten Richtlinien, wie z. B. `AmazonS3FullAccess` in der Produktion. Verwenden Sie `AmazonS3ReadOnlyAccess` oder eine benutzerdefinierte Richtlinie, die auf Ihren Modellbereich zugeschnitten ist. **Schützen Sie das vom Benutzer zuweisbare Label** + Nur Clusteradministratoren sollten das Label hinzufügen oder entfernen. `sagemaker.amazonaws.com/user-assignable=true` Verwenden Sie Kubernetes RBAC, um einzuschränken, wer ServiceAccount Labels in Ihrem Namespace ändern kann. + Prüfen Sie die mit a verknüpften RBAC-Rollen und IAM-Berechtigungen, bevor Sie sie als vom Benutzer zuweisbar kennzeichnen. ServiceAccount + Prüfen Sie regelmäßig, welche Personen das Label tragen. ServiceAccounts `user-assignable` ``` kubectl get serviceaccounts -n -l sagemaker.amazonaws.com/user-assignable=true ``` + Stellen Sie sicher, dass Rollen, die keine Administratorrechte sind `patch``update`, keine Verben oder `create` Verben auf ServiceAccount Ressourcen enthalten. Der Operator validiert das `user-assignable` Label bei der Bereitstellung, verhindert jedoch nicht, dass unbefugte Benutzer das Label einem hinzufügen. ServiceAccount Die Beschränkung, wer ServiceAccounts über RBAC Änderungen vornehmen kann, ist die wichtigste Kontrolle zum Schutz dieses Labels. Non-admin Benutzer sollten nur Zugriff auf Folgendes haben `get` und darauf zugreifen können: `list` ``` # Example: RBAC Role for non-admin users — read-only access to ServiceAccounts apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: sa-read-only namespace: rules: - apiGroups: [""] resources: ["serviceaccounts"] verbs: ["get", "list"] ``` **Wichtig** Der HyperPod Inferenzoperator fungiert als Vermittler, der Deployments im Namen der Benutzer erstellt. Im Gegensatz zu Standard-Kubernetes-Workloads, bei denen der Aufrufer direkt Pods erstellt, weist der Operator die angegebenen Pods zu, die er erstellt. ServiceAccount Das bedeutet, dass alle Berechtigungen, die einem Benutzer zuweisbar ServiceAccount sind, tatsächlich für jeden verfügbar sind, der in diesem Namespace eine erstellen kann. `InferenceEndpointConfig` Stellen Sie sicher, dass RBAC auf Namespace-Ebene steuert, wer Ressourcen erstellen und aktualisieren kann. `InferenceEndpointConfig` ## Laden Sie Modellgewichte vorab auf NVMe Wenn Sie vor der Bereitstellung NVMe auf bestimmten Knoten vorab auffüllen müssen, können Sie einen einmaligen Pod für die Synchronisierung von Amazon S3 verwenden. **Anmerkung** Dieser Ansatz zielt über auf einen bestimmten Knoten ab `nodeName` und funktioniert nicht mit Autoscaling. Verwenden Sie für Autoscaling-Szenarien das Kubernetes-Volume mit Fallback oder Amazon S3 mit Prefetch-Ansätzen, die fehlende Modelle automatisch über die InitContainer-Fallback-Logik behandeln. 1. Erstellen Sie die Preload-Pod-YAML-Datei. Ersetzen Sie die Platzhalterwerte durch Ihre tatsächlichen Ressourcen-IDs. ``` cat < nvme-s3-copy.yaml apiVersion: v1 kind: Pod metadata: name: nvme-s3-copy namespace: default spec: nodeName: restartPolicy: Never containers: - name: s3-copy image: public.ecr.aws/aws-cli/aws-cli:latest command: ["/bin/bash", "-c"] args: - | echo "=== Starting S3 sync to NVMe ===" aws s3 sync s3://// /nvme// --region echo "=== Sync complete ===" ls -la /nvme// du -sh /nvme// echo "=== Done ===" volumeMounts: - name: nvme-storage mountPath: /nvme serviceAccountName: default volumes: - name: nvme-storage hostPath: path: /opt/dlami/nvme type: Directory EOF ``` 1. Wenden Sie den Pod an und überwachen Sie den Synchronisierungsfortschritt. ``` kubectl apply -f nvme-s3-copy.yaml kubectl get pod nvme-s3-copy -w kubectl logs nvme-s3-copy -f ``` 1. Bereinigen Sie den Pod, nachdem die Synchronisierung abgeschlossen ist. ``` kubectl delete pod nvme-s3-copy ``` ## Reservierte Datenträgernamen Der Betreiber verwaltet mehrere interne Volumes, über die keine Änderungen vorgenommen werden können. `kubernetes.volumes` Die Verwendung eines dieser Namen führt zu einer `KubernetesVolumeValidationFailed` Bedingung. **Reservierte Datenträgernamen** | \# | Name | Zweck | | --- | --- | --- | | 1 | shm | Gemeinsamer Speicher (/dev/shm) für die Kommunikation zwischen Prozessen | | 2 | model-weights-copy | RAM-backed EmptyDir wird verwendet wenn prefetchEnabled: true | | 3 | parallel-copy-configmap | ConfigMap für paralleles Kopierskript (Prefetch) | | 4 | lmcache-config | LMCache-Konfigurationsvolume | | 5 | gated-model-downloader-configmap | ConfigMap Download-Skript für Gated Model | ## Dinge, die Sie sich merken sollten + **Verwenden Sie keine reservierten Datenträgernamen.** Der Operator verwaltet mehrere interne Volumes (siehe[Reservierte Datenträgernamen](#sagemaker-hyperpod-model-deployment-deploy-nvme-reserved-volumes)). Die Verwendung eines dieser Namen `kubernetes.volumes` führt zu einer `KubernetesVolumeValidationFailed` Bedingung. + **Die Namen der Volumes müssen übereinstimmen.** Der Operator leitet den Namen des Volumes von ab`modelVolumeMount.name`. Bei Verwendung `kubernetes.volumes` muss `modelSourceType: kubernetesVolume` es ein Volume mit demselben Namen enthalten. + **Mounten Sie Volumes an der richtigen Stelle in Ihrem InitContainer.** Stellen Sie sicher, dass jedes Volume, das Sie erstellen, im richtigen Pfad in Ihrem InitContainer gemountet ist. + **Für ist kein benutzerdefiniertes Dienstkonto erforderlich. S3/FSx** Wenn Sie keine benutzerdefinierten Dienstkonten erstellen können oder dies nicht möchten, können Sie `modelSourceType: s3` oder verwenden`fsx`. Der Betreiber stellt S3/FSx Volumen automatisch bereit. Sie können weiterhin benutzerdefinierte Volumes `initContainers` und Override-Volumes zusätzlich zum vom Betreiber verwalteten Speicher hinzufügen. + **IRSA-Anmeldeinformationen werden in alle Container eingespeist.** Wenn Sie ein Dienstkonto mit einer IRSA-Anmerkung einrichten`kubernetes.serviceAccountName`, injiziert Amazon EKS AWS Anmeldeinformationen (`aws-iam-token`Volume,,`AWS_WEB_IDENTITY_TOKEN_FILE`) in alle Container`AWS_ROLE_ARN`, einschließlich Ihrer benutzerdefinierten InitContainer. + **Bei Verwendung nicht festlegen. `modelLocation` `kubernetesVolume`** Der Volumenpfad wird von gesteuert`kubernetes.volumes`. Die Angabe des `modelLocation` `modelSourceType` `kubernetesVolume` Zeitpunkts führt zu einem Validierungsfehler. + **Verstehen Sie, wie `model-weights` vs mit Prefetch `model-weights-copy` funktioniert.** Wann `prefetchEnabled: true` erstellt der Operator zwei modellbezogene Volumen: + `model-weights`— das Quellvolume (von Amazon S3/Amazon FSx PVC oder Ihrem Override) + `model-weights-copy`— ein RAM-backed EmptyDir, aus dem der Worker tatsächlich liest + Während Sie `model-weights` in Ihrer Konfiguration angeben, wann`prefetchEnabled: true`, ist es tatsächlich `model-weights-copy` das, was `/opt/ml/model` im Worker-Container eingehängt wird. Wenn Sie einen benutzerdefinierten InitContainer verwenden, stellen Sie sicher, dass Sie die Daten in das aufgerufene Volume kopieren `model-weights-copy` — dort erwartet der Worker, sie zu finden. Wenn `prefetchEnabled: false` es nur ein Volume gibt (das nach Ihrem benannt ist`modelVolumeMount.name`) und es ist direkt darauf gemountet. `/opt/ml/model` ## Fehlerbehebung Verwenden Sie diese Debugging-Befehle, wenn Ihre Bereitstellung nicht wie erwartet funktioniert. + Überprüfen Sie den `InferenceEndpointConfig` Status, um den allgemeinen Bereitstellungsstatus und etwaige Konfigurationsprobleme zu überprüfen. ``` kubectl describe InferenceEndpointConfig -n ``` + Überprüfen Sie den Kubernetes-Bereitstellungsstatus. ``` kubectl describe deployment -n ``` + Überprüfen Sie den Status aller Kubernetes-Objekte in Ihrem Namespace. ``` kubectl get pods,svc,deployment,InferenceEndpointConfig,sagemakerendpointregistration -n ``` + Überprüfen Sie die InitContainer-Protokolle, wenn der Schritt zum Laden des Modells fehlschlägt. ``` kubectl logs -c smart-loader -n ``` + Wenn die Bereitstellung mit der Meldung „Nicht im Namespace gefunden“ fehlschlägt, überprüfen Sie, ob Folgendes vorhanden ist: ServiceAccount ``` kubectl get serviceaccount -n ``` + Wenn die Bereitstellung mit der Angabe „nicht als vom Benutzer zuweisbar gekennzeichnet“ fehlschlägt, bitten Sie Ihren Clusteradministrator, das erforderliche Label hinzuzufügen: ``` kubectl label serviceaccount sagemaker.amazonaws.com/user-assignable=true -n ``` + Wenn die Bereitstellung mit der Angabe „darf nicht auf das Dienstkonto des Betreibers verweisen“ fehlschlägt, erstellen Sie ein separates Konto ServiceAccount für Ihren Workload. Sie können nicht den eigenen HyperPod ServiceAccount Inferenzoperator verwenden.