Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

Service Mesh のインストール

OpenShift Container Platform 3.11

OpenShift Container Platform 3.11 Service Mesh インストールガイド

Red Hat OpenShift Documentation Team

概要

OpenShift での 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 コマンドラインユーティリティーのバージョン (oc クライアントツール) をインストールし、これをパスに追加します。

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 インストール内の各ノードでこれらの変更を行います。

  1. /etc/sysctl.d/99-elasticsearch.conf という名前のファイルを以下の内容で作成します。

    vm.max_map_count = 262144
  2. 以下のコマンドを実行します。

    $ 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 イメージをプルします。

  1. 以下のコマンドを実行します。

    $ docker login registry.redhat.io
  2. これにより、ユーザー名とパスワードを求めるプロンプトが出されます。
  3. 正常にログインすると、~/.docker/config.json は以下の内容で作成されます。

    {
         "auths": {
             "registry.redhat.io": {
                 "auth": "XXXXXXXXXXXXXXXXXX"
             }
         }
    }
  4. 各ノードで /var/lib/origin/.docker ディレクトリーを作成します。
  5. 各ノードで /.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 をインストールする必要があります。

  1. クラスター管理者として OpenShift Container Platform にログインします。
  2. 以下のコマンドを実行して 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 をインストールする必要があります。

  1. クラスター管理者として OpenShift Container Platform にログインします。
  2. 以下のコマンドを実行して、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 をインストールする必要があります。

  1. クラスター管理者として OpenShift Container Platform にログインします。
  2. istio-operator および istio-system namespace が存在しない場合、これらのコマンドを実行して namespace を作成します。

    $ oc new-project istio-operator
    $ oc new-project istio-system
  3. 以下のコマンドを実行して、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 インストールの検証

  1. クラスター管理者として OpenShift Container Platform にログインします。
  2. 以下のコマンドを実行して、Operator が正常にインストールされていることを確認します。

    $ oc get pods -n istio-operator
  3. 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 が機能するようするには、disablePolicyChecksfalse である必要があります。

  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 グローバルパラメーター

パラメーター説明デフォルト値

disablePolicyChecks

このブール値は、ポリシーチェックを有効にするかどうかを示します。

true/false

true

policyCheckFailOpen

このブール値は、Mixer ポリシーサービスに到達できない場合にトラフィックを Envoy サイドカーコンテナーに通過させることができるかどうかを指定します。

true/false

false

tag

Operator が Istio イメージをプルするために使用するタグ。

有効なコンテナーイメージタグです。

0.12.0

Hub

Operator が Istio イメージをプルするために使用するハブ。

有効なイメージリポジトリーです。

maistra/ または registry.redhat.io/openshift-istio-tech-preview/

mTLS

これは、デフォルトでサービス間での Mutual Transport Layer Security (mTLS) を有効にするかどうかを制御します。

true/false

false

imagePullSecret

Istio イメージを提供するレジストリーへのアクセスがセキュアな場合、ここに imagePullSecret を一覧表示します。

redhat-registry-pullsecret または quay-pullsecret

なし

表1.2 プロキシーパラメーター

タイプパラメーター説明デフォルト値

リソース

cpu

Envoy プロキシーに要求される CPU リソースのパーセンテージ。

ご使用の環境設定に基づく、ミリコア単位の CPU リソース。

100m

 

memory

Envoy プロキシー用に要求されるメモリー量。

ご使用の環境設定に基づく、利用可能なメモリー (バイト単位)。

128Mi

制限

cpu

Envoy プロキシー用に要求される CPU リソースの最大パーセンテージ。

ご使用の環境設定に基づく、ミリコア単位の CPU リソース。

2000m

 

memory

使用が許可されているメモリー Envoy プロキシーの最大量。

ご使用の環境設定に基づく、利用可能なメモリー (バイト単位)。

128Mi

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_enabledfalse に設定します。

  gateways:
       istio-egressgateway:
         autoscaleEnabled: false
         autoscaleMin: 1
         autoscaleMax: 5
       istio-ingressgateway:
         autoscaleEnabled: false
         autoscaleMin: 1
         autoscaleMax: 5
         ior_enabled: false

表1.4 Istio ゲートウェイパラメーター

タイプパラメーター説明デフォルト値

istio-egressgateway

autoscaleEnabled

このパラメーターは、自動スケーリングを有効にします。

true/false

true

 

autoscaleMin

autoscaleEnabled 設定に基づいて egress ゲートウェイにデプロイする Pod の最小数。

ご使用の環境設定に基づく、有効な割り当て可能な Pod 数。

1

 

autoscaleMax

autoscaleEnabled 設定に基づいて egress ゲートウェイにデプロイする Pod の最大数。

ご使用の環境設定に基づく、有効な割り当て可能な Pod 数。

5

istio-ingressgateway

autoscaleEnabled

このパラメーターは、自動スケーリングを有効にします。

true/false

true

 

autoscaleMin

autoscaleEnabled 設定に基づいて ingress ゲートウェイにデプロイする Pod の最小数。

ご使用の環境設定に基づく、有効な割り当て可能な Pod 数。

1

 

autoscaleMax

autoscaleEnabled 設定に基づいて ingress ゲートウェイにデプロイする Pod の最大数。

ご使用の環境設定に基づく、有効な割り当て可能な Pod 数。

5

 

ior_enabled

このパラメーターは、Istio ルートが OpenShift に自動的に設定されるかどうかを制御します。

true/false

true

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 ポリシーパラメーター

パラメーター説明デフォルト値

enabled

これにより Mixer が有効にされます。

true/false

true

autoscaleEnabled

これは、自動スケーリングを有効にするかどうかを制御します。小規模な環境では、このパラメーターを無効にします。

true/false

true

autoscaleMin

autoscaleEnabled 設定に基づいてデプロイする Pod の最小数。

ご使用の環境設定に基づく、有効な割り当て可能な Pod 数。

1

autoscaleMax

autoscaleEnabled 設定に基づいてデプロイする Pod の最大数。

ご使用の環境設定に基づく、有効な割り当て可能な Pod 数。

5

表1.6 Istio Mixer Telemetry パラメーター

タイプパラメーター説明デフォルト値

リソース

cpu

Mixer Telemetry に要求される CPU リソースのパーセンテージ。

ご使用の環境設定に基づく、ミリコア単位の CPU リソース。

1000m

 

memory

Mixer Telemetry に要求されるメモリー量。

ご使用の環境設定に基づく、利用可能なメモリー (バイト単位)。

1G

制限

cpu

Mixer Telemetry の使用が許可された CPU リソースの最大パーセンテージ。

ご使用の環境設定に基づく、ミリコア単位の CPU リソース。

4800m

 

memory

Mixer Telemetry の使用が許可されたメモリーの最大量。

ご使用の環境設定に基づく、利用可能なメモリー (バイト単位)。

4G

1.3.1.4.5. Istio Pilot の例
  pilot:
    resources:
      requests:
        cpu: 100m
     autoscaleEnabled: false
     traceSampling: 100.0

表1.7 Istio Pilot パラメーター

パラメーター説明デフォルト値

cpu

Pilot に要求される CPU リソースのパーセンテージ。

ご使用の環境設定に基づく、ミリコア単位の CPU リソース。

500m

memory

Pilot に要求されるメモリー量。

ご使用の環境設定に基づく、利用可能なメモリー (バイト単位)。

2048Mi

traceSampling

この値は、無作為のサンプリングの発生頻度を制御します。注: 開発またはテストの場合はこの値を増やします。

有効な数字

1.0

1.3.1.4.6. トレーシングおよび Jaeger の例
  tracing:
      enabled: false
      jaeger:
        tag: 1.13.1
        template: all-in-one
        agentStrategy: DaemonSet

表1.8 トレーシングおよび Jaeger パラメーター

パラメーター説明デフォルト値

enabled

これにより、環境でのトレーシングが可能となります。

true/false

true

Hub

Operator が Jaeger イメージをプルするために使用するハブ。

有効なイメージリポジトリーです。

jaegertracing/ または registry.redhat.io/openshift-istio-tech-preview/

tag

Operator が Jaeger イメージをプルするために使用するタグ。

有効なコンテナーイメージタグです。

1.13.1

template

Jaeger に使用するデプロイメントテンプレート

テンプレートタイプの名前

all-in-one / production-elasticsearch

agentStrategy

Jaeger エージェントを各コンピュートノードにデプロイします。

DaemonSet (必要な場合)

なし

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 パラメーター

パラメーター説明デフォルト値

enabled

これにより、サービスメッシュで Kiali を有効または無効にできます。Kiali はデフォルトでインストールされます。Kiali をインストールする必要がない場合は、enabled の値を false に変更します。

true/false

true

Hub

Operator が Kiali イメージをプルするために使用するハブ。

有効なイメージリポジトリーです。

kiali/ または registry.redhat.io/openshift-istio-tech-preview/

tag

Operator が Istio イメージをプルするために使用するタグ。

有効なコンテナーイメージタグです。

1.0.0

user

Kiali コンソールにアクセスするためのユーザー名。注: これは OpenShift アカウントとは関連しません。

有効な Kiali ダッシュボードユーザー名

なし

passphrase

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 パラメーター

パラメーター説明デフォルト

enabled

3scale アダプターを使用するかどうか

true/false

false

PARAM_THREESCALE_LISTEN_ADDR

gRPC サーバーのリッスンアドレスを設定します。

有効なポート番号

3333

PARAM_THREESCALE_LOG_LEVEL

ログ出力の最小レベルを設定します。

debuginfowarnerror、または none

info

PARAM_THREESCALE_LOG_JSON

ログが JSON としてフォーマットされるかどうかを制御します。

true/false

true

PARAM_THREESCALE_LOG_GRPC

ログに gRPC 情報を含むかどうかを制御します。

true/false

false

PARAM_THREESCALE_REPORT_METRICS

3scale システムおよびバックエンドメトリクスが収集され、Prometheus に報告されるかどうかを制御します。

true/false

true

PARAM_THREESCALE_METRICS_PORT

3scale /metrics エンドポイントをスクラップできるポートを設定します。

有効なポート番号

8080

PARAM_THREESCALE_CACHE_TTL_SECONDS

キャッシュから期限切れのアイテムを消去するまで待機する時間 (秒単位)。

時間 (秒単位)

300

PARAM_THREESCALE_CACHE_REFRESH_SECONDS

キャッシュ要素の更新を試行する場合の期限

時間 (秒単位)

180

PARAM_THREESCALE_CACHE_ENTRIES_MAX

キャッシュにいつでも保存できるアイテムの最大数。キャッシュを無効にするには 0 に設定します。

有効な数字

1000

PARAM_THREESCALE_CACHE_REFRESH_RETRIES

キャッシュ更新ループ時に到達できないホストが再試行される回数

有効な数字

1

PARAM_THREESCALE_ALLOW_INSECURE_CONN

3scale API 呼び出し時の証明書の検証を省略できるようにします。この有効化は推奨されていません。

true/false

false

PARAM_THREESCALE_CLIENT_TIMEOUT_SECONDS

3scale システムおよびバックエンドへの要求を終了するまで待機する秒数を設定します。

時間 (秒単位)

10

PARAM_THREESCALE_GRPC_CONN_MAX_SECONDS

接続を閉じるまでの最大秒数 (+/-10% のジッター) を設定します。

時間 (秒単位)

60

1.3.1.5. マルチテナントインストールの設定

サービスメッシュインスタンスをインストールおよび設定する方法については、「マルチテナント Red Hat OpenShift Service Mesh のインストール」の章を参照してください。

1.3.1.6. Mixer ポリシー適用の更新

以前のバージョンの Red Hat OpenShift Service Mesh では、Mixer のポリシーの適用がデフォルトで有効にされていました。Mixer ポリシーの適用はデフォルトで無効になりました。ポリシータスクを実行する前にこれを有効にする必要があります。

  1. 以下のコマンドを実行して、現在の Mixer ポリシー適用のステータスを確認します。

    $ oc get cm -n istio-system istio -o jsonpath='{.data.mesh}' | grep disablePolicyChecks
  2. disablePolicyChecks: true の場合、Service Mesh ConfigMap を編集します。

    $ oc edit cm -n istio-system istio
  3. ConfigMap 内で disablePolicyChecks: true を見つけ、値を false に変更します。
  4. 設定を保存してエディターを終了します。
  5. 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

作成したカスタムリソース定義ファイルを使用してサービスメッシュコントロールプレーンをデプロイします。

  1. istio-installation.yaml という名前のカスタムリソース定義ファイルを作成します。
  2. 以下のコマンドを実行してコントロールプレーンをデプロイします。

    $ oc create -n istio-system -f istio-installation.yaml
  3. 以下のコマンドを実行して、インストールプロセス時に 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 インストールに関する既知の問題

警告

現在、自動ルート作成はマルチテナントのサービスメッシュインストールと互換性がありません。マルチテナントインストールを試行する予定がある場合には、ServiceMeshControlPlaneior_enabledfalse に設定して無効にされていることを確認します。

  • 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 をサービスメッシュに統合する例です。

  1. ServiceMeshControlPlane カスタムリソースと同じ namespace に ServiceMeshMemberRoll という名前のカスタムリソースファイルを作成します。
  2. リソースに default という名前を付けます。
  3. 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です。

  1. 以下のコマンドを実行して、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>)
  2. コントロールプレーンをデプロイしたら、以下のコマンドを実行して Pod のステータスを確認します。

    $ oc get pods -n istio-system
  3. 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 へのアクセスが付与されるようにする必要があります。

  1. SCC の変更を必要とするサービスアカウントを特定します。

    注記

    <service account> および <namespace> をアプリケーション固有の値に置き換えます。

  2. 関連するサイドカーコンテナーに anyuid SCC を必要とするそれぞれのサービスアカウントについて、このコマンドを実行します。

    $ oc adm policy add-scc-to-user anyuid -z <service account> -n <namespace>
  3. 特権付き 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 インストール内の各マスターで以下の変更を加えます。

  1. マスター設定ファイルを含むディレクトリーに移動します(例: /etc/origin/master/master-config.yaml)。
  2. 以下の内容を含む 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
  3. 同じディレクトリーで以下のコマンドを実行し、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 機能に干渉しないようにします。

  1. エディターでアプリケーションの設定 yaml ファイルを開きます。
  2. 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

  3. 設定ファイルを保存します。
1.6.1.2.2. サイドカーコンテナーの手動挿入

サイドカーコンテナーの手動挿入は、アップストリームの istioctl コマンドを使用してサポートされます。

注記

サイドカーを手動で挿入する場合は、istio-system namespace 内の istio-sidecar-injector configmap から正しい設定を取得できるように、実行中のクラスターへのアクセスがあることを確認します。

実行可能ファイルを取得し、手動挿入でアプリケーションをデプロイするには、以下を行います。

  1. OS に適した インストール をダウンロードします。
  2. istioctl バイナリーをパス内の bin ディレクトリーに追加します。
  3. 以下のコマンドを実行してサイドカーをアプリケーションに挿入し、設定を 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 マイクロサービスは、detailsreviews マイクロサービスを呼び出して、ページを設定します。
  • 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 ファイルのバージョンを使用します。

  1. Bookinfo アプリケーションのプロジェクトを作成します。

    $ oc new-project myproject
  2. 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
  3. bookinfo.yaml ファイルを適用して Bookinfo アプリケーションを "myproject" namespace でデプロイします。

    $ oc apply -n myproject -f https://raw.githubusercontent.com/Maistra/bookinfo/master/bookinfo.yaml
  4. bookinfo-gateway.yaml ファイルを適用して Bookinfo の ingress ゲートウェイを作成します。

      $ oc apply -n myproject -f https://raw.githubusercontent.com/Maistra/bookinfo/master/bookinfo-gateway.yaml
  5. 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. デフォルトの宛先ルールの追加

  1. 相互 TLS を有効にしていない場合:

    $ oc apply -n myproject -f https://raw.githubusercontent.com/istio/istio/release-1.1/samples/bookinfo/networking/destination-rule-all.yaml
  2. 相互 TLS を有効にしている場合:

    oc apply -n myproject -f https://raw.githubusercontent.com/istio/istio/release-1.1/samples/bookinfo/networking/destination-rule-all-mtls.yaml
  3. 利用可能な宛先ルールを一覧表示するには、以下のコマンドを実行します。

    $ oc get destinationrules -o yaml

1.7.1.4. Bookinfo アプリケーションの削除

Bookinfo アプリケーションで終了したら、クリーンアップスクリプトを実行して削除することができます。

ヒント

本書の他のチュートリアルでも Bookinfo アプリケーションを使用しています。他のチュートリアルを継続して使用する場合は、クリーンアップスクリプトを実行しないでください。

  1. クリーンアップスクリプトをダウンロードします。

    $ curl -o cleanup.sh https://raw.githubusercontent.com/Maistra/bookinfo/master/cleanup.sh && chmod +x ./cleanup.sh
  2. クリーンアップスクリプトを実行して Bookinfo 仮想サービス、ゲートウェイを削除し、Pod を終了します。

    $ ./cleanup.sh
    namespace ? [default] myproject
  3. 以下のコマンドを実行してシャットダウンを確認します。

    $ 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. トレースの生成とトレースデータの分析

  1. Bookinfo アプリケーションをデプロイした後に、http://$GATEWAY_URL/productpage にアクセスし、ページを数回更新して一部のアクティビティーを生成します。
  2. Jaeger ダッシュボードにアクセスするためのルートはすでに存在します。ルートの詳細についてクエリーします。

    $ export JAEGER_URL=$(oc get route -n istio-system jaeger-query -o jsonpath='{.spec.host}')
  3. ブラウザーを起動して、https://${JAEGER_URL} に移動します。
  4. Jaeger ダッシュボードの左側のペインで、サービスメニューから「productpage」を選択し、ペイン下部の Find Traces ボタンをクリックします。以下のイメージに示されているように、トレースの一覧が表示されます。

    jaeger main screen
  5. 一覧のトレースのいずれかをクリックし、そのトレースの詳細ビューを開きます。最上部 (最新の) トレースをクリックすると、'/productpage の最終更新に対応する詳細が表示されます。

    jaeger spans

    先の図のトレースは、一部のネストされたスパンで構成されており、各スパンは 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. メトリクスのクエリー

  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
  2. Bookinfo アプリケーションにアクセスしてネットワークトラフィックを生成します。

    $ curl -o /dev/null http://$GATEWAY_URL/productpage
  3. Prometheus ユーザーインターフェースにアクセスするためのルートはすでに存在しています。ルートの詳細についてクエリーします。

    $ export PROMETHEUS_URL=$(oc get route -n istio-system prometheus -o jsonpath='{.spec.host}')
  4. ブラウザーを起動し、http://${PROMETHEUS_URL} に移動します。以下の図のように Prometheus ホーム画面が表示されます。

    prometheus home screen
  5. Expression フィールドに istio_request_duration_seconds_countを入力し、Execute ボタンをクリックします。以下の図と同様の画面が表示されます。

    prometheus metrics
  6. セレクターを使用してクエリーを絞り込むことができます。たとえば、istio_request_duration_seconds_count{destination_workload="reviews-v2"} は一致する destination_workload ラベルのあるカウンターのみを表示します。クエリーの使用についての詳細は、Prometheus のドキュメントを参照してください。
  7. 利用可能なすべての 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_totalistio_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 コンソールへのアクセス

  1. 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
  2. ブラウザーを起動し、https://${KIALI_URL} (上記の出力では kiali-istio-system.127.0.0.1.nip.io) に移動します。Kiali コンソールのログイン画面が表示されるはずです。
  3. インストール時にカスタムリソースファイルに指定したユーザー名およびパスワードを使用して、Kiali コンソールにログインします。

1.7.4.2. 概要ページ

初回ログイン時には概要 (Overview) ページが表示されます。ここでは、サービスメッシュに含まれるさまざまな namespace の健全性についての概要を確認できます。アプリケーション、ワークロード、またはサービスの正常性を表示できます。

概要ページ

1.7.4.3. グラフページ

グラフページには、要求によってつながれるマイクロサービスのグラフが表示されます。このページでは、アプリケーション、ワークロード、またはサービスが相互に対話する方法を確認することができます。

  1. 左側のナビゲーションにあるグラフをクリックします。

    Kiali グラフ

  2. 必要に応じて、Namespace メニューから bookinfo を選択します。グラフは Bookinfo アプリケーション内のアプリケーションを表示します。
  3. Namespace メニューの疑問符 (?) をクリックすると、Graph ヘルプツアーを利用できます。
  4. Done をクリックして、ヘルプツアーを閉じます。
  5. 左下隅の Legend をクリックします。Kiali は、グラフの凡例を表示します。

    Kiali の Legend

  6. グラフの凡例を閉じます。
  7. productpage ノードにカーソルを合わせます。グラフは、ノードからの送受信トラフィックのみをハイライトすることに注意してください。
  8. productpage ノードをクリックします。ページの右側の詳細が変更され、productpage の詳細が表示されます。

1.7.4.4. アプリケーションページ

アプリケーションページでは、アプリケーション、それらの健全性、その他の詳細情報を検索し、表示できます。

  1. 左側のナビゲーションにある Applications をクリックします。
  2. 必要に応じて、Namespace メニューから bookinfo を選択します。このページには、選択した namespace のアプリケーションとその健全性が表示されます。
  3. その他の健全性の詳細情報を表示するには、健全性 (Health) アイコンにカーソルを合わせます。
  4. reviews サービスをクリックし、そのアプリケーションの詳細を表示します。

    Kiali アプリケーションの詳細

  5. アプリケーションの詳細ページでは、より詳細な健全性情報を表示でき、reviews サービスの 3 つのバージョンについてさらに詳しく見ることができます。
  6. アプリケーションの詳細ページからタブをクリックして、アプリケーションのトラフィックおよびインバウンドとアウトバウンドのメトリクスを表示することもできます。

1.7.4.5. ワークロードページ

ワークロードページでは、ワークロード、それらの健全性、その他の詳細情報を検索し、表示できます。

  1. 左側のナビゲーションにある Workloads をクリックします。
  2. 必要に応じて、Namespace メニューから bookinfo を選択します。このページでは、選択した namespace のワークロード、それらの健全性およびラベルが表示されます。
  3. reviews-v1 ワークロードをクリックし、ワークロードの詳細を表示します。
  4. ワークロードの詳細ページで、ワークロードに関連付けられた Pod とサービスの概要を表示できます。

    Kiali ワークロードの詳細

  5. ワークロードの詳細ページから、タブをクリックしてワークロードのトラフィック、ログ、およびインバウンドおよびアウトバウンドメトリクスを表示することもできます。

1.7.4.6. サービスページ

サービスページでは、サービス、それらの健全性、その他の詳細情報を検索し、表示できます。

  1. 左側のナビゲーションにある Services をクリックします。
  2. 必要に応じて、Namespace メニューから bookinfo を選択します。このページには、選択した namespace で実行されているすべてのサービスの一覧と、ヘルスステータスなどのそのサービスに関する追加情報が表示されます。
  3. サービスに関する健全性の情報を表示するには、いずれかのサービスのヘルスアイコンにカーソルを合わせます。サービスは、オンラインの状態で要求に応答し、エラーがない場合に、正常であるとみなされます。
  4. Reviews サービスをクリックして、詳細情報を表示します。このサービスには 3 つの異なるバージョンがあることに注意してください。

    Kiali サービスの詳細

  5. サービスの詳細ページで、ワークロード、仮想サービス、サービスに関連付けられた宛先ルールの概要を表示できます。
  6. サービスの詳細ページからは、タブをクリックしてサービスのトラフィック、インバウンドメトリクスおよびトレースを表示することもできます。
  7. Actions メニューをクリックします。ここから、以下の操作を実行できます。

    • 重み付けされたルーティングの作成
    • 一致するルーティングの作成
    • トラフィックの一時停止
    • すべてのトラフィックルーティングの削除
  8. サービスの名前を 1 つクリックして、そのサービスの特定バージョンに関する追加情報を表示します。

1.7.4.7. Istio 設定ページ

Istio 設定ページでは、サーキットブレーカー、宛先ルール、フォールト挿入、ゲートウェイ、ルート、ルートルール、仮想サービスなど、現在サービスメッシュに対して実行されているすべての設定を表示できます。

  1. 左側のナビゲーションにある Istio Config をクリックします。
  2. 必要に応じて、Namespace メニューから bookinfo を選択します。このページには、選択した namespace で実行されている設定の一覧と検証のステータスが表示されます。

    Istio 設定

  3. 設定ファイルに関する追加情報を表示するには、以下のいずれかの設定をクリックします。

    Istio 設定 YAML

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 ダッシュボードへのアクセス

  1. Grafana ダッシュボードにアクセスするためのルートがすでに存在しています。ルートの詳細についてクエリーします。

      $ export GRAFANA_URL=$(oc get route -n istio-system grafana -o jsonpath='{.spec.host}')
  2. ブラウザーを起動して、http://${GRAFANA_URL} に移動します。以下の図が示すように、Grafana のホーム画面が表示されます。

    grafana home screen
  3. 左上隅のメニューから、Istio Mesh Dashboard を選択し、 Istio メッシュメトリクスを表示します。

    grafana mesh no traffic
  4. Bookinfo アプリケーションにアクセスして一部のトラフィックを生成します。

    $ curl -o /dev/null http://$GATEWAY_URL/productpage

    Dashboard は以下のようなメッシュを使用したトラフィックを反映します。

    grafana mesh with traffic
  5. サービスの詳細なメトリクスを表示するには、Service 列でサービス名をクリックします。サービスダッシュボードは以下の図のようになります。

    grafana services

    Bookinfo が http ベースのサービスのみを使用するので、TCP Bandwidth メトリクスは空であることに注意してください。また、ダッシュボードは、クライアントワークロードサービスを呼び出すワークロード、およびサービスワークロードからの要求を処理するワークロードについてのメトリクスを表示します。ダッシュボードの上部でメニューを使用して、別のサービスに切り替えるか、またはクライアントおよびサービスワークロードでメトリクスをフィルターできます。

  6. ワークロードダッシュボードに切り替えるには、左上隅にあるメニューで Istio Workload Dashboard をクリックします。以下の図のような画面が表示されます。

    grafana workloads

    このダッシュボードには、ワークロードのメトリクスとクライアント (インバウンド) およびサービス (アウトバウンド) ワークロードについてのメトリクスが表示されます。別のワークロードに切り替えることができます。インバウンドまたはアウトバウンドのワークロードでメトリクスをフィルターするには、ダッシュボードの上部にあるメニューを使用します。

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 ミッション

ここでは、Istio を使用して Circuit Breaker アーキテクチャーパターンを実装する方法を取り上げます。

Springboot

Istio Distributed Tracing ミッション

このシナリオでは、Jaeger の分散トレース機能およびサービスメッシュで適切にインストルメント化されたマイクロサービスの対話について取り上げます。

Springboot

セキュリティーのミッション

ここでは、サービスへのアクセスに関する Istio セキュリティーの概念が、アプリケーションによって個別に制御されるのではなく、プラットフォームによって制御されるケースを説明します。

Springboot

ルーティングのミッション

ここでは、実際のロールアウトシナリオをシミュレートするために設計されたサンプルアプリケーションのセットを使用して Istio の動的トラフィックルーティング機能を使用するケースを説明します。

Thorntail (A.K.A.Wildfly Swarm)

Istio Circuit Breaker ミッション

ここでは、Istio を使用して Circuit Breaker アーキテクチャーパターンを実装する方法を取り上げます。

Thorntail

Istio Distributed Tracing ミッション

このシナリオでは、Jaeger の分散トレース機能およびサービスメッシュで適切にインストルメント化されたマイクロサービスの対話について取り上げます。

Thorntail

セキュリティーのミッション

ここでは、サービスへのアクセスに関する Istio セキュリティーの概念が、アプリケーションによって個別に制御されるのではなく、プラットフォームによって制御されるケースを説明します。

Thorntail

ルーティングのミッション

ここでは、実際のロールアウトシナリオをシミュレートするために設計されたサンプルアプリケーションのセットを使用して Istio の動的トラフィックルーティング機能を使用するケースを説明します。

Vert.x

Istio Circuit Breaker ミッション

ここでは、Istio を使用して (最小限に) インストルメント化された Eclipse Vert.x マイクロサービスで Circuit Breaker を実装する方法を説明します。

Vert.x

Istio Distributed Tracing ミッション

このシナリオでは、Jaeger の分散トレース機能と(最小限に)インストルメント化された Eclipse Vert.x アプリケーションのセットの対話について取り上げます。

Vert.x

セキュリティーのミッション

このシナリオでは、Eclipse Vert.x アプリケーションのセットを使用した Istio Transport Layer Security(TLS) およびアクセス制御リスト (ACL) について説明します。

Vert.x

ルーティングのミッション

ここでは、最小限のサンプルアプリケーションのセットを使って Istio の動的トラフィックルーティング機能を使用するケースを取り上げます。

Node.js

Istio Circuit Breaker ミッション

ここでは、Istio を使用して Node.js アプリケーションで Circuit Breaker アーキテクチャーのパターンを実装する方法について説明します。

Node.js

Istio Distributed Tracing のミッション

このシナリオでは、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 コマンドを使用できます。

  1. 以下のコマンドで、インストールされたカスタムリソースの名前を取得します。

    oc get servicemeshcontrolplanes -n istio-system
  2. <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. プロジェクトの削除

  1. 以下のコマンドを実行して istio-system プロジェクトを削除します。

    $ oc delete project istio-system
  2. 以下のコマンドを実行して istio-operator プロジェクトを削除します。

    $ oc delete project istio-operator
  3. 以下のコマンドを実行して kiali-operator プロジェクトを削除します。

    $ oc delete project kiali-operator
  4. 以下のコマンドを実行して 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 ソリューションと統合できます。

前提条件

注記

3scale Istio アダプターを設定するには、アダプターパラメーターをカスタムリソースファイルに追加する手順について、サービスメッシュのインストールについて参照してください。

1.10.1. アダプターと Red Hat OpenShift Service Mesh の統合

これらの例を使用して、3scale Istio アダプターを使用してサービスに対する要求を設定できます。

注記

kind: handler リソースにとくに注意してください。3scale の認証情報と管理する API のサービス ID を使用して、これを更新する必要があります。

  1. 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"
  2. 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. カスタムリソースの生成

アダプターには、handlerinstance、および rule カスタムリソースの生成を可能にするツールが含まれます。

表1.12 使用法

オプション説明必須デフォルト値

-h, --help

利用可能なオプションについてのヘルプ出力を生成します

No

 

--name

この URL の一意の名前、トークンのペア

Yes

 

-n --namespace

テンプレートを生成する namespace

No

istio-system

-t, --token

3scale アクセストークン

Yes

 

-u, --url

3scale 管理ポータル URL

Yes

 

-s, --service

3scale API/サービス ID

Yes

 

--auth

指定する 3scale 認証パターン (1=Api Key、2=App Id/App Key、3=OIDC)

No

ハイブリッド

-o, --output

生成されたマニフェストを保存するファイル

No

標準出力

-v

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. 統合設定

  1. [your_API_name] > Integration > Configuration の順に移動します。
  2. Integration ページの上部で、右上隅の edit integration settings をクリックします。
  3. Service Mesh の見出しで、Istio オプションをクリックします。
  4. ページの下部までスクロールし、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 では、issuerjwksUri を適宜置き換えます。

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 によって収集されるようにラベルが付けられます。

法律上の通知

Copyright © 2017 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA").An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/.In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.Modified versions must remove all Red Hat trademarks.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.Licensed under the Apache License 2.0.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent.Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission.We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.