Load balancer avec Kubernetes
Grâce à Kubernetes, les entreprises se focalisent ainsi sur le développement de leurs logiciels. Il permet également de simplifier plusieurs tâches.
L’automatisation du cycle de vie des applications conteneurisées
Ces services ont besoin d’être mis à l’échelle, afin de suivre la demande et d’optimiser leur usage des ressources. Kubernetes permet donc d’automatiser cette étape. Cela assure un déploiement continu (CI/CD) de nouvelles versions et réduit drastiquement la maintenance.
Le déploiement d’applications multi-conteneurs (multi-containers)
Certains logiciels peuvent utiliser plusieurs conteneurs à la fois (bases de données, front end, back end, cache…). Cette situation nécessite parfois de posséder plusieurs instances. Kubernetes apporte alors de la synchronisation lors du déploiement, entre les différents conteneurs et composants liés.
Le lancement depuis n’importe quel environnement
Cloud public, cloud privé, serveur physique ou virtuel : Kubernetes s’implémente facilement, même dans une architecture hybride. Il offre une plus grande liberté à vos projets, en fonction de leur environnement.
Qu’est-ce qu’un load balancer ?
Cet équilibreur a pour but de répartir la charge de travail entre différents serveurs ou applications. Il peut être installé sur une infrastructure aussi bien physique que virtuelle. Un logiciel de load balancing (ou d’équilibrage des charges) prend ainsi la forme d’un contrôleur de livraison d'applications (application delivery controller ou ADC). Il permet à son bénéficiaire de faire évoluer la charge automatiquement, en fonction des prévisions de trafic.
L’ADC identifie en temps réel quel serveur ou application est la plus apte à répondre à une demande, afin que le cluster maintienne un niveau de performance stable. En cas de panne, il aura également pour mission de rediriger le trafic vers une ressource capable de s’en charger. Plusieurs types de configurations sont alors possibles.
Dans la chronologie, le load balancer intervient entre l’utilisateur et le serveur. Il analyse la demande, détermine quelle machine est disponible pour y répondre, puis la lui transmet. Il peut aussi ajouter des serveurs en cas de besoin.
La répartition de charge, comme nous venons de le voir, n’est qu’une des applications possibles du load balancer. Il est notamment utile pour désengorger un certificat SSL ou mettre à jour des groupes d’applications. Vous pouvez même y recourir afin de router vos noms de domaine.
Il existe deux types de load balancers :
- Les « load balancers L4 » ou « network load balancers »
Ils traitent les données de la couche 4 (ou layer 4) qui sont présentes au niveau du réseau et du transport (TCP/UDP). Ces load balancers ne se concentrent pas sur les informations applicatives, comme le type de contenu, les cookies, la localisation des headers, etc. Ils vont donc rediriger le trafic uniquement en se basant sur les données de la couche réseau.
- Les « load balancers L7 » ou « application load balancers »
Ils redirigent le trafic en s’appuyant sur les paramètres de la couche applicative, contrairement aux L4. Ces load balancers traitent ainsi un volume de données plus important et se basent sur davantage d’informations. Ceci inclut par exemple les protocoles HTTP, HTTPS et SSL.
Comment le load balancer fonctionne-t-il avec Kubernetes ?
Lorsque vous commencez à utiliser Kubernetes pour vos applications, la question du trafic externe reste une notion importante. Ce sujet est brièvement abordé sur le site officiel de Kubernetes, mais nous allons y apporter quelques précisions.
Il existe diverses manières d’acheminer un trafic externe vers votre cluster :
- utiliser un proxy avec le ClusterIP ;
- définir un service en tant que NodePort ;
- déclarer un service en tant que load balancer et l’exposer ainsi au trafic externe. Cette méthode est la plus employée.
Utiliser le ClusterIP via un proxy
Généralement utilisée pour le développement, cette méthode est disponible par défaut depuis Kubernetes. L’ouverture d’un proxy entre votre source extérieure et votre ClusterIP vous permet d’acheminer du trafic. Vous pouvez recourir à la commande « kubectl » pour créer ce proxy. Lorsqu’il sera opérationnel, vous serez directement connecté à l’IP de votre cluster pour ce service spécifique.
Exposer un service en tant que NodePort
Ce faisant, vous exposez les adresses de vos nœuds individuellement sur les ports concernés (un port fixe du service de 30000 à 32767). Vous pouvez ainsi accéder à votre service de l’extérieur depuis son propre port, sur chaque nœud. Pour cela, utilisez la commande <NodeIp>:<NodePort>
Même si elle reste envisageable, cette méthode est relativement difficile pour des services en production. Comme vous employez des ports « non standards », vous devez souvent configurer un répartiteur de charge externe. Celui-ci traite les ports standards et redirige le trafic vers la requête « <NodeIp>:<NodePort> ».
Opter pour un load balancer
Cela consiste à déclarer un service en tant que load balancer pour votre cluster. Il est ainsi exposé au trafic externe. Cette méthode nécessite d’utiliser la solution de load balancing d’un fournisseur cloud, comme notre Load Balancer. Elle provisionnera le service pour votre cluster, en lui assignant automatiquement son NodePort.
Si vous disposez d’un environnement de production, le load balancer est la solution que nous vous recommandons. Cependant, veuillez noter deux choses importantes :
- chaque service que vous définissez et déployez en tant que load balancer dispose de sa propre adresse IP ;
- l'utilisation du Load Balancer OVHcloud est réservée aux utilisateurs de Managed Kubernetes Service.
Il agit donc comme un filtre entre le trafic externe entrant et votre cluster Kubernetes. Vous pouvez déployer jusqu’à 16 load balancers par cluster, que vous gérez directement depuis votre interface K8s. Nos guides sont à votre disposition pour vous aider dans la configuration de votre équilibreur de charge.
Ajouter un Ingress avec votre load balancer
L’Ingress est un objet Kubernetes qui gère l’accès aux services de votre cluster depuis l’extérieur (comme un protocole HTTP). Mais alors, en quoi diffère-t-il du load balancer ?
Unique point d’entrée à votre cluster, il fonctionne à la manière d’un reverse proxy. L’Ingress dirige ensuite les requêtes passant par lui aux différents services, selon une configuration de règles. Il est exposé au trafic externe par ClusterIP, NodePort ou un load balancer. L’ Ingress le plus connu est NGINX Ingress Controller.
Pourquoi utiliser un Ingress avec votre load balancer ? Tout simplement afin de diminuer vos coûts. La facturation d’un load balancer est établie selon le nombre de services qu’il orchestre, avec une capacité limitée. Ainsi, grâce à un Ingress, vous pouvez attacher davantage de services au même load balancer et réaliser des économies.
Que me conseillez-vous ?
Pour répondre à cette question, vous devez déterminer avec certitude votre utilisation de Kubernetes.
Le load balancer convient à la vaste majorité des usages. Vous pouvez en définir un de façon personnalisée pour chacun de vos services Kubernetes, sans configuration nécessaire par la suite. Cette méthode ne conviendra cependant pas à tous les budgets. En effet, elle implique une gestion complexe d’un grand nombre d’adresses IP.
Plus simple : vous pouvez utiliser un load balancer et un Ingress derrière lui. Tous vos services seront ainsi rangés sous la même adresse IP et vous ne paieriez qu’un seul load balancer.
Vous devrez toutefois veiller à ce que les services orchestrés par ce modèle aient une relation logique entre eux. Dans le cas contraire, cela pourrait créer des dysfonctionnements ou des pannes.
Une configuration optimale pourrait être un load balancer couplé à un Ingress pour chaque « famille de services » ou de microservices. L’organisation dépendra de la complexité de vos architectures Kubernetes.
