Forem: Shubh Dadhich

Begrijpen van Pod Pending States: Waarom je Pods niet plannen?

Shubh Dadhich — Wed, 05 Nov 2025 08:54:52 +0000

Wat je zal leren

Wat is de Pod Pending State?.
Begrijpen van de oorzaak voor Pod Pending States.
Debuggen UseCase.

1. Wat is Pod Pending State?

Een pod is de basis eenheid van deployment waar container draait. Normaal gaan pods snel van eerste creatie naar de running state. De levenscyclus van een Pod beschrijft de verschillende fases die een Pod doorloopt van creatie tot einde.

Maar soms blijft de Pod vast in de Pending state. Dit betekent dat het Pod API object bestaat, maar de workload draait niet. Dat betekent dat geen van de containers in de pod draait. Dit is omdat de scheduler de pod niet op een node heeft geplaatst.

2. Begrijpen van de oorzaak voor Pod Pending States

Hier zijn de verschillende oorzaken wanneer de scheduler geen pod kan plannen op een node:

1. Onvoldoende node resources (CPU / memory)

Dit is een vaak fout die komt door een hogere pod resource vraag (CPU/Memory) dan een andere beschikbare node in de cluster. Dat betekent als een pod 4 GB-geheugen vraagt, maar geen van de nodes heeft 4 GB om te geven. Dit maakt dat de pod niet gepland wordt.

2. Node Affinity constraints

Als je Affinity/Anti-Affinity regels hebt gezet die een pod dwingen op een specifieke node of verbieden op een bepaalde node. Als de regels te streng zijn of elkaar tegenwerken, dan kan de scheduler geen pod plannen op een node.

3. Taints op nodes zonder passende tolerations

Als nodes taints hebben, dan stopt dit elke pod om te plannen op die nodes, tenzij de pods tolerations hebben voor de taint. Als de pods de juiste tolerations missen om te draaien op een node, dan blijven ze pending.

4. Volume binding problemen

Als de pod een volume (PVC) nodig heeft en de juiste PV is niet gemaakt of niet verbonden met het PVC, dan blijft de pod pending. Dit gebeurt vaak als er geen storage class is of geen cloud volume provider (bijv. EBS-CSI driver, Azure Files CSI).

5. Admission / LimitRange / ResourceQuota fouten

Als je een Admission controller policy hebt gezet, dan wordt die toegepast op de pod als die gepland wordt. Maar als de Namespace Resource Quota limieten heeft (CPU, Memory) en de pods gaan boven die limiet, dan blijven ze pending. Ook als LimitRange is gezet voor per-pod en per-container, kan een verkeerde limiet maken dat pods pending blijven.

3. Debuggen Use Case

In dit use case lopen we door een keten van pod pending probleem dat gaat over Onvoldoende Node resources, Affinity constraints en ongebonden PVC-problemen.

StorageClass YAML

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: demo-ebs
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
parameters:
  type: gp2

PVC YAML

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: demo-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: demo-ebs

Pas de Storage en PVC YAML-bestanden toe, en daarna pas het Deployment YAML-bestand toe.

Deployment YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        resources:
          requests:
            cpu: "4000m"        
            memory: "8Gi"       
        volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: dev
                operator: In
                values:
                - "true"
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: demo-pvc

Na het toepassen van alle YAML-bestanden zie je dat de pod in de pending state is.

Ook het PVC is in de pending state.

Nu, om de reden van de pending state te zien, voer het volgende commando uit: kubectl describe

In de fout zie je dat de node affinity selector maakt dat de pod pending is, omdat er geen label op de node is die past bij de affinity selector, zoals hieronder getoond:

Om de labels van de node te zien, voer het volgende commando uit:

kubectl get nodes <node name> --show-labels

Voeg nu het label toe aan een van de nodes met het volgende commando:

kubectl label node <node-name> dev=true

Als de node een label heeft, pas opnieuw het YAML-bestand toe en controleer de status.
Als de pod nog steeds pending is, zoals hieronder:

Voer dan het describe commando uit om de echte oorzaak te vinden.

De fout laat zien dat er niet genoeg CPU en Memory is voor de pod. Dit kan gebeuren door hoge requests van de pod, zoals hieronder:

Verlaag de CPU en Memory requests en pas opnieuw het YAML-bestand toe.

