Service Mesh ソリューション比較

最終更新: February 19, 2026 比較対象: Istio 1.24, Linkerd 2.15, Kong Mesh 2.8, Consul Connect 1.19

このドキュメントでは、Kubernetes 環境で利用可能な主要な Service Mesh ソリューションを包括的に比較します。

概要とアーキテクチャ

Service Mesh とは？

Service Mesh は、マイクロサービス間の通信を管理するインフラストラクチャレイヤーです。アプリケーションコードを変更せずに、トラフィック管理、セキュリティ、可観測性の機能を提供します。

Service Mesh の基本概念

アーキテクチャパターンの比較

詳細アーキテクチャ

Istio

機能:

Proxy: Envoy (C++)
アーキテクチャ: 統合 Control Plane (Istiod)
設定: Kubernetes CRD (VirtualService, DestinationRule など)
強み: 最も豊富な機能、大規模エンタープライズのサポート
弱み: 学習曲線が急、リソースオーバーヘッドが大きい

主要コンポーネント:

Istiod: Pilot + Citadel + Galley の統合
Envoy Proxy: Data Plane
Ingress/Egress Gateway: クラスター境界のトラフィック制御

Linkerd

機能:

Proxy: Linkerd2-proxy (Rust、カスタムビルド)
アーキテクチャ: マイクロサービス Control Plane
設定: Kubernetes ネイティブリソース + シンプルな Annotation
強み: 超軽量、インストールと運用が容易、高速なパフォーマンス
弱み: 機能が限定的、VM サポートなし

主要コンポーネント:

Destination: Service Discovery とルーティングポリシー
Identity: mTLS 証明書の自動発行
Proxy Injector: Sidecar の自動注入

Kong Mesh

機能:

Proxy: Envoy (Kuma Data Plane)
アーキテクチャ: Universal Control Plane (K8s + VM)
設定: Kuma CRD + Kong Mesh UI
強み: 優れた VM サポート、マルチゾーン/マルチクラウド、エンタープライズ機能
弱み: 商用機能は有料、コミュニティが比較的小さい

主要コンポーネント:

Global Control Plane: マルチゾーンポリシーの同期
Zone Control Plane: ローカル Data Plane の管理
Kuma DP: Kubernetes と VM 向けの Data Plane

Kong Mesh の詳細アーキテクチャ

Kong Mesh は Kuma をベースとする Universal Service Mesh であり、マルチゾーンアーキテクチャにより複数のクラスターと環境を単一の Mesh に統合します。

マルチゾーンデプロイメントアーキテクチャ

主な機能:

Global Control Plane: すべてのゾーンのポリシーを一元管理
Zone Control Plane: 各ゾーンの Data Plane を独立して管理
自動 Service Discovery: ゾーン間での Service Discovery を自動化
統合 mTLS: ゾーン間通信も自動的に暗号化

サービス接続とトラフィックフロー

ポリシー伝播のメカニズム

タイプ別のポリシー伝播スコープ:

ポリシータイプ	スコープ	伝播方法	ユースケース
Mesh	Global	すべてのゾーン	グローバル mTLS 設定
TrafficRoute	Global	すべてのゾーン	グローバルルーティングルール
TrafficPermission	Global	すべてのゾーン	サービス間アクセス制御
HealthCheck	Zone	ローカルゾーンのみ	ゾーン固有のヘルスチェック
ProxyTemplate	Zone	ローカルゾーンのみ	ゾーン固有の Envoy 設定

Data Plane のライフサイクル

ゾーン間 Service Discovery

Service Discovery の機能:

自動登録: 各ゾーンの Service は Zone CP に自動登録されます
グローバルビュー: Global CP はすべてのゾーンの Service を統合します
ローカル優先: 同一ゾーン内の Service を優先してルーティングします
自動フェイルオーバー: ローカル Service が失敗すると別のゾーンへ自動的に切り替えます
タグベースルーティング: Service タグを使用したきめ細かなルーティング制御

Kong Mesh の設定例

Mesh リソース（グローバル mTLS 設定）:

yaml

apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
  name: default
spec:
  # Enable global mTLS
  mtls:
    enabledBackend: ca-1
    backends:
    - name: ca-1
      type: builtin
      dpCert:
        rotation:
          expiration: 24h
      conf:
        caCert:
          RSAbits: 2048
          expiration: 10y
  # Global metrics collection
  metrics:
    enabledBackend: prometheus-1
    backends:
    - name: prometheus-1
      type: prometheus
      conf:
        port: 5670
        path: /metrics

