Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 3. Installing the Network Observability Operator

Installing Loki is a recommended prerequisite for using the Network Observability Operator. You can choose to use Network Observability without Loki, but there are some considerations for doing this, described in the previously linked section.

The Loki Operator integrates a gateway that implements multi-tenancy and authentication with Loki for data flow storage. The 

LokiStack
resource manages Loki, which is a scalable, highly-available, multi-tenant log aggregation system, and a web proxy with OpenShift Container Platform authentication. The 
LokiStack
proxy uses OpenShift Container Platform authentication to enforce multi-tenancy and facilitate the saving and indexing of data in Loki log stores.

Note

The Loki Operator can also be used for configuring the LokiStack log store. The Network Observability Operator requires a dedicated LokiStack separate from the logging.

3.1. Network Observability without Loki
Copia collegamento

You can use Network Observability without Loki by not performing the Loki installation steps and skipping directly to "Installing the Network Observability Operator". If you only want to export flows to a Kafka consumer or IPFIX collector, or you only need dashboard metrics, then you do not need to install Loki or provide storage for Loki. Without Loki, there won’t be a Network Traffic panel under Observe, which means there is no overview charts, flow table, or topology. The following table compares available features with and without Loki:

Expand
Table 3.1. Comparison of feature availability with and without Loki
 With LokiWithout Loki

Exporters

check solid

check solid

Flow-based metrics and dashboards

check solid

check solid

Traffic Flow Overview, Table and Topology views

check solid

x solid

Quick Filters

check solid

x solid

OpenShift Container Platform console Network Traffic tab integration

check solid

x solid

3.2. Installing the Loki Operator
Copia collegamento

The Loki Operator versions 5.7+ are the supported Loki Operator versions for Network Observabilty; these versions provide the ability to create a 

LokiStack
instance using the 
openshift-network
tenant configuration mode and provide fully-automatic, in-cluster authentication and authorization support for Network Observability. There are several ways you can install Loki. One way is by using the OpenShift Container Platform web console Operator Hub.

Prerequisites

  • Supported Log Store (AWS S3, Google Cloud Storage, Azure, Swift, Minio, OpenShift Data Foundation)
  • OpenShift Container Platform 4.10+
  • Linux Kernel 4.18+

Procedure

  1. In the OpenShift Container Platform web console, click Operators OperatorHub.
  2. Choose Loki Operator from the list of available Operators, and click Install.
  3. Under Installation Mode, select All namespaces on the cluster.

Verification

  1. Verify that you installed the Loki Operator. Visit the Operators Installed Operators page and look for Loki Operator.
  2. Verify that Loki Operator is listed with Status as Succeeded in all the projects.
Important

To uninstall Loki, refer to the uninstallation process that corresponds with the method you used to install Loki. You might have remaining 

ClusterRoles
and 
ClusterRoleBindings
, data stored in object store, and persistent volume that must be removed.

3.2.1. Creating a secret for Loki storage
Copia collegamento

The Loki Operator supports a few log storage options, such as AWS S3, Google Cloud Storage, Azure, Swift, Minio, OpenShift Data Foundation. The following example shows how to create a secret for AWS S3 storage. The secret created in this example, 

loki-s3
, is referenced in "Creating a LokiStack resource". You can create this secret in the web console or CLI.

  1. Using the web console, navigate to the Project All Projects dropdown and select Create Project. Name the project 
    netobserv
    and click Create.

  2. Navigate to the Import icon, +, in the top right corner. Paste your YAML file into the editor.

    The following shows an example secret YAML file for S3 storage: 

    apiVersion: v1
kind: Secret
metadata:
  name: loki-s3
  namespace: netobserv
    1 
    
stringData:
  access_key_id: QUtJQUlPU0ZPRE5ON0VYQU1QTEUK
  access_key_secret: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo=
  bucketnames: s3-bucket-name
  endpoint: https://s3.eu-central-1.amazonaws.com
  region: eu-central-1
    1
    The installation examples in this documentation use the same namespace, netobserv, across all components. You can optionally use a different namespace for the different components

Verification

  • Once you create the secret, you should see it listed under Workloads Secrets in the web console.

3.2.2. Creating a LokiStack custom resource
Copia collegamento

You can deploy a LokiStack using the web console or CLI to create a namespace, or new project.

Important

Querying application logs for multiple namespaces as a 

cluster-admin
user, where the sum total of characters of all of the namespaces in the cluster is greater than 5120, results in the error 
Parse error: input size too long (XXXX > 5120)
. For better control over access to logs in LokiStack, make the 
cluster-admin
user a member of the 
cluster-admin
group. If the 
cluster-admin
group does not exist, create it and add the desired users to it.

For more information about creating a 

cluster-admin
group, see the "Additional resources" section.

Procedure

  1. Navigate to Operators Installed Operators, viewing All projects from the Project dropdown.
  2. Look for Loki Operator. In the details, under Provided APIs, select LokiStack.
  3. Click Create LokiStack.

  4. Ensure the following fields are specified in either Form View or YAML view: 

    apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: loki
  namespace: netobserv
    1 
    
