37.2. インストールシステム
集計ロギングスタックを OpenShift Container Platform にインストールする一般的な手順は、コンテナーログの集計 に記載されています。インストールガイドを参照する際にいくつかの重要な事項に留意してください。
ロギング Pod をクラスター上に均等に分散させるため、プロジェクトの作成時に空の ノードセレクター を使用する必要があります。
oc adm new-project logging --node-selector=""
$ oc adm new-project logging --node-selector=""
これは、後で実行されるノードのラベリングと共に、ロギングプロジェクトへの Pod 配置を制御します。
Elasticsearch (ES) は、ノード障害に対する回復性を確保するために、少なくとも 3 つのクラスターサイズでデプロイする必要があります。これは openshift_logging_es_cluster_size
パラメーターをインベントリーホストファイルに設定することで指定されます。
パラメーターの詳細の一覧については、Ansible 変数 を参照してください。
Kibana には、アクセスに使用される任意のブラウザーから解決できるホスト名が必要です。たとえば、Kibana にラップトップで実行される Web ブラウザーからアクセスできるように Kibana の DNS エイリアスを企業名サービスに追加する必要がある場合があります。ロギングのデプロイでは、インフラストラクチャーノードの 1 つの Kibana にルートを作成するか、または OpenShift ルーターの実行中にルートを作成します。Kibana ホスト名のエイリアスはこのマシンを参照する必要があります。このホスト名は Ansible openshift_logging_kibana_hostname
変数として指定されます。
イメージがレジストリーからすでに取得されているかどうかや、クラスターのサイズによっては、インストールに時間がかかる場合があります。
openshift-logging プロジェクトの内部で、oc get all
を実行してデプロイメントを確認できます。
最終的には以下のようなセットアップになります。
デフォルトでは、各 ES インスタンスに割り当てられる RAM の容量は 16 GB です。openshift_logging_es_memory_limit
は openshift-ansible ホストインベントリーファイルで使用されるパラメーターです。この値の半分が個々の elasticsearch Pod java プロセスの ヒープサイズ に渡されることに注意してください。
EFK のインストールの詳細はこちら を参照してください。
37.2.1. 大規模クラスター リンクのコピーリンクがクリップボードにコピーされました!
ノードが 100 以上ある場合、最初に docker pull registry.redhat.io/openshift3/logging-fluentd:v3.11
からロギングイメージを事前にプルすることを推奨します。ロギングインフラストラクチャー Pod (Elasticsearch、Kibana、Curator) をデプロイしたら、ノードのラベリングを一度に 20 ノード単位で実行します。以下に例を示します。
単純なループを使用します。
while read node; do oc label nodes $node logging-infra-fluentd=true; done < 20_fluentd.lst
$ while read node; do oc label nodes $node logging-infra-fluentd=true; done < 20_fluentd.lst
以下の方法も有効です。
oc label nodes 10.10.0.{100..119} logging-infra-fluentd=true
$ oc label nodes 10.10.0.{100..119} logging-infra-fluentd=true
ノードをグループ化してラベリングすると、OpenShift ロギングで DaemonSet が一定のペースで使用されるので、イメージレジストリーなどの共有リソース上の競合を回避できます。
CrashLoopBackOff | ImagePullFailed | Error の問題が発生したかどうかを確認します。oc logs <pod>
、oc describe pod <pod>
および oc get event
は、役に立つ診断コマンドです。