3.4. インストール後のタスク
Kibana を使用する場合、Kibana のデータを確認し、び可視化するために、Kibana インデックスパターンおよびビジュアライゼーションを手動で作成する 必要があります。
クラスターネットワークプロバイダーがネットワークの分離を実施している場合、OpenShift Logging Operator が含まれるプロジェクト間のネットワークトラフィックを許可します。
3.4.1. Kibana インデックスパターンの定義
インデックスパターンは、可視化する必要のある Elasticsearch インデックスを定義します。Kibana でデータを確認し、可視化するには、インデックスパターンを作成する必要があります。
前提条件
Kibana で infra および audit インデックスを表示するには、ユーザーには
cluster-admin
ロール、cluster-reader
ロール、または両方のロールが必要です。デフォルトのkubeadmin
ユーザーには、これらのインデックスを表示するための適切なパーミッションがあります。default
、kube-
およびopenshift-
プロジェクトで Pod およびログを表示できる場合、これらのインデックスにアクセスできるはずです。以下のコマンドを使用して、現在のユーザーが適切なパーミッションを持っているかどうかを確認することができます。$ oc auth can-i get pods/log -n <project>
出力例
yes
注記監査ログは、デフォルトでは内部 OpenShift Container Platform Elasticsearch インスタンスに保存されません。Kibana で監査ログを表示するには、ログ転送 API を使用して監査ログの
default
出力を使用するパイプラインを設定する必要があります。- Elasticsearch ドキュメントは、インデックスパターンを作成する前にインデックス化する必要があります。これは自動的に実行されますが、新規または更新されたクラスターでは数分の時間がかかる可能性があります。
手順
Kibana でインデックスパターンを定義し、ビジュアライゼーションを作成するには、以下を実行します。
- OpenShift Container Platform コンソールで、Application Launcher をクリックし、Logging を選択します。
Management
Index Patterns Create index pattern をクリックして Kibana インデックスパターンを作成します。 -
各ユーザーは、プロジェクトのログを確認するために、Kibana に初めてログインする際にインデックスパターンを手動で作成する必要があります。ユーザーは
app
という名前のインデックスパターンを作成し、@timestamp
時間フィールドを使用してコンテナーログを表示する必要があります。 -
管理ユーザーはそれぞれ、最初に Kibana にログインする際に、
@timestamp
時間フィールドを使用してapp
、infra
およびaudit
インデックスについてインデックスパターンを作成する必要があります。
-
各ユーザーは、プロジェクトのログを確認するために、Kibana に初めてログインする際にインデックスパターンを手動で作成する必要があります。ユーザーは
- 新規インデックスパターンから Kibana のビジュアライゼーション (Visualization) を作成します。
3.4.2. ネットワークの分離が有効にされている場合のプロジェクト間のトラフィックの許可
クラスターネットワークプロバイダーはネットワークの分離を有効にする可能性があります。その場合、OpenShift Logging によってデプロイされる Operator が含まれるプロジェクト間のネットワークトラフィックを許可する必要があります。
ネットワークの分離は、異なるプロジェクトにある Pod およびサービス間のネットワークトラフィックをブロックします。OpenShift Logging は、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-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