Classique : Configuration de l'équilibrage de charge de base avec un équilibreur de charge de réseau (NLB) 1.0

La version 1.0 des NLB peuvent être créées uniquement dans des clusters classiques et ne peuvent pas être créées dans des clusters VPC. Pour effectuer un équilibrage de charge dans des clusters de VPC, voir Exposition d'applications avec des équilibreurs de charge pour VPC.

Exposez un port et utilisez une adresse IP portable pour un équilibreur de charge de réseau (NLB) de couche 4 afin d'exposer une application conteneurisée. Pour toute information sur les équilibreurs de charge de réseau 1.0, voir Composants et architecture d'un équilibreur de charge de réseau 1.0.

Configuration d'un équilibreur de charge de réseau 1.0 dans un cluster multizone

Avant de commencer

Pour pouvoir créer des équilibreurs de charge de réseau (NLB) publics dans plusieurs zones, au moins un VLAN public doit comporter des sous-réseaux portables disponibles dans chaque zone. Pour pouvoir créer des équilibreurs de charge de réseau (NLB) privés dans plusieurs zones, au moins un VLAN privé doit comporter des sous-réseaux portables disponibles dans chaque zone. Vous pouvez ajouter des sous-réseaux en suivant la procédure indiquée dans Configuration de sous-réseaux pour les clusters.
Activez une fonction VRF (Virtual Router Function) pour votre compte d'infrastructure IBM Cloud. Pour activer la fonction VRF, voir Activation de VRF. Pour vérifier si la fonction VRF est déjà activée, utilisez la commande ibmcloud account show. Si vous ne pouvez pas ou ne souhaitez pas activer VRF, activez Réseau local virtuel. Lorsqu'une fonction VRF ou Spanning VLAN est activée, l'équilibreur de charge de réseau (NLB) 1.0 peut router des paquets vers différents sous-réseaux dans le compte.
Assurez-vous de disposer de l'Auteur ou Responsable IBM Cloud Rôle d'accès au service IAM pour l'espace de noms default.
Vérifiez que vous possédez le nombre requis de noeuds worker :
- Clusters classiques : si vous limitez le trafic réseau aux noeuds worker de périphérie, vérifiez qu'au moins deux noeuds worker de périphérie sont activés dans chaque zone pour assurer le déploiement uniforme des équilibreurs de charge de réseau.
Lorsque les nœuds de cluster sont rechargés ou lorsqu'une mise à jour de cluster de cluster inclut une nouvelle imagekeepalived, l'adresse IP virtuelle de l'équilibreur de charge est déplacée vers l'interface réseau d'un nouveau noeud. Lorsque cela se produit, toute connexion de longue durée à votre équilibreur de charge doit être rétablie. Pensez à intégrer une logique de réessai dans votre application afin que les tentatives de rétablissement de la connexion soient effectuées rapidement.

Pour configurer un service d'équilibreur de charge de réseau 1.0 dans un cluster multizone :

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.

Créez un service d'équilibreur de charge pour l'application que vous désirez exposer sur l'Internet public ou sur un réseau privé.

