Anthos GKE On-Prem の以前のバージョンのドキュメントを表示しています最新のドキュメントはこちらをご覧ください

手動負荷分散モードの有効化

GKE On-Prem クラスタは、統合または手動のいずれかの負荷分散モードで実行できます。統合モードでは、GKE On-Prem クラスタは F5 BIG-IP ロードバランサを使用します。手動モードでは、F5 BIG-IP ロードバランサやその他の任意のロードバランサを使用できます。手動負荷分散モードでは、統合モードよりも多くの構成を行う必要があります。このページでは、手動負荷分散モードを使用する場合に必要な手順について説明します。

手動負荷分散モードで使用できるロードバランサの例として、Citrix ロードバランサSeesaw ロードバランサがあります。

手動負荷分散モードで F5 BIG-IP を使用する方法については、手動負荷分散を使用した GKE On-Prem 用 F5 BIG-IP ADC のインストールをご覧ください。

このトピックでは、後で使用するために 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 をインストールする際、構成ファイルを生成します。手動負荷分散モードの場合は、構成ファイルに次の変更を加えます。

  • lbmodeManual に設定します。

  • 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 オブジェクトに protocolportnodePort、および 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.10192.168.0.11192.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 では、手動負荷分散モードを使用して構成されたロードバランサはサポートされません。ロードバランサに問題が発生した場合は、ロードバランサのベンダーにお問い合わせください。

次のステップ

トラブルシューティング

詳しくは、トラブルシューティングを参照してください。