自動更新の有効化

自動更新を有効にすると、ALB はデフォルトとしてマークされているバージョンに更新されます。 新しいバージョンがデフォルト・バージョンになると、ALB は自動的にそのバージョンに更新されます。

1 ゾーンに 1 台しかワーカー・ノードが存在しないクラスターで、ALB レプリカの数を 1 に設定すると、更新が適用されるたびに、その単一の ALB ポッドが削除されて新規ポッドが作成されます。 この処理は、他のゾーンにワーカーノードやALBレプリカがあっても、トラフィックの混乱を引き起こす可能性がある。 トラフィックの中断を防ぐため、各ゾーンに少なくとも2つのワーカーノードが存在し、各 ALBに2つのレプリカが存在する ようにしてください。 更新プロセス中は、新しい接続のみが 2 番目の ALB ポッドにルーティングされ、更新中の ALB ポッド上の既存の接続は安全に終了することに注意してください。 更新中に終了した既存の接続の場合は、クライアント・アプリケーションで再試行を開始します。

自動更新のための保守時間帯をスケジュール

更新を希望する時間を指定するカスタマイズされた ConfigMap を作成することで、ALB の自動更新を制御および管理できます。

自動更新の時間を設定するには、デプロイメントConfigMap で updateStartTime と updateEndTime キーを設定します。 各キーは、24 時間フォーマット (HH:MM) の割り当て時刻を表します。 この時刻は現地時間ではなく協定世界時 (UTC) で指定されていることに注意してください。

1. configmap 用の YAML ファイルを作成します。 Specify the updateStartTime, and updateEndTime fields as key-value pairs in the data field.

   次のConfigMapの例では、UTC 20:34から23:59の間にクラスタ内のALBポッドの35%を更新するように自動更新機能を設定しています。

   apiVersion: v1
   kind: ConfigMap
   metadata:
       name: ibm-ingress-deploy-config
       namespace: kube-system
   data:
       "updateStartTime": "20:34"
       "updateEndTime": "23:59"
   

2. クラスターに configmap をデプロイします。 新しいルールは、次に更新が行われるときに適用されます。

   kubectl apply -f <filename>.yaml
   

自動更新の無効化

バグ修正とセキュリティー更新を受け取るには、自動更新を有効にしたままにします。 自動更新が無効になっている場合は、ALB を手動で更新する必要があります。

ibmcloud ks ingress alb autoupdate disable -c <cluster_name_or_ID> を実行して、ALB の自動更新を無効にすることができます。

クラスターで自動更新が有効になっているかどうかを確認するには、 ibmcloud ks ingress alb autoupdate get -c <cluster_name_or_ID> コマンドを使用します。 自動更新を再度有効にすることにした場合は、 ibmcloud ks ingress alb autoupdate enable -c <cluster_name_or_ID> を実行できます。

手動更新の適用

ibmcloud ks ingress alb update コマンドを使用して、Ingress ALB ポッドの一回限りの更新を手動で適用できます。 このコマンドはデフォルトの ALB イメージ・バージョンを適用しますが、 --version オプションを含めることで別のバージョンを適用できます。 詳細情報またはコマンド・オプションについては、 CLI リファレンス を参照してください。

--version オプションを使用して ALB イメージを特定のバージョンに更新するには、 ALB の自動更新を無効にし 、指定したバージョンを実行する間は無効にしておく必要があります。 自動更新では、常にデフォルト・バージョンが適用され、適用した手動更新が上書きされます。 別のバージョンを使用する場合は、自動更新を有効にすることはできません。

• 利用可能なALBのバージョンを一覧表示するには、以下のコマンドを実行する。

  ibmcloud ks ingress alb version ls --region <region>
  

• クラスター内のすべての ALB ポッドを更新するには、以下のコマンドを実行します。

  ibmcloud ks ingress alb update -c <cluster_name_or_ID> --version <image_version>
  

• 特定の ALB の ALB を更新するには、以下のコマンドを実行します。

  ibmcloud ks ingress alb update -c <cluster_name_or_ID> --version <image_version> --alb <ALB_ID> [--alb <ALB_2_ID> ...]
  

