Wat je zal leren
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
Top comments (0)