Scheduling avancé Kubernetes

Le scheduler Kubernetes place les Pods sur les nœuds disponibles selon des règles précises. Par défaut, il équilibre la charge automatiquement. Mais en production, vous devez souvent contrôler ce placement : isoler des workloads, garantir la haute disponibilité, ou exploiter du matériel spécifique (GPU, SSD).

CKA — Scheduling (15%)

Le domaine “Scheduling” représente 15% de l’examen CKA. Maîtrisez les concepts de cette page pour réussir les questions associées.

Vue d’ensemble des mécanismes

Mécanisme	Direction	Usage principal
nodeSelector	Pod → Node	Placement simple par labels
nodeAffinity	Pod → Node	Placement avancé avec expressions
podAffinity	Pod → Pod	Co-localisation de Pods
podAntiAffinity	Pod ↔ Pod	Séparation de Pods
taints/tolerations	Node → Pod	Exclusion de nœuds sauf exception
topologySpreadConstraints	Pod ↔ Topology	Répartition équilibrée

Glissez pour voir

# Voir les labels et taints d'un nœud
kubectl describe node <node-name> | grep -A10 Labels
kubectl describe node <node-name> | grep -A5 Taints

# Lister les nœuds avec leurs labels
kubectl get nodes --show-labels

---

nodeSelector — Placement simple

Le nodeSelector est le mécanisme le plus simple : il place le Pod uniquement sur des nœuds ayant tous les labels spécifiés.

Labelliser un nœud

# Ajouter un label
kubectl label node worker-1 disktype=ssd

# Vérifier
kubectl get nodes -l disktype=ssd

# Supprimer un label
kubectl label node worker-1 disktype-

Utiliser nodeSelector dans un Pod

apiVersion: v1
kind: Pod
metadata:
  name: ssd-pod
spec:
  nodeSelector:
    disktype: ssd
  containers:
  - name: app
    image: nginx:1.25

Limitation

nodeSelector est un AND logique : tous les labels doivent matcher. Pour des conditions OR ou des expressions complexes, utilisez nodeAffinity.

---

nodeAffinity — Placement avancé

nodeAffinity offre plus de flexibilité que nodeSelector avec des expressions logiques (In, NotIn, Exists, DoesNotExist, Gt, Lt).

Types d’affinité

Type	Comportement
requiredDuringSchedulingIgnoredDuringExecution	Obligatoire — le Pod ne démarre pas si aucun nœud ne matche
preferredDuringSchedulingIgnoredDuringExecution	Préféré — le scheduler essaie, mais place ailleurs si nécessaire

Glissez pour voir

Exemple : requiredDuringScheduling

apiVersion: v1
kind: Pod
metadata:
  name: affinity-required
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: topology.kubernetes.io/zone
            operator: In
            values:
            - eu-west-1a
            - eu-west-1b
  containers:
  - name: app
    image: nginx:1.25

Le Pod ne démarrera que sur un nœud dans la zone eu-west-1a ou eu-west-1b.

Exemple : preferredDuringScheduling

apiVersion: v1
kind: Pod
metadata:
  name: affinity-preferred
spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 80
        preference:
          matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd
      - weight: 20
        preference:
          matchExpressions:
          - key: disktype
            operator: In
            values:
            - hdd
  containers:
  - name: app
    image: nginx:1.25

Le scheduler préfère les nœuds SSD (poids 80) mais accepte les HDD (poids 20) si nécessaire.

Opérateurs disponibles

Opérateur	Description	Exemple
In	Valeur dans la liste	zone In [a, b]
NotIn	Valeur hors de la liste	env NotIn [prod]
Exists	La clé existe (valeur ignorée)	gpu Exists
DoesNotExist	La clé n’existe pas	spot DoesNotExist
Gt	Valeur supérieure (numérique)	cores Gt 4
Lt	Valeur inférieure (numérique)	memory Lt 32

Glissez pour voir

---

