1. なぜ今、K3sにサービスメッシュを検討するのか
K3sを選ぶ理由は、たいてい「軽量であること」だ。シングルバイナリで動き、リソースの限られたエッジやオンプレのノードにも収まる。そこにサービスメッシュを足すという話は、一見するとその前提と矛盾しているように聞こえる。
だが実際には、マルチサービス構成のK3sクラスタでmTLS通信や可観測性を求める声は増えている。問題は「サービスメッシュを入れるかどうか」ではなく、「K3sという軽量環境に合う構成はどちらか」だ。ここでは、代表的な2つの選択肢であるLinkerdとIstio Ambient Meshを、実際のリソース数値とK3s特有のハマりどころを踏まえて比較する。
Kubernetesの運用を軽くしたいというP1（インフラエンジニア／SRE）の関心事に対して、サービスメッシュはむしろ「足すことで重くなるかもしれない」変数だ。Kubo のようなK3sベースのマネージド環境を使っていても、アドオンの選定判断そのものは自分たちで下す必要がある。
2. LinkerdとIstio Ambient Mesh、構造がまるで違う
両者は「サイドカーを使わない」という共通点を持ちながら、内部構造がまったく異なる。
Linkerdは単一層構造だ。Pod横に配置されるRust製のマイクロプロキシが、L4とL7の両方を1つのプロセスで処理する。L7の機能（リトライやタイムアウトなど）を有効にしても、追加されるのは設定だけで、プロキシの階層は増えない。Buoyantの2026年のアーキテクチャ比較記事は、この違いを「1種類のプロキシと設定変更」対「2種類のプロキシとトポロジー変更」という言葉で表現している。
Istio Ambient Meshは2層構造になる。ノードごとに共有される軽量なL4プロキシ「ztunnel」がまずすべての通信を受け持ち、HTTPルーティングや認可ポリシーのようなL7機能が必要なネームスペースにだけ、Envoyベースの「waypoint」プロキシが追加される。トラフィックは source ztunnel → waypoint → destination ztunnel という経路をたどることになり、L7を使うかどうかでネットワークトポロジー自体が変わる。
Ambient Modeは2024年11月公開のIstio v1.24でGAに到達し、ztunnel・waypoint・関連APIがIstioのTechnical Oversight Committeeによって「Stable」と認定された(Istio公式ブログ、CNCF Blog)。2022年9月の構想発表から26ヶ月かけて安定版になった経緯を見ても、決して思いつきの機能ではない。
3. リソース使用量を数字で見る
「軽量である」を数字で確認する。
- Linkerdのマイクロプロキシ: 1インスタンスあたりメモリ10〜20MB程度、CPUは1コアの1/4以下という報告がある。ARM64/ARMv7にネイティブ対応しており、Raspberry Piのような小型ノードでも動く(Buoyantのエッジ環境向け記事)。
- Istio sidecarモード: Pod1つごとにEnvoyインスタンスが立つため、メモリは1podあたり50〜100MB。100Pod規模のクラスタでは、プロキシだけで25〜30GiBのメモリを消費するという試算もある。
- Istio Ambient（ztunnel）: L4プロキシがノードで共有されるため、同じ100Pod規模で3〜4GiBまで圧縮できるという報告がある。
実測ベンチマークでも傾向は同様だ。oneuptime.comのベンチマーク記事では、L4のみのトラフィックであればAmbientの平均レイテンシは約3.2msで、sidecarモードの約4.8msより速く、スループットもAmbientが約5000QPSに対しsidecarが約3330QPSという結果が出ている。ただし同記事は「L7機能を多用するワークロードでは性能差が縮まる」とも指摘しており、ワークロードの性質によって有利不利が変わる点には注意が必要だ。
K3sの前提であるリソース制約を考えると、LinkerdとIstio Ambientはどちらもsidecar型のIstioより現実的だが、Pod数が数百規模になるほどノード共有型のAmbientが効いてくる、というのが数字から見える傾向になる。
こうしたプロキシのメモリ・CPU使用量は、ノードのリソースが逼迫してから初めて気づくことが多い。Kubo のCaptain UIはノード単位のリソース使用状況を可視化するため、サービスメッシュのようなアドオンを追加した際の変化にも早い段階で気づける。
4. K3sで実際にハマったポイント — CNIパス設定
K3sにIstio Ambient Meshを入れる際、最初につまずきやすいのがCNI設定のパスだ。
K3sはCNIプラグインのバイナリを $DATA_DIR/data/cni（デフォルトでは /var/lib/rancher/k3s/data/cni）に配置するなど、標準的なKubernetesディストリビューションとは異なる非標準の場所を使う(K3s公式ドキュメント)。この違いを吸収するため、Istioのインストール時には global.platform=k3s の指定が必須になる。
helm install istio-cni istio/cni -n istio-system \
--set profile=ambient \
--set global.platform=k3s \
--wait
この指定を忘れると、istio-cni がK3sのデフォルトCNIであるFlannelの設定ファイルを見つけられず、ztunnelとの接続が確立しないままPodが起動に失敗する。カスタムCNIを使っている場合は、さらに cniConfDir と cniBinDir を明示的に指定する必要があるとIstio公式のプラットフォーム別要件ドキュメントには書かれている。K3sのシンプルさに慣れていると見落としやすい設定だ。
なお、K3sのデフォルトCNIであるFlannelはL7検査やNetworkPolicyの実装を持たないシンプルな構成のため、Istioのトラフィックインターセプト自体を妨げにくい。相性という意味では悪くない組み合わせになる。
5. waypointが「静かに素通りする」既知の挙動
もう一つ、運用前提として知っておくべき挙動がある。
Istio 1.27.1環境で、waypointを正しくデプロイし、対象サービスに istio.io/use-waypoint ラベルを付け、AuthorizationPolicyのtargetRefsも正しく設定しているにもかかわらず、L7ポリシーが適用されないという事象がistio/istioの公開Issueで報告されている。トラフィックがwaypointを経由せず、ztunnel経由のL4のみで宛先に直接流れてしまうケースだ。
Ambient Meshの設計では、L4ポリシーはztunnel単体で強制でき、L7ポリシーだけがwaypointを必要とする。waypointへのルーティングに問題があるとき、ztunnelは通信を許可してしまうのではなく「フェイルセーフでトラフィックを拒否する」設計になっている。今回のIssueのように意図せず素通りするケースがあるのは事実だが、これは執筆時点でオープンな既知の課題であり、今後のマイナーバージョンで解消される可能性がある点は踏まえておきたい。裏を返せば、L7ポリシーを本番のセキュリティ境界として使う場合は、設定後に実際のトラフィックログで経路を確認する運用ステップを省略できない、ということでもある。
6. どちらを選ぶべきか — 判断基準
ここまでの内容を整理すると、判断基準は次のように単純化できる。
- カナリアリリース、フォールトインジェクション、細かいHTTPルーティングなど、L7のトラフィック管理機能が本番要件として必須 → Istio Ambient Mesh。waypointの運用コストを払ってでも得られる機能が多い
- 必要なのはmTLSと基本的な可観測性で、運用チームの人数が少ない → Linkerd。プロキシが1種類で済み、アップグレードの影響範囲も小さい
Buoyantの比較記事は判断のチェックリストとして「運用対象コンポーネント数」「アップグレードプロセスの複雑さ」「障害時のトレーサビリティ」「1年後のアーキテクチャがどうなっているか」「各プロジェクトの信頼性の実績」の5項目を挙げている。K3sの文脈に置き換えるなら、ここに「そのノードのリソースに本当に余裕があるか」を加えて考えるべきだろう。
まとめ
K3sは軽量であることが価値の前提だ。サービスメッシュを足すこと自体は否定されるべきものではないが、「何を選ぶか」でその前提が簡単に崩れる。LinkerdはPodあたり10〜20MBという軽さでK3sの思想と親和性が高く、Istio Ambient Meshは2024年のGA以降Stableな機能として、L7の高度なトラフィック管理が必要なチームにとって現実的な選択肢になった。
一方で、global.platform=k3s のような設定の見落としや、waypointのルーティングに関する既知の課題のように、実際に手を動かして初めて分かる落とし穴もある。こうしたアドオンの選定・検証・アップグレード対応まで含めた運用は、決して小さな負荷ではない。
Kubo Cloud はK3sベースのマネージドKubernetesとして、Prometheus + Grafanaによるモニタリングやcert-managerによる証明書自動管理など、こうしたアドオンの標準搭載・運用をあらかじめ引き受けている。サービスメッシュのような追加コンポーネントの選定に工数を割く前に、土台となる運用そのものを外部化するという選択肢も検討する価値がある。K3sならではの落とし穴を含めた設計・運用の相談は、お問い合わせ から可能だ。EKSやAKSと比較したコスト構造が気になる場合は、料金プラン で具体的な数字を確認してほしい。