Probleme mit benutzerdefinierten Compute-Klassen beheben

In diesem Dokument erfahren Sie, wie Sie Probleme beheben, bei denen GKE-Arbeitslasten nicht auf Knoten geplant werden können, die durch eine benutzerdefinierte ComputeClass definiert sind, oder wenn der Cluster Autoscaler nicht die erwarteten Maschinentypen bereitstellt.

Dieses Dokument richtet sich an Anwendungsentwickler, Plattformadministratoren und ‑operatoren, die benutzerdefinierte ComputeClasses verwenden, um die Planung von Arbeitslasten und die automatische Erstellung von Knotenpools in GKE zu verwalten. Weitere Informationen zu den gängigen Rollen und Beispielaufgaben, auf die in Google Cloud Inhalten verwiesen wird, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Wichtige Konzepte

Zur Fehlerbehebung sollten Sie sich mit den folgenden GKE-Komponenten und ‑Mechanismen vertraut machen:

  • Benutzerdefinierte ComputeClass: Eine GKE-spezifische Ressource, mit der Sie eine priorisierte Liste von Knotenkonfigurationen für das Autoscaling definieren können. Weitere Informationen finden Sie unter Benutzerdefinierte Compute-Klassen.

  • Cluster-Autoscaler: Die Komponente, die Ihrem Cluster automatisch Knoten hinzufügt oder daraus entfernt, je nach Bedarf der Arbeitslast. Weitere Informationen finden Sie unter GKE-Cluster-Autoscaling.

  • Automatische Erstellung von Knotenpools: Der GKE-Cluster-Autoscaler erstellt und verwaltet Knotenpools automatisch basierend auf den Anforderungen der Arbeitslast. Weitere Informationen finden Sie unter Automatische Erstellung von Knotenpools.

  • Fallback-Logik: Der Mechanismus, mit dem Cluster Autoscaler versucht, zuerst Knoten bereitzustellen, die Ihrer Regel mit der höchsten Priorität entsprechen. Weitere Informationen finden Sie unter Fallback-Computing-Prioritäten auswählen.

Fehlerbehebung nach Symptomen

In diesem Dokument werden die Schritte zur Fehlerbehebung in einer Reihenfolge von grundlegenden Prüfungen bis hin zu komplexeren Konfigurationen beschrieben. Für eine umfassendere Diagnose empfehlen wir, diese Schritte in der angegebenen Reihenfolge auszuführen. Wenn Sie bestimmte Probleme haben, können Sie auch die entsprechenden Links in der folgenden Tabelle aufrufen:

Symptom Schritte zur Fehlerbehebung
Pod, der eine benutzerdefinierte ComputeClass anfordert, bleibt im Status Pending stecken
Cluster Autoscaler erstellt keine neuen Knoten, die der benutzerdefinierten Compute-Klasse entsprechen
Der Cluster-Autoscaler erstellt Standardmaschinentypen anstelle von spezialisierten Typen. Autoscaler-Fallbackverhalten analysieren
Die Ausgabe des Befehls kubectl describe computeclass zeigt einen fehlerhaften Status an Benutzerdefinierte ComputeClass-Konfigurationen überprüfen
Arbeitslasten werden nicht zu Knoten mit höherer Priorität migriert Allgemeinen Status des Cluster-Autoscalers prüfen
Bei Arbeitslasten mit GPU- oder Spot-VMs treten Planungsprobleme auf

Probleme außerhalb des Zuständigkeitsbereichs

In diesem Dokument werden die folgenden Probleme nicht behandelt:

  • Allgemeine GKE-Netzwerkprobleme, z. B. Pod-zu-Pod-Verbindungen oder Load-Balancing für Dienste.
  • Probleme im Zusammenhang mit dem horizontalen Pod-Autoscaler (HPA) oder dem vertikalen Pod-Autoscaler (VPA).
  • Probleme, die nicht mit dem benutzerdefinierten ComputeClass-Mechanismus zusammenhängen, z. B. Fehler auf Anwendungsebene oder PersistentVolume-Probleme, die nicht mit Planungsbeschränkungen zusammenhängen.
  • Probleme mit dem Kontingent oder der Nichtverfügbarkeit von Ressourcen, die nicht direkt mit der Fallback-Logik für ComputeClass zusammenhängen.

Platzhaltervariablen identifizieren

Wenn Sie die Befehle in diesem Dokument anpassen möchten, geben Sie Ihre spezifischen Werte in die Spalte Variable ein. Geänderte Werte werden automatisch in allen Codeblöcken und Befehlen synchronisiert.

Variable Beschreibung
PROJECT_ID Ihre Google Cloud -Projekt-ID.
LOCATION Die Compute Engine-Region oder -Zone, in der sich der Cluster befindet.
CLUSTER_NAME Der Name Ihres Clusters.
NODE_POOL_NAME Der Name des zu prüfenden Knotenpools (falls für Standardcluster zutreffend).
CUSTOM_COMPUTECLASS_NAME Der Name der benutzerdefinierten ComputeClass, die vom Pod angefordert wird.
NAMESPACE Der Namespace des Pods, der nicht geplant werden kann.
POD_NAME Der Name des Pods, der nicht geplant werden kann.

