1.3. Network Observability Operator 1.4.0
Network Observability Operator 1.4.0 では、次のアドバイザリーを利用できます。
1.3.1. チャネルの削除
最新の Operator 更新を受信するには、チャネルを v1.0.x から stable に切り替える必要があります。v1.0.x チャネルは削除されました。
1.3.2. 新機能および機能拡張
1.3.2.1. 主な機能拡張
Network Observability Operator の 1.4 リリースでは、OpenShift Container Platform Web コンソールプラグインと Operator 設定が改良され、新機能が追加されています。
Web コンソールの機能拡張:
- Query Options に、重複したフローを表示するかどうかを選択するための Duplicate flows チェックボックスが追加されました。
-
送信元トラフィックおよび宛先トラフィックを、
One-way、
Back-and-forth、Swap のフィルターでフィルタリングできるようになりました。
Observe
Dashboards NetObserv、および NetObserv / Health のネットワーク可観測性メトリクスダッシュボードは次のように変更されます。 - NetObserv ダッシュボードには、ノード、namespace、およびワークロードごとに、上位のバイト、送信パケット、受信パケットが表示されます。フローグラフはこのダッシュボードから削除されました。
- NetObserv/Health ダッシュボードには、フローのオーバーヘッド以外にも、ノード、namespace、ワークロードごとの最大フローレートが表示されます。
- インフラストラクチャーとアプリケーションのメトリクスは、namespace とワークロードの分割ビューで表示されます。
詳細は、ネットワーク可観測性メトリクス と クイックフィルター を参照してください。
設定の機能拡張
- 証明書設定など、設定された ConfigMap または Secret 参照に対して異なる namespace を指定できるオプションが追加されました。
-
spec.processor.clusterNameパラメーターが追加されたため、クラスターの名前がフローデータに表示されるようになりました。これは、マルチクラスターコンテキストで役立ちます。OpenShift Container Platform を使用する場合は、自動的に決定されるように空のままにします。
詳細は、フローコレクターのサンプルリソース および フローコレクター API 参照 を参照してください。
1.3.2.2. Loki を使用しないネットワーク可観測性
Network Observability Operator は、Loki なしでも機能し、使用できるようになりました。Loki がインストールされていない場合は、フローを KAFKA または IPFIX 形式にエクスポートし、ネットワーク可観測性メトリクスダッシュボードに入力することのみ可能です。詳細は、Loki を使用しないネットワーク可観測性 を参照してください。
1.3.2.3. DNS 追跡
1.4 では、Network Observability Operator は eBPF トレースポイントフックを使用して DNS 追跡を有効にします。Web コンソールの Network Traffic ページと Overview ページで、ネットワークの監視、セキュリティー分析の実施、DNS 問題のトラブルシューティングを行なえます。
1.3.2.4. SR-IOV のサポート
Single Root I/O Virtualization (SR-IOV) デバイスを使用して、クラスターからトラフィックを収集できるようになりました。詳細は、SR-IOV インターフェイストラフィックの監視の設定 を参照してください。
1.3.2.5. IPFIX エクスポーターのサポート
eBPF が強化されたネットワークフローを IPFIX コレクターにエクスポートできるようになりました。詳細は、強化されたネットワークフローデータのエクスポート を参照してください。
1.3.2.6. s390x アーキテクチャーのサポート
Network Observability Operator が、s390x アーキテクチャー上で実行できるようになりました。以前は、amd64、ppc64le、または arm64 で実行されていました。
1.3.3. バグ修正
-
これまで、ネットワーク可観測性によってエクスポートされた 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 の詳細の FlowCollectorStatus フィールドで、デプロイメントの状態に関する誤った情報が報告されることがありました。ステータスフィールドには、改善されたメッセージと適切な状態が表示されるようになりました。イベントの履歴は、イベントの日付順に保存されます。(NETOBSERV-1224) -
以前は、ネットワークトラフィックの負荷が急増すると、特定の eBPF Pod が OOM によって強制終了され、
CrashLoopBackOff状態になりました。現在は、eBPFagent のメモリーフットプリントが改善されたため、Pod が OOM によって強制終了されてCrashLoopBackOff状態に遷移することはなくなりました。(NETOBSERV-975) -
以前は、
processor.metrics.tlsがPROVIDEDに設定されている場合、insecureSkipVerifyオプションの値が強制的にtrueに設定されていました。現在は、insecureSkipVerifyをtrueまたはfalseに設定し、必要に応じて CA 証明書を提供できるようになりました。(NETOBSERV-1087)
1.3.4. 既知の問題
-
Network Observability Operator 1.2.0 リリース以降では、Loki Operator 5.6 を使用すると、Loki 証明書の変更が定期的に
flowlogs-pipelinePod に影響を及ぼすため、フローが Loki に書き込まれず、ドロップされます。この問題はしばらくすると自動的に修正されますが、Loki 証明書の移行中に一時的なフローデータの損失が発生します。この問題は、120 以上のノードを内包する大規模環境でのみ発生します。(NETOBSERV-980) -
現在、
spec.agent.ebpf.featuresに DNSTracking が含まれている場合、DNS パケットが大きいと、eBPFagent が最初のソケットバッファー (SKB) セグメント外で DNS ヘッダーを探す必要があります。これをサポートするには、eBPFagent の新しいヘルパー関数を実装する必要があります。現在、この問題に対する回避策はありません。(NETOBSERV-1304) -
現在、
spec.agent.ebpf.featuresに DNSTracking が含まれている場合、DNS over TCP パケットを扱うときに、eBPFagent が最初の SKB セグメント外で DNS ヘッダーを探す必要があります。これをサポートするには、eBPFagent の新しいヘルパー関数を実装する必要があります。現在、この問題に対する回避策はありません。(NETOBSERV-1245) -
現在、
KAFKAデプロイメントモデルを使用する場合、会話の追跡が設定されていると会話イベントが Kafka コンシューマー間で重複する可能性があり、その結果、会話の追跡に一貫性がなくなり、ボリュームデータが不正確になる可能性があります。そのため、deploymentModelがKAFKAに設定されている場合は、会話の追跡を設定することは推奨されません。(NETOBSERV-926) -
現在、
processor.metrics.server.tls.typeがPROVIDED証明書を使用するように設定されている場合、Operator の状態が不安定になり、パフォーマンスとリソース消費に影響を与える可能性があります。この問題が解決されるまではPROVIDED証明書を使用せず、代わりに自動生成された証明書を使用し、processor.metrics.server.tls.typeをAUTOに設定することが推奨されます。(NETOBSERV-1293
