検索

第4章 Day Two

download PDF

4.1. Red Hat OpenShift Service Mesh へのアプリケーションのデプロイ

アプリケーションをサービスメッシュにデプロイする場合、Istio のアップストリームのコミュニティーバージョンのアプリケーションの動作と Red Hat OpenShift Service Mesh インストール内のアプリケーションの動作に違いがいくつかあります。

4.1.1. コントロールプレーンのテンプレートの作成

ServiceMeshControlPlane テンプレートを使用すると、再利用可能な設定を作成することができます。各ユーザーは、作成するテンプレートを独自の設定で拡張することができます。テンプレートは、他のテンプレートから設定情報を継承することもできます。たとえば、会計チーム用の会計コントロールプレーンとマーケティングチーム用のマーケティングコントロールプレーンを作成できます。開発テンプレートと本番テンプレートを作成する場合、マーケティングチームおよび会計チームのメンバーは、チーム固有のカスタマイズで開発および本番テンプレートを拡張することができます。

ServiceMeshControlPlane と同じ構文に従うコントロールプレーンのテンプレートを設定する場合、ユーザーは階層的に設定を継承します。Operator は、Red Hat OpenShift Service Mesh のデフォルト設定を使用する default テンプレートと共に提供されます。カスタムテンプレートを追加するには、openshift-operators プロジェクトで smcp-templates という名前の ConfigMap を作成し、/usr/local/share/istio-operator/templates で Operator コンテナーに ConfigMap をマウントする必要があります。

4.1.1.1. ConfigMap の作成

以下の手順に従って、ConfigMap を作成します。

前提条件

  • Service Mesh Operator がインストールされ、検証されていること。
  • cluster-admin ロールを持つアカウント。
  • Operator デプロイメントの場所。
  • oc として知られる OpenShift Container Platform コマンドラインインターフェース (CLI) へのアクセス。

手順

  1. クラスター管理者として OpenShift Container Platform CLI にログインします。
  2. CLI で以下のコマンドを実行し、openshift-operators プロジェクトに smcp-templates という名前の ConfigMap を作成し、<templates-directory> をローカルディスクの ServiceMeshControlPlane ファイルの場所に置き換えます。

    $ oc create configmap --from-file=<templates-directory> smcp-templates -n openshift-operators
  3. Operator ClusterServiceVersion 名を見つけます。

    $ oc get clusterserviceversion -n openshift-operators | grep 'Service Mesh'
    maistra.v1.0.0            Red Hat OpenShift Service Mesh   1.0.0                Succeeded
  4. Operator クラスターサービスバージョンを編集して、Operator に smcp-templates ConfigMap を使用するよう指示します。

    $ oc edit clusterserviceversion -n openshift-operators maistra.v1.0.0
  5. ボリュームマウントおよびボリュームを Operator デプロイメントに追加します。

    deployments:
      - name: istio-operator
        spec:
          template:
            spec:
              containers:
                volumeMounts:
                  - name: discovery-cache
                    mountPath: /home/istio-operator/.kube/cache/discovery
                  - name: smcp-templates
                    mountPath: /usr/local/share/istio-operator/templates/
              volumes:
                - name: discovery-cache
                  emptyDir:
                    medium: Memory
                - name: smcp-templates
                  configMap:
                    name: smcp-templates
    ...
  6. 変更を保存し、エディターを終了します。
  7. ServiceMeshControlPlanetemplate パラメーターを使用してテンプレートを指定できます。

      apiVersion: maistra.io/v1
      kind: ServiceMeshControlPlane
      metadata:
        name: minimal-install
      spec:
        template: default

4.1.2. Red Hat OpenShift Service Mesh のサイドカーコンテナー挿入

Red Hat OpenShift Service Mesh は、アプリケーションの Pod 内のプロキシーサイドカーコンテナーに依存して、アプリケーションにサービスメッシュ機能を提供します。自動のサイドカーコンテナー挿入を有効にしたり、手動で管理したりできます。Red Hat では、プロジェクトにラベルを付ける必要のない、アノテーションを使用した自動挿入を推奨しています。これにより、デプロイメント時に、アプリケーションにサービスメッシュの適切な設定が含まれるようになります。この方法で必要となる権限が少なく、ビルダー Pod などの他の OpenShift 機能と競合しません。

注記

プロジェクトにラベルを付けている場合、デフォルトで Istio のアップストリームバージョンはサイドカーコンテナーを挿入します。Red Hat OpenShift Service Mesh では、サイドカーコンテナーがデプロイメントに自動的に挿入されるようにオプトインすることが求められるため、プロジェクトにラベルを付ける必要はありません。これにより、(Pod のビルドまたはデプロイの場合など) 不要な場合にはサイドカーコンテナーを挿入しないようにできます。

Webhook はすべてのプロジェクトにデプロイする Pod の設定をチェックし、これらの Pod が適切なアノテーションで挿入をオプトインしているかどうかを確認します。

4.1.2.1. 自動のサイドカーコンテナー挿入の有効化

アプリケーションを Red Hat OpenShift Service Mesh にデプロイする場合は、sidecar.istio.io/inject アノテーションに値 "true" を指定して、挿入をオプトインする必要があります。オプトインにより、サイドカーコンテナーの挿入が OpenShift エコシステム内の複数のフレームワークが使用する、ビルダー Pod などの他の OpenShift 機能に干渉しないようにします。

前提条件

  • 自動のサイドカーコンテナー挿入を有効にするデプロイメントを特定します。
  • アプリケーションの YAML 設定ファイルを見つけます。

手順

  1. エディターでアプリケーションの設定 YAML ファイルを開きます。
  2. sidecar.istio.io/inject を、以下に示すように "true" の値が含まれる設定 YAML に追加します。

    スリープテストアプリケーションの例

    apiVersion: extensions/v1
    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. 設定ファイルを保存します。

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

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

前提条件

  • oc として知られる OpenShift Container Platform コマンドラインインターフェース (CLI) へのアクセス。

手順

  1. OpenShift Container Platform CLI にログインします。
  2. 以下のコマンドを実行して、現在の Mixer ポリシー適用のステータスを確認します。

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

    $ oc edit cm -n istio-system istio
  4. ConfigMap 内で disablePolicyChecks: true を見つけ、値を false に変更します。
  5. 設定を保存してエディターを終了します。
  6. Mixer ポリシー適用ステータスを再度チェックして、false に設定されていることを確認します。

4.1.4. 適切なネットワークポリシーの設定

サービスメッシュはコントロールプレーンおよびメンバー namespace にネットワークポリシーを作成し、それらの間のトラフィックをホワイトリスト化します。デプロイする前に、以下の条件を考慮し、OpenShift Container Platform ルートで以前に公開されたメッシュのサービスを確認します。

  • Istio が適切に機能するには、メッシュへのトラフィックが常に ingress-gateway を経由する必要があります。
  • メッシュ外のサービスは、メッシュにない個別の namespace にデプロイします。
  • サービスメッシュでリストされた namespace 内にデプロイする必要のあるメッシュ以外のサービスでは、それらのデプロイメント maistra.io/expose-route: "true" にラベルを付けます。これにより、これらのサービスへの OpenShift Container Platform ルートは依然として機能します。

次のステップ

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.