spec:
  size: 1x.small
  storage:
    schemas:
    - version: v12
      effectiveDate: '2022-06-01'
    secret:
      name: loki-s3
      type: s3
  storageClassName: gp3
    2 
    
  tenants:
    mode: openshift-network
    1
    The installation examples in this documentation use the same namespace, netobserv, across all components. You can optionally use a different namespace.
    2
    Use a storage class name that is available on the cluster for ReadWriteOnce access mode. You can use oc get storageclasses to see what is available on your cluster.
    Important

    You must not reuse the same 

    LokiStack
    that is used for cluster logging.

  5. Click Create.

3.2.2.1. Deployment Sizing
Copia collegamento

Sizing for Loki follows the format of 

N<x>.<size>
where the value 
<N>
is the number of instances and 
<size>
specifies performance capabilities.

Note

1x.extra-small is for demo purposes only, and is not supported.

Expand
Table 3.2. Loki Sizing
 1x.extra-small1x.small1x.medium

Data transfer

Demo use only.

500GB/day

2TB/day

Queries per second (QPS)

Demo use only.

25-50 QPS at 200ms

25-75 QPS at 200ms

Replication factor

None

2

3

Total CPU requests

5 vCPUs

36 vCPUs

54 vCPUs

Total Memory requests

7.5Gi

63Gi

139Gi

Total Disk requests

150Gi

300Gi

450Gi

3.2.3. LokiStack ingestion limits and health alerts
Copia collegamento

The LokiStack instance comes with default settings according to the configured size. It is possible to override some of these settings, such as the ingestion and query limits. You might want to update them if you get Loki errors showing up in the Console plugin, or in 

flowlogs-pipeline
logs. An automatic alert in the web console notifies you when these limits are reached.

Here is an example of configured limits: 

spec:
  limits:
    global:
      ingestion:
        ingestionBurstSize: 40
        ingestionRate: 20
        maxGlobalStreamsPerTenant: 25000
      queries:
        maxChunksPerQuery: 2000000
        maxEntriesLimitPerQuery: 10000
        maxQuerySeries: 3000

For more information about these settings, see the LokiStack API reference.

3.2.4. Configuring authorization and multi-tenancy
Copia collegamento

Define 

ClusterRole
and 
ClusterRoleBinding
. The 
netobserv-reader
 
ClusterRole
enables multi-tenancy and allows individual user access, or group access, to the flows stored in Loki. You can create a YAML file to define these roles.

Procedure

  1. Using the web console, click the Import icon, +.
  2. Drop your YAML file into the editor and click Create:

Example ClusterRole reader yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: netobserv-reader
1 

rules:
- apiGroups:
  - 'loki.grafana.com'
  resources:
  - network
  resourceNames:
  - logs
  verbs:
  - 'get'

1
This role can be used for multi-tenancy.

Example ClusterRole writer yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: netobserv-writer
rules:
- apiGroups:
  - 'loki.grafana.com'
  resources:
  - network
  resourceNames:
  - logs
  verbs:
  - 'create'

Example ClusterRoleBinding yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: netobserv-writer-flp
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: netobserv-writer
subjects:
- kind: ServiceAccount
  name: flowlogs-pipeline
1 

  namespace: netobserv
- kind: ServiceAccount
  name: flowlogs-pipeline-transformer
  namespace: netobserv

1
The flowlogs-pipeline writes to Loki. If you are using Kafka, this value is flowlogs-pipeline-transformer.

3.2.5. Enabling multi-tenancy in Network Observability
Copia collegamento

Multi-tenancy in the Network Observability Operator allows and restricts individual user access, or group access, to the flows stored in Loki. Access is enabled for project admins. Project admins who have limited access to some namespaces can access flows for only those namespaces.

Prerequisite

  • You have installed Loki Operator version 5.7
  • The 
    FlowCollector
     
    spec.loki.authToken
    configuration must be set to 
    FORWARD
    .
  • You must be logged in as a project administrator

Procedure

  1. Authorize reading permission to 

    user1
    by running the following command: 

    $ oc adm policy add-cluster-role-to-user netobserv-reader user1

    Now, the data is restricted to only allowed user namespaces. For example, a user that has access to a single namespace can see all the flows internal to this namespace, as well as flows going from and to this namespace. Project admins have access to the Administrator perspective in the OpenShift Container Platform console to access the Network Flows Traffic page.

3.3. Installing the Network Observability Operator
Copia collegamento

You can install the Network Observability Operator using the OpenShift Container Platform web console Operator Hub. When you install the Operator, it provides the 

FlowCollector
custom resource definition (CRD). You can set specifications in the web console when you create the 
FlowCollector
.

Important

The actual memory consumption of the Operator depends on your cluster size and the number of resources deployed. Memory consumption might need to be adjusted accordingly. For more information refer to "Network Observability controller manager pod runs out of memory" in the "Important Flow Collector configuration considerations" section.