Hinweis

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Projekt zuzuweisen, damit Sie die nötigen Berechtigungen für die Aufgaben in diesem Dokument haben: Google Cloud

  • So greifen Sie auf GKE-Cluster zu: Kubernetes Engine-Clusterbetrachter (roles/container.viewer).
  • So rufen Sie Logs auf: Loganzeige (roles/logging.viewer).
  • So verwalten Sie GKE-Cluster: Kubernetes Engine-Administrator (roles/container.admin).

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Führen Sie den folgenden Befehl aus, um kubectl für die Kommunikation mit dem Cluster zu konfigurieren:

  gcloud container clusters get-credentials CLUSTER_NAME
      --location LOCATION
      --project PROJECT_ID

Einfache Diagnosetests durchführen

Prüfen Sie, ob die Kernkomponenten richtig konfiguriert sind und der Cluster benutzerdefinierte ComputeClasses unterstützt.

Pod-Status und -Selektor prüfen

Prüfen Sie, ob sich der Pod im Status Pending befindet und die benutzerdefinierte ComputeClass korrekt anfordert.

  1. Pods im Status Pending auflisten:

    kubectl get pods --all-namespaces -o wide | grep Pending

  2. Prüfen Sie die Spezifikation des Pods auf das Feld nodeSelector:

    kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.nodeSelector}'

Ergebnis auswerten

  • Ausgabe zeigt das Label: Das Feld nodeSelector ist korrekt mit dem Label cloud.google.com/compute-class konfiguriert.
  • In der Ausgabe wird das Label nicht angezeigt:
    • Interpretation:Möglicherweise ist das Feld nodeSelector für das Label cloud.google.com/compute-class in der Bereitstellungskonfiguration Ihrer Arbeitslast falsch oder fehlt.
    • Lösung:Ändern Sie die YAML-Datei Ihrer Arbeitslast, z. B. ein Deployment oder ein Job, um das Feld nodeSelector im Abschnitt spec.template.spec einzufügen.

Kompatibilität der Clusterversion prüfen

Benutzerdefinierte Compute-Klassen erfordern GKE-Version 1.30.3-gke.1451000 oder höher. Prüfen Sie, ob auf Ihrem Cluster eine Version ausgeführt wird, die benutzerdefinierte ComputeClasses unterstützt.

So prüfen Sie Ihre Clusterversion:

gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
    --format="value(currentMasterVersion)"

Ergebnis auswerten

  • Version 1.30.3-gke.1451000 oder höher:Ihre Clusterversion unterstützt benutzerdefinierte Compute-Klassen.
  • Version vor 1.30.3-gke.1451000:
    • Interpretation:Ihr Cluster wurde nicht auf eine Version aktualisiert, die benutzerdefinierte ComputeClasses unterstützt.
    • Lösung:Sie müssen ein Upgrade Ihres Clusters durchführen, um benutzerdefinierte ComputeClasses zu verwenden.

Benutzerdefinierte ComputeClass-Konfigurationen prüfen

Fehlkonfigurationen in der benutzerdefinierten ComputeClass-Ressource können verhindern, dass Pods geplant werden, oder dass GKE Knoten richtig bereitstellt.

Status und Zustand der ComputeClass prüfen

Prüfen Sie, ob GKE die benutzerdefinierte ComputeClass als fehlerfrei meldet.

  1. Alle ComputeClass-Ressourcen auflisten:

    kubectl get computeclass

  2. Beschreiben Sie die spezifische ComputeClass-Ressource:

    kubectl describe computeclass CUSTOM_COMPUTECLASS_NAME

Ergebnis auswerten

  • Der Status ist True:Die benutzerdefinierte ComputeClass ist fehlerfrei. Das folgende Beispiel zeigt eine fehlerfreie benutzerdefinierte ComputeClass:

    Status:
  Conditions:
    Last Transition Time:  2024-01-19T17:18:48Z
    Message:               CCC is healthy.
    Reason:                Health
    Status:                True
    Type:                  Health

  • Diagnosestatus zeigt False an:

    • Interpretation:Die benutzerdefinierte Compute-Klasse ist fehlerhaft. Sehen Sie sich die Felder Message und Reason in der Ausgabe an, um das Problem zu identifizieren.
    • Lösung: Führen Sie die Aktion aus, die dem Feld Reason in der Ausgabe entspricht:
      • NodePoolNotExist: Stellen Sie sicher, dass der referenzierte Knotenpool vorhanden ist, oder aktualisieren Sie die ComputeClass, sodass sie auf einen vorhandenen Knotenpool verweist.
      • ReservationUnusable: Konfiguration und Nutzung der referenzierten Reservierung prüfen.
      • Invalid machine type: Aktualisieren Sie die ComputeClass, um einen Maschinentyp zu verwenden, der in der Region oder Zone des Clusters unterstützt wird.

unsatisfiable-Richtlinie validieren

Das Feld whenUnsatisfiable bestimmt das Verhalten, wenn keine Prioritätsregeln erfüllt werden können.

