Isolieren klassischer NLBs auf Edge-Workerknoten

Klassiker

In den folgenden Schritten fügen Sie den Worker-Knoten in jedem öffentlichen oder privaten VLAN Ihres Clusters das Label „ dedicated=edge “ hinzu. Diese Bezeichnung wird verwendet, um Ihre Netzwerklastenausgleichsmodule (NLBs) nur auf diesen Arbeitsknoten bereitzustellen. Sowohl öffentliche als auch private NLBs können auf Edge-Worker-Knoten bereitgestellt werden.

Wenn Sie einen bestehenden Worker-Pool verwenden möchten, muss dieser sich über alle Zonen Ihres Clusters erstrecken und mindestens zwei Worker-Knoten pro Zone umfassen. Sie können den Worker-Pool mit „ dedicated=edge “ kennzeichnen, indem Sie den Befehl „ ibmcloud ks worker-pool label set “ verwenden.

Vorbereitende Schritte

  1. Erstellen Sie einen Workerpool mit dem Label dedicated=edge oder fügen Sie das Label einem Ihrer vorhandenen Worker-Pools hinzu.

    • Um einen Arbeiterpool zu erstellen, können Sie den worker-pool create classic Befehl.
        ibmcloud ks worker-pool create classic --name POOL_NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone WORKERS_PER_ZONE --hardware ISOLATION --label dedicated=edge
    ```
* Um einen bestehenden Workerpool zu kennzeichnen, können Sie den `worker-pool label set` [Befehl](/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. Stellen Sie sicher, dass der Worker-Pool und die Workerknoten die Bezeichnung dedicated=edge haben.

    • Um den Workerpool zu überprüfen, führen Sie den get Befehl.
        ibmcloud ks worker-pool get --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME_OR_ID
    ```
* Überprüfen Sie das Feld **Labels** der Ausgabe des folgenden Befehls, um einzelne Workerknoten zu überprüfen.
```sh {: pre}
    kubectl describe node <worker_node_private_IP>
    ```

  3. Alle vorhandenen NLBs im Cluster abrufen. Beachten Sie in der Ausgabe den Namespace und den Namen jedes Load Balancers.

    kubectl get services --all-namespaces | grep LoadBalancer

    Beispielausgabe:

    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. Führen Sie unter Verwendung der Ausgabe aus dem vorherigen Schritt den folgenden Befehl für jede NLB aus. Dieser Befehl stellt die NLB auf einem Edge-Workerknoten erneut bereit.

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

    Beispielausgabe:

    service "private-crc81nk5l10gfhdql4i3qg-nlb1" configured
service "public-crc81nk5l10gfhdql4i3qg-nlb1" configured

  5. Um sicherzustellen, dass Netzwerk-Workloads auf Edge-Knoten beschränkt sind, vergewissern Sie sich, dass die Load Balancer auf den Edge-Knoten und nicht auf Nicht-Edge-Knoten eingeplant sind.

    • NLB-Pods
      1. Vergewissern Sie sich, dass NLB-Pods auf Edge-Knoten bereitgestellt werden. Suchen Sie nach der externen IP-Adresse des Load-Balancer-Dienstes, die in der Ausgabe des vorherigen Schritts aufgeführt ist. Ersetzen Sie die Punkte (. ) mit Bindestrichen (- ). Im folgenden Beispiel für die crc81nk5l10gfhdql4i3qg hat der NLB eine externe IP-Adresse von 169.46.17.2.
        kubectl describe nodes -l dedicated=edge | grep "169-46-17-2"
        Beispielausgabe: 
        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. Confirm that no NLB pods are deployed to non-edge nodes. Beispiel für den NLB „ public-crc81nk5l10gfhdql4i3qg-nlb1 “ mit der externen IP-Adresse 169.46.17.2:
        kubectl describe nodes -l dedicated!=edge | grep "169-46-17-2"
        • If the NLB pods are correctly deployed to edge nodes, no NLB pods are returned. Your NLBs are successfully rescheduled onto only edge worker nodes.
        • If NLB pods are returned, continue to the next step.

  6. Wenn NLB-Pods weiterhin auf Nicht-Edge-Knoten bereitgestellt werden, können Sie die Pods löschen, sodass sie erneut auf Edge-Knoten bereitgestellt werden.

    Löschen Sie jeweils nur einen Pod und vergewissern Sie sich, dass der Pod auf einen Edge-Knoten umverteilt wurde, bevor Sie weitere Pods löschen.

    1. Pod löschen. Wenn beispielsweise einer der NLB-Pods von „ public-crc81nk5l10gfhdql4i3qg-alb1 “ keine Zuordnung zu einem Edge-Knoten vorgenommen hat:
        kubectl delete pod ibm-cloud-provider-ip-169-46-17-2-76fcb4965d-wz6dg -n ibm-system
    ```
2. Stellen Sie sicher, dass der Pod auf einem Edge-Workerknoten neu geplant wurde. Die Neuplanung erfolgt automatisch, kann aber einige Minuten dauern. Beispiel für den NLB „ `public-crc81nk5l10gfhdql4i3qg-alb1` “ mit der externen IP-Adresse `169.46.17.2`:
```sh {: pre}
    kubectl describe nodes -l dedicated=edge | grep "169-46-17-2"
    ```
    Beispielausgabe:

    ```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%)
    ```

Sie haben die Worker-Knoten in einem Worker-Pool mit „ dedicated=edge “ gekennzeichnet und alle vorhandenen NLBs auf den Edge-Knoten neu bereitgestellt. Alle nachfolgenden NLBs, die dem Cluster hinzugefügt werden, werden ebenfalls auf einem Edge-Knoten in Ihrem Edge-Worker-Pool bereitgestellt. Verhindern Sie nun als nächsten Schritt, dass andere Arbeitslasten auf Edge-Workerknoten ausgeführt werden und blockieren Sie eingehenden Datenverkehr an Knotenports auf Workerknoten.