LabHub

ブログ

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

2026-05-16 · 29 分で読めます · #service-mesh#istio#linkerd#cilium#consul#kuma#gloo-mesh#traefik-mesh#sidecar#ambient#ztunnel#waypoint#mtls#envoy#deep-dive#japanese

한국어English日本語

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

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

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

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

  1. サイドカーモデル — 従来 Istio、Linkerd 2/3、Consul Connect のデフォルト。
  2. Ambient モデル(L4 + L7 分離) — Istio Ambient(ztunnel + waypoint)、Linkerd の一部パターン。
  3. 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 AmbientL4 + L7 分離CNCF1.22 GA(2024)。採用加速。
Linkerd 2サイドカー(Rust micro-proxy)Buoyant軽量。メンテモード。
Linkerd 3サイドカー + 一部 ambient パターンBuoyant(paid edition 導入)コミュニティ論争。
Cilium Service MesheBPF + Envoy オプションCisco(Isovalent 買収)急成長。
Consul Connectサイドカー(Envoy)IBM(HashiCorp 買収)ガバナンス不透明。
Kumaサイドカー / multi-zoneKong / CNCF(Sandbox)federated mesh が強い。
Gloo MeshIstio 上の multi-clustersolo.io(商用)エンタープライズ標準。
Traefik MeshDaemonSet プロキシTraefik Labs軽量 / シンプル。
Open Service MeshサイドカーMicrosoft(sunset 2024-01)終了。
AWS App Meshサイドカー(Envoy)AWS(sunset 2024-10)終了。

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

三モデルは 異なるトレードオフ を持つ。サイドカーは「成熟しているが重い」、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)

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

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

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

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

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

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

短所も健在:

いつ sidecar Istio が正解か?

推奨: 新規は 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 ライセンスが必要になった。

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

Linkerd 3 の技術変更:

2026年現在の視点:

選定基準:

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 のモデル:

なぜ eBPF mesh が魅力的か?

現実的な制約:

2026年時点の推奨:

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 の強み(健在):

弱み・懸念:

いつ Consul Connect が正解か?

いつ避けるか?

7章 · Kuma(Kong) — federated mesh

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

Kuma のアーキテクチャ:

他 mesh 比の強み:

弱み:

いつ 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 が中核な場所。金融・通信・一部ビッグテック SRE 組織。

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

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

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

長所:

短所:

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

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

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

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

OSM の終了が示すこと:

App Mesh の終了が示すこと:

全体の教訓:

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

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

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

11.1 mTLS — 最も多い導入理由

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

運用 Tips:

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:

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:

11.4 可観測性 — golden signals

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

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

ダッシュボード:

運用 Tips:

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

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

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

Ambient の立場(Istio Ambient)

eBPF / proxyless の立場(Cilium)

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

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

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

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

Toss — Istio + 段階的 ambient 実験

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

中核の選定理由:

Kakao — Istio + 自前 control plane ツール

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

中核パターン:

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

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

技術ブログ公開事例:

サイボウズ(日本) — 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月基準):

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

参考 / References

原文を読む: https://www.youngju.dev/blog/culture/2026-05-16-service-mesh-2026-istio-ambient-linkerd-3-cilium-mesh-consul-connect-deep-dive.ja

コメント

まだコメントはありません。

ログインするとコメントできます