BGP でバンドルされたロードバランサを構成する

このドキュメントでは、GKE on Bare Metal のバンドルを Border Gateway Protocol（BGP）で設定して使用する方法について説明します。この負荷分散モードは、クラスタの外部 Border Gateway Protocol（eBGP）を介して ServiceType LoadBalancer 仮想 IP アドレス（VIP）のアドバタイズをサポートします。このシナリオでは、クラスタ ネットワークは自律システムであり、ピアリングを介して別の自律システム（外部ネットワーク）と相互接続します。

BGP 機能を備えたバンドル型ロードバランサはすべてのクラスタタイプに適用されますが、管理クラスタでは、この機能のコントロール プレーン ロード バランシング部分のみがサポートされます。

BGP 機能を備えたバンドル型ロードバランサを使用すると、次のようなメリットがあります。

  • N 方向のアクティブ / アクティブ ロード バランシング機能を使用してフェイルオーバーを高速化し、使用可能な帯域幅をより効率的に使用します。
  • eBGP と互換性のあるサードパーティ トップオブラック（ToR）スイッチやルーターで動作するレイヤ 3 プロトコルをサポートします。
  • 高度なソフトウェア定義ネットワーキング（SDN）スタックを実行しているデータセンターで、レイヤ 3 境界をクラスタまで引き上げることができます。

BGP によるバンドル型負荷分散の仕組み

次のセクションでは、BGP とバンドル型ロードバランサの動作の概要を簡単に説明します。

BGP ピアリング

BGP 機能を備えたバンドル型ロードバランサは、インフラストラクチャへの BGP 接続を開始します。BGP には次の技術的要件があります。

  • ピアリング セッションは、コントロール プレーン VIP とサービス VIP で分離されています。
  • コントロール プレーンのピアリング セッションは、コントロール プレーン ノードの IP アドレスから開始されます。
  • サービス ピアリング セッションは、NetworkGatewayGroup カスタム リソースで指定したフローティング IP アドレスから開始されます。
  • Anthos ネットワーク ゲートウェイ コントローラは、フローティング IP アドレスを管理します。
  • バンドル型 BGP ベースの負荷分散は eBGP ピアリングのみをサポートします。
  • マルチホップ ピアリングは、デフォルトでサポートされています。
  • BGP セッションの MD5 パスワードはサポートされていません。
  • IPv6 ベースのピアリング セッションはサポートされていません。
  • ピアにアドバタイズされたルートは、ネットワーク全体に再配布され、クラスタ内のあらゆる場所から到達可能である必要があります。
  • ピアリング セッションでは、受信モードで BGP ADD-PATH 機能を使用することをおすすめします。
  • 各ピアから複数のパスをアドバタイズすると、アクティブ/アクティブの負荷分散になります。
  • 複数のパスを使用して一連のロードバランサ ノードにトラフィックを分散できるように、等価コスト マルチパス ルーティング（ECMP）をネットワークで有効にする必要があります。

コントロール プレーンの負荷分散

クラスタ内の各コントロール プレーン ノードが、インフラストラクチャ内の 1 つ以上のピアとの BGP セッションを確立します。各コントロール プレーン ノードには少なくとも 1 つのピアが必要です。クラスタ構成ファイルでは、どのコントロール プレーン ノードがどの外部ピアに接続するかを構成できます。

次の図は、コントロール プレーンのピアリングの例を示しています。クラスタには、1 つのサブネットと別のサブネットに 2 つのコントロール プレーン ノードがあります。各サブネットには外部ピア（TOR）があり、GKE on Bare Metal コントロール プレーンノードがその TOR とピアリングします。

BGP ピアリングによるサービス負荷分散

サービス負荷分散

コントロール プレーン ピアリングの各コントロール プレーン ノードから開始されるピアリング セッションに加えて、LoadBalancer Service 用に追加のピアリング セッションが開始されます。これらのピアリング セッションは、クラスタノードの IP アドレスから直接開始されるのではなく、フローティング IP アドレスを使用します。

externalTrafficPolicy=Local ネットワーク ポリシーを使用する Service はサポートされていません。

フローティング IP アドレス

サービス負荷分散では、BGP ピアリングに使用するクラスタノードのサブネットでフローティング IP アドレスを予約する必要があります。クラスタには少なくとも 1 つのフローティング IP アドレスが必要ですが、BGP セッションの高可用性を確保するために、少なくとも 2 つのアドレスを予約することをおすすめします。フローティング IP アドレスは、クラスタ構成ファイルに含めることができる NetworkGatewayGroup カスタム リソース（CR）で指定されます。

フローティング IP アドレスを使用すると、BGP スピーカーの IP アドレスをノードにマッピングする必要がなくなります。Anthos Network Gateway コントローラは、NetworkGatewayGroup をノードに割り当て、フローティング IP アドレスを管理します。ノードがダウンすると、Anthos Network Gateway コントローラはフローティング IP アドレスを再割り当てし、外部ピアがピアリングする確定的 IP アドレスを持っていることを確認します。

外部ピア

データプレーン負荷分散では、クラスタ構成ファイルの loadBalancer.controlPlaneBGP セクションでコントロール プレーン ピアリングに指定したものと同じ外部ピアを使用できます。別の BGP ピアを指定することもできます。

データプレーンのピアリングに異なる BGP ピアを指定する場合は、クラスタ構成ファイルに BGPLoadBalancer と BGPPeer のリソース仕様を追加します。これらのカスタム リソースを指定しない場合、コントロール プレーンのピアが自動的にデータプレーンに使用されます。

