Types d'équilibreurs de charge

Le tableau ci-après décrit les caractéristiques de base de chaque option d'équilibrage de charge.

Equilibreur de charge d'application pour VPC

Configurez un équilibreur de charge d'application pour VPC multizone de couche 7 qui servira de point d'entrée externe pour les demandes entrantes vers une application dans votre cluster. Gardez les points suivants à l'esprit lorsque vous planifiez votre configuration VPC ALB.

Ne confondez pas les équilibreurs de charge d'application pour VPC avec les équilibreurs de charge d'application Ingress d'Red Hat OpenShift on IBM Cloud. Les équilibreurs de charge d'application pour VPC sont exécutés en dehors de votre cluster dans votre VPC et sont configurés par les services Kubernetes LoadBalancer que vous créez. Les équilibreurs de charge d'application Ingress sont des contrôleurs Ingress exécutés sur des noeuds worker dans votre cluster.

• Les noms des VPC ALB ont un format kube-<cluster_ID>-<kubernetes_lb_service_UID>. Pour afficher votre ID de cluster, exécutez ibmcloud oc cluster get --cluster <cluster_name>. Pour voir l'ID utilisateur du service Kubernetes LoadBalancer, exécutez la commande oc get svc myloadbalancer -o yaml et recherchez la zone metadata.uid dans la sortie. Les traits d'union (-) sont supprimés de l'UID du service Kubernetes LoadBalancer dans le nom du VPC ALB.

• Par défaut, lorsque vous créez un service Kubernetes LoadBalancer pour une application de votre cluster, un équilibreur de charge d'application pour VPC est créé dans votre VPC en dehors de votre cluster. L'équilibreur de charge d'application VPC achemine les demandes à votre application via les ports de noeud privés qui sont automatiquement ouverts sur vos noeuds worker.

• Si vous créez un service LoadBalancer Kubernetes public, vous pouvez accéder à votre application depuis l'internet via le nom d'hôte attribué par l'ALB de VPC au service Kubernetes LoadBalancer au format 1234abcd-<region>.lb.appdomain.cloud. Même si vos noeuds worker sont connectés uniquement à un sous-réseau VPC privé, l'équilibreur de charge d'application VPC peut recevoir et acheminer les demandes publiques au service qui expose votre application. Notez qu'aucune passerelle publique n'est requise sur votre sous-réseau VPC pour autoriser les demandes publiques adressées à votre équilibreur de charge d'application VPC. Toutefois, si votre application doit accéder à une URL publique, vous devez connecter des passerelles publiques aux sous-réseaux VPC auxquels vos noeuds worker sont connectés.

• Si vous créez un service privé Kubernetes LoadBalancer, votre application n'est accessible qu'aux systèmes connectés à vos sous-réseaux privés dans la même région et le même VPC. Si vous êtes connecté à votre réseau VPC privé, vous pouvez accéder à votre application via le nom d'hôte affecté par le VPC ALB au service Kubernetes LoadBalancer au format 1234abcd-<region>.lb.appdomain.cloud.

• Vous pouvez utiliser un VPC ALB existant sur un autre cluster en renommant le VPC ALB.

Le diagramme suivant illustre la manière dont un utilisateur accède à une application via Internet par l'intermédiaire de l'équilibreur de charge d'application VPC.

1. Une demande à votre application utilise le nom d'hôte affecté au service Kubernetes LoadBalancer par l'ALB de VPC, tel que 1234abcd-<region>.lb.appdomain.cloud.
2. La demande est automatiquement transmise par l'équilibreur de charge d'application VPC à l'un des ports de noeud du noeud worker, puis à l'adresse IP privée du pod d'application.
3. Si des instances d'application sont déployées sur plusieurs noeuds worker dans le cluster, l'équilibreur de charge achemine les demandes entre les pods d'application sur différents noeuds worker. De plus, si vous disposez d'un cluster multizone, l'équilibreur de charge d'application VPC achemine les demandes vers les noeuds worker sur tous les sous-réseaux et zones de votre cluster.

Equilibreur de charge de réseau de VPC

Dans les clusters VPC, configurez un layer-4 Network Load Balancer for VPC (VPC NLB) dans chaque zone de votre cluster pour servir de point d'entrée externe pour les requêtes entrantes vers une application.

