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á.

SSH direto

Antes de ativar, revise o seguinte:

Pré-requisitos

O Direct SSH exige DNS externo, uma zona hospedada privada do Amazon Route 53, conectividade VPC das máquinas clientes e (opcionalmente) o controlador do Load Balancer. AWS Para ver a lista completa de pré-requisitos, consulte. Pré-requisitos para o Direct SSH

Se o acesso ao navegador da Web já estiver habilitado em seu cluster, todos os pré-requisitos estarão em vigor. Antes de continuar, verifique se o ExternalDNS está configurado com. --policy=sync Para obter detalhes, consulte Configuração de DNS externo.

Se o acesso ao navegador da Web ainda não estiver configurado, consulte(Opcional) Configurando pré-requisitos. Para obter mais informações sobre como ativar o acesso ao navegador da Web, consulteInstalação do complemento EKS - Jupyter K8s com WebUI.

Configure o Direct SSH para seu cluster

Etapa 1: Adicionar regra de grupo de segurança para SSH

O acesso ao navegador da Web usa HTTPS (443) por meio de um Application Load Balancer (ALB). Como o Direct SSH se conecta diretamente aos IPs do pod na porta configurada, você precisa adicionar uma regra de entrada do grupo de segurança.

Verifique se o grupo de instâncias do seu espaço de trabalho tem uma substituição de SG:

aws sagemaker describe-cluster \
  --cluster-name <HYPERPOD_CLUSTER_NAME> \
  --region <AWS_REGION> \
  --query 'InstanceGroups[*].{Name:InstanceGroupName, OverrideSGs:OverrideVpcConfig.SecurityGroupIds}'

Opção A: O grupo de instâncias tem uma substituição de grupo de segurança

Se não OverrideSGs for nulo, adicione a regra a esse grupo de segurança:

SG_ID=<SG_ID_FROM_OVERRIDE_VPC_CONFIG>
aws ec2 authorize-security-group-ingress \
  --group-id $SG_ID \
  --protocol tcp \
  --port <SSH_PORT> \
  --cidr <SOURCE_CIDR> \
  --region <AWS_REGION>

Opção B: O grupo de instâncias não tem nenhuma substituição de grupo de segurança

Se OverrideSGs for nulo, use o grupo de segurança em nível de cluster da configuração da VPC do SageMaker HyperPod cluster:

SG_ID=$(aws sagemaker describe-cluster --cluster-name <HYPERPOD_CLUSTER_NAME> --region <AWS_REGION> \
  --query 'VpcConfig.SecurityGroupIds[0]' --output text)
aws ec2 authorize-security-group-ingress \
  --group-id $SG_ID \
  --protocol tcp \
  --port <SSH_PORT> \
  --cidr <SOURCE_CIDR> \
  --region <AWS_REGION>

A tabela a seguir mostra onde encontrar cada valor de espaço reservado.

Etapa 2: habilitar o SSH direto

Adicione directSSH à sua configuração adicional junto comclusterWebUI:

jupyter-k8s-aws-hyperpod:
  clusterWebUI:
    enabled: true
    domain: "<DOMAIN_NAME>"
    awsCertificateArn: "<ACM_CERTIFICATE_ARN>"
    traefik:
      shouldInstall: true
  directSSH:
    enabled: true
    port: <SSH_PORT>          # default: 22
    domain: "<ROUTE53_HOSTED_ZONE_DOMAIN>"

A tabela a seguir mostra onde encontrar cada valor de espaço reservado.

Atualize o complemento:

aws eks update-addon \
  --cluster-name <CLUSTER_NAME> \
  --addon-name amazon-sagemaker-spaces \
  --configuration-values file://addon-config.yaml \
  --resolve-conflicts OVERWRITE \
  --region <AWS_REGION>

Para desativar o Direct SSH, consulteRevogando o acesso direto ao SSH.

Etapa 3: Verificar se o Direct SSH está ativo

# Check addon status
aws eks describe-addon \
  --cluster-name <CLUSTER_NAME> \
  --addon-name amazon-sagemaker-spaces \
  --region <AWS_REGION>

# Check headless services created for workspaces
kubectl get svc -l app.kubernetes.io/component=direct-ssh

