Kubernetes-Cluster können beim Abrufen Ihrer Container-Images auf mehrere Probleme stoßen. Wenn ein Fehler auftritt, geben Ihre Pods ein ImagePullBackOff ein Zustand. So beheben Sie Fehler in dieser häufigen, aber kryptischen Nachricht, damit Sie Ihre Dienste online nutzen können.
Wie Image-Pulls funktionieren
Kubernetes muss ein Image abrufen, wenn Sie eine neue Bereitstellung erstellen oder eine vorhandene mit einer anderen Tag-Referenz aktualisieren. Die Verantwortung für das Abrufen von Bildern liegt beim Kubelet-Prozess auf jedem Worker-Knoten. Jedes Image, auf das von einem Pod-Manifest verwiesen wird, muss für alle Knoten im Cluster zugänglich sein, damit jeder von ihnen eine Containerplanungsanforderung erfüllen kann.
Der Download kann fehlschlagen, wenn der Bildpfad falsch ist, Sie nicht richtig authentifiziert sind oder das Netzwerk ausfällt. In diesem Fall zieht sich Kubernetes zurück und plant einen weiteren Download-Versuch. Die Verzögerung vor dem nächsten Pull erhöht sich exponentiell, wenn ein Versuch fehlschlägt, bis zu einer Grenze von fünf Minuten.
Wenn Ihr Pod den ImagePullBackOff anzeigt Zustand hatte Kubernetes mehrere aufeinanderfolgende Image-Pull-Fehler und wartet nun, bevor es erneut versucht. Der Container kann erst gestartet werden, wenn das Image verfügbar ist.
Sie können den Pod in diesem Zustand belassen, wenn Sie wissen, dass das Problem auf Netzwerkbedingungen oder einen anderen vorübergehenden Fehler zurückzuführen ist. Kubernetes führt schließlich einen weiteren Wiederholungsversuch durch und erfasst das Image erfolgreich. Wenn dies nicht der Fall ist, können Sie wie folgt mit dem Debuggen beginnen, damit Sie Ihren Pod aufrufen können.
Überprüfen Sie die Grundlagen
In erster Linie lohnt es sich, die Grundlagen zu überprüfen. Verweist Ihr Ressourcenmanifest auf ein gültiges Bild, das tatsächlich existiert? Überprüfen Sie den Registrierungspfad und das Image-Tag auf einfache Tippfehler.
Sie können den internen Kubernetes-Status mit dem describe pod überprüfen Befehl in Kubectl. Dies gibt Ihnen mehr Informationen als get pod und das Kubernetes-Dashboard bereitstellen.
kubectl describe pod my-pod --namespace my-namespace
Änderungen im Lebenszyklus des Pods werden unter der Überschrift „Ereignisse“ angezeigt. Das erste Ereignis wird Scheduled; darauf sollte ein Pulling folgen Ereignis für den ersten Pull-Versuch. Danach sehen Sie einen Failed oder BackOff Ereignis, wenn der Pull nicht erfolgreich sein konnte. Diese werden später in der Liste wiederholt, wenn sich Kubernetes noch in einem Backoff- und Wiederholungszyklus befindet.
Lesen der Message die mit diesen Ereignissen verbunden sind, liefern oft die Hauptursache des Problems. Ein manifest for image:tag not found Meldung bedeutet, dass das Bild gültig ist, Sie aber ein ungültiges Tag angegeben haben. Wenn does not exist or no pull access angezeigt wird , überprüfen Sie, ob die Registrierungs- und Bildpfade korrekt sind. Wenn Sie sicher sind, dass sie Recht haben, hängt das Problem mit einer falschen Authentifizierung zusammen.
Verwalten von Registrierungsanmeldungen
Sie müssen angemeldet sein, bevor Sie private Bilder abrufen können. In Kubernetes ist es ein zweistufiger Mechanismus:Erstellen Sie ein Geheimnis mit Anmeldeinformationen und verweisen Sie dann in Ihren Pod-Definitionen auf dieses Geheimnis.
Das Pod-Feld heißt imagePullSecrets . Es muss ein Kubernetes-Geheimnis angeben, das ein Anmeldetoken für die Registrierung bereitstellt. Dieses Geheimnis sollte einen Docker-kompatiblen JSON-Wert speichern.
apiVersion: v1
kind: Secret
type: kubernetes.io/dockerconfigjson
metadata:
name: image-pull-secret
data:
.dockerconfigjson: {{ "{"auths": {"registry.example.com": {"username": "demo-user", "password": "my-password"}}}" | b64enc }}
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: registry.example.com/my-image:latest
imagePullSecrets:
- name: image-pull-secret
Dieses Manifest zeigt, wie Sie ein Geheimnis erstellen, das Sie bei registry.example.com anmeldet als demo-user mit dem Passwort my-password . Der Pod verweist mit seinem Namen auf das Geheimnis. Kubelet-Prozesse auf den Knoten Ihres Clusters enthalten die config.json von Docker Snippet, wenn sie Bilder aus der Registrierung abrufen.
Das Snippet muss Base64-codiert sein, um ein gültiger geheimer Kubernetes-Wert zu sein. Sie können einen vorcodierten Wert verwenden oder Klartext durch b64enc von YAML leiten , wie im Manifest oben gezeigt.
Die Art der Anmeldeinformationen, die Sie verwenden, hängt von Ihrer Registrierung ab. In vielen Fällen password tatsächlich ein persönlicher Zugriffstoken oder API-Schlüssel sein. Docker Hub erfordert ein Zugriffstoken, das in Ihren Kontoeinstellungen generiert wird, wenn Sie die Zwei-Faktor-Authentifizierung für Ihr Konto aktiviert haben.
Registrierungsratenlimits
Wenn Sie Ihre Registrierungs-URL, den Bild-Tag-Namen und die Anmeldeinformationen überprüft haben, sehen Sie möglicherweise ImagePullBackOff aufgrund von Registry-Ratenbegrenzungen. Docker Hub beschränkt Sie jetzt auf 100 Container-Pulls alle sechs Stunden. Dies erhöht sich auf 200 Pulls pro sechs Stunden, wenn Sie Ihre Anmeldeinformationen angeben. Diese Obergrenze könnte in einem aktiven Cluster mit vielen häufig bereitgestellten Pods schnell erreicht werden.
Ein Pull-Fehler aufgrund einer Ratenbegrenzung manifestiert sich auf die gleiche Weise wie ein Authentifizierungsproblem. Sie müssen warten, bis genügend Zeit verstrichen ist, damit die Obergrenze abläuft. Kubernetes sollte das Image dann erfolgreich abrufen und Ihre Pods aufrufen.
Erwägen Sie für eine längerfristige Minderung die Ausführung Ihrer eigenen In-Cluster-Registrierung oder Ihres eigenen Proxys, um Ihre Bilder zwischenzuspeichern. Dies kann die Häufigkeit, mit der Sie auf die Server von Docker zugreifen, erheblich reduzieren und hilft Ihnen dabei, die Ratenbegrenzungen einzuhalten.
Zusammenfassung
Kubernetes-Pods geben ein ImagePullBackOff ein Zustand, wenn ein Knoten kein Bild abrufen kann. Kubelet wird den Pull regelmäßig wiederholen, sodass vorübergehende Fehler keinen manuellen Eingriff erfordern, um behoben zu werden.
Wenn Sie sicher sind, ein ImagePullBackOff nicht nur ein vorübergehender Fehler ist, stellen Sie zunächst sicher, dass der Bildpfad des Pods gültig ist. Wenn dies der Fall ist, vermuten Sie falsche Anmeldeinformationen oder eine erschöpfte Ratenbegrenzung. Verwenden von kubectl describe zeigt die Abfolge von Ereignissen, die zu dem Fehler geführt haben.
Als letzte Option können Sie versuchen, das Image selbst von einem anderen Computer abzurufen, um sicherzustellen, dass der Remote-Registrierungsserver tatsächlich aktiv ist. Wenn Sie das Image abrufen können, Ihr Cluster jedoch nicht, haben Sie möglicherweise allgemeinere Netzwerkprobleme, die verhindern, dass Ihre Knoten die Registrierung erreichen.