オーバーレイの限界を超えろ：BGPで実現する「裸の」Kubernetesネットワーク
こんにちは。現場のSREの視点から、クラウドネイティブの深淵を語る時間です。
皆さんが普段触れているKubernetes。kubectl get pods -o wide で表示されるPodのIPアドレス、あれが「仮想的なもの」だと思って思考停止していませんか？ VXLANやGeneveといったオーバーレイプロトコルでパケットをカプセル化し、ヘッダを二重三重に被せることで生じる「オーバーヘッド」と「MTU問題」。高トラフィックなAPIを運用していると、この微細なパケット処理の積み重ねが、いずれ無視できないレイテンシとして返ってきます。
今日は、そんなオーバーレイの呪縛を解き放ち、物理ネットワークとPodネットワークを直結させる「BGP（Border Gateway Protocol）」によるルーティングの奥義を解説します。
—
なぜ今、BGPなのか？
クラウドインフラにおいて、PodネットワークをネイティブL3で扱うメリットは明確です。「カプセル化をしない」ことによるパフォーマンス向上、そしてネットワークトラブル時の「追いかけやすさ」です。
CalicoのようなCNIをBGPモードで運用すると、Kubernetesノードは一つの「ルーター」として振る舞います。各ノードがBGPのピア（隣接ルーター）となり、「このPodのIPレンジは俺の担当だ」と周囲に広報（Advertisement）する。これにより、物理スイッチやクラウドの仮想ルーターがPodへの経路を学習し、パケットはカプセル化なしで目的地まで直行できるようになります。
—
現場で刺さる「ポート179番」のリアル
BGPのセッション確立にはTCPの 179 番ポートを使用します。ここが塞がっていると、どんなに設定を完璧にしてもBGPピアリングは成立しません。
トラブルシューティングの現場では、まずここを疑います。クラウドのセキュリティグループや、ノード間の iptables が 179 をブロックしていないか。以下のコマンドで、パケットが届いているか確認するのは基本中の基本です。
# ノード間でBGPのTCPセッションが確立されているか確認
# 確立されていれば ESTABLISHED になるはずだ
ss -antp | grep 179もし SYN_SENT で止まっているなら、それはネットワークパスのどこかで 179 が遮断されているサインです。クラウドのネットワークACL設定を再確認してください。
—
Calico BGP設定の現場的アプローチ
CalicoでBGPを有効化する際、よく使う BGPConfiguration の設定例を紹介します。
apiVersion: projectcalico.org/v3
kind: BGPConfiguration
metadata:
name: default
spec:
# ノード間でのフルメッシュ構成を無効化（大規模環境では必須）
nodeToNodeMeshEnabled: false
# BGPのAS番号を指定（クラウドプロバイダーの制約に合わせる）
asNumber: 64512大規模環境では nodeToNodeMeshEnabled: false にするのが鉄則です。全ノードが全ノードとピアを組むと、ノード数が増えた瞬間にセッション数が爆発し、CPU負荷が跳ね上がります。代わりに「Route Reflector」を立てて経路を集中管理するのが、シニアなエンジニアの作法です。
—
パケットを追跡する：デバッグの視点
BGPが正しく動いているか、経路情報を確認するには calicoctl を使い倒します。
# ノードが学習している経路を確認
calicoctl node status
# どのルートが広報されているか確認
calicoctl get bgppeer -o wideもし、特定のAPIサーバーからPodへ疎通できない場合、traceroute を実行してみてください。オーバーレイを使っている場合、ホップ数は論理的なものになりますが、BGPでネイティブルーティングしていれば、パケットは物理的なホップを刻みます。
# Podから外部APIへ疎通確認（Pythonで擬似的に検証）
python3 -c "import socket; print(socket.create_connection(('10.0.0.5', 80), timeout=5))"このとき、経路上でパケットがドロップしていれば、それはルーティングテーブルのどこかに「ブラックホール」がある証拠です。
—
SREからの最後のアドバイス
BGPによるPodルーティングは強力ですが、諸刃の剣でもあります。間違ったルートを広報すると、一瞬でクラスタ全体の通信を遮断（Blackhole）するリスクがあります。
1. ピアの認証: password 設定で必ず認証をかけること。
2. フィルタリング: 広報する経路は ExportPolicy で厳密に絞り込むこと。
3. 監視: BGPセッションのステータスをPrometheusでメトリクス化し、セッション断を即座に検知すること。
ネットワークは「魔法」ではなく「物理とロジックの積み重ね」です。オーバーレイの便利さに甘えず、時としてこうして「裸のネットワーク」と向き合うことで、皆さんのインフラは一段上の堅牢性を手に入れるはずです。
次回の運用で、もし 179 ポートに悩まされたら、この記事を思い出してください。現場からは以上です。
コメント