初めに
業務においてService Meshの構築に関わることとなったが、Service Meshとかよくわからん、という状態なので、情報を集約・整理をしてみる。
Service Mesh とは
サービスメッシュとは、マイクロサービスアーキテクチャなどのサービス間通信が複雑になるシステムにおいて、サービス間の通信を管理・監視することで、トラフィック制御や可観測性の向上などを可能にするアーキテクチャである。
各サービス間の通信をアプリ側で制御するのではなく、間にインフラ側の制御を挟むことで通信の管理・監視を可能にしており、この「サービス」間でインフラ制御を挟むことで「メッシュ」のように分けていることから、サービスメッシュとなっている。（と思っている。）
Google Cloud が提供する（していた）Service Meshの種類
1.Anthos Service Mesh (In Cluster)
GKE クラスタ上で Istio のコントロールプレーンの構成要素である istiod が動作する構成となっている。ユーザー側でistiod のアップグレードやスケール設定、モニタリングなど運用/管理する必要がある。
※写真引用元。参考サイト。
Anthos Service Meshについて
フルマネージドに進化した「Anthos Service Mesh」で運用を楽に！
2.Anthos Service Mesh (Managed Control Plane)
istiod を Google が管理することでマネージドサービスとして提供する構成となる。コントロールプレーンがマネージドのためユーザー側で istiod の運用/管理の必要がなり。
※写真引用元
Anthos Service Meshについて
3.Traffic Director
コントロールプレーンがGoogleフルマネージドであり、GCPのグローバルなインフラを活用した広域なトラフィック管理サービスとなる。負荷分散やロードバランシング、マルチ環境サービスメッシュを得意としたService Mesh。
各サービスに対してサイドカープロキシを立ててエンドポイントとし、ControlPlaneで管理する点は他のサービスメッシュと似ているが、Istioには基づかないというのはテクノロジーベースでの違いとなる。
※写真引用元
Traffic Director についての説明
4.Cloud Service Mesh (Anthos Service Mesh + Traffic Director)
Anthos Servic MeshとコントロールプレーンとしてTrafficDirectorを合わせた、GoogleフルマネージドのService Mesh。CloudRunへのMesh導入なども可能になった。
これ以上は別なサイトでも公開している人が多くいるみたいなので割愛。
Istio
Service MeshのツールとしてはIstioがよく使われるらしい。
サービス間のトラフィックを管理し、アクセス ポリシーを適用してテレメトリー データ集計を行う。インフラ制御になるため、アプリソースの改修を必要としないものらしい。
また、Istio サービス メッシュは、論理的にデータ プレーンとコントロール プレーンに分割される。
データプレーン
サイドカーとしてデプロイされたIstio-Proxy（Envoy） で構成されている。このProxyが、マイクロサービス間のすべてのネットワーク通信を仲介および制御し、テレメトリを収集してレポートしている。
コントロールプレーン
トラフィックをルーティングするためのプロキシを管理および構成を行っている。
サービスを検出してIstio-Proxyを構成したり、証明書周りの管理をしているのもコントロールプレーンとなる。
※写真引用元。参考。
Istio 公式サイト
envoy
サービス間の通信制御において、インフラ制御としてネットワークプロキシを提供することを目的に開発されたツール。サイドカーコンテナの形で、デプロイされることで、各サービス間の通信時にProxyとして機能するほか、インバウンド・アウトバウンド通信におけるEdgeとしても機能する。
Custom Resource Definity
Istioを調べる中でリソースに関する話題がいくつか出てきたので、整理する。
Istio 互換のカスタムリソースとしては、以下がある。（これ以外にもあるっぽい）
| リソース名 | 説明 |
|---|---|
| Virtual serivces | Istioトラフィックルーティング機能。PATHやヘッダーなどによるトラフィックの振り分けを行うことが可能。トラフィックの重み付けをすることで、A/Bテストやカナリーリリースの実現も可能。 |
| Destination rules | Virtual services の後に評価され、追加のポリシー設定やトラフィックの流し方を決定する。ランダムな負荷分散やCircuit Breakerの設定も可能。ラウンドロビン方法もランダム、加重、最小リクエストの3種類に分けられる。 |
| Gateways | インバウンド・アウトバウンドトラフィックを管理する。特定Hostへの通信における使用ポートやプロトコルの指定が可能で、TLS設定などレイヤ4-6の負荷分散構成もできる。L7を同じAPIリソースに追加する代わりに Istio Virtual services をゲートウェイにバインドする。 |
| Sidecars | デフォルトでIstioは、サイドカー（Istio-proxy）を構成しているが、Sidecarsリソースを作成することでSidecarsコンテナの微調整が可能になる。デフォルトではメッシュ内のすべてのサイドカープロキシを、メッシュ内のすべてのワークロード インスタンスに到達するために必要な構成でプログラムし、ワークロードに関連付けられているすべてのポートでトラフィックを受け入れる。Sidecarリソースでは、ワークロードとの間でトラフィックを転送するときにプロキシが受け入れるポートとプロトコルのセットを微調整できます。 |
※参考
Anthos Service Meshを調べていく その1
【Istio⛵️】Istioによって抽象化されるEnvoyのHTTPSリクエスト処理の仕組み
サイドカーコンテナ
いくつかのプロセスを実行する場合（ログやモニタリングのため）には、同じコンテナ内で複数のプロセスを実行する代わりに、別のコンテナを展開する。これをサイドカーコンテナと言う。
一つのPod内にメインコンテナではない別なコンテナを立ち上げている。
アプリケーションコンテナとの違い
サイドカー コンテナは、同じポッド内のアプリ コンテナと並行して実行されます。ただし、主要なアプリケーション ロジックは実行せず、代わりにメイン アプリケーションにサポート機能を提供します。
サイドカー コンテナには独自の独立したライフサイクルがあります。アプリ コンテナとは独立して起動、停止、再起動できます。つまり、プライマリ アプリケーションに影響を与えることなく、サイドカー コンテナを更新、拡張、または保守できます。
サイドカー コンテナーは、プライマリ コンテナーと同じネットワークおよびストレージ名前空間を共有します。この共存により、サイドカー コンテナーとプライマリ コンテナーは密接にやり取りし、リソースを共有できます。
※参考。引用元。
Sidecar Containers
fleet
フリートとは、GoogleCloudにおける複数クラスタを論理的に分ける概念のこと。
フリートを使用すると、クラスタを論理的にグループ化できるため、クラスタグループの管理がリッチになる。フリートとして分けられた各グループは様々な機能を享受することができる。
同一性
1. 名前空間の同一性
2. サービスの同一性
3. フリート外のリソースにアクセスするIDの同一性
4. フリート内IDの同一性
※参考。写真引用元。
フリートの仕組み