Créez un fichier de configuration de service nommé, par exemple, myloadbalancer.yaml.
Définissez un service d'équilibreur de charge pour l'application que vous désirez exposer. Vous pouvez spécifier une zone, un VLAN et une adresse IP.

    apiVersion: v1
    kind: Service
    metadata:
      name: myloadbalancer
      annotations:
        service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: <public_or_private>
        service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "<zone>"
        service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>"
    spec:
      type: LoadBalancer
      selector:
        <selector_key>: <selector_value>
      ports:
       - protocol: TCP
         port: 8080
         targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
      loadBalancerIP: <IP_address>
    ```

    `service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type`
    :   Annotation permettant de spécifier un équilibreur de charge `private` ou `public`. Si vous ne spécifiez pas cette annotation et que vos nœuds worker sont connectés à des réseaux locaux virtuels publics, un service public `LoadBalancer` est créé. Si vos noeuds worker sont connectés à des VLAN privés uniquement, un service `LoadBalancer` privé est créé.

    `service.kubernetes.io/ibm-load-balancer-cloud-provider-zone`
    :   Annotation utilisée pour indiquer la zone dans laquelle est déployé le service d'équilibreur de charge. Pour afficher les zones, exécutez `ibmcloud ks zone ls`.

    `service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan`
    :   Annotation utilisée pour spécifier un VLAN sur lequel est déployé le service d'équilibreur de charge. Pour voir les réseaux locaux virtuels, exécutez `ibmcloud ks vlan ls --zone <zone>`.

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

    `port`
    :   Port sur lequel le service est à l'écoute.

    `loadBalancerIP`
    :   Facultatif : pour créer un équilibreur de charge privé ou utiliser une adresse IP portable spécifique pour un équilibreur de charge public, indiquez l'adresse IP que vous désirez utiliser. Cette adresse IP doit se trouver sur le VLAN que vous avez spécifié dans les annotations. Si vous ne spécifiez pas d'adresse IP :
        :   Si votre cluster se trouve sur un VLAN public, une adresse IP publique portable est utilisée. La plupart des clusters se trouvent sur un VLAN public.
        :   Si votre cluster se trouve sur un VLAN privé uniquement, une adresse IP privée portable est utilisée.

    Exemple de fichier de configuration utilisé pour créer un service d'équilibreur de charge de réseau (NLB) privé 1.0 qui utilise une adresse IP indiquée sur le VLAN privé `2234945` dans la zone `dal12` :

    ```yaml {: codeblock}
    apiVersion: v1
    kind: Service
    metadata:
      name: myloadbalancer
      annotations:
        service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private
        service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "dal12"
        service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "2234945"
    spec:
      type: LoadBalancer
      selector:
        app: nginx
      ports:
       - protocol: TCP
         port: 8080
         targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
      loadBalancerIP: 172.21.xxx.xxx
    ```
3. Facultatif : limitez l'accès à votre service NLB à une plage d'adresses IP restreinte en spécifiant ces adresses dans le champ « `spec.loadBalancerSourceRanges` ». La fonctionnalité « `loadBalancerSourceRanges` » est mise en œuvre par `kube-proxy` au sein de votre cluster à l'aide de règles iptables sur les nœuds de travail. Pour plus d'informations, consultez la [documentation relative à l' Kubernetes](https://kubernetes.io/docs/concepts/services-networking/){: external}.

4. Créez le service dans votre cluster.

```sh {: pre}
    kubectl apply -f myloadbalancer.yaml
    ```

Vérifiez que la création du service d'équilibreur de charge de réseau a abouti. La création du service et la mise à disposition de l'application peuvent prendre quelques minutes.

kubectl describe service myloadbalancer

Exemple de sortie :

NAME:                   myloadbalancer
Namespace:              default
Labels:                 <none>
Selector:               app=liberty
Type:                   LoadBalancer
Zone:                   dal10
IP:                     172.21.xxx.xxx
LoadBalancer Ingress:   169.xx.xxx.xxx
Port:                   <unset> 8080/TCP
NodePort:               <unset> 32040/TCP
Endpoints:              172.30.xxx.xxx:8080
Session Affinity:       None
Events:
    FirstSeen    LastSeen    Count    From            SubObjectPath    Type     Reason                      Message
    ---------    --------    -----    ----            -------------    ----     ------                      -------
    10s            10s            1        {service-controller }      Normal CreatingLoadBalancer    Creating load balancer
    10s            10s            1        {service-controller }        Normal CreatedLoadBalancer    Created load balancer

Si vous avez créé un équilibreur de charge de réseau public, accédez à votre application via Internet.
1. Ouvrez le navigateur Web de votre choix.
2. Entrez l'adresse IP publique portable de l'équilibreur de charge de réseau et le port.
```
    http://169.xx.xxx.xxx:8080
    ```
```
Répétez les étapes 2 à 4 pour ajouter un NLB de version 1.0 dans chaque zone.
Si vous choisissez d'activer la conservation de l'adresse IP source pour un service d'équilibreur de charge de réseau 1.0, assurez-vous que les pods d'application sont planifiés sur les noeuds worker de périphérie en ajoutant l'affinité de noeud de périphérie aux pods d'application. Les pods d'application doivent être planifiés sur des noeuds de périphérie pour recevoir des demandes entrantes.
Facultatif : un service d'équilibreur de charge rend votre application accessible via les ports de noeud du service. Les ports de noeud (NodePort) sont accessibles sur toutes les adresses IP publiques et privées pour tous les noeuds figurant dans le cluster. Pour bloquer le trafic vers les ports de noeud lorsque vous utilisez un service d'équilibreur de charge de réseau, voir Contrôle du trafic entrant vers les services d'équilibreur de charge de réseau ou NodePort.

