サービスメッシュの担う責務＠サービスメッシュ¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. サービスメッシュの担う責務¶
サービスメッシュを採用しない場合 (Kubernetes のみ) と比較して、各サービスメッシュツールがインフラ領域のどんな責務を実装してくれるかを記載する。
もしサービスメッシュを採用しない場合、サービスメッシュと同じ責務をマイクロサービス領域に実装する必要がある。
サービスメッシュの責務が要件として必要であるなら、以下の理由からサービスメッシュツールの採用も検討したほうがよい。
- マイクロサービス側にインフラ領域の責務を実装しなくて済むため、アプリエンジニアの負担が減る。
- インフラ領域の責務をサイドカーに切り分けられるため、凝集度が高くなる
- 各マイクロサービスに共通して提供できるため、単純性が高くなる
一方で要件として不要ならば、サービスメッシュツール自体を採用する必要はない、という判断になる。
01-02. ツール¶
- Istio
- Linkerd
- Consul
- Amazon VPC Lattice
- Amazon ECS Service Connect
02. 概要¶
| クラウドネイティブ技術 (アルファベット順) | Cilium Service Mesh | Consul | Istio | Kong Mesh | Kuma | Linkerd | NGINX Service Mesh | Traefik Mesh |
|---|---|---|---|---|---|---|---|---|
| アーキテクチャモード | サイドカーレス | サイドカー | サイドカー／サイドカーレス | サイドカー／サイドカーレス | サイドカー | サイドカー | サイドカー | サイドカー |
| データプレーン | eBPF、Envoy | Envoy | Envoy、ztunnel | Envoy | Envoy | Linkerd Proxy | NGINX Plus | Traefik |
| CNCF ステータス | Graduated | なし | Graduated | なし | Sandbox | Graduated | なし | なし |
| 開発元 | Isovalent | HashiCorp | Google など | Kong | Kong | Buoyant | Nginx | Traefik Labs |
03. トラフィック管理¶
プロトコル¶
サービスメッシュが扱えるプロトコルは、ツールによって異なる。例えば Istio は HTTP と TCP を処理できるが、UDP には対応していない。また、AMQP などの非対応プロトコルは TCP として処理する。
| 責務 | Kubernetes (サービスメッシュ採用せず) |
Istio | Linkerd | Consul | Amazon VPC Lattice |
|---|---|---|---|---|---|
| TCP | Service + kube-proxy | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
| HTTP/1.1 | Ingress | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
| HTTP/2 (例：gRPC、GraphQL など) | Ingress | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
| gRPC | Ingress、Service + kube-proxy | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
ネットワーク¶
Kubernetes の Service は、配下に新旧バージョンの Pod が混在していても区別せず、同じ Pod 群として扱う。このため、Service だけでは段階的なリリースに必要なバージョン別の厳密なトラフィック制御ができない。
一方で、サービスメッシュツールは異なるバージョンの Pod に、さまざまな手法 (例：カナリア方式、トラフィックミラーリング方式など) で通信できる。
| 責務 | Kubernetes (サービスメッシュ採用せず) |
Istio | Linkerd | Consul | Amazon VPC Lattice |
|---|---|---|---|---|---|
L4 ロードバランシング |
Service + kube-proxy | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
L7 ロードバランシング |
Ingress | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
| ルーティング (ホストベース、パスベース、割合ベース) |
Service + kube-proxy、Ingress | ⭕️ |
× | × | × |
| サービス検出 | Service + kube-proxy | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
| CNI | 記入中... | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
04. 回復性の管理¶
サービスメッシュは、マイクロサービスの回復性を管理する。
| 責務 | Kubernetes (サービスメッシュ採用せず) |
Istio | Linkerd | Consul | Amazon VPC Lattice |
|---|---|---|---|---|---|
| サーキットブレイカー | 記入中... | ⭕️ |
× | ⭕️ |
⭕️ |
| フォールトインジェクション | 記入中... | ⭕️ |
⭕️ |
× | × |
| リトライ処理 | 記入中... | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
| タイムアウト | 記入中... | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
| リクエスト数制限 (レートリミット) |
記入中... | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
05. 通信の認証／認可¶
サービスメッシュは、ゼロトラストネットワークに基づいて、通信にも認証／認可を実施する。
Istio は、JWT の検証によるアカウント認証や、アカウント属性・ワークロード ID に基づく通信の認可を実装できる。ただし、ログインや認証情報の発行などの認証識別処理は、ID プロバイダーやアプリケーション側に実装する必要がある。
| 責務 | Kubernetes (サービスメッシュ採用せず) |
Istio | Linkerd | Consul | Amazon VPC Lattice |
|---|---|---|---|---|---|
| 相互 TLS 認証 | 相互 TLS 認証ツール (例：Spiffe) |
⭕️(Spiffe へ置き換えできる) |
⭕️ |
⭕️ |
⭕️ |
| JWT による Bearer 認証 | アプリで実装、認証プロキシ (例：OAuth2 Proxy など) や SSO プロキシ(例：Dex など) | ⭕️ |
× | ⭕️ |
× |
06. アプリケーションデータの暗号化¶
サービスメッシュは、TLS ハンドシェイクで共有した共通鍵でアプリケーションデータを暗号化する。証明書は通信相手の認証に使用する。
Kubernetes では、Pod の作成に応じて証明書の Kubernetes リソース (Certificate、CertificateSigningRequest など) を作成する必要がある。
| 責務 | Kubernetes (サービスメッシュ採用せず) |
Istio | Linkerd | Consul | Amazon VPC Lattice |
|---|---|---|---|---|---|
| 相互 TLS 認証 | 相互 TLS 認証ツール (例：Spiffe) |
⭕️(Spiffe へ置き換えできる) |
⭕️ |
⭕️ |
⭕️ |
| サーバー証明書の自動更新 | ・手動でサーバー証明書を更新 ・サーバー証明書管理ツール (例：Cert Manager) |
⭕️ |
× | ⭕️ |
⭕️ |
08. テレメトリー管理¶
ログの場合¶
サービスメッシュツールを使用する場合、マイクロサービスの代わりにサイドカープロキシがアクセスログを作成する。ログルーターがアクセスログを収集し、監視バックエンドに送信する。
ただし、マイクロサービスでもアクセスログを作成してもよい。
| 責務 | Kubernetes (サービスメッシュ採用せず) |
Istio | Linkerd | Consul | Amazon VPC Lattice |
|---|---|---|---|---|---|
| マイクロサービスの実行ログを作成する | - | × | × | × | × |
| マイクロサービスの実行ログをログルーター (例：Fluentd、FluentBit) へ送信する |
- | × | × | × | × |
| マイクロサービスのアクセスログを作成する | 各言語のロギングパッケージ | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
| マイクロサービスのアクセスログをログルーター (例：Fluentd、FluentBit) へ送信する |
各言語のロギングパッケージ | × | ⭕️ |
⭕️ |
⭕️ |
メトリクスの場合¶
サービスメッシュツールを使用する場合、マイクロサービスの代わりにサイドカープロキシがメトリクスの元になるデータポイントを作成して公開する。Prometheus などの収集／監視バックエンドがデータポイントを収集する。
| 責務 | Kubernetes (サービスメッシュ採用せず) |
Istio | Linkerd | Consul | Amazon VPC Lattice |
|---|---|---|---|---|---|
| マイクロサービスのゴールデンシグナルを作成する | クライアントパッケージ (例：otel クライアントパッケージなど) |
⭕️ |
⭕️ |
⭕️ |
⭕️ |
| マイクロサービスのゴールデンシグナルを監視バックエンド (例：Prometheus) へ送信する |
クライアントパッケージ (例：otel クライアントパッケージなど) |
× (Prometheus が取得する) |
⭕️ |
⭕️ |
⭕️ |
| マイクロサービスのエンドポイント別にメトリクスをフィルタリングする | 記入中... | ⭕️ |
⭕️ |
⭕️ |
× |
分散トレースの場合¶
サービスメッシュツールを使用する場合、マイクロサービスの代わりにサイドカープロキシがスパンを作成し、OpenTelemetry Collector などの収集エージェントに送信する。
ただし、マイクロサービス間でのトレースコンテキスト伝播は、マイクロサービスに実装する必要がある。
| 責務 | Kubernetes (サービスメッシュ採用せず) |
Istio | Linkerd | Consul | Amazon VPC Lattice |
|---|---|---|---|---|---|
| 分散トレースのスパンを作成する | クライアントパッケージ (例：otel クライアントパッケージなど) |
⭕️ |
⭕️ |
⭕️ |
⭕️ |
| 分散トレースをトレースの Collector (例：OpenTelemetry Collector、Jaeger Collector など) に送信する |
クライアントパッケージ (例：otel クライアントパッケージなど) |
⭕️ |
⭕️ |
⭕️ |
⭕️ |
サービスメッシュトポロジーの場合¶
| 責務 | Kubernetes (サービスメッシュ採用せず) |
Kiali | X-Ray |
|---|---|---|---|
| 必要なメトリクスを取得する | 記入中... | ⭕️ |
⭕️ |
| サービスメッシュトポロジーをモデリングする | 記入中... | ⭕️ |
⭕️ |
| サービスメッシュトポロジーをモデリングする | 記入中... | ⭕️ |
⭕️ |
07. アーキテクチャ¶
サービスメッシュのパターン¶
| 責務 | Istio | Linkerd | Consul | Amazon VPC Lattice | Cilium |
|---|---|---|---|---|---|
| サイドカーパターン | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
× |
| サイドカーレスパターン | ⭕️(アンビエントモード) |
× | × | × | ⭕️(サイドカーレスモデル) |
外部データプレーン¶
サービスメッシュは、Cluster 外にあるデータプレーンも管理する。
| 責務 | Istio | Linkerd | Consul | Amazon VPC Lattice |
|---|---|---|---|---|
| 異なる Cluster にあるデータプレーンの管理 (複数 Kubernetes Cluster メッシュ) |
⭕️ |
⭕️ |
⭕️ |
× |
| Cluster 外の仮想サーバーにあるデータプレーンの管理 | ⭕️ |
× | ⭕️ |
⭕️ |
Kubernetes との親和性¶
| 責務 | Istio | Linkerd | Consul | Amazon VPC Lattice |
|---|---|---|---|---|
| Ingress Controller | ⭕️ |
⭕️ |
⭕️ |
× |
| Egress Controller | ⭕️ |
× | × | × |
| カスタムリソース | ⭕️ |
⭕️ |
× | × |