Kapazitätsreserven konfigurieren

Kapazitätsreserven verbessern die Reaktionsfähigkeit und Zuverlässigkeit kritischer Arbeitslasten, indem sie die Reservekapazität des Clusters und die angehaltenen Status der vorab bereitgestellten und vorkonfigurierten Kapazität mithilfe einer Kubernetes-CustomResourceDefinition (CRD) für CapacityBuffer proaktiv verwalten. Mit Kapazitätsreserven können Sie explizit eine bestimmte Menge an ungenutzter Knotenkapazität in Ihrem Cluster definieren. Diese reservierte Kapazität trägt dazu bei, die Planungszeit für Pods zu verkürzen.

Wenn eine Arbeitslast mit hoher Priorität schnell skaliert werden muss, kann die neue Arbeitslast die leere Kapazität sofort nutzen, ohne auf die Knotenbereitstellung warten zu müssen. Dieser Ansatz minimiert die Latenz und vermeidet Ressourcenkonflikte bei plötzlichen Nachfragespitzen.

Auf dieser Seite werden Methoden zum Konfigurieren von Kapazitätspuffern beschrieben: ein Puffer mit einer festen Anzahl von Replikaten, ein Puffer mit Ressourcenlimits und ein prozentualer Puffer.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.
  • Sie müssen einen GKE-Cluster mit Version 1.35.2-gke.1842000 für aktive Puffer und Version 1.36.0-gke.2253000 oder höher für Standby-Puffer erstellen oder darauf zugreifen können.
  • Aktivieren Sie die automatische Knotenbereitstellung für Ihre Standardcluster. In Autopilot-Clustern ist die automatische Knotenbereitstellung bereits aktiviert. Die automatische Knotenbereitstellung ist für aktive Puffer optional, wird aber empfohlen. Für Standby-Puffer ist sie erforderlich.

Erforderliche Kubernetes-Objekte erstellen

Zum Konfigurieren eines CapacityBuffer benötigen Sie einen Namespace, der alle erforderlichen Objekte enthält (den CapacityBuffer selbst und zusätzliche Ressourcen wie ein PodTemplate oder eine Arbeitslast). PodTemplate und CapacityBuffer müssen sich im selben Namespace befinden. Sie können einen Namespace erstellen oder einen vorhandenen Namespace verwenden, einschließlich des Namespace default.

Je nachdem, welchen Typ von CapacityBuffer Sie konfigurieren, benötigen Sie auch eine der folgenden Optionen:

  • PodTemplate: Definiert die Ressourcenanforderungen für eine einzelne Einheit der Pufferkapazität. Die im CapacityBuffer-Objekt angegebene Konfiguration verweist auf die Pod-Vorlage.

  • Arbeitslast: Eine vorhandene Arbeitslast, auf die Sie im CapacityBuffer-Objekt verweisen. In diesem Leitfaden wird ein Deployment-Objekt als Beispielarbeitslast verwendet. Kapazitätsreserven unterstützen jedoch alle der folgenden Ressourcentypen:

    • Bereitstellung
    • ReplicaSet
    • StatefulSet
    • ReplicationController
    • Job

    • CustomResourceDefinitions (CRDs), die die Unterressource scale implementieren.

In diesem Abschnitt finden Sie Beispiele für diese Objekte. Wenn Sie bereits eine Arbeitslast haben, die Sie mit einem Kapazitäts-Puffer konfigurieren möchten, fahren Sie mit Kapazitäts-Puffer anwenden fort.

So erstellen Sie eine Kubernetes-Beispielarbeitslast:

  1. Speichern Sie das folgende Manifest als namespace.yaml:

    apiVersion: v1
kind: Namespace
metadata:
  name: capacity-buffer-example
  labels:
    name: capacity-buffer-example

    Mit diesem Manifest wird ein Namespace namens capacity-buffer-example erstellt.

  2. Optional: Wenn Sie Kapazitätspuffer mit einer benutzerdefinierten Compute-Klasse verwenden möchten, speichern Sie das folgende Manifest als custom-compute-class.yaml:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: ccc-example
  namespace: capacity-buffer-example
