2026年のサービスメッシュ — Istio Ambient / Linkerd 3 / Cilium Mesh / Consul Connect / Kuma 徹底比較(サイドカーは死んだのか)

プロローグ — 「service mesh がまた難しくなった」

KubeCon EU 2024。あるSREがステージで冗談を飛ばした。「service mesh を知っていると言うのはやめてください。2年前に知っていた mesh はもう存在しません」。会場は笑ったが、半分は本当だった。

2024-2026年に起きたことをまとめると:

Istio Ambient mode が 1.22 で GA(2024年) — サイドカーなしの Istio が現実になった。
Linkerd 3(Buoyant) — 一部機能を paid edition に移し、コミュニティから強い反発。
Cilium / Isovalent → Cisco(2024年) — eBPF メッシュがシスコの傘下に。
HashiCorp → IBM(2024年) — Consul Connect のガバナンスが変わった。
Open Service Mesh(Microsoft) — 2024年1月 sunset
AWS App Mesh — 2024年10月 sunset
Kuma(Kong) — federated multi-zone mesh として定着。
Gloo Mesh(solo.io) — multi-cluster Istio 運用の事実上の標準。
Traefik Mesh — 軽量オプションとして生き残り。

技術的にもっと興味深いのは モデル自体が分裂した ことだ。2020年は全員がサイドカー(Envoy が pod の隣に住む)だった。2026年には三つのモデルが共存している。

サイドカーモデル — 従来 Istio、Linkerd 2/3、Consul Connect のデフォルト。
Ambient モデル(L4 + L7 分離) — Istio Ambient(ztunnel + waypoint)、Linkerd の一部パターン。
eBPF / proxyless モデル — Cilium Service Mesh、gRPC-native、JVM の一部。

三つのモデルはトレードオフが異なり、ワークロードと運用体制によって正解が変わる。本稿は 各選択肢の 2026年現在の状態、サイドカー vs ambient vs proxyless 論争、運用パターン(mTLS・RBAC・トラフィックシフト・可観測性)、そして 誰が何を選ぶべきか を整理する。

ひとつだけ先に言っておく: service mesh はデフォルトではない。「Kubernetes を使うから mesh を入れる」は 2026年でも間違った推論だ。mesh なしで上手くやっているチームの方が、入れているチームより幸せなことが多い。ただし、本当に必要なチームにとっては、よく選ばれた mesh が運用の質を変える。

1章 · 2026年のサービスメッシュ地図 — 三モデル、七候補

選択肢	モデル	ガバナンス	2026年の状態
Istio(sidecar)	サイドカー	CNCF(graduated)	最も広く使われている。重い。
Istio Ambient	L4 + L7 分離	CNCF	1.22 GA(2024)。採用加速。
Linkerd 2	サイドカー(Rust micro-proxy)	Buoyant	軽量。メンテモード。
Linkerd 3	サイドカー + 一部 ambient パターン	Buoyant(paid edition 導入)	コミュニティ論争。
Cilium Service Mesh	eBPF + Envoy オプション	Cisco(Isovalent 買収)	急成長。
Consul Connect	サイドカー(Envoy)	IBM(HashiCorp 買収)	ガバナンス不透明。
Kuma	サイドカー / multi-zone	Kong / CNCF(Sandbox)	federated mesh が強い。
Gloo Mesh	Istio 上の multi-cluster	solo.io(商用)	エンタープライズ標準。
Traefik Mesh	DaemonSet プロキシ	Traefik Labs	軽量 / シンプル。
Open Service Mesh	サイドカー	Microsoft(sunset 2024-01)	終了。
AWS App Mesh	サイドカー(Envoy)	AWS(sunset 2024-10)	終了。

三モデルを一行でまとめると:

サイドカー — ワークロードの隣に Envoy(または micro-proxy)pod をもう一つ立てる。最も成熟しているが、メモリ・CPU・起動時間・デバッグ複雑度すべてが高い。
Ambient — ノードごとに L4 プロキシ(ztunnel)を置き、L7 ポリシーが必要な名前空間にだけ別の waypoint proxy を立てる。サイドカーのコストを大幅に下げる。
eBPF / proxyless — カーネル空間の eBPF でポリシー・暗号化・可観測性を実装。データプレーンプロキシなしでも mTLS・ポリシーの一部が可能。L7 機能が必要なら Envoy に転送する。

