Configuration d'un équilibreur de charge d'application pour VPC

Exposez votre application sur le réseau public ou sur le réseau privé en configurant un service Kubernetes LoadBalancer dans votre cluster. Lorsque vous exposez votre application, un équilibreur de charge d'application pour VPC qui achemine les demandes vers votre application est automatiquement créé dans votre VPC en dehors de votre cluster. Vous pouvez ensuite, si vous le souhaitez, enregistrer le VPC ALB à l'aide d'un enregistrement DNS et d'un certificat TLS. Les ALB VPC prennent uniquement en charge le protocole TCP.

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.

Configuration d'un équilibreur de charge d'application VPC public ou privé

Avant de commencer

Pour permettre à votre application de recevoir des requêtes publiques ou privées :

  1. Déployez votre application sur le cluster. Prenez soin d'ajouter un libellé à votre déploiement dans la section "metadata" de votre fichier de configuration de déploiement. Ce libellé personnalisé identifie tous les pods dans lesquels s'exécute votre application afin de pouvoir les inclure dans l'équilibrage de charge.

  2. Créez un fichier YAML de configuration pour votre service Kubernetes LoadBalancer. Dans le fichier YAML, spécifiez l'annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type comme "public" ou "private". La section annotations du fichier d'exemple ne comprend que certaines annotations disponibles. Pour une liste complète des annotations VPC ALB obligatoires et facultatives, voir Annotations et spécifications.

    Pour que votre VPC ALB soit facilement identifiable, pensez à nommer le service dans le format <app_name>-vpc-alb-<VPC_zone>.

    apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "`<app_name>-vpc-alb-<VPC_zone>`"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "<public_or_private>"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector: "<key>=<value>"
spec:
 type: LoadBalancer
 selector:     
    <selector_key>: <selector_value>
 ports:
   - name: http
     protocol: TCP
     port: 8080
     targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
   - name: https
     protocol: TCP
     port: 443
     targetPort: 443 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
  externalTrafficPolicy: Local # Specify Local or Cluster.

  3. Créez le service Kubernetes LoadBalancer dans votre cluster.

    oc apply -f myloadbalancer.yaml -n <namespace>

  4. Vérifiez que le service Kubernetes LoadBalancer a bien été créé dans votre cluster. Lorsque le service est créé, la zone LoadBalancer Ingress est renseignée avec un nom d'hôte affecté par l'équilibreur de charge d'application VPC.

La mise à disposition dans votre VPC de l'équilibreur de charge d'application VPC dure quelques minutes. Vous ne pouvez pas accéder à votre application en utilisant le nom d'hôte de votre service Kubernetes LoadBalancer jusqu'à ce que l'ALB VPC soit entièrement mis à disposition.

```sh {: pre}
oc describe svc myloadbalancer -n <namespace>
```
Exemple de sortie de l'interface de ligne de commande pour un service `LoadBalancer` public :
```sh {: screen}
NAME:                     myvpcalb
Namespace:                default
Labels:                   <none>
Annotations:              
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.XX.XX
LoadBalancer Ingress:     1234abcd-us-south.lb.appdomain.cloud
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  30610/TCP
Endpoints:                172.17.17.133:8080,172.17.22.68:8080,172.17.34.18:8080 + 3 more...
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     31438
Events:
    Type    Reason                           Age   From                Message
----    ------                           ----  ----                -------
Normal  EnsuringLoadBalancer             16m   service-controller  Ensuring load balancer
Normal  EnsuredLoadBalancer              15m   service-controller  Ensured load balancer
Normal  CloudVPCLoadBalancerNormalEvent  13m   ibm-cloud-provider  Event on cloud load balancer myvpcalb for service default/myvpcalb with UID 08cbacf0-2c93-4186-84b6-c4ab88a2faf9: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.
```

  1. Vérifiez que l'équilibreur de charge d'application VPC a bien été créé dans votre VPC. Dans la sortie, vérifiez que pour l'équilibreur de charge d'application VPC, la zone Operating Status est définie sur online et la zone Provision Status, sur active.

    ibmcloud is load-balancers

    Dans l'exemple de sortie de l'interface de ligne de commande suivant, l'équilibreur de charge d'application VPC nommé kube-bsaucubd07dhl66e4tgg-1f4f408ce6d2485499bcbdec0fa2d306 est créé pour le service Kubernetes LoadBalancer :

    ID                                          Name                                                         Family        Subnets               Is public   Provision status   Operating status   Resource group
