Équilibrage de charge natif en conteneur

Cette page explique ce qu'est l'équilibrage de charge natif en conteneurs dans Google Kubernetes Engine (GKE). L'équilibrage de charge natif en conteneurs permet à plusieurs types d'équilibreurs de charge de cibler directement les pods et de répartir équitablement le trafic dans les pods.

Architecture d'équilibrage de charge natif en conteneurs

L'équilibrage de charge natif en conteneurs utilise des groupes de points de terminaison du réseau (NEG) GCE_VM_IP_PORT. Les points de terminaison du NEG sont des adresses IP de pods.

L'équilibrage de charge natif en conteneurs est utilisé systématiquement pour les entrées GKE internes, et est facultatif pour l'entrée externe. Le contrôleur Ingress crée l'équilibreur de charge, y compris l'adresse IP virtuelle, les règles de transfert, les vérifications d'état et les règles de pare-feu.

Pour apprendre à utiliser l'équilibrage de charge natif en conteneurs avec Ingress, consultez la page Équilibrage de charge natif en conteneurs via Ingress.

Pour plus de flexibilité, vous pouvez également créer des NEG autonomes. Dans ce cas, vous êtes responsable de la création et de la gestion de tous les aspects de l'équilibreur de charge.

Avantages de l'équilibrage de charge natif en conteneurs

L'équilibrage de charge natif en conteneurs offre les avantages suivants :

Les pods sont des objets essentiels pour l'équilibrage de charge
kube-proxy configure les règles iptables des nœuds pour répartir le trafic à destination des pods. En l'absence de l'équilibrage de charge natif en conteneurs, le trafic de l'équilibreur de charge est transféré vers les groupes d'instances de nœuds, puis acheminé via des règles iptables vers des pods se trouvant ou non dans le même nœud. L'équilibrage de charge natif en conteneurs permet d'éviter ce saut de réseau supplémentaire en distribuant directement le trafic de l'équilibreur de charge aux pods censés recevoir le trafic. L'équilibrage de charge natif en conteneurs contribue également à améliorer la vérification de l'état dans la mesure où il cible directement les pods.

Comparaison d'un comportement par défaut (à gauche) et d'un comportement de l'équilibreur de charge natif en conteneurs
Amélioration des performances du réseau
Étant donné que l'équilibreur de charge natif en conteneurs communique directement avec les pods et réduit le nombre de sauts de réseau dans les connexions, la latence et le débit s'en trouvent améliorés
.
Visibilité accrue
Avec l'équilibrage de charge natif en conteneurs, vous bénéficiez d'une visibilité sur la latence entre l'équilibreur de charge d'application et les pods. La latence entre l'équilibreur de charge d'application et chaque pod est visible, et agrégée avec l'équilibrage de charge natif en conteneurs basé sur les adresses IP du nœud. Cela facilite le dépannage de vos services au niveau des NEG.
Compatibilité avec les fonctionnalités avancées d'équilibrage de charge
L'équilibrage de charge natif en conteneurs dans GKE est compatible avec plusieurs fonctionnalités des équilibreurs de charge d'application externes, telles que l'intégration à des services Google Cloud tels que Google Cloud Armor, Cloud CDN et Identity-Aware Proxy. Il comporte également des algorithmes d'équilibrage de charge pour une répartition précise du trafic.
Compatibilité avec Traffic Director
Le modèle de données NEG est requis pour utiliser Traffic Director, le plan de contrôle de trafic entièrement géré de Google Cloud pour le maillage de services.

Disponibilité des pods

Pour les pods concernés, le contrôleur d'entrée correspondant gère une porte de disponibilité de type cloud.google.com/load-balancer-neg-ready. Le contrôleur d'entrée envoie des demandes de vérification de l'état de l'équilibreur de charge incluant des demandes relatives à l'état de tous les points de terminaison appartenant au NEG. Lorsque l'état de l'équilibreur de charge indique que le point de terminaison correspondant à un pod particulier est opérationnel, le contrôleur d'entrée définit la valeur de la porte de disponibilité de ce pod sur True. Le kubelet exécuté sur chaque nœud calcule alors la disponibilité réelle du pod en tenant compte à la fois de cette valeur de porte de disponibilité et de la valeur de vérification de la préparation ("readiness probe") du pod, si celle-ci est définie.

Les portes de disponibilité des pods sont automatiquement activées lorsque vous utilisez l'équilibrage de charge natif en conteneurs via Ingress.

Les portes de disponibilité contrôlent la vitesse d'une mise à jour progressive. Lorsque vous lancez une mise à jour progressive, la création de chaque nouveau pod par GKE conduit à l'ajout d'un point de terminaison associé dans un NEG. Lorsque le point de terminaison est sain du point de vue de l'équilibreur de charge, le contrôleur d'entrée définit la porte de disponibilité sur True. Un pod nouvellement créé doit a minima passer sa porte de disponibilité avant que GKE ne supprime un ancien pod. Cela garantit que le point de terminaison correspondant au pod a déjà réussi la vérification d'état réalisée par l'équilibreur de charge et que la capacité de backend est maintenue.

Si la porte de disponibilité d'un pod n'indique jamais que le pod est prêt, par exemple en raison d'une image de conteneur incorrecte ou d'une vérification d'état mal configurée au niveau de l'équilibreur de charge, l'équilibreur de charge ne dirige aucun trafic vers le nouveau pod. Si un tel échec se produit lors du déploiement d'une mise à jour, le déploiement est bloqué après la tentative de création d'un nouveau pod car la porte de disponibilité de ce pod n'atteint jamais la valeur True. Pour plus d'informations sur la détection et la résolution d'une telle situation, consultez la section de dépannage.

Sans l'équilibrage de charge natif en conteneurs et sans portes de préparation, GKE ne peut pas détecter si les points de terminaison d'un équilibreur de charge sont opérationnels avant d'identifier les pods comme étant prêts. Dans les versions précédentes de Kubernetes, vous contrôliez la vitesse de suppression et de remplacement des pods en spécifiant un délai (minReadySeconds dans les spécifications de déploiement).

GKE définit la valeur de cloud.google.com/load-balancer-neg-ready pour un pod sur True si l'une des conditions suivantes est remplie :

  • Aucune des adresses IP du pod n'est un point de terminaison dans un NEG GCE_VM_IP_PORT géré par le plan de contrôle GKE.
  • Une ou plusieurs des adresses IP du pod sont des points de terminaison dans un NEG GCE_VM_IP_PORT géré par le plan de contrôle GKE. Le NEG est associé à un service de backend. La vérification de l'état de l'équilibreur de charge pour le service de backend est concluante.
  • Une ou plusieurs des adresses IP du pod sont des points de terminaison dans un NEG GCE_VM_IP_PORT géré par le plan de contrôle GKE. Le NEG est associé à un service de backend. La vérification de l'état de l'équilibreur de charge pour le service de backend se termine par un dépassement de délai.
  • Une ou plusieurs des adresses IP du pod sont des points de terminaison dans un ou plusieurs NEG GCE_VM_IP_PORT. Aucun des NEG n'est associé à un service de backend. Aucune donnée de vérification d'état de l'équilibreur de charge n'est disponible.

Affinité de session

L'équilibrage de charge natif en conteneurs est compatible avec l'affinité de session basée sur un pod.

Conditions requises pour utiliser l'équilibrage de charge natif en conteneurs

Les équilibreurs de charge natifs en conteneurs via Ingress sur GKE sont soumis aux exigences suivantes :

  • Le cluster doit être VPC natif.
  • Le module complémentaire HttpLoadBalancing doit être activé sur le cluster. Le module complémentaire HttpLoadBalancing est activé par défaut sur les clusters GKE ; vous ne devez pas le désactiver.

Limites pour les équilibreurs de charge natifs en conteneurs

Les équilibreurs de charge natifs en conteneurs via Ingress sur GKE sont soumis aux exigences suivantes :

  • Non compatibles avec les équilibreurs de charge réseau externes.
  • Vous ne devez pas modifier ni mettre à jour manuellement la configuration de l'équilibreur de charge d'application créé par GKE. Toutes les modifications que vous apportez sont remplacées par GKE.

Tarifs des équilibreurs de charge natifs en conteneurs

L'équilibreur de charge d'application provisionné par l'entrée que vous créez dans ce guide vous est facturé. Pour obtenir des informations sur les tarifs de l'équilibreur de charge, consultez la section Équilibrage de charge et règles de transfert sur la page des tarifs du VPC.

Étapes suivantes