Richtlinie prüfen:

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

Prüfen Sie das Feld spec.whenUnsatisfiable in der Ausgabe. Dieses Feld kann einen der folgenden Werte haben:

  • DoNotScaleUp: Pods bleiben im Status Pending, wenn keine bevorzugten Knoten erstellt werden können.
  • ScaleUpAnyway: Pods werden möglicherweise auf Standardknotentypen (z. B. E2-Serie) ausgeführt, wenn bevorzugte Knoten nicht verfügbar sind.

Ergebnis auswerten

Die Wirkung der Richtlinie whenUnsatisfiable hängt von ihrem Wert ab:

  • Wenn der Wert DoNotScaleUp ist:
    • Interpretation:Dies ist das erwartete Verhalten, wenn keine Prioritätsregeln erfüllt werden können, möglicherweise aufgrund von nicht verfügbaren Ressourcen oder Kontingentbeschränkungen. Wenn Pods auf bestimmte Hardware warten müssen, ist dieser Wert korrekt.
    • Lösung:Wenn die Ausführung der Arbeitslast wichtiger ist als die Ausführung auf bestimmter Hardware, ändern Sie die Richtlinie in ScaleUpAnyway.
  • Wenn der Wert ScaleUpAnyway ist:
    • Interpretation:Das ist ganz normal. GKE greift auf Standardknotentypen zurück, da bevorzugte Knoten nicht verfügbar sind.
    • Lösung:Wenn Pods nicht auf Standardknotentypen ausgeführt werden dürfen, ändern Sie die Richtlinie in DoNotScaleUp.
  • Standardverhalten:Wenn Sie keinen Wert für das Feld whenUnsatisfiable angegeben haben und eine GKE-Version vor 1.33 verwenden, wird standardmäßig die Richtlinie ScaleUpAnyway verwendet.

Das folgende Beispiel zeigt, wie Sie die Richtlinie aktualisieren, indem Sie das Feld whenUnsatisfiable in Ihrem ComputeClass-Manifest bearbeiten:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: CUSTOM_COMPUTECLASS_NAME
spec:
  # ... other fields
  whenUnsatisfiable: DoNotScaleUp # or ScaleUpAnyway

Einschränkungen bei der Pod-Planung prüfen

Achten Sie darauf, dass Ihre Pod-Spezifikation mit den Attributen der Knoten kompatibel ist, die von der benutzerdefinierten ComputeClass bereitgestellt werden.

Pod-Ressourcenanfragen prüfen

Prüfen Sie, ob die CPU-, Arbeitsspeicher- und GPU-Anforderungen des Pods von mindestens einem der Maschinentypen erfüllt werden können, die im Feld priorities der benutzerdefinierten ComputeClass definiert sind.

  1. Pod-Ressourcenanfragen abrufen:

    kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.containers[*].resources.requests}'

    Prüfen Sie die Ausgabe auf cpu, memory und GPU-Anfragen wie nvidia.com/gpu.

  2. Vergleichen Sie diese Anforderungen mit den Maschinentypen, die im Feld priorities der benutzerdefinierten ComputeClass definiert sind:

    kubectl get computeclass CUSTOM_COMPUTECLASS_NAME
    -o jsonpath='{.spec.priorities}'

    Suchen Sie in der Ausgabe nach den Feldern machineType oder machineFamily. Prüfen Sie für jeden Maschinentyp in der benutzerdefinierten ComputeClass die Spezifikationen in der Dokumentation zu Maschinentypen und prüfen Sie, ob die zuweisbaren Ressourcen größer als die Anfragen des Pods sind.

Ergebnis auswerten

  • Kompatible Ressourcen:Die Ressourcenanforderungen des Pods sind kleiner oder gleich den zuweisbaren Ressourcen mindestens eines Maschinentyps in der ComputeClass.

  • Ressourcen überschreiten die Kapazität:

    • Interpretation:Der Pod kann nicht geplant werden, da kein Maschinentyp in der ComputeClass genügend CPU, Arbeitsspeicher oder GPU bietet. Dies kann auch passieren, wenn das Feld nodePoolAutoCreation auf true gesetzt ist und die Speicheranforderung des Pods die Limits automatisch erstellter Knotenpools überschreitet.
    • Lösung:Passen Sie entweder die Ressourcenanforderungen des Pods oder die Maschinentypen der benutzerdefinierten ComputeClass an:
      • Pod-Ressourcenanfragen reduzieren: Wenn die Ressourcenanfragen hoch sind, senken Sie die Werte für cpu, memory oder gpu in der YAML-Datei der Arbeitslast.
      • Größere Maschinentypen verwenden: Wenn die Anforderungen des Pods gerechtfertigt sind, ändern Sie das Feld spec.priorities in Ihrem benutzerdefinierten ComputeClass-Manifest, um größere machineType- oder machineFamily-Optionen einzuschließen, die die Anforderungen des Pods erfüllen können. Beispiel:
    spec:
  priorities:
  - machineType: n2d-highmem-96 # A larger machine type
    spot: true
  # ... other priorities