spec:
  # Buffers are also created according to these priorities
  priorities:
  - machineFamily: n4
  - machineFamily: n4d
  - machineFamily: c4
  - machineFamily: c4d
  nodePoolAutoCreation:
    enabled: true

    Dieses Manifest erstellt eine benutzerdefinierte ComputeClass, die die Computing-Prioritäten für die von GKE bereitgestellten Knoten definiert und steuert. Weitere Informationen finden Sie unter Benutzerdefinierte Compute-Klassen.

  3. Speichern Sie das folgende Manifest als buffer-pod-template.yaml:

    apiVersion: v1
kind: PodTemplate
metadata:
  name: buffer-unit-template
  namespace: capacity-buffer-example # the namespace must be the same namespace as the CapacityBuffer
template:
  spec:
    terminationGracePeriodSeconds: 0
    containers:
    - name: buffer-container
      image: registry.k8s.io/pause:3.9
      resources:
        requests:
          cpu: "1"
          memory: "1Gi"
        limits:
          cpu: "1"
          memory: "1Gi"
    # Optional: Using buffers with a custom ComputeClass /
    # controls the properties of the provisioned nodes.
    nodeSelector:
      cloud.google.com/compute-class: ccc-example

    Mit diesem Manifest wird ein PodTemplate erstellt, das die Ressourcenanforderungen für eine einzelne Einheit der Pufferkapazität (1 CPU und 1Gi Arbeitsspeicher) definiert. Mit dieser Konfiguration wird die Größe der Kapazitätseinheiten angegeben, die GKE für den Puffer bereitstellt. Mit diesem PodTemplate berücksichtigt GKE beispielsweise keine Knoten mit weniger als 1 CPU und 1 GiB verfügbarer Ressourcen als Teil des Puffers, wenn der Cluster skaliert wird.

  4. Speichern Sie das folgende Manifest als sample-workload-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: critical-workload-ref
  namespace: capacity-buffer-example # the namespace must be the same namespace as the CapacityBuffer
spec:
  replicas: 10
  selector:
    matchLabels:
      app: critical-workload
  template:
    metadata:
      labels:
        app: critical-workload
    spec:
      containers:
      - name: busybox
        image: busybox
        command: ["sleep", "3600"]
        resources:
          requests:
            cpu: 100m
      # Optional: Using buffers with a custom ComputeClass /
      # controls the properties of the provisioned nodes.
      nodeSelector:
        cloud.google.com/compute-class: ccc-example

    Mit diesem Manifest wird ein Beispiel-Deployment mit 10 Replikaten erstellt. Dies ist das Referenzobjekt für das prozentuale Pufferbeispiel im nächsten Abschnitt.

  5. Wenden Sie die Manifeste auf Ihren Cluster an:

    kubectl apply -f namespace.yaml -f custom-compute-class.yaml -f buffer-pod-template.yaml -f sample-workload-deployment.yaml

  6. Prüfen Sie, ob GKE die Objekte erstellt hat:

    kubectl get podtemplate -n capacity-buffer-example
kubectl get deployment critical-workload-ref -n capacity-buffer-example

    Die Ausgabe sieht etwa so aus:

    NAME                   AGE
buffer-unit-template   1m

NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
critical-workload-ref   10/10   10           10          1m

Kapazitätspuffer anwenden

In diesem Abschnitt finden Sie Beispiele für die verschiedenen Arten von Kapazitätsreserven, die Sie auf Ihre Arbeitslasten anwenden können.

Puffer für feste Replikate konfigurieren

Wenn Sie einen CapacityBuffer mit festen Replikaten konfigurieren, geben Sie die genaue Anzahl der Puffer-Einheiten an, die Sie basierend auf einem PodTemplate benötigen.

So erstellen Sie einen Puffer mit einer festen Anzahl von Replikaten:

  1. Speichern Sie das folgende Manifest als cb-fixed-replicas.yaml:

    apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: fixed-replica-buffer
  namespace: NAMESPACE