Ensuite, vous pouvez enregistrer un sous-domaine d'équilibreur de charge de réseau.

Configuration d'un équilibreur de charge de réseau 1.0 dans un cluster à zone unique

Avant de commencer

Vous devez disposer d'une adresse IP publique ou privée portable disponible à affecter au service d'équilibreur de charge de réseau (NLB). Pour plus d'informations, voir Configuration de sous-réseaux pour les clusters.
Assurez-vous de disposer de l'Auteur ou Responsable IBM Cloud Rôle d'accès au service IAM pour l'espace de noms default.
Lorsque les nœuds de cluster sont rechargés ou lorsqu'une mise à jour de cluster de cluster inclut une nouvelle imagekeepalived, l'adresse IP virtuelle de l'équilibreur de charge est déplacée vers l'interface réseau d'un nouveau noeud. Lorsque cela se produit, toute connexion de longue durée à votre équilibreur de charge doit être rétablie. Pensez à intégrer une logique de réessai dans votre application afin que les tentatives de rétablissement de la connexion soient effectuées rapidement.

Pour créer un service d'équilibreur de charge de réseau 1.0 dans un cluster à zone unique :

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.

Créez un service d'équilibreur de charge pour l'application que vous désirez exposer sur l'Internet public ou sur un réseau privé.