Prerequisites

  • If you choose to use Loki, install the Loki Operator version 5.7+.
  • You must have 
    cluster-admin
    privileges.
  • One of the following supported architectures is required: 
    amd64
    , 
    ppc64le
    , 
    arm64
    , or 
    s390x
    .
  • Any CPU supported by Red Hat Enterprise Linux (RHEL) 9.
  • Must be configured with OVN-Kubernetes or OpenShift SDN as the main network plugin, and optionally using secondary interfaces, such as Multus and SR-IOV.
Note

This documentation assumes that your 

LokiStack
instance name is 
loki
. Using a different name requires additional configuration.

Procedure

  1. In the OpenShift Container Platform web console, click Operators OperatorHub.
  2. Choose Network Observability Operator from the list of available Operators in the OperatorHub, and click Install.
  3. Select the checkbox 
    Enable Operator recommended cluster monitoring on this Namespace
    .
  4. Navigate to Operators Installed Operators. Under Provided APIs for Network Observability, select the Flow Collector link.

  5. Navigate to the Flow Collector tab, and click Create FlowCollector. Make the following selections in the form view:

    1. spec.agent.ebpf.Sampling: Specify a sampling size for flows. Lower sampling sizes will have higher impact on resource utilization. For more information, see the "FlowCollector API reference", 
      spec.agent.ebpf
      .

    2. If you are using Loki, set the following specifications:

      1. spec.loki.enable: Select the check box to enable storing flows in Loki.
      2. spec.loki.url: Since authentication is specified separately, this URL needs to be updated to 
        https://loki-gateway-http.netobserv.svc:8080/api/logs/v1/network
        . The first part of the URL, "loki", must match the name of your 
        LokiStack
        .
      3. spec.loki.authToken: Select the 
        FORWARD
        value.
      4. spec.loki.statusUrl: Set this to 
        https://loki-query-frontend-http.netobserv.svc:3100/
        . The first part of the URL, "loki", must match the name of your 
        LokiStack
        .
      5. spec.loki.tls.enable: Select the checkbox to enable TLS.

      6. spec.loki.statusTls: The 

        enable
        value is false by default.

        For the first part of the certificate reference names: 

        loki-gateway-ca-bundle
        , 
        loki-ca-bundle
        , and 
        loki-query-frontend-http
        ,
        loki
        , must match the name of your 
        LokiStack
        .

    3. Optional: If you are in a large-scale environment, consider configuring the 
      FlowCollector
      with Kafka for forwarding data in a more resilient, scalable way. See "Configuring the Flow Collector resource with Kafka storage" in the "Important Flow Collector configuration considerations" section.
    4. Optional: Configure other optional settings before the next step of creating the 
      FlowCollector
      . For example, if you choose not to use Loki, then you can configure exporting flows to Kafka or IPFIX. See "Export enriched network flow data to Kafka and IPFIX" and more in the "Important Flow Collector configuration considerations" section.
    5. Click Create.

Verification

To confirm this was successful, when you navigate to Observe you should see Network Traffic listed in the options.

In the absence of Application Traffic within the OpenShift Container Platform cluster, default filters might show that there are "No results", which results in no visual flow. Beside the filter selections, select Clear all filters to see the flow.

Important

If you installed Loki using the Loki Operator, it is advised not to use 

querierUrl
, as it can break the console access to Loki. If you installed Loki using another type of Loki installation, this does not apply.

3.5. Installing Kafka (optional)
Copia collegamento

The Kafka Operator is supported for large scale environments. Kafka provides high-throughput and low-latency data feeds for forwarding network flow data in a more resilient, scalable way. You can install the Kafka Operator as Red Hat AMQ Streams from the Operator Hub, just as the Loki Operator and Network Observability Operator were installed. Refer to "Configuring the FlowCollector resource with Kafka" to configure Kafka as a storage option.

Note

To uninstall Kafka, refer to the uninstallation process that corresponds with the method you used to install.

3.6. Uninstalling the Network Observability Operator
Copia collegamento

You can uninstall the Network Observability Operator using the OpenShift Container Platform web console Operator Hub, working in the Operators Installed Operators area.

Procedure

  1. Remove the 

    FlowCollector
    custom resource.

    1. Click Flow Collector, which is next to the Network Observability Operator in the Provided APIs column.
    2. Click the options menu kebab for the cluster and select Delete FlowCollector.

  2. Uninstall the Network Observability Operator.

    1. Navigate back to the Operators Installed Operators area.
    2. Click the options menu kebab next to the Network Observability Operator and select Uninstall Operator.
    3. Home Projects and select 
      openshift-netobserv-operator
    4. Navigate to Actions and select Delete Project

  3. Remove the 

    FlowCollector
    custom resource definition (CRD).

    1. Navigate to Administration CustomResourceDefinitions.
    2. Look for FlowCollector and click the options menu kebab .

    3. Select Delete CustomResourceDefinition.

      Important

      The Loki Operator and Kafka remain if they were installed and must be removed separately. Additionally, you might have remaining data stored in an object store, and a persistent volume that must be removed.

Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2026 Red HatTorna in cima