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 di aree di lavoro riutilizzabili che fungono da modelli controllati dall'amministratore per la creazione di aree di lavoro. Forniscono impostazioni predefinite per i valori di configurazione dell'area di lavoro e protezioni per controllare cosa possono fare i data scientist. I modelli esistono a livello di cluster e possono essere riutilizzati in tutti i 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. Gli amministratori possono invece 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"

SMD/Immagini 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 specifica, è possibile specificare l'esatta versione SMD da utilizzare in un modello.

Requisiti per 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 richiesti.

Dipendenze locali richieste

Sul computer locale devono essere installati i seguenti componenti:

Requisiti specifici della piattaforma

requisiti di connettività di rete

Il computer locale deve avere accesso di 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 Distribution versione 2.7 o successiva.

Immagini personalizzate

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

Requisiti per l’istanza

Ottimizzazione del tempo di avvio di Kubernetes preriscaldando le immagini dei container

Le prestazioni di acquisizione delle immagini dei container sono diventate un ostacolo significativo per molti clienti EKS, soprattutto perché i carichi di lavoro si basano su immagini di container sempre più AI/ML grandi. L'estrazione e il disimballaggio 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 l'avvio rapido è essenziale, come notebook e processi di sviluppo interattivi.

Il preriscaldamento delle immagini è una tecnica utilizzata per precaricare immagini di container specifiche su ogni nodo del cluster prima che siano necessarie. EKS/HyperPod Invece di aspettare che un pod attivi la prima estrazione di un'immagine di grandi dimensioni, il cluster scarica e memorizza in modo proattivo le immagini su tutti i nodi. Ciò garantisce che all'avvio dei carichi di lavoro, le immagini richieste siano già disponibili localmente, eliminando i lunghi ritardi di 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.

Preriscaldamento tramite DaemonSet

Si consiglia di utilizzare un DaemonSet per precaricare le immagini. A DaemonSet garantisce che un pod venga eseguito su ogni nodo del cluster. Ogni contenitore all'interno del DaemonSet pod fa riferimento a un'immagine che si desidera 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 precarica due immagini GPU. Ogni contenitore esegue un sleep infinity comando leggero per mantenere attivo il pod 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

Space Default Storage (EBS)

Per impostazione predefinita, il sistema utilizza il driver CSI EBS per eseguire il provisioning dei volumi di storage EBS per ogni area di lavoro. SageMaker crea una classe di archiviazione EBS da utilizzare con le aree di lavoro e gli amministratori possono personalizzare la dimensione predefinita e massima di questi volumi utilizzando le impostazioni del modello. Per gli utenti esperti che lavorano con gli strumenti CLI, puoi anche personalizzare la classe di archiviazione dell'area di lavoro, 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 le aree di lavoro possono essere pianificate solo su nodi nella stessa AZ del volume di archiviazione. Ciò può portare a errori di pianificazione se la capacità del cluster esiste ma non nella zona di disponibilità corretta.

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 dell'area 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.

Utilizziamo 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 delle aree di lavoro inattive 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.

idleShutdownTimeoutMinuti (numeri interi, obbligatori): numero di minuti di inattività prima della chiusura dell'area di lavoro. Il valore minimo è 1.

rilevamento (oggetto, obbligatorio): definisce come rilevare lo stato di inattività dell'area di lavoro.

detection.httpGet (oggetto, opzionale) - Configurazione dell'endpoint HTTP per il rilevamento delle attività inattive. Utilizza la specifica HTTPGet Kubernetes Action.

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 di spegnimento predefinito in caso di inattività 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 Le aree di lavoro possono sovrascrivere questa configurazione se il modello lo consente.

Ignora politica

I modelli controllano il comportamento di override tramite: idleShutdownOverrides

allow (boolean, default: true) - Se gli spazi di lavoro possono sovrascrivere la configurazione di spegnimento inattivo predefinita.

minTimeoutMinutes(intero, opzionale) - Valore di timeout minimo consentito per le sostituzioni dell'area di lavoro.

maxTimeoutMinutes(intero, opzionale): valore di timeout massimo consentito per le sostituzioni dell'area 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 override

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 dello spazio 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 stato di inattività è abilitato, il sistema controlla periodicamente l'attività nell'area di lavoro utilizzando l'endpoint HTTP configurato. Se l'endpoint indica che l'area di lavoro è inattiva per la durata del timeout specificata, l'area 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 modelli di spazio 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 della CLI e dell'SDK all'indirizzo. https://sagemaker-hyperpod-cli.readthedocs.io/en/latest/index.html

Gli amministratori possono eseguire operazioni CRUD sui modelli di spazio, che fungono da configurazioni di base per la creazione di uno spazio. I data scientist possono eseguire operazioni CRUD su Spaces e sovrascrivere vari parametri, inclusi i profili GPU multiistanza per nodi di calcolo specifici. Possono avviare, arrestare e connettersi a Spaces tramite VSCode accesso remoto e 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 spazi esistenti vengono aggiornati o avviati. Se alcune impostazioni superano i limiti o non corrispondono, gli spazi non verranno aggiornati o avviati.

Usare hyp cli e kubectl

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

### 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 immagini simili a SMD, 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 di Code Editor personalizzato:

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"