Agent Sandbox in GKE aktivieren

In diesem Dokument wird erläutert, wie Sie die Agent Sandbox in einem Google Kubernetes Engine-Cluster (GKE) aktivieren. Außerdem wird beschrieben, wie Sie eine Sandbox-Umgebung im Cluster erstellen, um nicht vertrauenswürdigen Code sicher auszuführen.

Eine Übersicht darüber, wie die Agent Sandbox in der GKE nicht vertrauenswürdigen KI-generierten Code isoliert, finden Sie unter Informationen zur Agent Sandbox in der GKE.

Kosten

Die Agent Sandbox in der GKE wird ohne zusätzliche Kosten angeboten. Für die von Ihnen erstellten Ressourcen gelten die GKE-Preise.

Um unnötige Kosten zu vermeiden, deaktivieren Sie die GKE oder löschen Sie das Projekt, nachdem Sie dieses Dokument durchgearbeitet haben.

Hinweis

  1. Wählen Sie in der Google Cloud Console auf der Seite für die Projektauswahl ein Projekt von aus oder erstellen Sie eines Google Cloud .

    Rollen, die zum Auswählen oder Erstellen eines Projekts erforderlich sind

    • Projekt auswählen: Für die Auswahl eines Projekts ist keine bestimmte IAM-Rolle erforderlich. Sie können ein beliebiges Projekt auswählen, für das Ihnen eine Rolle zugewiesen wurde.
    • Projekt erstellen: Zum Erstellen eines Projekts benötigen Sie die Rolle „Projektersteller“ (roles/resourcemanager.projectCreator), die die resourcemanager.projects.create Berechtigung enthält. Rollen zuweisen.

    Zur Projektauswahl

  2. Prüfen Sie, ob die Abrechnung für Ihr Google Cloud Projekt aktiviert ist.

  3. Aktivieren Sie die Artifact Registry API und die Google Kubernetes Engine API, falls sie noch nicht aktiviert sind.

    Rollen, die zum Aktivieren von APIs erforderlich sind

    Zum Aktivieren von APIs benötigen Sie die Berechtigung serviceusage.services.enable. Wenn Sie das Projekt erstellt haben, haben Sie diese Berechtigung wahrscheinlich bereits über die Rolle „Inhaber“ (roles/owner). Andernfalls können Sie diese Berechtigung über die Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin) erhalten. Rollen zuweisen.

    APIs aktivieren

  4. Aktivieren Sie Cloud Shell in der Google Cloud Console.

    Cloud Shell aktivieren

  5. Prüfen Sie, ob auf Ihrem Cluster die GKE-Version 1.36.3-gke.1767000 oder höher ausgeführt wird (unterstützt die v1beta1-API).

Umgebungsvariablen definieren

Um die Befehle zu vereinfachen, die Sie in diesem Dokument ausführen, können Sie Umgebungsvariablen in Cloud Shell festlegen. Definieren Sie in Cloud Shell die folgenden nützlichen Umgebungsvariablen, indem Sie die folgenden Befehle ausführen:

export PROJECT_ID=$(gcloud config get project)
export CLUSTER_NAME="agent-sandbox-cluster"
export LOCATION="us-central1"
export CLUSTER_VERSION="1.36.3-gke.1767000"
export NODE_POOL_NAME="agent-sandbox-pool"
export MACHINE_TYPE="e2-standard-2"