Créez un fichier de configuration de service nommé, par exemple, myloadbalancer.yaml.
Définissez un service d'équilibreur de charge pour l'application que vous désirez exposer.

    apiVersion: v1
    kind: Service
    metadata:
      name: myloadbalancer
      annotations:
        service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: <public_or_private>
        service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>"
    spec:
      type: LoadBalancer
      selector:
        <selector_key>: <selector_value>
      ports:
       - protocol: TCP
         port: 8080
         targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
      loadBalancerIP: <IP_address>
    ```
    `service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type`
    :   Annotation permettant de spécifier un équilibreur de charge `private` ou `public`.

    `service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan`
    :   Annotation utilisée pour spécifier un VLAN sur lequel est déployé le service d'équilibreur de charge. Pour voir les réseaux locaux virtuels, exécutez `ibmcloud ks vlan ls --zone <zone>`.

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

    `port`
    :   Port sur lequel le service est à l'écoute.

    `loadBalancerIP`
    :   Facultatif : pour créer un équilibreur de charge privé ou utiliser une adresse IP portable spécifique pour un équilibreur de charge public, indiquez l'adresse IP que vous désirez utiliser. Cette adresse IP doit se trouver sur le VLAN que vous avez spécifié dans les annotations. Si vous ne spécifiez pas d'adresse IP :
        :   Si votre cluster se trouve sur un VLAN public, une adresse IP publique portable est utilisée. La plupart des clusters se trouvent sur un VLAN public.
        :   Si votre cluster se trouve sur un VLAN privé uniquement, une adresse IP privée portable est utilisée.

    Exemple de fichier de configuration utilisé pour créer un service d'équilibreur de charge de réseau 1.0 privé qui utilise une adresse IP indiquée sur le VLAN privé `2234945` :

    ```yaml {: codeblock}
    apiVersion: v1
    kind: Service
    metadata:
      name: myloadbalancer
      annotations:
        service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private
        service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "2234945"
    spec:
      type: LoadBalancer
      selector:
        app: nginx
      ports:
       - protocol: TCP
         port: 8080
         targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
      loadBalancerIP: 172.21.xxx.xxx
    ```
3. Facultatif : limitez l'accès à votre service NLB à une plage d'adresses IP restreinte en spécifiant ces adresses dans le champ « `spec.loadBalancerSourceRanges` ». La fonctionnalité « `loadBalancerSourceRanges` » est mise en œuvre par `kube-proxy` au sein de votre cluster à l'aide de règles iptables sur les nœuds de travail. Pour plus d'informations, consultez la [documentation relative à l' Kubernetes](https://kubernetes.io/docs/concepts/services-networking/){: external}.

4. Créez le service dans votre cluster.

```sh {: pre}
    kubectl apply -f myloadbalancer.yaml
    ```

Vérifiez que la création du service d'équilibreur de charge de réseau a abouti. La création du service et la mise à disposition de l'application peuvent prendre quelques minutes.

kubectl describe service myloadbalancer

Exemple de sortie :

NAME:                   myloadbalancer
Namespace:              default
Labels:                 <none>
Selector:               app=liberty
Type:                   LoadBalancer
Location:               dal10
IP:                     172.21.xxx.xxx
LoadBalancer Ingress:   169.xx.xxx.xxx
Port:                   <unset> 8080/TCP
NodePort:               <unset> 32040/TCP
Endpoints:              172.30.xxx.xxx:8080
Session Affinity:       None
Events:
    FirstSeen    LastSeen    Count    From            SubObjectPath    Type     Reason                      Message
    ---------    --------    -----    ----            -------------    ----     ------                      -------
    10s            10s            1        {service-controller }      Normal CreatingLoadBalancer    Creating load balancer
    10s            10s            1        {service-controller }        Normal CreatedLoadBalancer    Created load balancer

L'adresse IP LoadBalancer Ingress est l'adresse IP portable affectée à votre service d'équilibreur de charge de réseau.

Si vous avez créé un équilibreur de charge de réseau public, accédez à votre application via Internet.
1. Ouvrez le navigateur Web de votre choix.
2. Entrez l'adresse IP publique portable de l'équilibreur de charge de réseau et le port.
```
    http://169.xx.xxx.xxx:8080
    ```
```
Si vous choisissez d'activer la conservation de l'adresse IP source pour un service d'équilibreur de charge de réseau 1.0, assurez-vous que les pods d'application sont planifiés sur les noeuds worker de périphérie en ajoutant l'affinité de noeud de périphérie aux pods d'application. Les pods d'application doivent être planifiés sur des noeuds de périphérie pour recevoir des demandes entrantes.
Facultatif : un service d'équilibreur de charge rend votre application accessible via les ports de noeud du service. Les ports de noeud (NodePort) sont accessibles sur toutes les adresses IP publiques et privées pour tous les noeuds figurant dans le cluster. Pour bloquer le trafic vers les ports de noeud lorsque vous utilisez un service d'équilibreur de charge de réseau, voir Contrôle du trafic entrant vers les services d'équilibreur de charge de réseau ou NodePort.

Ensuite, vous pouvez enregistrer un sous-domaine d'équilibreur de charge de réseau.

Activation de la conservation de l'adresse IP source

Cette fonction est applicable uniquement aux équilibreurs de charge de réseau 1.0. Par défaut, l'adresse IP source des demandes du client est conservée dans les équilibreurs de charge de réseau 2.0.

