Skip to content

Commit 37e8fce

Browse files
authored
Merge pull request #110712 from openshift-cherrypick-robot/cherry-pick-109361-to-enterprise-4.22
[enterprise-4.22] OSDOCS-18561 [NETOBSERV] Final Vale Check for March 31 deadline
2 parents cc2b7e0 + 552fdaf commit 37e8fce

14 files changed

Lines changed: 89 additions & 62 deletions

modules/network-observability-create-network-policy.adoc

Lines changed: 22 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -2,13 +2,32 @@
22

33
// * networking/network_observability/network-observability-network-policy.adoc
44

5+
//03/31/2026: Include removed from assembly with 1.10. Remove when network observability docs move to the stand alone format as part of Clean the repo task. DITA changes made to pass Vale checks for March 31 deadline as move to stand alone will happen after March 31 deadline.
56

67
:_mod-docs-content-type: PROCEDURE
78
[id="network-observability-network-policy_{context}"]
89
= Creating a network policy for network observability
910

10-
If you want to further customize the network policies for the `netobserv` and `netobserv-privileged` namespaces, you must disable the managed installation of the policy from the `FlowCollector` CR, and create your own. You can use the network policy resources that are enabled from the `FlowCollector` CR as a starting point for the procedure that follows:
11+
[role="_abstract"]
12+
Customize network policies for the `netobserv` and `netobserv-privileged` namespaces by disabling the managed installation in the FlowCollector resource. Use the default managed policies as a template to create manual network policy configurations that meet specific security requirements.
1113

14+
.Procedure
15+
. Navigate to *Networking* -> *NetworkPolicies*.
16+
. Select the `netobserv` project from the *Project* dropdown menu.
17+
. Name the policy. For this example, the policy name is `allow-ingress`.
18+
. Click *Add ingress rule* three times to create three ingress rules.
19+
. Specify the following in the form:
20+
.. Make the following specifications for the first *Ingress rule*:
21+
... From the *Add allowed source* dropdown menu, select *Allow pods from the same namespace*.
22+
.. Make the following specifications for the second *Ingress rule*:
23+
... From the *Add allowed source* dropdown menu, select *Allow pods from inside the cluster*.
24+
... Click *+ Add namespace selector*.
25+
... Add the label, `kubernetes.io/metadata.name`, and the selector, `openshift-console`.
26+
.. Make the following specifications for the third *Ingress rule*:
27+
... From the *Add allowed source* dropdown menu, select *Allow pods from inside the cluster*.
28+
... Click *+ Add namespace selector*.
29+
... Add the label, `kubernetes.io/metadata.name`, and the selector, `openshift-monitoring`.
30+
+
1231
.Example `netobserv` network policy
1332
[source,yaml]
1433
----
@@ -36,7 +55,7 @@ spec:
3655
policyTypes:
3756
- Ingress
3857
----
39-
58+
+
4059
.Example `netobserv-privileged` network policy
4160
[source,yaml]
4261
----
@@ -56,24 +75,7 @@ spec:
5675
- Ingress
5776
----
5877

59-
.Procedure
60-
. Navigate to *Networking* -> *NetworkPolicies*.
61-
. Select the `netobserv` project from the *Project* dropdown menu.
62-
. Name the policy. For this example, the policy name is `allow-ingress`.
63-
. Click *Add ingress rule* three times to create three ingress rules.
64-
. Specify the following in the form:
65-
.. Make the following specifications for the first *Ingress rule*:
66-
... From the *Add allowed source* dropdown menu, select *Allow pods from the same namespace*.
67-
.. Make the following specifications for the second *Ingress rule*:
68-
... From the *Add allowed source* dropdown menu, select *Allow pods from inside the cluster*.
69-
... Click *+ Add namespace selector*.
70-
... Add the label, `kubernetes.io/metadata.name`, and the selector, `openshift-console`.
71-
.. Make the following specifications for the third *Ingress rule*:
72-
... From the *Add allowed source* dropdown menu, select *Allow pods from inside the cluster*.
73-
... Click *+ Add namespace selector*.
74-
... Add the label, `kubernetes.io/metadata.name`, and the selector, `openshift-monitoring`.
75-
7678
.Verification
7779
. Navigate to *Observe* -> *Network Traffic*.
7880
. View the *Traffic Flows* tab, or any tab, to verify that the data is displayed.
79-
. Navigate to *Observe* -> *Dashboards*. In the NetObserv/Health selection, verify that the flows are being ingested and sent to Loki, which is represented in the first graph.
81+
. Navigate to *Observe* -> *Dashboards*. In the NetObserv/Health selection, verify that the flows are being ingested and sent to Loki, which is represented in the first graph.

modules/network-observability-ebpf-flow-data-filtering-examples.adoc