Hier eine Erläuterung dieser Umgebungsvariablen:

  • PROJECT_ID: die ID Ihres aktuellen Google Cloud Projekts. Durch das Definieren dieser Variablen wird sichergestellt, dass alle Ressourcen, z. B. Ihr GKE-Cluster, im richtigen Projekt erstellt werden.
  • CLUSTER_NAME: der Name Ihres GKE-Cluster, z. B. agent-sandbox-cluster.
  • LOCATION: die Google Cloud Region oder Zone, in der Ihr GKE Cluster erstellt wird. Legen Sie dies auf die Region (z. B. us-central1) fest, wenn Sie einen Autopilot-Cluster erstellen, oder auf die Zone (z. B. us-central1-a) fest, wenn Sie einen Standard-Cluster erstellen.
  • CLUSTER_VERSION: die Version der GKE, die auf Ihrem Cluster ausgeführt wird (1.36.3-gke.1767000 oder höher).
  • NODE_POOL_NAME: der Name des Knotenpools, in dem Sandbox-Arbeitslasten ausgeführt werden, z. B. agent-sandbox-pool. Diese Variable ist nur erforderlich, wenn Sie einen GKE-Standardcluster erstellen.
  • MACHINE_TYPE: der Maschinentyp der Knoten in Ihrem Knotenpool, z. B. e2-standard-2. Weitere Informationen zu verschiedenen Maschinenserien und zur Auswahl zwischen verschiedenen Optionen finden Sie im Leitfaden zu Ressourcen und Vergleichen für Maschinenfamilien. Diese Variable ist nur erforderlich, wenn Sie einen GKE-Standardcluster erstellen.

Agent Sandbox in der GKE aktivieren

Sie können die Agent Sandbox in der GKE aktivieren, wenn Sie einen neuen Cluster erstellen oder einen vorhandenen Cluster aktualisieren.

Agent Sandbox in der GKE beim Erstellen eines neuen Clusters aktivieren

Für eine vollständig verwaltete Kubernetes-Umgebung empfehlen wir die Verwendung eines Autopilot-Clusters. Informationen zum Auswählen des GKE-Betriebsmodus, der für Ihre Arbeitslasten am besten geeignet ist, finden Sie unter GKE-Betriebsmodus auswählen.

Autopilot

Wenn Sie einen neuen GKE Autopilot-Cluster mit aktivierter Agent Sandbox in der GKE erstellen möchten, fügen Sie das Flag --enable-agent-sandbox hinzu:

gcloud beta container clusters create-auto ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --cluster-version=${CLUSTER_VERSION} \
    --enable-agent-sandbox

Achten Sie bei einem Autopilot-Cluster darauf, dass die Umgebungsvariable LOCATION auf eine Region festgelegt ist (z. B. us-central1).

Standard

Wenn Sie einen neuen GKE-Standardcluster mit aktivierter Agent Sandbox in der GKE erstellen möchten, müssen Sie den Cluster erstellen, einen Knotenpool mit aktiviertem gVisor hinzufügen und dann die Agent Sandbox in der GKE aktivieren. Um Kosten zu sparen, empfehlen wir, einen zonalen Cluster mit einem einzelnen Knoten pro Pool zu erstellen:

  1. Erstellen Sie den Cluster:

    gcloud beta container clusters create ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --num-nodes=1 \
    --cluster-version=${CLUSTER_VERSION}

    Achten Sie bei diesem Standardcluster darauf, dass die Umgebungsvariable LOCATION auf eine Zone festgelegt ist (z. B. us-central1-a).

  2. Erstellen Sie einen separaten Knotenpool mit aktiviertem gVisor:

    gcloud container node-pools create ${NODE_POOL_NAME} \
    --cluster=${CLUSTER_NAME} \
    --machine-type=${MACHINE_TYPE} \
    --location=${LOCATION} \
    --num-nodes=1 \
    --image-type=cos_containerd \
    --sandbox=type=gvisor

    LOCATION muss dieselbe Zone sein, die Sie beim Erstellen des Clusters verwendet haben.

  3. Aktualisieren Sie den Cluster, um die Agent Sandbox in der GKE zu aktivieren:

    gcloud beta container clusters update ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --enable-agent-sandbox

Agent Sandbox in der GKE beim Aktualisieren eines vorhandenen Clusters aktivieren

Wenn Sie die Agent Sandbox in der GKE in einem vorhandenen Cluster aktivieren möchten, muss auf dem Cluster die Version 1.36.3-gke.1767000 oder höher ausgeführt werden, die die v1beta1-API unterstützt.

