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
Top comments (0)