Kubernetes 004 – Scheduling : de l’ETCD au container

TL;DR

Le scheduling Kubernetes consiste a assigner un pod a un noeud compatible. Le scheduler observe les pods non planifies, filtre les noeuds possibles, choisit le meilleur candidat, puis le kubelet du noeud lance les conteneurs.

La video de reference

Video: https://www.youtube.com/watch?v=M7o21hmxI28

Elle relie directement l’architecture vue precedemment au cycle de vie concret d’un pod.

De l’objet API au pod execute

Quand un pod est cree, l’objet est stocke dans l’API Kubernetes. Tant qu’il n’a pas de noeud assigne, il est considere comme non schedule. Le scheduler le detecte, evalue les noeuds disponibles puis inscrit son choix dans l’objet pod.

Ensuite, le kubelet du noeud choisi voit qu’un pod lui est destine. Il recupere la specification, demande au runtime de tirer l’image si besoin, cree les conteneurs et remonte les statuts.

Ce que le scheduler regarde

Le scheduler peut tenir compte des ressources demandees, des contraintes de noeud, des taints et tolerations, des affinites, des ports deja utilises ou encore de la disponibilite generale du cluster. Pour debuter, il faut surtout retenir qu’un pod peut rester Pending si aucun noeud ne correspond.

Commandes utiles

kubectl get pods -o wide
kubectl describe pod <nom-du-pod>
kubectl get events --sort-by=.lastTimestamp
kubectl describe node <nom-du-noeud>

Ces commandes permettent de voir le noeud choisi, les evenements de scheduling et les causes d’un blocage.

Liens utiles

• Video: https://www.youtube.com/watch?v=M7o21hmxI28
• Kubernetes Scheduler: https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/
• Assigner des pods aux noeuds: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/
• Composants Kubernetes: https://kubernetes.io/docs/concepts/overview/components/

FAQ

Pourquoi un pod reste-t-il en Pending ?

Souvent parce qu’aucun noeud ne satisfait les contraintes: ressources insuffisantes, selector incorrect, taint non tolere ou probleme de volumes.

Le scheduler lance-t-il l’image Docker ?

Non. Il assigne le pod a un noeud. Le kubelet et le runtime creent ensuite les conteneurs.

etcd decide-t-il du noeud ?

Non. etcd stocke l’etat. La decision de placement vient du scheduler.

Les grandes phases du scheduling

Le scheduling peut etre vu en plusieurs phases. D’abord, Kubernetes repere les pods qui n’ont pas encore de noeud. Ensuite, le scheduler filtre les noeuds impossibles: pas assez de CPU ou memoire, contraintes de labels non respectees, taints non toleres, ports incompatibles, volumes non disponibles. Puis il classe les noeuds restants et choisit le plus adapte.

Cette decision est ensuite ecrite dans l’objet pod. Le kubelet du noeud choisi voit alors qu’un nouveau pod lui est assigne et demarre le travail local: recuperation d’image, creation des volumes, lancement des conteneurs, remontee du statut.

Pourquoi un pod peut rester en attente

Le statut Pending n’est pas toujours un probleme de scheduler, mais il doit faire poser les bonnes questions:

• le cluster a-t-il assez de ressources ?
• le pod demande-t-il un nodeSelector trop restrictif ?
• un taint empeche-t-il le placement ?
• une contrainte d’affinite bloque-t-elle le pod ?
• un volume necessaire est-il disponible sur le noeud ?

Le detail apparait souvent dans les events:

kubectl describe pod <pod>
kubectl get events --sort-by=.lastTimestamp

Exemple de contrainte simple

Un pod peut demander un noeud portant un label:

spec:
  nodeSelector:
    disktype: ssd

Si aucun noeud ne porte ce label, le pod ne peut pas etre schedule. On peut verifier les labels avec:

kubectl get nodes --show-labels

Erreurs frequentes

• Chercher dans les logs applicatifs alors que le pod n’a jamais ete place.
• Oublier de regarder la colonne NODE avec kubectl get pods -o wide.
• Ajouter des requests trop hautes pour un petit cluster de lab.
• Confondre scheduling impossible et image impossible a tirer.

A retenir

Le scheduler ne lance pas les conteneurs. Il choisit un noeud. Le kubelet applique ensuite localement la specification. Cette separation des responsabilites est essentielle pour depanner proprement.

Requests, limits et scheduling

Le scheduler se base notamment sur les requests CPU et memoire pour savoir si un noeud peut accueillir un pod. Les limits, elles, servent plutot a encadrer la consommation maximale a l’execution. Cette difference est importante: un pod peut rester Pending si ses requests sont trop elevees pour le cluster, meme si l’application consommerait moins en pratique.

Exemple:

resources:
  requests:
    cpu: "500m"
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "512Mi"

Dans un petit lab, des requests trop ambitieuses suffisent a bloquer le placement. En production, ne pas definir de requests rend au contraire le placement moins previsible.

Taints, tolerations et nodeSelector

Le scheduling ne se limite pas aux ressources. Un noeud peut porter un taint pour repousser certains pods, et un pod peut declarer une toleration pour accepter ce noeud. Un nodeSelector ou une affinite peut aussi forcer le pod a viser certains noeuds.

Ces mecanismes sont puissants pour separer des workloads, reserver des noeuds ou orienter des pods vers du materiel specifique. Mais ils peuvent aussi expliquer des blocages difficiles a voir si l’on ne regarde pas les events.

Commandes utiles:

kubectl describe node <node>
kubectl get nodes --show-labels
kubectl describe pod <pod>

Lire un evenement de scheduling

Un event de scheduling donne souvent une phrase tres concrete: ressources insuffisantes, taint non tolere, node selector incompatible, volume non disponible. Il faut apprendre a lire cette phrase plutot que de s’arreter au status Pending.

Exemple de demarche:

• regarder si la colonne NODE est vide;
• lire les events du pod;
• verifier les ressources demandees;
• verifier les labels et taints des noeuds;
• simplifier temporairement les contraintes pour isoler la cause.

Cette methode permet de distinguer un vrai probleme de capacite d’une simple contrainte trop restrictive.

Notions et definitions

• Pod: plus petite unite deployable dans Kubernetes.
• Controleur: objet qui maintient un etat attendu, comme Deployment, ReplicaSet, DaemonSet ou StatefulSet.
• Reconciliation: boucle permanente qui compare l’etat reel et l’etat desire.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Un Deployment a trois replicas recree automatiquement un pod supprime afin de revenir a l’etat attendu declare dans sa specification.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Declarer le workload avec un manifest YAML ou une commande kubectl.
• Observer les pods crees et leurs labels.
• Lire les events pour comprendre scheduling, pulls d’images et redemarrages.
• Modifier le controleur plutot que les pods generes directement.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser le passage d’un conteneur isole a un workload controle par Kubernetes. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl get pods -o wide --show-labels
• kubectl describe pod <pod> pour lire scheduling, events et conditions
• kubectl rollout history deployment/<name> quand un Deployment est concerne

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• modifier un pod gere par un controleur au lieu de modifier le controleur lui-meme
• ignorer les events alors qu’ils expliquent souvent le probleme
• oublier que les labels sont le lien entre controleurs, pods et Services

Exercice conseille

Lancez un Deployment nginx a trois replicas, supprimez un pod manuellement, puis observez comment le controleur reconcilie l’etat attendu.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 005 – Le Pod : c’est quoi ?.

Conclusion

Le scheduling est l’un des meilleurs exemples de la logique Kubernetes: chaque composant a un role precis, et le systeme avance par observation et mise a jour de l’etat.