GKE On-Prem クラスタは、統合または手動のいずれかの負荷分散モードで実行できます。統合モードでは、GKE On-Prem クラスタは F5 BIG-IP ロードバランサを使用します。手動モードでは、F5 BIG-IP ロードバランサやその他の任意のロードバランサを使用できます。手動負荷分散モードでは、統合モードよりも多くの構成を行う必要があります。このページでは、手動負荷分散モードを使用する場合に必要な手順について説明します。
手動負荷分散モードで使用できるロードバランサの例として、Citrix ロードバランサと Seesaw ロードバランサがあります。
このトピックでは、後で使用するために IP アドレスと nodePort 値を確保します。負荷分散とクラスタノードに使用する IP アドレスと nodePort 値の選択について説明します。ただし、この時点ではアドレスと nodePort 値に関することは何も行いません。後で GKE On-Prem をインストールする準備ができたら、アドレスと nodePort 値をクラスタ構成ファイルに入力する必要があります。ロードバランサを手動で構成するときにも、アドレスと nodePort 値が必要になります。
仮想 IP アドレスの確保
統合負荷分散モードと手動負荷分散モードのどちらを使用する場合でも、負荷分散に使用する複数の仮想 IP アドレス（VIP）を確保する必要があります。この VIP により、外部クライアントは Kubernetes API サーバー、Ingress Service、アドオン サービスにアクセスできます。VIP の確保に関する詳細な手順は、仮想 IP アドレスの確保をご覧ください。
ノード IP アドレスの確保
手動負荷分散モードでは、DHCP を使用できません。クラスタノードの静的 IP アドレスを指定する必要があります。管理クラスタ内のノードと、作成するすべてのユーザー クラスタ内のノードに十分なアドレスを確保する必要があります。確保するノード IP アドレスの数については、静的 IP の構成をご覧ください。
nodePort 値を確保する
GKE On-Prem クラスタでは、Kubernetes API サーバー、Ingress サービス、アドオン サービスは NodePort 型の Kubernetes Service として実装されます。手動負荷分散モードを使用する場合は、これらの Service で独自の nodePort 値を選択する必要があります。30000～32767 の範囲で値を選択します。nodePort の値を選択したら、後でクラスタ構成ファイルを変更するときのためにその値を確保します。
次の nodePort 値を選択して確保します。
Kubernetes API サーバー用に確保した VIP ごとに、1 つの
nodePort値を確保します。クラスタ Ingress サービス用に確保した VIP ごとに、HTTP トラフィックと HTTPS トラフィックの 2 つの
nodePort値を確保します。これはユーザー クラスタにのみ適用されます。クラスタ アドオン サービス用に確保した VIP ごとに、1 つの
nodePort値を確保します。これは管理クラスタにのみ適用されます。
たとえば、2 つのユーザー クラスタを作成し、すべてのクラスタでアドオンを使用するとします。次の nodePort 値を選択して確保する必要があります。
管理クラスタ内の Kubernetes API サーバーの
nodePort値。2 つの各ユーザー クラスタについての、Kubernetes API サーバーの
nodePort値。2 つの各ユーザー クラスタについての、Ingress サービスへの HTTP トラフィックの
nodePort値。2 つの各ユーザー クラスタについての、Ingress サービスへの HTTPS トラフィックの
nodePort値。管理クラスタ内のアドオン サービスの
nodePort値。2 つの各ユーザー クラスタについての、アドオン サーバーの
nodePort値。
上記の例では、11 個の nodePort 値を確保する必要があります。
GKE On-Prem 構成ファイルを変更する
GKE On-Prem をインストールする際、構成ファイルを生成します。手動負荷分散モードの場合は、構成ファイルに次の変更を加えます。
lbmodeをManualに設定する。admincluster.ipblockfilepathを管理クラスタの静的 IP YAML ファイルのパスに設定します。これについての詳細は、静的 IP の構成をご覧ください。Manualモードでは DHCP は選択できません。usercluster.ipblockfilepathをユーザー クラスタの静的 IP YAML ファイルのパスに設定します。admincluster.manuallbspecフィールドを管理クラスタ用に選択したnodePort値に更新します。usercluster.manuallbspecセクションをユーザー クラスタ用に選択したnodePort値に更新します。
次の例は、更新された構成ファイルの一部を示しています。
...
lbmode: Manual
...
admincluster:
ipblockfilepath: "ipblock1.yaml"
manuallbspec:
controlplanenodeport: 30968
addonsnodeport: 31405
...
usercluster:
ipblockfilepath: "env/default/ipblock2.yaml"
manuallbspec:
ingresshttpnodeport: 30243
ingresshttpsnodeport: 30879
controlplanenodeport: 30562
ロードバランサを構成する
構成ファイルを更新したら、ロードバランサの管理コンソールにログインして、VIP を構成します。
前述のとおり、5 つの VIP と 7 つのポートを構成する必要があります。そこで、以下の 7 つの仮想サービスをロードバランサに作成します。
- 管理クラスタ コントロール プレーン、TCP ポート 443
- アドオン マネージャー、TCP ポート 8443
- ユーザー コントロール プレーン、TCP ポート 80
- ユーザー クラスタ Ingress コントローラ、TCP ポート 80
- ユーザー クラスタ Ingress コントローラ、TCP ポート 443
負荷分散の例
Service には ServicePort オブジェクトの配列である ports フィールドがあります。NodePort タイプの Service 内では、各 ServicePort オブジェクトに protocol、port、nodePort、および targetPort があります。たとえば、ports 配列に ServicePort オブジェクトが 2 つある Service のマニフェストの一部は次のとおりです。
...
kind: Service
...
spec:
...
type: NodePort
ports:
- protocol: TCP
port: 80
nodePort: 32676
targetPort: 8080
- protocol: TCP
port: 443
nodePort: 32677
targetPort: 443
...
上記の Service がいずれかのユーザー クラスタの Ingress サービスを表しているとします。さらに、次の選択を行ったとします。
203.0.113.5はユーザー クラスタの Ingress サービスの VIP です。ユーザー クラスタのノードアドレスは
192.168.0.10、192.168.0.11、192.168.0.12です。
ロードバランサを構成すると、トラフィックは次のように転送されます。
クライアントは TCP ポート 80 で
203.0.113.5にリクエストを送信します。ロードバランサはユーザー クラスタ ノードを選択します。この例では、ノードアドレスは192.168.0.11であると仮定しています。ロードバランサは、リクエストを TCP ポート 32676 で192.168.0.11に転送します。ノードの iptables ルールは、TCP ポート 8080 で適切な Pod にリクエストを転送します。クライアントは TCP ポート 443 で
203.0.113.5にリクエストを送信します。ロードバランサはユーザー クラスタ ノードを選択します。この例では、ノードアドレスは192.168.0.10であると仮定しています。ロードバランサは、リクエストを TCP ポート 32677 で192.168.0.10に転送します。ノードの iptables ルールは、TCP ポート 443 で適切な Pod にリクエストを転送します。
手動負荷分散のサポートを取得する
Google では、手動負荷分散モードを使用して構成されたロードバランサはサポートされません。ロードバランサに問題が発生した場合は、ロードバランサのベンダーにお問い合わせください。
次のステップ
トラブルシューティング
詳しくは、トラブルシューティングを参照してください。