spec:
  podTemplateRef:
    name: POD_TEMPLATE
  replicas: 3
  provisioningStrategy: "STRATEGY"

    Ersetzen Sie Folgendes:

    • NAMESPACE: Der Name Ihres Namespace, z. B. capacity-buffer-example.
    • POD_TEMPLATE: die Pod-Vorlage, die Ihre Ressourcenanforderungen definiert, z. B. buffer-unit-template.
    • STRATEGY: die Bereitstellungsstrategie, entweder "buffer.x-k8s.io/active-capacity" (Standard) oder "buffer.gke.io/standby-capacity".

    Mit diesem Manifest wird eine CapacityBuffer-Ressource erstellt, die auf ein PodTemplate verweist, um eine bestimmte Anzahl von Puffereinheiten anzufordern.

  2. Wenden Sie das Manifest an:

    kubectl apply -f cb-fixed-replicas.yaml

  3. Prüfen Sie, ob GKE den Kapazitätspuffer angewendet hat:

    kubectl get capacitybuffer fixed-replica-buffer -n NAMESPACE

    Im Feld replicas im Status sollte 3 angezeigt werden. Das entspricht der Anzahl der Replikate, die Sie im Manifest definiert haben. Im Feld STATUS sollte ReadyForProvisioning angezeigt werden.

Puffer für Ressourcenlimits konfigurieren

Mit dem Feld limits können Sie eine maximale Menge an Ressourcen definieren, die der Puffer verbrauchen soll. Diese wird anhand der Größe Ihrer PodTemplate berechnet.

So erstellen Sie einen Puffer für Ressourcenlimits:

  1. Speichern Sie das folgende Manifest als cb-resource-limits.yaml:

    apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: resource-limit-buffer
  namespace: NAMESPACE
spec:
  podTemplateRef:
    name: POD_TEMPLATE
  limits:
    cpu: "5"
    memory: "5Gi"
  provisioningStrategy: "STRATEGY"

    Ersetzen Sie Folgendes:

    • NAMESPACE: Der Name Ihres Namespace, z. B. capacity-buffer-example.
    • POD_TEMPLATE: die Pod-Vorlage, die Ihre Ressourcenanforderungen definiert, z. B. buffer-unit-template.
    • STRATEGY: die Bereitstellungsstrategie, entweder "buffer.x-k8s.io/active-capacity" (Standard) oder "buffer.gke.io/standby-capacity".

    Mit diesem Manifest wird eine CapacityBuffer-Ressource mit einem Gesamtlaufzeitlimit von 5 CPUs und 5 GiB Arbeitsspeicher erstellt. Wenn Sie das PodTemplate-Beispiel aus dem vorherigen Schritt verwenden, definieren Sie jede Einheit als 1 CPU und 1Gi Arbeitsspeicher, was zu 5 Puffereinheiten führen sollte.

  2. Wenden Sie das Manifest an:

    kubectl apply -f cb-resource-limits.yaml

  3. Prüfen Sie, ob GKE den Kapazitätspuffer angewendet hat:

    kubectl get capacitybuffer resource-limit-buffer -n NAMESPACE

    Prüfen Sie den Status von CapacityBuffer. Im Feld replicas sollte ein Wert angezeigt werden, der aus den von Ihnen definierten Limits abgeleitet wird. Wenn Sie das PodTemplate-Beispiel aus dem vorherigen Abschnitt verwenden, sollten Sie 5 Puffereinheiten sehen, da dies die maximale Anzahl von Einheiten ist, die in die definierten Grenzwerte passen.

Prozentualen Puffer konfigurieren

Wenn Sie einen prozentualen Puffer konfigurieren, wird die Größe des Puffers dynamisch auf Grundlage eines Prozentsatzes einer vorhandenen skalierbaren Arbeitslast festgelegt. Prozentuale Kapazitätsreserven werden nur für skalierbare Kubernetes-Objekte unterstützt, die die Scale-Unterressource implementieren, z. B. Deployments, StatefulSets, ReplicaSets oder Jobs. Sie können keinen prozentualen Puffer für Pod-Vorlagen definieren, da sie kein replicas-Feld haben.

