Ingressリソースをエッジワーカーノードに隔離する

ALB ポッドをエッジワーカーノードに割り当てるには、ゾーンごとに少なくとも 2 つのエッジワーカーノードを含むワーカープールを作成するか、既存のワーカープールを使用する必要があります。 これにより、ALBポッドのスケジューリング先となるエッジノードが常に確保されるようになります。

ALB ポッドを更新すると、新しいポッドが展開され、既存のポッドが置き換えられます。 更新中もALBを利用可能に保つため、ローリング更新では1つずつポッドを置き換え、常に少なくとも1つのALBポッドが稼働した状態を維持します。 ただし、ALBポッドには、2つのALBポッドが同じワーカー上で実行されるのを防ぐアンチアフィニティルールが設定されています。 ゾーン内にエッジノードが少なくとも2つ存在する場合、新しいALBポッドをそのうちの1つに置き換えることができ、もう1つは引き続き稼働し続けます。

ALBの高可用性を確保するため、各リージョンに十分な数のエッジノードがない場合、エッジノードのラベルは無視され、ALBポッドはエッジノード以外のノードにもスケジューリングされます。

ALB ワークロードをエッジノードに分離する手順は、クラシックインフラストラクチャと VPC インフラストラクチャのいずれの場合も同様です。 ただし、ALBの外部IPの命名規則は、タイプごとに異なります。 クラシック・インフラストラクチャー上のALBの場合、外部IPアドレスは 169.46.17.2 のような標準的なIPアドレスとなります。 VPC インフラストラクチャ上の ALB の場合、外部 IP は f3bee8b5-us-south.lb.appdomain.cloud のようなホスト名となります。

開始前に

ワークロードをエッジワーカーノードに分離する

ワークロードをエッジワーカーノードに隔離するには：

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

  2. 上記のワーカー・プールとワーカー・ノードに 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>
    ```

  3. クラスター内のすべての既存の 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

  4. 前のステップの出力を使用して、有効な 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

  5. すべての ALB ポッドがエッジ・ノードにデプロイされていることを確認します。 クラスター内で使用可能なそれぞれのパブリック ALB とプライベート ALB には 2 つのポッドがあります。

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

  6. どの ALB ポッドも非エッジ・ノードにデプロイされていないことを確認します。

    kubectl describe nodes -l dedicated!=edge | grep alb

    ALB ポッドがエッジ・ノードに正しくデプロイされている場合は、ALB ポッドは返されません。 これは、ALBがエッジワーカーノードのみに正常に再スケジュールされたことを意味します。

次のステップ

dedicated=edge を使用してワーカープール内のワーカーノードにラベルを付け、既存のすべての ALB をエッジノードに再デプロイしたため、今後クラスターに追加される ALB もすべて、エッジワーカープール内のエッジノードにデプロイされるようになります。 次に、他の エッジワーカーノードでのワークロードの実行 を防止することができます。