1.5. サービスメッシュのデプロイメントモデル
Red Hat OpenShift Service Mesh は、さまざまなデプロイメントモデルを複数サポートし、ビジネス要件に最も適合するように、各種方法を組み合わせることができます。
Istio では、テナントはデプロイされたワークロードで共通のアクセスおよび権限を共有するユーザーのグループです。テナントを使用して、異なるチーム間で一定レベルの分離を確保できます。istio.io またはサービスリソースの NetworkPolicies
、AuthorizationPolicies
、および exportTo
アノテーションを使用して、異なるテナントへのアクセスを分離できます。
1.5.1. クラスター全体 (シングルテナント) メッシュデプロイメントモデル
クラスター全体のデプロイメントには、クラスター全体のリソースを監視する Service Mesh Control Plane が含まれます。クラスター全体のリソースのモニタリングは、コントロールプレーンがすべての namespace にわたって単一のクエリーを使用して Istio および Kubernetes リソースを監視するという点で、Istio の機能によく似ています。その結果、クラスター全体のデプロイメントにより、API サーバーに送信されるリクエストの数が減少します。
Istio と同様に、クラスター全体のメッシュには、デフォルトで istio-injection=enabled
namespace ラベルが付いた namespace が含まれます。このラベルを変更するには、ServiceMeshMemberRoll
リソースの spec.labelSelectors
フィールドを変更します。
1.5.2. マルチテナントデプロイメントモデル
Red Hat OpenShift Service Mesh は、デフォルトでマルチテナントとして設定される ServiceMeshControlPlane
をインストールします。Red Hat OpenShift Service Mesh はマルチテナント Operator を使用して、Service Mesh コントロールプレーンのライフサイクルを管理します。メッシュ内では、テナントに namespace が使用されます。
Red Hat OpenShift Service Mesh は ServiceMeshControlPlane
リソースを使用してメッシュインストールを管理します。メッシュのインストールのスコープはデフォルトでは、リソースを含む namespace に限定されます。ServiceMeshMemberRoll
および ServiceMeshMember
リソースを使用して、別の namespace をメッシュに追加します。namespace は単一のメッシュにのみ組み込むことができ、複数のメッシュを単一の OpenShift クラスターにインストールできます。
通常の Service Mesh デプロイメントでは、単一の Service Mesh コントロールプレーンを使用してメッシュ内のサービス間の通信を設定します。Red Hat OpenShift Service Mesh はテナントごとにコントロールプレーン 1 つと、メッシュが 1 つある "ソフトマルチテナンシー" をサポートします。クラスター内には、複数の独立したコントロールプレーンが存在させることができます。マルチテナントのデプロイメントでは、Service Mesh にアクセスできるプロジェクトを指定し、Service Mesh を他のコントロールプレーンインスタンスから分離します。
クラスター管理者はすべての Istio コントロールプレーンを制御して、可視化できますが、テナント管理者は特定の Service Mesh、Kiali、および Jaeger インスタンスしか制御できません。
指定の namespace または namespace 設定だけにワークロードをデプロイするチームパーミッションを付与できます。Service Mesh 管理者が mesh-user
ロールを付与していると、ユーザーは ServiceMeshMember
リソースを作成して namespace を ServiceMeshMemberRoll
に追加できます。
1.5.2.1. クラスター全体のメッシュへの移行について
クラスター全体のメッシュでは、1 つの ServiceMeshControlPlane
(SMCP) がクラスター全体のすべての namespace を監視します。Red Hat OpenShift Service Mesh バージョン 2.5 以降を使用して、既存のクラスターをマルチテナントメッシュからクラスター全体のメッシュに移行できます。
クラスターに複数の SMCP が必要な場合、クラスター全体のメッシュに移行できません。
デフォルトでは、クラスター全体のメッシュはクラスターを構成するすべての namespace を検出します。ただし、限られた namespace セットにアクセスするようにメッシュを設定できます。デフォルトでは、namespace はサイドカーインジェクションを受け取りません。どの namespace がサイドカーインジェクションを受け取るかを指定する必要があります。
同様に、どの Pod がサイドカーインジェクションを受け取るかを指定する必要があります。サイドカーインジェクションを受け取る namespace に存在する Pod は、サイドカーインジェクションを継承しません。サイドカーインジェクションを namespace と Pod に適用するのは別の操作です。
クラスター全体のメッシュに移行するときに Istio のバージョンを変更した場合は、アプリケーションを再起動する必要があります。同じ Istio バージョンを使用する場合、アプリケーションプロキシーはクラスター全体のメッシュの新規 SMCP に接続し、マルチテナントメッシュの場合と同じように動作します。
1.5.2.1.1. Web コンソールを使用してクラスター全体のメッシュに namespace を含めたり除外したりする
OpenShift Container Platform Web コンソールを使用して、クラスター全体のメッシュの ServiceMeshControlPlane
リソースに検出セレクターを追加できます。ディスカバリーセレクターはコントロールプレーンが検出できる namespace を定義します。コントロールプレーンは、メッシュから namespace を除外する検出セレクターのいずれにも一致しない namespace を無視します。
コントロールプレーンの namespace に Ingress または Egress ゲートウェイをインストールする場合は、コントロールプレーンの namespace を検出セレクターに含める必要があります。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされている。
-
ServiceMeshControlPlane
リソースがデプロイされている。 -
cluster-admin
ロールを持つユーザーとしてログインしている。Red Hat OpenShift Dedicated を使用する場合は、dedicated-admin
ロールを持つユーザーとしてログインします。
手順
- OpenShift Container Platform Web コンソールにログインします。
-
Operators
Installed Operators に移動します。 - Red Hat OpenShift Service Mesh Operator をクリックします。
- Istio Service Mesh Control Plane をクリックします。
- コントロールプレーンの名前をクリックします。
- YAML をクリックします。
YAML ファイルを変更して、
ServiceMeshControlPlane
リソースのspec.meshConfig
フィールドに検出セレクターが含まれるようにします。注記Istiod
サービスが検出できる namespace を設定する場合は、他のメッシュには公開すべきではない機密サービスが含まれる可能性のある namespace を除外します。以下の例では、
Istiod
サービスはistio-discovery: enabled
のラベルが付いた namespace、またはinfo
、httpbin
、またはistio-system
の名前を持つ namespace を検出します。apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane metadata: name: basic spec: mode: ClusterWide meshConfig: discoverySelectors: - matchLabels: istio-discovery: enabled 1 - matchExpressions: - key: kubernetes.io/metadata.name 2 operator: In values: - info - httpbin - istio-system
namespace が検出セレクターのいずれかに一致する場合、メッシュは namespace を検出します。メッシュは、どの検出セレクターにも一致しない namespace を除外します。
- ファイルを保存します。
1.5.2.1.2. CLI を使用したクラスター全体のメッシュへの namespace の組み込みと除外
OpenShift Container Platform CLI を使用して、クラスター全体のメッシュの ServiceMeshControlPlane
リソースに検出セレクターを追加できます。ディスカバリーセレクターはコントロールプレーンが検出できる namespace を定義します。コントロールプレーンは、メッシュから namespace を除外する検出セレクターのいずれにも一致しない namespace を無視します。
コントロールプレーンの namespace に Ingress または Egress ゲートウェイをインストールする場合は、コントロールプレーンの namespace を検出セレクターに含める必要があります。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされている。
-
ServiceMeshControlPlane
リソースがデプロイされている。 -
cluster-admin
ロールを持つユーザーとしてログインしている。Red Hat OpenShift Dedicated を使用する場合は、dedicated-admin
ロールを持つユーザーとしてログインします。
手順
- OpenShift Container Platform CLI にログインします。
次のコマンドを実行して、
ServiceMeshControlPlane
リソースを YAML ファイルとして開きます。$ oc -n istio-system edit smcp <name> 1
- 1
<name>
は、ServiceMeshControlPlane
リソースの名前を表します。
YAML ファイルを変更して、
ServiceMeshControlPlane
リソースのspec.meshConfig
フィールドに検出セレクターが含まれるようにします。注記Istiod
サービスが検出できる namespace を設定する場合は、他のメッシュには公開すべきではない機密サービスが含まれる可能性のある namespace を除外します。以下の例では、
Istiod
サービスはistio-discovery: enabled
のラベルが付いた namespace、またはinfo
、httpbin
、またはistio-system
の名前を持つ namespace を検出します。apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane metadata: name: basic spec: mode: ClusterWide meshConfig: discoverySelectors: - matchLabels: istio-discovery: enabled 1 - matchExpressions: - key: kubernetes.io/metadata.name 2 operator: In values: - info - httpbin - istio-system
namespace が検出セレクターのいずれかに一致する場合、メッシュは namespace を検出します。メッシュは、どの検出セレクターにも一致しない namespace を除外します。
- ファイルを保存して、エディターを終了します。
1.5.2.1.3. Web コンソールを使用して、クラスター全体のメッシュでサイドカーインジェクションを受け取る namespace を定義する
デフォルトでは、Red Hat OpenShift Service Mesh Operator はメンバーセレクターを使用して、サイドカーインジェクションを受け取る namespace を識別します。ServiceMeshMemberRoll
リソースで定義されている istio-injection=enabled
ラベルと一致しない namespace は、サイドカーインジェクションを受け取りません。
検出セレクターを使用してメッシュが検出できる namespace を決定しても、サイドカーインジェクションには影響しません。namespace の検出とサイドカーインジェクションの設定は別の操作です。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされている。
-
ServiceMeshControlPlanae
リソースをmode: ClusterWide
アノテーションが指定してデプロイした。 -
cluster-admin
ロールを持つユーザーとしてログインしている。Red Hat OpenShift Dedicated を使用する場合は、dedicated-admin
ロールを持つユーザーとしてログインします。
手順
- OpenShift Container Platform Web コンソールにログインします。
-
Operators
Installed Operators に移動します。 - Red Hat OpenShift Service Mesh Operator をクリックします。
- Istio Service Mesh Member Roll をクリックします。
-
ServiceMeshMemberRoll
リソースをクリックします。 - YAML をクリックします。
inject
ラベルと一致するメンバーセレクターを追加して、ServiceMeshMemberRoll
リソースのspec.memberSelectors
フィールドを変更します。次の例では、istio-injection: enabled
を使用します。apiVersion: maistra.io/v1 kind: ServiceMeshMemberRoll metadata: name: default spec: memberSelectors: - matchLabels: istio-injection: enabled 1
- 1
- namespace がサイドカーインジェクションを確実に受け取るようにします。
- ファイルを保存します。
1.5.2.1.4. CLI を使用して、クラスター全体のメッシュでサイドカーインジェクションを受け取る namespace を定義する
デフォルトでは、Red Hat OpenShift Service Mesh Operator はメンバーセレクターを使用して、サイドカーインジェクションを受け取る namespace を識別します。ServiceMeshMemberRoll
リソースで定義されている istio-injection=enabled
ラベルと一致しない namespace は、サイドカーインジェクションを受け取りません。
検出セレクターを使用してメッシュが検出できる namespace を決定しても、サイドカーインジェクションには影響しません。namespace の検出とサイドカーインジェクションの設定は別の操作です。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされている。
-
ServiceMeshControlPlanae
リソースをmode: ClusterWide
アノテーションが指定してデプロイした。 -
cluster-admin
ロールを持つユーザーとしてログインしている。Red Hat OpenShift Dedicated を使用する場合は、dedicated-admin
ロールを持つユーザーとしてログインします。
手順
- OpenShift Container Platform CLI にログインします。
ServiceMeshMemberRoll
リソースを編集します。$ oc edit smmr -n <controlplane-namespace>
inject
ラベルと一致するメンバーセレクターを追加して、ServiceMeshMemberRoll
リソースのspec.memberSelectors
フィールドを変更します。次の例では、istio-injection: enabled
を使用します。apiVersion: maistra.io/v1 kind: ServiceMeshMemberRoll metadata: name: default spec: memberSelectors: - matchLabels: istio-injection: enabled 1
- 1
- namespace がサイドカーインジェクションを確実に受け取るようにします。
- ファイルを保存して、エディターを終了します。
1.5.2.1.5. Web コンソールを使用してクラスター全体のメッシュから個々の Pod を除外する
Pod に sidecar.istio.io/inject: true
アノテーションが適用されており、Pod が ServiceMeshMemberRoll
リソースで定義されているラベルセレクターまたはメンバーリストのいずれかに一致する namespace に存在する場合、Pod はサイドカーインジェクションを受け取ります。
Pod に sidecar.istio.io/inject
アノテーションが適用されていない場合、サイドカーインジェクションを受け取ることができません。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされている。
-
ServiceMeshControlPlane
リソースをmode: ClusterWide
アノテーションが指定してデプロイした。 -
cluster-admin
ロールを持つユーザーとしてログインしている。Red Hat OpenShift Dedicated を使用する場合は、dedicated-admin
ロールを持つユーザーとしてログインします。
手順
- OpenShift Container Platform Web コンソールにログインします。
-
Workloads
Deployments に移動します。 - デプロイメントの名前をクリックします。
- YAML をクリックします。
次の例に示すように、YAML ファイルを変更して、サイドカーインジェクションを受け取るアプリケーションと受け取らないアプリケーションを 1 つずつデプロイします。
apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: selector: matchLabels: app: nginx template: metadata: annotations: sidecar.istio.io/inject: 'true' 1 labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx-without-sidecar spec: selector: matchLabels: app: nginx-without-sidecar template: metadata: labels: app: nginx-without-sidecar 2 spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80
- ファイルを保存します。
1.5.2.1.6. CLI を使用してクラスター全体のメッシュから個々の Pod を除外する
Pod に sidecar.istio.io/inject: true
アノテーションが適用されており、Pod が ServiceMeshMemberRoll
リソースで定義されているラベルセレクターまたはメンバーリストのいずれかに一致する namespace に存在する場合、Pod はサイドカーインジェクションを受け取ります。
Pod に sidecar.istio.io/inject
アノテーションが適用されていない場合、サイドカーインジェクションを受け取ることができません。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされている。
-
ServiceMeshControlPlane
リソースをmode: ClusterWide
アノテーションが指定してデプロイした。 -
cluster-admin
ロールを持つユーザーとしてログインしている。Red Hat OpenShift Dedicated を使用する場合は、dedicated-admin
ロールを持つユーザーとしてログインします。
手順
- OpenShift Container Platform CLI にログインします。
次のコマンドを実行して、デプロイメントを編集します。
$ oc edit deployment -n <namespace> <deploymentName>
次の例に示すように、YAML ファイルを変更して、サイドカーインジェクションを受け取るアプリケーションと受け取らないアプリケーションを 1 つずつデプロイします。
apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: selector: matchLabels: app: nginx template: metadata: annotations: sidecar.istio.io/inject: 'true' 1 labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx-without-sidecar spec: selector: matchLabels: app: nginx-without-sidecar template: metadata: labels: app: nginx-without-sidecar 2 spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80
- ファイルを保存します。
1.5.3. マルチテーマまたはフェデレーションされたデプロイメントモデル
フェデレーション は、個別の管理ドメインで管理される個別のメッシュ間でサービスとワークロードを共有できるデプロイメントモデルです。
Istio マルチクラスターモデルでは、メッシュ間だで高いレベルの信頼が必要なだけでなく、個々のメッシュが存在するすべての Kubernetes API サーバーへのリモートアクセスも必要です。Red Hat OpenShift Service Mesh のフェデレーションは、メッシュ間の 最小限 の信頼を前提とする Service Mesh のマルチクラスター実装に対して独自のアプローチを採用しています。
フェデレーションされたメッシュ は、単一のメッシュとして動作させるメッシュのグループです。各メッシュのサービスは、独自のサービスにできます。たとえば、別のメッシュからサービスをインポートすることでサービスを追加するメッシュは、メッシュ全体で同じサービスにさらにワークロードを追加し、高可用性を提供することや、その両方を組み合わせることができます。フェデレーションされたメッシュに参加するすべてのメッシュは個別に管理されたままなので、フェデレーション内の他のメッシュとの間でエクスポートやインポートされるサービスを明示的に設定する必要があります。証明書の生成、メトリクス、トレース収集などのサポート機能は、それぞれのメッシュのローカルで機能します。