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 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 gängigen Rollen und Beispielaufgaben, auf die wir in Cloud de Confiance by S3NS Inhalten verweisen, 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 Knoten in Ihrem Cluster je nach Arbeitslastanforderungen automatisch hinzufügt oder entfernt. Weitere Informationen finden Sie unter GKE-Cluster-Autoscaling.

• Automatische Erstellung von Knotenpools: Der GKE-Cluster-Autoscaler erstellt und verwaltet Knotenpools automatisch basierend auf den Arbeitslastanforderungen. 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 bestimmten Reihenfolge aufgeführt, von grundlegenden Prüfungen bis hin zu komplexeren Konfigurationen. 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 Planungseinschrä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 Ihr Cloud de Confiance by S3NS -Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Ausführen der Aufgaben in diesem Dokument benötigen:

• Für den Zugriff auf GKE-Cluster: Kubernetes Engine-Cluster-Betrachter (roles/container.viewer).
• So rufen Sie Logs auf: Loganzeige (roles/logging.viewer).
• Zum Verwalten von GKE-Clustern: 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

Grundlegende Diagnoseprüfungen 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 sich der Pod im Status Pending befindet und die benutzerdefinierte Compute-Klasse korrekt anfordert.

1. Listen Sie Pods im Status Pending auf:

   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

• In der Ausgabe wird das Label angezeigt: 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, sodass das Feld nodeSelector im Abschnitt spec.template.spec enthalten ist.

Kompatibilität der Clusterversion prüfen

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

Prüfen Sie die Clusterversion:

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 verwenden zu können.

Bereitgestellte Knoten für die benutzerdefinierte ComputeClass prüfen

Wenn Sie prüfen möchten, ob im Cluster Knoten vorhanden sind, die mit Ihrer ComputeClass verknüpft sind, listen Sie die Knoten auf, die dem ComputeClass-Label entsprechen:

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

Wenn die Ausgabe No resources found ist, sind keine Knoten mit der ComputeClass verknüpft. Prüfen Sie, ob Ihre Arbeitslasten diese ComputeClass tatsächlich ausgewählt haben, und suchen Sie in Ihren Autoscaling-Ereignissen nach Fehlern beim Hochskalieren.

Benutzerdefinierte ComputeClass-Konfigurationen prüfen

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

Zustand und Status von ComputeClass prüfen

Prüfen Sie, ob die 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 Systemstatus 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
  

• Der Integritätsstatus ist False:

  • Interpretation: Die benutzerdefinierte ComputeClass ist fehlerhaft. Prüfen Sie die Felder Message und Reason in der Ausgabe, 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: Prüfen Sie die Konfiguration und Nutzung 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.

unsatisfiable-Richtlinie validieren

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

Bitte machen Sie sich mit den Richtlinien vertraut:

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.
  • 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 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 standardmäßig die Richtlinie ScaleUpAnyway verwendet.

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-Anfragen 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 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 von mindestens einem Maschinentyp 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 Ihre ComputeClass Knoten mit spezialisierter Hardware verwendet, müssen Pods eine Toleranz für diese Markierungen haben, um auf diesen Knoten geplant zu werden.

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. Informationen zu GPU-spezifischen 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 durch die ComputeClass definierten Knoten entsprechen. Fügen Sie beispielsweise für GPU-Knoten eine Toleranz für die Markierung nvidia.com/gpu=present:NoSchedule hinzu:

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

Messwert für ausstehende Pods des Cluster Autoscalers analysieren

Anwendbare GKE-Versionen: 1.37 und höher

Wenn Sie wissen möchten, warum Pods, die eine bestimmte ComputeClass anfordern, ausstehend sind, verwenden Sie den Messwert kubernetes.io/autoscaler/cluster_pending_pods_per_ccc in Cloud Monitoring. Anhand dieses Messwerts können Sie feststellen, ob das Problem auf einen Mangel an geeigneten Knoten für die ComputeClass, ein Problem mit der Bereitstellung oder ein Problem mit der Pod-Konfiguration zurückzuführen ist. Dieser Messwert zeigt die Anzahl der Pods, die vom Cluster Autoscaler verarbeitet werden, aufgeschlüsselt nach ComputeClass, dem Grund für den Status „Pending“ und danach, ob es sich um einen System- oder Nutzer-Pod handelt.

