4.3. ログストアの設定

Red Hat OpenShift のロギングサブシステムは、Elasticsearch 6 (ES) を使用してログデータを保存および整理します。

ログストアに加えることのできる変更には、以下が含まれます。

  • Elasticsearch クラスターのストレージ。
  • シャードをクラスター内の複数のデータノードにレプリケートする方法 (完全なレプリケーションからレプリケーションなしまで)。
  • Elasticsearch データへの外部アクセス

Elasticsearch はメモリー集約型アプリケーションです。それぞれの Elasticsearch ノードには、ClusterLogging カスタムリソースで指定しない限り、メモリー要求および制限の両方に 16G 以上のメモリーが必要です。初期設定の OpenShift Container Platform ノードのセットは、Elasticsearch クラスターをサポートするのに十分な大きさではない場合があります。その場合、推奨されるサイズ以上のメモリー (各 Elasticsearch ノードに最大 64G) を使用して実行できるようにノードを OpenShift Container Platform クラスターに追加する必要があります。

各 Elasticsearch ノードはこれより低い値のメモリー設定でも動作しますが、これは実稼働環境には推奨されません。

4.3.1. 監査ログのログストアへの転送

デフォルトで、OpenShift Logging では監査ログを内部の OpenShift Container Platform Elasticsearch ログストアに保存しません。Kibana で表示するなど、監査ログをこのログストアに送信できます。

監査ログをデフォルトの内部 Elasticsearch ログストアに送信するには、Kibana で監査ログを表示するなど、ログ転送 API を使用する必要があります。

重要

内部 OpenShift Container Platform Elasticsearch ログストアは、監査ログのセキュアなストレージを提供しません。監査ログを転送するシステムが組織および政府の規制に適合し、適切にセキュリティーが保護されていることを確認します。Red Hat OpenShift のロギングサブシステムは、これらの規制に準拠していません。

手順

ログ転送 API を使用して監査ログを内部 Elasticsearch インスタンスに転送するには、以下を実行します。

  1. ClusterLogForwarder CR オブジェクトを定義する YAML ファイルを作成または編集します。

    • すべてのログタイプを内部 Elasticsearch インスタンスに送信するために CR を作成します。変更せずに以下の例を使用できます。

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogForwarder
      metadata:
        name: instance
        namespace: openshift-logging
      spec:
        pipelines: 1
        - name: all-to-default
          inputRefs:
          - infrastructure
          - application
          - audit
          outputRefs:
          - default
      1
      パイプラインは、指定された出力を使用して転送するログのタイプを定義します。デフォルトの出力は、ログを内部 Elasticsearch インスタンスに転送します。
      注記

      パイプラインの 3 つのすべてのタイプのログをパイプラインに指定する必要があります (アプリケーション、インフラストラクチャー、および監査)。ログの種類を指定しない場合、それらのログは保存されず、失われます。

    • 既存の ClusterLogForwarder CR がある場合、パイプラインを監査ログのデフォルト出力に追加します。デフォルトの出力を定義する必要はありません。以下に例を示します。

      apiVersion: "logging.openshift.io/v1"
      kind: ClusterLogForwarder
      metadata:
        name: instance
        namespace: openshift-logging
      spec:
        outputs:
         - name: elasticsearch-insecure
           type: "elasticsearch"
           url: http://elasticsearch-insecure.messaging.svc.cluster.local
           insecure: true
         - name: elasticsearch-secure
           type: "elasticsearch"
           url: https://elasticsearch-secure.messaging.svc.cluster.local
           secret:
             name: es-audit
         - name: secureforward-offcluster
           type: "fluentdForward"
           url: https://secureforward.offcluster.com:24224
           secret:
             name: secureforward
        pipelines:
         - name: container-logs
           inputRefs:
           - application
           outputRefs:
           - secureforward-offcluster
         - name: infra-logs
           inputRefs:
           - infrastructure
           outputRefs:
           - elasticsearch-insecure
         - name: audit-logs
           inputRefs:
           - audit
           outputRefs:
           - elasticsearch-secure
           - default 1
      1
      このパイプラインは、外部インスタンスに加えて監査ログを内部 Elasticsearch インスタンスに送信します。

