Équilibreurs de charge d'application dans les clusters classiques

Lorsque vous créez un cluster classique, un équilibreur de charge d'application public et un équilibreur de charge d'application privé sont automatiquement créés pour vous dans chaque zone. Les équilibreurs de charge d'application publics et privés dans les clusters classiques se voient affecter une adresse IP statique qui ne change pas pour la durée de vie du cluster.

Les équilibreurs de charge d'application publics partagent le même sous-domaine Ingress IBMqui est enregistré pour vous lorsque vous mettez à disposition un cluster, et chaque adresse IP individuelle de l'équilibreur de charge d'application public est liée à ce sous-domaine. Pour trouver l'adresse IP d'un équilibreur de charge d'application public, exécutez ibmcloud ks ingress alb ls et vérifiez la zone Adresse IP de l'équilibreur de charge d'application dans la sortie.

Les équilibreurs de charge d'application privés dans les clusters classiques n'utilisent pas le sous-domaine Ingress fourni par IBMet ne sont pas activés automatiquement. Vous devez d'abord activer les équilibreurs de charge d'application privés dans l'interface de ligne de commande, puis spécifier la classe private-iks-k8s-nginx dans votre ressource Ingress. Une fois les équilibreurs de charge d'application privés activés, vous pouvez trouver les adresses IP privées en exécutant ibmcloud ks ingress alb ls et en vérifiant la zone ALB IP dans la sortie.

Si un pod d'équilibreur de charge d'application public ou privé est replanifié, il conserve la même adresse IP. Toutefois, le retrait d'une zone avec un équilibreur de charge d'application ou le retrait de tous les noeuds worker sur un réseau local virtuel dans cette zone entraîne le retrait de l'adresse IP de cet équilibreur de charge d'application.

Équilibreurs de charge d'application dans VPC

Lorsque vous créez un cluster VPC, un équilibreur de charge d'application public et un équilibreur de charge d'application privé sont automatiquement créés pour vous dans chaque zone. En outre, un équilibreur de charge VPC public est automatiquement créé en dehors de votre cluster dans votre VPC. Lorsque vous activez des équilibreurs de charge d'application privés dans votre cluster VPC, un équilibreur de charge VPC privé est également créé.

Les adresses IP des équilibreurs de charge d'application dans les clusters de VPC ne sont pas statiques et peuvent changer au fil du temps. Par conséquent, les équilibreurs de charge VPC placent l'adresse IP publique ou privée de vos équilibreurs de charge d'application derrière un nom d'hôte statique. Des noms d'hôte distincts sont appliqués pour les équilibreurs de charge d'application publics ou privés. Notez que le nom d'hôte de l'équilibreur de charge d'application est distinct du sous-domaine Ingress du cluster.

Pour trouver le nom d'hôte d'un équilibreur de charge d'application dans un cluster de VPC, exécutez ibmcloud ks ingress alb ls. Les noms d'hôte privés sont répertoriés uniquement si les équilibreurs de charge d'application privés sont activés.

Exigences de noeud worker pour les équilibreurs de charge d'application

Au moins deux noeuds worker sont requis par zone dans votre cluster pour que les équilibreurs de charge d'application puissent fonctionner avec la haute disponibilité et recevoir des mises à jour périodiques. Les règles d'anti-affinité sur les pods d'équilibreur de charge d'application garantissent qu'un seul pod est planifié sur chaque noeud worker. Lorsque des mises à jour automatiques sont appliquées aux pods ALB, le pod est rechargé. Si vous ne disposez que d'un seul noeud worker et donc d'un seul pod d'équilibreur de charge d'application, le pod n'est pas automatiquement mis à jour pour éviter les interruptions de trafic et les mises à jour s'appliquent uniquement lorsque vous supprimez manuellement le pod et que vous replanifiez un nouveau pod. Le fait d'avoir au moins deux noeuds worker par zone permet d'éviter ce scénario.

Notez que si une zone tombe en panne, vous risquez de rencontrer des défaillances intermittentes au niveau des requêtes adressées à l'ALB Ingress dans cette zone.