三モデルは 異なるトレードオフ を持つ。サイドカーは「成熟しているが重い」、ambient は「運用が単純化するが新コンポーネントが増える」、eBPF は「軽いがカーネル・OS・CNI 依存が強い」。普遍的な正解はない。

2章 · Istio Ambient(2024 GA) — ztunnel + waypoint

Istio Ambient mode は 2022年に alpha で始まり、2024年 1.22 で GA となった。中核アイデアは データプレーンを二層に分ける ことだ。

[Pod A] ────► [ztunnel(ノード DaemonSet)] ──mTLS──► [ztunnel] ────► [Pod B]
                  L4(TCP・HBONE トンネル)

L7 が必要なときだけ:

[Pod A] → [ztunnel] → [waypoint proxy(名前空間/サービス単位)] → [ztunnel] → [Pod B]
                          L7(HTTP route, RBAC, traffic shifting)

ztunnel: Rust で新規実装されたノード DaemonSet。各ノードに 1 つ常駐し、そのノードの Pod トラフィックを HBONE(HTTP-Based Overlay Network Environment、HTTP/2 over mTLS)トンネルでノード間転送する。L4 のみ — TLS・ID・単純な mTLS。
waypoint proxy: L7 ポリシー(HTTP route, header-based routing, RBAC, retry, mirror)が必要な名前空間または service account に限り別 Envoy Pod を立てる。ztunnel は L7 が必要なトラフィックを waypoint へ迂回させる。

なぜこれが意味を持つのか?

メモリ・CPU の節減: Pod 100 個にサイドカー 100 個ではなく、ノード 10 個に ztunnel 10 + waypoint 2-3。サイドカー 1 個あたり 50-200 MB の Envoy メモリが不要に。
起動時間: サイドカーは Pod 起動時に同時に立ち上がる必要があり、Pod 起動時間が伸びていた。Ambient はノード DaemonSet が事前に立っているため Pod 起動が速い。
アプリとサイドカーのカップリング解消: サイドカー OOM がアプリを殺したり、サイドカーバージョンがアプリ lifecycle を縛ったりすることが消える。
L4 / L7 分離: L7 が不要なワークロード(多い — 単純な gRPC backend、キューワーカーなど)は ztunnel だけで完結。

なぜ全員が Ambient に行かないのか?

新コンポーネント二つ(ztunnel、waypoint)の運用学習。
CNI / ネットワーク依存性: ambient は iptables の上に新しい netfilter ルールを敷く。一部 CNI(特に Cilium の一部バージョン)との衝突事例がある。
GA でも一部機能はサイドカー専用: 特定の EnvoyFilter、WASM 拡張などは ambient で制限。
マイグレーションコスト: 既に sidecar で動いているクラスタを ambient に移す作業自体が大きい。

2026年現在の推奨は 新規クラスタは ambient、既存 sidecar クラスタは段階的に移行。solo.io の Gloo など商用ディストロが ambient 移行ツールを急速に整備中。

3章 · Istio sidecar(伝統) — 依然として多くの場所で

ambient が GA になったからといってサイドカー Istio が死んだわけではない。2026年現在 本番稼働中の Istio クラスタの大多数は依然として sidecar だ。理由は単純 — 「動いているものをわざわざ移さない」。

サイドカー Istio の長所は健在:

最も多い事例・ドキュメント・ブログ。問題が起きれば検索で答えが出る。
すべての機能が動く。EnvoyFilter、WASM 拡張、すべての telemetry v2 機能。
他の ingress/egress との統合事例が最も豊富。

短所も健在:

メモリ・CPU コスト — Envoy サイドカー 1 個あたり平均 50-200 MB。
Pod 起動時間の増加 — サイドカーが ready になるまでアプリがトラフィックを受けられない(holdApplicationUntilProxyStarts)。
アプリとサイドカーの lifecycle 結合 — サイドカー OOM がアプリトラフィックを切る。
Istio control plane(istiod) 負荷 — Pod 数が増えるほど xDS push コストが増える。

いつ sidecar Istio が正解か?

既に運用していて動いているとき(最頻出ケース)。
特定の sidecar 専用 EnvoyFilter や WASM がコア機能のとき。
Ambient を採用するだけのチーム余力がないとき。

推奨: 新規は ambient、既存 sidecar の移行は段階的に。最も多い間違いは「ambient GA したから即移行」 — 運用学習コストが大きい。

