Isolamento degli NLB classici sui nodi di lavoro edge

Classico

Nei passaggi seguenti, si aggiunge l'etichetta " dedicated=edge " ai nodi di lavoro su ciascuna VLAN pubblica o privata del cluster. Questa etichetta viene utilizzata per distribuire i tuoi sistemi di bilanciamento del carico di rete (NLB) solo su tali nodi di lavoro. È possibile distribuire NLB sia pubblici che privati sui nodi di lavoro periferici.

Se si intende utilizzare un pool di worker esistente, tale pool deve coprire tutte le zone del cluster e disporre di almeno due nodi worker per zona. Puoi etichettare il pool di lavoratori con dedicated=edge utilizzando il ibmcloud ks worker-pool label set comando.

Prima di iniziare

  1. Crea un pool di lavoratori con l'etichetta dedicated=edge oppure aggiungi l'etichetta a uno dei tuoi pool di lavoratori esistenti.

    • Per creare un pool di lavoratori è possibile utilizzare il file worker-pool create classic comando.
        ibmcloud ks worker-pool create classic --name POOL_NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone WORKERS_PER_ZONE --hardware ISOLATION --label dedicated=edge
        ```
    * Per etichettare un pool di nodi di lavoro esistente, puoi utilizzare il file `worker-pool label set` [comando](/docs/containers?topic=containers-kubernetes-service-cli#worker-pool-label-set-cli).
    ```sh {: pre}
        ibmcloud ks worker-pool label set --cluster CLUSTER --worker-pool POOL --label dedicated=edge
        ```
    
  2. Verifica che il pool di nodi di lavoro e i nodi di lavoro abbiano l'etichetta dedicated=edge.

    • Per controllare il pool di nodi di lavoro, esegui il file get comando.
        ibmcloud ks worker-pool get --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME_OR_ID
        ```
    * Per controllare i singoli nodi di lavoro, esamina il campo **Labels** dell'output del seguente comando.
    ```sh {: pre}
        kubectl describe node <worker_node_private_IP>
        ```
    
    
    
  3. Recupera tutti gli NLB presenti nel cluster. Nell'output, prendere nota dello spazio dei nomi e del nome di ciascun bilanciatore di carico.

    kubectl get services --all-namespaces | grep LoadBalancer
    

    Output di esempio:

    kube-system           private-crc81nk5l10gfhdql4i3qg-nlb1   LoadBalancer   172.21.233.160   10.216.23.123    80:31345/TCP,443:32630/TCP   8d
    kube-system           public-crc81nk5l10gfhdql4i3qg-nlb1    LoadBalancer   172.21.190.18    169.46.17.2      80:31345/TCP,443:32630/TCP   8d
    
  4. Utilizzando l'output del passaggio precedente, eseguire il seguente comando per ciascun NLB. Questo comando esegue una nuova distribuzione dell'NLB su un nodo worker periferico.

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

    Output di esempio:

    service "private-crc81nk5l10gfhdql4i3qg-nlb1" configured
    service "public-crc81nk5l10gfhdql4i3qg-nlb1" configured
    
  5. Per verificare che i carichi di lavoro di rete siano limitati ai nodi periferici, assicurarsi che i bilanciatori di carico siano assegnati ai nodi periferici e non a nodi non periferici.

    • Pod NLB
      1. Conferma che i pod NLB siano distribuiti ai nodi edge. Cerca l'indirizzo IP esterno del servizio di bilanciamento del carico indicato nell'output del passaggio precedente. Sostituisci i punti (. ) con trattini (- ). Nell'esempio seguente per il crc81nk5l10gfhdql4i3qg, l'NLB ha un indirizzo IP esterno di 169.46.17.2.
        kubectl describe nodes -l dedicated=edge | grep "169-46-17-2"
        
        Output di esempio:
        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. Conferma che nessun pod NLB sia distribuito ai nodi non edge. Esempio relativo al NLB di public-crc81nk5l10gfhdql4i3qg-nlb1, che ha un indirizzo IP esterno pari a 169.46.17.2:
        kubectl describe nodes -l dedicated!=edge | grep "169-46-17-2"
        
        • Se i pod NLB vengono distribuiti correttamente ai nodi edge, non viene restituito alcun pod NLB. I tuoi NLB vengono ripianificati correttamente solo sui nodi di lavoro edge.
        • Se i pod NLB vengono restituiti, vai al passo successivo.
  6. Se i pod NLB sono ancora distribuiti su nodi non perimetrali, è possibile eliminarli in modo che vengano ridistribuiti sui nodi perimetrali.

    Eliminare un solo pod alla volta e verificare che il pod sia stato riprogrammato su un nodo periferico prima di eliminare altri pod.

    1. Elimina un pod. Ad esempio, se uno dei pod NLB di public-crc81nk5l10gfhdql4i3qg-alb1 non fosse stato pianificato su un nodo periferico:
        kubectl delete pod ibm-cloud-provider-ip-169-46-17-2-76fcb4965d-wz6dg -n ibm-system
        ```
    2. Verifica che il pod venga ripianificato su un nodo di lavoro edge. La ripianificazione è automatica, ma potrebbe richiedere alcuni minuti. Esempio relativo al NLB di `public-crc81nk5l10gfhdql4i3qg-alb1`, che ha un indirizzo IP esterno pari a `169.46.17.2`:
    ```sh {: pre}
        kubectl describe nodes -l dedicated=edge | grep "169-46-17-2"
        ```
        Output di esempio:
    
        ```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%)
        ```
    
    
    

Hai assegnato ai nodi di lavoro di un pool di lavoro l'etichetta " dedicated=edge " e hai ridistribuito tutti gli NLB esistenti sui nodi periferici. Anche tutti gli NLB aggiunti successivamente al cluster vengono distribuiti su un nodo periferico del pool di worker periferici. Successivamente, impedisci l'esecuzione di altri carichi di lavoro sui nodi di lavoro edge e blocca il traffico in entrata verso le NodePort sui nodi di lavoro.