Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Personnaliser le module complémentaire

Modèle

Les modèles sont des configurations d'espace de travail réutilisables qui servent de plans contrôlés par l'administrateur pour la création d'espaces de travail. Ils fournissent des valeurs par défaut pour les valeurs de configuration de l'espace de travail et des garde-fous permettant de contrôler ce que les data scientists peuvent faire. Les modèles existent au niveau du cluster et peuvent être réutilisés dans les espaces de noms.

SageMaker Spaces crée deux modèles de système comme point de départ pour les data scientists, l'un pour l'éditeur de code et l'autre pour JupyterLab. Ces modèles de système sont gérés par l'addon et ne peuvent pas être modifiés directement. Les administrateurs peuvent plutôt créer de nouveaux modèles et les définir par défaut.

Gouvernance des tâches

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/Images personnalisées

Les clients peuvent configurer les politiques relatives aux images par le biais de modèles en fournissant une image par défaut et une liste d'images autorisées. En outre, les administrateurs peuvent choisir d'autoriser ou non les data scientists à apporter leurs propres images personnalisées. Le système utilise par défaut la dernière SageMaker distribution, mais si vous souhaitez attribuer une version particulière, vous pouvez spécifier la version SMD exacte à utiliser dans un modèle.

Exigences relatives aux images personnalisées :

Exigence d'IDE à distance

Version de VS Code exigée

La version v1.90 ou supérieure de VS Code est requise. Nous vous recommandons d’utiliser la dernière version stable de VS Code.

Système d’exploitation exigé

Vous avez besoin de l’un des systèmes d’exploitation suivants pour vous connecter à distance aux espaces Studio :

Prérequis pour les machines locales

Avant de connecter votre code Visual Studio local aux espaces Studio, assurez-vous que votre machine locale dispose des dépendances et de l'accès réseau requis.

Dépendances locales requises

Les composants suivants doivent être installés sur votre machine locale :

Exigences spécifiques à la plate-forme

Exigences en matière de connectivité réseau

Votre machine locale doit disposer d'un accès réseau aux points de terminaison du gestionnaire de session. Par exemple, dans l'est des États-Unis (Virginie du Nord) (us-east-1), il peut s'agir de :

Exigences relatives aux images

SageMaker Images de distribution

Lorsque vous utilisez SageMaker Distribution avec un accès à distance, utilisez SageMaker Distribution version 2.7 ou ultérieure.

Images personnalisées

Lorsque vous apportez votre propre image (BYOI) avec un accès à distance, assurez-vous de suivre les spécifications d'image personnalisées et de vous assurer que les dépendances suivantes sont installées :

Exigences relatives aux instances

Optimisation du temps de démarrage de Kubernetes en préchauffant les images des conteneurs

Les performances d'extraction d'images de conteneurs constituent désormais un obstacle majeur pour de nombreux clients d'EKS, d'autant plus que les AI/ML charges de travail reposent sur des images de conteneurs de plus en plus grandes. L'extraction et le déballage de ces grandes images prennent généralement plusieurs minutes la première fois qu'elles sont utilisées sur chaque nœud EKS. Ce délai augmente considérablement la latence lors du lancement de SageMaker Spaces et a un impact direct sur l'expérience utilisateur, en particulier dans les environnements où un démarrage rapide est essentiel, tels que les ordinateurs portables ou les tâches de développement interactives.

Le préchauffage des images est une technique utilisée pour précharger des images de conteneur spécifiques sur chaque nœud du EKS/HyperPod cluster avant qu'elles ne soient nécessaires. Au lieu d'attendre qu'un module déclenche la première extraction d'une image de grande taille, le cluster télécharge et met en cache les images de manière proactive sur tous les nœuds. Ainsi, lorsque les charges de travail sont lancées, les images requises sont déjà disponibles localement, éliminant ainsi les longs délais de démarrage à froid. Le préchauffage des images améliore la vitesse de démarrage de SageMaker Spaces et offre une expérience plus prévisible et réactive aux utilisateurs finaux.

Préchauffage via DaemonSet

Nous vous recommandons d'utiliser un DaemonSet pour précharger les images. A DaemonSet garantit qu'un pod s'exécute sur chaque nœud du cluster. Chaque conteneur à l'intérieur du DaemonSet module fait référence à une image que vous souhaitez mettre en cache. Lorsque Kubernetes démarre le pod, il extrait automatiquement les images et réchauffe le cache de chaque nœud.

L'exemple suivant montre comment créer un DaemonSet qui précharge deux images GPU. Chaque conteneur exécute une sleep infinity commande légère pour maintenir le pod actif avec un minimum de surcharge.

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

Comment ça marche

Espace de stockage par défaut (EBS)

Le système utilise le pilote EBS CSI par défaut pour provisionner des volumes de stockage EBS pour chaque espace de travail. SageMaker crée une classe de stockage EBS à utiliser avec les espaces de travail, et les administrateurs peuvent personnaliser la taille par défaut et maximale de ces volumes à l'aide des paramètres du modèle. Pour les utilisateurs expérimentés utilisant des outils CLI, vous pouvez également personnaliser la classe de stockage de l'espace de travail, ce qui permet aux utilisateurs de tirer parti d'autres classes de stockage, notamment en configurant des clés KMS gérées par le client pour leurs volumes EBS.