# Verify DNS record resolves (from within VPC)
dig <workspace-name>.<namespace>.<ROUTE53_HOSTED_ZONE_DOMAIN>

Conecte-se ao seu espaço de trabalho usando o Direct SSH

Use os procedimentos a seguir para se conectar ao seu espaço de trabalho usando o Direct SSH, gerenciar suas chaves SSH e solucionar problemas de conexão.

Como funciona a autenticação SSH

O Direct SSH usa autenticação de chave pública padrão. Cada usuário gera seu próprio par de chaves SSH e adiciona a chave pública ao seu espaço de trabalho. As chaves privadas nunca saem da máquina do usuário.

A seguir estão os principais fatos sobre o acesso SSH:

Etapa 1: gerar uma chave SSH na sua máquina cliente

Execute este comando uma vez para criar seu par de chaves:

ssh-keygen -t ed25519 -f ~/.ssh/my-workspace-key

Isso cria:

Etapa 2: adicione sua chave pública ao seu espaço de trabalho

Use um dos métodos a seguir para adicionar sua chave pública. Você não precisa fazer as duas coisas.

Adicione sua chave por meio do acesso ao navegador da web

Adicione sua chave por meio do kubectl

POD=$(kubectl get pods -n <namespace> -l workspace.jupyter.org/workspace-name=<space-name> \
  -o jsonpath='{.items[0].metadata.name}')
cat ~/.ssh/my-workspace-key.pub | kubectl exec -n <namespace> -i $POD -c workspace -- \
  bash -c "cat >> /home/sagemaker-user/.ssh/authorized_keys"

Etapa 3: conecte-se ao seu espaço de trabalho usando SSH

ssh -p <SSH_PORT> -i ~/.ssh/my-workspace-key sagemaker-user@<space-name>.<namespace>.<domain>

Exemplo:

ssh -p 2222 -i ~/.ssh/my-workspace-key sagemaker-user@my-space.default.spaces.example.com

Etapa 4: configurar o SSH para facilitar o acesso

Essa etapa opcional simplifica as conexões futuras. Adicione o seguinte ao ~/.ssh/config:

Host my-space
    HostName <space-name>.<namespace>.<domain>
    Port <SSH_PORT>
    User sagemaker-user
    IdentityFile ~/.ssh/my-workspace-key
    ServerAliveInterval 15
    ServerAliveCountMax 3

PortDefina como a porta que seu administrador configurou. Você pode omitir essa linha se o Direct SSH usar a porta padrão (22). Em seguida, conecte-se com: ssh my-space

Etapa 5: Conectar um IDE remoto

Depois que o Direct SSH funcionar a partir do seu terminal (Etapa 3), qualquer IDE Remote-SSH compatível se conecta usando a mesma ~/.ssh/config entrada. Você não precisa de AWS configuração adicional para essa conexão.

Instale a Remote-SSH extensão

Conecte-se a partir do IDE

Gerenciamento e revogação de chaves

Você gerencia suas chaves SSH. As chaves SSH são credenciais de longa duração sem expiração automática. Uma chave em authorized_keys concede acesso ao seu espaço de trabalho até que você a remova explicitamente.

Para girar sua chave

Recomendamos que você gire suas chaves periodicamente.

Se sua chave privada estiver comprometida

Aja imediatamente. Uma chave comprometida concede acesso total ao espaço de trabalho até que você a remova. authorized_keys

Práticas recomendadas

Revogando o acesso direto ao SSH

Para evitar deixar uma regra de grupo de segurança aberta depois de desativar o Direct SSH, conclua as três etapas em ordem. Não pule a Etapa 2.

Etapa 1: Desativar no gráfico do Helm

Remova totalmente a directSSH seção do arquivo de configuração do complemento. O Helm usa como padrão false quando directSSH.enabled a chave está ausente:

jupyter-k8s-aws-hyperpod:
  clusterWebUI:
    enabled: true
    domain: "<DOMAIN_NAME>"
    ...
  # directSSH section removed

Como alternativa, defina explicitamente: enabled: false

directSSH:
  enabled: false

Etapa 2: remover a regra de entrada do grupo de segurança