TrafficRoute（ゾーン間ルーティング）:

yaml

apiVersion: kuma.io/v1alpha1
kind: TrafficRoute
metadata:
  name: api-route
  namespace: kuma-system
spec:
  sources:
  - match:
      kuma.io/service: '*'
  destinations:
  - match:
      kuma.io/service: api
  conf:
    # Local zone priority (80%)
    loadBalancer:
      roundRobin: {}
    split:
    - weight: 80
      destination:
        kuma.io/service: api
        kuma.io/zone: zone-1
    - weight: 20
      destination:
        kuma.io/service: api
        kuma.io/zone: zone-2

TrafficPermission（サービス間アクセス制御）:

yaml

apiVersion: kuma.io/v1alpha1
kind: TrafficPermission
metadata:
  name: api-to-database
  namespace: kuma-system
spec:
  sources:
  - match:
      kuma.io/service: api
      kuma.io/zone: '*'  # api service from all zones
  destinations:
  - match:
      kuma.io/service: database
      kuma.io/zone: zone-3  # database in Zone 3 only

Kong Mesh アーキテクチャの利点

マルチゾーンアーキテクチャ:

グローバル Service Mesh: 複数のクラスターと環境を単一の Mesh に統合
独立したゾーン管理: 各ゾーンは独立して動作し、Global CP が失敗してもローカルトラフィックは正常に機能します
自動フェイルオーバー: ゾーン障害時に別のゾーンへ自動的に切り替えます
ポリシーの一貫性: 同じポリシーがすべてのゾーンに自動適用されます

ユニバーサルサポート:

Kubernetes + VM: K8s と VM を同等にサポート
マルチクラウド: AWS、GCP、Azure、オンプレミスを統合
レガシー統合: 既存の VM ワークロードを段階的に Mesh に追加

運用の利便性:

GUI 提供: Kong Mesh GUI による視覚的な管理
ポリシーテンプレート: 事前定義済みのポリシーテンプレートを提供
自動 Service Discovery: 手動設定なしで Service を自動検出

エンタープライズ機能（有料）:

RBAC: きめ細かなロールベースのアクセス制御
マルチテナンシー: ゾーンレベルの分離と管理
24/7 サポート: 本番環境向けのプロフェッショナルサポート
高度な可観測性: 詳細なメトリクスとトレーシング

Consul Connect

機能:

Proxy: Envoy または Built-in Proxy
アーキテクチャ: Consul Server Cluster + Consul Client
設定: HCL または Kubernetes CRD
強み: 強力な Service Discovery、VM ファーストの設計、マルチデータセンター
弱み: Consul インフラストラクチャの管理が必要、Kubernetes 統合は Istio より複雑

主要コンポーネント:

Consul Server: Service Catalog、KV Store、証明書管理
Consul Client: 各ノードで実行、Service 登録
Envoy Sidecar: トラフィック Proxy

パフォーマンス比較

レイテンシーオーバーヘッド

ベンチマーク結果（P99 レイテンシーの増加、1000 RPS）:

Service Mesh	P50	P95	P99	CPU 使用率	メモリ使用量
Baseline	0.1ms	0.2ms	0.3ms	-	-
Linkerd	+0.5ms	+0.8ms	+1.2ms	+3-8%	+20-50MB
Istio	+1.0ms	+2.5ms	+3.5ms	+5-15%	+50-150MB
Kong Mesh	+0.8ms	+2.0ms	+3.0ms	+5-12%	+40-120MB
Consul Connect	+1.0ms	+2.5ms	+3.5ms	+6-14%	+50-140MB

テスト環境: 3 ノード EKS 1.28、m5.xlarge、100 Service、1000 RPS

リソース使用量の比較

Control Plane リソース

コンポーネント	Istio	Linkerd	Kong Mesh	Consul Connect
CPU	500m-1	100m-300m	200m-500m	500m-1
メモリ	1-2GB	200-500MB	500MB-1GB	1-2GB
レプリカ数	1 (Istiod)	3-5 (マイクロサービス)	1-2 (Zone CP)	3-5 (Consul Server)

Data Plane リソース（Pod ごと）

Proxy	Istio Envoy	Linkerd2-proxy	Kuma DP	Consul Envoy
CPU	100-500m	20-100m	100-400m	100-500m
メモリ	50-150MB	20-50MB	40-120MB	50-140MB

