こんにちは！クラウドの裏側でパケットの旅路を見守るSREの皆さん、そしてこれからインフラの世界へ一歩を踏み出そうとしている未来のエンジニアの皆さん。日々のインフラ運用、本当にお疲れ様です！
Kubernetes（K8s）を使ってアプリを動かし始めると、必ずと言っていいほどぶ wall（壁）にぶつかるのが「ネットワーク」の仕組みです。「Podってなんだかたくさん作れるけれど、あっちのノードにいるPodと、こっちのノードにいるPodはどうやってお互いを見つけて会話しているんだろう？」と、疑問に思ったことはありませんか？
今回は、その謎を解き明かすカギであり、クラウドネイティブな世界でキビキビとパケットを直撃ルートで運んでくれる「BGP（Border Gateway Protocol）」と、K8sのネットワークプラグイン（Calicoなど）がタッグを組んだ「ネイティブL3ルーティング」の世界へ、あなたを優しくご案内します。
難しい専門用語やパケットの細かい構造は、私たちの身近な「郵便配達」に例えながら一歩ずつ紐解いていきますので、肩の力を抜いてリラックスして読み進めてくださいね！
—
1. なぜオーバーレイは少し「もどかしい」のか？ 〜手紙の二重封筒問題〜
Kubernetesのデフォルトのネットワーク（FlannelのVXLANなど）では、よく「オーバーレイネットワーク」という技術が使われます。
これって、身近な例で例えると「手紙を書いて、一度大きなダンボール箱（外側のカプセル）に入れ、宛先を書き換えて別の郵便局員に渡し、宛先の手前でまたダンボール箱を開封する」ようなものです。
- メリット: どんなインフラ環境（AWSでもGCPでもオアハウスのオンプレでも）であっても、既存のネットワーク設定をいじらずに安全にPod同士を通信させられる。
- デメリット（もどかしさ）: ダンボールに入れたり出したりする手間に「CPUパワー」と「パケットのサイズ（オーバーヘッド）」を少しずつ奪われてしまう。巨大なデータをガンガンやり取りする大規模システムでは、この「ひと手間」が地味なパフォーマンスの劣化（レイテンシの増加）につながるんです。
「もっとこう…、最初から宛先をハッキリ書いて、郵便局のダイレクトルートを最速で駆け抜けられたらいいのに！」
それを叶えてくれるのが、今回主役の「BGP」を使ったネイティブL3ルーティングなんです。
—
2. BGP（Border Gateway Protocol）ってなに？ 〜街の郵便局長さんたちの連絡網〜
BGPと聞くと、「なんだかインターネットのバックボーンを支える、超絶に難しそうなルーターのプロトコルでしょ？」身構えてしまいますよね。もちろん間違いではないのですが、本質はとてもシンプルです。
BGPの本質はズバリ、「お互いのネットワークの郵便局長さん同士が、『うちの町には、こういう宛先（IPアドレス）の住人が住んでいるよ！』と教え合うための連絡網」です。
BGPのルール：ポート179番での「お隣さん（ピア）挨拶」
BGPが動くとき、ルーター同士（あるいはKubernetesのノード同士）は、TCPのポート179番を使って専用のコネクションを張ります。これをネットワークの世界では「BGPピア（Peer）を組む」と呼びます。
毎日、朝礼のようにこう会話しています。
- Aルーター：「おーい、隣のBさん！ 私の管理下にある
192.168.10.0/24という町へ行きたいなら、私宛に荷物を投げてくれよな！」 - Bルーター：「了解！ メモしたよ。じゃあこっちは
192.168.20.0/24の町へのルートを持っているからね」
この信頼関係（ピアリング）が結ばれると、パケットは余計なダンボール（オーバーレイ）に包まれることなく、最初から正しい宛先に向かって最短ルート（ネイティブL3）を駆け抜けていくことができるのです。
—
3. Kubernetes（Calico等）とBGPが出会うとどうなる？
Kubernetesの代表的なCNI（Container Network Interface）プラグインであるCalicoなどは、このBGPの仕組みをノード間に持ち込むことができます。
ここで、K8sクラスターの中をのぞいてみましょう。
1. Podが誕生する: Node-Aの上に、新しいPodが生まれ、192.168.166.64/32 という専用のIPアドレスが割り当てられます。
2. CalicoがBGPで叫ぶ: Node-Aで動いているCalicoの仕組み（BirdというBGPデーモン）が、すぐさまネットワーク内の他のノード（Node-Bや、物理ルーター）に向けて、「おーい！ Node-Aのところに、新しく 192.168.166.64 っていうPodが引っ越してきたぞー！ この子宛ての荷物は全部Node-Aに送ってくれ！」とBGPでルート情報を配ります。
3. 最速でパケットが届く: Node-BのPodからそのIP宛てに通信が発生したとき、Node-Bは「あ、あの宛先はNode-Aに直結のルートだ！」と知っているので、余計なカプセル化なしで、そのままパケットをダイレクトに飛ばします。
最高にスマートで、無駄のない動きですよね！
—
4. 実践！CalicoでBGPピアリングを設定してみよう
「理屈はわかったけれど、実際の現場ではどう設定するの？」という方のために、CalicoでKubernetesノード同士（あるいは上流の物理ルーター）をBGPで結ぶ際の設定の雰囲気を覗いてみましょう。
Calicoでは、BGPPeer というカスタムリソースを使って、誰と誰がBGPの挨拶を交わすかを定義します。
設定例：全ノード間でBGPピアリングを自動化する（グローバル設定）
Kubernetesクラスター内のすべてのノードが、お互いにBGPで「ルート情報」を教え合う、一番シンプルで強力な構成（Full Mesh）のYAML例です。
apiVersion: projectcalico.org/v3
kind: BGPConfiguration
metadata:
name: default
spec:
# クラスター全体のAS番号（自律システム番号：郵便局のグループIDのようなもの）を指定します
asNumber: 64512
---
apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
name: cluster-wide-peer
spec:
# メッシュ（全ノードが相互に接続する）を有効にする設定です
nodeToNodeMeshEnabled: true
# 日本語コメント：これにより、追加の設定なしでK8sの各ノードが自動的にポート179番でBGP接続を確立します上流の物理ルーター（ToRスイッチ）とBGPを喋る場合
オンプレミスのデータセンターなどで、Kubernetesノードのすぐ上にある物理ルーター（Top of Rackスイッチ）にPodのルートを直接教えたい場合は、以下のように個別のピアを指定します。
apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
name: upstream-router-switch
spec:
# 上流の物理ルーターのIPアドレスを指定
peerIP: 10.0.0.1
# 上流ルーターが持っているAS番号
peerAS: 65000
# 自ノードのAS番号
asNumber: 64512
# 日本語コメント：これでKubernetesのノードが物理ルーターとBGP(179番)で直結され、
# 物理ネットワーク全体にPodのIPアドレスがダイレクトに広告されます！—
5. 現場のSREが教える！BGPトラブルシューティングの勘所
「設定ファイルを書いたのに、なぜかPod同士が通信できない……！」
そんな現場の修羅場で、ベテランSREたちが真っ先に確認するポイントをこっそりシェアします。
1. TCP 179番ポートが塞がれていないか？
- クラウドのセキュリティグループや、ホストOSのファイアウォール（
iptablesやfirewalld）で、ポート179番がブロックされているケースが非常に多いです。「挨拶の電話がつながらない状態」なので、まずはここを疑います。
2. AS番号（Autonomous System Number）が一致しているか？
- 設定ミスで、自分側のAS番号と相手が期待しているAS番号が食い違っていると、ルーター同士が「お前とは話す内容が違う」とそっぽを向いてしまいます。
3. パケットの最大サイズ（MTU）問題
- ネイティブL3ルーティングはオーバーレイを使わないためMTUの制限が緩くなりますが、物理ネットワーク側のジャンボフレーム設定などと噛み合わないと、たまに大きなパケットが途中でドロップすることがあります。
pingコマンドでサイズを指定して確認してみましょう。
—
まとめ：パケットの旅路をデザインしよう
いかがでしたでしょうか？
BGPによるKubernetes Podルート配布は、一見すると難解なネットワークの呪文のように見えますが、その本質は「お隣同士のルーターが、住人の住所録をスマートに交換し合い、最短ルートで郵便物を届けるための素晴らしい仕組み」です。
オーバーレイの呪縛から解放され、ネイティブなL3ルーティングでパケットが風のようにノード間を駆け抜けていく快感は、クラウドインフラを触るエンジニアにとって格別のものです。
まずは小さな検証環境から、CalicoとBGPの世界に飛び込んでみてください。あなたのKubernetesクラスターが、より軽快に、より美しく動き出すこと間違いなしです。
それでは、次回のインフラ探訪でお会いしましょう！ Happy Cloudeering!
コメント