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

GKE On-Prem クラスタは、統合、バンドル型、手動の 3 つの負荷分散モードのいずれかで実行できます。統合モードの場合、GKE On-Prem クラスタは F5 BIG-IP ロードバランサを使用します。バンドル型モードの場合、GKE On-Prem がロードバランサを提供して管理します。ロードバランサにライセンスを割り当てる必要はありません。必要なセットアップ作業は最小限に抑えられます。手動モードの場合、GKE On-Prem は指定された別のロードバランサを使用します。手動負荷分散モードでは、統合モードよりも多くの構成を行う必要があります。このページでは、手動負荷分散モードを使用する場合に必要な手順について説明します。

手動負荷分散モードで使用できるロードバランサには Citrix ロードバランサなどがあります。

このトピックでは、後で使用するために 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 値。

上記の例では、8 個の nodePort 値を確保する必要があります。

GKE On-Prem 構成ファイルを変更する

クラスタごとに構成ファイル(管理クラスタユーザー クラスタ)を準備します。

  • loadBalancer.kindManualLB に設定します。

  • network.ipModestatic に設定します。

  • network.ipBlockFilePath をユーザー クラスタの静的 IP YAML ファイルのパスに設定します。これについての詳細は、静的 IP の構成をご覧ください。DHCP は手動負荷分散モードのオプションではありません。

  • loadBalancer.manualLB フィールドを、クラスタに選択した nodePort 値で更新します。

次の例は、更新された構成ファイルの一部を示しています。

network:
  ipMode:
    type: static
    ipBlockFilePath: "ipblock1.yaml"
loadBalancer:
  kind: ManualLB
  manualLB:
    ingressHTTPNodePort: 30243
    ingressHTTPSNodePort: 30879
    controlPlaneNodePort: 30562:
    addonsnodeport: 31405

ロードバランサの構成

構成ファイルを更新したら、ロードバランサの管理コンソールにログインして、VIP を構成します。

  • 管理クラスタとユーザー クラスタの両方のクラスタ コントロール プレーン、TCP ポート 443
  • 管理クラスタのアドオン マネージャー(使用する場合)、TCP ポート 8443
  • ユーザー クラスタ 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 では、手動負荷分散モードを使用して構成されたロードバランサはサポートされません。ロードバランサに問題が発生した場合は、ロードバランサのベンダーにお問い合わせください。

次のステップ

トラブルシューティング

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