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
namespace: openshift-logging
spec:
managementState: Managed
# ...
5.5.2. ログストレージの設定 リンクのコピーリンクがクリップボードにコピーされました!
ClusterLogging カスタムリソース (CR) を変更することで、ロギングで使用するログストレージのタイプを設定できます。
前提条件
- 管理者権限がある。
-
OpenShift CLI (
oc) がインストールされている。 - Red Hat OpenShift Logging Operator と内部ログストア (LokiStack または Elasticsearch) がインストールされている。
-
ClusterLoggingCR が作成されている。
OpenShift Elasticsearch Operator は非推奨となっており、将来のリリースで削除される予定です。Red Hat は、現在のリリースのライフサイクル中にこの機能のバグ修正とサポートを提供しますが、この機能は拡張されなくなりました。OpenShift Elasticsearch Operator を使用してデフォルトのログストレージを管理する代わりに、Loki Operator を使用できます。
手順
ClusterLoggingCR のlogStore仕様を変更します。ClusterLoggingCR の例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 をログストアとして指定する
ClusterLoggingCR の例apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance namespace: openshift-logging spec: managementState: Managed logStore: type: lokistack lokistack: name: logging-loki # ...次のコマンドを実行して、
ClusterLoggingCR を適用します。$ oc apply -f <filename>.yaml
5.5.3. ログコレクターの設定 リンクのコピーリンクがクリップボードにコピーされました!
ClusterLogging カスタムリソース (CR) を変更することで、ロギングで使用するログコレクターのタイプを設定できます。
Fluentd は非推奨となっており、今後のリリースで削除される予定です。Red Hat は、現在のリリースのライフサイクル中にこの機能のバグ修正とサポートを提供しますが、この機能は拡張されなくなりました。Fluentd の代わりに、Vector を使用できます。
前提条件
- 管理者権限がある。
-
OpenShift CLI (
oc) がインストールされている。 - Red Hat OpenShift Logging Operator がインストールされている。
-
ClusterLoggingCR が作成されている。
手順
ClusterLoggingCR のcollection仕様を変更します。ClusterLoggingCR の例apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: # ... spec: # ... collection: type: <log_collector_type>1 resources: {} tolerations: {} # ...- 1
- ロギングに使用するログコレクターのタイプ。これは、
vectorまたはfluentdにすることができます。
次のコマンドを実行して、
ClusterLoggingCR を適用します。$ oc apply -f <filename>.yaml
5.5.4. ログビジュアライザーの設定 リンクのコピーリンクがクリップボードにコピーされました!
ClusterLogging カスタムリソース (CR) を変更することで、ロギングで使用するログビジュアライザーのタイプを設定できます。
前提条件
- 管理者権限がある。
-
OpenShift CLI (
oc) がインストールされている。 - Red Hat OpenShift Logging Operator がインストールされている。
-
ClusterLoggingCR が作成されている。
可視化に OpenShift Container Platform Web コンソールを使用する場合は、ロギングコンソールプラグインを有効にする必要があります。"Web コンソールによるログの可視化" に関するドキュメントを参照してください。
手順
ClusterLoggingCR のvisualization仕様を変更します。ClusterLoggingCR の例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: {} # ...次のコマンドを実行して、
ClusterLoggingCR を適用します。$ 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 は、2 つのサポート対象のオプションをデフォルトの Container Network Interface (CNI) ネットワークプロバイダー、OpenShift SDN および OVN-Kubernetes 用に提供します。これら 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-redhatnamespace にラベルを設定します。以下に例を示します。$ oc label namespace openshift-operators-redhat project=openshift-operators-redhatopenshift-operators-redhat、openshift-monitoring、およびopenshift-ingressプロジェクトから openshift-logging プロジェクトへの入力を許可する、openshift-loggingnamespace にネットワークポリシーオブジェクトを作成します。以下に例を示します。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