ALB の更新

IBM Cloud Kubernetes Service は、新機能を提供し、セキュリティーの脆弱性に対処するために、ALB バージョンを定期的にリリースしています。 ibmcloud ks ingress alb versions コマンドを使用して、使用可能なバージョンをリストするか、バージョン履歴の Ingress ALB のバージョン変更ログ を確認します。

ALBバージョンは「 <ingress_nginx_version>_<ibm_build>_iks 」という形式に従っており、ここで「 <ingress_nginx_version> 」は Kubernetes Ingress NGINX コントローラーの バージョンを表し、「 <ibm_build> 」の数字は IBM Cloud Kubernetes Service のビルドバージョンを示しています。

ALB は、デフォルト・バージョンに自動的に更新することも、自動更新を無効にして ALB バージョンを手動で管理することもできます。

サポートされるイメージ・バージョンの選択

IBM Cloud Kubernetes Service は、クラスター内の Ingress アプリケーション・ロード・バランサー (ALB) の Kubernetes Ingress イメージのみをサポートしています。 Kubernetes Ingress イメージは、NGINX Ingress コントローラーのコミュニティー Kubernetes プロジェクトの実装で構築されます。 以前にサポートされていた IBM Cloud Kubernetes Service Ingress イメージは、NGINX Ingress コントローラーのカスタム実装環境に基づいて構築されていましたが、サポートされません。

2020 年 12 月 1 日以降に作成されたクラスター: デフォルトのアプリケーション・ロード・バランサー (ALB) は、すべての新しい IBM Cloud Kubernetes Service クラスター内で Kubernetes Ingress イメージを実行します。

2020 年12 月 1 日より前に作成されたクラスター:

• カスタム IBM Ingress イメージを実行する ALB がある既存のクラスターは、引き続き現状のまま作動します。
• カスタム IBM Ingress イメージのサポートは、2021 年 6 月 2 日に終了します。
• 既存の Ingress セットアップをマイグレーションして、新しい Kubernetes Ingress に移行する必要があります。 既存の ALB やその他の Ingress リソースは、新しい Kubernetes Ingress イメージに自動的にマイグレーションされません。
• サポートされないイメージを含む ALB はすべて引き続き実行されますが、IBM のサポート対象外となります。

