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á.
# IDEs e cadernos
SageMaker A Amazon está introduzindo um novo recurso para clusters SageMaker HyperPod EKS, que permite que os desenvolvedores de IA executem suas cargas de trabalho interativas de aprendizado de máquina diretamente no cluster HyperPod EKS. Esse recurso introduz um novo complemento chamado Amazon SageMaker Spaces, que permite que os desenvolvedores de IA criem e gerenciem ambientes independentes para executar notebooks.
Os administradores podem usar o SageMaker HyperPod Console para instalar o complemento em seu cluster e definir configurações de espaço padrão, como imagens, recursos computacionais, armazenamento local para configurações de notebook (armazenamento adicional a ser anexado aos espaços de desenvolvimento), sistemas de arquivos e scripts de inicialização. Uma opção de instalação com um clique estará disponível com as configurações padrão para simplificar a experiência do administrador. Os administradores podem usar o SageMaker HyperPod console, o kubectl ou a HyperPod CLI para instalar o operador, criar configurações padrão e gerenciar todos os espaços em um local centralizado.
Os desenvolvedores de IA podem usar a HyperPod CLI para criar, atualizar e excluir espaços de desenvolvimento. Eles têm a flexibilidade de usar as configurações padrão fornecidas pelos administradores ou personalizar os ajustes. Os desenvolvedores de IA podem acessar seus espaços HyperPod usando o VS Code local IDEs, and/or o navegador da Web que hospeda o CodeEditor IDE JupyterLab ou o IDE em um domínio DNS personalizado configurado por seus administradores. Eles também podem usar o recurso de encaminhamento de portes do Kubernetes para acessar os espaços nos navegadores da web.
## Administrador
+ [Configurar permissões](permission-setup.md)
+ [Instale o complemento SageMaker AI Spaces](operator-install.md)
+ [Personalize o complemento](customization.md)
+ [Adicione usuários e configure contas de serviço](add-user.md)
+ [Limites](ds-limits.md)
+ [Governança de tarefas para espaços interativos em HyperPod](task-governance.md)
+ [Observabilidade](observability.md)
## Cientista de dados
+ [Crie e gerencie espaços](create-manage-spaces.md)
+ [Acesso pelo navegador da web](browser-access.md)
+ [Acesso remoto ao SageMaker Spaces](vscode-access.md)
## SageMaker Preços de instâncias gerenciadas do Spaces
O complemento/operador do SageMaker Spaces não incorre em nenhuma cobrança adicional para o cliente. No entanto, para suportar o SSH-over-SSM tunelamento necessário para o recurso *Remote IDE Connection*, o SageMaker Spaces usa uma instância AWS gerenciada. Essa instância é registrada como uma instância local avançada no SSM e, portanto, é cobrada por hora de computação.
[Consulte a tarifa “Gerenciamento de Instâncias On-Premises” na página de preços do AWS Systems Manager: AWS Systems Manager Pricing: pricing/ https://aws.amazon.com/systems-manager/](https://aws.amazon.com/systems-manager/pricing.com)
# Configurar permissões
## Funções necessárias para o complemento e suas dependências
### Funções do IAM necessárias para SageMaker espaços em SageMaker HyperPod
Ao ativar **SageMaker os recursos do Spaces (também conhecido como SageMaker ** **IDE/Notebooks)** em um cluster SageMaker HyperPod (EKS), várias funções do IAM devem ser criadas e atribuídas. Essas funções oferecem suporte a acesso seguro, roteamento, sessões remotas de IDE e provisionamento de armazenamento do EBS. A tabela a seguir resume as quatro funções e quando elas são necessárias.
### Tabela de resumo de funções
| Perfil do IAM | Obrigatório? | Finalidade | Quem o usa? | Personalização permitida pelo SageMaker console? |
| --- | --- | --- | --- | --- |
| Função de execução do complemento Spaces | Sempre necessário | Permite que o controlador Spaces gerencie Spaces, gere sessões pré-assinadas e gerencie URLs sessões de SSM | Pod controlador adicional (privilegiado) | ✔ Sim |
| Função do roteador no cluster | Necessário para acesso ao WebUI | Permite que o pod do roteador execute operações KMS para assinatura JWT (autenticação WebUI) | Pod de roteador no cluster (privilegiado) | ✔ Sim |
| Função de instância gerenciada do SSM | Necessário para acesso remoto ao IDE | Usado pelo sidecar do agente SSM para SSH-over-SSM sessões remotas de IDE | Pods do SSM Agent in Space IDE (não é um pod complementar) | ✔ Sim |
| Função do IAM para o complemento do driver EBS CSI | Sempre necessário | Permite que o driver EBS CSI use create/attach/modify volumes para cargas de trabalho do Spaces | Complemento do driver EBS CSI | Criado automaticamente |
| Função do IAM para complemento de DNS externo | Necessário para acesso ao WebUI | Ele garante que os endpoints do Space e os componentes do cluster possam receber nomes DNS automaticamente nas zonas hospedadas do Route 53 do cliente. | Complemento de DNS externo | Criado automaticamente |
### 1. Função de execução do complemento Spaces (obrigatória)
A função de execução do complemento Spaces é sempre necessária porque é usada pelo pod controlador do complemento SageMaker Spaces, um componente administrativo instalado por meio do complemento EKS. Essa função permite que o controlador gerencie espaços, provisione recursos, interaja com o SSM e gere pré-assinados URLs para acesso remoto ao IDE e ao WebUI. Ele também suporta o acesso KMS usado para assinatura de solicitações para autenticar as solicitações https do WebUI. Essa função pode ser criada automaticamente quando o complemento SageMaker Spaces é instalado por meio do SageMaker console. Para criação manual, AWS fornece a política `AmazonSageMakerSpacesControllerPolicy` gerenciada.
**Política de confiança de referência**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:SourceAccount": "{{accountId}}",
"aws:SourceArn": "arn:aws:eks:{{region}}:{{accountId}}:cluster/{{eksClusterName}}"
}
}
}
]
}
```
### 2. Função de roteador no cluster (necessária para autenticação WebUI)
A função In-Cluster Router é usada pelo **pod do roteador**, um componente privilegiado que autentica as sessões do Spaces WebUI. O roteador usa uma chave KMS para criar e assinar tokens JWT que autorizam o acesso do usuário a espaços específicos. Essa função permite que o pod do roteador gere chaves de dados e as descriptografe. Semelhante à função de controlador, ela reforça a segurança usando restrições de escopo baseadas em tags e clusters. Essa função pode ser gerada automaticamente quando o complemento Spaces é instalado por meio do AWS SageMaker console, mas os clientes podem criá-la manualmente.
**Política de confiança de referência**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:SourceAccount": "{{accountId}}",
"aws:SourceArn": "arn:aws:eks:{{region}}:{{accountId}}:cluster/{{eksClusterName}}"
}
}
}
]
}
```
**Política de permissão de referência**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "KMSDescribeKey",
"Effect": "Allow",
"Action": [
"kms:DescribeKey"
],
"Resource": "arn:aws:kms:{{region}}:{{accountId}}:key/{{kmsKeyId}}"
},
{
"Sid": "KMSKeyOperations",
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:{{region}}:{{accountId}}:key/{{kmsKeyId}}",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:sagemaker:component": "amazon-sagemaker-spaces",
"kms:EncryptionContext:sagemaker:eks-cluster-arn": "${aws:PrincipalTag/eks-cluster-arn}"
}
}
}
]
}
```
### 3. Função de instância gerenciada do SSM (necessária para acesso remoto ao IDE)
A função de instância gerenciada do SSM é passada ao registrar a instância gerenciada do SSM para habilitar o acesso remoto ao IDE. Essa função permite que o agente do SSM registre o pod como uma instância gerenciada do SSM e use os canais do SSM Session Manager para conectividade do IDE remoto (SSH sobre SSM). Ele pode ser criado automaticamente ao usar o AWS SageMaker console. Para implantações manuais, os clientes devem criar essa função e fornecê-la ao complemento Spaces. O pod do controlador em si não assume essa função; ele só a fornece durante a chamada`ssm:CreateActivation`.
**Política de confiança de referência**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "{{account}}"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:ssm:{{region}}:{{account}}:*"
}
}
}
]
}
```
**Política de permissões de referência**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:DescribeAssociation"
],
"Resource": [
"arn:aws:ssm:{{region}}:{{account}}:association/*",
"arn:aws:ssm:{{region}}:{{account}}:document/*",
"arn:aws:ec2:{{region}}:{{account}}:instance/*",
"arn:aws:ssm:{{region}}:{{account}}:managed-instance/*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:DescribeDocument"
],
"Resource": "arn:aws:ssm:{{region}}:{{account}}:document/*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetParameter",
"ssm:GetParameters"
],
"Resource": "arn:aws:ssm:{{region}}:{{account}}:parameter/*"
},
{
"Effect": "Allow",
"Action": [
"ssm:ListInstanceAssociations"
],
"Resource": [
"arn:aws:ec2:{{region}}:{{account}}:instance/*",
"arn:aws:ssm:{{region}}:{{account}}:managed-instance/*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:PutComplianceItems"
],
"Resource": [
"arn:aws:ec2:{{region}}:{{account}}:instance/*",
"arn:aws:ssm:{{region}}:{{account}}:managed-instance/*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:UpdateAssociationStatus"
],
"Resource": [
"arn:aws:ssm:{{region}}:{{account}}:document/*",
"arn:aws:ec2:{{region}}:{{account}}:instance/*",
"arn:aws:ssm:{{region}}:{{account}}:managed-instance/*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:UpdateInstanceAssociationStatus"
],
"Resource": [
"arn:aws:ssm:{{region}}:{{account}}:association/*",
"arn:aws:ec2:{{region}}:{{account}}:instance/*",
"arn:aws:ssm:{{region}}:{{account}}:managed-instance/*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:UpdateInstanceInformation"
],
"Resource": [
"arn:aws:ec2:{{region}}:{{account}}:instance/*",
"arn:aws:ssm:{{region}}:{{account}}:managed-instance/*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:GetDeployablePatchSnapshotForInstance",
"ssm:GetManifest",
"ssm:ListAssociations",
"ssm:PutInventory",
"ssm:PutConfigurePackageResult"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2messages:AcknowledgeMessage",
"ec2messages:DeleteMessage",
"ec2messages:FailMessage",
"ec2messages:GetEndpoint"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2messages:GetMessages",
"ec2messages:SendReply"
],
"Resource": "*",
"Condition": {
"ArnLike": {
"ssm:SourceInstanceARN": "arn:aws:ssm:{{region}}:{{account}}:managed-instance/*"
}
}
}
]
}
```
### 4. Função do IAM para o complemento do driver EBS CSI
A função do IAM para o driver CSI do EBS é necessária porque o driver CSI do EBS provisiona volumes persistentes para cargas de trabalho do Spaces. Embora a [Amazon EBSCSIDriver Policy AWS](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverPolicy.html) gerenciada forneça permissões básicas, os SageMaker HyperPod clusters exigem [recursos adicionais](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-ebs.html#sagemaker-hyperpod-eks-ebs-setup), como criar restaurações rápidas de instantâneos, marcar volumes pertencentes ao cluster e volumes para nós gerenciados. attaching/detaching HyperPod Essas permissões também incluem permissões SageMaker específicas APIs , como`sagemaker:AttachClusterNodeVolume`. Se o driver EBS CSI não estiver instalado, essa função agora será criada automaticamente pelo SageMaker console durante a instalação do complemento Spaces, **sem exigir nenhuma** ação do cliente.
### 5. Função do IAM para complemento de DNS externo
O complemento DNS externo gerencia registros DNS para recursos de Serviços e Entrada no cluster. HyperPod Ele garante que os endpoints do Space e os componentes do cluster possam receber nomes DNS automaticamente nas zonas hospedadas do Route 53 do cliente. Atualmente, os clientes geralmente instalam o DNS externo manualmente por meio de uma opção de 1 clique no console EKS. Como parte da melhoria da experiência do SageMaker Spaces, essa função agora será criada automaticamente pelo SageMaker console durante a instalação do complemento Spaces, **sem exigir nenhuma ação do cliente**.
## Configuração de permissão para o AWS kit de ferramentas para acessar espaços SageMaker
Para permitir que o painel lateral do explorador de recursos do AWS VS Code Toolkit descubra e se conecte ao SageMaker Spaces, as seguintes permissões do IAM são necessárias. Essas permissões permitem que o Toolkit liste SageMaker HyperPod clusters disponíveis, recupere detalhes do cluster e obtenha um token de conexão para o cluster Amazon EKS associado.
**Política de IAM necessária**
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SageMakerListClusters",
"Effect": "Allow",
"Action": "sagemaker:ListClusters",
"Resource": "*"
},
{
"Sid": "SageMakerDescribeCluster",
"Effect": "Allow",
"Action": "sagemaker:DescribeCluster",
"Resource": "arn:aws:sagemaker:{{region}}:{{account}}:cluster/cluster-name"
},
{
"Sid": "EksDescribeCluster",
"Effect": "Allow",
"Action": "eks:DescribeCluster",
"Resource": "arn:aws:eks:{{region}}:{{account}}:cluster/cluster-name"
},
{
"Sid": "EksGetToken",
"Effect": "Allow",
"Action": "eks:GetToken",
"Resource": "*"
}
]
}
```
**Recomendações de escopo**
+ Substitua cluster-name pelo (s) SageMaker HyperPod cluster (s) específico (s) que seus usuários precisam acessar.
+ A GetToken ação eks: atualmente não oferece suporte a restrições em nível de recurso e deve usar Resource: “\$1”. Essa é uma limitação AWS do serviço. A autenticação do lado do cliente é realizada por meio de [entradas de acesso do EKS](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html).
# Instale o complemento SageMaker AI Spaces
## Dependências
**Complemento do Amazon EKS Pod Identity Agent**
+ Necessário para que o operador obtenha AWS as credenciais
+ **Normalmente pré-instalado** na maioria dos clusters EKS
+ Instalação: por meio de complementos EKS
**Gerente de certificados**
+ Necessário para o gerenciamento de certificados TLS
+ **Pré-instalado** se estiver usando a criação HyperPod rápida de clusters
+ Instalação: por meio de complementos EKS
**Controlador EBS CSI**
+ Necessário para armazenamento persistente de espaço (volumes do EBS)
+ **Instalado automaticamente** ao usar o SageMaker console para instalar
+ Requer a função do IAM com `AmazonEBSCSIDriverPolicy` permissões HyperPod específicas de \$1
+ Instalação: por meio de complementos do EKS. No entanto, certifique-se de seguir o guia para instalar as permissões adicionais necessárias para HyperPod.
+ Referência: [Usando o driver CSI do Amazon EBS](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-ebs.html) em HyperPod
## Dependências adicionais para o WebUI Access
**AWS Controlador de balanceador de carga**
+ **Pré-instalado** se estiver usando a criação HyperPod rápida de clusters
+ Instalação: Via Helm
+ Guia de instalação manual: [Instalação do AWS Load Balancer Controller](https://docs.aws.amazon.com/eks/latest/userguide/lbc-helm.html)
**DNS externo**
+ Obrigatório ao usar um domínio personalizado para acesso ao WebUI
+ Gerencia registros DNS do Route53 automaticamente
+ Requer a função do IAM com permissões do Route53
+ Instalação: por meio de complementos EKS
## Instalação
Antes de começar, verifique se você tem:
+ Um SageMaker HyperPod cluster ativo com pelo menos um nó de trabalho executando o Kubernetes versão 1.30 ou posterior
+ Pelo menos um nó de trabalho com tipo mínimo de instância (XX vCPU, YY GiB de memória)
### Instalando o complemento Amazon SageMaker Spaces
Você pode instalar o complemento SageMaker Spaces usando a instalação rápida para as configurações padrão ou a instalação personalizada para configuração avançada.
#### Instalação rápida
1. Abra o SageMaker console da Amazon em [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Escolha seu cluster na lista de clusters.
1. Na guia IDE e Notebooks, localize Amazon SageMaker Spaces e escolha Instalação rápida.
Instalação rápida automática:
+ Cria as funções do IAM necessárias para o complemento
+ Ativa o modo de acesso remoto com as funções necessárias do IAM para Systems Manager
+ Instala o complemento e configura a associação de identidade do pod
#### Instalação personalizada
1. Abra o SageMaker console da Amazon em [https://console.aws.amazon.com/sagemaker/](https://console.aws.amazon.com/sagemaker/).
1. Escolha seu cluster na lista de clusters.
1. Na guia IDE e Notebooks, localize Amazon SageMaker Spaces e escolha Instalação personalizada.
1. Configure as seguintes opções:
**Funções do IAM exigidas pelo complemento**
+ Escolha se deseja criar novas funções do IAM com as permissões recomendadas ou usar as existentes com as permissões necessárias (consulte a seção Configuração de permissões do administrador acima)
**Configuração de acesso remoto**
+ Habilite para permitir que os usuários se conectem a espaços do Visual Studio Code local usando o AWS Systems Manager
+ Para a função de instância gerenciada do SSM:
+ **Criar nova função** — O complemento cria e gerencia a função com as permissões necessárias do Systems Manager
+ **Usar a função existente** — Selecione uma função pré-configurada com as permissões necessárias do Systems Manager
+ Certifique-se de que a função de execução do complemento Spaces tenha PassRole permissões para a função de instância gerenciada do SSM
**nota**
A ativação do acesso remoto ativa o nível de instâncias avançadas do AWS Systems Manager para cobranças adicionais por instância. Para obter informações sobre preços, consulte Preços do Systems Manager.
**Configuração de acesso ao navegador da Web**
+ Habilite para permitir que os usuários acessem espaços por meio de um navegador da Web usando certificados DNS e SSL do Route 53
+ **Pré-requisitos:** instalar o AWS Load Balancer Controller antes de ativar o acesso ao navegador
+ **Zona hospedada do Route 53:** selecione uma zona hospedada existente para um domínio ou subdomínio que você possui. O domínio ou subdomínio deve estar registrado e sob seu controle para permitir o gerenciamento de DNS e a validação do certificado SSL.
Para obter mais detalhes sobre o registro de domínio, consulte [Registrando um novo domínio](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-register.html#domain-register-procedure-section) no Route 53 Developer Guide.
+ **Subdomínio:** insira o prefixo do subdomínio (somente alfanumérico e hífens, máximo de 63 caracteres)
+ **Certificado SSL:** selecione um certificado SSL existente no Certificate Manager AWS . O certificado deve ser válido e abranger tanto seu subdomínio (por exemplo, subdomínio.domínio.com) quanto subdomínios curinga (por exemplo, \$1.subdomínio.domínio.com) para oferecer suporte ao acesso individual ao espaço. URLs
+ **Chave de assinatura de token:** selecione uma chave assimétrica AWS KMS para assinatura de token JWT. A chave é usada para criptografar tokens de autenticação para acesso seguro ao WebUI. Você pode criar uma nova chave assimétrica no KMS ou selecionar uma existente à qual sua conta tenha acesso.
**nota**
As cobranças padrão do Route 53 se aplicam a zonas hospedadas e consultas de DNS. Para obter informações sobre preços, consulte Preços do Route 53.
#### Instalação do complemento EKS - Jupyter K8s com WebUI
##### Arquivo de configuração
Crie`addon-config.yaml`:
```
jupyter-k8s:
workspacePodWatching:
enable: true
jupyter-k8s-aws-hyperpod:
clusterWebUI:
enabled: true
domain: ""
awsCertificateArn: ""
kmsEncryptionContext:
enabled: true
traefik:
shouldInstall: true
auth:
kmsKeyId: ""
```
**Substitua os seguintes espaços reservados:**
+ : Seu nome de domínio (por exemplo,`jupyter.example.com`)
+ : O ARN do seu certificado ACM (por exemplo, `arn:aws:acm:us-west-2:111122223333:certificate/12345678-1234-1234-1234-123456789012`
+ : O ARN da sua chave KMS (por exemplo, `arn:aws:kms:us-west-2:111122223333:key/12345678-1234-1234-1234-123456789012`
##### Instalação via AWS CLI
```
aws eks create-addon \
--cluster-name \
--addon-name amazon-sagemaker-spaces \
--configuration-values file://addon-config.yaml \
--resolve-conflicts OVERWRITE \
--region
```
**Para atualizar o complemento existente:**
```
aws eks update-addon \
--cluster-name \
--addon-name amazon-sagemaker-spaces \
--configuration-values file://addon-config.yaml \
--resolve-conflicts OVERWRITE \
--region
```
##### Instalação via Console de gerenciamento da AWS
1. Vá para o **console EKS** → Selecione seu cluster
1. Clique na guia **Complementos** → **Adicionar novo**
1. Selecione o complemento **SageMaker Spaces**
1. Cole a configuração YAML acima em Configurações **opcionais**
1. Clique em **Avançar** e revise as configurações do complemento
1. Clique em **Create (Criar)**
##### Verifique a instalação
```
# Check addon status
aws eks describe-addon \
--cluster-name \
--addon-name amazon-sagemaker-spaces \
--region
```
##### Personalizando atributos do ALB
Por padrão, o complemento cria um balanceador de carga público para uso com a interface do usuário da web. Você pode personalizar os atributos do balanceador de carga usando as propriedades do complemento EKS.
Para criar um ALB interno, defina o esquema como: `internal`
```
jupyter-k8s-aws-hyperpod:
clusterWebUI:
enabled: true
domain: ""
awsCertificateArn: ""
alb:
scheme: "internal" # Default is "internet-facing"
```
Você também pode usar o `alb.annotations` campo para personalizar as configurações do ALB:
```
jupyter-k8s-aws-hyperpod:
clusterWebUI:
enabled: true
domain: ""
awsCertificateArn: ""
alb:
scheme: "internal"
annotations:
alb.ingress.kubernetes.io/security-groups: ""
alb.ingress.kubernetes.io/subnets: ","
alb.ingress.kubernetes.io/load-balancer-attributes: "idle_timeout.timeout_seconds=60"
```
**Anotações ALB comuns:**
+ `alb.ingress.kubernetes.io/security-groups`: Especifique grupos de segurança para o ALB
+ `alb.ingress.kubernetes.io/subnets`: Especifique sub-redes para o ALB
+ `alb.ingress.kubernetes.io/load-balancer-attributes`: defina os atributos do ALB (tempo limite de inatividade, registros de acesso etc.)
Consulte a [documentação do AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/annotations/) para ver todas as anotações disponíveis.
### Atualização/controle de versão do complemento
```
aws eks update-addon \
--cluster-name \
--addon-name amazon-sagemaker-spaces \
--configuration-values file://addon-config.yaml \
--resolve-conflicts OVERWRITE \
--region
```
# 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: -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:
+ `curl`se você quiser usar o desligamento inativo
+ porta 8888
+ acesso remoto
## Requisito de IDE remoto
### Requisito de versão do VS Code
É necessária a versão [v1.90](https://code.visualstudio.com/updates/v1_90) ou posterior do VS Code. Recomendamos usar a [versão mais recente do VS Code](https://code.visualstudio.com/updates).
### Requisitos de sistema operacional
Você precisa de um dos seguintes sistemas operacionais para se conectar remotamente aos espaços do Studio:
+ macOS 13 e posterior
+ Windows 10
+ [O suporte ao Windows 10 termina em 14 de outubro de 2025](https://support.microsoft.com/en-us/windows/windows-10-support-ends-on-october-14-2025-2ca8b313-1946-43d3-b55c-2b95b107f281)
+ Windows 11
+ Linux
+ Instale o [Microsoft VS Code oficial para Linux](https://code.visualstudio.com/docs/setup/linux)
+ não é uma versão de código aberto
### 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.
**nota**
Ambientes com restrições de instalação de software podem impedir que os usuários instalem as dependências necessárias. O AWS Toolkit for Visual Studio Code pesquisa automaticamente essas dependências ao iniciar conexões remotas e solicitará a instalação se alguma estiver faltando. Coordene com seu departamento de TI para garantir que esses componentes estejam disponíveis.
**Dependências locais necessárias**
Sua máquina local deve ter os seguintes componentes instalados:
+ **[https://code.visualstudio.com/docs/remote/ssh](https://code.visualstudio.com/docs/remote/ssh)**
+ — Extensão padrão do VS Code Marketplace para desenvolvimento remoto
+ **[Plugin Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html)** — necessário para o gerenciamento seguro de sessões
+ **Cliente SSH** — Componente padrão na maioria das máquinas (o [OpenSSH é recomendado para Windows](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse))
+ **[https://code.visualstudio.com/docs/configure/command-line](https://code.visualstudio.com/docs/configure/command-line)**
+ Normalmente incluído na instalação do VS Code
**Requisitos específicos da plataforma**
+ **Usuários do Windows** — PowerShell 5.1 ou posterior é necessário para conexões de terminal SSH
**Requisitos de conectividade de rede**
Sua máquina local deve ter acesso à rede aos [endpoints do Session Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html). Por exemplo, no Leste dos EUA (Norte da Virgínia) (us-east-1), eles podem ser:
+ `[ssm.us-east-1.amazonaws.com](http://ssm.us-east-1.amazonaws.com)`
+ `ssm.us-east-1.api.aws`
+ `[ssmmessages.us-east-1.amazonaws.com](http://ssmmessages.us-east-1.amazonaws.com)`
+ `[ec2messages.us-east-1.amazonaws.com](http://ec2messages.us-east-1.amazonaws.com)`
### Requisitos de imagens
**SageMaker Imagens de distribuição**
Ao usar o SageMaker Distribution com acesso remoto, use o [SageMaker Distribution](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-distribution.html) versão 2.7 ou posterior.
**Imagens personalizadas**
Ao [trazer sua própria imagem (BYOI)](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-updated-byoi.html) com acesso remoto, siga as [especificações personalizadas da imagem](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-updated-byoi-specs.html) e garanta que as seguintes dependências estejam instaladas:
+ `curl`ou `wget` — Obrigatório para baixar AWS CLI componentes
+ `unzip`— Necessário para extrair arquivos de AWS CLI instalação
+ `tar`— Necessário para extração de arquivos
+ `gzip`— Necessário para manipulação de arquivos compactados
### Requisitos de instância
+ **Memória**: 8 GB ou mais.
+ Use instâncias com pelo menos 8 GB de memória. Os tipos de instância a seguir *não* são compatíveis devido à falta de memória (menos de 8 GB): `ml.t3.medium`, `ml.c7i.large`, `ml.c6i.large`, `ml.c6id.large` e `ml.c5.large`. Para obter uma lista mais completa dos tipos de instância, consulte a página de preços [sob demanda do Amazon EC2](https://aws.amazon.com/ec2/pricing/on-demand/)
## 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 <
+ Cada contêiner faz referência a uma imagem.
+ O Kubernetes precisa baixar cada imagem antes de iniciar o contêiner.
+ Quando o pod é executado em cada nó, as imagens são armazenadas em cache localmente.
+ Qualquer carga de trabalho usando essas imagens agora começa muito mais rápido.
## 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 do volume de armazenamento. Isso pode levar a falhas de agendamento se a capacidade do cluster existir, mas não na AZ correta.
## Armazenamento adicional
SageMaker O Spaces oferece suporte à anexação de volumes de armazenamento adicionais, como Amazon EFS, FSx for Lustre ou S3 Mountpoint, aos seus espaços de desenvolvimento. Isso permite que você acesse conjuntos de dados compartilhados, colabore em projetos ou use armazenamento de alto desempenho para suas cargas de trabalho.
### Pré-requisitos
Antes de anexar armazenamento adicional aos espaços, você deve:
1. **Instale o complemento de driver CSI apropriado por meio de complementos** [EKS (](https://docs.aws.amazon.com/eks/latest/userguide/workloads-add-ons-available-eks.html)Amazon EFS CSI Driver, Amazon for Lustre CSI Driver ou Mountpoint FSx for Amazon S3 CSI Driver)
1. **Configure os recursos de armazenamento e PersistentVolumeClaims** siga a documentação do driver CSI para seu tipo de armazenamento específico
1. **Verifique se o PVC está disponível** no mesmo namespace em que você planeja criar seu espaço
### Anexando armazenamento aos espaços
Depois de PersistentVolumeClaim configurar, você pode anexá-lo a um espaço usando a HyperPod CLI ou o kubectl.
**HyperPod CLI**
```
hyp create hyp-space \
--name my-space \
--display-name "My Space with FSx" \
--memory 8Gi \
--volume name=shared-fsx,mountPath=/shared,persistentVolumeClaimName=my-fsx-pvc
```
**kubectl**
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
name: my-space
spec:
displayName: "My Space with FSx"
desiredStatus: Running
volumes:
- name: shared-fsx
mountPath: /shared
persistentVolumeClaimName: my-fsx-pvc
```
### Vários volumes
Você pode anexar vários volumes de armazenamento adicionais a um único espaço especificando vários `--volume` sinalizadores com a CLI ou várias entradas na matriz com kubectl. `volumes`
**HyperPod CLI**
```
hyp create hyp-space \
--name my-space \
--display-name "My Space with Multiple Storage" \
--memory 8Gi \
--volume name=shared-efs,mountPath=/shared,persistentVolumeClaimName=my-efs-pvc \
--volume name=datasets,mountPath=/datasets,persistentVolumeClaimName=my-s3-pvc
```
**kubectl**
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
name: my-space
spec:
displayName: "My Space with Multiple Storage"
desiredStatus: Running
volumes:
- name: shared-efs
mountPath: /shared
persistentVolumeClaimName: my-efs-pvc
- name: datasets
mountPath: /datasets
persistentVolumeClaimName: my-s3-pvc
```
## Configuração de recursos
SageMaker O Spaces permite que você configure recursos computacionais para seus ambientes de desenvolvimento, incluindo recursos de CPU, memória e GPU para atender aos seus requisitos de carga de trabalho.
### Configuração de GPU
SageMaker O Spaces suporta alocação total de GPU e particionamento de GPU usando a tecnologia NVIDIA Multi-Instance GPU (MIG). Isso permite otimizar a utilização da GPU para diferentes tipos de cargas de trabalho de aprendizado de máquina.
#### Alocação completa de GPU
**HyperPod CLI**
```
hyp create hyp-space \
--name gpu-space \
--display-name "GPU Development Space" \
--image public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu \
--memory 16Gi \
--gpu 1 \
--gpu-limit 1
```
**kubectl**
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
name: gpu-space
spec:
displayName: "GPU Development Space"
image: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
desiredStatus: Running
resources:
requests:
memory: "16Gi"
nvidia.com/gpu: "1"
limits:
memory: "16Gi"
nvidia.com/gpu: "1"
```
#### Particionamento de GPU (MIG)
O particionamento de GPU usando a tecnologia NVIDIA Multi-Instance GPU (MIG) permite particionar uma única GPU em instâncias menores e isoladas. Seu HyperPod cluster deve ter nós de GPU que suportem MIG e tenham perfis MIG configurados. Para obter mais informações sobre como configurar o MIG em seu HyperPod cluster, consulte [Particionamento de GPU](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-gpu-partitioning-setup.html) usando o NVIDIA MIG.
**HyperPod CLI**
```
hyp create hyp-space \
--name mig-space \
--display-name "MIG GPU Space" \
--image public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu \
--memory 8Gi \
--accelerator-partition-type mig-3g.20gb \
--accelerator-partition-count 1
```
**kubectl**
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
name: mig-space
spec:
displayName: "MIG GPU Space"
image: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu"
desiredStatus: Running
resources:
requests:
memory: "8Gi"
nvidia.com/mig-3g.20gb: "1"
limits:
memory: "8Gi"
nvidia.com/mig-3g.20gb: "1"
```
## 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 um 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/](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/). 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
+ **path** - caminho HTTP para solicitar
+ **porta** - Número ou nome da porta
+ **esquema** - HTTP ou HTTPS (padrão: HTTP)
### 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 de`idleShutdownOverrides`:
**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](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, o Spaces não será atualizado ou iniciado.
## 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"
```
# Adicione usuários e configure contas de serviço
## Controle de acesso refinado - nossa recomendação
Os usuários são diferenciados com base no nome de usuário do Kubernetes. O nome de usuário do Kubernetes do usuário é definido em sua entrada de acesso. Para garantir que dois usuários humanos tenham nomes de usuário distintos, há duas opções:
1. Recomendado - Vários usuários humanos podem usar a mesma função, desde que cada um tenha seu próprio nome de sessão distinto que persistirá entre as sessões. Por padrão, os nomes de usuário do Kubernetes para funções do IAM estão no formato. `arn:aws:sts::{ACCOUNT_ID}:assumed-role/{ROLE_NAME}/{SESSION_NAME}` Com esse padrão, os usuários já serão diferenciados pelo nome da sessão. Um administrador tem algumas maneiras de impor nomes de sessão exclusivos por usuário.
+ Login SSO - Os usuários que usam o login SSO terão, por padrão, um nome de sessão vinculado ao nome de usuário AWS
+ Serviço central de venda de credenciais - Para clientes corporativos, eles podem ter algum serviço interno de venda automática de credenciais para o qual os usuários possam ligar para obter credenciais com sua identidade.
+ Aplicação baseada em funções — Exija que os usuários do IAM definam seu nome de sessão `aws:username` como função ao assumirem uma função do IAM em sua Conta da AWS. A documentação sobre como fazer isso está aqui: [https://aws.amazon.com/blogs/easily-control-naming-individualsegurança/](https://aws.amazon.com/blogs/security/easily-control-naming-individual-iam-role-sessions/) -/iam-role-sessions
1. Se dois cientistas de dados estiverem usando entradas de acesso diferentes (função ou usuário do IAM diferente), eles sempre serão contados como usuários diferentes.
**Criando entrada de acesso**
Política de IAM necessária para a função de cientista de dados:
+ `eks:DescribeCluster`
Políticas de entrada de acesso necessárias
+ `AmazonSagemakerHyperpodSpacePolicy`- com escopo para o namespace DS deve criar espaços em
+ `AmazonSagemakerHyperpodSpaceTemplatePolicy`- com escopo definido para o namespace “jupyter-k8s-shared”
## Espaços públicos e privados
Oferecemos suporte a dois tipos de padrões de compartilhamento: “Público” e “OwnerOnly”. Os campos “AccessType” e “OwnershipType” usam esses dois valores.
+ AccessType: os espaços públicos podem ser acessados por qualquer pessoa com permissões no namespace, mas só OwnerOnly podem ser acessados pelo criador do espaço e pelos usuários administradores. Os usuários administradores são definidos com os seguintes critérios:
+ OwnershipType: os espaços públicos podem ser modified/deleted de qualquer pessoa com permissões no namespace, OwnerOnly do criador ou do administrador. modified/deleted
Os usuários administradores são definidos por:
1. Parte do grupo `system:masters` Kubernetes
1. Parte do grupo Kubernetes definido na variável de ambiente CLUSTER\$1ADMIN\$1GROUP no gráfico do leme.
Os grupos de um usuário podem ser configurados usando entradas de acesso do EKS. Um espaço pode ser definido como “Público” ou “OwnerOnly” configurando a especificação no objeto:
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
labels:
app.kubernetes.io/name: jupyter-k8s
name: example-workspace
spec:
displayName: "Example Workspace"
image: "public.ecr.aws/sagemaker/sagemaker-distribution:3.4.2-cpu"
desiredStatus: "Running"
ownershipType: "Public"/"OwnerOnly"
accessType: "Public"/"OwnerOnly"
# more fields here
```
# Limites
Os espaços são executados como pods em nós HyperPod EKS com volumes EBS anexados. O número de espaços que podem ser implantados por nó é limitado pelos limites da AWS infraestrutura.
**Limites de volume do EBS por nó**
Referência: [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/volume\$1limits.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/volume_limits.html)
Os nós do EC2 têm um número máximo de volumes do EBS que podem ser conectados. Como cada espaço normalmente usa um volume do EBS, isso limita quantos espaços com armazenamento dedicado do EBS podem ser executados em um único nó.
**Máximo de pods por HyperPod nó**
Referência: [https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker- hyperpod-eks-prerequisites .html](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-prerequisites.html)
Cada tipo de HyperPod instância é compatível com um número máximo de pods com base nos endereços IP disponíveis do plug-in VPC CNI. Como cada espaço é executado como um pod, isso limita diretamente o número de espaços por nó.
**Impacto**
O limite efetivo de espaços por nó é a restrição atingida primeiro.
# Governança de tarefas para espaços interativos em HyperPod
Esta seção aborda como otimizar seus clusters compartilhados do Amazon SageMaker HyperPod EKS para cargas de trabalho do Interactive Spaces. Você aprenderá a configurar os recursos de governança de tarefas da Kueue, incluindo gerenciamento de cotas, agendamento de prioridades e políticas de compartilhamento de recursos, para garantir que suas cargas de trabalho de desenvolvimento sejam executadas sem interrupção, mantendo uma alocação justa nas atividades de treinamento, avaliação e processamento em lote de suas equipes.
## Como funciona o gerenciamento interativo do espaço
Para gerenciar com eficácia os espaços interativos em clusters HyperPod EKS compartilhados, implemente as seguintes estratégias de governança de tarefas usando os recursos existentes da Kueue.
**Configuração de classes prioritárias**
Defina classes prioritárias dedicadas para espaços interativos com pesos altos (como 100) para garantir que os pods de desenvolvimento sejam admitidos e programados antes de outros tipos de tarefas. Essa configuração permite que o Interactive Spaces antecipe trabalhos de menor prioridade durante o carregamento do cluster, o que é essencial para manter fluxos de trabalho de desenvolvimento ininterruptos.
**Dimensionamento e alocação de cotas**
Reserve recursos computacionais suficientes na sua equipe ClusterQueue para lidar com as cargas de trabalho de desenvolvimento esperadas. Durante os períodos em que os recursos de desenvolvimento estão ociosos, os recursos de cota não utilizados podem ser alocados temporariamente para as tarefas de outras equipes. Quando a demanda de desenvolvimento aumenta, esses recursos emprestados podem ser recuperados para priorizar os módulos pendentes do Interactive Space.
**Estratégias de compartilhamento de recursos**
Escolha entre duas abordagens de compartilhamento de cotas com base em seus requisitos:
*Controle estrito de recursos*: desative o empréstimo e o empréstimo de cotas para garantir que a capacidade computacional reservada esteja sempre disponível para seus espaços interativos. Essa abordagem requer cotas de dimensionamento grandes o suficiente para lidar de forma independente com a demanda de pico de desenvolvimento e pode resultar em nós ociosos durante períodos de baixo uso.
*Compartilhamento flexível de recursos*: habilite o empréstimo de cotas para permitir que outras equipes utilizem recursos de desenvolvimento ociosos quando necessário. No entanto, desative o empréstimo para garantir que os Espaços Interativos nunca funcionem com recursos emprestados e recuperáveis que possam levar a despejos inesperados.
**Preempção dentro da equipe**
Ative a preempção dentro da equipe ao executar cargas de trabalho mistas (treinamento, avaliação e espaços interativos) sob a mesma cota. Isso permite que a Kueue antecipe trabalhos de baixa prioridade em sua equipe para acomodar pods do Interactive Space de alta prioridade, garantindo que o trabalho de desenvolvimento possa prosseguir sem depender do empréstimo de cotas externas.
## Exemplo de configuração do Interactive Space
O exemplo a seguir mostra como a Kueue gerencia recursos computacionais para Interactive Spaces em um cluster compartilhado da Amazon. SageMaker HyperPod
**Configuração de cluster e configuração de políticas**
Seu cluster tem a seguinte configuração:
+ *Team Alpha (Dev Team)*: cota de 8 CPUs para Interactive Spaces
+ *Team Beta (ML Team)*: cota de 16 CPUs para treinamento e avaliação
+ *Team Gamma (Research)*: cota de 6 CPUs para experimentação
+ *Provisionamento estático*: sem ajuste de escala automático
+ *Capacidade total*: 30 CPUs
O pool de CPU compartilhada usa esta política de prioridade:
+ *Espaços interativos*: Prioridade 100
+ *Treinamento*: prioridade 75
+ *Avaliação*: prioridade 50
+ *Processamento em lote*: Prioridade 25
Kueue impõe cotas de equipe e classes prioritárias, com a preempção ativada e o empréstimo desativado para a equipe de desenvolvimento.
**Estado inicial: utilização normal do cluster**
Em operações normais:
+ *Team Alpha*: executa 6 espaços interativos usando 6 CPUs, 2 CPUs inativos
+ *Team Beta*: executa trabalhos de treinamento (12 CPUs) e avaliação (4 CPUs) dentro de sua cota de 16 CPUs
+ *Team Gamma*: executa cargas de trabalho de pesquisa em todos os 6 CPUs
+ *Compartilhamento de recursos*: a equipe Beta empresta os 2 inativos do Team Alpha CPUs para treinamento adicional
**Pico de desenvolvimento: o Team Alpha requer recursos adicionais**
Quando os desenvolvedores do Team Alpha precisam ampliar o trabalho de desenvolvimento, os pods adicionais do Interactive Space exigem mais CPUs 4. O Kueue detecta que os novos pods:
+ Dentro do namespace do Team Alpha
+ Prioridade 100 (espaços interativos)
+ Têm admissão pendente devido a restrições de cota.
**Processo de resposta de Kueue**
O Kueue segue um processo de três etapas para alocar recursos:
1. **Verificação de cota**
Pergunta: O Team Alpha tem uma cota não utilizada?
+ *Uso atual*: 6 CPUs usados, 2 CPUs disponíveis
+ *Novo requisito*: 4 CPUs necessários
+ *Resultado*: cota insuficiente → Prossiga para a Etapa 2
1. **Autopreempção dentro do Team Alpha**
Pergunta: Os trabalhos de menor prioridade do Team Alpha podem ser evitados?
+ *Alvos disponíveis*: Não há trabalhos de baixa prioridade no Team Alpha
+ *Resultado*: Nenhuma preempção possível → Prossiga para a Etapa 3
1. **Recupere recursos emprestados**
Pergunta: Os recursos do Team Alpha estão sendo emprestados por outras equipes?
+ *Recursos emprestados*: Equipe Beta usando 2 CPUs da Equipe Alpha
+ *Ação*: Kueue despeja os módulos de treinamento emprestados da Equipe Beta, liberando 2 CPUs
+ *Necessidade restante*: Ainda precisa de mais 2 CPUs → Os espaços interativos permanecem no NotAdmitted estado até que os recursos estejam disponíveis
Essa abordagem prioriza os Espaços Interativos, mantendo os limites das cotas da equipe e evitando que o trabalho de desenvolvimento seja executado com recursos emprestados instáveis.
# Observabilidade
## Monitoramento padrão do Kubernetes
Você pode monitorar o Spaces usando ferramentas padrão do Kubernetes, como `kubectl` descrição e registros. `kubectl`
**Monitorando o status do espaço**
```
# List all Spaces with status
kubectl get workspace -A
# Get detailed information about a specific Space
kubectl describe workspace
```
**Visualizando registros de espaço**
```
# View workspace container logs
kubectl logs -l workspace.jupyter.org/workspace-name= -c workspace
# View SSM agent sidecar logs (for remote IDE connectivity)
kubectl logs -l workspace.jupyter.org/workspace-name= -c ssm-agent-sidecar
# Follow logs in real-time
kubectl logs -l workspace.jupyter.org/workspace-name= -c workspace -f
```
**Entendendo as condições do espaço**
Os espaços relatam quatro tipos de condições em seus status:
+ **Disponível**: `True` quando o Space estiver pronto para uso. Todos os recursos necessários (pods, serviços, armazenamento) estão funcionando e em bom estado.
+ **Progredindo**: `True` quando o Espaço está sendo criado, atualizado ou reconciliado. Transições para `False` uma vez estável.
+ **Degradado**: `True` quando erros são detectados com os recursos do Space. Verifique a mensagem de condição para obter detalhes.
+ **Parado**: `True` quando o status Espaço desejado é definido como`Stopped`. Os pods são encerrados, mas o armazenamento e a configuração são preservados.
## CloudWatch Integração de registros
Você pode instalar o complemento de CloudWatch registro para enviar registros do Space ao Amazon CloudWatch Logs para gerenciamento e retenção centralizados de registros. Isso permite a agregação de registros em vários clusters e a integração com o CloudWatch Insights para consultas e análises. Todos os `kubectl` registros disponíveis acima podem ser consultados CloudWatch com este plug-in.
**Referência: https://docs.aws.amazon.com/sagemaker/** [latest/dg/sagemaker- hyperpod-eks-cluster-observability - cluster-cloudwatch-ci .html.](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-cluster-observability-cluster-cloudwatch-ci.html)
## HyperPod Complemento de observabilidade
O complemento SageMaker HyperPod de observabilidade fornece painéis abrangentes para monitorar a utilização de recursos espaciais. Depois de instalar o complemento, você pode visualizar o uso da memória espacial e da CPU na guia **Tarefas** do HyperPod console, que exibe métricas nos painéis do Amazon Managed Grafana.
**Referência: https://docs.aws.amazon.com/sagemaker/** [latest/dg/sagemaker- hyperpod-observability-addon .html](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-observability-addon.html)
**Principais métricas disponíveis:**
+ Utilização de CPU e memória por espaço
+ Métricas de GPU (se aplicável)
# Crie e gerencie espaços
Os cientistas de dados podem listar para visualizar todos os espaços aos quais têm acesso, criar um espaço usando um dos modelos, atualizar o espaço para atualizar a imagem, o sistema de arquivos e outros atributos da configuração do espaço e excluir um espaço. Como pré-requisito, os clientes devem instalar a HyperPod CLI ou usar o kubectl para criar e gerenciar espaços. [Para obter mais detalhes sobre a HyperPod CLI, consulte isso.](https://github.com/aws/sagemaker-hyperpod-cli/blob/main/README.md#space) Para usar os comandos kubectl, consulte [este guia](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) para instalar o kubectl.
## Criar espaço
**HyperPod CLI**
Crie um espaço Jupyter
```
hyp create hyp-space \
--name myspace \
--display-name "My Space" \
--memory 8Gi \
--template-ref name=sagemaker-jupyter-template,namespace=jupyter-k8s-system
```
Crie um espaço de editor de código
```
hyp create hyp-space \
--name myspace \
--display-name "My Space" \
--memory 8Gi \
--template-ref name=sagemaker-code-editor-template,namespace=jupyter-k8s-system
```
**kubectl**
```
kubectl apply -f - <
**HyperPod CLI**
```
hyp list hyp-space
```
**kubectl**
```
kubectl get workspaces -n
```
## Descreva um espaço
**HyperPod CLI**
```
hyp describe hyp-space --name myspace
```
**kubectl**
```
# Basic Status reporting
kubectl get workspace my-workspace -n
# Enhanced Workspace Information Retrieval
kubectl get workspace my-workspace -n -o wide
# Complete Workspace Information Retrieval
kubectl get workspace my-workspace -n -o json
kubectl get workspace my-workspace -n -o yaml
```
## Atualizar um espaço
**HyperPod CLI**
```
hyp update hyp-space \
--name myspace \
--display-name "Updated My Space"
```
**kubectl**
Atualize o arquivo YAML original do espaço de trabalho conforme necessário e aplique-o novamente. Certifique-se de que o nome dos metadados não tenha sido modificado. Você também pode usar esses comandos kubectl para modificar campos sem reaplicar todo o espaço de trabalho yaml:
```
# Open a Terminal IDE and modify the Workspace
kubectl edit workspace -n
# Patch a Workspace
kubectl patch workspace --type='merge' -p \
'{"spec":{"":""}}' -n
```
## Iniciar/parar um espaço
**HyperPod CLI**
```
hyp start hyp-space --name myspace
hyp stop hyp-space --name myspace
```
**kubectl**
Você pode atualizar o campo de status desejado no espaço de trabalho para start/stop um espaço.
```
# Start a Workspace
kubectl patch workspace --type='merge' -p \
'{"spec":{"desiredStatus":"Running"}}' -n
# Stop a Workspace
kubectl patch workspace --type='merge' -p \
'{"spec":{"desiredStatus":"Stopped"}}' -n
```
## Obtenha registros
**HyperPod CLI**
```
hyp get-logs hyp-space --name myspace
```
**kubectl**
```
# Check Pod Logs
kubectl logs -l workspace.jupyter.org/workspace-name=
# Check Pod Events
kubectl describe pod -l workspace.jupyter.org/workspace-name=
# Check Operator Logs
kubectl logs -n jupyter-k8s-system deployment/jupyter-k8s-controller-manager
```
## Excluir um espaço
**HyperPod CLI**
```
hyp delete hyp-space --name myspace
```
**kubectl**
```
# Delete a Workspace
kubectl delete workspace -n
```
# Acesso pelo navegador da web
O acesso à interface de usuário da Web permite que você se conecte diretamente aos espaços de desenvolvimento em execução no seu SageMaker HyperPod cluster por meio de uma interface segura de navegador da Web. Isso fornece acesso imediato ao Jupyter Lab e a outros ambientes de desenvolvimento baseados na web sem a necessidade de instalação de software local.
## Pré-requisitos
Antes de configurar o acesso à interface de usuário da web, certifique-se de ter concluído o seguinte:
+ SageMaker Instalação do *complemento Spaces: siga a instalação* do [complemento SageMaker Spaces e habilite o acesso à interface web durante a instalação](https://docs.aws.amazon.com/sagemaker/latest/dg/operator-install.html)
+ *Acesso do usuário ao cluster EKS*: os usuários precisam do EKS Access Entry configurado com as permissões apropriadas. Consulte [Adicionar usuários e configurar contas de serviço para obter detalhes de configuração do EKS Access Entry](https://docs.aws.amazon.com/sagemaker/latest/dg/add-user.html)
+ *Espaços de desenvolvimento*: crie e inicie espaços de desenvolvimento em seu HyperPod cluster
+ *kubectl access*: certifique-se de que o kubectl esteja configurado para acessar seu cluster EKS
## Gerar URL de acesso à interface do usuário da Web
**Usando HyperPod CLI**
Se você tiver a HyperPod CLI instalada, poderá usar este comando simplificado:
```
hyp create hyp-space-access --name --connection-type web-ui
```
**Uso do kubectl**
Você também pode usar a linha de `kubectl` comando para criar uma solicitação de conexão.
```
kubectl create -f - -o yaml <
spec:
workspaceName:
workspaceConnectionType: web-ui
EOF
```
O URL está presente na `status.workspaceConnectionUrl` saída desse comando.
## Acessando seu espaço de desenvolvimento
1. *Gere o URL da interface do usuário da web* usando um dos métodos acima
1. *Copie o URL* da resposta
1. *Abra o URL* no seu navegador
1. *Acesse seu ambiente de desenvolvimento* por meio da interface web
## Ambientes de desenvolvimento suportados
A interface de usuário da web fornece acesso a:
+ *Laboratório Jupyter*
+ *Editor de código*
## Solução de problemas
**Não é possível gerar acesso URLs**
Verifique o seguinte:
+ SageMaker O complemento Spaces está em execução: kubectl get pods -n sagemaker-spaces-system
+ O espaço de desenvolvimento está funcionando e saudável
+ O usuário tem as permissões de entrada de acesso EKS apropriadas
# Acesso remoto ao SageMaker Spaces
O acesso remoto permite que você conecte seu Visual Studio Code local diretamente aos espaços de desenvolvimento em execução no seu SageMaker HyperPod cluster. As conexões remotas usam SSM para estabelecer túneis seguros e criptografados entre sua máquina local e os espaços de desenvolvimento.
## Pré-requisitos
Antes de configurar o acesso remoto, verifique se você concluiu o seguinte:
+ *SageMaker Instalação do complemento SageMaker Spaces*[: siga a instalação do complemento Spaces](https://docs.aws.amazon.com/sagemaker/latest/dg/operator-install.html) e ative o acesso remoto durante a instalação (instalação rápida ou instalação personalizada com a configuração de acesso remoto ativada).
+ *Acesso do usuário ao cluster EKS*: os usuários precisam do EKS Access Entry configurado com as permissões apropriadas. Consulte [Adicionar usuários e configurar contas de serviço para obter detalhes de configuração do EKS Access Entry](https://docs.aws.amazon.com/sagemaker/latest/dg/add-user.html)
+ *Espaços de desenvolvimento*: crie e inicie espaços de desenvolvimento em seu HyperPod cluster
+ *kubectl access*: certifique-se de que o kubectl esteja configurado para acessar seu cluster EKS
## Gere conexão remota do VS Code
### Usando a HyperPod CLI
Se você tiver a HyperPod CLI instalada, poderá usar este comando simplificado:
```
hyp create hyp-space-access --name --connection-type vscode-remote
```
### Uso do kubectl
Você também pode usar a linha de `kubectl` comando para criar uma solicitação de conexão.
```
kubectl create -f - -o yaml <
spec:
workspaceName:
workspaceConnectionType: vscode-remote
EOF
```
O URL está presente na `status.workspaceConnectionUrl` saída desse comando.
## Conectando-se com o VS Code
1. Gere o URL de conexão do VS Code usando um dos métodos acima
1. Copie o URL do VS Code da resposta
1. Clique no URL ou cole-o no seu navegador
1. O VS Code solicitará a abertura da conexão remota
1. Confirme a conexão para estabelecer o ambiente de desenvolvimento remoto
## Ambientes de desenvolvimento suportados
A interface de usuário da web fornece acesso a:
+ *Laboratório Jupyter*
+ *Editor de código*
## Solução de problemas
**Não é possível gerar conexão URLs**
*Verifique o seguinte:*
+ SageMaker O complemento Spaces está em execução: kubectl get pods -n sagemaker-spaces-system
+ O espaço de desenvolvimento está funcionando e saudável
+ O acesso remoto foi ativado durante a instalação do complemento
+ O usuário tem as permissões de entrada de acesso EKS apropriadas