Auf Konflikte bei Markierungen und Toleranzen prüfen

Für eine benutzerdefinierte ComputeClass erstellte Knoten haben den Taint cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule. GKE fügt diese Toleranz automatisch zu Pods hinzu.

Spezielle Hardware wie GPUs haben jedoch zusätzliche Taints wie den nvidia.com/gpu=present:NoSchedule-Taint. Wenn für Ihre ComputeClass Knoten mit spezialisierter Hardware verwendet werden, müssen Pods eine Toleranz für diese Markierungen haben, damit sie auf diesen Knoten geplant werden können.

Prüfen Sie das Feld tolerations für den Pod:

kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.tolerations}'

Ergebnis auswerten

  • Korrekte Toleranzen:Taints und Toleranzen sind richtig konfiguriert.

  • Fehlende Toleranzen:

    • Interpretation:Fehlende Toleranzen verhindern, dass der Pod auf Knoten mit Markierungen für spezielle Hardware geplant wird. Wenn für die ComputeClass beispielsweise GPU-Knoten verwendet werden, fehlt dem Pod möglicherweise die nvidia.com/gpu=present:NoSchedule-Toleranz. GPU-spezifische Anforderungen finden Sie unter GPU-Konfiguration prüfen.

    • Lösung:Fügen Sie im Feld tolerations in Ihrer Pod-Spezifikation die erforderlichen Toleranzen hinzu, die den Markierungen auf den von der ComputeClass definierten Knoten entsprechen. Fügen Sie beispielsweise für GPU-Knoten eine Toleranz für die Markierung nvidia.com/gpu=present:NoSchedule wie folgt hinzu:

      spec:
template:
spec:
tolerations:
- key: "nvidia.com/gpu"
operator: "Exists"
effect: "NoSchedule"
# ... other tolerations and Pod spec

Knotenpoolkonfiguration (Standardcluster)

In GKE-Standardclustern müssen manuell erstellte Knotenpools mit Labels und Markierungen versehen werden, damit sie mit einer benutzerdefinierten ComputeClass funktionieren.

Knotenpoollabels und ‑markierungen prüfen

  1. Knotenpools in Ihrer benutzerdefinierten Compute-Klasse identifizieren Wenn die benutzerdefinierte ComputeClass das Feld nodePools verwendet, notieren Sie sich die Namen der aufgeführten Knotenpools:

    kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

  2. Prüfen Sie für jeden Knotenpool, den Sie identifiziert haben, die Konfiguration:

    gcloud container node-pools describe NODE_POOL_NAME
    --cluster CLUSTER_NAME
    --location LOCATION
    --format="yaml(config.labels, config.taints)"

Ergebnis auswerten

  • Knotenpool richtig konfiguriert:Der Knotenpool hat das Label cloud.google.com/compute-class: CUSTOM_COMPUTECLASS_NAME und die Markierung cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule.

  • Falsch konfigurierter Knotenpool:

    • Interpretation:Der Knotenpool wurde nicht mit dem Label und der Markierung konfiguriert, die erforderlich sind, um ihn der benutzerdefinierten Compute-Klasse zuzuordnen.

    • Lösung:Aktualisieren Sie den Knotenpool, um das Label und die Markierung hinzuzufügen:

      1. Knotenlabel hinzufügen oder aktualisieren:

        gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME --location=LOCATION \
    --node-labels=cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME

      2. So fügen Sie einen Knoten-Taint hinzu oder aktualisieren ihn:

        gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME --location=LOCATION \
    --node-taints=cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule

Konfiguration der automatischen Knotenpoolerstellung prüfen

Sowohl für Autopilot- als auch für Standardcluster, bei denen nodePoolAutoCreation auf true festgelegt ist, muss die automatische Erstellung von Knotenpools richtig konfiguriert sein.

Prüfen, ob die automatische Erstellung von Knotenpools aktiviert ist

  1. Prüfen Sie, ob das Feld nodePoolAutoCreation.enabled in der benutzerdefinierten ComputeClass auf true gesetzt ist:

    kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

  2. Prüfen Sie, ob die automatische Erstellung von Knotenpools im Cluster aktiviert ist:

    gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
    --format="value(autoscaling.enableNodeAutoprovisioning)"

Wenn eine der beiden Optionen deaktiviert ist, werden durch die automatische Erstellung von Knotenpools keine neuen Knotenpools für Ihre benutzerdefinierte Compute-Klasse erstellt.

