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: <user-input>-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:

Remote-IDE-Anforderung

Anforderung an die VS-Code-Version

VS-Code-Version v1.90 oder höher ist erforderlich. Wir empfehlen die neueste stabile Version von VS Code zu verwenden.

Anforderungen an Betriebssysteme

Sie benötigen eines der folgenden Betriebssysteme, um eine Remoteverbindung zu Studio-Bereichen herzustellen:

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.

Erforderliche lokale Abhängigkeiten

Auf Ihrem lokalen Computer müssen die folgenden Komponenten installiert sein:

Plattformspezifische Anforderungen

Anforderungen an die Netzwerkkonnektivität

Ihr lokaler Computer muss Netzwerkzugriff auf die Session Manager-Endpunkte haben. In USA Ost (Nord-Virginia) (us-east-1) können dies beispielsweise sein:

Anforderungen an Images

SageMaker Bilder zur Verteilung

Wenn Sie SageMaker Distribution mit Fernzugriff verwenden, verwenden Sie SageMaker Distribution Version 2.7 oder höher.

Benutzerdefinierte Bilder

Wenn Sie Bring Your Own Image (BYOI) mit Fernzugriff verwenden, stellen Sie sicher, dass Sie die benutzerdefinierten Image-Spezifikationen einhalten und dass die folgenden Abhängigkeiten installiert sind:

Instance-Anforderungen

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 für alle Knoten im Cache. 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 <<EOF | kubectl apply -n "namespace_1" -f -
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: image-preload-ds
spec:
  selector:
    matchLabels:
      app: image-preloader
  template:
    metadata:
      labels:
        app: image-preloader
    spec:
      containers:
      - name: preloader-3-4-2
        image: public.ecr.aws/sagemaker/sagemaker-distribution:3.4.2-gpu
        command: ["sleep"]
        args: ["infinity"]
        resources:
          requests:
            cpu: 1m
            memory: 16Mi
          limits:
            cpu: 5m
            memory: 32Mi
      - name: preloader-3-3-2
        image: public.ecr.aws/sagemaker/sagemaker-distribution:3.3.2-gpu
        command: ["sleep"]
        args: ["infinity"]
        resources:
          requests:
            cpu: 1m
            memory: 16Mi
          limits:
            cpu: 5m
            memory: 32Mi
EOF

So funktioniert’s

Space Default Storage (EBS)

Das System verwendet standardmäßig den EBS-CSI-Treiber, um EBS-Speichervolumes 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.

Lebenszyklus

Die Lebenszykluskonfiguration bietet Startskripts, 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/. 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-Aktionsspezifikation. HTTPGet

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 durchidleShutdownOverrides:

allow (boolean, default: true) — Gibt an, ob Workspaces die Standardkonfiguration für das 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.

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"