フローティング IP アドレスでのピアリング セッションに使用する外部ピアを、クラスタ構成ファイルに追加する BGPPeer カスタム リソースで指定します。BGPPeer リソースには、対応する BGPLoadBalancer カスタム リソースで識別するためのラベルが含まれています。BGPLoadBalancer カスタム リソースの peerSelector フィールドで一致するラベルを指定して、使用する BGPPeer を選択します。

Anthos ネットワーク ゲートウェイ コントローラは、予約済みのフローティング IP アドレスの組から、各外部ピアへのセッション（セッション数は構成可能）を確立しようとします。BGP セッションの高可用性を確保するために、少なくとも 2 つの外部ピアを指定することをおすすめします。Service ロード バランシングに指定された各外部ピアは、NetworkGatewayGroup カスタム リソースで指定されたすべてのフローティング IP アドレスとピアリングするように構成する必要があります。

ロードバランサ ノード

クラスタのノードのサブセットは負荷分散に使用されます。つまり、これらのノードが、着信する負荷分散トラフィックを受け入れるようにアドバタイズされたノードになります。このノードセットはデフォルトでコントロール プレーンのノードプールですが、クラスタ構成ファイルの loadBalancer セクションで別のノードプールを指定することもできます。ノードプールを指定すると、コントロール プレーン ノードプールではなく、ロードバランサ ノードにノードプールが使用されます。

フローティング IP アドレスは BGP スピーカーとして機能し、ロードバランサ ノードで実行される場合があります。フローティング IP アドレスは、ロードバランサ ノードであるかどうかに関係なく、同じサブネット内のノードに割り当てられ、ピアリングがそこから開始されます。ただし、BGP を介してアドバタイズされるネクストホップは常にロードバランサノードです。

ピアリング トポロジの例

次の図は、BGP ピアリングを使用したサービス負荷分散の例を示しています。それぞれのサブネット内のノードには、2 つのフローティング IP アドレスが割り当てられます。外部ピアが 2 つ定義されています。それぞれのフローティング IP は両方の外部ピアとピアリングします。

BGP ピアリングによるサービス負荷分散

BGP ロードバランサを設定する

次のセクションでは、BGP を使ってバンドルされているロードバランサーを使用するために、クラスタと外部ネットワークを構成する方法について説明します。

外部インフラストラクチャとの統合を計画する

BGP を備えたバンドル型ロードバランサを使用するには、外部インフラストラクチャを設定する必要があります。

  • 外部インフラストラクチャは、クラスタ内の各コントロール プレーン ノードとピアリングして、コントロール プレーンの通信を構成する必要があります。これらのピアリング セッションは、Kubernetes コントロール プレーン VIP をアドバタイズするために使用されます。

  • 外部インフラストラクチャは、データプレーン通信用に予約済みのフローティング IP アドレスのセットとピアリングするように構成する必要があります。フローティング IP アドレスは、Service VIP の BGP ピアリングに使用されます。BGP セッションで高可用性を確保するために、2 つのフローティング IP アドレスと 2 つのピアを使用することをおすすめします。フローティング IP を予約するプロセスは、BGP によるバンドル型負荷分散の構成で説明されます。

インフラストラクチャを構成したら、BGP ピアリング情報をクラスタ構成ファイルに追加します。作成したクラスタは、外部インフラストラクチャとのピアリング セッションを開始できます。

BGP を使用してバンドル型負荷分散を行うようにクラスタを構成する

クラスタ構成ファイルでは、クラスタの作成時に BGP を備えたバンドル負荷分散を有効にして構成します。 クラスタ構成ファイルで、高度なネットワークを有効にし、loadBalancer セクションを更新します。また、次の 3 つのカスタム リソースの仕様も追加します。

  • NetworkGatewayGroup: Service BGP ピアリング セッションに使用されるフローティング IP アドレスを指定します。

  • BGPLoadBalancer: BGP ロード バランシングに使用するピアをラベルセレクタで指定します。

  • BGPPeer: BGP ピアリング セッション用に、選択用のラベルを含む個々のピアを指定します。

次の手順では、クラスタと 3 つのカスタム リソースを構成して、BGP でバンドルされたロード バランシングを設定する方法について説明します。

  1. clusterNetwork セクションのクラスタ構成ファイルに advancedNetworking フィールドを追加して、true に設定します。

    このフィールドは、高度なネットワーク機能、特に Network Gateway Group リソースを有効にします。

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: CLUSTER_NAMESPACE
spec:
...
  clusterNetwork:
    advancedNetworking: true

    CLUSTER_NAMESPACE は、クラスタの名前空間に置き換えます。デフォルトでは、GKE on Bare Metal のクラスタ名前空間は、先頭に cluster- が付いたクラスタの名前です。たとえば、クラスタに test という名前をつける場合、名前空間は cluster-test になります。

  2. クラスタ構成ファイルの loadBalancer セクションで、mode を bundled に設定し、type フィールドを bgp 値に設定します。

    以下のフィールド値により、BGP ベースのバンドル型ロード バランシングが有効になります。

    ...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp
    ...

  3. コントロール プレーンの BGP ピアリング情報を指定するには、次のフィールドを loadBalancer セクションに追加します。

        ...
    # AS number for the cluster
    localASN: CLUSTER_ASN

    # List of BGP peers used for the control plane peering sessions.
    bgpPeers:
    - ip: PEER_IP
      asn: PEER_ASN
      # optional; if not specified, all CP nodes connect to all peers.
      controlPlaneNodes:   # optional
      - CP_NODE_IP