r006-d044af9b-92bf-4047-8f77-a7b86efcb923   kube-bsaucubd07dhl66e4tgg-1f4f408ce6d2485499bcbdec0fa2d306   Application   mysubnet-us-south-3   true        active             online             default

  2. Si vous avez créé un service public LoadBalancer, exécutez une commande curl sur le nom d'hôte du service Kubernetes LoadBalancer affecté par l'équilibreur de charge d'application VPC identifié à l'étape 4. Exemple :

    curl 06496f64-us-south.lb.appdomain.cloud:8080

    Exemple de sortie

    Hello world from hello-world-deployment-5fd7787c79-sl9hn! Your app is up and running in a cluster!

    Si vous avez créé un service LoadBalancer privé, vous devez être connecté à votre réseau VPC privé pour exécuter une commande curl sur le nom d'hôte.

Ne supprimez pas les sous-réseaux que vous avez associés à votre cluster lors de la création du cluster ou lorsque vous ajoutez des noeuds worker dans une zone. Si vous supprimez un sous-réseau VPC que votre cluster a utilisé, des problèmes peuvent se produire au niveau des équilibreurs de charge qui utilisent des adresses IP à partir du sous-réseau et il se peut que vous ne puissiez pas créer de nouveaux équilibreurs de charge.

Les ALB et NLB VPC qui ne sont pas associés à des clusters Kubernetes ou OpenShift peuvent être mis à jour directement à l'aide des commandes « ibmcloud is » ou via la section « Infrastructure VPC » de la console. Par exemple, modifier le port d'un auditeur frontal ou la valeur du délai d'attente d'un contrôle de santé. Toutefois, pour les équilibreurs de charge VPC associés à des clusters Kubernetes ou OpenShift, toute mise à jour doit être effectuée via des annotations dans la configuration Ingress. Le fournisseur « IBM Cloud » effectue périodiquement une resynchronisation avec tous les ALB et NLB du VPC associés afin de s'assurer que l'équilibreur de charge en cours d'exécution est conforme à la configuration attendue d'Ingress. Ainsi, si vous apportez des modifications à un tel équilibreur de charge directement via le VPC au lieu d'utiliser les annotations Ingress, ces modifications seront annulées.

Enregistrement d'un enregistrement DNS et d'un certificat TLS

L'équilibreur de charge d'application pour VPC (ALB de VPC) fournit un nom d'hôte HTTP par défaut au format 1234abcd-<region>.lb.appdomain.cloud à travers lequel vous pouvez accéder à votre application. Toutefois, si vous souhaitez qu'un certificat TLS pour votre domaine d'application prenne en charge HTTPS, vous pouvez créer un sous-domaine fourni par IBM ou apporter votre propre domaine personnalisé pour les équilibreurs de charge d'application publics et privés.

Après avoir créé un sous-domaine DNS pour un nom d'hôte ALB de VPC, vous ne pouvez pas utiliser les commandes nlb-dns health-monitor pour créer un contrôle d'intégrité personnalisé. Au lieu de cela, le diagnostic d'intégrité par défaut de l'équilibreur de charge VPC fourni pour le nom d'hôte d'équilibreur de charge d'application par défaut est utilisé. Pour plus d'informations, voir la documentation VPC.

Avant de commencer

  • Configurez un équilibreur de charge d'application VPC. Veillez à définir un port HTTPS dans votre service Kubernetes LoadBalancer qui configure l'équilibreur de charge d'application VPC.
  • Pour utiliser le certificat TLS afin d'accéder à votre application via HTTPS, vous devez être en mesure de mettre fin à des connexions TLS.

