第3章 Network Observability Operator リリースノートアーカイブ


3.1. Network Observability Operator リリースノートアーカイブ

これらのリリースノートは、OpenShift Container Platform での Network Observability Operator の過去の開発を追跡します。それらは参照のみを目的としています。

Network Observability Operator を使用すると、管理者は OpenShift Container Platform クラスターのネットワークトラフィックフローを観察および分析できます。

3.1.1. Network Observability Operator 1.9.3 アドバイザリー

Network Observability Operator 1.9.3 では、次のアドバイザリーを利用できます。

3.1.2. Network Observability Operator 1.9.2 アドバイザリー

Network Observability Operator 1.9.2 では、次のアドバイザリーを利用できます。

3.1.3. Network Observability 1.9.2 のバグ修正

  • この更新前は、OpenShift Container Platform バージョン 4.15 以前では TC_ATTACH_MODE 設定はサポートされていませんでした。これにより、コマンドラインインターフェイス (CLI) エラーが発生し、パケットとフローの観測が妨げられました。このリリースでは、Traffic Control eXtension (TCX) のフックアタッチメントモードが、これらの古いバージョン向けに調整されました。これにより、tcx フックのエラーが解消され、フローとパケットの観測が可能になります。

3.1.4. ネットワーク可観測性リリースノート 1.2.0 の次の更新の準備

Network Observability Operator の更新チャネルを、非推奨の v1.0.x から stable チャネルに切り替えて、今後のリリースおよび更新を引き続き受信します。

インストールされた Operator のサブスクリプションは、Operator の更新を追跡および受信する更新チャネルを指定します。Network Observability Operator の 1.2 リリースまでは、利用可能なチャネルは v1.0.x だけでした。Network Observability Operator の 1.2 リリースでは、更新の追跡および受信用に stable 更新チャネルが導入されました。今後の Operator 更新を受信するには、チャネルを v1.0.x から stable に切り替える必要があります。v1.0.x チャネルは非推奨となり、次のリリースで削除される予定です。

3.1.5. ネットワーク可観測性 1.2.0 アドバイザリー

Network Observability Operator 1.2.0 リリースについて次のアドバイザリーを表示できます。

3.1.6. ネットワーク可観測性 1.2.0 の新機能および機能強化

Network Observability Operator 1.2.0 リリースの次の新機能および拡張機能を表示できます。

3.1.6.1. Traffic Flows ビューのヒストグラム

時間の経過とともにフローのヒストグラムを表示することを選択できるようになりました。ヒストグラムを使用すると、Loki クエリー制限に達することなくフロー履歴を可視化できます。詳細は、ヒストグラムの使用を参照してください。

3.1.6.2. 会話の追跡

ログタイプ でフローをクエリーできるようになりました。これにより、同じ会話に含まれるネットワークフローをグループ化できるようになりました。詳細は、会話の操作を参照してください。

3.1.6.3. Network Observability のヘルスアラート

Network Observability Operator は、書き込み段階でのエラーが原因で flowlogs-pipeline がフローをドロップする場合、または Loki 取り込みレート制限に達した場合、自動アラートを作成するようになりました。詳細は、「ヘルスダッシュボード」を参照してください。

3.1.7. ネットワーク可観測性 1.2.0 のバグ修正