# Find the rule ID
aws ec2 describe-security-group-rules \
  --filters Name=group-id,Values=<SG_ID> \
  --query 'SecurityGroupRules[?IpProtocol==`tcp` && FromPort==`<SSH_PORT>`].[SecurityGroupRuleId,CidrIpv4]' \
  --output table \
  --region <AWS_REGION>

# Remove the rule
aws ec2 revoke-security-group-ingress \
  --group-id <SG_ID> \
  --security-group-rule-ids <RULE_ID> \
  --region <AWS_REGION>

Etapa 3: aplicar ao cluster

aws eks update-addon \
  --cluster-name <CLUSTER_NAME> \
  --addon-name amazon-sagemaker-spaces \
  --configuration-values file://addon-config.yaml \
  --resolve-conflicts OVERWRITE \
  --region <AWS_REGION>

A execução desse comando remove os serviços headless de todos os espaços de trabalho. O ExternalDNS então exclui os registros do Route 53 A em aproximadamente 30 segundos. Depois que o ExternalDNS remove os registros, novas conexões SSH não podem mais resolver o nome do host do espaço de trabalho.

O que acontece após a revogação

Solução de problemas

(Opcional) Configurando pré-requisitos

Use esta seção somente se o acesso ao navegador da Web ainda não estiver habilitado ou para verificar ou atualizar sua configuração de DNS externo.

Instalando do zero

Se o acesso ao navegador da Web ainda não estiver configurado, você precisará do seguinte antes de ativar o Direct SSH:

Para ver as dependências adicionais e as etapas de configuração de acesso ao navegador da Web, consulteInstale o SageMaker AI Spaces Add-on.

AWS Controlador de balanceador de carga: requisito de HyperPod vPCid

A documentação padrão AWS de instalação do Load Balancer Controller não menciona o vpcId parâmetro. Em HyperPod clusters, a omissão vpcId faz com que a instalação falhe. Você deve fornecê-lo explicitamente.

Obtenha seu ID de VPC:

aws sagemaker describe-cluster \
  --cluster-name <HYPERPOD_CLUSTER_NAME> \
  --region <AWS_REGION> \
  --query 'VpcConfig.VpcId' \
  --output text

Instale com os HyperPod parâmetros necessários:

helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
  -n kube-system \
  --set clusterName=<EKS_CLUSTER_NAME> \
  --set serviceAccount.create=false \
  --set serviceAccount.name=aws-load-balancer-controller \
  --set enableServiceMutatorWebhook=false \
  --set vpcId=<VPC_ID>

Crie a conta de serviço (aws-load-balancer-controller) com a anotação de função do IAM apropriada antes de executar esse comando. Para obter mais informações sobre a política do IAM e as etapas de criação da conta de serviço, consulte a configuração do Amazon EKS Load Balancer Controller IRSA no Guia do usuário do Amazon EKS.

Configuração de DNS externo

O ExternalDNS sincroniza os serviços do Kubernetes com os provedores de DNS. Configure o ExternalDNS com as seguintes configurações ao usá-lo com o Amazon Route 53 em um ambiente de produção.

Por padrão, o ExternalDNS usa. --policy=upsert-only Isso cria e atualiza registros DNS, mas nunca os exclui. Quando você exclui um espaço de trabalho, os registros A e TXT no Amazon Route 53 permanecem como entradas obsoletas.

Use --policy=upsert-only somente para testes e altere --policy=sync para produção. Você também deve definir o --txt-owner-id sinalizador, que informa ao ExternalDNS quais registros ele possui e quais registros excluir na limpeza.

Configure sua implantação de DNS externo com os seguintes argumentos:

--provider=aws
--source=service                          # watches Services (required for headless Services)
--domain-filter=<ROUTE53_HOSTED_ZONE>     # restricts ExternalDNS to your hosted zone only
--policy=sync                             # enables deletion of stale records on space deletion
--txt-owner-id=<CLUSTER_NAME>             # identifies which records this ExternalDNS instance owns

Nos argumentos anteriores, substitua os seguintes valores:

Para verificar sua política atual de ExternalDNS, execute o seguinte comando:

kubectl get deployment -n kube-system external-dns \
  -o jsonpath='{.spec.template.spec.containers[0].args}' | tr ',' '\n' | grep -E 'policy|owner|source|domain'