Lines changed: 27 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -26,24 +26,28 @@ spec:
2626
type: eBPF
2727
ebpf:
2828
flowFilter:
29-
enable: true <1>
29+
enable: true
3030
rules:
31-
- action: Accept <2>
32-
cidr: 0.0.0.0/0 <3>
33-
sampling: 1 <4>
31+
- action: Accept
32+
cidr: 0.0.0.0/0
33+
sampling: 1
3434
- action: Accept
3535
cidr: 10.128.0.0/14
36-
peerCIDR: 10.128.0.0/14 <5>
36+
peerCIDR: 10.128.0.0/14
3737
- action: Accept
3838
cidr: 172.30.0.0/16
3939
peerCIDR: 10.128.0.0/14
4040
sampling: 50
4141
----
42-
<1> Enables `eBPF` flow filtering by setting `spec.agent.ebpf.flowFilter.enable` to `true`.
43-
<2> Defines the action for the flow filter rule. Valid values are `Accept` or `Reject`.
44-
<3> Defines the IP address and `CIDR` mask for the flow filter rule. This parameter supports both `IPv4` and `IPv6` address formats. Use `0.0.0.0/0` for `IPv4` or `::/0` for `IPv6` to match any IP address.
45-
<4> Defines the sampling interval for matched flows and overrides the global sampling setting (`spec.agent.ebpf.sampling`).
46-
<5> Filters flows by Peer IP `CIDR`.
42+
43+
where:
44+
45+
`spec.agent.ebpf.flowFilter.enable`:: Specifies whether to enable `eBPF` flow filtering. Set to `true` to enable flow filtering.
46+
`spec.agent.ebpf.flowFilter.rules.action`:: Specifies the action for the flow filter rule. Valid values are `Accept` or `Reject`.
47+
`spec.agent.ebpf.flowFilter.rules.cidr`:: Specifies the IP address and `CIDR` mask for the flow filter rule. This parameter supports both `IPv4` and `IPv6` address formats. Use `0.0.0.0/0` for `IPv4` or `::/0` for `IPv6` to match any IP address.
48+
`spec.agent.ebpf.flowFilter.rules.peerCIDR`:: Specifies the Peer IP `CIDR` used to filter flows.
49+
`spec.agent.ebpf.flowFilter.rules.sampling`:: Specifies the sampling interval for matched flows. This value overrides the global sampling setting defined in `spec.agent.ebpf.sampling`.
50+
4751

4852
[id="example-yaml-filter-flows-with-packet-drops_{context}"]
4953
== Example YAML to filter flows with packet drops
@@ -62,18 +66,21 @@ spec:
6266
agent:
6367
type: eBPF
6468
ebpf:
65-
privileged: true <1>
69+
privileged: true
6670
features:
67-
- PacketDrop <2>
71+
- PacketDrop
6872
flowFilter:
69-
enable: true <3>
73+
enable: true
7074
rules:
71-
- action: Accept <4>
75+
- action: Accept
7276
cidr: 172.30.0.0/16
73-
pktDrops: true <5>
77+
pktDrops: true
7478
----
75-
<1> Enables packet drops reporting by setting `spec.agent.ebpf.privileged` to `true`.
76-
<2> Reports packet drops for each network flow by adding the `PacketDrop` value to the `spec.agent.ebpf.features` list.
77-
<3> Enables `eBPF` flow filtering by setting `spec.agent.ebpf.flowFilter.enable` to `true`.
78-
<4> Defines the action for the flow filter rule. Valid values are `Accept` or `Reject`.
79-
<5> Filters flows that contain drops by setting `pktDrops` to `true`.
79+
80+
where:
81+
82+
`spec.agent.ebpf.privileged`:: Specifies whether to enable privileged mode, which is required for reporting packet drops.
83+
`spec.agent.ebpf.features`:: Specifies the list of eBPF features to enable. Adding the `PacketDrop` value to this list reports packet drops for each network flow.
84+
`spec.agent.ebpf.flowFilter.enable`:: Specifies whether to enable `eBPF` flow filtering.
85+
`spec.agent.ebpf.flowFilter.rules.action`:: Specifies the action for the flow filter rule. Valid values are `Accept` or `Reject`.
86+
`spec.agent.ebpf.flowFilter.rules.pktDrops`:: Specifies whether to filter for flows that contain packet drops.

modules/network-observability-enabling-alerts.adoc

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,8 @@
22
//
33
// network_observability/network-observability-alerts.adoc
44

5+
//03/31/2026: Temporary for alerts. Removed from assembly when feature GA'd. Remove file when network observability docs are moved to the stand alone format.
6+
57
:_mod-docs-content-type: PROCEDURE
68
[id="network-observability-enabling-alerts_{context}"]
79
= Enabling Technology Preview alerts in network observability
@@ -25,7 +27,7 @@ spec:
2527
env:
2628
EXPERIMENTAL_ALERTS_HEALTH: "true"
2729
----
28-
30+
+
2931
You can still use the existing method for creating alerts. For more information, see "Creating alerts".
3032