Als de pod nog steeds pending is, zoals hieronder:

Als je de oorzaak niet hebt gezien tijdens het uitvoeren van het describe commando, dan kan je ook het get events commando uitvoeren zoals hieronder:

 kubectl get events

In de fout hierboven zie je dat er geen provisioneer, is om te helpen met het maken van het volume voor de pod. Voor de provisioneer moet je een add-on toevoegen aan jouw cluster (bij EKS).

In de kube-system namespace kan je de EBS CSI-driver pods zien.

Als je de EBS CSI-driver hebt toegevoegd, dan komen de pods omhoog en draaien ze. Dit is omdat de EBS CSI-driver automatisch het volume maakt voor jouw pods.

PVC Status

Conclusie

Wanneer pods in de pending state blijven, is er een probleem met scheduling. Door de echte oorzaak te begrijpen, of het nu gaat om onvoldoende resources, Affinity constraints, of provisioning van de storage, kan je het probleem precies oplossen in plaats van alleen te raden. Als je een gestructureerde checklist hebt om de root cause te vinden, kan je makkelijk een sterker en efficiënter Kubernetes omgeving bouwen.

Over mij

Ik ben Shubh Dadhich, een Kubernetes expert met interesse in DevOps, Cloud en Automatisering. Ik werk graag aan het maken van moeilijke problemen tot makkelijke, schaalbare oplossingen, en ik deel informatie via blogs en mentorschap.Ik ben open voor consultatie, training en mentorschap in Kubernetes, DevOps en Cloud. Of je net begint of je vaardigheden wilt verbeteren.
🔗 Verbinden met mij op LinkedIn: Shubh Dadhich

Troubleshooten van Kubernetes ContainerCreateError en Init Container Fouten

Shubh Dadhich — Sun, 28 Sep 2025 09:24:53 +0000

Kubernetes heeft veel complexiteit achter een simpel idee, dat bekend is als een pod, en fouten oplossen die horen bij een pod is één van de moeilijke taken. We gaan twee fouten bespreken: ContainerCreateError en Init Container Fouten.

Wat je gaat leren

Diepe kijk in ContainerCreateError en Init Container Fouten.
Begrijpen van de oorzaken.
Debugging gebruik case.

1. Diepe kijk in ContainerCreateError en Init Container Fouten.

Tijdens de levenscyclus van een pod doet de kubelet bepaalde acties op de target node:

Maak Pod Sandbox.
Trek de images voor de container.
Maak de container, init container (als er is, dan app container).
Start de container en draai de probes.

Ook al kunnen fouten gebeuren bij elke stap, ContainerCreateError en Init Container Fouten komen meestal bij de derde stap.

ContainerCreateError: Deze fout laat zien dat de kubelet niet kan maken een container voor een pod op de target node. Deze fout komt in de eerste fase, voor de applicatie start.

Init Container Fout: De init container draait voor de hoofdapplicatie container. Het is goed voor taken zoals draaien van afhankelijkheden, halen van config bestanden, maken van een database schema, of andere taken die eerst nodig zijn voor de hoofdapplicatie om te starten.
Als de init container faalt, zal de pod een status Init:0/1 laten zien, wat zegt dat de init container uitvoering is mislukt; de hoofdapp container zal niet starten tot de fout opgelost is.

2. Begrijpen van de oorzaken.

ContainerCreateError

1. Entrypoint/commando problemen: Verkeerde entrypoints en commando’s binnen het imago maken fouten. Bijv.: Binary niet gevonden (/app/start.sh: bestand of map bestaat niet).

2. Bestandssysteem/mounting: Verkeerde HostPath, mounten van niet bestaande configmap of secret, mount pad al in gebruik. Dit stopt dat de container kan worden gemaakt.

3. Security context beperkingen: Verkeerde security context instellen, zoals: Missende Linux mogelijkheden, runAsNonRoot terwijl image user is root (of andersom).

4. Node problemen: De node kan niet genoeg resources hebben (CPU, Geheugen) om een nieuwe container te draaien. Dit kan ook de OOMKilled fout geven tijdens het maken van de container.

Init Container Fouten

1. Initialisatie taak fout: Het script of commando dat is gegeven aan de init container faalde om te draaien of stopte met code nul status.

