Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Personaliza el complemento ## Plantilla Las plantillas son configuraciones de espacio de trabajo reutilizables que sirven como modelos controlados por el administrador para la creación de espacios de trabajo. Proporcionan valores predeterminados para la configuración del espacio de trabajo y sirven de barrera para controlar lo que pueden hacer los científicos de datos. Las plantillas existen a nivel de clúster y se pueden reutilizar en todos los espacios de nombres. SageMaker Spaces crea dos plantillas de sistema como punto de partida para los científicos de datos, una para el editor de código y otra para. JupyterLab El complemento administra estas plantillas de sistema y no se pueden editar directamente. En su lugar, los administradores pueden crear nuevas plantillas y configurarlas como predeterminadas. ## Gobierno de tareas ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: WorkspaceTemplate metadata: name: my-jupyter-template namespace: my-namespace labels: kueue.x-k8s.io/priority-class: -priority spec: displayName: "My Custom Jupyter Lab" description: "Custom Jupyter Lab with specific configurations" defaultImage: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu" allowedImages: - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu" - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu" defaultResources: requests: cpu: "1" memory: "4Gi" limits: cpu: "4" memory: "16Gi" primaryStorage: defaultSize: "10Gi" minSize: "5Gi" maxSize: "50Gi" defaultStorageClassName: "sagemaker-spaces-default-storage-class" defaultMountPath: "/home/sagemaker-user" defaultContainerConfig: command: ["/opt/amazon/sagemaker/workspace/bin/entrypoint-workspace-jupyterlab"] defaultPodSecurityContext: fsGroup: 1000 defaultOwnershipType: "Public" defaultAccessStrategy: name: "hyperpod-access-strategy" allowSecondaryStorages: true appType: "jupyterlab" ``` ## SMD/ Imágenes personalizadas Los clientes pueden configurar las políticas de imágenes mediante plantillas proporcionando una imagen predeterminada y una lista de imágenes permitidas. Además, los administradores pueden elegir si permiten que los científicos de datos traigan sus propias imágenes personalizadas. El sistema utiliza de forma predeterminada la SageMaker distribución más reciente, pero si desea anclarla a una versión concreta, puede especificar la versión de SMD exacta que se utilizará en una plantilla. Requisitos de imagen personalizada: + `curl`si desea utilizar el apagado inactivo + puerto 8888 + acceso remoto ## Requisito de IDE remoto ### Requisito de versión de Visual Studio Code Se requiere la versión [v1.90](https://code.visualstudio.com/updates/v1_90) o superior de Visual Studio Code. Recomendamos que se utilice la [versión más reciente de Visual Studio Code](https://code.visualstudio.com/updates). ### Requisitos del sistema operativo Para conectarse de forma remota a los espacios de Studio, necesita uno de los siguientes sistemas operativos: + macOS 13 o superior + Windows 10 + [El soporte de Windows 10 finaliza el 14 de octubre 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 + Instala el [código oficial de Microsoft VS para Linux](https://code.visualstudio.com/docs/setup/linux) + no es una versión de código abierto ### Requisitos previos de la máquina local Antes de conectar el código de Visual Studio local a los espacios de Studio, asegúrese de que la máquina local tenga las dependencias y el acceso a la red necesarios. **nota** Los entornos con restricciones de instalación de software pueden impedir que los usuarios instalen las dependencias necesarias. El AWS Toolkit for Visual Studio Code busca automáticamente estas dependencias al iniciar conexiones remotas y solicitará la instalación si falta alguna. Coordínese con su departamento de TI para asegurarse de que estos componentes estén disponibles. **Dependencias locales requeridas** Su máquina local debe tener instalados los siguientes componentes: + **[https://code.visualstudio.com/docs/remote/ssh](https://code.visualstudio.com/docs/remote/ssh)** + — Extensión estándar de VS Code Marketplace para desarrollo remoto + **[Plugin Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html)**: necesario para una gestión segura de las sesiones + **Cliente SSH**: componente estándar en la mayoría de las máquinas (se recomienda [OpenSSH 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 se incluye con la instalación de VS Code **Requisitos específicos de la plataforma** + **Usuarios de Windows**: se requiere la PowerShell versión 5.1 o posterior para las conexiones de terminales SSH **Requisitos de conectividad de red** Su máquina local debe tener acceso de red a los [puntos finales del administrador de sesiones](https://docs.aws.amazon.com/general/latest/gr/ssm.html). Por ejemplo, en EE. UU. Este (Virginia del Norte) (us-east-1) pueden 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 imágenes **SageMaker Imágenes de distribución** Cuando utilice SageMaker Distribution con acceso remoto, utilice la versión 2.7 o posterior de [SageMaker Distribution](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-distribution.html). **Imágenes personalizadas** Cuando [traiga su propia imagen (BYOI)](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-updated-byoi.html) con acceso remoto, asegúrese de seguir las [especificaciones de imagen personalizadas](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-updated-byoi-specs.html) y de que estén instaladas las siguientes dependencias: + `curl`o `wget` — Necesario para descargar componentes AWS CLI + `unzip`— Necesario para extraer los archivos AWS CLI de instalación + `tar`— Necesario para la extracción de archivos + `gzip`— Necesario para la gestión de archivos comprimidos ### Requisitos de instancias + **Memoria**: 8 GB o más + Usa instancias con al menos 8 GB de memoria. *No* se admiten los siguientes tipos de instancia por falta de memoria (menos de 8 GB): `ml.t3.medium`, `ml.c7i.large`, `ml.c6i.large`, `ml.c6id.large` y `ml.c5.large`. Para obtener una lista más completa de los tipos de instancias, consulte la página de [precios bajo demanda de Amazon EC2](https://aws.amazon.com/ec2/pricing/on-demand/) ## Optimización del tiempo de inicio de Kubernetes mediante el precalentamiento de las imágenes de los contenedores El rendimiento de la extracción de imágenes de contenedores se ha convertido en un obstáculo importante para muchos clientes de EKS, especialmente porque las AI/ML cargas de trabajo dependen de imágenes de contenedores cada vez más grandes. La primera vez que se utilizan en cada nodo de EKS, se tarda varios minutos en extraer y desempaquetar estas imágenes de gran tamaño. Este retraso añade una latencia considerable a la hora de lanzar SageMaker Spaces y repercute directamente en la experiencia del usuario, especialmente en entornos en los que es fundamental un arranque rápido, como las libretas o las tareas de desarrollo interactivo. El precalentamiento de imágenes es una técnica que se utiliza para precargar imágenes de contenedores específicas en cada nodo del EKS/HyperPod clúster antes de que se necesiten. En lugar de esperar a que un módulo active la primera extracción de una imagen grande, el clúster descarga y almacena en caché las imágenes de todos los nodos de forma proactiva. Esto garantiza que, cuando se inicien las cargas de trabajo, las imágenes necesarias ya estén disponibles localmente, lo que elimina las largas demoras en el arranque en frío. El precalentamiento de la imagen mejora la velocidad de inicio de SageMaker Spaces y proporciona a los usuarios finales una experiencia más predecible y con mayor capacidad de respuesta. ### El precalentamiento se realiza mediante DaemonSet Recomendamos utilizar un DaemonSet para precargar las imágenes. A DaemonSet garantiza que un pod se ejecute en cada nodo del clúster. Cada contenedor del DaemonSet pod hace referencia a una imagen que deseas almacenar en caché. Cuando Kubernetes inicia el pod, extrae automáticamente las imágenes y calienta la caché de cada nodo. En el siguiente ejemplo, se muestra cómo crear una DaemonSet que precargue dos imágenes de la GPU. Cada contenedor ejecuta un `sleep infinity` comando ligero para mantener el pod activo con una sobrecarga mínima. ``` cat < + Cada contenedor hace referencia a una imagen. + Kubernetes debe descargar cada imagen antes de iniciar el contenedor. + Una vez que el pod se ejecuta en todos los nodos, las imágenes se almacenan en caché localmente. + Cualquier carga de trabajo que utilice estas imágenes ahora comienza mucho más rápido. ## Espacio de almacenamiento predeterminado (EBS) El sistema utiliza el controlador CSI de EBS de forma predeterminada para aprovisionar los volúmenes de almacenamiento de EBS para cada espacio de trabajo. SageMaker crea una clase de almacenamiento de EBS para usarla con los espacios de trabajo, y los administradores pueden personalizar el tamaño predeterminado y máximo de estos volúmenes mediante la configuración de la plantilla. Para los usuarios avanzados que trabajan con herramientas CLI, también puede personalizar la clase de almacenamiento del espacio de trabajo, lo que permite a los usuarios aprovechar otras clases de almacenamiento, incluida la configuración de claves KMS administradas por el cliente para sus volúmenes de EBS. Tenga en cuenta que los volúmenes de EBS están enlazados a una zona de disponibilidad determinada, lo que significa que los espacios de trabajo solo se pueden programar en nodos de la misma zona de disponibilidad que su volumen de almacenamiento. Esto puede provocar errores de programación si existe capacidad del clúster pero no en la AZ correcta. ## Almacenamiento adicional SageMaker Spaces permite adjuntar volúmenes de almacenamiento adicionales, como Amazon EFS, FSx for Lustre o S3 Mountpoint, a sus espacios de desarrollo. Esto te permite acceder a conjuntos de datos compartidos, colaborar en proyectos o utilizar almacenamiento de alto rendimiento para tus cargas de trabajo. ### Requisitos previos Antes de adjuntar almacenamiento adicional a los espacios, debes: 1. **Instale el complemento de controlador CSI adecuado** mediante los [complementos de EKS](https://docs.aws.amazon.com/eks/latest/userguide/workloads-add-ons-available-eks.html) (controlador CSI Amazon EFS, controlador CSI Amazon FSx for Lustre o controlador CSI Mountpoint para Amazon S3) 1. **Configure los recursos de almacenamiento y PersistentVolumeClaims** siga la documentación del controlador CSI para su tipo de almacenamiento específico 1. **Asegúrese de que el PVC esté disponible** en el mismo espacio de nombres en el que planea crear su espacio ### Adjuntar almacenamiento a los espacios Una vez que haya PersistentVolumeClaim configurado una, puede adjuntarla a un espacio mediante la HyperPod CLI 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 ``` ### Múltiples volúmenes Puede adjuntar varios volúmenes de almacenamiento adicionales a un solo espacio especificando varios `--volume` indicadores con la CLI o varias entradas en la `volumes` matriz con kubectl. **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 ``` ## Configuración de recursos SageMaker Spaces le permite configurar los recursos informáticos para sus entornos de desarrollo, incluidos los recursos de CPU, memoria y GPU, para que se adapten a sus requisitos de carga de trabajo. ### Configuración de GPU SageMaker Spaces admite tanto la asignación completa de la GPU como el particionamiento de la GPU mediante la tecnología de GPU de instancias múltiples (MIG) de NVIDIA. Esto te permite optimizar el uso de la GPU para distintos tipos de cargas de trabajo de aprendizaje automático. #### Asignación total de la 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" ``` #### Particionamiento de GPU (MIG) El particionamiento de la GPU mediante la tecnología de GPU de instancias múltiples (MIG) de NVIDIA permite particionar una sola GPU en instancias más pequeñas y aisladas. El HyperPod clúster debe tener nodos de GPU que admitan MIG y tener perfiles MIG configurados. Para obtener más información sobre cómo configurar MIG en el HyperPod clúster, consulte [Partición de GPU](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-gpu-partitioning-setup.html) con 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 La configuración del ciclo de vida proporciona scripts de inicio que se ejecutan al crear o iniciar un espacio de trabajo. Estos scripts permiten a los administradores personalizar el entorno del espacio de trabajo durante el inicio. Se trata de scripts bash con un tamaño máximo de 1 KB. Si necesita una configuración más amplia, le recomendamos añadir un script a la imagen del contenedor y activar el script a partir de la configuración del ciclo de vida. [Aprovechamos los enlaces del ciclo de vida de los contenedores de Kubernetes para ofrecer esta funcionalidad en https://kubernetes. io/docs/concepts/containers/container](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/)-lifecycle-hooks/. Tenga en cuenta que Kubernetes no garantiza cuándo se ejecutará el script de inicio en relación con el punto de entrada del contenedor. ## Cierre por inactividad Configure el cierre automático de los espacios de trabajo inactivos para optimizar el uso de los recursos. ### Cierre por inactividad ``` idleShutdown: enabled: true idleShutdownTimeoutMinutes: 30 detection: httpGet: path: /api/idle port: 8888 scheme: HTTP ``` ### Parameters **habilitado** (booleano, obligatorio): habilita o deshabilita el cierre inactivo del espacio de trabajo. **idleShutdownTimeoutMinutos** (enteros, obligatorios): número de minutos de inactividad antes de que se cierre el espacio de trabajo. El valor mínimo es 1. **detección** (objeto, obligatorio): define cómo detectar el estado inactivo del espacio de trabajo. **detection.httpGet** (objeto, opcional): configuración de punto final HTTP para la detección de inactividad. Utiliza la especificación Action de Kubernetes. HTTPGet + **ruta: ruta** HTTP a solicitar + **puerto**: número o nombre del puerto + **esquema**: HTTP o HTTPS (predeterminado: HTTP) ### Ubicaciones de configuración **Configuración del espacio de trabajo** Defina el apagado por inactividad directamente en la especificación del espacio de trabajo: ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: Workspace metadata: name: my-workspace spec: displayName: "Development Workspace" image: jupyter/scipy-notebook:latest idleShutdown: enabled: true idleShutdownTimeoutMinutes: 30 detection: httpGet: path: /api/idle port: 8888 ``` **Configuración de plantilla** Defina el comportamiento de apagado en reposo predeterminado en WorkspaceTemplate: ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: WorkspaceTemplate metadata: name: jupyter-template spec: displayName: "Jupyter Template" defaultImage: jupyter/scipy-notebook:latest defaultIdleShutdown: enabled: true idleShutdownTimeoutMinutes: 30 detection: httpGet: path: /api/idle port: 8888 idleShutdownOverrides: allow: true minTimeoutMinutes: 60 maxTimeoutMinutes: 240 ``` ### Herencia y anulaciones de plantillas Los espacios de trabajo que utilizan una plantilla heredan automáticamente la configuración de la plantilla. `defaultIdleShutdown` Los espacios de trabajo pueden anular esta configuración si la plantilla lo permite. **Política de anulación** Las plantillas controlan el comportamiento de anulación mediante: `idleShutdownOverrides` **allow** (boolean, default: true): indica si los espacios de trabajo pueden anular la configuración predeterminada de apagado por inactividad. **minTimeoutMinutes**(entero, opcional): valor de tiempo de espera mínimo permitido para las anulaciones de espacios de trabajo. **maxTimeoutMinutes**(entero, opcional): valor de tiempo de espera máximo permitido para las anulaciones del espacio de trabajo. **Ejemplo de herencia** Workspace hereda los valores predeterminados de la plantilla: ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: Workspace metadata: name: my-workspace spec: displayName: "My Workspace" templateRef: name: jupyter-template # Inherits defaultIdleShutdown from template ``` **Ejemplo de anulación** Workspace anula los valores predeterminados de la plantilla: ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: Workspace metadata: name: my-workspace spec: displayName: "My Workspace" templateRef: name: jupyter-template idleShutdown: enabled: true idleShutdownTimeoutMinutes: 60 # Must be within template bounds detection: httpGet: path: /api/idle port: 8888 ``` **Configuración bloqueada** Evite la anulación del espacio de trabajo: ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: WorkspaceTemplate metadata: name: locked-template spec: displayName: "Locked Template" defaultImage: jupyter/scipy-notebook:latest defaultIdleShutdown: enabled: true idleShutdownTimeoutMinutes: 30 detection: httpGet: path: /api/idle port: 8888 idleShutdownOverrides: allow: false # Workspaces cannot override ``` ### Comportamiento Cuando el apagado por inactividad está activado, el sistema comprueba periódicamente la actividad del espacio de trabajo mediante el punto de conexión HTTP configurado. Si el punto final indica que el espacio de trabajo está inactivo durante el tiempo de espera especificado, el espacio de trabajo se detiene automáticamente. Puede reiniciar manualmente el espacio de trabajo cuando sea necesario. ## Actualizaciones de plantillas Las herramientas del cliente, como Kubectl o Hyperpod CLI y SDK, se pueden usar para administrar Spaces dentro del clúster de EKS. Los administradores pueden aprovisionar plantillas de Space para las configuraciones de Space predeterminadas, mientras que los científicos de datos pueden personalizar sus entornos de desarrollo integrados sin necesidad de comprender la complejidad subyacente de Kubernetes. Para obtener instrucciones de uso detalladas, consulte la documentación de CLI y SDK en [https://sagemaker-hyperpod-cli.readthedocs.io/en/latest/index.html](https://sagemaker-hyperpod-cli.readthedocs.io/en/latest/index.html). Los administradores pueden realizar operaciones CRUD en las plantillas de Space, que sirven como configuraciones básicas al crear un espacio. Los científicos de datos pueden realizar operaciones CRUD en Spaces y anular varios parámetros, incluidos los perfiles de GPU de varias instancias para nodos de procesamiento específicos. Pueden iniciar, detener y conectarse a los Spaces mediante el VSCode acceso remoto y la interfaz de usuario web. Cuando se actualiza una plantilla de espacio, cualquier espacio que se cree posteriormente se configurará con los ajustes de la plantilla actualizada. Las comprobaciones de conformidad se realizarán cuando se actualicen o se inicien los espacios existentes. Si alguna configuración está fuera de los límites o no coincide, los espacios no se actualizarán ni se iniciarán. ## Usando hyp cli y kubectl El usuario puede realizar CRUD en las plantillas con la CLI de Hyperpod ``` ### 1. Create a Space Template hyp create hyp-space-template --file template.yaml ### 2. List Space Templates hyp list hyp-space-template hyp list hyp-space-template --output json ### 3. Describe a Space Template hyp describe hyp-space-template --name my-template hyp describe hyp-space-template --name my-template --output json ### 4. Update a Space Template hyp update hyp-space-template --name my-template --file updated-template.yaml ### 5. Delete a Space Template hyp delete hyp-space-template --name my-template ``` Para crear plantillas personalizadas, puede utilizar las plantillas de nuestro sistema como punto de partida. Esta plantilla funcionará para imágenes tipo SMD, pero se puede personalizar en función de las imágenes utilizadas por los administradores. Ejemplo de plantilla personalizada: JupyterLab ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: WorkspaceTemplate metadata: name: my-jupyter-template namespace: my-namespace spec: displayName: "My Custom Jupyter Lab" description: "Custom Jupyter Lab with specific configurations" defaultImage: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu" allowedImages: - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu" - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu" defaultResources: requests: cpu: "1" memory: "4Gi" limits: cpu: "4" memory: "16Gi" primaryStorage: defaultSize: "10Gi" minSize: "5Gi" maxSize: "50Gi" defaultStorageClassName: "sagemaker-spaces-default-storage-class" defaultMountPath: "/home/sagemaker-user" defaultContainerConfig: command: ["/opt/amazon/sagemaker/workspace/bin/entrypoint-workspace-jupyterlab"] defaultPodSecurityContext: fsGroup: 1000 defaultOwnershipType: "Public" defaultAccessStrategy: name: "hyperpod-access-strategy" allowSecondaryStorages: true appType: "jupyterlab" ``` Ejemplo de plantilla de editor de código personalizada: ``` apiVersion: workspace.jupyter.org/v1alpha1 kind: WorkspaceTemplate metadata: name: my-code-editor-template namespace: my-namespace spec: displayName: "My Custom Code Editor" description: "Custom Code Editor with specific configurations" defaultImage: "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu" allowedImages: - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-cpu" - "public.ecr.aws/sagemaker/sagemaker-distribution:latest-gpu" defaultResources: requests: cpu: "1" memory: "4Gi" limits: cpu: "4" memory: "16Gi" primaryStorage: defaultSize: "10Gi" minSize: "5Gi" maxSize: "50Gi" defaultStorageClassName: "sagemaker-spaces-default-storage-class" defaultMountPath: "/home/sagemaker-user" defaultContainerConfig: command: ["/opt/amazon/sagemaker/workspace/bin/entrypoint-workspace-code-editor"] defaultPodSecurityContext: fsGroup: 1000 defaultOwnershipType: "Public" defaultAccessStrategy: name: "hyperpod-access-strategy" allowSecondaryStorages: true appType: "code-editor" ```