Merge pull request #63934 from skrthomas/netobserv-1.4-rn

skrthomas · web-flow · commit fa3416f2475b · 2023-09-28T19:38:41.000-04:00
Network Observability 1.4 Release Notes
diff --git a/networking/network_observability/network-observability-operator-release-notes.adoc b/networking/network_observability/network-observability-operator-release-notes.adoc
@@ -13,6 +13,91 @@ These release notes track the development of the Network Observability Operator
 
 For an overview of the Network Observability Operator, see xref:../../networking/network_observability/network-observability-overview.adoc#dependency-network-observability[About Network Observability Operator].
 
+[id="network-observability-operator-release-notes-1-4"]
+== Network Observability Operator 1.4.0
+The following advisory is available for the Network Observability Operator 1.4.0:
+
+* link:https://access.redhat.com/errata/RHSA-2023:5379[RHSA-2023:5379 Network Observability Operator 1.4.0]
+
+[id="network-observability-channel-removal-1.4"]
+=== Channel removal
+You must switch your channel from `v1.0.x` to `stable` to receive the latest Operator updates. The `v1.0.x` channel is now removed.
+
+[id="network-observability-operator-1.4.0-features-enhancements"]
+=== New features and enhancements
+
+[id="network-observability-enhanced-configuration-and-ui-1.4"]
+==== Notable enhancements
+The 1.4 release of the Network Observability Operator adds improvements and new capabilities to the {product-title} web console plugin and the Operator configuration. 
+
+[discrete]
+[id="web-console-enhancements-1.4_{context}"]
+===== Web console enhancements:
+
+* In the *Query Options*, the *Duplicate flows* checkbox is added to choose whether or not to show duplicated flows.
+* You can now filter source and destination traffic with image:arrow-up-long-solid.png[,10] *One-way*, image:arrow-up-long-solid.png[,10] image:arrow-down-long-solid.png[,10] *Back-and-forth*, and *Swap* filters. 
+* The Network Observability metrics dashboards in *Observe* -> *Dashboards* -> *NetObserv* and *NetObserv / Health* are modified as follows:
+** The *NetObserv* dashboard shows top bytes, packets sent, packets received per nodes, namespaces, and workloads. Flow graphs are removed from this dashboard.
+** The *NetObserv / Health* dashboard shows flows overhead as well as top flow rates per nodes, namespaces, and workloads.
+** Infrastructure and Application metrics are shown in a split-view for namespaces and workloads. 
+
+For more information, see xref:../../networking/network_observability/network-observability-overview.adoc#network-observability-dashboards[Network Observability metrics].
+
+[discrete]
+[id="configuration-enhancements-1.4_{context}"] 
+===== Configuration enhancements:
+
+* You now have the option to specify different namespaces for any configured ConfigMap or Secret reference, such as in certificates configuration.
+
+For more information, see xref:../../networking/network_observability/configuring-operator.adoc#network-observability-flowcollector-view_network_observability[Flow Collector sample resource] and xref:../../networking/network_observability/flowcollector-api.adoc#network-observability-flowcollector-api-specifications_network_observability[Flow Collector API Reference].
+
+[id="network-observability-without-loki-1.4"]
+==== Network Observability without Loki
+The Network Observability Operator is now functional and usable without Loki. If Loki is not installed, it can only export flows to KAFKA or IPFIX format and provide metrics in the Network Observability metrics dashboards. For more information, see xref:../../networking/network_observability/installing-operators.adoc#network-observability-without-loki_network_observability[Network Observability without Loki]. 
+
+[id="network-observability-dns-tracking-1.4"]
+==== DNS tracking
+In 1.4, the Network Observability Operator makes use of eBPF tracepoint hooks to enable DNS tracking. You can monitor your network, conduct security analysis, and troubleshoot DNS issues in the *Network Traffic* and *Overview* pages in the web console. 
+
+For more information, see xref:../../networking/network_observability/observing-network-traffic.adoc#network-observability-dns-overview_nw-observe-network-traffic[Configuring DNS tracking] and xref:../../networking/network_observability/observing-network-traffic.adoc#network-observability-dns-tracking_nw-observe-network-traffic[Working with DNS tracking].
+
+//Packet drops needs separate RN PR that doesn't cherrypick to 4.10+ since its only supported in 4.13+. This PR will go to 4.10+
+[id="SR-IOV-configuration-1.4"]
+==== SR-IOV support
+You can now collect traffic from a cluster with Single Root I/O Virtualization (SR-IOV) device. For more information, see xref:../../networking/network_observability/configuring-operator.adoc#network-observability-SR-IOV-config_network_observability[Configuring the monitoring of SR-IOV interface traffic].
+
+[id="IPFIX-support-1.4"]
+==== IPFIX exporter support
+You can now export eBPF-enriched network flows to the IPFIX collector. For more information, see xref:../../networking/network_observability/configuring-operator.adoc#network-observability-enriched-flows_network_observability[Export enriched network flow data].
+
+==== s390x architecture support
+Network Observability Operator can now run on `s390x` architecture. Previously it ran on `amd64`, `ppc64le`, or `arm64`.
+
+[id="network-observability-operator-1.4.0-bug-fixes"]
+=== Bug fixes
+* Previously, the Prometheus metrics exported by Network Observability were computed out of potentially duplicated network flows. In the related dashboards, from *Observe* -> *Dashboards*, this could result in potentially doubled rates. Note that dashboards from the *Network Traffic* view were not affected. Now, network flows are filtered to eliminate duplicates prior to metrics calculation, which results in correct traffic rates displayed in the dashboards. (link:https://issues.redhat.com/browse/NETOBSERV-1131[*NETOBSERV-1131*])
+
+* Previously, the Network Observability Operator agents were not able to capture traffic on network interfaces when configured with Multus or SR-IOV, non-default network namespaces. Now, all available network namespaces are recognized and used for capturing flows, allowing capturing traffic for SR-IOV. There are xref:../../networking/network_observability/configuring-operator.adoc#network-observability-SR-IOV-config_network_observability[configurations needed] for the `FlowCollector` and `SRIOVnetwork` custom resource to collect traffic. 
+(link:https://issues.redhat.com/browse/NETOBSERV-1283[*NETOBSERV-1283*])
+
+* Previously, in the Network Observability Operator details from *Operators* -> *Installed Operators*, the `FlowCollector` *Status* field might have reported incorrect information about the state of the deployment. The status field now shows the proper conditions with improved messages. The history of events is kept, ordered by event date. (link:https://issues.redhat.com/browse/NETOBSERV-1224[*NETOBSERV-1224*])
+
+* Previously, during spikes of network traffic load, certain eBPF pods were OOM-killed and went into a `CrashLoopBackOff` state. Now, the `eBPF` agent memory footprint is improved, so pods are not OOM-killed and entering a `CrashLoopBackOff` state. (link:https://issues.redhat.com/browse/NETOBSERV-975[*NETOBSERV-975*])
+
+* Previously when `processor.metrics.tls` was set to `PROVIDED` the `insecureSkipVerify` option value was forced to be `true`. Now you can set `insecureSkipVerify` to `true` or `false`, and provide a CA certificate if needed.  (link:https://issues.redhat.com/browse/NETOBSERV-1087[NETOBSERV-1087])
+
+[id="network-observability-operator-1.4.0-known-issues"]
+=== Known issues
+* Since the 1.2.0 release of the Network Observability Operator, using Loki Operator 5.6, a Loki certificate change periodically affects the `flowlogs-pipeline` pods and results in dropped flows rather than flows written to Loki. The problem self-corrects after some time, but it still causes temporary flow data loss during the Loki certificate change. This issue has only been observed in large-scale environments of 120 nodes or greater. (link:https://issues.redhat.com/browse/NETOBSERV-980[*NETOBSERV-980*])
+
+* Currently, when `spec.agent.ebpf.features` includes DNSTracking, larger DNS packets require the `eBPF` agent to look for DNS header outside of the 1st socket buffer (SKB) segment. A new `eBPF` agent helper function needs to be implemented to support it. Currently, there is no workaround for this issue. (link:https://issues.redhat.com/browse/NETOBSERV-1304[*NETOBSERV-1304*])
+
+* Currently, when `spec.agent.ebpf.features` includes DNSTracking, DNS over TCP packets requires the `eBPF` agent to look for DNS header outside of the 1st SKB segment. A new `eBPF` agent helper function needs to be implemented to support it. Currently, there is no workaround for this issue. (link:https://issues.redhat.com/browse/NETOBSERV-1245[*NETOBSERV-1245*])
+
+* Currently, when using a `KAFKA` deployment model, if conversation tracking is configured, conversation events might be duplicated across Kafka consumers, resulting in inconsistent tracking of conversations, and incorrect volumetric data. For that reason, it is not recommended to configure conversation tracking when `deploymentModel` is set to `KAFKA`. (link:https://issues.redhat.com/browse/NETOBSERV-926[*NETOBSERV-926*])
+
+* Currently, when the `processor.metrics.server.tls.type` is configured to use a `PROVIDED` certificate, the operator enters an unsteady state that might affect its performance and resource consumption. It is recommended to not use a `PROVIDED` certificate until this issue is resolved, and instead using an auto-generated certificate, setting `processor.metrics.server.tls.type` to `AUTO`. (link:https://issues.redhat.com/browse/NETOBSERV-1293)[*NETOBSERV-1293*]
+
 [id="network-observability-operator-release-notes-1-3"]
 == Network Observability Operator 1.3.0
 The following advisory is available for the Network Observability Operator 1.3.0:
@@ -40,7 +125,7 @@ You must switch your channel from `v1.0.x` to `stable` to receive future Operato
 
 [id="multi-arch-1.3"]
 ==== Multiple architectures now supported 
-* Network Observability Operator can now run on an amd64, ppc64le, or arm64 architecture. Previously, it only ran on amd64. 
+* Network Observability Operator can now run on an `amd64`, `ppc64le`, or `arm64` architectures. Previously, it only ran on `amd64`. 
 
 [id="deprecated-features-1.3"]
 === Deprecated features
@@ -63,13 +148,15 @@ The release of Network Observability Operator 1.3 deprecates the `spec.Loki.auth
 
 * Previously, when `processor.metrics.tls` was set to `AUTO` in the `FlowCollector`, the `flowlogs-pipeline servicemonitor` did not adapt the appropriate TLS scheme, and metrics were not visible in the web console. Now the issue is fixed for AUTO mode. (link:https://issues.redhat.com/browse/NETOBSERV-1070[*NETOBSERV-1070*])
 
-* Previously, certificate configuration, such as used for Kafka and Loki, did not allow specifying a namespace field, implying that the certificates had to be in the same namespace where Network Observability is deployed. Moreover, when using Kafka with TLS/mTLS, the user had to manually copy the certificate(s) to the privileged namespace where the eBPF agent pods are deployed and manually manage certificate updates, such as in the case of certificate rotation. Now, Network Observability setup is simplified by adding a namespace field for certificates in the `FlowCollector` resource. As a result, users can now install Loki or Kafka in different namespaces without needing to manually copy their certificates in the Network Observability namespace. The original certificates are watched so that the copies are automatically updated when needed. (link:https://issues.redhat.com/browse/NETOBSERV-773[*NETOBSERV-773*])
+* Previously, certificate configuration, such as used for Kafka and Loki, did not allow specifying a namespace field, implying that the certificates had to be in the same namespace where Network Observability is deployed. Moreover, when using Kafka with TLS/mTLS, the user had to manually copy the certificate(s) to the privileged namespace where the `eBPF` agent pods are deployed and manually manage certificate updates, such as in the case of certificate rotation. Now, Network Observability setup is simplified by adding a namespace field for certificates in the `FlowCollector` resource. As a result, users can now install Loki or Kafka in different namespaces without needing to manually copy their certificates in the Network Observability namespace. The original certificates are watched so that the copies are automatically updated when needed. (link:https://issues.redhat.com/browse/NETOBSERV-773[*NETOBSERV-773*])
 
 * Previously, the SCTP, ICMPv4 and ICMPv6 protocols were not covered by the Network Observability agents, resulting in a less comprehensive network flows coverage. These protocols are now recognized to improve the flows coverage. (link:https://issues.redhat.com/browse/NETOBSERV-934[*NETOBSERV-934*])
 
 [id="network-observability-operator-1.3.0-known-issues"]
-=== Known issue
-* When `processor.metrics.tls` is set to `PROVIDED` in the `FlowCollector`, the `flowlogs-pipeline` `servicemonitor` is not adapted to the TLS scheme. (link:https://issues.redhat.com/browse/NETOBSERV-1087[NETOBSERV-1087])
+=== Known issues
+* When `processor.metrics.tls` is set to `PROVIDED` in the `FlowCollector`, the `flowlogs-pipeline` `servicemonitor` is not adapted to the TLS scheme. (link:https://issues.redhat.com/browse/NETOBSERV-1087[*NETOBSERV-1087*])
+
+* Since the 1.2.0 release of the Network Observability Operator, using Loki Operator 5.6, a Loki certificate change periodically affects the `flowlogs-pipeline` pods and results in dropped flows rather than flows written to Loki. The problem self-corrects after some time, but it still causes temporary flow data loss during the Loki certificate change. This issue has only been observed in large-scale environments of 120 nodes or greater.(link:https://issues.redhat.com/browse/NETOBSERV-980[*NETOBSERV-980*])
 
 [id="network-observability-operator-release-notes-1-2"]
 == Network Observability Operator 1.2.0
@@ -99,7 +186,7 @@ The subscription of an installed Operator specifies an update channel that track
 [id="network-observability-operator-1.2.0-bug-fixes"]
 === Bug fixes
 
-* Previously, after changing the `namespace` value in the FlowCollector spec, eBPF Agent pods running in the previous namespace were not appropriately deleted. Now, the pods running in the previous namespace are appropriately deleted. (link:https://issues.redhat.com/browse/NETOBSERV-774[*NETOBSERV-774*])
+* Previously, after changing the `namespace` value in the FlowCollector spec, `eBPF` agent pods running in the previous namespace were not appropriately deleted. Now, the pods running in the previous namespace are appropriately deleted. (link:https://issues.redhat.com/browse/NETOBSERV-774[*NETOBSERV-774*])
 
 * Previously, after changing the `caCert.name` value in the FlowCollector spec (such as in Loki section), FlowLogs-Pipeline pods and Console plug-in pods were not restarted, therefore they were unaware of the configuration change. Now, the pods are restarted, so they get the configuration change. (link:https://issues.redhat.com/browse/NETOBSERV-772[*NETOBSERV-772*])
 
