Slik fikser du Kubernetes CrashLoopBackOff i lokal Minikube

Målet er ikke bare å få CrashLoopBackOff til å forsvinne i noen sekunder. En god fiksing holder containeren i gang, holder Poden Ready når den skal motta trafikk, stopper at omstartstallene øker, og produserer logger som viser en normal applikasjonsoppstart. I lokal Minikube bør du også bekrefte at Minikube-klusteret selv er sunt før du gjenoppbygger det.

Kubernetes' gjeldende dokumentasjon beskriver CrashLoopBackOff som en backoff-tilstand som oppstår når en container gjentatte ganger starter, feiler og startes på nytt. Kubernetes forskyver gradvis ytterligere omstarter for å unngå en tett feilsyklus. Etiketten er derfor et symptom på gjentatt containerfeil, ikke selve rotårsaken. Se Kubernetes Pod-livssyklusdokumentasjon.

Denne veiledningen bruker fire diagnostiske faser. Følg dem i rekkefølge og stopp når du har identifisert og korrigert den faktiske årsaken. Minikube er ment for lokal læring og utvikling, så den samme applikasjonsnivådiagnosen overføres til andre Kubernetes-kluster, mens de Minikube-spesifikke gjenopprettingsstegene ikke nødvendigvis gjelder for produksjon. Se den gjeldende Minikube startdokumentasjonen.

Hvordan ser en vellykket fiksing ut?

• Den berørte containeren forblir i en kjørende tilstand lenge nok til å fullføre normal oppstart.
• Poden blir Ready hvis den forventes å tjene trafikk.
• Omstartstallet slutter å øke i løpet av observasjonsperioden.
• kubectl logs viser en normal oppstartsbane i stedet for at den samme fatale feilen gjentar seg.
• Liveness- og startup-prober, hvis konfigurert, slutter å feile.
• Applikasjonen kan nå tjenestene eller avhengighetene den faktisk trenger.
• minikube status viser et sunt lokalt kluster når klusterhelsen var i tvil.

Krev ikke at omstartstelleren til en eksisterende Pod går tilbake til null. Kubernetes registrerer hvor mange ganger containeren har blitt startet på nytt i den Poden; en vellykket reparasjon kan etterlate et ikke-null historisk antall. Det som betyr noe, er at tallet slutter å øke. Hvis en Deployment-utrulling oppretter en ny Pod, starter den nye Poden vanligvis med sitt eget ferske omstartstall.

Fase 1: Bevis hvilken container som krasjer

Start med Pod-listen:

kubectl get pods -A

Hvis du allerede kjenner navnerommet, avgrens kommandoen:

kubectl get pods -n my-namespace

Beskriv deretter den berørte Poden:

kubectl describe pod <pod-name> -n <namespace>

Se på fire felt i containerdelen:

• State — containeren kan for øyeblikket være Waiting med årsaken CrashLoopBackOff.
• Last State — ofte Terminated, som forteller deg hva som skjedde i den forrige kjøringen.
• Reason and Exit Code — nyttige ledetråder som Error eller OOMKilled.
• Restart Count og Events — bevis på at feilen gjentar seg og om prober eller kubelet-handlinger er involvert.

En subtil men nyttig distinksjon: Podens overordnede fase kan fortsatt være Running mens en av containerne venter i CrashLoopBackOff. STATUS-kolonnen som skrives ut av kubectl get pods er en praktisk lesbar oppsummering, ikke en komplett diagnose av Pod-livssyklusstatus.

Kvalitetskontroll: ved slutten av denne fasen bør du vite den nøyaktige Poden, navnerommet og containeren som starter på nytt. Hvis Poden har flere containere, identifiser hvilken som feiler før du leser logger.

Hvis feilen faktisk ikke er CrashLoopBackOff

Tving ikke alle oppstartsproblemer inn i denne veiledningen. ImagePullBackOff, ErrImagePull, Pending og ContainerCreating peker mot ulike feilstadier. For eksempel skjer et bilde-hentingsproblem før applikasjonsprosessen starter, så applikasjonslogger kan ikke eksistere ennå.

