K3sと標準Kubernetesを比較するとき、多くの人は「K3sは軽量だからネットワークも簡易なはずだ」と考える。しかし実際の違いはそこではない。K3sはFlannelというCNI(Container Network Interface)プラグインをデフォルトで同梱しているのに対し、kubeadmで構築する標準Kubernetesは、CNIが一切選ばれていない状態からスタートする。この「最初から何かが選ばれているか、自分で選ぶ必要があるか」という出発点の違いが、NetworkPolicyの可否や通信性能といった本番運用上の実質的な差を生む。本記事では、K3sと標準KubernetesのCNIに関する既定動作の違いを、公式ドキュメントに基づいて整理する。
K3sと標準Kubernetesは「ネットワークの出発点」が違う
K3sは、CoreDNSやTraefikなどと並ぶ「Packaged Component」としてFlannelをあらかじめ組み込んでおり、そのデフォルトバックエンドはvxlanだ。K3s公式ドキュメントによれば、Flannelを無効化してカスタムCNIを使いたい場合は--flannel-backend=noneを指定し、任意のCNIプラグインをインストールすればよいとされている。暗号化が必要な場合はwireguard-nativeバックエンドを選ぶこともできる。
一方、kubeadmでクラスタを構築する標準Kubernetesは、コントロールプレーンの初期化とは独立した別ステップとして「Pod network add-on のインストール」が公式手順に組み込まれている。kubeadmのクラスタ構築ガイドおよびkubeadmのインストールガイドでは、kubeadmで構築したクラスタがContainer Network Interfaceプラグインに依存することが明記されており、CNIの選定と導入はクラスタ構築者の責任として切り出されている。
つまり、「K3sは機能が少ない簡易版」という理解は正確ではない。K3sは"デフォルトの選択"を用意しているのに対し、標準Kubernetesは"選択そのもの"をユーザーに委ねている、という設計思想の違いがある。GKE/EKS/AKSのようなマネージドサービスでは、多くの場合CNIがあらかじめ設定された状態で提供される点も踏まえると、K3sはこの「選択を省略する」方向に近い立ち位置にあると言える。
FlannelはNetworkPolicyを一切強制しない
K3sのデフォルトCNIであるFlannelには、見落とされがちな明確な制約がある。Flannel公式リポジトリの説明では、Flannelはネットワーク接続そのものに特化しており、flanneldバイナリはNetworkPolicyをネイティブには強制しないとされている。Flannelを使ってKubernetesのNamespace間通信を制限したいと考えても、Flannel単体では何も制限されず、意図せず全通信が許可された状態になる。
Flannelの公式ドキュメントでは、ポリシー管理が必要な組織向けに2つの選択肢が示されている。1つはHelm chart経由でKubernetes SIGs提供のネットワークポリシーコントローラーを別途デプロイする方法、もう1つはCalicoのような専用ツールと組み合わせる方法だ。つまりFlannelは意図的に「ネットワーキングのみ」に機能を絞り、ポリシー層はモジュールとして後から追加する設計になっている。
これはK3s固有の問題ではなく、標準Kubernetes側でもFlannelを選べば同じ制約を負うことになる。重要なのは、K3sのデフォルト構成をそのまま使う場合、NetworkPolicyによるNamespace間の通信制御は"効いていない"ことが多いという事実に気づくことだ。セキュリティ要件としてNetworkPolicyの強制が必要なら、Calico・Ciliumなどポリシー対応CNIへの切り替えを検討する必要がある。
VXLANオーバーレイは通信性能にどう効くか
K3sが採用するVXLANは「オーバーレイネットワーク」の一種で、ノード間を流れるパケットに追加のヘッダを付与してトンネリングする方式だ。Calico公式ドキュメントは、VXLANとIP-in-IPを比較して「VXLANはヘッダサイズが大きいぶん若干オーバーヘッドが増える」としながらも、「非常にネットワーク負荷の高いワークロードでない限り、通常は体感できる差ではない」とも説明している。その上でCalicoは、基本方針として「オーバーレイ/カプセル化なしでCalicoを運用することを推奨する。これにより最高のパフォーマンスとシンプルなネットワークが得られ、ワークロードから出て行くパケットがそのまま回線に送出される」としている。
Cilium公式ドキュメントでも同様の構図が説明されている。トンネリングモード(VXLAN/Geneve)はカプセル化ヘッダを追加するため実効MTUが下がるが、ジャンボフレームを有効にすれば1パケットあたりのオーバーヘッド比率は小さくできる。トンネリングモードの利点は「クラスタノードを接続する下層ネットワークがPodのCIDRを認識している必要がない」ことで、ネットワーク構成への依存度が低い。一方、ネイティブルーティングモードは下層ネットワークがPod CIDRをルーティングできることが前提になるが、トンネリングのオーバーヘッドそのものを回避できる。
K3sの既定構成(Flannel/VXLAN)は、この2つの選択肢のうち「ネットワーク構成への依存度を下げる」側に寄せた設計だと理解すると納得しやすい。運用のしやすさを優先するか、オーバーレイを無くして最高性能を狙うかは、ワークロードの要件次第でトレードオフになる。
K3sでCalico/Ciliumに切り替える判断基準と注意点
ここまでの違いを踏まえると、K3sのデフォルト構成(Flannel)を使い続けるべきか、Calico・Ciliumに切り替えるべきかの判断基準は次のように整理できる。
- NetworkPolicyによる通信制御が要件にある場合: Flannel単体では強制されないため、Calico・Ciliumなどポリシー対応CNIの導入を検討する
- 下層ネットワークがPod CIDRをルーティングできる環境がある場合: ネイティブルーティングモードを選べるCalico/Ciliumに切り替えることで、オーバーレイのオーバーヘッドを避けられる
- 運用のシンプルさ・構成への依存の低さを優先する場合: K3sの既定Flannel構成のままで問題ないケースも多い
ただし、ここには実務上の重要な注意点がある。K3s公式ドキュメントが示す通り、Flannelのバックエンド設定はサーバーノードの起動オプションとして指定するものであり、しかもクラスタ内の全サーバーで同一の値にそろえる必要がある。つまりCNIの選定は、気軽に触れる運用時設定ではなく、クラスタを構築するタイミングで決めておくべき設計判断だということだ。
加えて、CNIプラグインそのものの管理のされ方もKubernetesのバージョンによって変わっている。Kubernetes公式ドキュメントによれば、Kubernetes 1.24以降ではkubeletによるCNI管理(cni-bin-dirやnetwork-pluginフラグ)は廃止され、CNIの管理はコンテナランタイム側の責務に移っている。こうした仕様の変化も踏まえると、「とりあえずK3sのデフォルトで動かして、CNIは後で考える」という進め方は避け、本番投入前にNetworkPolicyと通信性能の要件を洗い出した上でCNIを決定しておくのが安全だ。
まとめ
K3sと標準Kubernetesの違いは「機能の多さ・少なさ」ではなく、CNIという重要な選択肢を最初から用意しているか、自分で選ぶ必要があるかという出発点にある。K3sの既定であるFlannel/VXLANはNetworkPolicyを強制せず、オーバーレイ特有のオーバーヘッドも持つ。一方で、ネットワーク構成への依存度が低く、最小構成で素早く立ち上げられるという利点もある。重要なのは、この性質を理解した上で、NetworkPolicyや通信性能の要件に応じてCalico・Ciliumへの切り替えを本番投入前に判断することだ。
とはいえ、CNIの選定・切り替えタイミングの見極めは、日々の運用に追われるインフラチームにとって片手間でこなせる作業ではない。KuboのようなマネージドK3sサービスであれば、NetworkPolicy要件や通信性能要件に応じたCNI選択を運用者に代わって最適化しつつ、Kubo Cloudが提供するPure Kubernetesとしての標準準拠も維持できる。EKS/AKSのような大手マネージドサービスの高コスト・複雑さ・ベンダーロックインに悩む必要はもうない。K3sベースのKuboなら、本格的なKubernetesの機能はそのままに、CNI選定のような地味だが重要な判断を運用の負担にせず、圧倒的なコスト効率で本番運用できる。
CNIの出発点の違いを正しく理解することは、K3sを「なんとなく軽いから」で選ぶのではなく、要件に基づいて正しく使いこなすための第一歩だ。NetworkPolicyや通信性能の要件が明確になっているなら、構築前の今が設計を見直す好機であり、お問い合わせからKuboの構成相談を始めることもできる。