第2章 クラスターロギングのデプロイについて
クラスターロギングを OpenShift Container Platform クラスターにインストールする前に、以下のセクションを確認します。
2.1. クラスターロギングのデプロイおよび設定について
OpenShift Container Platform クラスターロギングは、小規模および中規模の OpenShift Container Platform クラスター用に調整されたデフォルト設定で使用されるように設計されています。
以下のインストール方法には、サンプルのクラスターロギングのカスタムリソース (CR) が含まれます。これを使用して、クラスターロギングインスタンスを作成し、クラスターロギングのデプロイメントを設定することができます。
デフォルトのクラスターロギングインストールを使用する必要がある場合は、サンプル CR を直接使用できます。
デプロイメントをカスタマイズする必要がある場合、必要に応じてサンプル CR に変更を加えます。以下では、クラスターロギングのインスタンスをインストール時に実行し、インストール後に変更する設定について説明します。クラスターロギングのカスタムリソース外で加える変更を含む、各コンポーネントの使用方法については、設定についてのセクションを参照してください。
2.1.1. クラスターロギングの設定およびチューニング
クラスターロギング環境は、openshift-logging プロジェクトにデプロイされるクラスターロギングのカスタムリソースを変更することによって設定できます。
インストール時またはインストール後に、以下のコンポーネントのいずれかを変更することができます。
- メモリーおよび CPU
-
resourcesブロックを有効なメモリーおよび CPU 値で変更することにより、各コンポーネントの CPU およびメモリーの両方の制限を調整することができます。
spec:
logStore:
elasticsearch:
resources:
limits:
cpu:
memory:
requests:
cpu: 1
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 * * *"2.1.2. 変更されたクラスターロギングカスタムリソースのサンプル
以下は、前述のオプションを使用して変更されたクラスターロギングのカスタムリソースの例です。
変更されたクラスターロギングカスタムリソースのサンプル
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
name: "instance"
namespace: "openshift-logging"
spec:
managementState: "Managed"
logStore:
type: "elasticsearch"
elasticsearch:
nodeCount: 2
resources:
limits:
memory: 2Gi
requests:
cpu: 200m
memory: 2Gi
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
