Kubernetes 048 – High Availability avec HAProxy et kubeadm

TL;DR

Pour un cluster kubeadm HA, les clients et les noeuds doivent parler a un endpoint stable plutot qu’a un seul control plane. HAProxy peut fournir cet endpoint TCP vers plusieurs API Servers sur le port 6443. Il faut ensuite initialiser kubeadm avec --control-plane-endpoint.

La video de reference

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

Elle introduit la haute disponibilite de l’API Kubernetes avec HAProxy.

Pourquoi un load balancer ?

Dans un cluster a plusieurs control planes, l’API Server existe sur plusieurs noeuds. Les workers et les administrateurs ont besoin d’une adresse unique.

Le load balancer masque les control planes individuels et permet de continuer si l’un d’eux tombe.

HAProxy en TCP

L’API Kubernetes utilise HTTPS. HAProxy peut fonctionner en mode TCP sans terminer TLS:

frontend kubernetes-api
  bind *:6443
  mode tcp
  option tcplog
  default_backend kubernetes-masters

backend kubernetes-masters
  mode tcp
  balance roundrobin
  option tcp-check
  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 backend pointe vers les API Servers des control planes.

Endpoint kubeadm

Lors de l’initialisation du premier control plane:

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

L’endpoint doit etre l’adresse HAProxy ou un nom DNS qui y pointe.

Joindre les autres control planes

La commande de join des control planes doit utiliser ce meme endpoint:

sudo kubeadm join 192.168.56.10:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash> \
  --control-plane \
  --certificate-key <key>

Ainsi, les nouveaux control planes rejoignent un cluster dont l’adresse publique est stable.

Verifier HAProxy

systemctl status haproxy
ss -lntp | grep 6443
openssl s_client -connect 192.168.56.10:6443

On peut aussi arreter un API Server et verifier que l’endpoint repond toujours si un autre backend est disponible.

Limite: HAProxy seul

Si HAProxy tourne sur une seule machine, cette machine devient un point unique de panne. C’est mieux qu’un seul control plane, mais pas une HA complete.

L’etape suivante consiste a rendre aussi l’endpoint du load balancer hautement disponible, par exemple avec Keepalived.

Etcd et quorum

La haute disponibilite ne concerne pas seulement l’API Server. Le stockage etcd doit conserver son quorum. Trois control planes avec etcd embarque est une topologie courante pour un lab HA.

Il faut eviter les nombres pairs de membres etcd et comprendre l’impact d’une panne.

Liens utiles

• Video: https://www.youtube.com/watch?v=HOpP2HuGXno
• 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/
• HAProxy: https://www.haproxy.org/

FAQ

HAProxy termine-t-il TLS ?

Dans cette configuration, non. Il relaie le TCP vers les API Servers.

Pourquoi utiliser --control-plane-endpoint ?

Pour que les certificats et kubeconfigs pointent vers l’adresse stable du cluster.

HAProxy suffit-il pour la HA ?

Pas si HAProxy est seul. Il faut aussi rendre son IP ou son service redondant.

Erreurs frequentes

• Initialiser kubeadm avec l’IP d’un master au lieu du load balancer.
• Oublier d’ouvrir le port 6443.
• Mettre HAProxy en HTTP au lieu de TCP.
• Confondre HA de l’API et HA d’etcd.

Pour pratiquer

Configurez HAProxy devant trois control planes, puis stoppez un API Server. Verifiez que kubectl get nodes continue a fonctionner via l’endpoint HA.

Notions et definitions

• Service: point d’entree stable devant un ensemble de pods.
• Endpoint ou EndpointSlice: liste des backends reels selectionnes par le Service.
• kube-proxy: composant qui programme les regles reseau necessaires sur chaque noeud.

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

Un Deployment web expose par un Service web-svc permet a un client de viser une IP stable, meme si les pods web sont recrees avec de nouvelles adresses IP.

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

• Creer un Deployment avec un label clair, par exemple app=web.
• Creer un Service dont le selecteur cible ce label.
• Verifier que les endpoints apparaissent et correspondent aux pods attendus.
• Tester depuis un pod de debug plutot que depuis uniquement votre machine locale.

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 le chemin reseau complet entre un client, un Service, kube-proxy et les pods cibles. 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 svc,endpoints,endpointslices -o wide
• kubectl describe svc <service> pour verifier le selecteur, les ports et les endpoints
• kubectl logs -n kube-system -l k8s-app=kube-proxy pour confirmer le mode et les erreurs reseau

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 Service, Pod IP et endpoint reel
• oublier qu’un Service sans endpoint ne peut pas router de trafic applicatif
• diagnostiquer le CNI alors que le probleme vient du selecteur ou du port du Service

Exercice conseille

Creez deux Deployments nginx avec des labels differents, exposez-en un avec un Service, puis modifiez volontairement le selecteur pour observer la disparition des endpoints.

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 049 – HAProxy et Keepalived avec kubeadm.

Conclusion

HAProxy fournit la premiere brique d’un control plane hautement disponible: une adresse stable devant plusieurs API Servers. Il doit ensuite etre lui-meme rendu resilient.