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à.

Personalizza il componente aggiuntivo

Modello

I modelli sono configurazioni riutilizzabili dell'area di lavoro che fungono da blueprint controllati dall'amministratore per la creazione dell'area di lavoro. Forniscono valori predefiniti per i valori di configurazione dell'area di lavoro e guardrail per controllare ciò che i data scientist possono fare. I modelli esistono a livello di cluster e possono essere riutilizzati nei namespace.

SageMaker Spaces crea due modelli di sistema come punto di partenza per i data scientist, uno per Code Editor e uno per. JupyterLab Questi modelli di sistema sono gestiti dall'addon e non possono essere modificati direttamente. Invece, gli amministratori possono creare nuovi modelli e impostarli come predefiniti.

Governance delle attività

apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: my-jupyter-template
  namespace: my-namespace
  labels:
    kueue.x-k8s.io/priority-class: <user-input>-priority
spec:
  displayName: "My Custom Jupyter Lab"
  description: "Custom Jupyter Lab with specific configurations"
  defaultImage: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
  allowedImages:
    - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
    - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
  defaultResources:
    requests:
      cpu: "1"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "16Gi"
  primaryStorage:
    defaultSize: "10Gi"
    minSize: "5Gi"
    maxSize: "50Gi"
    defaultStorageClassName: "sagemaker-spaces-default-storage-class"
    defaultMountPath: "/home/sagemaker-user"
  defaultContainerConfig:
    command: ["/opt/amazon/sagemaker/workspace/bin/entrypoint-workspace-jupyterlab"]
  defaultPodSecurityContext:
    fsGroup: 1000
  defaultOwnershipType: "Public"
  defaultAccessStrategy:
    name: "hyperpod-access-strategy"
  allowSecondaryStorages: true
  appType: "jupyterlab"

Immagini SMD/personalizzate

I clienti possono configurare le politiche relative alle immagini tramite modelli fornendo un'immagine predefinita e un elenco di immagini consentite. Inoltre, gli amministratori possono scegliere se consentire ai data scientist di portare le proprie immagini personalizzate. Per impostazione predefinita, il sistema utilizza la SageMaker distribuzione più recente, ma se si desidera aggiungere una versione particolare, è possibile specificare l'esatta versione SMD da utilizzare in un modello.

Requisiti per le immagini personalizzate:

Requisito IDE remoto

Requisito per la versione di VS Code

È richiesta la versione VS Code v1.90 o successiva. Consigliamo di utilizzare l’ultima versione stabile di VS Code.

Requisiti del sistema operativo

Per connetterti in remoto agli spazi di Studio, devi disporre di uno dei seguenti sistemi operativi:

Prerequisiti del computer locale

Prima di connettere il codice di Visual Studio locale agli spazi di Studio, assicurati che il computer locale disponga delle dipendenze e dell'accesso alla rete necessari.

Dipendenze locali richieste

Nel computer locale devono essere installati i seguenti componenti:

Platform-specific requisiti

Requisiti di connettività di rete

Il computer locale deve avere accesso alla rete agli endpoint di Session Manager. Ad esempio, negli Stati Uniti orientali (Virginia settentrionale) (us-east-1) questi possono essere:

Requisiti delle immagini

SageMaker Immagini di distribuzione

Quando si utilizza SageMaker Distribution con accesso remoto, utilizzare SageMaker la versione 2.7 o successiva di Distribution.

Immagini personalizzate

Quando utilizzi Bring your own image (BYOI) con accesso remoto, assicurati di seguire le specifiche dell'immagine personalizzata e assicurati che siano installate le seguenti dipendenze:

Requisiti per l’istanza

Ottimizzazione del tempo di avvio di Kubernetes tramite le immagini dei contenitori Pre-Warming

Le prestazioni di estrazione delle immagini dai container sono diventate un ostacolo significativo per molti clienti EKS, soprattutto perché i carichi di AI/ML lavoro si basano su immagini di container sempre più grandi. L'estrazione e la decompressione di queste immagini di grandi dimensioni richiedono in genere diversi minuti la prima volta che vengono utilizzate su ciascun nodo EKS. Questo ritardo aggiunge una notevole latenza all'avvio di SageMaker Spaces e influisce direttamente sull'esperienza utente, in particolare in ambienti in cui è essenziale un avvio rapido, come notebook e lavori di sviluppo interattivi.