Achten Sie darauf, dass die Umgebungsvariable LOCATION auf die Region oder Zone festgelegt ist, in der sich Ihr vorhandener Cluster befindet.

  1. Wenn Sie einen GKE-Standardcluster verwenden, basiert die Agent Sandbox in der GKE auf gVisor. Wenn Ihr Standardcluster keinen Knotenpool mit aktiviertem gVisor hat, müssen Sie zuerst einen erstellen:

    gcloud container node-pools create ${NODE_POOL_NAME} \
    --cluster=${CLUSTER_NAME} \
    --machine-type=${MACHINE_TYPE} \
    --location=${LOCATION} \
    --image-type=cos_containerd \
    --sandbox=type=gvisor

  2. Aktualisieren Sie den Cluster, um die Agent Sandbox in der GKE zu aktivieren:

    gcloud beta container clusters update ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --enable-agent-sandbox

Konfiguration prüfen

Sie können prüfen, ob die Agent Sandbox in der GKE aktiviert ist, indem Sie die Clusterbeschreibung untersuchen.

gcloud beta container clusters describe ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --format="value(addonsConfig.agentSandboxConfig.enabled)"

Wenn Sie einen Autopilot-Cluster erstellt haben, ist der Standort die Region (z. B. us-central1). Wenn Sie einen Standardcluster erstellt haben, ist der Standort die Zone (z. B. us-central1-a).

Wenn das Feature erfolgreich aktiviert wurde, gibt der Befehl True zurück.

Bereitstellungsanforderungen für die Agent Sandbox in der GKE

Damit Sie eine Arbeitslast wie Sandbox oder SandboxTemplate, Ihr YAML-Manifest muss bestimmte Sicherheits- und Konfigurationseinstellungen enthalten. Die GKE erzwingt diese Anforderungen mithilfe einer Validating Admission Policy (VAP). Wenn diese Anforderungen nicht erfüllt sind, lehnt der Zulassungscontroller die Bereitstellung ab.

Erforderliche Konfiguration

Ihr Bereitstellungsmanifest muss die folgenden Einstellungen enthalten:

  • runtimeClassName: gvisor: sorgt dafür, dass der Pod in einer gVisor-Sandbox ausgeführt wird.
  • automountServiceAccountToken: false: verhindert, dass das Standarddienstkonto-Token automatisch im Pod bereitgestellt wird.
  • securityContext.runAsNonRoot: true: sorgt dafür, dass der Container nicht als Root-Nutzer ausgeführt wird.
  • securityContext.capabilities.drop: ["ALL"]: entfernt alle Linux-Funktionen aus dem Container.
  • resources.limits: Sie müssen CPU- und Arbeitsspeicherlimits angeben, um potenzielle Denial-of-Service-Szenarien (DoS) zu verhindern.
  • nodeSelector: muss auf sandbox.gke.io/runtime: gvisor ausgerichtet sein.
  • tolerations: muss eine Toleranz für die Markierung sandbox.gke.io/runtime=gvisor:NoSchedule enthalten.

Verbotene Konfiguration

Ihr Bereitstellungsmanifest darf keine der folgenden Einstellungen enthalten:

  • hostNetwork: true, hostPID: true oder hostIPC: true.
  • privileged: true in Container-Sicherheitskontexten.
  • HostPath-Volumes.
  • Hinzugefügte Funktionen (capabilities.add).
  • hostPort-Einstellungen.
  • Benutzerdefinierte Sysctls.
  • Projizierte Volumes für Dienstkonto-Tokens oder Zertifikate.

Sandbox-Umgebung bereitstellen

Wir empfehlen, eine Sandbox-Umgebung bereitzustellen, indem Sie eine SandboxTemplate definieren und vorgewärmte Instanzen mit einem SandboxWarmPool bereithalten. Anschließend können Sie mit einem SandboxClaim eine Instanz aus diesem vorgewärmten Knotenpool anfordern. Alternativ können Sie direkt eine Sandbox erstellen. Dieser Ansatz unterstützt jedoch keine vorgewärmten Pools.