2. Afhankelijkheid is niet klaar: Als de init container is gemaakt om te wachten op een afhankelijkheid (bijv. database) die nog niet beschikbaar is, of de database service zelf maakt het pending, zoals een verbinding timeout of weigering. Dit maakt dat de init container steeds opnieuw start in een loop.

3. Verkeerde configuratie: Een verkeerde config file, environment variabele, of een verkeerd commando argument maakt dat de init container faalt.

3. Debuggen gebruik case

Stel dat je een applicatie hebt uitgerold en het gebruikt:

Init container: die een shell script draait om te wachten op een database service.
Hoofd container: die de hoofdapplicatie image draait.

Wanneer je uitrolt, zie je eerst de init container init:0/1, gevolgd door de ContainerCreateError voor de hoofdapplicatie.

DockerFile

# Simple base image
FROM alpine:latest

USER fakeuser

CMD ["sleep", "3600"]

YAML File

apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  initContainers:
  - name: wait-for-db
    image: busybox:1.36
    command: ['sh', '-c', 'until nc -z db-service 5432; do echo "waiting for db"; sleep 2; done']

  containers:
  - name: myapp
    image: aqualyte/alpine-test:latest
    ports:
    - containerPort: 80

Na het toepassen van het YAML-bestand blijft de init container in de init:0/1 status, dat is omdat er geen draaiende db-service is.

Nu gaan we de db-service maken.

kubectl run db-pod \
  --image=postgres:15 \
  --port=5432 \
  --env="POSTGRES_USER=admin" \
  --env="POSTGRES_PASSWORD=admin123" \
  --env="POSTGRES_DB=mydb"

kubectl expose pod db-pod \
  --name=db-service \
  --port=5432 \
  --target-port=5432

Na het maken van de db-service zal de hoofdapplicatie container starten, maar zoals je kan zien, het blijft vast in CreateContainerError.

Wanneer je kubectl describe doet, kun je in de events de fout boodschap zien zoals hieronder:

In de fout staat dat geen users gevonden zijn, wat betekent dat het probeert te draaien als een verkeerde user die niet bestaat. Of in de security context of in het imago zelf is de verkeerde user genoemd.

In dit gebruik case is er een verkeerde user in het imago. Dus laten we het imago corrigeren.

Dockerfile

# Simple base image
FROM alpine:latest

CMD ["sleep", "3600"]

In de Dockerfile hierboven kun je of de user weghalen of je kunt een geldige user toevoegen.

Na het maken van veranderingen in de Dockerfile, push het imago naar de repository en pas het YAML-bestand opnieuw toe.

Conclusie

Omgaan met CreateContainerError en init container fouten met de juiste aanpak wordt eenvoudig om op te lossen. Door te begrijpen waar de fout komt, de Events en logs te kijken, en gestructureerde debuggen toe te passen, ga je snel van brand blussen naar zeker problemen oplossen. Bouw sterke init containers, en controleer specs zodat het uren van downtime en frustratie zal sparen. Kort gezegd, deze fouten zijn geen blokkades, maar kansen om de betrouwbaarheid en sterkte van jouw Kubernetes workloads te verbeteren.

Over mij

🔗 Verbinden met mij op LinkedIn: Shubh Dadhich

Oplossen van ImagePullBackOff en ErrImagePull: Image gerelateerde problemen

Shubh Dadhich — Sat, 20 Sep 2025 09:10:02 +0000

Kubernetes is veel gebruikt als een container orkestratie tool voor het inzetten en beheren van microservice applicaties. Maar zelfs de meest sterke systemen krijgen soms fouten. De meest voorkomende en vervelende fout die Kubernetes gebruikers krijgen is ImagePullBackOff en ErrImagePull fouten. Deze fouten laten duidelijk zien dat je cluster moeite heeft met het halen van de container images uit de bron registry.

In deze blog gaan we diep kijken naar deze image fouten, we zien hun aard, begrijpen hun oorzaak, en hoe je ze kan vinden en oplossen, met een debugging simulatie om te helpen bij hun oplossing.

Wat je zult leren

Een Diepe Duik in ImagePullBackOff en ErrImagePull.
Hoe ImagePullBackOff en ErrImagePull te detecteren.
De oorzaken ervan begrijpen.
Debuggen.