Wir empfehlen in der Regel, mit Strategien für feste Replikate oder Ressourcenlimits zu beginnen und nicht mit prozentualen Puffern. Prozentuale Puffer reagieren weniger auf plötzliche Skalierungen, wenn die Arbeitslast auf niedrige Zahlen oder null skaliert wird, da der Sicherheitsspielraum proportional zu den aktiven Pods skaliert wird. Sie sind hauptsächlich für große Bereitstellungen nützlich, die nie auf eine sehr geringe Anzahl von Replikaten skaliert werden.

So erstellen Sie einen prozentualen Puffer:

  1. Speichern Sie das folgende Manifest als cb-percentage-based.yaml:

    apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: percentage-buffer
  namespace: NAMESPACE
spec:
  scalableRef:
    apiGroup: apps
    kind: Deployment
    name: SCALABLE_RESOURCE_NAME
  percentage: 20
  provisioningStrategy: "STRATEGY"

    Ersetzen Sie Folgendes:

    • NAMESPACE: Der Name Ihres Namespace.
    • SCALABLE_RESOURCE_NAME: Der Name der skalierbaren Ressource, z. B. critical-workload-ref.
    • STRATEGY: die Bereitstellungsstrategie, entweder "buffer.x-k8s.io/active-capacity" (Standard) oder "buffer.gke.io/standby-capacity".

    Mit diesem Manifest wird eine CapacityBuffer-Ressource erstellt, die eine Puffergröße anfordert, die 20% der Replikate der referenzierten Ressource entspricht. Wenn Sie das Bereitstellungsbeispiel aus dem vorherigen Abschnitt verwenden, wird der Replikatwert auf 10 festgelegt.

  2. Wenden Sie das Manifest an:

    kubectl apply -f cb-percentage-based.yaml

  3. Prüfen Sie, ob GKE den Kapazitätspuffer angewendet hat:

    kubectl get capacitybuffer percentage-buffer -n NAMESPACE

    Prüfen Sie den Status von CapacityBuffer. Im Feld replicas sollte ein Wert aus der Prozentberechnung angezeigt werden. Wenn Sie das Bereitstellungsbeispiel aus dem vorherigen Abschnitt verwenden, sollten Sie 2 Puffereinheiten sehen. Das sind 20% der 10 Replikate, die in der Bereitstellung definiert sind.

  4. Testen Sie die dynamische Skalierung, indem Sie das Deployment manuell auf 20 Replikate hochskalieren:

    kubectl scale deployment critical-workload-ref -n NAMESPACE --replicas=20

    Der CapacityBuffer-Controller reagiert und skaliert den Puffer automatisch auf vier Replikate.

Standby-Puffer anpassen

Mit Annotationen können Sie anpassen, wie Standby-Puffer gestartet und aktualisiert werden. Fügen Sie dem Feld metadata.annotations Ihrer CapacityBuffer-Ressource die folgenden Annotationen hinzu:

  • buffer.gke.io/standby-capacity-init-time: Die Zeitdauer, die ein Knoten nach der Erstellung aktiv bleibt, bevor er gesperrt wird. Das Format ist ein Dauerstring (z. B. 5m oder 1h). Der Standardwert ist 5m.
  • buffer.gke.io/standby-capacity-refresh-frequency: wie oft angehaltene Knoten aktualisiert werden. Der Standardwert ist 24h.

Das folgende Beispiel zeigt ein Manifest mit diesen optionalen Feldern zum Anpassen des Verhaltens von Standby-Puffern:

apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: customized-standby-buffer
  namespace: my-namespace
  annotations:
    buffer.gke.io/standby-capacity-init-time: "15m"
    buffer.gke.io/standby-capacity-refresh-frequency: "12h"
spec:
  podTemplateRef:
    name: buffer-unit-template
  replicas: 3
  provisioningStrategy: "buffer.gke.io/standby-capacity"

Bilder in Standby-Puffern vorab laden