Lorsqu'une demande du client destinée à votre application est envoyée à votre cluster, un pod de service d'équilibreur de charge reçoit la demande. S'il n'existe aucun pod d'application sur le même noeud worker que le pod de service d'équilibreur de charge, l'équilibreur de charge de réseau transmet la demande sur un autre noeud worker. L'adresse IP source de la requête est remplacée par l'adresse IP publique du nœud de travail sur lequel s'exécute le pod du service d'équilibrage de charge.

Pour conserver l'adresse IP source d'origine de la requête du client, vous pouvez activer l'adresse IP source pour les services d'équilibrage de charge. La connexion TCP se poursuit jusqu'aux pods d'application de sorte que l'application puisse voir l'adresse IP source réelle du demandeur. Conserver l'adresse IP du client est pratique, notamment lorsque les serveurs d'applications doivent appliquer des règles de sécurité et de contrôle d'accès.

Après avoir activé l'adresse IP source, les pods de service d'équilibreur de charge doivent transférer les demandes aux pods d'application déployés sur le même noeud worker uniquement. En principe, des pods de service d'équilibreur de charge sont également déployés sur les noeuds worker sur lesquels sont déployés les pods d'application. Il existe cependant des situations où les pods d'équilibreur de charge et les pods d'application ne sont pas forcément planifiés sur le même noeud worker :

Vous disposez de noeuds de périphérie auxquels une tache est appliquée de sorte que seuls les pods du service d'équilibreur de charge puissent se déployer sur ces noeuds. Le déploiement des pods d'application n'est pas autorisé sur ces noeuds.
Votre cluster est connecté à plusieurs réseaux locaux virtuels (VLAN) publics ou privés, et vos pods d'application peuvent se déployer sur des noeuds worker connectés uniquement à un seul VLAN. Les pods de service d'équilibreur de charge risquent de ne pas se déployer sur ces noeuds worker car l'adresse IP de l'équilibreur de charge de réseau est connectée à un autre VLAN que les noeuds worker.

Pour forcer le déploiement de votre application sur des noeuds worker spécifiques sur lesquels peuvent se déployer des pods de service d'équilibreur de charge, vous devez ajouter des règles d'affinité et des tolérances au déploiement de votre application.

Ajout de règles d'affinité et de tolérances pour les noeuds de périphérie

Lorsque vous libellez des nœuds worker en tant que nœuds d'arête et la tache des nœuds d'arête, les pods de service de l'équilibreur de charge se déploient uniquement sur les nœuds d'arête, et les groupes d'applications ne peuvent pas se déployer sur les nœuds d'arête. Lorsque la propriété IP source est activée pour le service NLB, les pods d'équilibreur de charge sur les nœuds d'arête ne peuvent pas transmettre les demandes entrantes à vos pods d'application sur d'autres nœuds worker.

Pour forcer le déploiement des pods de votre application vers des nœuds périphériques, ajoutez une règle d'affinité avec les nœuds périphériques et une tolérance au déploiement de l'application.

Exemple de fichier YAML de déploiement avec les règles d'affinité et de tolérance pour les noeuds de périphérie :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: with-node-affinity
spec:
  selector:
    matchLabels:
      <label_name>: <label_value>
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: dedicated
                operator: In
                values:
                - edge
      tolerations:
        - key: dedicated
          value: edge
...

Les sections « affinity » et « tolerations » indiquent toutes deux dedicated comme key et edge comme value.

Ajout de règles d'affinité à plusieurs réseaux locaux virtuels (VLAN) publics ou privés

Lorsque votre cluster est connecté à plusieurs réseaux locaux virtuels (VLAN) publics ou privés, vos pods d'application peuvent se déployer sur des noeuds worker connectés uniquement à un seul VLAN. Si l'adresse IP de l'équilibreur de charge de réseau est connectée à un autre VLAN que ces noeuds worker, les pods de service d'équilibreur de charge ne pourront pas se déployer sur ces noeuds worker.

