HAProxy Technologies a publié un excellent article sur la manière d’exécuter HAProxy Ingress Controller à l’extérieur d’un cluster Kubernetes. En effet, traditionnellement, on exécutait HAProxy Ingress Controller en tant que pod à l’intérieur de votre cluster Kubernetes. En tant que pod, il a accès à d’autres pods car ils partagent le même plan d’adressage réseau au niveau des pods. Cela lui permet d’acheminer et d’équilibrer la charge du trafic vers les applications s’exécutant à l’intérieur des pods, mais le défi est de savoir comment connecter le trafic provenant de l’extérieur du cluster en premier lieu à l’Ingress Controller …
Dans cet article, ce problème est résolu en installant Project Calico en tant que plug-in réseau dans Kubernetes, puis en permettant à Calico de partager ses routes réseau avec le serveur de l’Ingress Controller dans le cluster Kubernetes via le peering BGP. Dans un environnement de production, ce peering BGP se ferait vers un périphérique de niveau 3 de votre réseau, mais pour cette démonstration, le démon de routage Internet BIRD a été utilisé comme routeur et installé sur la même machine virtuelle que l’Ingress Controller …
Ici, je vais essayer de simplifier cette méthode en testant l’utilisation du “VPN du pauvre” à savoir sshuttle :
- GitHub - sshuttle/sshuttle: Transparent proxy server that works as a poor man's VPN. Forwards over ssh. Doesn't require admin. Works with Linux and MacOS. Supports DNS tunneling.
- Sshuttle : le tunnel magique et sécurisé | Commandes et Système | IT-Connect
Le concept est simple : sshuttle permet de mettre en place un VPN avec un simple accès SSH à un serveur tiers. L’outil sait faire passer du DNS (DNS tunneling) et pas besoin d’être admin sur la machine, ni de jouer avec des protocoles VPN ou du port forwarding.
Application avec la création d’un cluster k3s sur Hetzner Cloud :
En utilisant la dernière release :
avec ces deux scripts qui n’installeront ni Traefik pour la partie Ingress Controller ni Klipper pour la partie du LoadBalancing embarqué :
Après la partie k3s Server, installation des Workers :
Le cluster k3s est opérationnel sans Traefik ni service de LoadBalancing :
Il est temps de créer une instance Ubuntu 20.04 LTS dans le Cloud de DigitalOcean qui hébergera HAProxy Ingress Controller :
Je commence par y insérer le fichier Kubeconfig relatif au cluster k3s avec le client Kubectl :
Et j’y installe également le serveur HAProxy indispensable au fonctionnement de HAProxy Ingress Controller en mode externe :
Récupération de HAProxy Ingress Controller fourni sous la forme d’un binaire sur GitHub :
GitHub - haproxytech/kubernetes-ingress: HAProxy ingress controller for K8s
Installation de sshuttle via Python :
Je connais par avance les plans d’adressage concernant les pods et les services dans k3s :
Dès lors il est possible d’établir un tunnel via sshuttle entre notre instance hébergeant HAProxy Ingress Controller dans DigitalOcean et le serveur k3s dans Hetzner Cloud :
Dès lors, lancement de HAProxy Ingress Controller en mode externe sur notre instance :
Cet Ingress Controller est à l’écoute pour le cluster k3s distant … Je teste ce dispositif avec le déploiement du sempiternel démonstrateur FC :
HAProxy Ingress Controller a intercepté le déploiement dans le cluster k3s :
Je peux vérifier localement sur cette instance externe que la liaison vers les plans d’adressage des services et pods fonctionne avec sshuttle :
Et effectivement, par l’entremise de HAProxy Ingress Controller, le démonstrateur FC est accessible via l’IP publique de cette instance distance dans DigitalOcean :
Un fichier de configuration pour HAProxy a été généré automatiquement :
et le service traditionnel de suivi du LoadBalancing d’HAProxy est disponible sur les ports TCP 1024 et 1048:
Je peux d’ailleur mettre à l’échelle le déploiement du démonstrateur FC dans le cluster k3s pour y observer le comportement avec HAProxy Ingress Controller :
et c’est immédiatement répercuter dans HAProxy :
avec assez peu de ressources consommées dans cette instance extérieure …
HAProxy Technologies a d’ailleurs proposé récemment un webinaire sur ce mode externe :
On peut aller plus loin sur l’utilisation de HAProxy Ingress Controller avec des options sur la limitation de débit notamment :
Rate Limiting with the HAProxy Kubernetes Ingress Controller - HAProxy Technologies
Ceci afin de tirer parti d’annotations destinnées à protéger services et API ...
Un dépôt GitHub existe reprenant la démonstration de HAProxy Ingress Controller à l’extérieur d’un cluster Kubernetes via BGP, k0s, Vagrant et le routeur Bird :
GitHub - haproxytech/kubernetes-ingress: HAProxy ingress controller for K8s
À suivre !
Top comments (0)