第6章 BGP ルーティング
6.1. BGP ルーティングについて リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform で BGP を MetalLB および FRR-K8s と統合するには、FRR-K8s リソースがクラスタールーティングをどのようにモデル化しているかを確認します。MetalLB Operator の外部で管理者または第三者が FRRConfiguration カスタムリソースを作成した場合、それを metallb-system から openshift-frr-k8s に移行します。
MetalLB Operator を使用しており、クラスター管理者、または MetalLB Operator 以外のサードパーティークラスターコンポーネントによって作成された metallb-system namespace に既存の FRRConfiguration CR がある場合は、それらが openshift-frr-k8s namespace にコピーされているか、そのサードパーティークラスターコンポーネントが新しい namespace を使用していることを確認する必要があります。詳細は、「FRR-K8s リソースの移行」を参照してください。
6.1.1. Border Gateway Protocol (BGP) ルーティングについて リンクのコピーリンクがクリップボードにコピーされました!
クラスターの外部ルーティングを有効にするには、FRRouting (FRR) と FRR-K8s デーモンを使用して BGP(Border Gateway Protocol) を設定します。
FRRConfiguration カスタムリソース (CR) を使用してルーティング動作を定義し、必要な namespace と移行方法を使用することで、MetalLBOperator との互換性を確保できます。
OpenShift Container Platform は、FRR を通じて BGP ルーティングをサポートします。FRR は、Linux、UNIX、および同様のオペレーティングシステム向けの無料のオープンソースインターネットルーティングプロトコルスイートです。FRR-K8s は、Kubernetes に準拠した方法で FRR API のサブセットを公開する Kubernetes ベースのデーモンセットです。クラスター管理者として、FRRConfiguration カスタムリソースを使用して FRR サービスにアクセスできます。
次の図は、1 つの OpenShift Container Platform ノード上に 2 つの namespace が存在するマルチテナント環境を示しています。OVN-Kubernetes ゲートウェイルーターが namespace から外部ソースへトラフィックを送信する場合、トラフィックはデフォルトの Virtual Routing and Forwarding (VRF) インスタンスを経由します。BGP アドバタイズメントは、FRR または OVN-Kubernetes ルーターがクラウドプロバイダーのルーターとの間で BGP セッションを確立したときに発生します。このセッションにより、クラウドプロバイダーのルーターは、そのノードが Pod またはサービスネットワークに到達するためのネクストホップ IP アドレスであることを認識します。
図6.1 VPN なしの BGP アドバタイズメント
以下の図は、VRF lite を使用する複数の VRF BGP インスタンスを示しています。このアーキテクチャーは、ローカルゲートウェイモードのみをサポートしています。VRF lite は、Multi-Protocol Label Switching (MPLS) や Ethernet Virtual Private Network (EVPN) プロトコルに特有の\重いカプセル化を伴うことなく、UDN を使用して Pod トラフィックを分離することでネットワーク仮想化を実現します。個別の L3 リンクは特定の VRF にマッピングされるため、独立した BGP ピアリングセッションによってトラフィックがネクストホップルーターにルーティングされます。さらに、この L3 メカニズムをマルチクラウドデプロイメントにデプロイすることで、ネットワーク上における特定の namespace の存在が可能になります。
図6.2 VRF lite を使用する複数の VRF BGP インスタンス
6.1.1.1. サポート対象プラットフォーム リンクのコピーリンクがクリップボードにコピーされました!
BGP ルーティングは、次のインフラストラクチャータイプでサポートされています。
- ベアメタル
BGP ルーティングでは、ネットワークプロバイダーに対して BGP が適切に設定されている必要があります。ネットワークプロバイダーの停止や設定ミスにより、クラスターネットワークが中断される可能性があります。
6.1.1.2. MetalLB Operator の使用に関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
MetalLB Operator は、クラスターへのアドオンとしてインストールされます。MetalLB Operator をデプロイすると、FRR-K8s が追加のルーティング機能プロバイダーとして自動的に有効になり、この機能によってインストールされた FRR-K8s デーモンが使用されます。
4.18 にアップグレードする前に、MetalLB Operator によって管理されていない metallb-system namespace 内の既存の FRRConfiguration (クラスター管理者またはその他のコンポーネントにより追加) を、openshift-frr-k8s namespace に手動でコピーし、必要に応じて namespace を作成する必要があります。
MetalLB Operator を使用しており、クラスター管理者、または MetalLB Operator 以外のサードパーティークラスターコンポーネントによって作成された既存の FRRConfiguration CR が metallb-system namespace に存在する場合は、次の操作を行う必要があります。
-
既存の
FRRConfigurationCR がopenshift-frr-k8snamespace にコピーされていることを確認します。 -
サードパーティークラスターコンポーネントが、作成する
FRRConfigurationCR に新しい namespace を使用することを確認します。
6.1.1.3. Cluster Network Operator の設定 リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Operator API は、BGP ルーティングを設定するために次の API フィールドを公開します。
-
spec.additionalRoutingCapabilities: ルートアドバタイズメントとは独立して使用できるクラスターの FRR-K8s デーモンのデプロイメントを有効にします。有効にすると、FRR-K8s デーモンがすべてのノードにデプロイされます。
6.1.1.4. BGP ルーティングカスタムリソース リンクのコピーリンクがクリップボードにコピーされました!
BGP ルーティングの設定には、次のカスタムリソースが使用されます。
FRRConfiguration- このカスタムリソースは、BGP ルーティングの FRR 設定を定義します。この CR には namespace があります。
6.1.2. FRRConfiguration CR の設定 リンクのコピーリンクがクリップボードにコピーされました!
MetalLB の標準機能を超えてルーティング動作をカスタマイズするには、FRRConfiguration カスタムリソース (CR) を設定します。
以下の参考例は、受信ルートなどの高度なサービスを有効にするために、特定の FRRouting (FRR) パラメーターを定義する方法を示しています。
routersパラメーターroutersパラメーターを使用して、Virtual Routing and Forwarding (VRF) リソースごとに 1 つずつ、複数のルーターを設定できます。各ルーターに AS 番号 (ASN) を定義する必要があります。次の例のように、接続する Border Gateway Protocol (BGP) の隣接機器のリストを定義することもできます。
FRRConfiguration CR の例
apiVersion: frrk8s.metallb.io/v1beta1 kind: FRRConfiguration metadata: name: test namespace: frr-k8s-system spec: bgp: routers: - asn: 64512 neighbors: - address: 172.30.0.3 asn: 4200000000 ebgpMultiHop: true port: 180 - address: 172.18.0.6 asn: 4200000000 port: 179 # ...toAdvertiseパラメーターデフォルトでは、
FRR-K8sはルーター設定の一部として設定されたプレフィックスをアドバタイズしません。プレフィックスをアドバタイズするには、toAdvertiseパラメーターを使用します。次の例のように、プレフィックスのサブセットをアドバタイズできます。
FRRConfiguration CR の例
apiVersion: frrk8s.metallb.io/v1beta1 kind: FRRConfiguration metadata: name: test namespace: frr-k8s-system spec: bgp: routers: - asn: 64512 neighbors: - address: 172.30.0.3 asn: 4200000000 ebgpMultiHop: true port: 180 toAdvertise: allowed: prefixes: - 192.168.2.0/24 prefixes: - 192.168.2.0/24 - 192.169.2.0/24 # ...-
allowed.prefixes: プレフィックスのサブセットをアドバタイズします。
次の例は、すべてのプレフィックスをアドバタイズする方法を示しています。
FRRConfiguration CR の例
apiVersion: frrk8s.metallb.io/v1beta1 kind: FRRConfiguration metadata: name: test namespace: frr-k8s-system spec: bgp: routers: - asn: 64512 neighbors: - address: 172.30.0.3 asn: 4200000000 ebgpMultiHop: true port: 180 toAdvertise: allowed: mode: all prefixes: - 192.168.2.0/24 - 192.169.2.0/24 # ...-
allowed.mode: すべてのプレフィックスをアドバタイズします。
-
toReceiveパラメーターデフォルトでは、
FRR-K8sは隣接機器によってアドバタイズされたプレフィックスを処理しません。このようなアドレスを処理するには、toReceiveパラメーターを使用できます。次の例のように、プレフィックスのサブセットを設定できます。
FRRConfiguration CR の例
apiVersion: frrk8s.metallb.io/v1beta1 kind: FRRConfiguration metadata: name: test namespace: frr-k8s-system spec: bgp: routers: - asn: 64512 neighbors: - address: 172.18.0.5 asn: 64512 port: 179 toReceive: allowed: prefixes: - prefix: 192.168.1.0/24 - prefix: 192.169.2.0/24 ge: 25 le: 28 # ...-
prefixes: プレフィックスの長さがleプレフィックスの長さ以下で、geプレフィックスの長さ以上の場合、プレフィックスが適用されます。
次の例では、アナウンスされたすべてのプレフィックスを処理するように FRR を設定します。
FRRConfiguration CR の例
apiVersion: frrk8s.metallb.io/v1beta1 kind: FRRConfiguration metadata: name: test namespace: frr-k8s-system spec: bgp: routers: - asn: 64512 neighbors: - address: 172.18.0.5 asn: 64512 port: 179 toReceive: allowed: mode: all # ...-
bgpパラメーターbgpパラメーターを使用すると、さまざまなBFDプロファイルを定義し、それらを隣接機器に関連付けることができます。次の例では、BFDは、BGPセッションをバックアップし、FRRはリンク障害を検出できます。FRRConfiguration CR の例
apiVersion: frrk8s.metallb.io/v1beta1 kind: FRRConfiguration metadata: name: test namespace: frr-k8s-system spec: bgp: routers: - asn: 64512 neighbors: - address: 172.30.0.3 asn: 64512 port: 180 bfdProfile: defaultprofile bfdProfiles: - name: defaultprofile # ...nodeSelectorパラメーターデフォルトでは、
FRR-K8sは、デーモンが実行されているすべてのノードに設定を適用します。nodeSelectorパラメーターを使用すると、設定を適用するノードを指定できます。以下に例を示します。FRRConfiguration CR の例
apiVersion: frrk8s.metallb.io/v1beta1 kind: FRRConfiguration metadata: name: test namespace: frr-k8s-system spec: bgp: routers: - asn: 64512 nodeSelector: labelSelector: foo: "bar" # ...interfaceパラメーターinterfaceパラメーターを使用すると、以下の設定例のように、番号なし BGP ピアリングを設定できます。FRRConfigurationCR の例apiVersion: frrk8s.metallb.io/v1beta1 kind: FRRConfiguration metadata: name: test namespace: frr-k8s-system spec: bgp: bfdProfiles: - echoMode: false name: simple passiveMode: false routers: - asn: 64512 neighbors: - asn: 64512 bfdProfile: simple disableMP: false interface: net10 port: 179 toAdvertise: allowed: mode: filtered prefixes: - 5.5.5.5/32 toReceive: allowed: mode: filtered prefixes: - 5.5.5.5/32 # ...-
neighbors.interface: 番号なしの BGP ピアリングを有効にします。
注記interfaceパラメーターを使用するには、2 つの BGP ピア間でポイントツーポイントのレイヤー 2 接続を確立する必要があります。番号なし BGP ピアリングは、IPv4、IPv6、またはデュアルスタックで使用できますが、IPv6 RA (ルーターアドバタイズメント) を有効にする必要があります。各インターフェイスは 1 つの BGP 接続に制限されます。このパラメーターを使用する場合は、
spec.bgp.routers.neighbors.addressパラメーターに値を指定できません。-
FRRConfiguration カスタムリソースのパラメーターは、次の表に記載されています。
| パラメーター | 型 | 説明 |
|---|---|---|
|
|
| FRR が設定するルーターを指定します (VRF ごとに 1 つ)。 |
|
|
| セッションのローカル側で使用する AS 番号 (ASN)。 |
|
|
|
|
|
|
| このルーターからセッションを確立するために使用するホスト VRF を指定します。 |
|
|
| BGP セッションを確立する隣接機器を指定します。 |
|
|
|
セッションのリモート終了に使用する ASN を指定します。このパラメーターを使用する場合は、 |
|
|
|
明示的に設定せずに、セッションのリモートエンドに使用する ASN を検出します。同じ ASN を持つネイバーの場合は |
|
|
|
セッションを確立する IP アドレスを指定します。このパラメーターを使用する場合は、 |
|
|
| セッションを確立するときに使用するインターフェイス名を指定します。このパラメーターを使用して、番号なし BGP ピアリングを設定します。2 つの BGP ピア間には、ポイントツーポイントのレイヤー 2 接続が必要です。番号なし BGP ピアリングは、IPv4、IPv6、またはデュアルスタックで使用できますが、IPv6 RA (ルーターアドバタイズメント) を有効にする必要があります。各インターフェイスは 1 つの BGP 接続に制限されます。 |
|
|
|
セッションを確立するときにダイアリングするポートを指定します。デフォルト値は |
|
|
|
BGP セッションの確立に使用するパスワードを指定します。 |
|
|
|
ネイバーの認証シークレットの名前を指定します。シークレットは "kubernetes.io/basic-auth" タイプであり、FRR-K8s デーモンと同じ namespace にある必要があります。キー "password" はパスワードをシークレットに保存します。 |
|
|
| RFC4271 に従って、要求された BGP ホールド時間を指定します。デフォルトは 180s です。 |
|
|
|
RFC4271 に従って、要求された BGP キープアライブ時間を指定します。デフォルトは |
|
|
| BGP が隣接機器に次に接続を試行するまで待機する時間を指定します。 |
|
|
| BGPPeer が複数ホップ離れているかどうかを示します。 |
|
|
| BGP セッションに関連付けられた BFD セッションに使用する BFD プロファイルの名前を指定します。設定されていない場合、BFD セッションは設定されません。 |
|
|
| 隣接機器にアドバタイズするプレフィックスのリストと、関連するプロパティーを表します。 |
|
|
| 隣接機器にアドバタイズするプレフィックスのリストを指定します。このリストは、ルーターで定義したプレフィックスと一致する必要があります。 |
|
|
|
プレフィックスを処理するときに使用するモードを指定します。プレフィックスリスト内のプレフィックスのみを許可するように |
|
|
| アドバタイズされたローカルプリファレンスに関連付けられたプレフィックスを指定します。ローカル設定に関連付けられたプレフィックスを、アドバタイズが許可されるプレフィックスに指定する必要があります。 |
|
|
| ローカル設定に関連付けられたプレフィックスを指定します。 |
|
|
| プレフィックスに関連付けられたローカル設定を指定します。 |
|
|
| アドバタイズされた BGP コミュニティーに関連付けられたプレフィックスを指定します。アドバタイズするプレフィックスのリストに、ローカル設定に関連付けられたプレフィックスを含める必要があります。 |
|
|
| コミュニティーに関連付けられたプレフィックスを指定します。 |
|
|
| プレフィックスに関連付けられたコミュニティーを指定します。 |
|
|
| 隣接機器から受信するプレフィックスを指定します。 |
|
|
| 隣接機器から受信する情報を指定します。 |
|
|
| 隣接機器から許可されるプレフィックスを指定します。 |
|
|
|
プレフィックスを処理するときに使用するモードを指定します。 |
|
|
| MP BGP を無効にして、IPv4 と IPv6 のルート交換を別々の BGP セッションに分離しないようにします。 |
|
|
| このルーターインスタンスからアドバタイズするすべてのプレフィックスを指定します。 |
|
|
| 隣接機器を設定するときに使用する BFD プロファイルのリストを指定します。 |
|
|
| 設定の他の部分で参照される BFD プロファイルの名前。 |
|
|
|
このシステムが制御パケットを受信できる最小間隔をミリ秒単位で指定します。デフォルトは |
|
|
|
このシステムが BFD 制御パケットを送信するために使用する、ジッターを除いた最小送信間隔をミリ秒単位で指定します。デフォルトは |
|
|
| パケット損失を判定するための検出乗数を設定します。接続損失検出タイマーを決定するには、リモート送信間隔にこの値を乗算します。 |
|
|
|
このシステムが処理できる最小のエコー受信送信間隔をミリ秒単位で設定します。デフォルトは |
|
|
| エコー送信モードを有効または無効にします。このモードはデフォルトで無効になっており、マルチホップ設定ではサポートされていません。 |
|
|
| セッションを passive としてマークします。passive セッションでは接続を開始せず、応答を開始する前にピアからの制御パケットを待機します。 |
|
|
| マルチホップセッションのみ。着信 BFD 制御パケットの最小予想 TTL を設定します。 |
|
|
| この設定の適用を試みるノードを制限します。指定した場合、指定されたセレクターに一致するラベルが割り当てられたノードのみが設定の適用を試みます。指定されていない場合は、すべてのノードがこの設定を適用しようとします。 |
|
|
| FRRConfiguration の監視状態を定義します。 |
6.1.3. Border Gateway Protocol (BGP) を使用したレイヤー 3 ネットワークにおける no-overlay モードについて リンクのコピーリンクがクリップボードにコピーされました!
no-overlay モードを使用すると、BGP を介してレイヤー 3 の Pod トラフィックをアンダーレイネットワーク上へ直接ルーティングできます。これによりカプセル化のオーバーヘッドが削減され、east-west パフォーマンスが向上します。
no-overlay モードでは、デフォルトのクラスターネットワークのデフォルトのカプセル化が無効になり、BGP で学習したルートを使用して Pod トラフィックをノード間で転送します。単一のクラスターで、overlay および no-overlay ネットワークを同時に実行できます。
デフォルトのクラスターネットワークでは、no-overlay はマネージドルーティングおよびアンマネージドルーティングの両方をサポートします。マネージドルーティングを使用すると、OVN-Kubernetes はクラスターノード間のみでフルメッシュ BGP ファブリックを作成します。これにより、外部 BGP ルーターは不要となり、Pod のルートはクラスター外にはアドバタイズされません (クラスター内トラフィック限定)。マネージドルーティングでは、ノードがレイヤー 2 で直接接続されている必要があります。そのため、異なるサブネットにノードを持つクラスターには適していません。デフォルトネットワークでアンマネージドルーティングを使用する場合、外部 BGP ピアを設定し、RouteAdvertisements カスタムリソース (CR) を使用して、Pod サブネットを既存の BGP インフラストラクチャーにアドバタイズします。
ClusterUserDefinedNetwork CR によって定義されたプライマリーネットワークの場合、no-overlay はアンマネージドのルーティングのみをサポートします。CUDN の外部 BGP ピアと RouteAdvertisements CR を設定します。
- 要件
- OVN-Kubernetes ネットワークプラグインを使用するベアメタルクラスター。
- クラスターに対して、シングルノードゾーン相互接続モードが有効化されている。
- BGP ルーティングが有効化され、FRR-K8s がデプロイされている。
-
レイヤー 3 ネットワークのみ (
ClusterUserDefinedNetworkCR で定義されたデフォルトネットワークまたはプライマリーネットワーク)。
- 制限事項
- レイヤー 2 ネットワークでは、no-overlay モードはサポートされていません。
- no-overlay ネットワークでは、EgressIP、EgressService、IPsec、マルチキャスト、および複数の外部ゲートウェイはサポートされていません。
-
ClusterUserDefinedNetworkCR を使用する場合、既存のネットワークを overlay および no-overlay モード間で切り替えることはサポートされていません。
- サポート対象のゲートウェイモード
- デフォルトのクラスターネットワークでは、ローカルゲートウェイ (LGW) モードと共有ゲートウェイ (SGW) モードの両方で、no-overlay がサポートされています。
ClusterUserDefinedNetworkCR によって定義されたプライマリーネットワークでは、LGW モードと SGW モードの両方で no-overlay がサポートされています。重要NoOverlayトランスポートモードで設定された CUDN 上で実行されている Pod は、externalTrafficPolicyがClusterに設定され、バックエンド Pod がリクエストの対象ノードとは異なるノードに存在する場合、NodePortサービスへの TCP 接続を確立できません。この問題は、送信 SNAT が有効か無効かに関わらず発生します。