Ejecutar IDEs interactivas en EKS con SageMaker AI Spaces

SageMaker AI Spaces para Amazon EKS permite ejecutar entornos interactivos como JupyterLab y Code Editor dentro del mismo clúster que hospeda sus pipelines. Esto mantiene acceso a nodos GPU, almacenamiento compartido e IAM, reduciendo tiempos de despliegue y costos.

Por Redaccion TD
Ejecutar IDEs interactivas en EKS con SageMaker AI Spaces

Resumen

Los científicos de datos y equipos de ML frecuentemente necesitan IDEs interactivas (p. ej. JupyterLab o Code Editor) para explorar datos, depurar y desarrollar modelos. Tradicionalmente estos entornos se ejecutan fuera del clúster que aloja las cargas de entrenamiento —en JupyterHub independiente o en la laptop local— perdiendo acceso directo a nodos GPU, almacenamiento compartido y a los roles IAM que usan los pipelines.

El complemento SageMaker AI Spaces para Amazon EKS soluciona esta brecha: permite lanzar entornos JupyterLab y Code Editor administrados directamente sobre el clúster EKS que ya operan. Mientras que preparar un JupyterHub con acceso a GPU, almacenamiento y autenticación puede tomar a un equipo de plataforma entre 3 y 5 días, con el add-on un científico de datos puede levantar un Space totalmente configurado en alrededor de 5 minutos.

Por qué importa para equipos en América Latina

En muchas organizaciones latinoamericanas, la infraestructura es más limitada y compartir recursos es crucial para optimizar costos. Consolidar notebooks y cargas de entrenamiento en un solo clúster puede mejorar la utilización de GPU —AWS reporta que esto puede aumentar la ocupación hasta en un 30% comparado con flotas dedicadas de notebooks— y evita mantener entornos GPU siempre activos que pueden costar miles de dólares al mes. Además, simplificar la autenticación y el acceso reduce la carga operacional de equipos de plataforma con recursos reducidos.

Arquitectura de la solución (visión general)

La implementación típica se organiza en tres capas:

  • Red y acceso: Amazon Route 53 resuelve un dominio comodín hacia un Application Load Balancer (ALB) público con TLS gestionado por AWS Certificate Manager (ACM). Para VS Code, AWS Systems Manager (SSM) establece túneles directos hacia los pods de Space.
  • Enrutamiento en el clúster: el AWS Load Balancer Controller provisiona el ALB; Traefik enruta por hostname y un middleware de autenticación valida tokens JWT usando AWS KMS para el cifrado de esos tokens.
  • Cómputo y almacenamiento: los pods de Space corren en workers en subredes privadas; el controlador CSI de Amazon EBS proporciona volúmenes persistentes; para almacenamiento compartido se usan Amazon EFS o Amazon FSx. EKS Pod Identity otorga roles IAM con alcance a los pods.

Consolidar entornos interactivos y de entrenamiento en un mismo clúster hace que los nodos GPU se mantengan ocupados entre trabajos y reduce costos operativos.

Requisitos previos

Antes de empezar necesita:

  • Cuenta AWS y AWS CLI 2.x configurado para la región objetivo.
  • kubectl 1.30 o posterior y Helm v3.
  • Una zona hospedada pública de Route 53 para un dominio que usted controle (referido como <YOUR_DOMAIN> en la documentación).
  • Permisos IAM para crear roles, políticas, add-ons de EKS, entradas DNS, asociaciones de Pod Identity, certificados ACM y claves KMS.
  • La versión del add-on Spaces debe ser 0.1.4 o posterior (versiones anteriores solo soportaban SageMaker HyperPod).

También tenga en cuenta que esta guía crea recursos que generan cargos: un ALB público, volúmenes EBS y un clúster EKS. El nivel “SSM advanced-instances” agrega alrededor de $0.00695/hr por Space pod. Siga la sección de limpieza al final.