...

    以下を置き換えます。

    • CLUSTER_ASN: 作成するクラスタの自律システム番号。
    • PEER_IP: 外部ピアデバイスの IP アドレス。
    • PEER_ASN: 外部ピアデバイスを含むネットワークの自律システム番号。
    • CP_NODE_IP: （省略可）外部ピアに接続するコントロール プレーン ノードの IP アドレス。コントロール プレーン ノードを指定しない場合、すべてのコントロール プレーン ノードが外部ピアに接続できます。1 つ以上の IP アドレスを指定すると、指定したノードのみがピアリング セッションに参加します。

    複数の外部ピアを指定できます。bgpPeers はマッピングのリストを受け取ります。BGP セッションの高可用性のために、少なくとも 2 つの外部ピアを指定することをおすすめします。複数のピアを使用する例については、構成例をご覧ください。

  4. loadBalancer.ports、loadBalancer.vips、loadBalancer.addressPools の各フィールドを設定します（図はデフォルト値です）。

    ...
  loadBalancer:
  ...
    # Other existing load balancer options remain the same
    ports:
      controlPlaneLBPort: 443
    # When type=bgp, the VIPs are advertised over BGP
    vips:
      controlPlaneVIP: 10.0.0.8
      ingressVIP: 10.0.0.1

    addressPools:
    - name: pool1
      addresses:
      - 10.0.0.1-10.0.0.4
...

  5. データプレーンのロード バランシングに使用するクラスタノードを指定します。

    この手順は省略可能です。nodePoolSpec セクションのコメント化を解除しない場合、コントロール プレーン ノードはデータプレーン負荷分散に使用されます。

    ...
  # Node pool used for load balancing data plane (nodes where incoming traffic
  # arrives. If not specified, this defaults to the control plane node pool.
  # nodePoolSpec:
  #   nodes:
  #   - address: <Machine 1 IP>
...

  6. NetworkGatewayGroup カスタム リソースを構成して、フローティング IP アドレスを予約します。

    フローティング IP アドレスは、データプレーン ロード バランシングのピアリング セッションで使用されます。

    ...
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: CLUSTER_NAMESPACE
spec:
  floatingIPs:
  - FLOATING_IP
...

    以下を置き換えます。

    • CLUSTER_NAMESPACE: クラスタの名前空間。デフォルトでは、GKE on Bare Metal のクラスタ名前空間は、先頭に cluster- が付いたクラスタの名前です。たとえば、クラスタに test という名前をつける場合、名前空間は cluster-test になります。
    • FLOATING_IP: クラスタのサブネットの 1 つの IP アドレス。IP アドレスは 1 つ以上指定する必要がありますが、2 つ以上指定することをおすすめします。

    NetworkGatewayGroup カスタム リソースの名前が default であり、クラスタの名前空間を使用していることを確認してください。NetworkGatewayGroup カスタム リソース仕様の内容については、構成例をご覧ください。

  7. （省略可）BGPLoadBalancer カスタム リソースを構成して、データプレーン ロード バランシングに使用するピアを指定します。

    ...
---
apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
  name: default
  namespace: CLUSTER_NAMESPACE
spec:
  peerSelector:
    PEER_LABEL: "true"
...

    以下を置き換えます。

    • CLUSTER_NAMESPACE: クラスタの名前空間。デフォルトでは、GKE on Bare Metal のクラスタ名前空間は、先頭に cluster- が付いたクラスタの名前です。たとえば、クラスタに test という名前をつける場合、名前空間は cluster-test になります。
    • PEER_LABEL: ロード バランシングに使用するピアの識別に使用されるラベル。一致するラベルを持つどの BGPPeer カスタム リソースも、各ピアの詳細を指定します。

    BGPLoadBalancer カスタム リソースの名前が default であり、クラスタの名前空間を使用していることを確認してください。BGPLoadBalancer カスタム リソースを指定しない場合、コントロール プレーンのピアは自動的にデータプレーン負荷分散に使用されます。包括的な例については、構成例をご覧ください。

  8. （省略可）1 つ以上の BGPPeer カスタム リソースを構成して、データプレーンの外部ピアを指定します。

    ...
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: BGP_PEER_NAME
  namespace: CLUSTER_NAMESPACE
  labels:
    PEER_LABEL: "true"
spec:
  localASN: CLUSTER_ASN
  peerASN: PEER_ASN
  peerIP: PEER_IP
  sessions: SESSION_QTY
  ...

    以下を置き換えます。

    • BGP_PEER_NAME: ピアの名前。
    • CLUSTER_NAMESPACE: クラスタの名前空間。デフォルトでは、GKE on Bare Metal のクラスタ名前空間は、先頭に cluster- が付いたクラスタの名前です。たとえば、クラスタに test という名前をつける場合、名前空間は cluster-test になります。
    • PEER_LABEL: ロード バランシングに使用するピアの識別に使用されるラベル。このラベルは、BGPLoadBalancer カスタム リソースで指定されたラベルに対応している必要があります。
    • CLUSTER_ASN: 作成するクラスタの自律システム番号。
    • PEER_IP: 外部ピアデバイスの IP アドレス。外部ピアは 2 つ以上指定することをおすすめしますが、少なくとも 1 つは指定する必要があります。
    • PEER_ASN: 外部ピアデバイスを含むネットワークの自律システム番号。
    • SESSION_QTY: このピアに確立するセッションの数。いずれかのノードが停止した場合でもピアへの接続を維持できるように、少なくとも 2 つのセッションを確立することをおすすめします。

    追加の BGPPeer カスタム リソースを作成して、複数の外部ピアを指定できます。BGP セッションの高可用性のために、少なくとも 2 つの外部ピア（2 つのカスタム リソース）を指定することをおすすめします。BGPPeer カスタム リソースを指定しない場合、コントロール プレーンのピアは自動的にデータプレーン負荷分散に使用されます。

  9. bmctl cluster createを実行してクラスターを作成すると、プリフライト チェックが実行されます。他のチェックの中でも、プリフライトチェックでは、コントロール プレーンの BGP ピアリング構成を検証し、問題があればクラスター作成前に管理者のワークステーションに直接報告します。

    成功すると、追加された BGP ロード バランシングリソース（NetworkGatewayGroup、BGPLoadBalancer、BGPPeer）がユーザー クラスタ名前空間の管理クラスタに入ります。その後にこれらのリソースを更新する場合は、管理クラスタの kubeconfig ファイルを使用します。次に、管理クラスタはユーザー クラスタへの変更を調整します。これらのリソースをユーザー クラスタで直接編集すると、管理クラスタが後続の調整での変更を上書きします。