Ergebnis auswerten

  • Automatisches Erstellen von Knotenpools aktiviert:In der ComputeClass ist das Feld nodePoolAutoCreation.enabled auf true festgelegt und die automatische Knotenbereitstellung ist auf Clusterebene aktiviert.

  • Automatische Erstellung von Knotenpools deaktiviert:

    • Interpretation:Die automatische Erstellung von Knotenpools ist deaktiviert, wenn der Wert des Felds nodePoolAutoCreation.enabled in der ComputeClass false ist oder fehlt oder wenn die automatische Bereitstellung von Knoten auf Clusterebene deaktiviert ist.

    • Lösung:Aktivieren Sie die automatische Erstellung von Knotenpools:

      1. Bearbeiten Sie die benutzerdefinierte ComputeClass-YAML-Datei, um nodePoolAutoCreation: enabled: true einzufügen:

        spec:
  # ... priorities
  nodePoolAutoCreation:
    enabled: true

      2. Automatische Knotenpoolerstellung auf Clusterebene aktivieren und Ressourcenlimits konfigurieren:

        gcloud container clusters update CLUSTER_NAME --location LOCATION \
  --enable-autoprovisioning \
  --autoprovisioning-min-cpu=MIN_CPU \
  --autoprovisioning-max-cpu=MAX_CPU \
  --autoprovisioning-min-memory=MIN_MEMORY \
  --autoprovisioning-max-memory=MAX_MEMORY

Ressourcenlimits für die automatische Erstellung von Knotenpools prüfen

Für die automatische Erstellung von Knotenpools gelten clusterweite Limits für CPU und Arbeitsspeicher. Wenn die aktuelle Nutzung des Clusters plus die Ressourcen eines neuen Knotens diese Limits überschreiten, werden durch die automatische Erstellung von Knotenpools keine neuen Knoten bereitgestellt.

  1. So rufen Sie die Ressourcenlimits auf:

    gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
--format="value(autoscaling.resourceLimits)"

    In der Ausgabe werden die Felder resourceType, minimum und maximum für CPU und Arbeitsspeicher (in GB) aufgeführt.

  2. Sehen Sie sich die Maschinentypen in den Prioritäten Ihrer benutzerdefinierten ComputeClass an. Die CPU- und Arbeitsspeicherspezifikationen finden Sie in der Dokumentation zu Maschinentypen.

  3. Ermitteln Sie die aktuelle Gesamt-CPU- und Arbeitsspeicherkapazität aller Knoten im Cluster. Die Summe aus der aktuellen Kapazität und den Ressourcen eines potenziellen neuen Knotens darf das maximale Limit für die automatische Erstellung von Knotenpools nicht überschreiten.

Ergebnis auswerten

  • Ausreichende Kapazität:Der Cluster hat innerhalb der Ressourcenlimits für die automatische Erstellung von Knotenpools ausreichend CPU- und Arbeitsspeicherkapazität, um einen neuen Knoten bereitzustellen.

  • Limits überschritten:

    • Interpretation:Bei der automatischen Erstellung von Knotenpools können keine neuen Knoten bereitgestellt werden, da der Cluster CPU- oder Arbeitsspeicherlimits erreicht hat oder die Limits für die Maschinentypen in der ComputeClass zu niedrig festgelegt wurden.

    • Lösung:Erhöhen Sie die Ressourcenlimits für die automatische Erstellung von Knotenpools:

      1. Legen Sie neue Höchstgrenzen fest, die die aktuelle Nutzung und das zukünftige Wachstum berücksichtigen, einschließlich der größten Maschinentypen in der benutzerdefinierten ComputeClass.

      2. Ressourcenlimits für die automatische Erstellung von Knotenpools aktualisieren Sie können mehrere Ressourcen in einem Befehl festlegen:

        gcloud container clusters update CLUSTER_NAME --location LOCATION \
  --set-nap-resource-limits resourceType=cpu,maximum=NEW_MAX_CPU \
  --set-nap-resource-limits resourceType=memory,maximum=NEW_MAX_GB

Autoscaling-Fallback-Verhalten analysieren

In diesem Abschnitt erfahren Sie, wie Sie externe Faktoren untersuchen können, um herauszufinden, warum der Cluster Autoscaler bevorzugte Optionen möglicherweise überspringt und Fallbacks verwendet oder nicht hochskaliert wird.

Für benutzerdefinierte Compute-Klassen wird eine priorisierte Fallback-Logik verwendet. Wenn ein Pod nicht auf Knoten geplant wird, die der Regel mit der höchsten Priorität entsprechen, liegt das häufig an Einschränkungen wie nicht verfügbaren Ressourcen oder Projektkontingenten. Wenn GKE keine Knoten bereitstellen kann, die einer bestimmten Prioritätsregel entsprechen, z. B. aufgrund eines ZONE_RESOURCE_POOL_EXHAUSTED- oder QUOTA_EXCEEDED-Fehlers von Compute Engine, versucht der Cluster Autoscaler sofort die nächste Regel in der Liste priorities. Es gibt keine Wartezeit, bevor GKE auf die nächste Priorität zurückgreift, außer bei Verwendung von TPUs oder des Bereitstellungsmodells „Flex-Start“, das eine konfigurierbare Verzögerung unterstützt.

Auf nicht verfügbare Ressourcen prüfen

Prüfen Sie, ob Ressourcen in der angegebenen Zone nicht verfügbar sind. Sehen Sie dazu in den Cluster-Autoscaler-Logs oder in den Fehlern der verwalteten Instanzgruppe (MIG) von Compute Engine nach.

Option 1: Sichtbarkeitsereignisse von Cluster Autoscaler prüfen

