Skip to main content
Deux règles de placement méritent d’être connues dès le départ, parce qu’elles expliquent des comportements surprenants : pourquoi certains pods ne se posent jamais sur le nœud big-one-9d0479e4, et pourquoi d’autres restent bloqués en Pending si ce nœud est le seul disponible. Cette page détaille ces règles, leurs conséquences pratiques et comment diagnostiquer un pod qui refuse de démarrer.

​
Règle 1 : le chart rollout évite big-one-9d0479e4

En l’absence d’affinity explicite dans votre fichier de valeurs, le chart rollout injecte automatiquement une préférence négative qui demande au scheduler d’éviter le nœud big-one-9d0479e4 tant qu’un autre convient. Il s’agit d’une règle de type preferredDuringSchedulingIgnoredDuringExecution avec un poids de 100. Le scheduler essaiera donc de placer le pod ailleurs, mais acceptera big-one-9d0479e4 si les trois autres nœuds sont pleins. Voici ce que cela donne dans le manifeste rendu :
Cette règle s’applique à toutes les applications déployées avec le chart rollout (ou rollout-v2) sauf si vous redéfinissez explicitement le bloc affinity dans votre fichier de valeurs.

​
Règle 2 : data-precompute exclut strictement

Les manifestes de values/data-precompute/ appliquent la même exclusion, mais en version stricte : requiredDuringSchedulingIgnoredDuringExecution. Ces pods REFUSENT de se planifier sur le nœud big-one-9d0479e4.
Si le nœud big-one-9d0479e4 est le seul disponible (par exemple si les trois masters sont saturés ou en maintenance), les pods data-precompute restent en Pending indéfiniment. Le scheduler ne les placera jamais sur ce nœud.

​
Conséquence pratique

L’essentiel de la charge repose sur les trois nœuds du plan de contrôle. C’est inhabituel pour un cluster Kubernetes, où l’on attend plutôt que les masters restent dédiés à la gestion du cluster.
L’essentiel de la charge repose sur les 3 nœuds du plan de contrôle. C’est inhabituel pour un cluster Kubernetes, et cela signifie que vos 3 masters portent aussi du workload applicatif. Prenez cela en compte lorsque vous dimensionnez les ressources CPU et mémoire de vos pods.

​
Raison historique

La raison exacte de cette exclusion n’est pas documentée. C’est une question à poser à l’équipe infrastructure (devops@kaeyros-analytics.com) avant de dimensionner quoi que ce soit ou de modifier ces règles. Ne supprimez pas le bloc affinity sans validation.

​
Diagnostiquer un pod bloqué en Pending

Si un pod reste en Pending, vérifiez d’abord s’il est victime d’une règle d’affinity.