1. Diepe kijk in ImagePullBackOff en ErrImagePull.

ImagePullBackOff en ErrImagePull laten zien dat de cluster niet kan trekken container images uit de registry. Ze lijken dicht bij elkaar, maar ze laten verschillende uitkomsten van de fout zien:

ErrImagePull: Deze fout komt direct wanneer Kubernetes niet kan trekken de container image tijdens de eerste poging of een volgende poging in korte tijd. Er kunnen veel oorzaken zijn die deze fout maken, zoals een typefout in de image naam of tag, een netwerk storing, of een probleem met registry login.

ImagePullBackOff: Deze status komt na de ErrImagePull fout. Wanneer Kubernetes steeds probeert en niet kan trekken de image uit de registry, gaat het in de BackOff status. Dit betekent dat in plaats van steeds proberen te trekken de image, het maakt een wachttijd die steeds langer wordt na elke poging. Dit geeft jou tijd om de fout op te lossen.

2. Hoe ImagePullBackOff en ErrImagePull te detecteren

Het vinden van de ImagePullBackOff en ErrImagePull is heel eenvoudig met basis Kubernetes commando’s; je kan vinden:

1. Kubectl get pod: Met dit commando kan je duidelijk zien de status van de pod, die laat jou de fout zien.

2. Kubectl describe pod: Met het describe commando kan je makkelijk krijgen de details over de fout onder het events deel, zoals hieronder getoond.

3. Begrijpen van de oorzaken

De oorzaken voor ImagePullBackOff en ErrImagePull zijn verdeeld in 3 hoofddelen:

1. Verkeerde Image Namen/Tags

Dit is een van de meest gewone en simpele problemen om op te lossen. Er kan een verkeerde image naam of image tag zijn die stopt de cluster om de image te trekken uit de registry. En in sommige gevallen kan het imago niet bestaan of verwijderd zijn.

2. Registry Authenticatie Problemen

In de meeste gevallen zijn container images die horen bij jouw applicatie of een interne service opgeslagen in de private registry. Dus om de image te trekken heb je de juiste login gegevens nodig voor authenticatie. Dit kan gedaan worden met de ImagePullSecrets parameter.

In veel situaties kunnen er missende secrets zijn die moeten worden gegeven aan de imagePullSecrets parameter. Of je kan verkeerde login gegevens hebben in ImagePullSecrets, die niet de juiste rechten hebben om het image te trekken uit de registry. Of misschien verwijst ImagePullSecrets naar de verkeerde secrets, die niet bestaan in jouw cluster.

3. Netwerk Verbinding Problemen

Zelfs als je de juiste image naam en logingegevens hebt om de image te trekken. Soms maken problemen met netwerk verbinding ook ImagePullBackOff en ErrImagePull. Deze problemen zijn als volgt:

Firewall: Als je een firewall hebt, dan moet je kijken of het blokkeert de uitgaande verbindingen naar het image registry IP adres of poort.
DNS resolutie: Als de host naam resolutie (bijv. docker.io, gcr.io) niet lukt voor de image registry, dan kan de verbinding niet gemaakt worden met de image registry.
Register uitvaltijd/Onbereikbaarheid: Als je een zelf-gehoste registry (bijv. Nexus repository) hebt op EC2 instances, dan kan je downtime zien, of soms is het registry domain zelf niet bereikbaar, wat heel zeldzaam is.

4. Debuggen

In deze sectie gaan we zien hoe te vinden en oplossen de ImagePullBackOff en ErrImagePull.

Voor dit doel gebruiken we een simpel Docker image. Je moet deze image pushen naar een private repository.

Dockerfile

FROM alpine:latest
LABEL maintainer="team@mycompany.com"
CMD ["sleep", "3600"]

YAML

Zodra je de image pusht naar de repository, kan je het YAML bestand hieronder draaien. Zorg dat je jouw eigen image naam geeft.

apiVersion: v1
kind: Pod
metadata:
  name: webserver
spec:
  containers:
  - name: alpine
    image: aqulyte/errimagepull:v1

Na het toepassen van het YAML, kijk de status van de pod. Als het een fout laat zien, dan is het tijd om te troubleshooten.

Draai het describe commando om de details van de fout te krijgen.