RFC 7911 で指定されているように、ピアリング セッションには BGP ADD-PATH 機能を使用することをおすすめします。デフォルトでは、BGP プロトコルでは、単一の接頭辞で 1 つのネクストホップのみがピアにアドバタイズされます。BGP ADD-PATH を使用すると、同じ接頭辞の複数のネクストホップをアドバタイズできます。ADD-PATH を BGP ベースのバンドル型負荷分散で使用すると、クラスタは複数のクラスタノードをロードバランサ サービス（プレフィックス）のフロントエンド ノード（ネクストホップ）としてアドバタイズできます。トラフィックを複数のパスに分散できるように、ネットワークで ECMP を有効にします。ネクストホップとして複数のクラスタノードをアドバタイズすることによってトラフィックをファンアウトする機能により、負荷分散のためのデータプレーン容量のスケーリングが向上します。

トップオブラック（ToR）スイッチやルーターなどの外部ピアデバイスが BGP ADD-PATH をサポートしている場合は、受信拡張機能のみを有効にするだけで十分です。BGP によるバンドル型負荷分散は ADD-PATH 機能なしで機能しますが、ピアリング セッションごとに単一の負荷分散ノードをアドバタイズする制限により、ロードバランサのデータプレーン容量が制限されます。ADD-PATH を使用しない場合、GKE on Bare Metal は、ロードバランサ ノードプールからアドバタイズするノードを選択し、異なる VIP のネクストホップを異なるノードに分散しようとします。

BGP ピアリングをロードバランサ ノードに制限する

GKE on Bare Metal は、フローティング IP アドレスと同じサブネット内のノードにフローティング IP アドレスを自動的に割り当てます。ロードバランサ ノードに到達しない場合でも、これらの IP アドレスから BGP セッションが開始されます。この動作は設計上、コントロール プレーン（BGP）がデータプレーン（LB ノードプール）から切り離されているためです。

BGP ピアリングに使用できるノードのセットを制限する場合は、ロードバランサ ノードにのみ使用される 1 つのサブネットを指定できます。つまり、そのサブネット内のすべてのノードをロードバランサのノードプールに構成できます。次に、BGP ピアリングに使用するフローティング IP アドレスを構成する場合は、同じサブネットからのアドレスであることを確認してください。GKE on Bare Metal は、フローティング IP アドレスの割り当てと BGP ピアリングがロードバランサ ノードからのみ行われることを確実にします。

デュアルスタック ネットワークを使用して BGP ロード バランシングを設定する

GKE on Bare Metal リリース 1.14.0 から、BGP ベースのバンドル ロードバランサは IPv6 をサポートします。IPv6 サポートの導入により、デュアルスタック ネットワーキング用に構成されたクラスタに IPv6 とデュアル スタックの LoadBalancer Service を構成できます。このセクションでは、BGP でデュアル スタック バンドル型ロード バランシングを構成するために必要な変更について説明します。

デュアルスタックの LoadBalancer Service を有効にするには、次の構成変更が必要です。

  • 基盤となるクラスタは、デュアルスタック ネットワーキング用に構成する必要があります。

    • クラスタ構成ファイルの spec.clusterNetwork.services.cidrBlocks の下に、IPv4 と IPv6 の両方の Service CIDR を指定します。

    • Pod の IPv4 と IPv6 の CIDR 範囲を指定するための適切な ClusterCIDRConfig リソースを定義します。

    デュアルスタック ネットワーキング用にクラスタを構成する方法については、IPv4 / IPv6 デュアルスタック ネットワーキングをご覧ください。

  • spec.loadBalancer.addressPools のクラスタ構成ファイルで IPv6 アドレスプールを指定します。MetalLB がデュアル スタック サービスに IP アドレスを割り振るには、IPv4 と IPv6 の両方の形式のアドレスを持つアドレスプールが少なくとも 1 つ必要です。

次の構成例では、BGP によるデュアルスタック バンドル型ロード バランシングに必要な変更を示しています。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  clusterNetwork:
  services:
      cidrBlocks:
      # Dual-stack Service IP addresses must be provided
      - 10.96.0.0/16
      - fd00::/112
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.8.0.10
      asn: 65002
    - ip: 10.8.0.11
      asn: 65002

    addressPools:
    - name: pool1
      addresses:
      # Each address must be either in the CIDR form (1.2.3.0/24)
      # or range form (1.2.3.1-1.2.3.5).
      - "203.0.113.1-203.0.113.20"
      - "2001:db8::1-2001:db8::20"  # Note the additional IPv6 range

... # Other cluster config info omitted
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100
---
apiVersion: baremetal.cluster.gke.io/v1alpha1
kind: ClusterCIDRConfig
metadata:
  name: cluster-wide-1
  namespace: cluster-bm
