Fiksing av Kubernetes ImagePullbackoff

Hvis du har jobbet med Kubernetes i lang tid, har du sannsynligvis møtt ImagePullbackoff -tilstanden. Hvis du ikke er kjent med dette problemet, kan det være frustrerende. Så i denne artikkelen vil du lede deg gjennom det grunnleggende om dette problemet, hvordan du kan feilsøke det, hva noen typiske grunner er, og hvor du kan begynne hvis du møter det.

Hva er ImagePullbackoff -feilen?

ImagePullbackoff -problemet er forårsaket av at Kubernetes container runtime ikke er i stand til å hente bildet fra verken et offentlig eller privat containerregister. Kubernetes vil stadig trekke bildet med en voksende backoff -forsinkelse, som indikert av backoff -komponenten. Med hvert forsøk vil Kubernetes øke forsinkelsen til den oppfyller den fem minutter lange begrensningen.

Det kan virke som en bred uttalelse som antyder at container kjøretid (enten Docker, container eller noe annet) ikke klarer å hente bildet fra registeret, men la oss se på de forskjellige årsakene du kan finne i neste avsnitt.

De foregående seksjonene vil gå over de forskjellige grunnene til at poden din kan være i imagepullbackoff -tilstanden når du starter beholderen. Du vil også lære å feilsøke og løse denne fryktede feilen.

Hva som får imagepullbackoff -feilen til å oppstå?

Følgende er noen av grunnene til at podet ditt kan sitte fast i ImagePullbackoff -tilstanden:

• Bilde ikke tilgjengelig
• Navnet eller taggen for bildet er feil.
• Privat bilde brukes, og det er et problem med autentisering.
• Det er vanskelig med nettverket.
• Navnet på registeret er unøyaktig.
• Prisgrenser for containerregistre
• POD har ikke tilgang til bildet fordi den mangler nødvendig legitimasjon.
• Grenser for registerpriser

Hvordan feilsøke imagepullbackoff?

La oss se på noen av de sannsynlige årsakene som er oppført i Bulleted List.

1. Containerbildet er ikke tilgjengelig, eller navnet som brukes er unøyaktig
Problemet genereres vanligvis hvis det er en skrivefeil eller det faktum at bildet som presses til containerregisteret mislykkes, men du viser til et bilde som ikke er der. La oss forsøke å gjenskape dette ved å lage en pod med et fiktivt bildetavn. Følgende kommando oppnår dette.

$ KUBECTL RUN NEWAPP --IMAGE = MY_IMAGE/MY_IMAGE: SISTE

Som du ser er poden opprettet.

Hvis vi prøver å få detaljene om poden med Get POD -kommandoen som du kan se nedenfor.

$ Kubectl få pod

Her vises det at bildet ikke er der, og at vi ikke klarer å trekke det.

Du kan benytte deg av Kubectl -kommandoen med det formål å oppdage årsaken og finne mer informasjon om dette problemet. Fordi kommandoen produserer mye output, vil vi bare vise seksjonene som er relevante for diskusjonen vår. Den virkelige feilmeldingen sees i følgende utgang under hendelser i meldingskolonnen:

$ Kubectl beskriver pod newapp

Noen deler av det produserte resultatet er som følger etter å ha utført beskrivingskommandoen.

2. Taggen eksisterer ikke
Det er mulig at bildeskodene du prøver å få har blitt pensjonist, eller at du skrev feilnavnet. Under noen omstendigheter vil poden din sitte fast i ImagePullbackoff -tilstanden igjen, som vist i kodeprøven nedenfor. For å reprodusere dette problemet, brukte vi med vilje det feilaktige tagnavnet, later i stedet for siste.

$ KUBECTL RUN APPTWO --IMAGE = NGINX: LATES

Kommandoen ovenfor har opprettet poden med navnet du har gitt.

Etter det får vi detaljene om poden med Get POD -kommandoen.

$ kubectl få pod

Som et resultat mislykkes bildet.

Nå bruker vi igjen beskrivingskommandoen for å forstå årsaken til denne statusen.

$ kubectl beskriver pod apptwo

I denne delen av hendelser kan du se årsaken til ImagePullbackoff -feilen.

Årsaken vises tydelig her for din bedre forståelse.

3. Feil legitimasjon og privat bildregister

Her prøver vi å reprodusere problemet, og for det spiste vi å snurre opp en pod som prøver å trekke et bilde fra et privat register.

$ KUBECTL RUN APPTHREE --IMAGE = DOCKER.io/hiyou/nameofimage

Kommandoen ovenfor gir følgende resultat.

Etter det har vi utført beskrivelseskommandoen.

Den beskrevne kommandoen viser de overordnede detaljene i poden og nevner også årsakene bak ImagePullbackoff -feilen.

Vi har ikke lagt en hemmelighet til Kubernetes eller inkludert en referanse til den i pod -definisjonen. Pod vil sitte fast i ImagePullbackoff -staten nok en gang, og varslingen verifiserer at tilgang til registeret nektes:

Du kan opprette en hemmelighet med Kubectl -kommandoen nedenfor for å fikse denne feilen. Kubectl -kommandoen brukes deretter for å opprette en hemmelighet for et Docker -register (privat).

4. Registerfrekvensgrenser

Hvis du verifiserer noen av legitimasjonene dine, for eksempel URL, detaljer og tagnavn, kan du få ImagePullbackOff på grunn av Registry Rate -grensene. Du kan nå bare trekke 100 containere hver sjette time på Docker Hub. Hvis du oppgir påloggingsdetaljene dine, vil dette klatre til 200 trekk hver sjette time. I en livlig klynge med mange ofte utplasserte belg, kan den grensen nås raskt.

Du må vente til hetten er nådd etter en bestemt tidsbegrensning. Kubernetes skal nå kunne trekke bildet og starte belgene dine.

Vurder å bruke deg er i klyngregisteret sammen med en proxy for å cache de relevante bildene dine. Dette kan hjelpe deg med å forbli innenfor hastighetsbegrensningene ved å redusere antall ganger du treffer Dockers servere.

Konklusjon

Når en node ikke klarer å trekke et bilde, går Kubernetes Pods inn i ImagePullbackoff -tilstanden. Kubelet vil prøve trekket regelmessig, så midlertidige problemer vil ikke kreve noen manuell inngrep. Denne artikkelen diskuterte ImagePullbackoff og tre potensielle kilder til problemet. Selv om det kan være flere årsaker, kan det å lese feilmeldingen raskt avsløre den sanne årsaken til problemet. Hvis du undersøker og følger prosedyrene ovenfor, bør det være enkelt å løse dette problemet.