Avant de commencer

1. Assurez-vous de disposer du rôle d’accès au service IAM Writer ou Manager IBM Cloud pour l’espace de noms dans lequel vous déployez le service LoadBalancer Kubernetes pour le VPC NLB.
2. Accédez à votre cluster Red Hat OpenShift.
3. Pour afficher les équilibreurs de charge de réseau VPC, installez le plug-in infrastructure-service. Le préfixe pour l'exécution des commandes est ibmcloud is.

   ibmcloud plugin install infrastructure-service
   

4. Pour les NLB VPC privés: Connectez-vous au réseau privé de votre VPC, par exemple via une connexion VPC VPN.
5. Pour les VPC NLB privés: Activez votre application pour qu'elle reçoive des requêtes de réseau privé.
   1. Créez un sous-réseau VPC dédié à votre VPC NLB. Ce sous-réseau doit exister dans le même VPC et dans le même emplacement que votre cluster, mais il ne peut pas être connecté à votre cluster ou à vos nœuds worker. Si vous entrez une plage IP spécifique, n'utilisez pas les plages réservées suivantes : 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16et 172.20.0.0/16. Après avoir approvisionné le sous-réseau, notez son ID.
   2. Si le client qui se connecte à votre application via le VPC NLB se trouve en dehors du VPC et de la zone de votre sous-réseau VPC dédié, vous devez créer une table de routage d'entrée personnalisée. Pour plus d'informations, voir la table dans les sections Limitations connues et A propos des tables de routage et des routes. Sélectionnez l'une des sources de trafic suivantes pour votre table de routage d'entrée personnalisée : Pour le trafic provenant d'un réseau sur site, sélectionnez Lien direct. Pour le trafic provenant d'un autre VPC ou d'une infrastructure classique, choisissez Passerelle de transit. Pour le trafic provenant d'une autre zone au sein du même VPC, choisissez VPC zone. Pour plus d'informations, voir Configuration de la connectivité VPC VPN.

Configurer le service LoadBalancer

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 en tant que "public" ou "private". La section annotations du fichier d'exemple ne comprend que certaines annotations disponibles. Pour une liste complète des annotations VPC NLB obligatoires et facultatives, voir Annotations et spécifications.

   Pour que votre VPC NLB soit facilement identifiable, envisagez de nommer le service au format <app_name>-vpc-nlb-<VPC_zone>.

   apiVersion: v1
   kind: Service
   metadata:
     name: <app_name>-vpc-nlb-<VPC_zone>
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "public"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector: "<key>=<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet1_ID,subnet2_ID>"
   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 <filename>.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 une adresse IP externe affectée par l'équilibreur de charge de réseau VPC.

La mise à disposition dans votre VPC de l'équilibreur de charge de réseau VPC dure quelques minutes. L'adresse IP externe de votre service Kubernetes LoadBalancer peut être à l'état pending jusqu'à ce que l'équilibreur de charge de réseau VPC ait été 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:                     myapp-vpc-nlb-us-east
Namespace:                default
Labels:                   <none>
Annotations:              service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.204.12
LoadBalancer Ingress:     169.XXX.XXX.XXX
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  32022/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:     30882
Events:
    Type     Reason                           Age                  From                Message
