バージョン 1.10。このバージョンは現在サポートされていません。詳細については、バージョンのサポートポリシーをご覧ください。バージョン 1.11 にアップグレードする方法については、1.11 ドキュメントのベアメタル版 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 アドレスから開始されます。
サービスピアリングセッションは、NetworkGatewayGroup カスタムリソースで指定したフローティング 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 アドレスは、クラスタ構成ファイルに含めることができる 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 でバンドルされたロードバランシングを設定する方法について説明します。

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 は、クラスタの名前空間に置き換えます。デフォルトでは、ベアメタル版 Anthos クラスタのクラスタ名前空間は、先頭に cluster- が付いたクラスタの名前です。たとえば、クラスタに test という名前をつける場合、名前空間は cluster-test になります。
クラスタ構成ファイルの 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 つの外部ピアを指定することをおすすめします。複数のピアを使用する例については、構成例をご覧ください。

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

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

この手順は省略可能です。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>
...
```
NetworkGatewayGroup カスタムリソースを構成して、フローティング IP アドレスを予約します。

フローティング IP アドレスは、データプレーンロードバランシングのピアリングセッションで使用されます。
```
...
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: CLUSTER_NAMESPACE
spec:
  floatingIPs:
  - FLOATING_IP
...
```
以下を置き換えます。
- CLUSTER_NAMESPACE: クラスタの名前空間。デフォルトでは、ベアメタル版 Anthos クラスタのクラスタ名前空間は、先頭に cluster- が付いたクラスタの名前です。たとえば、クラスタに test という名前をつける場合、名前空間は cluster-test になります。
- FLOATING_IP: クラスタのサブネットの 1 つの IP アドレス。IP アドレスは 1 つ以上指定する必要がありますが、2 つ以上指定することをおすすめします。
NetworkGatewayGroup カスタムリソースの名前が default であり、クラスタの名前空間を使用していることを確認してください。NetworkGatewayGroup カスタムリソース仕様の内容については、構成例をご覧ください。
（省略可）BGPLoadBalancer カスタムリソースを構成して、データプレーンロードバランシングに使用するピアを指定します。
```
...
---
apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
  name: default
  namespace: CLUSTER_NAMESPACE
spec:
  peerSelector:
    PEER_LABEL: "true"
...
```
以下を置き換えます。
- CLUSTER_NAMESPACE: クラスタの名前空間。デフォルトでは、ベアメタル版 Anthos クラスタのクラスタ名前空間は、先頭に cluster- が付いたクラスタの名前です。たとえば、クラスタに test という名前をつける場合、名前空間は cluster-test になります。
- PEER_LABEL: ロードバランシングに使用するピアの識別に使用されるラベル。一致するラベルを持つどの BGPPeer カスタムリソースも、各ピアの詳細を指定します。
BGPLoadBalancer カスタムリソースの名前が default であり、クラスタの名前空間を使用していることを確認してください。BGPLoadBalancer カスタムリソースを指定しない場合、コントロールプレーンのピアは自動的にデータプレーン負荷分散に使用されます。包括的な例については、構成例をご覧ください。
（省略可）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: クラスタの名前空間。デフォルトでは、ベアメタル版 Anthos クラスタのクラスタ名前空間は、先頭に cluster- が付いたクラスタの名前です。たとえば、クラスタに test という名前をつける場合、名前空間は cluster-test になります。
- PEER_LABEL: ロードバランシングに使用するピアの識別に使用されるラベル。このラベルは、BGPLoadBalancer カスタムリソースで指定されたラベルに対応している必要があります。
- CLUSTER_ASN: 作成するクラスタの自律システム番号。
- PEER_IP: 外部ピアデバイスの IP アドレス。外部ピアは 2 つ以上指定することをおすすめしますが、少なくとも 1 つは指定する必要があります。
- PEER_ASN: 外部ピアデバイスを含むネットワークの自律システム番号。
- SESSION_QTY: このピアに確立するセッションの数。いずれかのノードが停止した場合でもピアへの接続を維持できるように、少なくとも 2 つのセッションを確立することをおすすめします。
追加の BGPPeer カスタムリソースを作成して、複数の外部ピアを指定できます。BGP セッションの高可用性のために、少なくとも 2 つの外部ピア（2 つのカスタムリソース）を指定することをおすすめします。BGPPeer カスタムリソースを指定しない場合、コントロールプレーンのピアは自動的にデータプレーン負荷分散に使用されます。
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 のピアを構成します。ピアにノードが指定されていない場合、すべてのコントロールプレーンノードがすべてのピアに接続します。

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

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

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

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

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

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

警告: 特にセルフマネージドクラスタ（管理者、ハイブリッド、スタンドアロンのクラスタ）の場合で、コントロールプレーンの BGP ピアリング情報の更新は慎重に行ってください。クラスタがコントロールプレーン VIP をピアにアドバタイズできない場合、コントロールプレーン VIP と Kubernetes コントロールプレーンはクラスタ外部からアクセスできなくなります。たとえば、ピアリング構成で有効なピアを参照していない場合や、構成ミスやネットワークの問題によりクラスタがピアに接続できない場合、アクセスは失われます。アクセスを復旧する方法については、セルフマネージドクラスタのコントロールプレーン VIP へのアクセスの復旧をご覧ください。

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

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

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

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

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

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

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

サービス

アドレスプールとロードバランサノード設定を更新するには、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
bgppeer1-node-03   65500       65000      10.0.1.178   10.0.1.254   Established      2s
bgppeer1-node-05   65500       65000      10.0.3.212   10.0.1.254   Established      2s
bgppeer2-node-03   65500       65000      10.0.1.178   10.0.3.254   Established      2s
bgppeer2-node-05   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 プログラムを取得して、テストするコントロールプレーンノードにコピーします。

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