Probleme mit benutzerdefinierten Compute-Klassen beheben

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

Dieses Dokument richtet sich an Anwendungsentwickler, Plattformadministratoren und ‑operatoren, die benutzerdefinierte Compute-Klassen verwenden, um die Arbeitslastplanung und die automatische Erstellung von Knotenpools in GKE zu verwalten. Weitere Informationen zu den gängigen Rollen und Beispielaufgaben, auf die in Inhalten von Cloud de Confiance by S3NS 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 ComputeClasses.

• Cluster-Autoscaler: Die Komponente, die Knoten in Ihrem Cluster automatisch entsprechend der Arbeitslastanforderung hinzufügt oder entfernt. Weitere Informationen finden Sie unter GKE-Cluster-Autoscaling.

• Automatisches Erstellen 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 der 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, finden Sie in der folgenden Tabelle die entsprechenden Links:

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 Kontingenten oder der Nichtverfügbarkeit von Ressourcen, die nicht direkt mit der Fallback-Logik von 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.

Hinweis

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Projekt Cloud de Confiance by S3NS zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Ausführen der Aufgaben in diesem Dokument benötigen:

• So greifen Sie auf GKE-Cluster zu: Kubernetes Engine-Cluster-Viewer (roles/container.viewer).
• So können die Logs angezeigt werden: 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 Diagnosen durchführen

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

Pod-Status und ‑Selektor prüfen

Prüfen Sie, ob der Pod den Status Pending hat und die benutzerdefinierte ComputeClass korrekt anfordert.

1. Pods mit dem Status Pending auflisten:

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

2. Prüfen Sie die Pod-Spezifikation auf das Feld nodeSelector:

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

Ergebnis bewerten

• 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 in der Bereitstellungskonfiguration Ihrer Arbeitslast ein falsches oder fehlendes nodeSelector-Feld für das cloud.google.com/compute-class-Label vorhanden.
  • Lösung:Ändern Sie die YAML-Datei Ihrer Arbeitslast, z. B. ein Deployment oder ein Job, sodass das Feld nodeSelector im Abschnitt spec.template.spec enthalten ist.

Kompatibilität der Clusterversion prüfen

Benutzerdefinierte ComputeClasses erfordern die 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.

Clusterversion prüfen:

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

Ergebnis bewerten

• Version 1.30.3-gke.1451000 oder höher:Ihre Clusterversion unterstützt benutzerdefinierte ComputeClasses.
• 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.

Bereitgestellte Knoten für die benutzerdefinierte Compute-Klasse prüfen

So prüfen Sie, ob es Knoten im Cluster gibt, die mit Ihrer ComputeClass verknüpft sind:

kubectl get nodes -l cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME

Wenn die Ausgabe No resources found lautet, sind keine Knoten mit der ComputeClass verknüpft. Prüfen Sie, ob für Ihre Arbeitslasten tatsächlich diese Compute-Klasse ausgewählt wurde, und sehen Sie in den Autoscaling-Ereignissen nach Scale-up-Fehlern.

Benutzerdefinierte ComputeClass-Konfigurationen prüfen

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

ComputeClass-Status und ‑Zustand prüfen

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

1. Listen Sie alle ComputeClass-Ressourcen auf:

   kubectl get computeclass
   

2. Beschreiben Sie die spezifische ComputeClass-Ressource:

   kubectl describe computeclass CUSTOM_COMPUTECLASS_NAME
   

Ergebnis bewerten

• Der Status zeigt True an:Die benutzerdefinierte ComputeClass ist fehlerfrei. Hier ist ein Beispiel für eine fehlerfreie benutzerdefinierte ComputeClass:

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

• Der Gesundheitsstatus 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: Prüfen Sie, ob der referenzierte Knotenpool vorhanden ist, oder aktualisieren Sie die ComputeClass, um auf einen vorhandenen Knotenpool zu verweisen.
    • ReservationUnusable: Überprüfen Sie die Konfiguration und Verwendung der referenzierten Reservierung.
    • Invalid machine type: Aktualisieren Sie die ComputeClass, damit ein Maschinentyp verwendet wird, der in der Region oder Zone des Clusters unterstützt wird.

Richtlinie unsatisfiable 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 bewerten

