1.5. Service Mesh と Istio の相違点

Red Hat OpenShift Service Mesh は、追加機能の提供、OpenShift Container Platform へのデプロイ時の差異の処理を実行する Istio のインストールとは異なります。

1.5.1. Istio と Red Hat OpenShift Service Mesh の相違点

以下の機能は Service Mesh と Istio で異なります。

1.5.1.1. コマンドラインツール

Red Hat OpenShift Service Mesh のコマンドラインツールは oc です。  Red Hat OpenShift Service Mesh は、istioctl をサポートしません。

1.5.1.2. インストールおよびアップグレード

Red Hat OpenShift Service Mesh は、Istio インストールプロファイルをサポートしません。

Red Hat OpenShift Service Mesh は Service Mesh のカナリアアップグレードをサポートしません。

1.5.1.3. 自動的な挿入

アップストリームの Istio コミュニティーインストールは、ラベル付けしたプロジェクト内の Pod にサイドカーコンテナーを自動的に挿入します。

Red Hat OpenShift Service Mesh は、サイドカーコンテナーをあらゆる Pod に自動的に挿入することはなく、プロジェクトにラベルを付けることなくアノテーションを使用して挿入をオプトインする必要があります。この方法で必要となる権限は少なく、ビルダー Pod などの他の OpenShift Container Platform 機能と競合しません。自動挿入を有効にするには、サイドカーの自動挿入 セクションで説明されているとおり、sidecar.istio.io/inject ラベルまたはアノテーションを指定します。

表1.3 サイドカーインジェクションのラベルとアノテーションの設定

 アップストリーム IstioRed Hat OpenShift Service Mesh

namespace ラベル

"enabled" と "disabled"をサポート

"disabled" をサポート

Pod Label

"true" と "false"をサポート

"true" と "false"をサポート

Pod のアノテーション

"false" のみをサポート

"true" と "false"をサポート

1.5.1.4. Istio ロールベースアクセス制御機能

Istio ロールベースアクセス制御機能 (RBAC) は、サービスへのアクセスを制御するために使用できるメカニズムを提供します。ユーザー名やプロパティーのセットを指定してサブジェクトを特定し、それに応じてアクセス制御を適用できます。

アップストリームの Istio コミュニティーインストールには、ヘッダーの完全一致の実行、ヘッダーのワイルドカードの一致の実行、または特定の接頭辞または接尾辞を含むヘッダーの有無をチェックするオプションが含まれます。

Red Hat OpenShift Service Mesh は、正規表現を使用して要求ヘッダーと一致させる機能を拡張します。request.regex.headers のプロパティーキーを正規表現で指定します。

アップストリーム Istio コミュニティーの要求ヘッダーのマッチング例

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin-usernamepolicy
spec:
  action: ALLOW
  rules:
    - when:
        - key: 'request.regex.headers[username]'
          values:
            - "allowed.*"
  selector:
    matchLabels:
      app: httpbin

1.5.1.5. OpenSSL

Red Hat OpenShift Service Mesh では、BoringSSL を OpenSSL に置き換えます。OpenSSL は、Secure Sockets Layer (SSL) プロトコルおよび Transport Layer Security (TLS) プロトコルのオープンソース実装を含むソフトウェアライブラリーです。Red Hat OpenShift Service Mesh Proxy バイナリーは、基礎となる Red Hat Enterprise Linux オペレーティングシステムから OpenSSL ライブラリー (libssl および libcrypto) を動的にリンクします。

1.5.1.6. 外部ワークロード

Red Hat OpenShift Service Mesh は、ベアメタルサーバー上で OpenShift の外部で実行される仮想マシンなどの外部ワークロードをサポートしません。

1.5.1.7. 仮想マシンのサポート

OpenShift Virtualization を使用して、仮想マシンを OpenShift にデプロイできます。次に、メッシュの一部である他の Pod と同様に、mTLS または AuthorizationPolicy などのメッシュポリシーをこれらの仮想マシンに適用できます。

1.5.1.8. コンポーネントの変更

  • すべてのリソースに maistra-version ラベルが追加されました。
  • すべての Ingress リソースが OpenShift ルートリソースに変換されました。
  • Grafana、分散トレース (Jaeger)、および Kiali はデフォルトで有効になっており、OpenShift ルート経由で公開されます。
  • すべてのテンプレートから Godebug が削除されました。
  • istio-multi ServiceAccount および ClusterRoleBinding が削除されました。また、istio-reader ClusterRole も削除されました。

1.5.1.9. Envoy フィルター

Red Hat OpenShift Service Mesh は、明示的に文書化されている場合を除き、EnvoyFilter の設定はサポートしていません。下層の EnvoyAPI と疎結合されており、後方互換性を確保できません。EnvoyFilter パッチは、Istio によって生成される Envoy 設定の形式に非常に敏感です。Istio で生成された設定を変更すると、EnvoyFilter のアプリケーションが破損する可能性があります。

1.5.1.10. Envoy サービス

Red Hat OpenShift Service Mesh は、QUIC ベースのサービスをサポートしません。