新しい ALB を作成 するとき、以前に無効にされた ALB を有効にする とき、または [ALB を手動で更新 (#update-alb) する]ときに、 --version オプションを使用して ALB のイメージ・バージョンを指定できます。 既存のALBを有効化または更新する際に、 --version オプションを省略した場合、ALBは以前実行されていたのと同じイメージのデフォルトバージョンを実行します。具体的には、 Kubernetes Ingressイメージ、または IBM Cloud Kubernetes Service Ingressイメージのいずれかになります。

自動更新では、デフォルト・バージョンのみが適用されます。 デフォルト以外のバージョンを指定 するには、 ibmcloud ks ingress alb autoupdate disable コマンドを実行して、自動更新を無効にする必要があります。

ibmcloud ks ingress alb versions

Kubernetes Ingress versions
1.1.2_2507_iks (default)
1.2.1_2506_iks
0.35.0_1374_iks

ALB の手動スケーリング

各ALBは、1秒あたり約20,000件の接続を処理できます。 追加の接続を処理する必要がある場合は、1 つのゾーンに追加の ALB を作成するか、ALB ポッドのレプリカの数を増やすことができます。

自動スケーリング機能を使用した ALB の動的スケーリング

動的スケーリングを使用すると、ALB レプリカの数は実際の負荷に基づいて自動的に変更されます。 レプリカの数は、実際の負荷が低くなると減少し、負荷が高くなると増加します。これにより、ピーク時にトラフィックを処理する能力を維持しながら、計算能力を節約できます。 CPU 使用率に基づいてスケーリングを実装するように ALB 自動スケーリング機能を構成することも、定義したカスタム・メトリックに基づいてスケーリングを実装するように ALB 自動スケーリング機能を構成することもできます。

オートスケーリングを設定するには、次のコマンドを実行してください。 --cpu-average-utilization オプションを組み込むことにより、CPU 使用率に基づいてスケーリングできます。 あるいは、 --custom-metrics-file オプションを組み込んで構成ファイル・パスを指定することにより、カスタム・メトリックに基づいてスケーリングすることができます。

ibmcloud ks ingress alb autoscale set --alb ALB --cluster CLUSTER --max-replicas NUM_REPLICAS --min-replicas NUM_REPLICAS [--output OUTPUT] [-q] (--cpu-average-utilization PERCENT | --custom-metrics-file FILE)

--cluster, -c CLUSTER

必須: クラスターの名前または ID。

--alb ALB

ALB ID。 使用可能な ALB ID を確認するには、 ibmcloud ks ingress alb ls を実行します。

--max-replicas REPLICAS:

ALBのレプリカの最大数。 整数を指定してください。 ALB レプリカの最大数は、クラスター上のワーカー・ノードの数に制限されます。 クラスターにワーカー・ノードを追加するには、 クラシック・クラスターへのワーカー・ノードの追加 または VPC クラスターへのワーカー・ノードの追加 を参照してください。

--min-replicas REPLICAS

ALB のレプリカの最小数。 少なくとも 2 の整数を指定してください。

--cpu-average-utilization PERCENT

平均 CPU 使用率を使用した自動スケーリング: 自動スケーリング機能のターゲット CPU 使用率。 この平均は、すべての ALB ポッドについて、要求された CPU と比較した使用 CPU の割合を表します。 ALB ポッドによる現在の CPU 使用量を確認するには、 kubectl top pods -n kube-system -l app=ALB_ID を実行します。 ALB ポッドに要求された CPU 量を確認するには、 kubectl get deployment -n kube-system ALB_ID -o=jsonpath='{.spec.template.spec.containers[0].resources.requests.cpu} を実行します。 このオプションは、「 --custom-metrics-file 」オプションと併用することはできません。

--custom-metrics-file FILE

カスタム・メトリックを使用した自動スケーリング: 自動スケーリングのカスタム・メトリックとターゲット値を定義する構成ファイルの名前を指定します。 Prometheusなどのメトリック・プロバイダーをインストールして構成する必要があることに注意してください。 このオプションは、「 --cpu-average-utilization 」オプションと併用することはできません。

カスタム・メトリック YAML ファイルの例。 YAML ファイルでカスタム・メトリックを構成します。 ファイルを保存し、 --custom-metrics-file コマンド・オプションを使用してファイル名を指定します。 カスタムメトリクス仕様ファイルの作成に関する詳細は、 Kubernetes の「 水平ポッド自動スケーリング 」ドキュメントまたは MetricSpec の API ドキュメントを参照してください。

- type: Object
  object:
    metric:
      name: example_metrics
    describedObject:
      apiVersion: networking.k8s.io/v1
      kind: Ingress
      name: example-ingress
    target:
      type: Value
      value: 2k

ibmcloud ks ingress alb autoscale set -c CLUSTER_NAME_OR_ID --alb ALB_ID --min-replicas 2 --max-replicas 5 --cpu-average-utilization 60

ibmcloud ks ingress alb autoscale set -c CLUSTER_NAME_OR_ID --alb ALB_ID --min-replicas 2 --max-replicas 5 --custom-metrics-file my-custom-metrics.yaml

平均 CPU 使用率の計算

以下のイメージは、自動スケーリング構成を計画する際に CPU 使用量を判別するシナリオの例を示しています。

着信トラフィックがない 2 つの ALB レプリカが実行されているアイドル・クラスターがあるとします。 この場合の CPU 要求の合計は 2*20m=40m です。 一方のレプリカが 5m CPU ともう一方の 7m CPU を使用する可能性があります。 以下の公式を使用して、CPU 使用率を計算できます。

ibmcloud ks ingress alb autoscale unset --alb ALB --cluster CLUSTER

ALB の無効化

ALB をスケールダウンするには、クラスター内のトラフィックをルーティングしないように ALB を無効にします。

ibmcloud ks ingress alb disable --alb ALB_ID -c CLUSTER_NAME_OR_ID

ALBは、いつでも次のコマンドを実行することで再有効化できます。 ibmcloud ks ingress alb enable classic --alb ALB_ID -c CLUSTER_NAME_OR_ID （クラシッククラスターの場合）または ibmcloud ks ingress alb enable vpc-gen2 --alb ALB_ID -c CLUSTER_NAME_OR_ID を実行することで、ALBをいつでも再有効化できます。

クラシック・クラスタにおけるVLAN間のALBの移動

このトピックの情報は、クラシック・クラスターにのみ該当します。

ワーカー・ノードの VLAN 接続を変更すると、ワーカー・ノードは新規 VLAN に接続され、新規のパブリック IP アドレスまたはプライベート IP アドレスを割り当てられます。 ただし、ALB には、安定したポータブル・パブリック/プライベート IP アドレスが、古い VLAN に属するサブネットから割り当てられるため、ALB は新しい VLAN に自動的には移行できません。 ワーカー・ノードと ALB が別々の VLAN に接続されている場合、ALB はアプリ・ポッドへの着信ネットワーク・トラフィックをワーカー・ノードに転送できません。 ALB を別の VLAN に移動する場合は、新しい VLAN に ALB を作成し、古い VLAN の ALB を無効にする必要があります。 クラスター内のすべてのパブリック ALB は、IBM によって割り当てられる同じ Ingress サブドメインを共有します。 新しい ALB を作成するときに、Ingress リソース・ファイルを変更する必要はありません。

VLAN からすべてのワーカーを削除すると、VLAN のゾーン内の ALB の IP アドレスが削除されます。

1. ワーカー・ノードの接続先を変更した新しいパブリック VLAN またはプライベート VLAN をゾーンごとに取得します。

   1. ゾーンのワーカーの詳細をリストします。

       ibmcloud ks worker get --cluster CLUSTER_NAME_OR_ID --worker WORKER_ID
       ```
   2. 出力に表示されるパブリック VLAN またはプライベート VLAN の **ID** をメモします。
       * パブリック ALB を作成する場合は、パブリック VLAN の ID をメモします。
       * プライベート ALB を作成する場合は、プライベート VLAN の ID をメモします。
   
   3. 各ゾーンのワーカーでこの手順を繰り返し、各ゾーンの新しいパブリック VLAN またはプライベート VLAN の ID を確認します。
   
   

2. ゾーンごとに新しい VLAN で ALB を作成します。 このコマンドのパラメーターについて詳しくは、CLI リファレンスを参照してください。

   ibmcloud ks ingress alb create --cluster CLUSTER_NAME_OR_ID --type PUBLIC_OR_PRIVATE --zone ZONE --vlan VLAN_ID [--ip IP_ADDRESS] [--version image_version]
   

3. 各ゾーンの新しい VLAN 上に作成した ALB の**「Status」**がenabledで、ALB IP アドレスが割り当てられていることを確認します。

   ibmcloud ks ingress alb ls --cluster CLUSTER_NAME_OR_ID
   

   2294030 の VLAN dal12 と 2234940 の VLAN dal10 に新しいパブリック ALB が作成されたクラスターの出力例。

   ALB ID                                            Enabled   Status     Type      ALB IP          Zone    Build                          ALB VLAN ID   NLB Version
   private-crdf253b6025d64944ab99ed63bb4567b6-alb1   false     disabled   private   -               dal12   ingress:1.1.2_2507_iks   2294021
   private-crdf253b6025d64944ab99ed63bb4567b6-alb2   false     disabled   private   -               dal10   ingress:1.1.2_2507_iks   2234947
   public-crdf253b6025d64944ab99ed63bb4567b6-alb1    true      enabled    public    169.48.228.78   dal12   ingress:1.1.2_2507_iks   2294019
   public-crdf253b6025d64944ab99ed63bb4567b6-alb2    true      enabled    public    169.46.17.6     dal10   ingress:1.1.2_2507_iks   2234945
   public-crdf253b6025d64944ab99ed63bb4567b6-alb3    true      enabled    public    169.49.28.09    dal12   ingress:1.1.2_2507_iks   2294030
   public-crdf253b6025d64944ab99ed63bb4567b6-alb4    true      enabled    public    169.50.35.62    dal10   ingress:1.1.2_2507_iks   2234940
   

4. 古い VLAN に接続されている各 ALB を無効にします。

   ibmcloud ks ingress alb disable --alb OLD_ALB_ID -c CLUSTER_NAME_OR_ID
   

5. 古い VLAN に接続されている各 ALB の Status が disabled になっていることを確認します。 新しい VLAN に接続されている ALB のみが、着信ネットワーク・トラフィックを受信し、アプリ・ポッドと通信しています。

   ibmcloud ks ingress alb ls --cluster CLUSTER_NAME_OR_ID
   

   2294019 の VLAN dal12 と 2234945 の VLAN dal10 でデフォルトのパブリック ALB が無効にされたクラスターの出力例。

   ALB ID                                            Enabled   Status     Type      ALB IP          Zone    Build
   private-crdf253b6025d64944ab99ed63bb4567b6-alb1   false     disabled   private   -               dal12   ingress:1.1.2_2507_iks   2294021
   private-crdf253b6025d64944ab99ed63bb4567b6-alb2   false     disabled   private   -               dal10   ingress:1.1.2_2507_iks   2234947
   public-crdf253b6025d64944ab99ed63bb4567b6-alb1    false     disabled   public    169.48.228.78   dal12   ingress:1.1.2_2507_iks   2294019
   public-crdf253b6025d64944ab99ed63bb4567b6-alb2    false     disabled   public    169.46.17.6     dal10   ingress:1.1.2_2507_iks   2234945
   public-crdf253b6025d64944ab99ed63bb4567b6-alb3    true      enabled    public    169.49.28.09    dal12   ingress:1.1.2_2507_iks   2294030
   public-crdf253b6025d64944ab99ed63bb4567b6-alb4    true      enabled    public    169.50.35.62    dal10   ingress:1.1.2_2507_iks   2234940
   

6. パブリック ALB の場合のオプション: 新しい ALB の IP アドレスがクラスターの IBM 提供 Ingress サブドメインの下にリストされていることを確認します。 このサブドメインを見つけるには、 ibmcloud ks cluster get --cluster CLUSTER_NAME_OR_ID を実行します。

   nslookup <Ingress_subdomain>
   

   出力例

   Non-authoritative answer:
   Name:    mycluster-<hash>-0000.us-south.containers.appdomain.cloud
   Addresses:  169.49.28.09
           169.50.35.62
   

7. オプション: 古い VLAN 上のサブネットが不要になった場合は、それらを削除できます。

ALBでポート80を管理する

2026年1月26日以降に作成されたVPCクラスターでは、すべてのALBに対してポート80がデフォルトでブロックされます。 それ以前に作成されたクラスタは影響を受けません。

以下のコマンドを使ってALBのポート80を管理できる。 加えた変更はクラスタ内のすべてのALBに適用されることに注意してください。

• ALBのポート80のステータスを取得するには、以下のコマンドを実行する。

  ibmcloud ks ingress security port80 get --cluster CLUSTER_NAME_OR_ID
  

• ALBでポート80を有効にするには、以下のコマンドを実行する。

  ibmcloud ks ingress security port80 enable --cluster CLUSTER_NAME_OR_ID
  

• ALBでポート80を無効にするには、以下のコマンドを実行する。

  ibmcloud ks ingress security port80 disable --cluster CLUSTER_NAME_OR_ID