Pasos clave (resumen operativo)

  1. Variables comunes

    Defina variables reutilizables para el nombre del clúster, la región y el ID de cuenta. Ejemplo:

    export CLUSTER_NAME=<CLUSTER_NAME>
    export REGION=<REGION>
    export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
  2. Política de confianza para Pod Identity

    Todas las roles IAM que el post usa son asumidas por cuentas de servicio de Kubernetes mediante EKS Pod Identity, por eso comparten una política de confianza. Guarde y reutilice esta política:

    cat > pod-identity-trust.json <<'EOF'
    { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": ["sts:AssumeRole", "sts:TagSession"] }]
    }
    EOF
  3. Crear o validar el clúster EKS

    Siga la guía de inicio de EKS, pero cumpla requisitos específicos para Spaces:

    • Desactivar EKS Auto Mode (el add-on requiere nodos clásicos EC2 en Kubernetes 1.30 o posterior).
    • Usar una VPC con subredes públicas y privadas en al menos dos zonas de disponibilidad, con un gateway NAT para las subredes privadas.
    • Configurar el endpoint del clúster como público y privado.
    • Durante la creación agregue los add-ons: EKS Pod Identity Agent, Amazon EBS CSI Driver, cert-manager y External DNS. No instale aún Amazon SageMaker Spaces ni el AWS Load Balancer Controller: esos se instalan más adelante.
    • Cree un node group administrado en las subredes privadas (Amazon Linux 2023, m5.xlarge o superior) con al menos 2 nodos.
  4. Etiquetado de subredes (paso crítico)

    Antes de instalar el Spaces add-on, etiquete cada subred para que el AWS Load Balancer Controller las descubra. Si no lo hace, el controlador podría colocar el ALB en subredes privadas y Spaces quedaría inaccesible.

    export VPC_ID=$(aws eks describe-cluster --name $CLUSTER_NAME --region $REGION --query 'cluster.resourcesVpcConfig.vpcId' --output text)
    ALL_SUBNETS=$(aws ec2 describe-subnets --region $REGION --filters "Name=vpc-id,Values=${VPC_ID}" --query 'Subnets[*].SubnetId' --output text)
    aws ec2 create-tags --region $REGION --resources ${ALL_SUBNETS} --tags Key=kubernetes.io/cluster/$CLUSTER_NAME,Value=shared

    Después etiquete subredes públicas y privadas adecuadamente (en la documentación original están los comandos para eso).

  5. Instalar AWS Load Balancer Controller y el add-on de Spaces

    Una vez las subredes estén etiquetadas, instale el AWS Load Balancer Controller, solicite el certificado TLS en ACM para su dominio y cree la clave de encriptación KMS que usa el middleware de autenticación. Luego instale el SageMaker AI Spaces add-on en la versión adecuada.

  6. Lanzar su primer Space y acceso

    Con todo instalado puede crear su primer Space y acceder mediante una URL prefirmada en el navegador. Para conexiones desde VS Code puede usar SSH-over-SSM, que establece un túnel SSM directo al pod.

  7. Migrar la autenticación a OIDC (opcional)

    La guía muestra cómo avanzar hacia autenticación OpenID Connect usando Amazon Cognito, lo que facilita la integración con proveedores de identidad empresariales; es un paso relevante para entornos de producción.

Costos y limpieza

Recuerde que algunos recursos generan cargos continuos (ALB, EBS, EFS/FSx, instancias EC2, EKS). También tenga presente el cargo por SSM advanced-instances mencionado arriba. Al terminar las pruebas, elimine el clúster y recursos asociados según la sección de limpieza para evitar facturación innecesaria.

Recomendaciones operativas

  • Coordine con su equipo de plataforma el etiquetado y la configuración de subredes antes de instalar el add-on.
  • Validar versiones de kubectl, Helm y la versión mínima del add-on (0.1.4) evita problemas de compatibilidad.
  • Para organizaciones en Latinoamérica que comparten infraestructura entre equipos, esta arquitectura permite mejorar la utilización de GPU y reducir costos de notebooks siempre encendidos.

Conclusión

SageMaker AI Spaces sobre Amazon EKS permite integrar entornos interactivos directamente en el clúster que ya ejecuta sus pipelines, conservando acceso a GPU, almacenamiento compartido e IAM. Esto reduce tiempo de despliegue para científicos de datos y facilita la gestión operativa para equipos de plataforma, especialmente en contextos donde optimizar recursos y costos es crítico.

Fuente original: AWS ML Blog