第32章 コンテナーログの集計
32.1. 概要
OpenShift Container Platform のクラスター管理者として、EFK スタックをデプロイして各種の OpenShift Container Platform サービスのログを集計できます。アプリケーション開発者は、表示アクセス権を持つプロジェクトのログを表示することができます。EFK スタックは、複数のコンテナーまたは削除された Pod からのものであっても、ホストとアプリケーションからログを集計します。
EFK スタックは ELK スタックの変更バージョンであり、以下で構成されています。
- Elasticsearch (ES): すべてのログが格納されるオブジェクトストア。
- Fluentd: ノードからログを収集し、そのログを Elasticsearch に送ります。
- Kibana: Elasticsearch の Web UI。
クラスターにデプロイされると、スタックはすべてのノードおよびプロジェクトのログを Elasticsearch に集計し、ログを表示するために Kibana UI を提供します。クラスター管理者はすべてのログを表示できますが、アプリケーション開発者は表示権限を持つプロジェクトのログのみを表示できます。スタックのコンポーネントは安全な通信を実行します。
「Docker コンテナーログの管理」では、コンテナーログを管理し、ノードディスクが満杯になることを阻止するための json-file
ロギングドライバーオプションの使用について説明しています。
32.2. デプロイ前の設定
- Ansible Playbook は集計されたロギングをデプロイおよびアップグレードするために利用できます。通常インストール (Advanced installation)と設定 のセクションに精通しておくようにしてください。このセクションでは、Ansible を使用する準備に必要な情報と設定に関する情報を提供します。EFK スタックの各種の領域を設定するために、パラメーターが Ansible インベントリーファイルに追加されています。
- サイジングのガイドラインを確認して、デプロイメントの最適な設定方法を判断してください。
- クラスターのルーターをデプロイしていることを確認します。
- Elasticsearch に必要なストレージがあることを確認します。各 Elasticsearch レプリカに独自のストレージボリュームが必要であることに注意してください。詳細については、「Elasticsearch 」を参照してください。
プロジェクトを選択します。デプロイされたら、EFK スタックは OpenShift Container Platform クラスター内のすべてのプロジェクトのログを収集します。このセクションの例では、デフォルトのプロジェクトロギング を使用しています。プロジェクトがまだ存在していない場合は、Ansible Playbook によってプロジェクトが作成されます。プロジェクトに対してノードセレクターを指定する場合にのみ、プロジェクトを作成する必要があります。そうしない場合は、
openshift-logging
ロールによってプロジェクトが作成されます。$ oc adm new-project logging --node-selector="" $ oc project logging
注記Fluentd はクラスター全体にデプロイする必要があり、セレクターによって Fluentd がデプロイされる場所が制限されるため、プロジェクトには空のノードセレクターを指定することをお勧めします。コンポーネントの配置を制御するには、コンポーネントごとにノードセレクターを指定して、デプロイメント設定に適用する必要があります。
32.3. ロギング Ansible 変数の指定
EFK デプロイメントのパラメーターをインベントリーホストファイルに指定して、デフォルトを上書きすることができます。パラメーターを選択する前に、「Elasticsearch」と「Fluentd」のセクションを参照してください。
デフォルトでは、Elasticsearch サービスはクラスターのノード間での TCP 通信にポート 9300 を使用します。
パラメーター | 説明 |
---|---|
|
ロギングコンポーネントイメージのプレフィックス。たとえば、プレフィックスを registry.access.redhat.com/openshift3/ に設定すると registry.access.redhat.com/openshift3/logging-fluentd:latest が作成されます。 |
|
ロギングコンポーネントイメージのバージョン。たとえば、バージョンを v3.9 に設定すると registry.access.redhat.com/openshift3/logging-fluentd:v3.9 が作成されます。 |
|
|
|
Kubernetes マスターの URL。これは公開されている必要はありませんが、クラスター内からアクセスできる必要があります (例: https://<PRIVATE-MASTER-URL>:8443)。 |
|
Kubernetes マスターの公開された URL。これは、Kibana プロキシーによる認証のリダイレクトに使用されます (例: https://<CONSOLE-PUBLIC-URL-MASTER>:8443)。 |
|
集計されたロギングがデプロイされる namespace。 |
|
ロギングをインストールする場合は |
|
通常のアンインストールでは、再インストール中の予期せぬデータ損失を防ぐために PVC が維持されます。Ansible Playbook が完全かつ不可逆的にすべてのロギング永続データ (PVC を含む) を確実に削除するようにするには、 |
|
|
|
イベントルーターのロギングイメージのプレフィックス。デフォルトでは |
|
ロギングイベントルーターのイメージバージョン。デフォルトでは 'openshift_logging_image_version' に設定されています。 |
|
イベントルーターのシンク (受信側) を選択します。 |
|
Pod が到達するノードを選択するためのラベルのマップ ( |
|
デフォルトでは '1' に設定されます。 |
|
イベントルーターに割り当てる最小 CPU 量。デフォルトでは '100m' に設定されます。 |
|
イベントルーター Pod のメモリー制限。デフォルトでは '128Mi' に設定されます。 |
|
eventrouter がデプロイされる project。デフォルトでは 'default' に設定されます。 重要
プロジェクトを |
|
認証済みレジストリーからコンポーネントイメージをプルするために使用される既存のプルシークレットの名前を指定します。 |
|
ログレコードを削除するために Curator が使用するデフォルトの最小期間 (日単位)。 |
|
Curator が実行される時刻 (時間)。 |
|
Curator が実行される時刻 (分)。 |
|
実行時間を割り出すために Curator が使用するタイムゾーン。タイムゾーンは、 |
|
Curator のスクリプトログレベル。 |
|
Curator プロセスのログレベル。 |
|
Curator に割り当てる CPU 量。 |
|
Curator に割り当てるメモリー量。 |
|
Curator インスタンスをデプロイできるターゲットのノードを指定するノードセレクター。 |
|
|
|
|
|
Kibana に到達する Web クライアントの外部ホスト名。 |
|
Kibana に割り当てる CPU 量。 |
|
Kibana に割り当てるメモリー量。 |
|
|
|
Kibana プロキシーに割り当てる CPU 量。 |
|
Kibana プロキシーに割り当てるメモリー量。 |
|
Kibana を拡張して達成するレプリカ数。 |
|
Kibana インスタンスをデプロイできるターゲットのノードを指定するノードセレクター。 |
|
{"ELASTICSEARCH_REQUESTTIMEOUT":"30000"} など、Kibana デプロイメント設定に追加する環境変数のマッピング。 |
|
Kibana ルートの作成時に使用する公開されているキー。 |
|
Kibana ルートの作成時にキーに一致する証明書。 |
|
オプション。キーに添付する CA と、Kibana ルートの作成時に使用される証明書。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ルートと TLS サーバーの証明書に使用する外部向けホスト名。デフォルトでは
たとえば、 |
|
Elasticsearch が外部 TLS サーバー証明書に使用する証明書の場所。デフォルトは、生成される証明書になります。 |
|
Elasticsearch が外部 TLS サーバー証明書に使用するキーの場所。デフォルトは、生成されるキーになります。 |
|
Elasticsearch が外部 TLS サーバーに使用する CA 証明書の場所。デフォルトは内部 CA です。 |
|
|
|
ルートと TLS サーバー証明書に使用する外部向けホスト名。デフォルトでは
たとえば、 |
|
Elasticsearch が外部 TLS サーバー証明書に使用する証明書の場所。デフォルトは、生成される証明書になります。 |
|
Elasticsearch が外部 TLS サーバー証明書に使用するキーの場所。デフォルトは、生成されるキーになります。 |
|
Elasticsearch が外部 TLS サーバーに使用する CA 証明書の場所。デフォルトは内部 CA です。 |
|
Fluentd インスタンスをデプロイできるターゲットのノードを指定するノードセレクター。Fluentd を実行する必要があるノード (通常はすべて) には、Fluentd が実行およびログ収集できるようになる前に、このラベルを付ける必要があります。
インストール後に Aggregated Logging クラスターを拡張する際に、 インストールの一環として、Fluentd ノードセレクターのラベルを永続化されたノードラベルの一覧に追加することをお勧めします。 |
|
Fluentd Pod の CPU 上限。 |
|
Fluentd Pod のメモリー上限。 |
|
最初の起動時に Fluentd がジャーナルの先頭から読み取る必要がある場合は、 |
|
Fluentd をデプロイするためにラベルを付ける必要があるノードの一覧。デフォルトでは、全ノードに ['--all'] のラベルを付けます。null 値は |
|
|
|
監査ログファイルの場所。デフォルトは |
|
監査ログファイルの Fluentd |
|
Fluentd がログを送信する必要がある ES サービスの名前。 |
|
Fluentd がログを送信する必要がある ES サービスのポート。 |
|
Fluentd が |
|
Fluentd が |
|
Fluentd が |
|
デプロイする Elasticsearch レプリカ。冗長性を実現するには 3 つ以上のレプリカが必要です。 |
|
ES クラスターの CPU 量の上限。 |
|
Elasticsearch インスタンスごとに予約する RAM 容量。512 M 以上である必要があります。使用可能なサフィックスは G、g、M、m です。 |
|
すべての新規インデックスのプライマリーシャードごとのレプリカシャード数。デフォルトは '0' に設定されています。実稼働環境のクラスターに対しては、 |
|
ES で作成される新規インデックスごとのプライマリシャード数。デフォルトは '1' に設定されます。 |
|
特定の PV を選択するために PVC に追加されるキー/値のマップ。 |
|
バッキングストレージを動的にプロビジョニングするには、パラメーターの値を |
|
デフォルト以外のストレージクラスを使用するには、 |
|
Elasticsearch インスタンスごとに作成する Persistent Volume Claim (永続ボリューム要求) のサイズ (例: 100 G)。省略する場合は、PVC が作成されず、代わりに一時ボリュームが使用されます。 |
|
Elasticsearch インスタンスのストレージとして使用される Persistent Volume Claim (永続ボリューム要求) の名前のプレフィックス。logging-es-1 のように、インスタンスごとに数字が付加されます。まだ存在していない場合は、サイズ
|
|
リカバリーを試みる前に ES が待機する時間。 |
|
Elasticsearch ストレージボリュームにアクセスするための補助グループ ID の数。バッキングボリュームはこのグループ ID によるアクセスを許可する必要があります。 |
|
Elasticsearch インスタンスをデプロイできるターゲットのノードを判断するマップとして指定されているノードセレクター。このノードセレクターは、Elasticsearch インスタンスの実行用に予約または最適化されているノードにこれらのインスタンスを配置するために使用することができます。たとえば、セレクターは |
|
cluster-reader ロールに操作ログの読み取りが許可されている場合は |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Elasticsearch インスタンスをデプロイできるターゲットのノードを指定するノードセレクター。このノードセレクターは、Elasticsearch インスタンスの実行用に予約または最適化されているノード上にこれらのインスタンスを配置するために使用できます。たとえば、セレクターは |
|
デフォルト値
値 |
|
Kibana インスタンスをデプロイできるターゲットのノードを指定するノードセレクター。 |
|
Curator インスタンスをデプロイできるターゲットのノードを指定するノードセレクター。 |
カスタム証明書
デプロイメントプロセスで生成されるものを利用する代わりに、以下のインベントリー変数を使用してカスタム証明書を指定できます。カスタム証明書は、ユーザーのブラウザーと Kibana 間の通信を暗号化し、保護するために使用されます。これらが指定されない場合は、セキュリティー関連のファイルが生成されます。
ファイル名 | 説明 |
---|---|
|
Kibana サーバーのブラウザー向けの証明書。 |
|
ブラウザー向けの Kibana 証明書で使用されるキー。 |
|
ブラウザー向けの Kibana 証明書用に使用される CA ファイルへの制御ノード上の絶対パス。 |
|
Ops Kibana サーバーのブラウザー向け証明書。 |
|
ブラウザー向けの Ops Kibana 証明書で使用されるキー。 |
|
ブラウザー向けの Ops Kibana 証明書用に使用される CA ファイルへの制御ノード上の絶対パス。 |
32.4. EFK スタックのデプロイ
EFK スタックは Ansible Playbook を使用して EFK コンポーネントにデプロイされます。デフォルトのインベントリーファイルを使用して、デフォルトの OpenShift Ansible の場所から Playbook を実行します。
$ ansible-playbook [-i </path/to/inventory>] \ /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml
Playbook を実行すると、スタックをサポートするために必要なすべてのリソース (シークレット、ServiceAccount、DeploymentConfig など) がデプロイされます。Playbook はスタックが実行されるまでコンポーネント Pod のデプロイを待機します。待機手順が失敗しても、デプロイメントは成功する可能性があります。つまり、レジストリーからコンポーネントイメージを取得できる場合があります。これには数分の時間がかかる可能性があります。以下を使用してプロセスを確認できます。
$ oc get pods -w
最終的に Pod のステータスは Running になります。関連イベントの取得によるデプロイメント時の Pod のステータスを確認するには、以下を実行します。
$ oc describe pods/<pod_name>
Pod の実行に失敗したら、ログを確認してください。
$ oc logs -f <pod_name>
32.5. デプロイメントの概要と調整
このセクションでは、デプロイされたコンポーネントに対して行うことができる調整について説明します。
32.5.1. Ops クラスター
default、openshift、および openshift-infra プロジェクトのログが自動的に集計され、Kibana インターフェースで .operations 項目にグループ化されます。
EFK スタックをデプロイしたプロジェクト (ここでは logging) は .operations に集計 されず、その ID の下に表示されます。
インベントリーファイルで openshift_logging_use_ops
を true に設定した場合、Fluentd はメインの Elasticsearch クラスターと操作ログ用に予約された別のクラスター間でログを分割するように設定されます。この操作ログはノードシステムログおよびプロジェクト default、openshift、openshift-infra として定義されています。したがって、操作ログのインデックス化、アクセス、管理を行うために個別の Elasticsearch クラスター、個別の Kibana、および個別の Curator がデプロイされます。これらのデプロイメントは、-ops
を含む名前によって区別されます。このオプションを有効にする場合は、これらの個別のデプロイメントに留意してください。-ops
が含まれるという名前の変更はありますが、以下の説明の大部分が操作クラスターにも適用されます (存在する場合)。
32.5.2. Elasticsearch
高可用性環境には、それぞれが別のホスト上にある Elasticsearch のレプリカが少なくとも 3 つ必要です。Elasticsearch レプリカには各自のストレージが必要ですが、OpenShift Container Platform のデプロイメント設定ではすべての Pod 間でストレージボリュームを共有します。そのため、拡張時には、EFK デプロイヤーによって Elasticsearch の各レプリカに各自のデプロイメント設定が行われます。
インベントリーファイルで openshift_logging_es_cluster_size
を変更し、ロギング Playbook を再実行することで、作成後にクラスターを拡張することができます。追加のクラスタリングパラメーターは変更可能で、「 ロギング Ansible 変数の指定」で説明されています。
以下に示すようにストレージおよびネットワークの場所を選択する際の留意事項については、Elastic のドキュメントを参照してください。
すべての Elasticsearch デプロイメントの表示
現在の Elasticsearch デプロイメントをすべて表示するには、以下を実行します。
$ oc get dc --selector logging-infra=elasticsearch
ノードセレクター
Elasticsearch は大量のリソースを使用する可能性があるため、クラスターのすべてのメンバーでは、メンバー同士およびリモートストレージとのネットワーク接続の待機時間を短く設定する必要があります。待機時間を短く設定するには、ノードセレクターを使用してインスタンスを専用ノード、つまりクラスター内の専用リージョンに指定します。
ノードセレクターを設定するには、インベントリーファイルで openshift_logging_es_nodeselector
設定オプションを指定します。これはすべての Elasticsearch デプロイメントに適用されます。そのため、ノードセレクターを個別化する必要がある場合は、デプロイメント後に各デプロイメント設定を手動で編集する必要があります。ノードセレクターは Python と互換性のある dict (辞書) として指定されます。たとえば、{"node-type":"infra", "region":"east"}
のようになります。
永続的な Elasticsearch ストレージ
デフォルトでは、openshift_logging
Ansible ロールは Pod のすべてのデータが再起動時に消失する一時デプロイメントを作成します。実稼働環境での使用では、Elasticsearch デプロイメント設定ごとに永続ストレージボリュームを指定します。デプロイ前に必要な Persistent Volume Claim (永続ボリューム要求) を作成するか、またはそれらを独自に作成されるようにできます。PVC には openshift_logging_es_pvc_prefix
設定 (デフォルトでは logging-es-
) と一致する名前を付ける必要があります。各 PVC 名には連番が追加され、logging-es-1
、logging-es-2
などのようになります。デプロイメントに必要な PVC がすでに存在する場合は、その PVC が使用されます。PVC が存在せず、openshift_logging_es_pvc_size
が指定されている場合は、そのサイズ要求を使用して PVC が作成されます。
Lucene は NFS でサポートされていないファイルシステムの動作に依存するため、NFS ストレージをボリュームまたは永続ボリュームとして (または Gluster などの NAS を介して) 使用することは Elasticsearch ストレージではサポートされません。その場合、データ破損やその他の問題が発生する可能性があります。NFS ストレージが要件である場合は、大規模なファイルをボリュームに配置してストレージデバイスとして使用し、1 つのホスト上でそれをローカルにマウントすることができます。たとえば、NFS ストレージボリュームが /nfs/storage にマウントされている場合は、以下のようになります。
$ truncate -s 1T /nfs/storage/elasticsearch-1 $ mkfs.xfs /nfs/storage/elasticsearch-1 $ mount -o loop /nfs/storage/elasticsearch-1 /usr/local/es-storage $ chown 1000:1000 /usr/local/es-storage
次に、以下で説明するように /usr/local/es-storage をホストマウントとして使用します。異なるバッキングファイルをそれぞれの Elasticsearch レプリカのストレージとして使用します。
このループバックはノード上で、OpenShift Container Platform の外部から手動で保守する必要があります。コンテナー内から保守することはできません。
各ノードホスト上のローカルディスクボリューム (利用可能な場合) を Elasticsearch レプリカのストレージとして使用することができます。これを実行するには、以下のような準備が必要です。
関連するサービスアカウントに、ローカルボリュームをマウントし、編集する権限を指定する必要があります。
$ oc adm policy add-scc-to-user privileged \ system:serviceaccount:logging:aggregated-logging-elasticsearch 1
- 1
- ロギング Playbook を実行する際に、以前に作成したプロジェクトを使用します (例: logging)。
それぞれの Elasticsearch レプリカの定義にパッチを適用し、その権限を要求する必要があります。以下に例を示します (Ops クラスターの場合は
--selector component=es-ops
に変更)。$ for dc in $(oc get deploymentconfig --selector component=es -o name); do oc scale $dc --replicas=0 oc patch $dc \ -p '{"spec":{"template":{"spec":{"containers":[{"name":"elasticsearch","securityContext":{"privileged": true}}]}}}}' done
Elasticsearch レプリカは、ローカルストレージを使用するために適切なノード上に配置する必要があります。また、適切なノードが一定期間ダウンしている場合であっても、移動させてはなりません。この場合は、管理者がストレージを割り当てたノードに対して一意のノードセレクターを各 Elasticsearch レプリカに提供する必要があります。ノードセレクターを設定するには、各 Elasticsearch デプロイメント設定を編集し、nodeSelector セクションを追加または編集して、必要な各ノードに対して適用した一意のラベルを指定します。
apiVersion: v1 kind: DeploymentConfig spec: template: spec: nodeSelector: logging-es-node: "1" 1
- 1
- このラベル (この場合は
logging-es-node=1
) が付与されている単一のノードを持つレプリカを、ラベルによって一意に識別する必要があります。oc label
コマンドを使用して、必要に応じてノードにラベルを適用してください。
代わりに
oc patch
コマンドを使用して、ノードセレクターの適用を自動化することもできます。$ oc patch dc/logging-es-<suffix> \ -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-es-node":"1"}}}}}'
これらの手順を実行すると、この例 (ストレージが各ノードの同じパスにマウントされていることを前提とします) のように、ローカルホストのマウントを各レプリカに適用できます (Ops クラスターの場合は
--selector component=es-ops
に変更します)。$ for dc in $(oc get deploymentconfig --selector component=es -o name); do oc set volume $dc \ --add --overwrite --name=elasticsearch-storage \ --type=hostPath --path=/usr/local/es-storage oc rollout latest $dc oc scale $dc --replicas=1 done
Elasticsearch のスケールの変更
クラスターで使用される Elasticsearch インスタンスの数を増やす必要がある場合、このタスクは永続ボリュームの特性や、データの保存やクラスターのリカバリーに関する Elasticsearch の設定方法により、Elasticsearch デプロイメント設定の拡張ほど簡単に実行できません。また、拡張時には各 Elasticsearch クラスターノードのデプロイメント設定を作成する必要があります。
Elasticsearch のスケールを変更する最も簡単な方法は、前述のようにインベントリーホストファイルを変更し、ロギング Playbook を再実行することです。デプロイメント用に永続ストレージが提供されていると仮定すると、この方法によって混乱が生じることはないはずです。
新しい openshift_logging_es_cluster_size
の値が、クラスターにある現在の Elasticsearch のノード数 (スケールアップした後) より大きい場合のみ、ロギング Playbook を使用して Elasticsearch クラスターのサイズを調節できます。
カスタマイズを維持する必要があるなどの理由で再インストールを希望しない場合は、デプロイヤーによって提供されるテンプレートを使用して、新規の Elasticsearch デプロイメント設定をクラスターに追加することができます。ただし、これにはより複雑な手順が必要になります。
ルートとしての Elasticsearch の公開
デフォルトでは、OpenShift の集計ロギングでデプロイされた Elasticsearch はロギングクラスターの外部からアクセスできません。データにアクセスする必要があるツールに対しては、Elasticsearch への外部アクセスのルートを有効にすることができます。
OpenShift トークンを使用して Elasticsearch にアクセスできます。また、サーバー証明書を作成する際に (Kibana と同様に)、外部の Elasticsearch および Elasticsearch Ops ホスト名を指定することができます。
re-encrypt ルートとして Elasticsearch にアクセスするには、以下の変数を定義します。
openshift_logging_es_allow_external=True openshift_logging_es_hostname=elasticsearch.example.com
以下の Ansible Playbook を実行します。
$ ansible-playbook [-i </path/to/inventory>] \ /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml
Elasticsearch にリモートでログインするには、要求に 3 つの HTTP ヘッダーが含まれている必要があります。
Authorization: Bearer $token X-Proxy-Remote-User: $username X-Forwarded-For: $ip_address
ログにアクセスできるようになるには、プロジェクトへのアクセスが必要です。以下は例になります。
$ oc login <user1> $ oc new-project <user1project> $ oc new-app <httpd-example>
要求内で使用するこの ServiceAccount のトークンを取得する必要があります。
$ token=$(oc whoami -t)
以前に設定したトークンを使用して、公開ルート経由で Elasticsearch にアクセスできる必要があります。
$ curl -k -H "Authorization: Bearer $token" -H "X-Proxy-Remote-User: $(oc whoami)" -H "X-Forwarded-For: 127.0.0.1" https://es.example.test/project.my-project.*/_search?q=level:err | python -mjson.tool
32.5.3. Fluentd
Fluentd はノードラベルセレクターに従ってレプリカをデプロイする DeamonSet としてデプロイされます。ノードラベルセレクターはインベントリーパラメーター openshift_logging_fluentd_nodeselector
を使用して指定することができ、デフォルトは logging-infra-fluentd
です。OpenShift クラスターのインストールの一環として、Fluentd ノードセレクターを永続化されたノードラベル の一覧に追加することが推奨されます。
Fluentd は journald
をシステムログソースとして使用します。これらは、オペレーティングシステム、コンテナーランタイム、および OpenShift からのログメッセージです。
OpenShift Container Platform 3.9 のクリーンインストールではデフォルトのログドライバーとして json-file
を使用します。ただし、OpenShift Container Platform 3.7 からアップグレードされた環境では既存の journald
ログドライバーの設定が維持されます。json-file
ログドライバーを使用することが推奨されます。既存のログドライバー設定を json-file
に変更する手順については、「集計されたロギングドライバーの変更」を参照してください。
外部ログアグリゲーターにログを送信するための Fluentd の設定
secure-forward
プラグインを使用して、デフォルトの Elasticsearch ではなく外部のログアグリゲーターにログのコピーを送信するように Fluentd を設定することができます。ここから、ローカルでホストされている Fluentd によるログレコードの処理後に、さらなるログの処理が可能です。
ロギングデプロイメントでは、外部アグリゲーターを設定するための secure-forward.conf
セクションが Fluentd configmap に用意されています。
<store> @type secure_forward self_hostname pod-${HOSTNAME} shared_key thisisasharedkey secure yes enable_strict_verification yes ca_cert_path /etc/fluent/keys/your_ca_cert ca_private_key_path /etc/fluent/keys/your_private_key ca_private_key_passphrase passphrase <server> host ose1.example.com port 24284 </server> <server> host ose2.example.com port 24284 standby </server> <server> host ose3.example.com port 24284 standby </server> </store>
oc edit
コマンドを使用して更新できます。
$ oc edit configmap/logging-fluentd
secure-forward.conf
で使用される証明書を Fluentd Pod にマウントされる既存のシークレットに追加することができます。your_ca_cert
と your_private_key
の値は configmap/logging-fluentd
の secure-forward.conf
で指定されている値と一致している必要があります。
$ oc patch secrets/logging-fluentd --type=json \ --patch "[{'op':'add','path':'/data/your_ca_cert','value':'$(base64 /path/to/your_ca_cert.pem)'}]" $ oc patch secrets/logging-fluentd --type=json \ --patch "[{'op':'add','path':'/data/your_private_key','value':'$(base64 /path/to/your_private_key.pem)'}]"
your_private_key
は、汎用名に置き換えます。これは、JSON パスへのリンクで、お使いのホストシステムのパスではありません。
外部アグリゲーターを設定する際は、Fluentd からのメッセージを安全に受信できる必要があります。
外部アグリゲーターが別の Fluentd サーバーである場合、fluent-plugin-secure-forward
プラグインがインストールされていて、それによって提供される入力プラグインを使用する必要があります。
<source> @type secure_forward self_hostname ${HOSTNAME} bind 0.0.0.0 port 24284 shared_key thisisasharedkey secure yes cert_path /path/for/certificate/cert.pem private_key_path /path/for/certificate/key.pem private_key_passphrase secret_foo_bar_baz </source>
fluent-plugin-secure-forward
プラグインの設定方法に関する説明はこちらを参照してください。
Fluentd から API サーバーへの接続数の削減
mux
はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。
mux
は Secure Forward のリスナーサービスです。
パラメーター | 説明 |
---|---|
|
デフォルトは |
|
|
|
デフォルトは |
|
デフォルトは |
|
24284 |
|
500M |
|
1Gi |
|
デフォルトは |
|
デフォルト値は空であり、外部の |
Fluentd でのログのスロットリング
特に冗長なプロジェクトについては、管理者は処理される前の Fluentd によるログの読み取り速度を減速することができます。
スロットリングは設定されたプロジェクトのログ集計が遅れる一因になる可能性があります。Fluentd が追い付く前に Pod が削除された場合、ログエントリーが消失する可能性があります。
Systemd ジャーナルをログソースとして使用している場合、スロットリングは機能しません。スロットリングの実装は、各プロジェクトの個々のログファイルの読み取りを調整できる機能によって決まります。ジャーナルからの読み取り時に、単一のログソースしか存在せず、ログファイルは存在しないと、ファイルベースのスロットリングは利用できません。Fluentd プロセスに読み込まれるログエントリーを制限する方法はありません。
Fluentd に対して制限する必要があるプロジェクトを指示するには、デプロイメント後に ConfigMap のスロットル設定を編集します。
$ oc edit configmap/logging-fluentd
throttle-config.yaml キーの形式は、プロジェクト名と、各ノードでのログの読み取りに必要な速度が含まれる YAML ファイルです。デフォルトはノードごとに一度に 1,000 行です。以下に例を示します。
- プロジェクト
project-name: read_lines_limit: 50 second-project-name: read_lines_limit: 100
- ロギング
logging: read_lines_limit: 500 test-project: read_lines_limit: 10 .operations: read_lines_limit: 100
EFK スタックのいずれかの部分を変更する場合は (具体的には Elasticsearch または Fluentd)、まず Elasicsearch をゼロにスケールダウンして、他のノードと一致しないように Fluentd を調整する必要があります。次に、変更を行って、Elasicsearch と Fluentd のスケールを元に戻します。
Elasicsearch をゼロに調整するには、以下を実行します。
$ oc scale --replicas=0 dc/<ELASTICSEARCH_DC>
デーモンセット設定の nodeSelector がゼロに一致するように変更します。
Fluentd ノードセレクターを取得します。
$ oc get ds logging-fluentd -o yaml |grep -A 1 Selector nodeSelector: logging-infra-fluentd: "true"
oc patch
コマンドを使用して、deamonset の nodeSelector を変更します。
$ oc patch ds logging-fluentd -p '{"spec":{"template":{"spec":{"nodeSelector":{"nonexistlabel":"true"}}}}}'
Fluentd ノードセレクターを取得します。
$ oc get ds logging-fluentd -o yaml |grep -A 1 Selector nodeSelector: "nonexistlabel: "true"
Elastcsearch のサイズをゼロから元に戻します。
$ oc scale --replicas=# dc/<ELASTICSEARCH_DC>
deamonset 設定の nodeSelector を変更して logging-infra-fluentd: "true" に戻します。
oc patch
コマンドを使用して、deamonset の nodeSelector を変更します。
oc patch ds logging-fluentd -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-fluentd":"true"}}}}}'
32.5.4. Kibana
OpenShift Container Platform の Web コンソールから Kibana コンソールにアクセスするには、マスター webconsole-config configmap ファイルに loggingPublicURL
パラメーターを追加し、Kibana コンソールの URL (kibana-hostname
パラメーター) を指定します。値は HTTPS URL である必要があります。
... clusterInfo: ... loggingPublicURL: "https://kibana.example.com" ...
loggingPublicURL
パラメーターを設定すると、OpenShift Container Platform Web コンソールの Browse
通常通り Kiabana デプロイメントを拡張して冗長性を実現できます。
$ oc scale dc/logging-kibana --replicas=2
ロギング Playbook の複数の実行にわたってスケールを維持するには、インベントリーファイルの openshift_logging_kibana_replica_count
を必ず更新してください。
openshift_logging_kibana_hostname
変数によって指定されたサイトにアクセスすることで、ユーザーインターフェースを確認できます。
Kibana に関する詳細については、Kibana のドキュメントを参照してください。
Kibana Visualize
Kibana Visualize を使用すると、視覚化機能やダッシュボードを作成してコンテナーを監視できます。また Pod ログにより、管理者ユーザー (cluster-admin
または cluster-reader
) はデプロイメント、namespace、Pod、およびコンテナーごとにログを表示することができます。
Kibana Visualize は Elasticsearch および ES-OPS Pod 内に存在し、それらの Pod 内で実行する必要があります。ダッシュボードとその他の Kibana UI オブジェクトを読み込むには、まずはダッシュボードに追加するユーザーとして Kibana にログインしてから、ログアウトする必要があります。これにより、以下の手順で使用するユーザーごとの必要な設定が作成されます。次に、以下を実行します。
$ oc exec <$espod> -- es_load_kibana_ui_objects <user-name>
ここで、$espod
はいずれかの Elasticsearch Pod の名前です。
32.5.5. Curator
Curator を利用することで、管理者はスケジュールされた Elasticsearch のメンテナンス操作を設定し、プロジェクトごとに自動的に実行することができます。これは、設定に基づいてアクションを毎日実行するようにスケジュール設定されています。Elasticsearch クラスターごとに 1 つの Curator Pod のみを使用することが推奨されます。Curator は以下の構造を持つ YAML 設定ファイルで設定されます。
$PROJECT_NAME: $ACTION: $UNIT: $VALUE $PROJECT_NAME: $ACTION: $UNIT: $VALUE ...
利用可能なパラメーターを以下に示します。
変数名 | 説明 |
---|---|
|
プロジェクトの実際の名前 (myapp-devel など)。OpenShift Container Platform の操作ログについては、名前 |
|
実行するアクション。現在許可されているのは |
|
|
|
単位数を示す整数。 |
|
|
|
(数値) Curator ジョブを実行する時刻 (時、24 時間形式)。 |
|
(数値) Curator ジョブを実行する時刻 (分)。 |
|
(文字列) tzselect(8) または timedatectl(1) 形式での文字列。デフォルトのタイムゾーンは UTC です。 |
|
プロジェクト名に一致する正規表現の一覧。 |
|
適切にエスケープされた有効な正規表現パターン。一重引用符で囲まれています。 |
たとえば、以下のように Curator を設定します。
-
1 day
を経過した myapp-dev プロジェクトのインデックスを削除する -
1 week
を経過した myapp-qe プロジェクトのインデックスを削除する -
8 weeks
を経過したoperations ログを削除する -
31 days
を経過したその他すべてのプロジェクトのインデックスを削除する - 毎日午前 0 時に Curator ジョブを実行する
以下を使用します。
config.yaml: | myapp-dev: delete: days: 1 myapp-qe: delete: weeks: 1 .operations: delete: weeks: 8 .defaults: delete: days: 31 runhour: 0 runminute: 0 timezone: America/New_York .regex: - pattern: '^project\..+\-dev\..*$' delete: days: 15 - pattern: '^project\..+\-test\..*$' delete: days: 30
month
を操作の $UNIT
として使用する場合、Curator は今月の当日ではなく、今月の最初の日からカウントを開始します。たとえば、今日が 4 月 15 日であり、現時点で 2 カ月を経過したインデックスを削除する場合 (delete: months: 2)、Curator は 2 月 15 日より古い日付のインデックスを削除するのではなく、2 月 1 日より古いインデックスを削除します。つまり、今月の最初の日付まで遡り、次にその日付から丸 2 カ月遡ります。Curator で厳密な指定を行うための最適な方法として、日数で指定することができます (例: delete: days: 30
)。
32.5.5.1. Curator 設定の作成
openshift_logging
Ansible ロールは、Curator が設定の読み取りに使用する ConfigMap を提供します。この ConfigMap を編集するか、または置き換えることで、Curator を再設定することができます。現時点で、Ops および非 Ops 両方の Curator インスタンスを設定するために logging-curator
ConfigMap が使用されています。.operations
設定はすべてアプリケーションログ設定と同じ場所にあります。
提供された ConfigMap を編集して Curator インスタンスを設定するには、以下を実行します。
$ oc edit configmap/logging-curator
提供された ConfigMap を置換するには、以下を実行します。
$ create /path/to/mycuratorconfig.yaml $ oc create configmap logging-curator -o yaml \ --from-file=config.yaml=/path/to/mycuratorconfig.yaml | \ oc replace -f -
変更を行った後に、Curator を再デプロイします。
$ oc rollout latest dc/logging-curator $ oc rollout latest dc/logging-curator-ops
32.6. クリーンアップ
デプロイメント中に生成されたものをすべて削除します。
$ ansible-playbook [-i </path/to/inventory>] \ /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml \ -e openshift_logging_install_logging=False
32.7. Kibana のトラブルシューティング
OpenShift Container Platform で Kibana コンソールを使用することで発生する可能性がある問題は簡単に解決できますが、この場合役に立つエラーメッセージは表示されません。OpenShift Container Platform に Kibana をデプロイする際に問題が発生した場合は、以下のトラブルシューティングセクションを確認してください。
ログインループ
Kibana コンソールの OAuth2 プロキシーはマスターホストの OAuth2 サーバーとシークレットを共有する必要があります。シークレットが両方のサーバーで同一でない場合はログインループが発生する可能性があり、Kibana のログインページに継続的にリダイレクトされます。
この問題を修正するには、現在の OAuthClient を削除し、openshift-ansible
を使用して openshift_logging
ロールを再実行します。
$ oc delete oauthclient/kibana-proxy $ ansible-playbook [-i </path/to/inventory>] \ /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml
コンソール表示時の不明なエラー
Kibana コンソールにアクセスしようとする際に、以下のブラウザーエラーが表示される場合があります。
{"error":"invalid_request","error_description":"The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed."}
このエラーは、OAuth2 クライアントとサーバー間の不一致が原因で発生します。ログイン後にサーバーが安全にリダイレクトできるように、クライアントのリターンアドレスがホワイトリストで指定されている必要があります。
この問題を修正するには、OAuthClient エントリーを置き換えます。
$ oc delete oauthclient/kibana-proxy $ ansible-playbook [-i </path/to/inventory>] \ /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml
問題が解決しない場合は、OAuth クライアントに一覧表示されている URL の Kibana にアクセスしていることを確認してください。この問題は、転送先ポート (標準の 443 HTTPS ポートではなく 1443 など) の URL にアクセスすることで発生する可能性があります。OAuth クライアントを編集することで、サーバーのホワイトリストを調整できます。
$ oc edit oauthclient/kibana-proxy
コンソール表示時の 503 エラー
Kibana コンソールを表示する時にプロキシーエラーが発生する場合は、2 つの問題のうちのいずれかが原因である可能性があります。
1 つ目の問題は、Kibana が Pod を認識していない可能性があります。Elasticsearch の起動が遅い場合、Kibana はそれに到達しようとしてタイムアウトする場合があります。関連サービスにエンドポイントがあるかどうか確認してください。
$ oc describe service logging-kibana Name: logging-kibana [...] Endpoints: <none>
Kibana Pod が実行中である場合、エンドポイントが一覧表示されます。実行中でない場合は、Kibana Pod とデプロイメントの状態を確認してください。デプロイメントをスケールダウンして、再び元に戻さなければならない場合があります。
考えられる 2 つ目の問題として、Kibana サービスにアクセスするためのルートがマスクされている場合に発生する可能性があります。これは、あるプロジェクトでテストデプロイメントを実行し、次に最初のデプロイメントを完全に削除することなく別のプロジェクトでデプロイした場合に発生する可能性があります。複数のルートが同じ宛先に送信される場合、デフォルトルーターは最初に作成されたルートにのみルーティングします。問題が発生するルートをチェックして、そのルートが複数の場所で定義されているかどうかを確認してください。
$ oc get route --all-namespaces --selector logging-infra=support
F-5 ロードバランサーと有効にされた X-Forwarded-For
X-Forwarded-For
が有効にされた Kibana の前に F-5 ロードバランサーの使用を試みる場合、Elasticsearch Searchguard
プラグインが Kibana からの接続を適切に受け取ることができないという問題が発生する可能性があります。
Kibana のエラーメッセージの例
Kibana: Unknown error while connecting to Elasticsearch Error: Unknown error while connecting to Elasticsearch Error: UnknownHostException[No trusted proxies]
余分なヘッダーを無視するように Searchguard を設定するには、以下の手順を実行します。
- すべての Fluentd Pod をスケールダウンします。
- Fluentd Pod の終了後に Elasticsearch をスケールダウンします。
searchguard.http.xforwardedfor.header: DUMMY
を Elasticsearch の設定セクションに追加します。$ oc edit configmap/logging-elasticsearch 1
- 1
- この方法では、Elasticsearch の設定が ConfigMap に含まれている必要があります。
- Elasticsearch を拡張して元に戻します。
- すべての Fluentd Pod を拡張します。
32.8. 外部 Elasticsearch インスタンスへのログの送信
Fluentd は、Elasticsearch デプロイメント設定の ES_HOST
、ES_PORT
、OPS_HOST
、および OPS_PORT
環境変数の値にログを送信します。アプリケーションログは ES_HOST
の宛先に、操作ログは OPS_HOST
の宛先に送信されます。
AWS Elasticsearch インスタンスへのログの直接送信はサポートされていません。Fluentd Secure Forward を使用して、fluent-plugin-aws-elasticsearch-service
プラグインで設定した制御対象の Fluentd のインスタンスにログを送信してください。
ログを特定の Elasticsearch インスタンスに送信するには、デプロイメント設定を編集して、上記の変数の値を必要なインスタンスに置き換えます。
$ oc edit dc/<deployment_configuration>
外部 Elasticsearch インスタンスにアプリケーションログと操作ログの両方を含めるには、ES_HOST
と OPS_HOST
を同じ宛先に設定して、ES_PORT
と OPS_PORT
にも同一の値があるようにします。
外部でホストされている Elasticsearch インスタンスが TLS を使用していない場合、_CLIENT_CERT
、_CLIENT_KEY
、_CA
変数を空になるように更新します。TLS を使用していてもそれが Mutual TLS ではない場合は、_CLIENT_CERT
と _CLIENT_KEY
変数を空になるように更新し、logging-fluentd シークレットについて、Elasticsearch インスタンスと通信するための適切な _CA
値でパッチを適用するか再作成します。指定された Elasticsearch インスタンスと同様に Mutual TLS を使用している場合、logging-fluentd シークレットについて、クライアントキー、クライアント証明書、CA を使ってパッチを適用するか再作成します。
指定された Kibana と Elasticsearch イメージを使用していない場合、同じマルチテナント機能は利用できず、データは特定のプロジェクトへのユーザーアクセスによる制限を受けません。
32.9. 外部 syslog サーバーへのログの送信
fluent-plugin-remote-syslog
プラグインをホストで使用して、ログを外部 syslog サーバーに送信します。
環境変数を logging-fluentd
または logging-mux
デプロイメント設定で設定します。
- name: REMOTE_SYSLOG_HOST 1
value: host1
- name: REMOTE_SYSLOG_HOST_BACKUP
value: host2
- name: REMOTE_SYSLOG_PORT_BACKUP
value: 5555
- 1
- 必要なリモート syslog ホスト。各ホストで必須です。
これによって 2 つの宛先が作成されます。host1
の syslog サーバーはデフォルトポート 514
でメッセージを受信し、host2
は同じメッセージをポート 5555
で受信します。
または、独自のカスタム fluent.conf を logging-fluentd
または logging-mux
ConfigMap に設定できます。
Fluentd 環境変数
パラメーター | 説明 |
---|---|
|
デフォルトは |
|
(必須) リモート syslog サーバーのホスト名または IP アドレス。 |
|
接続先のポート番号。デフォルトは |
|
syslog の重大度を設定します。デフォルトは |
|
syslog ファシリティーを設定します。デフォルトは |
|
デフォルトは |
|
タグからプレフィックスを削除します。デフォルトは |
|
これが指定されている場合、このフィールドをキーとして使用してレコードを検索し、syslog メッセージにタグを設定します。 |
|
これが指定されている場合、このフィールドをキーとして使用してレコードを検索し、syslog メッセージにペイロードを設定します。 |
この実装は安全ではないため、接続にスヌーピングがないことを保証できる環境でのみ使用してください。
Fluentd ロギング Ansible 変数
パラメーター | 説明 |
---|---|
|
デフォルトは |
|
リモート syslog サーバーのホスト名または IP アドレス。必須です。 |
|
接続先のポート番号。デフォルトは |
|
syslog の重大度を設定します。デフォルトは |
|
syslog ファシリティーを設定します。デフォルトは |
|
デフォルトは |
|
タグからプレフィックスを削除します。デフォルトは |
|
文字列が指定された場合、このフィールドをキーとして使用してレコードを検索し、syslog メッセージにタグを設定します。 |
|
文字列が指定された場合、このフィールドをキーとして使用してレコードを検索し、syslog メッセージにペイロードを設定します。 |
Mux ロギング Ansible 変数
パラメーター | 説明 |
---|---|
|
デフォルトは |
|
リモート syslog サーバーのホスト名または IP アドレス。必須です。 |
|
接続先のポート番号。デフォルトは |
|
syslog の重大度を設定します。デフォルトは |
|
syslog ファシリティーを設定します。デフォルトは |
|
デフォルトは |
|
タグからプレフィックスを削除します。デフォルトは |
|
文字列が指定された場合、このフィールドをキーとして使用してレコードを検索し、syslog メッセージにタグを設定します。 |
|
文字列が指定された場合、このフィールドをキーとして使用してレコードを検索し、syslog メッセージにペイロードを設定します。 |
32.10. Elasticsearch 管理操作の実行
Elasticsearch と通信して管理操作を実行するのに使用する管理者の証明書、キー、CA は、logging-elasticsearch シークレット内にあります。
これらが EFK インストールにあるかどうかを確認するには、以下のコマンドを実行します。
$ oc describe secret logging-elasticsearch
これらがない場合は、「手動でのアップグレード方法」を参照して、最新バージョンを使用していることをまず確認してください。
- メンテナンスを実行しようとしているクラスター内にある Elasticsearch Pod に接続します。
Pod をクラスター内で検索するには、以下のいずれかのコマンドを使用します。
$ oc get pods -l component=es -o name | head -1 $ oc get pods -l component=es-ops -o name | head -1
Pod に接続します。
$ oc rsh <your_Elasticsearch_pod>
Elasticsearch コンテナーに接続すると、インデックス API のマニュアルに従い、シークレットからマウントされた証明書を使用して Elasticsearch と通信することができます。
Fluentd では、インデックス形式 project.{project_name}.{project_uuid}.YYYY.MM.DD を使用してログを Elasticsearch に送信します。ここで、YYYY.MM.DD はログレコードの日付です。
たとえば uuid が 3b3594fa-2ccd-11e6-acb7-0eb6b35eaee3 の logging プロジェクトから 2016 年 6 月 15 日以降のすべてのログを削除するには、以下のコマンドを実行します。
$ curl --key /etc/elasticsearch/secret/admin-key \ --cert /etc/elasticsearch/secret/admin-cert \ --cacert /etc/elasticsearch/secret/admin-ca -XDELETE \ "https://localhost:9200/project.logging.3b3594fa-2ccd-11e6-acb7-0eb6b35eaee3.2016.06.15"
32.11. 集計されたロギングのドライバーの変更
集計されたロギングについては、json-file
ログドライバーの使用を推奨します。
json-file
ドライバーを使用する場合は、Docker バージョン docker-1.12.6-55.gitc4618fb.el7_4 now 以降を使用していることを確認してください。
Fluentd では、/etc/docker/daemon.json ファイルおよび /etc/sysconfig/docker ファイルをチェックして、Docker が使用しているドライバーを判別します。
docker info
コマンドを使用すると、Docker が使用しているドライバーを確認できます。
# docker info | grep Logging Logging Driver: journald
json-file
に変更するには、以下の手順に従います。
/etc/sysconfig/docker ファイルまたは /etc/docker/daemon.json ファイルのいずれかを変更します。
例を以下に示します。
# cat /etc/sysconfig/docker OPTIONS=' --selinux-enabled --log-driver=json-file --log-opt max-size=1M --log-opt max-file=3 --signature-verification=False' cat /etc/docker/daemon.json { "log-driver": "json-file", "log-opts": { "max-size": "1M", "max-file": "1" } }
Docker サービスを再起動します。
systemctl restart docker
Fluentd を再起動します。
警告13 以上のノードで一度に Fluentd を再起動すると、Kubernetes スケジューラーに大きな負荷が生成されます。以下の手順に従って Fluentd を再起動する場合は、細心の注意を払ってください。
Fluentd を再起動する方法は 2 つあります。1 つのノードまたはノードセット上で Fluentd を再起動するか、またはすべてのノードで Fluentd を再起動できます。
以下の手順は、1 つのノードまたはノードセット上で Fluentd を再起動する方法を示しています。
Fluentd が実行しているノードの一覧を表示します。
$ oc get nodes -l logging-infra-fluentd=true
各ノードについて、ラベルを削除して Fluentd をオフにします。
$ oc label node $node logging-infra-fluentd-
Fluentd がオフになっていることを確認します。
$ oc get pods -l component=fluentd
各ノードについて Fluentd を再起動します。
$ oc label node $node logging-infra-fluentd=true
以下の手順は、すべてのノード上で Fluentd を再起動する方法を示しています。
すべてのノードで Fluentd をオフにします。
$ oc label node -l logging-infra-fluentd=true --overwrite logging-infra-fluentd=false
Fluentd がオフになっていることを確認します。
$ oc get pods -l component=fluentd
すべてのノードで Fluentd を再起動します。
$ oc label node -l logging-infra-fluentd=false --overwrite logging-infra-fluentd=true
Fluentd がオンになっていることを確認します。
$ oc get pods -l component=fluentd
32.12. Elasticsearch の手動ロールアウト
OpenShift Container Platform 3.7 では Aggregated Logging スタックで Elasticsearch Deployment Config オブジェクトが更新され、Config Change Trigger が除外されました。このため、dc
を変更しても自動ロールアウトは実行されなくなります。これは、ES クラスターで意図しない再起動を回避するものでしたが、クラスターメンバーの再起動時にシャードのリバランスが過剰に発生しまう可能性があります。
このセクションでは、ローリング再起動とフル再起動の 2 つの再起動手順を説明します。ローリング再起動はダウンタイムを発生させずに Elasticsearch クラスターに適切な変更を適用し (3 つのマスターが設定されている場合)、フル再起動は既存データを損なわずに大規模な変更を安全に適用します。
32.12.1. Elasticsearch ローリングクラスター再起動の実行
以下のいずれかの変更を行う場合は、ローリング再起動を推奨します。
- Elasticsearch Pod の実行で再起動が必要なノード
- logging-elasticsearch configmap
- logging-es-* デプロイメント設定
- 新規イメージのデプロイメントまたはアップグレード
これは今後推奨される再起動ポリシーになります。
openshift_logging_use_ops
が True
に設定される場合、ES クラスターへのアクションを ops クラスターに対して繰り返す必要があります。
ノードを意図的に停止する際のシャードのバランシングを防止します。
$ oc exec -c elasticsearch <any_es_pod_in_the_cluster> -- curl -s --cacert /etc/elasticsearch/secret/admin-ca \ --cert /etc/elasticsearch/secret/admin-cert \ --key /etc/elasticsearch/secret/admin-key \ -XPUT 'https://localhost:9200/_cluster/settings' \ -d '{ "transient": { "cluster.routing.allocation.enable" : "none" } }'
完了したら、ES クラスターの各
dc
についてoc rollout latest
を実行して、最新バージョンのdc
オブジェクトをデプロイします。$ oc rollout latest <dc_name>
新しい Pod がデプロイされます。Pod に 2 つのコンテナーが準備できたら、以下の
dc
に進むことができます。クラスターのすべての「dc」がロールアウトされたら、シャードバランシングを再度有効にします。
$ oc exec -c elasticsearch <any_es_pod_in_the_cluster> -- curl -s --cacert /etc/elasticsearch/secret/admin-ca \ --cert /etc/elasticsearch/secret/admin-cert \ --key /etc/elasticsearch/secret/admin-key \ -XPUT 'https://localhost:9200/_cluster/settings' \ -d '{ "transient": { "cluster.routing.allocation.enable" : "all" } }'
32.12.2. Elasticsearch フルクラスター再起動の実行
Elasticsearch のメジャーバージョンの変更など、変更プロセス中にデータ整合性が損なわれる危険性がある変更の場合は、フル再起動を推奨します。
openshift_logging_use_ops
が True
に設定される場合、ES クラスターへのアクションを ops クラスターに対して繰り返す必要があります。
logging-es-ops
サービスに変更を行う場合は、パッチとして代わりにコンポーネント "es-ops-blocked" および "es-ops" を使用します。
ES クラスターが停止しているときに、ES クラスターへのすべての外部通信を無効にします。以下のコマンドを実行して、非クラスターロギングサービス (
logging-es
やlogging-es-ops
など) を編集して、ES Pod に一致しないようにします。$ oc patch svc/logging-es -p '{"spec":{"selector":{"component":"es-blocked","provider":"openshift"}}}'
シャードの同期フラッシュを実行して、シャットダウン前のディスクへの書き込みを待機している保留中の操作がないようにします。
$ oc exec -c elasticsearch <any_es_pod_in_the_cluster> -- curl -s --cacert /etc/elasticsearch/secret/admin-ca \ --cert /etc/elasticsearch/secret/admin-cert \ --key /etc/elasticsearch/secret/admin-key \ -XPOST 'https://localhost:9200/_flush/synced'
ノードを意図的に停止する際のシャードのバランシングを防止します。
$ oc exec -c elasticsearch <any_es_pod_in_the_cluster> -- curl -s --cacert /etc/elasticsearch/secret/admin-ca \ --cert /etc/elasticsearch/secret/admin-cert \ --key /etc/elasticsearch/secret/admin-key \ -XPUT 'https://localhost:9200/_cluster/settings' \ -d '{ "transient": { "cluster.routing.allocation.enable" : "none" } }'
完了したら、ES クラスターの各
dc
についてoc rollout latest
を実行して、最新バージョンのdc
オブジェクトをデプロイします。$ oc rollout latest <dc_name>
新しい Pod がデプロイされます。Pod に 2 つのコンテナーが準備できたら、以下の
dc
に進むことができます。再起動が完了したら、ES クラスターへのすべての外部通信を有効にします。以下のコマンドを再度実行して、非クラスターロギングサービス (
logging-es
やlogging-es-ops
など) を編集して、ES Pod に一致するようにします。$ oc patch svc/logging-es -p '{"spec":{"selector":{"component":"es","provider":"openshift"}}}'