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 :
-
curlsi vous souhaitez utiliser l'arrêt au ralenti port 8888
-
accès distant
Exigence d'IDE à distance
Version de VS Code exigée
La version v1.90
Système d’exploitation exigé
Vous avez besoin de l’un des systèmes d’exploitation suivants pour vous connecter à distance aux espaces Studio :
-
macOS 13+
-
Windows 10
-
Windows 11
-
Linux
-
Installez le code Microsoft VS officiel pour Linux
-
il ne s'agit pas d'une version open source
-
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.
Note
Les environnements soumis à des restrictions d'installation de logiciels peuvent empêcher les utilisateurs d'installer les dépendances requises. Le AWS Toolkit for Visual Studio Code recherche automatiquement ces dépendances lors de l'établissement de connexions à distance et vous invite à procéder à l'installation s'il en manque une. Coordonnez-vous avec votre service informatique pour vous assurer que ces composants sont disponibles.
Dépendances locales requises
Les composants suivants doivent être installés sur votre machine locale :
-
— Extension VS Code Marketplace standard pour le développement à distance
-
Plug-in Session Manager — Nécessaire pour la gestion sécurisée des sessions
-
Client SSH : composant standard sur la plupart des machines (OpenSSH recommandé pour Windows
) -
Généralement inclus dans l'installation de VS Code
Exigences spécifiques à la plate-forme
-
Utilisateurs de Windows : la PowerShell version 5.1 ou ultérieure est requise pour les connexions au terminal SSH
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 :
-
curlouwget— Nécessaire pour le téléchargement de AWS CLI composants -
unzip— Nécessaire pour extraire les fichiers AWS CLI d'installation -
tar— Nécessaire pour l'extraction des archives -
gzip— Nécessaire pour la gestion des fichiers compressés
Exigences relatives aux instances
-
Mémoire : 8 Go ou plus
-
Utilisez des instances dotées d'au moins 8 Go de mémoire. Les types d’instances suivants ne sont pas pris en charge en raison d’une mémoire insuffisante (moins de 8 Go) :
ml.t3.medium,ml.c7i.large,ml.c6i.large,ml.c6id.largeetml.c5.large. Pour une liste plus complète des types d'instances, consultez la page de tarification d'Amazon EC2 On-Demand
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
-
Chaque conteneur fait référence à une image.
-
Kubernetes doit télécharger chaque image avant de démarrer le conteneur.
-
Une fois que le pod est en cours d'exécution sur chaque nœud, les images sont mises en cache localement.
-
Toute charge de travail utilisant ces images démarre désormais beaucoup plus rapidement.
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/.
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
-
path - chemin HTTP à demander
-
port - Numéro ou nom du port
-
schéma - HTTP ou HTTPS (par défaut : HTTP)
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.html
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"