Rufen Sie in der Google Cloud Console Cloud Logging > Log-Explorer auf und führen Sie die folgende Abfrage aus, um Autoscaler-Ereignisse zu finden, die auf eine Nichtverfügbarkeit von Ressourcen hinweisen:

resource.type="k8s_cluster"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.noScaleUpReason.messageId="no.scale.up.nap.resource.exhausted"

Option 2: MIG-Fehler prüfen

Sie können in der Google Cloud Console oder mit einer Cloud Logging-Abfrage nach MIG-Fehlern suchen.

  • Über die Google Cloud -Konsole:

    1. Rufen Sie in der Google Cloud Console Compute Engine > Instanzgruppen auf.
    2. Suchen Sie nach der MIG, die dem Knotenpool entspricht, der nicht hochskaliert werden kann.
    3. Klicken Sie auf den Namen der MIG und rufen Sie den Tab Fehler auf. Suchen Sie nach Meldungen, die auf eine Erschöpfung der Ressourcen hinweisen.

  • Cloud Logging-Abfrage verwenden:

    1. Rufen Sie in der Google Cloud Console Cloud Logging > Log-Explorer auf.
    2. Führen Sie die folgende Abfrage aus, um nach Fehlern aufgrund von Ressourcenerschöpfung in der MIG zu suchen:
    resource.type="gce_instance"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.status.message:("ZONE_RESOURCE_POOL_EXHAUSTED" OR "does not have enough resources available to fulfill the request" OR "resource pool exhausted" OR "does not exist in zone")

Ergebnis auswerten

  • Ressourcen sind verfügbar:Wenn in den Logs die ZONE_RESOURCE_POOL_EXHAUSTED-Meldungen nicht angezeigt werden, ist es unwahrscheinlich, dass die Nichtverfügbarkeit von Ressourcen die Ursache für den Scale-up-Fehler ist.

  • Ressourcen sind nicht verfügbar:

    • Interpretation:Die Knotenbereitstellung schlägt aufgrund einer vorübergehenden hohen Nachfrage nach einem bestimmten Maschinentyp (insbesondere Spot-VMs oder GPUs) in dieser Zone fehl oder weil ein Pod durch die PersistentVolume-Affinität auf eine Zone beschränkt ist, in der Ressourcen nicht verfügbar sind.

    • Lösung:Die Nichtverfügbarkeit von Ressourcen ist vorübergehend. Sie können die Ausfallsicherheit jedoch verbessern, indem Sie Ihre Konfiguration flexibler gestalten:

      • Maschinentypen diversifizieren: Das Feld spec.priorities in der benutzerdefinierten ComputeClass muss mehrere Maschinentypen oder ‑familien als Fallbacks enthalten:

        spec:
  priorities:
  - machineFamily: c3  # Highest priority
  - machineFamily: n2d # Fallback option
  - machineFamily: e2  # Lowest priority

      • Regionale Cluster verwenden: Wenn der Cluster zonal ist, ist er anfällig für die Nichtverfügbarkeit von Ressourcen in dieser einzelnen Zone. Wenn Sie regionale Cluster verwenden, kann der Cluster Autoscaler versuchen, Knoten in anderen Zonen innerhalb der Region bereitzustellen, in denen möglicherweise Kapazität verfügbar ist.

      • Compute Engine-Reservierungen verwenden: Für kritische Arbeitslasten, bei denen keine Verzögerungen toleriert werden können, erstellen Sie Compute Engine-Reservierungen, um die Kapazität für bestimmte Maschinentypen sicherzustellen.

Projektkontingente prüfen

Prüfen Sie, ob Ihr Projekt ein ausreichendes Kontingent für die Ressourcen wie CPUs, GPUs und IP-Adressen hat, die für die neuen Knoten erforderlich sind.

  1. Prüfen Sie die Autoscaling-Logs auf Kontingentfehler. So suchen Sie mit Cloud Logging in den Sichtbarkeitsereignissen des Autoscalers nach Fehlermeldungen im Zusammenhang mit Kontingenten:

    resource.type="k8s_cluster"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.noScaleUpReason.messageId="no.scale.up.nap.quota.exceeded"

    Alternativ können Sie die folgende Cloud Logging-Abfrage verwenden, um Logs für kontingentbezogene Fehler aus der MIG zu prüfen:

    resource.type="gce_instance"
protoPayload.methodName:"compute.instances.insert"
protoPayload.status.message:"QUOTA_EXCEEDED"
severity=ERROR

  2. So rufen Sie Kontingente in der Google Cloud Console auf:

    1. Rufen Sie in der Google Cloud Console die Seite IAM & Verwaltung > Kontingente auf.
    2. Filtern Sie nach dem Dienst Compute Engine API.
    3. Prüfen Sie die Nutzung relevanter Messwerte wie CPUs, GPUs (alle Typen) und verwendete IP-Adressen für die Region, in der sich Ihr GKE-Cluster befindet. Prüfen Sie, ob die aktuelle Nutzung das Limit erreicht hat.