Network Observability Operator 1.2.0 リリースには、次の修正された問題を表示できます。

  • これまでは、FlowCollector 仕様の namespace の値を変更すると、以前の namespace で実行されている eBPF agent Pod が適切に削除されませんでした。今は、以前の namespace で実行されている Pod も適切に削除されるようになりました。(NETOBSERV-774)
  • これまでは、FlowCollector 仕様 (Loki セクションなど) の caCert.name 値を変更しても、FlowLogs-Pipeline Pod および Console プラグイン Pod が再起動されないため、設定の変更が認識されませんでした。今は、Pod が再起動されるため、設定の変更が適用されるようになりました。(NETOBSERV-772)
  • これまでは、異なるノードで実行されている Pod 間のネットワークフローは、異なるネットワークインターフェイスでキャプチャーされるため、重複が正しく認識されないことがありました。その結果、コンソールプラグインに表示されるメトリクスが過大に見積もられていました。現在は、フローが重複として正しく識別され、コンソールプラグインで正確なメトリクスが表示されます。(NETOBSERV-755)
  • コンソールプラグインの "レポーター" オプションは、送信元ノードまたは宛先ノードのいずれかの観測点に基づいてフローをフィルタリングするために使用されます。以前は、このオプションはノードの観測点に関係なくフローを混合していました。これは、ネットワークフローがノードレベルで Ingress または Egress として誤って報告されることが原因でした。これで、ネットワークフロー方向のレポートが正しくなりました。"レポーター" オプションは、期待どおり、ソース観測点または宛先観測点をフィルターします。(NETOBSERV-696)
  • 以前は、フローを gRPC+protobuf リクエストとしてプロセッサーに直接送信するように設定されたエージェントの場合、送信されたペイロードが大きすぎる可能性があり、プロセッサーの GRPC サーバーによって拒否されました。これは、非常に高負荷のシナリオで、エージェントの一部の設定でのみ発生しました。エージェントは、次のようなエラーメッセージをログに記録しました: grpc: max より大きいメッセージを受信しました。その結果、それらのフローに関する情報が損失しました。現在、gRPC ペイロードは、サイズがしきい値を超えると、いくつかのメッセージに分割されます。その結果、サーバーは接続を維持します。(NETOBSERV-617)

3.1.8. ネットワーク可観測性 1.2.0 の既知の問題

次の問題とその回避策(利用可能な場合)を確認し、Network Observability Operator 1.2.0 リリースで問題をトラブルシューティングできます。

  • Loki Operator 5.6 を使用する Network Observability Operator の 1.2.0 リリースでは、Loki 証明書の移行が定期的に flowlogs-pipeline Pod に影響を及ぼし、その結果、Loki に書き込まれるフローではなくフローがドロップされます。この問題はしばらくすると自動的に修正されますが、依然として Loki 証明書の移行中に一時的なフローデータの損失が発生します。(NETOBSERV-980)

3.1.9. ネットワーク可観測性 1.2.0 の注目すべき技術的な変更

Network Observability Operator 1.2.0 リリースでは、新しい技術的な変更により、openshift-netobserv-operator namespace にインストールする必要があります。以前にカスタム namespace を使用していたユーザーは、古いインスタンスを削除し、Operator を再インストールする必要があります。

以前は、カスタム namespace を使用して Network Observability Operator をインストールできました。このリリースでは、ClusterServiceVersion を変更する conversion webhook が導入されています。この変更により、使用可能なすべての namespace がリストされなくなりました。さらに、Operator メトリクス収集を有効にするには、openshift-operators namespace など、他の Operator と共有される namespace は使用できません。

ここで、Operator を openshift-netobserv-operator namespace にインストールする必要があります。

以前にカスタム namespace を使用して Network Observability Operator をインストールした場合、新しい Operator バージョンに自動的にアップグレードすることはできません。以前にカスタム namespace を使用して Operator をインストールした場合は、インストールされた Operator のインスタンスを削除し、openshift-netobserv-operator namespace に Operator を再インストールする必要があります。一般的に使用される netobserv namespace などのカスタム namespace は、FlowCollector、Loki、Kafka、およびその他のプラグインでも引き続き使用できることに注意することが重要です。

3.1.10. ネットワークの可観測性 1.1.0 の強化

Network Observability Operator 1.1.0 に対して次のアドバイザリーを表示できます。

Network Observability Operator は現在安定しており、リリースチャンネルは v1.1.0 にアップグレードされています。

3.1.11. ネットワークの可観測性 1.1.0 の修正された問題

Network Observability Operator 1.1.0 リリースには、以下の修正された問題を表示できます。

  • 以前は、Loki の authToken 設定が FORWARD モードに設定されていない限り、認証が適用されず、権限のないユーザーがフローを取得できました。現在は、Loki の authToken モードに関係なく、クラスター管理者のみがフローを取得できます。(BZ#2169468)
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat