Équilibrage de charge natif en conteneur

L'équilibrage de charge natif en conteneurs permet à plusieurs types d'équilibreurs de charge de cibler directement les pods et de répartir équitablement leur trafic dans les pods.

L'équilibrage de charge natif en conteneurs exploite un modèle de données appelé groupes de points de terminaison réseau (NEG, Network Endpoint Groups). Ces groupes sont des ensembles de points de terminaison réseau représentés par des paires adresse IP-port.

Lorsque des NEG sont utilisés avec une entrée GKE, le contrôleur d'entrée facilite la création de tous les aspects de l'équilibreur de charge L7. Cela inclut la création de l'adresse IP virtuelle, des règles de transfert, des vérifications d'état, des règles de pare-feu, etc.

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 L7.

Avantages

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 HTTP(S) et les pods. La latence entre l'équilibreur de charge HTTP(S) 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 offre une compatibilité native dans Google Kubernetes Engine avec plusieurs fonctionnalités d'équilibrage de charge HTTP(S), par exemple l'intégration avec 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.

Pour l'équilibrage de charge natif en conteneurs via un objet Ingress, les portes de disponibilité des pods sont automatiquement activées dans :

  • les clusters GKE v1.13 exécutant la version 1.13.8 ou ultérieure ;
  • les clusters GKE v1.14 exécutant la version 1.14.4 ou ultérieure.
  • les clusters v1.15 et versions ultérieures.

Les portes de disponibilité contrôlent la vitesse d'une mise à jour progressive. Les versions de GKE répertoriées ci-dessus ajoutent automatiquement des portes de disponibilité aux pods. 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. Ainsi, 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).

Exigences

Les équilibreurs de charge natifs en conteneurs via un objet Ingress sur GKE ont les exigences suivantes :

Google Kubernetes Engine v1.13.8 ou v1.14.4

Les équilibreurs de charge natifs en conteneurs sont en disponibilité générale dans :

  • les clusters GKE v1.13 exécutant la version 1.13.8 ou ultérieure ;
  • les clusters GKE v1.14 exécutant la version 1.14.4 ou ultérieure.
VPC natif

Pour utiliser l'équilibrage de charge natif en conteneurs, les clusters doivent être des clusters de VPC natif. Pour en savoir plus, consultez la page Créer des clusters de VPC natif à l'aide d'adresses IP d'alias.

Équilibrage de charge HTTP

Pour utiliser l'équilibrage de charge natif en conteneurs, l'équilibrage de charge HTTP doit être activé sur votre cluster. L'équilibrage de charge HTTP est activé par défaut sur les clusters GKE. Vous ne devez pas le désactiver.

Restrictions

Les équilibreurs de charge natifs en conteneurs ne fonctionnent pas avec les anciens réseaux.

Limites

Les équilibreurs de charge natifs en conteneurs ne sont pas compatibles avec les équilibreurs de charge TCP/UDP internes, ni avec les équilibreurs de charge réseau.

Tarifs

L'équilibreur de charge HTTP(S) configuré 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.

Étape suivante