Endre tilnærming når: Events-delen peker mot bilde-henting, volummontering, planlegging eller opptaksfeil i stedet for en container som starter og avsluttes.

Fase 2: Les de gjeldende og tidligere loggene til den feilede containeren

For en Pod med én container, start med:

kubectl logs <pod-name> -n <namespace>

Når containeren starter på nytt raskt, er den mest nyttige kommandoen ofte:

kubectl logs <pod-name> -n <namespace> --previous

Kubernetes dokumenterer --previous som alternativet som skriver ut logger fra den forrige instansen av containeren i Poden. Hvis Poden inneholder mer enn én container, spesifiser den som feiler:

kubectl logs <pod-name> -n <namespace> -c <container-name> --previous

Se offisiell kubectl logs-referanse.

Klassifiser den første meningsfulle fatale feilen i stedet for å fokusere på den siste "prosessen avsluttet"-linjen. Typiske mønstre inkluderer:

Kvalitetskontroll: du bør kunne formulere en falsifiserbar hypotese som "applikasjonen avsluttes fordi DATABASE_HOST peker til en ikke-eksisterende Service", ikke bare "Kubernetes er ødelagt".

Behandle ikke avslutningskode 137 alene som bevis på OOM

En avslutningskode på 137 vises vanligvis når en prosess mottar SIGKILL, men det sterkere Kubernetes-spesifikke signalet er Last State: Terminated med Reason: OOMKilled. Kubernetes' ressursforvaltningsdokumentasjon viser denne kombinasjonen når en container overskrider minsegrensen. Se Kubernetes ressursforvaltningsdokumentasjon.

Nyttig handling: baser diagnosen på avslutningsårsaken og omkringliggende Events, ikke tallet 137 alene.

Fase 3: Fiks rotårsaken, ikke backoff-timeren

Når du vet hvorfor containeren avsluttes, endre den minste tingen som adresserer den årsaken. Å starte Poden på nytt gjentatte ganger reparerer ikke en dårlig kommando, manglende konfigurasjon, feilende helsesjekk eller utilstrekkelig minne.

Tilfelle A: applikasjonen prøver å nå en annen tjeneste på localhost

Inne i en normal Kubernetes-Pod deler containere i samme Pod et nettverksnavnerom og kan kommunisere med hverandre over localhost. En database som kjører i en annen Pod, nås ikke via applikasjonens localhost. Kubernetes oppretter DNS-navn for Services slik at arbeidsbelastninger kan oppdage dem etter tjenestenavn. Se Kubernetes nettverkskonsepter og DNS for Services og Pods.

Hvis Serviceen din heter postgres i samme navnerom, kan applikasjonen kanskje bruke:

DATABASE_HOST=postgres

På tvers av navnerom, bruk et navneromskvalifisert navn som postgres.data eller det fullt kvalifiserte tjenestenavnet som er passende for klusterdomenet ditt.

Verifiser Serviceen før du redigerer applikasjonen:

kubectl get svc -A
kubectl get endpointslices -n <namespace>

Endre tilnærming når: Serviceen eksisterer, men har ingen brukbare backend-endepunkter. I det tilfellet er det ikke nok å fikse klientens vertsnavn; diagnostiser serverens Deployment eller Service-selector.

Tilfelle B: ConfigMap- eller Secret-verdier er feil

Undersøk referansene i arbeidsbelastningsmanifestet:

kubectl get deployment <name> -n <namespace> -o yaml
kubectl get configmap -n <namespace>
kubectl get secret -n <namespace>

Kubernetes støtter miljøvariabler fra env, ConfigMaps og Secrets. En nyttig detalj er at ConfigMap-verdier som forbrukes som miljøvariabler ikke oppdateres i en allerede kjørende prosess når ConfigMap endres; Poden må erstattes. Det samme gjelder Secret-verdier som forbrukes som miljøvariabler. Se Kubernetes ConfigMap-dokumentasjon og Kubernetes Secret-injeksjonsdokumentasjon.

For en Deployment, etter å ha korrigert konfigurasjonen, er en utrullingsomstart en måte å opprette nye Pods på:

kubectl rollout restart deployment/<name> -n <namespace>
kubectl rollout status deployment/<name> -n <namespace>

Kvalitetskontroll: verifiser at den nye Poden faktisk bruker den tiltenkte verdien. Anta ikke at redigering av en ConfigMap umiddelbart endrer en miljøvariabel inne i en eksisterende container.

Tilfelle C: en liveness- eller startup-probe dreper en treg applikasjon

Kubernetes definerer tre probetyper med ulike formål:

• Startup probe: bestemmer om applikasjonsoppstarten er fullført. Mens den er aktiv, venter liveness- og readiness-prober.
• Liveness probe: bestemmer når Kubernetes skal starte en fastlåst eller usunn container på nytt.
• Readiness probe: bestemmer om en Pod skal motta trafikk gjennom Services.

En vanlig misforståelse er at en feilende readiness-probe forårsaker en omstart. Det gjør den ikke. En readiness-feil gjør Poden unready; gjentatte liveness- eller startup-probefeil kan forårsake containeromstarter. Se Kubernetes probe-konsepter og den offisielle probe-konfigurasjonsveiledningen.

Hvis applikasjonen legitimt trenger en lang oppstart, vurder en startup-probe med nok failureThreshold × periodSeconds-tid til å dekke realistisk oppstart. Deaktiver ikke alle prober bare for at statusen skal se grønn ut; det fjerner nyttig helsebeskyttelse.

Kvalitetskontroll: proben bør teste en betingelse som gjenspeiler dens formål, og applikasjonen bør overleve normal oppstart uten å bli drept for tidlig.

Tilfelle D: containeren er OOMKilled

Sammenlign først containerens minsegrense med dens faktiske oppstartsbehov. Et lite eksempel:

resources:
  requests:
    memory: "256Mi"
  limits:
    memory: "512Mi"

Hvis Reason: OOMKilled vises og applikasjonen legitimt krever mer enn den konfigurerte grensen, øk grensen forsiktig eller reduser applikasjonens minsebruk. Hvis Minikube selv er sulten på minne, kan det å bare øke containergrensen enkelt flytte problemet til noden.

Den gjeldende Minikube-dokumentasjonen sier at den standard lokale oppsettet forventer minst 2 CPU-er, 2 GB ledig minne og 20 GB ledig diskplass. Minikube støtter også endring av konfigurert klusterminne, noe som krever en omstart. Se Minikubes gjeldende startkrav.

Endre tilnærming når: flere urelaterte Pods feiler eller blir evikert, eller Minikube selv er usunt. Det peker utover én Deployments minsegrense.

Fase 4: Verifiser stabilitet og avgjør om problemet er på klusternivå

Etter å ha anvendt fiksen, se på arbeidsbelastningen i stedet for å sjekke den én gang:

kubectl get pods -n <namespace> -w

For en Deployment:

kubectl rollout status deployment/<name> -n <namespace>

Les deretter de nye loggene:

kubectl logs <new-pod-name> -n <namespace>

Et sterkt suksessignal er ikke enkelt STATUS=Running. Bekreft alle disse der det er aktuelt:

• READY når den forventede verdien, som 1/1.
• Omstartstallet forblir uendret mens du observerer normal oppstart og trafikk.
• Ingen nye BackOff-, probe-feil- eller OOM-hendelser vises.
• Applikasjonsloggene viser vellykket initialisering.
• Serviceen eller den lokale tilgangsbanen faktisk når applikasjonen.

Hvis applikasjonen fortsatt feiler, sjekk om Minikube selv er sunt

Kjør:

minikube status
kubectl get pods -A

Minikube status-kommandoen rapporterer tilstanden til det lokale klusteret, inkludert vert, kubelet, API-server og kubeconfig-status. Se den offisielle minikube status-referansen.

Hvis kontrollplanet eller kjerne-system-Pods er usunne, samle klusterdiagnostikk:

minikube logs --problems
minikube logs

