Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Distribuisci modelli dallo storage NVMe locale usando kubectl Questo argomento mostra come distribuire endpoint di inferenza su Amazon SageMaker HyperPod che caricano i pesi dei modelli dallo storage NVMe locale di un nodo anziché trasferirli sulla rete da Amazon S3 o Amazon FSx. La lettura locale dei pesi elimina l'hop di rete durante l'avvio del pod, il che riduce il tempo di avvio a freddo del pod di inferenza ed è utile per eventi di scalabilità automatica, carichi di lavoro con scalabilità da zero e failover sensibili alla latenza. Per i carichi di lavoro in cui la latenza con avvio a freddo non è un problema, usa o salta questo argomento. `modelSourceType: s3` `fsx` L'NVMe locale è locale del nodo ed è effimero: i dati su NVMe vengono persi quando un nodo viene sostituito, ad esempio durante un'interruzione puntuale, un guasto hardware o un aggiornamento dell'AMI. Gli approcci illustrati in questo argomento gestiscono la situazione in modo diverso: alcuni richiedono la precompilazione di ogni nodo, altri ricorrono automaticamente ad Amazon S3 quando il modello non è memorizzato nella cache locale. Lo storage di istanze NVMe locale si trova in genere nelle famiglie di istanze P, G e Trn. Consulta le [specifiche dell'instance store di Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html#ac_instance-store) per convalidare la disponibilità per il tuo tipo di istanza. Puoi scegliere tra i seguenti approcci in base ai tuoi requisiti di storage: **Approcci di implementazione NVMe** | \# | Approccio | Description | | --- | --- | --- | | 1 | Volume Kubernetes (nessun fallback) | Da utilizzare quando i pesi dei modelli esistono su NVMe su ogni nodo. La configurazione più semplice non richiede Amazon S3, Amazon FSx o PV/PVC InitContainers. | | 2 | Volume Kubernetes con fallback | Da utilizzare quando il modello potrebbe non esistere su NVMe su ogni nodo. Fornisci una soluzione personalizzata initContainer che controlla innanzitutto NVMe e scarica da Amazon S3 utilizzando le credenziali IRSA se il modello è mancante. | | 3 | Amazon S3 con prefetch e fallback | Utilizzalo quando desideri trasferire i pesi dei modelli alla RAM per l'avvio del pod. Fornisci una soluzione personalizzata initContainer che verifica innanzitutto NVMe e ritorna alla copia dal supporto Amazon S3 fornito dall'operatore se il modello non è memorizzato nella cache locale. | ## Prerequisiti Prima di iniziare, verifica di aver: + Configura funzionalità di inferenza sui tuoi SageMaker HyperPod cluster Amazon. Per ulteriori informazioni, consulta [Configurazione dei HyperPod cluster per l'implementazione dei modelli](sagemaker-hyperpod-model-deployment-setup.md). + Installato l’utilità [kubectl](https://kubernetes.io/docs/reference/kubectl/) e configurato [jq](https://jqlang.org/) nel terminale. + Pre-populated pesi dei modelli sullo storage NVMe locale dei nodi di destinazione (vedi per le istruzioni). [Precarica i pesi dei modelli su NVMe](#sagemaker-hyperpod-model-deployment-deploy-nvme-preload) ## Scegli il tuo approccio di implementazione Utilizza il seguente flusso decisionale per determinare quale approccio è giusto per il tuo caso d'uso. ``` ┌────────────────────────────┐ │ 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. │ └──────────────────────┘ └──────────────────┘ ``` ## Esegui la distribuzione utilizzando un volume Kubernetes (senza fallback) Utilizza questo approccio quando disponi di pesi dei modelli su NVMe su ogni nodo e desideri la configurazione più semplice: nessuna configurazione Amazon S3 o Amazon FSx, niente e niente InitContainers. PV/PVC Quando imposti, l'operatore salta completamente la `modelSourceType: kubernetesVolume` creazione. PV/PVC Non viene utilizzato alcun driver CSI, montaggio su fusibili Amazon S3 o montaggio Amazon FSx. Il `model-weights` volume fornito dal cliente viene utilizzato direttamente nelle specifiche del pod e l'operatore legge i dati del modello da NVMe all'indirizzo. `/opt/ml/model` **Importante** Durante l'utilizzo`modelSourceType: kubernetesVolume`, l'operatore ricava il nome del volume previsto dalla configurazione del lavoratore. `modelVolumeMount.name` `kubernetes.volumes`deve contenere un volume con lo stesso nome. L'operatore lo convalida e rifiuta la distribuzione con una `KubernetesVolumeValidationFailed` condizione se non viene trovato alcun volume corrispondente. Negli esempi seguenti, entrambi utilizzano. `model-weights` 1. Create il file `InferenceEndpointConfig` YAML. Sostituisci i valori segnaposto con i tuoi identificatori di risorsa effettivi. ``` 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. Implementa il. `InferenceEndpointConfig` ``` kubectl apply -f deploy_nvme_k8s_volume.yaml ``` 1. Verifica lo stato della distribuzione. ``` kubectl describe InferenceEndpointConfig nvme-k8s-volume -n default ``` ## Esegui la distribuzione utilizzando un volume Kubernetes con fallback Utilizza questo approccio quando il modello potrebbe essere o meno su NVMe su un determinato nodo. Un `hostPath` volume funziona solo sui nodi in cui esistono i dati: i pod programmati su altri nodi monterebbero un percorso vuoto o inesistente, causando il guasto del server modello. In questo approccio, imposti `modelSourceType: kubernetesVolume` e fornisci una soluzione personalizzata `initContainer` che controlla innanzitutto NVMe e scarica da Amazon S3 utilizzando le credenziali IRSA se il modello è mancante. ### Configura IRSA Prima della distribuzione, configura IAM Roles for Service Accounts (IRSA) per fornire le credenziali dei tuoi pod per il download da Amazon S3. 1. Ottieni l'ID del provider OIDC per il tuo cluster. ``` aws eks describe-cluster --name --region \ --query "cluster.identity.oidc.issuer" --output text ``` 1. Crea una policy di fiducia IAM. Salva quanto segue con nome`trust-policy.json`, sostituendo i valori segnaposto. ``` { "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" } } }] } ``` **avvertimento** Ambita sempre la politica di attendibilità in base a un namespace e a un nome specifici. ServiceAccount Non usate mai caratteri jolly nella condizione dell'oggetto (ad esempio,`system:serviceaccount:*:*`), poiché ciò consentirebbe ServiceAccount a qualsiasi utente di qualsiasi namespace di assumere il ruolo. 1. Crea il ruolo IAM e allega una policy di lettura mirata di Amazon S3 per il tuo bucket modello. ``` 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. Crea l'account del servizio Kubernetes con l'annotazione IRSA. ``` kubectl create sa -n kubectl annotate sa -n \ eks.amazonaws.com/role-arn=arn:aws:iam:::role/ ``` ### Implementazione del modello 1. Crea il file YAML. `InferenceEndpointConfig` Sostituisci i valori segnaposto con i tuoi identificatori di risorsa effettivi. ``` 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. Implementa il. `InferenceEndpointConfig` ``` kubectl apply -f deploy_nvme_k8s_volume_fallback.yaml ``` 1. Verifica lo stato della distribuzione. ``` kubectl describe InferenceEndpointConfig nvme-k8s-volume-fallback -n default ``` ## Esegui la distribuzione utilizzando Amazon S3 con prefetch e fallback NVMe Utilizza questo approccio quando desideri prestazioni di inferenza organizzando i pesi del modello sulla RAM, con fallback automatico su Amazon S3 se il modello non è memorizzato nella cache locale su NVMe. Quando imposti con, l'operatore crea automaticamente due `modelSourceType: s3` volumi`prefetchEnabled: true`: + Un volume che prende il nome dal tuo `modelVolumeMount.name` (in genere`model-weights`): un supporto per fusibili CSI Amazon S3 contenente il tuo modello + `model-weights-copy`— a da RAM-backed `emptyDir` dove il lavoratore legge Si aggiunge un `nvme-cache` volume personalizzato che punta allo storage NVMe locale del nodo e un volume personalizzato che: `initContainer` + Se il modello esiste su NVMe, copia da NVMe a RAM ()`model-weights-copy`, ignorando completamente la rete. + Se manca il modello, torna a copiare da Amazon S3 mount `model-weights` () a RAM `model-weights-copy` (). Facoltativamente, copia su NVMe in modo che i successivi avvii del pod sullo stesso nodo utilizzino il percorso locale veloce. **Importante** Non eseguire l'override in quando si utilizza `model-weights` questo approccio`kubernetes.volumes`. L'operatore crea un `model-weights` puntamento al volume CSI di Amazon S3. La sovrascrittura rimuove il volume fornito dall'operatore di cui InitContainer ha bisogno per il fallback. Utilizzate un nome di volume separato (ad esempio,) per NVMe HostPath. `nvme-cache` **Importante** Non includere in. `model-weights-copy` `kubernetes.volumes` È un nome riservato creato automaticamente dall'operatore. Il tuo InitContainer può farvi riferimento `volumeMounts` ma non deve dichiararlo come volume. 1. Crea il file `InferenceEndpointConfig` YAML. Sostituisci i valori segnaposto con i tuoi identificatori di risorsa effettivi. ``` 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. Implementa il. `InferenceEndpointConfig` ``` kubectl apply -f deploy_nvme_s3_prefetch_fallback.yaml ``` 1. Verifica lo stato della distribuzione. ``` kubectl describe InferenceEndpointConfig nvme-s3-prefetch-fallback -n default ``` ## Comprensione dei pesi dei modelli e dei pesi dei modelli con prefetch Quando si utilizza prefetch, l'operatore crea due volumi relativi al modello: + Un volume che prende il nome dal tuo `modelVolumeMount.name` (in genere`model-weights`): un supporto per fusibili CSI Amazon S3 contenente il tuo modello + `model-weights-copy`— un RAM-backed EmptyDir da cui l'operatore legge effettivamente Nel tuo, definisci`InferenceEndpointConfig`: ``` modelVolumeMount: name: model-weights mountPath: /opt/ml/model ``` Mentre fate riferimento`model-weights`, quando`prefetchEnabled: true`, in realtà `model-weights-copy` viene montato `/opt/ml/model` nel container del lavoratore. Quando utilizzi un InitContainer personalizzato, assicurati di copiare i dati nel volume chiamato`model-weights-copy`, che è dove l'operatore si aspetta di trovarli. Quando`prefetchEnabled: false`, c'è solo un volume (che prende il nome dal tuo`modelVolumeMount.name`) ed è montato direttamente su. `/opt/ml/model` ## Configura un account di servizio personalizzato Puoi assegnare un Kubernetes personalizzato ServiceAccount ai tuoi pod degli endpoint di inferenza utilizzando il campo in. `spec.kubernetes.serviceAccountName` `InferenceEndpointConfig` Ciò è utile per fornire AWS credenziali tramite IRSA (IAM Roles for Service Accounts) ai container di lavoro o ai contenitori init, ad esempio per scaricare i pesi dei modelli da Amazon S3 in uno scenario di fallback. **Importante** Il supporto per gli account di servizio personalizzati è disabilitato per impostazione predefinita e deve essere abilitato esplicitamente da un amministratore del cluster prima dell'uso. Per istruzioni, consulta [Abilita gli account di servizio personalizzati](#sagemaker-hyperpod-model-deployment-deploy-nvme-sa-enable). Se non si specifica a ServiceAccount, viene utilizzata l'impostazione predefinita ServiceAccount dello spazio dei nomi. ### Abilita gli account di servizio personalizzati Il supporto per gli account di servizio personalizzati è disabilitato per impostazione predefinita. Un amministratore del cluster deve abilitarlo nella configurazione Helm dell'operatore prima che gli utenti possano fare riferimento ServiceAccounts a custom nel proprio`InferenceEndpointConfig`. + Aggiorna i valori Helm dell'operatore per abilitare la funzionalità. Se hai distribuito l'operatore tramite Helm, esegui l'upgrade con il flag: ``` helm upgrade hyperpod-inference-operator \ --set enableCustomServiceAccounts=true \ --reuse-values ``` + Se hai distribuito l'operatore come componente aggiuntivo Amazon EKS, aggiorna la configurazione del componente aggiuntivo per includerla `enableCustomServiceAccounts: true` nelle impostazioni di configurazione avanzate. + Verifica che nel pod dell'operatore sia impostata la variabile di ambiente: ``` 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")' ``` Dovresti vedere: ``` { "name": "ENABLE_CUSTOM_SERVICE_ACCOUNTS", "value": "true" } ``` **Importante** Se questa funzione non è abilitata, qualsiasi funzione `InferenceEndpointConfig` che lo specifichi `kubernetes.serviceAccountName` viene rifiutata con uno `DeploymentFailed` stato e il messaggio:`kubernetes.serviceAccountName is not enabled. Requires addon configuration (enableCustomServiceAccounts: true)`. ### Etichetta l'account del servizio Prima di poter fare riferimento a una personalizzazione ServiceAccount, un amministratore del cluster deve etichettarla come assegnabile dall'utente: ``` kubectl label serviceaccount \ sagemaker.amazonaws.com/user-assignable=true \ -n ``` Solo ServiceAccounts con questa etichetta possono essere referenziati dagli endpoint di inferenza. Si tratta di un controllo di sicurezza per prevenire l'escalation non autorizzata dei privilegi. ### Specificare l'account di servizio nella configurazione Aggiungi il `serviceAccountName` campo sottostante `spec.kubernetes` nel tuo`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 ``` ### Regole di convalida L'operatore convalida il `serviceAccountName` campo sia nelle operazioni di creazione che di aggiornamento. La distribuzione verrà rifiutata con uno `DeploymentFailed` status se viene soddisfatta una delle seguenti condizioni: + Non ServiceAccount esiste nello spazio dei nomi — `serviceAccountName "X" not found in namespace "Y"` + Manca ServiceAccount l'etichetta richiesta — `serviceAccountName "X" is not labeled as user-assignable (requires label sagemaker.amazonaws.com/user-assignable=true)` + ServiceAccount È il sistema dell'operatore ServiceAccount — `serviceAccountName must not reference the operator's service account` **Nota** Tutti i contenitori nel pod di inferenza (worker, init containers e sidecar) ereditano le autorizzazioni specificate. ServiceAccount Se ServiceAccount è annotato con`eks.amazonaws.com/role-arn`, il pod riceve credenziali temporanee AWS per quel ruolo IAM. Gli amministratori del cluster devono etichettare ServiceAccounts come assegnabile dall'utente solo dopo aver esaminato i ruoli RBAC e le autorizzazioni IAM associati. **Nota** Se a ServiceAccount viene eliminato mentre un `InferenceEndpointConfig` è già in esecuzione, i pod esistenti continuano a funzionare con le credenziali correnti fino al riavvio. Tuttavia, la creazione di nuovi pod (ad esempio, durante il ridimensionamento o la riprogrammazione) avrà esito negativo perché non esiste più. ServiceAccount L'operatore convalida ServiceAccount quando la distribuzione viene creata per la prima volta e quando le specifiche IEC vengono aggiornate, ma non monitora continuamente il. ServiceAccount L'aggiornamento delle specifiche IEC dopo l'eliminazione della SA genererà uno stato. `DeploymentFailed` ### Le migliori pratiche di sicurezza per gli account di servizio personalizzati Quando utilizzi un endpoint personalizzato ServiceAccount con inferenza, l'operatore di HyperPod inferenza crea distribuzioni per tuo conto. Tutti i contenitori nel contenitore di inferenza, inclusi worker, init container e sidecar, ereditano le autorizzazioni specificate. ServiceAccount Segui queste best practice per proteggere il tuo cluster. **Blocca le autorizzazioni RBAC** + Crea un carico di lavoro dedicato ServiceAccount per ogni carico di lavoro di inferenza. Non riutilizzarlo ServiceAccounts su carichi di lavoro non correlati. + Associa solo le autorizzazioni RBAC minime richieste. Ad esempio, se il tuo contenitore init deve solo leggere da Amazon S3, non dovrebbe avere ServiceAccount le autorizzazioni per elencare o modificare le risorse Kubernetes. ``` # 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/ ``` + Evita di concedere autorizzazioni () a livello di cluster utilizzate dai pod di inferenza. ClusterRoleBindings ServiceAccounts **Ambito dei ruoli IRSA IAM** + Quando annoti un ServiceAccount with`eks.amazonaws.com/role-arn`, assicurati che il ruolo IAM segua i principi del privilegio minimo. + Ambita le autorizzazioni di Amazon S3 per il bucket e il prefisso specifici contenenti i pesi del modello. ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::", "arn:aws:s3::://*" ] }] } ``` + Non utilizzare politiche gestite di ampio respiro, ad esempio in produzione. `AmazonS3FullAccess` Usa `AmazonS3ReadOnlyAccess` o una policy personalizzata adatta al tuo modello bucket. **Proteggi l'etichetta assegnabile dall'utente** + Solo gli amministratori del cluster devono aggiungere o rimuovere l'etichetta. `sagemaker.amazonaws.com/user-assignable=true` Usa Kubernetes RBAC per limitare chi può modificare le etichette nel tuo spazio dei nomi. ServiceAccount + Esamina i ruoli RBAC e le autorizzazioni IAM associati a un prima di etichettarlo come assegnabile dall'utente. ServiceAccount + Verifica periodicamente quali etichette riportano l'etichetta. ServiceAccounts `user-assignable` ``` kubectl get serviceaccounts -n -l sagemaker.amazonaws.com/user-assignable=true ``` + Assicurati che i ruoli non amministrativi non includano `patch` parole `update` o `create` verbi sulle ServiceAccount risorse. L'operatore convalida l'`user-assignable`etichetta al momento dell'implementazione, ma non impedisce agli utenti non autorizzati di aggiungere l'etichetta a un. ServiceAccount Limitare chi può modificare ServiceAccounts tramite RBAC è il controllo principale per proteggere questa etichetta. Non-admin gli utenti devono avere e accedere solo a: `get` `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"] ``` **Importante** L'operatore di HyperPod inferenza funge da intermediario che crea distribuzioni per conto degli utenti. A differenza dei carichi di lavoro Kubernetes standard in cui il chiamante crea direttamente i pod, l'operatore assegna lo specificato ai pod che crea. ServiceAccount Ciò significa che qualsiasi autorizzazione concessa a un utente assegnabile è effettivamente disponibile per chiunque possa crearne una in quel ServiceAccount namespace. `InferenceEndpointConfig` Assicurati che l'RBAC a livello di namespace controlli chi può creare e aggiornare le risorse. `InferenceEndpointConfig` ## Precarica i pesi dei modelli su NVMe Se devi prepopolare NVMe su nodi specifici prima della distribuzione, puoi utilizzare un pod unico per la sincronizzazione da Amazon S3. **Nota** Questo approccio si rivolge a un nodo specifico tramite `nodeName` e non funziona con la scalabilità automatica. Per gli scenari di scalabilità automatica, usa il volume Kubernetes con fallback o Amazon S3 con approcci prefetch, che gestiscono automaticamente i modelli mancanti tramite la logica di fallback di InitContainer. 1. Crea il file YAML del pod di precaricamento. Sostituisci i valori segnaposto con i tuoi identificatori di risorsa effettivi. ``` 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. Applica il pod e monitora l'avanzamento della sincronizzazione. ``` kubectl apply -f nvme-s3-copy.yaml kubectl get pod nvme-s3-copy -w kubectl logs nvme-s3-copy -f ``` 1. Pulisci il pod al termine della sincronizzazione. ``` kubectl delete pod nvme-s3-copy ``` ## Nomi dei volumi riservati L'operatore gestisce diversi volumi interni che non possono essere sostituiti tramite. `kubernetes.volumes` L'utilizzo di uno di questi nomi genera una `KubernetesVolumeValidationFailed` condizione. **Nomi di volume riservati** | \# | Nome | Scopo | | --- | --- | --- | | 1 | shm | Memoria condivisa (/dev/shm) per la comunicazione tra processi | | 2 | model-weights-copy | RAM-backed emptyDir usato quando prefetchEnabled: true | | 3 | parallel-copy-configmap | ConfigMap per script di copia parallela (prefetch) | | 4 | lmcache-config | volume di configurazione LMCache | | 5 | gated-model-downloader-configmap | ConfigMap per lo script di download del modello recintato | ## Cose da ricordare + **Non utilizzare nomi di volume riservati.** L'operatore gestisce diversi volumi interni (vedi[Nomi dei volumi riservati](#sagemaker-hyperpod-model-deployment-deploy-nvme-reserved-volumes)). L'utilizzo di uno di questi nomi `kubernetes.volumes` genera una `KubernetesVolumeValidationFailed` condizione. + **I nomi dei volumi devono corrispondere.** L'operatore ricava il nome del volume da`modelVolumeMount.name`. Quando si utilizza`modelSourceType: kubernetesVolume`, `kubernetes.volumes` deve contenere un volume con lo stesso nome. + **Monta i volumi nella posizione corretta nel tuo InitContainer.** Assicurati che qualsiasi volume creato sia montato sul percorso corretto nel tuo InitContainer. + **Non è necessario alcun account di servizio personalizzato per S3/FSx.** Se non riesci a creare account di servizio personalizzati o preferisci non farlo, puoi utilizzare `modelSourceType: s3` o`fsx`. L'operatore effettua il S3/FSx provisioning automatico dei volumi. È comunque possibile aggiungere volumi personalizzati `initContainers` e sovrascrivere allo storage gestito dall'operatore. + **Le credenziali IRSA vengono inserite in tutti i contenitori.** Quando imposti un account `kubernetes.serviceAccountName` di servizio con un'annotazione IRSA, Amazon EKS inserisce AWS le credenziali (`aws-iam-token`volume,,`AWS_WEB_IDENTITY_TOKEN_FILE`) in tutti i contenitori`AWS_ROLE_ARN`, inclusi i tuoi InitContainers personalizzati. + **Non impostare durante l'utilizzo. `modelLocation` `kubernetesVolume`** Il percorso del volume è controllato da`kubernetes.volumes`. L'impostazione di `modelLocation` quando `modelSourceType` è `kubernetesVolume` genera un errore di convalida. + **Scopri come `model-weights-copy` funziona `model-weights` vs con prefetch.** Quando`prefetchEnabled: true`, l'operatore crea due volumi relativi al modello: + `model-weights`— il volume di origine (da Amazon S3/Amazon FSx PVC o il tuo override) + `model-weights-copy`— un RAM-backed EmptyDir da cui l'operatore legge effettivamente + Mentre fai riferimento `model-weights` nella tua configurazione, quando`prefetchEnabled: true`, in realtà viene montato nel `model-weights-copy` container del worker. `/opt/ml/model` Quando usi un InitContainer personalizzato, assicurati di copiare i dati nel volume chiamato`model-weights-copy`, che è dove l'operatore si aspetta di trovarli. Quando`prefetchEnabled: false`, c'è solo un volume (che prende il nome dal tuo`modelVolumeMount.name`) ed è montato direttamente su. `/opt/ml/model` ## Risoluzione dei problemi Utilizza questi comandi di debug se l’implementazione non funziona come previsto. + Controlla lo `InferenceEndpointConfig` stato per vedere lo stato della distribuzione di alto livello e gli eventuali problemi di configurazione. ``` kubectl describe InferenceEndpointConfig -n ``` + Controlla lo stato dell’implementazione di Kubernetes. ``` kubectl describe deployment -n ``` + Controlla lo stato di tutti gli oggetti Kubernetes nel tuo namespace. ``` kubectl get pods,svc,deployment,InferenceEndpointConfig,sagemakerendpointregistration -n ``` + Controlla i log di InitContainer se la fase di caricamento del modello fallisce. ``` kubectl logs -c smart-loader -n ``` + Se la distribuzione fallisce con «not found in namespace», verifica che esista: ServiceAccount ``` kubectl get serviceaccount -n ``` + Se la distribuzione fallisce con «non etichettato come assegnabile dall'utente», chiedi all'amministratore del cluster di aggiungere l'etichetta richiesta: ``` kubectl label serviceaccount sagemaker.amazonaws.com/user-assignable=true -n ``` + Se l'implementazione fallisce con «must not reference the operator service account», creane uno separato ServiceAccount per il tuo carico di lavoro. Non è possibile utilizzare quello dell'operatore di HyperPod inferenza. ServiceAccount