SandboxTemplate, SandboxWarmPool, SandboxClaim und Sandbox sind benutzerdefinierte Kubernetes-Ressourcen.

Das SandboxTemplate dient als wiederverwendbarer Entwurf. Der SandboxWarmPool sorgt dafür, dass immer eine bestimmte Anzahl vorgewärmter Pods ausgeführt wird und bereit ist, angefordert zu werden. Durch die Verwendung dieser benutzerdefinierten Ressource wird die Startlatenz minimiert.

So stellen Sie eine Sandbox-Umgebung bereit, indem Sie das SandboxTemplate und den SandboxWarmPool erstellen:

  1. Erstellen Sie in Cloud Shell eine Datei namens sandbox-template.yaml mit folgendem Inhalt:

    apiVersion: extensions.agents.x-k8s.io/v1beta1
kind: SandboxTemplate
metadata:
  name: python-runtime-template
  namespace: default
spec:
  podTemplate:
    metadata:
      labels:
        sandbox-type: python-runtime
    spec:
      runtimeClassName: gvisor # Required
      automountServiceAccountToken: false # Required
      securityContext:
        runAsNonRoot: true # Required
      nodeSelector:
        sandbox.gke.io/runtime: gvisor # Required
      tolerations:
      - key: "sandbox.gke.io/runtime"
        value: "gvisor"
        effect: "NoSchedule" # Required
      containers:
      - name: runtime
        image: registry.k8s.io/agent-sandbox/python-runtime-sandbox:v0.1.0
        ports:
        - containerPort: 8888
        resources:
          requests:
            cpu: "250m"
            memory: "512Mi"
          limits:
            cpu: "500m"
            memory: "1Gi" # Required
        securityContext:
          capabilities:
            drop: ["ALL"] # Required
      restartPolicy: OnFailure

  2. Wenden Sie das SandboxTemplate-Manifest an:

    kubectl apply -f sandbox-template.yaml

  3. Erstellen Sie eine Datei namens sandbox-warmpool.yaml mit folgendem Inhalt:

    apiVersion: extensions.agents.x-k8s.io/v1beta1
kind: SandboxWarmPool
metadata:
  name: python-runtime-warmpool
  namespace: default
  labels:
    app: python-runtime-warmpool
spec:
  replicas: 2
  sandboxTemplateRef:
    # This must match the name of the SandboxTemplate.
    name: python-runtime-template

  4. Wenden Sie das SandboxWarmPool-Manifest an:

    kubectl apply -f sandbox-warmpool.yaml

SandboxClaim erstellen

Mit dem SandboxClaim wird eine Sandbox aus dem vorgewärmten Pool angefordert. Da Sie einen vorgewärmten Pool erstellt haben, übernimmt die erstellte Sandbox einen ausgeführten Pod aus dem Pool, anstatt einen neuen Pod zu starten.

So fordern Sie eine Sandbox aus dem vorgewärmten Pool an, indem Sie einen SandboxClaim erstellen:

  1. Erstellen Sie eine Datei namens sandbox-claim.yaml mit folgendem Inhalt:

    apiVersion: extensions.agents.x-k8s.io/v1beta1
kind: SandboxClaim
metadata:
  name: sandbox-claim
  namespace: default
spec:
  warmPoolRef:
    # This must match the name of the SandboxWarmPool.
    name: python-runtime-warmpool

  2. Wenden Sie das SandboxClaim-Manifest an:

    kubectl apply -f sandbox-claim.yaml

  3. Prüfen Sie, ob die Sandbox, der Claim und der vorgewärmte Pool bereit sind:

    kubectl get sandboxwarmpool,sandboxclaim,sandbox,pod

Alternative: Sandbox direkt erstellen

Wenn Sie die schnellen Startzeiten, die durch vorgewärmte Pools bereitgestellt werden, nicht benötigen, können Sie eine Sandbox direkt bereitstellen, ohne Vorlagen zu verwenden.