関連情報

4.3.2. ログ保持時間の設定

デフォルトの Elasticsearch ログストアがインフラストラクチャーログ、アプリケーションログ、監査ログなどの 3 つのログソースのインデックスを保持する期間を指定する 保持ポリシー を設定できます。

保持ポリシーを設定するには、ClusterLogging カスタムリソース (CR) に各ログソースの maxAge パラメーターを設定します。CR はこれらの値を Elasticsearch ロールオーバースケジュールに適用し、Elasticsearch がロールオーバーインデックスを削除するタイミングを決定します。

Elasticsearch はインデックスをロールオーバーし、インデックスが以下の条件のいずれかに一致する場合に現在のインデックスを移動し、新規インデックスを作成します。

  • インデックスは Elasticsearch CR の rollover.maxAge の値よりも古い値になります。
  • インデックスサイズは、40 GB x プライマリーシャードの数よりも大きくなります。
  • インデックスの doc 数は、40960 KB × プライマリーシャードの数よりも大きくなります。

Elasticsearch は、設定する保持ポリシーに基づいてロールオーバーインデックスを削除します。ログソースの保持ポリシーを作成しない場合、ログはデフォルトで 7 日後に削除されます。

前提条件

  • Red HatOpenShift のロギングサブシステムと OpenShift Elasticsearch Operator がインストールされている必要があります。

手順

ログの保持時間を設定するには、以下を実行します。

  1. ClusterLogging CR を編集して、retentionPolicy パラメーターを追加するか、または変更します。

    apiVersion: "logging.openshift.io/v1"
    kind: "ClusterLogging"
    ...
    spec:
      managementState: "Managed"
      logStore:
        type: "elasticsearch"
        retentionPolicy: 1
          application:
            maxAge: 1d
          infra:
            maxAge: 7d
          audit:
            maxAge: 7d
        elasticsearch:
          nodeCount: 3
    ...
    1
    Elasticsearch が各ログソースを保持する時間を指定します。整数および時間の指定 (weeks(w)、hour(h/H)、minutes(m)、および seconds(s)) を入力します。たとえば、1 日の場合は 1d になります。maxAge よりも古いログは削除されます。デフォルトで、ログは 7 日間保持されます。
  2. Elasticsearch カスタムリソース (CR) で設定を確認できます。

    たとえば、Red Hat OpenShift Logging Operator は以下の Elasticsearch CR を更新し、8 時間ごとにインフラストラクチャーログのアクティブなインデックスをロールオーバーし、ロールオーバーされたインデックスはロールオーバーの 7 日後に削除される設定を含む保持ポリシーを設定するとします。OpenShift Container Platform は 15 分ごとにチェックし、インデックスをロールオーバーする必要があるかどうかを判別します。

    apiVersion: "logging.openshift.io/v1"
    kind: "Elasticsearch"
    metadata:
      name: "elasticsearch"
    spec:
    ...
      indexManagement:
        policies: 1
          - name: infra-policy
            phases:
              delete:
                minAge: 7d 2
              hot:
                actions:
                  rollover:
                    maxAge: 8h 3
            pollInterval: 15m 4
    ...
    1
    各ログソースについて、保持ポリシーは、そのソースのログを削除/ロールオーバーするタイミングを示します。
    2
    OpenShift Container Platform がロールオーバーされたインデックスを削除する場合。この設定は、ClusterLogging CR に設定する maxAge になります。
    3
    インデックスをロールオーバーする際に考慮する OpenShift Container Platform のインデックス期間。この値は、ClusterLogging CR に設定する maxAge に基づいて決定されます。
    4
    OpenShift Container Platform がインデックスをロールオーバーする必要があるかどうかをチェックする場合。この設定はデフォルトであるため、変更できません。
    注記

    Elasticsearch CR の変更はサポートされていません。保持ポリシーに対するすべての変更は ClusterLogging CR で行う必要があります。

    OpenShift Elasticsearch Operator は cron ジョブをデプロイし、pollInterval を使用してスケジュールされる定義されたポリシーを使用して各マッピングのインデックスをロールオーバーします。

    $ oc get cronjob

    出力例

    NAME                     SCHEDULE       SUSPEND   ACTIVE   LAST SCHEDULE   AGE
    elasticsearch-im-app     */15 * * * *   False     0        <none>          4s
    elasticsearch-im-audit   */15 * * * *   False     0        <none>          4s
    elasticsearch-im-infra   */15 * * * *   False     0        <none>          4s

