第30章 高可用性
30.1. 概要
このトピックでは、OpenShift Container Platform クラスターの Pod およびサービスの高可用性の設定について説明します。
IP フェイルオーバーは、ノードセットの仮想 IP (VIP) アドレスのプールを管理します。セットのすべての VIP はセットから選択されるノードによって提供されます。VIP は単一ノードが利用可能である限り提供されます。ノード上で VIP を明示的に配布する方法がないため、VIP のないノードがある可能性も、多数の VIP を持つノードがある可能性もあります。ノードが 1 つのみ存在する場合は、すべての VIP がそのノードに配置されます。
VIP はクラスター外からルーティングできる必要があります。
IP フェイルオーバーは各 VIP のポートをモニターし、ポートがノードで到達可能かどうかを判別します。ポートが到達不能な場合、VIP はノードに割り当てられません。ポートが 0
に設定されている場合、このチェックは抑制されます。check スクリプトは必要なテストを実行します。
IP フェイルオーバーは Keepalived を使用して一連のホストでの外部からアクセスできる VIP アドレスのセットをホストします。各 VIP は 1 度に 1 つのホストによって提供されます。Keepalived は VRRP プロトコルを使用して (一連のホストの) どのホストがどの VIP を提供するかを判別します。ホストが利用不可の場合や Keepalived が監視しているサービスが応答しない場合は、VIP は一連のホストの内の別のホストに切り換えられます。したがって、VIP はホストが利用可能である限り常に提供されます。
Keepalived を実行するホストが check スクリプトを渡す場合、ホストはプリエンプションストラテジー に応じて、その優先順位および現在の MASTER の優先順位に基づいて MASTER 状態になります。
管理者は、状態が変更されるたびに呼び出されるスクリプトを --notify-script=
オプションを使用して提供できます。Keepalived は VIP を提供する場合は MASTER 状態に、別のノードが VIP を提供する場合は BACKUP 状態に、または check スクリプトが失敗する場合は FAULT 状態になります。notify スクリプトは、状態が変更されるたびに新規の状態で呼び出されます。
OpenShift Container Platform は、oc adm ipfailover
コマンドの実行による IP フェイルオーバーのデプロイメント設定の作成をサポートします。IP フェイルオーバーのデプロイメント設定は VIP アドレスのセットを指定し、それらの提供先となるノードのセットを指定します。クラスターには複数の IP フェイルオーバーのデプロイメント設定を持たせることができ、それぞれが固有な VIP アドレスの独自のセットを管理します。IP フェイルオーバー設定の各ノードは IP フェイルオーバー Pod として実行され、この Pod は Keepalived を実行します。
VIP を使用してホストネットワーク (例: ルーター) を持つ Pod にアクセスする場合、アプリケーション Pod は ipfailover Pod を実行しているすべてのノードで実行されている必要があります。これにより、いずれの ipfailover ノードもマスターになり、必要時に VIP を提供することができます。アプリケーション Pod が ipfailover のすべてのノードで実行されていない場合、一部の ipfailoverノードが VIP を提供できないか、または一部のアプリケーション Pod がトラフィックを受信できなくなります。この不一致を防ぐために、ipfailover とアプリケーション Pod の両方に同じセレクターとレプリケーション数を使用します。
VIP を使用してサービスにアクセスする場合には、いずれのノードもノードの ipfailover セットに入れることができます。それは、(アプリケーション Pod が実行されている場所を問わず) サービスはすべてのノードで到達可能であるためです。ipfailover ノードのいずれもいつでもマスターにすることができます。サービスは外部 IP およびサービスポートを使用するか、または nodePort を使用することができます。
サービス定義で外部 IP を使用する場合、VIP は外部 IP に設定され、ipfailover のモニターポートはサービスポートに設定されます。nodePort はクラスターのすべてのノードで開かれ、サービスは VIP をサポートしているいずれのノードからのトラフィックについても負荷分散を行います。この場合、ipfailover のモニターノードはサービス定義で nodePort に設定されます。
nodePort のセットアップは特権付きの操作で実行されます。
サービス VIP の可用性が高い場合でも、パーマンスは依然として影響を受けます。keepalived はそれぞれの VIP が設定内のノードによって提供されるようにし、他のノードに VIP がない場合でも複数の VIP が同じノードに配置されることがあります。ipfailover が複数の VIP を同じノードに配置する場合、外部から一連の VIP 間で負荷分散を行う方法は失敗する可能性があります。
ingressIP を使用する場合は、ipfailover を ingressIP 範囲と同じ VIP 範囲を持つように設定できます。また、モニターポートを無効にすることもできます。この場合、すべての VIP がクラスター内の同じノードに表示されます。すべてのユーザーが ingressIP でサービスをセットアップし、これを高い可用性のあるサービスにすることができます。
クラスター内の VIP の最大数は 255 です。
30.2. IP フェイルオーバーの設定
oc adm ipfailover
コマンドを適切なオプションと共に使用し、ipfailover デプロイメント設定を作成します。
現時点で、ipfailover はクラウドインフラストラクチャーと互換性がありません。AWS の場合、AWS コンソールの使用により Elastic Load Balancer (ELB) で OpenShift Container Platform の高可用性を維持することができます。
管理者は、クラスター全体に ipfailover を設定することも、ラベルセレクターの定義に基づいてノードのサブセットに ipfailover を設定することもできます。また、複数の IP フェイルオーバーのデプロイメント設定をクラスター内に設定することもでき、それぞれの設定をクラスター内で相互に切り離すことができます。oc adm ipfailover
コマンドは ipfailover デプロイメント設定を作成し、これによりフェイルオーバー Pod が使用される制約またはラベルに一致する各ノードで実行されるようにします。この Pod は、すべての Keepalived デーモン間で VRRP (Virtual Router Redundancy Protocol) を使用する Keepalived を実行し、監視されるポートでサービスが利用可能であることを確認し、利用可能でない場合は Keepalived が仮想 IP (VIP) を自動的に浮動させます。
実稼働環境で使用する場合には、2 つ以上のノードで --selector=<label>
を使用してノードを選択するようにします。また、指定のラベルが付けられたセレクターのノード数に一致する --replicas=<n>
値を設定します。
oc adm ipfailover
コマンドには、Keepalived を制御する環境変数を設定するコマンドラインオプションが含まれます。環境変数は OPENSHIFT_HA_*
で開始され、必要に応じて変更できます。
たとえば、以下のコマンドは router=us-west-ha
のラベルが付けられたノードのセレクションに対して IP フェイルオーバー設定を作成します (7 仮想 IP を持つ 4 ノードで、ルータープロセスなどのポート 80 でリッスンするサービスをモニタリング)。
$ oc adm ipfailover --selector="router=us-west-ha" \ --virtual-ips="1.2.3.4,10.1.1.100-104,5.6.7.8" \ --watch-port=80 --replicas=4 --create
30.2.1. 仮想 IP アドレス
Keepalived は一連の仮想 IP アドレス (VIP) を管理します。管理者はこれらすべてのアドレスについて以下の点を確認する必要があります。
- 仮想 IP アドレスは設定されたホストでクラスター外からアクセスできる。
- 仮想 IP アドレスはクラスター内でこれ以外の目的で使用されていない。
各ノードの Keepalived は、必要とされるサービスが実行中であるかどうかを判別します。実行中の場合、VIP がサポートされ、Keepalived はネゴシエーションに参加してそのノードが VIP を提供するかを決定します。これに参加するノードについては、このサービスが VIP の監視 ポートでリッスンしている、またはチェックが無効にされている必要があります。
セット内の各 VIP は最終的に別のノードによって提供される可能性があります。
30.2.2. チェックおよび通知スクリプト
Keepalived は、オプションのユーザー指定のチェックスクリプトを定期的に実行してアプリケーションの正常性をモニターします。たとえば、このスクリプトは要求を発行し、応答を検証することで web サーバーをテストします。
スクリプトは oc adm ipfailover
コマンドに --check-script=<script>
オプションを指定して実行されます。このスクリプトは PASS の場合は 0
で終了するか、または FAIL の場合は 1
で終了する必要があります。
デフォルトでチェックは 2 秒ごとに実行されますが、--check-interval=<seconds>
オプションを使用して頻度を変更することができます。
チェックスクリプトが指定されない場合、TCP 接続をテストする単純なデフォルトスクリプトが実行されます。このデフォルトテストは、モニターポートが 0
の場合は抑制されます。
それぞれの仮想 IP (VIP) について、keepalived はノードの状態を保持します。ノードの VIP は MASTER、BACKUP、または FAULT の状態になります。FAULT 状態にないノードのすべての VIP はネゴシエーションに参加し、VIP の MASTER を決定します。選ばれなかったすべてのノードは BACKUP 状態になります。MASTER での check スクリプトが失敗すると、VIP は FAULT 状態になり、再ネゴシエーションがトリガーされます。BACKUP が失敗すると、VIP は FAULT 状態になります。check スクリプトが FAULT 状態の VIP に再度渡されると、その VIP は FAULT 状態を終了して MASTER のネゴシエーションを行います。結果としてその VIP の状態は MASTER または BACKUP のいずれかになります。
管理者はオプションの notify スクリプトを提供できます。このスクリプトは状態が変更されるたびに呼び出されます。Keepalived は以下の 3 つのパラメーターをこのスクリプトに渡します。
-
$1
- "GROUP"|"INSTANCE" -
$2
: グループまたはインスタンスの名前です。 -
$3
: 新規の状態 ("MASTER"|"BACKUP"|"FAULT") です。
これらのスクリプトは IP フェイルオーバー Pod で実行され、ホストのファイルシステムではなく Pod のファイルシステムを使用します。オプションにはスクリプトへの完全パスが必要です。管理者は Pod でスクリプトを利用可能にし、notify スクリプトを実行して結果を抽出できるようにする必要があります。スクリプトを提供する方法として、ConfigMap の使用が推奨されます。
check および notify スクリプトの完全パス名は、keepalived 設定ファイル、/etc/keepalived/keepalived.conf に追加されます。これは keepalived が起動するたびに読み込まれます。スクリプトは以下のように ConfigMap を使って Pod に追加できます。
必要なスクリプトを作成し、これを保持する ConfigMap を作成します。スクリプトには入力引数は指定されず、OK の場合は
0
を、FAIL の場合は1
を返します。check スクリプト mycheckscript.sh:
#!/bin/bash # Whatever tests are needed # E.g., send request and verify response exit 0
ConfigMap を作成します。
$ oc create configmap mycustomcheck --from-file=mycheckscript.sh
スクリプトを Pod に追加する方法として、
oc
コマンドの使用またはデプロイメント設定の編集の 2 つの方法があります。どちらの場合も、マウントされたconfigMap
ファイルのdefaultMode
は実行を許可する必要があります。通常は、値0755
(493
、10 進数) が使用されます。oc
コマンドの使用:$ oc env dc/ipf-ha-router \ OPENSHIFT_HA_CHECK_SCRIPT=/etc/keepalive/mycheckscript.sh $ oc volume dc/ipf-ha-router --add --overwrite \ --name=config-volume \ --mount-path=/etc/keepalive \ --source='{"configMap": { "name": "mycustomcheck", "defaultMode": 493}}'
ipf-ha-router デプロイメント設定の編集:
oc edit dc ipf-ha-router
を使用し、テキストエディターでルーターデプロイメント設定を編集します。... spec: containers: - env: - name: OPENSHIFT_HA_CHECK_SCRIPT 1 value: /etc/keepalive/mycheckscript.sh ... volumeMounts: 2 - mountPath: /etc/keepalive name: config-volume dnsPolicy: ClusterFirst ... volumes: 3 - configMap: defaultMode: 0755 4 name: customrouter name: config-volume ...
- 変更を保存してエディターを終了します。これにより ipf-ha-router が再起動します。
30.2.3. VRRP プリエンプション
ホストが check スクリプトを渡すことで FAULT 状態を終了する場合、その新規ホストが現在の MASTER 状態にあるホストよりも優先度が低い場合は BACKUP になります。ただしそのホストの優先度が高い場合は、プリエンプションストラテジーがクラスター内でのそのロールを決定します。
nopreempt ストラテジーは MASTER を低優先度のホストから高優先度のホストに移行しません。デフォルトの preempt 300 の場合、keepalived は指定された 300 秒の間待機し、MASTER を優先度の高いホストに移行します。
プリエンプションを指定するには、以下を実行します。
preemption-strategy
を使用して ipfailover を作成します。$ oc adm ipfailover --preempt-strategy=nopreempt \ ...
oc set env
コマンドを使用して変数を設定します。$ oc set env dc/ipf-ha-router \ --overwrite=true \ OPENSHIFT_HA_PREEMPTION=nopreempt
oc edit dc ipf-ha-router
を使用してルーターデプロイメント設定を編集します。... spec: containers: - env: - name: OPENSHIFT_HA_PREEMPTION 1 value: nopreempt ...
30.2.4. Keepalived マルチキャスト
OpenShift Container Platform の IP フェイルオーバーは keepalived を内部で使用します。
前述のラベルが付いたノードで multicast が有効にされており、それらが 224.0.0.18 (VRRP マルチキャスト IP アドレス) のネットワークトラフィックを許可することを確認します。
keepalived デーモンを起動する前に、起動スクリプトは、マルチキャストトラフィックのフローを許可する iptables
ルールを検証します。このルールがない場合、起動スクリプトは新規ルールを作成し、これを IP テーブル接続に追加します。この新規ルールが IP テーブルに追加される場所は --iptables-chain=
オプションによって異なります。--iptables-chain=
オプションが指定される場合、ルールはオプションで指定されるチェーンに追加されます。そうでない場合は、ルールは INPUT
チェーンに追加されます。
iptables
ルールは、1 つ以上の keepalived デーモンがノードで実行されている場合に存在している必要があります。
iptables
ルールは、最後の keepalived デーモンの終了後に削除できます。このルールは自動的に削除されません。
各ノードで iptables
ルールを手動で管理できます。(ipfailover が --iptable-chain=""
オプションで作成されていない限り) 何も存在しない場合にこのルールが作成されます。
手動で追加されたルールがシステム起動後も保持されることを確認する必要があります。
すべての keepalived デーモンはマルチキャスト 224.0.0.18 で VRRP を使用してそのピアとネゴシエーションするので注意が必要です。それぞれの VIP に異なる VRRP-id (0..255 の範囲) が設定されます。
$ for node in openshift-node-{5,6,7,8,9}; do ssh $node <<EOF export interface=${interface:-"eth0"} echo "Check multicast enabled ... "; ip addr show $interface | grep -i MULTICAST echo "Check multicast groups ... " ip maddr show $interface | grep 224.0.0 EOF done;
30.2.5. コマンドラインオプションおよび環境変数
オプション | 変数名 | デフォルト | 注記 |
---|---|---|---|
|
|
80 |
ipfailover Pod は、各 VIP のこのポートに対して TCP 接続を開こうとします。接続が設定されると、サービスは実行中であると見なされます。このポートが 0 に設定される場合、テストは常にパスします。 |
|
|
使用する ipfailover のインターフェース名で、VRRP トラフィックを送信するために使用されます。デフォルトで | |
|
|
2 |
作成するレプリカの数です。これは、ipfailover デプロイメント設定の |
|
|
複製する IP アドレス範囲の一覧です。これは指定する必要があります (例: 1.2.3.4-6,1.2.3.9.)。詳細については、こちらを参照してください。 | |
|
|
0 |
詳細は、VRRP ID オフセットを参照してください。 |
|
|
VRRP に作成するグループの数です。これが設定されていない場合、グループは | |
|
|
INPUT |
iptables チェーンの名前であり、 |
|
|
Pod のファイルシステム内の、アプリケーションの動作を確認するために定期的に実行されるスクリプトの完全パス名です。詳細は、こちらを参照してください。 | |
|
|
2 |
check スクリプトが実行される期間 (秒単位) です。 |
|
|
Pod ファイルシステム内の、状態が変更されるたびに実行されるスクリプトの完全パス名です。詳細は、こちらを参照してください。 | |
|
|
preempt 300 |
新たな優先度の高いホストを処理するためのストラテジーです。詳細は、「VRRP プリエンプション」のセクションを参照してください。 |
30.2.6. VRRP ID オフセット
ipfailover デプロイメント設定で管理される各 ipfailover Pod (ノード/レプリカあたり 1 Pod) は keepalived デーモンを実行します。作成される ipfailover デプロイメント設定が多くなると、作成される Pod も多くなり、共通の VRRP ネゴシエーションに参加するデーモンも多くなります。このネゴシエーションはすべての keepalived デーモンによって実行され、これはどのノードがどの仮想 IP (VIP) を提供するかを決定します。
keepalived は内部で固有の vrrp-id を各 VIP に割り当てます。ネゴシエーションはこの vrrp-id セットを使用し、決定後には優先される vrrp-id に対応する VIP が優先されるノードで提供されます。
したがって、ipfailover デプロイメント設定で定義されるすべての VIP について、ipfailover Pod は対応する vrrp-id を割り当てます。これは、--vrrp-id-offset
から開始し、順序に従って vrrp-id を VIP の一覧に割り当てることによって実行されます。vrrp-id には範囲 1..255 の値を設定できます。
複数の ipfailover デプロイメント設定がある場合、デプロイメント設定の VIP 数を増やす余地があることや vrrp-id 範囲のいずれも重複しないことを確認できるよう --vrrp-id-offset
を注意して指定する必要があります。
30.2.7. 254 を超えるアドレスについての IP フェイルオーバーの設定
IP フェイルオーバー管理は VIP アドレスの 254 グループに制限されています。デフォルトでは、OpenShift Container Platform は各グループに 1 つの IP アドレスを割り当てます。virtual-ip-groups
オプションを使用するとこれを変更でき、.IP フェイルオーバーの設定時に複数の IP アドレスをそれぞれのグループに配置し、各 VRRPインスタンスに利用できる VIP グループの数を定義できます。
VIP の作成により、VRRP フェイルオーバーの発生時の広範囲の VRRP の割り当てが作成され、これはクラスター内のすべてのホストがローカルにサービスにアクセスする場合に役立ちます。たとえば、サービスが ExternalIP
で公開されている場合などがこれに含まれます。
フェイルオーバーのルールとして、ルーターなどのサービスは特定の 1 つのホストに制限しません。代わりに、サービスは、IP フェイルオーバーの発生時にサービスが新規ホストに再作成されないように各ホストに複製可能な状態にする必要があります。
OpenShift Container Platform のヘルスチェックを使用している場合、IP フェイルオーバーおよびグループの性質上、グループ内のすべてのインスタンスはチェックされません。そのため、Kubernetes ヘルスチェックを使ってサービスが有効であることを確認する必要があります。
# oc adm ipfailover <ipfailover_name> --create \ ... --virtual-ip-groups=<number_of_ipfailover_groups>
たとえば、7 つの VIP のある環境で --virtual-ip-groups
が 3
に設定されている場合、これは 3 つのグループを作成し、3 つの VIP を最初のグループに、2 つの VIP を 2 つの残りのグループにそれぞれ割り当てます。
--virtual-ip-groups
オプションで設定されるグループの数がフェイルオーバーに設定される IP アドレスの数よりも小さい場合、グループには複数の IP アドレスが含まれ、アドレスのすべてが単一のユニットとして移行します。
30.2.8. 高可用サービスの設定
以下の例では、ノードのセットに IP フェイルオーバーを指定して可用性の高い router および geo-cache ネットワークサービスをセットアップする方法について説明します。
サービスに使用されるノードにラベルを付けます。の手順は、OpenShift Container Platform クラスターのすべてのノードでサービスを実行し、クラスターのすべてのノード内で固定されない VIP を使用する場合はオプションになります。
以下の例では、地理的区分 US west でトラフィックを提供するノードのラベルを定義します (ha-svc-nodes=geo-us-west)。
$ oc label nodes openshift-node-{5,6,7,8,9} "ha-svc-nodes=geo-us-west"
サービスアカウントを作成します。ipfailover を使用したり、(環境ポリシーによって異なる) ルーターを使用する場合は事前に作成された router サービスアカウントか、または新規の ipfailover サービスアカウントのいずれかを再利用できます。
以下の例は、デフォルト namespace で ipfailover という名前の新規サービスアカウントを作成します。
$ oc create serviceaccount ipfailover -n default
デフォルト namespace の ipfailover サービスアカウントを 特権付き SCC に追加します。
$ oc adm policy add-scc-to-user privileged system:serviceaccount:default:ipfailover
router および geo-cache サービスを起動します。
重要ipfailover は手順 1 のすべてのノードで実行されるため、手順 1 のすべてのノードでルーター/サービスを実行することも推奨されます。
最初の手順で使用されるラベルに一致するノードでルーターを起動します。以下の例では、ipfailover サービスアカウントを使用して 5 つのインスタンスを実行します。
$ oc adm router ha-router-us-west --replicas=5 \ --selector="ha-svc-nodes=geo-us-west" \ --labels="ha-svc-nodes=geo-us-west" \ --service-account=ipfailover
各ノードでレプリカと共に geo-cache サービスを実行します。geo-cache サービスの実行については、「設定サンプル」を参照してください。
重要ファイルで参照される myimages/geo-cache Docker イメージが使用するイメージに置き換えられていることを確認します。レプリカの数を geo-cache ラベルのノード数に変更します。ラベルが最初の手順で使用したものと一致していることを確認します。
$ oc create -n <namespace> -f ./examples/geo-cache.json
router および geo-cache サービスの ipfailover を設定します。それぞれに独自の VIP があり、いずれも最初の手順の ha-svc-nodes=geo-us-west のラベルが付けられた同じノードを使用します。レプリカの数が最初の手順のラベル設定に一覧表示されているノード数と一致していることを確認してください。
重要router、geo-cache および ipfailover はすべてデプロイメント設定を作成します。それらの名前はすべて異なっている必要があります。
ipfailover が必要なインスタンスでモニターする必要のある VIP およびポート番号を指定します。
router の ipfailover コマンド:
$ oc adm ipfailover ipf-ha-router-us-west \ --replicas=5 --watch-port=80 \ --selector="ha-svc-nodes=geo-us-west" \ --virtual-ips="10.245.2.101-105" \ --iptables-chain="INPUT" \ --service-account=ipfailover --create
以下は、ポート 9736 でリッスンする geo-cache サービスの
oc adm ipfailover
コマンドです。2 つのipfailover
デプロイメント設定があるため、それぞれの VIP が独自のオフセットを取得できるように--vrrp-id-offset
を設定する必要があります。この場合10
の値は、ipf-ha-geo-cache
が 10 から開始するためにipf-ha-router-us-west
には最大 10 の VIP (0-9)を持たせることができることを意味します。$ oc adm ipfailover ipf-ha-geo-cache \ --replicas=5 --watch-port=9736 \ --selector="ha-svc-nodes=geo-us-west" \ --virtual-ips=10.245.3.101-105 \ --vrrp-id-offset=10 \ --service-account=ipfailover --create
上記のコマンドでは、各ノードに ipfailover、router、および geo-cache Pod があります。各 ipfailover 設定の VIP のセットは重複してなならず、外部またはクラウド環境の別の場所で使用することはできません。それぞれの例の 5 つの VIP
10.245.{2,3}.101-105
は、2 つの ipfailover デプロイメント設定で提供されます。IP フェイルオーバーはどのアドレスがどのノードで提供されるかを動的に選択します。管理者は、すべての router VIP が同じ router を参照し、すべての geo-cache VIP が同じ geo-cache サービスを参照することを前提とした上で VIP アドレスを参照する外部 DNS をセットアップします。1 つのノードが実行中である限り、すべての VIP アドレスが提供されます。
30.2.8.1. IP フェイルオーバー Pod のデプロイ
postgresql-ingress サービスの定義に基づいてノードポート 32439 および外部 IP アドレスでリッスンする postgresql をモニターするために ipfailover ルーターをデプロイします。
30.2.9. 高可用サービスの仮想 IP の動的更新
IP フェイルオーバーのデフォルトのデプロイメント方法として、デプロイメントを再作成します。高可用のルーティングサービスの動的更新を最小限のダウンタイムまたはダウンタイムなしで実行するには、以下を実行する必要があります。
- ローリングアップデート (Rolling Update) ストラテジーを使用するように IP フェイルオーバーサービスデプロイメント設定を更新する。
-
仮想 IP アドレスの更新された一覧またはセットを使用して
OPENSHIFT_HA_VIRTUAL_IPS
環境変数を更新します。
以下の例は、デプロイメントストラテジーおよび仮想 IP アドレスを動的に更新する方法について示しています。
以下を使用して作成された IP フェイルオーバー設定を見てみましょう。
$ oc adm ipfailover ipf-ha-router-us-west \ --replicas=5 --watch-port=80 \ --selector="ha-svc-nodes=geo-us-west" \ --virtual-ips="10.245.2.101-105" \ --service-account=ipfailover --create
デプロイメント設定を編集します。
$ oc edit dc/ipf-ha-router-us-west
spec.strategy.type
フィールドをRecreate
からRolling
に更新します。spec: replicas: 5 selector: ha-svc-nodes: geo-us-west strategy: recreateParams: timeoutSeconds: 600 resources: {} type: Rolling 1
- 1
Rolling
に設定します。
追加の仮想 IP アドレスを含めるように
OPENSHIFT_HA_VIRTUAL_IPS
環境変数を更新します。- name: OPENSHIFT_HA_VIRTUAL_IPS value: 10.245.2.101-105,10.245.2.110,10.245.2.201-205 1
- 1
10.245.2.110,10.245.2.201-205
が一覧に追加されます。
- VIP のセットに一致するよう外部 DNS を更新します。
30.3. サービスの ExternalIP および NodePort の設定
ユーザーは VIP をサービスの ExternalIP として割り当てることができます。Keepalived は、各 VIP が ipfailover 設定のノードで提供されるようにします。要求がそのノードに到達すると、クラスター内のすべてのノードで実行されているサービスがサービスのエンドポイント間で要求の負荷分散を行います。
NodePorts を ipfailover 監視ポートに設定して、keepalived がアプリケーションが実行中であることを確認できるようにします。NodePort はクラスター内のすべてのノードで公開されるため、すべての ipfailover ノードの keepalived で利用可能になります。
30.4. IngressIP の高可用性
クラウド以外のクラスターでは、ipfailover およびサービスへの ingressIP を組み合わせることができます。結果として、ingressIP を使用してサービスを作成するユーザーに高可用サービスが提供されます。
この方法では、まず ingressIPNetworkCIDR
範囲を指定し、次に ipfailover 設定を作成する際に同じ範囲を使用します。
ipfailover はクラスター全体に対して最大 255 の VIP をサポートするため、ingressIPNetworkCIDR
は /24
以下に設定する必要があります。