Kubernetes scheduling
| Fiche express | |
|---|---|
| Composant | kube-scheduler |
| Mécanismes | nodeSelector · nodeName · affinité · taints/tolerations |
| Voir aussi | Kubernetes taint · Kubernetes daemonSets |
Le scheduling est le processus par lequel Kubernetes décide sur quel nœud placer un Pod nouvellement créé. Par défaut, le kube-scheduler choisit un nœud parmi ceux disponibles en tenant compte des ressources demandées (CPU, mémoire) et de contraintes de placement éventuelles. Cette page couvre les règles d'affectation les plus directes ; pour l'exclusion active de nœuds via taints et tolerations, voir Kubernetes taint.
nodeSelector : contrainte simple par label
Le moyen le plus direct de contraindre le placement d'un Pod est de sélectionner des nœuds par label.
kubectl get nodes
kubectl label nodes <nom-du-noeud> special=true
apiVersion: v1
kind: Pod
metadata:
name: nodeselector-pod
spec:
nodeSelector:
special: "true"
containers:
- name: app
image: nginx
kubectl create -f nodeselector-pod.yml
kubectl get pod nodeselector-pod -o wide
Le Pod n'est alors éligible qu'aux nœuds portant le label demandé. C'est la forme la plus simple d'affinité — pour des règles plus riches (préférence plutôt qu'obligation, affinité entre Pods), Kubernetes propose les mécanismes de node affinity et pod affinity/anti-affinity (au-delà du périmètre de cette fiche — à vérifier selon les besoins du cluster concerné).
nodeName : forcer un nœud précis
Il est possible de contourner totalement le scheduler en fixant directement le nœud cible dans la spécification du Pod :
apiVersion: v1
kind: Pod
metadata:
name: nodename-pod
spec:
nodeName: <nom-du-noeud>
containers:
- name: app
image: nginx
kubectl create -f nodename-pod.yml
kubectl get pod nodename-pod -o wide
À réserver à des cas très spécifiques (debug, contrainte matérielle stricte) : cette approche court-circuite entièrement la logique du scheduler et ne tient compte d'aucune autre contrainte (ressources disponibles, taints...).
Gestion des ressources
Le scheduler tient compte des requests et limits déclarées sur les conteneurs pour décider si un nœud a la capacité d'accueillir un Pod. Un Pod dont les requests dépassent les ressources disponibles sur tous les nœuds reste en Pending.
Exclusion active : taints et tolerations
Alors que nodeSelector et l'affinité attirent des Pods vers des nœuds, les taints fonctionnent dans l'autre sens : ils repoussent les Pods d'un nœud sauf toleration explicite. Voir Kubernetes taint pour le détail (effects NoSchedule/PreferNoSchedule/NoExecute, syntaxe, cas d'usage).