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

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

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

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

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

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

サービス負荷分散

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

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

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

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

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

外部ピア

フローティング IP アドレスでのピアリング セッションに使用する外部ピアを、クラスタ構成ファイルに追加する BGPLoadBalancer カスタム リソースで指定します。外部ピアは、クラスタ構成ファイルの loadBalancer.controlPlaneBGP セクションでコントロール プレーン ピアリングに指定したものと同じでも、別のピアを指定することもできます。

Anthos ネットワーク ゲートウェイ コントローラは、予約済みのフローティング IP アドレスのセットから、各外部ピアに対する 2 つのセッションを確立しようとします。BGP セッションで高可用性を確保するために、少なくとも 2 つの外部ピアを指定することをおすすめします。Service 負荷分散に指定された各外部ピアは、AnthosNetworkGateway カスタム リソースで指定されたすべてのフローティング 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 を備えたバンドル負荷分散を有効にして構成します。

  1. baremetal.cluster.gke.io/enable-anthos-network-gateway アノテーションをクラスタ構成ファイルに追加し、true に設定します。

    このアノテーションにより、Anthos Network Gateway コントローラが有効になります。

    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      name: bm
      namespace: cluster-bm
      # This annotation is required for BGP load balancer
      annotations:
        baremetal.cluster.gke.io/enable-anthos-network-gateway: "true"
    spec:
    ...
    
  2. クラスタ構成ファイルの loadBalancer セクションで、modebundled に設定し、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 つの外部ピアを指定することをおすすめします。複数のピアを使用する例については、構成例をご覧ください。

    コントロール プレーンのこの BGP ピアリング構成は、クラスタの作成後には更新できません。

  4. loadBalancer.portsloadBalancer.vipsloadBalancer.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. AnthosNetworkGateway カスタム リソースを構成して、フローティング IP アドレスを予約します。

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

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

    以下を置き換えます。

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

    AnthosNetworkGateway カスタム リソース仕様の表示例については、構成例をご覧ください。

  7. BGPLoadBalancer カスタム リソースを構成して、データプレーンの BGP ピアリング情報を指定します。

    ...
    ---
    apiVersion: networking.gke.io/v1alpha1
    kind: BGPLoadBalancer
    metadata:
      name: bgplb
      namespace: CLUSTER_NAMESPACE
    spec:
      localASN: CLUSTER_ASN
      peers:
      - peerIP: PEER_IP
        peerASN: PEER_ASN
        ...
    

    以下を置き換えます。

    • CLUSTER_NAMESPACE: クラスタの名前空間。デフォルトでは、ベアメタル版 Anthos クラスタのクラスタ名前空間は、先頭に cluster- が付いたクラスタの名前です。たとえば、クラスタに test という名前を指定した場合、名前空間は cluster-test になります。
    • CLUSTER_ASN: 作成するクラスタの自律システム番号。
    • PEER_IP: 外部ピアデバイスの IP アドレス。少なくとも 1 つの外部ピアを指定する必要がありますが、2 つ以上のピアを指定することをおすすめします。コントロール プレーンで指定したものと同じピアを使用できます。
    • PEER_ASN: 外部ピアデバイスを含むネットワークの自律システム番号。

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

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

BGP ADD-PATH を使用して、セッションごとに複数のネクストホップをアドバタイズする

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

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

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

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

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

構成例

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

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

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

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

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

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

AnthosNetworkGateway カスタム リソースで、サービス負荷分散ピアリング セッションに使用するフローティング IP アドレスを指定します。BGPLoadBalancer リソースで、対応する外部ピアを指定します。

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/v1alpha1
kind: AnthosNetworkGateway
metadata:
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
metadata:
  name: bgplb
  namespace: cluster-bm
spec:
  localASN: 65001
  peers:
  - peerIP: 10.8.0.10
    peerASN: 65002
  - peerIP: 10.8.0.11
    peerASN: 65002

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

次の図に示すように、この構成では、2 つのコントロール プレーン ノード(10.0.1.1010.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アドレスを指定することで、特定のピアに接続できるコントロール プレーン ノードを制限しています。

AnthosNetworkGateway カスタム リソースで、サービス負荷分散ピアリング セッションに使用するフローティング IP アドレスを指定します。BGPLoadBalancer リソースで、対応する外部ピアを指定します。

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

    peers:
    - 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/v1alpha1
kind: AnthosNetworkGateway
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
metadata:
  name: bgplb
  namespace: cluster-bm
spec:
  localASN: 65001
  peers:
  - peerIP: 10.0.1.254
    peerASN: 65002
  - peerIP: 10.0.2.254
    peerASN: 65002

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

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

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

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

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

AnthosNetworkGateway カスタム リソースで、サービス負荷分散ピアリング セッションに使用するフローティング IP アドレスを指定します。BGPLoadBalancer リソースで、対応する外部ピアを指定します。

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

    peers:
    - 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/v1alpha1
kind: AnthosNetworkGateway
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.3.100
  - 10.0.3.101
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
  name: bgplb
  namespace: cluster-bm
spec:
  bgp:
    localASN: 65001
    peers:
    - peerIP: 10.0.3.254
      peerASN: 65002

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

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

コントロール プレーン

プレビュー中は、コントロール プレーンの負荷分散構成を変更できません。

サービス

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

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

トラブルシューティング

次のセクションでは、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                            AGE
10.0.1.254-node-01              170m
10.0.1.254-node-05              170m
10.0.3.254-node-01              170m
10.0.3.254-node-05              170m

次の 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/v1alpha1
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                                  AGE
bgplb-default-load-balancer-example   5d5h
bgplb-gke-system-istio-ingress        6d

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

手動での 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 の Anthos clusters 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 コマンドを使用してプロセスを停止します。