podAffinity et podAntiAffinity

Ces mécanismes définissent des règles de placement entre Pods, pas entre Pod et Node.

podAffinity — Co-localisation

Placer un Pod sur le même nœud (ou dans la même zone) qu’un autre Pod :

apiVersion: v1
kind: Pod
metadata:
  name: cache-client
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: redis
        topologyKey: kubernetes.io/hostname
  containers:
  - name: client
    image: busybox:1.36
    command: ['sh', '-c', 'sleep 3600']

Ce Pod sera placé sur le même nœud (topologyKey: kubernetes.io/hostname) qu’un Pod ayant le label app=redis.

podAntiAffinity — Séparation

Placer un Pod sur un nœud différent des autres réplicas (haute disponibilité) :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: web
            topologyKey: kubernetes.io/hostname
      containers:
      - name: nginx
        image: nginx:1.25

Chaque réplica sera placé sur un nœud différent. Si vous n’avez que 2 nœuds, le 3ᵉ Pod restera Pending.

topologyKey courants

• kubernetes.io/hostname — même nœud
• topology.kubernetes.io/zone — même zone cloud
• topology.kubernetes.io/region — même région

---

Taints et Tolerations

Les taints sont appliqués aux nœuds pour repousser les Pods. Les tolerations permettent aux Pods de tolérer ces taints.

Appliquer un taint

# Syntaxe : kubectl taint nodes <node> <key>=<value>:<effect>
kubectl taint nodes worker-1 dedicated=database:NoSchedule

# Vérifier
kubectl describe node worker-1 | grep Taints

# Supprimer un taint (ajout du tiret final)
kubectl taint nodes worker-1 dedicated=database:NoSchedule-

Effects disponibles

Effect	Comportement
NoSchedule	Nouveaux Pods sans toleration ne sont pas schedulés
PreferNoSchedule	Le scheduler évite ce nœud mais l’utilise si nécessaire
NoExecute	Pods existants sans toleration sont évincés

Glissez pour voir

Ajouter une toleration

apiVersion: v1
kind: Pod
metadata:
  name: db-pod
spec:
  tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "database"
    effect: "NoSchedule"
  containers:
  - name: postgres
    image: postgres:15

Toleration universelle

Pour tolérer tous les taints d’un nœud (utile pour DaemonSets) :

tolerations:
- operator: "Exists"

Cas d’usage courants

Taint	Usage
node-role.kubernetes.io/control-plane:NoSchedule	Protège le control plane
dedicated=gpu:NoSchedule	Réserve des nœuds GPU
maintenance=true:NoExecute	Évince les Pods avant maintenance

Glissez pour voir

---

topologySpreadConstraints — Répartition équilibrée

Ce mécanisme répartit les Pods de manière équilibrée sur une topologie (zones, nœuds).

Exemple : répartition sur les zones

apiVersion: apps/v1
kind: Deployment
metadata:
  name: balanced-app
spec:
  replicas: 6
  selector:
    matchLabels:
      app: balanced
  template:
    metadata:
      labels:
        app: balanced
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: balanced
      containers:
      - name: app
        image: nginx:1.25

Paramètre	Description
maxSkew	Différence maximale de Pods entre topologies (1 = équilibré)
topologyKey	Label définissant la topologie (zone, nœud, rack)
whenUnsatisfiable	DoNotSchedule (strict) ou ScheduleAnyway (best-effort)
labelSelector	Pods concernés par la contrainte

Glissez pour voir

Résultat avec 3 zones et 6 réplicas

Zone	Pods
eu-west-1a	2
eu-west-1b	2
eu-west-1c	2

Glissez pour voir

---

Priorité et Preemption

Kubernetes peut évincer des Pods de basse priorité pour faire de la place à des Pods de haute priorité.

Créer une PriorityClass

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
preemptionPolicy: PreemptLowerPriority
description: "Pour les workloads critiques"

Utiliser une PriorityClass

