Kubernetes : Le Scheduler ( Partie 2)

Dans un article précédent, nous avons vu l’un des facteurs ( à savoir Taint et Tolération) que Scheduler prend en compte pour sélectionner le node approprié pour déployer les pods dans kubernetes cluster.

Dans cet article ce tutoriel, nous poursuivrons notre voyage avec le scheduler et nous alons couvrir deux autres facteurs appelés node selector et node affinity.

Scheduler & Node Selector

Disons que nous avons un Cluster Kubernetes avec 3 nodes et 3 pods qui attendent être déployés sur ces nodes.

L’un de ces pods (Red Pod) héberge une application critique qui exige d’être déployée sur un node configuré avec des ressources plus élevées, dont le nom est high:

Avec la configuration par défaut de scheduler, tous les pods peuvent être déployés sur n’importe quel node. Dans ce cas, le pode rouge peut se retrouver sur le node 2 ou le node 3. Par contre ce n’est pas ce que nous souhaitons.

Nous devons donc dire au scheduler de déployer le pod rouge sur le node dont les ressources sont suffisants.

Configuration du pod :

Pour ce faire, nous ajoutons la propriété nodeSelector à la section spec du fichier yaml du pod comme ceci :

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80
nodeSelector: 
  ressources: high

Une fois le prod est créé, il est déployée sur le node 1 dont les ressources sont élevées.

Mais comment le scheduler sait-il qu’il existe un node nommé « haut » ?
C’est parce qu’une label « high » a été attribuée à ce node pour qu’il soit identifié.

Pour attribuer une label à un node, utilisez la commande ci-dessous :

kubectl label nodes <node_name> key=value

Dans notre cas, voici la commande :

kubectl label nodes node1 ressources=high

Ainsi, la première chose à faire est d’attribuer un label au node et d’ajouter la propriété nodeSelector dans le fichier de configuration yaml du pod pour sélectionner ce node souhaité.

Maintenant, nous sommes sûrs que notre pod finira par être déployé sur le node avec les ressources élevées :

Maintenant supposons que nous avons un cluster avec 3 nodes avec différentes ressources comme ci-dessous :

Nous souhaitons déployer le pod B sur le node « haut » ou sur le node « moyen ». Et Il ne faut pas que le pod déployer le module C sur le nœud le plus bas.

Nous ne pouvons pas utiliser ces expressions avec « nodeSelector« , il ne le comprend pas.

C’est pourquoi que nous avons besoin d’un autre facteur que le planificateur utilise, appelé nodeaffinity.

nodeaffinity :

nodeaffinity nous donne plus de flexibilité sur le choix du node approprié.

Par exemple, nous pouvons dire au Scheduler de déployer le pod sur le node contenant des ressources élevées ou sur celui qui a des ressources moyennes. Dans ce cas, le Scheduler essaiera de déployer le pod sur le node haut en premier. Par contre s’il ne peut pas le faire pour une raison quelconque, le pod sera déployé sur le node moyen.

Un autre cas d’utilisation de nodeaffinity est de dire au Scheduler de ne pas déployer le pod sur le node avec des ressource faible, ainsi le pod sera déployé soit sur l’un des nodes haut ou moyen.

Pour plus de détails sur nodeaffinity, réferez-vous à la documentation officielle.

Voir cet article en anglais.