4章 · Linkerd 3 — Buoyant の有料化決定(2024)

Linkerd は 2017年から「サイドカーだが軽量」を武器に、サイドカー陣営のミニマリストを自称してきた。Rust で書かれた linkerd2-proxy(現 linkerd-proxy)は Envoy よりメモリ・CPU が大幅に少ない — サイドカー 1 個あたり 10-30 MB 程度。

そんな 2024年、Buoyant(Linkerd の親会社)は stable release(production-ready ビルド)を paid edition に移すと発表。無料で入手できるのは edge release(週次ビルド)のみで、production で stable channel を使うには Buoyant Enterprise ライセンスが必要になった。

コミュニティの反応は激しかった:

「オープンソース mesh の黄金期が終わった」
「これは事実上 source-available への後退だ」
「だが Linkerd を維持しているのは非常に小さな会社だ。無限に無料でいられるはずがない」
「CNCF graduation プロジェクトでこれは許されるのか?」

Linkerd 3 の技術変更:

サイドカーはそのまま Rust micro-proxy。依然として軽い。
一部 ambient スタイルのパターン(サービス単位のポリシー委譲)を導入。
multi-cluster mTLS と federated 証明書管理の強化。
policy リソースがより豊富に(L7 RBAC など)。

2026年現在の視点:

技術的には依然として魅力的。サイドカーで最も軽い。
運用面で本当にシンプル。Istio のように数十の CRD を覚える必要がない。
しかし production stable ビルドの paid 化により、CNCF 卒業プロジェクトという安心感を削った。
edge channel は自由に使えるが、エンタープライズが unsupported channel を使うのは政治的に難しい。

選定基準:

軽量でシンプルな sidecar mesh が欲しく、Buoyant Enterprise コストを許容できるなら依然として良い選択。
「ベンダーロックイン」が怖いなら Istio Ambient や Cilium Service Mesh で迂回可能。
小さなチームが素早く mTLS だけ欲しいなら、依然として最もきれいな選択肢の一つ。

5章 · Cilium Service Mesh — eBPF + Cisco 買収(2024)

Cilium は元々 CNI(Container Network Interface)として始まったが、eBPF ベースの強力さを武器に Service Mesh 領域へ拡張した。2022年に OSS で service mesh 機能を公式化し、2023-2024年に本格的に production 採用が増えた。

2024年に Cisco が Isovalent(Cilium 親会社)を買収。eBPF 市場でのシスコの影響力が一気に拡大し、Cilium のエンタープライズディストリビューション — Isovalent Cilium Enterprise — の将来がシスコのセキュリティ・ネットワーキング製品群への統合方向に向かっている。

Cilium Service Mesh のモデル:

L4 mTLS + ポリシー: eBPF のみで動作。サイドカー・waypoint なしでノードカーネルで処理。
L7 機能(HTTP routing, gRPC, Kafka filter): ノードごとの Envoy(DaemonSet)または ingress gateway 形式。サイドカーではない。
可観測性: Hubble で L3/L4/L7 の可視性。eBPF でキャプチャするためサイドカーなしでも非常に豊か。
Network Policy 統合: CiliumNetworkPolicy で L3-L7 を一箇所で。

なぜ eBPF mesh が魅力的か?

サイドカー 0 個 — メモリ・CPU・起動時間すべて削減。
L4 はカーネルで処理 — context switch なしで速い。
mesh + CNI が一つ — 二つのコンポーネントを別管理する必要がない。
Hubble 可観測性 — すべてのトラフィックが eBPF でキャプチャされるためサンプリングなしで見える。

現実的な制約:

カーネル依存: 新機能には新カーネルが必要。5.x 後半または 6.x 推奨。
L7 機能は結局 Envoy — サイドカーがないだけで、Envoy 自体はどこかに存在する。
運用学習: eBPF・iptables・CNI・NetworkPolicy のインタラクションが複雑。
Istio API 互換不足: Istio に慣れているチームには運用パターンが異なる。

2026年時点の推奨:

新規クラスタを敷くなら Cilium は CNI として使う価値が十分(多くのクラウドの推奨 CNI)。
Cilium Service Mesh は「Cilium CNI を既に使っているなら」自然な拡張。
シスコ買収後のライセンス / ガバナンス変化を注視すること。