スループットの比較

最大 RPS（Requests Per Second）:

結論:

Linkerd: 最小のオーバーヘッド、軽量な Proxy
Istio/Consul: 機能が多いため、オーバーヘッドはやや大きい
Kong Mesh: 中程度のパフォーマンスレベル

機能比較

総合機能比較表

機能領域	Istio	Linkerd	Kong Mesh	Consul Connect
トラフィック管理
トラフィック分割（Canary）	きめ細かい	基本	きめ細かい	基本
A/B テスト	Header ベース	限定的	Header ベース	限定的
Blue-Green	はい	はい	はい	はい
トラフィックミラーリング	はい	いいえ	はい	Enterprise
Circuit Breaking	はい	基本	はい	はい
Retry	きめ細かい	基本	きめ細かい	基本
Timeout	はい	はい	はい	はい
Fault Injection	はい	限定的	はい	限定的
セキュリティ
mTLS 自動化	はい	はい	はい	はい
Authorization Policy	非常にきめ細かい	基本	きめ細かい	Intentions
外部 CA 統合	はい	はい	はい	はい
JWT 認証	はい	限定的	はい	はい
Rate Limiting	EnvoyFilter	いいえ	はい	Enterprise
可観測性
メトリクス（Prometheus）	豊富	基本	豊富	基本
分散トレーシング	すべてのバックエンド	Jaeger	すべてのバックエンド	Jaeger/Zipkin
Access Log	非常に詳細	基本	詳細	基本
トポロジーの可視化	Kiali	Dashboard	GUI	UI
OpenTelemetry	はい	はい	はい	はい
プラットフォームサポート
Kubernetes	はい	はい	はい	はい
Virtual Machine	限定的	いいえ	優れている	優れている
マルチクラスター	優れている	サポート対象	優れている	優れている
Service Discovery	はい	はい	はい	非常に強力
運用
インストールの複雑さ	高い	低い	中程度	中程度
アップグレード	中程度	容易	中程度	中程度
トラブルシューティング	困難	容易	中程度	中程度
CLI ツール	istioctl	linkerd	kumactl	consul

凡例:

はい = 完全にサポート
限定的 = サポートが限定的、または Enterprise 機能
いいえ = サポートされていない

トラフィック管理の詳細比較

Canary Deployment の例

Istio:

yaml

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        user-agent:
          regex: ".*Mobile.*"
    route:
    - destination:
        host: reviews
        subset: v2
      weight: 100
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Linkerd:

yaml

apiVersion: split.smi-spec.io/v1alpha2
kind: TrafficSplit
metadata:
  name: reviews-split
spec:
  service: reviews
  backends:
  - service: reviews-v1
    weight: 90
  - service: reviews-v2
    weight: 10
---
# Requires separate Service creation
apiVersion: v1
kind: Service
metadata:
  name: reviews-v1
spec:
  selector:
    app: reviews
    version: v1
---
apiVersion: v1
kind: Service
metadata:
  name: reviews-v2
spec:
  selector:
    app: reviews
    version: v2

Kong Mesh:

yaml

apiVersion: kuma.io/v1alpha1
kind: TrafficRoute
metadata:
  name: reviews-route
spec:
  sources:
  - match:
      kuma.io/service: '*'
  destinations:
  - match:
      kuma.io/service: reviews
  conf:
    split:
    - weight: 90
      destination:
        kuma.io/service: reviews
        version: v1
    - weight: 10
      destination:
        kuma.io/service: reviews
        version: v2

Consul Connect:

hcl

Kind = "service-splitter"
Name = "reviews"
Splits = [
  {
    Weight        = 90
    ServiceSubset = "v1"
  },
  {
    Weight        = 10
    ServiceSubset = "v2"
  },
]

比較:

Istio: 最もきめ細かな制御（Header ベースのルーティング、さまざまなマッチ条件）
Linkerd: シンプルですが、個別の Service 作成が必要
Kong Mesh: Kuma CRD、直感的
Consul: HCL 設定、Service Discovery と統合

セキュリティ機能

mTLS 設定の比較

Istio:

yaml

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: default
  namespace: istio-system
spec:
  host: "*.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

Linkerd:

bash

# mTLS enabled automatically (no configuration needed)
linkerd install | kubectl apply -f -

# Add annotation to namespace
kubectl annotate namespace default linkerd.io/inject=enabled

