Kubernetes 049 – HAProxy et Keepalived avec kubeadm

TL;DR

HAProxy repartit le trafic vers les API Servers, mais s’il est seul il reste un point de panne. Keepalived permet de porter une IP virtuelle entre plusieurs machines. En combinant Keepalived et HAProxy, on obtient un endpoint Kubernetes plus resilient pour kubeadm.

La video de reference

Video: https://www.youtube.com/watch?v=YexNqhBsJc4

Elle prolonge l’episode HAProxy en ajoutant une VIP partagee.

Le probleme restant

Avec un seul HAProxy, tous les clients parlent a une seule machine. Si cette machine tombe, les API Servers peuvent etre vivants, mais l’endpoint devient inaccessible.

Keepalived corrige ce point en deplacant une IP virtuelle vers un autre noeud disponible.

Principe de Keepalived

Keepalived utilise VRRP pour elire un noeud actif qui porte la VIP. Si ce noeud echoue, un autre prend l’IP.

Les clients ne changent pas de configuration: ils parlent toujours a la VIP.

Exemple de configuration

vrrp_instance VI_1 {
  state MASTER
  interface eth1
  virtual_router_id 51
  priority 110
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass secret
  }
  virtual_ipaddress {
    192.168.56.100/24
  }
}

Sur le noeud secondaire, on baisse la priorite et on utilise state BACKUP.

HAProxy sur chaque noeud LB

Chaque noeud qui peut porter la VIP doit aussi faire tourner HAProxy:

frontend kubernetes-api
  bind 192.168.56.100:6443
  mode tcp
  default_backend kubernetes-masters

backend kubernetes-masters
  mode tcp
  balance roundrobin
  server master1 192.168.56.11:6443 check
  server master2 192.168.56.12:6443 check
  server master3 192.168.56.13:6443 check

Le bind peut aussi etre *:6443 selon le contexte reseau.

Utiliser la VIP avec kubeadm

sudo kubeadm init \
  --control-plane-endpoint "192.168.56.100:6443" \
  --upload-certs \
  --pod-network-cidr=10.244.0.0/16

Tous les joins et kubeconfigs doivent viser cette VIP ou un DNS qui pointe dessus.

Verifier la VIP

ip addr show
systemctl status keepalived
systemctl status haproxy
curl -k https://192.168.56.100:6443/readyz

Un test de failover consiste a arreter Keepalived sur le noeud actif et observer le basculement.

Health checks

Une configuration plus solide fait dependre la priorite Keepalived de l’etat de HAProxy. Si HAProxy est mort, le noeud ne doit pas garder la VIP.

Cela se fait avec des scripts de check Keepalived adaptes au contexte.

Points de vigilance reseau

La VIP doit etre possible dans le reseau choisi. En cloud, VRRP peut etre bloque ou non supporte. Dans ce cas, il faut utiliser le mecanisme de load balancing du fournisseur.

En lab Vagrant, cela fonctionne souvent bien sur un reseau prive.

Liens utiles

• Video: https://www.youtube.com/watch?v=YexNqhBsJc4
• Playlist Kubernetes v2: https://www.youtube.com/playlist?list=PLn6POgpklwWo6wiy2G3SjBubF6zXjksap
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• HA kubeadm: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/
• Keepalived: https://www.keepalived.org/

FAQ

Keepalived remplace-t-il HAProxy ?

Non. Keepalived gere la VIP. HAProxy repartit le trafic vers les API Servers.

Peut-on utiliser un DNS au lieu d’une IP ?

Oui, mais le DNS doit pointer vers un endpoint lui-meme hautement disponible.

Est-ce adapte au cloud public ?

Pas toujours. Les clouds proposent souvent leur propre load balancer.

Erreurs frequentes

• Oublier HAProxy sur le noeud qui recupere la VIP.
• Configurer une VIP hors du reseau local.
• Ne pas tester le failover.
• Initialiser kubeadm avec une IP non virtuelle.

Pour pratiquer

Montez deux noeuds load balancer, deplacez la VIP en arretant Keepalived sur le primaire, puis verifiez que kubectl continue a joindre l’API.

Notions et definitions

• Control plane: ensemble des composants qui exposent l’API et prennent les decisions.
• Worker node: machine qui execute les pods applicatifs.
• Runtime et kubelet: briques locales responsables du lancement et du suivi des conteneurs.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Dans un cluster kubeadm, l’API Server recoit les manifests, le scheduler choisit un noeud, puis le kubelet demande au runtime de lancer les conteneurs.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Verifier les prerequis systeme: swap, modules kernel, runtime, reseau.
• Initialiser ou rejoindre le cluster selon le role du noeud.
• Installer un CNI avant d’attendre des pods applicatifs fonctionnels.
• Valider CoreDNS, nodes Ready et un deploiement de test.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser les composants d’un cluster, leur installation et les responsabilites entre control plane, workers et runtime. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl get nodes -o wide
• kubectl -n kube-system get pods -o wide
• sudo crictl ps ou sudo systemctl status containerd kubelet sur les noeuds

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• confondre installation reussie et cluster exploitable dans la duree
• ne pas verifier DNS, CNI, certificats et horloge apres l’installation
• oublier que la haute disponibilite depend aussi du load balancer et du reseau

Exercice conseille

Preparez une checklist post-installation: nodes Ready, CoreDNS fonctionnel, CNI actif, pod de test joignable et redemarrage d’un composant kube-system observe.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 050 – Installation avec Ansible et kubeadm.

Conclusion

HAProxy et Keepalived forment un couple classique pour un endpoint Kubernetes redondant en lab ou bare metal. La VIP devient le point d’entree stable du cluster.