6章 · Consul Connect — HashiCorp → IBM 買収(2024)

Consul は 2014年から HashiCorp の service discovery・KV store として始まり、Consul Connect で service mesh 領域に進出した。VM と Kubernetes を同時に扱う mesh という点が最大の差別点だった — Istio・Linkerd が Kubernetes-first であるのに対し、Consul は最初から VM・bare-metal までを mesh に束ねられた。

2024年に IBM が HashiCorp を買収。Terraform・Vault・Consul・Nomad など HashiCorp の全製品が IBM 傘下へ。ガバナンス・ライセンス(既に 2023年に BSL へ変更)の両方に影響が出た。

Consul Connect の強み(健在):

ハイブリッド環境: VM + Kubernetes + bare-metal を一つの mesh に。
multi-datacenter / WAN federation: 早期からよく対応。
Vault 統合: Consul Connect の CA を Vault に委譲可能。
Service mesh + service discovery + KV: 統合プラットフォーム。

弱み・懸念:

BSL ライセンス(2023): 既に自由 OSS ではない — 競合 SaaS 提供が制限される。
IBM 買収後のロードマップ不透明: 一部ユーザーは OpenTofu 系の fork(Consul 向けは未成熟)を懸念。
Kubernetes-only 環境 では Istio / Linkerd 比で魅力が下がる。

いつ Consul Connect が正解か?

VM と Kubernetes を同時に扱うハイブリッド環境。
既に HashiCorp スタック(Terraform・Vault・Nomad)を深く使っている組織。
multi-region / multi-datacenter mesh が中核。

いつ避けるか?

純粋な Kubernetes-only で、ベンダーロックインが負担なとき。
ライセンス変更に敏感な OSS-first 組織。

7章 · Kuma(Kong) — federated mesh

Kuma は Kong が 2019年に作成し、2020年に CNCF Sandbox に寄贈した mesh。技術的には Envoy ベースのサイドカー mesh だが、最大の特徴は multi-zone / federated モデルだ。

Kuma のアーキテクチャ:

global control plane(グローバルポリシー管理) + zone control plane(各クラスタ/リージョン)。
一つの mesh が複数クラスタ・複数クラウド・VM を横断できる。
Universal mode(VM/bare-metal)と Kubernetes mode の両方をサポート。

他 mesh 比の強み:

multi-zone が first-class: Istio・Linkerd の multi-cluster より運用モデルがシンプル。
policy → mesh 単位で fan-out: 一箇所で定義すれば全 zone に伝播。
Kong API Gateway との統合: API ゲートウェイまで mesh の一部に。

弱み:

Istio ほどの広範なドキュメント / 事例が不足。
一部 L7 高度機能は Istio 比で遅れて入る。
Kong の商用化戦略次第で OSS feature set が影響を受ける可能性。

いつ Kuma? multi-cluster / multi-cloud / hybrid 環境で運用シンプルさが核のとき。特に既に Kong API Gateway を使っているなら自然。

8章 · Gloo Mesh(solo.io) — multi-cluster Istio

solo.io の Gloo Mesh は Istio の上に載せた商用 multi-cluster コントロールプレーン だ。Istio 単体は単一クラスタ運用はうまく動くが、複数クラスタを一つの mesh に束ねる作業(多クラスタ federation、共通証明書、cross-cluster service discovery)は運用上複雑。Gloo Mesh はその部分を商用製品で抽象化する。

Gloo Mesh が解決する問題:

multi-cluster Istio federation の自動化: 証明書・trust domain・east-west gateway セットアップが GUI / CLI で単純化。
グローバルポリシー管理: ポリシーを一箇所で定義 → 全クラスタに伝播。
VirtualService・DestinationRule の abstraction: より高水準の RouteTable・VirtualGateway CRD。
Ambient マイグレーション支援: solo.io が ambient 陣営の主要コントリビュータの一つ。

誰が使うか: 大規模エンタープライズ、特に multi-cluster Istio が中核な場所。金融・通信・一部ビッグテック SRE 組織。

代替: OSS Istio + 自前 multi-cluster セットアップ(可能だが運用コスト大)、または Cilium ClusterMesh。

9章 · Traefik Mesh — 軽量オプション

