第7章 クラスターロギングデプロイメントの設定
7.1. クラスターロギングの設定について リンクのコピーリンクがクリップボードにコピーされました!
クラスターロギングを OpenShift Container Platform クラスターにインストールした後に、以下の設定を行うことができます。
特に指示がない場合は、これらの設定を実行する前にクラスターロギングを管理外の状態に設定する必要があります。詳細は、クラスターロギングの管理状態の変更 を参照してください。
管理外の状態の Operator はサポートされず、クラスター管理者は個々のコンポーネント設定およびアップグレードを完全に制御していることを前提としています。詳細は、管理外の Operator のサポートポリシー を参照してください。
7.1.1. クラスターロギングのデプロイおよび設定について リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターロギングは、小規模および中規模の OpenShift Container Platform クラスター用に調整されたデフォルト設定で使用されるように設計されています。
以下のインストール方法には、サンプルの ClusterLogging カスタムリソース (CR) が含まれます。これを使用して、クラスターロギングインスタンスを作成し、クラスターロギングのデプロイメントを設定することができます。
デフォルトのクラスターロギングインストールを使用する必要がある場合は、サンプル CR を直接使用できます。
デプロイメントをカスタマイズする必要がある場合、必要に応じてサンプル CR に変更を加えます。以下では、クラスターロギングのインスタンスをインストール時に実行し、インストール後に変更する設定について説明します。ClusterLogging カスタムリソース外で加える変更を含む、各コンポーネントの使用方法については、設定についてのセクションを参照してください。
7.1.1.1. クラスターロギングの設定およびチューニング リンクのコピーリンクがクリップボードにコピーされました!
クラスターロギング環境は、openshift-logging プロジェクトにデプロイされる ClusterLogging カスタムリソースを変更することによって設定できます。
インストール時またはインストール後に、以下のコンポーネントのいずれかを変更することができます。
- メモリーおよび CPU
-
resourcesブロックを有効なメモリーおよび CPU 値で変更することにより、各コンポーネントの CPU およびメモリーの両方の制限を調整することができます。
spec:
logStore:
elasticsearch:
resources:
limits:
cpu:
memory: 16Gi
requests:
cpu: 500m
memory: 16Gi
type: "elasticsearch"
collection:
logs:
fluentd:
resources:
limits:
cpu:
memory:
requests:
cpu:
memory:
type: "fluentd"
visualization:
kibana:
resources:
limits:
cpu:
memory:
requests:
cpu:
memory:
type: kibana
curation:
curator:
resources:
limits:
memory: 200Mi
requests:
cpu: 200m
memory: 200Mi
type: "curator"
- Elasticsearch ストレージ
-
storageClassnameおよびsizeパラメーターを使用し、Elasticsearch クラスターの永続ストレージのクラスおよびサイズを設定できます。Cluster Logging Operator は、これらのパラメーターに基づいて、Elasticsearch クラスターの各データノードについてPersistentVolumeClaimを作成します。
spec:
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 3
storage:
storageClassName: "gp2"
size: "200G"
この例では、クラスターの各データノードが gp2 ストレージの 200G を要求する PersistentVolumeClaim にバインドされるように指定します。それぞれのプライマリーシャードは単一のレプリカによってサポートされます。
storage ブロックを省略すると、一時ストレージのみを含むデプロイメントになります。
spec:
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 3
storage: {}
- Elasticsearch レプリケーションポリシー
Elasticsearch シャードをクラスター内のデータノードにレプリケートする方法を定義するポリシーを設定できます。
-
FullRedundancy:各インデックスのシャードはすべてのデータノードに完全にレプリケートされます。 -
MultipleRedundancy:各インデックスのシャードはデータノードの半分に分散します。 -
SingleRedundancy:各シャードの単一コピー。2 つ以上のデータノードが存在する限り、ログは常に利用可能かつ回復可能です。 -
ZeroRedundancy:シャードのコピーはありません。ログは、ノードの停止または失敗時に利用不可になる (または失われる) 可能性があります。
-
- Curator スケジュール
- Curator のスケジュールを cron 形式 で指定します。
spec:
curation:
type: "curator"
resources:
curator:
schedule: "30 3 * * *"
7.1.1.2. 変更された ClusterLogging リソースのサンプル リンクのコピーリンクがクリップボードにコピーされました!
以下は、前述のオプションを使用して変更された ClusterLogging カスタムリソースの例です。
変更された ClusterLogging リソースのサンプル
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
name: "instance"
namespace: "openshift-logging"
spec:
managementState: "Managed"
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 3
resources:
limits:
memory: 32Gi
requests:
cpu: 3
memory: 32Gi
storage: {}
redundancyPolicy: "SingleRedundancy"
visualization:
type: "kibana"
kibana:
resources:
limits:
memory: 1Gi
requests:
cpu: 500m
memory: 1Gi
replicas: 1
curation:
type: "curator"
curator:
resources:
limits:
memory: 200Mi
requests:
cpu: 200m
memory: 200Mi
schedule: "*/5 * * * *"
collection:
logs:
type: "fluentd"
fluentd:
resources:
limits:
memory: 1Gi
requests:
cpu: 200m
memory: 1Gi