harmony/docs/doc-remove-worker-flag.md
Willem dd3f07e5b7
All checks were successful
Run Check Script / check (pull_request) Successful in 1m13s
doc for removing worker flag from cp on UPI
2025-10-09 15:28:42 -04:00

2.7 KiB
Raw Permalink Blame History

  1. Titre : Retrait du flag worker sur les control planes (UPI)

  2. Contexte

    Dans certaines installations OpenShift UPI, les nodes de control plane (masters) héritent par erreur du label worker (node-role.kubernetes.io/worker).
    Cela provoque la planification de workloads non critiques (par ex. routers, Ceph pods, etc.) sur les control planes, ce qui compromet la stabilité et la séparation des rôles.

  3. Symptômes observés

  • Apres avoir ajouté des serveur dans HAProxy, tous les serveurs backend (wk0, wk1, wk2) apparaissent en état DOWN.
    Le trafic HTTP/HTTPS est redirigé vers les control planes au lieu des workers.

  • Les pods router-default sont déployés sur cp1 et cp2 plutôt que sur les workers.

  • Sur les masters, la commande suivante montre une écoute sur le port 80 :

    ss -tlnp | grep 80

    -> processus haproxy en écoute sur 0.0.0.0:80

    -> meme chose pour port 443

  • Dans le namespace rook-ceph, certains pods (mon, mgr, operator) ne se planifient pas, sont aussi deployé sur les cp au lieu des worker nodes :

  1. Cause

    En installation UPI, les rôles (master, worker) ne sont pas gérés par le Machine Config Operator (MCO).
    Les controls planes sont schedulable par default. Qui amene les trois roles, worker, master et control-plane.

  2. Diagnostic

  3. Vérifier les labels du node :

    oc get nodes --show-labels | grep control-plane

  4. Inspecter la configuration du kubelet :

    cat /etc/systemd/system/kubelet.service

    Rechercher la ligne :

    --node-labels=node-role.kubernetes.io/control-plane,node-role.kubernetes.io/master,node-role.kubernetes.io/worker

    → présence du label worker confirme le problème.

  5. Vérifier que ce flag ne provient pas du MCO :

    oc get machineconfig | grep rendered-master

Solution:
Pour rendre les control planes non planifiables (cest-à-dire empêcher tout déploiement de workloads dessus), il faut appliquer le patch suivant sur la ressource scheduler du cluster :
```

oc patch scheduler cluster --type merge -p '{"spec":{"mastersSchedulable":false}}'
```
Cette commande désactive la planification sur les masters et supprime efficacement le rôle worker de leurs fonctions.

Une fois le patch appliqué, il faut déplacer les workloads encore présents sur les control planes vers les workers à laide des commandes :

```
oc adm cordon
oc adm drain --ignore-daemonsets delete-emptydir-data
```