Recherche

HAProxy : le contrôleur d'ingress se détache des clusters

Le contrôleur HAProxy peut désormais fonctionner hors d'un cluster Kubernetes. Authentification, paramétrage et gestion des erreurs évoluent aussi.

Publié par Clément Bohic le - mis à jour à
Lecture
2 min
  • Imprimer
HAProxy : le contrôleur d'ingress se détache des clusters

Comment gagner en latence sur un cluster Kubernetes ? Par exemple, en externalisant le contrôleur d'ingress. C'est désormais faisable avec celui associé à l'équilibreur de charge HAProxy.

Sa dernière version permet aussi d'activer l'authentification basique sur HTTP. On ajoute pour cela l'annotation auth-type avec la valeur basic-auth dans la définition Ingress ou dans le ConfigMap.

Autre forme d'authentification qui devient activable : l'authentification TLS mutuelle entre le contrôleur (client) et les back-end (serveur). Les annotations server-ca et server-crt remplissent ce rôle. On peut les intégrer dans les définitions de services.

Les annotations donnent aussi la possibilité de paramétrer HAProxy sans avoir à éditer son fichier de configuration - avec son « langage » propre. Cette couche d'abstraction ne donne cependant pas accès à toutes les capacités de l'équilibreur de charge. La dernière version du contrôleur propose un palliatif : l'intégration de directives « natives » dans le ConfigMap comme dans les définitions d'ingress ou de services.

Le code ci-dessous illustre cette approche. Il stocke l'IP du client et l'URL demandée, puis applique un nombre limite de requêtes. Autant de fonctionnalités non exposées à travers les annotations.

On soulignera aussi qu'il est maintenant possible de « donner corps » aux erreurs que génère HAProxy. Ce en créant des ressources ConfigMap qui associent des messages HTML à des codes HTTP.

Illustration principale © Macrovector - shutterstock.com

Sur le même thème

Voir tous les articles Workspace

Livres Blancs #security

Voir tous les livres blancs
S'abonner
au magazine
Se connecter
Retour haut de page