Notez que les volumes EBS sont liés à une zone de zone spécifique, ce qui signifie que les espaces de travail ne peuvent être planifiés que sur des nœuds de la même zone que leur volume de stockage. Cela peut entraîner des échecs de planification si la capacité du cluster existe mais pas dans la bonne zone de disponibilité.

Cycle de vie

La configuration du cycle de vie fournit des scripts de démarrage qui s'exécutent lors de la création ou du démarrage d'un espace de travail. Ces scripts permettent aux administrateurs de personnaliser l'environnement de travail au démarrage. Il s'agit de scripts bash d'une taille maximale de 1 Ko. Si vous avez besoin d'une configuration plus importante, nous vous recommandons d'ajouter un script à l'image du conteneur et de déclencher le script à partir de la configuration du cycle de vie.

Nous utilisons les hooks du cycle de vie des conteneurs Kubernetes pour fournir cette fonctionnalité https://kubernetes. io/docs/concepts/containers/container-crochets pour le cycle de vie/. Notez que Kubernetes ne fournit aucune garantie quant au moment où le script de démarrage sera exécuté par rapport au point d'entrée du conteneur.

Arrêt d’inactivité

Configurez l'arrêt automatique des espaces de travail inactifs pour optimiser l'utilisation des ressources.

Arrêt d’inactivité

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

Parameters

activé (booléen, obligatoire) : active ou désactive l'arrêt inactif de l'espace de travail.

idleShutdownTimeoutMinutes (entier, obligatoire) : nombre de minutes d'inactivité avant la fermeture de l'espace de travail. La valeur minimum est de 1.

détection (objet, obligatoire) - Définit comment détecter l'état d'inactivité de l'espace de travail.

Detection.HttpGet (objet, facultatif) : configuration du point de terminaison HTTP pour la détection des inactifs. Utilise la spécification Kubernetes Action. HTTPGet

Emplacements de configuration

Configuration d'espace de travail

Définissez l'arrêt en mode veille directement dans les spécifications de l'espace de travail :

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

Configuration du modèle

Définissez le comportement d'arrêt en mode veille par défaut dans 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

Héritage et remplacements de modèles

Les espaces de travail utilisant un modèle héritent automatiquement de la configuration du defaultIdleShutdown modèle. Les espaces de travail peuvent remplacer cette configuration si le modèle le permet.

Politique de dérogation

Les modèles contrôlent le comportement de substitution par idleShutdownOverrides les moyens suivants :

allow (boolean, default : true) : indique si les espaces de travail peuvent remplacer la configuration d'arrêt en mode veille par défaut.

minTimeoutMinutes(entier, facultatif) - Valeur de délai d'expiration minimale autorisée pour les remplacements de l'espace de travail.

maxTimeoutMinutes(entier, facultatif) - Valeur maximale du délai d'expiration autorisé pour les remplacements de l'espace de travail.

Exemple d'héritage

Workspace hérite des paramètres par défaut du modèle :

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

Exemple de dérogation

Workspace remplace les paramètres par défaut du modèle :

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

Configuration verrouillée

Empêchez les remplacements d'espaces de travail :

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

Comportement

Lorsque l'arrêt en mode inactif est activé, le système vérifie régulièrement l'activité de l'espace de travail à l'aide du point de terminaison HTTP configuré. Si le point de terminaison indique que l'espace de travail est inactif pendant la durée spécifiée, l'espace de travail s'arrête automatiquement. Vous pouvez redémarrer manuellement l'espace de travail en cas de besoin.

Mises à jour des modèles

Les outils clients tels que Kubectl ou Hyperpod CLI et SDK peuvent être utilisés pour gérer les espaces au sein du cluster EKS. Les administrateurs peuvent fournir des modèles d'espace pour les configurations d'espace par défaut, tandis que les data scientists peuvent personnaliser leurs environnements de développement intégrés sans avoir à comprendre la complexité sous-jacente de Kubernetes. Pour des instructions d'utilisation détaillées, reportez-vous à la documentation de la CLI et du SDK à l'https://sagemaker-hyperpod-cli.readthedocs.io/en/latest/index.htmladresse.

Les administrateurs peuvent effectuer des opérations CRUD sur les modèles d'espace, qui servent de configurations de base lors de la création d'un espace. Les data scientists peuvent effectuer des opérations CRUD sur Spaces et annuler divers paramètres, notamment les profils GPU multi-instances pour des nœuds de calcul spécifiques. Ils peuvent démarrer, arrêter et se connecter aux Spaces via un VSCode accès à distance et l'interface utilisateur Web. Lorsqu'un modèle d'espace est mis à jour, tout espace créé ultérieurement sera configuré avec les paramètres du modèle mis à jour. Des contrôles de conformité seront effectués lors de la mise à jour ou du démarrage des espaces existants. Si certains paramètres sont hors limites ou ne correspondent pas, les espaces ne seront pas mis à jour ou ne démarreront pas.

Utilisation de hyp cli et kubectl

L'utilisateur peut effectuer un CRUD sur les modèles avec 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

Pour créer des modèles personnalisés, vous pouvez utiliser nos modèles de système comme point de départ. Ce modèle fonctionnera pour les images de type SMD, mais il peut être personnalisé en fonction des images utilisées par les administrateurs.

Exemple de JupyterLab modèle personnalisé :

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"

Exemple de modèle d'éditeur de code personnalisé :

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"