Alors que les architectures de microservices deviennent de plus en plus populaires, la gestion d'une solution logicielle basée sur des conteneurs revient désormais à gérer le cycle de vie de centaines de conteneurs. Cela peut facilement transformer tous les avantages attendus des architectures de microservices basées sur des conteneurs en cauchemar pour l'administrateur système. C'est là que l'orchestration des conteneurs entre en jeu et permet de simplifier la gestion de ces systèmes basés sur des conteneurs.
Kubernetes est actuellement la plate-forme d'orchestration de conteneurs la plus populaire et la plus largement adoptée. Lors de la gestion d'un si grand nombre de conteneurs, la mise en réseau devient un aspect critique du système, car tous ces conteneurs doivent communiquer efficacement entre eux et avec le monde extérieur. Etant donné l'aspect éphémère des conteneurs, vous vous retrouvez avec un environnement réseau en constante évolution.
En tant que tel, la mise en réseau est l'un des aspects les plus complexes de Kubernetes. Si vous souhaitez exécuter avec succès un service accessible au public dans Kubernetes, vous devez comprendre comment exploiter correctement les outils que Kubernetes vous offre. Lorsque vous envisagez d'exposer une application sur Internet, Kubernetes propose plusieurs options parmi lesquelles vous devez choisir, telles que les services, les équilibreurs de charge et les entrées. Comme ceux-ci peuvent causer beaucoup de confusion, examinons ces différentes solutions et comprenons pourquoi les load balancers sont si cruciaux dans ce type de contexte.
À première vue, la mise en réseau Kubernetes peut sembler simple, car sa configuration tient dans une poignée de ressources comme le service ou l'entrée. Mais sous la surface, l'orchestrateur exploite en réalité de nombreux concepts et technologies de mise en réseau complexes, abstraits de l'utilisateur.
Si vous souhaitez exposer correctement vos pods, qui sont des ressources éphémères, vous devez comprendre le fonctionnement d'une ressource Kubernetes cruciale appelée "Service".
En un mot, un service expose un ensemble de pods derrière une adresse IP unique appelée ClusterIP et un nom de domaine. Ils sont tous deux uniquement accessibles au sein du cluster Kubernetes et permettent d'équilibrer le trafic entre les différents pods. Un service Kubernetes agit comme un équilibreur de charge réseau interne accessible aux charges de travail du cluster Kubernetes.
Il existe différents services Kubernetes pour exposer vos pods à internet. L'un s'appelle NodePort. Un NodePort est un type de service Kubernetes qui expose un port spécifique sur chaque nœud d'un cluster, permettant au trafic externe d'accéder à un pod s'exécutant sur ce nœud, en connectant l'adresse IP de ce pod à un port spécifique, HTTP par exemple.
Les nodeports ouvrent un port sur chaque nœud du cluster K8s et relient le trafic arrivant sur ce port au service qui le transmettra ensuite à un pod du cluster K8s.
NodePort peut être utile pour les projets qui ont besoin d'un test sur leurs applications localement avant de les déployer en production, ou lorsque vous n'avez qu'un seul nœud dans votre cluster.
Parfois, cela suffit pour un trafic très faible et une charge de travail sans impact sur l'entreprise, par exemple, lorsque vous n'avez pas besoin de fonctionnalités avancées telles que le routage ou le chiffrement de certificat.
Le problème avec NodePort est que les ports disponibles se situent dans la plage 30000, ce qui n'est pas approprié pour le trafic internet arrivant généralement sur les ports 80 ou 443 car les pare-feu bloqueraient facilement ce port sur Internet.
Ce faisant, vous créez également un SPOF (Single Point of Failure), car vous vous appuyez sur un seul nœud. Pour éviter ce comportement, vous devrez disposer d'une adresse IP publique pour chaque pod, ainsi que gérer l'équilibrage du trafic et la configuration des vérifications de l'état… Au final, vous finissez par construire un équilibreur de charge devant vos nœuds Kubernetes.
C'est pourquoi un service "Load Balancer" est utile pour exposer vos pods au monde extérieur. Vous devez le configurer devant un service NodePort, et il devient un point d'entrée vers votre cluster Kubernetes qui transfère le trafic vers vos pods.
Lorsque cela se produit, Scaleway provisionne automatiquement un Load Balancer public au niveau du réseau qui transfère le trafic externe vers les pods derrière votre service Kubernetes Load Balancer. Le Load Balancer est automatiquement tenu à jour des changements de configuration dans votre cluster Kubernetes, grâce au Cloud Controller Manager, et est supprimé lorsque vous supprimez votre service dans Kubernetes.
Une chose importante à noter est qu'avec Kubernetes Load Balancer, vous équilibrez la charge au niveau de la couche 4, donc aucun certificat SSL/TLS n'est impliqué au niveau de l'équilibreur de charge. Vous faites effectivement un passthrough. Le certificat SSL/TLS et toutes les couches HTTP sont gérés dans votre pod, qui peut être un contrôleur d'entrée.
La manière standard d'apporter internet à votre cluster consiste à utiliser un équilibreur de charge qui tire parti de ses avantages, pour équilibrer le trafic et augmenter la résilience.
Comme nous venons de le mentionner, un autre composant que vous pouvez entendre parler du routage réseau et de Kubernetes est le contrôleur Ingress, qui est également une ressource Kubernetes qui gère l'accès externe aux services dans un cluster. Il agit comme un proxy inverse, acheminant le trafic entrant vers le service approprié en fonction du chemin de l'URL ou du nom d'hôte.
Le contrôleur Ingress est très proche d'un équilibreur de charge mais ne fonctionne qu'entre les nœuds de travail, au niveau de l'application, couche 7, équilibrant le trafic vers différents services dans Kubernetes.
Dans ce cas, le load balancer a des services comme backends ; tandis que les mêmes services Kubernetes ont les pods comme backend.
L'entrée placée entre le service Load balancer et le nœud fournit en fait la configuration du réseau (services backend et routes). Les contrôleurs d'entrée sont bien connus dans la communauté et des noms tels que Nginx, Traefik et HAProxy sont très courants. Et vous pouvez utiliser notre bibliothèque d'applications pour la déployer de manière transparente avec un Helm Chart.
Imaginez que votre entreprise héberge plusieurs services derrière le mycompany.com domaine. Le blog est accessible via blog.mycompany.com, tandis que la boutique est accessible via shop.mycompany.com.
Dans Kubernetes, vous aurez alors des pods derrière un service de blog qui serviront le blog, et d'autres pods derrière un service de boutique pour servir la boutique.
Vous utilisez ensuite une entrée pour exposer les deux services derrière une seule adresse IP publique et faire en sorte que l'entrée redirige le trafic vers blog.mycompany.com vers les pods de blog et le trafic vers shop.mycompany.com vers les pods de la boutique.
Le load balancer est l'élément d'infrastructure dont vous avez besoin pour exposer votre application ou service de conteneur sur internet. En effet, votre infrastructure est alors capable d'équilibrer le trafic entre les pods et de supporter les pics de trafic de manière transparente. La résilience sera accrue car les requêtes sont redirigées vers des ressources backend disponibles et saines et enfin un moyen d'accéder au réseau externe sans expositions inutiles.
D'autres technologies existent pour fournir le même service, comme NodePort, mais pas avec les mêmes fonctionnalités en termes de fiabilité et de sécurité. Cependant, ils ne sont pas mutuellement incompatibles. Un contrôleur d'entrée doit être associé à un Load Balancer ou à un Nodeport.
Si vous souhaitez en savoir plus sur les équilibreurs de charge, voici quelques ressources complémentaires utiles :
Configuration d'un équilibreur de charge pour vos applications Kubernetes
Premiers pas avec Kubernetes : Équilibreurs de charge
Dans cet article, nous allons distinguer les différentes méthodes d'autoscaling fournies par Kubernetes et comprendre les différences entre l'horizontal pod autoscaler et le vertical pod autoscaler.
Vous pouvez désormais profiter de notre control plane managé et haute disponibilité pour créer vos clusters de conteneurs. Découvrez Kubernetes Kapsule dans cet article
