Kubernetes Probleemoplossing

Kubernetes health probes vertellen de kubelet wanneer een container herstart moet worden, wanneer verkeer gestopt moet worden, en wanneer gewacht moet worden op een trage opstart. Verkeerd geconfigureerde probes zijn een van de meest voorkomende oorzaken van CrashLoopBackOff en doorrollende outages. Dit artikel doorloopt alle drie probetypen, de vier probemechanismen, timingparameters en de configuratiepatronen die workloads stabiel houden in productie.

CrashLoopBackOff is geen foutmelding. Het is een status die aangeeft dat een container in je pod steeds opstart, crasht en opnieuw gestart wordt met oplopende wachttijden. Dit artikel loopt door wat de status betekent, hoe je exit codes en logs leest, de meest voorkomende oorzaken, en hoe je elk probleem oplost.

ImagePullBackOff betekent dat de kubelet een container-image niet kon pullen en het opnieuw probeert met exponentieel oplopende wachttijden. De oorzaak staat altijd in de Events-sectie van kubectl describe pod: een typfout in de image-referentie, ontbrekende registry-credentials, Docker Hub-ratelimits, of een netwerkprobleem tussen de node en de registry. Dit artikel loopt door elke oorzaak, hoe je die vaststelt, en hoe je het oplost.

ContainerCreating betekent dat de kubelet bezig is met de voorbereidingen van je pod (volumes, netwerk, secrets), maar dat iets het proces blokkeert. Anders dan bij CrashLoopBackOff start de container nooit daadwerkelijk. De oplossing hangt af van welke stap vastloopt: een PVC die niet gebonden raakt, een ontbrekend Secret, een kapotte CNI-plugin, of een init container die niet afrondt. Dit artikel loopt elke oorzaak langs, hoe je die herkent in kubectl-events en hoe je het oplost.

OOMKilled betekent dat de Linux-kernel je container heeft beëindigd omdat hij zijn geheugenlimiet overschreed. De container stopt met exit code 137 (SIGKILL), de kubelet herstart hem, en zonder actie blijft hij in een lus crashen. Dit artikel behandelt hoe OOMKilled werkt op kernelniveau, hoe je het onderscheidt van node-level OOM en eviction, hoe je de oorzaak vaststelt, en hoe je geheugenlimieten goed instelt voor JVM-, Go-, Node.js- en Python-workloads.

Een pod in Pending-status is geaccepteerd door de API-server, maar geen enkele node kan hem draaien. De scheduler heeft elke node gecontroleerd, nul geschikte gevonden, en wacht tot de omstandigheden veranderen. De oplossing hangt volledig af van welk filter faalde: te weinig CPU of geheugen, een taint zonder bijpassende toleration, een node-affinity mismatch, een ongebonden PersistentVolumeClaim, of een ResourceQuota die pod-creatie blokkeert nog voordat scheduling begint.

Een node in NotReady-status is gestopt met het versturen van heartbeats naar het control plane. De kubelet is uitgevallen, onbereikbaar, of meldt actief dat een gezondheidsconditie faalt. Pods op de node worden binnen vijf minuten verwijderd. Dit artikel behandelt hoe je node-condities leest, de oorzaak vaststelt (kubelet-crash, container-runtime-fout, resourcedruk, netwerkpartitie, certificaatverlopen), en de node veilig herstelt of vervangt.

Distroless en minimale container-images bevatten geen shell, geen package manager en geen debugging-tools. kubectl exec faalt meteen. kubectl debug lost dit op door een ephemeral container met de juiste tools in een draaiende pod te injecteren, zonder herstart. Deze gids behandelt de drie kubectl debug-modi: ephemeral containers met --target, podkopieën met --copy-to en node-level debugging.

Als pods geen DNS-namen kunnen resolven, werkt er niets meer. Service-naar-service-verkeer faalt, externe API-aanroepen lopen vast, en de applicatielogs raken gevuld met connectiefouten. De oorzaak zit ergens in de DNS-keten: de /etc/resolv.conf van de pod, de kube-dns Service, CoreDNS zelf, of de upstream-resolver. Dit artikel loopt elke laag door met concrete diagnostische commando's en oplossingen.

Als Kubernetes een pod stopt, heeft je applicatie een beperkt tijdsvenster om verbindingen te draineren, lopende requests af te ronden en resources op te ruimen voordat het proces geforceerd wordt gekilld. Dit verkeerd configureren is de meest voorkomende oorzaak van 502-fouten tijdens deployments. Dit artikel behandelt de pod-terminatiecyclus, de race condition bij endpoint-verwijdering, preStop hooks, signaalafhandeling in Go, Node.js, Java en Python, en hoe je test of je shutdown daadwerkelijk graceful is.

kubectl delete namespace komt direct terug, maar de namespace blijft daarna eindeloos in Terminating staan. De oorzaak is bijna altijd een finalizer die geen enkele controller verwijdert: of op een resource binnen de namespace, of op de eigen kubernetes-finalizer van de namespace omdat een APIService niet beschikbaar is. Dit artikel legt het finalizer-mechanisme uit, laat zien hoe je de exacte resource vindt die deletion blokkeert, en hoe je de finalizer weghaalt zonder de cleanup over te slaan die hij beschermde.

De ingress-nginx-repository is op 24 maart 2026 gearchiveerd. Geen beveiligingspatches meer, geen bugfixes, geen releases. Als je cluster nog op ingress-nginx draait voor L7-verkeer, is migratie naar Gateway API geen optie meer maar een noodzaak. Deze handleiding loopt de volledige migratie door: een implementatie kiezen, manifests converteren met ingress2gateway, beide controllers parallel draaien, cert-manager aansluiten, en DNS knippen zonder downtime.

Evicted pods in kubectl get pods zijn het signaal van de kubelet dat een node geen geheugen, disk of PIDs meer had. De kubelet kiest pods om te beëindigen via een drie-stappen-ranking die QoS-class niet rechtstreeks gebruikt, en zet daarna status.phase=Failed en status.reason=Evicted. Dit artikel laat zien hoe je de eviction-reden leest, de achtergebleven pod-objecten opruimt, vaststelt welke pressure de oorzaak was, en herhaling voorkomt.

Een pod met topology spread constraints blijft Pending terwijl het cluster nog vrije capaciteit heeft. De scheduler meldt in hetzelfde FailedScheduling-event zowel niet-getolereerde taints als constraints die niet matchen. De oorzaak is de default nodeTaintsPolicy: Ignore, die niet-bereikbare getainte nodes meetelt in de spread-wiskunde en zo een deadlock veroorzaakt in multi-tenant clusters. De fix is nodeTaintsPolicy: Honor zetten op de constraint.