As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Personalize o complemento

Modelo

Os modelos são configurações de espaço de trabalho reutilizáveis que servem como esquemas controlados pelo administrador para a criação do espaço de trabalho. Eles fornecem padrões para valores de configuração do espaço de trabalho e grades de proteção para controlar o que os cientistas de dados podem fazer. Os modelos existem no nível do cluster e podem ser reutilizados em todos os namespaces.

SageMaker O Spaces cria dois modelos de sistema como ponto de partida para cientistas de dados, um para o Code Editor e outro para JupyterLab. Esses modelos de sistema são gerenciados pelo complemento e não podem ser editados diretamente. Em vez disso, os administradores podem criar novos modelos e defini-los como padrão.

Governança de tarefas

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/Imagens personalizadas

Os clientes podem configurar políticas de imagem por meio de modelos, fornecendo uma imagem padrão e uma lista de imagens permitidas. Além disso, os administradores podem escolher se querem permitir que os cientistas de dados tragam suas próprias imagens personalizadas. O sistema usa como padrão a SageMaker distribuição mais recente, mas se você quiser fixar em uma versão específica, você pode especificar a versão exata do SMD a ser usada em um modelo.

Requisitos de imagem personalizada:

Requisito de IDE remoto

Requisito de versão do VS Code

É necessária a versão v1.90 ou posterior do VS Code. Recomendamos usar a versão mais recente do VS Code.

Requisitos de sistema operacional

Você precisa de um dos seguintes sistemas operacionais para se conectar remotamente aos espaços do Studio:

Pré-requisitos da máquina local

Antes de conectar seu Visual Studio Code local aos espaços do Studio, certifique-se de que sua máquina local tenha as dependências e o acesso à rede necessários.

Dependências locais necessárias

Sua máquina local deve ter os seguintes componentes instalados:

Requisitos específicos da plataforma

Requisitos de conectividade de rede

Sua máquina local deve ter acesso à rede aos endpoints do Session Manager. Por exemplo, no Leste dos EUA (Norte da Virgínia) (us-east-1), eles podem ser:

Requisitos de imagens

SageMaker Imagens de distribuição

Ao usar o SageMaker Distribution com acesso remoto, use o SageMaker Distribution versão 2.7 ou posterior.

Imagens personalizadas

Ao trazer sua própria imagem (BYOI) com acesso remoto, siga as especificações personalizadas da imagem e garanta que as seguintes dependências estejam instaladas:

Requisitos de instância

Otimizando o tempo de inicialização do Kubernetes por meio do pré-aquecimento das imagens do contêiner

O desempenho de extração de imagens de contêineres se tornou um gargalo significativo para muitos clientes do EKS, especialmente porque as AI/ML cargas de trabalho dependem de imagens de contêineres cada vez maiores. Extrair e descompactar essas imagens grandes normalmente leva vários minutos na primeira vez em que são usadas em cada nó EKS. Esse atraso adiciona latência substancial ao iniciar o SageMaker Spaces e afeta diretamente a experiência do usuário, especialmente em ambientes em que a inicialização rápida é essencial, como notebooks e trabalhos de desenvolvimento interativos.

O pré-aquecimento de imagem é uma técnica usada para pré-carregar imagens de contêineres específicas em cada nó do EKS/HyperPod cluster antes que elas sejam necessárias. Em vez de esperar que um pod acione a primeira extração de uma imagem grande, o cluster baixa e armazena imagens em cache de forma proativa em todos os nós. Isso garante que, quando as cargas de trabalho forem iniciadas, as imagens necessárias já estejam disponíveis localmente, eliminando longos atrasos na inicialização a frio. O pré-aquecimento da imagem melhora a velocidade de inicialização do SageMaker Spaces e fornece uma experiência mais previsível e responsiva para os usuários finais.

Pré-aquecimento via DaemonSet

Recomendamos usar a DaemonSet para pré-carregar imagens. A DaemonSet garante que um pod seja executado em cada nó do cluster. Cada contêiner dentro do DaemonSet pod faz referência a uma imagem que você deseja armazenar em cache. Quando o Kubernetes inicia o pod, ele extrai automaticamente as imagens, aquecendo o cache em cada nó.

O exemplo a seguir mostra como criar um DaemonSet que pré-carrega duas imagens de GPU. Cada contêiner executa um sleep infinity comando leve para manter o pod ativo com o mínimo de sobrecarga.

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

Como funciona

Armazenamento padrão de espaço (EBS)

O sistema usa o driver EBS CSI por padrão para provisionar volumes de armazenamento do EBS para cada espaço de trabalho. SageMaker cria uma classe de armazenamento do EBS para uso com espaços de trabalho, e os administradores podem personalizar o tamanho padrão e máximo desses volumes usando configurações de modelo. Para usuários avançados que trabalham com ferramentas CLI, você também pode personalizar a classe de armazenamento do espaço de trabalho, o que permite que os usuários aproveitem outras classes de armazenamento, incluindo a configuração de chaves KMS gerenciadas pelo cliente para seus volumes do EBS.

