將 Ingress 資源隔離至邊緣工作節點

若要將 ALB Pod 排程至邊緣工作節點，您必須建立或使用現有的工作節點池，且該工作節點池在每個區域中至少須包含兩個邊緣工作節點。這可確保始終有邊緣節點可用，以便將 ALB Pod 排程至這些節點上。

當您更新 ALB Pod 時，系統會逐步部署一個新的 Pod 來取代現有的 Pod。為了確保 ALB 在更新期間仍可正常運作，滾動式更新會一次僅替換一個 Pod，以確保至少有一個 ALB Pod 始終處於活躍狀態。然而，ALB Pod 設有反親和性規則，可防止兩個 ALB Pod 在同一台工作節點上運行。若某個區域中至少有兩個邊緣節點，則可在其中一個節點上部署新的 ALB Pod，同時另一個節點仍會繼續運行。

為了確保 ALB 的高可用性，當各區域中的邊緣節點數量不足時，系統會忽略邊緣節點標籤，並將 ALB Pod 排程至非邊緣節點上。

將 ALB 工作負載隔離至邊緣節點的步驟，在傳統基礎架構和 VPC 基礎架構中均相同。然而，各種類型的 ALB 外部 IP 的命名規則各不相同。對於部署在傳統基礎架構上的 ALB，其外部 IP 為標準 IP 位址，例如 169.46.17.2。對於部署於 VPC 基礎架構上的 ALB，其外部 IP 為一個主機名稱，例如 f3bee8b5-us-south.lb.appdomain.cloud。

開始之前

請確保您擁有以下 IAM 角色：
- 該叢集的任何平台存取角色
- 所有命名空間的「撰寫者」或「管理員」服務存取角色
請登入您的帳戶。適用的話，請將適當的資源群組設為目標。設定叢集的環境定義。

將工作負載隔離至邊緣工作節點

若要將您的工作負載隔離至邊緣工作節點：

建立一個標籤為「dedicated=edge」的工作者群組，或將此標籤新增至您現有的工作者群組之一。

若要建立一個「經典」工作執行程序池，您可以使用 worker-pool create classic 指令。

    ibmcloud oc worker-pool create classic --name POOL_NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone WORKERS_PER_ZONE --hardware ISOLATION --label dedicated=edge
    ```
* 若要建立 VPC 工作壟池，您可以使用 ` `worker-pool create vpc-gen2` ` [指令](/docs/containers?topic=containers-kubernetes-service-cli#worker-pool-create-vpc-gen2-cli)。
```sh {: pre}
    ibmcloud oc worker-pool create vpc-gen2 --name POOL_NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone WORKERS_PER_ZONE --hardware ISOLATION --label dedicated=edge
    ```
* 若要為現有的工作匣加上標籤，您可以使用 `worker-pool label set` [指令](/docs/containers?topic=containers-kubernetes-service-cli#worker-pool-label-set-cli)。
```sh {: pre}
    ibmcloud oc worker-pool label set --cluster CLUSTER --worker-pool POOL --label dedicated=edge
    ```

驗證工作者節點儲存區和工作者節點是否具有 dedicated=edge 標籤。

若要檢查工作執行程序池，請使用 get 指令。

    ibmcloud ks worker-pool get --cluster CLUSTER_NAME_OR_ID --worker-pool WORKER_POOL_NAME_OR_ID
    ```
* 若要檢查個別工作者節點，請檢閱下列指令輸出中的 **Labels** 欄位。
```sh {: pre}
    kubectl describe node <worker_node_private_IP>
    ```

擷取叢集裡的所有現有 ALB。檢視該指令的輸出結果。對於每個「狀態」設定為「已啟用」的 ALB，請記錄其 ALB ID 和建置版本。

ibmcloud ks ingress alb ls --cluster CLUSTER_NAME_OR_ID

輸出範例

ALB ID                                Enabled   State     Type      Load Balancer Hostname                      Zone         Build                                  Status
private-crc81nk5l10gfhdql4i3qg-alb1   true      enabled   private   e9dd35e6-us-south.lb.appdomain.cloud   us-south-3   3.7.4_348800920_iks   enabled
public-crc81nk5l10gfhdql4i3qg-alb1    true      enabled   public    38daf55c-us-south.lb.appdomain.cloud   us-south-3   3.7.4_348800920_iks   healthy

根據前一步驟的輸出結果，針對每個已啟用的 ALB 執行 ibmcloud ks ingress alb update 指令。此指令會將 ALB 重新部署到邊緣工作者節點。

當您執行此指令將 ALB 重新部署至邊緣工作節點時，ALB 也會同步更新至最新版本。若您不希望將 ALB 更新至最新版本，請加入 --version 選項，並指定前一步驟輸出結果中「Build」欄位所列的版本。
```
ibmcloud ks ingress alb update -c <cluster_name_or_ID> --alb <ALB_ID> [--version <build_version>]
```
輸出範例
```
Updating ALB pods for private-crc81nk5l10gfhdql4i3qg-alb1 to version '3.7.4_348800920_iks' in cluster crc81nk5l10gfhdql4i3qg...
OK
```

確認是否將所有 ALB Pod 都部署到了邊緣節點。每個在叢集裡啟用的公用和專用 ALB 都有兩個 Pod。

kubectl describe nodes -l dedicated=edge | grep alb

輸出範例

kube-system                private-crc81nk5l10gfhdql4i3qg-alb1-d5dd478db-27pv4    0 (0%)        0 (0%)      0 (0%)           0 (0%)
kube-system                private-crc81nk5l10gfhdql4i3qg-alb1-d5dd478db-7p9q6    0 (0%)        0 (0%)      0 (0%)           0 (0%)
kube-system                public-crc81nk5l10gfhdql4i3qg-alb1-5ff8cdff89-s77z6    0 (0%)        0 (0%)      0 (0%)           0 (0%)
kube-system                public-crc81nk5l10gfhdql4i3qg-alb1-5ff8cdff89-kvs9f    0 (0%)        0 (0%)      0 (0%)           0 (0%)

確認是否沒有任何 ALB Pod 部署到非邊緣節點。
```
kubectl describe nodes -l dedicated!=edge | grep alb
```
如果 ALB Pod 正確部署到了邊緣節點，則不會傳回任何 ALB Pod。這表示您的 ALB 已成功重新排程至僅限邊緣工作節點上。

下一步

既然您已使用 dedicated=edge 標記工作節點池中的工作節點，並將所有現有的 ALB 重新部署至邊緣節點，那麼之後新增至叢集的所有 ALB 也將部署至您的邊緣工作節點池中的邊緣節點。接下來，您可以防止其他工作負載在邊緣工作節點上執行。