So stellen Sie eine Sandbox-Umgebung bereit, indem Sie direkt eine Sandbox erstellen:

  1. Erstellen Sie eine Datei namens sandbox.yaml mit folgendem Inhalt:

    apiVersion: agents.x-k8s.io/v1beta1
kind: Sandbox
metadata:
  name: sandbox-example-2
spec:
  replicas: 1
  podTemplate:
    metadata:
      labels:
        sandbox: sandbox-example
    spec:
      runtimeClassName: gvisor
      restartPolicy: OnFailure
      automountServiceAccountToken: false # Required
      securityContext:
        runAsNonRoot: true # Required
        runAsUser: 1000 # Required if image defaults to root (e.g. busybox)
      nodeSelector:
        sandbox.gke.io/runtime: gvisor
      tolerations:
      - key: "sandbox.gke.io/runtime"
        value: "gvisor"
        effect: "NoSchedule" # Required
      containers:
      - name: my-container
        image: busybox
        command: ["/bin/sh", "-c"]
        args: ["sleep 3600000; echo 'Container finished successfully'; exit 0"]
        securityContext:
          capabilities:
            drop: ["ALL"] # Required
          allowPrivilegeEscalation: false
        resources:
          limits:
            cpu: "100m"
            memory: "128Mi" # Required

  2. Wenden Sie das Sandbox-Manifest an:

    kubectl apply -f sandbox.yaml

  3. Prüfen Sie, ob die Sandbox ausgeführt wird:

    kubectl get sandbox

Agent Sandbox in der GKE von v1alpha1 zu v1beta1 migrieren

Wenn Ihr Cluster mit einer früheren Version der Agent Sandbox in der GKE mithilfe von benutzerdefinierten v1alpha1-Ressourcen bereitgestellt wurde, können Sie ein Upgrade auf die GKE-Version 1.36.3-gke.1767000 oder höher mit nahezu null Ausfallzeiten für Arbeitslasten durchführen.

Hinweis: Dieses Migrationsverfahren gilt für Cluster, die das verwaltete Feature „Agent Sandbox in der GKE“ verwenden (--enable-agent-sandbox). Wenn Sie die Agent Sandbox mit Open-Source-Manifesten bereitgestellt haben, lesen Sie die Migrationsanleitung für Upstream.

Wichtigste API-Unterschiede zwischen v1alpha1 und v1beta1

Konzept v1alpha1-Verhalten v1beta1-Verhalten Auswirkungen der Migration
SandboxClaim-Ziele Direkter Verweis auf SandboxTemplate ohne vorgewärmten Pool zulässig (Kaltstart). Erfordert einen Verweis auf einen SandboxWarmPool (spec.warmPoolRef.name). Kaltstart-Claims müssen einem Schatten-Warmpool zugeordnet werden (replicas: 0).
Sandbox-Betriebsmodus Wird aus Replikaten oder Statusfeldern abgeleitet. Expliziter Wert für das Feld spec.operatingMode (z. B. Running oder Suspended). Der Conversion-Webhook ordnet dieses Feld automatisch zu und legt es fest.
Speicherversion der CustomResourceDefinition v1alpha1 in etcd gespeichert (storage: true). v1beta1 in etcd gespeichert (storage: true). Webhook konvertiert dynamisch; nach dem Upgrade werden etcd-Objekte noch einmal gespeichert.
Conversion-Webhook Keine. Aktiv unter /convert (Port 9447). Bidirektionale Konvertierung zwischen v1alpha1 und v1beta1.

Mit dem Migrationstool migrieren

Verwenden Sie das kanonische Migrationsskript aus dem Agent Sandbox-Repository, um automatisch Schatten-Warmpools zu erstellen und nichtflüchtigen Speicher noch einmal zu speichern.

Skript herunterladen und vorbereiten:

curl -LO https://raw.githubusercontent.com/kubernetes-sigs/agent-sandbox/v0.5.6/helm/files/migrate.sh
chmod +x migrate.sh