Schritte zum Abfragen

So fragen Sie den Messwert in der Cloud de Confiance Console ab:

1. Rufen Sie in der Cloud de Confiance Console die Seite „Metrics Explorer“ auf.
2. Wählen Sie den Ressourcentyp k8s_entity aus.
3. Wählen Sie den Messwert kubernetes.io/autoscaler/cluster_pending_pods_per_ccc aus.
4. Fügen Sie einen Filter hinzu:entity_type = ComputeClass.
5. Fügen Sie einen Filter für Ihre spezifische ComputeClass hinzu: entity_name = "COMPUTECLASS_NAME".
   • Wenn Sie Pods sehen möchten, die keine ComputeClass verwenden, filtern Sie mit entity_name = "".
6. Gruppieren Sie nach metric.labels.reason, um die Autoscaler-Status für diese Pods zu sehen. Sie können Pods auch mit dem Schlüssellabel metric.labels.type gruppieren.

Beispiel für eine PromQL-Abfrage

Verwenden Sie die folgende PromQL-Abfrage, um den Status ausstehender Nutzer-Pods zu ermitteln, die die ComputeClass „COMPUTECLASS_NAME“ anfordern:

sum by (reason) (
  kubernetes_io:autoscaler_cluster_pending_pods_per_ccc{
    monitored_resource="k8s_entity",
    entity_type="ComputeClass",
    entity_name="COMPUTECLASS_NAME",
    type="user_pod"
  }
)

Messwertbezogene Gründe

Die Ausgabe des Schlüssellabels metric.labels.reason kann Folgendes enthalten:

• unable_to_provision: Das Cluster-Autoscaling ist blockiert. Pods in diesem Status für eine ComputeClass können nicht geplant werden, da keine neuen Knoten erstellt werden können. Prüfen Sie die Cluster-Autoscaling-Logs in der Steuerungsebene auf Details zu Engpässen, Kontingenten oder Fehlkonfigurationen in der ComputeClass-Definition. Prüfen Sie auch die Sichtbarkeitsereignisse des Cluster Autoscaler.

• provisioning_in_progress: Für Knoten, die die ComputeClass-Anforderungen erfüllen sollten, wurde eine Hochskalierung ausgelöst. Wenn Pods hier verbleiben, kann es zu Verzögerungen bei der Knotenerstellung oder -bereitschaft kommen.

• unprocessed: Cluster Autoscaler hat diese Pods noch nicht ausgewertet. Eine dauerhaft hohe Zahl kann auf eine Verzögerung des Autoscalers hinweisen.

• no_action_taken: Cluster Autoscaler hat entschieden, diese Pods nicht zu skalieren. Dieses Verhalten kann auf Pod-Einschränkungen zurückzuführen sein, die von den Knotentypen der ComputeClass oder anderen Limits auf Clusterebene nicht erfüllt werden können. Prüfen Sie die Pod-Spezifikation (kubectl describe pod) und die Cluster-Autoscaling-Logs.

Fehler bei der Knotenbereitstellung analysieren

Anwendbare GKE-Versionen: 1.37 und höher

Informationen zum Prüfen des aktuellen Systemstatus einer ComputeClass finden Sie unter ComputeClass-Systemstatus prüfen. Wenn Sie feststellen, dass Pods, die einer ComputeClass zugeordnet sind, den Status unable_to_provision haben, stellt Cluster Autoscaler keine neuen Knoten bereit, die den Anforderungen der ComputeClass entsprechen. Sie können den Cloud Monitoring-Messwert kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc verwenden, um die Ursache zu diagnostizieren.

1. Rufen Sie in der Cloud de Confiance Console Monitoring und dann Metrics Explorer auf.
2. Wählen Sie als Ressourcentyp k8s_entity aus.
3. Wählen Sie den Messwert als kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc aus.
4. Fügen Sie einen Filter hinzu: resource.labels.entity_type = ComputeClass.
5. Fügen Sie einen Filter für Ihre spezifische ComputeClass hinzu: entity_name = "CUSTOM_COMPUTECLASS_NAME".
   • Wenn Sie Pods sehen möchten, die keine ComputeClass verwenden, filtern Sie mit entity_name = "".
