Aucun pod ne se crée

Vous avez appliqué votre manifest, kubectl get deploy montre bien le Deployment… mais READY reste à 0/1 et aucun pod n’apparaît (ou il reste bloqué en Pending). Sur Kontainers, quatre causes couvrent la quasi-totalité des cas.

Où lire l’erreur

Un pod rejeté à l’admission n’apparaît jamais dans kubectl get pods : c’est le ReplicaSet (créé par le Deployment) qui porte le message :

kubectl describe deploy <deployment> -n <namespace> | tail -5
kubectl get events -n <namespace> --sort-by=.lastTimestamp | tail -10

Cause 1 : quota atteint

Le message contient exceeded quota: blackswift-standard :

Error creating: pods "web-xxx" is forbidden: exceeded quota:
blackswift-standard, requested: requests.memory=4Gi,
used: requests.memory=18Gi, limited: requests.memory=20Gi

Le message dit tout : ce qui est demandé, ce qui est déjà utilisé, le plafond. Vérifiez votre consommation globale :

kubectl describe resourcequota blackswift-standard -n <namespace>

Solutions : réduire les requests du nouveau workload, scaler à zéro ce qui ne sert pas, ou demander une augmentation. Les plafonds par défaut sont listés dans Quotas et limites.

Cause 2 : rejet Pod Security

Le message mentionne violates PodSecurity "baseline:latest" :

Error creating: pods "web-xxx" is forbidden: violates PodSecurity
"baseline:latest": privileged (container "web" must not set
securityContext.privileged=true)

Votre pod demande une capacité interdite : privileged, montage hostPath, hostNetwork, hostPID… C’est fréquent avec des charts Helm prévus pour un cluster dédié. Retirez l’option en cause — si elle est indispensable à votre cas d’usage, parlez-en au support.

Cause 3 : toleration control-plane

admission webhook "validate.kyverno.svc-fail" denied the request:
restrict-controlplane-scheduling: 'validation error: Pods may not
use tolerations which schedule on control plane nodes.'

Retirez la toleration node-role.kubernetes.io/control-plane (ou master) du manifest — souvent héritée d’un chart ou d’un copier-coller.

Cause 4 : pod `Pending`

Le pod existe mais ne démarre pas. kubectl describe pod vous dira pourquoi ; les deux cas courants :

pod has unbound immediate PersistentVolumeClaims : le PVC référencé n’existe pas encore ou vient d’être créé — transitoire si le PVC se Bound (vérifier) ;
volume RWO déjà monté ailleurs : deux pods se disputent le même volume ReadWriteOnce — utilisez strategy: Recreate sur le Deployment concerné.

Cas particulier : DaemonSets et ReplicationControllers

Ces deux types d’objets ne sont pas disponibles sur Kontainers (pourquoi). Un chart qui en dépend doit être adapté — le besoin se couvre généralement avec un Deployment.

Pas votre cas ? Retour à la checklist de diagnostic, ou contactez le support avec la sortie des commandes ci-dessus.