5.5. インストール後のタスク
Red Hat OpenShift Logging Operator をインストールした後、ClusterLogging
カスタムリソース (CR) を作成および変更してデプロイメントを設定できます。
Elasticsearch ログストアを使用していない場合は、内部 Elasticsearch logStore
および Kibana visualization
コンポーネントを ClusterLogging
カスタムリソース (CR) から削除できます。これらのコンポーネントの削除はオプションですが、これによりリソースを節約できます。Elasticsearch ログストアを使用しない場合の未使用コンポーネントの削除 を参照してください。
5.5.1. ClusterLogging カスタムリソースについて
ロギング環境を変更するには、ClusterLogging
カスタムリソース (CR) を作成し、変更します。
ClusterLogging
カスタムリソース (CRD) のサンプル
apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance 1 namespace: openshift-logging 2 spec: managementState: Managed 3 # ...
5.5.2. ログストレージの設定
ClusterLogging
カスタムリソース (CR) を変更することで、ロギングで使用するログストレージのタイプを設定できます。
前提条件
- 管理者権限がある。
-
OpenShift CLI (
oc
) がインストールされている。 - Red Hat OpenShift Logging Operator と内部ログストア (LokiStack または Elasticsearch) がインストールされている。
-
ClusterLogging
CR が作成されている。
Logging 5.9 リリースに、OpenShift Elasticsearch Operator の更新バージョンは含まれていません。ロギング 5.8 でリリースされた OpenShift Elasticsearch Operator を現在使用している場合、Logging 5.8 の EOL まで引き続き Logging で機能します。OpenShift Elasticsearch Operator を使用してデフォルトのログストレージを管理する代わりに、Loki Operator を使用できます。Logging のライフサイクルの日付の詳細は、Platform Agnostic Operator を参照してください。
手順
ClusterLogging
CR のlogStore
仕様を変更します。ClusterLogging
CR の例apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: # ... spec: # ... logStore: type: <log_store_type> 1 elasticsearch: 2 nodeCount: <integer> resources: {} storage: {} redundancyPolicy: <redundancy_type> 3 lokistack: 4 name: {} # ...
LokiStack をログストアとして指定する
ClusterLogging
CR の例apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance namespace: openshift-logging spec: managementState: Managed logStore: type: lokistack lokistack: name: logging-loki # ...
次のコマンドを実行して、
ClusterLogging
CR を適用します。$ oc apply -f <filename>.yaml
5.5.3. ログコレクターの設定
ClusterLogging
カスタムリソース (CR) を変更することで、ロギングで使用するログコレクターのタイプを設定できます。
Fluentd は非推奨となっており、今後のリリースで削除される予定です。Red Hat は、現在のリリースのライフサイクル中にこの機能のバグ修正とサポートを提供しますが、この機能は拡張されなくなりました。Fluentd の代わりに、Vector を使用できます。
前提条件
- 管理者権限がある。
-
OpenShift CLI (
oc
) がインストールされている。 - Red Hat OpenShift Logging Operator がインストールされている。
-
ClusterLogging
CR が作成されている。
手順
ClusterLogging
CR のcollection
仕様を変更します。ClusterLogging
CR の例apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: # ... spec: # ... collection: type: <log_collector_type> 1 resources: {} tolerations: {} # ...
- 1
- ロギングに使用するログコレクターのタイプ。これは、
vector
またはfluentd
にすることができます。
次のコマンドを実行して、
ClusterLogging
CR を適用します。$ oc apply -f <filename>.yaml
5.5.4. ログビジュアライザーの設定
ClusterLogging
カスタムリソース (CR) を変更することで、ロギングで使用するログビジュアライザーのタイプを設定できます。
前提条件
- 管理者権限がある。
-
OpenShift CLI (
oc
) がインストールされている。 - Red Hat OpenShift Logging Operator がインストールされている。
-
ClusterLogging
CR が作成されている。
可視化に OpenShift Container Platform Web コンソールを使用する場合は、ロギングコンソールプラグインを有効にする必要があります。「Web コンソールによるログの可視化」に関するドキュメントを参照してください。
手順
ClusterLogging
CR のvisualization
仕様を変更します。ClusterLogging
CR の例apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: # ... spec: # ... visualization: type: <visualizer_type> 1 kibana: 2 resources: {} nodeSelector: {} proxy: {} replicas: {} tolerations: {} ocpConsole: 3 logsLimit: {} timeout: {} # ...
次のコマンドを実行して、
ClusterLogging
CR を適用します。$ oc apply -f <filename>.yaml
5.5.5. ネットワークの分離が有効になっている場合のプロジェクト間のトラフィックの許可
クラスターネットワークプラグインによって、ネットワークの分離が実施される場合があります。その場合は、OpenShift Logging によってデプロイされる Operator が含まれるプロジェクト間のネットワークトラフィックを許可する必要があります。
ネットワークの分離は、異なるプロジェクトにある Pod およびサービス間のネットワークトラフィックをブロックします。ロギングは、OpenShift Elasticsearch Operator を openshift-operators-redhat
プロジェクトにインストールし、Red Hat OpenShift Logging Operator を openshift-logging
プロジェクトにインストールします。したがって、これら 2 つのプロジェクト間のトラフィックを許可する必要があります。
OpenShift Container Platform は、ネットワークプラグインとして、OpenShift SDN と OVN-Kubernetes の 2 つのサポートされた選択肢を提供します。これら 2 つのプロバイダーはさまざまなネットワーク分離ポリシーを実装します。
OpenShift SDN には 3 つのモードがあります。
- network policy (ネットワークポリシー)
- これはデフォルトモードになります。ポリシーが定義されていない場合は、すべてのトラフィックを許可します。ただし、ユーザーがポリシーを定義する場合、通常はすべてのトラフィックを拒否し、例外を追加して開始します。このプロセスでは、異なるプロジェクトで実行されているアプリケーションが破損する可能性があります。そのため、ポリシーを明示的に設定し、1 つのロギング関連のプロジェクトから他のプロジェクトへの egress のトラフィックを許可します。
- multitenant (マルチテナント)
- このモードは、ネットワークの分離を実行します。2 つのロギング関連のプロジェクトを結合して、それらのプロジェクト間のトラフィックを許可します。
- subnet (サブネット)
- このモードでは、すべてのトラフィックを許可します。ネットワーク分離は実行しません。アクションは不要です。
OVN-Kubernetes は常に ネットワークポリシー を使用します。そのため、OpenShift SDN の場合と同様に、ポリシーを明示的に設定し、1 つのロギング関連のプロジェクトから他のプロジェクトへの egress のトラフィックを許可する必要があります。
手順
multitenant モードで OpenShift SDN を使用している場合は、2 つのプロジェクトに参加します。以下に例を示します。
$ oc adm pod-network join-projects --to=openshift-operators-redhat openshift-logging
または、network policy の OpenShift SDN および OVN-Kubernetes の場合は、以下の操作を実行します。
openshift-operators-redhat
namespace にラベルを設定します。以下に例を示します。$ oc label namespace openshift-operators-redhat project=openshift-operators-redhat
openshift-operators-redhat
、openshift-monitoring
、およびopenshift-ingress
プロジェクトから openshift-logging プロジェクトへの入力を許可する、openshift-logging
namespace にネットワークポリシーオブジェクトを作成します。以下に例を示します。apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-monitoring-ingress-operators-redhat spec: ingress: - from: - podSelector: {} - from: - namespaceSelector: matchLabels: project: "openshift-operators-redhat" - from: - namespaceSelector: matchLabels: name: "openshift-monitoring" - from: - namespaceSelector: matchLabels: network.openshift.io/policy-group: ingress podSelector: {} policyTypes: - Ingress