1.5.1.11. Istio Container Network Interface (CNI) プラグイン

Red Hat OpenShift Service Mesh には CNI プラグインが含まれ、アプリケーション Pod ネットワーキングを設定する代替の方法が提供されます。CNI プラグインは init-container ネットワーク設定を置き換えます。これにより、昇格した権限でサービスアカウントおよびプロジェクトに Security Context Constraints (SCC) へのアクセスを付与する必要がなくなります。

注記

デフォルトでは、Istio Container Network Interface (CNI) Pod は、すべての OpenShift Container Platform ノード上に作成されます。特定のノードでの CNI Pod の作成を除外するには、maistra.io/exclude- cni=true ラベルをノードに適用します。このラベルを追加すると、以前にデプロイされた Istio CNI Pod がノードから削除されます。

1.5.1.12. グローバル mTLS 設定

Red Hat OpenShift Service Mesh は、メッシュ内で相互 TLS 認証 (mTLS) を有効または無効にする PeerAuthentication リソースを作成します。

1.5.1.13. ゲートウェイ

Red Hat OpenShift Service Mesh は、デフォルトで受信および送信用のゲートウェイをインストールします。次の設定を使用して、ServiceMeshControlPlane (SMCP) リソースでゲートウェイのインストールを無効にできます。

  • spec.gateways.enabled=false は、ingress ゲートウェイと egress ゲートウェイの両方を無効にします。
  • spec.gateways.ingress.enabled=false は、ingress ゲートウェイを無効にします。
  • spec.gateways.egress.enabled=false は、egress ゲートウェイを無効にします。
注記

Operator はデフォルトゲートウェイにアノテーションを付けて、それらが Red Hat OpenShift Service Mesh Operator によって生成および管理されていることを示します。

1.5.1.14. マルチクラスター設定

マルチクラスター設定における Red Hat OpenShift Service Mesh のサポートは、複数のクラスターにわたる Service Mesh のフェデレーションに限定されます。

1.5.1.15. カスタム証明書署名要求 (CSR)

Kubernetes 認証局 (CA) で CSR を処理するように Red Hat OpenShift Service Mesh を設定することはできません。

1.5.1.16. Istio ゲートウェイのルート

Istio ゲートウェイの OpenShift ルートは、Red Hat OpenShift Service Mesh で自動的に管理されます。Istio ゲートウェイが Service Mesh 内で作成され、更新され、削除されるたびに、OpenShift ルートが作成され、更新され、削除されます。

Istio OpenShift Routing (IOR) と呼ばれる Red Hat OpenShift Service Mesh コントロールプレーンコンポーネントは、ゲートウェイルートを同期させます。詳細は、「自動ルートの作成」を参照してください。

1.5.1.16.1. catch-all ドメイン

catch-all ドメイン ("*") はサポートされません。ゲートウェイ定義で catch-all ドメインが見つかった場合、Red Hat OpenShift Service Mesh はルートを 作成します が、デフォルトのホスト名を作成するには OpenShift に依存します。つまり、新たに作成されたルートは、catch all ("*") ルート ではなく、代わりに <route-name>[-<project>].<suffix> 形式のホスト名を持ちます。デフォルトのホスト名の仕組みや、cluster-admin がカスタマイズできる仕組みについての詳細は、OpenShift Container Platform ドキュメントを参照してください。Red Hat OpenShift Dedicated を使用する場合は、Red Hat OpenShift Dedicated の dedicated-admin ロールを参照してください。

1.5.1.16.2. サブドメイン

サブドメイン (e.g.: "*.domain.com") はサポートされます。ただし、この機能は OpenShift Container Platform ではデフォルトで有効になっていません。つまり、Red Hat OpenShift Service Mesh はサブドメインを持つルートを 作成します が、これは OpenShift Container Platform が有効にするように設定されている場合にのみ有効になります。

1.5.1.16.3. トランスポート層セキュリティー

トランスポート層セキュリティー (TLS) がサポートされます。ゲートウェイに tls セクションが含まれると、OpenShift ルートは TLS をサポートするように設定されます。

関連情報

1.5.2. マルチテナントインストール

アップストリームの Istio は単一テナントのアプローチをとりますが、Red Hat OpenShift Service Mesh はクラスター内で複数の独立したコントロールプレーンをサポートします。Red Hat OpenShift Service Mesh はマルチテナント Operator を使用して、コントロールプレーンのライフサイクルを管理します。

Red Hat OpenShift Service Mesh は、デフォルトでマルチテナントコントロールプレーンをインストールします。Service Mesh にアクセスできるプロジェクトを指定し、Service Mesh を他のコントロールプレーンインスタンスから分離します。

1.5.2.1. マルチテナンシーとクラスター全体のインストールの比較

マルチテナントインストールとクラスター全体のインストールの主な違いは、istod で使用される権限の範囲です。コンポーネントでは、クラスタースコープのロールベースのアクセス制御 (RBAC) リソース ClusterRoleBinding が使用されなくなりました。