Die Auswirkung 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 Kontingentlimits. Wenn Pods auf bestimmte Hardware warten müssen, ist dieser Wert korrekt.
  • Auflö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 ein normales Verhalten. 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 die Richtlinie standardmäßig auf ScaleUpAnyway gesetzt.

Im folgenden Beispiel wird gezeigt, 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 für die 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 Anfragen mit den Maschinentypen, die im Feld priorities der benutzerdefinierten ComputeClass definiert sind:

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

   Prüfen Sie die Ausgabe auf die Felder 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 bewerten

• Kompatible Ressourcen:Die Ressourcenanfragen 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 Speicheranfrage des Pods die Limits der automatisch erstellten Knotenpools überschreitet.
  • Lösung:Passen Sie entweder die Ressourcenanfragen 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 Pod-Anforderungen 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.

Spezialisierte Hardware wie GPUs haben jedoch zusätzliche Markierungen wie die Markierung nvidia.com/gpu=present:NoSchedule. Wenn in Ihrer 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 bewerten

• Korrekte Toleranzen:Taints und Toleranzen sind richtig konfiguriert.

• Fehlende Toleranzen:

  • Interpretation: Fehlende Toleranzen verhindern, dass der Pod auf Knoten mit Markierungen für spezialisierte Hardware geplant wird. Wenn die ComputeClass beispielsweise GPU-Knoten verwendet, fehlt dem Pod möglicherweise die Toleranz nvidia.com/gpu=present:NoSchedule. GPU-spezifische Anforderungen finden Sie unter GPU-Konfiguration überprü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 identifizierten Knotenpool die Konfiguration:

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

Ergebnis bewerten

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

• Knotenpool falsch konfiguriert:

  • Interpretation: Der Knotenpool wurde nicht mit dem Label und der Markierung konfiguriert, die erforderlich sind, um ihn mit der benutzerdefinierten ComputeClass zu verknüpfen.

  • 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 für die automatische Erstellung von Knotenpools 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 Knotenpoolerstellung für den 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 ComputeClass erstellt.

Ergebnis bewerten

• Automatische Erstellung von Knotenpools aktiviert:Im Feld nodePoolAutoCreation.enabled der ComputeClass ist 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 Knotenbereitstellung 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 Grenzwerte überschreiten, werden durch die automatische Erstellung von Knotenpools keine neuen Knoten bereitgestellt.

1. Ressourcenlimits ansehen:

   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. Prüfen Sie die Maschinentypen in den Prioritäten Ihrer benutzerdefinierten ComputeClass. Die CPU- und Arbeitsspeicherspezifikationen finden Sie in der Dokumentation zu Maschinentypen.

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

Ergebnis bewerten

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

• Limits überschritten:

  • Interpretation: Die automatische Erstellung von Knotenpools kann keine neuen Knoten bereitstellen, da der Cluster die 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 der aktuellen Nutzung und dem zukünftigen Wachstum Rechnung tragen, 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
       

Autoscaler-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 das Hochskalieren fehlschlägt.

Benutzerdefinierte ComputeClasses verwenden eine priorisierte Fallback-Logik. 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 priorities-Liste anzuwenden. Es gibt keine Wartezeit, bevor die GKE auf die nächste Priorität zurückgreift, außer bei Verwendung von TPUs oder dem Bereitstellungsmodell „Flex-Start“, die eine konfigurierbare Verzögerung unterstützen.

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 Cloud de Confiance 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 Cloud de Confiance Console oder mithilfe einer Cloud Logging-Abfrage nach MIG-Fehlern suchen.

• Cloud de Confiance Console verwenden:

  1. Rufen Sie in der Cloud de Confiance 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 Cloud de Confiance Console die Seite 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 bewerten

• Ressourcen sind verfügbar:Wenn in den Logs keine ZONE_RESOURCE_POOL_EXHAUSTED-Meldungen 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übergehend 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 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 auftreten dürfen, erstellen Sie Compute Engine-Reservierungen, um Kapazität für bestimmte Maschinentypen zu reservieren.

Projektkontingente prüfen

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

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. Kontingente in der Cloud de Confiance Console ansehen:

   1. Rufen Sie in der Cloud de Confiance 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 bewerten