サポートされるイメージ・バージョンの表示

サポートされている最新 3 つのバージョンをイメージのタイプごとにリスト表示するには、以下のコマンドを実行します。

ibmcloud ks ingress alb versions

出力例

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

Kubernetes Ingress バージョンはフォーマット <community_version>_<ibm_build>_iks に従います。 IBM ビルド番号は、IBM Cloud Kubernetes Service でリリースされた最新の Kubernetes Ingress NGINX リリースを示しています。 例えば、バージョン 1.1.2_2507_iks は、0.47.0 Ingress NGINX バージョンの最新のビルドを示します。 IBM Cloud Kubernetes Service では、脆弱性に対処するために、コミュニティー・イメージ・バージョンのビルドをリリースする場合もあります。

Ingressイメージの各バージョンにおける変更点については、Ingressバージョン変更ログ を参照してください。

以前のバージョンに戻す

ALBポッドが最近アップデートされたが、ALBのカスタム設定が最新のイメージバージョンのビルドに影響される場合、ibmcloud ks ingress alb update コマンドに --version オプションを付けて使用することで、ALBポッドをサポートされている以前のバージョンにロールバックすることができます。 ALB を変更するイメージ・バージョンは、ibmcloud ks ingress alb versions の出力にリストされている、サポートされるイメージ・バージョンである必要があります。

旧バージョンに戻す場合は、 自動 ALB 更新を無効にして 、旧バージョンを実行する間は無効にしておく必要があることに注意してください。 自動更新では、常に最新バージョンが適用され、適用した手動更新が上書きされます。 以前のバージョンを使用する場合は、自動更新を有効にすることはできません。

ゾーン内に追加の ALB を作成する

ゾーン内の各 ALB は、異なるワーカー・ノード上の 2 つのポッドとしてデプロイされます。 ALB 処理能力を拡大し、より多くの接続を処理するために、ゾーン内に追加の ALB を作成できます。 新しい ALB の IP アドレスが自動的に Ingress サブドメインに追加されます。

マルチゾーン・クラスターを作成すると、ワーカー・ノードが存在する各ゾーンにデフォルトのパブリック ALB が作成されます。 後でこれら元の3つのゾーンの1つを削除し、別のゾーンにワーカーを追加した場合、デフォルトのパブリックALBはその新しいゾーンには作成されない。 その新しいゾーンの接続を処理するために、ALB を手動で作成することができます。

Ingress リソース検証を使用すると、すべての作成要求と更新要求がすべての ALB によって検証されます。 特定の ALB インスタンスに対してポッドが実行されていない場合、クラスターに Ingress リソースを適用できない可能性があります。 ALB ごとに少なくとも 1 つの実行中のポッドが有効になっていることを確認します。 詳しくは、 Ingress デプロイメントのカスタマイズに関するリファレンス を参照してください。

1. ワーカー・ノードが存在するゾーンごとに 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]
   

   以下のコマンドは、 VPC クラスターに適用されます。 詳細情報およびコマンド・オプションについては、 CLI リファレンス を参照してください。

   ibmcloud ks ingress alb create vpc-gen2 --cluster <cluster_name_or_ID> --type <public_or_private> --zone <vpc_zone> [--version image_version]
   

2. 各ゾーンに作成した ALB の 状況 が enabled であることを確認します。 クラシック・クラスターの場合は、 ALB IP が割り当てられていることを確認します。 VPC クラスターの場合は、 「ロード・バランサーのホスト名 (Load Balancer Hostname)」 が割り当てられていることを確認します。

   ibmcloud ks ingress alb ls --cluster <cluster_name_or_ID>
   

   クラシッククラスタの出力例。

   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       -
   

   VPCクラスタの出力例。

   ALB ID                                            Enabled   Status     Type      Load Balancer Hostname                 Zone         Build
   private-crdf253b6025d64944ab99ed63bb4567b6-alb1   false     disabled   private   -                                      us-south-2   ingress:1.1.2_2507_iks
   private-crdf253b6025d64944ab99ed63bb4567b6-alb2   false     disabled   private   -                                      us-south-1   ingress:1.1.2_2507_iks
   public-crdf253b6025d64944ab99ed63bb4567b6-alb1    true      enabled    public    23f2dfb1-us-south.lb.appdomain.cloud   us-south-2   ingress:1.1.2_2507_iks
   public-crdf253b6025d64944ab99ed63bb4567b6-alb2    true      enabled    public    23f2dfb1-us-south.lb.appdomain.cloud   us-south-1   ingress:1.1.2_2507_iks
   
   