Il preriscaldamento delle immagini è una tecnica utilizzata per precaricare immagini specifiche del contenitore su ogni nodo del cluster prima che siano necessarie. EKS/HyperPod Invece di aspettare che un pod attivi il primo pull di un'immagine di grandi dimensioni, il cluster scarica e memorizza nella cache le immagini in modo proattivo su tutti i nodi. Ciò garantisce che all'avvio dei carichi di lavoro, le immagini richieste siano già disponibili localmente, eliminando i lunghi ritardi dovuti all'avvio a freddo. Il preriscaldamento delle immagini migliora la velocità di avvio di SageMaker Spaces e offre un'esperienza più prevedibile e reattiva per gli utenti finali.

Pre-Warming tramite DaemonSet

Si consiglia di utilizzare a DaemonSet per precaricare le immagini. A DaemonSet assicura che un pod venga eseguito su ogni nodo del cluster. Ogni contenitore all'interno del DaemonSet pod fa riferimento a un'immagine da memorizzare nella cache. Quando Kubernetes avvia il pod, estrae automaticamente le immagini, riscaldando la cache su ogni nodo.

L'esempio seguente mostra come creare un file DaemonSet che precarichi due immagini GPU. Ogni contenitore esegue un sleep infinity comando leggero per mantenere il pod attivo con un sovraccarico minimo.

cat <<EOF | kubectl apply -n "namespace_1" -f -
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: image-preload-ds
spec:
  selector:
    matchLabels:
      app: image-preloader
  template:
    metadata:
      labels:
        app: image-preloader
    spec:
      containers:
      - name: preloader-3-4-2
        image: public.ecr.aws/sagemaker/sagemaker-distribution:3.4.2-gpu
        command: ["sleep"]
        args: ["infinity"]
        resources:
          requests:
            cpu: 1m
            memory: 16Mi
          limits:
            cpu: 5m
            memory: 32Mi
      - name: preloader-3-3-2
        image: public.ecr.aws/sagemaker/sagemaker-distribution:3.3.2-gpu
        command: ["sleep"]
        args: ["infinity"]
        resources:
          requests:
            cpu: 1m
            memory: 16Mi
          limits:
            cpu: 5m
            memory: 32Mi
EOF

Come funziona

Spazio di archiviazione predefinito (EBS)

Il sistema utilizza di default il driver EBS CSI per effettuare il provisioning dei volumi di storage EBS per ogni workspace. SageMaker crea una classe di archiviazione EBS da utilizzare con gli spazi di lavoro e gli amministratori possono personalizzare le dimensioni predefinite e massime di questi volumi utilizzando le impostazioni del modello. Per gli utenti esperti che utilizzano gli strumenti CLI, è anche possibile personalizzare la classe di archiviazione dello spazio di lavoro, il che consente agli utenti di sfruttare altre classi di archiviazione, inclusa la configurazione di chiavi KMS gestite dal cliente per i propri volumi EBS.

Tieni presente che i volumi EBS sono associati a una particolare AZ, il che significa che gli spazi di lavoro possono essere pianificati solo su nodi nella stessa AZ del loro volume di archiviazione. Ciò può portare a errori di pianificazione se la capacità del cluster esiste ma non nell'AZ corretto.

Spazio di archiviazione aggiuntivo

SageMaker Spaces supporta il collegamento di volumi di storage aggiuntivi come Amazon EFS, FSx for Lustre o S3 Mountpoint ai tuoi spazi di sviluppo. Ciò consente di accedere a set di dati condivisi, collaborare su progetti o utilizzare storage ad alte prestazioni per i carichi di lavoro.

Prerequisiti

Prima di collegare spazio di archiviazione aggiuntivo agli spazi, devi:

Collegare lo spazio di archiviazione agli spazi

Una volta PersistentVolumeClaim configurato, puoi collegarlo a uno spazio usando la HyperPod CLI o kubectl.

HyperPod CLI