4.3.3. ログストアの CPU およびメモリー要求の設定

それぞれのコンポーネント仕様は、CPU とメモリー要求の両方への調整を許可します。OpenShift Elasticsearch Operator は環境に適した値を設定するため、これらの値を手動で調整する必要はありません。

注記

大規模なクラスターでは、Elasticsearch プロキシーコンテナーのデフォルトのメモリー制限が不十分である場合があり、これにより、プロキシーコンテナーが OOM による強制終了 (OOMKilled) が生じます。この問題が発生した場合には、Elasticsearch プロキシーのメモリー要求および制限を引き上げます。

各 Elasticsearch ノードはこれより低い値のメモリー設定でも動作しますが、これは実稼働環境でのデプロイメントには推奨 されていません。実稼働環境での使用の場合には、デフォルトの 16Gi よりも小さい値を各 Pod に割り当てることはできません。Pod ごとに割り当て可能な最大値は 64Gi であり、この範囲の中で、できるだけ多くのメモリーを割り当てることを推奨します。

前提条件

  • Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。

手順

  1. openshift-logging プロジェクトで ClusterLogging カスタムリソース (CR) を編集します。

    $ oc edit ClusterLogging instance
    apiVersion: "logging.openshift.io/v1"
    kind: "ClusterLogging"
    metadata:
      name: "instance"
    ....
    spec:
        logStore:
          type: "elasticsearch"
          elasticsearch:1
            resources:
              limits: 2
                memory: "32Gi"
              requests: 3
                cpu: "1"
                memory: "16Gi"
            proxy: 4
              resources:
                limits:
                  memory: 100Mi
                requests:
                  memory: 100Mi
    1
    必要に応じて CPU およびメモリー要求を指定します。これらの値を空のままにすると、OpenShift Elasticsearch Operator はデフォルト値を設定します。これらのデフォルト値はほとんどのデプロイメントでは問題なく使用できるはずです。デフォルト値は、メモリー要求の場合は 16Gi であり、CPU 要求の場合は 1 です。
    2
    Pod が使用できるリソースの最大量。
    3
    Pod のスケジュールに必要最小限のリソース。
    4
    必要に応じて Elasticsearch プロキシーの CPU およびメモリーの制限および要求を指定します。これらの値を空のままにすると、OpenShift Elasticsearch Operator はデフォルト値を設定します。これらのデフォルト値はほとんどのデプロイメントでは問題なく使用できるます。デフォルト値は、メモリー要求の場合は 256Mi、CPU 要求の場合は 100m です。

Elasticsearch メモリーの量を調整するときは、要求制限 の両方に同じ値を使用する必要があります。

以下に例を示します。

      resources:
        limits: 1
          memory: "32Gi"
        requests: 2
          cpu: "8"
          memory: "32Gi"
1
リソースの最大量。
2
必要最小限の量。

Kubernetes は一般的にはノードの設定に従い、Elasticsearch が指定された制限を使用することを許可しません。requestslimits に同じ値を設定することにより、Elasticseach が必要なメモリーを確実に使用できるようにします (利用可能なメモリーがノードにあることを前提とします)。

4.3.4. ログストアのレプリケーションポリシーの設定

Elasticsearch シャードをクラスター内の複数のデータノードにレプリケートする方法を定義できます。

前提条件

  • Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。