Detaillierte Anleitung für die Migration

Wenn Sie einen vorhandenen Cluster mit nahezu null Ausfallzeiten für Arbeitslasten migrieren möchten, führen Sie die folgenden drei Phasen in der angegebenen Reihenfolge aus:

Phase 1: Bootstrap-Phase vor dem Upgrade

  1. Vorhandene Ressourcen sichern:Speichern Sie eine YAML-Sicherung Ihrer deklarativen Agent Sandbox in der GKE-Ressourcen (sandboxtemplates, sandboxwarmpools und sandboxclaims):

    kubectl get sandboxtemplates,sandboxwarmpools,sandboxclaims \
    --all-namespaces -o yaml > agent-sandbox-v1alpha1-backup.yaml

  2. Sicherheitskonformität der Vorlage prüfen: Achten Sie darauf, dass die vorhandenen SandboxTemplate Ressourcen die Bereitstellungsanforderungen für die Agent Sandbox in der GKE erfüllen. Während der Speichermigration in Phase 3 lehnt der Zulassungscontroller Aktualisierungen an Vorlagen ab, die diesen Sicherheitsrichtlinien nicht entsprechen.

  3. Vorschau der zu erstellenden Schattenpools ansehen:

    ./migrate.sh --phase=bootstrap --dry-run

  4. Bootstrap-Phase ausführen:

    ./migrate.sh --phase=bootstrap

  5. Erstellte Schattenpools prüfen:

    kubectl get sandboxwarmpools --all-namespaces \
    -o custom-columns="NAMESPACE:.metadata.namespace,NAME:.metadata.name,REPLICAS:.spec.replicas,SHADOW:.metadata.annotations.agents\.x-k8s\.io/migration-shadow"

Phase 2: GKE-Steuerungsebene aktualisieren

Aktualisieren Sie die GKE-Steuerungsebene auf Version 1.36.3-gke.1767000 oder höher:

gcloud container clusters upgrade ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --master \
    --cluster-version=1.36.3-gke.1767000

Beachten Sie während der Einführung der Steuerungsebene Folgendes:

  • Bei Pods gibt es keine Neustarts oder Ausfallzeiten.
  • Der neue Controller und der /convert-Webhook-Endpunkt werden auf der Steuerungsebene bereitgestellt.

Phase 3: Speichermigration nach dem Upgrade

Aktualisieren Sie nach Abschluss des Upgrades der Steuerungsebene Ihre Anmeldedaten und schreiben Sie die gespeicherten etcd-Objekte neu, indem Sie die Speichermigrationsphase ausführen:

./migrate.sh --phase=migrate

Checkliste für die Überprüfung nach der Migration

Element prüfen Befehl Erwartetes Ergebnis
Speicherversionen der CustomResourceDefinition kubectl get crd sandboxes.agents.x-k8s.io sandboxclaims.extensions.agents.x-k8s.io sandboxtemplates.extensions.agents.x-k8s.io sandboxwarmpools.extensions.agents.x-k8s.io -o jsonpath='{range .items[*]}{.metadata.name}{": storedVersions="}{.status.storedVersions}{"\n"}{end}' Für alle vier CustomResourceDefinitions wird Folgendes angezeigt:
storedVersions=["v1beta1"]
Pod-Kontinuität kubectl get pods -n default -o wide Status: 1/1 Running
Restarts: 0
(gilt für Cluster mit aktiven Sandboxen)
Claim-Bindung kubectl get sandboxclaims -n default -o yaml spec.warmPoolRef.name: shadow-pool-...
status.conditions: Ready=True (erfordert, dass die Vorlage den Zulassungsanforderungen entspricht)
`v1alpha1`-Kompatibilität kubectl get sandboxes.v1alpha1.agents.x-k8s.io Zeigt eine Warnung zur Einstellung an und gibt die Ressource zurück
Native CRUD für `v1beta1` kubectl apply -f sandbox-claim.yaml Wird ohne Warnungen angewendet

