Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Personaliza el complemento

Plantilla

Las plantillas son configuraciones de espacio de trabajo reutilizables que sirven como modelos controlados por el administrador para la creación de espacios de trabajo. Proporcionan valores predeterminados para la configuración del espacio de trabajo y sirven de barrera para controlar lo que pueden hacer los científicos de datos. Las plantillas existen a nivel de clúster y se pueden reutilizar en todos los espacios de nombres.

SageMaker Spaces crea dos plantillas de sistema como punto de partida para los científicos de datos, una para el editor de código y otra para. JupyterLab El complemento administra estas plantillas de sistema y no se pueden editar directamente. En su lugar, los administradores pueden crear nuevas plantillas y configurarlas como predeterminadas.

Gobierno de tareas

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/ Imágenes personalizadas

Los clientes pueden configurar las políticas de imágenes mediante plantillas proporcionando una imagen predeterminada y una lista de imágenes permitidas. Además, los administradores pueden elegir si permiten que los científicos de datos traigan sus propias imágenes personalizadas. El sistema utiliza de forma predeterminada la SageMaker distribución más reciente, pero si desea anclarla a una versión concreta, puede especificar la versión exacta de SMD para utilizarla en una plantilla.

Requisitos de imagen personalizada:

Requisito de IDE remoto

Requisito de versión de Visual Studio Code

Se requiere la versión v1.90 o superior de Visual Studio Code. Recomendamos que se utilice la versión más reciente de Visual Studio Code.

Requisitos del sistema operativo

Para conectarse de forma remota a los espacios de Studio, necesita uno de los siguientes sistemas operativos:

Requisitos previos de la máquina local

Antes de conectar el código de Visual Studio local a los espacios de Studio, asegúrese de que la máquina local tenga las dependencias y el acceso a la red necesarios.

Dependencias locales requeridas

Su máquina local debe tener instalados los siguientes componentes:

Requisitos específicos de la plataforma

Requisitos de conectividad de red

Su máquina local debe tener acceso de red a los puntos finales del administrador de sesiones. Por ejemplo, en EE. UU. Este (Virginia del Norte) (us-east-1) pueden ser:

Requisitos de imágenes

SageMaker Imágenes de distribución

Cuando utilice SageMaker Distribution con acceso remoto, utilice la versión 2.7 o posterior de SageMaker Distribution.

Imágenes personalizadas

Cuando traiga su propia imagen (BYOI) con acceso remoto, asegúrese de seguir las especificaciones de imagen personalizadas y de que estén instaladas las siguientes dependencias:

Requisitos de instancias

Optimización del tiempo de inicio de Kubernetes mediante el precalentamiento de las imágenes de los contenedores

El rendimiento de la extracción de imágenes de contenedores se ha convertido en un obstáculo importante para muchos clientes de EKS, especialmente porque las AI/ML cargas de trabajo dependen de imágenes de contenedores cada vez más grandes. La primera vez que se utilizan en cada nodo de EKS, se tarda varios minutos en extraer y desempaquetar estas imágenes de gran tamaño. Este retraso añade una latencia considerable a la hora de lanzar SageMaker Spaces y repercute directamente en la experiencia del usuario, especialmente en entornos en los que es fundamental un arranque rápido, como las libretas o las tareas de desarrollo interactivo.

El precalentamiento de imágenes es una técnica que se utiliza para precargar imágenes de contenedores específicas en cada nodo del EKS/HyperPod clúster antes de que se necesiten. En lugar de esperar a que un módulo active la primera extracción de una imagen grande, el clúster descarga y almacena en caché las imágenes de todos los nodos de forma proactiva. Esto garantiza que, cuando se inicien las cargas de trabajo, las imágenes necesarias ya estén disponibles localmente, lo que elimina las largas demoras en el arranque en frío. El precalentamiento de la imagen mejora la velocidad de inicio de SageMaker Spaces y proporciona a los usuarios finales una experiencia más predecible y con mayor capacidad de respuesta.

El precalentamiento mediante DaemonSet

Recomendamos utilizar un DaemonSet para precargar las imágenes. A DaemonSet garantiza que un pod se ejecute en cada nodo del clúster. Cada contenedor del DaemonSet pod hace referencia a una imagen que deseas almacenar en caché. Cuando Kubernetes inicia el pod, extrae automáticamente las imágenes y calienta la caché de cada nodo.

En el siguiente ejemplo, se muestra cómo crear una DaemonSet que precargue dos imágenes de la GPU. Cada contenedor ejecuta un sleep infinity comando ligero para mantener el pod activo con una sobrecarga mínima.

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

Cómo funciona

Espacio de almacenamiento predeterminado (EBS)

El sistema utiliza el controlador CSI de EBS de forma predeterminada para aprovisionar los volúmenes de almacenamiento de EBS para cada espacio de trabajo. SageMaker crea una clase de almacenamiento de EBS para usarla con los espacios de trabajo, y los administradores pueden personalizar el tamaño predeterminado y máximo de estos volúmenes mediante la configuración de la plantilla. Para los usuarios avanzados que trabajan con herramientas CLI, también puede personalizar la clase de almacenamiento del espacio de trabajo, lo que permite a los usuarios aprovechar otras clases de almacenamiento, incluida la configuración de claves KMS administradas por el cliente para sus volúmenes de EBS.

