IBM Cloud Docs
Classique : A propos des équilibreurs de charge de réseau (NLB)

Classique : A propos des équilibreurs de charge de réseau (NLB)

Les équilibreurs de charge réseau ne peuvent être créés que dans des clusters classiques. Pour effectuer un équilibrage de charge dans des clusters de VPC, voir Exposition d'applications avec des équilibreurs de charge pour VPC.

Lorsque vous créez un cluster standard, un sous-réseau public portable et un sous-réseau privé portable sont fournis automatiquement par Red Hat® OpenShift® on IBM Cloud®.

  • Le sous-réseau public portable fournit 5 adresses IP utilisables. 1 adresse IP publique portable est utilisée par l'ALB d'entrée public par défaut. Les 4 autres adresses IP publiques portables peuvent être utilisées pour exposer des applications individuelles sur Internet en créant des services d'équilibreur de charge de réseau (NLB) publics.
  • Le sous-réseau privé portable fournit 5 adresses IP utilisables. 1 adresse IP privée portable est utilisée par l'ALB d'entrée privée par défaut. Les 4 autres adresses IP privées portables peuvent être utilisées pour exposer des applications individuelles sur un réseau privé en créant des services d'équilibreur de charge privés, ou des équilibreurs de charge de réseau.

Pour rendre une application accessible via une adresse IP publique portable et une adresse IP privée portable, vous devez créer un équilibreur de charge de réseau public et un équilibreur de charge de réseau privé. Les adresses IP publiques et privées portables sont des adresses IP flottantes statiques et ne changent pas lorsqu'un nœud worker est supprimé. Si le nœud de travail sur lequel se trouve l'adresse IP NLB est supprimé, un démon Keepalive qui surveille constamment l'IP déplace automatiquement l'IP vers un autre nœud de travail. Vous pouvez affecter n'importe quel port à votre équilibreur de charge de réseau. L'équilibreur de charge de réseau fait office de point d'entrée externe des demandes entrantes pour l'application. Pour accéder au NLB à partir d'Internet, vous pouvez utiliser l'adresse IP publique de votre NLB et le port affecté au format <IP_address>:<port>. Vous pouvez également créer des entrées DNS pour des équilibreurs de charge de réseau en enregistrant les adresses IP d'équilibreur de charge de réseau avec des sous-domaines.

Lorsque vous exposez une application avec un service d'équilibreur de charge de réseau, elle est également automatiquement mise à disposition sur les ports de noeud (NodePort) du service. Les ports de noeud sont accessibles sur toutes les adresses IP publiques et privées de tous les noeuds worker figurant dans le cluster. Pour bloquer le trafic vers les ports de noeud lorsque vous utilisez un service d'équilibreur de charge de réseau, voir Contrôle du trafic entrant vers les services d'équilibreur de charge de réseau ou NodePort.

Bien que le protocole SCTP Kubernetes soit généralement disponible dans l'édition de la communauté Kubernetes, la création d'équilibreurs de charge qui utilisent ce protocole n'est pas prise en charge dans les clusters IBM Cloud Kubernetes Service.

Comparaison de l'équilibrage de charge de base et DSR dans les équilibreurs de charge de réseau versions 1.0 et 2.0

Lorsque vous créez un équilibreur de charge de réseau, vous pouvez choisir un équilibreur de charge de réseau version 1.0, qui effectue l'équilibrage de charge de base, ou un équilibreur de charge de réseau version 2.0, qui effectue l'équilibrage de charge DSR (Direct Server Return).