Wenn in einer CustomResourceDefinition nach Abschluss der Migrationsphase weiterhin ["v1alpha1", "v1beta1"] in .status.storedVersions aufgeführt ist, ist dies das erwartete Kubernetes-Verhalten. Das Migrationsskript schreibt alle vorhandenen Einträge in etcd in v1beta1 um, aber Kubernetes entfernt veraltete Versionen nicht automatisch aus der Liste status.storedVersions.

Nachdem Sie bestätigt haben, dass alle Ressourcen migriert wurden, können Sie v1alpha1 optional aus den gespeicherten Versionen entfernen:

for crd in \
    sandboxes.agents.x-k8s.io \
    sandboxclaims.extensions.agents.x-k8s.io \
    sandboxtemplates.extensions.agents.x-k8s.io \
    sandboxwarmpools.extensions.agents.x-k8s.io; do
  kubectl patch crd "${crd}" --subresource=status --type=merge \
    -p '{"status":{"storedVersions":["v1beta1"]}}'
done

Probleme bei der Migration beheben

Wenn nach dem Upgrade der Steuerungsebene oder der Ausführung der Speichermigration Probleme auftreten, beheben Sie sie, anstatt zu versuchen, ein Downgrade der Steuerungsebene durchzuführen:

  • Claim bleibt in WarmPoolNotFound hängen:

    • Wenn ein v1alpha1-Claim für den Kaltstart ohne Ausführung von ./migrate.sh --phase=bootstrap aktualisiert wurde, erstellen Sie den fehlenden Schatten-Warmpool manuell:

      apiVersion: extensions.agents.x-k8s.io/v1beta1
kind: SandboxWarmPool
metadata:
  name: shadow-pool-TEMPLATE_NAME
  namespace: NAMESPACE
  annotations:
    agents.x-k8s.io/migration-shadow: "true"
spec:
  replicas: 0
  sandboxTemplateRef:
    name: TEMPLATE_NAME

    • Wenn ein Claim einen bestimmten Warmpool benannt hat, der nicht mehr vorhanden ist, erstellen Sie die fehlende SandboxWarmPool-Ressource mit diesem Namen oder aktualisieren Sie spec.warmPoolRef.name im Claim, um auf einen vorhandenen Warmpool zu verweisen.

  • Claim-Bedingung Ready=False: Führen Sie kubectl describe sandboxclaim aus, um die Ereignisse im Claim zu prüfen. Achten Sie darauf, dass das referenzierte SandboxTemplate alle Bereitstellungsanforderungen für die Agent Sandbox in der GKE erfüllt, und wenden Sie die Vorlage bei Bedarf noch einmal an.

  • Konvertierungs- oder Controllerfehler: Prüfen Sie, ob die Lease für die Leaderwahl der Steuerungsebene aktiv ist, indem Sie kubectl get leases -n gke-managed-agentsandbox ausführen. Wenn die Probleme weiterhin auftreten, wenden Sie sich an Cloud Customer Care.

Agent Sandbox in der GKE deaktivieren

Verwenden Sie den Befehl gcloud beta container clusters update mit dem Flag --no-enable-agent-sandbox, um die Agent Sandbox in der GKE zu deaktivieren.

gcloud beta container clusters update ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --no-enable-agent-sandbox

Wenn Sie einen Autopilot-Cluster erstellt haben, ist der Standort die Region (z. B. us-central1). Wenn Sie einen Standardcluster erstellt haben, ist der Standort die Zone (z. B. us-central1-a).

Ressourcen bereinigen

Löschen Sie den erstellten GKE-Cluster, damit Ihrem Google Cloud Konto keine Gebühren in Rechnung gestellt werden.

gcloud container clusters delete $CLUSTER_NAME \
    --location=${LOCATION} \
    --quiet

Wenn Sie einen Autopilot-Cluster erstellt haben, ist der Standort die Region (z. B. us-central1). Wenn Sie einen Standardcluster erstellt haben, ist der Standort die Zone (z. B. us-central1-a).

Nächste Schritte