Um die Startzeiten von Arbeitslasten zu verkürzen, wenn ein Standby-Knoten reaktiviert wird, können Sie Container-Images mit einem DaemonSet vorab laden. Das DaemonSet wird während der Startphase ausgeführt, bevor der Knoten angehalten wird.

So laden Sie Bilder mithilfe des DaemonSet vor:

  1. Speichern Sie das folgende Manifest als image-puller-daemonset.yaml:

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: image-prefetch-daemonset
  namespace: NAMESPACE
spec:
  selector:
    matchLabels:
      name: image-prefetch
  template:
    metadata:
      labels:
        name: image-prefetch
    spec:
      tolerations:
      - key: "buffer.gke.io/standby-node-suspended"
        operator: "Exists"
      initContainers:
      - name: image-puller
        image: IMAGE_NAME
        command: ["sh", "-c", "true"]
      containers:
      - name: pause
        image: registry.k8s.io/pause:3.9

    Ersetzen Sie Folgendes:

    • NAMESPACE: der Namespace für das DaemonSet, z. B. capacity-buffer-example.
    • IMAGE_NAME: Der Name des vorzuladenden Bildes, z. B. your-app-image:latest.

  2. Wenden Sie das DaemonSet-Manifest auf Ihren Cluster an:

    kubectl apply -f image-puller-daemonset.yaml

  3. Prüfen Sie, ob das DaemonSet erstellt wurde:

    kubectl get daemonset image-prefetch-daemonset -n NAMESPACE

  4. Prüfen Sie, ob Ihr Kapazitätsbuffer erstellt wurde und für die Bereitstellung bereit ist:

    kubectl get capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE

    Prüfen Sie den Status. Im Feld STATUS sollte ReadyForProvisioning angezeigt werden.

Status des Kapazitätsbuffers und Leistung überwachen

Sie können den Status und die Integrität Ihrer Kapazitätspuffer mit kubectl-Befehlen und Cloud Monitoring-Messwerten überwachen.

Status der CapacityBuffer-Ressource prüfen

So prüfen Sie den Zustand Ihrer Kapazitätspuffer und stellen sicher, dass sie für die Verarbeitung von Arbeitslasten bereit sind:

  1. Rufen Sie den Status aller Kapazitätspuffer im Cluster ab:

    kubectl get capacitybuffer -A

  2. So rufen Sie den detaillierten Status, die Bedingungen und die Ereignisprotokolle eines bestimmten Puffers auf:

    kubectl describe capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE

Gesperrte Standby-Pufferknoten identifizieren

Standby-Puffer-VMs werden vorab bereitgestellt, aber angehalten, um Kosten zu senken. Sie erkennen diese gesperrten Knoten daran, dass sie einen benutzerdefinierten Zustand haben. Führen Sie den folgenden Befehl aus, um gesperrte Knoteninstanzen zu prüfen:

kubectl get nodes -o custom-columns='NAME:.metadata.name,SUSPENDED:.status.conditions[?(@.type=="Suspended")].status'

Der Status True gibt an, dass eine Standby-VM angehalten ist. Der Status False oder <none> gibt einen aktiven, ausgeführten Knoten an.

Leistung mit Cloud Monitoring überwachen

Um die Leistung von Kapazitätsreserven zu überwachen, sollten Sie die folgenden Ressourcen in Cloud Monitoring im Blick behalten:

  • Reaktionslatenz (cluster_autoscaler/reaction_time_milliseconds): Gibt die Dauer an, die der Cluster Autoscaler benötigt, um eine Skalierungsentscheidung basierend auf der ausstehenden Nachfrage Ihres CapacityBuffer zu treffen.
  • Cluster Autoscaler-Logs: Suchen Sie nach Logeinträgen wie "Capacity pod processor injecting ...", um Ereignisse zum Ersetzen aktiver Puffer-Pods zu beobachten.

Kapazitätsreserven entfernen

Wenn Sie keinen Kapazitätspuffer mehr für Ihre Arbeitslasten benötigen, löschen Sie das CapacityBuffer-Objekt. Dadurch werden die Platzhalter-Pods entfernt und Cluster Autoscaler kann die Knoten herunterskalieren.

