Wie debugge ich "ImagePullBackOff"?

Auf einmal kann ich einige Images nicht mehr bereitstellen, die zuvor bereitgestellt werden könnten. Ich habe folgenden Pod-Status:

[root@webdev2 origin]# oc get pods 
NAME                      READY     STATUS             RESTARTS   AGE 
arix-3-yjq9w              0/1       ImagePullBackOff   0          10m 
docker-registry-2-vqstm   1/1       Running            0          2d 
router-1-kvjxq            1/1       Running            0          2d 

Die Anwendung wird einfach nicht gestartet. Der Pod versucht nicht, den Container auszuführen. Von der Event-Seite habe ich Back-off pulling image "172.30.84.25:5000/default/arix@sha256:d326. Ich habe überprüft, ob ich das Bild mit dem Tag mit ziehen kann docker pull.

Ich habe auch das Protokoll des letzten Containers überprüft. Es war aus irgendeinem Grund geschlossen. Ich denke, der Pod sollte zumindest versuchen, ihn neu zu starten.

Ich habe keine Ideen mehr, um die Probleme zu beheben. Was kann ich mehr überprüfen?

Sie können die Syntax " Beschreibe Pod " verwenden

Für OpenShift verwenden Sie:

oc describe pod <pod-id>  

Für Vanille Kubernetes:

kubectl describe pod <pod-id>  

Untersuchen Sie die Ereignisse der Ausgabe. In meinem Fall zeigt es Back-Off Pulling Image Coredns / Coredns: Neueste

In diesem Fall kann das Bild coredns / coredns: latest nicht aus dem Internet abgerufen werden.

Events:
  FirstSeen LastSeen    Count   From                SubObjectPath           Type        Reason      Message
  --------- --------    -----   ----                -------------           --------    ------      -------
  5m        5m      1   {default-scheduler }                        Normal      Scheduled   Successfully assigned coredns-4224169331-9nhxj to 192.168.122.190
  5m        1m      4   {kubelet 192.168.122.190}   spec.containers{coredns}    Normal      Pulling     pulling image "coredns/coredns:latest"
  4m        26s     4   {kubelet 192.168.122.190}   spec.containers{coredns}    Warning     Failed      Failed to pull image "coredns/coredns:latest": Network timed out while trying to connect to https://index.docker.io/v1/repositories/coredns/coredns/images. You may want to check your internet connection or if you are behind a proxy.
  4m        26s     4   {kubelet 192.168.122.190}                   Warning     FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "coredns" with ErrImagePull: "Network timed out while trying to connect to https://index.docker.io/v1/repositories/coredns/coredns/images. You may want to check your Internet connection or if you are behind a proxy."

  4m    2s  7   {kubelet 192.168.122.190}   spec.containers{coredns}    Normal  BackOff     Back-off pulling image "coredns/coredns:latest"
  4m    2s  7   {kubelet 192.168.122.190}                   Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "coredns" with ImagePullBackOff: "Back-off pulling image \"coredns/coredns:latest\""

Zusätzliche Debugging-Schritte

1. Versuchen Sie, das Docker-Image und das Tag manuell auf Ihrem Computer abzurufen
2. Identifizieren Sie den Knoten, indem Sie 'kubectl / oc get pods -o wide' ausführen.
3. ssh in den Knoten (wenn Sie können), der das Docker-Image nicht ziehen kann
4. Überprüfen Sie, ob der Knoten das DNS der Docker-Registrierung auflösen kann, indem Sie einen Ping ausführen.
5. Versuchen Sie, das Docker-Image manuell auf den Knoten zu ziehen
6. Wenn Sie eine private Registrierung verwenden, überprüfen Sie, ob Ihr Geheimnis existiert und das Geheimnis korrekt ist. Ihr Geheimnis sollte sich auch im selben Namespace befinden. Danke swenzel
7. Einige Registries verfügen über Firewalls, die den Zugriff auf IP-Adressen einschränken. Die Firewall blockiert möglicherweise den Pull
8. Einige CIs erstellen Bereitstellungen mit temporären Docker-Geheimnissen. Das Geheimnis läuft also nach ein paar Tagen ab (Sie fragen nach Produktionsfehlern ...)

Haben Sie versucht zu bearbeiten, um zu sehen, was falsch ist (ich hatte den falschen Bildort)?

kubectl edit pods arix-3-yjq9w

oder sogar deinen Pod löschen?

kubectl delete arix-3-yjq9w

Ich habe vergessen, das mit 1.0.8 gekennzeichnete Bild an die ECR (AWS Images Hub) zu senden ... Wenn Sie Helm verwenden und ein Upgrade durchführen durch:

Helm Upgrade Minta-Benutzer ./src/services/user/helm-chart

Stellen Sie sicher, dass das Bild-Tag in values.yaml verschoben wird (an ECR oder Docker Hub usw.), zum Beispiel: (Dies ist mein Helmdiagramm / values.yaml)

replicaCount: 1

image:
   repository:dkr.ecr.us-east-1.amazonaws.com/minta-user
   tag: 1.0.8

Sie müssen sicherstellen, dass das Bild: 1.0.8 gedrückt wird!

Ich hatte ein ähnliches Problem, aber statt eines waren alle meine Pods nicht bereit und zeigten den Bereitschaftsstatus 0/1 an

Ich habe viele Dinge ausprobiert, aber schließlich stellte ich fest, dass der Kontext nicht richtig eingestellt war. Bitte verwenden Sie den folgenden Befehl und stellen Sie sicher, dass Sie sich im richtigen Kontext befinden

kubectl config get-context

Wenn der Pod auf GKE tot ist, ist es am besten, nach Ereignissen zu suchen. Es wird detaillierter gezeigt, worum es bei dem Fehler geht.

In meinem Fall hatte ich:

Failed to pull image "gcr.io/project/imagename@sha256:c8e91af54fc17faa1c49e2a05def5cbabf8f0a67fc558eb6cbca138061a8400a":
 rpc error: code = Unknown desc = error pulling image configuration: unknown blob

Es stellte sich heraus, dass das Bild irgendwie beschädigt war. Nach dem Repushing und der Bereitstellung mit dem neuen Hash funktionierte es wieder.

Führen Sie die Docker-Anmeldung aus

Schieben Sie das Bild zum Docker-Hub

Pod neu erstellen

Dies löste das Problem für mich. Ich hoffe es hilft.