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

Microservices
HAProxy 1.5

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

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.

basic authentication HAProxy

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.

TLS mutuel

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.

backend config snippet

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.

HAProxy custom error

Illustration principale © Macrovector – shutterstock.com


Lire la biographie de l´auteur  Masquer la biographie de l´auteur 
Avis d'experts de l'IT