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.
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.
Lire aussi : Le MFA, une course à obstacles pour Snowflake
Illustration principale © Macrovector - shutterstock.com
Sur le même thème
Voir tous les articles Workspace