Pingは通る、でもPodは繋がらない — よくある「半分だけ動く」障害
Kubernetesのオーバーレイネットワークで最も厄介なのは、「完全に落ちている」障害ではない。Podへのpingは通り、DNS解決も問題なく、それなのにアプリケーションのHTTPリクエストだけが断続的にタイムアウトする——この「半分だけ動く」状態こそが、多くのインフラエンジニアを疲弊させる。
原因の多くはMTU（最大転送単位）の不一致にある。Pod のネットワークインターフェースはCNIプラグインからMTU値を継承する仕組みになっており、オーバーレイ型のカプセル化がこの値を圧迫する。ある調査では、Flannel VXLANのMTU目安は1450、Calico IPIPは1480、Calico VXLANは1450、Weaveは1376とされ、いずれも物理NICの標準値1500から数十バイト削られている（MTU troubleshooting ガイド）。ICMPやDNSのような小さいパケットはこの削減分の影響を受けずに通過するが、TCPのセッションが大きなペイロードを送ろうとした瞬間にパケットが断片化・ドロップされ、「繋がらない」ように見える。
この記事では、なぜKubernetesのオーバーレイネットワークがここまで複雑になるのか、その構造的な理由と、現場で使える切り分け手順を整理する。こうした障害の大半は「どのPodがどのノードにいて、経路がどう解決されているか」が見えていれば数分で切り分けがつく類のものでもある。実際、KuboのようなマネージドK3s環境ではネットワークトポロジの可視化を前提に設計されている。
なぜOSPFなら自動収束するのに、KubernetesのCNIは人間が調べる羽目になるのか
従来の物理ネットワークで経路情報を扱う代表的な仕組みがOSPF（Open Shortest Path First）だ。OSPFでは各ルータが自身の接続状態を**LSA（Link State Advertisement）**として周囲に配信し、すべてのルータが同一のトポロジデータベースを持つ。リンク障害などのトポロジ変化が起きると、影響を受けたルータが新しいLSAを再配信し、各ルータが並行して最短経路を再計算する。これにより「短い収束期間で最小限のトラフィックのみ」で経路が自動的に再構築される（1998年に標準化されたRFC 2328: OSPF Version 2）。
一方、Kubernetesのネットワークモデルは前提がまったく異なる。Kubernetesは「すべてのコンテナがNATなしで相互通信できる」「コンテナのIPアドレスが内外で同じである」ことをネットワークモデルの要件として定めている（Kubernetesネットワークモデルの要件解説）が、この要求を満たす実装自体は仕様に含まれておらず、**CNI（Container Network Interface）**プラグインに委ねられている。CNIはCNCFが2017年にIncubatingプロジェクトとして受け入れた標準規格で、コンテナランタイム（containerdやCRI-Oなど）が Pod をネットワークに接続する際にADD/DELといったコマンドでプラグインを呼び出す仕組みを定義しているにすぎない（CNCF: Container Network Interface (CNI)、Kubernetes公式: Network Plugins）。
つまりOSPFの世界では「ルータという固定された機器同士が経路を学習し合う」のに対し、Kubernetesの世界では「Podがスケジューリングされるたびに新しいIPが割り当てられ、その経路情報をCNIプラグインが都度反映する」という非同期な処理が発生する。ネットワーク機器自身が自律的に収束するOSPFと違い、Kubernetesのオーバーレイは「今どのノードにどのPodがいて、その経路がどう解決されているか」を人間がログとツールを使って追いかける必要がある——これが「半日かかる」の正体だ。
FlannelのVXLANとCalicoのBGP、障害の見え方はこう違う
K3sクラスタで最もよく使われるCNIはFlannelとCalicoの2つで、両者は障害の起き方も調査すべき場所もまったく違う。
Flannel VXLAN — L2オーバーレイの落とし穴
K3sはデフォルトでFlannelをVXLANバックエンドとして採用しており、パケットをカプセル化して転送する。FlannelにはVXLANのほかにも host-gw（ノードIP経由のルーティング、レイヤー2接続が全ノード間に必要）や wireguard-native（暗号化付きカプセル化）といったバックエンドが選べる（K3s公式: Basic Network Options）。注意したいのはUDPポート番号で、FlannelのVXLANはLinuxカーネルの伝統的なデフォルトであるUDPポート8472を使う一方、Calico VXLANはIANA標準のUDPポート4789を使う。両者は似て非なる実装であり、ノード間ファイアウォールで使用中のCNIに対応するポートが塞がれていないかがまず疑うべきポイントになる。障害時はまず flanneld のログと、各ノードの ip -d link show flannel.1 でMTU・カプセル化状態を確認するのが定石だ。
Calico BGP — ルーティングモードの選択が鍵
Calicoは非オーバーレイのBGPモードとオーバーレイモード（IPIP/VXLAN）の両方をサポートする点でFlannelと異なる。BGPモードでは「標準的なルーティングプロトコルであるBGPを使って経路を共有」し、物理ネットワーク側（ToRスイッチなど）とピアリングすることで、Pod IPをクラスタ外からも直接ルーティング可能にできる。一方オーバーレイモードは「ほぼすべてのネットワーク環境で動作する」代わりに、カプセル化によるCPUオーバーヘッドとMTU削減という代償を払う(Calico公式: Determine best networking)。BGPモードで障害が起きた場合は calico-node のBGPピアリング状態（calicoctl node status相当）を、オーバーレイモードの場合はFlannel同様カプセル化とMTUを疑う、というように調査の起点がまったく異なる。
この「CNIによって見るべきログとツールが違う」という事実そのものが、Kubernetesのネットワーク障害対応を属人化させる大きな要因になっている。FlannelかCalicoか、さらにBGPかオーバーレイかという選択を自前でチューニングし続けるのは、片手間でできる作業ではない。Kuboはこの2系統のCNI構成をどちらも選択可能な形で提供し、構成そのものの選定コストを引き受ける設計になっている。
現場で最初にやるべき切り分け手順
「Pingは通るのにHTTPだけ詰まる」障害に遭遇したとき、経験則から次の順序で切り分けると迷いが少ない。
kubectl describe podでイベントを確認する: スケジューリング失敗やCNI初期化エラーなど、明白な失敗はまずここに出る- CNI DaemonSetのログを見る:
calico-nodeやkube-flannelのPodログにIPプール枯渇やBGPピアリング断などの手がかりがないか確認する - Pod内のMTUを確認する:
ip link show eth0で実際のMTU値を確認し、使用しているCNI(Flannel VXLAN=1450, Calico IPIP=1480等)の推奨値とズレていないか照合する（MTU troubleshooting ガイド） tcpdumpでカプセル化パケットを確認する: ノード間のインターフェースで実際にVXLANやBGPのパケットが想定通り流れているかを目視で確認する
このほか、IPフォワーディングが無効化されていないか（sysctl net.ipv4.ip_forward）、ブリッジネットフィルタが無効になっていないか（sysctl net.bridge.bridge-nf-call-iptables）、AWSなど一部クラウドでソース/宛先チェックがオーバーレイの通信を遮断していないか、といった環境依存の落とし穴も定番のチェックポイントとして知られている（Kubernetesネットワーク障害切り分けガイド）。
いずれの手順も、OSPFのように「勝手に直る」ことはない。人間がログを追い、ツールを使い、原因を1つずつ潰していく必要がある。この地道な作業を型化しておくかどうかが、障害対応にかかる時間を1時間で終わらせるか半日かけるかの分かれ目になる。
まとめ
KubernetesのオーバーレイネットワークがOSPFのように自動収束しないのは、怠慢でも設計ミスでもない。Podという動的に生成・消滅する存在に対して、経路情報を都度反映するというCNIの宿命的な非同期性がそこにある。FlannelのVXLANかCalicoのBGPかという選択自体が、障害時にどこを調べるべきかを大きく左右することも押さえておきたい。
この「型化された切り分け作業」こそが運用コストの正体であり、チームの誰か1人にしか手順が分からない状態は、障害対応の属人化というリスクをそのまま抱え続けることになる。実際、この切り分け作業を毎回ゼロから行うコストは、K3sクラスタを自前運用する上で最も見えにくい負債の一つだ。
KuboはK3sベースのマネージドKubernetesとして、FlannelとCalicoのどちらの構成も選択可能にしながら、Captain UIでネットワークトポロジやPodの配置状況を可視化する。ルーティングテーブルやCNIのログを手探りで追いかける代わりに、経路がどう解決されているかを画面上で確認できる状態を目指した設計だ。EKS/AKSを自前でチューニングし続けるよりも、Kubo Cloudなら月額48,000円からこの運用負荷そのものを引き受けられる。
もしCNIのトラブルシューティングに毎回時間を溶かしていると感じているなら、一度お問い合わせから現状の構成を相談してみてほしい。EKSの約58%のコストで、同じPure Kubernetesの上に、運用の手間を減らす選択肢がある。