[{"data":1,"prerenderedAt":326},["ShallowReactive",2],{"blog-ja-k3s-vs-kubernetes-cni-flannel-default-comparison":3,"blog-related-ja-k3s-vs-kubernetes-cni-flannel-default-comparison":277,"blog-ja-k3s-vs-kubernetes-cni-flannel-default-comparison-alt":263},{"id":4,"title":5,"author":6,"body":7,"date":257,"description":258,"extension":259,"image":260,"locale":261,"meta":262,"navigation":263,"path":264,"seo":265,"stem":266,"tags":267,"__hash__":276},"blog\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cni-flannel-default-comparison.md","K3s vs 標準Kubernetes、CNIの出発点はここまで違う。Flannel標準搭載とCNI選択制が生む差","Kubo Team",{"type":8,"value":9,"toc":248},"minimark",[10,18,26,31,55,74,81,85,91,108,111,118,122,128,137,145,148,152,158,161,183,194,211,214,225,239],[11,12,13],"p",{},[14,15],"img",{"alt":16,"src":17},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cni-flannel-default-comparison\u002Fsection01.webp",[11,19,20,21,25],{},"K3sと標準Kubernetesを比較するとき、多くの人は「K3sは軽量だからネットワークも簡易なはずだ」と考える。しかし実際の違いはそこではない。",[22,23,24],"strong",{},"K3sはFlannelというCNI(Container Network Interface)プラグインをデフォルトで同梱しているのに対し、kubeadmで構築する標準Kubernetesは、CNIが一切選ばれていない状態からスタートする","。この「最初から何かが選ばれているか、自分で選ぶ必要があるか」という出発点の違いが、NetworkPolicyの可否や通信性能といった本番運用上の実質的な差を生む。本記事では、K3sと標準KubernetesのCNIに関する既定動作の違いを、公式ドキュメントに基づいて整理する。",[27,28,30],"h2",{"id":29},"k3sと標準kubernetesはネットワークの出発点が違う","K3sと標準Kubernetesは「ネットワークの出発点」が違う",[11,32,33,34,38,39,46,47,50,51,54],{},"K3sは、CoreDNSやTraefikなどと並ぶ「Packaged Component」としてFlannelをあらかじめ組み込んでおり、そのデフォルトバックエンドは",[35,36,37],"code",{},"vxlan","だ。",[40,41,45],"a",{"href":42,"rel":43},"https:\u002F\u002Fdocs.k3s.io\u002Fnetworking\u002Fbasic-network-options",[44],"nofollow","K3s公式ドキュメント","によれば、Flannelを無効化してカスタムCNIを使いたい場合は",[35,48,49],{},"--flannel-backend=none","を指定し、任意のCNIプラグインをインストールすればよいとされている。暗号化が必要な場合は",[35,52,53],{},"wireguard-native","バックエンドを選ぶこともできる。",[11,56,57,58,61,62,67,68,73],{},"一方、kubeadmでクラスタを構築する標準Kubernetesは、コントロールプレーンの初期化とは",[22,59,60],{},"独立した別ステップ","として「Pod network add-on のインストール」が公式手順に組み込まれている。",[40,63,66],{"href":64,"rel":65},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fsetup\u002Fproduction-environment\u002Ftools\u002Fkubeadm\u002Fcreate-cluster-kubeadm\u002F",[44],"kubeadmのクラスタ構築ガイド","および",[40,69,72],{"href":70,"rel":71},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fsetup\u002Fproduction-environment\u002Ftools\u002Fkubeadm\u002Finstall-kubeadm\u002F",[44],"kubeadmのインストールガイド","では、kubeadmで構築したクラスタがContainer Network Interfaceプラグインに依存することが明記されており、CNIの選定と導入はクラスタ構築者の責任として切り出されている。",[11,75,76,77,80],{},"つまり、「K3sは機能が少ない簡易版」という理解は正確ではない。",[22,78,79],{},"K3sは\"デフォルトの選択\"を用意しているのに対し、標準Kubernetesは\"選択そのもの\"をユーザーに委ねている","、という設計思想の違いがある。GKE\u002FEKS\u002FAKSのようなマネージドサービスでは、多くの場合CNIがあらかじめ設定された状態で提供される点も踏まえると、K3sはこの「選択を省略する」方向に近い立ち位置にあると言える。",[27,82,84],{"id":83},"flannelはnetworkpolicyを一切強制しない","FlannelはNetworkPolicyを一切強制しない",[11,86,87],{},[14,88],{"alt":89,"src":90},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cni-flannel-default-comparison\u002Fsection02.webp",[11,92,93,94,99,100,103,104,107],{},"K3sのデフォルトCNIであるFlannelには、見落とされがちな明確な制約がある。",[40,95,98],{"href":96,"rel":97},"https:\u002F\u002Fgithub.com\u002Fflannel-io\u002Fflannel",[44],"Flannel公式リポジトリ","の説明では、Flannelはネットワーク接続そのものに特化しており、",[35,101,102],{},"flanneld","バイナリは",[22,105,106],{},"NetworkPolicyをネイティブには強制しない","とされている。Flannelを使ってKubernetesのNamespace間通信を制限したいと考えても、Flannel単体では何も制限されず、意図せず全通信が許可された状態になる。",[11,109,110],{},"Flannelの公式ドキュメントでは、ポリシー管理が必要な組織向けに2つの選択肢が示されている。1つはHelm chart経由でKubernetes SIGs提供のネットワークポリシーコントローラーを別途デプロイする方法、もう1つはCalicoのような専用ツールと組み合わせる方法だ。つまりFlannelは意図的に「ネットワーキングのみ」に機能を絞り、ポリシー層はモジュールとして後から追加する設計になっている。",[11,112,113,114,117],{},"これはK3s固有の問題ではなく、標準Kubernetes側でもFlannelを選べば同じ制約を負うことになる。重要なのは、",[22,115,116],{},"K3sのデフォルト構成をそのまま使う場合、NetworkPolicyによるNamespace間の通信制御は\"効いていない\"ことが多い","という事実に気づくことだ。セキュリティ要件としてNetworkPolicyの強制が必要なら、Calico・Ciliumなどポリシー対応CNIへの切り替えを検討する必要がある。",[27,119,121],{"id":120},"vxlanオーバーレイは通信性能にどう効くか","VXLANオーバーレイは通信性能にどう効くか",[11,123,124],{},[14,125],{"alt":126,"src":127},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cni-flannel-default-comparison\u002Fsection03.webp",[11,129,130,131,136],{},"K3sが採用するVXLANは「オーバーレイネットワーク」の一種で、ノード間を流れるパケットに追加のヘッダを付与してトンネリングする方式だ。",[40,132,135],{"href":133,"rel":134},"https:\u002F\u002Fdocs.tigera.io\u002Fcalico\u002Flatest\u002Fnetworking\u002Fconfiguring\u002Fvxlan-ipip",[44],"Calico公式ドキュメント","は、VXLANとIP-in-IPを比較して「VXLANはヘッダサイズが大きいぶん若干オーバーヘッドが増える」としながらも、「非常にネットワーク負荷の高いワークロードでない限り、通常は体感できる差ではない」とも説明している。その上でCalicoは、基本方針として「オーバーレイ\u002Fカプセル化なしでCalicoを運用することを推奨する。これにより最高のパフォーマンスとシンプルなネットワークが得られ、ワークロードから出て行くパケットがそのまま回線に送出される」としている。",[11,138,139,144],{},[40,140,143],{"href":141,"rel":142},"https:\u002F\u002Fdocs.cilium.io\u002Fen\u002Fstable\u002Fnetwork\u002Fconcepts\u002Frouting\u002F",[44],"Cilium公式ドキュメント","でも同様の構図が説明されている。トンネリングモード(VXLAN\u002FGeneve)はカプセル化ヘッダを追加するため実効MTUが下がるが、ジャンボフレームを有効にすれば1パケットあたりのオーバーヘッド比率は小さくできる。トンネリングモードの利点は「クラスタノードを接続する下層ネットワークがPodのCIDRを認識している必要がない」ことで、ネットワーク構成への依存度が低い。一方、ネイティブルーティングモードは下層ネットワークがPod CIDRをルーティングできることが前提になるが、トンネリングのオーバーヘッドそのものを回避できる。",[11,146,147],{},"K3sの既定構成(Flannel\u002FVXLAN)は、この2つの選択肢のうち「ネットワーク構成への依存度を下げる」側に寄せた設計だと理解すると納得しやすい。運用のしやすさを優先するか、オーバーレイを無くして最高性能を狙うかは、ワークロードの要件次第でトレードオフになる。",[27,149,151],{"id":150},"k3sでcalicociliumに切り替える判断基準と注意点","K3sでCalico\u002FCiliumに切り替える判断基準と注意点",[11,153,154],{},[14,155],{"alt":156,"src":157},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cni-flannel-default-comparison\u002Fsection04.webp",[11,159,160],{},"ここまでの違いを踏まえると、K3sのデフォルト構成(Flannel)を使い続けるべきか、Calico・Ciliumに切り替えるべきかの判断基準は次のように整理できる。",[162,163,164,171,177],"ul",{},[165,166,167,170],"li",{},[22,168,169],{},"NetworkPolicyによる通信制御が要件にある場合",": Flannel単体では強制されないため、Calico・Ciliumなどポリシー対応CNIの導入を検討する",[165,172,173,176],{},[22,174,175],{},"下層ネットワークがPod CIDRをルーティングできる環境がある場合",": ネイティブルーティングモードを選べるCalico\u002FCiliumに切り替えることで、オーバーレイのオーバーヘッドを避けられる",[165,178,179,182],{},[22,180,181],{},"運用のシンプルさ・構成への依存の低さを優先する場合",": K3sの既定Flannel構成のままで問題ないケースも多い",[11,184,185,186,189,190,193],{},"ただし、ここには実務上の重要な注意点がある。",[40,187,45],{"href":42,"rel":188},[44],"が示す通り、Flannelのバックエンド設定は",[22,191,192],{},"サーバーノードの起動オプション","として指定するものであり、しかもクラスタ内の全サーバーで同一の値にそろえる必要がある。つまりCNIの選定は、気軽に触れる運用時設定ではなく、クラスタを構築するタイミングで決めておくべき設計判断だということだ。",[11,195,196,197,202,203,206,207,210],{},"加えて、CNIプラグインそのものの管理のされ方もKubernetesのバージョンによって変わっている。",[40,198,201],{"href":199,"rel":200},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fextend-kubernetes\u002Fcompute-storage-net\u002Fnetwork-plugins\u002F",[44],"Kubernetes公式ドキュメント","によれば、Kubernetes 1.24以降ではkubeletによるCNI管理(",[35,204,205],{},"cni-bin-dir","や",[35,208,209],{},"network-plugin","フラグ)は廃止され、CNIの管理はコンテナランタイム側の責務に移っている。こうした仕様の変化も踏まえると、「とりあえずK3sのデフォルトで動かして、CNIは後で考える」という進め方は避け、本番投入前にNetworkPolicyと通信性能の要件を洗い出した上でCNIを決定しておくのが安全だ。",[27,212,213],{"id":213},"まとめ",[11,215,216,217,220,221,224],{},"K3sと標準Kubernetesの違いは「機能の多さ・少なさ」ではなく、",[22,218,219],{},"CNIという重要な選択肢を最初から用意しているか、自分で選ぶ必要があるか","という出発点にある。K3sの既定であるFlannel\u002FVXLANはNetworkPolicyを強制せず、オーバーレイ特有のオーバーヘッドも持つ。一方で、ネットワーク構成への依存度が低く、最小構成で素早く立ち上げられるという利点もある。重要なのは、この性質を理解した上で、NetworkPolicyや通信性能の要件に応じてCalico・Ciliumへの切り替えを",[22,222,223],{},"本番投入前に","判断することだ。",[11,226,227,228,233,234,238],{},"とはいえ、CNIの選定・切り替えタイミングの見極めは、日々の運用に追われるインフラチームにとって片手間でこなせる作業ではない。",[40,229,232],{"href":230,"rel":231},"https:\u002F\u002Fkubo.hexabase.io\u002F",[44],"Kubo","のようなマネージドK3sサービスであれば、NetworkPolicy要件や通信性能要件に応じたCNI選択を運用者に代わって最適化しつつ、",[40,235,237],{"href":230,"rel":236},[44],"Kubo Cloud","が提供するPure Kubernetesとしての標準準拠も維持できる。EKS\u002FAKSのような大手マネージドサービスの高コスト・複雑さ・ベンダーロックインに悩む必要はもうない。K3sベースのKuboなら、本格的なKubernetesの機能はそのままに、CNI選定のような地味だが重要な判断を運用の負担にせず、圧倒的なコスト効率で本番運用できる。",[11,240,241,242,247],{},"CNIの出発点の違いを正しく理解することは、K3sを「なんとなく軽いから」で選ぶのではなく、要件に基づいて正しく使いこなすための第一歩だ。NetworkPolicyや通信性能の要件が明確になっているなら、構築前の今が設計を見直す好機であり、",[40,243,246],{"href":244,"rel":245},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[44],"お問い合わせ","からKuboの構成相談を始めることもできる。",{"title":249,"searchDepth":250,"depth":250,"links":251},"",2,[252,253,254,255,256],{"id":29,"depth":250,"text":30},{"id":83,"depth":250,"text":84},{"id":120,"depth":250,"text":121},{"id":150,"depth":250,"text":151},{"id":213,"depth":250,"text":213},"2026-10-20","K3sはFlannelをデフォルト同梱し、標準KubernetesはCNI未選定の状態から始まる。この出発点の違いがNetworkPolicyの可否や通信性能にどう影響するかを、K3s\u002FKubernetes\u002FCalico\u002FCiliumの公式ドキュメントをもとに比較・解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cni-flannel-default-comparison\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-vs-kubernetes-cni-flannel-default-comparison",{"title":5,"description":258},"blog\u002Fja\u002Fk3s-vs-kubernetes-cni-flannel-default-comparison",[268,269,270,271,272,273,274,275],"k3s","kubernetes","cni","flannel","calico","cilium","networkpolicy","networking","ITYRJinghyeGUdSYSTfZDcmHPoaIWXMNJaKzGA1ypMA",[278,285,292,300,309,318],{"path":279,"title":280,"description":281,"date":282,"tags":283},"\u002Fblog\u002Fja\u002Fk3s-flannel-vxlan-overlay-mtu-troubleshooting","pingは通るのにHTTPだけ詰まる。K3sのFlannel VXLANオーバーレイネットワークがMTUで壊れる理由","K3sクラスタでpingは通るのにHTTPリクエストだけ詰まる——それはVXLANオーバーレイネットワークのMTU不整合が原因かもしれない。Flannel\u002FCalicoのMTU設計、PMTUブラックホールの正体、3ステップの診断手順とクラウド別の恒久対策までを解説する。","2026-09-01",[268,269,275,37,271,284],"mtu",{"path":286,"title":287,"description":288,"date":289,"tags":290},"\u002Fblog\u002Fja\u002Fkubernetes-cni-overlay-network-troubleshooting-ospf","OSPFなら1分で直る障害が、KubernetesのCNIだと半日かかる理由","Kubernetesのオーバーレイネットワークはなぜトラブルシューティングに時間がかかるのか。CNIの仕組み、Flannel VXLANとCalico BGPの違い、MTU不一致の切り分け手順まで、K3s運用者が押さえるべきポイントを解説する。","2026-08-16",[268,269,270,291,275],"overlay-network",{"path":293,"title":294,"description":295,"date":296,"tags":297},"\u002Fblog\u002Fja\u002Fkubernetes-networking-cni-service-mesh-network-engineer","サブネットは計算できるのに、Podは繋がらない。Kubernetesネットワーキングで最初にハマる壁","サブネット設計は得意なのに、なぜKubernetesのPod間通信では毎回つまずくのか。CNI・Service Mesh・NetworkPolicyというKubernetesネットワーキングの基礎を、伝統的なネットワーク設計の知識と対比しながら整理する。","2026-07-22",[269,268,275,270,298,299],"service-mesh","network-policy",{"path":301,"title":302,"description":303,"date":304,"tags":305},"\u002Fblog\u002Fja\u002Fk3s-ingress-gateway-api-migration-traefik-gap","Ingressはもう終わる。Gateway APIに移行したら、K3sのTraefikは半分しか乗り換えられなかった","K3s Gateway API 移行を試みると、標準搭載のTraefikでもCRD未導入・Canary設定の作り直し・証明書連携の見直しが必要になる。2026年のingress-nginx退役とKubernetes 1.36移行を踏まえ、K3s特有の落とし穴と実務対応をまとめた。","2026-10-10",[268,269,306,307,308,275],"gateway-api","traefik","ingress",{"path":310,"title":311,"description":312,"date":313,"tags":314},"\u002Fblog\u002Fja\u002Fk3s-networkpolicy-dual-stack-kube-router-ipv6-gap","「K3sはNetworkPolicyを無視する」は嘘だった。それでも通信が漏れていた、ServiceLBという死角","K3sはkube-router内蔵コントローラでNetworkPolicyをデフォルト強制する。それでもLoadBalancer経由の通信だけが漏れる理由は、ServiceLBの実装とNetworkPolicy APIの恒久的な制約が組み合わさった結果だった。検証手順と対処法を解説する。","2026-09-24",[268,269,274,315,316,317],"servicelb","kube-router","network-security",{"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",[268,269,324,275,325],"kubevirt","managed-kubernetes",1792592613022]