spec:
  ipv4:
    cidr: "192.168.0.0/16"
    perNodeMaskSize: 24
  ipv6:
    cidr: "2001:db8:1::/112"
    perNodeMaskSize: 120

BGP によるデュアル スタック、バンドル型ロード バランシングの制限事項

BGP でデュアル スタック バンドル型ロード バランシングを使用するようにクラスタを構成する場合は、次の制限事項に注意してください。

  • IPv6 コントロール プレーンのロード バランシングはサポートされていません。

  • IPv6 BGP セッションはサポートされていませんが、マルチプロトコル BGP を使用して IPv4 セッションで IPv6 ルートをアドバタイジングできます。

構成例

以降のセクションでは、さまざまなオプションまたは動作のために BGP ベースの負荷分散を構成する方法について説明します。

全てのノードが同じピアを使用するように構成する

次の図に示すように、この構成により、すべてのノードから到達可能な一連の外部ピア（10.8.0.10 と 10.8.0.11）が生成されます。データプレーン ノードに割り当てられたコントロール プレーン ノード（10.0.1.10、10.0.1.11、10.0.2.10）とフローティング IP アドレス（10.0.1.100、10.0.2.100）はすべてピアに到達します。

同一の外部ピアは、loadBalancer Service ピアリング用に予約されたフローティング IP アドレス（10.0.1.100 または 10.0.2.100）のいずれかからアクセスできます。フローティング IP アドレスは、同じサブネット内のノードに割り当てることができます。

すべてのノードが同じピアを使用する BGP 負荷分散

次のクラスタ構成サンプルに示すように、controlPlaneNodes を指定せずに、コントロール プレーン ノード bgpPeers のピアを構成します。ピアにノードが指定されていない場合、すべてのコントロール プレーン ノードがすべてのピアに接続します。

NetworkGatewayGroup カスタム リソースで、サービス負荷分散ピアリング セッションに使用するフローティング IP アドレスを指定します。この例では、BGPLoadBalancer が指定されていないため、コントロール プレーンのピアが自動的にデータプレーン BGP セッションに使用されます。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.8.0.10
      asn: 65002
    - ip: 10.8.0.11
      asn: 65002

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100

特定のコントロール プレーン ノードが特定の外部ピアとピアリングするように構成する

次の図に示すように、この構成では、2 つのコントロール プレーン ノード（10.0.1.10と10.0.1.11）が1つの外部ピア（10.0.1.254）とピアリングし、3 番目のコントロール プレーン ノード（10.0.2.10）が別の外部ピア（10.0.2.254）とピアリングすることになります。この構成は、すべてのノードをすべてのピアに接続する必要がない場合に役立ちます。たとえば、コントロール プレーン ノードが対応するトップオブラック（ToR）スイッチのみとピアリングする場合などです。

同一の外部ピアは、サービス負荷分散ピアリング セッション用に予約されたフローティング IP アドレス（10.0.1.100 または 10.0.2.100）のいずれかからアクセスできます。フローティング IP アドレスは、同じサブネット内のノードに割り当てることができます。

コントロール プレーン ノードとピアの明示的なマッピングによる BGP 負荷分散

以下のクラスタ構成例では、bgpPeers セクションのピアの controlPlaneNodes フィールドにIPアドレスを指定することで、特定のピアに接続できるコントロール プレーン ノードを制限しています。

NetworkGatewayGroup カスタム リソースで、サービス負荷分散ピアリング セッションに使用するフローティング IP アドレスを指定します。この例では、BGPLoadBalancer が指定されていないため、コントロール プレーンのピアが自動的にデータプレーン BGP セッションに使用されます。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.0.1.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.1.10
        - 10.0.1.11
    - ip: 10.0.2.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.2.10

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100

コントロール プレーンとデータプレーンを個別に構成する

次の図に示すように、この構成では、2 つのコントロール プレーン ノード（10.0.1.10と10.0.1.11）が1つの外部ピア（10.0.1.254）とピアリングし、3 番目のコントロール プレーン ノード（10.0.2.11）が別の外部ピア（10.0.2.254）とピアリングすることになります。

3 番目の外部ピア（10.0.3.254）には、Service 負荷分散ピアリング セッション用に予約されているフローティング IP アドレス（10.0.3.100 または 10.0.3.101）のいずれかからアクセスできます。フローティング IP アドレスは、同じサブネット内のノードに割り当てることができます。

コントロール プレーンとデータプレーンで別の構成を使用した BGP 負荷分散

以下のクラスタ構成例では、bgpPeers セクションのピアの controlPlaneNodes フィールドにIPアドレスを指定することで、特定のピアに接続できるコントロール プレーン ノードを制限しています。

NetworkGatewayGroup カスタム リソースで、Service ロード バランシング ピアリング セッションに使用するフローティング IP アドレスを指定します。

データプレーン ロード バランシングを構成するには:

  • BGPPeer リソースでデータプレーンの外部ピアを指定し、ピア選択に使用するラベル（cluster.baremetal.gke.io/default-peer: "true" など）を追加します。

  • BGPLoadBalancer リソースの peerSelector フィールドに一致するラベルを指定します。

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.0.1.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.1.10
        - 10.0.1.11
    - ip: 10.0.2.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.2.11

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.3.100
  - 10.0.3.101
---
apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
  name: default
  namespace: cluster-bm
spec:
  peerSelector:
    cluster.baremetal.gke.io/default-peer: "true"
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer1
  namespace: cluster-bm
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.3.254
  sessions: 2

BGP ベースの負荷分散構成の変更

BGP でバンドル型負荷分散を使用するように構成されたクラスタを作成した後、一部の構成設定を更新できますが、クラスタの作成後に更新できないものもあります。

