Gestion des équilibreurs de charge VPC

Apportez des modifications à vos équilibreurs de charge VPC existants.

Ne renommez pas les VPC NLB ou ALB. Le changement de nom d'un équilibreur de charge VPC génère une erreur pour le service LoadBalancer Kubernetes, ce qui peut perturber votre charge de travail.

Équilibreurs de charge VPC persistants

Par défaut, les équilibreurs de charge VPC sont supprimés lorsque le cluster auquel ils sont associés est supprimé. Cependant, lorsque vous créez une définition de service LoadBalancer, vous pouvez rendre votre équilibreur de charge persistant afin qu'il reste disponible même après la suppression de votre cluster. Un équilibreur de charge VPC persistant peut être appliqué à un autre cluster après la suppression du cluster précédent.

Les noms des équilibreurs de charge VPC sont formatés par défaut comme kube-<cluster_ID>-<kubernetes_lb_service_UID>. Lorsqu'un cluster est supprimé, ce format de nom spécifie les équilibreurs de charge associés qui sont également supprimés. Pour vous assurer que votre équilibreur de charge n'est pas supprimé lorsque vous supprimez un cluster, incluez l'annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name dans votre définition de service LoadBalancer pour donner un nom unique à votre équilibreur de charge. Le nom de l'équilibreur de charge doit être unique au sein de votre VPC et ne peut comprendre que des caractères alphanumériques minuscules et des traits d'union (-). L'annotation peut être appliquée à tous les types d'équilibreurs de charge du VPC.

Vous êtes responsable de la suppression des équilibreurs de charge VPC persistants lorsqu'ils ne sont plus nécessaires. Pour supprimer un équilibreur de charge VPC persistant, supprimez la définition de service Kubernetes LoadBalancer à laquelle l'équilibreur de charge VPC est associé.

Déplacer un équilibreur de charge VPC d'un cluster à un autre

Équilibreurs de charge VPC persistants peut être détaché d'un cluster VPC puis rattaché à un autre. Le nouveau cluster doit se trouver dans le même VPC que le cluster d'origine.

Détacher un équilibreur de charge VPC d'un cluster

Les équilibreurs de charge VPC sont liés à la Kubernetes LoadBalancer définition de service avec laquelle ils ont été créés. Pour détacher un équilibreur de charge VPC persistant d'un cluster, vous devez rompre le lien avec le service LoadBalancer. Ce faisant, le service LoadBalancer devient inutilisable et peut être supprimé en toute sécurité. L'équilibreur de charge VPC peut alors être attaché à un autre cluster.

Pour rompre le lien entre l'équilibreur de charge VPC et le service LoadBalancer, vous pouvez soit renommer l'équilibreur de charge VPC, soit supprimer l'annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name de la définition de service originale LoadBalancer. Notez qu'il s'agit de la seule circonstance dans laquelle vous devez renommer un équilibreur de charge VPC, car cela crée une erreur pour la ressource Kubernetes. Toutefois, si votre objectif final est d'utiliser l'équilibreur de charge VPC sur un autre cluster, cette erreur ne perturbe pas votre charge de travail. Ne renommez pas l'équilibreur de charge VPC si vous souhaitez le conserver sur le même cluster.

Attacher un équilibreur de charge VPC à un cluster

Une fois qu’un équilibreur de charge VPC persistant a été détaché d’un cluster, vous pouvez l’attacher à un autre cluster en créant une nouvelle définition de service LoadBalancer Kubernetes qui fait référence à cet équilibreur de charge VPC.

Lorsque vous créez un nouveau service LoadBalancer sur le nouveau cluster, vous pouvez utiliser l'annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name pour spécifier le nom de l'équilibreur de charge VPC que vous souhaitez attacher.

Lorsque vous créez le service LoadBalancer, le type d'équilibreur de charge VPC (ALB, NLB) et le type d'IP (public, privé) doivent correspondre aux spécifications du service LoadBalancer. Par exemple, un service LoadBalancer existant sur le nouveau cluster qui spécifie un type NLB ne peut pas être utilisé pour attacher un VPC ALB au cluster. Les annotations qui spécifient le type d'équilibreur de charge et le type d'IP sont service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features et service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type.

Le port et les ports de nœuds spécifiés dans le service LoadBalancer ne doivent pas nécessairement correspondre à ceux avec lesquels l'équilibreur de charge VPC a été créé. L'équilibreur de charge VPC se reconfigure avec les définitions de port du service LoadBalancer auquel il est associé dans le nouveau cluster.

Contrôles d'intégrité pour les équilibreurs de charge

Les équilibreurs de charge VPC sont automatiquement configurés avec des contrôles de santé, que vous configurez avec l'annotation externalTrafficPolicy. Vous pouvez utiliser des annotations supplémentaires pour personnaliser les contrôles de santé sur vos équilibreurs de charge.

Si externalTrafficPolicyest défini surCluster, les contrôles d'intégrité TCP sont appliqués. Si vous configurez un équilibreur de charge UDP, vous devez effectuer des spécifications de port supplémentaires.
Si externalTrafficPolicyest défini surLocal, des vérifications d'intégrité HTTP sont appliquées. Le trafic entrant n'est acheminé que vers le module d'application résidant sur ce nœud spécifique. S'il n'y a pas de pod d'application sur ce nœud spécifique, le trafic entrant est abandonné.

