« Équilibreur de charge Kubernetes » est un terme assez large qui fait référence à plusieurs choses. Dans cet article, nous examinerons deux types d’équilibreurs de charge : l’un utilisé pour exposer les services Kubernetes au monde extérieur et l’autre utilisé par les ingénieurs pour équilibrer les charges de trafic réseau vers ces services.
Continuez à lire pour obtenir les meilleures pratiques éprouvées pour gérer un équilibreur de charge Kubernetes.
Qu’est-ce qu’un équilibreur de charge Kubernetes ?
Dans Kubernetes, les conteneurs sont regroupés en pods avec des ressources de stockage et de réseau partagées, ainsi que des spécifications sur la manière d’exécuter ces conteneurs. Un groupe de pods associés peut former un service Kubernetes.
Étant donné que les pods ne sont pas persistants – Kubernetes les crée et les détruit automatiquement – leurs adresses IP ne sont pas non plus persistantes. Pour exposer les pods, vous devez utiliser une ressource Kubernetes appelée Service.
Un service Kubernetes vous permet d’exposer un groupe de pods à un usage externe ou interne. Vous pouvez choisir parmi quelques types de services, voici donc un aperçu rapide pour vous aider à démarrer.
Présentation des services Kubernetes
ClusterIP – il s’agit d’un type de service K8s par défaut qui expose un ensemble de pods uniquement en interne. Voici un exemple de définition YAML pour le service ClusterIP :
apiVersion: v1
kind: Service
metadata:
name: my-internal-service
spec:
selector:
app: my-app
type: ClusterIP
ports:
- name: http
port: 80
targetPort: 80
protocol: TCPClusterIP est utilisé pour la communication d’application interne et n’est pas disponible en dehors du cluster.
NodePort – le Service expose un port donné sur chaque IP de Node du cluster.
Exemple de définition YAML :
apiVersion: v1
kind: Service
metadata:
name: my-nodeport-service
spec:
selector:
app: my-app
type: NodePort
ports:
- name: http
port: 80
targetPort: 80
nodePort: 30000
protocol: TCPNotez que le service NodePort présente de nombreux inconvénients :
- vous ne pouvez avoir qu’un seul service par port
- vous ne pouvez utiliser que les ports 30000–32767,
- si votre adresse IP de nœud/VM change, vous devez vous en occuper.
C’est pourquoi il n’est pas recommandé pour les cas d’utilisation en production.
Équilibreur de charge – ce service expose un ensemble de pods à l’aide d’un équilibreur de charge externe. Toutes les offres Kubernetes gérées ont leur propre implémentation (pour EKS, vous pouvez utiliser NLB, ALB, etc.)
Dans la plupart des cas, ils sont créés par le fournisseur de cloud. Mais il y a aussi des projets qui visent à l’exposer sur des clusters bare metal – métalb est un bon exemple (je partage plus d’exemples à la fin de cet article).
Mais ce n’est pas la fin de l’histoire.
Kubernetes possède également un objet API appelé Entrée. Ingress est construit au-dessus du service Kubernetes (pour exposer Ingress, vous devez utiliser le service Kubernetes). La principale responsabilité d’Ingress est de distribuer le trafic réseau aux services selon des règles ou des algorithmes de routage prédéterminés.
Il expose également les pods au trafic externe, généralement via HTTP. En fonction de vos objectifs commerciaux et des spécificités de votre environnement, vous pouvez utiliser différentes stratégies de répartition de la charge.
Exemple de définition YAML :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: minimal-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx-example
rules:
- http:
paths:
- path: /testpath
pathType: Prefix
backend:
service:
name: test
port:
number: 80Stratégies de répartition du trafic de l’équilibreur de charge
Une distribution efficace du trafic réseau entre plusieurs services backend est essentielle pour maximiser l’évolutivité et la disponibilité.
Vous disposez d’une grande liberté pour équilibrer la charge du trafic externe vers les pods, mais chaque stratégie a ses avantages et ses inconvénients. Tout dépend de votre charge, de vos besoins et de vos préférences.
Le choix de l’algorithme d’équilibrage de charge est celui que vous devez faire avec soin – sinon, vous vous retrouverez avec une répartition de charge déséquilibrée ou un seul serveur Web fonctionnant à chaud.
Voici une sélection d’algorithmes d’équilibrage de charge que vous devriez considérer.
Tournoi à la ronde
À l’aide de cet algorithme de planification, vous suivez une séquence de serveurs éligibles qui obtiennent de nouvelles connexions. Notez que cette solution est statique – elle ne tient pas vraiment compte des variations de vitesse ou de performances entre ces serveurs individuels. Il s’assure simplement que les requêtes parviennent aux serveurs dans l’ordre.
Round robin est incapable de différencier les serveurs lents des serveurs rapides, il alloue donc un nombre égal de connexions à chacun d’eux. Si vous vous attendez à un trafic de production hautes performances, ce n’est peut-être pas le meilleur choix.
Équilibreur de charge L4 Round Robin
L’une des tactiques de base d’équilibrage de charge dans Kubernetes. Il traite toutes les requêtes envoyées au service et les achemine. Le kube-proxy implémente des adresses IP virtuelles pour les services à l’aide de règles iptables, ajoutant une certaine complexité au processus. Cela ajoute également une latence supplémentaire à chaque demande, ce qui peut devenir un problème si le nombre de services ne cesse d’augmenter.
Équilibrage de charge L7 Round Robin
Le proxy L7 dirige le trafic vers les pods Kubernetes en contournant le proxy kube via une passerelle API et en gérant les demandes pour les pods disponibles. L’équilibreur de charge suit également les pods, qui sont disponibles avec l’API Kubernetes Endpoints. Lorsqu’il reçoit une demande pour un service Kubernetes donné, il effectue un tour de rôle de la demande parmi les pods concernés pour en trouver un disponible.
Proxy kube L4 et IPVS
Par défaut, kube-proxy utilise iptables pour le routage, mais il peut également utiliser un serveur virtuel IP (IPVS). L’avantage d’IPVS est l’évolutivité : s’exécute en temps O(1) sans être influencé par le nombre de règles de routage requises. Ce nombre est directement proportionnel au nombre de services.
Si vous utilisez un énorme cluster Kubernetes avec des milliers de services, IPVS est une bonne option. Néanmoins, IPVS est un routage de niveau L4, il est donc soumis à certaines limitations.
Anneau de hachage
Cet algorithme de planification est basé sur un hachage, qui dérive d’une clé spécifiée. Un hachage permet la distribution de nouvelles connexions entre les serveurs. Ring hash est une bonne solution pour un grand nombre de serveurs et de contenus dynamiques puisqu’il allie équilibrage de charge et persistance. De nombreuses applications ou services de commerce électronique nécessitant un état par client l’utilisent.
Lorsqu’un serveur doit être ajouté ou supprimé, le hachage cohérent n’a pas à recalculer toute la table de hachage. Donc, cela n’affecte pas les autres connexions. Notez que le hachage en anneau peut ajouter une certaine latence aux demandes lors de l’exécution à grande échelle. En outre, l’algorithme génère des tables de recherche relativement volumineuses qui peuvent ne pas tenir dans le cache du processeur de votre CPU.
Maglev
Comme pour le hachage en anneau, Maglev est un algorithme de hachage cohérent qui a été initialement développé par Google. L’idée sous-jacente était une vitesse accrue sur le hachage en anneau lors des recherches de table de hachage. L’autre objectif de ses créateurs était de minimiser l’empreinte mémoire de l’algorithme.
Si vous décidez d’utiliser Maglev pour les microservices, attendez-vous à des coûts élevés liés à la génération d’une table de recherche en cas de défaillance d’un nœud. Étant donné que les pods K8 sont de nature relativement transitoire, l’utilisation de Maglev n’est peut-être pas la meilleure idée.
Moins de connexion
Cet algorithme d’équilibrage de charge dynamique distribue les demandes des clients aux pods avec le plus petit nombre de connexions actives et la plus petite charge de connexion. Grâce à cela, il s’adapte aux serveurs plus lents ou malsains. Mais lorsque tous vos pods sont également sains, la charge sera répartie de manière égale.
Meilleures pratiques pour gérer un équilibreur de charge Kubernetes
Lors de la mise en œuvre des équilibreurs de charge Kubernetes, suivez quelques étapes de configuration pour vous assurer que votre déploiement K8s utilise au maximum les équilibreurs de charge que vous choisissez.
Voici quelques bonnes pratiques pour travailler avec des équilibreurs de charge dans Kubernetes.
Vérifier si l’équilibreur de charge est activé
Celui-ci semble trop évident pour être inclus dans cette liste, mais c’est une étape clé. Vous devez activer l’équilibreur de charge de service dans votre système K8s. Votre équilibreur de charge doit prendre en charge les environnements confinés et la découverte de services. De plus, votre application doit être conçue pour la conteneurisation.
Chaque fournisseur de services cloud a sa propre implémentation d’équilibreur de charge – la plupart d’entre eux permettent un réglage fin en utilisant des annotations de service
Activer une sonde de préparation
Une sonde de préparation informe K8s si l’application est prête à servir le trafic ou non. Vous devez activer les sondes de préparation lorsqu’elles transmettent le trafic au pod. Pour ce faire, vous devez l’avoir défini dans l’un de vos déploiements K8s.
Si vous n’avez pas de sonde en place, l’utilisateur atteindra le pod mais n’obtiendra pas de réponse saine du serveur. En effet, le travail de la sonde de préparation consiste à signaler à Kubernetes quand placer un pod derrière l’équilibreur de charge et un service derrière le proxy.
Activer une sonde de vivacité
Une autre sonde clé que vous devez activer est une sonde de vivacité. Il permet à Kubernetes de savoir si un pod est suffisamment sain pour continuer à fonctionner ou s’il est préférable de le redémarrer. Il effectue une vérification simple ou complexe basée sur des commandes bash.
Cette sonde est là pour aider les K8 à déterminer si l’équilibrage de charge fonctionne bien ou si certains de ses composants nécessitent une assistance. Les sondes de vivacité augmentent la disponibilité même si votre application contient des bogues.
Appliquer la politique réseau
Pour protéger votre déploiement K8s, l’équilibreur de charge doit pouvoir appliquer des stratégies de groupe de sécurité aux machines virtuelles ou aux nœuds de travail.
Dans un scénario idéal, vous devez limiter le trafic entrant et sortant au minimum requis. Quel est l’avantage de placer une telle limitation? Il vous aide à prévenir l’exposition accidentelle de services indésirables au flux de trafic sortant.
Kubernetes est livré avec une fonctionnalité de politique de sécurité réseau capable de servir toutes les ressources dans les déploiements. Vous devez également vous assurer que votre cluster Kubernetes est provisionné avec un plug-in réseau qui prend en charge les stratégies réseau.
Activer les requêtes CPU/mémoire
De cette façon, les conteneurs pourront demander des ressources automatiquement. Cela permet de libérer les ressources CPU et mémoire dont le système a besoin….