BGP 関連リソース（NetworkGatewayGroup、BGPLoadBalancer、BGPPeer）を後で更新する場合は、管理クラスタの kubeconfig ファイルを使用します。次に、管理クラスタはユーザー クラスタへの変更を調整します。これらのリソースをユーザー クラスタで直接編集すると、管理クラスタが後続の調整での変更を上書きします。

コントロール プレーン

コントロール プレーンの BGP ピアリング情報は、Cluster リソースで更新できます。コントロール プレーンの負荷分散セクションで指定されたピアを追加または削除できます。

以下のセクションでは、コントロール プレーン BGP ピアリング情報の更新に関するベスト プラクティスの概要を説明します。

更新前にピアステータスを確認する

ピアの構成ミスのリスクを最小限に抑えるため、変更を加える前に、コントロール プレーンの BGP ピアリング セッションが想定どおりの状態であることを確認してください。たとえば、すべての BGP ピアリング セッションが現在稼働していることが想定される場合、すべての bgp-advertiser Pod が ready を報告し、セッションが稼働していることを示していることを確認します。現在のステータスが想定と一致しない場合は、ピア構成を更新する前に問題を修正してください。

コントロール プレーン BGP セッションの詳細の取得については、コントロール プレーン BGP セッションをご覧ください。

制御できる状態でピアを更新する

可能な場合は、一度に 1 つのピアを更新して、考えられる問題を切り分けできるようにします。

  1. 単一のピアを追加または更新します。
  2. 構成の整合性がとられる間待ちます。
  3. クラスタが新しいピアや更新されたピアに接続できることを確認します。
  4. 古いピアや不要なピアを削除します。

サービス

アドレスプールとロードバランサ ノード設定を更新するには、Cluster リソースの nodePoolSpec を編集します。

クラスタの作成後に BGP ピアリング構成を変更するには、NetworkGatewayGroup と BGPLoadBalancer のカスタム リソースを編集します。これらのカスタム リソースのピアリング情報の変更は、ターゲット クラスタの負荷分散ソリューションの構成に反映されます。

管理クラスタ内のクラスタ名前空間のソースリソースでの更新のみを行います。ターゲット（ユーザー）クラスタ内のリソースに加えた変更はすべて上書きされます。

トラブルシューティング

次のセクションでは、BGP を備えたバンドル型負荷分散のトラブルシューティング情報にアクセスする方法について説明します。

コントロール プレーン BGP セッション

コントロール プレーンの BGP ピアリング構成は、クラスタの作成時にプリフライト チェックで検証されます。プリフライト チェックでは次の処理が試行されます。

  • 各ピアとの BGP 接続を確立します。
  • コントロール プレーン VIP をアドバタイズします。
  • VIP を使用して、コントロール プレーン ノードにアクセスできることを確認します。

クラスタの作成がプリフライト チェックに失敗した場合は、プリフライト チェックログでエラーを確認してください。日付スタンプ付きのプリフライト チェック ログファイルは baremetal/bmctl-workspace/CLUSTER_NAME/log ディレクトリにあります。

ランタイム時に、コントロール プレーン BGP スピーカーは各コントロール プレーン ノードで静的 Pod として実行され、ログにイベント情報を書き込みます。これらの静的 Pod の名前には「bgpadvertiser」が含まれるため、次の kubectl get pods コマンドを使用して BGP スピーカー Pod のステータスを表示します。

kubectl -n kube-system get pods | grep bgpadvertiser

Pod が正常に動作している場合は、次のようなレスポンスが返されます。

bgpadvertiser-node-01                            1/1     Running   1          167m
bgpadvertiser-node-02                            1/1     Running   1          165m
bgpadvertiser-node-03                            1/1     Running   1          163m

次のコマンドを使用して、bgpadvertiser-node-01 Pod のログを表示します。

kubectl -n kube-system logs bgpadvertiser-node-01

Service の BGP セッション

BGPSession リソースは、現在の BGP セッションに関する情報を提供します。セッション情報を取得するには、まず現在のセッションを取得してから、いずれかのセッションの BGPSession リソースを取得します。

次の kubectl get コマンドを使用して、現在のセッションを一覧表示します。

kubectl -n kube-system get bgpsessions

このコマンドは、次の例のようなセッションのリストを返します。

NAME                 LOCAL ASN   PEER ASN   LOCAL IP     PEER IP      STATE            LAST REPORT
10.0.1.254-node-01   65500       65000      10.0.1.178   10.0.1.254   Established      2s
10.0.1.254-node-02   65500       65000      10.0.3.212   10.0.1.254   Established      2s
10.0.3.254-node-01   65500       65000      10.0.1.178   10.0.3.254   Established      2s
10.0.3.254-node-02   65500       65000      10.0.3.212   10.0.3.254   Established      2s

次の kubectl describe コマンドを使用して、10.0.1.254-node-01 BGP セッションの BGPSession リソースを取得します。

kubectl -n kube-system describe bgpsession 10.0.1.254-node-01

返される BGPSession リソースは、次の例のようになります。

Name:         10.0.1.254-node-01
Namespace:    kube-system
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1
Kind:         BGPSession
Metadata:
 (omitted)
Spec:
  Floating IP:  10.0.1.178
  Local ASN:    65500
  Local IP:     10.0.1.178
  Node Name:    node-01
  Peer ASN:     65000
  Peer IP:      10.0.1.254
Status:
  Advertised Routes:
    10.0.4.1/32
  Last Report Time:  2021-06-14T22:09:36Z
  State:             Established