En quoi les versions 1.0 et 2.0 NLBs sont-elles similaires?
Les équilibreurs de charge de réseau 1.0 et 2.0 sont des équilibreurs de charge de couche 4 qui existent dans l'espace du noyau Linux. Ces deux versions s'exécutent dans le cluster et utilisent des ressources de noeud worker. Par conséquent, la capacité disponible des équilibreurs de charge de réseau est toujours dédiée à votre propre cluster. En outre, les deux versions de NLB ne mettent pas fin à la connexion. Les connexions sont transférées à un pod d'application à la place.
En quoi les versions 1.0 et 2.0 NLBs sont-elles différentes?
Lorsqu'un client envoie une demande à votre application, l'équilibreur de charge de réseau achemine des paquets de demandes à l'adresse IP du noeud worker où il existe un pod d'application. Les équilibreurs de charge de réseau 1.0 utilisent une conversion d'adresses réseau (NAT) pour réécrire l'adresse IP source du paquet de demandes sur l'adresse IP du noeud worker où il existe un pod d'équilibreur de charge. Lorsque le noeud worker renvoie un paquet de réponses d'application, il utilise l'adresse IP du noeud worker où se trouve l'équilibreur de charge de réseau. L'équilibreur de charge de réseau doit ensuite envoyer le paquet de réponses au client. Pour empêcher la réécriture de l'adresse IP, vous pouvez activer la conservation de l'adresse IP source. Cependant, la conservation de l'adresse IP source nécessite que les pods d'équilibreur de charge et les pods d'application s'exécutent sur le même noeud worker pour éviter d'avoir à transférer la demande vers un autre noeud worker. Vous devez ajouter des propriétés d'affinité de noeud et de tolérance aux pods d'application. Pour plus d'informations sur l'équilibrage de charge de base avec des équilibreurs de charge de réseau version 1.0, voir Composants et architecture d'un équilibreur de charge de réseau 1.0.

Contrairement aux équilibreurs de charge de réseau 1.0, les équilibreurs de charge de réseau 2.0 n'utilisent pas la conversion NAT lors du transfert des demandes aux pods d'application sur d'autres noeuds worker. Lorsqu'un équilibreur de charge de réseau 2.0 achemine une demande client, il utilise un tunnel IP sur IP (IPIP) pour encapsuler le paquet de demandes d'origine dans un autre paquet. Ce paquet comporte une adresse IP source du noeud worker dans lequel se trouve le pod d'équilibreur de charge, ce qui permet au paquet de demandes d'origine de conserver l'adresse IP du client comme adresse IP source. Le noeud worker utilise ensuite le mode DSR (Direct Server Return) pour envoyer le paquet de réponses de l'application à l'adresse IP du client. Le paquet de réponses ignore l'équilibreur de charge de réseau et est envoyé directement au client, réduisant ainsi la quantité de trafic que l'équilibreur de charge de réseau doit traiter. Pour plus d'informations sur l'équilibrage de charge DSR avec des équilibreurs de charge de réseau version 2.0, voir Composants et architecture d'un équilibreur de charge de réseau 2.0.

Composants et architecture d'un équilibreur de charge de réseau 1.0

L'équilibreur de charge de réseau 1.0 TCP/UDP utilise Iptables, une fonction du noyau Linux, pour équilibrer la charge des demandes sur les pods d'une application.

Flux de circulation dans un cluster à zone unique

Le diagramme suivant montre comment un équilibreur de charge de réseau 1.0 dirige la communication d'Internet vers une application dans un cluster à zone unique.

Exposez une application dans un cluster à zone unique en utilisant un NLB ( 1.0 ).
Expose an app in a single-zone cluster by using an NLB 1.0

  1. Une demande adressée à votre application utilise l'adresse IP publique de votre équilibreur de charge de réseau et le port affecté sur le noeud worker. Notez que si vous créez un sous-domaine DNS pour votre équilibreur de charge de réseau, les utilisateurs peuvent accéder à votre application via le sous-domaine de l'équilibreur de charge de réseau à la place. Un service système DNS résout le sous-domaine avec l'adresse IP publique portable de l'équilibreur de charge de réseau.

  2. L'équilibreur de charge de réseau reçoit la demande et la transmet à l'adresse IP privée du pod d'application via le réseau privé. L'adresse IP source du package de demande est remplacée par l'adresse IP publique du noeud worker sur lequel s'exécute le pod d'équilibreur de charge de réseau. Si plusieurs instances d'application sont déployées dans le cluster, l'équilibreur de charge de réseau achemine les demandes entre les pods d'application.

  3. Lorsque l'application renvoie un paquet de réponses, elle utilise l'adresse IP du noeud worker où se trouve l'équilibreur de charge de réseau qui a transmis la demande du client. L'équilibreur de charge de réseau envoie ensuite le paquet de réponses au client.