手順

  1. openshift-logging プロジェクトで ClusterLogging カスタムリソース (CR) を編集します。

    $ oc edit clusterlogging instance
    apiVersion: "logging.openshift.io/v1"
    kind: "ClusterLogging"
    metadata:
      name: "instance"
    
    ....
    
    spec:
      logStore:
        type: "elasticsearch"
        elasticsearch:
          redundancyPolicy: "SingleRedundancy" 1
    1
    シャードの冗長性ポリシーを指定します。変更の保存時に変更が適用されます。
    • FullRedundancy:Elasticsearch は、各インデックスのプライマリーシャードをすべてのデータノードに完全にレプリケートします。これは最高レベルの安全性を提供しますが、最大量のディスクが必要となり、パフォーマンスは最低レベルになります。
    • MultipleRedundancy:Elasticsearch は、各インデックスのプライマリーシャードをデータノードの半分に完全にレプリケートします。これは、安全性とパフォーマンス間の適切なトレードオフを提供します。
    • SingleRedundancy:Elasticsearch は、各インデックスのプライマリーシャードのコピーを 1 つ作成します。2 つ以上のデータノードが存在する限り、ログは常に利用可能かつ回復可能です。5 以上のノードを使用する場合には、MultipleRedundancy よりもパフォーマンスが良くなります。このポリシーは、単一 Elasticsearch ノードのデプロイメントには適用できません。
    • ZeroRedundancy:Elasticsearch は、プライマリーシャードのコピーを作成しません。ノードが停止または失敗した場合、ログは利用不可となるか、失われる可能性があります。安全性よりもパフォーマンスを重視する場合や、独自のディスク/PVC バックアップ/復元ストラテジーを実装している場合は、このモードを使用できます。
注記

インデックステンプレートのプライマリーシャードの数は Elasticsearch データノードの数と等しくなります。

4.3.5. Elasticsearch Pod のスケールダウン

クラスター内の Elasticsearch Pod 数を減らすと、データ損失や Elasticsearch のパフォーマンスが低下する可能性があります。

スケールダウンする場合、一度に 1 つの Pod 分スケールダウンし、クラスターがシャードおよびレプリカのリバランスを実行できるようにする必要があります。Elasticsearch のヘルスステータスが green に戻された後に、別の Pod でスケールダウンできます。

注記

Elasticsearch クラスターが ZeroRedundancy に設定される場合、Elasticsearch Pod をスケールダウンしないでください。

4.3.6. ログストアの永続ストレージの設定

Elasticsearch には永続ストレージが必要です。ストレージが高速になると、Elasticsearch のパフォーマンスも高速になります。

警告

NFS ストレージをボリュームまたは永続ボリュームを使用 (または Gluster などの NAS を使用する) ことは Elasticsearch ストレージではサポートされません。Lucene は NFS が指定しないファイルシステムの動作に依存するためです。データの破損およびその他の問題が発生する可能性があります。

前提条件

  • Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。

手順

  1. ClusterLogging CR を編集してクラスターの各データノードが永続ボリューム要求 (PVC) にバインドされるように指定します。

    apiVersion: "logging.openshift.io/v1"
    kind: "ClusterLogging"
    metadata:
      name: "instance"
    # ...
    spec:
      logStore:
        type: "elasticsearch"
        elasticsearch:
          nodeCount: 3
          storage:
            storageClassName: "gp2"
            size: "200G"

この例では、クラスターの各データノードが、200G の AWS General Purpose SSD (gp2) ストレージを要求する永続ボリューム要求 (PVC) にバインドされるように指定します。

注記

永続ストレージにローカルボリュームを使用する場合は、LocalVolume オブジェクトの volumeMode: block で記述される raw ブロックボリュームを使用しないでください。Elasticsearch は raw ブロックボリュームを使用できません。

4.3.7. emptyDir ストレージのログストアの設定

ログストアで emptyDir を使用することができます。これは、Pod のデータすべてが再起動時に失われる一時デプロイメントを作成します。

注記

emptyDir を使用する場合、ログストアが再起動するか、または再デプロイされる場合にデータが失われます。

前提条件

  • Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。

手順

  1. ClusterLogging CR を編集して emptyDir を指定します。

     spec:
        logStore:
          type: "elasticsearch"
          elasticsearch:
            nodeCount: 3
            storage: {}

4.3.8. Elasticsearch クラスターのローリング再起動の実行

elasticsearch 設定マップまたは elasticsearch-* デプロイメント設定のいずれかを変更する際にローリング再起動を実行します。

さらにローリング再起動は、Elasticsearch Pod が実行されるノードで再起動が必要な場合に推奨されます。

前提条件

  • Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。

手順

