Questo contenuto non è disponibile nella lingua selezionata.
Chapter 3. Network Observability Operator release notes archive
3.1. Network Observability Operator release notes archive Copia collegamentoCollegamento copiato negli appunti!
These release notes track past developments of the Network Observability Operator in the OpenShift Container Platform. They are for reference purposes only.
The Network Observability Operator enables administrators to observe and analyze network traffic flows for OpenShift Container Platform clusters.
3.1.1. Network Observability Operator 1.9.3 advisory Copia collegamentoCollegamento copiato negli appunti!
The following advisory is available for the Network Observability Operator 1.9.3:
3.1.2. Network Observability Operator 1.9.2 advisory Copia collegamentoCollegamento copiato negli appunti!
The following advisory is available for the Network Observability Operator 1.9.2:
3.1.3. Network observability 1.9.2 bug fixes Copia collegamentoCollegamento copiato negli appunti!
-
Before this update, OpenShift Container Platform versions 4.15 and earlier did not support the
TC_ATTACH_MODEconfiguration. 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 eliminatestcxhook errors and enables flow and packet observation.
3.1.4. Network observability release notes 1.2.0 preparing for the next update Copia collegamentoCollegamento copiato negli appunti!
Switch the Network Observability Operator’s update channel from the deprecated v1.0.x to the stable channel to continue receiving future releases and updates.
The subscription of an installed Operator specifies an update channel that tracks and receives updates for the Operator. Until the 1.2 release of the Network Observability Operator, the only channel available was v1.0.x. The 1.2 release of the Network Observability Operator introduces the stable update channel for tracking and receiving updates. You must switch your channel from v1.0.x to stable to receive future Operator updates. The v1.0.x channel is deprecated and planned for removal in a following release.
3.1.5. Network observability 1.2.0 advisory Copia collegamentoCollegamento copiato negli appunti!
You can view the following advisory for the Network Observability Operator 1.2.0 release.
3.1.6. Network observability 1.2.0 new features and enhancements Copia collegamentoCollegamento copiato negli appunti!
You can view the following new features and enhancements for the Network Observability Operator 1.2.0 release.
3.1.6.1. Histogram in Traffic Flows view Copia collegamentoCollegamento copiato negli appunti!
You can now choose to show a histogram of flows over time. The histogram enables you to visualize the history of flows without hitting the Loki query limit. For more information, see "Using the histogram".
3.1.6.2. Conversation tracking Copia collegamentoCollegamento copiato negli appunti!
You can now query flows by Log Type, which enables grouping network flows that are part of the same conversation. For more information, see "Working with conversations".
3.1.6.3. Network observability health alerts Copia collegamentoCollegamento copiato negli appunti!
The Network Observability Operator now creates automatic alerts if the flowlogs-pipeline is dropping flows because of errors at the write stage or if the Loki ingestion rate limit has been reached. For more information, see "Health dashboards".
3.1.7. Network observability 1.2.0 bug fixes Copia collegamentoCollegamento copiato negli appunti!
You can view the following fixed issues for the Network Observability Operator 1.2.0 release.
-
Previously, after changing the
namespacevalue in the FlowCollector spec,eBPFagent pods running in the previous namespace were not appropriately deleted. Now, the pods running in the previous namespace are appropriately deleted. (NETOBSERV-774) -
Previously, after changing the
caCert.namevalue 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. (NETOBSERV-772) - Previously, network flows between pods running on different nodes were sometimes not correctly identified as being duplicates because they are captured by different network interfaces. This resulted in over-estimated metrics displayed in the console plug-in. Now, flows are correctly identified as duplicates, and the console plug-in displays accurate metrics. (NETOBSERV-755)
- The "reporter" option in the console plug-in is used to filter flows based on the observation point of either source node or destination node. Previously, this option mixed the flows regardless of the node observation point. This was due to network flows being incorrectly reported as Ingress or Egress at the node level. Now, the network flow direction reporting is correct. The "reporter" option filters for source observation point, or destination observation point, as expected. (NETOBSERV-696)
- Previously, for agents configured to send flows directly to the processor as gRPC+protobuf requests, the submitted payload could be too large and is rejected by the processors' GRPC server. This occurred under very-high-load scenarios and with only some configurations of the agent. The agent logged an error message, such as: grpc: received message larger than max. As a consequence, there was information loss about those flows. Now, the gRPC payload is split into several messages when the size exceeds a threshold. As a result, the server maintains connectivity. (NETOBSERV-617)
3.1.8. Network observability 1.2.0 known issues Copia collegamentoCollegamento copiato negli appunti!
You can review the following issues and their workarounds, if available, to troubleshoot issues with the Network Observability Operator 1.2.0 release.
-
In the 1.2.0 release of the Network Observability Operator, using Loki Operator 5.6, a Loki certificate transition periodically affects the
flowlogs-pipelinepods 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 transition. (NETOBSERV-980)
3.1.9. Network observability 1.2.0 notable technical changes Copia collegamentoCollegamento copiato negli appunti!
The Network Observability Operator 1.2.0 release requires installation in the openshift-netobserv-operator namespace due to new technical changes. Users who previously used a custom namespace must delete the old instance and reinstall the Operator.
Previously, you could install the Network Observability Operator using a custom namespace. This release introduces the conversion webhook which changes the ClusterServiceVersion. Because of this change, all the available namespaces are no longer listed. Additionally, to enable Operator metrics collection, namespaces that are shared with other Operators, like the openshift-operators namespace, cannot be used.
Now, the Operator must be installed in the openshift-netobserv-operator namespace.
You cannot automatically upgrade to the new Operator version if you previously installed the Network Observability Operator using a custom namespace. If you previously installed the Operator using a custom namespace, you must delete the instance of the Operator that was installed and re-install your operator in the openshift-netobserv-operator namespace. It is important to note that custom namespaces, such as the commonly used netobserv namespace, are still possible for the FlowCollector, Loki, Kafka, and other plug-ins.
3.1.10. Network observability 1.1.0 enhancements Copia collegamentoCollegamento copiato negli appunti!
You can view the following advisory for the Network Observability Operator 1.1.0:
The Network Observability Operator is now stable and the release channel is upgraded to v1.1.0.
3.1.11. Network observability 1.1.0 fixed issues Copia collegamentoCollegamento copiato negli appunti!
You can view the following fixed issues for the Network Observability Operator 1.1.0 release.
-
Previously, unless the Loki
authTokenconfiguration was set toFORWARDmode, authentication was not enforced, allowing unauthorized users to retrieve flows. Now, regardless of the LokiauthTokenmode, only cluster administrators can retrieve flows. (BZ#2169468)