7.4. ルートベースのデプロイメントストラテジーの使用

手順

1. Networking Routes ページに移動します。
2. 編集するルートの横にある Actions メニューをクリックし、Edit Route を選択します。
3. YAML ファイルを編集します。weight を 0 から 256 の間の整数になるように更新します。これは、他のターゲット参照オブジェクトに対するターゲットの相対的な重みを指定します。値 0 はこのバックエンドへの要求を抑制します。デフォルトは 100 です。オプションについての詳細は、oc explain routes.spec.alternateBackends を実行します。
4. Save をクリックします。

1. Networking Routes ページに移動します。
2. Create Route をクリックします。
3. ルートの Name を入力します。
4. Service を選択します。
5. Add Alternate Service をクリックします。
6. Weight および Alternate Service Weight の値を入力します。他のターゲットとの相対的な重みを示す 0 から 255 の間の数字を入力します。デフォルトは 100 です。
7. Target Port を選択します。
8. Create をクリックします。

手順

1. サービスおよび対応する重みのルートによる負荷分散を管理するには、oc set route-backends コマンドを使用します。

   $ oc set route-backends ROUTENAME \
       [--zero|--equal] [--adjust] SERVICE=WEIGHT[%] [...] [options]

   たとえば、以下のコマンドは ab-example-a に weight=198 を指定して主要なサービスとし、ab-example-b に weight=2 を指定して 1 番目の代用サービスとして設定します。

   $ oc set route-backends ab-example ab-example-a=198 ab-example-b=2

   つまり、99% のトラフィックはサービス ab-example-a に、1% はサービス ab-example-b に送信されます。

   このコマンドでは、デプロイメントはスケーリングされません。要求の負荷を処理するのに十分な Pod がある状態でこれを実行する必要があります。

2. フラグなしのコマンドを実行して、現在の設定を確認します。

   $ oc set route-backends ab-example

   出力例

   NAME                    KIND     TO           WEIGHT
   routes/ab-example       Service  ab-example-a 198 (99%)
   routes/ab-example       Service  ab-example-b 2   (1%)

3. --adjust フラグを使用すると、個別のサービスの重みを、それ自体に対して、または主要なサービスに対して相対的に変更できます。割合を指定すると、主要サービスまたは 1 番目の代用サービス (主要サービスを設定している場合) に対して相対的にサービスを調整できます。他にバックエンドがある場合には、重みは変更に比例した状態になります。

   以下の例では、ab-example-a および ab-example-b サービスの重みを変更します。

   $ oc set route-backends ab-example --adjust ab-example-a=200 ab-example-b=10

   または、パーセンテージを指定してサービスの重みを変更します。

   $ oc set route-backends ab-example --adjust ab-example-b=5%

   パーセンテージ宣言の前に + を指定すると、現在の設定に対して重み付けを調整できます。以下に例を示します。

   $ oc set route-backends ab-example --adjust ab-example-b=+15%

   --equal フラグでは、全サービスの weight が 100 になるように設定します。

   $ oc set route-backends ab-example --equal

   --zero フラグは、全サービスの weight を 0 に設定します。すべての要求に対して 503 エラーが返されます。

   注記

   ルートによっては、複数のバックエンドまたは重みが設定されたバックエンドをサポートしないものがあります。

手順

1. すべてのシャードに共通の ab-example=true ラベルを追加して新規アプリケーションを作成します。

   $ oc new-app openshift/deployment-example --name=ab-example-a --as-deployment-config=true --labels=ab-example=true --env=SUBTITLE\=shardA
   $ oc delete svc/ab-example-a

   アプリケーションがデプロイされ、サービスが作成されます。これは最初のシャードです。

2. ルートを使用してアプリケーションを利用できるようにしてください (または、サービス IP を直接使用してください)。

   $ oc expose deployment ab-example-a --name=ab-example --selector=ab-example\=true
   $ oc expose service ab-example

3. ab-example-<project_name>.<router_domain> でアプリケーションを参照し、v1 イメージが表示されることを確認します。

4. 1 つ目のシャードと同じソースイメージおよびラベルに基づくが、別のバージョンがタグ付けされたバージョンと一意の環境変数を指定して 2 つ目のシャードを作成します。

   $ oc new-app openshift/deployment-example:v2 \
       --name=ab-example-b --labels=ab-example=true \
       SUBTITLE="shard B" COLOR="red" --as-deployment-config=true
   $ oc delete svc/ab-example-b

5. この時点で、いずれの Pod のセットもルートで提供されます。しかし、両ブラウザー (接続を開放) とルーター (デフォルトでは cookie を使用) で、バックエンドサーバーへの接続を維持しようとするので、シャードが両方返されない可能性があります。

   1 つのまたは他のシャードに対してブラウザーを強制的に実行するには、以下を実行します。

   1. oc scale コマンドを使用して、ab-example-a のレプリカを 0 に減らします。

      $ oc scale dc/ab-example-a --replicas=0

      ブラウザーを更新して、v2 および shard B (赤) を表示させます。

   2. ab-example-a を 1 レプリカに、ab-example-b を 0 にスケーリングします。

      $ oc scale dc/ab-example-a --replicas=1; oc scale dc/ab-example-b --replicas=0

      ブラウザーを更新して、v1 および shard A (青) を表示します。

6. いずれかのシャードでデプロイメントをトリガーする場合、そのシャードの Pod のみが影響を受けます。どちらかの Deployment オブジェクトで SUBTITLE 環境変数を変更してデプロイメントをトリガーできます。

   $ oc edit dc/ab-example-a

   または

   $ oc edit dc/ab-example-b