10.4. Elasticsearch ログストアの設定
Elasticsearch 6 を使用して、ログデータを保存および整理できます。
ログストアに加えることのできる変更には、以下が含まれます。
- Elasticsearch クラスターのストレージ
- シャードをクラスター内の複数のデータノードにレプリケートする方法 (完全なレプリケーションからレプリケーションなしまで)
- Elasticsearch データへの外部アクセス
10.4.1. ログストレージの設定
ClusterLogging
カスタムリソース (CR) を変更することで、ロギングで使用するログストレージのタイプを設定できます。
前提条件
- 管理者権限がある。
-
OpenShift CLI (
oc
) がインストールされている。 - Red Hat OpenShift Logging Operator と内部ログストア (LokiStack または Elasticsearch) がインストールされている。
-
ClusterLogging
CR が作成されている。
Logging 5.9 リリースに、OpenShift Elasticsearch Operator の更新バージョンは含まれていません。ロギング 5.8 でリリースされた OpenShift Elasticsearch Operator を現在使用している場合、Logging 5.8 の EOL まで引き続き Logging で機能します。OpenShift Elasticsearch Operator を使用してデフォルトのログストレージを管理する代わりに、Loki Operator を使用できます。Logging のライフサイクルの日付の詳細は、Platform Agnostic Operator を参照してください。
手順
ClusterLogging
CR のlogStore
仕様を変更します。ClusterLogging
CR の例apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: # ... spec: # ... logStore: type: <log_store_type> 1 elasticsearch: 2 nodeCount: <integer> resources: {} storage: {} redundancyPolicy: <redundancy_type> 3 lokistack: 4 name: {} # ...
LokiStack をログストアとして指定する
ClusterLogging
CR の例apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance namespace: openshift-logging spec: managementState: Managed logStore: type: lokistack lokistack: name: logging-loki # ...
次のコマンドを実行して、
ClusterLogging
CR を適用します。$ oc apply -f <filename>.yaml
10.4.2. 監査ログのログストアへの転送
ロギングデプロイメントでは、デフォルトでコンテナーおよびインフラストラクチャーのログは ClusterLogging
カスタムリソース (CR) に定義された内部ログストアに転送されます。
セキュアなストレージを提供しないため、監査ログはデフォルトで内部ログストアに転送されません。お客様の責任において、監査ログを転送するシステムが組織および政府の規制に準拠し、適切に保護されていることを確認してください。
このデフォルト設定が要件を満たす場合、ClusterLogForwarder
CR を設定する必要はありません。ClusterLogForwarder
CR が存在する場合、default
出力を含むパイプラインが定義されている場合を除き、ログは内部ログストアに転送されません。
手順
ログ転送 API を使用して監査ログを内部 Elasticsearch インスタンスに転送するには、以下を実行します。
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 インスタンスに送信します。
関連情報
10.4.3. ログ保持時間の設定
デフォルトの Elasticsearch ログストアがインフラストラクチャーログ、アプリケーションログ、監査ログなどの 3 つのログソースのインデックスを保持する期間を指定する 保持ポリシー を設定できます。
保持ポリシーを設定するには、ClusterLogging
カスタムリソース (CR) に各ログソースの maxAge
パラメーターを設定します。CR はこれらの値を Elasticsearch ロールオーバースケジュールに適用し、Elasticsearch がロールオーバーインデックスを削除するタイミングを決定します。
Elasticsearch はインデックスをロールオーバーし、インデックスが以下の条件のいずれかに一致する場合に現在のインデックスを移動し、新規インデックスを作成します。
-
インデックスは
Elasticsearch
CR のrollover.maxAge
の値よりも古い値になります。 - インデックスサイズは、40 GB x プライマリーシャードの数よりも大きくなります。
- インデックスの doc 数は、40960 KB × プライマリーシャードの数よりも大きくなります。
Elasticsearch は、設定する保持ポリシーに基づいてロールオーバーインデックスを削除します。ログソースの保持ポリシーを作成しない場合、ログはデフォルトで 7 日後に削除されます。
前提条件
- Red Hat OpenShift Logging Operator と OpenShift Elasticsearch Operator がインストールされている。
手順
ログの保持時間を設定するには、以下を実行します。
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 日間保持されます。
Elasticsearch
カスタムリソース (CR) で設定を確認できます。たとえば、Red Hat OpenShift Logging Operator は以下の
Elasticsearch
CR を更新し、8 時間ごとにインフラストラクチャーログのアクティブなインデックスをロールオーバーし、ロールオーバーされたインデックスはロールオーバーの 7 日後に削除される設定を含む保持ポリシーを設定するとします。Red Hat OpenShift Service on AWS は 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
- Red Hat OpenShift Service on AWS がロールオーバーされたインデックスを削除するタイミング。この設定は、
ClusterLogging
CR に設定するmaxAge
になります。 - 3
- インデックスをロールオーバーする際に考慮する Red Hat OpenShift Service on AWS のインデックス期間。この値は、
ClusterLogging
CR に設定するmaxAge
に基づいて決定されます。 - 4
- Red Hat OpenShift Service on AWS がインデックスをロールオーバーする必要があるかどうかをチェックするタイミング。この設定はデフォルトであるため、変更できません。
注記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
10.4.4. ログストアの CPU およびメモリー要求の設定
それぞれのコンポーネント仕様は、CPU とメモリー要求の両方への調整を許可します。OpenShift Elasticsearch Operator は環境に適した値を設定するため、これらの値を手動で調整する必要はありません。
大規模なクラスターでは、Elasticsearch プロキシーコンテナーのデフォルトのメモリー制限が不十分な場合があり、これにより、プロキシーコンテナーが OOM による強制終了 (OOMKilled) が生じます。この問題が発生した場合は、Elasticsearch プロキシーのメモリー要求および制限を引き上げます。
各 Elasticsearch ノードはこれより低い値のメモリー設定でも動作しますが、これは実稼働環境でのデプロイメントには推奨 されていません。実稼働環境で使用する場合は、デフォルトの 16Gi よりも小さい値を各 Pod に割り当てることはできません。Pod ごとに割り当て可能な最大値は 64Gi であり、この範囲の中で、できるだけ多くのメモリーを割り当てることを推奨します。
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
手順
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"
Kubernetes は一般的にはノードの設定に従い、Elasticsearch が指定された制限を使用することを許可しません。requests
と limits
に同じ値を設定することにより、Elasticsearch が必要なメモリーを確実に使用できるようにします (利用可能なメモリーがノードにあることを前提とします)。
10.4.5. ログストアのレプリケーションポリシーの設定
Elasticsearch シャードをクラスター内の複数のデータノードにレプリケートする方法を定義できます。
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
手順
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 データノードの数と等しくなります。
10.4.6. Elasticsearch Pod のスケールダウン
クラスター内の Elasticsearch Pod 数を減らすと、データ損失や Elasticsearch のパフォーマンスが低下する可能性があります。
スケールダウンする場合は、一度に 1 つの Pod 分スケールダウンし、クラスターがシャードおよびレプリカのリバランスを実行できるようにする必要があります。Elasticsearch のヘルスステータスが green
に戻された後に、別の Pod でスケールダウンできます。
Elasticsearch クラスターが ZeroRedundancy
に設定される場合は、Elasticsearch Pod をスケールダウンしないでください。
10.4.7. ログストアの永続ストレージの設定
Elasticsearch には永続ストレージが必要です。ストレージが高速になると、Elasticsearch のパフォーマンスも高速になります。
NFS ストレージをボリュームまたは永続ボリュームを使用 (または Gluster などの NAS を使用する) ことは Elasticsearch ストレージではサポートされません。Lucene は NFS が指定しないファイルシステムの動作に依存するためです。データの破損およびその他の問題が発生する可能性があります。
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
手順
ClusterLogging
CR を編集してクラスターの各データノードが永続ボリューム要求にバインドされるように指定します。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) ストレージを要求する永続ボリューム要求にバインドされるように指定します。
永続ストレージにローカルボリュームを使用する場合は、LocalVolume
オブジェクトの volumeMode: block
で記述される raw ブロックボリュームを使用しないでください。Elasticsearch は raw ブロックボリュームを使用できません。
10.4.8. emptyDir ストレージのログストアの設定
ログストアで emptyDir を使用できます。これは、Pod のデータすべてが再起動時に失われる一時デプロイメントを作成します。
emptyDir を使用する場合は、ログストアが再起動するか、再デプロイされる場合にデータが失われます。
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
手順
ClusterLogging
CR を編集して emptyDir を指定します。spec: logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: {}
10.4.9. Elasticsearch クラスターのローリング再起動の実行
elasticsearch
config map または elasticsearch-*
デプロイメント設定のいずれかを変更する際にローリング再起動を実行します。
さらにローリング再起動は、Elasticsearch Pod が実行されるノードで再起動が必要な場合に推奨されます。
前提条件
- Red Hat OpenShift Logging および Elasticsearch Operators がインストールされている必要があります。
手順
クラスターのローリング再起動を実行するには、以下を実行します。
openshift-logging
プロジェクトに切り替えます。$ oc project openshift-logging
Elasticsearch Pod の名前を取得します。
$ oc get pods -l component=elasticsearch
コレクター Pod をスケールダウンして、Elasticsearch への新しいログの送信を停止します。
$ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "false"}}}}}'
Red Hat OpenShift Service on AWS 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}}
Red Hat OpenShift Service on AWS 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":
コマンドが完了したら、ES クラスターのそれぞれのデプロイメントについて、以下を実行します。
デフォルトで、Red Hat OpenShift Service on AWS 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
デプロイメントが完了したら、ロールアウトを許可しないように Pod をリセットします。
$ oc rollout pause deployment/<deployment-name>
以下に例を示します。
$ oc rollout pause deployment/elasticsearch-cdm-0-1
出力例
deployment.extensions/elasticsearch-cdm-0-1 paused
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
であることを確認します。
- Elasticsearch config map を変更した場合は、それぞれの Elasticsearch Pod に対してこれらの手順を繰り返します。
クラスターのすべてのデプロイメントがロールアウトされたら、シャードのバランシングを再度有効にします。
$ 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" } } } } }
新しいログが Elasticsearch に送信されるように、コレクター Pod をスケールアップします。
$ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "true"}}}}}'
10.4.10. ログストアサービスのルートとしての公開
デフォルトでは、ロギングでデプロイされたログストアはロギングクラスターの外部からアクセスできません。データにアクセスするツールについては、ログストアへの外部アクセスのために re-encryption termination でルートを有効にできます。
re-encrypt ルート、Red Hat OpenShift Service on AWS トークンおよびインストールされたログストア CA 証明書を作成して、ログストアに外部からアクセスできます。次に、以下を含む cURL 要求でログストアサービスをホストするノードにアクセスします。
-
Authorization: Bearer ${token}
- Elasticsearch reencrypt ルートおよび Elasticsearch API 要求
内部からは、ログストアクラスター 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 がインストールされている必要があります。
- ログにアクセスできるようになるには、プロジェクトへのアクセスが必要です。
手順
ログストアを外部に公開するには、以下を実行します。
openshift-logging
プロジェクトに切り替えます。$ oc project openshift-logging
ログストアから CA 証明書を抽出し、admin-ca ファイルに書き込みます。
$ oc extract secret/elasticsearch --to=. --keys=admin-ca
出力例
admin-ca
ログストアサービスのルートを YAML ファイルとして作成します。
以下のように 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.key
、spec.tls.certificate
、およびspec.tls.caCertificate
パラメーターを設定する必要はありません。
以下のコマンドを実行して、前のステップで作成したルート YAML にログストア CA 証明書を追加します。
$ cat ./admin-ca | sed -e "s/^/ /" >> <file-name>.yaml
ルートを作成します。
$ oc create -f <file-name>.yaml
出力例
route.route.openshift.io/elasticsearch created
Elasticsearch サービスが公開されていることを確認します。
要求に使用されるこのサービスアカウントのトークンを取得します。
$ token=$(oc whoami -t)
作成した elasticsearch ルートを環境変数として設定します。
$ routeES=`oc get route elasticsearch -o jsonpath={.spec.host}`
ルートが正常に作成されていることを確認するには、公開されたルート経由で 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>" }
10.4.11. デフォルトの Elasticsearch ログストアを使用しない場合の未使用のコンポーネントの削除
管理者がログをサードパーティーのログストアに転送し、デフォルトの Elasticsearch ログストアを使用しない場合は、ロギングクラスターからいくつかの未使用のコンポーネントを削除できます。
つまり、デフォルトの Elasticsearch ログストアを使用しない場合は、内部 Elasticsearch logStore
、Kibana visualization
コンポーネントを ClusterLogging
カスタムリソース (CR) から削除できます。これらのコンポーネントの削除はオプションですが、これによりリソースを節約できます。
前提条件
ログフォワーダーがログデータをデフォルトの内部 Elasticsearch クラスターに送信しないことを確認します。ログ転送の設定に使用した
ClusterLogForwarder
CR YAML ファイルを検査します。これにはdefault
を指定するoutputRefs
要素が ない ことを確認します。以下に例を示します。outputRefs: - default
ClusterLogForwarder
CR がログデータを内部 Elasticsearch クラスターに転送し、ClusterLogging
CR から logStore
コンポーネントを削除するとします。この場合、内部 Elasticsearch クラスターはログデータを保存するために表示されません。これがないと、データが失われる可能性があります。
手順
openshift-logging
プロジェクトでClusterLogging
カスタムリソース (CR) を編集します。$ oc edit ClusterLogging instance
-
これらが存在する場合は、
logStore
、visualization
スタンザをClusterLogging
CR から削除します。 ClusterLogging
CR のcollection
スタンザを保持します。結果は以下の例のようになります。apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: "openshift-logging" spec: managementState: "Managed" collection: type: "fluentd" fluentd: {}
コレクター Pod が再デプロイされたことを確認します。
$ oc get pods -l component=collector -n openshift-logging