kubectl get コマンドを使用して BGPAdvertisedRoute リソースを取得します。

kubectl -n kube-system get bgpadvertisedroutes

次の例のようなレスポンスに、現在アドバタイズされているルートが表示されます。

NAME                                    PREFIX           METRIC
default-default-load-balancer-example   10.1.1.34/32
default-gke-system-istio-ingress        10.1.1.107/32

kubectl describe を使用すると、各ルートがどのネクストホップをアドバタイズしているかの詳細を表示できます。

セルフマネージド クラスタのコントロール プレーン VIP へのアクセスを復元する

管理クラスタ、ハイブリッド クラスタ、スタンドアロン クラスタのコントロール プレーン VIP に再びアクセスするには、クラスタの BGP 構成を更新する必要があります。次のコマンド サンプルに示すように、SSH を使用してノードに接続し、kubectl を使用して編集用にクラスタ リソースを開きます。

ssh -i IDENTITY_FILE root@CLUSTER_NODE_IP

kubectl --kubeconfig /etc/kubernetes/admin.conf edit -n CLUSTER_NAMESPACE cluster CLUSTER_NAME

以下を置き換えます。

  • IDENTITY_FILE: 公開鍵認証の ID 鍵を含む SSH ID ファイルの名前。
  • CLUSTER_NODE_IP: クラスタノードの IP アドレス。
  • CLUSTER_NAMESPACE: クラスタの名前空間。
  • CLUSTER_NAME: クラスタの名前。

クラスタ オブジェクト内の BGP ピアリング構成を変更します。新しいクラスタ構成を保存したら、bgpadvertiser Pod の正常性をモニタリングします。構成が機能している場合、Pod はピアに接続すると再起動し、正常な状態になります。

手動での BGP の確認

このセクションでは、BGP 構成を手動で確認する手順について説明します。この手順では、長時間実行されている BGP の構成をネットワーク チームとともにより詳細にデバッグできるように BGP 接続を設定します。この手順は、クラスタを作成する前の構成の検証や BGP 関連のプリフライト チェックが失敗した場合に使用されます。

プリフライト チェックでは、次の BGP 確認タスクが自動化されています。

  • BGP 接続をピアに設定します。
  • コントロール プレーン VIP をアドバタイズします。
  • 他のすべてのクラスタノードから VIP に送信されるトラフィックが現在のロードバランサ ノードに到達していることを確認します。

これらのタスクは、各コントロール プレーン ノードの BGP ピアごとに実行されます。クラスタを作成する際、これらのチェックに合格することは非常に重要です。ただし、プリフライト チェックでは、長時間実行接続が作成されないため、障害のデバッグは困難です。

以降のセクションでは、BGP 接続を設定し、単一のクラスタマシンから 1 つのピアへのルートをアドバタイズする手順について説明します。複数のマシンと複数のピアをテストするには、さまざまなマシンとピアの組み合わせで同じ手順を繰り返します。

コントロール プレーン ノードからの BGP 接続が確立されるため、計画しているいずれかのコントロール プレーン ノードからこの手順をテストしてください。

BGP テスト プログラム バイナリを取得する

管理ワークステーションで、このセクションの手順に沿って実行します。次の手順では、BGP 接続のテストに使用する bgpadvertiser プログラムを取得して、テストするコントロール プレーン ノードにコピーします。

  1. ansible-runner Docker イメージを pull します。

    レジストリ ミラーを使用しない場合

    レジストリ ミラーを使用しない場合は、次のコマンドを実行して ansible-runner Docker イメージを pull します。

    gcloud auth login
gcloud auth configure-docker
docker pull gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13

    レジストリ ミラーを使用する場合

    レジストリ ミラーを使用する場合は、次のコマンドを実行して ansible-runner Docker イメージを pull します。

    docker login REGISTRY_HOST