Pour enregistrer un nom d'hôte d'équilibreur de charge d'application VPC avec un sous-domaine DNS :

  1. Extrayez le nom d'hôte de votre VPC ALB en exécutant la commande get svc. Dans la sortie, recherchez le nom d'hôte dans la colonne EXTERNAL-IP. Par exemple, 1234abcd-us-south.lb.appdomain.cloud.

    oc get svc -o wide

    Exemple de sortie

    NAME            TYPE           CLUSTER-IP       EXTERNAL-IP                            PORT(S)     AGE       SELECTOR
...
webserver-lb    LoadBalancer   172.21.xxx.xxx   1234abcd-us-south.lb.appdomain.cloud   8080:30532/TCP     1d       run=webserver

  2. Créez un sous-domaine DNS personnalisé ou fourni par IBM pour le nom d'hôte de l'équilibreur de charge.

    • Domaine personnalisé: fournissez votre propre domaine personnalisé et attribuez-lui un alias en spécifiant l'adresse IP externe de l'équilibreur de charge, au format 1234abcd-us-south.lb.appdomain.cloud d'un enregistrement de nom canonique (CNAME).

      1. Enregistrez votre domaine personnalisé en utilisant votre fournisseur de DNS (Domain Name Service) ou IBM Cloud DNS.
      2. Définissez un alias pour votre domaine personnalisé en spécifiant l'adresse IP externe de l'équilibreur de charge en tant qu'enregistrement de nom canonique (CNAME). Dans l'exemple suivant, l'équilibreur de charge dont l'IP externe est 1234abcd-us-south.lb.appdomain.cloud est accessible à www.your-custom-domain.com.
      Hôte/Service
      Le préfixe où vous voulez accéder à votre application, par exemple, www.
      Type de ressource
      Sélectionnez CNAME.
      TTL
      Sélectionnez une période de vie.
      Valeur/Cible
      L'IP externe de LoadBalancer que vous avez récupérée précédemment. Par exemple,1234abcd-us-south.lb.appdomain.cloud.. Notez que lorsque vous utilisez le DNS IBM Cloud, veillez à saisir un point final.

    • Sous-domaine fourni par IBM : utilisez les commandes nlb-dns pour générer un sous-domaine avec un certificat TLS pour le nom d'hôte VPC ALB. IBM Cloud prend en charge automatiquement la génération et la gestion du certificat TLS générique pour le sous-domaine.

      1. Créez un sous-domaine DNS et un certificat TLS.
        ibmcloud oc nlb-dns create vpc-gen2 --cluster CLUSTER_NAME_OR_ID --lb-host VPC_LB_HOSTNAME --type (public|private)
      2. Vérifiez que le sous-domaine est créé. Pour plus d'informations, voir Description du format de sous-domaine.
        ibmcloud oc nlb-dns ls --cluster CLUSTER_NAME_OR_ID
        Exemple de sortie
        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   <certificate>

  3. Si vous avez créé un sous-domaine pour un ALB VPC public, ouvrez un navigateur Web et saisissez l'adresse URL pour accéder à votre application via ce sous-domaine, comme dans l'exemple www.your-custom-domain.com. Si vous avez créé un sous-domaine pour un équilibreur de charge d'application VPC privé, vous devez être connecté à votre réseau VPC privé pour tester l'accès à votre sous-domaine.

Pour utiliser le certificat TLS afin d'accéder à votre application via HTTPS, prenez soin de définir un port HTTPS dans votre service Kubernetes LoadBalancer. Vous pouvez vérifier que les demandes routent correctement via le port HTTPS en exécutant curl -v --insecure https://<domain>. Une erreur de connexion indique qu'aucun port HTTPS n'est ouvert sur le service. De plus, vérifiez que les connexions TLS peuvent être interrompues par votre application. Vous pouvez vérifier que votre application termine correctement TLS en exécutant curl -v https://<domain>. Une erreur de certificat indique que votre application n'arrête pas correctement les connexions TLS.

Enregistrement d'un enregistrement DNS privé pour un VPC ALB privé