Observe que os volumes do EBS estão vinculados a uma AZ específica, o que significa que os espaços de trabalho só podem ser programados em nós na mesma AZ de seu volume de armazenamento. Isso pode levar a falhas de agendamento se a capacidade do cluster existir, mas não na AZ correta.

Ciclo de vida

A configuração do ciclo de vida fornece scripts de inicialização que são executados quando um espaço de trabalho é criado ou iniciado. Esses scripts permitem que os administradores personalizem o ambiente do espaço de trabalho durante a inicialização. Esses são scripts bash com tamanho máximo de 1 KB. Se você precisar de uma configuração maior, recomendamos adicionar um script à imagem do contêiner e acionar o script a partir da configuração do ciclo de vida.

Aproveitamos os ganchos do ciclo de vida do contêiner Kubernetes para fornecer essa funcionalidade https://kubernetes. io/docs/concepts/containers/container-ganchos de ciclo de vida/. Observe que o Kubernetes não fornece garantias de quando o script de inicialização será executado em relação ao ponto de entrada do contêiner.

Encerramento por inatividade

Configure o desligamento automático de espaços de trabalho ociosos para otimizar o uso de recursos.

Encerramento por inatividade

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

Parâmetros

ativado (booleano, obrigatório) - Ativa ou desativa o desligamento inativo do espaço de trabalho.

idleShutdownTimeoutMinutos (inteiro, obrigatório) - Número de minutos de inatividade antes do encerramento do espaço de trabalho. O valor mínimo é 1.

detecção (objeto, obrigatório) - Define como detectar o estado ocioso do espaço de trabalho.

Detection.httpGet (object, opcional) - Configuração de endpoint HTTP para detecção de inatividade. Usa a especificação Kubernetes Action. HTTPGet

Locais de configuração

Configuração do espaço de trabalho

Defina o desligamento inativo diretamente na especificação do espaço de trabalho:

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

Configuração do modelo

Defina o comportamento padrão de desligamento inativo em um: 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

Herança e substituições de modelos

Os espaços de trabalho que usam um modelo herdam automaticamente a configuração do defaultIdleShutdown modelo. Os espaços de trabalho podem substituir essa configuração se o modelo permitir.

Política de substituição

Os modelos controlam o comportamento de substituição por meio deidleShutdownOverrides:

allow (boolean, default: true) - Se os espaços de trabalho podem substituir a configuração padrão de desligamento ocioso.

minTimeoutMinutes(inteiro, opcional) - Valor mínimo de tempo limite permitido para substituições de espaço de trabalho.

maxTimeoutMinutes(inteiro, opcional) - Valor máximo de tempo limite permitido para substituições de espaço de trabalho.

Exemplo de herança

O espaço de trabalho herda os padrões do modelo:

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

Exemplo de substituição

O espaço de trabalho substitui os padrões do modelo:

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

Configuração bloqueada

Evite substituições no espaço de trabalho:

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 o desligamento inativo está ativado, o sistema verifica periodicamente a atividade do espaço de trabalho usando o endpoint HTTP configurado. Se o endpoint indicar que o espaço de trabalho está ocioso durante o tempo limite especificado, o espaço de trabalho será interrompido automaticamente. Você pode reiniciar manualmente o espaço de trabalho quando necessário.

Atualizações de modelos

As ferramentas do cliente, como Kubectl ou Hyperpod CLI e SDK, podem ser usadas para gerenciar espaços no cluster EKS. Os administradores podem provisionar modelos de espaço para as configurações padrão do Space, enquanto os cientistas de dados podem personalizar seus ambientes de desenvolvimento integrados sem precisar entender a complexidade subjacente do Kubernetes. Para obter instruções de uso detalhadas, consulte a documentação da CLI e do SDK em. https://sagemaker-hyperpod-cli.readthedocs.io/en/latest/index.html

Os administradores podem realizar operações CRUD em modelos de espaço, que servem como configurações básicas ao criar um espaço. Os cientistas de dados podem realizar operações CRUD no Spaces e substituir vários parâmetros, incluindo os perfis de GPU de várias instâncias para nós de computação específicos. Eles podem iniciar, parar e se conectar aos Spaces por meio do VSCode acesso remoto e da interface do usuário da Web. Quando um modelo de espaço é atualizado, qualquer espaço criado posteriormente será definido com as configurações do modelo atualizado. As verificações de conformidade serão realizadas quando os Spaces existentes forem atualizados ou iniciados. Se alguma configuração estiver fora dos limites ou for incompatível, os Spaces não serão atualizados ou iniciados.

Usando hyp cli e kubectl

O usuário pode executar CRUD nos modelos com o 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

Para criar modelos personalizados, você pode usar nossos modelos de sistema como ponto de partida. Este modelo funcionará para imagens semelhantes a SMD, mas pode ser personalizado com base nas imagens usadas pelos administradores.

Exemplo de JupyterLab modelo personalizado:

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"

Exemplo de modelo de editor de código personalizado:

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"