Ergebnis auswerten

  • Kontingent unter den Grenzwerten:Wenn die Kontingentnutzung unter den Kontingentlimits liegt und in den Logs keine QUOTA_EXCEEDED-Fehler gefunden werden, verhindern Kontingentlimits keine Aufskalierung.
  • Kontingent überschritten:
    • Interpretation:Die Knotenbereitstellung schlägt fehl, weil das Kontingent für Ressourcen wie CPUs, GPUs, IP-Adressen oder MIGs nicht ausreicht.
    • Lösung:Wenn Ihr Projekt ein Kontingentlimit erreicht hat, fordern Sie eine Kontingenterhöhung an.

Erweiterte Konfigurationen

Konfigurationen wie GPUs, Spot-VMs und Compute Engine-Reservierungen haben eigene spezifische Anforderungen und potenzielle Fehlerquellen, die geprüft werden müssen.

GPU-Konfiguration prüfen

Prüfen Sie für benutzerdefinierte Compute-Klassen, die GPU-Knoten bereitstellen, die GPU-Konfiguration in der benutzerdefinierten Compute-Klasse und stellen Sie sicher, dass der Pod die obligatorische nvidia.com/gpu-Toleranz hat.

  1. Prüfen Sie die YAML-Datei der benutzerdefinierten Compute-Klasse auf einen gpu-Block in einer Prioritätsregel:

    kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

    Im gpu-Block sollten die Felder type und count angegeben werden, z. B.:

    priorities:
- machineType: a2-highgpu-1g
  gpu:
    type: nvidia-tesla-a100
    count: 1

  2. Prüfen Sie den Pod auf GPU-Toleranz. Jeder Pod, der auf einem GPU-Knoten geplant werden muss, muss die Toleranz nvidia.com/gpu haben, auch wenn der Pod selbst keine GPU anfordert.

    kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations}'

    Prüfen Sie das Feld spec.tolerations auf Toleranz.

Ergebnis auswerten

  • GPU richtig konfiguriert:Wenn die ComputeClass die GPU type und count definiert und Pods die Toleranz nvidia.com/gpu enthalten, ist die GPU-Konfiguration richtig. Im Folgenden wird die erforderliche Toleranz gezeigt:

    tolerations:
- key: "nvidia.com/gpu"
  operator: "Exists"
  effect: "NoSchedule"

  • GPU falsch konfiguriert:

    • Interpretation:Möglicherweise fehlt dem Pod die erforderliche nvidia.com/gpu-Toleranz, die ComputeClass ist aufgrund von GPU-Feldabweichungen möglicherweise fehlerhaft oder die GKE-Version verarbeitet die GPU-Konfiguration nicht richtig.
    • Lösung:Führen Sie eine der folgenden Aktionen aus:
      • Ändern Sie die YAML-Datei der Arbeitslast, um die obligatorische GPU-Toleranz einzuschließen, und wenden Sie die YAML-Datei noch einmal an.
      • Führen Sie ein Upgrade des GKE-Cluster durch. Wenn die benutzerdefinierte ComputeClass fehlerhaft ist und das Problem mit GPU-Feldern zusammenhängt, suchen Sie nach bekannten Problemen und führen Sie ein Upgrade auf eine gepatchte GKE-Version durch, z. B. 1.31.8-gke.1045000 oder höher.

Konfiguration von Spot-VMs prüfen

Wenn Sie Spot-VMs verwenden, muss die Einstellung spot: true in den richtigen Prioritätsregeln in Ihrem ComputeClass-Manifest enthalten sein. Machen Sie sich außerdem mit der Preislogik des Cluster Autoscalers vertraut.

Prüfen Sie das ComputeClass-Manifest:

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

Suchen Sie in der Ausgabe im Feld spec.priorities nach spot: true, z. B.:

priorities:
- machineFamily: n2d
  spot: true

Der Cluster Autoscaler verwendet möglicherweise Preisdaten von us-central1 als Baseline, wenn er die Kosten verschiedener Spot-VM-Typen vergleicht. Dies kann in anderen Regionen zu scheinbar nicht optimalen Entscheidungen führen. Das ist ein bekanntes Verhalten.

Ergebnis auswerten

  • Spot-VMs sind richtig konfiguriert:Wenn das Feld spot: true angegeben ist und der Cluster-Autoscaler Spot-VMs bereitstellt, funktioniert die Konfiguration wie erwartet.

  • Planung von Spot-VMs fehlgeschlagen:

    • Interpretation:Pods, für die Spot-VMs erforderlich sind, können möglicherweise nicht auf Spot-VMs geplant werden, weil in der Zielzone keine Ressourcen verfügbar sind oder weil der Cluster Autoscaler aufgrund seines us-central1-Preismodells einen anderen VM-Typ auswählt.

    • Lösung:

      • Wenn Sie vermuten, dass eine Ressource nicht verfügbar ist, lesen Sie den Abschnitt Ressourcenverfügbarkeit prüfen.

      • Wenn Sie die Auswahl von Spot-VMs steuern möchten, listen Sie die machineType-Einträge in Ihrem Feld priorities für Ihre Region explizit vom günstigsten zum teuersten auf. Mit diesem Ansatz haben Sie die direkte Kontrolle über die Fallback-Reihenfolge. Beispiel:

        spec:
  priorities:
  - machineType: t2d-standard-48 # Cheapest in this region
    spot: true
  - machineType: n2d-standard-48 # Fallback Spot option
    spot: true
  - machineType: n2d-standard-48 # On-demand fallback
    spot: false

