バージョン 1.9. このバージョンは現在サポートされていません。詳細については、バージョンのサポートポリシーをご覧ください。バージョン 1.10 にアップグレードする方法については、1.10 ドキュメントのベアメタル版 Anthos のアップグレードをご覧ください。

利用可能なサポートされているバージョン: 1.13 | 1.12 | 1.11

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 を備えたバンドル負荷分散を有効にして構成します。

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:
...
```
クラスタ構成ファイルの 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
    ...
```
コントロールプレーンの 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 ピアリング構成は、クラスタの作成後には更新できません。
loadBalancer.ports、loadBalancer.vips、loadBalancer.addressPools の各フィールドを設定します（図はデフォルト値です）。

注: バンドル型 BGP ベースの負荷分散（mode: bundled と type: bgp）を使用する場合、指定した　VIP　はクラスタ内のノードと同じサブネットでない必要があります。
```
...
  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
...
```
データプレーンのロードバランシングに使用するクラスタノードを指定します。

この手順は省略可能です。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>
...
```
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 カスタムリソース仕様の表示例については、構成例をご覧ください。
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 つの外部ピアを指定することをおすすめします。複数のピアを使用する例については、構成例をご覧ください。
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.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 のピアを構成します。ピアにノードが指定されていない場合、すべてのコントロールプレーンノードがすべてのピアに接続します。

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.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アドレスを指定することで、特定のピアに接続できるコントロールプレーンノードを制限しています。

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/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

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

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

コントロールプレーンとデータプレーンで別の構成を使用した 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.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 プログラムを取得して、テストするコントロールプレーンノードにコピーします。

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 は、レジストリミラーサーバーの名前に置き換えます。
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 .
```
テストするコントロールプレーンノードに bgpadvertiser バイナリをコピーするには、次のコマンドを実行します。
```
scp bgpadvertiser USERNAME>@CP_NODE_IP:/tmp/
```
以下を置き換えます。
- USERNAME: コントロールプレーンノードへのアクセスに使用するユーザー名。
- CP_NODE_IP: コントロールプレーンノードの IP アドレス。

BGP 接続を設定する

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

/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: 外部ピアデバイスを含むネットワークの自律システム番号。
bgpadvertiser デーモンを実行して、次のコマンドでコントロールプレーン VIP を置き換えます。
```
/tmp/bgpadvertiser --config /tmp/bgpadvertiser.conf --advertise-ip CONTROL_PLANE_VIP
```
CONTROL_PLANE_VIP は、コントロールプレーン VIP に使用する IP アドレスに置き換えます。このコマンドにより、BGP アドバタイザーがこのアドレスをピアにアドバタイズします。

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

この時点で、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 の実行を継続できるように、別のターミナルで以下のコマンドを実行します。

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 アドレスを持つインターフェースです。
別のノードから VIP に ping します。
```
ping CONTROL_PLANE_VIP
```
ping が失敗する場合は、ネットワークデバイスの BGP 構成に問題がある可能性があります。ネットワーク管理者と協力して、構成を確認し、問題を解決してください。

クリーンアップ

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

トラフィックテスト用に VIP を追加した場合は、コントロールプレーンノードから VIP を削除します。
```
ip addr del CONTROL_PLANE_VIP/32 dev INTF_NAME
```
コントロールプレーンノードの bgpadvertiser ターミナルで Ctrl+C を押して bgpadvertiser を停止します。
bgpadvertiser プロセスが実行されていないことを確認します。
```
ps -ef | grep bgpadvertiser
```
動作中のプロセスが表示される場合は、kill コマンドを使用してプロセスを停止します。