このドキュメントでは、Google Distributed Cloud の 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 アドレスから開始されます。 - GDC コントローラのネットワーク ゲートウェイは、フローティング IP アドレスを管理します。
- バンドル型 BGP ベースの負荷分散は eBGP ピアリングのみをサポートします。
- マルチホップ ピアリングは、デフォルトでサポートされています。
- BGP セッションの MD5 パスワードはサポートされていません。
- IPv6 ベースのピアリング セッションはサポートされていません。
- ピアにアドバタイズされたルートは、ネットワーク全体に再配布され、クラスタ内のあらゆる場所から到達可能である必要があります。
- ピアリング セッションでは、受信モードで BGP
ADD-PATH機能を使用することをおすすめします。 - 各ピアから複数のパスをアドバタイズすると、アクティブ/アクティブの負荷分散になります。
- 複数のパスを使用して一連のロードバランサ ノードにトラフィックを分散できるように、等価コスト マルチパス ルーティング（ECMP）をネットワークで有効にする必要があります。
コントロール プレーンの負荷分散
クラスタ内の各コントロール プレーン ノードが、インフラストラクチャ内の 1 つ以上のピアとの BGP セッションを確立します。各コントロール プレーン ノードには少なくとも 1 つのピアが必要です。クラスタ構成ファイルでは、どのコントロール プレーン ノードがどの外部ピアに接続するかを構成できます。
次の図は、コントロール プレーンのピアリングの例を示しています。クラスタには、1 つのサブネットと別のサブネットに 2 つのコントロール プレーン ノードがあります。各サブネットには外部ピア（TOR）があり、Google Distributed Cloud コントロール プレーン ノードがその TOR とピアリングします。
サービス負荷分散
コントロール プレーン ピアリングの各コントロール プレーン ノードから開始されるピアリング セッションに加えて、LoadBalancer Service 用に追加のピアリング セッションが開始されます。これらのピアリング セッションは、クラスタノードの IP アドレスから直接開始されるのではなく、フローティング IP アドレスを使用します。
externalTrafficPolicy=Local ネットワーク ポリシーを使用する Service はサポートされていません。ただし、externalTrafficPolicy=Local の設定はワークロードに依存しており、Service をサポートする Pod が追加されるかノードから完全に削除されるたびに、ルートが更新されます。このルート更新動作により、等価コスト マルチパス（ECMP）ルーティングでトラフィック フローが変更され、トラフィックが減少する可能性があります。
フローティング IP アドレス
サービス負荷分散では、BGP ピアリングに使用するクラスタノードのサブネットでフローティング IP アドレスを予約する必要があります。クラスタには少なくとも 1 つのフローティング IP アドレスが必要ですが、BGP セッションの高可用性を確保するために、少なくとも 2 つのアドレスを予約することをおすすめします。フローティング IP アドレスは、クラスタ構成ファイルに含めることができる NetworkGatewayGroup カスタム リソース（CR）で指定されます。
フローティング IP アドレスを使用すると、BGP スピーカーの IP アドレスをノードにマッピングする必要がなくなります。GDC 用ネットワーク ゲートウェイ コントローラは、NetworkGatewayGroup をノードに割り当て、フローティング IP アドレスを管理します。ノードがダウンすると、Network Gateway for GDC コントローラはフローティング IP アドレスを再割り当てし、外部ピアがピアリングする確定的 IP アドレスを持っていることを確認します。
外部ピア
データプレーン負荷分散では、クラスタ構成ファイルの loadBalancer.controlPlaneBGP セクションでコントロール プレーン ピアリングに指定したものと同じ外部ピアを使用できます。別の BGP ピアを指定することもできます。
データプレーンのピアリングに異なる BGP ピアを指定する場合は、クラスタ構成ファイルに BGPLoadBalancer と BGPPeer のリソース仕様を追加します。これらのカスタム リソースを指定しない場合、コントロール プレーンのピアが自動的にデータプレーンに使用されます。
フローティング IP アドレスでのピアリング セッションに使用する外部ピアを、クラスタ構成ファイルに追加する BGPPeer カスタム リソースで指定します。BGPPeer リソースには、対応する BGPLoadBalancer カスタム リソースで識別するためのラベルが含まれています。BGPLoadBalancer カスタム リソースの peerSelector フィールドで一致するラベルを指定して、使用する BGPPeer を選択します。
Network Gateway for GDC コントローラは、予約済みのフローティング IP アドレスのセットから、各外部ピアへのセッションを確立しようとします（セッション数は構成可能）。BGP セッションの高可用性を確保するために、少なくとも 2 つの外部ピアを指定することをおすすめします。Service ロード バランシングに指定された各外部ピアは、NetworkGatewayGroup カスタム リソースで指定されたすべてのフローティング IP アドレスとピアリングするように構成する必要があります。
ロードバランサ ノード
クラスタのノードのサブセットは負荷分散に使用されます。つまり、これらのノードが、着信する負荷分散トラフィックを受け入れるようにアドバタイズされたノードになります。このノードセットはデフォルトでコントロール プレーンのノードプールですが、クラスタ構成ファイルの loadBalancer セクションで別のノードプールを指定することもできます。ノードプールを指定すると、コントロール プレーン ノードプールではなく、ロードバランサ ノードにノードプールが使用されます。
フローティング IP アドレスは BGP スピーカーとして機能し、ロードバランサ ノードで実行される場合があります。フローティング IP アドレスは、ロードバランサ ノードであるかどうかに関係なく、同じサブネット内のノードに割り当てられ、ピアリングがそこから開始されます。ただし、BGP を介してアドバタイズされるネクストホップは常にロードバランサノードです。
ピアリング トポロジの例
次の図は、BGP ピアリングを使用したサービス負荷分散の例を示しています。それぞれのサブネット内のノードには、2 つのフローティング IP アドレスが割り当てられます。外部ピアが 2 つ定義されています。それぞれのフローティング IP は両方の外部ピアとピアリングします。
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: trueCLUSTER_NAMESPACEは、クラスタの名前空間に置き換えます。デフォルトでは、Google Distributed Cloud のクラスタ Namespace は、先頭に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 nodeSelector: # optional - NODE_SELECTOR ...以下を置き換えます。
CLUSTER_NAMESPACE: クラスタの名前空間。デフォルトでは、Google Distributed Cloud のクラスタ Namespace は、先頭にcluster-が付いたクラスタの名前です。たとえば、クラスタにtestという名前をつける場合、名前空間はcluster-testになります。FLOATING_IP: クラスタのサブネットの 1 つの IP アドレス。IP アドレスは 1 つ以上指定する必要がありますが、2 つ以上指定することをおすすめします。NODE_SELECTOR:（省略可）トップオブラック（ToR）スイッチなどの外部ピアとのピアリング セッションをインスタンス化するためのノードを識別するラベルセレクタ。不要な場合は、このフィールドを削除します。
NetworkGatewayGroupカスタム リソースの名前がdefaultであり、クラスタの名前空間を使用していることを確認してください。NetworkGatewayGroupカスタム リソース仕様の内容については、構成例をご覧ください。（省略可）
BGPLoadBalancerカスタム リソースを構成して、データプレーン ロード バランシングに使用するピアを指定します。... --- apiVersion: networking.gke.io/v1 kind: BGPLoadBalancer metadata: name: default namespace: CLUSTER_NAMESPACE spec: peerSelector: PEER_LABEL: "true" ...以下を置き換えます。
CLUSTER_NAMESPACE: クラスタの名前空間。デフォルトでは、Google Distributed Cloud のクラスタ Namespace は、先頭に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 selectors: # Optional gatewayRefs: - GATEWAY_REF ...以下を置き換えます。
BGP_PEER_NAME: ピアの名前。CLUSTER_NAMESPACE: クラスタの名前空間。デフォルトでは、Google Distributed Cloud のクラスタ Namespace は、先頭にcluster-が付いたクラスタの名前です。たとえば、クラスタにtestという名前をつける場合、名前空間はcluster-testになります。PEER_LABEL: ロード バランシングに使用するピアの識別に使用されるラベル。このラベルは、BGPLoadBalancerカスタム リソースで指定されたラベルに対応している必要があります。CLUSTER_ASN: 作成するクラスタの自律システム番号。PEER_IP: 外部ピアデバイスの IP アドレス。外部ピアは 2 つ以上指定することをおすすめしますが、少なくとも 1 つは指定する必要があります。PEER_ASN: 外部ピアデバイスを含むネットワークの自律システム番号。SESSION_QTY: このピアに確立するセッションの数。いずれかのノードが停止した場合でもピアへの接続を維持できるように、少なくとも 2 つのセッションを確立することをおすすめします。GATEWAY_REF:（省略可）ピアリングに使用する NetworkGatewayGroup リソースの名前。未設定の場合は、一部またはすべてのゲートウェイ リソースが使用される可能性があります。この設定を NetworkGatewayGroups リソースのnodeSelectorフィールドと組み合わせて使用し、ToR スイッチなどの特定の外部ピアとのピアリングに使用するノードを選択します。必要に応じて、1 行に 1 つのゲートウェイの形式で複数の NetworkGatewayGroups を選択するための複数のエントリを取得できます。
追加の
BGPPeerカスタム リソースを作成して、複数の外部ピアを指定できます。BGP セッションの高可用性のために、少なくとも 2 つの外部ピア（2 つのカスタム リソース）を指定することをおすすめします。BGPPeerカスタム リソースを指定しない場合、コントロール プレーンのピアは自動的にデータプレーン負荷分散に使用されます。bmctl cluster createを実行してクラスターを作成すると、プリフライト チェックが実行されます。他のチェックの中でも、プリフライトチェックでは、コントロール プレーンの BGP ピアリング構成を検証し、問題があればクラスター作成前に管理者のワークステーションに直接報告します。成功すると、追加された BGP ロード バランシングリソース（NetworkGatewayGroup、BGPLoadBalancer、BGPPeer）がユーザー クラスタ名前空間の管理クラスタに入ります。その後にこれらのリソースを更新する場合は、管理クラスタの kubeconfig ファイルを使用します。次に、管理クラスタはユーザー クラスタへの変更を調整します。これらのリソースをユーザー クラスタで直接編集すると、管理クラスタが後続の調整での変更を上書きします。
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 を使用しない場合、Google Distributed Cloudl は、ロードバランサ ノードプールからアドバタイズするノードを選択し、異なる VIP のネクストホップを異なるノードに分散しようとします。
BGP ピアリングをロードバランサ ノードに制限する
Google Distributed Cloud は、フローティング IP アドレスと同じサブネット内のノードにフローティング IP アドレスを自動的に割り当てます。ロードバランサ ノードに到達しない場合でも、これらの IP アドレスから BGP セッションが開始されます。この動作は設計上、コントロール プレーン（BGP）がデータプレーン（LB ノードプール）から切り離されているためです。
BGP ピアリングに使用できるノードのセットを制限する場合は、ロードバランサ ノードにのみ使用される 1 つのサブネットを指定できます。つまり、そのサブネット内のすべてのノードをロードバランサのノードプールに構成できます。次に、BGP ピアリングに使用するフローティング IP アドレスを構成する場合は、同じサブネットからのアドレスであることを確認してください。Google Distributed Cloud は、フローティング IP アドレスの割り当てと BGP ピアリングがロードバランサ ノードからのみ行われるようにします。
デュアルスタック ネットワークを使用して BGP ロード バランシングを設定する
Google Distributed Cloud リリース 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 アドレスは、同じサブネット内のノードに割り当てることができます。
次のクラスタ構成サンプルに示すように、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 アドレスは、同じサブネット内のノードに割り当てることができます。
以下のクラスタ構成例では、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 アドレスは、同じサブネット内のノードに割り当てることができます。
以下のクラスタ構成例では、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 つのピアを更新して、考えられる問題を切り分けできるようにします。
- 単一のピアを追加または更新します。
- 構成の整合性がとられる間待ちます。
- クラスタが新しいピアや更新されたピアに接続できることを確認します。
- 古いピアや不要なピアを削除します。
サービス
アドレスプールとロードバランサ ノード設定を更新するには、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 プログラムを取得して、テストするコントロール プレーン ノードにコピーします。
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.13REGISTRY_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_VIPCONTROL_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の Google Distributed Cloud 構成に入力した IP アドレスを持つインターフェースです。
別のノードから VIP に ping します。
ping CONTROL_PLANE_VIPping が失敗する場合は、ネットワーク デバイスの BGP 構成に問題がある可能性があります。ネットワーク管理者と協力して、構成を確認し、問題を解決してください。
クリーンアップ
BGP が機能していることを手動で確認してから、次の手順に沿ってノードをリセットしてください。ノードが正しくリセットされない場合は、手動セットアップでプリフライト チェックまたは後続のクラスタ作成に支障をきたす可能性があります。
トラフィック テスト用に VIP を追加した場合は、コントロール プレーン ノードから VIP を削除します。
ip addr del CONTROL_PLANE_VIP/32 dev INTF_NAMEコントロール プレーン ノードの
bgpadvertiserターミナルでCtrl+Cを押して bgpadvertiser を停止します。bgpadvertiserプロセスが実行されていないことを確認します。ps -ef | grep bgpadvertiser動作中のプロセスが表示される場合は、
killコマンドを使用してプロセスを停止します。