hyp create hyp-space \
    --name my-space \
    --display-name "My Space with FSx" \
    --memory 8Gi \
    --volume name=shared-fsx,mountPath=/shared,persistentVolumeClaimName=my-fsx-pvc

kubectl

apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  name: my-space
spec:
  displayName: "My Space with FSx"
  desiredStatus: Running
  volumes:
  - name: shared-fsx
    mountPath: /shared
    persistentVolumeClaimName: my-fsx-pvc

Volumi multipli

Puoi collegare più volumi di archiviazione aggiuntivi a un singolo spazio specificando più --volume flag con la CLI o più voci nell'volumesarray con kubectl.

HyperPod CLI

hyp create hyp-space \
    --name my-space \
    --display-name "My Space with Multiple Storage" \
    --memory 8Gi \
    --volume name=shared-efs,mountPath=/shared,persistentVolumeClaimName=my-efs-pvc \
    --volume name=datasets,mountPath=/datasets,persistentVolumeClaimName=my-s3-pvc

kubectl

apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  name: my-space
spec:
  displayName: "My Space with Multiple Storage"
  desiredStatus: Running
  volumes:
  - name: shared-efs
    mountPath: /shared
    persistentVolumeClaimName: my-efs-pvc
  - name: datasets
    mountPath: /datasets
    persistentVolumeClaimName: my-s3-pvc

Configurazione delle risorse

SageMaker Spaces ti consente di configurare le risorse di calcolo per i tuoi ambienti di sviluppo, tra cui risorse CPU, memoria e GPU per soddisfare i requisiti del carico di lavoro.

Configurazione GPU

SageMaker Spaces supporta sia l'allocazione dell'intera GPU che il partizionamento della GPU utilizzando la tecnologia Multi-Instance NVIDIA GPU (MIG). Ciò consente di ottimizzare l'utilizzo della GPU per diversi tipi di carichi di lavoro di machine learning.

Allocazione dell'intera GPU

HyperPod CLI

hyp create hyp-space \
    --name gpu-space \
    --display-name "GPU Development Space" \
    --image public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu \
    --memory 16Gi \
    --gpu 1 \
    --gpu-limit 1

kubectl

apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  name: gpu-space
spec:
  displayName: "GPU Development Space"
  image: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
  desiredStatus: Running
  resources:
    requests:
      memory: "16Gi"
      nvidia.com/gpu: "1"
    limits:
      memory: "16Gi"
      nvidia.com/gpu: "1"

Partizionamento della GPU (MIG)

Il partizionamento della GPU tramite la tecnologia NVIDIA Multi-Instance GPU (MIG) consente di partizionare una singola GPU in istanze più piccole e isolate. Il HyperPod cluster deve avere nodi GPU che supportano MIG e avere profili MIG configurati. Per ulteriori informazioni sulla configurazione del MIG sul HyperPod cluster, consulta Partizionamento della GPU tramite NVIDIA MIG.

HyperPod CLI

hyp create hyp-space \
    --name mig-space \
    --display-name "MIG GPU Space" \
    --image public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu \
    --memory 8Gi \
    --accelerator-partition-type mig-3g.20gb \
    --accelerator-partition-count 1

kubectl

apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  name: mig-space
spec:
  displayName: "MIG GPU Space"
  image: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
  desiredStatus: Running
  resources:
    requests:
      memory: "8Gi"
      nvidia.com/mig-3g.20gb: "1"
    limits:
      memory: "8Gi"
      nvidia.com/mig-3g.20gb: "1"

Ciclo di vita

La configurazione del ciclo di vita fornisce script di avvio che vengono eseguiti quando viene creato o avviato un workspace. Questi script consentono agli amministratori di personalizzare l'ambiente dello spazio di lavoro durante l'avvio. Si tratta di script bash con una dimensione massima di 1 KB. Se hai bisogno di una configurazione di configurazione più ampia, ti consigliamo di aggiungere uno script all'immagine del contenitore e di attivare lo script dalla configurazione del ciclo di vita.

Sfruttiamo gli hook del ciclo di vita dei container Kubernetes per fornire questa funzionalità. https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/ Tieni presente che Kubernetes non fornisce garanzie su quando lo script di avvio verrà eseguito in relazione al punto di ingresso del contenitore.

Spegnimento in modalità inattiva