Le paramètre externalTrafficPolicy: Local peut entraîner l'échec des contrôles de santé sur les nœuds de travail de l'équilibreur de charge. En général, ce résultat correspond au comportement attendu et n'indique pas nécessairement un problème, car le trafic est intentionnellement interrompu si l'équilibreur de charge tente de se connecter à un nœud qui n'a pas de module d'application. Pour plus d'informations, voir Pourquoi les contrôles de santé de l'équilibreur de charge VPC échouent-ils sur mes nœuds de travail?.

Personnalisation des contrôles de santé pour les équilibreurs de charge VPC

Pour mieux contrôler les contrôles de santé de votre équilibreur de charge VPC, vous pouvez utiliser des annotations optionnelles pour personnaliser vos contrôles de santé avec des configurations avancées pour les intervalles de test, les délais d'attente et les tentatives. Vous pouvez modifier ou supprimer ces personnalisations à tout moment.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol

Optionnel: cette annotation définit le protocole de contrôle de santé sur la ressource d'équilibreur de charge VPC associée au service d'équilibreur de charge Kubernetes. Normalement, le protocole de contrôle de santé VPC LB est déterminé par la valeur du paramètre externalTrafficPolicy dans la spécification du service d'équilibreur de charge Kubernetes. Cette annotation ne tient pas compte de cette logique. Cette annotation ne not modifie pas la façon dont Kubernetes, et kube-proxy en particulier, se comporte par rapport aux différents paramètres de externalTrafficPolicy.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port

Facultatif. Le port TCP utilisé pour les contrôles d'intégrité. Cette annotation ne s'applique que si ibm-load-balancer-cloud-provider-vpc-health-check-protocol est également spécifié.

Si le port TCP spécifié se trouve en dehors de la plage de ports des nœuds Kubernetes (30 000-32 767), le groupe de sécurité VPC appliqué aux nœuds de travail du cluster doit être modifié afin d'autoriser le trafic entrant sur ce port.
Si cette annotation est appliquée à un service de répartition de charge Kubernetes associé à un VPC ALB, les règles sortantes du groupe de sécurité attribué au VPC ALB doivent être modifiées afin d’autoriser le trafic sortant vers le port TCP spécifié.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path

Facultatif. Le chemin d'accès de vérification de l'état de santé ( URL ) pour les vérifications de l'état de santé HTTPs et HTTP. Cette annotation ne s'applique que si ibm-load-balancer-cloud-provider-vpc-health-check-protocol est défini comme http ou https.

Le chemin d' URL s doit être au format d' une requête de type « origin-form-request ».
Si cette annotation n'est pas spécifiée et que l'annotation ibm-load-balancer-cloud-provider-vpc-health-check-protocol est définie comme http ou https, la valeur par défaut / est appliquée.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay

Facultatif. Nombre de secondes d'attente entre les tentatives de contrôle de l'état de santé. Par défaut, cette valeur est fixée à 5, avec un minimum de 2 et un maximum de 60. Cette valeur doit être supérieure à la valeur ibm-load-balancer-cloud-provider-vpc-health-check-timeout, qui est fixée par défaut à 2.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout

Facultatif. Nombre de secondes d'attente pour une réponse à un contrôle de santé. Par défaut, cette valeur est fixée à 2, avec un minimum de 1 et un maximum de 59. Cette valeur doit être inférieure à la valeur ibm-load-balancer-cloud-provider-vpc-health-check-delay, qui est fixée par défaut à 5.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries

Nombre maximal de tentatives de contrôle de santé pour l'équilibreur de charge VPC. Par défaut, cette valeur est fixée à 2, avec un minimum de 1 et un maximum de 10.

Activation des contrôles d'intégrité TCP pour les équilibreurs de charge UDP

Étant donné qu'aucun contrôle d'intégrité UDP n'est effectué, les équilibreurs de charge UDP qui utilisent les contrôles d'intégrité TCP doivent avoir un port TCP supplémentaire spécifié avec l'annotationservice.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp.

Vous pouvez spécifier le port du nœud TCP pour un autre équilibreur de charge ou NodePort en cours d'exécution dans votre cluster. Pour les versions 4.14 et antérieures du cluster, si le port du nœud se trouve en dehors de la 30000-32767 plage, vous devez modifier le groupe de sécurité du cluster VPC kube-<cluster-ID> afin d’autoriser le trafic entrant vers le port spécifié.

Notez que si la valeur de port spécifiée concerne un service qui tombe en panne de manière inattendue ou dont la valeur de port est reconfigurée, les contrôles d'intégrité d' TCP cessent de fonctionner jusqu'à ce que le service soit de nouveau opérationnel ou que vous reconfiguriez l'annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp avec une nouvelle valeur de port TCP. Pour éviter cela, vous pouvez spécifier le portkubelet``10250, qui est une valeur de port statique qui permet de ne pas rencontrer d'interruptions de service. Toutefois, pour les versions de cluster 4.14 et antérieures, vous devez modifier le groupe de sécurité du cluster VPC kube-<cluster-ID> afin d'accepter le trafic entrant provenant de ce port kubelet.