Les équilibreurs de charge de réseau VPC offrent plusieurs avantages (par exemple, ils offrent un débit supérieur et de meilleures performances en exploitant DSR (Direct Server Return). Avec DSR, le noeud worker peut envoyer les paquets de réponses des applications directement à l'adresse IP du client et contourner l'équilibreur de charge de réseau VPC, pour diminuer le volume de trafic à traiter par l'équilibreur de charge de réseau VPC. En outre, vous pouvez configurer le VPC NLB pour inclure la préservation de l'adresse IP source sur toutes les requêtes des clients en incluant le externalTrafficPolicy: Local spécification.

• Les noms VPC NLB standard ont un format kube-<cluster_ID>-<kubernetes_lb_service_UID>. Pour afficher votre ID de cluster, exécutez ibmcloud oc cluster get --cluster <cluster_name>. Pour voir l'ID utilisateur du service Kubernetes LoadBalancer, exécutez la commande oc get svc myloadbalancer -o yaml et recherchez la zone metadata.uid dans la sortie. Les traits d'union (-) sont supprimés de l'UID du service Kubernetes LoadBalancer dans le nom du VPC NLB.

• Lorsque vous créez un service Kubernetes LoadBalancer pour une application dans votre cluster et incluez l'annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb", un équilibreur de charge de réseau VPC est créé dans votre VPC en dehors de votre cluster. L'équilibreur de charge de réseau VPC achemine les demandes à votre application via les ports de noeud privés qui sont automatiquement ouverts sur vos noeuds worker.

• Si vous créez un service public Kubernetes LoadBalancer, vous pouvez accéder à votre application depuis l'internet via l'adresse IP externe et publique attribuée par le VPC NLB au service Kubernetes LoadBalancer. Même si vos noeuds worker sont connectés uniquement à un sous-réseau VPC privé, l'équilibreur de charge de réseau VPC peut recevoir et acheminer les demandes publiques au service qui expose votre application. Notez qu'aucune passerelle publique n'est requise sur votre sous-réseau VPC pour autoriser les demandes publiques adressées à votre équilibreur de charge de réseau VPC. Toutefois, si votre application doit accéder à une URL publique, vous devez connecter des passerelles publiques aux sous-réseaux VPC auxquels vos noeuds worker sont connectés.

• Si vous créez un service privé Kubernetes LoadBalancer, votre application n'est accessible qu'aux systèmes connectés à vos sous-réseaux privés dans la même région et le même VPC. Si vous êtes connecté à votre réseau VPC privé, vous pouvez accéder à votre application par l'intermédiaire de l'adresse IP privée externe affectée par l'équilibreur de charge de réseau VPC au service Kubernetes LoadBalancer.

Le diagramme suivant illustre la manière dont un utilisateur accède à une application via Internet par l'intermédiaire de l'équilibreur de charge de réseau VPC.

1. Une demande adressée à votre application utilise l'adresse IP externe affectée au service Kubernetes LoadBalancer par l'équilibreur de charge de réseau VPC.
2. La demande est automatiquement transmise par l'équilibreur de charge de réseau VPC à l'un des ports de noeud du noeud worker, puis à l'adresse IP privée du pod d'application.
3. Si des instances d'applications sont déployées sur plusieurs nœuds de travail dans le cluster, le VPC NLB achemine les requêtes entre les pods d'applications sur les différents nœuds de travail à travers toutes les zones du cluster.

Limitations

Passez en revue les paramètres et limitations par défaut suivants.

• Consultez les limitations connues des équilibreurs de charge d'application VPC et les limitations connues des équilibreurs de charge de réseau VPC.
• Les ALB de VPC privé n'acceptent pas tout le trafic ; ils acceptent uniquement le trafic RFC 1918.
• Les NLB de VPC privés doivent être créés sur un sous-réseau VPC dédié qui doit exister dans le même VPC et dans le même emplacement que votre cluster, mais le sous-réseau ne peut pas être connecté à votre cluster ou à vos nœuds worker.
• Red Hat OpenShift: Bien que le Kubernetes protocole SCTP soit généralement disponible dans la 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.
• Un équilibreur de charge VPC est créé pour chaque service Kubernetes LoadBalancer que vous créez et il achemine les demandes uniquement vers ce service Kubernetes LoadBalancer. Dans tous vos clusters de VPC de votre VPC, vous pouvez créer jusqu'à 50 équilibreurs de charge de VPC. Pour plus d'informations, voir la documentation sur les quotas VPC.
• L'équilibreur de charge du VPC peut acheminer les demandes vers un nombre limité de nœuds de travail. Le nombre maximal de nœuds vers lesquels vous pouvez acheminer les demandes dépend de la manière dont vous avez défini l'annotation externalTrafficPolicy.
  • Si vous avez défini externalTrafficPolicy: Cluster dans votre configuration de l'équilibreur de charge :
    • L'équilibreur de charge VPC achemine les données vers les huit premiers nœuds de travail découverts dans chaque zone. Pour un cluster avec des nœuds de travail dans trois zones, cela signifie que l'équilibreur de charge achemine les données vers 24 nœuds de travail au total. Pour un cluster à zone unique, l'équilibreur de charge achemine les données vers 8 nœuds de travail au total. Vous pouvez modifier le nombre de nœuds de travail par zone vers lesquels l'équilibreur de charge se dirige à l'aide de l'option service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota, mais le nombre total pour toutes les zones ne peut pas dépasser 50. Si la grappe compte moins de 50 nœuds de travail dans toutes les zones, spécifiez 0 pour router vers tous les nœuds de travail d'une zone. La kube-proxy configure les tables IP pour acheminer le trafic entrant du nœud de travail vers le module d'application, quel que soit le nœud sur lequel le module d'application réside.
  • Si vous avez défini externalTrafficPolicy: Local dans votre configuration de l'équilibreur de charge, l'équilibreur de charge VPC n'est créé que s'il y a 50 nœuds de travail ou moins dans le cluster. Cette limite est fixée par les quotas VPC de 50 membres de pool par pool d'équilibreur de charge VPC. Pour éviter cette limitation, utilisez l'annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector pour limiter le nombre de nœuds de travail dans le pool de l'équilibreur de charge. Par exemple, vous pouvez utiliser cette annotation pour forcer le trafic entrant vers un pool de travailleurs spécifique. Si vous utilisez cette annotation pour forcer le trafic vers un pool de travailleurs spécifique, vous devez également vous assurer que le pod d'application s'exécute dans le même pool de travailleurs.
• Lorsque vous définissez le fichier YAML de configuration pour un service Kubernetes LoadBalancer, les annotations et paramètres ci-dessous ne sont pas pris en charge :
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>"
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "<algorithm>"
  • spec.loadBalancerIP
  • spec.loadBalancerSourceRanges
  • Equilibreurs de charge réseau VPC uniquement : service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"
  • Equilibreurs de charge d'application VPC uniquement : le paramètre externalTrafficPolicy: Local est pris en charge, mais il ne conserve pas l'adresse IP source de la demande.
• Lorsque vous supprimez un cluster VPC, tous les équilibreurs de charge VPC non persistants, qui sont nommés au format kube-<cluster_ID>-<kubernetes_lb_service_UID> et sont automatiquement créés par Red Hat OpenShift on IBM Cloud pour les services Kubernetes LoadBalancer dans ce cluster, sont également automatiquement supprimés. Cependant, les équilibreurs de charge persistants avec des noms uniques et les équilibreurs de charge VPC que vous avez créés manuellement dans votre VPC ne sont pas supprimés.
• Vous pouvez enregistrer jusqu'à 128 sous-domaines pour les noms d'hôte d'équilibreur de charge VPC. Cette limite peut être levée sur demande en ouvrant un cas de support.
• Les sous-domaines que vous enregistrez pour les équilibreurs de charge VPC sont limités à 130 caractères ou moins.
• Les ALB VPC écoutent sur les mêmes sous-réseaux VPC que les nœuds de travail du cluster, sauf si le service d'équilibreur de charge Kubernetes est créé avec les annotations service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets ou service.kubernetes.io/ibm-load-balancer-cloud-provider-zone, qui limitent le trafic à des nœuds spécifiques.
  • Les sous-réseaux et les zones de l'ALB VPC peuvent être mis à jour ou modifiés après la création de l'ALB. Si vous ajoutez d'autres zones au cluster ou mettez à jour le service d'équilibreur de charge Kubernetes avec les annotations service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets ou service.kubernetes.io/ibm-load-balancer-cloud-provider-zone, le VPC ALB est mis à jour pour écouter sur les nouveaux sous-réseaux.
• Les VPC NLB n'écoutent que sur un seul sous-réseau VPC dans une seule zone. Ils ne peuvent pas être configurés pour écouter sur plusieurs sous-réseaux VPC ou pour écouter sur plusieurs zones. Vous pouvez spécifier le sous-réseau unique sur lequel un NLB doit écouter avec les annotations service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets ou service.kubernetes.io/ibm-load-balancer-cloud-provider-zone.
  • Les VPC NLB transmettent le trafic entrant à tous les nœuds de travail de la grappe, sauf si vous limitez le trafic entrant à des nœuds de travail spécifiques à l'aide des options service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector ou service.kubernetes.io/ibm-load-balancer-cloud-provider-zone annotations. Pour limiter le trafic à une zone spécifique, vous pouvez utiliser ces annotations pour spécifier les nœuds de travail dans cette zone.
• La désactivation de l'allocation de noeud d'équilibrage de charge n'est pas prise en charge pour les équilibreurs de charge VPC.
• Les VPC NLB peuvent être configurés avec UDP et TCP sur le même VPC LB, mais le port d'écoute doit être différent.