Kapazitätsreserven konfigurieren

Kapazitätsreserven verbessern die Reaktionsfähigkeit und Zuverlässigkeit kritischer Arbeitslasten, indem sie die freie Clusterkapazität proaktiv mit einer benutzerdefinierten Kubernetes-Ressourcendefinition für CapacityBuffer verwalten. Mit einem Kapazitäts-Puffer können Sie explizit eine bestimmte Menge an ungenutzter Knotenkapazität in Ihrem Cluster definieren. Diese reservierte Kapazität trägt dazu bei, dass GKE Knoten im Voraus bereitstellt.

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 zu warten. So werden Latenzzeiten minimiert und Ressourcenkonflikte bei plötzlichen Nachfragespitzen vermieden.

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

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 diesen Task 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.
  • Erstellen Sie einen GKE-Cluster mit Version 1.35.2-gke.1842000 oder höher oder sorgen Sie dafür, dass Sie auf einen solchen Cluster zugreifen können.
  • Optional, aber empfohlen: Aktivieren Sie die automatische Knotenbereitstellung für Ihren Cluster.

  • Wenn Sie Standby-Puffer verwenden möchten, müssen Sie einen Cluster mit der folgenden GKE-Version erstellen:

    gcloud container clusters create CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --cluster-version=1.35.2-gke.1842002 \
    --release-channel=None

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name des neuen Clusters.
    • COMPUTE_REGION: die Compute Engine-Region für den neuen Cluster, z. B. us-central1.

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 Beispiel für eine Arbeitslast verwendet. Kapazitätsreserven unterstützen jedoch alle der folgenden Ressourcentypen:

    • Bereitstellung
    • ReplicaSet
    • StatefulSet
    • ReplicationController
    • Job

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

Dieser Abschnitt enthält Beispiele für diese Objekte. Wenn Sie bereits eine Arbeitslast haben, die Sie mit einem Kapazitätspuffer konfigurieren möchten, fahren Sie mit Kapazitätspuffer anwenden fort.

So erstellen Sie eine Beispielarbeitslast für Kubernetes:

  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. 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"

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

  3. 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

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

  4. Wenden Sie die Manifeste auf Ihren Cluster an:

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

  5. 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ätsreserve 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 einer Pod-Vorlage benötigen.

So erstellen Sie einen Zwischenspeicher 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 PodTemplate, 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 Buffereinheiten 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.

Prozentualen Puffer konfigurieren

Wenn Sie einen prozentualen Puffer konfigurieren, wird der Puffer dynamisch auf Grundlage eines Prozentsatzes einer vorhandenen skalierbaren Arbeitslast dimensioniert. Prozentuale Puffer werden für alle Objekte unterstützt, die eine Scale-Unterressource definieren, z. B. Deployments, StatefulSets, ReplicaSets oder Jobs. Sie können keinen prozentualen Puffer für Pod-Vorlagen definieren, da sie kein replicas-Feld haben.

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 Ihrer 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.

Puffer für Ressourcenlimits konfigurieren

Mit dem Feld limits können Sie eine maximale Anzahl von Ressourcen definieren, die der Puffer verbrauchen soll. Diese wird anhand der Größe von 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 PodTemplate, 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 Gesamtwert 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 Buffereinheiten 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 Grenzwerten 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 innerhalb der definierten Grenzwerte liegen.

Standby-Pufferverhalten anpassen

Mit Anmerkungen können Sie anpassen, wie Standby-Puffer gestartet und aktualisiert werden. Fügen Sie diese Annotationen dem Feld metadata.annotations Ihrer CapacityBuffer-Ressource 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 gesperrte Knoten aktualisiert werden. Der Standardwert ist 1d.

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 fortgesetzt 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ätspuffer erstellt 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.

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 (nutzungsabhängige Abrechnung pro Pod) verwendet wird, kann der CapacityBuffer nicht bereitgestellt werden.

So identifizieren Sie dieses Problem:

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.

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.

Nächste Schritte