Flux de circulation dans un cluster multizone

Le diagramme suivant montre comment un équilibreur de charge de réseau 1.0 dirige la communication d'Internet vers une application dans un cluster multizone.

Utiliser un NLB 1.0 pour équilibrer la charge des applications dans un cluster
un NLB 1.0 pour équilibrer la charge des applications dans un
multizone*

  1. Une demande adressée à votre application utilise le sous-domaine DNS pour vos équilibreurs de charge de réseau. Vous pouvez également accéder à l'équilibreur de charge de réseau dans chaque zone en utilisant son adresse IP publique et son port sur le noeud worker. Notez que par défaut, chaque équilibreur de charge de réseau 1.0 est configuré dans une seule zone. Pour assurer la haute disponibilité, vous devez déployer un équilibreur de charge de réseau 1.0 dans toutes les zones où se trouvent vos instances d'application.

  2. Un service système DNS résout le sous-domaine avec l'adresse IP publique portable de l'un des équilibreurs de charge de réseau et le port qui lui a été affecté sur le noeud worker. Les demandes sont traitées par les équilibreurs de charge de réseau dans les différentes zones à tour de rôle.

  3. L'équilibreur de charge de réseau reçoit la demande et la transmet à l'adresse IP privée du pod d'application via le réseau privé. L'adresse IP source du package de demande est remplacée par l'adresse IP publique du noeud worker sur lequel s'exécute le pod d'équilibreur de charge de réseau. Chaque équilibreur de charge de réseau route les demandes vers les instances d'application au sein de sa propre zone et vers les instances d'application situées dans d'autres zones. De plus, si plusieurs instances d'application sont déployées dans une zone, l'équilibreur de charge de réseau route les demandes entre les pods d'application dans la zone.

  4. Lorsque l'application renvoie un paquet de réponses, elle utilise l'adresse IP du noeud worker où se trouve l'équilibreur de charge de réseau qui a transmis la demande du client. L'équilibreur de charge de réseau envoie ensuite le paquet de réponses au client.

Composants et architecture d'un équilibreur de charge de réseau 2.0

L'équilibreur de charge de réseau 2.0 est un équilibreur de charge de couche 4 qui utilise le serveur IPVS (IP Virtual Server) du noyau Linux. Il prend en charge les protocoles TCP et UDP, s'exécute devant plusieurs noeuds worker et utilise un tunnel IP sur IP (IPIP) pour distribuer le trafic qui arrive sur une adresse IP d'équilibreur de charge de réseau unique sur ces noeuds worker.

Flux de circulation dans un cluster à zone unique

Le diagramme suivant montre comment un équilibreur de charge de réseau 2.0 dirige la communication d'Internet vers une application dans un cluster à zone unique.

Exposer une application dans Red Hat OpenShift on IBM Cloud en utilisant une version 2.0
une application dans Red Hat OpenShift on IBM Cloud en utilisant une version 2.0

  1. Une demande client adressée à votre application utilise l'adresse IP publique de votre équilibreur de charge de réseau et le port affecté sur le noeud worker. Dans cet exemple, l'équilibreur de charge de réseau a l'adresse IP virtuelle 169.61.23.130 et s'exécute sur le noeud worker dont l'adresse IP privée est 10.73.13.25. Notez que si vous créez un sous-domaine DNS pour votre équilibreur de charge de réseau, les utilisateurs peuvent accéder à votre application via le sous-domaine de l'équilibreur de charge de réseau à la place. Un service système DNS résout le sous-domaine avec l'adresse IP publique portable de l'équilibreur de charge de réseau.

  2. L'équilibreur de charge de réseau encapsule le paquet de demandes du client (labellisé "CR" dans l'image) dans un paquet IPIP (labellisé "IPIP"). Le paquet de demandes du client conserve l'adresse IP du client comme adresse IP source. Le paquet d'encapsulation IPIP utilise l'adresse IP 10.73.14.25 du noeud worker comme adresse IP source.

  3. L'équilibreur de charge de réseau achemine le paquet IPIP vers un noeud worker dans lequel réside un pod d'application et dont l'adresse IP privée est 10.73.13.26. Si plusieurs instances d'application sont déployées dans le cluster, l'équilibreur de charge de réseau achemine les demandes entre les noeuds worker dans lesquels sont déployés les pods d'application.

  4. Le noeud worker 10.73.14.26 décompresse le paquet d'encapsulation IPIP, puis décompresse le paquet de demandes du client. Le paquet de demandes du client est transféré au pod d'application sur ce noeud worker.

  5. Le noeud worker 10.73.14.26 utilise ensuite l'adresse IP source du paquet de demandes d'origine, l'adresse IP du client, pour renvoyer le paquet de réponses du pod d'application directement au client.

Flux de circulation dans un cluster multizone

Le diagramme suivant montre comment les équilibreurs de charge de réseau 2.0 de chaque zone dirigent le trafic d'Internet vers une application dans un cluster multizone.

Expose an app in Red Hat OpenShift on IBM Cloud by using an NLB 2.0
Expose an app in Red Hat OpenShift on IBM Cloud by using an NLB 2.0

  1. Une demande adressée à votre application utilise le sous-domaine DNS pour vos équilibreurs de charge de réseau. Vous pouvez également accéder à l'équilibreur de charge de réseau dans chaque zone en utilisant son adresse IP publique et son port sur le noeud worker. Notez que par défaut, chaque équilibreur de charge de réseau 2.0 est configuré dans une seule zone. Pour assurer la haute disponibilité, vous devez déployer un équilibreur de charge de réseau 2.0 dans toutes les zones où se trouvent vos instances d'application.

  2. Un service système DNS résout le sous-domaine avec l'adresse IP publique portable de l'un des équilibreurs de charge de réseau et le port qui lui a été affecté sur le noeud worker. Dans cet exemple, l'équilibreur de charge de réseau a l'adresse IP virtuelle 169.61.23.130 et s'exécute sur le noeud worker dont l'adresse IP privée est 10.73.13.25. Les demandes sont traitées par les équilibreurs de charge de réseau dans les différentes zones à tour de rôle.

  3. L'équilibreur de charge de réseau encapsule le paquet de demandes du client (labellisé "CR" dans l'image) dans un paquet IPIP (labellisé "IPIP"). Le paquet de demandes du client conserve l'adresse IP du client comme adresse IP source. Le paquet d'encapsulation IPIP utilise l'adresse IP 10.73.14.25 du noeud worker comme adresse IP source.

  4. L'équilibreur de charge de réseau achemine le paquet IPIP vers un noeud worker dans lequel réside un pod d'application et dont l'adresse IP privée est 10.73.13.26. De plus, chaque équilibreur de charge de réseau route les demandes vers les instances d'application au sein de sa propre zone et vers les instances d'application situées dans d'autres zones. De plus, si plusieurs instances d'application sont déployées dans une zone, l'équilibreur de charge de réseau route les demandes entre les pods d'application dans la zone.

  5. Le noeud worker 10.73.14.26 décompresse le paquet d'encapsulation IPIP, puis décompresse le paquet de demandes du client. Le paquet de demandes du client est transféré au pod d'application sur ce noeud worker.

  6. Le noeud worker 10.73.14.26 utilise ensuite l'adresse IP source du paquet de demandes d'origine, l'adresse IP du client, pour renvoyer le paquet de réponses du pod d'application directement au client.