이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 3. Network Observability Operator archived release notes


3.1. Network Observability Operator release notes archive

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

The following advisory is available for the Network Observability Operator 1.9.3:

3.1.2. Network Observability Operator 1.9.2 advisory

The following advisory is available for the Network Observability Operator 1.9.2:

3.1.3. Network observability 1.9.2 bug fixes

  • Before this update, OpenShift Container Platform 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.

3.1.4. Network observability 1.2.0 new features and enhancements

This release of network observability and the Network Observability Operator includes the following new features and enhancements:

3.1.4.1. Preparing for the next update

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.4.2. Histogram in Traffic Flows view

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.4.3. Conversation tracking

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.4.4. Network observability health alerts

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.5. Network observability 1.2.0 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. (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. (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.6. Network observability 1.1.0 enhancements

The following advisory is available 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.7. Network observability 1.1.0 bug fixes

  • Previously, unless the Loki authToken configuration was set to FORWARD mode, authentication was not enforced, allowing unauthorized users to retrieve flows. Now, regardless of the Loki authToken mode, only cluster administrators can retrieve flows. (BZ#2169468)
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat