Service Mesh のインストール
OpenShift Container Platform 3.11 Service Mesh インストールガイド
概要
第1章 Red Hat OpenShift Service Mesh のインストール
1.1. 製品概要
1.1.1. Red Hat OpenShift Service Mesh の概要
Red Hat OpenShift Service Mesh の本リリースはテクノロジープレビューリリースでのみ利用可能です。テクノロジープレビューリリースは、Red Hat 製品のサービスレベルアグリーメント (SLA) ではサポートされておらず、機能的に完全でない可能性があり、Red Hat では実稼働環境での使用を推奨しません。クラスターで Red Hat OpenShift Service Mesh を使用すると、OpenShift 全体がテクノロジープレビューとしてレンダリングされます (サポートされていない状態)。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。詳細は、「テクノロジプレビュー機能のサポート範囲」を参照してください。
サービスメッシュは、分散したマイクロサービスアーキテクチャーの複数のアプリケーションを構成するマイクロサービスのネットワークであり、マイクロサービス間の対話を可能にします。サービスメッシュのサイズとおよび複雑性が増大すると、これを把握し、管理することがより困難になる可能性があります。
オープンソースの Istio プロジェクトをベースとする Red Hat OpenShift Service Mesh は、サービスコードに変更を加えずに、既存の分散したアプリケーションに透過的な層を追加します。Red Hat OpenShift Service Mesh サポートは、特別なサイドカープロキシーをマイクロサービス間のネットワーク通信をすべてインターセプトするメッシュ内の関連サービスにデプロイすることで、サービスに追加できます。コントロールプレーンの機能を使用してサービスメッシュを設定し、管理します。
Red Hat OpenShift Service Mesh により、以下を提供するデプロイされたサービスのネットワークを簡単に作成できます。
- 検出
- 負荷分散
- サービス間の認証
- 障害回復
- メトリクス
- モニタリング
サービスメッシュは、以下を含むより複雑な運用機能も提供します。
- A/B テスト
- カナリアリリース
- レート制限
- アクセス制御
- エンドツーエンド認証
1.1.2. Red Hat OpenShift Service Mesh アーキテクチャー
Red Hat OpenShift Service Mesh は、データプレーンとコントロールプレーンに論理的に分割されます。
データプレーン は、サイドカーコンテナーとしてデプロイされたインテリジェントプロキシーのセットです。これらのプロキシーは、サービスメッシュ内のマイクロサービス間の受信および送信ネットワーク通信をすべてインターセプトし、制御します。サイドカープロキシーは、Mixer、汎用ポリシーおよび Telemetry ハブとも通信します。
- Envoy プロキシーは、サービスメッシュ内の全サービスの受信トラフィックおよび送信トラフィックをすべてインターセプトします。Envoy は、同じ Pod の関連するサービスに対してサイドカーコンテナーとしてデプロイされます。
コントロールプレーンは、プロキシーがトラフィックをルーティングするように管理および設定し、Mixer がポリシーを適用し、Telemetry を収集するように設定します。
- Mixer は、アクセス制御と使用ポリシー (承認、レート制限、クォータ、認証、および要求トレースなど) を適用し、Envoy プロキシーやその他のサービスから Telemetry データを収集します。
- Pilot はランタイム時にプロキシーを設定します。Pilot は、Envoy サイドカーコンテナーのサービス検出、インテリジェントルーティング (例: A/B テストまたはカナリアデプロイメント) のトラフィック管理機能、および回復性 (タイムアウト、再試行、サーキットブレーカー) を提供します。
- Citadel は証明書を発行し、ローテーションします。Citadel は、組み込み型のアイデンティティーおよび認証情報の管理機能を使用して、強力なサービス間認証およびエンドユーザー認証を提供します。Citadel を使用して、サービスメッシュで暗号化されていないトラフィックをアップグレードできます。Operator は、Citadel を使用して、ネットワーク制御ではなく、サービスアイデンティティーに基づいてポリシーを適用することができます。
- Galley は、サービスメッシュ設定を取り込み、その後設定を検証し、処理し、配布します。Galley は、他のサービスメッシュコンポーネントが OpenShift Container Platform からユーザー設定の詳細を取得できないようにします。
Red Hat OpenShift Service Mesh は、istio-operator を使用してコントロールプレーンのインストールも管理します。Operator は、OpenShift クラスターで共通アクティビティーを実装し、自動化できるソフトウェアの構成要素です。これはコントローラーとして動作し、クラスター内の必要なオブジェクトの状態を設定したり、変更したりできます。
1.1.3. サポートされる設定
以下は、Red Hat OpenShift Service Mesh 0.12.TechPreview で唯一サポートされている設定です。
- Red Hat OpenShift Container Platform バージョン 3.11。
- Red Hat OpenShift Container Platform バージョン 4.1。
OpenShift Online および OpenShift Dedicated は Red Hat OpenShift Service Mesh 0.12.TechPreview に対してはサポートされていません。
- デプロイメントは、フェデレーションされていない単一の OpenShift Container Platform クラスターに含まれる必要があります。
- Red Hat OpenShift Service Mesh の本リリースは、OpenShift Container Platform x86_64 でのみ利用できます。
- Red Hat OpenShift Service Mesh は、外部プロバイダーを持たないフラットネットワークとして構成された OpenShift Container Platform Software Defined Networking (SDN) にのみ適しています。
- 本リリースでは、すべてのサービスメッシュコンポーネントが動作する OpenShift クラスターに含まれている設定のみをサポートしています。クラスター外にあるマイクロサービスの管理や、マルチクラスターシナリオにおけるマイクロサービスの管理はサポートしていません。
- Kiali の可観測性コンソールは Chrome、Edge、Firefox、または Safari ブラウザーの 2 つの最新リリースでのみサポートされています。
このテクノロジープレビュー機能のサポートについての詳細は、Red Hat ナレッジベースの記事を参照してください。
1.1.4. Red Hat OpenShift Service Mesh とアップストリーム Istio コミュニティーインストールの比較について確認する
Red Hat OpenShift Service Mesh のインストールは、複数の点でアップストリームの Istio コミュニティーインストールとは異なります。Red Hat OpenShift Service Mesh の変更点は、問題の解決、追加機能の提供、OpenShift へのデプロイ時の差異の処理を実行するために必要になることがあります。
Red Hat OpenShift Service Mesh の現行リリースは、以下の点で現在のアップストリーム Istio コミュニティーのリリースとは異なります。
1.1.4.1. マルチテナントインストール
マルチテナントコントロールプレーンのインストールは、OpenShift Container Platform の再起動およびアップグレードで問題を生じさせることで知られています。マルチテナントコントロールプレーンのインストールは、Red Hat OpenShift Service Mesh 0.12.TechPreview 以降のデフォルト設定です。
Red Hat OpenShift Service Mesh では、マルチテナントコントロールプレーンのインストールを設定し、サービスメッシュにアクセスできる namespace を指定し、サービスメッシュを他のコントロールプレーンインスタンスから分離することができます。
1.1.4.2. 自動的な挿入
アップストリームの Istio コミュニティーインストールは、ラベル付けした namespace にサイドカーコンテナーを自動的に挿入します。
Red Hat OpenShift Service Mesh はサイドカーコンテナーを namespace に自動的に挿入しませんが、自動的なサイドカーコンテナーの挿入についてのセクションで説明されているように、sidecar .istio.io/inject
アノテーションを指定する必要があります。
1.1.4.3. ロールベースアクセス制御機能
ロールベースアクセス制御機能 (RBAC) は、サービスへのアクセスを制御するために使用できるメカニズムを提供します。ユーザー名やプロパティーのセットを指定してサブジェクトを特定し、それに応じてアクセス制御を適用することができます。
アップストリームの Istio コミュニティーインストールには、ヘッダーの完全一致の実行、ヘッダーのワイルドカードの一致の実行、または特定のプレフィックスまたはサフィックスを含むヘッダーの有無をチェックするオプションが含まれます。
アップストリーム Istio コミュニティーの要求ヘッダーのマッチング例
apiVersion: "rbac.istio.io/v1alpha1" kind: ServiceRoleBinding metadata: name: httpbin-client-binding namespace: httpbin spec: subjects: - user: "cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account" properties: request.headers[<header>]: "value"
Red Hat OpenShift Service Mesh は、正規表現を使用して要求ヘッダーと一致させる機能を拡張します。request.regex.headers
のプロパティーキーを正規表現で指定します。
Red Hat OpenShift Service Mesh の正規表現による要求ヘッダーのマッチング
apiVersion: "rbac.istio.io/v1alpha1" kind: ServiceRoleBinding metadata: name: httpbin-client-binding namespace: httpbin spec: subjects: - user: "cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account" properties: request.regex.headers[<header>]: "<regular expression>"
1.1.4.4. 自動ルート作成
現在、自動ルート作成はマルチテナントのサービスメッシュインストールと互換性がありません。マルチテナントインストールを試行する場合には、これが ServiceMeshControlPlane
で無効にされていることを確認します。
Red Hat OpenShift Service Mesh は Istio ゲートウェイの OpenShift ルートを自動的に管理します。Istio ゲートウェイがサービスメッシュで作成され、更新され、削除される場合に、一致する OpenShift ルートが作成され、更新され、削除されます。
以下のゲートウェイが作成される場合は、次のコマンドを実行します。
apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: gateway1 spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - www.bookinfo.com - bookinfo.example.com
以下の OpenShift ルートが自動的に作成されます。
$ oc -n istio-system get routes NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD gateway1-lvlfn bookinfo.example.com istio-ingressgateway <all> None gateway1-scqhv www.bookinfo.com istio-ingressgateway <all> None
このゲートウェイが削除されると、Red Hat OpenShift Service Mesh はルートを削除します。
手動で作成されたルートはサービスメッシュによって管理されません。
1.1.4.4.1. catch-all ドメイン
Red Hat OpenShift Service Mesh は catch-all またはワイルドカードドメインをサポートしません。サービスメッシュがゲートウェイ定義で catch-all ドメインを見つけると、Red Hat OpenShift Service Mesh はルートを作成しますが、デフォルトのホスト名を作成するには OpenShift に依存する必要があります。サービスメッシュが作成するルートは catch-all ルートではなく、 <route-name>[-<namespace>].<suffix>
構造のあるホスト名を持ちます。
1.1.4.4.2. サブドメイン
サブドメインはサポートされていますが、OpenShift ではデフォルトで有効にされていません。Red Hat OpenShift Service Mesh はサブドメインを持つルートを作成しますが、これは OpenShift でサブドメインを有効にした後にのみ動作します。詳細は、ワイルドカードルートに関する OpenShift ドキュメントを参照してください。
1.1.4.4.3. TLS
OpenShift ルートは TLS をサポートするように設定されます。
Red Hat OpenShift Service Mesh によって作成されるすべての OpenShift ルートは istio-system
namespace に置かれます。
1.1.4.5. OpenSSL
Red Hat OpenShift Service Mesh では、BoringSSL を OpenSSL に置き換えます。OpenSSL は、Secure Sockets Layer (SSL) プロトコルおよび Transport Layer Security (TLS) プロトコルのオープンソース実装を含むソフトウェアライブラリーです。Red Hat OpenShift Service Mesh Proxy バイナリーは、基礎となる UBI8 オペレーティングシステムから OpenSSL ライブラリー (libssl および libcrypto) を動的にリンクします。
1.1.4.6. Container Network Interface (CNI)
Red Hat OpenShift Service Mesh には CNI が含まれ、アプリケーション Pod ネットワーキングを設定する代替の方法が提供されます。CNI を有効にする際に、init-container ネットワーク設定を置き換えます。これにより、SCC (Security Context Constraints) を変更して、サービスアカウントおよび namespace に追加の特権を付与する必要がなくなります。
1.1.5. Red Hat OpenShift Service Mesh のインストールの概要
Red Hat OpenShift Service Mesh のインストールプロセスでは、以下の 4 つの異なるプロジェクト (namespace) を作成します。
- istio-operator プロジェクト (1 Pod)
- istio-system プロジェクト (17 Pod)
- kiali-operator プロジェクト (1 Pod)
- observability プロジェクト (1 Pod)
最初に Kubernetes Operator を作成します。この Operator は、サービスメッシュコンポーネントのデプロイメント、更新、および削除を管理するカスタムリソースを定義し、監視します。
カスタムリソースファイルの定義方法によっては、サービスメッシュのインストール時に以下のコンポーネントのいずれかをインストールできます。
- Red Hat OpenShift Service Mesh: オープンソースの Istio プロジェクトをベースとし、アプリケーションを構成するマイクロサービスを接続し、保護し、制御し、観察することができます。
- Jaeger: オープンソース Jaeger プロジェクトをベースとし、トレースを実行して、複雑な分散システムでトランザクションを監視し、トラブルシューティングできます。
- Kiali: オープンソースの Kiali プロジェクトをベースとしており、サービスメッシュの可観測性を提供します。Kiali を使用すると、単一のコンソールで設定を表示し、トラフィックを監視し、トレースの表示と分析を実行できます。
1.2. 前提条件
1.2.1. Red Hat OpenShift Service Mesh のインストールの前提条件
Red Hat OpenShift Service Mesh をインストールする前に、以下の前提条件を満たす必要があります。
- お使いの Red Hat アカウントに有効な OpenShift Container Platform サブスクリプションを用意します。サブスクリプションをお持ちでない場合は、営業担当者にお問い合わせください。
OpenShift Container Platform バージョン 3.11 以降をインストールします。
- システムおよび環境要件についての詳細は、OpenShift Container Platform ドキュメントを参照してください。
OpenShift Container Platform バージョンに一致する OpenShift Container Platform コマンドラインユーティリティーのバージョン (
oc
クライアントツール) をインストールし、これをパスに追加します。- インストール手順については、OpenShift Container Platform のコマンドラインリファレンスについてのドキュメントを参照してください。
1.2.1.1. OpenShift Container Platform インストールの準備
サービスメッシュを OpenShift Container Platform インストールにインストールする前に、マスター設定およびそれぞれのスケジュール可能なノードを変更する必要があります。これらの変更は、サービスメッシュで必要とされる機能を有効にし、Elasticsearch 機能が正常に機能することを確認します。
1.2.1.2. ノード設定の更新
OpenShift Container Platform 4.1 を実行している場合には、ノード設定の更新は必要ありません。
Elasticsearch アプリケーションを実行するには、各ノードのカーネル設定に変更を加える必要があります。この変更は sysctl
サービスによって処理されます。
OpenShift Container Platform インストール内の各ノードでこれらの変更を行います。
/etc/sysctl.d/99-elasticsearch.conf
という名前のファイルを以下の内容で作成します。vm.max_map_count = 262144
以下のコマンドを実行します。
$ sysctl vm.max_map_count=262144
1.2.1.3. コンテナーレジストリーの更新
OpenShift Container Platform 3.11 をオンプレミスで実行している場合は、以下の手順に従って registry.redhat.io へのアクセスを設定します。
プライベート registry.redhat.io に OpenShift Container Platform 3.11 からアクセスし、インストールプロセス用の Red Hat OpenShift Service Mesh イメージをプルします。
以下のコマンドを実行します。
$ docker login registry.redhat.io
- これにより、ユーザー名とパスワードを求めるプロンプトが出されます。
正常にログインすると、
~/.docker/config.json
は以下の内容で作成されます。{ "auths": { "registry.redhat.io": { "auth": "XXXXXXXXXXXXXXXXXX" } } }
-
各ノードで
/var/lib/origin/.docker
ディレクトリーを作成します。 -
各ノードで
/.docker/config.json
ファイルを/var/lib/origin/.docker
ディレクトリーにコピーします。
1.3. Service Mesh のインストール
1.3.1. Red Hat OpenShift Service Mesh のインストール
Service Mesh のインストールには、Operator のインストール、その後にコントロールプレーンをデプロイするためのカスタムリソース定義ファイルの作成および管理が必要になります。
Red Hat OpenShift Service Mesh 0.9.TechPreview 以降、Mixer のポリシーの適用はデフォルトで無効にされています。ポリシータスクを実行するには、これを有効にする必要があります。Mixer ポリシーの適用を有効にする方法については、Mixer ポリシーの適用の更新について参照してください。
マルチテナントコントロールプレーンのインストールは、OpenShift Container Platform の再起動およびアップグレードで問題を生じさせることで知られています。マルチテナントコントロールプレーンのインストールは、Red Hat OpenShift Service Mesh 0.12.TechPreview 以降のデフォルト設定です。
1.3.1.1. Operator のインストール
サービスメッシュのインストールプロセスでは、Operator が導入され、これにより istio-operator
namespace 内でコントロールプレーンのインストールが管理されます。この Operator は、コントロールプレーンのデプロイメント、更新、および削除に関連するカスタムリソースを定義し、監視します。
Red Hat OpenShift Service Mesh 0.12.TechPreview 以降では、Red Hat OpenShift Service Mesh Operator がコントロールプレーンをインストールするには、Jaeger Operator および Kiali Operator をインストールをする必要があります。
1.3.1.1.1. Jaeger Operator のインストール
コントロールプレーンをインストールするには、Red Hat OpenShift Service Mesh Operator の Jaeger Operator をインストールする必要があります。
- クラスター管理者として OpenShift Container Platform にログインします。
以下のコマンドを実行して Jaeger Operator をインストールします。
$ oc new-project observability # create the project for the jaeger operator $ oc create -n observability -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/v1.13.1/deploy/crds/jaegertracing_v1_jaeger_crd.yaml $ oc create -n observability -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/v1.13.1/deploy/service_account.yaml $ oc create -n observability -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/v1.13.1/deploy/role.yaml $ oc create -n observability -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/v1.13.1/deploy/role_binding.yaml $ oc create -n observability -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/v1.13.1/deploy/operator.yaml
1.3.1.1.2. Kiali Operator のインストール
コントロールプレーンをインストールするには、Red Hat OpenShift Service Mesh Operator の Kiali Operator をインストールする必要があります。
- クラスター管理者として OpenShift Container Platform にログインします。
以下のコマンドを実行して、Kiali Operator をインストールします。
$ bash <(curl -L https://git.io/getLatestKialiOperator) --operator-image-version v1.0.0 --operator-watch-namespace '**' --accessible-namespaces '**' --operator-install-kiali false
1.3.1.1.3. Red Hat OpenShift Service Mesh Operator のインストール
Red Hat OpenShift Service Mesh Operator をインストールする前に、Jaeger Operator および Kiali Operator をインストールする必要があります。
- クラスター管理者として OpenShift Container Platform にログインします。
istio-operator
およびistio-system
namespace が存在しない場合、これらのコマンドを実行して namespace を作成します。$ oc new-project istio-operator $ oc new-project istio-system
以下のコマンドを実行して、Red Hat OpenShift Service Mesh Operator をインストールします。クラスターにアクセスできる場合は、任意のホストからこれを実行できます。
$ oc apply -n istio-operator -f https://raw.githubusercontent.com/Maistra/istio-operator/maistra-0.12/deploy/servicemesh-operator.yaml
1.3.1.2. Operator インストールの検証
- クラスター管理者として OpenShift Container Platform にログインします。
以下のコマンドを実行して、Operator が正常にインストールされていることを確認します。
$ oc get pods -n istio-operator
Operator が実行状態になると、これが正常にインストールされていることになります。
NAME READY STATUS RESTARTS AGE istio-operator-5cd6bcf645-fvb57 1/1 Running 0 1h
1.3.1.3. カスタムリソースファイルの作成
istio-system
プロジェクトは、Service Mesh ドキュメント全体でサンプルとして使用されますが、必要に応じて他の namespace を使用できます。
Service Mesh コントロールプレーンをデプロイするには、カスタムリソースをデプロイする必要があります。独自の API を Kubernetes プロジェクトまたはクラスターに導入する必要のあるカスタムリソース。プロジェクトパラメーターを定義し、オブジェクトを作成するカスタムのリソース yaml ファイルを作成します。この例のカスタムリソース yaml ファイルには、サポートされるすべてのパラメーターが含まれ、これにより Red Hat Enterprise Linux (RHEL) をベースとした Red Hat OpenShift Service Mesh 0.12.TechPreview イメージがデプロイされます。
3scale の Istio Adapter は、カスタムリソースファイルでデプロイされ、設定されます。また、稼働している 3scale アカウント (SaaS または On-Premises) が必要になります。
istio-installation.yaml の詳細例
apiVersion: maistra.io/v1 kind: ServiceMeshControlPlane metadata: name: basic-install spec: threeScale: enabled: false istio: global: proxy: resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 128Mi multitenant: true gateways: istio-egressgateway: autoscaleEnabled: false istio-ingressgateway: autoscaleEnabled: false ior_enabled: false mixer: policy: autoscaleEnabled: false telemetry: autoscaleEnabled: false resources: requests: cpu: 100m memory: 1G limits: cpu: 500m memory: 4G pilot: autoscaleEnabled: false traceSampling: 100.0 kiali: dashboard: user: admin passphrase: admin tracing: enabled: true
1.3.1.4. カスタムリソースパラメーター
以下の例は、Red Hat OpenShift Service Mesh でサポートされるカスタムリソースパラメーターの使用を示し、表はサポートされているパラメーターに関する追加情報を示しています。
CPU、メモリー、Pod の数などのカスタムリソースパラメーターを使用して Red Hat OpenShift Service Mesh に設定するリソースは、OpenShift クラスターの設定をベースとしています。現在のクラスター設定で利用可能なリソースに基づいて、これらのパラメーターを設定します。
1.3.1.4.1. Istio グローバルの例
3scale Istio Adapter が機能するようするには、disablePolicyChecks
は false
である必要があります。
istio: global: hub: `maistra/` or `registry.redhat.io/openshift-istio-tech-preview/` tag: 0.12.0 proxy: resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 128Mi mtls: enabled: false disablePolicyChecks: true policyCheckFailOpen: false imagePullSecrets: - MyPullSecret
Pod 内のコンテナーの CPU およびメモリーリソースを指定する方法についての詳細は、OpenShift ドキュメントのコンピュートリソースについて参照してください。
表1.1 グローバルパラメーター
パラメーター | 説明 | 値 | デフォルト値 |
---|---|---|---|
| このブール値は、ポリシーチェックを有効にするかどうかを示します。 |
|
|
| このブール値は、Mixer ポリシーサービスに到達できない場合にトラフィックを Envoy サイドカーコンテナーに通過させることができるかどうかを指定します。 |
|
|
| Operator が Istio イメージをプルするために使用するタグ。 | 有効なコンテナーイメージタグです。 |
|
| Operator が Istio イメージをプルするために使用するハブ。 | 有効なイメージリポジトリーです。 |
|
| これは、デフォルトでサービス間での Mutual Transport Layer Security (mTLS) を有効にするかどうかを制御します。 |
|
|
| Istio イメージを提供するレジストリーへのアクセスがセキュアな場合、ここに imagePullSecret を一覧表示します。 | redhat-registry-pullsecret または quay-pullsecret | なし |
表1.2 プロキシーパラメーター
タイプ | パラメーター | 説明 | 値 | デフォルト値 |
---|---|---|---|---|
リソース |
| Envoy プロキシーに要求される CPU リソースのパーセンテージ。 | ご使用の環境設定に基づく、ミリコア単位の CPU リソース。 |
|
| Envoy プロキシー用に要求されるメモリー量。 | ご使用の環境設定に基づく、利用可能なメモリー (バイト単位)。 |
| |
制限 |
| Envoy プロキシー用に要求される CPU リソースの最大パーセンテージ。 | ご使用の環境設定に基づく、ミリコア単位の CPU リソース。 |
|
| 使用が許可されているメモリー Envoy プロキシーの最大量。 | ご使用の環境設定に基づく、利用可能なメモリー (バイト単位)。 |
|
1.3.1.4.2. Container Network Interface (CNI) の例
Container Network Interface (CNI) を有効にすると、手動のサイドカー挿入が機能しますが、Pod が ServiceMeshMemberRoll
リソースの一部でない限り、Pod はコントロールプレーンと通信できません。
apiVersion: maistra.io/v1 kind: ServiceMeshControlPlane metadata: name: basic-install spec: istio: istio_cni: enabled: true
表1.3 CNI パラメーター
タイプ | パラメーター | 説明 | 値 | デフォルト値 |
---|
1.3.1.4.3. Istio ゲートウェイの例
自動ルート作成は現在、マルチテナンシーでは機能しません。マルチテナントインストールの場合、ior_enabled
を false
に設定します。
gateways: istio-egressgateway: autoscaleEnabled: false autoscaleMin: 1 autoscaleMax: 5 istio-ingressgateway: autoscaleEnabled: false autoscaleMin: 1 autoscaleMax: 5 ior_enabled: false
表1.4 Istio ゲートウェイパラメーター
タイプ | パラメーター | 説明 | 値 | デフォルト値 |
---|---|---|---|---|
|
| このパラメーターは、自動スケーリングを有効にします。 |
|
|
| autoscaleEnabled 設定に基づいて egress ゲートウェイにデプロイする Pod の最小数。 | ご使用の環境設定に基づく、有効な割り当て可能な Pod 数。 |
| |
| autoscaleEnabled 設定に基づいて egress ゲートウェイにデプロイする Pod の最大数。 | ご使用の環境設定に基づく、有効な割り当て可能な Pod 数。 |
| |
|
| このパラメーターは、自動スケーリングを有効にします。 |
|
|
| autoscaleEnabled 設定に基づいて ingress ゲートウェイにデプロイする Pod の最小数。 | ご使用の環境設定に基づく、有効な割り当て可能な Pod 数。 |
| |
| autoscaleEnabled 設定に基づいて ingress ゲートウェイにデプロイする Pod の最大数。 | ご使用の環境設定に基づく、有効な割り当て可能な Pod 数。 |
| |
| このパラメーターは、Istio ルートが OpenShift に自動的に設定されるかどうかを制御します。 |
|
|
1.3.1.4.4. Istio Mixer の例
mixer: enabled: true policy: autoscaleEnabled: false telemetry: autoscaleEnabled: false resources: requests: cpu: 100m memory: 1G limits: cpu: 500m memory: 4G
表1.5 Istio Mixer ポリシーパラメーター
パラメーター | 説明 | 値 | デフォルト値 |
---|---|---|---|
| これにより Mixer が有効にされます。 |
|
|
| これは、自動スケーリングを有効にするかどうかを制御します。小規模な環境では、このパラメーターを無効にします。 |
|
|
| autoscaleEnabled 設定に基づいてデプロイする Pod の最小数。 | ご使用の環境設定に基づく、有効な割り当て可能な Pod 数。 |
|
| autoscaleEnabled 設定に基づいてデプロイする Pod の最大数。 | ご使用の環境設定に基づく、有効な割り当て可能な Pod 数。 |
|
表1.6 Istio Mixer Telemetry パラメーター
タイプ | パラメーター | 説明 | 値 | デフォルト値 |
---|---|---|---|---|
リソース |
| Mixer Telemetry に要求される CPU リソースのパーセンテージ。 | ご使用の環境設定に基づく、ミリコア単位の CPU リソース。 |
|
| Mixer Telemetry に要求されるメモリー量。 | ご使用の環境設定に基づく、利用可能なメモリー (バイト単位)。 |
| |
制限 |
| Mixer Telemetry の使用が許可された CPU リソースの最大パーセンテージ。 | ご使用の環境設定に基づく、ミリコア単位の CPU リソース。 |
|
| Mixer Telemetry の使用が許可されたメモリーの最大量。 | ご使用の環境設定に基づく、利用可能なメモリー (バイト単位)。 |
|
1.3.1.4.5. Istio Pilot の例
pilot: resources: requests: cpu: 100m autoscaleEnabled: false traceSampling: 100.0
表1.7 Istio Pilot パラメーター
パラメーター | 説明 | 値 | デフォルト値 |
---|---|---|---|
| Pilot に要求される CPU リソースのパーセンテージ。 | ご使用の環境設定に基づく、ミリコア単位の CPU リソース。 |
|
| Pilot に要求されるメモリー量。 | ご使用の環境設定に基づく、利用可能なメモリー (バイト単位)。 |
|
| この値は、無作為のサンプリングの発生頻度を制御します。注: 開発またはテストの場合はこの値を増やします。 | 有効な数字 |
|
1.3.1.4.6. トレーシングおよび Jaeger の例
tracing: enabled: false jaeger: tag: 1.13.1 template: all-in-one agentStrategy: DaemonSet
表1.8 トレーシングおよび Jaeger パラメーター
パラメーター | 説明 | 値 | デフォルト値 |
---|---|---|---|
| これにより、環境でのトレーシングが可能となります。 |
|
|
| Operator が Jaeger イメージをプルするために使用するハブ。 | 有効なイメージリポジトリーです。 |
|
| Operator が Jaeger イメージをプルするために使用するタグ。 | 有効なコンテナーイメージタグです。 |
|
| Jaeger に使用するデプロイメントテンプレート | テンプレートタイプの名前 |
|
| Jaeger エージェントを各コンピュートノードにデプロイします。 |
| なし |
1.3.1.4.7. Kiali の例
Kiali は Oath 認証およびダッシュボードのユーザーをサポートします。デフォルトで、Kiali は OpenShift Oauth を使用しますが、ダッシュボードのユーザーとパスフレーズを追加して Dashboard ユーザーを有効にすることができます。
kiali: enabled: true hub: kiali/ tag: v1.0.0 dashboard: user: admin passphrase: admin
表1.9 Kiali パラメーター
パラメーター | 説明 | 値 | デフォルト値 |
---|---|---|---|
|
これにより、サービスメッシュで Kiali を有効または無効にできます。Kiali はデフォルトでインストールされます。Kiali をインストールする必要がない場合は、 |
|
|
| Operator が Kiali イメージをプルするために使用するハブ。 | 有効なイメージリポジトリーです。 |
|
| Operator が Istio イメージをプルするために使用するタグ。 | 有効なコンテナーイメージタグです。 |
|
| Kiali コンソールにアクセスするためのユーザー名。注: これは OpenShift アカウントとは関連しません。 | 有効な Kiali ダッシュボードユーザー名 | なし |
| Kiali コンソールへのアクセスに使用されるパスワード。注: これは OpenShift アカウントとは関連しません。 | 有効な Kiali ダッシュボードパスフレーズ | なし |
1.3.1.4.8. 3scale の例
threeScale: enabled: false PARAM_THREESCALE_LISTEN_ADDR: 3333 PARAM_THREESCALE_LOG_LEVEL: info PARAM_THREESCALE_LOG_JSON: true PARAM_THREESCALE_LOG_GRPC: false PARAM_THREESCALE_REPORT_METRICS: true PARAM_THREESCALE_METRICS_PORT: 8080 PARAM_THREESCALE_CACHE_TTL_SECONDS: 300 PARAM_THREESCALE_CACHE_REFRESH_SECONDS: 180 PARAM_THREESCALE_CACHE_ENTRIES_MAX: 1000 PARAM_THREESCALE_CACHE_REFRESH_RETRIES: 1 PARAM_THREESCALE_ALLOW_INSECURE_CONN: false PARAM_THREESCALE_CLIENT_TIMEOUT_SECONDS: 10 PARAM_THREESCALE_GRPC_CONN_MAX_SECONDS: 60
表1.10 3scale パラメーター
パラメーター | 説明 | 値 | デフォルト |
---|---|---|---|
| 3scale アダプターを使用するかどうか |
|
|
| gRPC サーバーのリッスンアドレスを設定します。 | 有効なポート番号 |
|
| ログ出力の最小レベルを設定します。 |
|
|
| ログが JSON としてフォーマットされるかどうかを制御します。 |
|
|
| ログに gRPC 情報を含むかどうかを制御します。 |
|
|
| 3scale システムおよびバックエンドメトリクスが収集され、Prometheus に報告されるかどうかを制御します。 |
|
|
|
3scale | 有効なポート番号 |
|
| キャッシュから期限切れのアイテムを消去するまで待機する時間 (秒単位)。 | 時間 (秒単位) |
|
| キャッシュ要素の更新を試行する場合の期限 | 時間 (秒単位) |
|
|
キャッシュにいつでも保存できるアイテムの最大数。キャッシュを無効にするには | 有効な数字 |
|
| キャッシュ更新ループ時に到達できないホストが再試行される回数 | 有効な数字 |
|
|
|
|
|
| 3scale システムおよびバックエンドへの要求を終了するまで待機する秒数を設定します。 | 時間 (秒単位) |
|
| 接続を閉じるまでの最大秒数 (+/-10% のジッター) を設定します。 | 時間 (秒単位) |
|
1.3.1.5. マルチテナントインストールの設定
サービスメッシュインスタンスをインストールおよび設定する方法については、「マルチテナント Red Hat OpenShift Service Mesh のインストール」の章を参照してください。
1.3.1.6. Mixer ポリシー適用の更新
以前のバージョンの Red Hat OpenShift Service Mesh では、Mixer のポリシーの適用がデフォルトで有効にされていました。Mixer ポリシーの適用はデフォルトで無効になりました。ポリシータスクを実行する前にこれを有効にする必要があります。
以下のコマンドを実行して、現在の Mixer ポリシー適用のステータスを確認します。
$ oc get cm -n istio-system istio -o jsonpath='{.data.mesh}' | grep disablePolicyChecks
disablePolicyChecks: true
の場合、Service Mesh ConfigMap を編集します。$ oc edit cm -n istio-system istio
-
ConfigMap 内で
disablePolicyChecks: true
を見つけ、値をfalse
に変更します。 - 設定を保存してエディターを終了します。
-
Mixer ポリシー適用ステータスを再度チェックして、
false
に設定されていることを確認します。
1.3.1.7. コントロールプレーンのデプロイ
OpenShift Container Platform 4.1 の導入により、ホストのネットワーク機能は、iptables ではなく nftables をベースとするようになりました。この変更は、サービスメッシュアプリケーションコンポーネントの初期化に影響します。サービスメッシュは、サービスメッシュのネットワークコンポーネントを正常に初期化するために、OpenShift が実行されているホストオペレーティングシステムを認識する必要があります。
OpenShift Container Platform 4.1 を使用している場合は、これらの変更をカスタムリソースに加える必要はありません。
OpenShift インストールが Red Hat Enterprise Linux (RHEL) 7 ホストにデプロイされている場合、カスタムリソースは以下を含む RHEL 7 proxy-init
コンテナーイメージを明示的に要求する必要があります。
RHEL 7 ホストの proxy-init コンテナーの有効化
apiVersion: maistra.io/v1 kind: ServiceMeshControlPlane spec: istio: global: proxy_init: image: proxy-init
作成したカスタムリソース定義ファイルを使用してサービスメッシュコントロールプレーンをデプロイします。
-
istio-
installation.yaml
という名前のカスタムリソース定義ファイルを作成します。 以下のコマンドを実行してコントロールプレーンをデプロイします。
$ oc create -n istio-system -f istio-installation.yaml
以下のコマンドを実行して、インストールプロセス時に Pod の進捗を確認します。
$ oc get pods -n istio-system -w
1.4. マルチテナントサービスメッシュのインストール
1.4.1. マルチテナント Red Hat OpenShift Service Mesh のインストール
Red Hat OpenShift Service Mesh Operator はマルチテナントコントロールプレーンのインストールのサポートを提供します。マルチテナントコントロールプレーンは、指定された namespace のみがサービスメッシュに参加できるように設定されるので、他のインストールからメッシュを分離します。
- マルチテナントコントロールプレーンのインストールをクラスター全体のコントロールプレーンのインストールと併用することはできません。Red Hat OpenShift Service Mesh のインストールは、マルチテナントまたは単一のクラスター全体のインストールのいずれかである必要があります。
- マルチテナントコントロールプレーンのインストールは、OpenShift Container Platform の再起動およびアップグレードで問題を生じさせることで知られています。マルチテナントコントロールプレーンのインストールは、Red Hat OpenShift Service Mesh 0.12.TechPreview 以降のデフォルト設定です。
1.4.1.1. マルチテナント Red Hat OpenShift Service Mesh インストールに関する既知の問題
現在、自動ルート作成はマルチテナントのサービスメッシュインストールと互換性がありません。マルチテナントインストールを試行する予定がある場合には、ServiceMeshControlPlane
で ior_enabled
を false
に設定して無効にされていることを確認します。
-
MeshPolicy
は依然としてクラスタースコープのリソースであり、OpenShift にインストールされたすべてのコントロールプレーンに適用されます。これにより、複数のコントロールプレーンのインストールや、1つのコントロールプレーンが削除される場合の不明な動作の発生を防ぐことができます。 -
Jaeger エージェントは
DaemonSet
として実行されるため、トレーシング
は単一のServiceMeshControlPlane
インスタンスに対してのみ有効にされる場合があります。 ServiceMeshControlPlane
リソースを削除する前にコントロールプレーンを含むプロジェクトを削除する場合、インストールの一部は削除されない可能性があります。-
SecurityContextConstraints
に追加されたサービスアカウントは削除されない可能性があります。 -
Kiali に関連付けられた
OAuthClient
リソースは削除されないか、その redirectURI の一覧が正確ではないことがあります。
-
1.4.1.2. マルチテナントとクラスター全体のインストールの相違点
マルチテナントインストールとクラスター全体のインストールの主な違いは、コントロールプレーンのデプロイメント (Galley や Pilot など) で使用される権限の範囲です。コンポーネントではクラスタースコープのロールベースのアクセス制御 (RBAC) ClusterRoleBinding
が使用されなくなりましたが、コンポーネントは namespace スコープの RBAC RoleBinding
に依存します。
members
一覧のすべての namespace には、コントロールプレーンのデプロイメントに関連付けられた各サービスアカウントの RoleBinding
があり、各コントロールプレーンのデプロイメントはそれらのメンバー namespace のみを監視します。各メンバー namespace には maistra.io/member-of
ラベルが追加されており、member-of
の値はコントロールプレーンのインストールが含まれる namespace になります。
1.4.1.3. マルチテナントインストールでの namespace の設定
マルチテナントコントロールプレーンのインストールは、Service Mesh の一部として設定された namespace のみに影響を与えます。ServiceMeshControlPlane
リソースと同じ namespace にある ServiceMeshMemberRoll
リソースの Service Mesh に関連付けられた namespace を指定し、これを default
として指定する必要があります。
Container Network Interface (CNI) を有効にすると、手動のサイドカー挿入が機能しますが、Pod が ServiceMeshMemberRoll
リソースの一部でない限り、Pod はコントロールプレーンと通信できません。
メンバー namespace はコントロールプレーンのインストールが成功した場合にのみ更新されます。
任意の数の namespace を追加できますが、namespace は 単一の ServiceMeshMemberRoll
にのみ属することができます。
ServiceMeshMemberRoll
リソースは、以下のイベントに対応して調整されます。-
ServiceMeshMemberRoll
は作成、更新、または削除されます。 -
ServiceMeshMemberRoll
を含む namespace のServiceMeshControlPlane
リソースは作成または更新されます。 -
ServiceMeshMemberRoll
に一覧表示される namespace は作成または削除されます。
-
ServiceMeshMemberRoll
リソースは、対応する ServiceMeshControlPlane
リソースが削除されると削除されます。
以下は、bookinfo namespace をサービスメッシュに統合する例です。
-
ServiceMeshControlPlane
カスタムリソースと同じ namespace にServiceMeshMemberRoll
という名前のカスタムリソースファイルを作成します。 -
リソースに
default
という名前を付けます。 namespaces を
ServiceMeshMemberRoll
のメンバー一覧に追加します。この例では、bookinfo
namespace はサービスメッシュに結合されます。apiVersion: maistra.io/v1 kind: ServiceMeshMemberRoll metadata: name: default spec: members: # a list of namespaces joined into the service mesh - bookinfo
1.5. インストール後のタスク
1.5.1. コントロールプレーンのインストールの確認
リソースの名前は istio-installation
です。
以下のコマンドを実行して、Operator がコントロールプレーンのデプロイを終了したかどうかを判別します。
$ oc get servicemeshcontrolplane/basic-install -n istio-system --template='{{range .status.conditions}}{{printf "%s=%s, reason=%s, message=%s\n\n" .type .status .reason .message}}{{end}}'
コントロールプレーンのインストールが完了すると、出力は以下のようになります。
Installed=True, reason=InstallSuccessful, message=%!s(<nil>)
コントロールプレーンをデプロイしたら、以下のコマンドを実行して Pod のステータスを確認します。
$ oc get pods -n istio-system
Pod が以下のような状態にあることを確認します。
注記この検証ステップの実行時に返される結果は、クラスターのノードの数や、3scale、Jaeger、Kiali、Prometheus などを使用しているかどうかによって異なります。
NAME READY STATUS RESTARTS AGE 3scale-istio-adapter-67b96f97b5-cwvgt 1/1 Running 0 99s grafana-75f4cbbc6-xw99s 1/1 Running 0 54m istio-citadel-8489b8bb96-ttqfd 1/1 Running 0 54m stio-egressgateway-5ccd4d5ddd-wtp2h 1/1 Running 0 52m istio-galley-58ff8db57c-jrpkz 1/1 Running 0 54m istio-ingressgateway-698674848f-bk57s 1/1 Running 0 52m istio-node-2d764 1/1 Running 0 54m istio-node-4h926 1/1 Running 0 54m istio-node-6qxcj 1/1 Running 0 54m istio-node-8fxqz 1/1 Running 0 54m istio-node-gzg5v 1/1 Running 0 54m istio-node-vxx5p 1/1 Running 0 54m istio-pilot-764966cf69-9nlhp 2/2 Running 0 19m istio-policy-7c856f7d5f-4fjk4 2/2 Running 2 53m istio-sidecar-injector-757b8ccdbf-znggc 1/1 Running 0 49m istio-telemetry-65d8b47c98-jrp9h 2/2 Running 2 53m jaeger-f775b79f8-cmbb2 2/2 Running 0 54m kiali-7646d796cd-kfx29 1/1 Running 0 20m prometheus-56cb9c859b-dlqmn 2/2 Running 0 54m
1.6. アプリケーションの要件
1.6.1. Red Hat OpenShift Service Mesh へのアプリケーションのデプロイに関する要件
アプリケーションをサービスメッシュにデプロイする場合、Istio のアップストリームのコミュニティーバージョンの動作と Red Hat OpenShift Service Mesh インストール内での動作に違いがいくつかあります。
1.6.1.1. アプリケーションサービスアカウント用のセキュリティー制約の設定
セキュリティー制約の緩和は、Red Hat OpenShift Service Mesh のテクノロジープレビューでのみ必要です。
OpenShift 環境で実行されているサービスメッシュにアプリケーションをデプロイする場合、アプリケーションを正常に機能させるために、サービスアカウントを使用してアプリケーションのセキュリティー制約を緩和する必要があります。各サービスアカウントには、サイドカーコンテナーを正常に実行できるようにするために、anyuid
および privileged
SCC (Security Context Constraints) を指定したパーミッションを付与する必要があります。
Pod のネットワーク設定への変更が istio-init
初期化コンテナーで正常に更新されるようにするには 特権付き
SCC が必要であり、サイドカーコンテナーが必要なユーザー ID の 1337
で実行できるようにするには、anyuid
SCC が必要です。
適切なパーミッションを設定するには、アプリケーションの Pod で使用されるサービスアカウントを特定する必要があります。ほとんどのアプリケーションでは、これは デフォルト
のサービスアカウントですが、Deployment/DeploymentConfig は serviceAccountName
を指定して Pod 仕様内でこの設定を上書きする可能性があります。
特定された各サービスアカウントについて、クラスター設定を更新して、クラスター管理者権限を持つアカウントで以下のコマンドを実行し、クラスターに anyuid
および 特権付き
SCC へのアクセスが付与されるようにする必要があります。
SCC の変更を必要とするサービスアカウントを特定します。
注記<service account>
および<namespace>
をアプリケーション固有の値に置き換えます。関連するサイドカーコンテナーに
anyuid
SCC を必要とするそれぞれのサービスアカウントについて、このコマンドを実行します。$ oc adm policy add-scc-to-user anyuid -z <service account> -n <namespace>
特権付き
SCC が必要な各サービスアカウントについてこのコマンドを実行し、その Pod のネットワーク設定に対して更新を正常に実行できるようにします。$ oc adm policy add-scc-to-user privileged -z <service account> -n <namespace>
1.6.1.2. マスター設定の更新
OpenShift Container Platform 4.1 を実行している場合には、マスター設定の更新は必要ありません。
サービスメッシュは、アプリケーションの Pod 内のプロキシーサイドカーコンテナーの存在に依存して、アプリケーションにサービスメッシュ機能を提供します。自動のサイドカーコンテナー挿入を有効にしたり、手動で管理したりできます。デプロイメント時にアプリケーションにサービスメッシュの適切な設定が含まれるように、アノテーションを使用して自動挿入を実行することが推奨されます。この場合、namespace にラベルを付ける必要はありません。この方法で必要となる権限が少なく、ビルダー Pod などの他の OpenShift 機能と競合しません。
namespace にラベルを付けている場合、デフォルトで Istio のアップストリームバージョンはサイドカーコンテナーを挿入します。Red Hat OpenShift Service Mesh で namespace にラベルを付ける必要はありません。 ただし、Red Hat OpenShift Service Mesh では、サイドカーコンテナーがデプロイメントに自動的に挿入されるようにオプトインすることが求められます。これにより、(Pod のビルドまたはデプロイの場合など) 不要な場合にはサイドカーコンテナーを挿入しないようにできます。Webhook はすべての namespace にデプロイする Pod の設定をチェックし、これらの Pod が適切なアノテーションで挿入をオプトインしているかどうかを確認します。
サービスメッシュサイドカーの自動挿入を有効にするには、 Webhook のサポートおよび証明書署名要求 (CSR) の署名を追加するために、まず各マスターでマスター設定を変更する必要があります。
OpenShift Container Platform インストール内の各マスターで以下の変更を加えます。
- マスター設定ファイルを含むディレクトリーに移動します(例: /etc/origin/master/master-config.yaml)。
以下の内容を含む
master-config.patch
という名前のファイルを作成します。admissionConfig: pluginConfig: MutatingAdmissionWebhook: configuration: apiVersion: apiserver.config.k8s.io/v1alpha1 kubeConfigFile: /dev/null kind: WebhookAdmission ValidatingAdmissionWebhook: configuration: apiVersion: apiserver.config.k8s.io/v1alpha1 kubeConfigFile: /dev/null kind: WebhookAdmission
同じディレクトリーで以下のコマンドを実行し、
master-config.yaml
ファイルにパッチを適用します。$ cp -p master-config.yaml master-config.yaml.prepatch $ oc ex config patch master-config.yaml.prepatch -p "$(cat master-config.patch)" > master-config.yaml $ /usr/local/bin/master-restart api && /usr/local/bin/master-restart controllers
1.6.1.2.1. サイドカーの自動挿入
アプリケーションを Red Hat OpenShift Service Mesh にデプロイする場合は、sidecar.istio.io/inject
アノテーションに値 true
を指定して、挿入をオプトインする必要があります。オプトインにより、サイドカーコンテナーの挿入が OpenShift エコシステム内の複数のフレームワークが使用する、ビルダー Pod などの他の OpenShift 機能に干渉しないようにします。
- エディターでアプリケーションの設定 yaml ファイルを開きます。
sidecar.istio.io/inject
を、以下に示すように"true"
の値が含まれる設定 yaml に追加します。スリープテストアプリケーションの例
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: sleep spec: replicas: 1 template: metadata: annotations: sidecar.istio.io/inject: "true" labels: app: sleep spec: containers: - name: sleep image: tutum/curl command: ["/bin/sleep","infinity"] imagePullPolicy: IfNotPresent
- 設定ファイルを保存します。
1.6.1.2.2. サイドカーコンテナーの手動挿入
サイドカーコンテナーの手動挿入は、アップストリームの istioctl
コマンドを使用してサポートされます。
サイドカーを手動で挿入する場合は、istio-system namespace 内の istio-sidecar-injector configmap から正しい設定を取得できるように、実行中のクラスターへのアクセスがあることを確認します。
実行可能ファイルを取得し、手動挿入でアプリケーションをデプロイするには、以下を行います。
- OS に適した インストール をダウンロードします。
-
istioctl
バイナリーをパス内の bin ディレクトリーに追加します。 以下のコマンドを実行してサイドカーをアプリケーションに挿入し、設定を
oc
コマンドにパイプしてデプロイメントを作成します。$ istioctl kube-inject -f app.yaml | oc create -f -
1.7. チュートリアル
いくつかのチュートリアルを使用し、サービスメッシュについての詳細を確認することができます。
1.7.1. Bookinfo チュートリアル
アップストリームの Istio プロジェクトには bookinfo というチュートリアルのサンプルがあり、これは各種の Istio 機能を示すために使用される 4 つの異なるマイクロサービスで構成されています。Bookinfo アプリケーションは、オンラインブックストアの単一カタログエントリーのように、書籍に関する情報を表示します。ページに表示される内容は、書籍の説明、書籍の詳細 (ISBN、ページ数その他の情報)、および書評です。
Bookinfo アプリケーションは 4 つのマイクロサービスで構成されます。
-
productpage
マイクロサービスは、details
とreviews
マイクロサービスを呼び出して、ページを設定します。 -
details
マイクロサービスには書籍の情報が含まれています。 -
reviews
マイクロサービスには、書評が含まれます。これはratings
マイクロサービスも呼び出します。 -
ratings
マイクロサービスには、書評を伴う書籍のランキング情報が含まれます。
reviews マイクロサービスには、以下の 3 つのバージョンがあります。
-
バージョン v1 は、
ratings
サービスを呼び出しません。 -
バージョン v2 は、
ratings
サービスを呼び出して、各評価を 1 から 5 の黒い星で表示します。 -
バージョン v3 は、
ratings
サービスを呼び出して、各評価を 1 から 5 の赤い星で表示します。
1.7.1.1. Bookinfo アプリケーションのインストール
以下の手順では、Service Mesh 0.12.TechPreview を使用する OpenShift Container Platform での Bookinfo チュートリアルのデプロイおよび実行について説明します。
前提条件
- OpenShift Container Platform 3.11 以降がインストールされている。
- Red Hat OpenShift Service Mesh 0.12.TechPreview がインストールされている。
Red Hat OpenShift Service Mesh は、アップストリームの Istio プロジェクトとは別の自動挿入を実装します。そのため、この手順では Istio サイドカーコンテナーの自動挿入を有効にするためのアノテーションが付けられた bookinfo.yaml
ファイルのバージョンを使用します。
Bookinfo アプリケーションのプロジェクトを作成します。
$ oc new-project myproject
Bookinfo で使用されるサービスアカウントを "myproject" namespace の
anyuid
および特権付き
SCC に追加して SCC (Security Context Constraints) を更新します。$ oc adm policy add-scc-to-user anyuid -z default -n myproject $ oc adm policy add-scc-to-user privileged -z default -n myproject
bookinfo.yaml
ファイルを適用して Bookinfo アプリケーションを "myproject" namespace でデプロイします。$ oc apply -n myproject -f https://raw.githubusercontent.com/Maistra/bookinfo/master/bookinfo.yaml
bookinfo-gateway.yaml
ファイルを適用して Bookinfo の ingress ゲートウェイを作成します。$ oc apply -n myproject -f https://raw.githubusercontent.com/Maistra/bookinfo/master/bookinfo-gateway.yaml
GATEWAY_URL
パラメーターの値を設定します。$ export GATEWAY_URL=$(oc get route -n istio-system istio-ingressgateway -o jsonpath='{.spec.host}')
1.7.1.2. Bookinfo インストールの検証
アプリケーションが正常にデプロイされていることを確認するには、以下のコマンドを実行します。
$ curl -o /dev/null -s -w "%{http_code}\n" http://$GATEWAY_URL/productpage
または、ブラウザーで http://$GATEWAY_URL/productpage
を開くことができます。
1.7.1.3. デフォルトの宛先ルールの追加
相互 TLS を有効にしていない場合:
$ oc apply -n myproject -f https://raw.githubusercontent.com/istio/istio/release-1.1/samples/bookinfo/networking/destination-rule-all.yaml
相互 TLS を有効にしている場合:
oc apply -n myproject -f https://raw.githubusercontent.com/istio/istio/release-1.1/samples/bookinfo/networking/destination-rule-all-mtls.yaml
利用可能な宛先ルールを一覧表示するには、以下のコマンドを実行します。
$ oc get destinationrules -o yaml
1.7.1.4. Bookinfo アプリケーションの削除
Bookinfo アプリケーションで終了したら、クリーンアップスクリプトを実行して削除することができます。
本書の他のチュートリアルでも Bookinfo アプリケーションを使用しています。他のチュートリアルを継続して使用する場合は、クリーンアップスクリプトを実行しないでください。
クリーンアップスクリプトをダウンロードします。
$ curl -o cleanup.sh https://raw.githubusercontent.com/Maistra/bookinfo/master/cleanup.sh && chmod +x ./cleanup.sh
クリーンアップスクリプトを実行して Bookinfo 仮想サービス、ゲートウェイを削除し、Pod を終了します。
$ ./cleanup.sh namespace ? [default] myproject
以下のコマンドを実行してシャットダウンを確認します。
$ oc get virtualservices -n myproject No resources found. $ oc get gateway -n myproject No resources found. $ oc get pods -n myproject No resources found.
1.7.2. 分散トレースのチュートリアル
Jaeger はオープンソースの分散トレースシステムです。Jaeger はマイクロサービスベースの分散システムの監視およびトラブルシューティングに使用します。Jaeger を使用すると、トレースを実行できます。これは、アプリケーションを構成するさまざまなマイクロサービスで要求のパスを追跡します。Jaeger はデフォルトでサービスメッシュの一部としてインストールされます。
このチュートリアルでは、サービスメッシュおよび bookinfo
チュートリアルを使用して、Red Hat OpenShift Service Mesh の Jaeger コンポーネントでトレースを実行する方法を説明します。
前提条件
- OpenShift Container Platform 3.11 以降がインストールされている。
- Red Hat OpenShift Service Mesh 0.12.TechPreview がインストールされている。
-
Bookinfo
デモ用アプリケーションがインストールされている。
1.7.2.1. トレースの生成とトレースデータの分析
- Bookinfo アプリケーションをデプロイした後に、http://$GATEWAY_URL/productpage にアクセスし、ページを数回更新して一部のアクティビティーを生成します。
Jaeger ダッシュボードにアクセスするためのルートはすでに存在します。ルートの詳細についてクエリーします。
$ export JAEGER_URL=$(oc get route -n istio-system jaeger-query -o jsonpath='{.spec.host}')
-
ブラウザーを起動して、
https://${JAEGER_URL}
に移動します。 Jaeger ダッシュボードの左側のペインで、サービスメニューから「productpage」を選択し、ペイン下部の Find Traces ボタンをクリックします。以下のイメージに示されているように、トレースの一覧が表示されます。
一覧のトレースのいずれかをクリックし、そのトレースの詳細ビューを開きます。最上部 (最新の) トレースをクリックすると、
'/productpage
の最終更新に対応する詳細が表示されます。先の図のトレースは、一部のネストされたスパンで構成されており、各スパンは Bookinfo サービス呼び出しに対応し、すべてが
'/productpage
要求の応答で実行されます。全体的な処理時間は 2.62s で、details サービスは 3.56ms、reviews サービスは 2.6s、ratings サービスは 5.32ms かかりました。リモートサービスへの各呼び出しは、それぞれクライアント側とサーバー側のスパンで表されます。たとえば、details クライアント側スパンにはproductpage details.myproject.svc.cluster.local:9080
というラベルが付けられます。その下にネスト化されるスパンには、details details.myproject.svc.cluster.local:9080
というラベルが付けられ、要求のサーバー側の処理に対応します。トレースは istio-policy への呼び出しも表示し、これには Istio による承認チェックが反映されます。
1.7.2.2. トレーシングチュートリアルの削除
Bookinfo チュートリアルを削除する手順に従い、トレーシングチュートリアルを削除します。
1.7.3. Prometheus チュートリアル
Prometheus はオープンソースのシステムであり、サービスモニタリングツールキットです。Prometheus は指定された間隔で設定されたターゲットのメトリクスを収集し、ルール式を評価し、結果を表示し、一部の条件が true の場合にアラートをトリガーできます。Grafana またはその他の API コンシューマーを使用して、収集したデータを視覚化できます。
このチュートリアルでは、サービスメッシュおよび bookinfo
のチュートリアルを使用して、Prometheus を使用してメトリクスについてクエリーする方法を示します。
前提条件
- OpenShift Container Platform 3.11 以降がインストールされている。
- Red Hat OpenShift Service Mesh 0.12.TechPreview がインストールされている。
-
Bookinfo
デモ用アプリケーションがインストールされている。
1.7.3.1. メトリクスのクエリー
prometheus
サービスがクラスターで実行されていることを確認します。Kubernetes 環境では、以下のコマンドを実行します。$ oc get svc prometheus -n istio-system
以下のような出力が表示されます。
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE prometheus 10.59.241.54 <none> 9090/TCP 2m
Bookinfo アプリケーションにアクセスしてネットワークトラフィックを生成します。
$ curl -o /dev/null http://$GATEWAY_URL/productpage
Prometheus ユーザーインターフェースにアクセスするためのルートはすでに存在しています。ルートの詳細についてクエリーします。
$ export PROMETHEUS_URL=$(oc get route -n istio-system prometheus -o jsonpath='{.spec.host}')
ブラウザーを起動し、
http://${PROMETHEUS_URL}
に移動します。以下の図のように Prometheus ホーム画面が表示されます。Expression フィールドに
istio_request_duration_seconds_count
を入力し、Execute
ボタンをクリックします。以下の図と同様の画面が表示されます。-
セレクターを使用してクエリーを絞り込むことができます。たとえば、
istio_request_duration_seconds_count{destination_workload="reviews-v2"}
は一致する destination_workload ラベルのあるカウンターのみを表示します。クエリーの使用についての詳細は、Prometheus のドキュメントを参照してください。 利用可能なすべての Prometheus メトリクスを一覧表示するには、以下のコマンドを実行します。
$ oc get prometheus -n istio-system -o jsonpath='{.items[*].spec.metrics[*].name}' requests_total request_duration_seconds request_bytes response_bytes tcp_sent_bytes_total tcp_received_bytes_total
クエリーで使用される場合に、返されるメトリクスの名前には istio_
が付けられている必要があることに注意してください。 たとえば、requests_total
は istio_requests_total
になります。
1.7.3.2. Prometheus チュートリアルの削除
Bookinfo チュートリアルを削除する手順に従い、Prometheus チュートリアルを削除します。
1.7.4. Kiali チュートリアル
Kiali は Istio と連携してサービスメッシュトポロジーを可視化し、サーキットブレーカー、要求レートなどの機能を見えるようにします。Kiali は、抽象アプリケーションからサービスおよびワークロードまで、さまざまなレベルでのメッシュコンポーネントに関する洞察を提供します。Kiali は、リアルタイムで namespace のインタラクティブなグラフビューを提供します。複数のレベル (アプリケーション、バージョン、ワークロード) での対話と、選択したグラフノードまたはエッジのコンテキスト情報およびチャートを表示できます。
このチュートリアルでは、サービスメッシュと bookinfo
のチュートリアルを使用して、Kiali コンソールでサービスメッシュのトポロジーおよび健全性を表示する方法を示します。
前提条件
- OpenShift Container Platform 3.11 以降がインストールされている。
- Red Hat OpenShift Service Mesh 0.12.TechPreview がインストールされている。
- カスタムリソースファイルで指定される Kiali パラメーター。
-
Bookinfo
デモ用アプリケーションがインストールされている。
1.7.4.1. Kiali コンソールへのアクセス
Kiali コンソールにアクセスするためのルートはすでに存在します。以下のコマンドを実行して、ルートおよび Kiali URL を取得します。
$ oc get routes
環境が若干異なる可能性がありますが、以下のような結果が表示されます。
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD grafana grafana-istio-system.127.0.0.1.nip.io grafana http None istio-ingress istio-ingress-istio-system.127.0.0.1.nip.io istio-ingress http None istio-ingressgateway istio-ingressgateway-istio-system.127.0.0.1.nip.io istio-ingressgateway http None jaeger-query jaeger-query-istio-system.127.0.0.1.nip.io jaeger-query jaeger-query edge None kiali kiali-istio-system.127.0.0.1.nip.io kiali <all> None prometheus prometheus-istio-system.127.0.0.1.nip.io prometheus http-prometheus None tracing tracing-istio-system.127.0.0.1.nip.io tracing tracing edge None
-
ブラウザーを起動し、https://${KIALI_URL} (上記の出力では
kiali-istio-system.127.0.0.1.nip.io
) に移動します。Kiali コンソールのログイン画面が表示されるはずです。 - インストール時にカスタムリソースファイルに指定したユーザー名およびパスワードを使用して、Kiali コンソールにログインします。
1.7.4.2. 概要ページ
初回ログイン時には概要 (Overview) ページが表示されます。ここでは、サービスメッシュに含まれるさまざまな namespace の健全性についての概要を確認できます。アプリケーション、ワークロード、またはサービスの正常性を表示できます。
1.7.4.3. グラフページ
グラフページには、要求によってつながれるマイクロサービスのグラフが表示されます。このページでは、アプリケーション、ワークロード、またはサービスが相互に対話する方法を確認することができます。
左側のナビゲーションにあるグラフをクリックします。
-
必要に応じて、Namespace メニューから
bookinfo
を選択します。グラフは Bookinfo アプリケーション内のアプリケーションを表示します。 - Namespace メニューの疑問符 (?) をクリックすると、Graph ヘルプツアーを利用できます。
- Done をクリックして、ヘルプツアーを閉じます。
左下隅の Legend をクリックします。Kiali は、グラフの凡例を表示します。
- グラフの凡例を閉じます。
- productpage ノードにカーソルを合わせます。グラフは、ノードからの送受信トラフィックのみをハイライトすることに注意してください。
- productpage ノードをクリックします。ページの右側の詳細が変更され、productpage の詳細が表示されます。
1.7.4.4. アプリケーションページ
アプリケーションページでは、アプリケーション、それらの健全性、その他の詳細情報を検索し、表示できます。
- 左側のナビゲーションにある Applications をクリックします。
-
必要に応じて、Namespace メニューから
bookinfo
を選択します。このページには、選択した namespace のアプリケーションとその健全性が表示されます。 - その他の健全性の詳細情報を表示するには、健全性 (Health) アイコンにカーソルを合わせます。
reviews
サービスをクリックし、そのアプリケーションの詳細を表示します。-
アプリケーションの詳細ページでは、より詳細な健全性情報を表示でき、
reviews
サービスの 3 つのバージョンについてさらに詳しく見ることができます。 - アプリケーションの詳細ページからタブをクリックして、アプリケーションのトラフィックおよびインバウンドとアウトバウンドのメトリクスを表示することもできます。
1.7.4.5. ワークロードページ
ワークロードページでは、ワークロード、それらの健全性、その他の詳細情報を検索し、表示できます。
- 左側のナビゲーションにある Workloads をクリックします。
-
必要に応じて、Namespace メニューから
bookinfo
を選択します。このページでは、選択した namespace のワークロード、それらの健全性およびラベルが表示されます。 -
reviews-v1
ワークロードをクリックし、ワークロードの詳細を表示します。 ワークロードの詳細ページで、ワークロードに関連付けられた Pod とサービスの概要を表示できます。
- ワークロードの詳細ページから、タブをクリックしてワークロードのトラフィック、ログ、およびインバウンドおよびアウトバウンドメトリクスを表示することもできます。
1.7.4.6. サービスページ
サービスページでは、サービス、それらの健全性、その他の詳細情報を検索し、表示できます。
- 左側のナビゲーションにある Services をクリックします。
-
必要に応じて、Namespace メニューから
bookinfo
を選択します。このページには、選択した namespace で実行されているすべてのサービスの一覧と、ヘルスステータスなどのそのサービスに関する追加情報が表示されます。 - サービスに関する健全性の情報を表示するには、いずれかのサービスのヘルスアイコンにカーソルを合わせます。サービスは、オンラインの状態で要求に応答し、エラーがない場合に、正常であるとみなされます。
Reviews サービスをクリックして、詳細情報を表示します。このサービスには 3 つの異なるバージョンがあることに注意してください。
- サービスの詳細ページで、ワークロード、仮想サービス、サービスに関連付けられた宛先ルールの概要を表示できます。
- サービスの詳細ページからは、タブをクリックしてサービスのトラフィック、インバウンドメトリクスおよびトレースを表示することもできます。
Actions メニューをクリックします。ここから、以下の操作を実行できます。
- 重み付けされたルーティングの作成
- 一致するルーティングの作成
- トラフィックの一時停止
- すべてのトラフィックルーティングの削除
- サービスの名前を 1 つクリックして、そのサービスの特定バージョンに関する追加情報を表示します。
1.7.4.7. Istio 設定ページ
Istio 設定ページでは、サーキットブレーカー、宛先ルール、フォールト挿入、ゲートウェイ、ルート、ルートルール、仮想サービスなど、現在サービスメッシュに対して実行されているすべての設定を表示できます。
- 左側のナビゲーションにある Istio Config をクリックします。
必要に応じて、Namespace メニューから
bookinfo
を選択します。このページには、選択した namespace で実行されている設定の一覧と検証のステータスが表示されます。設定ファイルに関する追加情報を表示するには、以下のいずれかの設定をクリックします。
1.7.4.8. 分散トレースのページ
左側のナビゲーションの Distributed Tracing リンクをクリックします。このページでは、Jaeger によって提供されるデータをトレースできます。
1.7.4.9. Kiali チュートリアルの削除
Kiali チュートリアルを削除する手順は、Bookinfo チュートリアルを削除する手順と同じです。
1.7.5. Grafana チュートリアル
Grafana は、モニタリングおよびメトリクス分析とダッシュボードを作成するためのオープンソースツールです。Grafana を使用して、Graphite、Elasticsearch、OpenTSDB、 Prometheus、または InfluxDB などメトリクスが保存される場所にかかわらず、クエリー、視覚化、アラートを実行できます。Istio には Prometheus および Grafana によるモニタリングが含まれます。
このチュートリアルでは、サービスメッシュと bookinfo
のチュートリアルを使用して、Istio Dashboard を設定し、使用してメッシュトラフィックを監視する方法を説明します。このタスクの一環として、Grafana Istio アドオンをインストールし、Web ベースのインターフェースを使用してサービスメッシュのトラフィックデータを表示します。
前提条件
- OpenShift Container Platform 3.11 以降がインストールされている。
- Red Hat OpenShift Service Mesh 0.12.TechPreview がインストールされている。
-
Bookinfo
デモ用アプリケーションがインストールされている。
1.7.5.1. Grafana ダッシュボードへのアクセス
Grafana ダッシュボードにアクセスするためのルートがすでに存在しています。ルートの詳細についてクエリーします。
$ export GRAFANA_URL=$(oc get route -n istio-system grafana -o jsonpath='{.spec.host}')
ブラウザーを起動して、
http://${GRAFANA_URL}
に移動します。以下の図が示すように、Grafana のホーム画面が表示されます。左上隅のメニューから、Istio Mesh Dashboard を選択し、 Istio メッシュメトリクスを表示します。
Bookinfo アプリケーションにアクセスして一部のトラフィックを生成します。
$ curl -o /dev/null http://$GATEWAY_URL/productpage
Dashboard は以下のようなメッシュを使用したトラフィックを反映します。
サービスの詳細なメトリクスを表示するには、Service 列でサービス名をクリックします。サービスダッシュボードは以下の図のようになります。
Bookinfo が http ベースのサービスのみを使用するので、TCP Bandwidth メトリクスは空であることに注意してください。また、ダッシュボードは、クライアントワークロードサービスを呼び出すワークロード、およびサービスワークロードからの要求を処理するワークロードについてのメトリクスを表示します。ダッシュボードの上部でメニューを使用して、別のサービスに切り替えるか、またはクライアントおよびサービスワークロードでメトリクスをフィルターできます。
ワークロードダッシュボードに切り替えるには、左上隅にあるメニューで Istio Workload Dashboard をクリックします。以下の図のような画面が表示されます。
このダッシュボードには、ワークロードのメトリクスとクライアント (インバウンド) およびサービス (アウトバウンド) ワークロードについてのメトリクスが表示されます。別のワークロードに切り替えることができます。インバウンドまたはアウトバウンドのワークロードでメトリクスをフィルターするには、ダッシュボードの上部にあるメニューを使用します。
1.7.5.2. Grafana チュートリアルの削除
Bookinfo チュートリアルを削除する手順に従い、Grafana のチュートリアルを削除します。
1.7.6. Red Hat OpenShift Application Runtime Missions
bookinfo
ベースのチュートリアルのほかにも、Fabric8 統合開発プラットフォームランチャーを使用し、Istio 機能の一部を確認するために、サービスメッシュ固有のチュートリアル (ミッション) とサンプルアプリケーション (ブースター) を使用できます。これらのブースターやミッションクリティカルのそれぞれは 4 つの異なるアプリケーションランタイムで利用できます。Fabric8 の詳細は、Fabric8 のドキュメントを参照してください。
前提条件
- OpenShift Container Platform 3.11 以降がインストールされている。
- Red Hat OpenShift Service Mesh 0.12.TechPreview がインストールされている。
- ランチャーパラメーターがカスタムリソースファイルで指定されている。
表1.11 RHOAR チュートリアル
ランタイム | ミッション | 説明 |
---|---|---|
Springboot | ここでは、Istio を使用して Circuit Breaker アーキテクチャーパターンを実装する方法を取り上げます。 | |
Springboot | このシナリオでは、Jaeger の分散トレース機能およびサービスメッシュで適切にインストルメント化されたマイクロサービスの対話について取り上げます。 | |
Springboot | ここでは、サービスへのアクセスに関する Istio セキュリティーの概念が、アプリケーションによって個別に制御されるのではなく、プラットフォームによって制御されるケースを説明します。 | |
Springboot | ここでは、実際のロールアウトシナリオをシミュレートするために設計されたサンプルアプリケーションのセットを使用して Istio の動的トラフィックルーティング機能を使用するケースを説明します。 | |
Thorntail (A.K.A.Wildfly Swarm) | ここでは、Istio を使用して Circuit Breaker アーキテクチャーパターンを実装する方法を取り上げます。 | |
Thorntail | このシナリオでは、Jaeger の分散トレース機能およびサービスメッシュで適切にインストルメント化されたマイクロサービスの対話について取り上げます。 | |
Thorntail | ここでは、サービスへのアクセスに関する Istio セキュリティーの概念が、アプリケーションによって個別に制御されるのではなく、プラットフォームによって制御されるケースを説明します。 | |
Thorntail | ここでは、実際のロールアウトシナリオをシミュレートするために設計されたサンプルアプリケーションのセットを使用して Istio の動的トラフィックルーティング機能を使用するケースを説明します。 | |
Vert.x | ここでは、Istio を使用して (最小限に) インストルメント化された Eclipse Vert.x マイクロサービスで Circuit Breaker を実装する方法を説明します。 | |
Vert.x | このシナリオでは、Jaeger の分散トレース機能と(最小限に)インストルメント化された Eclipse Vert.x アプリケーションのセットの対話について取り上げます。 | |
Vert.x | このシナリオでは、Eclipse Vert.x アプリケーションのセットを使用した Istio Transport Layer Security(TLS) およびアクセス制御リスト (ACL) について説明します。 | |
Vert.x | ここでは、最小限のサンプルアプリケーションのセットを使って Istio の動的トラフィックルーティング機能を使用するケースを取り上げます。 | |
Node.js | ここでは、Istio を使用して Node.js アプリケーションで Circuit Breaker アーキテクチャーのパターンを実装する方法について説明します。 | |
Node.js | このシナリオでは、Jaeger の分散トレース機能およびサービスメッシュで実行される適切にインストルメント化された Node.js アプリケーションの対話について取り上げます。 | |
Node.js | 以下のシナリオは、Node.js アプリケーションで Istio Transport Layer Security (TLS) およびアクセス制御リスト (ACL) について説明します。 | |
Node.js | ここでは、実際のロールアウトシナリオをシミュレートするために設計されたサンプルアプリケーションのセットを使用して Istio の動的トラフィックルーティング機能を使用するケースを説明します。 |
1.8. Red Hat OpenShift Service Mesh の削除
1.8.1. Red Hat OpenShift Service Mesh の削除
以下のプロセスに従って、既存の OpenShift Container Platform インスタンスからサービスメッシュを削除します。クラスター管理者としてログインし、クラスターにアクセスできるホストからこれらのコマンドを実行します。
1.8.1.1. コントロールプレーンの削除
servicemeshcontrolplane
を削除すると、作成されたリソースのアンインストールを Service Mesh Operator に対してトリガーします。
servicemeshcontrolplane
の代わりに短い smcp
コマンドを使用できます。
以下のコマンドで、インストールされたカスタムリソースの名前を取得します。
oc get servicemeshcontrolplanes -n istio-system
<name_of_custom_resource>
を先のコマンドの出力に置き換え、以下のコマンドを実行してカスタムリソースを削除します。$ oc delete servicemeshcontrolplanes -n istio-system <name_of_custom_resource>
1.8.1.2. Operator の削除
Red Hat OpenShift Service Mesh を正常に削除するには、Operator を削除する必要があります。Red Hat OpenShift Service Mesh Operator を削除したら、Jaeger Operator および Kiali Operator を削除する必要があります。
1.8.1.2.1. Red Hat OpenShift Service Mesh Operator の削除
このコマンドを実行して、Red Hat OpenShift Service Mesh Operator を削除します。
$ oc delete -n istio-operator -f https://raw.githubusercontent.com/Maistra/istio-operator/maistra-0.12/deploy/servicemesh-operator.yaml
1.8.1.2.2. Jaeger Operator の削除
以下のコマンドを実行して Jaeger Operator を削除します。
$ oc delete -n observability -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/v1.13.1/deploy/operator.yaml $ oc delete -n observability -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/v1.13.1/deploy/role_binding.yaml $ oc delete -n observability -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/v1.13.1/deploy/role.yaml $ oc delete -n observability -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/v1.13.1/deploy/service_account.yaml $ oc delete -n observability -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/v1.13.1/deploy/crds/jaegertracing_v1_jaeger_crd.yaml
1.8.1.2.3. Kiali Operator の削除
以下のコマンドを実行して、Kiali Operator を削除します。
$ bash <(curl -L https://git.io/getLatestKialiOperator) --uninstall-mode true --operator-watch-namespace '**'
1.8.1.3. プロジェクトの削除
以下のコマンドを実行して
istio-system
プロジェクトを削除します。$ oc delete project istio-system
以下のコマンドを実行して
istio-operator
プロジェクトを削除します。$ oc delete project istio-operator
以下のコマンドを実行して
kiali-operator
プロジェクトを削除します。$ oc delete project kiali-operator
以下のコマンドを実行して
observability
プロジェクトを削除します。$ oc delete project observability
1.9. Red Hat OpenShift Service Mesh のアップグレード
1.9.1. Red Hat OpenShift Service Mesh のアップグレード
Red Hat OpenShift Service Mesh はテクノロジープレビュー機能ですが、アップグレードはありません。既存のサービスメッシュのインストール(たとえば、開発者プレビューをインストールしている場合)がある場合、Red Hat OpenShift Service Mesh の新規バージョンをインストールする前に、インストールを削除する 必要 があります。
1.10. 3scale Istio Adapter
3scale Istio アダプターを使用すると、Red Hat OpenShift Service Mesh 内で実行中のサービスにラベルを付け、そのサービスを 3scale API Management ソリューションと統合できます。
前提条件
- Red Hat OpenShift Service Mesh 0.12.0+
- 稼働している 3scale アカウント (SaaS または 3scale 2.5 On-Premises)
- Red Hat OpenShift Service Mesh の前提条件
- Mixer ポリシーの適用が有効になっていることを確認します。「Mixer ポリシー適用の更新」では、現在の Mixer ポリシーの適用ステータスをチェックし、ポリシーの適用を有効にする手順が説明されています。
3scale Istio アダプターを設定するには、アダプターパラメーターをカスタムリソースファイルに追加する手順について、サービスメッシュのインストールについて参照してください。
1.10.1. アダプターと Red Hat OpenShift Service Mesh の統合
これらの例を使用して、3scale Istio アダプターを使用してサービスに対する要求を設定できます。
kind: handler
リソースにとくに注意してください。3scale の認証情報と管理する API のサービス ID を使用して、これを更新する必要があります。
3scale 設定でハンドラー設定を変更します。
apiVersion: "config.istio.io/v1alpha2" kind: handler metadata: name: threescale spec: adapter: threescale params: service_id: "<SERVICE_ID>" system_url: "https://<organization>-admin.3scale.net/" access_token: "<ACCESS_TOKEN>" connection: address: "threescale-istio-adapter:3333"
- 3scale 設定でルール設定を変更します。
# rule to dispatch to handler threescalehandler apiVersion: "config.istio.io/v1alpha2" kind: rule metadata: name: threescale spec: match: destination.labels["service-mesh.3scale.net"] == "true" actions: - handler: threescale.handler instances: - threescale-authorization.instance
1.10.1.1. カスタムリソースの生成
アダプターには、handler
、instance
、および rule
カスタムリソースの生成を可能にするツールが含まれます。
表1.12 使用法
オプション | 説明 | 必須 | デフォルト値 |
---|---|---|---|
| 利用可能なオプションについてのヘルプ出力を生成します | No | |
| この URL の一意の名前、トークンのペア | Yes | |
| テンプレートを生成する namespace | No |
|
| 3scale アクセストークン | Yes | |
| 3scale 管理ポータル URL | Yes | |
| 3scale API/サービス ID | Yes | |
| 指定する 3scale 認証パターン (1=Api Key、2=App Id/App Key、3=OIDC) | No | ハイブリッド |
| 生成されたマニフェストを保存するファイル | No | 標準出力 |
| CLI バージョンを出力し、即座に終了する | No |
1.10.1.1.1. URL サンプルからのテンプレートの生成
この例では、トークンと URL のペアを 1 つのハンドラーとして複数のサービスで共有できるように汎用テンプレートを生成します。
$ 3scale-gen-config --name=admin-credentials --url="https://<organization>-admin.3scale.net:443" --token="[redacted]"
この例では、ハンドラーに埋め込まれたサービス ID を使用してテンプレートを生成します。
$ 3scale-gen-config --url="https://<organization>-admin.3scale.net" --name="my-unique-id" --service="123456789" --token="[redacted]"
1.10.1.2. デプロイされたアダプターからのマニフェストの生成
デプロイされたアダプターからこれらのマニフェストを生成するには、これが istio-system
namespace にデプロイされることを前提とし、以下を実行します。
$ export NS="istio-system" URL="https://<replaceme>-admin.3scale.net:443" NAME="name" TOKEN="token" oc exec -n ${NS} $(oc get po -n ${NS} -o jsonpath='{.items[?(@.metadata.labels.app=="3scale-istio-adapter")].metadata.name}') \ -it -- ./3scale-config-gen \ --url ${URL} --name ${NAME} --token ${TOKEN} -n ${NS}
これでターミナルにサンプル出力が生成されます。必要に応じて、これらのサンプルを編集し、oc create
コマンドを使用してオブジェクトを作成します。
要求がアダプターに到達すると、アダプターはサービスが 3scale の API にどのようにマッピングされるかを認識している必要があります。これは、以下の 2 つの方法のいずれかで提供できます。
- ワークロードのラベルとして実行 (推奨)
-
ハンドラーでの
service_id
としてのハードコーディング
必要なアノテーションでワークロードを更新します。
ハンドラーに埋め込まれていない場合は、以下の例に記載されているサービス ID のみを更新する必要があります。ハンドラーの設定が優先されます。
$ export CREDENTIALS_NAME="replace-me" export SERVICE_ID="replace-me" export DEPLOYMENT="replace-me" patch="$(oc get deployment "${DEPLOYMENT}" patch="$(oc get deployment "${DEPLOYMENT}" --template='{"spec":{"template":{"metadata":{"labels":{ {{ range $k,$v := .spec.template.metadata.labels }}"{{ $k }}":"{{ $v }}",{{ end }}"service-mesh.3scale.net/service-id":"'"${SERVICE_ID}"'","service-mesh.3scale.net/credentials":"'"${CREDENTIALS_NAME}"'"}}}}}' )" oc patch deployment "${DEPLOYMENT}" --patch ''"${patch}"''
1.10.1.3. アダプター経由でのサービストラフィックのルーティング
3scale アダプターを使用してサービスのトラフィックを駆動するには、kind: rule
リソースで、以前に設定で作成した destination.labels["service-mesh.3scale.net/credentials"] =="threescale"
ルールに一致させる必要があります。
サービスを統合するには、上記のラベルがターゲットワークロードのデプロイメントで PodTemplateSpec に追加される必要があります。値の threescale
は生成されたハンドラーの名前を参照します。このハンドラーは、3scale を呼び出すのに必要なアクセストークンを保存します。
以下のラベルをワークロードに追加して、要求時にサービス ID をインスタンス経由でアダプターに渡します。
destination.labels["service-mesh.3scale.net/service-id"] == "replace-me"
3scale の管理者は、必要な認証情報名とサービス ID の両方を提供できる必要があります。
1.10.2. 3scale での統合設定
3scale SaaS を使用している場合、Red Hat OpenShift Service Mesh は Early Access プログラムの一部として有効にされています。
1.10.2.1. 統合設定
- [your_API_name] > Integration > Configuration の順に移動します。
- Integration ページの上部で、右上隅の edit integration settings をクリックします。
- Service Mesh の見出しで、Istio オプションをクリックします。
- ページの下部までスクロールし、Update Service をクリックします。
1.10.3. キャッシング動作
3scale System API からの応答は、アダプター内でデフォルトでキャッシュされます。cacheTTLSeconds
値よりも古いと、エントリーはキャッシュから消去されます。また、デフォルトでキャッシュされたエントリーの自動更新は、cacheRefreshSeconds
値に基づいて、期限が切れる前に数秒間試行されます。cacheTTLSeconds
値よりも高い値を設定することで、自動更新を無効にできます。
cacheEntriesMax
を正の値以外に設定すると、キャッシングを完全に無効にできます。
更新プロセスを使用すると、到達不能になるホストのキャッシュされた値が、期限が切れて最終的に消去される前に再試行されます。
1.10.4. 認証要求
このテクノロジープレビューリリースは以下の認証方法をサポートします。
- 標準 API キー: 単一のランダム文字列またはハッシュが識別子およびシークレットトークンとして機能します。
- Application identifier and key pairs: イミュータブルな識別子とミュータブルなシークレットキー文字列。これは AppID と呼ばれています。
- OpenID authentication method: JSON Web トークンから解析されるクライアント ID 文字列。これは OpenID Connect (OIDC) と呼ばれています。
1.10.4.1. 認証パターンの適用
以下の認証方法の例に従って instance
カスタムリソースを変更し、認証動作を設定します。認証情報は、以下から受け取ることができます。
- 要求ヘッダー
- 要求パラメーター
- 要求ヘッダーとクエリーパラメーターの両方
ヘッダーの値を指定する場合、この値は小文字である必要があります。たとえば、ヘッダーを X-User-Key
として送信する場合は、これを設定で request.headers["x-user-key"]
として参照される必要があります。
1.10.4.1.1. API キー認証方法
サービスメッシュは、subject
カスタムリソースパラメーターの user
オプションで指定されたクエリーパラメーターと要求ヘッダーで API キーを検索します。これは、カスタムリソースファイルで指定される順序で値をチェックします。不要なオプションを省略することで、API キーの検索をクエリーパラメーターまたは要求ヘッダーに制限できます。
この例では、サービスメッシュは user_key
クエリーパラメーターの API キーを検索します。API キーがクエリーパラメーターにない場合、サービスメッシュは x-user-key
ヘッダーを確認します。
API キー認証方法の例
apiVersion: "config.istio.io/v1alpha2" kind: instance metadata: name: threescale-authorization namespace: istio-system spec: template: authorization params: subject: user: request.query_params["user_key"] | request.headers["x-user-key"] | "" action: path: request.url_path method: request.method | "get"
アダプターが異なるクエリーパラメーターまたは要求ヘッダーを検査するようにする場合は、名前を適宜変更します。たとえば、「key」というクエリーパラメーターの API キーを確認するには、request.query_params["user_key"]
を request.query_params["key"]
に変更します。
1.10.4.1.2. アプリケーション ID およびアプリケーションキーペアの認証方法
サービスメッシュは、subject
カスタムリソースパラメーターの properties
オプションで指定されるように、クエリーパラメーターと要求ヘッダーでアプリケーション ID とアプリケーションキーを検索します。アプリケーションキーはオプションです。これは、カスタムリソースファイルで指定される順序で値をチェックします。不要なオプションを含めないことで、認証情報の検索をクエリーパラメーターまたは要求ヘッダーのいずれかに制限できます。
この例では、サービスメッシュは最初にクエリーパラメーターのアプリケーション ID とアプリケーションキーを検索し、必要に応じて要求ヘッダーに移動します。
アプリケーション ID およびアプリケーションキーペアの認証方法の例
apiVersion: "config.istio.io/v1alpha2" kind: instance metadata: name: threescale-authorization namespace: istio-system spec: template: authorization params: subject: app_id: request.query_params["app_id"] | request.headers["x-app-id"] | "" app_key: request.query_params["app_key"] | request.headers["x-app-key"] | "" action: path: request.url_path method: request.method | "get"
アダプターが異なるクエリーパラメーターまたは要求ヘッダーを検査するようにする場合は、名前を適宜変更します。たとえば、identification
という名前のクエリーパラメーターのアプリケーション ID を確認するには、request.query_params["app_id"]
を request.query_params["identification"]
に変更します。
1.10.4.1.3. OpenID 認証方法
OpenID Connect (OIDC) 認証方法を使用するには、subject
フィールドで properties
値を使用して client_id
および任意で app_key
を設定します。
このオブジェクトは、前述の方法を使用して操作することができます。以下の設定例では、クライアント識別子 (アプリケーション ID) は、azp ラベルの JSON Web Token (JWT) から解析されます。これは必要に応じて変更できます。
OpenID 認証方法の例
apiVersion: "config.istio.io/v1alpha2" kind: instance metadata: name: threescale-authorization spec: template: threescale-authorization params: Subject: properties: app_key: request.query_params["app_key"] | request.headers["x-app-key"] | "" client_id: request.auth.claims["azp"] | "" action: path: request.url_path method: request.method | "get" service: destination.labels["service-mesh.3scale.net/service-id"] | ""
この統合を正常に機能させるには、クライアントがアイデンティティープロバイダー (IdP) で作成されるよう OIDC を 3scale で実行する必要があります。保護するサービスと同じ namespace でサービスのエンドユーザー認証を作成する必要があります。JWT は要求の Authorization
ヘッダーに渡されます。
以下で定義されるサンプル Policy
では、issuer
と jwksUri
を適宜置き換えます。
OpenID Policy の例
apiVersion: authentication.istio.io/v1alpha1 kind: Policy metadata: name: jwt-example namespace: bookinfo spec: origins: - jwt: issuer: >- http://keycloak-keycloak.34.242.107.254.nip.io/auth/realms/3scale-keycloak jwksUri: >- http://keycloak-keycloak.34.242.107.254.nip.io/auth/realms/3scale-keycloak/protocol/openid-connect/certs principalBinding: USE_ORIGIN targets: - name: productpage
1.10.4.1.4. ハイブリッド認証方法
特定の認証方法を適用せず、いずれかの方法の有効な認証情報を受け入れる方法を選択できます。API キーとアプリケーション ID/アプリケーションキーペアの両方が提供される場合、サービスメッシュは API キーを使用します。
この例では、サービスメッシュがクエリーパラメーターの API キーをチェックし、次に要求ヘッダーを確認します。API キーがない場合、クエリーパラメーターのアプリケーション ID とキーをチェックし、次に要求ヘッダーを確認します。
ハイブリッド認証方法の例
apiVersion: "config.istio.io/v1alpha2" kind: instance metadata: name: threescale-authorization spec: template: authorization params: subject: user: request.query_params["user_key"] | request.headers["x-user-key"] | properties: app_id: request.query_params["app_id"] | request.headers["x-app-id"] | "" app_key: request.query_params["app_key"] | request.headers["x-app-key"] | "" client_id: request.auth.claims["azp"] | "" action: path: request.url_path method: request.method | "get" service: destination.labels["service-mesh.3scale.net/service-id"] | ""
1.10.5. アダプターメトリクス
アダプターはデフォルトで、/metrics
エンドポイントのポート 8080
で公開されるさまざまな Prometheus メトリクスを報告します。これらのメトリクスから、アダプターと 3scale 間の対話方法についての洞察が提供されます。サービスには、自動的に検出され、Prometheus によって収集されるようにラベルが付けられます。