Tenga en cuenta que los volúmenes de EBS están enlazados a una zona de disponibilidad determinada, lo que significa que los espacios de trabajo solo se pueden programar en nodos de la misma zona de disponibilidad que su volumen de almacenamiento. Esto puede provocar errores de programación si existe capacidad del clúster pero no en la AZ correcta.

Ciclo de vida

La configuración del ciclo de vida proporciona scripts de inicio que se ejecutan al crear o iniciar un espacio de trabajo. Estos scripts permiten a los administradores personalizar el entorno del espacio de trabajo durante el inicio. Se trata de scripts bash con un tamaño máximo de 1 KB. Si necesita una configuración más amplia, le recomendamos añadir un script a la imagen del contenedor y activar el script a partir de la configuración del ciclo de vida.

Aprovechamos los enlaces del ciclo de vida de los contenedores de Kubernetes para ofrecer esta funcionalidad en https://kubernetes. io/docs/concepts/containers/container-lifecycle-hooks/. Tenga en cuenta que Kubernetes no garantiza cuándo se ejecutará el script de inicio en relación con el punto de entrada del contenedor.

Cierre por inactividad

Configure el cierre automático de los espacios de trabajo inactivos para optimizar el uso de los recursos.

Cierre por inactividad

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

Parameters

habilitado (booleano, obligatorio): habilita o deshabilita el cierre inactivo del espacio de trabajo.

idleShutdownTimeoutMinutos (enteros, obligatorios): número de minutos de inactividad antes de que se cierre el espacio de trabajo. El valor mínimo es 1.

detección (objeto, obligatorio): define cómo detectar el estado inactivo del espacio de trabajo.

detection.httpGet (objeto, opcional): configuración de punto final HTTP para la detección de inactividad. Utiliza la especificación Action de Kubernetes. HTTPGet

Ubicaciones de configuración

Configuración del espacio de trabajo

Defina el apagado por inactividad directamente en la especificación del espacio de trabajo:

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

Configuración de la plantilla

Defina el comportamiento de apagado en reposo predeterminado en 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

Herencia y anulaciones de plantillas

Los espacios de trabajo que utilizan una plantilla heredan automáticamente la configuración de la plantilla. defaultIdleShutdown Los espacios de trabajo pueden anular esta configuración si la plantilla lo permite.

Política de anulación

Las plantillas controlan el comportamiento de anulación mediante: idleShutdownOverrides

allow (boolean, default: true): indica si los espacios de trabajo pueden anular la configuración predeterminada de apagado por inactividad.

minTimeoutMinutes(entero, opcional): valor de tiempo de espera mínimo permitido para las anulaciones de espacios de trabajo.

maxTimeoutMinutes(entero, opcional): valor de tiempo de espera máximo permitido para las anulaciones del espacio de trabajo.

Ejemplo de herencia

Workspace hereda los valores predeterminados de la plantilla:

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

Ejemplo de anulación

Workspace anula los valores predeterminados de la plantilla:

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

Configuración bloqueada

Evite la anulación del espacio de trabajo:

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

Comportamiento

Cuando el apagado por inactividad está activado, el sistema comprueba periódicamente la actividad del espacio de trabajo mediante el punto de conexión HTTP configurado. Si el punto final indica que el espacio de trabajo está inactivo durante el tiempo de espera especificado, el espacio de trabajo se detiene automáticamente. Puede reiniciar manualmente el espacio de trabajo cuando sea necesario.

Actualizaciones de plantillas

Las herramientas del cliente, como Kubectl o Hyperpod CLI y SDK, se pueden usar para administrar Spaces dentro del clúster de EKS. Los administradores pueden aprovisionar plantillas de Space para las configuraciones de Space predeterminadas, mientras que los científicos de datos pueden personalizar sus entornos de desarrollo integrados sin necesidad de comprender la complejidad subyacente de Kubernetes. Para obtener instrucciones de uso detalladas, consulte la documentación de CLI y SDK en https://sagemaker-hyperpod-cli.readthedocs.io/en/latest/index.html.

Los administradores pueden realizar operaciones CRUD en las plantillas de Space, que sirven como configuraciones básicas al crear un espacio. Los científicos de datos pueden realizar operaciones CRUD en Spaces y anular varios parámetros, incluidos los perfiles de GPU de varias instancias para nodos de procesamiento específicos. Pueden iniciar, detener y conectarse a los Spaces mediante el VSCode acceso remoto y la interfaz de usuario web. Cuando se actualiza una plantilla de espacio, cualquier espacio que se cree posteriormente se configurará con los ajustes de la plantilla actualizada. Las comprobaciones de conformidad se realizarán cuando se actualicen o se inicien los espacios existentes. Si alguna configuración está fuera de los límites o no coincide, los espacios no se actualizarán ni se iniciarán.

Usando hyp cli y kubectl

El usuario puede realizar CRUD en las plantillas con la CLI de 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

Para crear plantillas personalizadas, puede utilizar las plantillas de nuestro sistema como punto de partida. Esta plantilla funcionará para imágenes tipo SMD, pero se puede personalizar en función de las imágenes utilizadas por los administradores.

Ejemplo de plantilla personalizada: 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"

Ejemplo de plantilla de editor de código personalizada:

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"