Avant de commencer

• Vérifiez que vous disposez des rôles IBM Cloud IAM suivants :
  • N'importe quel rôle d'accès à la plateforme pour le cluster
  • Rôle d'accès au service Auteur ou Responsable pour tous les espaces de nom
• Accédez à votre cluster Red Hat OpenShift.

1. Créez un pool de nœuds de calcul avec le libellé dedicated=edge ou ajoutez l'étiquette à l'un de vos pools de travailleurs existants.

   • Pour créer un pool de travailleurs, vous pouvez utiliser le worker-pool create classic commande.

       ibmcloud oc worker-pool create classic --name POOL_NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone WORKERS_PER_ZONE --hardware ISOLATION --label dedicated=edge
       ```
   * Pour étiqueter un pool de nœuds de calcul existant, vous pouvez utiliser l'outil `worker-pool label set` [commande](/docs/openshift?topic=openshift-kubernetes-service-cli#worker-pool-label-set-cli).
   ```sh {: pre}
       ibmcloud oc worker-pool label set --cluster CLUSTER --worker-pool POOL --label dedicated=edge
       ```
   

2. Vérifiez que le pool de noeuds worker et les noeuds worker comportent le libellé dedicated=edge.

   • Pour vérifier le pool de nœuds de calcul, exécutez le get commande.

       ibmcloud oc worker-pool get --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME_OR_ID
       ```
   * Pour vérifier les noeuds worker individuels, examinez la zone **Labels** de la sortie de la commande suivante :
   ```sh {: pre}
       oc describe node <worker_node_private_IP>
       ```
   
   
   
   

3. Extrayez tous les NLB existants dans le cluster. Dans le résultat, notez l'espace de noms et le nom de chaque équilibreur de charge.

   oc get services --all-namespaces | grep LoadBalancer
   

   Exemple de sortie :

   PORT(S)                      AGE
   router-default
   80:31228/TCP,443:31655/TCP   4h54m
   LoadBalancer   172.21.71.79    169.46.17.2
   

4. À l'aide de la sortie de l'étape précédente, exécutez la commande suivante pour chaque NLB. Cette commande redéploie le NLB sur un noeud de travail d'arête.

   oc get service -n <namespace> <name> -o yaml | oc apply -f -
   

   Exemple de sortie :

   service "router-default" configured
   

5. Pour vérifier que les charges de travail réseau sont limitées aux nœuds périphériques, assurez-vous que les équilibreurs de charge sont affectés aux nœuds périphériques et non à des nœuds non périphériques.

   • Pods d'équilibreur de charge de réseau
     1. Vérifiez que les pods d'équilibreur de charge de réseau sont déployés sur des noeuds de périphérie. Recherchez l'adresse IP externe du service d'équilibrage de charge qui figure dans le résultat de l'étape précédente. Remplacez les points (. ) avec des tirets (- ). Dans l'exemple suivant pour le crc81nk5l10gfhdql4i3qg, le NLB possède une adresse IP externe de 169.46.17.2.

        oc describe nodes -l dedicated=edge | grep "169-46-17-2"
        

        Exemple de sortie :

        ibm-system                 ibm-cloud-provider-ip-169-46-17-2-76fcb4965d-wz6dg                 5m (0%)       0 (0%)      10Mi (0%)        0 (0%)
        ibm-system                 ibm-cloud-provider-ip-169-46-17-2-76fcb4965d-2z64r                 5m (0%)       0 (0%)      10Mi (0%)        0 (0%)
        

     2. Vérifiez qu'aucun pod d'équilibreur de charge de réseau n'est déployé sur des noeuds autres que des noeuds de périphérie. Exemple pour le NLB « public-crc81nk5l10gfhdql4i3qg-nlb1 », dont l'adresse IP externe est 169.46.17.2:

        oc describe nodes -l dedicated!=edge | grep "169-46-17-2"
        

        • Si les pods d'équilibreur de charge de réseau sont correctement déployés sur des noeuds de périphérie, aucun pod d'équilibreur de charge de réseau n'est renvoyé. Vos équilibreurs de charge de réseau sont replanifiés uniquement sur des noeuds worker de périphérie.
        • Si des pods d'équilibreur de charge de réseau sont renvoyés, passez à l'étape suivante.

6. Si les pods NLB sont encore déployés sur des nœuds non d'arête, vous pouvez supprimer les pods de sorte qu'ils soient redéployés vers des nœuds d'arête.

   Ne supprimez qu'un seul pod à la fois et assurez-vous que celui-ci a bien été réaffecté à un nœud périphérique avant de supprimer d'autres pods.

   1. Supprimez un pod. Par exemple, si l'un des pods NLB de public-crc81nk5l10gfhdql4i3qg-alb1 n'a pas été planifié sur un nœud périphérique :

       oc delete pod ibm-cloud-provider-ip-169-46-17-2-76fcb4965d-wz6dg -n ibm-system
       ```
   2. Vérifiez que le pod est replanifié sur un noeud worker de périphérie. La replanification est automatique, mais peut durer quelques minutes. Exemple pour le NLB « `public-crc81nk5l10gfhdql4i3qg-alb1` », dont l'adresse IP externe est `169.46.17.2`:
   ```sh {: pre}
       oc describe nodes -l dedicated=edge | grep "169-46-17-2"
       ```
       Exemple de sortie :
   
       ```sh {: screen}
       ibm-system                 ibm-cloud-provider-ip-169-46-17-2-76fcb4965d-wz6dg                 5m (0%)       0 (0%)      10Mi (0%)        0 (0%)
       ibm-system                 ibm-cloud-provider-ip-169-46-17-2-76fcb4965d-2z64r                 5m (0%)       0 (0%)      10Mi (0%)        0 (0%)
       ```
   
   
   

Vous avez attribué l'étiquette « dedicated=edge » aux nœuds de travail d'un pool de travail, puis vous avez redéployé tous les NLB existants vers les nœuds périphériques. Tous les NLB ajoutés par la suite au cluster sont également déployés sur un nœud périphérique de votre pool de travailleurs périphériques. Ensuite, empêchez d'autres charges de travail de s'exécuter sur des noeuds worker de périphérie et bloquez le trafic entrant vers des ports de noeud (NodePort) sur des noeuds worker.