6. Wählen Sie im Bereich Gruppieren nach die Optionen metric.labels.reason und resource.labels.entity_name aus.
7. Wählen Sie einen Aggregator aus, z. B. rate oder delta.

Die Rate oder Änderung der Fehler wird nach Ursache aufgeschlüsselt angezeigt.

Fehlerursachen interpretieren

Das Feld metric.labels.reason gibt Aufschluss darüber, warum die Knotenerstellung fehlschlägt. Wenn Sie die Hauptursachen für Fehler ermitteln, können Sie Korrekturmaßnahmen ergreifen.

Das kann unter anderem folgende Gründe haben:

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. Identifizieren Sie Knotenpools in Ihrer benutzerdefinierten ComputeClass. 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 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 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 ComputeClass erstellt.

Ergebnis bewerten

• Automatische Erstellung 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 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 Limits ü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. Ermitteln Sie die aktuelle 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 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
       

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 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 sich dazu die Logs des Cluster-Autoscalings oder die Fehler der verwalteten Compute Engine-Instanzgruppe (MIG) an.

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 Autoscaling-Ereignisse zu finden, die auf eine Nichtverfügbarkeit von Ressourcen hinweisen könnten:

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 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 Fehler beim Hochskalieren 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: Achten Sie darauf, dass das Feld spec.priorities in der benutzerdefinierten ComputeClass mehrere Maschinentypen oder ‑familien als Fallbacks enthält:

      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, die keine Verzögerungen tolerieren, können Sie Compute Engine-Reservierungen erstellen, um 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 die Logs auf kontingentbezogene Fehler 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 prüfen:

   1. Rufen Sie in der Cloud de Confiance Console IAM und 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, 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 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. Prüfen Sie die YAML-Datei der benutzerdefinierten ComputeClass auf einen gpu-Block innerhalb 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 die Toleranz im Feld spec.tolerations.

Ergebnis bewerten

• GPU richtig konfiguriert: Wenn die ComputeClass die GPU-type und count definiert und Pods die Toleranz 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.
    • 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.

Spot-VM-Konfiguration prüfen

Wenn Sie Spot-VMs verwenden, muss die Einstellung spot: true in den richtigen Prioritätsregeln in Ihrem ComputeClass-Manifest enthalten sein. Außerdem sollten Sie die Preislogik des Cluster Autoscalers kennen.

ComputeClass-Manifest prüfen:

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

Suchen Sie in der Ausgabe im Feld spec.priorities nach spot: true, zum Beispiel:

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. Dieses Verhalten ist bekannt.

Ergebnis bewerten

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

• Spot-VMs können nicht geplant werden:

  • 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 im Feld priorities explizit auf, vom günstigsten bis zum teuersten für Ihre Region. So 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 Konfiguration der benutzerdefinierten ComputeClass zusammenhängen, aber deren Betrieb beeinträchtigen können.

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 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 anhand einer Vorgangs-ID mit dem folgenden Befehl überwachen:

    gcloud container operations wait OPERATION_ID --location LOCATION
    

    Ersetzen Sie OPERATION_ID durch die ID aus der Ausgabe des Befehls list. Nach Abschluss des Blockiervorgangs sollte Cluster Autoscaler 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. Prüfen Sie das Feld spec.tolerations, 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. 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 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 false ist oder weggelassen wird oder wenn die Toleranzen des Pods zu breit gefasst sind, verbleiben Arbeitslasten auf Knoten mit niedrigerer Priorität, obwohl 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

• Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, finden Sie unter Support erhalten weitere Hilfe, einschließlich Ratschlägen zu den folgenden Themen:

  • 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 lesen
• Compute-Klassen standardmäßig auf Pods anwenden
• Arbeitslasttrennung in GKE konfigurieren
• Fehlerbehebung bei Problemen mit der Hochskalierung von Cluster Autoscaler