Vous souhaitez éviter la complexité liée à la configuration de ports d' TCP s supplémentaires pour les contrôles d'intégrité dans un équilibreur de charge UDP? Définissez externalTrafficPolicysur Localpour utiliser les vérifications d'intégrité HTTP, qui ne nécessitent aucune spécification de port supplémentaire.

Modifier le sous-réseau ou la zone d'un équilibreur de charge

Une fois que vous avez créé un VPC NLB, vous ne pouvez plus reconfigurer le sous-réseau d'écoute avec lequel il a été créé. Si vous souhaitez modifier le sous-réseau d'écoute d'un VPC NLB existant, vous devez supprimer, mettre à jour, puis réappliquer le service LoadBalancer Kubernetes correspondant.

Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.

Répertoriez vos services Kubernetes et recherchez le nom du service LoadBalancer à modifier.

oc get services

Exemple de sortie.

NAME                     TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)                        AGE
my-load-balancer         LoadBalancer   172.21.77.198   52.118.150.107   8080:32767/TCP,443:30943/TCP   5d

Recherchez l'équilibreur de charge de VPC qui correspond au service Kubernetes LoadBalancer.

Les noms d'équilibreurs de charge de VPC sont au format kube-<cluster_ID>-<kubernetes_lb_service_UID>. Pour afficher votre ID de cluster, exécutez ibmcloud ks cluster get --cluster CLUSTER_NAME. Pour afficher l'UID de service de Kubernetes LoadBalancer, exécutez oc get svc LOAD_BALANCER_NAME -o yaml et recherchez la zone metadata.uid dans la sortie. Les tirets (-) sont supprimés de l'identifiant unique (UID) du service LoadBalancer Kubernetes dans le nom de l'équilibreur de charge VPC.
```
ibmcloud is load-balancers
```
Exemple de sortie.
```
ID                                          Name                                                         Family        Subnets                                       Is public   Provision status   Operating status   Resource group      
r000-5aaaa11f6-c111-111f-b2e0-1c11aaaaf0dc0   kube-c441c43d02mb8mg00r70-3e25d0b5bf11111111fe4ca3f11111cb   Network       subnet-1                                  true        active             online             default                                                    Application      
```
Obtenez la définition de service Kubernetes LoadBalancer et enregistrez la sortie dans un fichier yaml appelé my-lb.yaml.
```
oc describe service my-load-balancer -o yaml
```
Supprimez le service Kubernetes LoadBalancer. Cela supprime également l'équilibreur de charge de VPC correspondant.
```
oc delete service my-load-balancer
```
Mettez à jour le fichier de définition de service Kubernetes LoadBalancer avec les modifications de sous-réseau ou de zone que vous souhaitez implémenter. Ne modifiez pas le nom du service LoadBalancer. Pour plus de détails sur la spécification de sous-réseaux ou de zones pour les équilibreurs de charge réseau, voir Configuration d'un équilibreur de charge réseau de VPC.
Appliquez le nouveau fichier de définition LoadBalancer.
```
oc apply -f my-lb.yaml
```

Vérifiez que le service Kubernetes LoadBalancer est recréé avec succès dans votre cluster. Lors de la création du service, le champ Ingress d' LoadBalancer est renseigné avec une adresse IP externe pour le NLB.

oc describe service my-load-balancer

Exemple de sortie.

NAME:                     my-load-balancer
Namespace:                default
Labels:                   <none>
Annotations:              service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.X.XXX.XX
LoadBalancer Ingress:     169.XXX.XXX.XXX
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  32022/TCP
Endpoints:                172.XX.XX.XXX:8080,172.XX.XX.XX:8080,172.XX.XX.XX:8080 + 3 more...
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     30882
Events:
    Type     Reason                           Age                  From                Message
----     ------                           ----                 ----                -------
Normal   EnsuringLoadBalancer             9m27s (x7 over 15m)  service-controller  Ensuring load balancer
Normal   EnsuredLoadBalancer              9m20s                service-controller  Ensured load balancer
Normal   CloudVPCLoadBalancerNormalEvent  8m17s                ibm-cloud-provider  Event on cloud load balancer myvpcnlb for service default/my-load-balancer with UID 2d93b07d-ecf6-41d2-ad3f-9c2985122ec1: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.

Vérifiez que l'équilibreur de charge de VPC est recréé et que le sous-réseau ou la zone sont mis à jour. Notez que le provisionnement de l'équilibreur de charge VPC prend quelques minutes et qu'un statut create_pending en cours peut s'afficher jusqu'à ce qu'il soit entièrement provisionné.

ibmcloud is load-balancers

Exemple de sortie.

ID                                          Name                                                         Family        Subnets                                       Is public   Provision status   Operating status   Resource group     
r006-5ecc68f6-c751-409f-b2e0-1c69babf0dc0   kube-c441c43d02mb8mg00r70-3e25d0b5bf03445796fe4ca3f73885cb   Network       subnet-2                                  true        active             online             default