クラスターのローリング再起動を実行するには、以下を実行します。

  1. openshift-logging プロジェクトに切り替えます。

    $ oc project openshift-logging
  2. Elasticsearch Pod の名前を取得します。

    $ oc get pods -l component=elasticsearch-
  3. コレクター Pod をスケールダウンして、Elasticsearch への新しいログの送信を停止します。

    $ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "false"}}}}}'
  4. OpenShift Container Platform es_util ツールを使用してシャードの同期フラッシュを実行して、シャットダウンの前にディスクへの書き込みを待機している保留中の操作がないようにします。

    $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_flush/synced" -XPOST

    以下に例を示します。

    $ oc exec -c elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6  -c elasticsearch -- es_util --query="_flush/synced" -XPOST

    出力例

    {"_shards":{"total":4,"successful":4,"failed":0},".security":{"total":2,"successful":2,"failed":0},".kibana_1":{"total":2,"successful":2,"failed":0}}

  5. OpenShift Container Platform es_util ツールを使用して、ノードを意図的に停止する際のシャードのバランシングを防ぎます。

    $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "primaries" } }'

    以下に例を示します。

    $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "primaries" } }'

    出力例

    {"acknowledged":true,"persistent":{"cluster":{"routing":{"allocation":{"enable":"primaries"}}}},"transient":

  6. コマンドが完了したら、ES クラスターのそれぞれのデプロイメントについて、以下を実行します。

    1. デフォルトで、OpenShift Container Platform Elasticsearch クラスターはノードのロールアウトをブロックします。以下のコマンドを使用してロールアウトを許可し、Pod が変更を取得できるようにします。

      $ oc rollout resume deployment/<deployment-name>

      以下に例を示します。

      $ oc rollout resume deployment/elasticsearch-cdm-0-1

      出力例

      deployment.extensions/elasticsearch-cdm-0-1 resumed

      新規 Pod がデプロイされます。Pod に準備状態のコンテナーがある場合、次のデプロイメントに進むことができます。

      $ oc get pods -l component=elasticsearch-

      出力例

      NAME                                            READY   STATUS    RESTARTS   AGE
      elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6k    2/2     Running   0          22h
      elasticsearch-cdm-5ceex6ts-2-f799564cb-l9mj7    2/2     Running   0          22h
      elasticsearch-cdm-5ceex6ts-3-585968dc68-k7kjr   2/2     Running   0          22h

    2. デプロイメントが完了したら、ロールアウトを許可しないように Pod をリセットします。

      $ oc rollout pause deployment/<deployment-name>

      以下に例を示します。

      $ oc rollout pause deployment/elasticsearch-cdm-0-1

      出力例

      deployment.extensions/elasticsearch-cdm-0-1 paused

    3. Elasticsearch クラスターが green または yellow 状態にあることを確認します。

      $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query=_cluster/health?pretty=true
      注記

      直前のコマンドで使用した Elasticsearch Pod でロールアウトを実行した場合、Pod は存在しなくなっているため、ここで新規 Pod 名が必要になります。

      以下に例を示します。

      $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query=_cluster/health?pretty=true
      {
        "cluster_name" : "elasticsearch",
        "status" : "yellow", 1
        "timed_out" : false,
        "number_of_nodes" : 3,
        "number_of_data_nodes" : 3,
        "active_primary_shards" : 8,
        "active_shards" : 16,
        "relocating_shards" : 0,
        "initializing_shards" : 0,
        "unassigned_shards" : 1,
        "delayed_unassigned_shards" : 0,
        "number_of_pending_tasks" : 0,
        "number_of_in_flight_fetch" : 0,
        "task_max_waiting_in_queue_millis" : 0,
        "active_shards_percent_as_number" : 100.0
      }
      1
      次に進む前に、このパラメーターが green または yellow であることを確認します。
  7. Elasticsearch 設定マップを変更した場合、それぞれの Elasticsearch Pod についてこれらの手順を繰り返します。
  8. クラスターのすべてのデプロイメントがロールアウトされたら、シャードのバランシングを再度有効にします。

    $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "all" } }'

    以下に例を示します。

    $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "all" } }'

    出力例

    {
      "acknowledged" : true,
      "persistent" : { },
      "transient" : {
        "cluster" : {
          "routing" : {
            "allocation" : {
              "enable" : "all"
            }
          }
        }
      }
    }

  9. 新しいログが Elasticsearch に送信されるように、コレクター Pod をスケールアップします。

    $ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "true"}}}}}'