kubectl delete capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE

Ersetzen Sie CAPACITY_BUFFER_NAME durch den Namen des CapacityBuffer, den Sie löschen möchten.

Fehlerbehebung

Im folgenden Abschnitt finden Sie Informationen zur Behebung häufiger Probleme mit Kapazitätsreserven.

Kapazitätsreserve aufgrund des Abrechnungsmodells nicht verfügbar

Wenn Sie einen CapacityBuffer für eine Arbeitslast erstellen, für die das Pod-basierte Abrechnungsmodell (Abrechnung pro Pod) verwendet wird, kann der CapacityBuffer nicht bereitgestellt werden.

So finden Sie heraus, wo das Problem liegt:

kubectl describe capacitybuffer BUFFER_NAME -n NAMESPACE

Suchen Sie nach einer Bedingung vom Typ ReadyForProvisioning mit dem Status False.

Achten Sie zur Behebung dieses Problems darauf, dass Ihr CapacityBuffer auf eine Arbeitslast oder ein PodTemplate verweist, das mit der knotenbasierten Abrechnung kompatibel ist.

Berechtigungsfehler für benutzerdefinierte skalierbare Ressourcen

Wenn Sie einen CapacityBuffer für die Verwendung mit benutzerdefinierten skalierbaren Objekten konfigurieren (mit dem Feld scalableRef), kann der Cluster Autoscaler den Puffer möglicherweise nicht skalieren, wenn er nicht die erforderlichen Berechtigungen hat. Dieses Problem tritt nur in GKE-Versionen vor 1.36.0-gke.2459000 auf.

Um dieses Problem zu beheben, müssen Sie die erforderlichen Berechtigungen manuell gewähren, indem Sie eine ClusterRole und eine ClusterRoleBinding erstellen, wie im folgenden Beispiel:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: custom-scale-getter
rules:
- apiGroups: ["api.example.com"]
  resources: ["customreplicatedresources/scale"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ca-custom-scale-getter
subjects:
- kind: User
  name: "system:cluster-autoscaler"
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: custom-scale-getter

Weitere Informationen zum Konfigurieren von RBAC finden Sie in der Kubernetes-RBAC-Dokumentation.

Buffer-Pods werden nicht auf Knoten geplant, die von benutzerdefinierten ComputeClasses bereitgestellt werden.

Wenn in Ihrer CapacityBuffer-Konfigurationsabhängigkeit (z. B. ein PodTemplate) eine benutzerdefinierte ComputeClass ausgewählt wird, kann es vorkommen, dass Buffer-Pods nicht auf den neu bereitgestellten Knoten geplant werden. Dieses Problem führt dazu, dass der Cluster Autoscaler wiederholt redundante Knotenpools und Knoten erstellt, während inaktive Knoten gelöscht werden.

Dieses Problem tritt auf, wenn die benutzerdefinierte ComputeClass Knoten mit Markierungen oder bestimmten Laufzeitanforderungen bereitstellt und Ihre Puffer-Pods (oder die PodTemplate, auf der sie basieren) keine entsprechenden Toleranzen oder Einstellungen haben.

Um dieses Problem zu beheben, aktualisieren Sie die CapacityBuffer-Konfiguration, um die erforderlichen Toleranzen, Knotenauswahlen oder Laufzeitklassen anzugeben. Wenn Ihre Abhängigkeit beispielsweise eine benutzerdefinierte ComputeClass auswählt, die mit GKE Sandbox konfiguriert ist, aktualisieren Sie die Abhängigkeit, um eine der folgenden Aktionen auszuführen:

  • Geben Sie das Feld spec.runtimeClassName: gvisor an.
  • Fügen Sie eine explizite Toleranz für die Markierung sandbox.gke.io/runtime=gvisor:NoSchedule hinzu.

Weitere Informationen finden Sie in der Dokumentation zu benutzerdefinierten Compute-Klassen.

Nächste Schritte