apiVersion: v1
kind: Pod
metadata:
  name: critical-pod
spec:
  priorityClassName: high-priority
  containers:
  - name: app
    image: nginx:1.25

Attention

La preemption peut causer des interruptions. Utilisez-la uniquement pour des workloads réellement critiques.

---

Exercices pratiques

Exercice 1 : nodeSelector (2 min)

Labellisez un nœud avec tier=frontend et créez un Pod qui ne s’exécute que sur ce nœud.

Solution

# Labelliser
kubectl label node worker-1 tier=frontend

# Pod
kubectl apply -f - <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: frontend-pod
spec:
  nodeSelector:
    tier: frontend
  containers:
  - name: nginx
    image: nginx:1.25
EOF

# Vérifier
kubectl get pod frontend-pod -o wide

Exercice 2 : Taint + Toleration (4 min)

1. Appliquez un taint workload=ml:NoSchedule sur un nœud
2. Créez un Pod sans toleration (doit rester Pending)
3. Créez un Pod avec toleration (doit démarrer)

Solution

# Taint
kubectl taint nodes worker-1 workload=ml:NoSchedule

# Pod sans toleration
kubectl run no-toleration --image=nginx -o yaml --dry-run=client | \
  kubectl apply -f -
kubectl get pod no-toleration
# Pending (si worker-1 est le seul nœud disponible)

# Pod avec toleration
kubectl apply -f - <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: ml-pod
spec:
  tolerations:
  - key: "workload"
    operator: "Equal"
    value: "ml"
    effect: "NoSchedule"
  containers:
  - name: app
    image: nginx:1.25
EOF

# Nettoyage
kubectl taint nodes worker-1 workload=ml:NoSchedule-

Exercice 3 : podAntiAffinity HA (5 min)

Créez un Deployment de 3 réplicas avec une anti-affinité garantissant qu’aucun Pod ne partage le même nœud.

Solution

kubectl apply -f - <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ha-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ha-app
  template:
    metadata:
      labels:
        app: ha-app
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: ha-app
            topologyKey: kubernetes.io/hostname
      containers:
      - name: nginx
        image: nginx:1.25
EOF

# Vérifier la distribution
kubectl get pods -l app=ha-app -o wide

---

Debugging du scheduling

Quand un Pod reste Pending, le scheduler indique pourquoi dans les events :

# Events du Pod
kubectl describe pod <pod-name> | grep -A10 Events

# Messages courants
# 0/3 nodes are available: 1 node(s) had untolerated taint, 2 node(s) didn't match Pod's node affinity
# 0/3 nodes are available: 3 Insufficient cpu
# 0/3 nodes are available: 3 node(s) didn't match pod anti-affinity rules

Checklist debugging

1. Vérifier les events du Pod

   kubectl describe pod <name> | tail -20

2. Vérifier les ressources disponibles

   kubectl describe nodes | grep -A5 "Allocated resources"

3. Vérifier les taints des nœuds

   kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

4. Vérifier les labels des nœuds

   kubectl get nodes --show-labels | tr ',' '\n'

---

À retenir

1. nodeSelector : placement simple, tous les labels doivent matcher
2. nodeAffinity : placement avancé avec expressions (In, NotIn, Exists, Gt, Lt)
3. podAffinity/AntiAffinity : placement relatif entre Pods (co-localisation ou séparation)
4. Taints repoussent les Pods, tolerations permettent aux Pods de passer
5. topologySpreadConstraints : répartition équilibrée sur zones/nœuds
6. PriorityClass : permet la preemption des Pods de basse priorité
7. Un Pod Pending → kubectl describe pod pour voir la raison

---

Prochaines étapes

Troubleshooting Kubernetes Debug des clusters, Pods et networking

Autoscaling HPA, VPA et Cluster Autoscaler

Exercices CKA Entraînement format examen

Requests et Limits Gestion des ressources CPU et mémoire

×

📖 Voir la documentation →