Traefik Mesh(旧 Maesh)は DaemonSet ベースの軽量 mesh だ。サイドカーモデルではなく、ノードごとのプロキシ(Traefik 自体)が一つでそのノードのトラフィックを処理する。モデル的には ambient の ztunnel に近い — ただし作られた時期はずっと早い(2019)。

長所:

サイドカーなし — メモリ・起動時間の負担が少ない。
運用シンプル — Traefik に慣れたチームにとっては学習コストが小さい。
SMI(Service Mesh Interface) 互換 — 標準 API。

短所:

L7 ポリシーの豊富さが Istio レベルではない。
mTLS・複雑な RBAC は他 mesh より単純。
コミュニティ規模が Istio・Linkerd・Cilium より小さい。

いつ Traefik Mesh? 小さなクラスタ、単純なトラフィックポリシーのみ必要な場所、既に Traefik ingress を使っている場所。

10章 · OSM / AWS App Mesh 終了の意味

Open Service Mesh(Microsoft) — 2024年1月 sunset。 AWS App Mesh — 2024年10月 sunset。

二つの mesh 終了は業界にシグナルを残した。

OSM の終了が示すこと:

Microsoft が自前 mesh より Istio・Cilium の採用を追う方が合理的 と判断。
AKS(Azure Kubernetes Service)は今や Istio add-on をデフォルト推奨。
クラウドベンダーが自前で mesh を構築するモデルの限界 — コミュニティモメンタムについていけない。

App Mesh の終了が示すこと:

AWS も自前 mesh を諦めた。AWS Cloud Map + ALB/NLB + EKS 上の OSS mesh(Istio/Linkerd) パターンへの回帰。
EKS 顧客が App Mesh より Istio/Linkerd/Cilium をより多く採用したことを認めた決定。
AWS は代わりに App Mesh を deprecate し、マイグレーションガイドを提供 する形で整理。

全体の教訓:

mesh は OSS コミュニティ + CNCF 傘下が強い場所に集中する — Istio、Linkerd、Cilium、Kuma。
クラウドベンダー自前 mesh は生き残りにくい — Google ですら ASM(Anthos Service Mesh)を Istio ベースで作る。
mesh の価値は portability — 一つの mesh で複数クラウドを束ねるのが核。ベンダー固有 mesh はその価値と衝突する。

11章 · mTLS / RBAC / Traffic shifting / 可観測性パターン

どの mesh を選んでも結局運用するパターンは似ている。中核の 4 つ。

11.1 mTLS — 最も多い導入理由

mesh を入れる最頻出理由。ゼロトラストネットワークの第一歩。

STRICT mode: mesh 内部のすべてのトラフィックは mTLS のみ許可。外部からの平文は拒否。
PERMISSIVE mode: mTLS と平文の両方を許可。マイグレーション段階で使用。
CA 管理: Istio は istiod が CA、Cilium は SPIRE 統合、Consul は Vault 委譲。

運用 Tips:

段階導入: PERMISSIVE → STRICT の順。一気に STRICT にすると未識別平文トラフィックで事故になる。
外部統合: データベース・Kafka・外部 API は mesh の外。egress gateway でポリシーを別に組む。
証明書ローテーション: 7日がデフォルト。短すぎると control plane 負荷増。

11.2 RBAC — 誰が誰を呼べるか

AuthorizationPolicy(Istio)、Server / ServerAuthorization(Linkerd)、CiliumNetworkPolicy(Cilium)で表現。

# Istio 例 — frontend ServiceAccount のみが backend の /api を呼べる
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: backend-policy
spec:
  selector:
    matchLabels:
      app: backend
  rules:
    - from:
        - source:
            principals: ['cluster.local/ns/default/sa/frontend']
      to:
        - operation:
            paths: ['/api/*']

運用 Tips:

default-deny → allow ルール: ゼロトラスト原則。
principal は ServiceAccount ベースで — 名前空間・ラベルベースは変更に弱い。
L7 ポリシーを過度に細かく組まない — コード変更のたびにポリシー変更が必要になる。

11.3 Traffic shifting — canary / blue-green / A/B

mesh のキラー機能。weighted routing で新バージョンを段階公開。

# Istio — v1 に 90%、v2 に 10%
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: payment
spec:
  hosts: ['payment']
  http:
    - route:
        - destination: { host: payment, subset: v1 }
          weight: 90
        - destination: { host: payment, subset: v2 }
          weight: 10

運用 Tips:

Argo Rollouts / Flagger と組み合わせる: 自動 progressive delivery。
メトリクスベース自動 rollback: error rate / latency が閾値超で自動復旧。
header-based routing で内部 dogfood: 特定ヘッダ付きリクエストのみ v2 へ — 社員トラフィックで先に検証。

11.4 可観測性 — golden signals

mesh が自動キャプチャする 4 つ:

トラフィック: RPS、bytes/sec
エラー: 5xx 比率、gRPC error code
レイテンシ: p50、p95、p99
飽和: キュー長、コネクションプール

ダッシュボード:

Istio: Kiali(サービスグラフ) + Grafana(メトリクス) + Jaeger/Tempo(トレース)。
Linkerd: 自前 viz extension(軽量)。
Cilium: Hubble UI(eBPF ベース、非常に豊富)。

運用 Tips:

trace sampling は 1-5%: 100% はバックエンド(Tempo/Jaeger)負荷大。
メトリクス cardinality 管理: pod label をそのままメトリクスに載せない(Prometheus 爆発)。
サービスグラフは発見用: 平常時は見ない、事故時に最速のツール。

12章 · サイドカー vs ambient vs proxyless 論争

2024-2026年で最も激しかった mesh 論争。一行まとめ:

サイドカー: 成熟しているが重い。
Ambient: コストを下げるが新コンポーネントが増える。
eBPF / proxyless: 最も軽いがカーネル・CNI 依存が強い。

サイドカーの立場(Istio sidecar、Linkerd 2/3)

すべての機能が動く — EnvoyFilter、WASM、telemetry v2。
isolation が強い — ある Pod の mesh 設定が他 Pod に影響しない。
デバッグが直感的 — どの Pod のサイドカーを見ればよいか分かる。
コスト? 「メモリ 100 MB はクラウドインスタンスに比べれば小さい」

Ambient の立場(Istio Ambient)

メモリ・起動時間の大幅減 — Pod 100 個 × 100 MB = 10 GB が消える。
アプリとサイドカーの lifecycle decoupling — サイドカー更新 ≠ アプリ再起動。
L4 / L7 分離 — L7 ポリシーが必要な場所にのみ waypoint。
短所? 「新コンポーネント二つの運用。それでもサイドカーよりまし」

eBPF / proxyless の立場(Cilium)

サイドカー・waypoint・ztunnel すべてなし — ノードカーネルが処理。
L4 mTLS・ポリシーはカーネルで — 最も軽い。
Hubble でサンプリングなしに観察 — 可観測性が豊富。
短所? 「L7 機能は結局 Envoy が必要。カーネル依存が強い」

2026年のコンセンサス(緩やかだが)

新規クラスタ → ambient(Istio)または eBPF(Cilium)。サイドカーは新規には推奨しない。
既存 sidecar クラスタ → 運用チームの余力に応じて段階的に ambient へ。
CNI を新規選定中 → Cilium は強力な候補。Cilium を選んだなら Cilium Service Mesh も自然。
ハイブリッド(VM + K8s) → Consul Connect または Kuma。

論争は終わっていない。ただしサイドカー only の時代は終わった。

13章 · 韓国 / 日本の事例 — Toss、Kakao、メルカリ、サイボウズ

Toss — Istio + 段階的 ambient 実験

Toss は決済・証券・銀行を一つの K8s で運用。セキュリティ・監査要件で mTLS は必須で、Istio sidecar で開始。2024-2025年から ambient mode を新規クラスタに限り導入、段階的に sidecar クラスタを移行中。

中核の選定理由:

金融監査要件: mTLS、監査ログ、RBAC を mesh で一元化。
multi-cluster 可視性: Kiali + Grafana + Tempo 組み合わせ。
新規は ambient: Pod メモリ削減効果が千単位 Pod 運用で大きい。

Kakao — Istio + 自前 control plane ツール

Kakao は大規模マイクロサービスインフラに Istio sidecar ベース。自前 control plane ツール(VirtualService・DestinationRule をより安全に管理する GitOps レイヤー)を作り、運用チームと開発チームのポリシー変更の摩擦を減らした。

中核パターン:

canary は自前 progressive delivery ツールで: Argo Rollouts ベース。
mTLS は STRICT、RBAC は default-deny。
trace sampling は 1%、error trace は 100%。

メルカリ(日本) — Istio + Cloud Run/GKE ハイブリッド