Allgemeiner Status von Cluster Autoscaler

In diesem Abschnitt erfahren Sie, wie Sie nach Problemen suchen, die möglicherweise nicht direkt mit der benutzerdefinierten ComputeClass-Konfiguration zusammenhängen, aber den Betrieb beeinträchtigen.

Gleichzeitige Vorgänge prüfen

Prüfen Sie, ob gleichzeitig andere Cluster- oder Knotenpoolvorgänge ausgeführt werden. In GKE ist in der Regel nur ein Vorgang gleichzeitig zulässig, was das Autoscaling blockieren kann.

Laufende Vorgänge auflisten, die sich nicht im Status DONE befinden:

gcloud container operations list \
    --location=LOCATION \
    --filter='targetLink~"/clusters/CLUSTER_NAME" AND status!=DONE'

Wenn der Befehl Vorgänge zurückgibt, ist möglicherweise ein Vorgang wie ein Cluster-Upgrade, die Erstellung eines Knotenpools oder eine andere Änderung in Bearbeitung. Autoscaling-Ereignisse werden möglicherweise blockiert, bis dieser Vorgang abgeschlossen ist.

Ergebnis auswerten

  • Keine gleichzeitigen Vorgänge:Wenn der Befehl list eine leere Liste zurückgibt, wird die automatische Clusterskalierung nicht durch Vorgänge blockiert.

  • Gleichzeitige Vorgänge gefunden:

    • Interpretation:Wenn mit dem Befehl Vorgänge mit dem Status RUNNING oder PENDING aufgeführt werden, ist möglicherweise ein gleichzeitiger Vorgang wie ein Cluster-Upgrade oder eine Knotenpooländerung im Gange, der das Autoscaling blockiert.

    • Lösung:Warten Sie, bis der laufende Vorgang abgeschlossen ist. Sie können den Status mit einer Vorgangs-ID so überwachen:

      gcloud container operations wait OPERATION_ID --location LOCATION

      Ersetzen Sie OPERATION_ID durch die ID aus der Ausgabe des list-Befehls. Nach Abschluss des Blockierungsvorgangs sollte das Cluster-Autoscaling wieder normal funktionieren.

Aktive Migration prüfen

Wenn Sie feststellen, dass Arbeitslasten auf Knoten mit niedrigerer Priorität verbleiben, obwohl Knoten mit höherer Priorität verfügbar sind, prüfen Sie, ob die aktive Migration aktiviert ist. Wenn das Feld activeMigration.optimizeRulePriority in Ihrer ComputeClass auf false gesetzt oder weggelassen wird, verschiebt GKE Arbeitslasten nicht automatisch auf Knoten mit höherer Priorität, wenn diese verfügbar werden.

  1. Sehen Sie sich das Feld spec.tolerations an, um die Pod-Toleranzen zu prüfen. Wenn der Pod Toleranzen hat, die mit Taints in mehreren Knotenpools mit unterschiedlichen Prioritäten übereinstimmen, kann der Scheduler ihn auf einem Knoten mit niedrigerer Priorität platzieren, wenn dieser zuerst verfügbar ist.

    kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations[*]}{"\n"}'

  2. Prüfen Sie das ComputeClass-Manifest auf das Feld spec.activeMigration.optimizeRulePriority, um festzustellen, ob die aktive Migration aktiviert ist.

    kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

Ergebnis auswerten

  • Aktive Migration aktiviert:Wenn das Feld activeMigration.optimizeRulePriority true ist, versucht GKE, Arbeitslasten auf Knoten mit höherer Priorität zu verschieben, sobald diese verfügbar sind.

  • Aktive Migration deaktiviert oder ineffektiv:

    • Interpretation:Wenn das Feld activeMigration.optimizeRulePriority false ist oder fehlt oder wenn die Toleranzen des Pods zu breit gefasst sind, verbleiben Arbeitslasten auf Knoten mit niedrigerer Priorität, wenn Knoten mit höherer Priorität verfügbar sind. So können Arbeitslasten auf Knoten mit niedrigerer Priorität geplant werden, die zuerst verfügbar werden.

    • Lösung:Wenn Sie möchten, dass Arbeitslasten auf Knoten mit höherer Priorität verschoben werden, führen Sie eine der folgenden Aktionen aus:

      • Verwenden Sie spezifischere Planungsbeschränkungen wie nodeAffinity, um Knotenpools mit höherer Priorität zu bevorzugen.

      • Bearbeiten Sie das ComputeClass-Manifest, um activeMigration.optimizeRulePriority: true festzulegen, und wenden Sie die YAML-Datei an:

        spec:
  activeMigration:
    optimizeRulePriority: true

Support anfordern

Nächste Schritte