Warum zeigen Pods beim Abrufen von Images pull QPS exceeded Fehler an?

Beim Starten von Pods können Fehlermeldungen auftreten, die darauf hinweisen, dass das Herunterladen von Images gedrosselt wird, beispielsweise mit Meldungen wie pull QPS exceeded.

Wenn Sie Pods bereitstellen, die Container-Images abrufen müssen, können Sie die folgenden Symptome beobachten:

  • Fehlermeldungen, die pull QPS exceeded beim Start des Pods enthalten
  • Langsame Bildzugriffszeiten, insbesondere wenn mehrere große Bilder gezogen werden
  • Es dauert länger als erwartet, bis die Schoten den Zustand Running erreichen
  • Bildzugoperationen, die scheinbar gedrosselt oder in der Geschwindigkeit begrenzt sind

Die wahrscheinlichste Ursache für langsames Herunterladen von Images mit Fehlern pull QPS exceeded ist, dass Ihre VPC-Worker-Knoten an ihre Grenze der Festplatten-E/A-Bandbreite stoßen.

VPC-Arbeitsknoten haben je nach ihrer Konfiguration unterschiedliche Bandbreitengrenzen:

  • Standard-Arbeitsknoten (ohne Sekundärspeicher): Begrenzt auf 393 Mbit/s (49 MB/Sek.) für Festplatten-E/A-Vorgänge
  • Worker-Knoten mit sekundärem Speicher: Höhere Bandbreitenbeschränkungen je nach ausgewählter Speicherebene

Wenn mehrere Pods gleichzeitig versuchen, große Container-Images zu ziehen:

  1. Jeder Image-Pull-Vorgang verbraucht Festplatten-E/A-Bandbreite
  2. Die kombinierte Bandbreitennachfrage kann das Limit von 49 MB/Sek. schnell sättigen
  3. Sobald das Limit erreicht ist, verlangsamen sich die Bildziehvorgänge erheblich
  4. Kubernetes kann pull QPS exceeded Fehler melden, da es den Betrieb drosselt

Um festzustellen, ob Sie das Bandbreitenlimit der VPC-Arbeitsknoten erreichen, verwenden Sie die Überwachungsfunktionen von IBM Cloud.

Festplatten-E/A-Bandbreite prüfen

  1. Navigieren Sie in der Konsole OpenShift Ihres Clusters zu Beobachten → Metriken.

  2. Verwenden Sie die folgende Prometheus Abfrage, um die Lese- und Schreibraten der Festplatte zu überwachen:

    irate(node_disk_read_bytes_total[2m]) + irate(node_disk_written_bytes_total[2m])
    
  3. Interpretieren Sie die Ergebnisse:

    • Wenn eines der Geräte Werte anzeigt, die sich 49M (49 MB/Sek.) nähern, stoßen Sie an die Bandbreitengrenze.
    • Anhaltende Werte an oder in der Nähe dieses Grenzwerts bei Bildzugoperationen bestätigen eine Bandsättigung.
    • Mehrfache Überschreitungen dieser Grenze deuten auf wiederholte Bandbreitenbeschränkungen hin.

Bildzugriffszeiten prüfen

Sie können die Abrufzeiten auch direkt überprüfen:

oc get events -A | grep -E "Successfully pulled image"

Dieser Befehl zeigt an, wie lange jeder Bildabruf gedauert hat, und hilft Ihnen, langsame Abrufe zu erkennen.

Problem beheben

Primäre Lösung: Verwendung von Worker-Pools mit sekundärem Speicher

Die empfohlene Lösung ist die Verwendung von Worker-Pools mit angeschlossenem Sekundärspeicher. Der sekundäre Speicher mit 10iops-tier bietet eine dedizierte E/A-Bandbreite, die nicht mit der Boot-Platte konkurriert, was zu einem viel höheren Durchsatz für gleichzeitige Image-Pulls und schnelleren Pod-Startzeiten führt.

  1. Erstellen Sie einen neuen Worker-Pool mit sekundärem Speicher.

    • Wenn Sie einen neuen Worker-Pool erstellen, wählen Sie eine Variante mit sekundärem Speicher.
    • Verwenden Sie eine der 10iops-tier Speicheroptionen für eine optimale Leistung.
  2. Migrieren Sie Ihre Workloads in den neuen Pool.

  3. Entleeren und entfernen Sie den alten Arbeitsvorrat, nachdem die Migration abgeschlossen ist.

Weitere Hinweise

Ein Upgrade auf Sekundärspeicher ist zwar die primäre Lösung, aber Sie können auch eine andere wählen:

Bildgrößen reduzieren
Verwenden Sie mehrstufige Aufbauten und minimieren Sie Schichten
Bild-Caching verwenden
Häufig verwendete Bilder auf Worker Nodes vorziehen
Optimieren Sie imagePullPolicy
Konfigurieren Sie Ihre Pod-Spezifikationen, um unnötige Abrufe zu vermeiden:
  • Verwenden Sie imagePullPolicy: IfNotPresent, um Bilder nur dann zu beziehen, wenn sie nicht bereits auf dem Knoten vorhanden sind.
  • Vermeiden Sie imagePullPolicy: Always, es sei denn, Sie müssen jedes Mal die neueste Version abrufen.
  • Verwenden Sie für Produktions-Workloads spezifische Bild-Tags, nicht latest, in Kombination mit IfNotPresent, um die Anzahl der Pulls zu minimieren.
Überwachung und Warnmeldungen einrichten
Richten Sie Warnungen für anhaltend hohe Festplatten-E/A-Raten ein, die sich 49 MB/Sek. nähern.
  • Überwachen Sie die Abrufzeiten von Images als Teil Ihrer Bereitstellungsmetriken.
  • Verfolgen Sie die Startzeiten der Pods, um Leistungseinbußen zu erkennen.