メルカリは GKE ベース Istio sidecar で開始。一部ワークロードを Cloud Run に移すにつれ mesh 外部呼び出しが増え、ingress/egress gateway パターン で外部統合をきれいに整理した。

技術ブログ公開事例:

mTLS をすべての service-to-service で義務化。
Backstage + Istio CRD 統合でポリシー変更を PR ベースワークフローに。
gRPC + Envoy gRPC-Web filter — フロントエンド統合。

サイボウズ(日本) — Linkerd 2/3 採用、軽量優先

サイボウズ(kintone など)は OSS フレンドリーなエンジニアリング文化で有名。Linkerd を選んだ理由はシンプルさ。Istio の複雑さを引き受けるより、Linkerd の軽い運用パターンを好む。

2024年の Buoyant 有料化発表後に再評価したが、edge channel + 一部 community ビルドで運用を維持する方向 を検討中という後談(公式発表なし — コミュニティ推測)。

14章 · 誰が何を選ぶべきか — 決定木

Q1. mesh が本当に必要か?
├── いいえ(mTLS のみ必要) → cert-manager + アプリライブラリ mTLS / SPIFFE/SPIRE 直接
├── いいえ(trace のみ必要) → OTel SDK + Tempo/Jaeger
└── はい → 次へ

Q2. 環境は?
├── 純 K8s、単一クラスタ
│   ├── 新規 → Istio Ambient or Cilium Service Mesh
│   └── 既存 sidecar → 段階移行
├── 純 K8s、多クラスタ
│   ├── OSS のみ → Cilium ClusterMesh or Kuma
│   └── エンタープライズ支援必要 → Gloo Mesh(solo.io)
├── ハイブリッド(VM + K8s)
│   └── Consul Connect or Kuma(Universal mode)
└── 非常に小さなクラスタ、単純ポリシー
    └── Traefik Mesh

Q3. チーム余力は?
├── 運用人員が少ない → Linkerd 3(軽量、有料許容可なら)or Traefik Mesh
├── 運用人員が多い → Istio Ambient(フル機能)
└── eBPF 経験あり → Cilium Service Mesh

Q4. CNI は?
├── Cilium 使用中 → Cilium Service Mesh が自然
├── Calico/その他 → Istio Ambient / Linkerd
└── クラウドデフォルト CNI → それが互換するか先に確認

一行推奨(2026年5月基準):

一般新規 K8s: Istio Ambient または Cilium Service Mesh。
小さなチーム、シンプルさ優先: Linkerd 3(有料許容可なら)または Traefik Mesh。
ハイブリッド(VM + K8s): Consul Connect または Kuma。
多クラスタエンタープライズ: Gloo Mesh。

最も重要なメタ推奨: mesh を入れる前に、mesh なしで生きられないかもう一度問え。本当に mesh が必要なチームは思ったより少ない。

参考 / References

Istio Ambient Mode — https://istio.io/latest/docs/ops/ambient/
Istio 1.22 Release Notes(Ambient GA) — https://istio.io/latest/news/releases/1.22.x/announcing-1.22/
Linkerd by Buoyant — https://linkerd.io/
Buoyant stable release policy change(2024) — https://buoyant.io/blog/changes-to-stable-distribution
Cilium Service Mesh — https://cilium.io/use-cases/service-mesh/
Isovalent acquired by Cisco(2024) — https://www.isovalent.com/blog/post/welcome-isovalent-cisco/
HashiCorp + IBM(2024) — https://www.hashicorp.com/blog/hashicorp-joins-ibm
Consul Connect — https://developer.hashicorp.com/consul/docs/connect
Kuma — https://kuma.io/
Gloo Mesh(solo.io) — https://www.solo.io/products/gloo-mesh/
Traefik Mesh — https://traefik.io/traefik-mesh/
Open Service Mesh sunset announcement — https://github.com/openservicemesh/osm
AWS App Mesh end-of-support — https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html
CNCF Service Mesh Landscape — https://landscape.cncf.io/?group=projects-and-products&view-mode=card#orchestration-management--service-mesh
Envoy Proxy — https://www.envoyproxy.io/
SPIFFE/SPIRE — https://spiffe.io/
Service Mesh Interface(SMI) — https://smi-spec.io/
メルカリ Tech Blog — https://engineering.mercari.com/
サイボウズ Tech Blog — https://blog.cybozu.io/