docker pull REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13

    REGISTRY_HOST は、レジストリ ミラー サーバーの名前に置き換えます。

  2. bgpadvertiser バイナリを抽出する方法は以下のとおりです。

    レジストリ ミラーを使用しない場合

    bgpadvertiser バイナリを抽出するには、次のコマンドを実行します。

    docker cp $(docker create gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .

    レジストリ ミラーを使用する場合

    bgpadvertiser バイナリを抽出するには、次のコマンドを実行します。

    docker cp $(docker create REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .

  3. テストするコントロール プレーン ノードに bgpadvertiser バイナリをコピーするには、次のコマンドを実行します。

    scp bgpadvertiser USERNAME>@CP_NODE_IP:/tmp/

    以下を置き換えます。

    • USERNAME: コントロール プレーン ノードへのアクセスに使用するユーザー名。

    • CP_NODE_IP: コントロール プレーン ノードの IP アドレス。

BGP 接続を設定する

このセクションの手順は、コントロール プレーン ノードで実行します。

  1. /tmp/bgpadvertiser.conf のノードに、次のような構成ファイルを作成します。

    localIP: NODE_IP
localASN: CLUSTER_ASN
peers:
- peerIP: PEER_IP
  peerASN: PEER_ASN

    以下を置き換えます。

    • NODE_IP: 使用中のコントロール プレーン ノードの IP アドレス。
    • CLUSTER_ASN: クラスタで使用される自律システム番号。
    • PEER_IP: テストするいずれかの外部ピアの IP アドレス。
    • PEER_ASN: 外部ピアデバイスを含むネットワークの自律システム番号。

  2. bgpadvertiser デーモンを実行して、次のコマンドでコントロール プレーン VIP を置き換えます。

    /tmp/bgpadvertiser --config /tmp/bgpadvertiser.conf --advertise-ip CONTROL_PLANE_VIP

    CONTROL_PLANE_VIP は、コントロール プレーン VIP に使用する IP アドレスに置き換えます。このコマンドにより、BGP アドバタイザーがこのアドレスをピアにアドバタイズします。

  3. プログラムの出力を表示します。

    この時点で、bgpadvertiser デーモンが起動してピアへの接続を試行し、VIP をアドバタイズします。BGP 接続が確立されると、プログラムは BGP_FSM_ESTABLISHED を含むメッセージを定期的に出力します（次のサンプル出力をご覧ください）。

    {"level":"info","ts":1646788815.5588224,"logger":"BGPSpeaker","msg":"GoBGP gRPC debug endpoint disabled","localIP":"21.0.101.64"}
{"level":"info","ts":1646788815.5596201,"logger":"BGPSpeaker","msg":"Started.","localIP":"21.0.101.64"}
I0309 01:20:15.559667 1320826 main.go:154] BGP advertiser started.
I0309 01:20:15.561434 1320826 main.go:170] Health status HTTP server started at "127.0.0.1:8080".
INFO[0000] Add a peer configuration for:21.0.101.80      Topic=Peer
{"level":"info","ts":1646788815.5623345,"logger":"BGPSpeaker","msg":"Peer added.","localIP":"21.0.101.64","peer":"21.0.101.80/4273481989"}
DEBU[0000] IdleHoldTimer expired                         Duration=0 Key=21.0.101.80 Topic=Peer
I0309 01:20:15.563503 1320826 main.go:187] Peer applied: {4273481989 21.0.101.80}
DEBU[0000] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_ACTIVE old=BGP_FSM_IDLE reason=idle-hold-timer-expired
DEBU[0000] create Destination                            Nlri=10.0.0.1/32 Topic=Table
{"level":"info","ts":1646788815.5670514,"logger":"BGPSpeaker","msg":"Route added.","localIP":"21.0.101.64","route":{"ID":0,"Metric":0,"NextHop":"21.0.101.64","Prefix":"10.0.0.1/32","VRF":""}}
I0309 01:20:15.568029 1320826 main.go:199] Route added: {0 0 21.0.101.64 10.0.0.1/32 }
I0309 01:20:15.568073 1320826 main.go:201] BGP advertiser serving...
DEBU[0005] try to connect                                Key=21.0.101.80 Topic=Peer
DEBU[0005] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_OPENSENT old=BGP_FSM_ACTIVE reason=new-connection
DEBU[0005] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_OPENCONFIRM old=BGP_FSM_OPENSENT reason=open-msg-received
INFO[0005] Peer Up                                       Key=21.0.101.80 State=BGP_FSM_OPENCONFIRM Topic=Peer
DEBU[0005] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_ESTABLISHED old=BGP_FSM_OPENCONFIRM reason=open-msg-negotiated
DEBU[0005] sent update                                   Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer attributes="[{Origin: i} 4273481990 {Nexthop: 21.0.101.64}]" nlri="[10.0.0.1/32]" withdrawals="[]"
DEBU[0006] received update                               Key=21.0.101.80 Topic=Peer attributes="[{Origin: i} 4273481989 4273481990 {Nexthop: 21.0.101.64}]" nlri="[10.0.0.1/32]" withdrawals="[]"
DEBU[0006] create Destination                            Nlri=10.0.0.1/32 Topic=Table
DEBU[0035] sent                                          Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer data="&{{[] 19 4} 0x166e528}"
DEBU[0065] sent                                          Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer data="&{{[] 19 4} 0x166e528}"

こうしたメッセージが表示されない場合は、構成ファイルの BGP 構成パラメータを再確認し、ネットワーク管理者に確認してください。これで BGP 接続が設定されます。ネットワーク管理者は、自身の側で接続が確立されていることと、アドバタイズされたルートが表示されることを確認します。

トラフィックのテスト

ネットワークで VIP にトラフィックが転送できることをテストするには、bgpadvertiser を実行しているコントロール プレーン ノードに VIP を追加する必要があります。bgpadvertiser の実行を継続できるように、別のターミナルで以下のコマンドを実行します。

  1. VIP をコントロール プレーン ノードに追加します。

    ip addr add CONTROL_PLANE_VIP/32 dev INTF_NAME

    以下を置き換えます。

    • CONTROL_PLANE_VIP: bgpadvertiser の VIP --advertise-ip 引数。
    • INTF_NAME: ノード上の Kubernetes インターフェース。つまり、loadBalancer.bgpPeers.controlPlaneNodes の GKE on Bare Metal 構成に入力した IP アドレスを持つインターフェースです。

  2. 別のノードから VIP に ping します。

    ping CONTROL_PLANE_VIP

    ping が失敗する場合は、ネットワーク デバイスの BGP 構成に問題がある可能性があります。ネットワーク管理者と協力して、構成を確認し、問題を解決してください。

クリーンアップ

BGP が機能していることを手動で確認してから、次の手順に沿ってノードをリセットしてください。ノードが正しくリセットされない場合は、手動セットアップでプリフライト チェックまたは後続のクラスタ作成に支障をきたす可能性があります。

  1. トラフィック テスト用に VIP を追加した場合は、コントロール プレーン ノードから VIP を削除します。

    ip addr del CONTROL_PLANE_VIP/32 dev INTF_NAME

  2. コントロール プレーン ノードの bgpadvertiser ターミナルで Ctrl+C を押して bgpadvertiser を停止します。

  3. bgpadvertiser プロセスが実行されていないことを確認します。

    ps -ef | grep bgpadvertiser

  4. 動作中のプロセスが表示される場合は、kill コマンドを使用してプロセスを停止します。