サービスメッシュの担う責務＠サービスメッシュ¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. サービスメッシュの担う責務¶
サービスメッシュを採用しない場合 (Kubernetes のみ) と比較して、各サービスメッシュツールがインフラ領域のどんな責務を実装してくれるかを記載する。
もしサービスメッシュを採用しない場合、サービスメッシュと同じ責務をマイクロサービス領域に実装する必要がある。
サービスメッシュが担う責務が要件として必要であるなら、以下の理由でサービスメッシュツールを採用した方が良い。
- マイクロサービス側にインフラ領域の責務を実装しなくて済むため、アプリエンジニアの負担が減る。
- インフラ領域の責務をサイドカーに切り分けられるため、凝集度が高くなる
- 各マイクロサービスに共通して提供できるため、単純性が高くなる
一方で要件として不要ならば、サービスメッシュツール自体を採用する必要はない、という判断になる。
01-02. ツール¶
- Istio
- Linkerd
- Consul
- AWS VPC Lattice (AWS App Meshの移行先)
02. トラフィック管理¶
プロトコル¶
サービスメッシュは、任意のプロトコルを扱える。
| 責務 | Kubernetes (サービスメッシュ採用せず) |
Istio | Linkerd | Consul | AWS VPC Lattice |
|---|---|---|---|---|---|
| TCP | Service + kube-proxy | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
| HTTP/1.1 | Ingress | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
| HTTP/2 (例：gRPCなど) | Ingress | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
| gRPC | Ingress、Service + kube-proxy | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
ネットワーク¶
Kubernetesでは、Serviceは単一のバージョンのPodとしか通信できない。
もし複数の異なるバージョンのPodを対象にしたい場合、Podのバージョンに応じたServiceを作成する必要がある。
一方で、サービスメッシュツールは異なるバージョンのPodに、さまざまな手法 (例：カナリア方式、トラフィックミラーリング方式など) で通信できる。
| 責務 | Kubernetes (サービスメッシュ採用せず) |
Istio | Linkerd | Consul | AWS VPC Lattice |
|---|---|---|---|---|---|
L4ロードバランシング |
Service + kube-proxy | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
L7ロードバランシング |
Ingress | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
| ルーティング (ホストベース、パスベース、割合ベース) |
Service + kube-proxy、Ingress | ⭕️ |
× | × | × |
| サービスディスカバリー | Service + kube-proxy | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
| CNI | 記入中... | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
03. 復旧性の管理¶
サービスメッシュは、マイクロサービスの復旧性を管理する。
| 責務 | Kubernetes (サービスメッシュ採用せず) |
Istio | Linkerd | Consul | AWS VPC Lattice |
|---|---|---|---|---|---|
| サーキットブレイカー | 記入中... | ⭕️ |
× | ⭕️ |
⭕️ |
| フォールトインジェクション | 記入中... | ⭕️ |
⭕️ |
× | × |
| 再試行処理 | 記入中... | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
| タイムアウト | 記入中... | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
| リクエスト数制限 (レートリミット) |
記入中... | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
04. 通信の認証/認可¶
サービスメッシュは、ゼロトラストネットワークに基づいて、通信にも認証/認可を実施する。
マイクロサービス側の認証/認可はサービスメッシュの管理外であるため、別に実装する必要がある。
| 責務 | Kubernetes (サービスメッシュ採用せず) |
Istio | Linkerd | Consul | AWS VPC Lattice |
|---|---|---|---|---|---|
| 相互TLS認証 | 相互TLS認証ツール (例：Spiffe) |
⭕️(Spiffeへ置き換えできる) |
⭕️ |
⭕️ |
⭕️ |
| JWTによるBearer認証 | アプリで実装、OAuthプロキシ (例：OAuth2 Proxyなど) やSSOプロキシ(例：Dexなど) | ⭕️ |
× | ⭕️ |
× |
05. アプリケーションデータの暗号化¶
サービスメッシュは、アプリケーションデータをSSL証明書で暗号化する。
Kubernetesでは、Podの作成に応じて証明書のKubernetesリソース (Certificate、CertificateSigningRequestなど) を作成する必要がある。
| 責務 | Kubernetes (サービスメッシュ採用せず) |
Istio | Linkerd | Consul | AWS VPC Lattice |
|---|---|---|---|---|---|
| 相互TLS認証 | 相互TLS認証ツール (例：Spiffe) |
⭕️(Spiffeへ置き換えできる) |
⭕️ |
⭕️ |
⭕️ |
| SSL証明書の自動更新 | ・手動でSSL証明書を更新 ・SSL証明書管理ツール (例：Cert Manager) |
⭕️ |
× | ⭕️ |
⭕️ |
06. テレメトリー管理¶
ログの場合¶
サービスメッシュツールを使用する場合、マイクロサービスの代わりにサイドカープロキシがアクセスログを作成し、ログ監視バックエンドに送信する。
ただし、マイクロサービスでもアクセスログを作成しても良い。
| 責務 | Kubernetes (サービスメッシュ採用せず) |
Istio | Linkerd | Consul | AWS VPC Lattice |
|---|---|---|---|---|---|
| マイクロサービスの実行ログを作成する | - | × | × | × | × |
| マイクロサービスの実行ログをログルーター (例：Fluentd、FluentBit) へ送信する |
- | × | × | × | × |
| マイクロサービスのアクセスログを作成する | 各言語のロギングパッケージ | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
| マイクロサービスのアクセスログをログルーター (例：Fluentd、FluentBit) へ送信する |
各言語のロギングパッケージ | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
メトリクスの場合¶
サービスメッシュツールを使用する場合、マイクロサービスの代わりにサイドカープロキシがメトリクスを作成し、メトリクス監視バックエンドに送信する。
| 責務 | Kubernetes (サービスメッシュ採用せず) |
Istio | Linkerd | Consul | AWS VPC Lattice |
|---|---|---|---|---|---|
| マイクロサービスのゴールデンシグナルを作成する | クライアントパッケージ (例：otelクライアントパッケージなど) |
⭕️ |
⭕️ |
⭕️ |
⭕️ |
| マイクロサービスのゴールデンシグナルをメトリクス監視バックエンド (例：Prometheus) へ送信する |
クライアントパッケージ (例：otelクライアントパッケージなど) |
⭕️ |
⭕️ |
⭕️ |
⭕️ |
| マイクロサービスのエンドポイント別にメトリクスをフィルタリングする | 記入中... | ⭕️ |
⭕️ |
⭕️ |
× |
分散トレースの場合¶
サービスメッシュツールを使用する場合、マイクロサービスの代わりにサイドカープロキシがメトリクスを作成し、トレース監視バックエンドに送信する。
ただし、マイクロサービス間でのトレースコンテキスト伝播は、マイクロサービスに実装する必要がある。
| 責務 | Kubernetes (サービスメッシュ採用せず) |
Istio | Linkerd | Consul | AWS VPC Lattice |
|---|---|---|---|---|---|
| 分散トレースのスパンを作成する | クライアントパッケージ (例：otelクライアントパッケージなど) |
⭕️ |
⭕️ |
⭕️ |
⭕️ |
| 分散トレースをトレースのCollector (例：OpenTelemetry Collector、Jaeger Collectorなど) に送信する |
クライアントパッケージ (例：otelクライアントパッケージなど) |
⭕️ |
⭕️ |
⭕️ |
⭕️ |
サービスメッシュトポロジーの場合¶
| 責務 | Kubernetes (サービスメッシュ採用せず) |
Kiali | X-Ray |
|---|---|---|---|
| 必要なメトリクスのデータポイントを収集する | 記入中... | ⭕️ |
⭕️ |
| サービスメッシュトポロジーをモデリングする | 記入中... | ⭕️ |
⭕️ |
| サービスメッシュトポロジーをモデリングする | 記入中... | ⭕️ |
⭕️ |
07. アーキテクチャ¶
サービスメッシュのパターン¶
| 責務 | Istio | Linkerd | Consul | AWS VPC Lattice | Cilium |
|---|---|---|---|---|---|
| サイドカー型 | ⭕️ |
⭕️ |
⭕️ |
⭕️ |
× |
| サイドカーレス型 | ⭕️(アンビエントメッシュ) |
× | × | × | ⭕️(カーネルモデル) |
外部データプレーン¶
サービスメッシュは、Cluster外にあるデータプレーンも管理する。
| 責務 | Istio | Linkerd | Consul | AWS VPC Lattice |
|---|---|---|---|---|
| 異なるClusterにあるデータプレーンの管理 (マルチClusterメッシュ) |
⭕️ |
⭕️ |
⭕️ |
× |
| Cluster外の仮想サーバーにあるデータプレーンの管理 | ⭕️ |
× | ⭕️ |
⭕️ |
Kubernetesとの親和性¶
| 責務 | Istio | Linkerd | Consul | AWS VPC Lattice |
|---|---|---|---|---|
| Ingressコントローラー | ⭕️ |
⭕️ |
⭕️ |
× |
| Egressコントローラー | ⭕️ |
× | × | × |
| カスタムリソース | ⭕️ |
⭕️ |
× | × |