コンテンツにスキップ

設計パターン

はじめに

本サイトにつきまして、【IT技術の知見】はじめに - 俺の技術ノート をご認識のほど宜しくお願いいたします。


01. 管理下の Kubernetes Cluster 数

単一 Kubernetes Cluster

単一の Kubernetes Cluster 内のワークロードで、サービスメッシュを構成する。


複数 Kubernetes Cluster

複数の Kubernetes Cluster にまたがるワークロードで単一のサービスメッシュを構成し、Cluster 間での障害の分離やフェイルオーバーを実現する。


02. Istiod コントロールプレーン数

Istiod コントロールプレーン数に関するパターンである。


02-02. 単一 Istiod コントロールプレーン

単一 Istiod コントロールプレーンとは

複数 Kubernetes Cluster のネットワークを横断的に管理する Istiod コントロールプレーンを作成する。

Istiod コントロールプレーンを持つプライマリ Cluster、サービスメッシュに参加する Cluster のリモート Cluster からなる。


02-03. 複数 Istiod コントロールプレーン

複数 Istiod コントロールプレーンとは

Kubernetes Cluster ごとに Istiod コントロールプレーンを作成する。


異なる Istiod コントロールプレーン間のデータプレーン共有

▼ 同じプライベートネットワーク内の場合

異なる Cluster が同じプライベートネットワーク内に所属している場合、各 Cluster の Istiod が kube-apiserver からリソース設定を取得し、データプレーンへ Envoy の設定値を配布する。

このとき、IngressGateway を使用せずに、異なる Cluster のコンテナが直接通信できる。

istio_multi-service-mesh_cluster_same-network

▼ 異なるプライベートネットワーク内の場合

異なる Cluster が異なるプライベートネットワーク内に所属している場合、各 Cluster の Istiod が kube-apiserver からリソース設定を取得し、データプレーンへ Envoy の設定値を配布する。

このとき、IngressGateway を経由して、異なる Cluster のコンテナが間接的に通信できる。

istio_multi-service-mesh_cluster_difficult-network


03. プライマリー／リモートクラスター構成

プライマリー／リモートクラスター構成

Istio コントロールプレーンとデータプレーンを異なるクラスターにデプロイする。


シングル Istiod

プライマリークラスターに Istio コントロールプレーンと Istio Ingress Gateway や Istio Egress Gateway を配置し、リモートクラスターにはデータプレーンを配置する。

マルチ Istiod

プライマリークラスターに複数の Istio コントロールプレーンを配置し、リモートクラスターにはデータプレーンを配置する。


データプレーンが仮想サーバーの場合

▼ 同じプライベートネットワーク内の場合

仮想サーバーがコントロールプレーン Node と同じプライベートネットワーク内に所属している場合、仮想サーバー上のコンテナをサービスメッシュに参加させる。

コントロールプレーン側では WorkloadGroup の作成、仮想サーバー側では istio デーモンプロセスの実行が必要である。

このとき、IngressGateway を使用せずに、Kubernetes 上のコンテナと仮想サーバー上のコンテナが直接的に通信できる。

istio_multi-service-mesh_vm_same-network

▼ 異なるプライベートネットワーク内の場合

仮想サーバーがコントロールプレーン Node と異なるプライベートネットワーク内に所属している場合、仮想サーバー上のコンテナをサービスメッシュに参加させる。

コントロールプレーン側では WorkloadGroup の作成、仮想サーバー側では istio デーモンプロセスの実行が必要である。

このとき、IngressGateway を経由して、Kubernetes 上のコンテナと仮想サーバー上のコンテナが間接的に通信できる。

istio_multi-service-mesh_vm_difficult-network


データプレーンが非 Kubernetes のコンテナの場合

クラウド上のコンテナ (例：Amazon ECS) がコントロールプレーン Node と同じプライベートネットワーク内に所属している場合、クラウド上のコンテナをサービスメッシュに参加させる。

コントロールプレーン側では〇 (Amazon ECS を認識するためのリソースが必要なはずだが、調査してもわからず...) の作成、クラウド上のコンテナのホストマシンでは ztunnel デーモンあるいは ztunnel コンテナの実行が必要である。


04. 接続メッシュ数

単一メッシュ

すべてのワークロードを単一のサービスメッシュで管理し、サービス名はメッシュ内で一意になる。


複数メッシュ

複数のサービスメッシュを作成し、メッシュフェデレーションによってメッシュ間の通信を連携する。


05. テナント分離

Namespace テナント

Istio のサービスメッシュは、管理下の複数の Namespace をテナントとして分離する。

Namespace as-a-Service として提供する。


Cluster テナント

Istio のサービスメッシュは、管理下の複数 Kubernetes Cluster をテナントとして分離する。

Clusters as-a-Service として提供する。


メッシュテナント

単一または複数の Kubernetes Cluster からなる独立したサービスメッシュをテナントとして分離する。

各サービスメッシュは独立しているが、Istio Ingress Gateway を経由して互いに通信できる。

メッシュテナントを採用すると、複数メッシュパターンになる。