4.3.9. ログストアサービスのルートとしての公開

デフォルトでは、Red Hat OpenShift のロギングサブシステムとともにデプロイされているログストアには、ロギングクラスターの外部からアクセスできません。データにアクセスするツールについては、ログストアへの外部アクセスのために re-encryption termination でルートを有効にすることができます。

re-encrypt ルート、OpenShift Container Platform トークンおよびインストールされたログストア CA 証明書を作成して、ログストアに外部からアクセスすることができます。次に、以下を含む cURL 要求でログストアサービスをホストするノードにアクセスします。

内部からは、ログストアクラスター IP を使用してログストアサービスにアクセスできます。これは、以下のコマンドのいずれかを使用して取得できます。

$ oc get service elasticsearch -o jsonpath={.spec.clusterIP} -n openshift-logging

出力例

172.30.183.229

$ oc get service elasticsearch -n openshift-logging

出力例

NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
elasticsearch   ClusterIP   172.30.183.229   <none>        9200/TCP   22h

以下のようなコマンドを使用して、クラスター IP アドレスを確認できます。

$ oc exec elasticsearch-cdm-oplnhinv-1-5746475887-fj2f8 -n openshift-logging -- curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://172.30.183.229:9200/_cat/health"

出力例

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    29  100    29    0     0    108      0 --:--:-- --:--:-- --:--:--   108

前提条件

  • Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
  • ログにアクセスできるようになるには、プロジェクトへのアクセスが必要です。

手順

ログストアを外部に公開するには、以下を実行します。

  1. openshift-logging プロジェクトに切り替えます。

    $ oc project openshift-logging
  2. ログストアから CA 証明書を抽出し、admin-ca ファイルに書き込みます。

    $ oc extract secret/elasticsearch --to=. --keys=admin-ca

    出力例

    admin-ca

  3. ログストアサービスのルートを YAML ファイルとして作成します。

    1. 以下のように YAML ファイルを作成します。

      apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        name: elasticsearch
        namespace: openshift-logging
      spec:
        host:
        to:
          kind: Service
          name: elasticsearch
        tls:
          termination: reencrypt
          destinationCACertificate: | 1
      1
      次の手順でログストア CA 証明書を追加するか、またはコマンドを使用します。一部の re-encrypt ルートで必要とされる spec.tls.keyspec.tls.certificate、および spec.tls.caCertificate パラメーターを設定する必要はありません。
    2. 以下のコマンドを実行して、前のステップで作成したルート YAML にログストア CA 証明書を追加します。

      $ cat ./admin-ca | sed -e "s/^/      /" >> <file-name>.yaml
    3. ルートを作成します。

      $ oc create -f <file-name>.yaml

      出力例

      route.route.openshift.io/elasticsearch created

  4. Elasticsearch サービスが公開されていることを確認します。

    1. 要求に使用されるこのサービスアカウントのトークンを取得します。

      $ token=$(oc whoami -t)
    2. 作成した elasticsearch ルートを環境変数として設定します。

      $ routeES=`oc get route elasticsearch -o jsonpath={.spec.host}`
    3. ルートが正常に作成されていることを確認するには、公開されたルート経由で Elasticsearch にアクセスする以下のコマンドを実行します。

      curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://${routeES}"

      以下のような出力が表示されます。

      出力例

      {
        "name" : "elasticsearch-cdm-i40ktba0-1",
        "cluster_name" : "elasticsearch",
        "cluster_uuid" : "0eY-tJzcR3KOdpgeMJo-MQ",
        "version" : {
        "number" : "6.8.1",
        "build_flavor" : "oss",
        "build_type" : "zip",
        "build_hash" : "Unknown",
        "build_date" : "Unknown",
        "build_snapshot" : true,
        "lucene_version" : "7.7.0",
        "minimum_wire_compatibility_version" : "5.6.0",
        "minimum_index_compatibility_version" : "5.0.0"
      },
        "<tagline>" : "<for search>"
      }