Minikubes dokumentasjon er eksplisitt på at minikube logs er for feilsøking av det lokale Kubernetes-klusteret, ikke din brukers applikasjonskode. Bruk kubectl logs for applikasjonscontaineren og minikube logs når klusteret eller noden selv er mistenkelig. Se den gjeldende minikube logs-referansen og Minikube feilsøkingsveiledning.

Endre tilnærming når: kjerne-Kubernetes-komponenter feiler, API-serveren er utilgjengelig, Minikube-status er usunn, eller mange urelaterte arbeidsbelastninger feiler samtidig. På det tidspunktet er det usannsynlig at fortsettelse av å redigere én Deployment løser det underliggende problemet.

Bør du slette og gjenopprette Minikube-klusteret?

Kun etter at du har skilt et applikasjonsproblem fra et klusterproblem. Å gjenopprette et lokalt utviklingskluster kan være rimelig når klusteret er engangsbruk, manifestene dine er reproduiserbare, og Minikube selv er korrupt eller feilkonfigurert. Det er et dårlig første svar på en applikasjon som avsluttes med en tydelig stack trace.

Kommandoer som minikube delete fjerner det lokale klusteret. Det kan også fjerne lokal Kubernetes-tilstand og data du forventet å beholde. Ikke bruk sletting som en diagnostisk snarvei når et persistent volum, lokal database eller manuelt opprettet ressurs inneholder den eneste kopien av noe viktig.

Kvalitetsterskel for å bytte til klustergjenoppretting: du har bekreftet at feilen ikke forklares av arbeidsbelastningens kommando, konfigurasjon, avhengighet, prober eller ressursgrenser; Minikube-helsen er unormal; og den lokale tilstanden er enten sikkerhetskopiert eller trygt reproduiserbar.

Et kompakt beslutningstre

Hva denne arbeidsflyten ikke kan garantere

En lokal CrashLoopBackOff kan avsløre en applikasjonsfeil, avhengighetsfeil, probe-feil, ressursgrense, arkitekturmismatch, manglende fil, tillatelsesproblem eller mange andre oppstartsfeil. Ingen fast kommandosekvens kan identifisere alle årsaker uten å lese den faktiske avslutningsårsaken, Events og logger.

Videre beviser ikke en fiks som fungerer i Minikube automatisk produksjonsklarhet. Produksjonskluster kan bruke ulike lagringsklasser, sikkerhetspolicyer, ingress-kontrollere, nodearkitekturer, nettverkspolicyer, ressurskvoter, secret-systemer eller eksterne tjenester. Minikube er verdifullt for å reprodusere og forstå container-nivåfeilen, men miljøspesifikk atferd må fortsatt testes der applikasjonen faktisk skal kjøre.

Endelig sjekkliste

• Identifiser den nøyaktige feilende containeren og navnerommet.
• Les Last State, avslutningsårsak, avslutningskode, omstartstall og Events.
• Bruk kubectl logs --previous for containere som starter på nytt raskt.
• Gjør bevisene om til én spesifikk rotårsakshypotese.
• Fiks konfigurasjon, avhengighetsadressering, prober eller ressurser basert på de bevisene.
• Start på nytt eller rull ut nye Pods når miljøbaserte ConfigMap- eller Secret-verdier endres.
• Verifiser Ready-tilstand og bekreft at omstartstallet slutter å øke.
• Bruk minikube status og minikube logs kun når klusterhelsen også er mistenkelig.
• Gjenopprett Minikube kun når klusteret selv er den sannsynlige årsaken og engangsbruk-tilstanden er beskyttet.

Den mest pålitelige måten å fikse CrashLoopBackOff på er å behandle det som et signal til å undersøke, ikke som diagnosen. I en sunn feilsøkingsprosess innsnevrer hver kommando årsaken: Pod-tilstanden forteller deg hva som starter på nytt, tidligere logger forteller deg hvorfor den siste kjøringen feilet, manifestet og Events viser hva Kubernetes ba containeren gjøre, og Minikube-diagnostikk forteller deg om det lokale klusteret selv er involvert. Når disse lagene er enige, er fiksen vanligvis mye mindre – og mye lettere å verifisere – enn å slette og gjenoppbygge alt.