Lorsque l'adresse IP source est activée, planifiez les pods d'application sur les noeuds worker avec le même VLAN que l'adresse IP de l'équilibreur de charge de réseau en ajoutant une règle d'affinité au déploiement de l'application.

Avant de commencer :

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

Procurez-vous l'adresse IP du service d'équilibreur de charge de réseau. Recherchez cette adresse dans la zone LoadBalancer Ingress.
```
kubectl describe service <loadbalancer_service_name>
```

Récupérez l'ID VLAN auquel votre service d'équilibreur de charge de réseau est connecté.

Affichez la liste des VLAN publics portables de votre cluster.

    ibmcloud ks cluster get --cluster <cluster_name_or_ID> --show-resources
    ```
    Exemple de sortie
    ```sh {: screen}
    ...
    Subnet VLANs
    VLAN ID   Subnet CIDR       Public   User-managed
    2234947   10.xxx.xx.xxx/29  false    false
    2234945   169.36.5.xxx/29   true     false
    ```
2. Dans la sortie sous **Subnet VLANs**, recherchez le routage CIDR de sous-réseau correspondant à l'adresse IP d'équilibreur de charge de réseau que vous avez récupérée précédemment et notez l'ID du VLAN.

    Par exemple, si l'adresse IP du service d'équilibreur de charge de réseau est `169.36.5.xxx`, le sous-réseau correspondant dans l'exemple de sortie de l'étape précédente est `169.36.5.xxx/29`. L'ID du VLAN auquel est connecté ce sous-réseau est `2234945`.

Ajoutez une règle d'affinité au déploiement de l'application pour l'ID de VLAN que vous avez noté à l'étape précédente.

Par exemple, si vous disposez de plusieurs VLAN et que vous souhaitez que vos pods d'application se déploient sur des noeuds worker résidant uniquement sur le VLAN public 2234945 :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: with-node-affinity
spec:
  selector:
    matchLabels:
      <label_name>: <label_value>
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: publicVLAN
                operator: In
                values:
                - "2234945"
...

Dans l'exemple de fichier YAML, la section affinity contient publicVLAN pour key et "2234945" pour value.

Appliquez le fichier de configuration de déploiement mis à jour.
```
kubectl apply -f with-node-affinity.yaml
```

Vérifiez que les pods d'application déployés sur les noeuds worker sont connectés au VLAN désigné.

Affichez la liste des pods de votre cluster. Remplacez <selector> par le libellé que vous avez utilisé pour l'application.

    kubectl get pods -o wide app=<selector>
    ```
    Exemple de sortie
    ```sh {: screen}
    NAME                   READY     STATUS              RESTARTS   AGE       IP               NODE
    cf-py-d7b7d94db-vp8pq  1/1       Running             0          10d       172.30.xxx.xxx   10.176.48.78
    ```
2. Dans la sortie, identifiez un pod pour votre application. Notez l'ID du noeud worker (**NODE**) sur lequel réside le pod.

    Dans l'exemple de sortie de l'étape précédente, le pod d'application `cf-py-d7b7d94db-vp8pq` réside sur le noeud worker `10.176.48.78`.

3. Affichez la liste des détails relatifs à votre noeud worker.

```sh {: pre}
    kubectl describe node <worker_node_ID>
    ```
    Exemple de sortie

    ```sh {: screen}
    NAME:                   10.xxx.xx.xxx
    Role:
    Labels:                 arch=amd64
    beta.kubernetes.io/arch=amd64
    beta.kubernetes.io/os=linux
    failure-domain.beta.kubernetes.io/region=us-south
    failure-domain.beta.kubernetes.io/zone=dal10
    ibm-cloud.kubernetes.io/encrypted-docker-data=true
    kubernetes.io/hostname=10.xxx.xx.xxx
    privateVLAN=2234945
    publicVLAN=2234967
    ...
    ```
4. Dans la section **Labels** de la sortie, vérifiez que le VLAN public ou privé correspond au VLAN que vous avez désigné dans les étapes précédentes.