Zoals getoond in de fout hierboven, kan het niet trekken van het image uit de registry. Omdat we proberen te trekken een image uit een private repository, moeten we login gegevens geven via de ImagePullSecrets parameter.

Draai het commando hieronder om de secrets te maken.

kubectl create secret docker-registry myregistry-secret \
  --docker-server=docker.io \
  --docker-username=YOUR_DOCKER_USERNAME \
  --docker-password=YOUR_DOCKER_PASSWORD \
  --docker-email=YOUR_DOCKER_EMAIL

Zodra de secrets zijn gemaakt, bewerk het YAML bestand zoals hieronder:

apiVersion: v1
kind: Pod
metadata:
  name: webserver
spec:
  containers:
  - name: alpine
    image: aqulyte/errimagepull:v1
  imagePullSecrets:
  - name: myregistry-secret

Na het toepassen van het YAML, als je de ImagePullBackOff fout niet krijgt, dan is het goed.

MAAR…

Als de fout blijft.

Dan moet je meer troubleshooten. Voor mij was het een verkeerde project naam en image tag.

Na correctie, hieronder is het juiste YAML, en zet opnieuw in het YAML.

apiVersion: v1
kind: Pod
metadata:
  name: webserver
spec:
  containers:
  - name: alpine
    image: aqualyte/errimagepull:latest
  imagePullSecrets:
  - name: myregistry-secret

Nu is de fout opgelost.

Jouw Pod zal draaien zonder problemen.

Conclusie

ImagePullBackOff en ErrImagePull zijn gewone fouten en zijn makkelijk op te lossen door hun oorzaken te begrijpen, die kunnen gaan van typefouten en login problemen tot netwerk of registry problemen. Door deze fouten helemaal te vermijden, helpen goede praktijken zoals het gebruiken van juiste duidelijke tags, het instellen van ImagePullSecrets, en het volgen van netwerk en registry verbinding om meer betrouwbare en vloeiende deployments te krijgen.

Over mij

🔗 Verbinden met mij op LinkedIn: Shubh Dadhich

CrashLoopBackOff: Warrom Je Pods Blijven Crashen?

Shubh Dadhich — Sat, 06 Sep 2025 08:20:16 +0000

Heb je ooit naar de pods van je Kubernetes-cluster gekeken en dat vervelende bericht CrashLoopBackOff naast je pods gezien? Nou, het is een veelvoorkomende fout die vaak gebeurt tijdens het werken met een containerapplicatie, en het kan eng lijken, maar het is de manier van Kubernetes om te zeggen dat er iets mis is met je applicatie of de configuratie.

In deze blog gaan we de fouten van CrashLoopBackOff bekijken, de veelvoorkomende oorzaken onderzoeken, en je de kennis geven om deze crashes te begrijpen en op te lossen.

Wat je zult leren

Een Diepe Duik in CrashLoopBackOff.
Hoe CrashLoopBackOff te detecteren.
De oorzaken ervan begrijpen.
Debuggen

Een Diepe Duik in CrashLoopBackOff

CrashLoopBackOff betekent dat je pod is gestart, gecrasht, opnieuw gestart, en weer gecrasht. En dit blijft in een continue lus. Kubernetes wil niet dat de mislukte container continu opnieuw wordt gestart, omdat dat onnodige resources verbruikt. Om dit te voorkomen, implementeert Kubernetes een “BackOff”-vertraging tussen elke herstart poging.

Wat is BackOff

BackOff is een algoritme in het Kubelet-onderdeel dat de herstart lus voorkomt. Wanneer een container in een pod stopt met een fout en de restartPolicy is ingesteld op always (standaard) of OnFailure, probeert de kubelet de pod opnieuw te starten. Maar als de container steeds direct crasht, gebruikt de kubelet een BackOff-algoritme, dat een toenemende vertraging toevoegt (10s, 20s, 30s...) na elke herstart poging. Dit geeft je een kort moment om het probleem te vinden en op te lossen. Deze vertraging gaat door tot 300 seconden (5 minuten). Als het probleem niet is opgelost, start de kubelet de pod elke 5 minuten opnieuw.

2. Hoe te detecteren CrashLoopBackOff

Er zijn gewone en eenvoudige methodes om de CrashLoopBackOff-fout te detecteren. Die methodes zijn als volgt:

kubectl get pods: Dit is je standaardcommando om de status van de pod te controleren

kubectl describe pod : Dit commando geeft alle details van de pods, inclusief hun events. In de event-sectie kun je de fout van CrashLoopBackOff zien.

kubectl get events: Het laat je alle events van de pods zien die draaien. Je kunt dit commando ook gebruiken om de hoofdoorzaak van de fout te vinden.

3. De oorzaken ervan begrijpen

De oorzaken van CrashLoopBackOff zijn verschillend. Maar ze vallen onder enkele belangrijke categorieën zoals hieronder.

a. Problemen op applicatieniveau.

Als je applicatiecode of configuratie fout is, kan het ervoor zorgen dat de container kort na het starten crasht. Enkele veelvoorkomende applicatieproblemen zijn als volgt:

Runtime-fouten, zoals uitzonderingen, die niet goed worden afgehandeld in je applicatiecode, laten de container crashen.
Ontbrekende afhankelijkheden, zoals startbestanden, omgevingsvariabelen of bibliotheken die niet aanwezig zijn in de container.
Fouten zoals verkeerde database verbinding strings, API-sleutels of andere applicatiespecifieke configuraties die voorkomen dat de container start.
Poortconflict, waar de applicatie probeert te verbinden met een poort die al in gebruik is door een andere container in de pod. Het is een minder vaak voorkomend probleem, maar het is wel een van de redenen voor CrashLoopBackOff.

b. Verkeerde configuratie in manifest.

Soms zorgt een fout in de manifest bestanden voor crashes van de pod zoals:

Verkeerde command, args, of EntryPoint die zijn opgegeven in de Dockerfile of in het Kubernetes deployment manifest zorgen voor een fout bij het starten van de container.
Verkeerde volume mount configuraties of mount paths in de container zijn fout, en de applicatie kan de nodige bestanden niet vinden.
Typefouten bij environment variables, verkeerde waarden, of ontbrekende verplichte variabelen zorgen ervoor dat de container niet kan starten.

c. Fouten met probes

Probes worden gebruikt om de gezondheid en gereedheid van de container in de pod te bepalen. Als de probes falen, kan dat leiden tot een ongezonde herstart van de container.

Liveness Probe: Deze probe wordt gebruikt om te bepalen of de container leeft en goed draait. Voortdurend falen kan leiden tot een herstart van de container, wat CrashLoopBackOff kan veroorzaken.
Enkele veelvoorkomende redenen zijn:
- Incorrect eindpunt: Als de probe is geconfigureerd om een eindpunt te controleren dat niet bestaat of geen antwoord geeft. Dat zal leiden tot meerdere herstarts en een crash van de container.
- Slow Response: Als de applicatie langzaam reageert op de probe, die langer duurt dan de timeout Seconds van de probe. Dat veroorzaakt meerdere herstarts van de container.

4. Debuggen

In deze sectie, we zullen leren hoe te identificeren problemen oplossen de CrashLoopBackOff-fout. Of het nu gaat om het applicatie niveau, een verkeerde configuratie in het manifest, of probe fouten.

Voor dit doel gebruiken wij een aangepaste image en applicatie logica:

1. DockerFile

FROM busybox:latest

ENV APP_MODE=staging

RUN mkdir -p /home/app
WORKDIR /home/app

COPY startup.sh .
RUN chmod +x startup.sh

ENTRYPOINT ["./startup.sh"]

2. Application Code(codelogica kan variëren)

#!/bin/sh
set -e
# Step 1: Check if config file exists
[ -f /config/app.conf ] || (echo "[Stage 1] Config file missing. Exiting..." && false)


# Step 2: Check for valid APP_MODE
[ "$APP_MODE" = "production" ] || (echo "[Stage 2] Invalid APP_MODE=$APP_MODE. Exiting..." && false)


# Step 3: App started
echo "[Stage 3] App started successfully."
while true; do
  echo "App running..."
  sleep 10
done

In de bovenstaande Dockerfile en shell-script is er een verschil tussen de Dockerfile env variabele en de code. In het script, bij stap 1, is er een controle of het bestand app.conf bestaat in de container. En bij stap 2, is er een controle voor een geldige APP_MODE als productie.

3. K8s Manifest