ServiceMeshMemberRoll members リストのすべてのプロジェクトには、コントロールプレーンのデプロイメントに関連付けられた各サービスアカウントの RoleBinding があり、各コントロールプレーンのデプロイメントはそれらのメンバープロジェクトのみを監視します。各メンバープロジェクトには maistra.io/member-of ラベルが追加されており、member-of の値はコントロールプレーンのインストールが含まれるプロジェクトになります。

Red Hat OpenShift Service Mesh は各メンバープロジェクトを設定し、それ自体、コントロールプレーン、および他のメンバープロジェクト間のネットワークアクセスを確保できるようにします。正確な設定は、OpenShift Container Platform のソフトウェア定義ネットワーク (SDN) の設定方法によって異なります。詳細は、OpenShift SDN についてを参照してください。

OpenShift Container Platform クラスターが SDN プラグインを使用するように設定されている場合:

  • NetworkPolicy: Red Hat OpenShift Service Mesh は、各メンバープロジェクトで NetworkPolicy リソースを作成し、他のメンバーおよびコントロールプレーンからのすべての Pod に対する Ingress を許可します。Service Meshからメンバーを削除すると、この NetworkPolicy リソースがプロジェクトから削除されます。

    注記

    また、これにより Ingress がメンバープロジェクトのみに制限されます。メンバー以外のプロジェクトの Ingress が必要な場合は、NetworkPolicy を作成してそのトラフィックを許可する必要があります。

  • Multitenant: Red Hat OpenShift Service Mesh は、各メンバープロジェクトの NetNamespace をコントロールプレーンプロジェクトの NetNamespace に追加します (oc adm pod-network join-projects --to control-plane-project member-project の実行と同じです)。Service Meshからメンバーを削除すると、その NetNamespace はコントロールプレーンから分離されます (oc adm pod-network isolate-projects member-project の実行と同じです)。
  • Subnet: 追加の設定は実行されません。

1.5.2.2. クラスタースコープのリソース

アップストリーム Istio には、依存するクラスタースコープのリソースが 2 つあります。MeshPolicy および ClusterRbacConfig。これらはマルチテナントクラスターと互換性がなく、以下で説明されているように置き換えられました。

  • コントロールプレーン全体の認証ポリシーを設定するために、MeshPolicy は ServiceMeshPolicy に置き換えられます。これは、コントロールプレーンと同じプロジェクトに作成する必要があります。
  • コントロールプレーン全体のロールベースのアクセス制御を設定するために、ClusterRbacConfig は ServicemeshRbacConfig に置き換えられます。これは、コントロールプレーンと同じプロジェクトに作成する必要があります。

1.5.3. Kiali とサービスメッシュ

OpenShift Container Platform での Service Mesh を使用した Kiali のインストールは、複数の点でコミュニティーの Kiali インストールとは異なります。以下の変更点は、問題の解決、追加機能の提供、OpenShift Container Platform へのデプロイ時の差異の処理を実行するために必要になることがあります。

  • Kiali はデフォルトで有効になっています。
  • Ingress はデフォルトで有効になっている。
  • Kiali ConfigMap が更新されている。
  • Kiali の ClusterRole 設定が更新されている。
  • 変更は Service Mesh または Kiali Operator によって上書きされる可能性があるため、ConfigMap を編集しないでください。Kiali Operator が管理するファイルには、kiali.io/ ラベルまたはアノテーションが付いています。Operator ファイルの更新は、cluster-admin 権限を持つユーザーに制限する必要があります。Red Hat OpenShift Dedicated を使用する場合に、dedicated-admin 権限のあるユーザーだけが Operator ファイルを更新できるようにする必要があります。

1.5.4. 分散トレースとService Mesh

OpenShift Container Platform での Service Mesh を使用した distributed tracing platform (Jaeger) のインストールは、複数の点でコミュニティーの Jaeger インストールとは異なります。以下の変更点は、問題の解決、追加機能の提供、OpenShift Container Platform へのデプロイ時の差異の処理を実行するために必要になることがあります。

  • 分散トレースは、Service Mesh に対してデフォルトで有効にされています。
  • Ingress は、Service Mesh に対してデフォルトで有効になっています。
  • Zipkin ポート名が、(http から) jaeger-collector-zipkin に変更されています。
  • Jaeger は、production または streaming デプロイメントオプションのいずれかを選択する際に、デフォルトでストレージに Elasticsearch を使用します。
  • Istio のコミュニティーバージョンは、一般的なトレースルートを提供します。Red Hat OpenShift Service Mesh は Red Hat OpenShift 分散トレーシプラットフォーム (Jaeger) Operator によってインストールされ、OAuth によってすでに保護されている jaeger ルートを使用します。
  • Red Hat OpenShift Service Mesh は Envoy プロキシーにサイドカーを使用し、Jaeger も Jaeger エージェントにサイドカーを使用します。両者は個別に設定し、混同しないようにしてください。プロキシーサイドカーは、Pod の Ingress および Egress トラフィックに関連するスパンを作成します。エージェントサイドカーは、アプリケーションによって出力されるスパンを受け取り、これらを Jaeger Collector に送信します。