2.4. Post-installation tasks
If you plan to use Kibana, you must manually create your Kibana index patterns and visualizations to explore and visualize data in Kibana.
If your cluster network provider enforces network isolation, allow network traffic between the projects that contain the OpenShift Logging operators.
2.4.1. Defining Kibana index patterns
An index pattern defines the Elasticsearch indices that you want to visualize. To explore and visualize data in Kibana, you must create an index pattern.
Prerequisites
A user must have the
cluster-adminrole, thecluster-readerrole, or both roles to view the infra and audit indices in Kibana. The defaultkubeadminuser has proper permissions to view these indices.If you can view the pods and logs in the
default,kube-andopenshift-projects, you should be able to access these indices. You can use the following command to check if the current user has appropriate permissions:$ oc auth can-i get pods/log -n <project>
Example output
yes
注意The audit logs are not stored in the internal OpenShift Container Platform Elasticsearch instance by default. To view the audit logs in Kibana, you must use the Log Forwarding API to configure a pipeline that uses the
defaultoutput for audit logs.- Elasticsearch documents must be indexed before you can create index patterns. This is done automatically, but it might take a few minutes in a new or updated cluster.
Procedure
To define index patterns and create visualizations in Kibana:
-
In the OpenShift Container Platform console, click the Application Launcher
and select Logging.
Create your Kibana index patterns by clicking Management
Index Patterns Create index pattern: -
Each user must manually create index patterns when logging into Kibana the first time in order to see logs for their projects. Users must create an index pattern named
appand use the@timestamptime field to view their container logs. -
Each admin user must create index patterns when logged into Kibana the first time for the
app,infra, andauditindices using the@timestamptime field.
-
Each user must manually create index patterns when logging into Kibana the first time in order to see logs for their projects. Users must create an index pattern named
- Create Kibana Visualizations from the new index patterns.
2.4.2. Allowing traffic between projects when network isolation is enabled
Your cluster network provider might enforce network isolation. If so, you must allow network traffic between the projects that contain the operators deployed by OpenShift Logging.
Network isolation blocks network traffic between pods or services that are in different projects. OpenShift Logging installs the OpenShift Elasticsearch Operator in the openshift-operators-redhat project and the Red Hat OpenShift Logging Operator in the openshift-logging project. Therefore, you must allow traffic between these two projects.
OpenShift Container Platform offers two supported choices for the default Container Network Interface (CNI) network provider, OpenShift SDN and OVN-Kubernetes. These two providers implement various network isolation policies.
OpenShift SDN has three modes:
- network policy
- This is the default mode. If no policy is defined, it allows all traffic. However, if a user defines a policy, they typically start by denying all traffic and then adding exceptions. This process might break applications that are running in different projects. Therefore, explicitly configure the policy to allow traffic to egress from one logging-related project to the other.
- multitenant
- This mode enforces network isolation. You must join the two logging-related projects to allow traffic between them.
- subnet
- This mode allows all traffic. It does not enforce network isolation. No action is needed.
OVN-Kubernetes always uses a network policy. Therefore, as with OpenShift SDN, you must configure the policy to allow traffic to egress from one logging-related project to the other.
Procedure
If you are using OpenShift SDN in multitenant mode, join the two projects. For example:
$ oc adm pod-network join-projects --to=openshift-operators-redhat openshift-logging
Otherwise, for OpenShift SDN in network policy mode and OVN-Kubernetes, perform the following actions:
Set a label on the
openshift-operators-redhatnamespace. For example:$ oc label namespace openshift-operators-redhat project=openshift-operators-redhat
Create a network policy object in the
openshift-loggingnamespace that allows ingress from theopenshift-operators-redhatproject to theopenshift-loggingproject. For example:kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-openshift-operators-redhat spec: ingress: - from: - namespaceSelector: matchLabels: project: openshift-operators-redhat