Kong Mesh:

yaml

apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
  name: default
spec:
  mtls:
    enabledBackend: ca-1
    backends:
    - name: ca-1
      type: builtin
      dpCert:
        rotation:
          expiration: 24h
      conf:
        caCert:
          RSAbits: 2048
          expiration: 10y

Consul Connect:

hcl

Kind = "mesh"
Meta = {
  "consul.hashicorp.com/gateway-kind" = "mesh-gateway"
}
TLS {
  Incoming {
    TLSMinVersion = "TLSv1_2"
  }
}

Authorization Policy の比較

Istio（最もきめ細かい）:

yaml

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: reviews-policy
spec:
  selector:
    matchLabels:
      app: reviews
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/productpage"]
    to:
    - operation:
        methods: ["GET"]
        paths: ["/reviews/*"]
    when:
    - key: request.headers[user-agent]
      values: ["*Mobile*"]

Linkerd:

yaml

apiVersion: policy.linkerd.io/v1beta1
kind: Server
metadata:
  name: reviews-server
spec:
  podSelector:
    matchLabels:
      app: reviews
  port: 9080
  proxyProtocol: HTTP/1
---
apiVersion: policy.linkerd.io/v1alpha1
kind: AuthorizationPolicy
metadata:
  name: reviews-policy
spec:
  targetRef:
    kind: Server
    name: reviews-server
  requiredAuthenticationRefs:
  - kind: ServiceAccount
    name: productpage

Kong Mesh:

yaml

apiVersion: kuma.io/v1alpha1
kind: TrafficPermission
metadata:
  name: reviews-permission
spec:
  sources:
  - match:
      kuma.io/service: productpage
  destinations:
  - match:
      kuma.io/service: reviews

Consul Connect（Intentions）:

hcl

Kind = "service-intentions"
Name = "reviews"
Sources = [
  {
    Name   = "productpage"
    Action = "allow"
  }
]

比較:

Istio: 非常にきめ細かな L7 制御（Method、Path、Header）
Linkerd: Service Account ベース、シンプル
Kong Mesh: Service レベルの権限
Consul: Intentions ベース、直感的

可観測性機能

メトリクス収集

Istio:

メトリクス数: デフォルトで 50 以上のメトリクス
カスタマイズ: EnvoyFilter による無制限の拡張
統合: Prometheus、Grafana、Kiali

Linkerd:

メトリクス数: デフォルトで 20 以上のメトリクス（ゴールデンシグナルに注力）
カスタマイズ: 限定的
統合: Prometheus、Grafana、Linkerd Dashboard

Kong Mesh:

メトリクス数: デフォルトで 40 以上のメトリクス
カスタマイズ: Datadog、Prometheus
統合: Kong Mesh GUI、Grafana

Consul Connect:

メトリクス数: デフォルトで 30 以上のメトリクス
カスタマイズ: Telegraf 統合
統合: Consul UI、Prometheus、Grafana

分散トレーシング

サポートされるバックエンド:

Service Mesh	Jaeger	Zipkin	Tempo	Datadog	AWS X-Ray
Istio	はい	はい	はい	はい	はい
Linkerd	はい	はい	はい	限定的	限定的
Kong Mesh	はい	はい	はい	はい	はい
Consul	はい	はい	限定的	限定的	限定的

可視化ツール

Istio + Kiali:

yaml

apiVersion: kiali.io/v1alpha1
kind: Kiali
metadata:
  name: kiali
spec:
  deployment:
    accessible_namespaces: ["**"]
  external_services:
    prometheus:
      url: http://prometheus:9090
    grafana:
      url: http://grafana:3000
    tracing:
      url: http://jaeger-query:16686

Linkerd Dashboard:

bash

linkerd viz install | kubectl apply -f -
linkerd viz dashboard

Kong Mesh GUI:

yaml

apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
  name: default
spec:
  metrics:
    enabledBackend: prometheus-1
    backends:
    - name: prometheus-1
      type: prometheus

Consul UI:

hcl

ui_config {
  enabled = true
  metrics_provider = "prometheus"
  metrics_proxy {
    base_url = "http://prometheus:9090"
  }
}

マルチクラスターサポート

アーキテクチャ比較

Istio Multi-Primary:

Linkerd Multi-cluster:

Kong Mesh Multi-zone:

Consul Multi-datacenter:

マルチクラスター機能の比較

