[{"data":1,"prerenderedAt":362},["ShallowReactive",2],{"blog-ja-kubernetes-cni-overlay-network-troubleshooting-ospf":3,"blog-related-ja-kubernetes-cni-overlay-network-troubleshooting-ospf":309,"blog-ja-kubernetes-cni-overlay-network-troubleshooting-ospf-alt":298},{"id":4,"title":5,"author":6,"body":7,"date":292,"description":293,"extension":294,"image":295,"locale":296,"meta":297,"navigation":298,"path":299,"seo":300,"stem":301,"tags":302,"__hash__":308},"blog\u002Fblog\u002Fja\u002Fkubernetes-cni-overlay-network-troubleshooting-ospf.md","OSPFなら1分で直る障害が、KubernetesのCNIだと半日かかる理由","Kubo Team",{"type":8,"value":9,"toc":279},"minimark",[10,15,23,31,42,51,55,61,70,90,93,97,103,106,111,136,140,157,164,167,173,176,225,241,244,247,253,256,259,270],[11,12,14],"h2",{"id":13},"pingは通るでもpodは繋がらない-よくある半分だけ動く障害","Pingは通る、でもPodは繋がらない — よくある「半分だけ動く」障害",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-cni-overlay-network-troubleshooting-ospf\u002Fsection01.webp",[16,24,25,26,30],{},"Kubernetesのオーバーレイネットワークで最も厄介なのは、「完全に落ちている」障害ではない。Podへの",[27,28,29],"code",{},"ping","は通り、DNS解決も問題なく、それなのにアプリケーションのHTTPリクエストだけが断続的にタイムアウトする——この「半分だけ動く」状態こそが、多くのインフラエンジニアを疲弊させる。",[16,32,33,34,41],{},"原因の多くはMTU（最大転送単位）の不一致にある。Pod のネットワークインターフェースはCNIプラグインからMTU値を継承する仕組みになっており、オーバーレイ型のカプセル化がこの値を圧迫する。ある調査では、Flannel VXLANのMTU目安は1450、Calico IPIPは1480、Calico VXLANは1450、Weaveは1376とされ、いずれも物理NICの標準値1500から数十バイト削られている（",[35,36,40],"a",{"href":37,"rel":38},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-03-20-troubleshoot-mtu-kubernetes\u002Fview",[39],"nofollow","MTU troubleshooting ガイド","）。ICMPやDNSのような小さいパケットはこの削減分の影響を受けずに通過するが、TCPのセッションが大きなペイロードを送ろうとした瞬間にパケットが断片化・ドロップされ、「繋がらない」ように見える。",[16,43,44,45,50],{},"この記事では、なぜKubernetesのオーバーレイネットワークがここまで複雑になるのか、その構造的な理由と、現場で使える切り分け手順を整理する。こうした障害の大半は「どのPodがどのノードにいて、経路がどう解決されているか」が見えていれば数分で切り分けがつく類のものでもある。実際、",[35,46,49],{"href":47,"rel":48},"https:\u002F\u002Fkubo.hexabase.io\u002F",[39],"Kubo","のようなマネージドK3s環境ではネットワークトポロジの可視化を前提に設計されている。",[11,52,54],{"id":53},"なぜospfなら自動収束するのにkubernetesのcniは人間が調べる羽目になるのか","なぜOSPFなら自動収束するのに、KubernetesのCNIは人間が調べる羽目になるのか",[16,56,57],{},[19,58],{"alt":59,"src":60},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-cni-overlay-network-troubleshooting-ospf\u002Fsection02.webp",[16,62,63,64,69],{},"従来の物理ネットワークで経路情報を扱う代表的な仕組みがOSPF（Open Shortest Path First）だ。OSPFでは各ルータが自身の接続状態を**LSA（Link State Advertisement）**として周囲に配信し、すべてのルータが同一のトポロジデータベースを持つ。リンク障害などのトポロジ変化が起きると、影響を受けたルータが新しいLSAを再配信し、各ルータが並行して最短経路を再計算する。これにより「短い収束期間で最小限のトラフィックのみ」で経路が自動的に再構築される（1998年に標準化された",[35,65,68],{"href":66,"rel":67},"https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc2328.txt",[39],"RFC 2328: OSPF Version 2","）。",[16,71,72,73,78,79,84,85,69],{},"一方、Kubernetesのネットワークモデルは前提がまったく異なる。Kubernetesは「すべてのコンテナがNATなしで相互通信できる」「コンテナのIPアドレスが内外で同じである」ことをネットワークモデルの要件として定めている（",[35,74,77],{"href":75,"rel":76},"https:\u002F\u002Fwww.aquasec.com\u002Fcloud-native-academy\u002Fkubernetes-101\u002Fkubernetes-networking\u002F",[39],"Kubernetesネットワークモデルの要件解説","）が、この要求を満たす実装自体は仕様に含まれておらず、**CNI（Container Network Interface）**プラグインに委ねられている。CNIはCNCFが2017年にIncubatingプロジェクトとして受け入れた標準規格で、コンテナランタイム（containerdやCRI-Oなど）が Pod をネットワークに接続する際にADD\u002FDELといったコマンドでプラグインを呼び出す仕組みを定義しているにすぎない（",[35,80,83],{"href":81,"rel":82},"https:\u002F\u002Fwww.cncf.io\u002Fprojects\u002Fcontainer-network-interface-cni\u002F",[39],"CNCF: Container Network Interface (CNI)","、",[35,86,89],{"href":87,"rel":88},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fextend-kubernetes\u002Fcompute-storage-net\u002Fnetwork-plugins\u002F",[39],"Kubernetes公式: Network Plugins",[16,91,92],{},"つまりOSPFの世界では「ルータという固定された機器同士が経路を学習し合う」のに対し、Kubernetesの世界では「Podがスケジューリングされるたびに新しいIPが割り当てられ、その経路情報をCNIプラグインが都度反映する」という非同期な処理が発生する。ネットワーク機器自身が自律的に収束するOSPFと違い、Kubernetesのオーバーレイは「今どのノードにどのPodがいて、その経路がどう解決されているか」を人間がログとツールを使って追いかける必要がある——これが「半日かかる」の正体だ。",[11,94,96],{"id":95},"flannelのvxlanとcalicoのbgp障害の見え方はこう違う","FlannelのVXLANとCalicoのBGP、障害の見え方はこう違う",[16,98,99],{},[19,100],{"alt":101,"src":102},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-cni-overlay-network-troubleshooting-ospf\u002Fsection03.webp",[16,104,105],{},"K3sクラスタで最もよく使われるCNIはFlannelとCalicoの2つで、両者は障害の起き方も調査すべき場所もまったく違う。",[107,108,110],"h3",{"id":109},"flannel-vxlan-l2オーバーレイの落とし穴","Flannel VXLAN — L2オーバーレイの落とし穴",[16,112,113,114,117,118,121,122,127,128,131,132,135],{},"K3sはデフォルトでFlannelをVXLANバックエンドとして採用しており、パケットをカプセル化して転送する。FlannelにはVXLANのほかにも ",[27,115,116],{},"host-gw","（ノードIP経由のルーティング、レイヤー2接続が全ノード間に必要）や ",[27,119,120],{},"wireguard-native","（暗号化付きカプセル化）といったバックエンドが選べる（",[35,123,126],{"href":124,"rel":125},"https:\u002F\u002Fdocs.k3s.io\u002Fnetworking\u002Fbasic-network-options",[39],"K3s公式: Basic Network Options","）。注意したいのはUDPポート番号で、FlannelのVXLANはLinuxカーネルの伝統的なデフォルトであるUDPポート8472を使う一方、Calico VXLANはIANA標準のUDPポート4789を使う。両者は似て非なる実装であり、ノード間ファイアウォールで使用中のCNIに対応するポートが塞がれていないかがまず疑うべきポイントになる。障害時はまず ",[27,129,130],{},"flanneld"," のログと、各ノードの ",[27,133,134],{},"ip -d link show flannel.1"," でMTU・カプセル化状態を確認するのが定石だ。",[107,137,139],{"id":138},"calico-bgp-ルーティングモードの選択が鍵","Calico BGP — ルーティングモードの選択が鍵",[16,141,142,143,148,149,152,153,156],{},"Calicoは非オーバーレイのBGPモードとオーバーレイモード（IPIP\u002FVXLAN）の両方をサポートする点でFlannelと異なる。BGPモードでは「標準的なルーティングプロトコルであるBGPを使って経路を共有」し、物理ネットワーク側（ToRスイッチなど）とピアリングすることで、Pod IPをクラスタ外からも直接ルーティング可能にできる。一方オーバーレイモードは「ほぼすべてのネットワーク環境で動作する」代わりに、カプセル化によるCPUオーバーヘッドとMTU削減という代償を払う(",[35,144,147],{"href":145,"rel":146},"https:\u002F\u002Fdocs.tigera.io\u002Fcalico\u002Flatest\u002Fnetworking\u002Fdetermine-best-networking",[39],"Calico公式: Determine best networking",")。BGPモードで障害が起きた場合は ",[27,150,151],{},"calico-node"," のBGPピアリング状態（",[27,154,155],{},"calicoctl node status","相当）を、オーバーレイモードの場合はFlannel同様カプセル化とMTUを疑う、というように調査の起点がまったく異なる。",[16,158,159,160,163],{},"この「CNIによって見るべきログとツールが違う」という事実そのものが、Kubernetesのネットワーク障害対応を属人化させる大きな要因になっている。FlannelかCalicoか、さらにBGPかオーバーレイかという選択を自前でチューニングし続けるのは、片手間でできる作業ではない。",[35,161,49],{"href":47,"rel":162},[39],"はこの2系統のCNI構成をどちらも選択可能な形で提供し、構成そのものの選定コストを引き受ける設計になっている。",[11,165,166],{"id":166},"現場で最初にやるべき切り分け手順",[16,168,169],{},[19,170],{"alt":171,"src":172},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-cni-overlay-network-troubleshooting-ospf\u002Fsection04.webp",[16,174,175],{},"「Pingは通るのにHTTPだけ詰まる」障害に遭遇したとき、経験則から次の順序で切り分けると迷いが少ない。",[177,178,179,190,203,216],"ol",{},[180,181,182,189],"li",{},[183,184,185,188],"strong",{},[27,186,187],{},"kubectl describe pod"," でイベントを確認する",": スケジューリング失敗やCNI初期化エラーなど、明白な失敗はまずここに出る",[180,191,192,195,196,198,199,202],{},[183,193,194],{},"CNI DaemonSetのログを見る",": ",[27,197,151],{}," や ",[27,200,201],{},"kube-flannel"," のPodログにIPプール枯渇やBGPピアリング断などの手がかりがないか確認する",[180,204,205,195,208,211,212,215],{},[183,206,207],{},"Pod内のMTUを確認する",[27,209,210],{},"ip link show eth0"," で実際のMTU値を確認し、使用しているCNI(Flannel VXLAN=1450, Calico IPIP=1480等)の推奨値とズレていないか照合する（",[35,213,40],{"href":37,"rel":214},[39],"）",[180,217,218,224],{},[183,219,220,223],{},[27,221,222],{},"tcpdump"," でカプセル化パケットを確認する",": ノード間のインターフェースで実際にVXLANやBGPのパケットが想定通り流れているかを目視で確認する",[16,226,227,228,231,232,235,236,69],{},"このほか、IPフォワーディングが無効化されていないか（",[27,229,230],{},"sysctl net.ipv4.ip_forward","）、ブリッジネットフィルタが無効になっていないか（",[27,233,234],{},"sysctl net.bridge.bridge-nf-call-iptables","）、AWSなど一部クラウドでソース\u002F宛先チェックがオーバーレイの通信を遮断していないか、といった環境依存の落とし穴も定番のチェックポイントとして知られている（",[35,237,240],{"href":238,"rel":239},"https:\u002F\u002Fgoteleport.com\u002Fblog\u002Ftroubleshooting-kubernetes-networking\u002F",[39],"Kubernetesネットワーク障害切り分けガイド",[16,242,243],{},"いずれの手順も、OSPFのように「勝手に直る」ことはない。人間がログを追い、ツールを使い、原因を1つずつ潰していく必要がある。この地道な作業を型化しておくかどうかが、障害対応にかかる時間を1時間で終わらせるか半日かけるかの分かれ目になる。",[11,245,246],{"id":246},"まとめ",[16,248,249],{},[19,250],{"alt":251,"src":252},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-cni-overlay-network-troubleshooting-ospf\u002Fsection05.webp",[16,254,255],{},"KubernetesのオーバーレイネットワークがOSPFのように自動収束しないのは、怠慢でも設計ミスでもない。Podという動的に生成・消滅する存在に対して、経路情報を都度反映するというCNIの宿命的な非同期性がそこにある。FlannelのVXLANかCalicoのBGPかという選択自体が、障害時にどこを調べるべきかを大きく左右することも押さえておきたい。",[16,257,258],{},"この「型化された切り分け作業」こそが運用コストの正体であり、チームの誰か1人にしか手順が分からない状態は、障害対応の属人化というリスクをそのまま抱え続けることになる。実際、この切り分け作業を毎回ゼロから行うコストは、K3sクラスタを自前運用する上で最も見えにくい負債の一つだ。",[16,260,261,264,265,269],{},[35,262,49],{"href":47,"rel":263},[39],"はK3sベースのマネージドKubernetesとして、FlannelとCalicoのどちらの構成も選択可能にしながら、Captain UIでネットワークトポロジやPodの配置状況を可視化する。ルーティングテーブルやCNIのログを手探りで追いかける代わりに、経路がどう解決されているかを画面上で確認できる状態を目指した設計だ。EKS\u002FAKSを自前でチューニングし続けるよりも、",[35,266,268],{"href":47,"rel":267},[39],"Kubo Cloud","なら月額48,000円からこの運用負荷そのものを引き受けられる。",[16,271,272,273,278],{},"もしCNIのトラブルシューティングに毎回時間を溶かしていると感じているなら、一度",[35,274,277],{"href":275,"rel":276},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[39],"お問い合わせ","から現状の構成を相談してみてほしい。EKSの約58%のコストで、同じPure Kubernetesの上に、運用の手間を減らす選択肢がある。",{"title":280,"searchDepth":281,"depth":281,"links":282},"",2,[283,284,285,290,291],{"id":13,"depth":281,"text":14},{"id":53,"depth":281,"text":54},{"id":95,"depth":281,"text":96,"children":286},[287,289],{"id":109,"depth":288,"text":110},3,{"id":138,"depth":288,"text":139},{"id":166,"depth":281,"text":166},{"id":246,"depth":281,"text":246},"2026-08-16","Kubernetesのオーバーレイネットワークはなぜトラブルシューティングに時間がかかるのか。CNIの仕組み、Flannel VXLANとCalico BGPの違い、MTU不一致の切り分け手順まで、K3s運用者が押さえるべきポイントを解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-cni-overlay-network-troubleshooting-ospf\u002Feyecatch.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fkubernetes-cni-overlay-network-troubleshooting-ospf",{"title":5,"description":293},"blog\u002Fja\u002Fkubernetes-cni-overlay-network-troubleshooting-ospf",[303,304,305,306,307],"k3s","kubernetes","cni","overlay-network","networking","Fy4aoKzRkYJAu4-6ntGFz0kZ53yBO-iQhgeD5wT1eT4",[310,318,326,336,345,354],{"path":311,"title":312,"description":313,"date":314,"tags":315},"\u002Fblog\u002Fja\u002Fkubernetes-networking-cni-service-mesh-network-engineer","サブネットは計算できるのに、Podは繋がらない。Kubernetesネットワーキングで最初にハマる壁","サブネット設計は得意なのに、なぜKubernetesのPod間通信では毎回つまずくのか。CNI・Service Mesh・NetworkPolicyというKubernetesネットワーキングの基礎を、伝統的なネットワーク設計の知識と対比しながら整理する。","2026-07-22",[304,303,307,305,316,317],"service-mesh","network-policy",{"path":319,"title":320,"description":321,"date":322,"tags":323},"\u002Fblog\u002Fja\u002Fkubevirt-calico-live-migration-networking","VMを動かしても通信は切れない。KubeVirtとCalicoが実現するKubernetesライブマイグレーションの舞台裏","KubernetesでVM（KubeVirt）をノード間へライブマイグレーションしても、なぜ通信が切れないのか。CalicoのIP永続化・BGPルート収束の仕組みと、VMware移行先としての実務的な意味を解説する。","2026-08-07",[303,304,324,307,325],"kubevirt","managed-kubernetes",{"path":327,"title":328,"description":329,"date":330,"tags":331},"\u002Fblog\u002Fja\u002Fk3s-container-image-security-supply-chain-checklist","「スキャン済み」は本番投入の許可証にならない。K3sコンテナイメージセキュリティ、署名からアドミッション制御まで","コンテナ セキュリティ ガイドラインというと『スキャンしてるから大丈夫』で止まりがちだ。K3s環境でベースイメージの最小化から脆弱性スキャン、SBOM生成、署名、アドミッション制御まで、本番投入前に通すべき工程を実務チェックリストとして具体的に解説する。","2026-08-24",[303,304,332,333,334,335],"container-security","image-scanning","sbom","supply-chain-security",{"path":337,"title":338,"description":339,"date":340,"tags":341},"\u002Fblog\u002Fja\u002Fk3s-harbor-private-registry-docker-hub-rate-limit","Docker Hubの無料枠が凍りついた朝、K3sクラスタは静かに詰む。Harborを自前で持つべきタイミング","Docker Hubのpull rate limitで本番K3sクラスタのイメージ取得が止まるリスクが現実味を増している。CNCF卒業プロジェクトHarborを自前運用する設計判断と隠れたコストを解説する。","2026-08-23",[303,304,342,343,344],"harbor","container-registry","cncf",{"path":346,"title":347,"description":348,"date":349,"tags":350},"\u002Fblog\u002Fja\u002Fkubernetes-cost-management-eks-aks-billing-visibility","EKSの請求書は月末にならないと読めない。Kubernetesのコストが『後から分かる』構造的な理由","EKS\u002FAKSのKubernetesコストはなぜ想定外に膨らむのか。オートスケールとクロスAZ課金がコストを見えなくする構造を分解し、K3sベースのマネージドインフラで固定費化する方法を解説します。","2026-08-22",[303,304,351,325,352,353],"cost-optimization","aks","finops",{"path":355,"title":356,"description":357,"date":358,"tags":359},"\u002Fblog\u002Fja\u002Fkubernetes-operations-specialization-managed-k3s-hiring","eBPFもcert-managerもService Meshも。Kubernetes運用がひとりのエンジニアの手に負えなくなった理由","Kubernetes運用の求人がなぜ埋まらないのか。原因はツール知識の不足ではなく、専門分野が広がりすぎたことにある。採用で埋めるのではなく基盤に吸収させる、マネージドK3sという解決策を解説する。","2026-08-21",[303,304,325,360,361],"devops","platform-engineering",1787649512496]