第3章 クラスターロギング
3.1. OpenShift Serverless での OpenShift Logging の使用
3.1.1. Red Hat OpenShift の logging サブシステムのデプロイについて
OpenShift Container Platform クラスター管理者は、OpenShift Container Platform Web コンソールまたは CLI コマンドを使用してロギングシステムをデプロイし、OpenShift Elasticsearch Operator および Red Hat OpenShift Logging Operator をインストールできます。Operator がインストールされたら、ClusterLogging
カスタムリソース (CR) を作成して、ロギングサブシステム pod およびロギングサブシステムをサポートするために必要なその他のリソースをスケジュールします。Operator は、ロギングサブシステムのデプロイ、アップグレード、および保守を担当します。
ClusterLogging
CR は、ログを収集し、保存し、視覚化するために必要なロギングスタックのすべてのコンポーネントを含む完全なロギングシステム環境を定義します。Red Hat OpenShift Logging Operator はロギングシステム CR を監視し、ロギングデプロイメントを適宜調整します。
管理者およびアプリケーション開発者は、表示アクセスのあるプロジェクトのログを表示できます。
3.1.2. Red Hat OpenShift のロギングサブシステムのデプロイおよび設定
Logging システムは、小規模および中規模の OpenShift Container Platform クラスター用に調整されたデフォルト設定で使用されるように設計されています。
以下のインストール方法には、サンプルの ClusterLogging
カスタムリソース (CR) が含まれます。これを使用して、ロギングサブシステムインスタンスを作成し、ロギングサブシステムの環境を設定できます。
デフォルトのロギングサビシステムのインストールを使用する必要がある場合は、サンプル CR を直接使用できます。
デプロイメントをカスタマイズする必要がある場合は、必要に応じてサンプル CR に変更を加えます。以下では、OpenShift Logging インスタンスのインストール時に実行し、インストール後に変更する設定を説明します。ClusterLogging
カスタムリソース外で加える変更を含む、各コンポーネントの使用方法は、設定に関するセクションを参照してください。
3.1.2.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
- Elasticsearch ストレージ
-
storageClass
name
およびsize
パラメーターを使用し、Elasticsearch クラスターの永続ストレージのクラスおよびサイズを設定できます。Red Hat OpenShift Logging Operator は、これらのパラメーターに基づいて、Elasticsearch クラスターの各データノードについて永続ボリューム要求 (PVC) を作成します。
spec: logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: storageClassName: "gp2" size: "200G"
この例では、クラスターの各データノードが gp2 ストレージの 200G を要求する PVC にバインドされるように指定します。それぞれのプライマリーシャードは単一のレプリカによってサポートされます。
storage
ブロックを省略すると、一時ストレージのみを含むデプロイメントになります。
spec: logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 storage: {}
- Elasticsearch レプリケーションポリシー
Elasticsearch シャードをクラスター内のデータノードにレプリケートする方法を定義するポリシーを設定できます。
-
FullRedundancy
: 各インデックスのシャードはすべてのデータノードに完全にレプリケートされます。 -
MultipleRedundancy
: 各インデックスのシャードはデータノードの半分に分散します。 -
SingleRedundancy
: 各シャードの単一コピー。2 つ以上のデータノードが存在する限り、ログは常に利用可能かつ回復可能です。 -
ZeroRedundancy
: シャードのコピーはありません。ログは、ノードの停止または失敗時に利用不可になる (または失われる) 可能性があります。
-
3.1.2.2. 変更された ClusterLogging カスタムリソースのサンプル
以下は、前述のオプションを使用して変更された ClusterLogging
カスタムリソースの例です。
変更された ClusterLogging
リソースのサンプル
apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: "openshift-logging" spec: managementState: "Managed" logStore: type: "elasticsearch" retentionPolicy: application: maxAge: 1d infra: maxAge: 7d audit: maxAge: 7d elasticsearch: nodeCount: 3 resources: limits: cpu: 200m memory: 16Gi requests: cpu: 200m memory: 16Gi storage: storageClassName: "gp2" size: "200G" redundancyPolicy: "SingleRedundancy" visualization: type: "kibana" kibana: resources: limits: memory: 1Gi requests: cpu: 500m memory: 1Gi replicas: 1 collection: logs: type: "fluentd" fluentd: resources: limits: memory: 1Gi requests: cpu: 200m memory: 1Gi