apiVersion: apps/v1
kind: Deployment
metadata:
  name: crashloop-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: crashloop-demo
  template:
    metadata:
      labels:
        app: crashloop-demo
    spec:
      containers:
      - name: demo
        image: aqualyte/crashloop_busybox
        env:
        - name: APP_MODE
          value: "staging"
        livenessProbe:
          exec:
            command:
            - cat
            - /config/app.conf
          initialDelaySeconds: 0
          periodSeconds: 1
          timeoutSeconds: 1
          failureThreshold: 2

In het bovenstaande manifest gebruiken wij de aangepaste image en geven env als staging. En een liveness probe die het cat commando uitvoert.
Na het toepassen van het manifest-bestand zal het een CrashLoopBackOff fout geven.

Om de oorzaak van de fout te vinden, zoals eerder genoemd, gebruik de kubectl log of kubectl describe commando.

Zoals de logs laten zien, zoekt het naar app.conf in de container, dat niet aanwezig is, en het shell-script heeft ook een controle voor het config bestand. Het is een van de verkeerde configuraties in het manifest waar je vergeet het config bestand te geven. Om dit op te lossen, moeten wij het config bestand koppelen aan de pod.

Beste praktijk is om de config map als een volume te koppelen aan de pod.

ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  app.conf: |
    env=production

Na het toepassen van de config map, voeg het volume en de volume mount toe in het k8s manifest.

Volume and Volume mounts

volumes:
- name: config-volume
  configMap:
   name: app-config
  volumeMounts:
  - name: config-volume
    mountPath: /config

Eenmaal toegevoegd, verwijder de deployment en pas opnieuw het manifest toe. Na opnieuw toepassen, als het probleem blijft, zoals hieronder getoond:

Gebruik dan het kubectl describe commando, waar je de exit code van de container kan lezen.

Exit code: 1 betekent dat de container is gestopt door een applicatiefout of door een verkeerde referentie in de image specificatie.

Controleer de logs van de pod om de fout te debuggen.

In de logs, het laat de ongeldige APP_MODE zien. Dit is omdat in de code logica er een check is voor APP_MODE als productie, maar wij geven de verkeerde waarde. Dit zijn de scenario’s wanneer er een conflict is tussen code logica en een misconfiguratie in het manifest.

Hier wij hebben twee manieren om te debuggen:

Maak veranderingen in de code logica en Dockerfile, en zet opnieuw in.
Of geef de vereiste environment waarde om het probleem op te lossen.

Voor nu, laten wij met de tweede optie gaan en de environment waarde in het manifest veranderen.

K8s manifest

APP_MODE = Production

apiVersion: apps/v1
kind: Deployment
metadata:
  name: crashloop-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: crashloop-demo
  template:
    metadata:
      labels:
        app: crashloop-demo
    spec:
      containers:
      - name: demo
        image: aqualyte/crashloop_busybox
        env:
        - name: APP_MODE
          value: "production"
        volumeMounts:
        - name: config-volume
          mountPath: /config
        livenessProbe:
          exec:
            command:
            - cat
            - /config/app.conf
          initialDelaySeconds: 0
          periodSeconds: 1
          timeoutSeconds: 1
          failureThreshold: 2
      volumes:
          - name: config-volume
            configMap:
              name: app-config

Zodra veranderingen klaar zijn in het manifest, verwijder de vorige deployment en pas opnieuw toe.

Deployment zal actief en werkend zijn.

Conclusie

CrashLoopBackOff is meer dan alleen een fout; het is een signaal dat iets niet goed is met jouw applicatie of met de configuratie. Door de logs, exit code, probe instellingen en gebruik van resources te bekijken, jij kan snel de oorzaak vinden en oplossen. Elke keer jij zal de mogelijkheden kleiner maken tot jij de echte oorzaak hebt gevonden.

Over mij

Ik ben Shubh Dadhich, een Kubernetes expert met interesse in DevOps, Cloud en Automatisering. Ik werk graag aan het maken van moeilijke problemen tot makkelijke, schaalbare oplossingen, en ik deel informatie via blogs en mentorschap.

Ik ben open voor consultatie, training en mentorschap in Kubernetes, DevOps en Cloud. Of je net begint of je vaardigheden wilt verbeteren.

🔗 Verbinden met mij op LinkedIn: Shubh Dadhich