ALBポッドのレプリカ数の変更

デフォルトでは、各 ALB のレプリカは 2 つです。 ALB ポッドの数を手動で変更するか、動的な自動スケーリングを有効にすることで、ALB 処理機能をカスタマイズできます。

単一の ALB ポッドで大量の要求を処理できます。 タイムアウト、低速な応答、またはその他の過負荷の兆候が発生した場合は、バックエンド・アプリケーションの状態を確認してください。 ALB ポッドをスケーリングする前に、ALB がアプリケーションのボトルネックであることを確認してください。そうでないと、予期した結果が得られない可能性があります。

クラシック・クラスターの場合: ALB のロード・バランサー・サービス構成の externalTrafficPolicy が Local に設定されている場合は、2 レプリカより上にスケーリングしないでください。 クラシック・ロード・バランサーは、2 つのレプリカの固定構成で実行され、ロード・バランサー・ポッドと同じノードにある ALB ポッドにのみトラフィックを転送できます。

デフォルトでは、Ingress バージョンの定期更新が自動的に ALB にロールアウトされます。 1 ゾーンに 1 台しかワーカー・ノードが存在しないクラスターで、ALB レプリカの数を 1 に設定すると、更新が適用されるたびに、その単一の ALB ポッドが削除されて新規ポッドが作成されます。 このプロセスによって、他のゾーンにワーカー・ノードと ALB レプリカが存在する場合でもトラフィックが中断する可能性があります。 トラフィックの中断を防ぐために、各ゾーンにワーカー・ノードが 2 台以上存在し、ALB ごとにレプリカが 2 つ存在するようにしてください。 更新プロセス中は、新しい接続のみが 2 番目の ALB ポッドにルーティングされ、更新中の ALB ポッド上の既存の接続は安全に終了することに注意してください。 クライアント・アプリケーションは、更新中に終了した既存の接続に対して再試行を開始することをお勧めします。

ConfigMapを作成して、ALB レプリカの数を手動で変更します。 動的スケーリングを使用するように ALB を構成 している場合は、ALB レプリカを手動でスケーリングすることはできません。

1. ALB の ID を取得します。

   ibmcloud ks ingress alb ls -c <cluster_name_or_ID>
   

2. ibm-ingress-deploy-config 構成マップの YAML ファイルを作成します。 ALB ごとに '{"replicas":<number_of_replicas>}' を追加します。 この例では、ALB ポッドの数を 4 つのレプリカに増やします。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ibm-ingress-deploy-config
     namespace: kube-system
   data:
     <alb1-id>: '{"replicas":4}'
     <alb2-id>: '{"replicas":4}'
     ...
   

3. クラスターに ibm-ingress-deploy-config 構成マップを作成します。

   kubectl create -f ibm-ingress-deploy-config.yaml
   

4. 変更を適用するには、ALBを更新する。 変更が適用されるまで5分ほどかかる場合がありますのでご注意ください。

   ibmcloud ks ingress alb update -c <cluster_name_or_ID>
   

5. ALBポッドの数が、指定したレプリカの数まで増加していることを確認します Ready

   kubectl get pods -n kube-system | grep alb
   

動的 ALB 自動スケーリングを構成するためのコマンド例

平均 CPU 使用率 60% に基づく動的スケーリングのコマンド例。

ibmcloud ks ingress alb autoscale set -c <cluster_name_or_ID> --alb <alb-id> --min-replicas 2 --max-replicas 5 --cpu-average-utilization 60

my-custom-metrics.yaml という名前のファイルに保管されているカスタム・メトリックに基づく動的スケーリングのコマンド例。

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 使用率を計算できます。

ALB 自動スケーリングの無効化

次のコマンドを実行して、ALB の自動スケーリングを無効にします。

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