[{"data":1,"prerenderedAt":332},["ShallowReactive",2],{"blog-ja-kubernetes-networking-cni-service-mesh-network-engineer":3,"blog-related-ja-kubernetes-networking-cni-service-mesh-network-engineer":281,"blog-ja-kubernetes-networking-cni-service-mesh-network-engineer-alt":269},{"id":4,"title":5,"author":6,"body":7,"date":263,"description":264,"extension":265,"image":266,"locale":267,"meta":268,"navigation":269,"path":270,"seo":271,"stem":272,"tags":273,"__hash__":280},"blog\u002Fblog\u002Fja\u002Fkubernetes-networking-cni-service-mesh-network-engineer.md","サブネットは計算できるのに、Podは繋がらない。Kubernetesネットワーキングで最初にハマる壁","Kubo Team",{"type":8,"value":9,"toc":243},"minimark",[10,15,23,26,37,40,49,53,58,61,66,69,72,76,83,87,90,94,99,102,106,121,124,128,137,140,144,159,167,171,176,179,183,190,193,197,206,209,213,216,219,231,240],[11,12,14],"h2",{"id":13},"_1-サブネットは計算できるのになぜpodは繋がらないのか","1. サブネットは計算できるのに、なぜPodは繋がらないのか",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-networking-cni-service-mesh-network-engineer\u002Fsection01.webp",[16,24,25],{},"サブネットマスクの計算も、VLANの設計も、BGPのピアリングも問題なくこなせる。それなのに、Kubernetesクラスタを触り始めた途端、Pod同士がなぜ繋がらないのか分からなくなる——これは決して珍しい話ではありません。",[16,27,28,29,36],{},"Kubernetesネットワーキングは、従来のネットワーク設計とは異なる抽象化レイヤーの上に成り立っています。Podは頻繁に作られては消え、IPアドレスは固定されず、ルーティングテーブルを手作業で編集する余地はほとんどありません。",[30,31,35],"a",{"href":32,"rel":33},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fservices-networking\u002Fservice\u002F",[34],"nofollow","Kubernetes公式ドキュメント","が説明する通り、KubernetesのServiceリソースは「動的に変化するPodのIPアドレスから切り離された、安定したネットワークエンドポイント」を提供する仕組みであり、これは伝統的なネットワーク設計における「固定IP + 静的ルーティング」という前提そのものを覆します。",[16,38,39],{},"つまり、Kubernetesネットワーキングを理解するとは、ネットワークエンジニアが持つ「アドレス設計」の知識を、Kubernetesの「宣言的・動的」な世界にどう翻訳するかを学ぶことに他なりません。本記事では、CNI・Service Mesh・NetworkPolicyという3つの主要コンポーネントを、従来のネットワーク概念と対比しながら整理していきます。",[16,41,42,43,48],{},"とはいえ、この翻訳作業を毎回ゼロから自社でやり切る必要があるかというと、必ずしもそうではありません。",[30,44,47],{"href":45,"rel":46},"https:\u002F\u002Fkubo.hexabase.io\u002F",[34],"Kubo","のようなマネージドKubernetesサービスでは、CNIの選定やNetworkPolicyの基本構成がすでに標準化された状態から始められます。まずはKubernetesネットワーキングの基礎を押さえておきましょう。",[11,50,52],{"id":51},"_2-kubernetesネットワーキングの3層構造-cniserviceingress","2. Kubernetesネットワーキングの3層構造 — CNI・Service・Ingress",[16,54,55],{},[19,56],{"alt":21,"src":57},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-networking-cni-service-mesh-network-engineer\u002Fsection02.webp",[16,59,60],{},"Kubernetesネットワーキングは、大きく3つの層に分けて理解すると全体像がつかみやすくなります。",[62,63,65],"h3",{"id":64},"cnicontainer-network-interface-pod間通信の土台","CNI(Container Network Interface) — Pod間通信の土台",[16,67,68],{},"CNIは、Podにネットワークインターフェースを割り当て、Pod間の実際のパケット転送を担うレイヤーです。CNIの仕様自体はプラグイン形式になっており、クラスタ構築時にどのCNIプラグインを採用するかによって、Pod間通信の実装方式(オーバーレイネットワークかBGPによるルーティングか等)が大きく変わります。",[16,70,71],{},"伝統的なネットワークで言えば、CNIは「スイッチとルーターの組み合わせ」に近い役割です。ただし、物理的なポート設定ではなく、Kubernetesのマニフェストによる宣言的な設定が基本になる点が最大の違いです。",[62,73,75],{"id":74},"service-pod群を隠す安定したエンドポイント","Service — Pod群を隠す安定したエンドポイント",[16,77,78,79,82],{},"Podは頻繁にスケールアップ・ダウンし、IPアドレスも変わります。この不安定さを吸収するのがServiceリソースです。",[30,80,35],{"href":32,"rel":81},[34],"によれば、Serviceが作成されると固定のClusterIPが割り当てられ、コントローラが常にセレクタに一致するPodをスキャンして、対応するEndpointSliceを自動更新します。クライアント側はPodの個別IPを意識する必要がなく、ロードバランサ配下に複数のサーバーが隠れているのと同じ発想です。",[62,84,86],{"id":85},"ingress-クラスタ外部との接点","Ingress — クラスタ外部との接点",[16,88,89],{},"クラスタ外部からのHTTP\u002FHTTPSトラフィックをルーティングする役割を担うのがIngressです。従来のリバースプロキシ・ロードバランサの設定に近い概念ですが、Kubernetesではこれもマニフェストとして宣言的に管理される点が特徴です。",[11,91,93],{"id":92},"_3-cni選定の実際-ciliumcalicoflannelの設計思想の違い","3. CNI選定の実際 — Cilium・Calico・Flannelの設計思想の違い",[16,95,96],{},[19,97],{"alt":21,"src":98},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-networking-cni-service-mesh-network-engineer\u002Fsection03.webp",[16,100,101],{},"CNIプラグインの選定は、ネットワークエンジニアの既存知識が最も活きる、あるいは最も発想の転換を迫られる領域です。代表的な3つのプラグインを見てみましょう。",[62,103,105],{"id":104},"cilium-ebpfで実現する可観測性とセキュリティ","Cilium — eBPFで実現する可観測性とセキュリティ",[16,107,108,109,114,115,120],{},"Ciliumは、Linuxカーネルの機能であるeBPFを基盤にしたCNIプラグインです。",[30,110,113],{"href":111,"rel":112},"https:\u002F\u002Fwww.cncf.io\u002Fannouncements\u002F2023\u002F10\u002F11\u002Fcloud-native-computing-foundation-announces-cilium-graduation\u002F",[34],"CNCF公式の発表","によれば、Ciliumは2021年10月にCNCF Incubatingプロジェクトとして採択された後、2023年10月にGraduated(卒業)レベルへ昇格しました。同発表では、100社以上での導入実績と800名以上の個別コントリビューターが参加していることが報告されており、CNCFの中でもKubernetes本体に次いで活発なプロジェクトの一つとされています。",[30,116,119],{"href":117,"rel":118},"https:\u002F\u002Fwww.cncf.io\u002Fprojects\u002Fcilium\u002F",[34],"CNCFのプロジェクトページ","でも、CiliumはeBPFベースのネットワーキング・セキュリティ・可観測性ソリューションとして位置づけられています。",[16,122,123],{},"伝統的なネットワークエンジニアにとって、Ciliumの強みは「パケットの流れを可視化できる」という点にあります。従来のtcpdumpやNetFlowに近い感覚で、Pod間通信をリアルタイムに観測できるのは大きな利点です。",[62,125,127],{"id":126},"calico-bgpネイティブという馴染みのある選択肢","Calico — BGPネイティブという「馴染みのある」選択肢",[16,129,130,131,136],{},"Calicoは、BGP(Border Gateway Protocol)をベースにしたルーティングを採用できる点が特徴です。",[30,132,135],{"href":133,"rel":134},"https:\u002F\u002Fdocs.tigera.io\u002Fcalico\u002Flatest\u002Fabout\u002F",[34],"Calico公式ドキュメント","では、Calicoはコンテナ・仮想マシン・ベアメタルホストに対応するネットワーキング・セキュリティソリューションと説明されており、Kubernetesだけでなく OpenStack やベアメタル環境まで幅広くサポートしています。",[16,138,139],{},"BGPによるルーティングは、データセンターネットワークで培った知識がそのまま活きる数少ない領域であり、ネットワークエンジニアにとって最も「馴染みのある」CNIと言えるでしょう。",[62,141,143],{"id":142},"flannel-シンプルな接続性に特化","Flannel — シンプルな接続性に特化",[16,145,146,147,152,153,158],{},"Flannelは、",[30,148,151],{"href":149,"rel":150},"https:\u002F\u002Fgithub.com\u002Fflannel-io\u002Fflannel",[34],"公式リポジトリの説明","にある通り「Kubernetes向けに設計されたシンプルなレイヤー3ネットワークファブリック」です。各ノード上でflanneldエージェントが動作し、あらかじめ設定されたアドレス空間からサブネットを割り当てる仕組みになっています。ポリシーエンジンを持たず、純粋な接続性提供に特化している点がCiliumやCalicoとの大きな違いです。K3sでは、このFlannelが",[30,154,157],{"href":155,"rel":156},"https:\u002F\u002Fdocs.k3s.io\u002Fnetworking\u002Fbasic-network-options",[34],"デフォルトのCNIプラグイン","として採用されており、バックエンドにはvxlanがデフォルト設定されています。",[16,160,161,162,166],{},"K3sベースの",[30,163,165],{"href":45,"rel":164},[34],"Kubo Cloud","も、この軽量なネットワーク構成を土台にしつつ、NetworkPolicy対応やモニタリングを標準搭載しているため、Flannel単体では手薄になりがちなポリシー制御・可観測性の部分を運用時に別途組み上げる手間を減らせます。",[11,168,170],{"id":169},"_4-networkpolicyとservice-meshは何が違うのか","4. NetworkPolicyとService Meshは何が違うのか",[16,172,173],{},[19,174],{"alt":21,"src":175},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-networking-cni-service-mesh-network-engineer\u002Fsection04.webp",[16,177,178],{},"Kubernetesネットワーキングを学ぶ上で、多くのエンジニアが混同しがちなのがNetworkPolicyとService Meshの役割の違いです。",[62,180,182],{"id":181},"networkpolicy-l3l4のアクセス制御","NetworkPolicy — L3\u002FL4のアクセス制御",[16,184,185,189],{},[30,186,35],{"href":187,"rel":188},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fservices-networking\u002Fnetwork-policies\u002F",[34],"によれば、NetworkPolicyは「IPアドレスやポートレベル(OSI層3\u002F4)でのトラフィック制御」を実現するリソースであり、TCP・UDP・SCTPといったプロトコルをサポートします。重要な注意点として、公式ドキュメントは「NetworkPolicyはネットワークプラグインによって実装される」と明記しており、NetworkPolicy自体をサポートしないCNIプラグイン(前述のFlannelがその代表例です)を使っている場合、NetworkPolicyリソースを作成しても何の効果も発揮しません。",[16,191,192],{},"これは、伝統的なファイアウォールルールの設定に近い発想です。「どのPod(送信元)から、どのPod(宛先)への、どのポートへの通信を許可するか」を宣言的に定義する仕組みだと理解すると分かりやすいでしょう。",[62,194,196],{"id":195},"service-mesh-l7の暗号化可観測性トラフィック制御","Service Mesh — L7の暗号化・可観測性・トラフィック制御",[16,198,199,200,205],{},"一方でService Meshは、L7(アプリケーション層)の機能を担います。代表的な実装であるIstioの場合、",[30,201,204],{"href":202,"rel":203},"https:\u002F\u002Fistio.io\u002Flatest\u002Fdocs\u002Fconcepts\u002Fsecurity\u002F",[34],"公式ドキュメント","は「Istioはアプリケーションコードの変更なしに、相互TLS(mTLS)をトランスポート認証のフルスタックソリューションとして提供する」と説明しています。クライアント側とサーバー側それぞれのEnvoyプロキシがハンドシェイクを行い、身元を相互に検証した上でトラフィックを暗号化するという流れです。",[16,207,208],{},"つまり、NetworkPolicyが「通信していいか\u002F悪いか」を判定するファイアウォールだとすれば、Service Meshは「通信そのものを暗号化し、誰が誰と話しているかを可視化する」レイヤーだという整理ができます。両者は競合する技術ではなく、組み合わせて使うことで初めて、L3\u002FL4とL7の両方をカバーする防御が実現します。",[11,210,212],{"id":211},"_5-まとめ-サブネット思考は土台になるが発想の転換が必要","5. まとめ — サブネット思考は土台になるが、発想の転換が必要",[16,214,215],{},"Kubernetesネットワーキングは、決して伝統的なネットワーク設計の知識を無駄にする技術ではありません。BGPの理解はCalicoの運用にそのまま活き、ファイアウォールルール設計の発想はNetworkPolicyの設計に直結します。一方で、「Podは動的に生成・消滅する」「IPは固定されない」「設定はマニフェストによる宣言的管理が基本」という前提の転換は避けて通れません。",[16,217,218],{},"CNIの選定、NetworkPolicyとService Meshの役割分担——これらを一つひとつ設計・検証していく作業は、決して小さな学習コストではありません。EKSやAKSでゼロからCNIを選定し、NetworkPolicyの対応状況を確認し、監視体制まで構築するには、相応の運用工数がかかります。",[16,220,221,224,225,230],{},[30,222,47],{"href":45,"rel":223},[34],"はK3sをベースにしたマネージドKubernetesサービスで、CNIやネットワークポリシーの基本構成があらかじめ標準化されているため、ネットワーク設計の複雑さをゼロから検討する必要がありません。4vCPU\u002F8GB\u002F40GB×3ノード構成の場合、",[30,226,229],{"href":227,"rel":228},"https:\u002F\u002Fwww.hexabase.com\u002Fpricing\u002F",[34],"料金プラン","にある通り月額48,000円からフルスペックのKubernetes環境を運用開始でき、これはAWS EKSの月額82,700円と比較して大幅なコスト効率を実現します。",[16,232,233,234,239],{},"もちろん、Kuboは標準的なKubernetes APIをそのまま使えるため、Calico・Cilium由来の知識やBGPの経験がそのまま活かせる設計です。ネットワーク設計の土台を学びながら、実際の運用はマネージドサービスに任せるという選択肢も十分に現実的です。ネットワーク設計の詳細を自社で検討する余裕がない場合は、",[30,235,238],{"href":236,"rel":237},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[34],"お問い合わせ","から現在の構成を相談してみるのも一つの手です。",[16,241,242],{},"Kubernetesネットワーキングという領域は、伝統的なネットワークエンジニアにとって「知らない言語」ではなく、「文法が変わった、馴染みのある言語」なのです。",{"title":21,"searchDepth":244,"depth":244,"links":245},2,[246,247,253,258,262],{"id":13,"depth":244,"text":14},{"id":51,"depth":244,"text":52,"children":248},[249,251,252],{"id":64,"depth":250,"text":65},3,{"id":74,"depth":250,"text":75},{"id":85,"depth":250,"text":86},{"id":92,"depth":244,"text":93,"children":254},[255,256,257],{"id":104,"depth":250,"text":105},{"id":126,"depth":250,"text":127},{"id":142,"depth":250,"text":143},{"id":169,"depth":244,"text":170,"children":259},[260,261],{"id":181,"depth":250,"text":182},{"id":195,"depth":250,"text":196},{"id":211,"depth":244,"text":212},"2026-07-22","サブネット設計は得意なのに、なぜKubernetesのPod間通信では毎回つまずくのか。CNI・Service Mesh・NetworkPolicyというKubernetesネットワーキングの基礎を、伝統的なネットワーク設計の知識と対比しながら整理する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-networking-cni-service-mesh-network-engineer\u002Feyecatch.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fkubernetes-networking-cni-service-mesh-network-engineer",{"title":5,"description":264},"blog\u002Fja\u002Fkubernetes-networking-cni-service-mesh-network-engineer",[274,275,276,277,278,279],"kubernetes","k3s","networking","cni","service-mesh","network-policy","OCKobSUbreLehe4umeevkjaN7oB3yXj08RdS2ZY0SEg",[282,290,298,307,315,323],{"path":283,"title":284,"description":285,"date":286,"tags":287},"\u002Fblog\u002Fja\u002Fkubevirt-calico-live-migration-networking","VMを動かしても通信は切れない。KubeVirtとCalicoが実現するKubernetesライブマイグレーションの舞台裏","KubernetesでVM（KubeVirt）をノード間へライブマイグレーションしても、なぜ通信が切れないのか。CalicoのIP永続化・BGPルート収束の仕組みと、VMware移行先としての実務的な意味を解説する。","2026-08-07",[275,274,288,276,289],"kubevirt","managed-kubernetes",{"path":291,"title":292,"description":293,"date":294,"tags":295},"\u002Fblog\u002Fja\u002Fkubernetes-microservices-chatty-calls-latency","1つの注文処理で、裏側は5回叩かれていた。Kubernetesマイクロサービスの「チャッティ呼び出し」とレイテンシの正体","1回の注文処理の裏側でサービスが5回も呼び出されていた。原因はKubernetesマイクロサービスが陥る「チャッティ呼び出し」というアーキテクチャの問題。分散システムのN+1問題と解決策を解説する。","2026-08-02",[274,275,296,278,297,289],"microservices","latency",{"path":299,"title":300,"description":301,"date":302,"tags":303},"\u002Fblog\u002Fja\u002Fkubernetes-certificate-management-cert-manager-process-debt","証明書の更新、1行のコードより2ヶ月の会議が長かった。Kubernetesの証明書管理が『技術』ではなく『手続き』の問題である理由","Kubernetesの証明書管理は技術的には数日で終わる。だが実際に時間がかかるのは合意形成という『手続き』だ。cert-managerによる自動化と、組織的負債をなくす設計を解説する。","2026-08-09",[275,274,304,305,306],"cert-manager","tls","security",{"path":308,"title":309,"description":310,"date":311,"tags":312},"\u002Fblog\u002Fja\u002Fai-agent-sandbox-kata-containers-kubernetes","AIエージェントのコードは「信頼できる製品」じゃない。Kubernetesサンドボックス設計の答え","AIエージェントが生成・実行するコードはもう「信頼できる製品」ではない。KubernetesでAIエージェント向けサンドボックスを設計する際、コンテナ分離の限界とKata Containersによるマイクロ VM分離がなぜ必要になるのかを解説する。","2026-08-08",[275,274,313,314,306],"kata-containers","ai-agent",{"path":316,"title":317,"description":318,"date":319,"tags":320},"\u002Fblog\u002Fja\u002Fkubernetes-image-signing-sigstore-supply-chain","イメージタグは誰でも書き換えられる。Kubernetesのイメージ署名にSigstoreで『来歴』を刻むという発想","コンテナイメージ署名の仕組みを解説。イメージタグは誰でも書き換え可能で、CI\u002FCDのテストを通過した保証にはならない。SigstoreとKyvernoを組み合わせ、Kubernetes\u002FK3s上で未署名イメージの起動を拒否する防御層を構築する方法を、GitOps運用との統合も含めて紹介する。","2026-08-06",[275,274,321,322,306],"ci-cd","gitops",{"path":324,"title":325,"description":326,"date":327,"tags":328},"\u002Fblog\u002Fja\u002Fkubernetes-high-availability-broadcast-seamless-switching","「同じ映像を2回送って、早く着いた方を使う。」放送業界の非常識がKubernetesの高可用性設計そのものだった件","ワールドカップ放送は同じ映像を2つの経路で二重送信し、早く着いた方だけを使う。この一見無駄な冗長化がKubernetesの高可用性設計・マルチAZ構成と同じ思想である理由を解説する。","2026-08-05",[275,274,329,330,331],"high-availability","multi-az","sre",1786354651215]