Configura lo spegnimento automatico degli spazi di lavoro inattivi per ottimizzare l'utilizzo delle risorse.

Spegnimento in modalità inattiva

idleShutdown:
  enabled: true
  idleShutdownTimeoutMinutes: 30
  detection:
    httpGet:
      path: /api/idle
      port: 8888
      scheme: HTTP

Parameters

abilitato (booleano, obbligatorio): abilita o disabilita lo spegnimento inattivo per l'area di lavoro.

idle ShutdownTimeoutMinutes (numero intero, obbligatorio): numero di minuti di inattività prima della chiusura dello spazio di lavoro. Il valore minimo è 1.

rilevamento (oggetto, obbligatorio): definisce come rilevare lo stato di inattività del workspace.

detection.httpGet (object, opzionale) - Configurazione dell'endpoint HTTP per il rilevamento degli inattivi. Utilizza le HTTPGetAction specifiche Kubernetes.

Posizioni di configurazione

Configurazione dell'area di lavoro

Definisci lo spegnimento inattivo direttamente nelle specifiche dell'area di lavoro:

apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:

      name: my-workspace
spec:
  displayName: "Development Workspace"
  image:
      jupyter/scipy-notebook:latest
  idleShutdown:
    enabled: true

      idleShutdownTimeoutMinutes: 30
    detection:
      httpGet:
        path:
      /api/idle
        port: 8888

Configurazione del modello

Definisci il comportamento predefinito di spegnimento inattivo in un: WorkspaceTemplate

apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: jupyter-template
spec:
  displayName: "Jupyter Template"
  defaultImage: jupyter/scipy-notebook:latest
  defaultIdleShutdown:
    enabled: true
    idleShutdownTimeoutMinutes: 30
    detection:
      httpGet:
        path: /api/idle
        port: 8888
  idleShutdownOverrides:
    allow: true
    minTimeoutMinutes: 60
    maxTimeoutMinutes: 240

Ereditarietà e sostituzioni dei modelli

Le aree di lavoro che utilizzano un modello ereditano automaticamente la configurazione del modello. defaultIdleShutdown I workspace possono sovrascrivere questa configurazione se il modello lo consente.

Sostituisci politica

I modelli controllano il comportamento di sostituzione tramite: idleShutdownOverrides

allow (boolean, default: true) - Indica se gli spazi di lavoro possono sovrascrivere la configurazione predefinita di inattività.

min TimeoutMinutes (intero, opzionale) - Valore di timeout minimo consentito per le sostituzioni dello spazio di lavoro.

max TimeoutMinutes (intero, opzionale) - Valore di timeout massimo consentito per le sostituzioni dello spazio di lavoro.

Esempio di ereditarietà

Workspace eredita le impostazioni predefinite del modello:

apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  name: my-workspace
spec:
  displayName: "My Workspace"
  templateRef:
    name: jupyter-template
  # Inherits defaultIdleShutdown from template

Esempio di sovrascrittura

Workspace sostituisce le impostazioni predefinite del modello:

apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
  name: my-workspace
spec:
  displayName: "My Workspace"
  templateRef:
    name: jupyter-template
  idleShutdown:
    enabled: true
    idleShutdownTimeoutMinutes: 60  # Must be within template bounds
    detection:
      httpGet:
        path: /api/idle
        port: 8888

Configurazione bloccata

Impedisci le sostituzioni dell'area di lavoro:

apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: locked-template
spec:
  displayName: "Locked Template"
  defaultImage: jupyter/scipy-notebook:latest
  defaultIdleShutdown:
    enabled: true
    idleShutdownTimeoutMinutes: 30
    detection:
      httpGet:
        path: /api/idle
        port: 8888
  idleShutdownOverrides:
    allow: false  # Workspaces cannot override

Comportamento

Quando lo spegnimento in modalità inattiva è abilitato, il sistema controlla periodicamente l'attività dello spazio di lavoro utilizzando l'endpoint HTTP configurato. Se l'endpoint indica che lo spazio di lavoro è inattivo per la durata di timeout specificata, lo spazio di lavoro si interrompe automaticamente. È possibile riavviare manualmente l'area di lavoro quando necessario.

