The stable channel only provides updates to the most recent release of logging. To continue receiving updates for prior releases, you must change your subscription channel to stable-x.y, where |
You can install the logging subsystem for Red Hat OpenShift by deploying the Red Hat OpenShift Logging Operator. The logging subsystem Operator creates and manages the components of the logging stack.
For new installations, Vector and LokiStack are recommended. Documentation for logging is in the process of being updated to reflect these underlying component changes. |
Ensure that you have downloaded the pull secret from the Red Hat OpenShift Cluster Manager as shown in Obtaining the installation program in the installation documentation for your platform.
If you have the pull secret, add the redhat-operators
catalog to the OperatorHub custom resource (CR) as shown in Configuring OKD to use Red Hat Operators.
Fluentd is deprecated and is planned to be removed in a future release. Red Hat provides bug fixes and support for this feature during the current release lifecycle, but this feature no longer receives enhancements. As an alternative to Fluentd, you can use Vector instead. |
If you do not want to use the default Elasticsearch log store, you can remove the internal Elasticsearch |
Logging is provided as an installable component, with a distinct release cycle from the core OKD. The Red Hat OpenShift Container Platform Life Cycle Policy outlines release compatibility. |
In the OKD web console, click Operators → OperatorHub.
Choose Red Hat OpenShift Logging from the list of available Operators, and click Install.
Ensure that A specific namespace on the cluster is selected under Installation mode.
Ensure that Operator recommended namespace is openshift-logging under Installed Namespace.
Select Enable operator recommended cluster monitoring on this namespace.
This option sets the openshift.io/cluster-monitoring: "true"
label in the Namespace object.
You must select this option to ensure that cluster monitoring
scrapes the openshift-logging
namespace.
Select stable-5.y as the Update channel.
The stable channel only provides updates to the most recent release of logging. To continue receiving updates for prior releases, you must change your subscription channel to stable-x.y, where |
Select an Update approval.
The Automatic strategy allows Operator Lifecycle Manager (OLM) to automatically update the Operator when a new version is available.
The Manual strategy requires a user with appropriate credentials to approve the Operator update.
Select Enable or Disable for the Console plugin.
Click Install.
Verify that the Red Hat OpenShift Logging Operator is installed by switching to the Operators → Installed Operators page.
Ensure that Red Hat OpenShift Logging is listed in the openshift-logging project with a Status of Succeeded.
Verify that the Red Hat OpenShift Logging Operator installed by switching to the Operators → Installed Operators page.
Ensure that Red Hat OpenShift Logging is listed in the openshift-logging project with a Status of Succeeded.
If the Operator does not appear as installed, to troubleshoot further:
Switch to the Operators → Installed Operators page and inspect the Status column for any errors or failures.
Switch to the Workloads → Pods page and check the logs in any pods in the
openshift-logging
project that are reporting issues.
Create a ClusterLogging instance.
The form view of the web console does not include all available options. The YAML view is recommended for completing your setup. |
In the collection section, select a Collector Implementation.
Fluentd is deprecated and is planned to be removed in a future release. Red Hat provides bug fixes and support for this feature during the current release lifecycle, but this feature no longer receives enhancements. As an alternative to Fluentd, you can use Vector instead. |
In the logStore section, select a type.
The Elasticsearch Operator is deprecated and is planned to be removed in a future release. Red Hat provides bug fixes and support for this feature during the current release lifecycle, but this feature no longer receives enhancements. As an alternative to using the Elasticsearch Operator to manage the default log storage, you can use the Loki Operator. |
Click Create.
Create an OpenShift Logging instance:
Switch to the Administration → Custom Resource Definitions page.
On the Custom Resource Definitions page, click ClusterLogging.
On the Custom Resource Definition details page, select View Instances from the Actions menu.
On the ClusterLoggings page, click Create ClusterLogging.
You might have to refresh the page to load the data.
In the YAML field, replace the code with the following:
This default OpenShift Logging configuration should support a wide array of environments. Review the topics on tuning and configuring logging subsystem components for information on modifications you can make to your OpenShift Logging cluster. |
apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
name: instance (1)
namespace: openshift-logging
spec:
managementState: Managed (2)
logStore:
type: elasticsearch (3)
retentionPolicy: (4)
application:
maxAge: 1d
infra:
maxAge: 7d
audit:
maxAge: 7d
elasticsearch:
nodeCount: 3 (5)
storage:
storageClassName: <storage_class_name> (6)
size: 200G
resources: (7)
limits:
memory: 16Gi
requests:
memory: 16Gi
proxy: (8)
resources:
limits:
memory: 256Mi
requests:
memory: 256Mi
redundancyPolicy: SingleRedundancy
visualization:
type: kibana (9)
kibana:
replicas: 1
collection:
logs:
type: fluentd (10)
fluentd: {}
1 | The name must be instance . |
2 | The OpenShift Logging management state. In some cases, if you change the OpenShift Logging defaults, you must set this to Unmanaged .
However, an unmanaged deployment does not receive updates until OpenShift Logging is placed back into a managed state. |
3 | Settings for configuring Elasticsearch. Using the CR, you can configure shard replication policy and persistent storage. |
4 | Specify the length of time that Elasticsearch should retain each log source. Enter an integer and a time designation: weeks(w), hours(h/H), minutes(m) and seconds(s). For example, 7d for seven days. Logs older than the maxAge are deleted. You must specify a retention policy for each log source or the Elasticsearch indices will not be created for that source. |
5 | Specify the number of Elasticsearch nodes. See the note that follows this list. |
6 | Enter the name of an existing storage class for Elasticsearch storage. For best performance, specify a storage class that allocates block storage. If you do not specify a storage class, OpenShift Logging uses ephemeral storage. |
7 | Specify the CPU and memory requests for Elasticsearch as needed. If you leave these values blank, the OpenShift Elasticsearch Operator sets default values that should be sufficient for most deployments. The default values are 16Gi for the memory request and 1 for the CPU request. |
8 | Specify the CPU and memory requests for the Elasticsearch proxy as needed. If you leave these values blank, the OpenShift Elasticsearch Operator sets default values that should be sufficient for most deployments. The default values are 256Mi for the memory request and 100m for the CPU request. |
9 | Settings for configuring Kibana. Using the CR, you can scale Kibana for redundancy and configure the CPU and memory for your Kibana nodes. For more information, see Configuring the log visualizer. |
10 | Settings for configuring Fluentd. Using the CR, you can configure Fluentd CPU and memory limits. For more information, see Configuring Fluentd. |
The maximum number of Elasticsearch control plane nodes is three. If you specify a For example, if
Example output
The number of primary shards for the index templates is equal to the number of Elasticsearch data nodes. |
Click Create. This creates the logging subsystem components, the Elasticsearch
custom resource and components, and the Kibana interface.
Verify the install:
Switch to the Workloads → Pods page.
Select the openshift-logging project.
Confirm that pods exist for the Operator and the Elasticsearch, collector, and Kibana components:
cluster-logging-operator-595f9bf9c4-txrp4
collector-29bw8
collector-4kvnl
collector-7rr7w
collector-9m2xp
collector-xt45j
elasticsearch-cdm-g559ha9u-1-659fd594bf-pcm2f
elasticsearch-cdm-g559ha9u-2-66455f68db-v46n6
elasticsearch-cdm-g559ha9u-3-85696bcf55-g7tf8
elasticsearch-im-app-27934020-9ltxl
elasticsearch-im-audit-27934020-86cdt
elasticsearch-im-infra-27934020-6lrgm
kibana-5c6b7cd56-66c9l
If Alertmanager logs alerts such as Prometheus could not scrape fluentd for more than 10m
, make sure that openshift.io/cluster-monitoring
is set to "true"
for the OpenShift Elasticsearch Operator and OpenShift Logging Operator. See the Red Hat KnowledgeBase for more information: Prometheus could not scrape fluentd for more than 10m alert in Alertmanager
You can use the OpenShift CLI (oc
) to install the Elasticsearch Operator and the Red Hat OpenShift Logging Operator.
Ensure that you have the necessary persistent storage for Elasticsearch. Note that each Elasticsearch node requires its own storage volume.
If you use a local volume for persistent storage, do not use a raw block volume, which is described with |
Elasticsearch is a memory-intensive application. By default, OKD installs three Elasticsearch nodes with memory requests and limits of 16 GB. This initial set of three OKD nodes might not have enough memory to run Elasticsearch within your cluster. If you experience memory issues that are related to Elasticsearch, add more Elasticsearch nodes to your cluster rather than increasing the memory on existing nodes.
Ensure that you have downloaded the pull secret from the Red Hat OpenShift Cluster Manager as shown in Obtaining the installation program in the installation documentation for your platform.
If you have the pull secret, add the redhat-operators
catalog to the OperatorHub custom resource (CR) as shown in Configuring OKD to use Red Hat Operators.
Create a Namespace
object for the Elasticsearch Operator:
Namespace
objectapiVersion: v1
kind: Namespace
metadata:
name: openshift-operators-redhat (1)
annotations:
openshift.io/node-selector: ""
labels:
openshift.io/cluster-monitoring: "true" (2)
1 | You must specify the openshift-operators-redhat namespace. To prevent possible conflicts with metrics, you should configure the Prometheus Cluster Monitoring stack to scrape metrics from the openshift-operators-redhat namespace and not the openshift-operators namespace. The openshift-operators namespace might contain community Operators, which are untrusted and could publish a metric with the same name as an OKD metric, which would cause conflicts. |
2 | String. You must specify this label as shown to ensure that cluster monitoring scrapes the openshift-operators-redhat namespace. |
Apply the Namespace
object by running the following command:
$ oc apply -f <filename>.yaml
Create a Namespace
object for the Red Hat OpenShift Logging Operator:
Namespace
objectapiVersion: v1
kind: Namespace
metadata:
name: openshift-logging
annotations:
openshift.io/node-selector: ""
labels:
openshift.io/cluster-monitoring: "true"
Apply the Namespace
object by running the following command:
$ oc apply -f <filename>.yaml
Install the Elasticsearch Operator by creating the following objects:
Create an OperatorGroup
object for the Elasticsearch Operator:
OperatorGroup
objectapiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: openshift-operators-redhat
namespace: openshift-operators-redhat (1)
spec: {}
1 | You must specify the openshift-operators-redhat namespace. |
Apply the OperatorGroup
object by running the following command:
$ oc apply -f <filename>.yaml
Create a Subscription
object to subscribe a namespace to the Elasticsearch Operator:
Subscription
objectapiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: elasticsearch-operator
namespace: openshift-operators-redhat (1)
spec:
channel: <channel> (2)
installPlanApproval: Automatic (3)
source: redhat-operators (4)
sourceNamespace: openshift-marketplace
name: elasticsearch-operator
1 | You must specify the openshift-operators-redhat namespace. |
2 | Specify stable , or stable-y.z as the channel, where y is the major version and z is the minor version. See the following note. |
3 | Automatic allows the Operator Lifecycle Manager (OLM) to automatically update the Operator when a new version is available. Manual requires a user with appropriate credentials to approve the Operator update. |
4 | Specify redhat-operators . If your OKD cluster is installed on a restricted network, also known as a disconnected cluster,
specify the name of the CatalogSource object created when you configured the Operator Lifecycle Manager (OLM). |
Specifying Specifying |
Apply the Subscription
object by running the following command:
$ oc apply -f <filename>.yaml
The Elasticsearch Operator is installed to the openshift-operators-redhat
namespace and copied to each project in the cluster.
Install the Red Hat OpenShift Logging Operator by creating the following objects:
Create an OperatorGroup
object for the Red Hat OpenShift Logging Operator:
OperatorGroup
objectapiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: cluster-logging
namespace: openshift-logging (1)
spec:
targetNamespaces:
- openshift-logging (1)
1 | You must specify the openshift-logging namespace. |
Apply the OperatorGroup
object by running the following command:
$ oc apply -f <filename>.yaml
Create a Subscription
object to subscribe a namespace to the Red Hat OpenShift Logging Operator:
Subscription
objectapiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: cluster-logging
namespace: openshift-logging (1)
spec:
channel: "stable" (2)
name: cluster-logging
source: redhat-operators (3)
sourceNamespace: openshift-marketplace
1 | You must specify the openshift-logging namespace. |
2 | Specify stable , or stable-5.<x> as the channel. |
3 | Specify redhat-operators . If your OKD cluster is installed on a restricted network, also known as a disconnected cluster, specify the name of the CatalogSource object you created when you configured the Operator Lifecycle Manager (OLM). |
Apply the Subscription
object by running the following command:
$ oc apply -f <filename>.yaml
The Red Hat OpenShift Logging Operator is installed to the openshift-logging
namespace.
Create a ClusterLogging
custom resource (CR):
This default |
ClusterLogging
CRapiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
name: instance (1)
namespace: openshift-logging
spec:
managementState: Managed (2)
logStore:
type: elasticsearch (3)
retentionPolicy: (4)
application:
maxAge: 1d
infra:
maxAge: 7d
audit:
maxAge: 7d
elasticsearch:
nodeCount: 3 (5)
storage:
storageClassName: <storage_class_name> (6)
size: 200G
resources: (7)
limits:
memory: 16Gi
requests:
memory: 16Gi
proxy: (8)
resources:
limits:
memory: 256Mi
requests:
memory: 256Mi
redundancyPolicy: SingleRedundancy
visualization:
type: kibana (9)
kibana:
replicas: 1
collection:
logs:
type: fluentd (10)
fluentd: {}
1 | The name must be instance . |
2 | The logging subsystem management state. In some cases, if you change the logging subsystem defaults, you must set this to Unmanaged . However, an unmanaged deployment does not receive updates until the logging subsystem is placed back into a managed state. Placing a deployment back into a managed state might revert any modifications you made. |
3 | Settings for configuring Elasticsearch. Using the custom resource (CR), you can configure shard replication policy and persistent storage. |
4 | Specify the length of time that Elasticsearch should retain each log source. Enter an integer and a time designation: weeks(w), hours(h/H), minutes(m) and seconds(s). For example, 7d for seven days. Logs older than the maxAge are deleted. You must specify a retention policy for each log source or the Elasticsearch indices will not be created for that source. |
5 | Specify the number of Elasticsearch nodes. See the note that follows this list. |
6 | Enter the name of an existing storage class for Elasticsearch storage. For best performance, specify a storage class that allocates block storage. If you do not specify a storage class, OKD deploys the logging subsystem with ephemeral storage only. |
7 | Specify the CPU and memory requests for Elasticsearch as needed. If you leave these values blank, the Elasticsearch Operator sets default values that are sufficient for most deployments. The default values are 16Gi for the memory request and 1 for the CPU request. |
8 | Specify the CPU and memory requests for the Elasticsearch proxy as needed. If you leave these values blank, the Elasticsearch Operator sets default values that should be sufficient for most deployments. The default values are 256Mi for the memory request and 100m for the CPU request. |
9 | Settings for configuring Kibana. Using the CR, you can scale Kibana for redundancy and configure the CPU and memory for your Kibana pods. |
10 | Settings for configuring Fluentd. Using the CR, you can configure Fluentd CPU and memory limits. |
The maximum number of Elasticsearch control plane nodes is three. If you specify a For example, if
Example output
The number of primary shards for the index templates is equal to the number of Elasticsearch data nodes. |
Apply the ClusterLogging
custom resource (CR) by running the following command:
$ oc apply -f <filename>.yaml
This creates the logging subsystem components, the Elasticsearch
CR and components, and the Kibana interface.
Verify the Elasticsearch Operator installation:
$ oc get csv --all-namespaces
NAMESPACE NAME DISPLAY VERSION REPLACES PHASE
default elasticsearch-operator.5.1.0-202007012112.p0 OpenShift Elasticsearch Operator 5.5.0-202007012112.p0 Succeeded
kube-node-lease elasticsearch-operator.5.5.0-202007012112.p0 OpenShift Elasticsearch Operator 5.5.0-202007012112.p0 Succeeded
kube-public elasticsearch-operator.5.5.0-202007012112.p0 OpenShift Elasticsearch Operator 5.5.0-202007012112.p0 Succeeded
kube-system elasticsearch-operator.5.5.0-202007012112.p0 OpenShift Elasticsearch Operator 5.5.0-202007012112.p0 Succeeded
openshift-apiserver-operator elasticsearch-operator.5.5.0-202007012112.p0 OpenShift Elasticsearch Operator 5.5.0-202007012112.p0 Succeeded
openshift-apiserver elasticsearch-operator.5.5.0-202007012112.p0 OpenShift Elasticsearch Operator 5.5.0-202007012112.p0 Succeeded
openshift-authentication-operator elasticsearch-operator.5.5.0-202007012112.p0 OpenShift Elasticsearch Operator 5.5.0-202007012112.p0 Succeeded
openshift-authentication elasticsearch-operator.5.5.0-202007012112.p0 OpenShift Elasticsearch Operator 5.5.0-202007012112.p0 Succeeded
...
There should be an Elasticsearch Operator instance in each namespace. The version number might be different than shown.
Verify the Red Hat OpenShift Logging Operator installation.
There should be a Red Hat OpenShift Logging Operator in the openshift-logging
namespace. The Version number might be different than shown.
$ oc get csv -n openshift-logging
NAMESPACE NAME DISPLAY VERSION REPLACES PHASE
...
openshift-logging clusterlogging.5.1.0-202007012112.p0 OpenShift Logging 5.1.0-202007012112.p0 Succeeded
...
Verify the installation by listing the pods in the openshift-logging project. Run the following command:
$ oc get pods -n openshift-logging
You should see several pods for components of the logging subsystem, similar to the following list:
NAME READY STATUS RESTARTS AGE
cluster-logging-operator-66f77ffccb-ppzbg 1/1 Running 0 7m
elasticsearch-cdm-ftuhduuw-1-ffc4b9566-q6bhp 2/2 Running 0 2m40s
elasticsearch-cdm-ftuhduuw-2-7b4994dbfc-rd2gc 2/2 Running 0 2m36s
elasticsearch-cdm-ftuhduuw-3-84b5ff7ff8-gqnm2 2/2 Running 0 2m4s
collector-587vb 1/1 Running 0 2m26s
collector-7mpb9 1/1 Running 0 2m30s
collector-flm6j 1/1 Running 0 2m33s
collector-gn4rn 1/1 Running 0 2m26s
collector-nlgb6 1/1 Running 0 2m30s
collector-snpkt 1/1 Running 0 2m28s
kibana-d6d5668c5-rppqm 2/2 Running 0 2m39s
After you have installed the Red Hat OpenShift Logging Operator, you can configure your deployment by creating and modifying a ClusterLogging
custom resource (CR).
To make changes to your logging subsystem environment, create and modify the ClusterLogging
custom resource (CR).
ClusterLogging
custom resource (CR)apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
name: "instance" (1)
namespace: "openshift-logging" (2)
spec:
managementState: "Managed" (3)
# ...
1 | The CR name must be instance . |
2 | The CR must be installed to the openshift-logging namespace. |
3 | The Red Hat OpenShift Logging Operator management state. When set to unmanaged the operator is in an unsupported state and will not get updates. |
You can configure which log storage type your logging subsystem uses by modifying the ClusterLogging
custom resource (CR).
You have administrator permissions.
You have installed the OpenShift CLI (oc
).
You have installed the Red Hat OpenShift Logging Operator and an internal log store that is either the LokiStack or Elasticsearch.
You have created a ClusterLogging
CR.
The Elasticsearch Operator is deprecated and is planned to be removed in a future release. Red Hat provides bug fixes and support for this feature during the current release lifecycle, but this feature no longer receives enhancements. As an alternative to using the Elasticsearch Operator to manage the default log storage, you can use the Loki Operator. |
Modify the ClusterLogging
CR logStore
spec:
ClusterLogging
CR exampleapiVersion: 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: {}
# ...
1 | Specify the log store type. This can be either lokistack or elasticsearch . |
2 | Optional configuration options for the Elasticsearch log store. |
3 | Specify the redundancy type. This value can be ZeroRedundancy , SingleRedundancy , MultipleRedundancy , or FullRedundancy . |
4 | Optional configuration options for LokiStack. |
Apply the ClusterLogging
CR by running the following command:
$ oc apply -f <filename>.yaml
You can configure which log collector type your logging subsystem uses by modifying the ClusterLogging
custom resource (CR).
Fluentd is deprecated and is planned to be removed in a future release. Red Hat provides bug fixes and support for this feature during the current release lifecycle, but this feature no longer receives enhancements. As an alternative to Fluentd, you can use Vector instead. |
You have administrator permissions.
You have installed the OpenShift CLI (oc
).
You have installed the Red Hat OpenShift Logging Operator.
You have created a ClusterLogging
CR.
Modify the ClusterLogging
CR collection
spec:
ClusterLogging
CR exampleapiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
# ...
spec:
# ...
collection:
type: <log_collector_type> (1)
resources: {}
tolerations: {}
# ...
1 | The log collector type you want to use for the logging subsystem. This can be vector or fluentd . |
Apply the ClusterLogging
CR by running the following command:
$ oc apply -f <filename>.yaml
You can configure which log visualizer type your logging subsystem uses by modifying the ClusterLogging
custom resource (CR).
You have administrator permissions.
You have installed the OpenShift CLI (oc
).
You have installed the Red Hat OpenShift Logging Operator.
You have created a ClusterLogging
CR.
If you want to use the OKD web console for visualization, you must enable the logging subsystem Console plugin. See the documentation about "Log visualization with the web console". |
Modify the ClusterLogging
CR visualization
spec:
ClusterLogging
CR exampleapiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
# ...
spec:
# ...
visualization:
type: <visualizer_type> (1)
kibana: (2)
resources: {}
nodeSelector: {}
proxy: {}
replicas: {}
tolerations: {}
ocpConsole: (3)
logsLimit: {}
timeout: {}
# ...
1 | The type of visualizer you want to use for your logging subsystem. This can be either kibana or ocp-console . The Kibana console is only compatible with deployments that use Elasticsearch log storage, while the OKD console is only compatible with LokiStack deployments. |
2 | Optional configurations for the Kibana console. |
3 | Optional configurations for the OKD web console. |
Apply the ClusterLogging
CR by running the following command:
$ oc apply -f <filename>.yaml
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. The logging subsystem 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.
OKD 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:
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.
This mode enforces network isolation. You must join the two logging-related projects to allow traffic between them.
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.
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-redhat
namespace. For example:
$ oc label namespace openshift-operators-redhat project=openshift-operators-redhat
Create a network policy object in the openshift-logging
namespace that allows ingress from the openshift-operators-redhat
, openshift-monitoring
and openshift-ingress
projects to the openshift-logging project. For example:
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