機能	Istio	Linkerd	Kong Mesh	Consul
設定の複雑さ	中程度	低い	中程度	中程度
Service Discovery	自動	Mirror Service	自動	強力
トラフィックフェイルオーバー	自動	手動	自動	自動
mTLS	自動	Gateway 経由	自動	自動
ネットワーク要件	Flat または Gateway	Gateway	Flat または Gateway	Gateway
ポリシー同期	はい	限定的	Global CP	はい
最大クラスター数	数十個	~10	数十個	数十個

運用の複雑さ

インストールとアップグレード

Istio:

bash

# Install
istioctl install --set profile=default

# Upgrade (Canary)
istioctl install --set profile=default --revision=1-24-0

# Sequential transition per namespace
kubectl label namespace default istio.io/rev=1-24-0 --overwrite
kubectl rollout restart deployment -n default

Linkerd:

bash

# Install
linkerd install | kubectl apply -f -

# Upgrade (In-place)
linkerd upgrade | kubectl apply -f -

# Automatic rollout

Kong Mesh:

bash

# Helm install
helm install kong-mesh kong-mesh/kong-mesh

# Upgrade
helm upgrade kong-mesh kong-mesh/kong-mesh

Consul:

bash

# Helm install
helm install consul hashicorp/consul -f values.yaml

# Upgrade
helm upgrade consul hashicorp/consul -f values.yaml

比較:

Linkerd: 最も簡単なインストールとアップグレード
Istio: Canary アップグレードによりダウンタイムなしを実現できますが、複雑です
Kong/Consul: Helm ベース、中程度の複雑さ

トラブルシューティングツール

Istio:

bash

# Check proxy status
istioctl proxy-status

# Validate configuration
istioctl analyze

# Check proxy configuration
istioctl proxy-config cluster <pod> -n <namespace>

# Change log level
istioctl proxy-config log <pod> --level debug

Linkerd:

bash

# Check status
linkerd check

# Check statistics
linkerd stat deploy

# Tap (real-time traffic observation)
linkerd tap deploy/webapp

# Check profile
linkerd profile --template deploy/webapp

Kong Mesh:

bash

# Check status
kumactl inspect dataplanes

# Check metrics
kumactl inspect meshes

# Check logs
kubectl logs -n kong-mesh-system deployment/kong-mesh-control-plane

Consul:

bash

# Check status
consul members

# Check services
consul catalog services

# Check intentions
consul intention list

# Proxy logs
kubectl logs <pod> -c consul-connect-envoy-sidecar

学習曲線

コスト分析

インフラストラクチャコスト

リソースベースのコスト計算（100 Pod 環境、EKS m5.xlarge）:

Service Mesh	Control Plane CPU	Control Plane メモリ	Data Plane CPU（合計）	Data Plane メモリ（合計）	月額コスト（概算）
Baseline	-	-	-	-	$300
Linkerd	300m	500MB	2 vCPU	5GB	+$50 (~$350)
Istio	1 vCPU	2GB	10 vCPU	15GB	+$150 (~$450)
Kong Mesh	500m	1GB	8 vCPU	12GB	+$120 (~$420)
Consul	1 vCPU	2GB	10 vCPU	14GB	+$145 (~$445)

注記: 実際のコストは、ワークロードパターン、トラフィック量、設定によって大きく異なる場合があります。

運用コスト

エンジニアの工数（月次）:

タスク	Istio	Linkerd	Kong Mesh	Consul
初期セットアップ	40h	8h	20h	24h
日次運用	20h/month	5h/month	10h/month	12h/month
トラブルシューティング	15h/month	3h/month	8h/month	10h/month
アップグレード	8h/quarter	2h/quarter	4h/quarter	5h/quarter

ライセンスコスト

製品	オープンソース	Enterprise
Istio	無料（Apache 2.0）	Google Cloud Service Mesh（使用量ベース）
Linkerd	無料（Apache 2.0）	Buoyant Enterprise ($$$)
Kong Mesh	Kuma Open Source	Kong Mesh Enterprise（要問い合わせ）
Consul	無料（MPL 2.0）	Consul Enterprise ($$$)

Enterprise 機能の例:

Kong Mesh Enterprise: マルチゾーン GUI、RBAC、24/7 サポート
Consul Enterprise: 監査ログ、Namespace、冗長化ゾーン
Buoyant Enterprise: HA Control Plane、24/7 サポート、SLA