Dans la version 4.15 ou ultérieure, vous pouvez utiliser les annotations facultatives suivantes pour associer un propre DNS instance qui sert un DNS personnalisé zone à un VPC ALB privé. Pour cela, les deux annotations facultatives doivent être définies. Si elles ne sont pas spécifiées, les enregistrements DNS de type « A » correspondant à la propriété « hostname » de cet équilibreur de charge sont ajoutés à la zone DNS publique lb.appdomain.cloud.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn"
L' instance DNS à associer à cet équilibreur de charge. L'instance spécifiée peut se trouver dans une région ou un compte différent, conformément aux politiques IAM. Valeurs possibles : 9 ≤ longueur ≤ 512
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id"
L' zone DNS à associer à cet équilibreur de charge. La zone spécifiée peut se trouver dans une région ou un compte différent, en fonction des politiques IAM. Valeurs possibles : 1 ≤ longueur ≤ 128, La valeur doit correspondre à l'expression régulière [1]*[a-z0-9]$

Les conditions suivantes doivent être remplies avant de pouvoir utiliser cette fonction :

  • Créer la zone DNS qui peut être liée à un équilibreur de charge
  • Activer l'autorisation de service à service entre les VPC LB et les DNS Services
  • Ajouter le VPC du cluster aux réseaux autorisés de la zone

Pour des informations détaillées, voir les documents Intégration d'un équilibreur de charge d'application avec IBM Cloud DNS Services et Ajouter un VPC en tant que réseau autorisé à la zone DNS.

Exemple :

apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "crn:v1:bluemix:public:dns-svcs:global:a/bb1b52262f7441a586f49068482f1e60:f761b566-030a-4696-8649-cc9d09889e88::"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "d66662cc-aa23-4fe1-9987-858487a61f45"
spec:
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 169.60.115.164
...

Annotations et spécifications

Examinez les annotations et spécifications obligatoires et facultatives du VPC ALB.

Annotations et spécifications requises

service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "alb"
Annotation pour créer un VPC ALB. Si vous n'incluez pas service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features, un VPC ALB est provisionné par défaut.
service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
(Obligatoire pour les ALB VPC privés) Annotation permettant de spécifier un service qui accepte les demandes publiques ou privées. Si cette annotation n'est pas incluse, un VPC ALB public est créé.
externalTrafficPolicy
Spécifiez Cluster pour transmettre une demande à un nœud de travailleur qui contient le module d'application. Ce nœud de travail peut se trouver dans une zone différente. Par défaut, cette annotation est définie sur Cluster.
Spécifiez Local pour empêcher le trafic entrant d'être transféré vers un autre nœud. Cette option configure également les contrôles d'intégrité HTTP.
Notez que pour utiliser l'IP source du client d'origine pour les VPC ALB, vous devez activer le protocole PROXY avec l'annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol".