3133
//for NetObserv 1.10, specific to new alerts functionality and new health dashboard as a Technology Preview feature. This may or may not be needed when the feature GA's.
Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,16 @@
1+
// Module included in the following assemblies:
2+
//
3+
// network_observability/installing-operators.adoc
4+
5+
:_mod-docs-content-type: REFERENCE
6+
[id="additional-resources_configuring-flow-collector-considerations_{context}"]
7+
= Important Flow Collector configuration considerations
8+
9+
[role="_abstract"]
10+
Review essential `FlowCollector` configuration options before initial deployment to avoid pod disruptions caused by later reconfiguration. Key settings include Kafka integration, enriched flow data exports, SR-IOV traffic monitoring, and advanced tracking for DNS and packet drops.
11+
12+
When you create the `FlowCollector` instance, you can reconfigure it, but the pods are terminated and recreated again, which can be disruptive.
13+
14+
Therefore, you can consider configuring the following options when creating the `FlowCollector` for the first time.
15+
16+
//03/20/2026: Comment for JTBD work. This will likely need to be addressed and redone for JTBD. This file was created only to meet the ConceptLink rule by the deadline.

modules/network-observability-operator-release-notes-1-10-advisory.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@
66
= Network Observability Operator 1.10 advisory
77

88
[role="_abstract"]
9-
Review the advisory that is available for the Network Observability Operator 1.10:
9+
You can review the advisory for Network Observability Operator 1.10 release.
1010

1111
* link:https://access.redhat.com/errata/RHEA-2025:19153[RHEA-2025:19153 Network Observability Operator 1.10]
1212

modules/network-observability-operator-release-notes-1-10-technology-preview-features.adoc

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,9 @@
55
[id="network-observability-operator-release-notes-1-10-technology-preview-features_{context}"]
66
= Network Observability Operator 1.10 Technology Preview features
77

8+
[role="_abstract"]
9+
You can review the Technology Preview features for Network Observability Operator 1.10 release.
10+
811
[id="network-observability-operator-custom-alerts-technology-preview_{context}"]
912
== Network Observability Operator custom alerts (Technology Preview)
1013
This release introduces new alert functionality, and custom alert configuration. These capabilities are Technology Preview features, and must be explicitly enabled.

modules/network-observability-operator-release-notes-1-9-2-advisory.adoc

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,7 @@
55
[id="network-observability-operator-release-notes-1-9-2-advisory_{context}"]
66
= Network Observability Operator 1.9.2 advisory
77

8-
The following advisory is available for the Network Observability Operator 1.9.2:
8+
[role="_abstract"]
9+
You can review the advisory for Network Observability Operator 1.9.2 release.
910

1011
* link:https://access.redhat.com/errata/RHEA-2025:14150[RHEA-2025:14150 Network Observability Operator 1.9.2]

modules/network-observability-operator-release-notes-1-9-2-bug-fixes.adoc

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -5,4 +5,7 @@
55
[id="network-observability-release-notes-1-9-2-bug-fixes_{context}"]
66
= Network observability 1.9.2 bug fixes
77

8+
[role="_abstract"]
9+
You can review the fixed issues for the Network Observability Operator 1.9.1 release.
10+
811
* Before this update, {product-title} versions 4.15 and earlier did not support the `TC_ATTACH_MODE` configuration. This led to command-line interface (CLI) errors and prevented the observation of packets and flows. With this release, the Traffic Control eXtension (TCX) hook attachment mode has been adjusted for these older versions. This eliminates `tcx` hook errors and enables flow and packet observation.

modules/network-observability-operator-release-notes-1-9-3-advisory.adoc

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,7 @@
55
[id="network-observability-operator-release-notes-1-9-3-advisory_{context}"]
66
= Network Observability Operator 1.9.3 advisory
77

8-
The following advisory is available for the Network Observability Operator 1.9.3:
8+
[role="_abstract"]
9+
You can review the advisory for Network Observability Operator 1.9.3 release.
910

1011
* link:https://access.redhat.com/errata/RHEA-2025:15780[RHEA-2025:15780 Network Observability Operator 1.9.3]

modules/network-observability-predefined-metrics.adoc

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,10 @@
77
[id="network-observability-predefined-metrics_{context}"]
88
= Predefined metrics
99

10+
[role="_abstract"]
1011
Metrics generated by the `flowlogs-pipeline` are configurable in the `spec.processor.metrics.includeList` of the `FlowCollector` custom resource to add or remove metrics.
1112
////
1213

13-
//moved to network-observability-metrics-names.adoc
14+
//moved to network-observability-metrics-names.adoc
15+
16+
//03/31/2026 Remove when network observability docs move to the stand alone format as part of Clean the repo task.

0 commit comments

Comments
 (0)