サポートコンソール開発者トライアルの開始お問い合わせ

1.8. Network Observability Operator 1.4.0

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

1.8.1. チャネルの削除

最新の Operator 更新を受信するには、チャネルを v1.0.x から stable に切り替える必要があります。v1.0.x チャネルは削除されました。

1.8.2. 新機能および機能拡張

1.8.2.1. 主な機能拡張

Network Observability Operator の 1.4 リリースでは、OpenShift Container Platform Web コンソールプラグインと Operator 設定が改良され、新機能が追加されています。

Web コンソールの機能拡張:
  • Query Options に、重複したフローを表示するかどうかを選択するための Duplicate flows チェックボックスが追加されました。
  • 送信元トラフィックおよび宛先トラフィックを、 arrow up long solid One-way、 arrow up long solid arrow down long solid Back-and-forth、Swap のフィルターでフィルタリングできるようになりました。

  • Observe Dashboards NetObserv、および NetObserv / Health の Network Observability メトリクスダッシュボードは次のように変更されます。

    • NetObserv ダッシュボードには、ノード、namespace、およびワークロードごとに、上位のバイト、送信パケット、受信パケットが表示されます。フローグラフはこのダッシュボードから削除されました。
    • NetObserv/Health ダッシュボードには、フローのオーバーヘッド以外にも、ノード、namespace、ワークロードごとの最大フローレートが表示されます。
    • インフラストラクチャーとアプリケーションのメトリクスは、namespace とワークロードの分割ビューで表示されます。

詳細は、Network Observability メトリクス と クイックフィルター を参照してください。

設定の機能拡張
  • 証明書設定など、設定された ConfigMap または Secret 参照に対して異なる namespace を指定できるオプションが追加されました。
  • spec.processor.clusterName パラメーターが追加されたため、クラスターの名前がフローデータに表示されるようになりました。これは、マルチクラスターコンテキストで役立ちます。OpenShift Container Platform を使用する場合は、自動的に決定されるように空のままにします。

詳細は、Flow Collector のサンプルリソース と Flow Collector API リファレンス を参照してください。

1.8.2.2. Loki を使用しない Network Observability

Network Observability Operator は、Loki なしでも機能し、使用できるようになりました。Loki がインストールされていない場合は、フローを KAFKA または IPFIX 形式にエクスポートし、Network Observability メトリクスダッシュボードに入力することのみ可能です。詳細は、Loki を使用しない Network Observability を参照してください。

1.8.2.3. DNS 追跡

1.4 では、Network Observability Operator は eBPF トレースポイントフックを使用して DNS 追跡を有効にします。Web コンソールの Network Traffic ページと Overview ページで、ネットワークの監視、セキュリティー分析の実施、DNS 問題のトラブルシューティングを行なえます。

詳細は、DNS 追跡の設定 および DNS 追跡の使用 を参照してください。

1.8.2.4. SR-IOV のサポート

Single Root I/O Virtualization (SR-IOV) デバイスを使用して、クラスターからトラフィックを収集できるようになりました。詳細は、SR-IOV インターフェイストラフィックの監視の設定 を参照してください。

1.8.2.5. IPFIX エクスポーターのサポート

eBPF エンリッチ化ネットワークフローを IPFIX コレクターにエクスポートできるようになりました。詳細は、エンリッチされたネットワークフローデータのエクスポート を参照してください。

1.8.2.6. パケットドロップ

Network Observability Operator の 1.4 リリースでは、eBPF トレースポイントフックを使用してパケットドロップの追跡を有効にできます。パケットドロップの原因を検出して分析し、ネットワークパフォーマンスを最適化するための決定を行えるようになりました。OpenShift Container Platform 4.14 以降では、ホストのドロップと OVS のドロップの両方が検出されます。OpenShift Container Platform 4.13 では、ホストのドロップのみが検出されます。詳細は、パケットドロップト追跡の設定 および パケットドロップの使用 を参照してください。

1.8.2.7. s390x アーキテクチャーのサポート

Network Observability Operator が、s390x アーキテクチャー上で実行できるようになりました。以前は、amd64、ppc64le、または arm64 で実行されていました。