• Kontingent unter den Limits: Wenn die Kontingentnutzung unter den Kontingentlimits liegt und in den Logs keine QUOTA_EXCEEDED-Fehler gefunden werden, wird die Hochskalierung nicht durch Kontingentlimits blockiert.
• 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 bei benutzerdefinierten ComputeClasses, die GPU-Knoten bereitstellen, die GPU-Konfiguration in der benutzerdefinierten ComputeClass und achten Sie darauf, dass der Pod die obligatorische Toleranz nvidia.com/gpu hat.

1. Suchen Sie in der YAML-Datei der benutzerdefinierten ComputeClass nach einem gpu-Block in einer Prioritätsregel:

   kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
   

   Im Block gpu 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 bewerten

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

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

• GPU falsch konfiguriert:

  • Interpretation: Dem Pod fehlt möglicherweise die erforderliche nvidia.com/gpu-Toleranz, die ComputeClass ist möglicherweise aufgrund von GPU-Feldabweichungen fehlerhaft oder die GKE-Version verarbeitet die GPU-Konfiguration nicht korrekt.
  • Lösung:Führen Sie eine der folgenden Aktionen aus:
    • Ändern Sie die YAML-Datei der Arbeitslast, um die obligatorische GPU-Toleranz einzufügen, und wenden Sie die YAML-Datei noch einmal an.
    • Aktualisieren Sie den GKE-Cluster. 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 Referenz, wenn er die Kosten verschiedener Spot-VM-Typen vergleicht. Dies kann in anderen Regionen zu scheinbar nicht optimalen Entscheidungen führen. Dieses Verhalten ist bekannt.

Ergebnis bewerten

• 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 des 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 ihren Betrieb beeinträchtigen.

Auf gleichzeitige Vorgänge prüfen

Prüfen Sie, ob gleichzeitig keine anderen Cluster- oder Knotenpoolvorgänge ausgeführt werden. In GKE gibt es Limits für gleichzeitige Vorgänge, die das Autoscaling blockieren können.

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 bewerten

• Keine gleichzeitigen Vorgänge:Wenn der Befehl list eine leere Liste zurückgibt, wird das Cluster-Autoscaling nicht durch Vorgänge blockiert.

• Gleichzeitige Vorgänge gefunden:

  • Interpretation: Wenn der Befehl Vorgänge mit dem Status RUNNING oder PENDING auflistet, ist möglicherweise ein gleichzeitiger Vorgang wie ein Clusterupgrade oder eine Knotenpooländerung im Gange und blockiert das Autoscaling.

  • Lösung: Warten Sie, bis der laufende Vorgang abgeschlossen ist. Sie können den Status mithilfe einer Vorgangs-ID ü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 ist 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 Tolerierungen hat, die mit Markierungen in mehreren Knotenpools mit unterschiedlichen Prioritäten übereinstimmen, kann der Planer 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. Wenn Sie prüfen möchten, ob die aktive Migration aktiviert ist, sehen Sie sich das ComputeClass-Manifest nach dem Feld spec.activeMigration.optimizeRulePriority an.

   kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
   

Ergebnis bewerten

• Aktive Migration aktiviert: Wenn das Feld activeMigration.optimizeRulePriority den Wert true hat, 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 den Wert false hat oder weggelassen wird oder wenn die Toleranzen des Pods zu weit gefasst sind, bleiben 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 Arbeitslasten auf Knoten mit höherer Priorität verschieben möchten, führen Sie eine der folgenden Aktionen aus:

    • Verwenden Sie spezifischere Planungseinschrä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

• Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, können Sie Support anfordern. Dort erhalten Sie unter anderem Hilfe zu den folgenden Themen:

  • Sie können eine Supportanfrage stellen, indem Sie sich an Cloud Customer Care wenden.
  • Support von der Community erhalten, indem Sie Fragen auf Stack Overflow stellen und mit dem Tag google-kubernetes-engine nach ähnlichen Problemen suchen. Sie können auch dem #kubernetes-engine-Slack-Kanal beitreten, um weiteren Community-Support zu erhalten.
  • Sie können Probleme oder Feature Requests über die öffentliche Problemverfolgung melden.

Nächste Schritte

• Best Practices für ComputeClasses
• ComputeClasses standardmäßig auf Pods anwenden
• Arbeitslasttrennung in GKE konfigurieren
• Fehlerbehebung bei Problemen mit der Hochskalierung von Cluster Autoscaler