Service Mesh
Service Mesh のインストール、使用法、およびリリースノート
概要
第1章 Service Mesh 2.x
1.1. OpenShift Service Mesh について
Red Hat OpenShift Service Mesh は OpenShift Container Platform とは異なる頻度でリリースされ、Red Hat OpenShift Service Mesh Operator は ServiceMeshControlPlane
の複数のバージョンのデプロイをサポートしているため、Service Mesh のドキュメントでは、本製品のマイナーバージョン用に個別のドキュメントセットを維持していません。現在のドキュメントセットは、特定のトピックまたは特定の機能でバージョン固有の制限がない限り、現在サポートされている Service Mesh の最新バージョンに適用されます。
Red Hat OpenShift Service Mesh のライフサイクルとサポートされるプラットフォームに関する追加情報は、プラットフォームライフサイクルポリシー を参照してください。
1.1.1. Red Hat OpenShift Service Mesh の概要
Red Hat OpenShift Service Mesh は、アプリケーションで一元化された制御ポイントを作成して、マイクロサービスアーキテクチャーのさまざまな問題に対応します。OpenShift Service Mesh はアプリケーションコードを変更せずに、既存の分散アプリケーションに透過的な層を追加します。
マイクロサービスアーキテクチャーは、エンタープライズアプリケーションの作業をモジュールサービスに分割するため、スケーリングとメンテナンスが容易になります。ただし、マイクロサービスアーキテクチャー上に構築されるエンタープライズアプリケーションはサイズも複雑性も増すため、マイクロサービスアーキテクチャーの理解と管理は困難です。Service Mesh は、サービス間のトラフィックをキャプチャーしたり、インターセプトしたりして、他のサービスへの新規要求を変更、リダイレクト、または作成することによってこれらのアーキテクチャーの問題に対応できます。
オープンソースの Istio プロジェクト をベースにする Service Mesh では、検出、負荷分散、サービス間の認証、障害復旧、メトリクス、およびモニタリングを提供する、デプロイされたサービスのネットワークを簡単に作成できます。Service Mesh は、A/B テスト、カナリアリリース、レート制限、アクセス制御、エンドツーエンド認証を含む、より複雑な運用機能を提供します。
1.1.2. コア機能
Red Hat OpenShift Service Mesh は、サービスのネットワーク全体で多数の主要機能を均一に提供します。
- トラフィック管理: サービス間でトラフィックおよび API 呼び出しのフローを制御し、呼び出しの安定度を高め、不利な条件下でもネットワークの堅牢性を維持します。
- サービス ID とセキュリティー: メッシュのサービスを検証可能な ID で指定でき、サービスのトラフィックがさまざまな信頼度のネットワークに送られる際にそのトラフィックを保護する機能を提供します。
- ポリシーの適用: サービス間の対話に組織のポリシーを適用し、アクセスポリシーが適用され、リソースはコンシューマー間で均等に分散されるようにします。ポリシー変更は、アプリケーションコードを変更するのではなく、メッシュを設定して行います。
- テレメトリー: サービス間の依存関係やそれらの間のトラフィックの性質やフローを理解するのに役立ち、問題を素早く特定できます。
1.2. Service Mesh リリースノート
1.2.1. 多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
1.2.2. 新機能および拡張機能
今回のリリースでは、以下のコンポーネントおよび概念に関連する拡張機能が追加されました。
1.2.2.1. Red Hat OpenShift Service Mesh バージョン 2.4.5 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.11 以降でサポートされます。
1.2.2.1.1. Red Hat OpenShift Service Mesh バージョン 2.4.5 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.16.7 |
Envoy プロキシー | 1.24.12 |
Jaeger | 1.47.0 |
Kiali | 1.65.11 |
1.2.2.2. Red Hat OpenShift Service Mesh バージョン 2.4.4 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.11 以降でサポートされます。
1.2.2.2.1. Red Hat OpenShift Service Mesh バージョン 2.4.4 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.16.7 |
Envoy プロキシー | 1.24.12 |
Jaeger | 1.47.0 |
Kiali | 1.65.10 |
1.2.2.3. Red Hat OpenShift Service Mesh バージョン 2.4.3 の新機能
- Red Hat OpenShift Service Mesh Operator がテクノロジープレビュー機能として ARM ベースのクラスターで利用できるようになりました。
-
envoyExtAuthzGrpc
フィールドが追加されました。これは、gRPC API を使用して外部承認プロバイダーを設定するために使用されます。 - Common Vulnerabilities and Exposures (CVE) が解決されました。
- このリリースは、OpenShift Container Platform 4.10 以降のバージョンでサポートされます。
1.2.2.3.1. Red Hat OpenShift Service Mesh バージョン 2.4.3 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.16.7 |
Envoy プロキシー | 1.24.10 |
Jaeger | 1.42.0 |
Kiali | 1.65.8 |
1.2.2.3.2. ARM ベースのクラスターに対する Red Hat OpenShift Service Mesh Operator
ARM ベースのクラスターに対する Red Hat OpenShift Service Mesh Operator の機能はテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
このリリースでは、Red Hat OpenShift Service Mesh Operator がテクノロジープレビュー機能として ARM ベースのクラスターで利用できるようになります。Istio、Envoy、Prometheus、Kiali、Grafana のイメージが利用可能です。Jaeger ではイメージを使用できないため、Jaeger を Service Mesh アドオンとして無効にする必要があります。
1.2.2.3.3. 外部認可設定に対するリモートプロシージャコール(gRPC) API のサポート
今回の機能拡張により、envoyExtAuthzGrpc
フィールドが追加され、gRPC API を使用して外部認可プロバイダーが設定されます。
1.2.2.4. Red Hat OpenShift Service Mesh バージョン 2.4.2 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.10 以降でサポートされます。
1.2.2.4.1. Red Hat OpenShift Service Mesh バージョン 2.4.2 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.16.7 |
Envoy プロキシー | 1.24.10 |
Jaeger | 1.42.0 |
Kiali | 1.65.7 |
1.2.2.5. Red Hat OpenShift Service Mesh バージョン 2.4.1 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.10 以降でサポートされます。
1.2.2.5.1. Red Hat OpenShift Service Mesh バージョン 2.4.1 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.16.5 |
Envoy プロキシー | 1.24.8 |
Jaeger | 1.42.0 |
Kiali | 1.65.7 |
1.2.2.6. Red Hat OpenShift Service Mesh バージョン 2.4 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.10 以降でサポートされます。
1.2.2.6.1. Red Hat OpenShift Service Mesh バージョン 2.4 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.16.5 |
Envoy プロキシー | 1.24.8 |
Jaeger | 1.42.0 |
Kiali | 1.65.6 |
1.2.2.6.2. クラスター全体のデプロイメント
この機能拡張により、クラスター全体のデプロイメントの一般利用可能なバージョンが導入されます。クラスター全体のデプロイメントには、クラスター全体のリソースを監視する Service Mesh Control Plane が含まれます。コントロールプレーンは、すべての namespace で単一のクエリーを使用して、メッシュ設定に影響を与える各 Istio または Kubernetes リソースの種類を監視します。クラスター全体のデプロイメントでコントロールプレーンが実行するクエリーの数を減らすと、パフォーマンスが向上します。
1.2.2.6.3. ディスカバリーセレクターのサポート
この機能強化により、meshConfig.discoverySelectors
フィールドの一般利用可能なバージョンが導入され、これをクラスター全体のデプロイメントで使用して、Service Mesh コントロールプレーンが検出できるサービスを制限できます。
spec: meshConfig discoverySelectors: - matchLabels: env: prod region: us-east1 - matchExpressions: - key: app operator: In values: - cassandra - spark
1.2.2.6.4. cert-manager istio-csr との統合
この更新により、Red Hat OpenShift Service Mesh は cert-manager
コントローラーおよび istio-csr
エージェントと統合されます。cert-manager
は、証明書と証明書発行者を Kubernetes クラスター内のリソースタイプとして追加し、それらの証明書の取得、更新、使用のプロセスを簡素化します。cert-manager
は、Istio の中間 CA 証明書を提供し、ローテーションします。istio-csr
との統合により、ユーザーは Istio プロキシーからの署名証明書要求を cert-manager
に委任できます。ServiceMeshControlPlane
v2.4 は cert-manager
によって提供された CA 証明書を cacerts
シークレットとして受け入れます。
cert-manager
および istio-csr
との統合は、IBM Power、IBM Z、および IBM® LinuxONE ではサポートされていません。
1.2.2.6.5. 外部認証システムとの統合
この機能強化により、AuthorizationPolicy
リソースの action:CUSTOM
フィールドを使用して、Red Hat OpenShift Service Mesh を外部認可システムと統合する一般に利用可能な方法が導入されました。envoyExtAuthzHttp
フィールドを使用して、アクセス制御を外部認証システムに委任します。
1.2.2.6.6. 外部 Prometheus インストールとの統合
この機能拡張により、Prometheus 拡張プロバイダーの一般利用可能なバージョンが導入されます。spec.meshConfig
仕様で extensionProviders
フィールドの値を prometheus
に設定することで、OpenShift Container Platform モニタリングスタックまたはカスタム Prometheus インストールにメトリックを公開できます。テレメトリーオブジェクトは、トラフィックメトリックを収集するように Istio プロキシーを設定します。Service Mesh は、Prometheus メトリックの Telemetry API のみをサポートします。
spec: meshConfig: extensionProviders: - name: prometheus prometheus: {} --- apiVersion: telemetry.istio.io/v1alpha1 kind: Telemetry metadata: name: enable-prometheus-metrics spec: metrics: - providers: - name: prometheus
1.2.2.6.7. シングルスタック IPv6 のサポート
この機能拡張により、シングルスタック IPv6 クラスターの一般利用可能なサポートが導入され、より広範囲の IP アドレスへのアクセスが提供されます。デュアルスタック IPv4 または IPv6 クラスターはサポートされていません。
シングルスタック IPv6 サポートは、IBM Power、IBM Z、および IBM® LinuxONE では利用できません。
1.2.2.6.8. OpenShift Container Platform Gateway API のサポート
OpenShift Container Platform Gateway API のサポートはテクノロジープレビュー機能としてのみご利用いただけます。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
この機能強化により、OpenShift Container Platform Gateway API の更新されたテクノロジープレビューバージョンが導入されます。デフォルトでは、OpenShift Container Platform Gateway API は無効になっています。
1.2.2.6.8.1. OpenShift Container Platform Gateway API の有効化
OpenShift Container Platform Gateway API を有効にするには、ServiceMeshControlPlane
リソースの techPreview.gatewayAPI
仕様で、enabled
フィールドの値を true
に設定します。
spec: techPreview: gatewayAPI: enabled: true
以前は、ゲートウェイ API を有効にするために環境変数が使用されていました。
spec: runtime: components: pilot: container: env: PILOT_ENABLE_GATEWAY_API: "true" PILOT_ENABLE_GATEWAY_API_STATUS: "true" PILOT_ENABLE_GATEWAY_API_DEPLOYMENT_CONTROLLER: "true"
1.2.2.6.9. インフラストラクチャーノードへのコントロールプレーンのデプロイメント
Service Mesh コントロールプレーンのデプロイメントが OpenShift インフラストラクチャーノードでサポートされ、文書化されるようになりました。詳細は、以下のドキュメントを参照してください。
- すべての Service Mesh コントロールプレーンコンポーネントをインフラストラクチャーノード上で実行するための設定
- 個別の Service Mesh コントロールプレーンコンポーネントをインフラストラクチャーノード上で実行するための設定
1.2.2.6.10. Istio 1.16 サポート
Service Mesh 2.4 は Istio 1.16 に基づいており、新機能と製品の機能強化をもたらします。多くの Istio 1.16 機能がサポートされていますが、次の例外に注意する必要があります。
- サイドカーの HBONE プロトコルは実験的な機能であり、サポートされていません。
- ARM64 アーキテクチャー上の Service Mesh はサポートされていません。
- OpenTelemetry API は引き続きテクノロジープレビュー機能です。
1.2.2.7. Red Hat OpenShift Service Mesh バージョン 2.3.9 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.11 以降でサポートされます。
1.2.2.7.1. Red Hat OpenShift Service Mesh バージョン 2.3.9 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.14.5 |
Envoy プロキシー | 1.22.11 |
Jaeger | 1.47.0 |
Kiali | 1.57.14 |
1.2.2.8. Red Hat OpenShift Service Mesh バージョン 2.3.8 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.11 以降でサポートされます。
1.2.2.8.1. Red Hat OpenShift Service Mesh バージョン 2.3.8 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.14.5 |
Envoy プロキシー | 1.22.11 |
Jaeger | 1.47.0 |
Kiali | 1.57.13 |
1.2.2.9. Red Hat OpenShift Service Mesh バージョン 2.3.7 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.10 以降でサポートされます。
1.2.2.9.1. Red Hat OpenShift Service Mesh バージョン 2.3.7 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.14.6 |
Envoy プロキシー | 1.22.11 |
Jaeger | 1.42.0 |
Kiali | 1.57.11 |
1.2.2.10. Red Hat OpenShift Service Mesh バージョン 2.3.6 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.10 以降でサポートされます。
1.2.2.10.1. Red Hat OpenShift Service Mesh バージョン 2.3.6 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.14.5 |
Envoy プロキシー | 1.22.11 |
Jaeger | 1.42.0 |
Kiali | 1.57.10 |
1.2.2.11. Red Hat OpenShift Service Mesh バージョン 2.3.5 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.10 以降でサポートされます。
1.2.2.11.1. Red Hat OpenShift Service Mesh バージョン 2.3.5 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.14.5 |
Envoy プロキシー | 1.22.9 |
Jaeger | 1.42.0 |
Kiali | 1.57.10 |
1.2.2.12. Red Hat OpenShift Service Mesh バージョン 2.3.4 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.10 以降でサポートされます。
1.2.2.12.1. Red Hat OpenShift Service Mesh バージョン 2.3.4 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.14.6 |
Envoy プロキシー | 1.22.9 |
Jaeger | 1.42.0 |
Kiali | 1.57.9 |
1.2.2.13. Red Hat OpenShift Service Mesh バージョン 2.3.3 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.9 以降でサポートされます。
1.2.2.13.1. Red Hat OpenShift Service Mesh バージョン 2.3.3 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.14.5 |
Envoy プロキシー | 1.22.9 |
Jaeger | 1.42.0 |
Kiali | 1.57.7 |
1.2.2.14. Red Hat OpenShift Service Mesh バージョン 2.3.2 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.9 以降でサポートされます。
1.2.2.14.1. Red Hat OpenShift Service Mesh バージョン 2.3.2 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.14.5 |
Envoy プロキシー | 1.22.7 |
Jaeger | 1.39 |
Kiali | 1.57.6 |
1.2.2.15. Red Hat OpenShift Service Mesh バージョン 2.3.1 の新機能
Red Hat OpenShift Service Mesh の本リリースには、新機能の導入、CVE (Common Vulnerabilities and Exposures) への対応、バグ修正が含まれ、OpenShift Container Platform 4.9 以降でサポートされます。
1.2.2.15.1. Red Hat OpenShift Service Mesh バージョン 2.3.1 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.14.5 |
Envoy プロキシー | 1.22.4 |
Jaeger | 1.39 |
Kiali | 1.57.5 |
1.2.2.16. Red Hat OpenShift Service Mesh バージョン 2.3 の新機能
Red Hat OpenShift Service Mesh の本リリースには、新機能の導入、CVE (Common Vulnerabilities and Exposures) への対応、バグ修正が含まれ、OpenShift Container Platform 4.9 以降でサポートされます。
1.2.2.16.1. Red Hat OpenShift Service Mesh バージョン 2.3 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.14.3 |
Envoy プロキシー | 1.22.4 |
Jaeger | 1.38 |
Kiali | 1.57.3 |
1.2.2.16.2. 新しい Container Network Interface (CNI) DaemonSet コンテナーと ConfigMap
openshift-operators
namespace には、新しい istio CNI DaemonSet istio-cni-node-v2-3
、新しい ConfigMap
リソース、istio-cni-config-v2-3
が含まれています。
Service Mesh Control Plane 2.3 にアップグレードすると、既存の istio-cni-node
DaemonSet は変更されず、新しい istio-cni-node-v2-3
DaemonSet が作成されます。
この名称変更は、以前のリリースや、以前のリリースを使用してデプロイされた Service Mesh Control Plane に関連付けられた istio-cni-node
CNI DaemonSet には影響しません。
1.2.2.16.3. ゲートウェイ挿入のサポート
このリリースでは、ゲートウェイ挿入の一般利用可能なサポートが導入されています。ゲートウェイ設定は、サービスワークロードとともに実行するサイドカー Envoy プロキシーではなく、メッシュのエッジで実行するスタンドアロン Envoy プロキシーに適用されます。これにより、ゲートウェイオプションのカスタマイズ機能が有効になります。ゲートウェイ挿入を使用する場合は、ゲートウェイプロキシーを実行する namespace にリソース (Service
、Deployment
、Role
、および RoleBinding
) を作成する必要があります。
1.2.2.16.4. Istio 1.14 サポート
Service Mesh 2.3 は Istio 1.14 に基づいており、新機能と製品の機能強化をもたらします。多くの Istio 1.14 機能がサポートされていますが、次の例外に注意する必要があります。
- ProxyConfig API はサポートされていますが、image フィールドは例外です。
- Telemetry API はテクノロジープレビュー機能です。
- SPIRE ランタイムはサポートされていない機能です。
1.2.2.16.5. OpenShift Service Mesh Console
OpenShift Service Mesh コンソールはテクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
このリリースでは、Kiali インターフェイスを OpenShift Web コンソールに直接統合する OpenShift Container Platform Service Mesh Console のテクノロジープレビューバージョンが導入されています。追加情報は、OpenShift Service Mesh コンソールの紹介 (テクノロジープレビュー) を参照してください。
1.2.2.16.6. クラスター全体のデプロイメント
クラスター全体のデプロイメントは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
このリリースでは、テクノロジープレビュー機能としてクラスター全体のデプロイメントが導入されています。クラスター全体のデプロイメントには、クラスター全体のリソースを監視する Service Mesh Control Plane が含まれます。コントロールプレーンは、すべての namespace で単一のクエリーを使用して、メッシュ設定に影響を与える各 Istio または Kubernetes リソースの種類を監視します。対照的に、マルチテナントアプローチでは、リソースの各種類で namespace ごとにクエリーを使用します。クラスター全体のデプロイメントでコントロールプレーンが実行するクエリーの数を減らすと、パフォーマンスが向上します。
このクラスター全体のデプロイメントドキュメントは、SMCP v2.3 を使用してデプロイメントされたコントロールプレーンにのみ適用されます。SMCP v2.3 を使用して作成されたクラスター全体のデプロイメントは、SMCP v2.4 を使用して作成されたクラスター全体のデプロイメントと互換性がありません。
1.2.2.16.6.1. クラスター全体のデプロイメントの設定
次の ServiceMeshControlPlane
オブジェクトの例では、クラスター全体のデプロイを設定します。
クラスター全体のデプロイメント用に SMCP を作成する場合、ユーザーは cluster-admin
ClusterRole に属している必要があります。SMCP がクラスター全体のデプロイメント用に設定されている場合は、それがクラスター内の唯一の SMCP である必要があります。コントロールプレーンモードをマルチテナントからクラスター全体 (またはクラスター全体からマルチテナント) に変更することはできません。マルチテナントコントロールプレーンがすでに存在する場合は、それを削除して、新しいコントロールプレーンを作成します。
この例では、クラスター全体のデプロイメント用に SMCP を設定します。
apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
name: cluster-wide
namespace: istio-system
spec:
version: v2.3
techPreview:
controlPlaneMode: ClusterScoped 1
- 1
- Istiod が、個々の namespace を監視するのではなく、クラスターレベルでリソースを監視できるようにします。
さらに、SMMR もクラスター全体のデプロイメント用に設定する必要があります。この例では、クラスター全体のデプロイメント用に SMMR を設定します。
apiVersion: maistra.io/v1
kind: ServiceMeshMemberRoll
metadata:
name: default
spec:
members:
- '*' 1
- 1
- 後で作成する namespace を含め、すべての namespace をメッシュに追加します。kube、openshift、kube-*、および openshift-* の namespace は、メッシュの一部ではありません。
1.2.2.17. Red Hat OpenShift Service Mesh バージョン 2.2.12 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.11 以降でサポートされます。
1.2.2.17.1. Red Hat OpenShift Service Mesh バージョン 2.2.12 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.12.9 |
Envoy プロキシー | 1.20.8 |
Jaeger | 1.47.0 |
Kiali | 1.48.11 |
1.2.2.18. Red Hat OpenShift Service Mesh バージョン 2.2.11 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.11 以降でサポートされます。
1.2.2.18.1. Red Hat OpenShift Service Mesh バージョン 2.2.11 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.12.9 |
Envoy プロキシー | 1.20.8 |
Jaeger | 1.47.0 |
Kiali | 1.48.10 |
1.2.2.19. Red Hat OpenShift Service Mesh バージョン 2.2.10 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.10 以降でサポートされます。
1.2.2.19.1. Red Hat OpenShift Service Mesh バージョン 2.2.10 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.12.9 |
Envoy プロキシー | 1.20.8 |
Jaeger | 1.42.0 |
Kiali | 1.48.8 |
1.2.2.20. Red Hat OpenShift Service Mesh バージョン 2.2.9 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.10 以降でサポートされます。
1.2.2.20.1. Red Hat OpenShift Service Mesh バージョン 2.2.9 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.12.9 |
Envoy プロキシー | 1.20.8 |
Jaeger | 1.42.0 |
Kiali | 1.48.7 |
1.2.2.21. Red Hat OpenShift Service Mesh バージョン 2.2.8 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.10 以降でサポートされます。
1.2.2.21.1. Red Hat OpenShift Service Mesh バージョン 2.2.8 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.12.9 |
Envoy プロキシー | 1.20.8 |
Jaeger | 1.42.0 |
Kiali | 1.48.7 |
1.2.2.22. Red Hat OpenShift Service Mesh バージョン 2.2.7 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.10 以降でサポートされます。
1.2.2.22.1. Red Hat OpenShift Service Mesh バージョン 2.2.7 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.12.9 |
Envoy プロキシー | 1.20.8 |
Jaeger | 1.42.0 |
Kiali | 1.48.6 |
1.2.2.23. Red Hat OpenShift Service Mesh バージョン 2.2.6 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.9 以降でサポートされます。
1.2.2.23.1. Red Hat OpenShift Service Mesh バージョン 2.2.6 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.12.9 |
Envoy プロキシー | 1.20.8 |
Jaeger | 1.39 |
Kiali | 1.48.5 |
1.2.2.24. Red Hat OpenShift Service Mesh バージョン 2.2.5 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.9 以降でサポートされます。
1.2.2.24.1. Red Hat OpenShift Service Mesh バージョン 2.2.5 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.12.9 |
Envoy プロキシー | 1.20.8 |
Jaeger | 1.39 |
Kiali | 1.48.3 |
1.2.2.25. Red Hat OpenShift Service Mesh バージョン 2.2.4 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.9 以降でサポートされます。
1.2.2.25.1. Red Hat OpenShift Service Mesh バージョン 2.2.4 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.12.9 |
Envoy プロキシー | 1.20.8 |
Jaeger | 1.36.14 |
Kiali | 1.48.3 |
1.2.2.26. Red Hat OpenShift Service Mesh バージョン 2.2.3 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.9 以降でサポートされます。
1.2.2.26.1. Red Hat OpenShift Service Mesh バージョン 2.2.3 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.12.9 |
Envoy プロキシー | 1.20.8 |
Jaeger | 1.36 |
Kiali | 1.48.3 |
1.2.2.27. Red Hat OpenShift Service Mesh バージョン 2.2.2 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.9 以降でサポートされます。
1.2.2.27.1. Red Hat OpenShift Service Mesh バージョン 2.2.2 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.12.7 |
Envoy プロキシー | 1.20.6 |
Jaeger | 1.36 |
Kiali | 1.48.2-1 |
1.2.2.27.2. ルートラベルのコピー
この機能強化により、アノテーションのコピーに加えて、OpenShift ルートの特定のラベルをコピーできます。Red Hat OpenShift Service Mesh は、Istio Gateway リソースに存在するすべてのラベルとアノテーション (kubectl.kubernetes.io で始まるアノテーションを除く) をマネージドの OpenShift Route リソースにコピーします。
1.2.2.28. Red Hat OpenShift Service Mesh バージョン 2.2.1 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.9 以降でサポートされます。
1.2.2.28.1. Red Hat OpenShift Service Mesh バージョン 2.2.1 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.12.7 |
Envoy プロキシー | 1.20.6 |
Jaeger | 1.34.1 |
Kiali | 1.48.2-1 |
1.2.2.29. Red Hat OpenShift Service Mesh 2.2 の新機能
このリリースの Red Hat Service Mesh は、新しい機能と拡張機能を追加し、OpenShift Container Platform 4.9 以降でサポートされています。
1.2.2.29.1. Red Hat OpenShift Service Mesh バージョン 2.2 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.12.7 |
Envoy プロキシー | 1.20.4 |
Jaeger | 1.34.1 |
Kiali | 1.48.0.16 |
1.2.2.29.2. WasmPlugin
API
このリリースでは、WasmPlugin
API のサポートが追加され、ServiceMeshExtension
が非推奨になりました。
1.2.2.29.3. ROSA サポート
このリリースでは、マルチクラスターフェデレーションを含む Red Hat OpenShift on AWS (ROSA) の Service Mesh サポートが導入されています。
1.2.2.29.4. istio-node
DaemonSet の名前変更
このリリースでは、istio-node
DaemonSet の名前が istio-cni-node
に変更になり、アップストリーム Istio の名前と同じになりました。
1.2.2.29.5. エンボイサイドカーネットワークの変更
Istio 1.10 は、デフォルトで lo
ではなく eth0
を使用してトラフィックをアプリケーションコンテナーに送信するように Envoy を更新しました。
1.2.2.29.6. Service Mesh コントロールプレーン 1.1
このリリースは、すべてのプラットフォームでの Service Mesh 1.1 に基づく Service Mesh コントロールプレーンのサポートの終了を示します。
1.2.2.29.7. Istio 1.12 サポート
Service Mesh 2.2 は Istio 1.12 に基づいており、新機能と製品の機能強化をもたらします。多くの Istio 1.12 機能がサポートされていますが、サポートされていない次の機能に注意する必要があります。
- AuthPolicy ドライランはテクノロジープレビュー機能です。
- gRPC Proxyless Service Mesh は、テクノロジープレビュー機能です。
- Telemetry API は、テクノロジープレビュー機能です。
- ディスカバリーセレクターはサポート対象外の機能です。
- 外部コントロールプレーンはサポート対象外の機能です。
- ゲートウェイインジェクションはサポート対象外の機能です。
1.2.2.29.8. Kubernetes Gateway API
Kubernetes Gateway API はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
Kubernetes Gateway API は、デフォルトで無効になっているテクノロジープレビュー機能です。Kubernetes API デプロイメントコントローラーが無効になっている場合は、ingress ゲートウェイを手動でデプロイし、作成されたゲートウェイオブジェクトにリンクする必要があります。
Kubernetes API デプロイコントローラーが有効になっている場合は、ゲートウェイオブジェクトが作成されると、ingress ゲートウェイが自動的にデプロイされます。
1.2.2.29.8.1. Gateway API CRD のインストール
Gateway API CRD は、デフォルトでは OpenShift クラスターにプリインストールされていません。SMCP で Gateway API サポートを有効にする前に、CRD をインストールします。
$ kubectl get crd gateways.gateway.networking.k8s.io || { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.4.0" | kubectl apply -f -; }
1.2.2.29.8.2. Kubernetes Gateway API の有効化
この機能を有効にするには、ServiceMeshControlPlane
で Istiod
コンテナーに次の環境変数を設定します。
spec: runtime: components: pilot: container: env: PILOT_ENABLE_GATEWAY_API: "true" PILOT_ENABLE_GATEWAY_API_STATUS: "true" # and optionally, for the deployment controller PILOT_ENABLE_GATEWAY_API_DEPLOYMENT_CONTROLLER: "true"
ゲートウェイ API リスナーでのルート接続を制限するには、SameNamespace
または All
設定を使用します。Istio は、listeners.allowedRoutes.namespaces
のラベルセレクターの使用を無視し、デフォルトの動作 (SameNamespace
) に戻します。
1.2.2.29.8.3. 手動によるゲートウェイリソースへの既存ゲートウェイのリンク
Kubernetes API デプロイメントコントローラーが無効になっている場合は、ingress ゲートウェイを手動でデプロイし、作成されたゲートウェイリソースにリンクする必要があります。
apiVersion: gateway.networking.k8s.io/v1alpha2 kind: Gateway metadata: name: gateway spec: addresses: - value: ingress.istio-gateways.svc.cluster.local type: Hostname
1.2.2.30. Red Hat OpenShift Service Mesh 2.1.6 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.9 以降でサポートされます。
1.2.2.30.1. Red Hat OpenShift Service Mesh バージョン 2.1.6 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.9.9 |
Envoy プロキシー | 1.17.5 |
Jaeger | 1.36 |
Kiali | 1.36.16 |
1.2.2.31. Red Hat OpenShift Service Mesh 2.1.5.2 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.9 以降でサポートされます。
1.2.2.31.1. Red Hat OpenShift Service Mesh バージョン 2.1.5.2 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.9.9 |
Envoy プロキシー | 1.17.5 |
Jaeger | 1.36 |
Kiali | 1.24.17 |
1.2.2.32. Red Hat OpenShift Service Mesh 2.1.5.1 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.9 以降でサポートされます。
1.2.2.32.1. Red Hat OpenShift Service Mesh バージョン 2.1.5.1 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.9.9 |
Envoy プロキシー | 1.17.5 |
Jaeger | 1.36 |
Kiali | 1.36.13 |
1.2.2.33. Red Hat OpenShift Service Mesh 2.1.5 の新機能
Red Hat OpenShift Service Mesh の本リリースには、CVE (Common Vulnerabilities and Exposures) への対応とバグ修正が含まれ、OpenShift Container Platform 4.9 以降でサポートされます。
1.2.2.33.1. Red Hat OpenShift Service Mesh バージョン 2.1.5 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.9.9 |
Envoy プロキシー | 1.17.1 |
Jaeger | 1.36 |
Kiali | 1.36.12-1 |
1.2.2.34. Red Hat OpenShift Service Mesh 2.1.4 の新機能
このリリースの Red Hat OpenShift Service Mesh では、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。
1.2.2.34.1. Red Hat OpenShift Service Mesh バージョン 2.1.4 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.9.9 |
Envoy プロキシー | 1.17.1 |
Jaeger | 1.30.2 |
Kiali | 1.36.12-1 |
1.2.2.35. Red Hat OpenShift Service Mesh 2.1.3 の新機能
このリリースの Red Hat OpenShift Service Mesh では、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。
1.2.2.35.1. Red Hat OpenShift Service Mesh バージョン 2.1.3 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.9.9 |
Envoy プロキシー | 1.17.1 |
Jaeger | 1.30.2 |
Kiali | 1.36.10-2 |
1.2.2.36. Red Hat OpenShift Service Mesh 2.1.2.1 の新機能
このリリースの Red Hat OpenShift Service Mesh では、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。
1.2.2.36.1. Red Hat OpenShift Service Mesh バージョン 2.1.2.1 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.9.9 |
Envoy プロキシー | 1.17.1 |
Jaeger | 1.30.2 |
Kiali | 1.36.9 |
1.2.2.37. Red Hat OpenShift Service Mesh 2.1.2 の新機能
このリリースの Red Hat OpenShift Service Mesh では、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。
このリリースでは、Red Hat 分散トレースプラットフォーム (Jaeger) Operator がデフォルトで openshift-distributed-tracing
namespace にインストールされるようになりました。以前のリリースでは、デフォルトのインストールは openshift-operator
namespace にありました。
1.2.2.37.1. Red Hat OpenShift Service Mesh バージョン 2.1.2 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.9.9 |
Envoy プロキシー | 1.17.1 |
Jaeger | 1.30.1 |
Kiali | 1.36.8 |
1.2.2.38. Red Hat OpenShift Service Mesh 2.1.1 の新機能
このリリースの Red Hat OpenShift Service Mesh では、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。
このリリースでは、ネットワークポリシーの自動作成を無効にする機能も追加されています。
1.2.2.38.1. Red Hat OpenShift Service Mesh バージョン 2.1.1 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.9.9 |
Envoy プロキシー | 1.17.1 |
Jaeger | 1.24.1 |
Kiali | 1.36.7 |
1.2.2.38.2. ネットワークポリシーの無効化
Red Hat OpenShift Service Mesh は、Service Mesh コントロールプレーンおよびアプリケーションネームスペースで多数の NetworkPolicies
リソースを自動的に作成し、管理します。これは、アプリケーションとコントロールプレーンが相互に通信できるようにするために使用されます。
NetworkPolicies
リソースの自動作成および管理を無効にする場合 (例: 会社のセキュリティーポリシーを適用する場合など) は、これを実行できます。ServiceMeshControlPlane
を編集して spec.security.manageNetworkPolicy
設定を false
に設定できます。
spec.security.manageNetworkPolicy
を無効にすると、Red Hat OpenShift Service Mesh は、NetworkPolicy
オブジェクトをひとつも作成しません。システム管理者は、ネットワークを管理し、この原因の問題を修正します。
手順
- OpenShift Container Platform Web コンソールで、Operators → Installed Operators をクリックします。
-
Project メニューから、Service Mesh コントロールプレーンをインストールしたプロジェクト (例:
istio-system
) を選択します。 -
Red Hat OpenShift Service Mesh Operator をクリックします。Istio Service Mesh Control Plane 列で、
ServiceMeshControlPlane
の名前 (basic-install
など) をクリックします。 -
Create ServiceMeshControlPlane Details ページで、
YAML
をクリックして設定を変更します。 以下の例のように、
ServiceMeshControlPlane
フィールドspec.security.manageNetworkPolicy
をfalse
に設定します。apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane spec: security: trust: manageNetworkPolicy: false
- Save をクリックします。
1.2.2.39. Red Hat OpenShift Service Mesh 2.1 の新機能および機能拡張
Red Hat OpenShift Service Mesh の本リリースでは、Istio 1.9.8、Envoy Proxy 1.17.1、Jaeger 1.24.1、および Kiali 1.36.5 のサポートと新機能および機能拡張が OpenShift Container Platform 4.6 EUS、4.7、4.8、および 4.9 で追加されました。
1.2.2.39.1. Red Hat OpenShift Service Mesh バージョン 2.1 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.9.6 |
Envoy プロキシー | 1.17.1 |
Jaeger | 1.24.1 |
Kiali | 1.36.5 |
1.2.2.39.2. Service Mesh のフェデレーション
Service Mesh をフェデレーションできるように新規のカスタムリソース定義 (CRD) が追加されました。Service Mesh は、同じクラスター内または異なる OpenShift クラスター間でフェデレーションを行うことができます。これらの新規リソースには以下が含まれます。
-
ServiceMeshPeer
: ゲートウェイ設定、ルート信頼証明書設定、ステータスフィールドなど、別の Service Mesh でのフェデレーションを定義します。フェデレーションされたメッシュのペアでは、各メッシュは独自のServiceMeshPeer
リソースを個別に定義します。 -
ExportedServiceMeshSet
: ピアメッシュのインポートに利用できる特定のServiceMeshPeer
サービスを定義します。 -
ImportedServiceSet
: ピアメッシュからインポートする特定のServiceMeshPeer
のサービスを定義します。これらのサービスは、ピアのExportedServiceMeshSet
リソースで利用できるようにする必要もあります。
Service Mesh Federation は、Red Hat OpenShift Service on AWS (ROSA)、Azure Red Hat OpenShift (ARO)、または OpenShift Dedicated (OSD) のクラスター間ではサポートされていません。
1.2.2.39.3. OVN-Kubernetes Container Network Interface(CNI) の一般提供
OVN-Kubernetes Container Network Interface(CNI) は、以前は Red Hat OpenShift Service Mesh 2.0.1 のテクノロジープレビュー機能として導入されましたが、OpenShift Container Platform 4.7.32、OpenShift Container Platform 4.8.12、および OpenShift Container Platform 4.9 で使用できるように Red Hat OpenShift Service Mesh 2.1 および 2.0.x で一般提供されています。
1.2.2.39.4. Service Mesh WebAssembly(WASM) 拡張
ServiceMeshExtensions
カスタムリソース定義 (CRD) は、最初に 2.0 でテクノロジープレビュー機能として導入され、今回のバージョンで一般公開されました。CRD を使用して独自のプラグインを構築できますが、Red Hat では独自に作成したプラグインはサポートしていません。
Mixer は Service Mesh 2.1 で完全に削除されました。Mixer が有効な場合は、Service Mesh 2.0.x リリースから 2.1 へのアップグレードは、ブロックされます。Mixer プラグインは WebAssembly 拡張に移植する必要があります。
1.2.2.39.5. 3scale WebAssembly Adapter (WASM)
Mixer が正式に削除されたため、OpenShift 3scale mixer アダプターは、Service Mesh 2.1 ではサポート対象外となっています。Service Mesh 2.1 にアップグレードする前に、Mixer ベースの 3scale アダプターと追加の Mixer プラグインを削除します。次に、ServiceMeshExtension
リソースを使用して、新しい 3scale WebAssembly アダプターを Service Mesh 2.1 以上で手動でインストールして設定します。
3scale 2.11 では、WebAssembly
に基づく更新された Service Mesh の統合が導入されました。
1.2.2.39.6. Istio 1.9 サポート
Service Mesh 2.1 は Istio 1.9 をベースとしており、製品の新機能および機能拡張が数多く追加されました。Istio 1.9 の大半の機能がサポートされていますが、以下の例外に注意してください。
- 仮想マシンの統合はまだサポートされていません。
- Kubernetes Gateway API はまだサポートされていません。
- WebAssembly HTTP フィルターのリモートフェッチおよびロードはサポートされていません。
- Kubernetes CSR API を使用したカスタム CA 統合はまだサポートされていません。
- トラフィック監視要求の分類機能はテクノロジープレビュー機能です。
- Authorization ポリシーの CUSTOM アクションによる外部承認システムとの統合はテクノロジープレビュー機能です。
1.2.2.39.7. Service Mesh Operator のパフォーマンス向上
各 ServiceMeshControlPlane
の調整の終了時に以前のリソースのプルーニングに使用する期間が短縮されました。これにより、ServiceMeshControlPlane
のデプロイメントにかかる時間が短縮され、既存の SMCP に適用される変更がこれまでよりも早く有効になります。
1.2.2.39.8. Kiali の更新
Kiali 1.36 には、以下の機能と拡張機能が含まれています。
Service Mesh のトラブルシューティング機能
- コントロールプレーンおよびゲートウェイの監視
- プロキシーの同期ステータス
- Envoy 設定ビュー
- Envoy プロキシーおよびアプリケーションログのインターリーブを示す統合ビュー
- フェデレーションされた Service Mesh ビューをサポートする namespace およびクラスターボックス
- 新しい検証、ウィザード、および分散トレースの機能拡張
1.2.2.40. Red Hat OpenShift Service Mesh 2.0.11.1 の新機能
Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応し、OpenShift Container Platform 4.9 以降でサポートされます。
1.2.2.40.1. Red Hat OpenShift Service Mesh バージョン 2.0.11.1 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.6.14 |
Envoy プロキシー | 1.14.5 |
Jaeger | 1.36 |
Kiali | 1.24.17 |
1.2.2.41. Red Hat OpenShift Service Mesh 2.0.11 の新機能
Red Hat OpenShift Service Mesh の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応し、OpenShift Container Platform 4.9 以降でサポートされます。
1.2.2.41.1. Red Hat OpenShift Service Mesh バージョン 2.0.11 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.6.14 |
Envoy プロキシー | 1.14.5 |
Jaeger | 1.36 |
Kiali | 1.24.16-1 |
1.2.2.42. Red Hat OpenShift Service Mesh 2.0.10 の新機能
このリリースの Red Hat OpenShift Service Mesh では、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。
1.2.2.42.1. Red Hat OpenShift Service Mesh バージョン 2.0.10 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.6.14 |
Envoy プロキシー | 1.14.5 |
Jaeger | 1.28.0 |
Kiali | 1.24.16-1 |
1.2.2.43. Red Hat OpenShift Service Mesh 2.0.9 の新機能
このリリースの Red Hat OpenShift Service Mesh では、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。
1.2.2.43.1. Red Hat OpenShift Service Mesh バージョン 2.0.9 に含まれるコンポーネントのバージョン
コンポーネント | バージョン |
---|---|
Istio | 1.6.14 |
Envoy プロキシー | 1.14.5 |
Jaeger | 1.24.1 |
Kiali | 1.24.11 |
1.2.2.44. Red Hat OpenShift Service Mesh 2.0.8 の新機能
このリリースの Red Hat OpenShift Service Mesh では、バグ修正に対応しています。
1.2.2.45. Red Hat OpenShift Service Mesh 2.0.7.1 の新機能
このリリースの Red Hat OpenShift Service Mesh では、CVE (Common Vulnerabilities and Exposures) に対応しています。
1.2.2.45.1. Red Hat OpenShift Service Mesh が URI フラグメントを処理する方法の変更
Red Hat OpenShift Service Mesh には、リモートで悪用可能な脆弱性 CVE-2021-39156 が含まれており、URI パスにフラグメント (URI の末尾が # 文字で始まるセクション) を含む HTTP リクエストが Istio URI パスベースの認証ポリシーを無視する可能性があります。たとえば、Istio 認証ポリシーは URI パス /user/profile
に送信される要求を拒否します。脆弱なバージョンでは、URI パス /user/profile#section1
のリクエストは、deny ポリシーと、(正規化された URI path /user/profile%23section1
を使用する) バックエンドへのルートを無視するため、セキュリティーのインシデントにつながる可能性があります。
DENY アクションおよび operation.paths
、または ALLOW アクションおよび operation.notPaths
で認可ポリシーを使用する場合は、この脆弱性の影響を受けます。
軽減策により、リクエストの URI の断片部分が、承認とルーティングの前に削除されます。これにより、URI のフラグメントを持つ要求が、フラグメントの一部のない URI をベースとする認可ポリシーが無視できなくなります。
軽減策の新しい動作からオプトインするには、URI の fragment セクションが保持されます。ServiceMeshControlPlane
を設定して URI フラグメントを保持できます。
新しい動作を無効にすると、上記のようにパスを正規化し、安全でないと見なされます。URI フラグメントを保持することを選択する前に、セキュリティーポリシーでこれに対応していることを確認してください。
ServiceMeshControlPlane
の変更例
apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane metadata: name: basic spec: techPreview: meshConfig: defaultConfig: proxyMetadata: HTTP_STRIP_FRAGMENT_FROM_PATH_UNSAFE_IF_DISABLED: "false"
1.2.2.45.2. 認証ポリシーに必要な更新
Istio はホスト名自体とすべての一致するポートの両方にホスト名を生成します。たとえば、httpbin.foo のホストの仮想サービスまたはゲートウェイは、httpbin.foo and httpbin.foo:* に一致する設定を生成します。ただし、完全一致許可ポリシーは、hosts
または notHosts
フィールドに指定された完全一致文字列にのみ一致します。
ルールの正確な文字列比較を使用して hosts または notHosts を決定する AuthorizationPolicy
リソースがある場合、クラスターは影響を受けます。
完全一致ではなく接頭辞一致を使用するように、認証ポリシー ルール を更新する必要があります。たとえば、最初の AuthorizationPolicy
の例で hosts: ["httpbin.com"]
を hosts: ["httpbin.com:*"]
に置き換えます。
接頭辞一致を使用した最初の AuthorizationPolicy の例
apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: httpbin namespace: foo spec: action: DENY rules: - from: - source: namespaces: ["dev"] to: - operation: hosts: [“httpbin.com”,"httpbin.com:*"]
接頭辞一致を使用した 2 つ目の AuthorizationPolicy の例
apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: httpbin namespace: default spec: action: DENY rules: - to: - operation: hosts: ["httpbin.example.com:*"]
1.2.2.46. Red Hat OpenShift Service Mesh 2.0.7 の新機能
このリリースの Red Hat OpenShift Service Mesh では、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。
1.2.2.47. Red Hat OpenShift Dedicated および Microsoft Azure Red Hat OpenShift 上の Red Hat OpenShift Service Mesh
Red Hat OpenShift Service Mesh は、Red Hat OpenShift Dedicated および Microsoft Azure Red Hat OpenShift 経由でサポートされるようになりました。
1.2.2.48. Red Hat OpenShift Service Mesh 2.0.6 の新機能
このリリースの Red Hat OpenShift Service Mesh では、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。
1.2.2.49. Red Hat OpenShift Service Mesh 2.0.5 の新機能
このリリースの Red Hat OpenShift Service Mesh では、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。
1.2.2.50. Red Hat OpenShift Service Mesh 2.0.4 の新機能
このリリースの Red Hat OpenShift Service Mesh では、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。
CVE-2021-29492 および CVE-2021-31920 に対応するために、手動による手順を完了する必要があります。
1.2.2.50.1. CVE-2021-29492 および CVE-2021-31920 で必要な手動による更新
Istio にはリモートで悪用可能な脆弱性があり、複数のスラッシュまたはエスケープされたスラッシュ文字 (%2F
または %5C
) を持つ HTTP リクエストパスが、パスベースの認証ルールが使用される場合に Istio 認証ポリシーを無視する可能性があります。
たとえば、Istio クラスター管理者が、パス /admin
での要求を拒否する認証 DENY ポリシーを定義すると仮定します。URL パス //admin
に送信される要求は、認証ポリシーには拒否されません。
RFC 3986 に応じて、複数のスラッシュを持つパス //admin
は、/admin
とは異なるパスとして処理される必要があります。ただし、一部のバックエンドサービスは、複数のスラッシュを単一のスラッシュにマージして URL パスを正規化することを選択します。これにより、認証ポリシーがバイパスされ (//admin
は /admin
に一致しない)、ユーザーはバックエンドのパス (/admin
) でリソースにアクセスできます。これは、セキュリティーのインシデントを表します。
ALLOW action + notPaths
フィールドまたは DENY action + paths field
パターンを使用する認証ポリシーがある場合、クラスターはこの脆弱性の影響を受けます。これらのパターンは、予期しないポリシーのバイパスに対して脆弱です。
以下の場合、クラスターはこの脆弱性の影響を受けません。
- 認証ポリシーがありません。
-
認証ポリシーは、
paths
フィールドまたはnotPaths
フィールドを定義しません。 -
認証ポリシーは、
ALLOW action + paths
フィールドまたはDENY action + notPaths
フィールドのパターンを使用します。これらのパターンは、ポリシーのバイパスではなく、予期しない拒否を生じさせる可能性があります。このような場合、アップグレードは任意です。
パスの正規化向けの Red Hat OpenShift Service Mesh 設定の場所は、Istio 設定とは異なります。
1.2.2.50.2. パスの正規化設定の更新
Istio 認証ポリシーは、HTTP リクエストの URL パスをベースとする場合があります。URI の正規化として知られる パスの正規化 は、正規化されたパスを標準の方法で処理できるように、受信要求のパスを変更し、標準化します。構文の異なるパスは、パスの正規化後と同一になる場合があります。
Istio は、認証ポリシーに対して評価し、要求をルーティングする前の、要求パスでの以下の正規化スキームをサポートします。
オプション | 説明 | 例 | 注記 |
---|---|---|---|
| 正規化は行われません。Envoy が受信する内容はそのまますべて、どのバックエンドサービスにも完全に転送されます。 |
| この設定は CVE-2021-31920 に対して脆弱です。 |
|
現時点で、これは Istio の デフォルト インストールで使用されるオプションです。これにより、Envoy プロキシーで |
| この設定は CVE-2021-31920 に対して脆弱です。 |
| スラッシュは BASE の正規化後にマージされます。 |
| この設定に対して更新を行い、CVE-2021-31920 のリスクを軽減します。 |
|
デフォルトですべてのトラフィックを許可する場合の最も厳密な設定です。この設定の場合は、認証ポリシーのルートを詳細にテストする必要がある点に注意してください。パーセントでエンコードされた スラッシュおよびバックスラッシュ文字 ( |
| この設定に対して更新を行い、CVE-2021-31920 のリスクを軽減します。この設定はより安全ですが、アプリケーションが破損する可能性があります。実稼働環境にデプロイする前にアプリケーションをテストします。 |
正規化アルゴリズムは以下の順序で実行されます。
-
パーセントでデコードされた
%2F
、%2f
、%5C
および%5c
。 -
Envoy の
normalize_path
オプションで実装された RFC 3986 およびその他の正規化。 - スラッシュをマージします。
これらの正規化オプションは HTTP 標準および一般的な業界プラクティスの推奨事項を表しますが、アプリケーションは独自に選択したいずれかの方法で URL を解釈する場合があります。拒否ポリシーを使用する場合は、アプリケーションの動作を把握している必要があります。
1.2.2.50.3. パスの正規化設定の例
Envoy がバックエンドサービスの期待値に一致するように要求パスを正規化することは、システムのセキュリティーを保護する上で非常に重要です。以下の例は、システムを設定するための参考として使用できます。正規化された URL パス、または NONE
が選択されている場合、元の URL パスは以下のようになります。
- 認証ポリシーの確認に使用されます。
- バックエンドアプリケーションに転送されます。
アプリケーションの条件 | 選択内容 |
---|---|
プロキシーを使用して正規化を行う。 |
|
RFC 3986 に基づいて要求パスを正規化し、スラッシュをマージしない。 |
|
RFC 3986 に基づいて要求パスを正規化し、スラッシュをマージするが、パーセントでエンコードされた スラッシュをデコードしない。 |
|
RFC 3986 に基づいて要求パスを正規化し、パーセントでエンコードされた スラッシュをデコードし、スラッシュをマージする。 |
|
RFC 3986 と互換性のない方法で要求パスを処理する。 |
|
1.2.2.50.4. パスを正規化するための SMCP の設定
Red Hat OpenShift Service Mesh のパスの正規化を設定するには、ServiceMeshControlPlane
で以下を指定します。設定例を使用すると、システムの設定を判断するのに役立ちます。
SMCP v2 pathNormalization
spec: techPreview: global: pathNormalization: <option>
1.2.2.50.5. ケース正規化 (case normalization) の設定
環境によっては、大文字と小文字を区別しない場合の比較用に 2 つのパスを認証ポリシーに用意すると便利な場合があります。たとえば、https://myurl/get
と https://myurl/GeT
を同等なものとして扱います。このような場合は、以下に示されている EnvoyFilter
を使用できます。このフィルターは、比較用に使用されるパスとアプリケーションに表示されるパスの両方を変更します。この例では、istio-system
が Service Mesh コントロールプレーンプロジェクトの名前となります。
EnvoyFilter
をファイルに保存して、以下のコマンドを実行します。
$ oc create -f <myEnvoyFilterFile>
apiVersion: networking.istio.io/v1alpha3 kind: EnvoyFilter metadata: name: ingress-case-insensitive namespace: istio-system spec: configPatches: - applyTo: HTTP_FILTER match: context: GATEWAY listener: filterChain: filter: name: "envoy.filters.network.http_connection_manager" subFilter: name: "envoy.filters.http.router" patch: operation: INSERT_BEFORE value: name: envoy.lua typed_config: "@type": "type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua" inlineCode: | function envoy_on_request(request_handle) local path = request_handle:headers():get(":path") request_handle:headers():replace(":path", string.lower(path)) end
1.2.2.51. Red Hat OpenShift Service Mesh 2.0.3 の新機能
このリリースの Red Hat OpenShift Service Mesh では、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。
また、このリリースには以下の新機能があります。
-
指定された Service Mesh コントロールプレーン namespace から情報を収集する
must-gather
データ収集ツールにオプションが追加されました。詳細は、OSSM-351 を参照してください。 - 数百の namespace が含まれる Service Mesh コントロールプレーンのパフォーマンスの向上
1.2.2.52. Red Hat OpenShift Service Mesh 2.0.2 の新機能
Red Hat OpenShift Service Mesh の本リリースでは、IBM Z および IBM Power Systems のサポートが追加されました。また、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。
1.2.2.53. Red Hat OpenShift Service Mesh 2.0.1 の新機能
このリリースの Red Hat OpenShift Service Mesh では、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。
1.2.2.54. Red Hat OpenShift Service Mesh 2.0 の新機能
Red Hat OpenShift Service Mesh の本リリースでは、Istio 1.6.5、Jaeger 1.20.0、Kiali 1.24.2、3scale Istio Adapter 2.0 および OpenShift Container Platform 4.6 のサポートが追加されました。
また、このリリースには以下の新機能があります。
- Service Mesh コントロールプレーンのインストール、アップグレード、および管理を単純化します。
- Service Mesh コントロールプレーンのリソース使用量と起動時間を短縮します。
ネットワークのコントロールプレーン間の通信を削減することで、パフォーマンスが向上します。
- Envoy の Secret Discovery Service (SDS) のサポートが追加されました。SDS は、Envoy サイドカープロキシーにシークレットを提供するためのより安全で効率的なメカニズムです。
- よく知られているセキュリティーリスクがある Kubernetes シークレットを使用する必要性がなくなります。
プロキシーが新しい証明書を認識するのに再起動を必要としなくなったため、証明書のローテーション時にパフォーマンスが向上します。
- WebAssembly 拡張を使用してビルドされる Istio の Telemetry v2 アーキテクチャーのサポートを追加します。この新しいアーキテクチャーにより、パフォーマンスが大幅に改善されました。
- ServiceMeshControlPlane リソースを簡素化された設定を含む v2 に更新し、Service Mesh コントロールプレーンの管理を容易にします。
- WebAssembly 拡張を テクノロジープレビュー として導入します。
1.2.3. テクノロジープレビュー
現在、今回のリリースに含まれる機能にはテクノロジープレビューのものがあります。これらの実験的機能は、実稼働環境での使用を目的としていません。
テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
1.2.4. 非推奨および削除された機能
以前のリリースで利用可能であった一部の機能が非推奨になるか、削除されました。
非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、本製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。
本製品では、削除機能が除去されています。
1.2.4.1. Red Hat OpenShift Service Mesh 2.4 で非推奨化および廃止された機能
v2.1 の ServiceMeshControlPlane
リソースはサポートされなくなりました。お客様は、新しいバージョンの ServiceMeshControlPlane
リソースを使用するようにメッシュデプロイメントをアップグレードする必要があります。
Istio OpenShift Routing (IOR) のサポートは非推奨となり、将来のリリースでは削除される予定です。
Grafana のサポートは非推奨となり、将来のリリースでは削除される予定です。
Red Hat OpenShift Service Mesh 2.3 で非推奨となった以下の暗号スイートのサポートは、クライアント側とサーバー側の両方で TLS ネゴシエーションで使用される暗号のデフォルトのリストから削除されました。これらの暗号スイートのいずれかを必要とするサービスにアクセスする必要があるアプリケーションは、プロキシーから TLS 接続が開始されると接続に失敗します。
- ECDHE-ECDSA-AES128-SHA
- ECDHE-RSA-AES128-SHA
- AES128-GCM-SHA256
- AES128-SHA
- ECDHE-ECDSA-AES256-SHA
- ECDHE-RSA-AES256-SHA
- AES256-GCM-SHA384
- AES256-SHA
1.2.4.2. Red Hat OpenShift Service Mesh 2.3 で非推奨化および廃止された機能
次の暗号スイートのサポートは非推奨になりました。将来のリリースでは、クライアント側とサーバー側の両方で TLS ネゴシエーションに使用されるデフォルトの暗号リストから削除される予定です。
- ECDHE-ECDSA-AES128-SHA
- ECDHE-RSA-AES128-SHA
- AES128-GCM-SHA256
- AES128-SHA
- ECDHE-ECDSA-AES256-SHA
- ECDHE-RSA-AES256-SHA
- AES256-GCM-SHA384
- AES256-SHA
Red Hat OpenShift Service Mesh バージョン 2.2 で非推奨化された ServiceMeshExtension
API は、Red Hat OpenShift Service Mesh バージョン 2.3 で廃止されました。ServiceMeshExtension
API を使用している場合、WebAssembly エクステンションを引き続き使用するには WasmPlugin
API に移行する必要があります。
1.2.4.3. 非推奨になった Red Hat OpenShift Service Mesh 2.2 の機能
ServiceMeshExtension
API は、リリース 2.2 で非推奨になり、今後のリリースで削除される予定です。ServiceMeshExtension
API はリリース 2.2 でも引き続きサポートされますが、お客様は新しい WasmPluginAPI
への移行を開始する必要があります。
1.2.4.4. Red Hat OpenShift Service Mesh 2.2 で削除された機能
このリリースは、すべてのプラットフォームでの Service Mesh 1.1 に基づく Service Mesh コントロールプレーンのサポートの終了を示します。
1.2.4.5. Red Hat OpenShift Service Mesh 2.1 で削除された機能
Service Mesh 2.1 では、Mixer コンポーネントが削除されます。バグ修正およびサポートは、Service Mesh 2.0 の最後のライフサイクルで提供されます。
Mixer プラグインが有効な場合は、Service Mesh 2.0.x リリースから 2.1 へのアップグレードは続行されません。Mixer プラグインは、WebAssembly 拡張に移植する必要があります。
1.2.4.6. 非推奨になった Red Hat OpenShift Service Mesh 2.0 の機能
Mixer コンポーネントはリリース 2.0 で非推奨となり、リリース 2.1 で削除されます。Mixer を使用した拡張機能の実装はリリース 2.0 でも引き続きサポートされますが、拡張機能を新規の WebAssembly メカニズムに移行する必要があります。
以下のリソースタイプは Red Hat OpenShift Service Mesh 2.0 でサポートされなくなりました。
Policy
(authentication.istio.io/v1alpha1) はサポートされなくなりました。Policy リソースの特定の設定によっては、同じ効果を実現するために複数のリソースを設定しなければならない場合があります。-
RequestAuthentication
(security.istio.io/v1beta1) の使用 -
PeerAuthentication
(security.istio.io/v1beta1) の使用
-
ServiceMeshPolicy
(maistra.io/v1) はサポートされなくなりました。-
上記のように
RequestAuthentication
またはPeerAuthentication
を使用しますが、Service Mesh コントロールプレーン namespace に配置します。
-
上記のように
RbacConfig
(rbac.istio.io/v1alpha1) はサポートされなくなりました。-
AuthorizationPolicy
(security.istio.io/v1beta1) に置き換わります。これはRbacConfig
、ServiceRole
、およびServiceRoleBinding
の動作を包含します。
-
ServiceMeshRbacConfig
(maistra.io/v1) がサポートされなくなりました。-
上記のように
AuthorizationPolicy
を使用しますが、Service Mesh コントロールプレーンの namespace に配置します。
-
上記のように
-
ServiceRole
(rbac.istio.io/v1alpha1) がサポートされなくなりました。 -
ServiceRoleBinding
(rbac.istio.io/v1alpha1) がサポートされなくなりました。 -
Kiali では、
login
およびLDAP
ストラテジーは非推奨になりました。今後のバージョンでは、OpenID プロバイダーを使用した認証が導入されます。
1.2.5. 既知の問題
Red Hat OpenShift Service Mesh には以下のような制限が存在します。
- Red Hat OpenShift Service Mesh はまだ IPv6 をフルサポートを提供していません。その結果、Red Hat OpenShiftServiceMesh ではデュアルスタッククラスターはサポート対象外です。
- グラフレイアウト: Kiali グラフのレイアウトは、アプリケーションのアーキテクチャーや表示データ (グラフィックノードとその対話の数) によって異なることがあります。すべての状況に適した単一のレイアウトを作成することは不可能ではないにしても困難であるため、Kiali は複数の異なるレイアウトの選択肢を提供します。別のレイアウトを選択するには、Graph Settings メニューから異なる Layout Schema を選択します。
- Kiali コンソールから distributed tracing platform (Jaeger) や Grafana などの関連サービスに初めてアクセスする場合、OpenShift Container Platform のログイン認証情報を使用して証明書を受け入れ、再認証する必要があります。これは、フレームワークが組み込まれたページをコンソールで表示する方法に問題があるために生じます。
- Bookinfo サンプルアプリケーションは、IBM Power、IBM Z、および IBM® LinuxONE にはインストールできません。
- WebAssembly 拡張機能は、IBM Power、IBM Z、および IBM® LinuxONE ではサポートされていません。
- LuaJIT は、IBM Power、IBM Z、および IBM® LinuxONE ではサポートされていません。
- シングルスタック IPv6 サポートは、IBM Power、IBM Z、および IBM® LinuxONE では利用できません。
1.2.5.1. Service Mesh の既知の問題
Red Hat OpenShift Service Mesh には次のような既知の問題が存在します。
OSSM-3890 マルチテナントメッシュデプロイメントでゲートウェイ API を使用しようとすると、次のようなエラーメッセージが生成されます。
2023-05-02T15:20:42.541034Z error watch error in cluster Kubernetes: failed to list *v1alpha2.TLSRoute: the server could not find the requested resource (get tlsroutes.gateway.networking.k8s.io) 2023-05-02T15:20:42.616450Z info kube controller "gateway.networking.k8s.io/v1alpha2/TCPRoute" is syncing...
マルチテナントメッシュデプロイメントでゲートウェイ API をサポートするには、すべてのゲートウェイ API カスタムリソース定義 (CRD) ファイルがクラスター内に存在する必要があります。
マルチテナントメッシュデプロイメントでは、CRD スキャンが無効になり、Istio はクラスター内にどの CRD が存在するかを検出する方法がありません。その結果、Istio はサポートされているすべての Gateway API CRD を監視しようとしますが、それらの CRD の一部が存在しない場合はエラーが生成されます。
Service Mesh 2.3.1 以降のバージョンは、
v1alpha2
とv1beta1
の両方の CRD をサポートします。したがって、マルチテナントメッシュデプロイメントでゲートウェイ API をサポートするには、両方の CRD バージョンが存在する必要があります。回避策: 次の例では、
kubectl get
操作によりv1alpha2
およびv1beta1
CRD がインストールされます。URL には追加のexperimental
セグメントが含まれており、それに応じて既存のスクリプトが更新されることに注意してください。$ kubectl get crd gateways.gateway.networking.k8s.io || { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=v0.5.1" | kubectl apply -f -; }
OSSM-2042
default
という名前の SMCP のデプロイメントが失敗します。SMCP オブジェクトを作成し、そのバージョンフィールドを v2.3 に設定する場合、オブジェクトの名前はdefault
にできません。名前がdefault
の場合、コントロールプレーンはデプロイに失敗し、OpenShift は次のメッセージを含むWarning
イベントを生成します。Error processing component mesh-config: error: [mesh-config/templates/telemetryv2_1.6.yaml: Internal error occurred: failed calling webhook "rev.validation.istio.io": Post "https://istiod-default.istio-system.svc:443/validate?timeout=10s": x509: certificate is valid for istiod.istio-system.svc, istiod-remote.istio-system.svc, istio-pilot.istio-system.svc, not istiod-default.istio-system.svc, mesh-config/templates/enable-mesh-permissive.yaml
OSSM-1655 SMCP で
mTLS
を有効にした後に、Kiali ダッシュボードにエラーが表示されます。SMCP で
spec.security.controlPlane.mtls
設定を有効にすると、Kiali コンソールにエラーメッセージNo subsets defined
が表示されます。OSSM-1505 この問題は、OpenShift Container Platform 4.11 で
ServiceMeshExtension
リソースを使用する場合にのみ発生します。OpenShift Container Platform 4.11 でServiceMeshExtension
を使用すると、リソースの準備が整いません。oc describe ServiceMeshExtension
を使用して問題を調べると、stderr: Error creating mount namespace before pivot: function not implemented
エラーが表示されます。回避策:
ServiceMeshExtension
は Service Mesh 2.2 で廃止されました。ServiceMeshExtension
からWasmPlugin
リソースに移行します。詳細は、ServiceMeshExtension
からWasmPlugin
リソースへの移行を参照してください。-
OSSM-1396 ゲートウェイリソースに
spec.externalIPs
設定が含まれていると、ゲートウェイは、ServiceMeshControlPlane
の更新時に再作成されず削除され、再作成されることはありません。 - OSSM-1168 Service Mesh リソースが単一の YAML ファイルとして作成される場合は、Envoy プロキシーサイドカーが Pod に確実に挿入されません。SMCP、SMMR、およびデプロイメントリソースを個別に作成すると、デプロイメントは想定どおりに機能します。
OSSM-1115
spec.proxy
API のconcurrency
フィールドが istio-proxy に伝播されませんでした。concurrency
フィールドは、ProxyConfig
で設定すると機能します。concurrency
フィールドは、実行するワーカースレッドの数を指定します。フィールドが0
に設定されている場合、使用可能なワーカースレッドの数は CPU コアの数と等しくなります。フィールドが設定されていない場合、使用可能なワーカースレッドの数はデフォルトで2
になります。次の例では、
concurrency
フィールドが0
に設定されています。apiVersion: networking.istio.io/v1beta1 kind: ProxyConfig metadata: name: mesh-wide-concurrency namespace: <istiod-namespace> spec: concurrency: 0
OSSM-1052 Service Mesh コントロールプレーンで入力ゲートウェイのサービス
ExternalIP
を設定すると、サービスは作成されません。SMCP のスキーマには、サービスのパラメーターがありません。回避策: SMCP 仕様でゲートウェイの作成を無効にして、(サービス、ロール、および RoleBinding など) ゲートウェイのデプロイメントを完全に手動で管理します。
OSSM-882 これは、Service Mesh 2.1 以前に適用されます。namespace は accessible_namespace リストにありますが、Kiali UI には表示されません。デフォルトでは、Kiali は kube で始まる namespace を表示しません。これらの namespace は通常内部使用のみであり、メッシュの一部ではないためです。
たとえば、akube-a という名前の namespace を作成し、これを Service Mesh メンバーロールに追加すると、Kiali UI は namespace を表示しません。定義された除外パターンの場合、ソフトウェアは、このパターンで始まるか、そのパターンを含む namespace を除外します。
回避策: Kiali カスタムリソース設定を変更して、設定に接頭辞としてキャレット (^) を追加します。以下に例を示します。
api: namespaces: exclude: - "^istio-operator" - "^kube-.*" - "^openshift.*" - "^ibm.*" - "^kiali-operator"
-
MAISTRA-2692 Mixer が削除されると、Service Mesh 2.0.x で定義されたカスタムメトリクスを 2.1 で使用できません。カスタムメトリックは
EnvoyFilter
を使用して設定できます。明示的に文書化されている場合を除き、Red Hat はEnvoyFilter
設定をサポートできません。これは、下層の Envoy API と疎結合されており、後方互換性を保持できないためです。 - MAISTRA-2648 サービスメッシュ拡張機能は現在、IBM Z にデプロイされたメッシュと互換性がありません。
MAISTRA-1959 2.0 への移行 Prometheus の収集 (
spec.addons.prometheus.scrape
がtrue
に設定される) は mTLS が有効にされていると機能しません。また、Kiali は、mTLS が無効になっている場合に余分なグラフデータを表示します。この問題は、たとえば、プロキシー設定からポート 15020 を除外して対応できます。
spec: proxy: networking: trafficControl: inbound: excludedPorts: - 15020
-
MAISTRA-453 新規プロジェクトを作成して Pod を即時にデプロイすると、サイドカーコンテナーの挿入は発生しません。この Operator は Pod の作成前に
maistra.io/member-of
を追加できないため、サイドカーコンテナーの挿入を発生させるには Pod を削除し、再作成する必要があります。 - MAISTRA-158 同じホスト名を参照する複数のゲートウェイを適用すると、すべてのゲートウェイが機能しなくなります。
1.2.5.2. Kiali の既知の問題
Kiali の新たな問題は、Component
が Kiali
に設定された状態の OpenShift Service Mesh プロジェクトに作成される必要があります。
Kiali の既知の問題は以下のとおりです。
- KIALI-2206 初回の Kiali コンソールへのアクセス時に、Kiali のキャッシュされたブラウザーデータがない場合、Kiali サービスの詳細ページの Metrics タブにある View in Grafana リンクは誤った場所にリダイレクトされます。この問題は、Kiali への初回アクセス時にのみ生じます。
- KIALI-507 Kiali は Internet Explorer 11 に対応していません。これは、基礎となるフレームワークが Internet Explorer に対応していないためです。Kiali コンソールにアクセスするには、Chrome、Edge、Firefox、または Safari ブラウザーの最新の 2 バージョンのいずれかを使用します。
1.2.6. 修正された問題
以下の問題は、現在のリリースで解決されています。
OSSM-3647 以前は、Service Mesh コントロールプレーン (SMCP) v2.2 (Istio 1.12) では、WasmPlugin は受信リスナーにのみ適用されていました。SMCP v2.3 (Istio 1.14) 以降、WasmPlugin はデフォルトでインバウンドおよびアウトバウンドのリスナーに適用されるようになり、3scale WasmPlugin のユーザーにリグレッションが発生しました。環境変数
APPLY_WASM_PLUGINS_TO_INBOUND_ONLY
が追加され、SMCP v2.2 から v2.3 および v2.4 への安全な移行が可能になります。次の設定を SMCP config に追加する必要があります。
spec: runtime: components: pilot: container: env: APPLY_WASM_PLUGINS_TO_INBOUND_ONLY: "true"
安全な移行を確保するには、次の手順を実行します。
-
SMCP v2.2 で
APPLY_WASM_PLUGINS_TO_INBOUND_ONLY
を設定します。 - 2.4 にアップグレードします。
-
WasmPlugins で
spec.match[].mode: SERVER
を設定します。 - 以前に追加した環境変数を削除します。
-
SMCP v2.2 で
以下の問題は、これまでのリリースで解決されています。
1.2.6.1. Service Mesh の修正された問題
-
OSSM-4851 以前は、
runAsGroup
、runAsUser
、またはfsGroup
パラメーターがnil
の場合、メッシュ内をスコープとする namespace に新しい Pod をデプロイするオペレータでエラーが発生しました。nil
値を回避するために yaml 検証が追加されました。 -
OSSM-3771 以前は、Service Mesh Control Plane (SMCP) で定義された追加の Ingress ゲートウェイに対して OpenShift ルートを無効にすることができませんでした。現在、
routeConfig
ブロックを追加の各additionalIngress
ゲートウェイに追加できるため、ゲートウェイごとに OpenShift ルートの作成を有効または無効にできます。 OSSM-4197 では、ServiceMeshControlPlane リソースの v2.2 または v2.1 をデプロイしても、
/etc/cni/multus/net.d/
ディレクトリーは作成されませんでした。その結果、istio-cni
Pod の準備ができず、istio-cni
Pod のログに次のメッセージが含まれていました。$ error Installer exits with open /host/etc/cni/multus/net.d/v2-2-istio-cni.kubeconfig.tmp.841118073: no such file or directory
ここで、ServiceMeshControlPlane リソースの v2.2 または v2.1 をデプロイすると、
/etc/cni/multus/net.d/
ディレクトリーが作成され、istio-cni
Pod の準備が整います。-
OSSM-3993 以前は、Kiali は標準 HTTPS ポート
443
上のプロキシー経由の OpenShift OAuth のみをサポートしていました。現在、Kiali は非標準の HTTPS ポートを介した OpenShift OAuth をサポートします。ポートを有効にするには、Kiali CR でspec.server.web_port
フィールドをプロキシーの非標準 HTTPS ポートに設定する必要があります。 -
OSSM-3936 以前は、
injection_label_rev
およびinjection_label_name
属性の値がハードコーディングされていました。これにより、カスタム設定が Kiali カスタムリソース定義 (CRD) で有効になりませんでした。今回のリリースより、属性値はハードコーディングされなくなりました。spec.istio_labels
仕様のinjection_label_rev
およびinjection_label_name
属性の値をカスタマイズできます。 - OSSM-3644 これまで、フェデレーション egress-gateway はネットワークゲートウェイエンドポイントの誤った更新を受信し、余分なエンドポイントエントリーが発生していました。これで、egress-gateway ゲートウェイはサーバー側で更新され、正しいネットワークゲートウェイエンドポイントを受信できるようになりました。
-
OSSM-3595 これまでは、
iptables-restore
ユーティリティーが/tmp
ディレクトリー内のファイルを開くことを SELinux が許可しなかったため、RHEL 上でistio-cni
プラグインが失敗することがありました。SELinux は、ファイル経由ではなくstdin
入力ストリーム経由でiptables-restore
を渡すようになりました。 - OSSM-3586 以前は、Google Cloud Platform (GCP) メタデータサーバーが利用できない場合に Istio プロキシーの起動が遅くなりました。Istio 1.14.6 にアップグレードすると、メタデータサーバーが利用できない場合でも、Istio プロキシーは GCP 上で期待どおりに起動します。
- OSSM-3025 Istiod が準備完了にならないことがあります。メッシュに多くのメンバーの namespace が含まれている場合は、Istiod 内のデッドロックが原因で Istiod Pod が準備完了にならないことがありました。デッドロックが解決され、Pod が期待どおりに起動するようになりました。
-
OSSM-2493 SMCP のデフォルトの
nodeSelector
とtolerations
が Kiali に渡されません。SMCP.spec.runtime.defaults
に追加するnodeSelector
とtolerations
が Kiali リソースに渡されるようになりました。 -
OSSM-2492 SMCP のデフォルトの Toleration が Jaeger に渡されません。
SMCP.spec.runtime.defaults
に追加するnodeSelector
とtolerations
が Jaeger リソースに渡されるようになりました。 -
OSSM-2374
ServiceMeshMember
リソースの 1 つを削除すると、Service Mesh Operator がServiceMeshMemberRoll
を削除しました。これは、最後のServiceMeshMember
を削除する際に期待される動作ですが、削除されたメンバーに加えて、メンバーが含まれている場合、Operator はServiceMeshMemberRoll
を削除しないようにする必要があります。この問題は修正され、Operator は最後のServiceMeshMember
リソースが削除された場合のみ、ServiceMeshMemberRoll を削除するようになりました。 OSSM-2373 ログイン時に OAuth メタデータを取得しようとして、エラーが発生しました。クラスターのバージョンを取得するには、
system:anonymous
アカウントが使用されます。クラスターのデフォルトのバンドルされた ClusterRole と ClusterRoleBinding を使用すると、匿名アカウントはバージョンを正しく取得できます。system:anonymous
アカウントがクラスターバージョンを取得する権限を失うと、OpenShift 認証は使用できなくなります。これは、Kiali SA を使用して、クラスターのバージョンを取得することで修正されます。これにより、クラスターのセキュリティーも向上します。
- OSSM-2371 Kiali が view-only として設定されているにもかかわらず、ユーザーはワークロードの詳細の Logs タブの kebab メニューからプロキシーログレベルを変更できます。この問題は修正されており、Kiali が view-only として設定されている場合は、Set Proxy Log Level の下のオプションが無効になります。
- OSSM-2344 Istiod を再起動すると、Kiali によって CRI-O がポート転送リクエストでいっぱいになります。この問題は、Kiali が Istiod に接続できず、Kiali が同時に大量のリクエストを istiod に発行したときに発生しました。Kiali が istiod に送信するリクエストの数が制限されるようになりました。
- OSSM-2335 Traces の散布図のプロット上でマウスポインターをドラッグすると、同時バックエンドリクエストが原因で Kiali コンソールが応答を停止する場合がありました。
OSSM-2221 以前は、デフォルトで
ignore-namespace
ラベルが名前空間に適用されていたため、ServiceMeshControlPlane
名前空間へのゲートウェイインジェクションはできませんでした。v2.4 コントロールプレーンを作成すると、名前空間に
ignore-namespace
ラベルが適用されなくなり、ゲートウェイインジェクションが可能になります。以下の例では、
oc label
コマンドは既存のデプロイメントの namespace からignore-namespace
ラベルを削除します。$ oc label namespace <istio_system> maistra.io/ignore-namespace-
上の例では、<istio_system> は
ServiceMeshControlPlane
namespace の名前を表します。OSSM-2053 Red Hat OpenShift Service Mesh Operator 2.2 または 2.3 を使用すると、SMCP の調整中に、SMMR コントローラーがメンバーの namespace を
SMMR.status.configuredMembers
から削除しました。これにより、メンバーの namespace のサービスがしばらく利用できなくなりました。Red Hat OpenShift Service Mesh Operator 2.2 または 2.3 を使用すると、SMMR コントローラーは
SMMR.status.configuredMembers
から namespace を削除しなくなります。代わりに、コントローラーは namespace をSMMR.status.pendingMembers
に追加して、それらが最新ではないことを示します。調整中に、各 namespace が SMCP と同期されると、namespace はSMMR.status.pendingMembers
から自動的に削除されます。-
OSSM-1962 フェデレーションコントローラーで
EndpointSlices
を使用します。フェデレーションコントローラーがEndpointSlices
を使用するようになりました。これにより、大規模なデプロイメントでのスケーラビリティとパフォーマンスが向上します。PILOT_USE_ENDPOINT_SLICE フラグはデフォルトで有効になっています。フラグを無効にすると、フェデレーションデプロイメントを使用できなくなります。 -
OSSM-1668 新しいフィールド
spec.security.jwksResolverCA
がバージョン 2.1SMCP
に追加されましたが、2.2.0 および 2.2.1 リリースにはありませんでした。このフィールドが存在する Operator バージョンから、このフィールドが存在しなかった Operator バージョンにアップグレードする場合は、SMCP
で.spec.security.jwksResolverCA
フィールドを使用できませんでした。 -
OSSM-1325 istiod Pod がクラッシュし、
fatal error: concurrent map iteration and map write
のエラーメッセージが表示されます。 OSSM-1211 フェイルオーバー用のフェデレーション Service Mesh の設定が想定どおりに機能しません。
Istiod パイロットログに、
envoy connection [C289] TLS error: 337047686:SSL routines:tls_process_server_certificate:certificate verify failed
のエラーが表示されます。-
OSSM-1099 Kiali コンソールに
Sorry, there was a problem.Try a refresh or navigate to a different page.
メッセージが表示されました - OSSM-1074 SMCP で定義された Pod アノテーションが Pod に注入されません。
- OSSM-999 Kiali は想定どおりに保持されませんでした。ダッシュボードグラフでは、カレンダーの時刻がグレーアウトされています。
-
OSSM-797 Kiali Operator Pod は、Operator のインストールまたはアップグレード時に
CreateContainerConfigError
を生成します。 -
kube
で始まる OSSM-722 namespace は Kiali には表示されません。 -
OSSM-569: Prometheus
istio-proxy
コンテナーには CPU メモリー制限がありません。Prometheusistio-proxy
サイドカーは、spec.proxy.runtime.container
で定義されたリソース制限を使用するようになりました。 -
OSSM-535 SMCP での validationMessages のサポート。Service Mesh コントロールプレーンの
ValidationMessages
フィールドをTrue
に設定できるようになりました。これにより、問題のトラブルシューティングに役立つ、リソースのステータスのログが書き込まれます。 - OSSM-449 VirtualService および Service により、"Only unique values for domains are permitted.Duplicate entry of domain." エラーが生じます。
- 同様の名前を持つ OSSM-419 namespace は、namespace が Service Mesh Member Role で定義されていない場合でも、Kiali namespace の一覧に表示されます。
- OSSM-296 ヘルス設定を Kiali カスタムリソース (CR) に追加する場合、これは Kiali configmap にレプリケートされません。
- OSSM-291 Kiali コンソールの、Applications、Services、および Workloads ページの Remove Label from Filters が機能しません。
- OSSM-289 Kiali コンソールの istio-ingressgateway および jaeger-query サービスの Service Details ページにはトレースが表示されません。トレースは Jaeger にあります。
- OSSM-287 Kiali コンソールでは、トレースが Graph Service に表示されません。
OSSM-285 Kiali コンソールにアクセスしようとすると、Error trying to get OAuth Metadata エラーメッセージが表示されます。
回避策: Kiali Pod を再起動します。
MAISTRA-2735 Red Hat OpenShift Service Mesh バージョン 2.1 では、SMCP の調整時に Service Mesh Operator が削除するリソースが変更されました。以前のバージョンでは、Operator は以下のラベルを持つリソースを削除しました。
-
maistra.io/owner
-
app.kubernetes.io/version
Operator は
app.kubernetes.io/managed-by=maistra-istio-operator
ラベルを含まないリソースを無視するようになりました。独自のリソースを作成する場合は、app.kubernetes.io/managed-by=maistra-istio-operator
ラベルをそれらに追加することはできません。-
-
MAISTRA-2687 外部証明書を使用する場合は、Red Hat OpenShift Service Mesh 2.1 フェデレーションゲートウェイでは、証明書チェーンが完全に送信されません。Service Mesh フェデレーション egress ゲートウェイはクライアント証明書のみを送信します。フェデレーション Ingress ゲートウェイはルート証明書のみを認識するため、ルート証明書をフェデレーションインポート
ConfigMap
に追加しない限り、クライアント証明書を検証できません。 -
MAISTRA-2635 非推奨の Kubernetes API が置き換えられました。OpenShift Container Platform 4.8 との互換性を維持するために、
apiextensions.k8s.io/v1beta1
API は Red Hat OpenShift Service Mesh 2.0.8 で非推奨になりました。 -
MAISTRA-2631 nsenter バイナリーが存在しないことが原因で Podman に問題が発生しているため、WASM 機能は使用できません。Red Hat OpenShift Service Mesh は
Error: error configuring CNI network plugin exec: "nsenter": executable file not found in $PATH
エラーメッセージを生成します。コンテナーイメージには nsenter が含まれ、WASM が予想通りに機能するようになりました。 - MAISTRA-2534 istiod が JWT ルールで指定された発行者の JWKS の取得を試行する際に、発行者サービスは 502 で応答します。これにより、プロキシーコンテナーの準備ができなくなり、デプロイメントがハングしていました。コミュニティーバグ の修正は、Service Mesh 2.0.7 リリースに含まれています。
MAISTRA-2411 Operator が
ServiceMeshControlPlane
でspec.gateways.additionaIngress
を使用して新規 ingress ゲートウェイを作成する場合、Operator はデフォルトの istio-ingressgateway の場合と同様に追加の Ingress ゲートウェイのNetworkPolicy
を作成しません。これにより、新規ゲートウェイのルートから 503 応答が生じました。回避策: <istio-system> namespace に
NetworkPolicy
を手動で作成します。MAISTRA-2401 CVE-2021-3586 servicemesh-operator: NetworkPolicy リソースが Ingress リソースのポートを誤って指定しています。Red Hat OpenShift Service Mesh にインストールされた NetworkPolicy リソースでは、アクセス可能なポートが適切に指定されませんでした。これにより、任意の Pod からこれらのリソースの全ポートにアクセスできるようになりました。以下のリソースに適用されるネットワークポリシーが影響を受けます。
- Galley
- Grafana
- Istiod
- Jaeger
- Kiali
- Prometheus
- サイドカーインジェクター
-
MAISTRA-2378: クラスターが
ovs-multitenant
で OpenShift SDN を使用するように設定されており、メッシュに多数の namespace (200+) が含まれる場合に、OpenShift Container Platform ネットワークプラグインは namespace を迅速に設定できません。Service Mesh がタイムアウトすると、namespace がサービスメッシュから継続的にドロップされ、再リストされます。 - MAISTRA-2370 は listerInformer で tombstones を処理します。更新されたキャッシュコードベースは、namespace キャッシュからのイベントを集約されたキャッシュに変換する際に tombstones を処理しないため、go ルーチンでパニックが生じました。
MAISTRA-2117 オプションの
ConfigMap
マウントを Operator に追加します。CSV にはオプションのConfigMap
ボリュームマウントが含まれるようになり、smcp-templates
ConfigMap
(存在する場合) をマウントします。smcp-templates
ConfigMap
が存在しないと、マウントされたディレクトリーは空になります。ConfigMap
を作成すると、ディレクトリーにはConfigMap
からのエントリーが設定され、SMCP.spec.profiles
で参照できます。Service Mesh Operator の再起動は必要ありません。CSV を変更して 2.0 Operator を使用して smcp-templates ConfigMap をマウントしている場合は、Red Hat OpenShift Service Mesh 2.1 にアップグレードできます。アップグレード後は、CSV を編集せずに、既存の ConfigMap およびこれに含まれるプロファイルを引き続き使用できます。以前別の名前で ConfigMap を使用していた場合は、ConfigMap の名前を変更するか、アップグレード後に CSV を更新する必要があります。
-
MAISTRA-2010 AuthorizationPolicy は
request.regex.headers
フィールドをサポートしません。validatingwebhook
はこのフィールドのある AuthorizationPolicy を拒否し、これを無効にした場合でも、パイロットは同じコードを使用してこの検証を試行し、機能しません。 MAISTRA-1979 2.0 への移行 変換 webhook は、
SMCP.status
を v2 から v1 に変換する際に以下の重要なフィールドをドロップします。- conditions
- components
- observedGeneration
annotations
Operator を 2.0 にアップグレードすると、リソースの maistra.io/v1 バージョンを使用する SMCP ステータスを読み取るクライアントツールが破損する可能性があります。
また、
oc get servicemeshcontrolplanes.v1.maistra.io
の実行時に READY および STATUS 列が空になります。
MAISTRA-1947 テクノロジープレビュー ServiceMeshExtensions への更新は適用されません。
回避策:
ServiceMeshExtensions
を削除し、再作成します。-
MAISTRA-1983 2.0 への移行 既存の無効な
ServiceMeshControlPlane
を使用した 2.0.0 へのアップグレードは修復できません。ServiceMeshControlPlane
リソース内の無効な項目により、回復不可能なエラーが発生しました。修正により、エラーが回復可能になりました。無効なリソースを削除してこれを新しいリソースに置き換えるか、リソースを編集してエラーを修正できます。リソースの編集に関する詳細は、 [Red Hat OpenShift Service Mesh インストールの設定] を参照してください。 - MAISTRA-1502 バージョン 1.0.10 の CVE の修正により、Istio ダッシュボードは Grafana の Home Dashboard メニューから利用できなくなりました。Istio ダッシュボードにアクセスするには、ナビゲーションパネルの Dashboard メニューをクリックし、Manage タブを選択します。
- MAISTRA-1399 Red Hat OpenShift Service Mesh では、サポート対象外の CNI プロトコルがインストールされなくなりました。サポート対象のネットワーク設定は変更されていません。
- MAISTRA-1089 2.0 への移行 コントロールプレーン以外の namespace で作成されたゲートウェイは自動的に削除されます。SMCP 仕様からゲートウェイ定義を削除した後にこれらのリソースを手動で削除する必要があります。
MAISTRA-858 Istio 1.1.x に関連する非推奨のオプションと設定 を説明する以下のような Envoy ログメッセージが予想されます。
- [2019-06-03 07:03:28.943][19][warning][misc] [external/envoy/source/common/protobuf/utility.cc:129] 非推奨の 'envoy.api.v2.listener.Filter.config' オプションの使用。この設定はまもなく Envoy から削除されます。
- [2019-08-12 22:12:59.001][13][warning][misc] [external/envoy/source/common/protobuf/utility.cc:174] lds.proto ファイルから非推奨の 'envoy.api.v2.Listener.use_original_dst' オプションを使用。この設定はまもなく Envoy から削除されます。
MAISTRA-806 エビクトされた Istio Operator Pod により、メッシュおよび CNI はデプロイできなくなります。
回避策: コントロールペインのデプロイ時に
istio-operator
Pod がエビクトされる場合は、エビクトされたistio-operator
Pod を削除します。- MAISTRA-681 Service Mesh コントロールプレーンに多くの namespace がある場合に、パフォーマンスの問題が発生する可能性があります。
- MAISTRA-193 ヘルスチェックが citadel で有効になっていると、予期しないコンソール情報メッセージが表示されます。
- Bugzilla 1821432: OpenShift Container Platform カスタムリソースの詳細ページのトグルコントロールで CR が正しく更新されません。OpenShift Container Platform Web コンソールの Service Mesh Control Plane (SMCP) Overview ページの UI のトグルコントロールにより、リソースの誤ったフィールドが更新されることがあります。SMCP を更新するには、YAML コンテンツを直接編集するか、トグルコントロールをクリックせずにコマンドラインからリソースを更新します。
1.3. Service Mesh について
Red Hat OpenShift Service Mesh は、サービスメッシュにおいてネットワーク化されたマイクロサービス全体の動作に関する洞察と運用管理のためのプラットフォームを提供します。Red Hat OpenShift Service Mesh では、OpenShift Container Platform 環境でマイクロサービスの接続、保護、監視を行うことができます。
1.3.1. サービスメッシュについて
Service Mesh は、分散したマイクロサービスアーキテクチャーの複数のアプリケーションを設定するマイクロサービスのネットワークであり、マイクロサービス間の対話を可能にします。Service Mesh のサイズとおよび複雑性が増大すると、これを把握し、管理することがより困難になる可能性があります。
オープンソースの Istio プロジェクトをベースとする Red Hat OpenShift Service Mesh は、サービスコードに変更を加えずに、既存の分散したアプリケーションに透過的な層を追加します。Red Hat OpenShift Service Mesh サポートをサービスに追加するには、マイクロサービス間のすべてのネットワーク通信を傍受する特別なサイドカープロキシーをメッシュ内の関連サービスにデプロイします。Service Mesh コントロールプレーンの機能を使用して Service Mesh を設定し、管理します。
Red Hat OpenShift Service Mesh により、以下を提供するデプロイされたサービスのネットワークを簡単に作成できます。
- 検出
- 負荷分散
- サービス間の認証
- 障害回復
- メトリクス
- モニタリング
Red Hat OpenShift Service Mesh は、以下を含むより複雑な運用機能も提供します。
- A/B テスト
- カナリアリリース
- アクセス制御
- エンドツーエンド認証
1.3.2. Service Mesh アーキテクチャー
Service Mesh テクノロジーはネットワーク通信レベルで動作します。つまり、サービスメッシュコンポーネントは、マイクロサービスとの間のトラフィックを取得または傍受して、リクエストを変更したり、リダイレクトしたり、他のサービスへの新しいリクエストを作成したりします。
高いレベルでは、Red Hat OpenShift Service Mesh はデータプレーンおよびコントロールプレーンで設定されます。
データプレーン は、Pod のアプリケーションコンテナーとともに実行するインテリジェントプロキシーのセットであり、Service Mesh 内のマイクロサービス間で起こる受信および送信ネットワーク通信をすべて傍受し、制御します。データプレーンは、すべての受信 (ingress) および送信 (egress) ネットワークトラフィックを傍受する方法で実装されます。Istio データプレーンは、Pod のサイドアプリケーションコンテナーで実行する Envoy コンテナーで設定されます。Envoy コンテナーはプロキシーとして機能し、すべてのネットワーク通信を Pod に対して制御します。
Envoy プロキシー は、データプレーントラフィックと対話する唯一の Istio コンポーネントです。プロキシー経由でサービスフロー間の受信 (ingress) および送信 (egress) ネットワークトラフィックはすべて、そのプロキシーを介して行われます。また、Envoy プロキシーは、メッシュ内のサービストラフィックに関連するすべてのメトリックを収集します。Envoy プロキシーはサイドカーとしてデプロイされ、サービスと同じ Pod で実行されます。Envoy プロキシーは、メッシュゲートウェイの実装にも使用されます。
- Sidecar プロキシー は、ワークロードインスタンスのインバウンドおよびアウトバウンド通信を管理します。
ゲートウェイ は、受信または送信 HTTP/TCP 接続を受信するロードバランサーとして動作するプロキシーです。ゲートウェイ設定は、サービスワークロードとともに実行するサイドカー Envoy プロキシーではなく、メッシュのエッジで実行するスタンドアロン Envoy プロキシーに適用されます。ゲートウェイを使用してメッシュの受信トラフィックおよび送信トラフィックを管理することで、メッシュに入るか、メッシュを出るトラフィックを指定できます。
- Ingress-gateway - ingress コントローラーとしても知られる、Ingress ゲートウェイは Service Mesh に入るトラフィックを受信し、制御する専用の Envoy プロキシーです。Ingress ゲートウェイは、モニタリングおよびルーティングルールなどの機能をクラスターに入るトラフィックに適用できるようにします。
- Egress-gateway - egress コントローラーとしても知られる、Egress Gateway は Service Mesh からトラフィックを管理する専用の Envoy プロキシーです。Egress Gateway は、モニタリングおよびルートルールなどの機能をメッシュのトラフィックに適用できるようにします。
コントロールプレーン は、データプレーンを設定するプロキシーを管理し、設定します。これは、設定用の権威ソースで、アクセス制御および使用状況ポリシーを管理し、Service Mesh のプロキシーからメトリクスを収集します。
Istio コントロールプレーンは、以前の複数のコントロールプレーンコンポーネント (Citadel、Galley、Pilot) を単一バイナリーに統合する Istiod で設定されています。Istiod は、サービス検出、設定、および証明書の管理を行います。これは、高レベルのルーティングルールを Envoy 設定に変換し、それらをランタイム時にサイドカーコンテナーに伝播します。
- Istiod は認証局 (CA) として機能し、データプレーンでセキュアな mTLS 通信に対応する証明書を生成します。この場合は、外部 CA を使用することもできます。
- Istiod は、サイドカーコンテナーを OpenShift クラスターにデプロイされたワークロードに挿入します。
Red Hat OpenShift Service Mesh は、istio-operator を使用してコントロールプレーンのインストールも管理します。Operator は、OpenShift クラスターで共通アクティビティーを実装し、自動化できるソフトウェアの設定要素です。これはコントローラーとして機能し、クラスター内の必要なオブジェクトの状態 (この場合は Red Hat OpenShift Service Mesh のインストール) を設定または変更できます。
Red Hat OpenShift Service Mesh は以下の Istio アドオンを製品の一部としてバンドルします。
- Kiali: Kiali は Red Hat OpenShift Service Mesh の管理コンソールです。ダッシュボード、可観測性、および堅牢な設定、ならびに検証機能を提供します。これは、トラフィックトポロジーを推測して Service Mesh の構造を示し、メッシュの正常性を表示します。Kiali は、詳細なメトリック、強力な検証、Grafana へのアクセス、および分散トレースプラットフォーム (Jaeger) との強力な統合を提供します。
- Prometheus: Red Hat OpenShift Service Mesh は Prometheus を使用してサービスからのテレメトリー情報を保存します。Kiali は、メトリクス、ヘルスステータス、およびメッシュトポロジーを取得するために Prometheus に依存します。
- Jaeger: Red Hat OpenShift Service Mesh は分散トレースプラットフォーム (Jaeger) をサポートします。Jaeger はオープンソースのトレース機能で、複数のサービス間の単一要求に関連付けられたトレースを一元管理し、表示します。分散トレースプラットフォーム (Jaeger) を使用すると、マイクロサービスベースの分散システムの監視とトラブルシューティングを行うことができます。
- Elasticsearch: Elasticsearch は、オープンソースの分散型 JSON ベースの検索および解析エンジンです。分散トレースプラットフォーム (Jaeger) は、永続ストレージに Elasticsearch を使用します。
- Grafana: Grafana は、Istio データの高度なクエリーおよびメトリクス分析、ならびにダッシュボードを使用してメッシュ管理者を提供します。任意で、Grafana を使用して Service Mesh メトリクスを分析できます。
以下の Istio 統合は Red Hat OpenShift Service Mesh でサポートされます。
- 3scale: Istio では、オプションで Red Hat 3scale API Management ソリューションとの統合が提供されます。2.1 より前のバージョンでは、この統合は 3scale Istio アダプターを使用して実行されました。バージョン 2.1 以降では、3scale の統合は WebAssembly モジュールを介して行われます。
3scale アダプターのインストール方法に関する詳細は、3scale Istio アダプターのドキュメント を参照してください。
1.3.3. Kiali について
Kiali は、Service Mesh のマイクロサービスとそれらの接続方法を表示して Service Mesh を可視化します。
1.3.3.1. Kiali の概要
Kiali では、OpenShift Container Platform で実行される Service Mesh の可観測性 (Observability) を提供します。Kiali は、Istio サービスメッシュの定義、検証、および確認に役立ちます。トポロジーを推測することで Service Mesh の構造を理解するのに役立ち、Service Mesh の正常性に関する情報も提供します。
Kiali は、サーキットブレーカー、要求レート、レイテンシー、トラフィックフローのグラフなどの機能を可視化する、namespace のインタラクティブなグラフビューをリアルタイムで提供します。Kiali では、異なるレベルのコンポーネント (アプリケーションからサービスおよびワークロードまで) に関する洞察を提供し、選択されたグラフノードまたはエッジに関するコンテキスト情報やチャートを含む対話を表示できます。Kiali は、ゲートウェイ、宛先ルール、仮想サービス、メッシュポリシーなど、Istio 設定を検証する機能も提供します。Kiali は詳細なメトリックを提供し、基本的な Grafana 統合は高度なクエリーに利用できます。Jaeger を Kiali コンソールに統合することで、分散トレースを提供します。
Kiali は、デフォルトで Red Hat OpenShift Service Mesh の一部としてインストールされます。
1.3.3.2. Kiali アーキテクチャー
Kiali はオープンソースの Kiali プロジェクト に基づいています。Kiali は Kiali アプリケーションと Kiali コンソールという 2 つのコンポーネントで設定されます。
- Kiali アプリケーション (バックエンド): このコンポーネントはコンテナーアプリケーションプラットフォームで実行され、Service Mesh コンポーネントと通信し、データを取得し、処理し、そのデータをコンソールに公開します。Kiali アプリケーションはストレージを必要としません。アプリケーションをクラスターにデプロイする場合、設定は ConfigMap およびシークレットに設定されます。
- Kiali コンソール (フロントエンド): Kiali コンソールは Web アプリケーションです。Kiali アプリケーションは Kiali コンソールを提供し、データをユーザーに表示するためにバックエンドに対してデータのクエリーを実行します。
さらに Kiali は、コンテナーアプリケーションプラットフォームと Istio が提供する外部サービスとコンポーネントに依存します。
- Red Hat Service Mesh (Istio): Istio は Kiali の要件です。Istio は Service Mesh を提供し、制御するコンポーネントです。Kiali と Istio を個別にインストールすることはできますが、Kiali は Istio に依存し、Istio が存在しない場合は機能しません。Kiali は、Prometheus および Cluster API 経由で公開される Istio データおよび設定を取得する必要があります。
- Prometheus: 専用の Prometheus インスタンスは Red Hat OpenShift Service Mesh インストールの一部として組み込まれています。Istio Telemetry が有効になっている場合、メトリクスデータは Prometheus に保存されます。Kiali はこの Prometheus データを使用して、メッシュトポロジーの判別、メトリクスの表示、健全性の算出、可能性のある問題の表示などを行います。Kiali は Prometheus と直接通信し、Istio Telemetry で使用されるデータスキーマを想定します。Prometheus は Istio に依存しており、Kiali と明示的な依存関係があるため、Kiali の機能の多くは Prometheus なしに機能しません。
- Cluster API: Kiali はサービスメッシュ設定を取得し、解決するために、OpenShift Container Platform (Cluster API) の API を使用します。Kiali は Cluster API に対してクエリーを実行し、たとえば、namespace、サービス、デプロイメント、Pod、その他のエンティティーの定義を取得します。Kiali はクエリーを実行して、異なるクラスターエンティティー間の関係も解決します。Cluster API に対してもクエリーを実行し、仮想サービス、宛先ルール、ルートルール、ゲートウェイ、クォータなどの Istio 設定を取得します。
- Jaeger: Jaeger はオプションですが、Red Hat OpenShift Service Mesh インストールの一部としてデフォルトでインストールされます。デフォルトの Red Hat OpenShift Service Mesh インストールの一部として分散トレースプラットフォーム (Jaeger) をインストールすると、Kiali コンソールには分散トレースデータを表示するタブが含まれます。Istio の分散トレース機能を無効にした場合、トレースデータは利用できないことに注意してください。また、トレースデータを表示するには、ユーザーは Service Mesh コントロールプレーンがインストールされている namespace にアクセスできる必要があります。
- Grafana: Grafana はオプションですが、デフォルトでは Red Hat OpenShift Service Mesh インストールの一部としてインストールされます。使用可能な場合は、Kiali のメトリクスページに Grafana 内の同じメトリクスにユーザーを移動させるリンクが表示されます。Grafana ダッシュボードへのリンクと Grafana データを表示するには、Service Mesh コントロールプレーンがインストールされている namespace にユーザーがアクセスできる必要があることに注意してください。
1.3.3.3. Kiali の機能
Kiali コンソールは Red Hat Service Mesh に統合され、以下の機能を提供します。
- 健全性: アプリケーション、サービス、またはワークロードの問題を素早く特定します。
- トポロジー: Kiali グラフを使用して、アプリケーション、サービス、またはワークロードの通信方法を可視化します。
- メトリック: 事前定義済みのメトリックダッシュボードを使用すると、Go、Node.js、Quarkus、Spring Boot、Thorntail、および Vert.xまた、独自のカスタムダッシュボードを作成することもできます。
- トレース: Jaeger との統合により、アプリケーションを設定するさまざまなマイクロサービスで要求のパスを追跡できます。
- 検証: 最も一般的な Istio オブジェクト (宛先ルール、サービスエントリー、仮想サービスなど) で高度な検証を実行します。
- 設定: ウィザードを使用するか、Kiali コンソールの YAML エディターを直接使用して、Istio ルーティング設定を作成し、更新し、削除できるオプションの機能です。
1.3.4. 分散トレースについて
ユーザーがアプリケーションでアクションを実行するたびに、応答を生成するために多数の異なるサービスに参加を要求する可能性のあるアーキテクチャーによって要求が実行されます。この要求のパスは分散トランザクションです。分散トレースプラットフォーム (Jaeger) を使用すると、分散トレースを実行できます。これは、アプリケーションを設定するさまざまなマイクロサービスで要求のパスを追跡します。
分散トレースは、さまざまな作業ユニットの情報を連携させるために使用される技術です。これは、分散トランザクションでのイベントのチェーン全体を理解するために、通常さまざまなプロセスまたはホストで実行されます。分散トレースを使用すると、開発者は大規模なサービス指向アーキテクチャーで呼び出しフローを可視化できます。シリアル化、並行処理、およびレイテンシーの原因を理解しておくことも重要です。
分散トレースプラットフォーム (Jaeger) は、マイクロサービスのスタック全体で個別のリクエストの実行を記録し、トレースとして表示します。トレース とは、システムにおけるデータ/実行パスです。エンドツーエンドトレースは、1 つ以上のスパンで設定されます。
スパンは、オペレーション名、オペレーションの開始時間および期間を持つ、作業の論理単位を表しています。スパンは因果関係をモデル化するためにネスト化され、順序付けられます。
1.3.4.1. 分散トレースの概要
サービスの所有者は、分散トレースを使用してサービスをインストルメント化し、サービスアーキテクチャーに関する洞察を得ることができます。Red Hat OpenShift 分散トレーシングプラットフォームを使用すると、最新のクラウドネイティブのマイクロサービスベースのアプリケーションにおいてコンポーネント間の対話のモニタリング、ネットワークプロファイリング、トラブルシューティングが可能です。
分散トレースプラットフォームを使用すると、以下の機能を実行できます。
- 分散トランザクションの監視
- パフォーマンスとレイテンシーの最適化
- 根本原因分析の実行
分散トレースプラットフォームは、以下の 3 つのコンポーネントで設定されます。
- Red Hat OpenShift 分散トレーシングプラットフォーム (Jaeger)。これは、オープンソースの Jaeger プロジェクト に基づいています。
- Red Hat OpenShift 分散トレーシングプラットフォーム (Tempo)。オープンソースの Grafana Tempo プロジェクト に基づいています。
- Red Hat build of OpenTelemetry。オープンソースの OpenTelemetry プロジェクト に基づいています。
1.3.4.2. Red Hat OpenShift 分散トレーシングプラットフォームアーキテクチャー
Red Hat OpenShift 分散トレースプラットフォームは、複数のコンポーネントで設定されており、トレースデータを収集し、保存し、表示するためにそれらが連携します。
Red Hat OpenShift 分散トレースプラットフォーム (Jaeger): このコンポーネントは、オープンソースの Jaeger プロジェクト に基づいています。
- クライアント (Jaeger クライアント、Tracer、Reporter、インストルメント化されたアプリケーション、クライアントライブラリー): 分散トレースプラットフォーム (Jaeger) クライアントは、OpenTracing API の言語固有の実装です。それらは、手動または (Camel (Fuse)、Spring Boot (RHOAR)、MicroProfile (RHOAR/Thorntail)、Wildfly (EAP)、その他 OpenTracing にすでに統合されているものを含む) 各種の既存オープンソースフレームワークを使用して、分散トレース用にアプリケーションをインストルメント化するために使用できます。
- エージェント (Jaeger エージェント、Server Queue、Processor Worker): 分散トレースプラットフォーム (Jaeger) エージェントは、User Datagram Protocol (UDP) で送信されるスパンをリッスンするネットワークデーモンで、 Collector にバッチ処理や送信を実行します。このエージェントは、インストルメント化されたアプリケーションと同じホストに配置されることが意図されています。これは通常、Kubernetes などのコンテナー環境にサイドカーコンテナーを配置することによって実行されます。
- Jaeger Collector (Collector、Queue、Worker): Jaeger エージェントと同様に、Jaeger Collector はスパンを受信し、これらを処理するために内部キューに配置します。これにより、Jaeger Collector はスパンがストレージに移動するまで待機せずに、クライアント/エージェントにすぐに戻ることができます。
- Storage (Data Store): コレクターには永続ストレージのバックエンドが必要です。Red Hat OpenShift 分散トレースプラットフォーム (Jaeger) には、スパンストレージ用のプラグ可能なメカニズムがあります。このリリースでは、サポートされているストレージは Elasticsearch のみであることに注意してください。
- Query (Query Service): Query は、ストレージからトレースを取得するサービスです。
- Ingester (Ingester Service): Red Hat OpenShift 分散トレースプラットフォームは Apache Kafka を Collector と実際の Elasticsearch バッキングストレージ間のバッファーとして使用できます。Ingester は、Kafka からデータを読み取り、Elasticsearch ストレージバックエンドに書き込むサービスです。
- Jaeger Console: Red Hat OpenShift 分散トレースプラットフォーム (Jaeger) ユーザーインターフェイスを使用すると、分散トレースデータを可視化できます。検索ページで、トレースを検索し、個別のトレースを設定するスパンの詳細を確認できます。
Red Hat OpenShift 分散トレーシングプラットフォーム (Tempo): このコンポーネントは、オープンソースの Grafana Tempo プロジェクト に基づいています。
- Gateway: ゲートウェイは、認証、認可、およびディストリビューターまたはクエリーフロントエンドサービスへのリクエストの転送を処理します。
-
Distributor: ディストリビューターは、Jaeger、OpenTelemetry、Zipkin などの複数の形式のスパンを受け入れます。
トレース ID
をハッシュし、分散一貫性のあるハッシュリングを使用して、スパンを Ingesters にルーティングします。 - Ingester: Ingester はトレースをブロックにバッチ化し、ブルームフィルターとインデックスを作成してすべてバックエンドにフラッシュします。
- Query Frontend: Query Frontend は、受信クエリーの検索スペースをシャーディングします。次に、検索クエリーが Querier に送信されます。Query Frontend のデプロイメントでは、Tempo Query サイドカーを介して Jaeger UI が公開されます。
- Querier: Querier は、Ingester またはバックエンドストレージで要求されたトレース ID を検索します。パラメーターに応じて、Ingester にクエリーを実行し、バックエンドから Bloom インデックスを取得して、オブジェクトストレージ内のブロックを検索できます。
- Compactor: Compactor は、ブロックをバックエンドストレージとの間でストリーミングして、ブロックの総数を減らします。
Red Hat build of OpenTelemetry - このコンポーネントは、オープンソースの OpenTelemetry プロジェクト に基づいています。
- OpenTelemetry Collector: OpenTelemetry Collector は、テレメトリーデータを受信、処理、エクスポートするためのベンダーに依存しない方法です。OpenTelemetry Collector は、Jaeger や Prometheus などのオープンソースの可観測性データ形式をサポートし、1 つ以上のオープンソースまたは商用バックエンドに送信します。Collector は、インストルメンテーションライブラリーがテレメトリーデータをエクスポートするデフォルトの場所です。
1.3.4.3. Red Hat OpenShift 分散トレーシングプラットフォームの機能
Red Hat OpenShift 分散トレースプラットフォームは、以下の機能を提供します。
- Kiali との統合: 適切に設定されている場合は、Kiali コンソールから分散トレースプラットフォームデータを表示できます。
- 高いスケーラビリティー: 分散トレースプラットフォームのバックエンドは、単一障害点がなく、ビジネスニーズに合わせてスケーリングできるように設計されています。
- 分散コンテキストの伝播: さまざまなコンポーネントからのデータをつなぎ、完全なエンドツーエンドトレースを作成できます。
- Zipkin との後方互換性: Red Hat OpenShift 分散トレースプラットフォームには、Zipkin のドロップイン置き換えで使用できるようにする API がありますが、このリリースでは、Red Hat は Zipkin の互換性をサポートしていません。
1.3.5. 次のステップ
- OpenShift Container Platform 環境で Red Hat OpenShift Service Mesh をインストールする準備 をします。
1.4. サービスメッシュのデプロイメントモデル
Red Hat OpenShift Service Mesh は、さまざまなデプロイメントモデルを複数サポートし、ビジネス要件に最も適合するように、各種方法を組み合わせることができます。
Istio では、テナントはデプロイされたワークロードで共通のアクセスおよび権限を共有するユーザーのグループです。テナントを使用して、異なるチーム間で一定レベルの分離を確保できます。Istio.io またはサービスリソースの NetworkPolicies
、AuthorizationPolicies
、および exportTo
アノテーションを使用して、異なるテナントへのアクセスを分離できます。
1.4.1. クラスター全体 (シングルテナント) メッシュデプロイメントモデル
クラスター全体のデプロイメントには、クラスター全体のリソースを監視する Service Mesh Control Plane が含まれます。クラスター全体のリソースの監視は、コントロールプレーンがすべての名前空間にわたって単一のクエリーを使用して Istio および Kubernetes リソースを監視するという点で、Istio の機能によく似ています。その結果、クラスター全体のデプロイメントにより、API サーバーに送信されるリクエストの数が減少します。
Istio と同様に、クラスター全体のメッシュには、デフォルトで istio-injection=enabled
名前空間ラベルが付いた名前空間が含まれます。このラベルを変更するには、ServiceMeshMemberRoll
リソースの spec.labelSelectors
フィールドを変更します。
1.4.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.4.3. マルチテーマまたはフェデレーションされたデプロイメントモデル
フェデレーション は、個別の管理ドメインで管理される個別のメッシュ間でサービスとワークロードを共有できるデプロイメントモデルです。
Istio マルチクラスターモデルでは、メッシュ間だで高いレベルの信頼が必要なだけでなく、個々のメッシュが存在するすべての Kubernetes API サーバーへのリモートアクセスも必要です。Red Hat OpenShift Service Mesh のフェデレーションは、メッシュ間の最小限の信頼を前提とする Service Mesh のマルチクラスター実装に対して独自のアプローチを採用しています。
フェデレーションされたメッシュ は、単一のメッシュとして動作させるメッシュのグループです。各メッシュのサービスは、独自のサービスにできます。たとえば、別のメッシュからサービスをインポートすることでサービスを追加するメッシュは、メッシュ全体で同じサービスにさらにワークロードを追加し、高可用性を提供することや、その両方を組み合わせることができます。フェデレーションされたメッシュに参加するすべてのメッシュは個別に管理されたままなので、フェデレーション内の他のメッシュとの間でエクスポートやインポートされるサービスを明示的に設定する必要があります。証明書の生成、メトリック、トレース収集などのサポート機能は、それぞれのメッシュのローカルで機能します。
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
ラベルまたはアノテーションを指定します。
アップストリーム Istio | Red 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
ネットワーク設定を置き換えます。これにより、昇格した権限でサービスアカウントおよびプロジェクトに SCC (Security Context Constraints) へのアクセスを付与する必要がなくなります。
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 に送信します。
1.6. Service Mesh のインストールの準備
Red Hat OpenShift Service Mesh をインストールする前に、OpenShift Container Platform にサブスクライブし、サポート対象の設定で OpenShift Container Platform をインストールする必要があります。
1.6.1. 前提条件
- お使いの Red Hat アカウントに有効な OpenShift Container Platform サブスクリプションを用意します。サブスクリプションをお持ちでない場合は、営業担当者にお問い合わせください。
- OpenShift Container Platform 4.11 の概要 を確認します。
OpenShift Container Platform 4.11 をインストールします。制限されたネットワーク に Red Hat OpenShift Service Mesh をインストールする場合は、選択した OpenShift Container Platform インフラストラクチャーの手順に従います。
- AWS への OpenShift Container Platform 4.11 のインストール
- ユーザーによってプロビジョニングされた AWS への OpenShift Container Platform 4.11 のインストール
- ベアメタルへの OpenShift Container Platform 4.11 のインストール
- vSphere への OpenShift Container Platform 4.11 のインストール
- IBM Z および LinuxONE への OpenShift Container Platform 4.11 のインストール
- IBM Power への OpenShift Container Platform 4.11 のインストール
OpenShift Container Platform バージョンに一致する OpenShift Container Platform コマンドラインユーティリティーのバージョン (
oc
クライアントツール) をインストールし、これをパスに追加します。- OpenShift Container Platform 4.11 を使用している場合は、About the OpenShift CLI を参照してください。
Red Hat OpenShift Service Mesh のライフサイクルおよびサポートされるプラットフォームの詳細は、サポートポリシー を参照してください。
1.6.2. サポートされる構成
以下の設定は、Red Hat OpenShift Service Mesh の現行リリースでサポートされます。
1.6.2.1. サポート対象プラットフォーム
Red Hat OpenShift Service Mesh Operator は、複数のバージョンの ServiceMeshControlPlane
リソースをサポートします。バージョン 2.4 の Service Mesh コントロールプレーンは、以下のプラットフォームバージョンでサポートされます。
- Red Hat OpenShift Container Platform バージョン 4.10 以降
- Red Hat OpenShift Dedicated バージョン 4
- Azure Red Hat OpenShift (ARO) バージョン 4
- Red Hat OpenShift Service on AWS (ROSA)
1.6.2.2. サポートされない設定
明示的にサポート対象外とされているケースには、以下が含まれます。
- OpenShift Online は Red Hat OpenShift Service Mesh に対してはサポートされていません。
- Red Hat OpenShift Service Mesh では、Service Mesh が実行されているクラスター以外にあるマイクロサービスの管理はサポートしていません。
1.6.2.3. サポートされるネットワーク設定
Red Hat OpenShift Service Mesh は以下のネットワーク設定をサポートします。
- OpenShift-SDN
- OVN-Kubernetes は、サポートされているすべてのバージョンの OpenShift Container Platform で使用できます。
- OpenShift Container Platform で認定され、さらに Service Mesh 適合テストに合格したサードパーティーの Container Network Interface(CNI) プラグイン。詳細は、認定 OpenShift CNI プラグイン を参照してください。
1.6.2.4. Service Mesh でサポートされる設定
Red Hat OpenShift Service Mesh の本リリースは、OpenShift Container Platform x86_64、IBM Z、および IBM Power でのみ利用できます。
- IBM Z は OpenShift Container Platform 4.10 以降でのみサポートされます。
- IBM Power は OpenShift Container Platform 4.10 以降でのみサポートされます。
- すべての Service Mesh コンポーネントが単一の OpenShift Container Platform クラスター内に含まれる設定。
- 仮想マシンなどの外部サービスを統合しない設定。
-
Red Hat OpenShift Service Mesh は、明示的に文書化されている場合を除き、
EnvoyFilter
の設定はサポートしていません。
1.6.2.5. Kiali のサポートされる設定
- Kiali コンソールは、Google Chrome、Microsoft Edge、Mozilla Firefox、または Apple Safari ブラウザーの最新の 2 つのリリースでのみサポートされています。
-
OpenShift
認証ストラテジーは、Kiali が Red Hat OpenShift Service Mesh (OSSM) とともにデプロイされている場合にサポートされる唯一の認証設定です。openshift
ストラテジーは、OpenShift Container Platform の個人のロールベースのアクセス制御 (RBAC) ロールに基づいてアクセスを制御します。
1.6.2.6. 分散トレースのサポートされる設定
- サイドカーとしての Jaeger エージェントは、Jaeger でサポートされる唯一の設定です。デーモンセットとしての Jaeger はマルチテナントインストールまたは OpenShift Dedicated ではサポートされません。
1.6.2.7. サポート対象の WebAssembly モジュール
- 3scale WebAssembly は、提供されている唯一の WebAssembly モジュールです。カスタム WebAssembly モジュールを作成できます。
1.6.3. 次のステップ
- OpenShift Container Platform 環境に Red Hat OpenShift Service Mesh をインストール します。
1.7. Operator のインストール
Red Hat OpenShift Service Mesh をインストールするには、まず必要な Operator を OpenShift Container Platform にインストールし、コントロールプレーンをデプロイするために ServiceMeshControlPlane
リソースを作成します。
この基本的なインストールはデフォルトの OpenShift 設定に基づいて設定され、実稼働環境での使用を目的としていません。 このデフォルトインストールを使用してインストールを確認し、お使いの環境に Service Mesh を設定します。
前提条件
- Red Hat OpenShift Service Mesh のインストールの準備 のプロセスを確認している。
-
cluster-admin
ロールを持つアカウントがある。(Red Hat OpenShift Dedicated を使用する場合)dedicated-admin
ロールがあるアカウント。
以下の手順では、OpenShift Container Platform に Red Hat OpenShift Service Mesh の基本的なインスタンスをインストールする方法について説明します。
1.7.1. Operator の概要
Red Hat OpenShift Service Mesh には、以下の 4 つの Operator が必要です。
- OpenShift Elasticsearch:(オプション) 分散トレースプラットフォーム (Jaeger) でのトレースおよびロギング用にデータベースストレージを提供します。これはオープンソースの Elasticsearch プロジェクトに基づいています。
- Red Hat OpenShift 分散トレースプラットフォーム (Jaeger): 複雑な分散システムでのトランザクションを監視し、トラブルシューティングするための分散トレース機能を提供します。これはオープンソースの Jaeger プロジェクトに基づいています。
- Red Hat が提供する Kiali Operator: Service Mesh の可観測性を提供します。これにより、単一のコンソールで設定を表示し、トラフィックを監視し、トレースの分析を実行できます。これはオープンソースの Kiali プロジェクトに基づいています。
-
Red Hat OpenShift Service Mesh: アプリケーションを設定するマイクロサービスを接続し、保護し、制御し、観察できます。Service Mesh Operator は、Service Mesh コンポーネントのデプロイメント、更新、および削除を管理する
ServiceMeshControlPlane
リソースを定義し、監視します。これはオープンソースの Istio プロジェクトに基づいています。
Operator のコミュニティーバージョンはインストールしないでください。コミュニティー Operator はサポートされていません。
1.7.2. Operator のインストール
Red Hat OpenShift Service Mesh をインストールするには、以下の Operator をこの順序でインストールします。Operator ごとに手順を繰り返します。
- OpenShift Elasticsearch
- Red Hat OpenShift 分散トレースプラットフォーム (Jaeger)
- Red Hat が提供する Kiali Operator
- Red Hat OpenShift Service Mesh
OpenShift Logging の一部として OpenShift Elasticsearch Operator がすでにインストールされている場合は、OpenShift Elasticsearch Operator を再びインストールする必要はありません。Red Hat OpenShift 分散トレースプラットフォーム (Jaeger) Operator はインストールされた OpenShift Elasticsearch Operator を使用して Elasticsearch インスタンスを作成します。
手順
-
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。(Red Hat OpenShift Dedicated を使用する場合)dedicated-admin
ロールがあるアカウント。 - OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- Operator のフィルターボックスに名前を入力し、Red Hat バージョンの Operator を選択します。Operator のコミュニティーバージョンはサポートされていません。
- Install をクリックします。
- 各 Operator の Install Operator ページで、デフォルト設定を受け入れます。
Install をクリックします。Operator がインストールされるまで待機してから、一覧で次に来る Operator で手順を繰り返します。
-
OpenShift Elasticsearch Operator は、
openshift-operators-redhat
namespace にインストールされ、クラスター内のすべての namespace で使用できます。 -
Red Hat OpenShift 分散トレースプラットフォーム (Jaeger) は、
openshift-distributed-tracing
namespace にインストールされ、クラスター内のすべての namespace で使用できます。 -
Red Hat および Red Hat OpenShift Service Mesh Operator が提供する Kiali Operator は
openshift-operators
namespace にインストールされ、クラスター内のすべての namespace で使用できます。
-
OpenShift Elasticsearch Operator は、
- 4 つの Operator すべてをインストールしたら、Operators → Installed Operators をクリックし、Operator がインストールされていることを確認します。
1.7.3. インフラストラクチャーノード上で実行する Service Mesh Operator の設定
このタスクは、Service Mesh Operator がインフラストラクチャーノードで実行されている場合にのみ実行する必要があります。
Operator をワーカーノード上で実行する場合は、このタスクを省略してください。
前提条件
- Service Mesh Operator がインストールされている。
- デプロイメントを構成するノードのいずれかが、インフラストラクチャーノードである。詳細は、「インフラストラクチャーマシンセットの作成」を参照してください。
手順
namespace にインストールされている Operator を一覧表示します。
$ oc -n openshift-operators get subscriptions
Service Mesh Operator
Subscription
リソースを編集して、Operator を実行する場所を指定します。$ oc -n openshift-operators edit subscription <name> 1
- 1
<name>
は、Subscription
リソースの名前です。Subscription
リソースのデフォルト名はservicemeshoperator
です。
Subscription
リソースのspec.config
に、NodeSelector
とtolerations
を追加します。spec: config: nodeSelector: 1 node-role.kubernetes.io/infra: "" tolerations: 2 - effect: NoSchedule key: node-role.kubernetes.io/infra value: reserved - effect: NoExecute key: node-role.kubernetes.io/infra value: reserved
1.7.4. Service Mesh Operator のインフラストラクチャーノードでの実行を検証
手順
Operator Pod に関連付けられたノードがインフラストラクチャーノードであることを確認します。
$ oc -n openshift-operators get po -l name=istio-operator -owide
1.7.5. 次のステップ
-
Red Hat OpenShift Service Mesh Operator は、Service Mesh コントロールプレーンをデプロイするまで、Service Mesh カスタムリソース定義 (CRD) を作成しません。
ServiceMeshControlPlane
リソースを使用して、Service Mesh コンポーネントをインストールおよび設定できます。詳細は、Creating the ServiceMeshControlPlane を参照してください。
1.8. ServiceMeshControlPlane の作成
1.8.1. About ServiceMeshControlPlane
コントロールプレーンには、Istiod、Ingress および Egress Gateway、Kiali や Jaeger などのその他コンポーネントが含まれます。コントロールプレーンは、Service Mesh Operator やデータプレーンアプリケーションおよびサービスとは別の namespace にデプロイする必要があります。OpenShift Container Platform Web コンソールまたはコマンドラインから oc
クライアントツールを使用して、ServiceMeshControlPlane
(SMCP) の基本的なインストールをデプロイできます。
この基本インストールは、デフォルトの OpenShift Container Platform 設定に基づいて設定されており、実稼働環境での使用を目的として設計されていません。このデフォルトのインストールを使用してインストールを確認し、環境に合わせて ServiceMeshControlPlane
設定を設定します。
Red Hat OpenShift Service on AWS (ROSA) では、リソースを作成できる場所に関して追加の制限が適用されるので、デフォルトのデプロイメントは機能しません。ROSA 環境に SMCP をデプロイメントする前の追加要件は、「Red Hat OpenShift Service on AWS へのService Mesh のインストール」を参照してください。
Service Mesh に関するドキュメントは istio-system
をサンプルプロジェクトとして使用しますが、Service Mesh を任意のプロジェクトにデプロイできます。
1.8.1.1. Web コンソールからの Service Mesh コントロールプレーンのデプロイ
Web コンソールを使用して基本的な ServiceMeshControlPlane
をデプロイできます。この例では、istio-system
が Service Mesh コントロールプレーンプロジェクトの名前となります。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされている必要がある。
-
cluster-admin
ロールを持つアカウントがある。
手順
-
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。(Red Hat OpenShift Dedicated を使用する場合)dedicated-admin
ロールがあるアカウント。 istio-system
という名前のプロジェクトを作成します。- Home → Projects に移動します。
- Create Project をクリックします。
Name
フィールドに istio-system と入力します。ServiceMeshControlPlane
リソースは、マイクロサービスおよび Operator とは異なるプロジェクトにインストールする必要があります。これらのステップは
istio-system
を例として使用しますが、サービスが含まれるプロジェクトから分離されない限り、Service Mesh コントロールプレーンを任意のプロジェクトにデプロイできます。- Create をクリックします。
- Operators → Installed Operators に移動します。
- Red Hat OpenShift Service Mesh Operator をクリックした後に、Istio Service Mesh Control Plane をクリックします。
- Istio Service Mesh Control Plane タブで Create ServiceMeshControlPlane をクリックします。
Create ServiceMeshControlPlane ページで、デフォルトの Service Mesh コントロールプレーンバージョンを受け入れて、製品の最新バージョンで利用可能な機能を活用します。コントロールプレーンのバージョンは、Operator のバージョンに関係なく利用可能な機能を判別します。
-
Create をクリックします。Operator は、設定パラメーターに基づいて Pod、サービス、Service Mesh コントロールプレーンのコンポーネントを作成します。
ServiceMeshControlPlane
設定は後で設定できます。
-
Create をクリックします。Operator は、設定パラメーターに基づいて Pod、サービス、Service Mesh コントロールプレーンのコンポーネントを作成します。
Istio Service Mesh Control Plane タブをクリックしてコントロールプレーンが正常にインストールされることを確認します。
- 新規コントロールプレーンの名前をクリックします。
- Resources タブをクリックして、Red Hat OpenShift Service Mesh コントロールプレーンリソース (Operator が作成し、設定したもの) を表示します。
1.8.1.2. CLI を使用した Service Mesh コントロールプレーンのデプロイ
コマンドラインから基本的な ServiceMeshControlPlane
をデプロイできます。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされている必要がある。
-
OpenShift CLI (
oc
) へのアクセスがある。
手順
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。(Red Hat OpenShift Dedicated を使用する場合)dedicated-admin
ロールがあるアカウント。$ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
istio-system
という名前のプロジェクトを作成します。$ oc new-project istio-system
以下の例を使用して
istio-installation.yaml
という名前のServiceMeshControlPlane
ファイルを作成します。Service Mesh コントロールプレーンのバージョンは、Operator のバージョンに関係なく利用可能な機能を判別します。バージョン 2.4 istio-installation.yaml の例
apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane metadata: name: basic namespace: istio-system spec: version: v2.4 tracing: type: Jaeger sampling: 10000 addons: jaeger: name: jaeger install: storage: type: Memory kiali: enabled: true name: kiali grafana: enabled: true
以下のコマンドを実行して Service Mesh コントロールプレーンをデプロイします。ここで、
<istio_installation.yaml>
にはファイルへの完全パスが含まれます。$ oc create -n istio-system -f <istio_installation.yaml>
Pod のデプロイメントの進行状況を監視するには、次のコマンドを実行します。
$ oc get pods -n istio-system -w
以下のような出力が表示されるはずです。
NAME READY STATUS RESTARTS AGE grafana-b4d59bd7-mrgbr 2/2 Running 0 65m istio-egressgateway-678dc97b4c-wrjkp 1/1 Running 0 108s istio-ingressgateway-b45c9d54d-4qg6n 1/1 Running 0 108s istiod-basic-55d78bbbcd-j5556 1/1 Running 0 108s jaeger-67c75bd6dc-jv6k6 2/2 Running 0 65m kiali-6476c7656c-x5msp 1/1 Running 0 43m prometheus-58954b8d6b-m5std 2/2 Running 0 66m
1.8.1.3. CLI を使用した SMCP インストールの検証
コマンドラインから ServiceMeshControlPlane
の作成を検証できます。
手順
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。(Red Hat OpenShift Dedicated を使用する場合)dedicated-admin
ロールがあるアカウント。$ oc login https://<HOSTNAME>:6443
次のコマンドを実行して、Service Mesh コントロールプレーンのインストールを確認します。
istio-system
は、Service Mesh コントロールプレーンをインストールした namespace です。$ oc get smcp -n istio-system
STATUS
列がComponentsReady
の場合は、インストールが正常に終了しています。NAME READY STATUS PROFILES VERSION AGE basic 10/10 ComponentsReady ["default"] 2.1.1 66m
1.8.2. コントロールプレーンコンポーネントとインフラストラクチャーノードについて
インフラストラクチャーノードは、次の 2 つの主な目的のためにインフラストラクチャーのワークロードを分離する方法を提供します。
- サブスクリプション数に対する請求コストの発生を防ぐため
- インフラストラクチャーのワークロードの保守と管理を分離するため
Service Mesh コントロールプレーンコンポーネントの一部またはすべてをインフラストラクチャーノード上で実行するように設定できます。
1.8.2.1. Web コンソールを使用してインフラストラクチャーノード上で実行されるようにすべてのコントロールプレーンコンポーネントを設定する
Service Mesh コントロールプレーンによってデプロイされたすべてのコンポーネントがインフラストラクチャーノードで実行される場合は、このタスクを実行します。これらのデプロイされたコンポーネントには、Istiod、Ingress Gateway、Egress Gateway、および Prometheus、Grafana、Distributed Tracing などのオプションのアプリケーションが含まれます。
コントロールプレーンをワーカーノード上で実行する場合は、このタスクを省略してください。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされています。
-
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 をクリックします。
-
コントロールプレーンリソースの名前をクリックします。たとえば、
basic
です。 - YAML をクリックします。
次の例に示すように、
nodeSelector
フィールドとtolerations
フィールドをServiceMeshControlPlane
リソースのspec.runtime.defaults.pod
仕様に追加します。spec: runtime: defaults: pod: nodeSelector: 1 node-role.kubernetes.io/infra: "" tolerations: 2 - effect: NoSchedule key: node-role.kubernetes.io/infra value: reserved - effect: NoExecute key: node-role.kubernetes.io/infra value: reserved
- Save をクリックします。
- Reload をクリックします。
1.8.2.2. Web コンソールを使用してインフラストラクチャーノード上で実行されるように個別のコントロールプレーンコンポーネントを設定する
Service Mesh コントロールプレーンによってデプロイされた個々のコンポーネントがインフラストラクチャーノードで実行される場合は、このタスクを実行します。これらのデプロイされたコンポーネントには、Istiod、Ingress Gateway、および Egress Gateway が含まれます。
コントロールプレーンをワーカーノード上で実行する場合は、このタスクを省略してください。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされています。
-
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 をクリックします。
-
コントロールプレーンリソースの名前をクリックします。たとえば、
basic
です。 - YAML をクリックします。
次の例に示すように、
nodeSelector フィールド
とtolerations
フィールドをServiceMeshControlPlane
リソースのspec.runtime.components.pilot.pod
仕様に追加します。spec: runtime: components: pilot: pod: nodeSelector: 1 node-role.kubernetes.io/infra: "" tolerations: 2 - effect: NoSchedule key: node-role.kubernetes.io/infra value: reserved - effect: NoExecute key: node-role.kubernetes.io/infra value: reserved
次の例に示すように、
nodeSelector
フィールドとtolerations
フィールドをServiceMeshControlPlane
リソースのspec.gateways.ingress.runtime.pod
およびspec.gateways.egress.runtime.pod
仕様に追加します。spec: gateways: ingress: runtime: pod: nodeSelector: 1 node-role.kubernetes.io/infra: "" tolerations: 2 - effect: NoSchedule key: node-role.kubernetes.io/infra value: reserved - effect: NoExecute key: node-role.kubernetes.io/infra value: reserved egress: runtime: pod: nodeSelector: 3 node-role.kubernetes.io/infra: "" tolerations: 4 - effect: NoSchedule key: node-role.kubernetes.io/infra value: reserved - effect: NoExecute key: node-role.kubernetes.io/infra value: reserved
- Save をクリックします。
- Reload をクリックします。
1.8.2.3. CLI を使用してインフラストラクチャーノード上で実行されるようにすべてのコントロールプレーンコンポーネントを設定する
Service Mesh コントロールプレーンによってデプロイされたすべてのコンポーネントがインフラストラクチャーノードで実行される場合は、このタスクを実行します。これらのデプロイされたコンポーネントには、Istiod、Ingress Gateway、Egress Gateway、および Prometheus、Grafana、Distributed Tracing などのオプションのアプリケーションが含まれます。
コントロールプレーンをワーカーノード上で実行する場合は、このタスクを省略してください。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされています。
-
cluster-admin
ロールを持つユーザーとしてログインしています。Red Hat OpenShift Dedicated を使用する場合は、dedicated-admin
ロールを持つユーザーとしてログインします。
手順
ServiceMeshControlPlane
リソースを YAML ファイルとして開きます。$ oc -n istio-system edit smcp <name> 1
- 1
<name>
は、ServiceMeshControlPlane
リソースの名前を表します。
ServiceMeshControlPlane
によってデプロイされたすべての Service Mesh コンポーネントをインフラストラクチャーノードで実行するには、ServiceMeshControlPlane
リソースのspec.runtime.defaults.pod
仕様にnodeSelector
フィールドとtolerations
フィールドを追加します。spec: runtime: defaults: pod: nodeSelector: 1 node-role.kubernetes.io/infra: "" tolerations: 2 - effect: NoSchedule key: node-role.kubernetes.io/infra value: reserved - effect: NoExecute key: node-role.kubernetes.io/infra value: reserved
1.8.2.4. CLI を使用してインフラストラクチャーノード上で実行されるように個別のコントロールプレーンコンポーネントを設定する
Service Mesh コントロールプレーンによってデプロイされた個々のコンポーネントがインフラストラクチャーノードで実行される場合は、このタスクを実行します。これらのデプロイされたコンポーネントには、Istiod、Ingress Gateway、および Egress Gateway が含まれます。
コントロールプレーンをワーカーノード上で実行する場合は、このタスクを省略してください。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされています。
-
cluster-admin
ロールを持つユーザーとしてログインしています。Red Hat OpenShift Dedicated を使用する場合は、dedicated-admin
ロールを持つユーザーとしてログインします。
手順
ServiceMeshControlPlane
リソースを YAML ファイルとして開きます。$ oc -n istio-system edit smcp <name> 1
- 1
<name>
は、ServiceMeshControlPlane
リソースの名前を表します。
インフラストラクチャーノードで Istiod コンポーネントを実行するには、
ServiceMeshControlPlane
リソースのspec.runtime.components.pilot.pod
仕様にnodeSelector
フィールドとtolerations
フィールドを追加します。spec: runtime: components: pilot: pod: nodeSelector: 1 node-role.kubernetes.io/infra: "" tolerations: 2 - effect: NoSchedule key: node-role.kubernetes.io/infra value: reserved - effect: NoExecute key: node-role.kubernetes.io/infra value: reserved
Ingress Gateway と Egress Gateway をインフラストラクチャーノードで実行する場合は、
ServiceMeshControlPlane
リソースのspec.gateways.ingress.runtime.pod
仕様とspec.gateways.egress.runtime.pod
仕様に、nodeSelector
フィールドとtolerations
フィールドを追加します。spec: gateways: ingress: runtime: pod: nodeSelector: 1 node-role.kubernetes.io/infra: "" tolerations: 2 - effect: NoSchedule key: node-role.kubernetes.io/infra value: reserved - effect: NoExecute key: node-role.kubernetes.io/infra value: reserved egress: runtime: pod: nodeSelector: 3 node-role.kubernetes.io/infra: "" tolerations: 4 - effect: NoSchedule key: node-role.kubernetes.io/infra value: reserved - effect: NoExecute key: node-role.kubernetes.io/infra value: reserved
1.8.2.5. Service Mesh コントロールプレーンがインフラストラクチャーノードで実行されていることの検証
手順
Istiod、Ingress Gateway、Egress Gateway Pod に関連付けられたノードがインフラストラクチャーノードであることを確認します。
$ oc -n istio-system get pods -owide
1.8.3. コントロールプレーンとクラスター全体のデプロイメントについて
クラスター全体のデプロイメントには、クラスター全体のリソースを監視する Service Mesh Control Plane が含まれます。クラスター全体のリソースの監視は、コントロールプレーンがすべての名前空間にわたって単一のクエリーを使用して Istio および Kubernetes リソースを監視するという点で、Istio の機能によく似ています。その結果、クラスター全体のデプロイメントにより、API サーバーに送信されるリクエストの数が減少します。
OpenShift Container Platform Web コンソールまたは CLI を使用して、クラスター全体のデプロイメント用に Service Mesh コントロールプレーンを設定できます。
1.8.3.1. Web コンソールを使用したクラスター全体のデプロイメント用のコントロールプレーンの設定
OpenShift Container Platform Web コンソールを使用して、クラスター全体のデプロイメント用に ServiceMeshControlPlane
リソースを設定できます。この例では、istio-system
が Service Mesh コントロールプレーンプロジェクトの名前となります。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされています。
-
cluster-admin
ロールを持つアカウントを使用してログインしているか、Red Hat OpenShift Dedicated をdedicated-admin
ロールを持つアカウントを使用してログインしています。
手順
istio-system
という名前のプロジェクトを作成します。- Home → Projects に移動します。
- Create Project をクリックします。
Name
フィールドに istio-system と入力します。ServiceMeshControlPlane
リソースは、マイクロサービスおよび Operator とは異なるプロジェクトにインストールする必要があります。これらの手順では、
istio-system
をサンプルとして使用します。Service Mesh コントロールプレーンは、サービスが含まれるプロジェクトから分離されている限り、任意のプロジェクトにデプロイできます。- Create をクリックします。
- Operators → Installed Operators に移動します。
- Red Hat OpenShift Service Mesh Operator をクリックした後に、Istio Service Mesh Control Plane をクリックします。
- Istio Service Mesh Control Plane タブで Create ServiceMeshControlPlane をクリックします。
- YAML view をクリックします。Service Mesh コントロールプレーンのバージョンは、Operator のバージョンに関係なく利用可能な機能を判別します。
YAML ファイルの
spec.mode
フィールドを変更して、Clusterwide
を指定します。バージョン 2.4 istio-installation.yaml の例
apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane metadata: name: basic namespace: istio-system spec: version: v2.4 mode: ClusterWide
-
Create をクリックします。Operator は、設定パラメーターに基づいて Pod、サービス、Service Mesh コントロールプレーンのコンポーネントを作成します。
ServiceMeshMemberRoll
がデフォルト設定の一部として存在しないと、オペレーターは ServiceMeshMemberRoll も作成します。 Istio Service Mesh Control Plane タブをクリックしてコントロールプレーンが正常にインストールされることを確認します。
-
新しい
ServiceMeshControlPlane
オブジェクトの名前をクリックします。 - Resources タブをクリックして、Red Hat OpenShift Service Mesh コントロールプレーンリソース (Operator が作成し、設定したもの) を表示します。
-
新しい
このモジュールは、次のアセンブリーに含まれています: * service_mesh/v2x/ossm-create-smcp.adoc :_mod-docs-content-type: PROCEDURE
1.8.3.2. CLI を使用したクラスター全体のデプロイメント用のコントロールプレーンの設定
CLI を使用して、クラスター全体のデプロイメント用に ServiceMeshControlPlane
リソースを設定できます。この例では、istio-system
は Service Mesh コントロールプレーンの namespace の名前です。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされています。
-
OpenShift CLI (
oc
) にアクセスできる。
手順
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。(Red Hat OpenShift Dedicated を使用する場合)dedicated-admin
ロールがあるアカウント。$ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
istio-system
という名前のプロジェクトを作成します。$ oc new-project istio-system
以下の例を使用して
istio-installation.yaml
という名前のServiceMeshControlPlane
ファイルを作成します。バージョン 2.4 istio-installation.yaml の例
apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane metadata: name: basic namespace: istio-system spec: version: v2.4 mode: ClusterWide
以下のコマンドを実行して Service Mesh コントロールプレーンをデプロイします。ここで、
<istio_installation.yaml>
にはファイルへの完全パスが含まれます。$ oc create -n istio-system -f <istio_installation.yaml>
Pod のデプロイの進行状況を監視するには、次のコマンドを実行します。
$ oc get pods -n istio-system -w
次の例のような出力が表示されるはずです。
出力例
NAME READY STATUS RESTARTS AGE grafana-b4d59bd7-mrgbr 2/2 Running 0 65m istio-egressgateway-678dc97b4c-wrjkp 1/1 Running 0 108s istio-ingressgateway-b45c9d54d-4qg6n 1/1 Running 0 108s istiod-basic-55d78bbbcd-j5556 1/1 Running 0 108s jaeger-67c75bd6dc-jv6k6 2/2 Running 0 65m kiali-6476c7656c-x5msp 1/1 Running 0 43m prometheus-58954b8d6b-m5std 2/2 Running 0 66m
このモジュールは次のアセンブリに含まれています: * service_mesh/v2x/ossm-create-smcp.adoc
1.8.3.3. クラスター全体のメッシュのメンバーロールのカスタマイズ
クラスター全体モードでは、ServiceMeshControlPlane
リソースを作成すると、ServiceMeshMemberRoll
リソースも作成されます。ServiceMeshMemberRoll
リソースは、作成後に変更できます。リソースを変更すると、Service Mesh オペレーターはそのリソースを変更しなくなります。OpenShift Container Platform Web コンソールを使用して ServiceMeshMemberRoll
リソースを変更する場合は、変更を上書きするプロンプトを受け入れます。
または、ServiceMeshControlPlane
リソースをデプロイする前に ServiceMeshMemberRoll
リソースを作成することもできます。ServiceMeshControlPlane
リソースを作成するとき、Service Mesh Operator は ServiceMeshMemberRoll
を変更しません。
ServiceMeshMemberRoll
リソース名には、default
という名前を付け、ServiceMeshControlPlane
リソースと同じプロジェクト名前空間に作成する必要があります。
メッシュに名前空間を追加するには 2 つの方法があります。spec.members
リストで名前を指定して名前空間を追加することも、ラベルに基づいて名前空間を含めるか除外するように一連の名前空間ラベルセレクターを設定することもできます。
ServiceMeshMemberRoll
リソースでメンバーがどのように指定されているかに関係なく、各名前空間に ServiceMeshMember
リソースを作成してメッシュにメンバーを追加することもできます。
1.8.4. Kiali を使用した SMCP インストールの検証
Kiali コンソールを使用して、Service Mesh のインストールを検証できます。Kiali コンソールには、Service Mesh コンポーネントが適切にデプロイおよび設定されていることを検証する方法がいくつかあります。
手順
-
cluster-admin 権限を持つユーザーとして OpenShift Container Platform Web コンソールにログインします。(Red Hat OpenShift Dedicated を使用する場合)
dedicated-admin
ロールがあるアカウント。 - Networking → Routes に移動します。
Routes ページで、Namespace メニューから Service Mesh コントロールプレーンプロジェクトを選択します (例:
istio-system
)。Location 列には、各ルートのリンク先アドレスが表示されます。
- 必要に応じて、フィルターを使用して Kiali コンソールのルートを見つけます。ルートの Location をクリックしてコンソールを起動します。
Log In With OpenShift をクリックします。
初回の Kiali コンソールへのログイン時に、表示するパーミッションを持つ Service Mesh 内のすべての namespace を表示する Overview ページが表示されます。概要 ページに複数の namespace が表示されている場合は、Kiali は最初に正常性または検証に問題がある namespace を表示します。
図1.1 Kiali の概要ページ
各 namespace のタイルには、ラベルの数、Istio Config の状態、アプリケーション の状態と数、namespace の トラフィック が表示されます。コンソールのインストールを検証中で、namespace がまだメッシュに追加されていないと、
istio-system
以外のデータは表示されない可能性があります。Kiali には、Service Mesh コントロールプレーンがインストールされている namespace 専用のダッシュボードが 4 つあります。これらのダッシュボードを表示するには、オプション メニューをクリックします コントロールプレーン namespace のタイル (例:
istio-system
) で、次のいずれかのオプションを選択します。- Istio メッシュダッシュボード
- Istio コントロールプレーンダッシュボード
- Istio パフォーマンスダッシュボード
Istio Wasm Exetension ダッシュボード
図1.2 GrafanaIstio コントロールプレーンダッシュボード
Kiali は、Grafana ホームページ から入手できる追加の Grafana ダッシュボード 2 つもインストールします。
- Istio ワークロードダッシュボード
- Istio サービスダッシュボード
Service Mesh コントロールプレーンノードを表示するには、グラフ ページをクリックし、メニューから
ServiceMeshControlPlane
をインストールした Namespace を選択します (例:istio-system
)。- 必要に応じて、Display idle nodes をクリックします。
- グラフ ページの詳細は、グラフツアー リンクをクリックしてください。
- メッシュトポロジーを表示するには、namespace メニューの Service Mesh メンバーロールから追加の namespace を 1 つまたは複数選択します。
istio-system
namespace 内のアプリケーションのリストを表示するには、アプリケーション ページをクリックします。Kiali は、アプリケーションの状態を表示します。- 情報アイコンの上にマウスをかざすと、詳細 列に記載されている追加情報が表示されます。
istio-system
namespace のワークロードのリストを表示するには、ワークロード ページをクリックします。Kiali は、ワークロードの状態を表示します。- 情報アイコンの上にマウスをかざすと、詳細 列に記載されている追加情報が表示されます。
istio-system
namespace のサービスのリストを表示するには、サービス ページをクリックします。Kiali は、サービスと設定の状態を表示します。- 情報アイコンの上にマウスをかざすと、詳細 列に記載されている追加情報が表示されます。
istio-system
namespace の Istio 設定オブジェクトのリストを表示するには、Istio Config ページをクリックします。Kiali は、設定の正常性を表示します。- 設定エラーがある場合は、行をクリックすると、Kiali が設定ファイルを開き、エラーが強調表示されます。
1.8.5. Red Hat OpenShift Service on AWS (ROSA) へのインストール
バージョン 2.2 以降、Red Hat OpenShift Service Mesh は Red Hat OpenShift Service on AWS (ROSA) へのインストールがサポートされます。このセクションでは、このプラットフォームに Service Mesh をインストールする際の追加の要件を説明します。
1.8.5.1. インストールの場所
Red Hat OpenShift Service Mesh をインストールし、ServiceMeshControlPlane
を作成する際に、istio-system
などの新規 namespace を作成する必要があります。
1.8.5.2. 必要な Service Mesh コントロールプレーンの設定
ServiceMeshControlPlane
ファイルのデフォルト設定は ROSA クラスターでは機能しません。Red Hat OpenShift Service on AWS にインストールする場合は、デフォルトの SMCP を変更し、spec.security.identity.type=ThirdParty
を設定する必要があります。
ROSA 用の ServiceMeshControlPlane
リソースの例
apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane metadata: name: basic namespace: istio-system spec: version: v2.4 security: identity: type: ThirdParty #required setting for ROSA tracing: type: Jaeger sampling: 10000 policy: type: Istiod addons: grafana: enabled: true jaeger: install: storage: type: Memory kiali: enabled: true prometheus: enabled: true telemetry: type: Istiod
1.8.5.3. Kiali 設定の制限
Red Hat OpenShift Service on AWS では、リソースを作成できる場所に関して追加の制限が適用され、Red Hat 管理の namespace に Kiali リソースを作成することはできません。
つまり、ROSA クラスターでは、spec.deployment.accessible_namespaces
の以下の共通設定は許可されません。
-
['**']
(すべての namespaces) -
default
-
codeready-*
-
openshift-*
-
redhat-*
検証エラーメッセージでは、制限されたすべての namespace の完全なリストが提供されます。
ROSA 用の Kiali
リソースの例
apiVersion: kiali.io/v1alpha1 kind: Kiali metadata: name: kiali namespace: istio-system spec: auth: strategy: openshift deployment: accessible_namespaces: #restricted setting for ROSA - istio-system image_pull_policy: '' ingress_enabled: true namespace: istio-system
1.8.6. 関連情報
Red Hat OpenShift Service Mesh はクラスター内で複数の独立したコントロールプレーンをサポートします。ServiceMeshControlPlane
プロファイルを使用すると、再利用可能な設定を作成ができます。詳細は、Creating control plane profiles を参照してください。
1.8.7. 次のステップ
- プロジェクトを Service Mesh に追加してアプリケーションを利用可能にします。詳細は、Adding services to a service mesh を参照してください。
1.9. Service Mesh へのサービスの追加
プロジェクトにはサービスが含まれますが、そのプロジェクトを Service Mesh に追加していなければサービスは使用できません。
1.9.1. Service Mesh へのプロジェクトの追加
Operator をインストールして ServiceMeshControlPlane
リソースを作成した後、1 つ以上のプロジェクトを Service Mesh に追加します。
基本的に、OpenShift Container Platform でのプロジェクトとは、プロジェクトで使用できるユーザー ID 範囲などの追加のアノテーションを持つ Kubernetes namespace です。通常、OpenShift Container Platform Web コンソールではプロジェクトという用語が使用され、CLI では namespace という用語が使用されますが、この 2 つの用語は基本的に同義です。
OpenShift Container Platform Web コンソールまたは CLI のいずれかを使用して、既存の Service Mesh にプロジェクトを追加できます。プロジェクトをサービスメッシュに追加するには、次の 3 つの方法があります。
-
ServiceMeshMemberRoll
リソースでプロジェクト名を指定する方法。 -
ServiceMeshMemberRoll
リソースのspec.labelSelectors
フィールドでラベルセレクターを設定します。 -
プロジェクトで
ServiceMeshMember
リソースを作成する方法。
最初の方法を使用する場合は、ServiceMeshMemberRoll
リソースを作成する必要があります。
1.9.2. Red Hat OpenShift Service Mesh メンバーロールの作成
ServiceMeshMemberRoll
は、Service Mesh コントロールプレーンに属するプロジェクトを一覧表示します。ServiceMeshMemberRoll
に一覧表示されているプロジェクトのみがコントロールプレーンの影響を受けます。プロジェクトは、特定のコントロールプレーンのデプロイメント用にメンバーロールに追加するまで Service Mesh に属しません。
istio-system
など、ServiceMeshControlPlane
と同じプロジェクトに、 default
という名前の ServiceMeshMemberRoll
リソースを作成する必要があります。
1.9.2.1. Web コンソールからのメンバーロールの作成
Web コンソールを使用して 1 つ以上のプロジェクトを Service Mesh メンバーロールに追加します。この例では、istio-system
が Service Mesh コントロールプレーンプロジェクトの名前となります。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされ、検証されていること。
- Service Mesh に追加する既存プロジェクトの一覧。
手順
- OpenShift Container Platform Web コンソールにログインします。
メッシュのサービスがない場合や、ゼロから作業を開始する場合は、アプリケーションのプロジェクトを作成します。これは、Service Mesh コントロールプレーンをインストールしたプロジェクトとは異なる必要があります。
- Home → Projects に移動します。
- Name フィールドに名前を入力します。
- Create をクリックします。
- Operators → Installed Operators に移動します。
-
Project メニューをクリックし、リストから
ServiceMeshControlPlane
リソースがデプロイされているプロジェクト (例:istio-system
) を選択します。 - Red Hat OpenShift Service Mesh Operator をクリックします。
- Istio Service Mesh Member Roll タブをクリックします。
- Create ServiceMeshMemberRoll をクリックします。
-
Members をクリックし、Value フィールドにプロジェクトの名前を入力します。任意の数のプロジェクトを追加できますが、プロジェクトは 単一 の
ServiceMeshMemberRoll
リソースしか属することができません。 - Create をクリックします。
1.9.2.2. CLI からのメンバーロールの作成
コマンドラインからプロジェクトを ServiceMeshMemberRoll
に追加します。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされ、検証されていること。
- Service Mesh に追加するプロジェクトの一覧。
-
OpenShift CLI (
oc
) へのアクセスがある。
手順
OpenShift Container Platform CLI にログインします。
$ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
メッシュのサービスがない場合や、ゼロから作業を開始する場合は、アプリケーションのプロジェクトを作成します。これは、Service Mesh コントロールプレーンをインストールしたプロジェクトとは異なる必要があります。
$ oc new-project <your-project>
プロジェクトをメンバーとして追加するには、以下の YAML の例を変更します。任意の数のプロジェクトを追加できますが、プロジェクトは 単一 の
ServiceMeshMemberRoll
リソースしか属することができません。この例では、istio-system
が Service Mesh コントロールプレーンプロジェクトの名前となります。servicemeshmemberroll-default.yaml の例
apiVersion: maistra.io/v1 kind: ServiceMeshMemberRoll metadata: name: default namespace: istio-system spec: members: # a list of projects joined into the service mesh - your-project-name - another-project-name
以下のコマンドを実行して、
istio-system
namespace にServiceMeshMemberRoll
リソースをアップロードおよび作成します。$ oc create -n istio-system -f servicemeshmemberroll-default.yaml
以下のコマンドを実行して、
ServiceMeshMemberRoll
が正常に作成されていることを確認します。$ oc get smmr -n istio-system default
STATUS
列がConfigured
の場合、インストールは正常に終了しています。
1.9.3. ServiceMeshMemberRoll リソースを使用したプロジェクトの追加について
ServiceMeshMemberRoll
リソースを使用するのが、プロジェクトを Service Mesh に追加する最も簡単な方法です。プロジェクトを追加するには、ServiceMeshMemberRoll
リソースの spec.members
フィールドにプロジェクト名を指定します。ServiceMeshMemberRoll
リソースは、ServiceMeshControlPlane
リソースによって制御されるプロジェクトを指定します。
この方法を使用してプロジェクトを追加するには、追加するプロジェクトの servicemeshmemberrolls
権限と update pods
権限をユーザーが持っている必要があります。
Service Mesh に追加するアプリケーション、ワークロード、またはサービスがすでにある場合は、次を参照してください。
-
Web コンソールで
ServiceMeshMemberRoll
リソースを使用してメッシュにプロジェクトを追加または削除する -
CLI で
ServiceMeshMemberRoll
リソースを使用してメッシュにプロジェクトを追加または削除する
-
Web コンソールで
-
あるいは、Bookinfo というサンプルアプリケーションをインストールして
ServiceMeshMemberRoll
リソースに追加するには、Bookinfo サンプルアプリケーションのチュートリアルを参照してください。
1.9.3.1. Web コンソールで ServiceMeshMemberRoll リソースを使用してメッシュにプロジェクトを追加または削除する
OpenShift Container Platform Web コンソールで ServiceMeshMemberRoll
リソースを使用して、メッシュにプロジェクトを追加または削除できます。プロジェクトはいくつでも追加できますが、プロジェクトは 1 つの メッシュにのみ属することができます。
ServiceMeshMemberRoll
リソースは、対応する ServiceMeshControlPlane
リソースが削除されると削除されます。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされ、検証されていること。
-
既存の
ServiceMeshMemberRoll
リソース。 -
ServiceMeshMemberRoll
リソースを持つプロジェクトの名前。 - メッシュに追加する、またはメッシュから削除するプロジェクトの名前。
手順
- OpenShift Container Platform Web コンソールにログインします。
- Operators → Installed Operators に移動します。
-
Project メニューをクリックし、リストから
ServiceMeshControlPlane
リソースがデプロイされているプロジェクトを選択します。たとえば、istio-system
です。 - Red Hat OpenShift Service Mesh Operator をクリックします。
- Istio Service Mesh Member Roll タブをクリックします。
-
default
リンクをクリックします。 - YAML タブをクリックします。
YAML を変更してプロジェクトをメンバーとして追加します (またはプロジェクトを削除して既存メンバーを削除します)。任意の数のプロジェクトを追加できますが、プロジェクトは 単一 の
ServiceMeshMemberRoll
リソースしか属することができません。servicemeshmemberroll-default.yaml の例
apiVersion: maistra.io/v1 kind: ServiceMeshMemberRoll metadata: name: default namespace: istio-system #control plane project spec: members: # a list of projects joined into the service mesh - your-project-name - another-project-name
- Save をクリックします。
- Reload をクリックします。
1.9.3.2. CLI で ServiceMeshMemberRoll リソースを使用してメッシュにプロジェクトを追加または削除する
CLI で ServiceMeshMemberRoll
リソースを使用して、1 つ以上のプロジェクトをメッシュに追加できます。プロジェクトはいくつでも追加できますが、プロジェクトは 1 つの メッシュにのみ属することができます。
ServiceMeshMemberRoll
リソースは、対応する ServiceMeshControlPlane
リソースが削除されると削除されます。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされ、検証されていること。
-
既存の
ServiceMeshMemberRoll
リソース。 -
ServiceMeshMemberRoll
リソースを持つプロジェクトの名前。 - メッシュに追加する、またはメッシュから削除するプロジェクトの名前。
-
OpenShift CLI (
oc
) へのアクセスがある。
手順
- OpenShift Container Platform CLI にログインします。
ServiceMeshMemberRoll
リソースを編集します。$ oc edit smmr -n <controlplane-namespace>
YAML を変更して、プロジェクトをメンバーとして追加または削除します。任意の数のプロジェクトを追加できますが、プロジェクトは 単一 の
ServiceMeshMemberRoll
リソースしか属することができません。servicemeshmemberroll-default.yaml の例
apiVersion: maistra.io/v1 kind: ServiceMeshMemberRoll metadata: name: default namespace: istio-system #control plane project spec: members: # a list of projects joined into the service mesh - your-project-name - another-project-name
- ファイルを保存して、エディターを終了します。
1.9.4. ServiceMeshMember リソースを使用したプロジェクトの追加について
ServiceMeshMember
リソースを使用すると、ServiceMeshMemberRoll
リソースを変更せずにプロジェクトを Service Mesh に追加できます。プロジェクトを追加するには、Service Mesh に追加するプロジェクトに ServiceMeshMember
リソースを作成します。Service Mesh Operator が ServiceMeshMember
オブジェクトを処理すると、ServiceMeshMemberRoll
リソースの status.members
リストにプロジェクトが表示されます。次に、プロジェクトに存在するサービスがメッシュで利用可能になります。
メッシュ管理者は、各メッシュユーザーに ServiceMeshMember
リソースの ServiceMeshControlPlane
リソースを参照する権限を付与する必要があります。この権限を設定すると、メッシュユーザーが Service Mesh プロジェクトまたは ServiceMeshMemberRoll
リソースへの直接アクセス権を持っていない場合でも、メッシュユーザーはプロジェクトをメッシュに追加できます。詳細は、Red Hat OpenShift Service Mesh メンバーの作成を参照してください。
1.9.4.1. Web コンソールで ServiceMeshMember リソースを使用してメッシュにプロジェクトを追加
OpenShift Container Platform Web コンソールで ServiceMeshMember
リソースを使用して、1 つ以上のプロジェクトをメッシュに追加できます。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされています。
-
ServiceMeshControlPlane
リソースの名前と、リソースが属するプロジェクトの名前はわかっています。 - メッシュに追加するプロジェクトの名前はわかっています。
-
Service Mesh 管理者は、Service Mesh へのアクセスを明示的に付与する必要があります。管理者は、
RoleBinding
またはClusterRoleBinding
を使用してmesh-user
ロール
をユーザーに割り当てて、メッシュにアクセスする権限を付与できます。詳細は、Red Hat OpenShift Service Mesh メンバーの作成 を参照してください。
手順
- OpenShift Container Platform Web コンソールにログインします。
- Operators → Installed Operators に移動します。
-
Project メニューをクリックし、ドロップダウンリストからメッシュに追加するプロジェクトを選択します。たとえば、
istio-system
です。 - Red Hat OpenShift Service Mesh Operator をクリックします。
- Istio Service Mesh Member タブをクリックします。
- Create ServiceMeshMember をクリックします。
-
ServiceMeshMember
のデフォルト名を許可します。 - クリックして ControlPlaneRef を展開します。
-
Namespace フィールドで、
ServiceMeshControlPlane
リソースが属するプロジェクトを選択します。たとえば、istio-system
です。 -
Name フィールドに、この namespace が属する
ServiceMeshControlPlane
リソースの名前を入力します。たとえば、basic
です。 - Create をクリックします。
-
ServiceMeshMember
リソースが作成され、プロジェクトがメッシュに追加されたことを確認します。リソース名をクリックします。たとえば、default
です。画面の最後に表示される Conditions セクションを表示します。Reconciled
およびReady
の条件のStatus
がTrue
であることを確認します。Status
がFalse
の場合は、Reason
列およびMessage
列で詳細を確認してください。
1.9.4.2. CLI で ServiceMeshMember リソースを使用してメッシュにプロジェクトを追加する
CLI で ServiceMeshMember
リソースを使用して、1 つ以上のプロジェクトをメッシュに追加できます。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされています。
-
ServiceMeshControlPlane
リソースの名前と、それが属するプロジェクトの名前はわかっています。 - メッシュに追加するプロジェクトの名前はわかっています。
-
Service Mesh 管理者は、Service Mesh へのアクセスを明示的に付与する必要があります。管理者は、
RoleBinding
またはClusterRoleBinding
を使用してmesh-user
ロール
をユーザーに割り当てて、メッシュにアクセスする権限を付与できます。詳細は、Red Hat OpenShift Service Mesh メンバーの作成 を参照してください。
手順
- OpenShift Container Platform CLI にログインします。
ServiceMeshMember
マニフェストの YAML ファイルを作成します。マニフェストは、istio-system
namespace にデプロイされたServiceMeshControlPlane
リソースが作成した Service Mesh にmy-application
プロジェクトを追加します。apiVersion: maistra.io/v1 kind: ServiceMeshMember metadata: name: default namespace: my-application spec: controlPlaneRef: namespace: istio-system name: basic
YAML ファイルを適用して
ServiceMeshMember
リソースを作成します。$ oc apply -f <file-name>
ServiceMeshMember
リソースを作成したら、namespace がメッシュの一部であることを確認します。以下のコマンドを実行する際に、READY
列にTrue
の値が表示されていることを確認します。$ oc get smm default -n my-application
ServiceMeshMemberRoll
リソースにアクセスできる場合は、my-application
namespace がServiceMeshMemberRoll
リソースのstatus.members
およびstatus.configuredMembers
フィールドに表示されることを確認します。
1.9.5. ラベルセレクターを使用したプロジェクトの追加について
クラスター全体のデプロイメントの場合は、ラベルセレクターを使用してプロジェクトをメッシュに追加できます。ServiceMeshMemberRoll
リソースで指定されたラベルセレクターを使用すると、サービスメッシュオペレーターは、namespace ラベルに基づいてメッシュに namespace を追加またはメッシュから namespace を削除できます。単一のラベルセレクターを指定するために使用できる他の標準 OpenShift Container Platform リソースとは異なり、ServiceMeshMemberRoll
リソースを使用して複数のラベルセレクターを指定できます。
namespace のラベルが ServiceMeshMemberRoll
リソースで指定されたセレクターのいずれかに一致する場合、その namespace はメッシュに含まれます。
基本的に、OpenShift Container Platform でのプロジェクトとは、プロジェクトで使用できるユーザー ID 範囲などの追加のアノテーションを持つ Kubernetes namespace です。通常、OpenShift Container Platform Web コンソールでは プロジェクト という用語が使用され、CLI では namespace という用語が使用されますが、この 2 つの用語は基本的に同義です。
1.9.5.1. Web コンソールでラベルセレクターを使用してメッシュにプロジェクトを追加する
ラベルセレクターを使用して、OpenShift Container Platform Web コンソールでサービスメッシュにプロジェクトを追加できます。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされています。
-
デプロイメントには既存の
ServiceMeshMemberRoll
リソースがあります。 -
cluster-admin
ロールを持つユーザーとしてログインしています。Red Hat OpenShift Dedicated を使用する場合は、dedicated-admin
ロールを持つユーザーとしてログインします。
手順
- OpenShift Container Platform Web コンソールにログインします。
- Operators → Installed Operators に移動します。
-
Project メニューをクリックし、ドロップダウンリストから
ServiceMeshMemberRoll
リソースがデプロイされているプロジェクトを選択します。たとえば、istio-system です。 - Red Hat OpenShift Service Mesh Operator をクリックします。
- Istio Service Mesh Member Roll タブをクリックします。
- Create ServiceMeshMember Roll をクリックします。
-
ServiceMeshMemberRoll
のデフォルト名を受け入れます。 Labels フィールドにキーと値のペアを入力して、Service Mesh に含める namespace を識別するラベルを定義します。プロジェクト namespace にセレクターで指定されたラベルがある場合、プロジェクト namespace は Service Mesh に含まれます。両方のラベルを含める必要はありません。
たとえば、
mykey=myvalue
と入力すると、このラベルを持つすべての名前空間がメッシュの一部として含まれます。セレクターが一致を識別すると、プロジェクト namespace が Service Mesh に追加されます。myotherkey=myothervalue
と入力すると、このラベルを持つすべての名前空間がメッシュの一部として含まれます。セレクターが一致を識別すると、プロジェクト namespace が Service Mesh に追加されます。- Create をクリックします。
1.9.5.2. CLI でラベルセレクターを使用してメッシュにプロジェクトを追加する
ラベルセレクターを使用して、CLI でプロジェクトを Service Mesh に追加できます。
前提条件
- Red Hat OpenShift Service Mesh Operator がインストールされています。
-
デプロイメントには既存の
ServiceMeshMemberRoll
リソースがあります。 -
cluster-admin
ロールを持つユーザーとしてログインしています。Red Hat OpenShift Dedicated を使用する場合は、dedicated-admin
ロールを持つユーザーとしてログインします。
手順
- OpenShift Container Platform CLI にログインします。
ServiceMeshMemberRoll
リソースを編集します。$ oc edit smmr -n <controlplane_project>
前の例では、例として
<controlplane_project>
を使用しています。Service Mesh コントロールプレーンは、サービスが含まれるプロジェクトから分離されている限り、任意のプロジェクトにデプロイできます。YAML ファイルを変更して、
ServiceMeshMemberRoll
リソースのspec.memberSelectors
フィールドに名前空間ラベルセレクターを含めます。注記matchLabels
フィールドを使用する代わりに、セレクターでmatchExpressions
フィールドを使用することもできます。apiVersion: maistra.io/v1 kind: ServiceMeshMemberRoll metadata: name: default namespace: istio-system spec: memberSelectors: 1 - matchLabels: 2 mykey: myvalue 3 - matchLabels: 4 myotherkey: myothervalue 5
- 1
- Service Mesh に含まれるプロジェクト namespace を識別するために使用されるラベルセレクターが含まれます。プロジェクト namespace にセレクターで指定されたラベルがある場合、プロジェクト namespace は Service Mesh に含まれます。プロジェクト namespace には両方のラベルを含める必要はありません。
- 2 3
mykey=myvalue
ラベルを持つすべての namespace を指定します。セレクターが一致を識別すると、プロジェクト namespace が Service Mesh に追加されます。- 4 5
myotherkey=myothervalue
ラベルを持つすべての namespace を指定します。セレクターが一致を識別すると、プロジェクト namespace が Service Mesh に追加されます。
1.9.6. Bookinfo のサンプルアプリケーション
Bookinfo のサンプルアプリケーションでは、OpenShift Container Platform での Red Hat OpenShift Service Mesh 2.4.5 のインストールをテストすることができます。
Bookinfo アプリケーションは、オンラインブックストアの単一カタログエントリーのように、書籍に関する情報を表示します。このアプリケーションでは、書籍の説明、書籍の詳細 (ISBN、ページ数その他の情報)、および書評のページが表示されます。
Bookinfo アプリケーションはこれらのマイクロサービスで設定されます。
-
productpage
マイクロサービスは、details
とreviews
マイクロサービスを呼び出して、ページを設定します。 -
details
マイクロサービスには書籍の情報が含まれています。 -
reviews
マイクロサービスには、書評が含まれます。これはratings
マイクロサービスも呼び出します。 -
ratings
マイクロサービスには、書評を伴う書籍のランキング情報が含まれます。
reviews マイクロサービスには、以下の 3 つのバージョンがあります。
-
バージョン v1 は、
ratings
サービスを呼び出しません。 -
バージョン v2 は、
ratings
サービスを呼び出して、各評価を 1 から 5 の黒い星で表示します。 -
バージョン v3 は、
ratings
サービスを呼び出して、各評価を 1 から 5 の赤い星で表示します。
1.9.6.1. Bookinfo アプリケーションのインストール
このチュートリアルでは、プロジェクトの作成、そのプロジェクトへの Bookinfo アプリケーションのデプロイ、Service Mesh での実行中のアプリケーションの表示を行い、サンプルアプリケーションを作成する方法を説明します。
前提条件:
- OpenShift Container Platform 4.1 以降がインストールされている。
- Red Hat OpenShift Service Mesh 2.4.5 がインストールされている。
-
OpenShift CLI (
oc
) へのアクセスがある。 -
cluster-admin
ロールを持つアカウントがある。
Bookinfo サンプルアプリケーションは、IBM Z および IBM Power Systems にインストールできません。
このセクションのコマンドは、Service Mesh コントロールプレーンプロジェクトが istio-system
であると仮定します。コントロールプレーンを別の namespace にインストールしている場合は、実行する前にそれぞれのコマンドを編集します。
手順
-
cluster-admin 権限を持つユーザーとして OpenShift Container Platform Web コンソールにログインします。(Red Hat OpenShift Dedicated を使用する場合)
dedicated-admin
ロールがあるアカウント。 - Home → Projects をクリックします。
- Create Project をクリックします。
Project Name として
info
を入力し、Display Name を入力します。その後、Description を入力し、Create をクリックします。または、CLI からこのコマンドを実行して、
info
プロジェクトを作成できます。$ oc new-project info
- Operators → Installed Operators をクリックします。
-
プロジェクト メニューをクリックし、Service Mesh コントロールプレーンの namespace を使用します。この例では
istio-system
を使用します。 - Red Hat OpenShift Service Mesh Operator をクリックします。
Istio Service Mesh Member Roll タブをクリックします。
- Istio Service Mesh Member Roll がすでに作成されている場合は、名前をクリックしてから YAML タブをクリックし、YAML エディターを開きます。
-
ServiceMeshMemberRoll
を作成していない場合は、Create ServiceMeshMemberRoll をクリックします。
- Members をクリックし、Value フィールドにプロジェクトの名前を入力します。
Create をクリックして、更新した Service Mesh Member Roll を保存します。
または、以下のサンプルを YAML ファイルに保存します。
Bookinfo ServiceMeshMemberRoll の例 (servicemeshmemberroll-default.yaml)
apiVersion: maistra.io/v1 kind: ServiceMeshMemberRoll metadata: name: default spec: members: - info
以下のコマンドを実行して、そのファイルをアップロードし、
istio-system
namespace にServiceMeshMemberRoll
リソースを作成します。この例では、istio-system
が Service Mesh コントロールプレーンプロジェクトの名前となります。$ oc create -n istio-system -f servicemeshmemberroll-default.yaml
以下のコマンドを実行して、
ServiceMeshMemberRoll
が正常に作成されていることを確認します。$ oc get smmr -n istio-system -o wide
STATUS
列がConfigured
の場合、インストールは正常に終了しています。NAME READY STATUS AGE MEMBERS default 1/1 Configured 70s ["info"]
CLI で 'info' プロジェクトに Bookinfo アプリケーションをデプロイするには、
bookinfo.yaml
ファイルを適用します。$ oc apply -n info -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.4/samples/bookinfo/platform/kube/bookinfo.yaml
以下のような出力が表示されるはずです。
service/details created serviceaccount/info-details created deployment.apps/details-v1 created service/ratings created serviceaccount/info-ratings created deployment.apps/ratings-v1 created service/reviews created serviceaccount/info-reviews created deployment.apps/reviews-v1 created deployment.apps/reviews-v2 created deployment.apps/reviews-v3 created service/productpage created serviceaccount/info-productpage created deployment.apps/productpage-v1 created
info-gateway.yaml
ファイルを適用して Ingress ゲートウェイを作成します。$ oc apply -n info -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.4/samples/bookinfo/networking/bookinfo-gateway.yaml
以下のような出力が表示されるはずです。
gateway.networking.istio.io/info-gateway created virtualservice.networking.istio.io/info created
GATEWAY_URL
パラメーターの値を設定します。$ export GATEWAY_URL=$(oc -n istio-system get route istio-ingressgateway -o jsonpath='{.spec.host}')
1.9.6.2. デフォルトの宛先ルールの追加
Bookinfo アプリケーションを使用するには、先にデフォルトの宛先ルールを追加する必要があります。相互トランスポート層セキュリティー (TLS) 認証が有効かどうかによって、2 つの事前設定される YAML ファイルを使用できます。
手順
宛先ルールを追加するには、以下のいずれかのコマンドを実行します。
相互 TLS を有効にしていない場合:
$ oc apply -n info -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.4/samples/bookinfo/networking/destination-rule-all.yaml
相互 TLS を有効にしている場合:
$ oc apply -n info -f https://raw.githubusercontent.com/Maistra/istio/maistra-2.4/samples/bookinfo/networking/destination-rule-all-mtls.yaml
以下のような出力が表示されるはずです。
destinationrule.networking.istio.io/productpage created destinationrule.networking.istio.io/reviews created destinationrule.networking.istio.io/ratings created destinationrule.networking.istio.io/details created
1.9.6.3. Bookinfo インストールの検証
Bookinfo アプリケーションのサンプルが正常にデプロイされたことを確認するには、以下の手順を実行します。
前提条件
- Red Hat OpenShift Service Mesh がインストールされている。
- Bookinfo サンプルアプリケーションのインストール手順を実行します。
CLI からの手順
- OpenShift Container Platform CLI にログインします。
以下のコマンドですべての Pod が準備状態にあることを確認します。
$ oc get pods -n info
すべての Pod のステータスは
Running
である必要があります。以下のような出力が表示されるはずです。NAME READY STATUS RESTARTS AGE details-v1-55b869668-jh7hb 2/2 Running 0 12m productpage-v1-6fc77ff794-nsl8r 2/2 Running 0 12m ratings-v1-7d7d8d8b56-55scn 2/2 Running 0 12m reviews-v1-868597db96-bdxgq 2/2 Running 0 12m reviews-v2-5b64f47978-cvssp 2/2 Running 0 12m reviews-v3-6dfd49b55b-vcwpf 2/2 Running 0 12m
以下のコマンドを実行して、製品ページの URL を取得します。
echo "http://$GATEWAY_URL/productpage"
- Web ブラウザーで出力をコピーして貼り付けて、Bookinfo の製品ページがデプロイされていることを確認します。
Kiali Web コンソールからの手順
Kiali Web コンソールのアドレスを取得します。
-
cluster-admin
権限を持つユーザーとして OpenShift Container Platform Web コンソールにログインします。(Red Hat OpenShift Dedicated を使用する場合)dedicated-admin
ロールがあるアカウント。 - Networking → Routes に移動します。
Routes ページで、Namespace メニューから Service Mesh コントロールプレーンプロジェクトを選択します (例:
istio-system
)。Location 列には、各ルートのリンク先アドレスが表示されます。
- Kiali の 場所 列のリンクをクリックします。
- Log In With OpenShift をクリックします。Kiali の 概要 画面には、各プロジェクトの namespace のタイルが表示されます。
-
- Kiali で、グラフ をクリックします。
- Namespace リストから info を選択し、Graph Type リストから App graph を選択します。
Display メニューから Display idle nodes をクリックします。
これにより、定義されているが要求を受信または送信していないノードが表示されます。アプリケーションが適切に定義されていることを確認できますが、要求トラフィックは報告されていません。
- 期間 メニューを使用して、期間を延ばして、古いトラフィックを取得できるようにします。
- Refresh Rate メニューを使用して、トラフィックを頻繁に更新するか、まったく更新しないようにします。
- Services、Workloads または Istio Config をクリックして、info コンポーネントのリストビューを表示し、それらが正常であることを確認します。
1.9.6.4. Bookinfo アプリケーションの削除
以下の手順で、Bookinfo アプリケーションを削除します。
前提条件
- OpenShift Container Platform 4.1 以降がインストールされている。
- Red Hat OpenShift Service Mesh 2.4.5 がインストールされている。
-
OpenShift CLI (
oc
) へのアクセスがある。
1.9.6.4.1. Bookinfo プロジェクトの削除
手順
- OpenShift Container Platform Web コンソールにログインします。
- Home → Projects をクリックします。
-
info
メニュー をクリックしてから Delete Project をクリックします。 確認ダイアログボックスに
info
と入力してから Delete をクリックします。または、CLI を使用して次のコマンドを実行し、
info
プロジェクトを作成できます。$ oc delete project info
1.9.6.4.2. Service Mesh Member Roll からの Bookinfo プロジェクトの削除
手順
- OpenShift Container Platform Web コンソールにログインします。
- Operators → Installed Operators をクリックします。
-
Project メニューをクリックし、一覧から
istio-system
を選択します。 - Red Hat OpenShift Service Mesh Operator の Provided APIS で、Istio Service Mesh Member Roll のリンクをクリックします。
-
ServiceMeshMemberRoll
メニュー をクリックし、Edit Service Mesh Member Roll を選択します。 デフォルトの Service Mesh Member Roll YAML を編集し、members 一覧から
info
を削除します。または、CLI を使用して次のコマンドを実行し、
ServiceMeshMemberRoll
からinfo
プロジェクトを削除できます。この例では、istio-system
が Service Mesh コントロールプレーンプロジェクトの名前となります。$ oc -n istio-system patch --type='json' smmr default -p '[{"op": "remove", "path": "/spec/members", "value":["'"info"'"]}]'
- Save をクリックして、Service Mesh Member Roll を更新します。
1.9.7. 次のステップ
- インストールプロセスを続行するには、サイドカーインジェクションを有効化 する必要があります。
1.10. サイドカーコンテナーの挿入の有効化
サービスが含まれる namespace をメッシュに追加したら、次の手順は、アプリケーションのデプロイメントリソースでサイドカーの自動挿入を有効にします。デプロイメントごとにサイドカーコンテナーの自動挿入を有効にする必要があります。
Bookinfo サンプルアプリケーションをインストールした場合は、アプリケーションがデプロイされ、インストール手順の一部としてサイドカーが注入されています。独自のプロジェクトおよびサービスを使用している場合は、アプリケーションを OpenShift Container Platform にデプロイします。
詳細は、OpenShift Container Platform のドキュメント Understanding Deployment and DeploymentConfig objects を参照してください。
Init Containers (Pod 内のアプリケーションコンテナーの前に実行される特殊なコンテナー) によって開始されたトラフィックは、デフォルトでサービスメッシュの外に移動できません。Init Container が実行する、メッシュ外のネットワークトラフィック接続の確立を必要とするアクションはすべて失敗します。
Init Container をサービスに接続する方法について、詳細は Red Hat ナレッジベースソリューション initContainer in CrashLoopBackOff on pod with Service Mesh sidecar injected を参照してください。
1.10.1. 前提条件
- メッシュにデプロイされたサービス(Bookinfo サンプルアプリケーションなど)。
- デプロイメントリソースファイル。
1.10.2. サイドカーコンテナーの自動挿入の有効化
アプリケーションをデプロイする場合は、deployment
オブジェクトで spec.template.metadata.annotations
のアノテーション sidecar.istio.io/inject
を true
に設定して、インジェクションをオプトインする必要があります。オプトインにより、サイドカーの挿入が OpenShift Container Platform エコシステム内の複数のフレームワークが使用する、ビルダー Pod などの他の OpenShift Container Platform 機能に干渉しないようにします。
前提条件
- Service Mesh の一部である namespace と、サイドカーの自動注入が必要なデプロイメントを特定しておく。
手順
デプロイメントを見つけるには、
oc get
コマンドを使用します。$ oc get deployment -n <namespace>
たとえば、
info
namespace の ratings-v1 マイクロサービスのデプロイメントファイルを表示するには、次のコマンドを使用して YAML 形式でリソースを表示します。oc get deployment -n info ratings-v1 -o yaml
- エディターでアプリケーションのデプロイメント設定の YAML ファイルを開きます。
次の例に示すように、
spec.template.metadata.annotations.sidecar.istio/inject
を Deployment YAML に追加し、sidecar.istio.io/inject
をtrue
に設定します。info deployment-rateds-v1.yaml からのスニペットの例
apiVersion: apps/v1 kind: Deployment metadata: name: ratings-v1 namespace: info labels: app: ratings version: v1 spec: template: metadata: annotations: sidecar.istio.io/inject: 'true'
- デプロイメント設定ファイルを保存します。
ファイルをアプリケーションが含まれるプロジェクトに追加し直します。
$ oc apply -n <namespace> -f deployment.yaml
この例では、
info
はratings-v1
アプリを含むプロジェクトの名前であり、deployment-ratings-v1.yaml
は編集したファイルです。$ oc apply -n info -f deployment-ratings-v1.yaml
リソースが正常にアップロードされたことを確認するには、以下のコマンドを実行します。
$ oc get deployment -n <namespace> <deploymentName> -o yaml
以下に例を示します。
$ oc get deployment -n info ratings-v1 -o yaml
1.10.3. サイドカーインジェクションの検証
Kiali コンソールは、アプリケーション、サービス、ワークロードにサイドカープロキシーがあるかどうかを検証するためのいくつかの方法を提供します。
図1.3 サイドカーバッジがない
グラフ ページには、次のグラフに サイドカー がないことを示すノードバッジが表示されます。
- App graph
- Versioned app graph
- Workload graph
図1.4 サイドカーアイコンがない
アプリケーション ページでは、サイドカーがない namespace 内のアプリケーションの 詳細 列に Missing Sidecar アイコンが表示されます。
ワークロード ページでは、サイドカーがない namespace 内のアプリケーションの 詳細 列に Missing Sidecar アイコンが表示されます。
サービス ページでは、サイドカーがない namespace 内のアプリケーションの 詳細 列に Missing Sidecar アイコンが表示されます。サービスのバージョンが複数ある場合は、サービスの詳細 ページを使用して、Missing Sidecar アイコンを表示します。
ワークロードの詳細 ページには、アプリケーションログとプロキシーログを表示および相互に関連付けることができる特別な統合 Logs タブがあります。Envoy ログは、アプリケーションワークロードのサイドカーインジェクションを検証する別の方法として表示できます。
ワークロードの詳細 ページには、Envoy プロキシーであるか、Envoy プロキシーが注入されたワークロード用の Envoy タブもあります。このタブには、クラスター、リスナー、ルート、ブートストラップ、設定、および メトリック のサブタブなど、組み込みの Envoy ダッシュボードが表示されます。
Envoy アクセスログを有効にする方法については、トラブルシューティング のセクションを参照してください。
Envoy ログの表示については、Kiali コンソールでのログの表示 を参照してください。
1.10.4. アノテーションによるプロキシー環境変数の設定
Envoy サイドカープロキシーの設定は、ServiceMeshControlPlane
によって管理されます。
デプロイメントの Pod アノテーションを injection-template.yaml
ファイルに追加することにより、アプリケーションのサイドカープロキシーで環境変数を設定できます。環境変数がサイドカーコンテナーに挿入されます。
injection-template.yaml の例
apiVersion: apps/v1 kind: Deployment metadata: name: resource spec: replicas: 7 selector: matchLabels: app: resource template: metadata: annotations: sidecar.maistra.io/proxyEnv: "{ \"maistra_test_env\": \"env_value\", \"maistra_test_env_2\": \"env_value_2\" }"
独自のカスタムリソースを作成するときは、maistra.io/
ラベルとアノテーションを含めないでください。これらのラベルとアノテーションは、リソースが Operator によって生成および管理されていることを示しています。独自のリソースの作成時に Operator が生成したリソースからコンテンツをコピーする場合は、maistra.io/
で始まるラベルやアノテーションを含めないでください。これらのラベルまたはアノテーションを含むリソースは、次回の調整時に Operator によって上書きまたは削除されます。
1.10.5. サイドカープロキシーの更新
サイドカープロキシーの設定を更新するには、アプリケーション管理者はアプリケーション Pod を再起動する必要があります。
デプロイメントで自動のサイドカーコンテナー挿入を使用する場合は、アノテーションを追加または変更してデプロイメントの Pod テンプレートを更新できます。以下のコマンドを実行して Pod を再デプロイします。
$ oc patch deployment/<deployment> -p '{"spec":{"template":{"metadata":{"annotations":{"kubectl.kubernetes.io/restartedAt": "'`date -Iseconds`'"}}}}}'
デプロイメントで自動のサイドカーコンテナー挿入を使用しない場合は、デプロイメントまたは Pod で指定されたサイドカーコンテナーイメージを変更して Pod を再起動し、サイドカーコンテナーを手動で更新する必要があります。
1.10.6. 次のステップ
ご使用の環境用に Red Hat OpenShift Service Mesh 機能を設定します。
1.11. Service Mesh のアップグレード
Red Hat OpenShift Service Mesh の最新機能にアクセスするには、最新バージョンの 2.4.5 にアップグレードしてください。
1.11.1. バージョニングについて
Red Hat は、製品リリースにセマンティックバージョニングを使用します。セマンティックバージョニングは、X.Y.Z 形式の 3 つのコンポーネント番号になります。
- X はメジャーバージョンを表します。メジャーリリースは通常、アーキテクチャーの変更、API の変更、スキーマの変更、および同様のメジャー更新など、何らかの最新の変更を意味します。
- Y はマイナーバージョンを表します。マイナーリリースには、下位互換性を維持しながら、新しい機能が含まれています。
- Z はパッチバージョン (z-stream リリースとも呼ばれます) を表します。パッチリリースは、Common Vulnerabilities and Exposures (CVE) に対処し、バグ修正をリリースするために使用されます。通常、新機能はパッチリリースの一部としてリリースされません。
1.11.1.1. バージョニングが Service Mesh のアップグレードに与える影響
実行する更新のバージョンによって、アップグレードプロセスが異なります。
- パッチの更新: パッチのアップグレードは、Operator Lifecycle Manager (OLM) によって管理されます。Operator を更新すると自動的に発生します。
-
マイナーアップグレード: マイナーアップグレードでは、最新の Red Hat OpenShift Service Mesh Operator バージョンに更新することと、
ServiceMeshControlPlane
リソースのspec.version
値を手動で変更することの両方が必要です。 -
メジャーアップグレード: メジャーアップグレードでは、最新の Red Hat OpenShift Service Mesh Operator バージョンに更新することと、
ServiceMeshControlPlane
リソースのspec.version
値を手動で変更することの両方が必要です。メジャーアップグレードには後方互換性のない変更が含まれている可能性があるため、手動による追加の変更が必要になる場合があります。
1.11.1.2. Service Mesh のバージョンについて
ご使用のシステムにデプロイした Red Hat OpenShift Service Mesh のバージョンを理解するには、各コンポーネントのバージョンがどのように管理されるかを理解する必要があります。
Operator バージョン: 最新の Operator バージョンは 2.4.5 です。Operator バージョン番号は、現在インストールされている Operator のバージョンのみを示します。Red Hat OpenShift Service Mesh Operator は Service Mesh コントロールプレーンの複数のバージョンをサポートするため、Operator のバージョンはデプロイされた
ServiceMeshControlPlane
リソースのバージョンを決定しません。重要最新の Operator バージョンにアップグレードすると、パッチの更新が自動的に適用されますが、Service Mesh コントロールプレーンは最新のマイナーバージョンに自動的にアップグレードされません。
ServiceMeshControlPlane バージョン:
ServiceMeshControlPlane
バージョンは、使用している Red Hat OpenShift Service Mesh のバージョンを決定します。ServiceMeshControlPlane
リソースのspec.version
フィールドの値は、Red Hat OpenShift Service Mesh のインストールとデプロイに使用されるアーキテクチャーと設定を制御します。Service Mesh コントロールプレーンを作成する場合は、以下の 2 つの方法のいずれかでバージョンを設定できます。- Form View で設定するには、Control Plane Version メニューからバージョンを選択します。
-
YAML View で設定するには、YAML ファイルに
spec.version
の値を設定します。
Operator Lifecycle Manager (OLM) は Service Mesh コントロールプレーンのアップグレードをを管理しないため、SMCP を手動でアップグレードしない限り、Operator および ServiceMeshControlPlane
(SMCP) のバージョン番号が一致しない可能性があります。
1.11.2. アップグレードに関する考慮事項
maistra.io/
ラベルまたはアノテーションは、ユーザーが作成したカスタムリソースで使用することはできません。これは、Red Hat OpenShift Service Mesh Operator によってリソースが生成され、管理される必要があることを示すためです。
アップグレード時に、Operator はファイルの削除や置換などの変更を、リソースが Operator によって管理されることを示す以下のラベルまたはアノテーションを含むリソースに対して行います。
アップグレードする前に、ユーザーが作成したカスタムリソースで以下のラベルまたはアノテーションが含まれるか確認します。
-
maistra-istio-operator
(Red Hat OpenShift Service Mesh) に設定されたmaistra.io/
およびapp.kubernetes.io/managed-by
ラベル -
kiali.io/
(Kiali) -
jaegertracing.io/
(Red Hat OpenShift 分散トレースプラットフォーム (Jaeger)) -
logging.openshift.io/
(Red Hat Elasticsearch)
アップグレードの前に、ユーザーが作成したカスタムリソースで、それらが Operator によって管理されることを示すラベルまたはアノテーションを確認します。Operator によって管理されないカスタムリソースからラベルまたはアノテーションを削除します。
バージョン 2.0 にアップグレードする場合、Operator は SMCP と同じ namespace で、これらのラベルを持つリソースのみを削除します。
バージョン 2.1 にアップグレードする場合、Operator はすべての namespace で、これらのラベルを持つリソースを削除します。
1.11.2.1. アップグレードに影響する可能性のある既知の問題
アップグレードに影響する可能性がある既知の問題には、次のものがあります。
- Operator をアップグレードする際に、Jaeger または Kiali のカスタム設定が元に戻される可能性があります。Operator をアップグレードする前に、Service Mesh の実稼働環境用デプロイメント内にある Jaeger オブジェクトまたは Kiali オブジェクトのカスタム設定をメモし、再作成できるようにしてください。
-
Red Hat OpenShift Service Mesh は、明示的に文書化されている場合を除き、
EnvoyFilter
設定の使用はサポートしていません。これは、下層の Envoy API と疎結合されており、後方互換性を保持できないためです。Envoy フィルターを使用していて、ServiceMeshControlPlane
のアップグレードによって導入された新しいバージョンの Envoy が原因で Istio によって生成された設定が変更された場合、実装したEnvoyFilter
が壊れる可能性があります。 -
OSSM-1505
ServiceMeshExtension
は、OpenShift Container Platform バージョン 4.11 では機能しません。ServiceMeshExtension
は Red Hat OpenShift Service Mesh 2.2 で非推奨となったため、この既知の問題は修正されず、エクステンションをWasmPluging
に移行する必要があります。 -
OSSM-1396 ゲートウェイリソースに
spec.externalIPs
設定が含まれている場合、ゲートウェイは、ServiceMeshControlPlane
の更新時に再作成されずに削除され、再作成されることはありません。
OSSM-1052 Service Mesh コントロールプレーンで入力ゲートウェイのサービス
ExternalIP
を設定すると、サービスは作成されません。SMCP のスキーマには、サービスのパラメーターがありません。回避策: SMCP 仕様でゲートウェイの作成を無効にして、(サービス、ロール、および RoleBinding など) ゲートウェイのデプロイメントを完全に手動で管理します。
1.11.3. Operator のアップグレード
Service Mesh に最新のセキュリティー修正、バグ修正、およびソフトウェア更新プログラムを適用し続けるには、Operator を最新の状態に保つ必要があります。パッチの更新は、Operator をアップグレードすることで開始されます。
Operator のバージョンは、お使いの Service Mesh のバージョンを 判別しません。デプロイされた Service Mesh コントロールプレーンのバージョンによって、Service Mesh のバージョンが決まります。
Red Hat OpenShift Service Mesh Operator は Service Mesh コントロールプレーンの複数のバージョンをサポートするため、Red Hat OpenShift Service Mesh Operator を更新しても、デプロイされた ServiceMeshControlPlane
の spec.version
値は 更新されません。また、spec.version
値は 2 桁の数字 (2.2 など) であり、パッチの更新 (2.2.1 など) は SMCP バージョン値に反映されないことにも注意してください。
Operator Lifecycle Manager (OLM) は、クラスター内の Operator のインストール、アップグレード、ロールベースのアクセス制御 (RBAC) を制御します。OLM はデフォルトで OpenShift Container Platform で実行されます。OLM は利用可能な Operator のクエリーやインストールされた Operator のアップグレードを実行します。
Operator をアップグレードするためにアクションを実行する必要があるかどうかは、インストール時に選択した設定によって異なります。各 Operator をインストールしたときに、Update Channel および Approval Strategy を選択しました。これら 2 つの設定の組み合わせによって、Operator が更新されるタイミングと方法が決まります。
バージョン付けされたチャネル | stable または Preview チャネル | |
---|---|---|
自動 | そのバージョンのみのマイナーリリースおよびパッチリリースの Operator を自動的に更新します。次のメジャーバージョン (バージョン 2.0 から 3.0) には、自動的に自動的に更新されません。次のメジャーバージョンに更新するために必要な Operator サブスクリプションを手動で変更します。 | すべてのメジャー、マイナーおよびパッチリリースについて、Operator を自動的に更新します。 |
手動 | 指定したバージョンのマイナーおよびパッチリリースに必要な手動更新。次のメジャーバージョンに更新するために必要な Operator サブスクリプションを手動で変更します。 | すべてのメジャー、マイナー、およびパッチリリースについて、手動更新が必要になります。 |
Red Hat OpenShift Service Mesh Operator を更新すると、Operator Lifecycle Manager (OLM) は古い Operator Pod を削除し、新しい Pod を開始します。新しい Operator Pod が開始されると、調整プロセスは ServiceMeshControlPlane
(SMCP) をチェックし、いずれかの Service Mesh コントロールプレーンコンポーネントの利用可能な更新されたコンテナーイメージがある場合は、それらの Service Mesh コントロールプレーン Pod を新しいコンテナーイメージを使用するものに置き換えます。
Kiali および Red Hat OpenShift 分散トレースプラットフォーム (Jaeger) Operator をアップグレードすると、OLM 調整プロセスがクラスターをスキャンし、管理対象インスタンスを新しい Operator のバージョンにアップグレードします。たとえば、Red Hat OpenShift 分散トレースプラットフォーム (Jaeger) Operator をバージョン 1.30.2 からバージョン 1.34.1 に更新する場合、Operator は分散トレースプラットフォームの実行中のインスタンスをスキャンし、それらも 1.34.1 にアップグレードします。
Red Hat OpenShift Service Mesh の特定のパッチバージョンにとどまるには、自動更新を無効にして、Operator のその特定のバージョンにとどまる必要があります。
Operator のアップグレードに関する詳細は、Operator Lifecycle Manager のドキュメントを参照してください。
1.11.4. コントロールプレーンのアップグレード
マイナーおよびメジャーリリースのコントロールプレーンを手動で更新する必要があります。コミュニティーの Istio プロジェクトはカナリアアップグレードを推奨していますが、Red Hat OpenShift Service Mesh はインプレースアップグレードのみをサポートしています。Red Hat OpenShift Service Mesh では、各マイナーリリースから次のマイナーリリースに順番にアップグレードする必要があります。たとえば、バージョン 2.0 からバージョン 2.1 にアップグレードしてから、バージョン 2.2 にアップグレードする必要があります。Red Hat OpenShift Service Mesh 2.0 から 2.2 に直接更新することはできません。
Service Mesh コントロールプレーンをアップグレードすると、Operator が管理するすべてのリソース (ゲートウェイなど) もアップグレードされます。
複数のバージョンのコントロールプレーンを同じクラスターにデプロイできますが、Red Hat OpenShift Service Mesh は、Service Mesh のカナリアアップグレードをサポートしていません。つまり、spec.version
の値が異なるさまざまな SCMP リソースを使用できますが、同じメッシュを管理することはできません。
エクステンションの移行に関する詳細は、Migrating from ServiceMeshExtension to WasmPlugin resources を参照してください。
1.11.4.1. バージョン 2.3 から 2.4 へのアップグレードに伴う変更
Service Mesh コントロールプレーンをバージョン 2.3 から 2.4 にアップグレードすると、次の動作変更が導入されます。
- Istio OpenShift Routing (IOR) のサポートは非推奨になりました。IOR 機能は引き続き有効ですが、将来のリリースでは削除される予定です。
次の暗号スイートはサポートされなくなり、クライアント側とサーバー側の TLS ネゴシエーションで使用される暗号のリストから削除されました。
- ECDHE-ECDSA-AES128-SHA
- ECDHE-RSA-AES128-SHA
- AES128-GCM-SHA256
- AES128-SHA
- ECDHE-ECDSA-AES256-SHA
- ECDHE-RSA-AES256-SHA
- AES256-GCM-SHA384
AES256-SHA
これらの暗号スイートのいずれかを使用するサービスにアクセスする必要があるアプリケーションは、プロキシーが TLS 接続を開始すると接続に失敗します。
1.11.4.2. バージョン 2.2 から 2.3 へのアップグレードに伴う変更
Service Mesh コントロールプレーンをバージョン 2.2 から 2.3 にアップグレードすると、次の動作変更が導入されます。
-
このリリースでは、
WasmPlugin
API を使用する必要があります。2.2 で非推奨化されたServiceMeshExtension
API のサポートが廃止されました。ServiceMeshExtension
API の使用中にアップグレードを試みると、アップグレードは失敗します。
1.11.4.3. バージョン 2.1 から 2.2 へのアップグレードに伴う変更
Service Mesh コントロールプレーンをバージョン 2.1 から 2.2 にアップグレードすると、次の動作変更が導入されます。
-
istio-node
DaemonSet は、アップストリームの Istio の名前と一致するようにistio-cni-node
に名前が変更されました。 -
Istio 1.10 は、デフォルトで
lo
ではなくeth0
を使用してトラフィックをアプリケーションコンテナーに送信するように Envoy を更新しました。 -
このリリースでは、
WasmPlugin
API のサポートが追加され、ServiceMeshExtension
が非推奨になりました。
1.11.4.4. バージョン 2.0 から 2.1 へのアップグレードに伴う変更
Service Mesh コントロールプレーンをバージョン 2.0 から 2.1 にアップグレードすると、以下のアーキテクチャーおよび動作上の変更が導入されます。
アーキテクチャーの変更
Mixer は Red Hat OpenShift Service Mesh 2.1 で完全に削除されました。Red Hat OpenShift Service Mesh 2.0.x リリースから 2.1 へのアップグレードは、Mixer が有効な場合にブロックされます。
v2.0 から v2.1 にアップグレード時に以下のメッセージが表示される場合は、.spec.version
フィールドを更新する前に、既存のコントロールプレーン仕様にすでに存在する Mixer
タイプを Istiod
タイプに更新します。
An error occurred admission webhook smcp.validation.maistra.io denied the request: [support for policy.type "Mixer" and policy.Mixer options have been removed in v2.1, please use another alternative, support for telemetry.type "Mixer" and telemetry.Mixer options have been removed in v2.1, please use another alternative]”
以下に例を示します。
apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane spec: policy: type: Istiod telemetry: type: Istiod version: v2.4
動作上の変更
AuthorizationPolicy
の更新-
PROXY プロトコルでは、
ipBlocks
およびnotIpBlocks
を使用してリモート IP アドレスを指定する場合は、代わりにremoteIpBlocks
およびnotRemoteIpBlocks
を使用するように設定を更新します。 - ネストされた JSON Web Token(JWT) 要求のサポートが追加されました。
-
PROXY プロトコルでは、
EnvoyFilter
の重大な変更-
typed_config
を使用する必要があります。 - Xds v2 はサポート対象外になりました。
- フィルター名が非推奨になりました。
-
- 以前のバージョンのプロキシーは、新しいプロキシーから 1xx または 204 ステータスコードを受信すると、503 ステータスコードを報告する場合があります。
1.11.4.5. Service Mesh コントロールプレーンのアップグレード
Red Hat OpenShift Service Mesh をアップグレードするには、Red Hat OpenShift Service Mesh ServiceMeshControlPlane
v2 リソースのバージョンフィールドを更新する必要があります。次に、設定と適用が完了したら、アプリケーション Pod を再起動して各サイドカープロキシーとその設定を更新します。
前提条件
- OpenShift Container Platform 4.9 以降を実行している。
- 最新の Red Hat OpenShift Service Mesh Operator がある。
手順
ServiceMeshControlPlane
リソースが含まれるプロジェクトに切り替えます。この例では、istio-system
が Service Mesh コントロールプレーンプロジェクトの名前となります。$ oc project istio-system
v2
ServiceMeshControlPlane
リソース設定をチェックし、これが有効であることを確認します。以下のコマンドを実行して、
ServiceMeshControlPlane
リソースを v2 リソースとして表示します。$ oc get smcp -o yaml
ヒントService Mesh コントロールプレーン設定をバックアップします。
.spec.version
フィールドを更新し、設定を適用します。以下に例を示します。
apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane metadata: name: basic spec: version: v2.4
または、コマンドラインの代わりに Web コンソールを使用して Service Mesh コントロールプレーンを編集することもできます。OpenShift Container Platform Web コンソールで、Project をクリックし、入力したプロジェクト名を選択します。
- Operators → Installed Operators をクリックします。
-
ServiceMeshControlPlane
インスタンスを見つけます。 - YAML view を選択し、直前の例のように YAML ファイルのテキストを更新します。
- Save をクリックします。
1.11.4.6. Red Hat OpenShift Service Mesh のバージョン 1.1 からバージョン 2.0 への移行
バージョン 1.1 から 2.0 にアップグレードするには、ワークロードおよびアプリケーションを新規バージョンを実行する Red Hat OpenShift Service Mesh の新規インスタンスに移行する手動の手順が必要です。
前提条件
- OpenShift Container Platform 4.7 にアップグレードしてから Red Hat OpenShift Service Mesh 2.0 にアップグレードする必要があります。
- Red Hat OpenShift Service Mesh のバージョン 2.0 Operator が必要です。自動 アップグレードパスを選択した場合、Operator は最新情報を自動的にダウンロードします。ただし、Red Hat OpenShift Service Mesh バージョン 2.0 で機能を使用するために実行する必要のある手順があります。
1.11.4.6.1. Red Hat OpenShift Service Mesh のアップグレード
Red Hat OpenShift Service Mesh をアップグレードするには、新規の namespace に Red Hat OpenShift Service Mesh ServiceMeshControlPlane
2.0 リソースのインスタンスを作成する必要があります。次に、設定後にマイクロサービスアプリケーションおよびワークロードを古いメッシュから新規の Service Mesh に移動します。
手順
v1
ServiceMeshControlPlane
リソース設定をチェックし、これが有効であることを確認します。以下のコマンドを実行して、
ServiceMeshControlPlane
リソースを v2 リソースとして表示します。$ oc get smcp -o yaml
-
無効なフィールドの情報は、出力の
spec.techPreview.errored.message
フィールドを確認してください。 - v1 リソースに無効なフィールドがある場合は、リソースは調整されず、v2 リソースとして編集することはできません。v2 フィールドへの更新はすべて、元の v1 設定で上書きされます。無効なフィールドを修正するには、リソースの v1 バージョンを置き換えるか、パッチを適用するか、編集できます。リソースを修正せずに削除することもできます。リソースの修正後に調整でき、リソースの v2 バージョンを変更または表示できます。
ファイルを編集してリソースを修正するには、
oc get
を使用してリソースを取得し、テキストファイルをローカルで編集し、リソースを編集したファイルに置き換えます。$ oc get smcp.v1.maistra.io <smcp_name> > smcp-resource.yaml #Edit the smcp-resource.yaml file. $ oc replace -f smcp-resource.yaml
パッチを使用してリソースを修正するには、
oc patch
を使用します。$ oc patch smcp.v1.maistra.io <smcp_name> --type json --patch '[{"op": "replace","path":"/spec/path/to/bad/setting","value":"corrected-value"}]'
コマンドラインツールで編集してリソースを修正するには、
oc edit
を使用します。$ oc edit smcp.v1.maistra.io <smcp_name>
Service Mesh コントロールプレーン設定をバックアップします。
ServiceMeshControlPlane
リソースが含まれるプロジェクトに切り替えます。この例では、istio-system
が Service Mesh コントロールプレーンプロジェクトの名前となります。$ oc project istio-system
以下のコマンドを実行して、現在の設定を取得します。<smcp_name> は
ServiceMeshControlPlane
リソースのメタデータに指定されます (例:basic-install
またはfull-install
)。$ oc get servicemeshcontrolplanes.v1.maistra.io <smcp_name> -o yaml > <smcp_name>.v1.yaml
ServiceMeshControlPlane
を、開始点としての設定に関する情報が含まれる v2 のコントロールプレーンバージョンに変換します。$ oc get smcp <smcp_name> -o yaml > <smcp_name>.v2.yaml
プロジェクトを作成します。OpenShift Container Platform コンソールの Project メニューで、
New Project
をクリックし、プロジェクトの名前 (例:istio-system-upgrade
) を入力します。または、CLI からこのコマンドを実行できます。$ oc new-project istio-system-upgrade
-
v2
ServiceMeshControlPlane
のmetadata.namespace
フィールドを新規のプロジェクト名で更新します。この例では、istio-system-upgrade
を使用します。 -
version
フィールドを 1.1 から 2.0 に更新するか、v2ServiceMeshControlPlane
でこれを削除します。 新規 namespace に
ServiceMeshControlPlane
を作成します。コマンドラインで以下のコマンドを実行し、取得したServiceMeshControlPlane
の v2 バージョンでコントロールプレーンをデプロイします。この例では、`<smcp_name.v2> ` をファイルへのパスに置き換えます。$ oc create -n istio-system-upgrade -f <smcp_name>.v2.yaml
または、コンソールを使用して Service Mesh コントロールプレーンを作成することもできます。OpenShift Container Platform Web コンソールで、 Project をクリックします。次に、入力したプロジェクト名を選択します。
- Operators → Installed Operators をクリックします。
- Create ServiceMeshControlPlane をクリックします。
-
YAML view を選択し、取得した YAML ファイルのテキストをフィールドに貼り付けます。
apiVersion
フィールドがmaistra.io/v2
に設定されていることを確認し、metadata.namespace
フィールドを新規 namespace (例:istio-system-upgrade
) を使用するように変更します。 - Create をクリックします。
1.11.4.6.2. 2.0 ServiceMeshControlPlane の設定
ServiceMeshControlPlane
リソースは Red Hat OpenShift Service Mesh バージョン 2.0 用に変更されました。ServiceMeshControlPlane
リソースの v2 バージョンを作成したら、新機能を利用し、デプロイメントを適合させるようにこれを変更します。ServiceMeshControlPlane
リソースを変更するため、Red Hat OpenShift Service Mesh 2.0 の仕様および動作に以下の変更を加えることを検討してください。使用する機能の更新情報は、Red Hat OpenShift Service Mesh 2.0 の製品ドキュメントを参照してください。v2 リソースは、Red Hat OpenShift Service Mesh 2.0 インストールに使用する必要があります。
1.11.4.6.2.1. アーキテクチャーの変更
以前のバージョンで使用されるアーキテクチャーのユニットは Istiod によって置き換えられました。2.0 では、Service Mesh コントロールプレーンのコンポーネント Mixer、Pilot、Citadel、Galley、およびサイドカーインジェクター機能が単一のコンポーネントである Istiod に統合されました。
Mixer はコントロールプレーンコンポーネントとしてサポートされなくなりましたが、Mixer ポリシーおよび Telemetry プラグインは Istiod の WASM 拡張でサポートされるようになりました。レガシー Mixer プラグインを統合する必要がある場合は、ポリシーと Telemetry に対して Mixer を有効にできます。
シークレット検出サービス (SDS) は、