1.8.3. バグ修正

  • これまで、Network Observability によってエクスポートされた Prometheus メトリクスは、重複する可能性のあるネットワークフローから計算されていました。その結果、関連するダッシュボード (Observe Dashboards) でレートが 2 倍になる可能性がありました。ただし、Network Traffic ビューのダッシュボードは影響を受けていませんでした。現在は、メトリクスの計算前にネットワークフローがフィルタリングされて重複が排除されるため、ダッシュボードに正しいトラフィックレートが表示されます。(NETOBSERV-1131)
  • 以前は、Network Observability Operator エージェントは、Multus または SR-IOV (デフォルト以外のネットワーク namespace) で設定されている場合、ネットワークインターフェイス上のトラフィックをキャプチャーできませんでした。現在は、利用可能なすべてのネットワーク namespace が認識され、フローのキャプチャーに使用されるため、SR-IOV のトラフィックをキャプチャーできます。トラフィックを収集する場合は、FlowCollector および SRIOVnetwork カスタムリソースで 必要な設定 があります。(NETOBSERV-1283)
  • 以前は、Operators Installed Operators に表示される Network Observability Operator の詳細の FlowCollector Status フィールドで、デプロイメントの状態に関する誤った情報が報告されることがありました。ステータスフィールドには、改善されたメッセージと適切な状態が表示されるようになりました。イベントの履歴は、イベントの日付順に保存されます。(NETOBSERV-1224)
  • 以前は、ネットワークトラフィックの負荷が急増すると、特定の eBPF Pod が OOM によって強制終了され、CrashLoopBackOff 状態になりました。現在は、eBPF agent のメモリーフットプリントが改善されたため、Pod が OOM によって強制終了されて CrashLoopBackOff 状態に遷移することはなくなりました。(NETOBSERV-975)
  • 以前は、processor.metrics.tls が PROVIDED に設定されている場合、insecureSkipVerify オプションの値が強制的に true に設定されていました。現在は、insecureSkipVerify を true または false に設定し、必要に応じて CA 証明書を提供できるようになりました。(NETOBSERV-1087)

1.8.4. 既知の問題

  • Network Observability Operator 1.2.0 リリース以降では、Loki Operator 5.6 を使用すると、Loki 証明書の変更が定期的に flowlogs-pipeline Pod に影響を及ぼすため、フローが Loki に書き込まれず、ドロップされます。この問題はしばらくすると自動的に修正されますが、Loki 証明書の移行中に一時的なフローデータの損失が発生します。この問題は、120 以上のノードを内包する大規模環境でのみ発生します。(NETOBSERV-980)
  • 現在、spec.agent.ebpf.features に DNSTracking が含まれている場合、DNS パケットが大きいと、eBPF agent が最初のソケットバッファー (SKB) セグメント外で DNS ヘッダーを探す必要があります。これをサポートするには、eBPF agent の新しいヘルパー関数を実装する必要があります。現在、この問題に対する回避策はありません。(NETOBSERV-1304)
  • 現在、spec.agent.ebpf.features に DNSTracking が含まれている場合、DNS over TCP パケットを扱うときに、eBPF agent が最初の SKB セグメント外で DNS ヘッダーを探す必要があります。これをサポートするには、eBPF agent の新しいヘルパー関数を実装する必要があります。現在、この問題に対する回避策はありません。(NETOBSERV-1245)
  • 現在、KAFKA デプロイメントモデルを使用する場合、会話の追跡が設定されていると会話イベントが Kafka コンシューマー間で重複する可能性があり、その結果、会話の追跡に一貫性がなくなり、ボリュームデータが不正確になる可能性があります。そのため、deploymentModel が KAFKA に設定されている場合は、会話の追跡を設定することは推奨されません。(NETOBSERV-926)
  • 現在、processor.metrics.server.tls.type が PROVIDED 証明書を使用するように設定されている場合、Operator の状態が不安定になり、パフォーマンスとリソース消費に影響を与える可能性があります。この問題が解決されるまでは PROVIDED 証明書を使用せず、代わりに自動生成された証明書を使用し、processor.metrics.server.tls.type を AUTO に設定することが推奨されます。(NETOBSERV-1293
  • Network Observability Operator の 1.3.0 リリース以降、Operator をインストールすると、警告カーネル taint が表示されます。このエラーの理由は、Network Observability eBPF エージェントに、HashMap テーブル全体を事前割り当てするメモリー制約があることです。Operator eBPF エージェントは BPF_F_NO_PREALLOC フラグを設定し、HashMap がメモリーを大幅に使用している際に事前割り当てが無効化されるようにします。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.