ユースケースの推奨事項

1. 大規模エンタープライズ（1000 以上の Service）

推奨: Istio

理由:

最も豊富な機能セット
きめ細かなトラフィック制御（A/B テスト、Canary）
強力なセキュリティ（L7 Authorization）
マルチクラスター連携
広範なコミュニティとツールエコシステム

設定例:

yaml

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  profile: production
  components:
    pilot:
      k8s:
        hpaSpec:
          minReplicas: 3
          maxReplicas: 10
        resources:
          requests:
            cpu: 2000m
            memory: 4Gi

2. 小規模から中規模のスタートアップ（10～100 Service）

推奨: Linkerd

理由:

短時間でのインストール（5 分未満）
低いリソースオーバーヘッド
シンプルな運用
自動 mTLS とメトリクス

設定例:

bash

linkerd install | kubectl apply -f -
linkerd viz install | kubectl apply -f -

# Enable per namespace
kubectl annotate namespace default linkerd.io/inject=enabled

3. ハイブリッドクラウド（K8s + VM）

推奨: Consul Connect または Kong Mesh

理由:

VM ワークロードを優先するサポート
強力な Service Discovery
マルチプラットフォームでの一貫性

Consul の設定例:

hcl

# In Kubernetes
service {
  name = "web"
  port = 8080
  connect {
    sidecar_service {}
  }
}

# In VM
service {
  name = "database"
  port = 5432
  connect {
    sidecar_service {
      proxy {
        upstreams = [
          {
            destination_name = "web"
            local_bind_port  = 8080
          }
        ]
      }
    }
  }
}

4. マルチクラウド戦略

推奨: Istio または Kong Mesh

理由:

クラウド中立
一貫したポリシーと可観測性
マルチクラスター連携

Istio マルチクラスター:

bash

# Cluster 1 (AWS)
istioctl install --set values.global.meshID=mesh1 \
  --set values.global.multiCluster.clusterName=aws-cluster \
  --set values.global.network=aws-network

# Cluster 2 (GCP)
istioctl install --set values.global.meshID=mesh1 \
  --set values.global.multiCluster.clusterName=gcp-cluster \
  --set values.global.network=gcp-network

# Share Service Discovery
istioctl create-remote-secret \
  --context=aws-cluster --name=aws-cluster | \
  kubectl apply -f - --context=gcp-cluster

5. レガシー移行

推奨: Kong Mesh または Consul

理由:

VM とコンテナを同時にサポート
段階的な移行
既存の Service Discovery との統合

Kong Mesh ハイブリッド:

yaml

# Kubernetes Service
apiVersion: v1
kind: Service
metadata:
  name: legacy-db
  annotations:
    kuma.io/mesh: default
spec:
  type: ExternalName
  externalName: legacy-db.vm.local
---
# Run Kuma DP on VM
kuma-dp run \
  --cp-address=https://kong-mesh-cp:5678 \
  --dataplane-token-file=/tmp/token \
  --dataplane-file=/etc/kuma/dataplane.yaml

6. 強力な可観測性要件

推奨: Istio

理由:

デフォルトで 50 以上のメトリクス
詳細な Access Log
すべてのトレーシングバックエンドをサポート
Kiali 統合

可観測性スタック:

yaml

# Prometheus + Grafana + Jaeger + Kiali
istioctl install --set profile=demo \
  --set values.prometheus.enabled=true \
  --set values.grafana.enabled=true \
  --set values.tracing.enabled=true \
  --set values.kiali.enabled=true

最終結論と推奨事項

決定木

クイック推奨ガイド

状況	第 1 選択	第 2 選択	避けるべき選択
導入開始時	Linkerd	Kong Mesh	Istio（複雑）
大規模エンタープライズ	Istio	Kong Mesh	Linkerd（機能が限定的）
リソース制約	Linkerd	-	Istio（オーバーヘッド）
VM ワークロード	Consul	Kong Mesh	Linkerd（サポートなし）
マルチクラウド	Istio	Consul	単一クラウドソリューション
迅速な ROI	Linkerd	-	Istio（学習曲線）
きめ細かな制御	Istio	Kong Mesh	Linkerd（限定的）

最終推奨事項

Istio:

使用する場面: 大規模エンタープライズ、豊富な機能が必要、チームに Service Mesh の経験がある場合
長所: クラス最高の機能、強力なコミュニティ、将来志向
短所: 学習曲線が急、リソース使用量が多い

