Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Add-on anpassen
## Vorlage
Vorlagen sind wiederverwendbare Workspace-Konfigurationen, die als vom Administrator gesteuerte Blueprints für die Erstellung von Arbeitsbereichen dienen. Sie bieten Standardwerte für Workspace-Konfigurationswerte und Richtlinien, mit denen gesteuert werden kann, was Datenwissenschaftler tun können. Vorlagen existieren auf Clusterebene und können in verschiedenen Namespaces wiederverwendet werden.
SageMaker Spaces erstellt zwei Systemvorlagen als Ausgangspunkt für Datenwissenschaftler, eine für den Code-Editor und eine für. JupyterLab Diese Systemvorlagen werden vom Addon verwaltet und können nicht direkt bearbeitet werden. Stattdessen können Admins neue Vorlagen erstellen und diese als Standard festlegen.
## Verwaltung von Aufgaben
```
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//Benutzerdefinierte Bilder
Kunden können Image-Richtlinien mithilfe von Vorlagen konfigurieren, indem sie ein Standard-Image und eine Liste der zulässigen Images bereitstellen. Darüber hinaus können Administratoren wählen, ob Datenwissenschaftler ihre eigenen benutzerdefinierten Images mitbringen dürfen. Das System verwendet standardmäßig die neueste SageMaker Distribution. Wenn Sie sich jedoch an eine bestimmte Version binden möchten, können Sie die genaue SMD-Version angeben, die in einer Vorlage verwendet werden soll.
Anforderungen an benutzerdefinierte Bilder:
+ `curl`wenn Sie Idle Shutdown verwenden möchten
+ Port 8888
+ Remote-Zugriff
## Remote-IDE-Anforderung
### Anforderung an die VS-Code-Version
VS-Code-Version [v1.90](https://code.visualstudio.com/updates/v1_90) oder höher ist erforderlich. Wir empfehlen die [neueste stabile Version von VS Code](https://code.visualstudio.com/updates) zu verwenden.
### Anforderungen an Betriebssysteme
Sie benötigen eines der folgenden Betriebssysteme, um eine Remoteverbindung zu Studio-Bereichen herzustellen:
+ macOS 13\$1
+ Windows 10
+ [Die Unterstützung für Windows 10 endet am 14. Oktober 2025](https://support.microsoft.com/en-us/windows/windows-10-support-ends-on-october-14-2025-2ca8b313-1946-43d3-b55c-2b95b107f281)
+ Windows 11
+ Linux
+ Installieren Sie den offiziellen [Microsoft VS Code für Linux](https://code.visualstudio.com/docs/setup/linux)
+ keine Open-Source-Version
### Voraussetzungen für lokale Maschinen
Bevor Sie Ihren lokalen Visual Studio-Code mit Studio Spaces verbinden, stellen Sie sicher, dass Ihr lokaler Computer über die erforderlichen Abhängigkeiten und den erforderlichen Netzwerkzugriff verfügt.
**Anmerkung**
Umgebungen mit Einschränkungen bei der Softwareinstallation können Benutzer daran hindern, die erforderlichen Abhängigkeiten zu installieren. Das AWS Toolkit for Visual Studio Code sucht beim Initiieren von Remoteverbindungen automatisch nach diesen Abhängigkeiten und fordert Sie zur Installation auf, falls diese fehlen. Stimmen Sie sich mit Ihrer IT-Abteilung ab, um sicherzustellen, dass diese Komponenten verfügbar sind.
**Erforderliche lokale Abhängigkeiten**
Auf Ihrem lokalen Computer müssen die folgenden Komponenten installiert sein:
+ **[https://code.visualstudio.com/docs/remote/ssh](https://code.visualstudio.com/docs/remote/ssh)**
+ — Standard-VS Code Marketplace-Erweiterung für die Fernentwicklung
+ **[Session Manager-Plugin](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html)** — Für eine sichere Sitzungsverwaltung erforderlich
+ **SSH-Client** — Standardkomponente auf den meisten Maschinen ([OpenSSH wird für Windows empfohlen](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)**
+ In der Regel in der VS Code-Installation enthalten
**Plattformspezifische Anforderungen**
+ **Windows-Benutzer** — PowerShell 5.1 oder höher ist für SSH-Terminalverbindungen erforderlich
**Anforderungen an die Netzwerkkonnektivität**
Ihr lokaler Computer muss Netzwerkzugriff auf die [Session Manager-Endpunkte](https://docs.aws.amazon.com/general/latest/gr/ssm.html) haben. In USA Ost (Nord-Virginia) (us-east-1) können dies beispielsweise sein:
+ `[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)`
### Anforderungen an Images
**SageMaker Bilder zur Verteilung**
Wenn Sie SageMaker Distribution mit Fernzugriff verwenden, verwenden Sie [SageMaker Distribution](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-distribution.html) Version 2.7 oder höher.
**Benutzerdefinierte Bilder**
Wenn Sie [Bring Your Own Image (BYOI)](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-updated-byoi.html) mit Fernzugriff verwenden, stellen Sie sicher, dass Sie die [benutzerdefinierten Image-Spezifikationen](https://docs.aws.amazon.com/sagemaker/latest/dg/studio-updated-byoi-specs.html) einhalten und dass die folgenden Abhängigkeiten installiert sind:
+ `curl`oder `wget` — Erforderlich für das Herunterladen von Komponenten AWS CLI
+ `unzip`— Erforderlich für das Extrahieren von AWS CLI Installationsdateien
+ `tar`— Für das Extrahieren von Archiven erforderlich
+ `gzip`— Erforderlich für die Handhabung komprimierter Dateien
### Instance-Anforderungen
+ **Arbeitsspeicher**: 8 GB oder mehr
+ Verwenden Sie Instanzen mit mindestens 8 GB Arbeitsspeicher. Die folgenden Instance-Typen werden aufgrund unzureichenden Speichers (weniger als 8 GB) *nicht* unterstützt: `ml.t3.medium`, `ml.c7i.large`, `ml.c6i.large`, `ml.c6id.large` und `ml.c5.large`. Eine vollständigere Liste der Instance-Typen finden Sie auf der Seite [Amazon EC2 On-Demand-Preise](https://aws.amazon.com/ec2/pricing/on-demand/)
## Optimierung der Kubernetes-Startzeit durch Vorwärmen von Container-Images
Die Leistung beim Abrufen von Container-Images ist für viele EKS-Kunden zu einem erheblichen Engpass geworden, insbesondere da AI/ML Workloads auf immer größere Container-Images angewiesen sind. Das Ziehen und Entpacken dieser großen Images dauert in der Regel mehrere Minuten, wenn sie zum ersten Mal auf jedem EKS-Knoten verwendet werden. Diese Verzögerung erhöht die Latenz beim Start von SageMaker Spaces erheblich und wirkt sich direkt auf die Benutzererfahrung aus — insbesondere in Umgebungen, in denen ein schneller Start unerlässlich ist, wie Notebooks oder interaktive Entwicklungsjobs.
Bei der Image-Vorwärmung handelt es sich um eine Technik, mit der bestimmte Container-Images vorab auf jeden Knoten im EKS/HyperPod Cluster geladen werden, bevor sie benötigt werden. Anstatt darauf zu warten, dass ein Pod den ersten Abruf eines großen Images auslöst, lädt der Cluster proaktiv Bilder herunter und speichert sie zwischen allen Knoten. Dadurch wird sichergestellt, dass beim Start von Workloads die erforderlichen Images bereits lokal verfügbar sind, wodurch lange Kaltstartverzögerungen vermieden werden. Das Vorwärmen von Bildern verbessert die Startgeschwindigkeit von SageMaker Spaces und sorgt für ein vorhersehbareres und reaktionsschnelleres Erlebnis für Endbenutzer.
### Vorwärmen über DaemonSet
Wir empfehlen die Verwendung von a DaemonSet zum Vorladen von Bildern. A DaemonSet stellt sicher, dass auf jedem Knoten im Cluster ein Pod ausgeführt wird. Jeder Container im DaemonSet Pod verweist auf ein Bild, das Sie zwischenspeichern möchten. Wenn Kubernetes den Pod startet, werden die Bilder automatisch abgerufen, wodurch der Cache auf jedem Knoten erwärmt wird.
Das folgende Beispiel zeigt, wie Sie einen erstellen, der zwei DaemonSet GPU-Images vorab lädt. Jeder Container führt einen einfachen `sleep infinity` Befehl aus, um den Pod bei minimalem Overhead aktiv zu halten.
```
cat <
+ Jeder Container referenziert ein Bild.
+ Kubernetes muss jedes Image herunterladen, bevor der Container gestartet wird.
+ Sobald der Pod auf jedem Knoten ausgeführt wird, werden die Bilder lokal zwischengespeichert.
+ Jeder Workload, der diese Images verwendet, startet jetzt viel schneller.
## Space Default Storage (EBS)
Das System verwendet standardmäßig den EBS-CSI-Treiber, um EBS-Speicher-Volumes für jeden Workspace bereitzustellen. SageMaker erstellt eine EBS-Speicherklasse für die Verwendung mit Workspaces, und Administratoren können die Standard- und Maximalgröße dieser Volumes mithilfe von Vorlageneinstellungen anpassen. Für fortgeschrittene Benutzer, die mit CLI-Tools arbeiten, können Sie auch die Speicherklasse des Workspace anpassen, sodass Benutzer andere Speicherklassen nutzen können, einschließlich der Konfiguration von kundenverwalteten KMS-Schlüsseln für ihre EBS-Volumes.
Beachten Sie, dass EBS-Volumes an eine bestimmte AZ gebunden sind, was bedeutet, dass Workspaces nur auf Knoten geplant werden können, die sich in derselben AZ wie ihr Speichervolume befinden. Dies kann zu Planungsfehlern führen, wenn Clusterkapazität vorhanden ist, aber nicht in der richtigen AZ.
## Zusätzlicher Speicher
SageMaker Spaces unterstützt das Anhängen zusätzlicher Speichervolumes wie Amazon EFS, FSx for Lustre oder S3 Mountpoint an Ihre Entwicklungsbereiche. Auf diese Weise können Sie auf gemeinsam genutzte Datensätze zugreifen, an Projekten zusammenarbeiten oder Hochleistungsspeicher für Ihre Workloads verwenden.
### Voraussetzungen
Bevor Sie Spaces zusätzlichen Speicherplatz hinzufügen, müssen Sie:
1. **Installieren Sie das entsprechende CSI-Treiber-Add-on** über [EKS-Add-Ons](https://docs.aws.amazon.com/eks/latest/userguide/workloads-add-ons-available-eks.html) (Amazon EFS CSI Driver, Amazon FSx for Lustre CSI Driver oder Mountpoint for Amazon S3 CSI Driver)
1. **Richten Sie Speicherressourcen ein und PersistentVolumeClaims befolgen** Sie die CSI-Treiber-Dokumentation für Ihren spezifischen Speichertyp
1. **Stellen Sie sicher, dass das PVC in demselben Namespace verfügbar ist**, in dem Sie Ihren Bereich einrichten möchten
### Speicher an Räume anhängen
Sobald Sie eine PersistentVolumeClaim konfiguriert haben, können Sie sie entweder über die HyperPod CLI oder kubectl an einen Space anhängen.
**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
```
### Mehrere Bände
Sie können mehrere zusätzliche Speichervolumes an einen einzelnen Speicherplatz anhängen, indem Sie mehrere `--volume` Flags mit der CLI oder mehrere Einträge im `volumes` Array mit kubectl angeben.
**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
```
## Konfiguration der Ressourcen
SageMaker Mit Spaces können Sie Rechenressourcen für Ihre Entwicklungsumgebungen konfigurieren, einschließlich CPU-, Arbeitsspeicher- und GPU-Ressourcen, die Ihren Workload-Anforderungen entsprechen.
### GPU-Konfiguration
SageMaker Spaces unterstützt sowohl die gesamte GPU-Zuweisung als auch die GPU-Partitionierung mithilfe der NVIDIA Multi-Instance-GPU (MIG) -Technologie. Auf diese Weise können Sie die GPU-Auslastung für verschiedene Arten von Workloads für maschinelles Lernen optimieren.
#### Vollständige GPU-Zuweisung
**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"
```
#### GPU-Partitionierung (MIG)
Die GPU-Partitionierung mithilfe der NVIDIA Multi-Instance-GPU (MIG) -Technologie ermöglicht es Ihnen, eine einzelne GPU in kleinere, isolierte Instanzen zu partitionieren. Ihr HyperPod Cluster muss über GPU-Knoten verfügen, die MIG unterstützen, und es müssen MIG-Profile konfiguriert sein. Weitere Informationen zur Einrichtung von MIG auf Ihrem HyperPod Cluster finden Sie unter [GPU-Partitionierung mit NVIDIA MIG](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-gpu-partitioning-setup.html).
**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"
```
## Lebenszyklus
Die Lebenszykluskonfiguration stellt Startskripts bereit, die ausgeführt werden, wenn ein Workspace erstellt oder gestartet wird. Diese Skripts ermöglichen es Administratoren, die Workspace-Umgebung beim Start anzupassen. Dies sind Bash-Skripte mit einer maximalen Größe von 1 KB. Wenn Sie eine größere Setup-Konfiguration benötigen, empfehlen wir, dem Container-Image ein Skript hinzuzufügen und das Skript über die Lebenszykluskonfiguration auszulösen.
[Wir nutzen Kubernetes-Container-Lifecycle-Hooks, um diese Funktionalität bereitzustellen https://kubernetes. io/docs/concepts/containers/container-lifelycle-hooks/.](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) Beachten Sie, dass Kubernetes keine Garantie dafür gibt, wann das Startskript in Bezug auf den Einstiegspunkt des Containers ausgeführt wird.
## Herunterfahren im Leerlauf
Konfigurieren Sie das automatische Herunterfahren inaktiver Workspaces, um die Ressourcennutzung zu optimieren.
### Herunterfahren im Leerlauf
```
idleShutdown:
enabled: true
idleShutdownTimeoutMinutes: 30
detection:
httpGet:
path: /api/idle
port: 8888
scheme: HTTP
```
### Parameters
**enabled** (boolean, required) — Aktiviert oder deaktiviert das Herunterfahren im Leerlauf für den Workspace.
**idleShutdownTimeoutMinuten** (Ganzzahl, erforderlich) — Anzahl der Minuten der Inaktivität, bevor der Workspace heruntergefahren wird. Der Mindestwert ist 1.
**detection** (object, required) — Definiert, wie der Ruhezustand eines Workspace erkannt wird.
**Detection.HttpGet** (Objekt, optional) — HTTP-Endpunktkonfiguration für die Erkennung von Leerlauf. Verwendet die Kubernetes Action-Spezifikation. HTTPGet
+ **path** — HTTP-Pfad zur Anfrage
+ **port** — Portnummer oder Name
+ **Schema** — HTTP oder HTTPS (Standard: HTTP)
### Speicherorte der Konfiguration
**Konfiguration des Arbeitsbereichs**
Definieren Sie das Herunterfahren im Leerlauf direkt in der Workspace-Spezifikation:
```
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
```
**Konfiguration der Vorlage**
Definieren Sie das Standardverhalten beim Herunterfahren im Leerlauf in einem 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
```
### Vererbung und Überschreibungen von Vorlagen
Arbeitsbereiche, die eine Vorlage verwenden, erben automatisch die Konfiguration der Vorlage. `defaultIdleShutdown` Arbeitsbereiche können diese Konfiguration überschreiben, wenn die Vorlage dies zulässt.
**Richtlinie außer Kraft setzen**
Vorlagen steuern das Verhalten beim Außerkraftsetzen durch`idleShutdownOverrides`:
**allow** (boolean, default: true) — Ob Workspaces die Standardkonfiguration zum Herunterfahren im Leerlauf überschreiben können.
**minTimeoutMinutes**(Ganzzahl, optional) — Minimaler zulässiger Timeout-Wert für Workspace-Overrides.
**maxTimeoutMinutes**(Ganzzahl, optional) — Maximal zulässiger Timeout-Wert für Workspace-Overrides.
**Beispiel für Vererbung**
Workspace erbt die Standardeinstellungen für Vorlagen:
```
apiVersion: workspace.jupyter.org/v1alpha1
kind: Workspace
metadata:
name: my-workspace
spec:
displayName: "My Workspace"
templateRef:
name: jupyter-template
# Inherits defaultIdleShutdown from template
```
**Beispiel überschreiben**
Workspace überschreibt die Standardeinstellungen der Vorlage:
```
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
```
**Gesperrte Konfiguration**
Workspace-Überschreibungen verhindern:
```
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
```
### Behavior
Wenn das Herunterfahren im Leerlauf aktiviert ist, überprüft das System den Workspace regelmäßig anhand des konfigurierten HTTP-Endpunkts auf Aktivitäten. Wenn der Endpunkt angibt, dass der Workspace für die angegebene Timeout-Dauer inaktiv ist, stoppt der Workspace automatisch. Sie können den Workspace bei Bedarf manuell neu starten.
## Vorlagenaktualisierungen
Die Client-Tools wie Kubectl oder Hyperpod CLI und SDK können für die Verwaltung von Spaces innerhalb des EKS-Clusters verwendet werden. Administratoren können Space-Vorlagen für standardmäßige Space-Konfigurationen bereitstellen, während Datenwissenschaftler ihre integrierten Entwicklungsumgebungen anpassen können, ohne die zugrunde liegende Komplexität von Kubernetes verstehen zu müssen. Detaillierte Nutzungsanweisungen finden Sie in der CLI- und SDK-Dokumentation unter [https://sagemaker-hyperpod-cli.readthedocs.io/en/latest/index.html](https://sagemaker-hyperpod-cli.readthedocs.io/en/latest/index.html).
Administratoren können CRUD-Operationen mit Space-Vorlagen durchführen, die als Basiskonfigurationen bei der Erstellung eines Space dienen. Datenwissenschaftler können CRUD-Operationen auf Spaces ausführen und verschiedene Parameter außer Kraft setzen, einschließlich der Multi-Instanz-GPU-Profile für bestimmte Rechenknoten. Sie können die Spaces über VSCode Fernzugriff und die Weboberfläche starten, beenden und eine Verbindung zu ihnen herstellen. Wenn eine Space-Vorlage aktualisiert wird, werden alle später erstellten Spaces mit den Einstellungen in der aktualisierten Vorlage konfiguriert. Konformitätsprüfungen werden durchgeführt, wenn bestehende Spaces aktualisiert oder gestartet werden. Wenn Einstellungen außerhalb der zulässigen Grenzen liegen oder nicht übereinstimmen, können die Spaces nicht aktualisiert oder gestartet werden.
## Verwenden von hyp cli und kubectl
Der Benutzer kann mit der Hyperpod-CLI CRUD für die Vorlagen ausführen
```
### 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
```
Um benutzerdefinierte Vorlagen zu erstellen, können Sie unsere Systemvorlagen als Ausgangspunkt verwenden. Diese Vorlage funktioniert für SMD-ähnliche Bilder, kann jedoch auf der Grundlage der von Administratoren verwendeten Bilder angepasst werden.
Beispiel für eine benutzerdefinierte Vorlage: 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"
```
Beispiel für eine benutzerdefinierte Code-Editor-Vorlage:
```
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"
```