----     ------                           ----                 ----                -------
Warning  SyncLoadBalancerFailed           13m (x5 over 15m)    service-controller  Error syncing load balancer: failed to ensure load balancer: kube-bqcssbbd0bsui62odcdg-2d93b07decf641d2ad3f9c2985122ec1 for service default/myvpcnlb is busy: offline/create_pending
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/myvpcnlb with UID 2d93b07d-ecf6-41d2-ad3f-9c2985122ec1: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.
```

5. Vérifiez que l'équilibreur de charge de réseau VPC a bien été créé dans votre VPC. Dans la sortie, vérifiez que pour l'équilibreur de charge de réseau 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 de réseau VPC nommé kube-bh077ne10vqpekt0domg-046e0f754d624dca8b287a033d55f96e est créé pour le service Kubernetes LoadBalancer :

   ID                                     Name                                                         Created          Host Name                                  Is Public   Listeners                               Operating Status   Pools                                   Private IPs              Provision Status   Public IPs                    Subnets                                Resource Group
   06496f64-a689-4693-ba23-320959b7b677   kube-bh077ne10vqpekt0domg-046e0f754d624dca8b287a033d55f96e   8 minutes ago    1234abcd-us-south.lb.appdomain.cloud       yes         95482dcf-6b9b-4c6a-be54-04d3c46cf017    online             717f2122-5431-403c-b21d-630a12fc3a5a    10.241.0.7               active             169.63.99.184                 c6540331-1c1c-40f4-9c35-aa42a98fe0d9   00809211b934565df546a95f86160f62
   

6. Accédez à l'adresse IP du service Kubernetes LoadBalancer que vous avez trouvé à l'étape 4 et votre port d'application au format <external_IP>:<app_port>.

7. Facultatif : répétez ces étapes pour déployer un équilibreur de charge de réseau VPC public dans chaque zone dans laquelle vous souhaitez exposer votre application. Vous pouvez ensuite enregistrer les adresses IP externes de l'équilibreur de charge de réseau VPC dans chaque zone avec un sous-domaine DNS.

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 NLB VPC 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.

Mise en place d'un NLB public à l'aide d'une plage de ports

Les plages de ports peuvent être utilisées dans les NLB publics lorsqu'il est nécessaire d'héberger un service à partir d'un seul nom d'hôte ayant plusieurs applications dorsales, chacune écoutant sur un numéro de port distinct. Pour utiliser des plages de ports dans votre cluster Kubernetes, une configuration manuelle doit être effectuée. Tout d'abord, l'option ibm-load-balancer-cloud-provider-vpc-port-range doit être définie. Il peut comprendre une ou plusieurs plages, chacune étant délimitée par une virgule. La valeur spec.ports.port doit également être réglée sur la valeur minimale de la gamme de ports.

Dans l'exemple suivant, une plage de ports de 30000-30010 est utilisée.

Les services Nodeport doivent être créés manuellement pour chaque déploiement dans lequel le service NLB transmet la requête. Le numéro de port de chacun de ces services Nodeport doit être compris dans la plage de ports configurée dans le service NLB.

Dans l'exemple de diagramme suivant, un service Nodeport avec le port 30000 est créé pour le déploiement 1 tandis qu'un service Nodeport avec le port 30001 est créé pour le déploiement 2.

L'utilisateur envoie une requête au port 30001 du NLB contenant la plage de ports. Cette demande est dirigée vers le service NLB VPC qui dirige la demande vers le service Nodeport dans le cluster qui écoute également sur le port 30001, qui dans ce cas est pour le Déploiement 2. Le service Nodeport dirige alors la requête vers le port cible des pods sélectionnés du déploiement 2.

Créez un NLB qui utilise une plage de ports en utilisant l'exemple suivant. Le sélecteur et les pods backend doivent être associés au service d'équilibrage de charge de la plage de ports afin que les contrôles de santé aboutissent et que les données soient livrées aux ports de la plage de ports. Pour utiliser la plage de ports, vous devez créer des services NodePort supplémentaires dont les valeurs de port se situent dans la plage définie par le service d'équilibreur de charge.

1. Enregistrez l'exemple de configuration LoadBalancer suivant dans un fichier appelé loadbalancer.yaml.

   apiVersion: v1
   kind: Service
   metadata:
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-port-range: 30000-30010
     name: nlb-port-range
   spec:
     externalTrafficPolicy: Cluster
     ports:
     - port: 30000 # Must match min from the port range
       protocol: TCP
       nodePort: 30011 # Can be port in range or not
       targetPort: 8080
     selector:
       app: echo-server  # Must be valid for health checks to work
     type: LoadBalancer
   

2. Créer le service.

   oc apply -f loadbalancer.yaml
   

3. Créez un service NodePort avec des valeurs de port qui se situent dans la plage de ports spécifiée dans le service LoadBalancer que vous avez créé précédemment.

   apiVersion: v1
   kind: Service
   metadata:
     name: echo-server-node-port
   spec:
     ports:
     - port: 80
       protocol: TCP # The protocol of the port range
       nodePort: 30003 # Node port in the port range
       targetPort: 8080
     selector:
       app: echo-server
     type: NodePort
   

4. Créer le service NodePort.

   oc apply -f nodeport.yaml
   

5. Pour accéder à un port qui se trouve dans la plage fournie par NLB.

   curl https://<public ip assigned to NLB>:30003
   

   • 30003 = Est un port de nœud dans la plage qui répond à la demande
   • Les autres ports de la plage ne répondent pas, à moins que des services de port de nœud supplémentaires ne soient créés.

Annotations et spécifications requises

service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb"

Instructions pour créer un VPC NLB. Si vous n'incluez pas cette annotation et que vous spécifiez nlb, un VPC ALB est créé par défaut.

service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"

(Obligatoire pour les NLB privés) Annotation permettant de spécifier un service qui accepte les requêtes privées. Si cette annotation n'est pas incluse, un VPC NLB public est créé.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets

(Obligatoire pour les NLB privés, facultatif pour les NLB publics) Annotation permettant de spécifier le sous-réseau dédié sur lequel le NLB VPC est déployé. La valeur peut être spécifiée en tant qu'ID de sous-réseau VPC, nom de sous-réseau VPC ou CIDR de sous-réseau VPC. Vous ne devez spécifier qu'un seul sous-réseau. Le sous-réseau doit figurer dans le même VPC que votre cluster et dans une zone où se trouvent des noeuds worker pour votre cluster, mais aucun noeud worker ne peut être associé à ce sous-réseau. Les noeuds worker qui se trouvent dans la même zone que ce sous-réseau sont configurés pour recevoir le trafic de l'équilibreur de charge de réseau VPC. 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.

externalTrafficPolicy

Spécifiez Local ou Cluster.

Définissez la valeur Local pour conserver l'adresse IP source des demandes client émises vers vos applications. Ce paramètre empêche le trafic entrant d'être transféré vers un autre nœud. Cette option configure également les contrôles d'intégrité HTTP.

Si Cluster est défini, DSR n'est implémenté qu'à partir du noeud worker auquel l'équilibreur de charge de réseau VPC achemine initialement la demande entrante. Une fois la demande reçue, elle est transmise à un nœud de travail qui contient le module d'application, lequel peut se trouver dans une zone différente. La réponse du pod d'application est envoyée au noeud worker d'origine et ce dernier utilise DSR pour envoyer la réponse directement au client, en contournant l'équilibreur de charge de réseau VPC. Cette option configure également les contrôles d'intégrité TCP. Pour les équilibreurs de charge « UDP », le fichier « service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp » est obligatoire si vous choisissez l'option « Cluster ». Pour plus d'informations, consultez la section « Configuration des contrôles d'intégrité d' TCP pour les équilibreurs de charge d' UDP ».

Annotations et spécifications facultatives

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name

Indiquez 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-zone

Annotation permettant de spécifier une zone VPC à laquelle votre cluster est connecté. L'équilibreur de charge de réseau VPC est déployé sur le sous-réseau de cette zone auquel vos noeuds worker sont connectés. Si vous modifiez ultérieurement cette annotation dans une autre zone, le NLB de VPC n'est pas déplacé vers la nouvelle zone. Si vous ne spécifiez pas cette annotation ou le site service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets annotation, le VPC NLB est déployé dans la zone la plus optimale (par exemple, une zone dont les nœuds de travail sont dans l'état Ready ). 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-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 nœuds de travail de votre cluster sont configurés pour recevoir le trafic provenant du VPC NLB. 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 recevoir du trafic; vous devez recréer ou mettre à jour le VPC NLB pour que le nœud de travailleur nouvellement étiqueté reçoive du trafic.

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

Le port du nœud TCP à utiliser pour les contrôles d'intégrité d' TCP dans un équilibreur de charge UDP. Requis pour les équilibreurs de charge UDP ayant externalTrafficPolicydéfini surCluster. Voir Configuration des contrôles d'intégrité TCP pour les équilibreurs de charge UDP pour plus d'informations avant de définir une valeur de port.

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

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. Les options disponibles sont http, https, ou tcp. En général, le protocole de contrôle de santé VPC LB est déterminé par la valeur du paramètre externalTrafficPolicy dans la spécification de service de l'équilibreur de charge Kubernetes. Toutefois, cette annotation ne tient pas compte de cette logique. Cette annotation ne 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 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 sortantes 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é. Pour plus d'informations, voir Comprendre la mise en réseau sécurisée par défaut des clusters VPC et Créer et gérer des groupes de sécurité VPC.

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 sur 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.

service.kubernetes.io/ibm-load-balancer-cloud-provider-dns-name: "example-ingress-domain.<region>.containers.appdomain.cloud"

Version 4.16 ou ultérieure.

Enregistrer l'adresse IP de l'équilibreur de charge avec le domaine d'entrée 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-member-quota

Optionnel. 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

1.30 s de version et versions ultérieures.

Optionnel. 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é géré par IBM, spécifiez un groupe de sécurité dont vous êtes propriétaire et que vous gérez. Cette option supprime le groupe de sécurité géré par 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é géré 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. 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

Facultatif : 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 de destination. 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.