Linkerd:

使用する場面: シンプルさを最優先、小規模チーム、迅速な開始、リソース効率
長所: インストール/運用がシンプル、低オーバーヘッド、自動 mTLS
短所: 機能が限定的、VM サポートなし

Kong Mesh / Consul Connect:

使用する場面: ハイブリッド環境（K8s + VM）、マルチプラットフォーム、レガシー統合
長所: VM ファーストのサポート、柔軟なアーキテクチャ、強力な Service Discovery
短所: 商用機能は有料、コミュニティ規模

次のステップ:

PoC 環境で 2～3 のソリューションをテストする
実際のワークロードパターンでパフォーマンスベンチマークを実施する
チームのフィードバックを収集する
本番ロールアウト計画を策定する

関連ドキュメント:

エンドツーエンドのオブザーバビリティラボ

ArgoCD の詳細クイズ

Istio の詳細クイズ

Linkerd の詳細クイズ

Cilium サービスメッシュの詳細クイズ

Cilium 詳説

Calico 詳説

メトリクス

ログ記録

トレーシング

アラート通知

可観測性の演習

ArgoCD

トラフィック管理

セキュリティ

可観測性

レジリエンス

高度な設定

比較ガイド

メトリクス

ログ記録

トレーシング

アラート通知

Service Mesh ソリューション比較 ​

目次 ​

概要とアーキテクチャ ​

Service Mesh とは？ ​

Service Mesh の基本概念 ​

アーキテクチャパターンの比較 ​

詳細アーキテクチャ ​

Istio ​

Linkerd ​

Kong Mesh ​

Kong Mesh の詳細アーキテクチャ ​

Consul Connect ​

パフォーマンス比較 ​

レイテンシーオーバーヘッド ​

リソース使用量の比較 ​

Control Plane リソース ​

Data Plane リソース（Pod ごと） ​

スループットの比較 ​

機能比較 ​

総合機能比較表 ​

トラフィック管理の詳細比較 ​

Canary Deployment の例 ​

セキュリティ機能 ​

mTLS 設定の比較 ​

Authorization Policy の比較 ​

可観測性機能 ​

メトリクス収集 ​

分散トレーシング ​

可視化ツール ​

マルチクラスターサポート ​

アーキテクチャ比較 ​

マルチクラスター機能の比較 ​

運用の複雑さ ​

インストールとアップグレード ​

トラブルシューティングツール ​

学習曲線 ​

コスト分析 ​

インフラストラクチャコスト ​

運用コスト ​

ライセンスコスト ​

ユースケースの推奨事項 ​

1. 大規模エンタープライズ（1000 以上の Service） ​

2. 小規模から中規模のスタートアップ（10～100 Service） ​

3. ハイブリッドクラウド（K8s + VM） ​

4. マルチクラウド戦略 ​

5. レガシー移行 ​

6. 強力な可観測性要件 ​

最終結論と推奨事項 ​

決定木 ​

クイック推奨ガイド ​

最終推奨事項 ​

Service Mesh ソリューション比較

目次

概要とアーキテクチャ

Service Mesh とは？

Service Mesh の基本概念

アーキテクチャパターンの比較

詳細アーキテクチャ

Istio

Linkerd

Kong Mesh

Kong Mesh の詳細アーキテクチャ

Consul Connect

パフォーマンス比較

レイテンシーオーバーヘッド

リソース使用量の比較

Control Plane リソース

Data Plane リソース（Pod ごと）

スループットの比較

機能比較

総合機能比較表

トラフィック管理の詳細比較

Canary Deployment の例

セキュリティ機能

mTLS 設定の比較

Authorization Policy の比較

可観測性機能

メトリクス収集

分散トレーシング

可視化ツール

マルチクラスターサポート

アーキテクチャ比較

マルチクラスター機能の比較

運用の複雑さ

インストールとアップグレード

トラブルシューティングツール

学習曲線

コスト分析

インフラストラクチャコスト

運用コスト

ライセンスコスト

ユースケースの推奨事項

1. 大規模エンタープライズ（1000 以上の Service）

2. 小規模から中規模のスタートアップ（10～100 Service）

3. ハイブリッドクラウド（K8s + VM）

4. マルチクラウド戦略

5. レガシー移行

6. 強力な可観測性要件

最終結論と推奨事項

決定木

クイック推奨ガイド

最終推奨事項