Kubernetes : Le Scheduler ( Partie 1)

Au niveau de Kubernetes, le scheduler a un rôle important, c’est de choisir le node adéquat pour faire tourner un pod particuler.

Durant cet article , nous allons découvrir quels sont les facteurs pris en compte par le scheduler pour choisir le node approprié pour démarrer les pods.

Manuel Scheduling

Est-il possible de choisir manuellement sur quel node un pod doit tourner à la place du Sheduler ?

Oui, c’est possible, et c’est ce que nous appelons le Manuel Scheduling. Si vous souhaitez que votre application s’exécute sur un node spécifique, vous pouvez le faire manuellement.

Pour ce faire, vous devez spécifier le nom du node au niveau le fichier YAML du pod. Pour mieux comprendre prenons un exemple.

Voici un exemple de fichier yaml de pod exécutant le serveur web NGINX:

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

Pour choisir un node spécifique, vous devez définir une propriété appelée nodeName dans le fichier yaml comme suit :

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80
  nodeName: node1

Une fois le pod est créé par la commande suivante, il sera placé sur le node que nous avons de spécifié.

# kubectl create -f nginx.yaml

Dans le cas d’un manuel scheduling, le scheduler ignore tous les pods dont la propriété nodeName est définie.

Le manuel scheduling peut être utile dans certains scénarios où vous souhaitez plus de contrôle sur l’emplacement de vos pods.

Par contre en cas de plusieurs pods au niveau de votre cluster, vous ne serez pas heureux de les gérer manuellement , vous aurez certainement besoin de l’aide du Scheduler.

Nous allons maintenant découvrir quels sont les facteurs pris en compte par le Scheduler pour choisir le node approprié pour faire tourner les pods.

Taint et Tolération

Le Kube Scheduler utilise la « taint » pour empêcher certains pods d’être exécutés dans un node particulier et n’accepte que les pods qui tolèrent ce taint.

Prenons un exemple pour mieux comprendre :

Ici, nous avons un cluster simple avec 3 nodes et 3 pods qui doivent être déployés sur ces nodes. Dans une situation normale (sans restriction), n’importe quel pod peut être placé sur n’importe quel node.

Supposons maintenant que nous avons un pod qui contient un conteneur applicatif critique (POD A) et que nous voulons nous assurer que cette application est déployée sur un node (node A) qui dispose des ressources suffisantes ( RAM, CPU …).

Non seulement cela, mais nous voulons aussi empêcher tous les autres pods (contenant des applications non critique) d’être déployés sur le node A.

Pour ce faire, nous allons ajouter une taint au node A et nous allons ajouter une tolérance au Pod A pour qu’il soit toléré à la taint :

Dans ce cas, le Scheduler ne déploie que le pod A sur le node A et les autres pods sur le node B et le node C aléatoirement.

Voyons maintenant comment nous pouvons appliquer ceci sur kubernetes.

key=value and & effect

Tout d’abord, nous devons ajouter une « taint » au node par la commande ci-dessous :

# kubectl taint nodes node_name key=value:effect

La valeur d’une taint dans Kubernetes peut être définie avec n’importe quelle chaîne de caractères. Disons que nous voulons déployer uniquement les pods qui contenant des applications critiques sur node A, la commande sera comme suit :

# kubectl taint nodes nodeA criticalapp=yes:NoSchedule

effect se réfère à l’action qui doit être prise lorsque le pod est placé sur un node avec une taint correspondante. Il y a trois valeurs possibles pour effect :

• NoSchedule :

C’est le comportement que nous avons vu jusqu’à présent, tous les pods qui ne tolèrent pas l’altération ne seront pas placé dans le node.

• PreferNoSchedule

Le scheduler essaiera d’éviter de placer des pods sur le node, mais ce n’est pas garanti. C’est une restriction plus souple que NoSchedule. Si aucun autre node n’est disponible, les pods sans la tolérance correspondante seront quand même placé sur le node.

• NoExecute

Cet effet est très dangereurs, elle est utilisé pour expluser les pods existants d’un dans un node qui ne tolèrent pas à la taint. Par exemple, si vous ajoutez une taint à un node et des pods y sont en cours d’exécution et qu’il n’y a pas de tolérance correspondante, les pods seront expulsés.

Tolérance du POD

Comme nous l’avons déjà vu, les tolérances sont utilisées pour spécifier qu’un pod peut être exécuter sur un node avec une taint correspondante.

Pour ce faire, nous devons ajouter une tolérance au fichier yaml du pod :

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80
  tolerations:
  - key: "critocalapp"
    operator: "Equal"
    value: "blue"
    effect: "NoSchedule"

Et voilà, Nous avons appris à placer les pods manuellement et comment le taint et la tolérance influencent les décisions du scheduler pour contrôler le placement des pods sur les nodes d’un cluster.

Dans le prochain article, nous allons voir d’autres facteurs que le scheduler prend en compte pour choisir le ou les nodes approprié pour démarrer les pods.

Pour plus d’informations sur le kube scheduler, réferez-vous à la documentation officielle.

Voir cet article en anglais.