Annotations et spécifications facultatives

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name
Ajoutez un nom unique pour que votre équilibreur de charge VPC soit persistant. Les équilibreurs de charge VPC persistants ne sont pas supprimés lorsque le cluster auquel ils appartiennent est supprimé. Pour plus d'informations, voir Équilibreurs de charge VPC persistants. Cette annotation ne peut être définie que lors de la création de l'équilibreur de charge. Il ne peut pas être utilisé dans une opération de mise à jour.
service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"
Activez le protocole PROXY. L'équilibreur de charge transmet les informations de connexion client, notamment l'adresse IP du client, l'adresse IP du serveur proxy et les deux numéros de port, contenues dans les en-têtes de demande, à votre application de back end. Notez que votre application de back end doit être configurée pour accepter le protocole PROXY. Par exemple, vous pouvez configurer une application NGINX pour qu'elle accepte le protocole PROXY en suivant ces étapes.
service.kubernetes.io/ibm-load-balancer-cloud-provider-zone
Annotation permettant de spécifier une zone VPC à laquelle votre cluster est connecté. Lorsque vous spécifiez une zone dans cette annotation, deux processus se produisent : (1) le VPC ALB est déployé sur le même sous-réseau de cette zone que celui auquel vos nœuds de travail sont connectés, et (2) seuls les nœuds de travail de votre cluster dans cette zone sont configurés pour recevoir le trafic du VPC ALB. Pour placer l'équilibreur de charge dans une zone spécifique, vous devez spécifier cette annotation lorsque vous créez l'équilibreur de charge. Si vous modifiez ultérieurement cette annotation pour une zone différente, les nœuds d'écoute et les nœuds de travail backend sont automatiquement mis à jour pour correspondre à la nouvelle zone. Si le label dedicated: edge est défini sur les nœuds de travail et que vous spécifiez cette annotation, seuls les nœuds périphériques de la zone spécifiée sont configurés pour recevoir du trafic. Les nœuds périphériques dans les autres zones et les nœuds non périphériques de la zone spécifiée ne reçoivent pas de trafic de l'équilibreur de charge. Pour afficher les zones, exécutez ibmcloud ks zone ls --provider vpc-gen2.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets
Annotation permettant de spécifier un ou plusieurs sous-réseaux sur lesquels le service VPC ALB est déployé. Si elle est spécifiée, cette annotation a priorité sur l'annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-zone. Sans cette annotation, les sous-réseaux que le VPC ALB déploie sont automatiquement mis à jour pour correspondre aux zones d'un cluster si ce dernier passe d'une région à zone unique à une région à zones multiples, ou vice versa. Vous pouvez spécifier un sous-réseau différent dans le même VPC que les sous-réseaux auxquels votre cluster est connecté. Dans ce cas, même si l'équilibreur de charge d'application VPC est déployé sur un autre sous-réseau du même VPC, il peut tout de même router le trafic vers vos noeuds worker sur les sous-réseaux du cluster. Pour afficher les sous-réseaux dans tous les groupes de ressources, exécutez ibmcloud oc subnets --provider vpc-gen2 --vpc-id VPC_ID --zone ZONE. Cette annotation peut être ajoutée ou modifiée pour les VPC ALB existants.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector
Annotation permettant de spécifier un sélecteur d'étiquette de nœud de travail. Vous pouvez configurer des nœuds de travail spécifiques dans votre cluster pour recevoir du trafic en spécifiant des clés de sélection d'étiquettes. Vous ne pouvez inclure qu'un seul sélecteur d'étiquette dans l'annotation, et ce sélecteur doit être spécifié au format "key=value". Si cette annotation n'est pas spécifiée, tous les noeuds worker de votre cluster sont configurés pour recevoir le trafic de l'équilibreur de charge d'application VPC. Cette annotation prévaut sur l'annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-zone, et toutes les étiquettes dedicated: edge présentes sur les nœuds de travail sont ignorées. Pour limiter le trafic à une zone spécifique, vous pouvez utiliser cette annotation pour spécifier les nœuds de travail dans cette zone. Notez que la définition d'une nouvelle étiquette sur un nœud de travailleur de cluster ne configure pas automatiquement le nœud de travailleur pour qu'il reçoive du trafic ; vous devez recréer ou mettre à jour le VPC ALB pour que le nœud de travailleur nouvellement étiqueté reçoive du trafic.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol
Le protocole de contrôle de santé sur la ressource d'équilibreur de charge VPC associée au service d'équilibreur de charge Kubernetes. Les options disponibles sont http, https, ou tcp. Habituellement, 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, mais cette annotation supplante 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
Le port de l' 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 votre cluster ne fonctionne pas avec Secure by Default, vous devrez peut-être apporter les modifications suivantes aux groupes de sécurité VPC appliqués. Si votre cluster fonctionne avec Secure by Default, ces changements sont appliqués automatiquement.
  • Si le port TCP spécifié se situe 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 ALB VPC, les règles de sortie du groupe de sécurité attribué à l’ALB VPC 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
