【CNDW2025】containerlab×kindでひもとくBGP＋Kubernetes検証環境の作り方とサイボウズでの実践

CloudNative Days Winter 2025で行われたセッション「作って、試して、壊せる！containerlab×kindで再現するBGP+Kubernetes環境」では、サイボウズの花田 浩紀氏が、BGPネットワークとKubernetesクラスタを統合したローカル検証環境の構築手法を解説した。BGPを活用したKubernetesネットワークが注目を集める一方、その検証方法は十分に共有されてこなかった。containerlabとkindを用いた具体的な再現手法と、その実践例を通じて、現実的な検証アプローチの価値を紐解く。

Kubernetesネットワークの要件と
BGP活用が注目される背景

Kubernetesは、各Podにクラスター内で一意なIPアドレスを割り当て、Pod同士の直接通信を可能にすることを前提としている。またPodの入れ替わりが発生しても継続的なアクセスポイントを提供し、必要に応じてクラスター外部へサービスを公開できることも求められる。一方でこれらの要件を満たす限り、通信方式やルーティングの実装は自由であり、L2やL3、オーバーレイなど特定の方式に限定されない。

こうした柔軟性を背景に近年注目されているのが、BGPをKubernetesのネットワーク制御に活用する手法である。BGPはTCPの179番ポートでセッションを確立し、AS(Autonomous System、同一のルーティングポリシーで管理されるネットワーク単位)ごとに経路情報を交換するルーティングプロトコルであり、インターネットだけでなくデータセンターネットワークでも広く使われてきた。ベンダーに依存せず、耐障害性とスケーラビリティを両立できる点が特徴である。

花田氏はBGPについて「TCPの179番ポートでセッションを張って、経路情報を交換します」と説明した。近年では、このBGPを用いてPodやServiceが使用するIPアドレスの経路情報を上流のデータセンターネットワークと直接交換する構成が採られ始めている。これにより、オーバーレイを用いない高性能な通信や、ECMPを活用した高可用なロードバランシングが可能となる。

MetalLB、Calico、Ciliumといった主要OSSでもBGPを利用した機能が提供されているが、導入前に本番に近い構成をローカルで検証する手法は十分に共有されてこなかった。BGPは複数のネットワーク機器が関与する前提の技術であり、ローカル環境での再現は容易ではないためである。

セッションではこうした課題に対し、前半でBGPネットワークとkindクラスタを統合したローカル検証環境の構築方法を、後半でその実践例を紹介する。

containerlabとkindで実現する
BGP＋Kubernetes検証環境

こうした課題に対し、花田氏はcontainerlabを用いたアプローチを紹介した。containerlabはコンテナベースのネットワークラボ環境を宣言的に構築できるツールである。YAMLファイルでトポロジーを定義し、ワンコマンドで環境の起動と破棄が可能で、内部的にはDockerを用いてルータやスイッチ、ホストといったネットワーク要素をコンテナとして再現する。これにより、データセンターネットワークやクラスタネットワークをローカル環境上で再現できる。

花田氏はcontainerlabについて「YAMLファイルでトポロジーを定義して、ワンコマンドで環境の起動と破棄ができます」と説明した。

本セッションの特徴は、このcontainerlab上にkindクラスタを統合している点にある。containerlabではノードの種別としてk8s-kindを指定でき、kindが作成するKubernetesノードをネットワークトポロジーの一部として扱える。また、ext-containerやnetwork-mode: containerといった機能を組み合わせることで、既存のコンテナと同一のネットワーク名前空間を共有する構成も可能となる。これにより、Kubernetesノード上で動作するBGP関連コンポーネントを現実の構成に近い形で再現できる。

デモではまず、BGPを用いたL4ロードバランシングが実演された。この構成では上流スイッチと各KubernetesノードがBGPでピアリングし、各ノードからLoadBalancer ServiceのVIPを等コストで上流に広報する。上流スイッチはECMPによりトラフィックを分散し、Kubernetesクラスタ外からのアクセスを複数ノードで受け止める仕組みである。花田氏は「各ノードからサービスのVIPを等コストで広報しています」と説明し、BGPによるシンプルな負荷分散の考え方を示した。

続くデモではBGPを用いたPod間通信の再現が行われた。ここではPod CIDRの経路をBGPで広報し、クラスタ外からPodへの直接通信を可能にする構成が示された。ただし、CiliumのBGPコントロールプレーンは受信した経路をカーネルのルーティングテーブルに取り込まないという制約がある。そのため、デモでは各ノードにBIRDをサイドカー的に配置し、カーネル経由で経路を受け渡す工夫が採られている。

花田氏はこの点について「そのままでは受信した経路を使えないので、サイドカーパターンで吸収しています」と語り、実運用で直面する制約と設計上の工夫を示した。

このように、containerlabとkindを組み合わせることで、BGPネットワークとKubernetesクラスタを統合した検証環境をローカルで構築できる。環境の構築・破棄を高速に繰り返せる点は、BGPを用いたネットワーク設計やOSSの挙動を安全に検証するうえで大きな利点となる。

サイボウズNecoに見る
Cilium BGP検証とローカル再現の価値

セッションの後半では、ここまでに紹介されたローカル検証環境の活用例として、サイボウズで運用されているオンプレミスKubernetesクラスタ「Neco」が紹介された。Necoは数百ノード規模のシングルクラスタ・マルチテナント構成を採用しており、サーバーからミドルウェアまでを自社で開発・運用する基盤である。

NecoではデータセンターネットワークとKubernetesネットワークを分掌しつつ、BGPを用いて両者を連携させている。各Kubernetesノード上で動作するBIRDがToRスイッチとBGPでピアリングし、PodやServiceに関する経路情報を交換する構成である。Ciliumをはじめとするネットワークコンポーネントは、このBGP構成を前提に運用されている。

花田氏は、こうした環境においてCiliumのBGPコントロールプレーンへの移行検証を進めるにあたり、containerlabとkindを用いたローカル検証環境を構築したと説明。「本番とほぼ同じ構成をローカルで再現して、移行の検証を回しました」という言葉が示すように、検証環境を高速に構築・破棄できることが移行作業の安全性と効率を大きく高めた。

実際の検証では、MetalLBの旧コントロールプレーンと新しいBGPコントロールプレーンとの挙動差や、切り替え時に発生し得る問題点が明らかになり、一部はアップストリームへの修正提案にもつながった。これは、本番に近い構成を手元で何度も「作って、試して、壊せる」環境があったからこそ得られた成果である。

BGPとKubernetesの統合は設計や検証の難易度が高い領域である。本セッションで示されたcontainerlab×kindによるアプローチは、そのハードルを下げ、ネットワークとクラスタの振る舞いを安全に理解するための有効な手段と言えるだろう。