Aggiornamenti dei modelli

Gli strumenti client come Kubectl o Hyperpod CLI e SDK possono essere utilizzati per gestire gli spazi all'interno del cluster EKS. Gli amministratori possono fornire Space Templates per le configurazioni Space predefinite, mentre i Data Scientist possono personalizzare i propri ambienti di sviluppo integrati senza dover comprendere la complessità sottostante di Kubernetes. Per istruzioni dettagliate sull'uso, consulta la documentazione CLI e SDK all'indirizzo. https://sagemaker-hyperpod-cli.readthedocs.io/en/latest/index.html

Gli amministratori possono eseguire operazioni CRUD su Space Templates, che fungono da configurazioni di base per la creazione di uno Space. I data scientist possono eseguire operazioni CRUD su Spaces e sovrascrivere vari parametri, inclusi i profili Multi-Instance GPU per nodi di calcolo specifici. Possono avviare, arrestare e connettersi agli Spaces tramite l'accesso remoto a VSCode e l'interfaccia utente Web. Quando un modello di spazio viene aggiornato, qualsiasi spazio creato successivamente verrà configurato con le impostazioni del modello aggiornato. I controlli di conformità verranno eseguiti quando gli Spaces esistenti vengono aggiornati o avviati. Se le impostazioni sono scadute o non corrispondono, gli Spaces non verranno aggiornati o avviati.

Usare hyp cli e kubectl

L'utente può eseguire CRUD sui modelli con l'Hyperpod CLI

### 1. Create a Space Template
hyp create hyp-space-template --file template.yaml

### 2. List Space Templates
hyp list hyp-space-template
hyp list hyp-space-template --output json

### 3. Describe a Space Template
hyp describe hyp-space-template --name my-template
hyp describe hyp-space-template --name my-template --output json

### 4. Update a Space Template
hyp update hyp-space-template --name my-template --file updated-template.yaml

### 5. Delete a Space Template
hyp delete hyp-space-template --name my-template

Per creare modelli personalizzati, puoi utilizzare i nostri modelli di sistema come punto di partenza. Questo modello funzionerà per SMD-like le immagini, tuttavia può essere personalizzato in base alle immagini utilizzate dagli amministratori.

Esempio di modello personalizzato JupyterLab :

apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: my-jupyter-template
  namespace: my-namespace
spec:
  displayName: "My Custom Jupyter Lab"
  description: "Custom Jupyter Lab with specific configurations"
  defaultImage: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
  allowedImages:
    - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
    - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
  defaultResources:
    requests:
      cpu: "1"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "16Gi"
  primaryStorage:
    defaultSize: "10Gi"
    minSize: "5Gi"
    maxSize: "50Gi"
    defaultStorageClassName: "sagemaker-spaces-default-storage-class"
    defaultMountPath: "/home/sagemaker-user"
  defaultContainerConfig:
    command: ["/opt/amazon/sagemaker/workspace/bin/entrypoint-workspace-jupyterlab"]
  defaultPodSecurityContext:
    fsGroup: 1000
  defaultOwnershipType: "Public"
  defaultAccessStrategy:
    name: "hyperpod-access-strategy"
  allowSecondaryStorages: true
  appType: "jupyterlab"

Esempio di modello personalizzato di Code Editor:

apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: my-code-editor-template
  namespace: my-namespace
spec:
  displayName: "My Custom Code Editor"
  description: "Custom Code Editor with specific configurations"
  defaultImage: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
  allowedImages:
    - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu"
    - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
  defaultResources:
    requests:
      cpu: "1"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "16Gi"
  primaryStorage:
    defaultSize: "10Gi"
    minSize: "5Gi"
    maxSize: "50Gi"
    defaultStorageClassName: "sagemaker-spaces-default-storage-class"
    defaultMountPath: "/home/sagemaker-user"
  defaultContainerConfig:
    command: ["/opt/amazon/sagemaker/workspace/bin/entrypoint-workspace-code-editor"]
  defaultPodSecurityContext:
    fsGroup: 1000
  defaultOwnershipType: "Public"
  defaultAccessStrategy:
    name: "hyperpod-access-strategy"
  allowSecondaryStorages: true
  appType: "code-editor"