Le chemin d'accès au contrôle de santé URL pour les contrôles de santé HTTP et HTTPs. 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'accès URL doit être au format d'une cible de demande de forme d'origine. 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
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
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.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout
Délai d'inactivité, en secondes, de la connexion du programme d'écoute. Le délai d'inactivité par défaut dépend des paramètres de votre compte. En général, cette valeur est 50. Toutefois, certains comptes figurant sur la liste des comptes autorisés ont des paramètres de délai plus importants. Si vous ne définissez pas l'annotation, vos équilibreurs de charge utilisent le délai d'attente défini dans votre compte. Vous pouvez spécifier explicitement le délai d'attente en définissant cette annotation. La valeur minimale est 50. La longueur maximale est de 7200.
service.kubernetes.io/ibm-load-balancer-cloud-provider-dns-name: "example-ingress-domain.<region>.containers.appdomain.cloud"
Version 4.17 ou ultérieure.
Enregistrer l'adresse IP de l'équilibreur de charge avec le domaine d'adresse spécifié. Si le domaine spécifié n'existe pas, un domaine est créé qui utilise le fournisseur interne géré par IBM (IBM NS1). Pour créer un nouveau domaine, le nom doit être unique pour tous les domaines existants (pas seulement ceux de votre cluster). La suppression du service d'équilibreur de charge supprime l'adresse IP du domaine. Cependant, la suppression de l'annotation ne supprime pas l'adresse IP du domaine.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn"
Version 4.15 ou ultérieure.
Le DNS instance à associer à cet équilibreur de charge. Pour plus d'informations, voir Enregistrement d'un enregistrement DNS privé.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id"
Version 4.15 ou ultérieure.
Le DNS zone à associer à cet équilibreur de charge. Pour plus d'informations, voir Enregistrement d'un enregistrement DNS privé.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota
Le nombre de nœuds de travail par zone vers lesquels l'équilibreur de charge se dirige. La valeur par défaut est de 8. Pour un cluster dont les nœuds de travail sont répartis dans trois zones, cela signifie que l'équilibreur de charge achemine le trafic vers 24 nœuds de travail au total. Le nombre total de nœuds de travail dans toutes les zones vers lesquelles l'équilibreur de charge se dirige 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.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group
Version 1.30 ou ultérieure.
Un groupe de sécurité géré par le client à ajouter à l'équilibreur de charge VPC. Si vous ne souhaitez pas utiliser le groupe de sécuritéIBM, spécifiez un groupe de sécurité que vous possédez et gérez. Cette option supprime le groupe de sécurité IBM et le remplace par le groupe de sécurité que vous spécifiez. La suppression de l'annotation d'un équilibreur de charge existant remplace le groupe de sécurité que vous avez ajouté par le groupe de sécurité IBM Vous pouvez ajouter ou supprimer cette annotation à tout moment. Vous êtes responsable de la gestion de votre groupe de sécurité et de sa mise à jour.
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-allow-outbound-traffic
Disponible pour les clusters qui exécutent Secure by Default. Annotation pour créer des groupes de sécurité pour chaque adresse IP d'un ALB associé à un port externe que vous spécifiez. Ces règles sont créées dans le groupe de sécurité du cluster et sont automatiquement mises à jour si l'adresse IP du VPC ALB change. Spécifiez les ports externes valides dans une liste séparée par des virgules, par exemple 80,443. Dans cet exemple, si chaque ALB public associé à chaque valeur de port externe possède deux adresses IP, une règle de sortie est créée par adresse IP, soit un total de 4 nouvelles règles. Vous pouvez ajouter ou supprimer cette annotation à tout moment.
selector
Clé de libellé (<selector_key>) et valeur (<selector_value>) que vous avez utilisées dans la section spec.template.metadata.labels du déploiement de votre application YAML. Ce libellé personnalisé identifie tous les pods dans lesquels s'exécute votre application afin de pouvoir les inclure dans l'équilibrage de charge.
port
Port sur lequel le service est à l'écoute.
targetPort
Port vers lequel le service achemine le trafic. L'application s'exécutant dans le pod doit être à l'écoute du trafic entrant de type « TCP » sur ce port cible. Le port cible est souvent défini de manière statique dans l'image qui tourne dans le module d'application. Le port cible configuré dans le pod est différent du port du nœud pour le service et peut également être différent du port externe configuré sur le VPC LB.

  1. a-z0-9- ↩︎