Red Hat Summit第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. Network Observability Operator 1.9.0 アドバイザリー
Network Observability Operator 1.9.0 リリースに関するアドバイザリーを確認できます。
3.1.5. Network Observability Operator 1.9.0 の新機能と機能強化
Network Observability Operator 1.9.0 リリース の新機能と拡張機能を確認できます。
3.1.5.1. ユーザー定義ネットワークと Network Observability の連携
このリリースでは、Network Observability で ユーザー定義ネットワーク (UDN) 機能が一般提供になりました。Network Observability で UDNMapping 機能が有効になっている場合、Traffic フローテーブルに UDN labels 列が表示されます。Source Network Name と Destination Network Name の情報に基づいてログをフィルタリングできます。
3.1.5.2. フローログ取り込み時のフィルタリング
このリリースでは、生成されるネットワークフローの数と Network Observability コンポーネントのリソース使用量を削減するためのフィルターを作成できます。設定できるフィルターは次のとおりです。
- eBPF エージェントフィルター
- flowlogs-pipeline フィルター
3.1.5.3. IPsec のサポート
この更新により、OpenShift Container Platform で IPsec が有効な場合、Network Observability に次の機能拡張が導入されます。
- IPsec Status という新しい列が Network Observability の Traffic フロービューに表示され、フローが正常に IPsec で暗号化されたかどうか、または暗号化/復号化中にエラーが発生したかどうかが表示されます。
- 暗号化されたトラフィックの割合を示す新しいダッシュボードが生成されます。
3.1.5.4. Network Observability CLI
パケット、フロー、メトリクスのキャプチャーで、次のフィルタリングオプションが利用できるようになりました。
-
--samplingオプションを使用して、サンプリングされるパケットの比率を設定します。 -
--queryオプションを使用して、カスタムクエリーを使用してフローをフィルタリングします。 -
--interfacesオプションを使用して、監視するインターフェイスを指定します。 -
--exclude_interfacesオプションを使用して、除外するインターフェイスを指定します。 -
--include_listオプションを使用して、生成するメトリクス名を指定します。
詳細は、Network Observability CLI リファレンス を参照してください。
3.1.6. Network Observability Operator リリースノート 1.9.0 で注目すべき技術的な変更点
Network Observability Operator 1.6.0 リリースの主な技術的な変更を確認できます。
-
Network Observability 1.9 では、
NetworkEvents機能が、OpenShift Container Platform 4.19 の新しい Linux カーネルで動作するように更新されました。この更新により、古いカーネルとの互換性が失われます。そのため、NetworkEvents機能は OpenShift Container Platform 4.19 でのみ使用できます。Network Observability 1.8 および OpenShift Container Platform 4.18 でこの機能を使用している場合は、Network Observability のアップグレードを回避するか、Network Observability 1.9 にアップグレードし、OpenShift Container Platform を 4.19 にアップグレードすることを検討してください。 -
netobserv-readerクラスターロールの名前がnetobserv-loki-readerに変更されました。 - eBPF エージェントの CPU パフォーマンスが向上しました。
3.1.7. Network Observability Operator 1.9.0 テクノロジープレビュー機能
Network Observability Operator 1.9.0 リリースのテクノロジープレビュー機能を確認できます。
現在、今回のリリースに含まれる機能にはテクノロジープレビューのものがあります。これらの実験的機能は、実稼働環境での使用を目的としていません。これらの機能に関しては、Red Hat カスタマーポータルの以下のサポート範囲を参照してください。
3.1.7.1. eBPF Manager Operator と Network Observability の連携
eBPF Manager Operator は、すべての eBPF プログラムを管理することで、攻撃対象領域を削減し、コンプライアンス、セキュリティー、競合防止を実現します。Network Observability は、eBPF Manager Operator を使用してフックをロードできます。これにより、特権モードや、CAP_BPF や CAP_PERFMON などの追加の Linux ケイパビリティーを eBPF エージェントに提供する必要がなくなります。eBPF Manager Operator と Network Observability の連携は、64 ビット AMD アーキテクチャーでのみサポートされています。
3.1.8. Network Observability Operator 1.9.0 CVE
Network Observability Operator 1.9.0 リリースの CVE を確認できます。
3.1.9. Network Observability Operator 1.9.0 の修正された問題
Network Observability Operator 1.9.0 リリースの修正された問題を確認できます。
-
以前は、コンソールプラグインから送信元または送信先 IP でフィルタリングするときに、
10.128.0.0/24などの Classless Inter-Domain Routing (CIDR) 表記を使用すると機能せず、除外されるはずの結果が返されていました。この更新により、CIDR 表記を使用できるようになり、結果が期待どおりにフィルタリングされるようになりました。(NETOBSERV-2276) -
以前は、ネットワークフローが使用中のネットワークインターフェイスを誤って識別することがあり、特に
eth0とens5が混同されるリスクがありました。この問題は、eBPF エージェントがPrivilegedとして設定されている場合にのみ発生していました。この更新により、問題が部分的に修正され、ほぼすべてのネットワークインターフェイスが正しく識別されるようになりました。詳細は、以下の既知の問題を参照してください。(NETOBSERV-2257) - 以前は、Operator が動作を適応させるために利用可能な Kubernetes API をチェックするときに、古い API がある場合、Operator の正常な起動を妨げるエラーが発生していました。この更新により、Operator は関連のない API のエラーを無視し、関連する API のエラーをログに記録して、正常に実行を続行するようになりました。(NETOBSERV-2240)
- 以前は、コンソールプラグインの Traffic フロービューで、フローを Bytes または Packets で並べ替えることができませんでした。この更新により、ユーザーがフローを Bytes と Packets で並べ替えられるようになりました。(NETOBSERV-2239)
-
以前は、IPFIX エクスポーターを使用して
FlowCollectorリソースを設定すると、IPFIX フロー内の MAC アドレスが最初の 2 バイトに切り捨てられていました。この更新により、MAC アドレスが IPFIX フロー内で完全に表現されるようになりました。(NETOBSERV-2208) - 以前は、Operator 検証 Webhook から送信される警告の一部に、実行する必要がある内容が明確に示されていないものがありました。この更新により、このようなメッセージの一部が見直され、より実用的なものに修正されました。(NETOBSERV-2178)
-
以前は、入力エラーなどが発生した場合、
FlowCollectorリソースからLokiStackを参照するときに問題が発生したのかどうかが明確にわかりませんでした。この更新により、そのような場合に、参照されたLokiStackが見つからないことがFlowCollectorステータスに明確に示されるようになりました。(NETOBSERV-2174) - 以前は、コンソールプラグインの Traffic flows ビューで、テキストがオーバーフローすると、テキストの省略記号により、表示されるテキストの大部分が隠れてしまうことがありました。この更新により、可能な限り多くのテキストが表示されるようになりました。(NETOBSERV-2119)
- 以前は、Network Observability 1.8.1 以前のコンソールプラグインが OpenShift Container Platform 4.19 Web コンソールで動作しなかったため、Network Traffic ページにアクセスできませんでした。この更新により、コンソールプラグインに互換性が追加され、Network Observability 1.9.0 で Network Traffic ページにアクセスできるようになりました。(NETOBSERV-2046)
-
以前は、会話トラッキング (
FlowCollectorリソースのlogTypes: ConversationsまたはlogTypes: All) を使用すると、ダッシュボードに表示される Traffic レートのメトリクスに不具合が発生し、トラフィックの増加が制御不能であると誤って表示されていました。現在は、より正確なトラフィックレートがメトリクスに表示されます。ただし、ConversationsおよびEndedConversationsモードでは、長時間にわたる接続は対象外であるため、これらのメトリクスは依然として完全には正確でないことに注意してください。この情報はドキュメントに追加されました。このような不正確さを避けるために、デフォルトモードのlogTypes: Flowsが推奨されます。(NETOBSERV-1955)
3.1.10. Network Observability Operator 1.9.0 の既知の問題
Network Observability Operator 1.9.0 リリースの既知の問題を確認できます。
- ユーザー定義ネットワーク (UDN) 機能はサポートされていますが、OpenShift Container Platform 4.18 で使用すると、設定の問題と警告が表示されます。この警告は無視できます。(NETOBSERV-2305)
-
まれに、eBPF エージェントが複数のネットワーク namespace がある環境で
privilegedモードで実行されている場合、フローと関連するインターフェイスを適切に相関させることができないことがあります。この問題の大部分は今回のリリースで特定され解決されました。しかし、特にens5インターフェイスに関しては、いくつかの不整合が残っています。(NETOBSERV-2287)
3.1.11. Network Observability Operator 1.8.1 アドバイザリー
Network Observability Operator 1.8.1 リリースに関するアドバイザリーを確認できます。
3.1.12. Network Observability Operator 1.8.1 CVE
Network Observability Operator 1.8.1 リリースの CVE を確認できます。
3.1.13. Network Observability Operator 1.8.0 の修正された問題
Network Observability Operator 1.8.1 リリースに関する修正された問題を確認できます。
- この修正により、OpenShift Container Platform の今後のバージョンでは、Observe メニューが 1 回だけ表示されるようになります。(NETOBSERV-2139)
3.1.14. Network Observability Operator 1.8.0 アドバイザリー
Network Observability Operator 1.8.0 リリースに関するアドバイザリーを確認できます。
3.1.15. Network Observability Operator 1.8.0 の新機能と機能強化
Network Observability Operator 1.8.0 リリースの新機能および拡張機能を確認できます。
3.1.15.1. パケット変換
変換されたエンドポイント情報を使用してネットワークフローをエンリッチできるようになりました。サービスだけでなく特定のバックエンド Pod も表示されるため、どの Pod がリクエストを処理したか確認できます。
詳細は、エンドポイント変換 (xlat) および エンドポイント変換 (xlat) の操作 を参照してください。
3.1.15.2. OVN-Kubernetes ネットワークイベントの追跡
OVN-Kubernetes ネットワークイベントの追跡は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
Network Observability のネットワークイベントトラッキングを使用して、ネットワークポリシー、管理ネットワークポリシー、Egress ファイアウォールなどの OVN-Kubernetes イベントに関する情報を取得できるようになりました。
詳細は、ネットワークイベントの表示 を参照してください。
3.1.15.3. 1.8 における eBPF パフォーマンスの改善
- Network Observability では、per-CPU マップの代わりにハッシュマップが使用されるようになりました。つまり、ネットワークフローデータがカーネル空間で追跡され、新しいパケットもそこに集約されます。ネットワークフローの重複排除がカーネル内で実行できるようになったため、カーネルとユーザー空間の間のデータ転送サイズによってパフォーマンスが向上します。これらの eBPF パフォーマンスの向上により、eBPF エージェントで CPU リソースが 40% から 57% 削減される可能性があります。
3.1.15.4. Network Observability CLI
このリリースでは、Network Observability CLI に次の新しい機能、オプション、フィルターが追加されました。
-
oc netobserv metricsコマンドを実行して、フィルターを有効にしてメトリクスをキャプチャーします。 -
フローおよびパケットキャプチャーで
--backgroundオプションを使用して CLI をバックグラウンドで実行し、oc netobserv followを実行してバックグラウンド実行の進行状況を確認し、oc netobserv copyを実行して生成されたログをダウンロードします。 -
--get-subnetsオプションを使用して、マシン、Pod、およびサービスのサブネットでフローとメトリクスのキャプチャーを強化します。 以下は、パケット、フロー、メトリクスのキャプチャーで利用できる新しいフィルタリングオプションです。
- IP、ポート、プロトコル、アクション、TCP フラグなどに基づく eBPF フィルター
-
--node-selectorを使用するカスタムノード -
--dropsのみを使用するドロップ -
--regexesを使用する任意のフィールド
詳細は、Network Observability CLI リファレンス を参照してください。
3.1.16. Network Observability Operator リリースノート 1.8.0 の修正済みの問題
Network Observability Operator 1.8.0 リリースに関する修正された問題を確認できます。
- 以前は、Network Observability Operator には、メトリクスサーバーの RBAC を管理するための "kube-rbac-proxy" コンテナーが付属していました。この外部コンポーネントは非推奨であるため、削除する必要がありました。これは、サイドカープロキシーを必要としない、Kubernetes コントローラーランタイムを介した TLS および RBAC の直接管理に置き換えられました。(NETOBSERV-1999)
- 以前の OpenShift Container Platform コンソールプラグインでは、複数の値と一致しないキーでフィルタリングするとフィルタリングされませんでした。この修正により、フィルタリングされた値が一切含まれないフローという期待どおりの結果が返されます。(NETOBSERV-1990)
- 以前は、Loki が無効になっている OpenShift Container Platform コンソールプラグインでは、互換性のないフィルターと集計のセットを選択することで "Can’t build query" エラーが発生することが多くなっていました。現在は、ユーザーにフィルターの非互換性を認識させつつ、互換性のないフィルターを自動的に無効にすることで、このエラーを回避しています。(NETOBSERV-1977)
- 以前は、コンソールプラグインからフローの詳細を表示すると、ICMP 情報が常にサイドパネルに表示され、ICMP 以外のフローの場合は "undefined" の値が表示されていました。この修正により、ICMP 以外のフローでは ICMP 情報が表示されなくなります。(NETOBSERV-1969)
- 以前は、Traffic flows ビューの "Export data" リンクが意図したとおりに機能せず、空の CSV レポートが生成されていました。現在は、エクスポート機能が復元され、空ではない CSV データが生成されます。(NETOBSERV-1958)
-
以前は、会話ログは Loki が有効な場合にのみ役立つにもかかわらず、
loki.enableをfalseに設定して、processor.logTypesConversations、EndedConversations、またはAllを使用してFlowCollectorを設定することが可能でした。その結果、リソースを無駄に使用していました。現在、この設定は無効であり、検証 Webhook によって拒否されます。(NETOBSERV-1957) -
FlowCollectorで、processor.logTypesをAllに設定すると、他のオプションよりも CPU、メモリー、ネットワーク帯域幅などのリソースがはるかに多く消費されます。この点は、以前は文書化されていませんでした。これは現在文書化されており、検証 Webhook から警告がトリガーされます。(NETOBSERV-1956) - 以前は、負荷が高い場合に、eBPF エージェントによって生成された一部のフローが誤って破棄され、トラフィック帯域幅が予測を下回っていました。現在、生成されたフローは破棄されません。(NETOBSERV-1954)
-
以前は、
FlowCollector設定でネットワークポリシーを有効にすると、Operator Webhook へのトラフィックがブロックされ、FlowMetricsAPI 検証が機能しなくなっていました。現在は、Webhook へのトラフィックは許可されます。(NETOBSERV-1934) -
以前は、デフォルトのネットワークポリシーをデプロイすると、
additionalNamespacesフィールドにデフォルトでopenshift-consoleとopenshift-monitoringの namespace が設定され、ルールが重複していました。現在は、デフォルトで追加の namespace が設定されなくなったため、ルールの重複を防止できます。(NETOBSERV-1933) - 以前は、OpenShift Container Platform コンソールプラグインから TCP フラグでフィルタリングすると、目的のフラグのみを持つフローが一致していました。現在は、少なくとも目的のフラグを持つフローがフィルタリングされたフローに表示されるようになります。(NETOBSERV-1890)
- eBPF エージェントが特権モードで実行され、Pod が継続的に追加または削除されると、ファイル記述子 (FD) リークが発生します。この修正により、ネットワーク namespace の削除時に FD が適切に閉じられるようになります。(NETOBSERV-2063)
-
以前は、CLI エージェント
DaemonSetはマスターノードにデプロイされませんでした。現在は、taint が設定された場合にすべてのノードでスケジュールするための toleration がエージェントDaemonSetに追加されています。CLI エージェントDaemonSetPod はすべてのノードで実行されます。(NETOBSERV-2030) - 以前は、Prometheus ストレージのみを使用する場合、Source Resource および Source Destination フィルターのオートコンプリートは機能しませんでした。現在、この問題は修正され、提案が期待どおりに表示されるようになりました。(NETOBSERV-1885)
- 以前は、複数の IP を使用するリソースは Topology ビューで個別に表示されていました。現在は、リソースはビュー内で単一のトポロジーノードとして表示されます。(NETOBSERV-1818)
- 以前は、マウスポインターを列の上に置くと、コンソールで Network traffic テーブルビューの内容が更新されていました。現在は表示が固定され、ポインターを置いても行の高さは一定のままです。(NETOBSERV-2049)
3.1.17. Network Observability Operator リリースノート 1.8.0 の既知の問題
Network Observability Operator 1.8.0 リリースの既知の問題を確認できます。
- クラスター内に重複するサブネットを使用するトラフィックがある場合、eBPF エージェントが重複した IP からのフローを混同するリスクがわずかにあります。これは、異なる接続がまったく同じ送信元 IP と宛先 IP を持ち、ポートとプロトコルが 5 秒の時間枠内にあり、同じノードで発生している場合に発生する可能性があります。セカンダリーネットワークまたは UDN を設定しない限り、これは不可能です。その場合でも、通常は送信元ポートが差別化要因となるため、通常のトラフィックで発生する可能性は非常に低くなります。(NETOBSERV-2115)
-
OpenShift Container Platform Web コンソールのフォームビューから、
FlowCollectorリソースのspec.exportersセクションで設定するエクスポーターのタイプを選択した後、そのタイプの詳細な設定がフォームに表示されません。回避策として、YAML を直接設定します。(NETOBSERV-1981)
3.1.18. Network Observability Operator 1.7.0 アドバイザリー
Network Observability Operator 1.7.0 リリースのアドバイザリーを確認できます。
3.1.19. Network Observability Operator 1.7.0 の新機能と機能拡張
Network Observability Operator 1.7.0 リリースの次の新機能と機能拡張を確認できます。
3.1.19.1. OpenTelemetry のサポート
エンリッチされたネットワークフローを、Red Hat build of OpenTelemetry などの互換性のある OpenTelemetry エンドポイントにエクスポートできるようになりました。詳細は、エンリッチされたネットワークフローデータのエクスポート を参照してください。
3.1.19.2. Network Observability Developer パースペクティブ
Developer パースペクティブで Network Observability を使用できるようになりました。詳細は、OpenShift Container Platform コンソールの統合 を参照してください。
3.1.19.3. TCP フラグフィルタリング
tcpFlags フィルターを使用して、eBPF プログラムによって処理されるパケットの量を制限できるようになりました。詳細は、フローフィルターの設定パラメーター、eBPF フローのルールフィルター、および FlowMetric API と TCP フラグを使用した SYN フラッディングの検出 を参照してください。
3.1.19.4. OpenShift Virtualization の Network Observability
Open Virtual Network (OVN)-Kubernetes などを介してセカンダリーネットワークに接続された仮想マシンから送信される eBPF エンリッチ化ネットワークフローを検出することで、OpenShift Virtualization 環境のネットワークパターンを観測できます。詳細は、仮想マシン (VM) のセカンダリーネットワークインターフェイスを Network Observability 用に設定する を参照してください。
3.1.19.5. FlowCollector カスタムリソース (CR) でのネットワークポリシーのデプロイ
このリリースでは、FlowCollector カスタムリソース (CR) を設定して、ネットワーク可観測性のためのネットワークポリシーをデプロイできます。以前は、ネットワークポリシーが必要な場合は、手動で作成する必要がありました。ネットワークポリシーを手動で作成するオプションは引き続き利用可能です。詳細は、FlowCollector カスタムリソースを使用した Ingress ネットワークポリシーの設定 を参照してください。
3.1.19.6. FIPS コンプライアンス
FIPS モードで実行されている OpenShift Container Platform クラスターに Network Observability Operator をインストールして使用できます。
重要クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された Red Hat Enterprise Linux (RHEL) コンピューターからインストールプログラムを実行する必要があります。RHEL で FIPS モードを設定する方法の詳細は、RHEL から FIPS モードへの切り替え を参照してください。
FIPS モードでブートされた Red Hat Enterprise Linux (RHEL) または Red Hat Enterprise Linux CoreOS (RHCOS) を実行する場合、OpenShift Container Platform コアコンポーネントは、x86_64、ppc64le、および s390x アーキテクチャーのみで、FIPS 140-2/140-3 検証のために NIST に提出された RHEL 暗号化ライブラリーを使用します。
3.1.19.7. eBPF エージェントの機能拡張
eBPF エージェントで次の機能拡張を利用できます。
-
DNS サービスが
53以外のポートにマッピングされている場合は、spec.agent.ebpf.advanced.env.DNS_TRACKING_PORTを使用して、この DNS 追跡ポートを指定できます。 - トランスポートプロトコル (TCP、UDP、または SCTP) のフィルタリングルールに 2 つのポートを使用できるようになりました。
- プロトコルフィールドを空のままにしておくことで、ワイルドカードプロトコルを使用してトランスポートポートをフィルタリングできるようになりました。
詳細は、FlowCollector API 仕様 を参照してください。
3.1.19.8. Network Observability CLI
Network Observability CLI (oc netobserv) が一般提供になりました。1.6 テクノロジープレビューリリース以降、次の機能強化が行われました。
- フローキャプチャーと同様に、パケットキャプチャー用の eBPF エンリッチメントフィルターが追加されました。
-
フローキャプチャーとパケットキャプチャーの両方でフィルター
tcp_flagsを使用できるようになりました。 - 最大バイト数または最大時間に達したときに、自動ティアダウンオプションを利用できます。
詳細は、Network Observability CLI について および Network Observability CLI 1.7.0 を参照してください。
3.1.20. Network Observability Operator 1.7.0 で修正された問題
Network Observability Operator 1.7.0 リリースで修正された次の問題を確認できます。
-
以前は、RHEL 9.2 リアルタイムカーネルを使用すると、一部の Webhook が機能しませんでした。現在は、この RHEL 9.2 リアルタイムカーネルが使用されているかどうかを確認するための修正が導入されています。このカーネルが使用されている場合、
s390xアーキテクチャーの使用時にパケットドロップやラウンドトリップ時間などの機能が実行されないという内容の警告が表示されます。この修正は OpenShift 4.16 以降で適用されます。(NETOBSERV-1808) - 以前は、Overview タブの Manage panels ダイアログで、total、bar、donut、または line でフィルタリングしても、結果が表示されませんでした。現在は、利用可能なパネルが正しくフィルタリングされます。(NETOBSERV-1540)
-
以前は、高ストレス下で eBPF エージェントが多数の小さなフローを生成する状態になり、フローがほとんど集約されないことがありました。この修正により、集約プロセスが高いストレス下でも維持され、作成されるフローが少なくなりました。この修正により、eBPF エージェントだけでなく、
flowlogs-pipelineおよび Loki でもリソース消費が改善されます。(NETOBSERV-1564) -
以前は、
namespace_flows_totalメトリクスではなく、workload_flows_totalメトリクスが有効になっていると、健全性ダッシュボードにBy namespaceフローチャートが表示されませんでした。この修正により、workload_flows_totalが有効な場合に健全性ダッシュボードにフローチャートが表示されるようになりました。(NETOBSERV-1746) -
以前は、
FlowMetricsAPI を使用してカスタムメトリクスを生成し、後で新しいラベルを追加するなどしてそのラベルを変更すると、メトリクスの入力が停止し、flowlogs-pipelineログにエラーが表示されていました。この修正により、ラベルを変更しても、flowlogs-pipelineログにエラーが表示されなくなりました。(NETOBSERV-1748) -
以前は、デフォルトの Loki の
WriteBatchSize設定に不一致がありました。FlowCollectorCRD のデフォルトでは 100 KB に設定されていましたが、OLM のサンプルまたはデフォルト設定では 10 MB に設定されていました。現在は、両方とも 10 MB になりました。これにより、全般的にパフォーマンスが向上し、リソースフットプリントが削減されました。(NETOBSERV-1766) - 以前は、プロトコルを指定しなかった場合、ポート上の eBPF フローフィルターが無視されていました。この修正により、ポートやプロトコルごとに eBPF フローフィルターを個別に設定できるようになりました。(NETOBSERV-1779)
- 以前は、Pod からサービスへのトラフィックが トポロジービュー に表示されませんでした。サービスから Pod への戻りトラフィックのみが表示されていました。この修正により、そのトラフィックも正しく表示されるようになりました。(NETOBSERV-1788)
- 以前は、Network Observability にアクセスできるクラスター管理者以外のユーザーが、namespace など、自動補完をトリガーする項目をフィルタリングしようとすると、コンソールプラグインにエラーが表示されていました。この修正により、エラーが表示されなくなり、自動補完によって期待どおりの結果が返されるようになりました。(NETOBSERV-1798)
- セカンダリーインターフェイスのサポートが追加されたときに、インターフェイスの通知を確認するために、ネットワークごとの namespace を netlink に登録する作業を複数回繰り返す必要がありました。同時に、TC とは異なり、TCX フックではインターフェイスがダウンしたときにハンドラーを明示的に削除する必要があったため、失敗したハンドラーによってファイル記述子のリークが発生しました。さらに、ネットワーク namespace が削除されるときに、netlink goroutine ソケットを終了する Go クローズチャネルイベントが存在していなかったため、Go スレッドがリークしていました。現在は、Pod を作成または削除するときに、ファイル記述子や Go スレッドがリークしなくなりました。(NETOBSERV-1805)
- 以前は、フローの JSON で該当するデータが利用可能であっても、Traffic flows テーブルの ICMP のタイプと値に、'n/a' と表示されていました。この修正により、ICMP 列にフローテーブル内の該当する値が期待どおりに表示されるようになりました。(NETOBSERV-1806)
- 以前は、コンソールプラグインで、未設定の DNS レイテンシーなどの未設定のフィールドをフィルタリングできないことがありました。この修正により、未設定のフィールドでのフィルタリングが可能になりました。(NETOBSERV-1816)
- 以前は、OpenShift Web コンソールプラグインでフィルターをクリアして、別のページに移動してからフィルターがあったページに戻ると、フィルターが再表示される場合がありました。この修正により、クリアした後にフィルターが予期せず再表示されることがなくなりました。(NETOBSERV-1733)
3.1.21. Network Observability Operator 1.7.0 の既知の問題
Network Observability Operator 1.7.0 リリースの次の既知の問題を確認できます。
- Network Observability で must-gather ツールを使用する場合、クラスターで FIPS が有効になっているとログが収集されません。(NETOBSERV-1830)
FlowCollectorでspec.networkPolicyが有効になっている場合、netobservnamespace にネットワークポリシーがインストールされるため、FlowMetricsAPI を使用できません。ネットワークポリシーにより、検証 Webhook への呼び出しがブロックされます。回避策として、次のネットワークポリシーを使用してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.22. Network Observability Operator リリースノート 1.6.2 のアドバイザリー
Network Observability Operator 1.6.2 リリースのアドバイザリーを確認できます。
3.1.23. Network Observability Operator リリースノート 1.6.2 の CVE
Network Observability Operator 1.6.2 リリースの CVE を確認できます。
3.1.24. Network Observability Operator リリースノート 1.6.2 の修正された問題
Network Observability Operator 1.6.2 リリースで修正された問題を確認できます。
- セカンダリーインターフェイスのサポートが追加されたときに、インターフェイスの通知を確認するために、ネットワークごとの namespace を netlink に登録する作業を複数回繰り返す必要がありました。同時に、TC とは異なり、TCX フックではインターフェイスがダウンしたときにハンドラーを明示的に削除する必要があったため、失敗したハンドラーによってファイル記述子のリークが発生しました。これで、Pod の作成および削除時にファイル記述子がリークしなくなりました。(NETOBSERV-1805)
3.1.25. Network Observability Operator リリースノート 1.6.2 の既知の問題
Network Observability Operator 1.6.2 リリースの既知の問題を確認できます。
- コンソールプラグインとの互換性の問題があり、OpenShift Container Platform クラスターの将来のバージョンに Network Observability をインストールできない可能性がありました。1.6.2 にアップグレードすると、互換性の問題が解決され、Network Observability を期待どおりにインストールできるようになります。(NETOBSERV-1737)
3.1.26. Network Observability Operator リリースノート 1.6.1 のアドバイザリー
Network Observability Operator 1.6.1 リリースのアドバイザリーを確認できます。
3.1.27. Network Observability Operator リリースノート 1.6.1 の CVE
Network Observability Operator 1.6.1 リリースの CVE を確認できます。
3.1.28. Network Observability Operator リリースノート 1.6.1 の修正された問題
Network Observability Operator 1.6.1 リリースで修正された問題を確認できます。
- 以前は、原因や TCP 状態などのパケットドロップに関する情報は、Loki データストアでのみ入手でき、Prometheus では入手できませんでした。そのため、OpenShift Web コンソールプラグインの 概要 のドロップ統計は、Loki でのみ利用可能でした。この修正により、パケットドロップに関する情報もメトリクスに追加されるため、Loki が無効になっているときにドロップ統計を表示できるようになります。(NETOBSERV-1649)
-
eBPF エージェントの
PacketDrop機能が有効になっていて、サンプリングが1より大きい値に設定されていると、報告されたドロップされたバイトとドロップされたパケットではサンプリング設定が無視されます。これは、ドロップを見逃さないように意図的に行われたものですが、副作用として、ドロップなしの報告率と比較したドロップの報告率が偏ってしまいました。たとえば、1:1000などの非常に高いサンプリングレートでは、コンソールプラグインから見ると、ほぼすべてのトラフィックがドロップされているように見える可能性があります。この修正により、ドロップされたバイトとパケットでサンプリング設定が尊重されるようになりました。(NETOBSERV-1676) - 以前は、最初にインターフェイスが作成されてから eBPF エージェントがデプロイされると、SR-IOV セカンダリーインターフェイスが検出されませんでした。これは、最初にエージェントがデプロイされ、その後 SR-IOV インターフェイスが作成された場合にのみ検出されました。この修正により、デプロイメントの順序に関係なく SR-IOV セカンダリーインターフェイスが検出されるようになりました。(NETOBSERV-1697)
- 以前は、Loki が無効になっていると、関連機能が有効になっていない場合でも、OpenShift Web コンソールの Topology ビューで、ネットワークトポロジーダイアグラムの横にあるスライダーに Cluster と Zone の集約オプションが表示されていました。この修正により、スライダーには有効な機能に応じたオプションのみが表示されるようになりました。(NETOBSERV-1705)
-
以前は、Loki が無効になっていて、OpenShift Web コンソールが初めて読み込まれると、
Request failed with status code 400 Loki is disabledエラーが発生していました。この修正により、エラーは発生しなくなりました。(NETOBSERV-1706) - 以前は、OpenShift Web コンソールの トポロジー ビューで、任意のグラフノードの横にある Step into アイコンをクリックすると、選択したグラフノードにフォーカスを設定するために必要なフィルターが適用されず、OpenShift Web コンソールに Topology ビューの広いビューが表示されていました。この修正により、フィルターが正しく設定され、トポロジー が効果的に絞り込まれます。この変更の一環として、ノード 上の Step into アイコンをクリックすると、Namespaces スコープではなく Resource スコープに移動するようになりました。(NETOBSERV-1720)
- 以前は、Loki が無効になっていると、Scope が Owner に設定されている OpenShift Web コンソールの Topology ビューで、任意のグラフノードの横にある Step into アイコンをクリックすると、Scope が Resource に移動しましたが、これは Loki なしでは利用できないため、エラーメッセージが表示されていました。この修正により、Loki が無効になっていると、Owner スコープで Step into アイコンが非表示になるため、このシナリオは発生しなくなります。(NETOBSERV-1721)
- 以前は、Loki が無効になっている場合に、グループを設定すると OpenShift Web コンソールの Topology ビューにエラーが表示されましたが、その後スコープが変更されたため、グループが無効になりました。この修正により、無効なグループが削除され、エラーが防止されます。(NETOBSERV-1722)
-
YAML ビュー ではなく、OpenShift Web コンソールの Form view から
FlowCollectorリソースを作成すると、agent.ebpf.metrics.enableおよびprocessor.subnetLabels.openShiftAutoDetectの設定が Web コンソールによって誤って管理されていました。これらの設定は、Form view ではなく、YAML view でのみ無効にできます。混乱を避けるため、これらの設定は Form view から削除されました。これらは引き続き YAML view でアクセスできます。(NETOBSERV-1731) - 以前は、eBPF エージェントは、SIGTERM 信号によるクラッシュなど、予期しないクラッシュの前にインストールされたトラフィック制御フローをクリーンアップできませんでした。これにより、古いものが削除されなかったため、同じ名前のトラフィック制御フローフィルターが複数作成されました。この修正により、エージェントの起動時に、新しいトラフィック制御フローがインストールされる前に、以前にインストールされたトラフィック制御フローがすべてクリーンアップされるようになります。(NETOBSERV-1732)
- 以前は、カスタムサブネットラベルを設定し、OpenShift サブネットの自動検出を有効にしたままにすると、OpenShift サブネットがカスタムサブネットよりも優先され、クラスターサブネット内のカスタムラベルの定義が妨げられていました。この修正により、カスタム定義されたサブネットが優先され、クラスター内のサブネットにカスタムラベルを定義できるようになります。(NETOBSERV-1734)
3.1.29. Network Observability Operator リリースノート 1.6.0 のアドバイザリー
Network Observability Operator 1.6.0 リリースのアドバイザリーを確認できます。
3.1.30. Network Observability Operator 1.6.0 の新機能と機能拡張
Network Observability Operator 1.6.0 の次の新機能と機能拡張を確認できます。
3.1.30.1. Loki を使用しない場合の Network Observability Operator の使用の強化
Network Observability Operator を使用すると、Prometheus メトリクスを使用でき、ストレージのために Loki に依存する度合いが低下します。
3.1.30.2. カスタムメトリクス API
FlowMetrics API を使用して、フローログデータからカスタムメトリクスを作成できます。フローログデータを Prometheus ラベルと組み合わせて使用することで、ダッシュボード上のクラスター情報をカスタマイズできます。識別する必要があるフローおよびメトリクスのサブネットに、カスタムラベルを追加できます。この機能拡張により、新しいラベル SrcSubnetLabel と DstSubnetLabel を使用して、フローログとメトリクスの両方に存在する外部トラフィックをより簡単に識別することもできます。外部トラフィックがある場合、これらのフィールドが空になるため、外部トラフィックを識別できます。
3.1.30.3. eBPF のパフォーマンスの強化
次の更新により、CPU とメモリーの面で eBPF エージェントのパフォーマンスが向上しました。
- eBPF エージェントが、TC の代わりに TCX Webhook を使用するようになりました。
NetObserv/Health ダッシュボードに、eBPF メトリクスを表示する新しいセクションがあります。
- eBPF エージェントがフローをドロップしたときに、新しい eBPF メトリクスに基づいてアラートが通知されます。
- 重複したフローが削除されたため、Loki のストレージ需要が大幅に減少しました。ネットワークインターフェイス別の重複した複数のフローが、関連する一連のネットワークインターフェイスを含む重複排除された 1 つのフローになりました。
重複したフローの更新により、Network Traffic テーブルの Interface および Interface Direction フィールドの名前が Interfaces および Interface Directions に変更されました。そのため、これらのフィールドを使用するブックマーク済みの クイックフィルター のクエリーを、interfaces および ifdirections に更新する必要があります。
3.1.30.4. eBPF 収集のルールベースのフィルタリング
ルールベースのフィルタリングを使用して、作成されるフローの量を削減できます。このオプションを有効にすると、eBPF エージェント統計の Netobserv/Health ダッシュボードに、Filtered flows rate ビューが表示されます。
3.1.31. Network Observability Operator 1.6.0 で修正された問題
Network Observability Operator 1.6.0 で修正された次の問題を確認できます。
-
以前は、
FlowMetricsAPI 作成用の Operator Lifecycle Manager (OLM) フォームに、OpenShift Container Platform ドキュメントへの無効なリンクが表示されていました。このリンクの参照先が有効なページに更新されました。(NETOBSERV-1607) - 以前は、Operator Hub の Network Observability Operator の説明に、ドキュメントへの無効なリンクが表示されていました。この修正により、このリンクは復元されます。(NETOBSERV-1544)
-
以前は、Loki が無効になっていて Loki
ModeがLokiStackに設定されていても、または Loki の手動 TLS 設定が設定されていても、Network Observability Operator が Loki CA 証明書の読み取りを試行していました。この修正により、Loki が無効になっている場合、Loki 設定に設定があっても Loki 証明書が読み取られなくなりました。(NETOBSERV-1647) -
以前は、Network Observability Operator の
ocmust-gatherプラグインがamd64アーキテクチャーでしか動作せず、他のすべてのアーキテクチャーでは失敗していました。これは、プラグインがocバイナリーにamd64を使用していたためです。現在、Network Observability Operatorocのmust-gatherプラグインは、あらゆるアーキテクチャープラットフォームでログを収集します。 -
以前は、
not equal toを使用して IP アドレスをフィルタリングすると、Network Observability Operator がリクエストエラーを返していました。現在は、IP アドレスと範囲がequalの場合でもnot equal toの場合でも、IP フィルタリングが機能します。(NETOBSERV-1630) -
以前は、ユーザーが管理者でなかった場合、エラーメッセージが Web コンソールの Network Traffic ビューで選択したタブと一致しませんでした。現在は、
user not adminエラーがどのタブにも表示されるようになり、表示が改善されました。(NETOBSERV-1621)
3.1.32. Network Observability Operator 1.6.0 の既知の問題
Network Observability Operator 1.6.0 の次の既知の問題を確認できます。
-
eBPF エージェントの
PacketDrop機能が有効になっていて、サンプリングが1より大きい値に設定されている場合、ドロップされたバイト数とドロップされたパケット数の報告で、サンプリング設定が無視されます。これはドロップを見逃さないように意図的に行われますが、副作用として、ドロップが報告された割合と非ドロップが報告された割合が偏ってしまいます。たとえば、1:1000などの非常に高いサンプリングレートでは、コンソールプラグインから見ると、ほぼすべてのトラフィックがドロップされているように見える可能性があります。(NETOBSERV-1676) - Overview タブの Manage panels ウィンドウで、total、bar、donut、または line でフィルタリングしても、結果が表示されません。(NETOBSERV-1540)
- SR-IOV セカンダリーインターフェイスを作成してから eBPF エージェントをデプロイした場合、インターフェイスは検出されません。エージェントをデプロイしてから SR-IOV インターフェイスを作成した場合にのみ検出されます。(NETOBSERV-1697)
- Loki が無効になっている場合、OpenShift Web コンソールの Topology ビューで、関連機能が有効になっていない場合でも、ネットワークトポロジー図の横にあるスライダーに Cluster および Zone 集計オプションが常に表示されます。これらのスライダーオプションを無視する以外に、具体的な回避策はありません。(NETOBSERV-1705)
-
Loki が無効になっているときに、OpenShift Web コンソールが初めて読み込まれると、
Request failed with status code 400 Loki is disabledというエラーが表示される場合があります。回避策としては、Topology タブと Overview タブをクリックするなど、Network Traffic ページのコンテンツを何度か切り替える方法があります。エラーが表示されなくなるはずです。(NETOBSERV-1706)
3.1.33. Network Observability Operator 1.5.0 アドバイザリー
Network Observability Operator 1.5 リリースの次のアドバイザリーを参照できます。
3.1.34. Network Observability Operator 1.5.0 の新機能と機能拡張
Network Observability Operator 1.5 リリースの次の新機能と機能拡張を確認できます。
3.1.34.1. DNS 追跡の機能拡張
1.5 では、UDP に加えて TCP プロトコルもサポートされるようになりました。また、新しいダッシュボードが、Network Traffic ページの Overview ビューに追加されました。
3.1.34.2. ラウンドトリップタイム (RTT)
fentry/tcp_rcv_established Extended Berkeley Packet Filter (eBPF) フックポイントから取得した TCP ハンドシェイクのラウンドトリップタイム (RTT) を使用して、平滑化されたラウンドトリップタイム (SRTT) を読み取り、ネットワークフローを分析できます。Web コンソールの Overview、Network Traffic、および Topology ページで、ネットワークトラフィックを監視し、RTT メトリクス、フィルタリング、およびエッジラベルを使用してトラブルシューティングを行うことができます。
3.1.34.3. メトリクス、ダッシュボード、アラートの機能拡張
Observe includeList 仕様で定義できるようになりました。以前のリリースでは、これらのメトリクスは ignoreTags 仕様で定義されていました。
3.1.34.4. Loki を使用していない場合の Network Observability の向上
Loki を使用していない場合でも、DNS、パケットドロップ、および RTT メトリクスを使用して Netobserv ダッシュボードの Prometheus アラートを作成できます。旧バージョンの Network Observability 1.4 では、これらのメトリクスは、Network Traffic、Overview、および Topology ビューでのクエリーと分析にのみ使用できました。これらのビューを使用するには、Loki が必要でした。
3.1.34.5. アベイラビリティーゾーン
クラスターのアベイラビリティーゾーンに関する情報を収集するように FlowCollector リソースを設定できます。この設定では、ノードに適用される topology.kubernetes.io/zone ラベル値を使用してネットワークフローデータをエンリッチします。
3.1.34.6. 主な機能拡張
Network Observability Operator の 1.5 リリースでは、OpenShift Container Platform Web コンソールプラグインと Operator 設定が改良され、新機能が追加されています。
3.1.34.7. パフォーマンスの強化
Kafka 使用時の eBPF のパフォーマンスを向上させるために、
spec.agent.ebpf.kafkaBatchSizeのデフォルトが10MBから1MBに変更されました。重要既存のインストールからアップグレードする場合、この新しい値は自動的に設定されません。アップグレード後に eBPF Agent のメモリー消費のパフォーマンスリグレッションが確認された場合は、
kafkaBatchSizeを減らして別の値にすることを検討してください。
3.1.34.8. Web コンソールの機能拡張:
- DNS と RTT の Overview ビューに新しいパネル (Min、Max、P90、P99) が追加されました。
新しいパネル表示オプションが追加されました。
- 1 つのパネルに焦点を当て、他のパネルの表示を小さくする。
- グラフの種類を切り替える。
- Top と Overall を表示する。
- Custom time range ウィンドウに収集遅延の警告が表示されます。
- Manage panels および Manage columns ポップアップウィンドウの内容の視認性が向上しました。
- Egress QoS の Differentiated Services Code Point (DSCP) フィールドを使用して、Web コンソールの Network Traffic ページの QoS DSCP をフィルタリングできます。
3.1.34.9. 設定の機能拡張
-
spec.loki.mode仕様をLokiStackモードにすると、URL、TLS、クラスターロール、クラスターロールバインディング、およびauthToken値を自動的に設定され、インストールが簡素化されます。Manualモードを使用すると、これらの設定をより詳細に制御できます。 -
API バージョンが
flows.netobserv.io/v1beta1からflows.netobserv.io/v1beta2に変更されます。
3.1.35. Network Observability Operator 1.5.0 で修正された問題
Network Observability Operator 1.5 リリースで修正された次の問題を確認できます。
-
以前は、コンソールプラグインの自動登録が無効になっている場合、Web コンソールインターフェイスでコンソールプラグインを手動で登録することができませんでした。
FlowCollectorリソースのspec.console.register値がfalseに設定されている場合、Operator がプラグインの登録をオーバーライドして消去します。この修正により、spec.console.register値をfalseに設定しても、コンソールプラグインの登録または登録削除に影響しなくなりました。その結果、プラグインを手動で安全に登録できるようになりました。(NETOBSERV-1134) -
以前は、デフォルトのメトリクス設定を使用すると、NetObserv/Health ダッシュボードに Flows Overhead という名前の空のグラフが表示されていました。このメトリクスを使用するには、
ignoreTagsリストから "namespaces-flows" と "namespaces" を削除する必要がありました。この修正により、デフォルトのメトリクス設定を使用する場合にこのメトリクスが表示されるようになります。(NETOBSERV-1351) - 以前は、eBPF Agent を実行しているノードが、特定のクラスター設定で解決されませんでした。これにより連鎖的な影響が生じ、最終的にトラフィックメトリクスの一部を提供できなくなりました。この修正により、eBPF Agent のノード IP が、Pod のステータスから推測されて、Operator によって安全に提供されるようになりました。これにより、欠落していたメトリクスが復元されました。(NETOBSERV-1430)
- 以前は、Loki Operator の Loki エラー 'Input size too long' に、問題をトラブルシューティングするための追加情報が含まれていませんでした。この修正により、Web コンソールのエラーの隣にヘルプが直接表示され、詳細なガイダンスへの直接リンクが表示されるようになりました。(NETOBSERV-1464)
-
以前は、コンソールプラグインの読み取りタイムアウトが 30 秒に強制的に指定されていました。
FlowCollectorv1beta2API の更新により、この値を、Loki Operator のqueryTimeout制限に基づいて更新するようにspec.loki.readTimeout仕様を設定できるようになりました。(NETOBSERV-1443) -
以前は、Operator バンドルが、CSV アノテーションによってサポートされている機能の一部 (
features.operators.openshift.io/…など) を期待どおりに表示しませんでした。この修正により、これらのアノテーションが期待どおりに CSV に設定されるようになりました。(NETOBSERV-1305) -
以前は、調整中に
FlowCollectorステータスがDeploymentInProgress状態とReady状態の間で変動することがありました。この修正により、基礎となるコンポーネントがすべて完全に準備完了した場合にのみ、ステータスがReadyになります。(NETOBSERV-1293)
3.1.36. Network Observability Operator 1.5.0 の既知の問題
Network Observability Operator 1.5 リリースの次の既知の問題を確認できます。
-
Web コンソールにアクセスしようとすると、OCP 4.14.10 のキャッシュの問題により、Observe ビューにアクセスできなくなります。Web コンソールに
Failed to get a valid plugin manifest from /api/plugins/monitoring-plugin/というエラーメッセージが表示されます。推奨される回避策は、クラスターを最新のマイナーバージョンに更新することです。この回避策が機能しない場合は、こちらの Red Hat ナレッジベースの記事 (NETOBSERV-1493) で説明されている回避策を適用する必要があります。 -
Network Observability Operator の 1.3.0 リリース以降、Operator をインストールすると、警告カーネル taint が表示されます。このエラーの理由は、Network Observability eBPF エージェントに、HashMap テーブル全体を事前割り当てするメモリー制約があることです。Operator eBPF エージェントは
BPF_F_NO_PREALLOCフラグを設定し、HashMap がメモリーを大幅に使用している際に事前割り当てが無効化されるようにします。
3.1.37. Network Observability Operator 1.4.2 のアドバイザリー
Network Observability Operator 1.4.2 では、次のアドバイザリーを利用できます。
3.1.38. Network Observability Operator1.4.2 の CVE
Network Observability Operator 1.4.2 リリースでは、次の CVE を確認できます。
3.1.39. Network Observability Operator 1.4.1 のアドバイザリー
Network Observability Operator 1.4.1 の次のアドバイザリーを確認できます。
3.1.40. Network Observability Operator リリース 1.4.1 の CVE
Network Observability Operator 1.4.1 リリースでは、次の CVE を確認できます。
3.1.41. Network Observability Operator リリースノート 1.4.1 の修正された問題
Network Observability Operator 1.4.1 リリースで修正された次の問題を確認できます。
- 1.4 には、ネットワークフローデータを Kafka に送信するときに既知の問題がありました。Kafka メッセージキーが無視されたため、接続の追跡でエラーが発生していました。現在、キーはパーティショニングに使用されるため、同じ接続からの各フローが同じプロセッサーに送信されます。(NETOBSERV-926)
-
1.4 で、同じノード上で実行されている Pod 間のフローを考慮するために、
Inner方向のフローが導入されました。Inner方向のフローは、フローから派生して生成される Prometheus メトリクスでは考慮されなかったため、バイトレートとパケットレートが過小評価されていました。現在は派生メトリクスにInner方向のフローが含まれ、正しいバイトレートとパケットレートが提供されるようになりました。(NETOBSERV-1344)
3.1.42. ネットワーク可観測性リリースノート 1.4.0 のアドバイザリー
Network Observability Operator 1.4.0 リリースの次のアドバイザリーを確認できます。
3.1.43. ネットワーク可観測性リリースノート 1.4.0 の新機能と機能拡張
Network Observability Operator 1.4.0 リリースでは、次の新機能と機能拡張を確認できます。
3.1.43.1. 主な機能拡張
Network Observability Operator の 1.4 リリースでは、OpenShift Container Platform Web コンソールプラグインと Operator 設定が改良され、新機能が追加されています。
3.1.43.2. Web コンソールの機能拡張:
- Query Options に、重複したフローを表示するかどうかを選択するための Duplicate flows チェックボックスが追加されました。
-
送信元トラフィックおよび宛先トラフィックを、
One-way、
Back-and-forth、Swap のフィルターでフィルタリングできるようになりました。
Observe
Dashboards NetObserv、および NetObserv / Health の Network Observability メトリクスダッシュボードは次のように変更されます。 - NetObserv ダッシュボードには、ノード、namespace、およびワークロードごとに、上位のバイト、送信パケット、受信パケットが表示されます。フローグラフはこのダッシュボードから削除されました。
- NetObserv/Health ダッシュボードには、フローのオーバーヘッド以外にも、ノード、namespace、ワークロードごとの最大フローレートが表示されます。
- インフラストラクチャーとアプリケーションのメトリクスは、namespace とワークロードの分割ビューで表示されます。
3.1.43.3. 設定の機能拡張
- 証明書設定など、設定された ConfigMap または Secret 参照に対して異なる namespace を指定できるオプションが追加されました。
-
spec.processor.clusterNameパラメーターが追加されたため、クラスターの名前がフローデータに表示されるようになりました。これは、マルチクラスターコンテキストで役立ちます。OpenShift Container Platform を使用する場合は、自動的に決定されるように空のままにします。
3.1.43.4. Loki を使用しない Network Observability
Network Observability Operator は、Loki なしでも機能し、使用できるようになりました。Loki がインストールされていない場合は、フローを KAFKA または IPFIX 形式にエクスポートし、Network Observability メトリクスダッシュボードに入力することのみ可能です。
3.1.43.5. DNS 追跡
1.4 では、Network Observability Operator は eBPF トレースポイントフックを使用して DNS 追跡を有効にします。Web コンソールの Network Traffic ページと Overview ページで、ネットワークの監視、セキュリティー分析の実施、DNS 問題のトラブルシューティングを行なえます。
3.1.43.6. SR-IOV のサポート
Single Root I/O Virtualization (SR-IOV) デバイスを使用して、クラスターからトラフィックを収集できるようになりました。
3.1.43.7. IPFIX エクスポーターのサポート
eBPF エンリッチ化ネットワークフローを IPFIX コレクターにエクスポートできるようになりました。
3.1.43.8. パケットドロップ
Network Observability Operator の 1.4 リリースでは、eBPF トレースポイントフックを使用してパケットドロップの追跡を有効にできます。パケットドロップの原因を検出して分析し、ネットワークパフォーマンスを最適化するための決定を行えるようになりました。OpenShift Container Platform 4.14 以降では、ホストのドロップと OVS のドロップの両方が検出されます。OpenShift Container Platform 4.13 では、ホストのドロップのみが検出されます。
3.1.43.9. s390x アーキテクチャーのサポート
Network Observability Operator が、s390x アーキテクチャー上で実行できるようになりました。以前は、amd64、ppc64le、または arm64 で実行されていました。
3.1.44. ネットワーク可観測性リリースノート 1.4.0 で削除された機能
Network Observability Operator 1.4.0 リリースでは、次の削除された機能を確認できます。
3.1.44.1. チャネルの削除
最新の Operator 更新を受信するには、チャネルを v1.0.x から stable に切り替える必要があります。v1.0.x チャネルは削除されました。
3.1.45. ネットワーク可観測性リリースノート 1.4.0 の修正された問題
Network Observability Operator 1.4.0 リリースで修正された次の問題を確認できます。
-
これまで、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 の詳細の 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)
3.1.46. ネットワーク可観測性リリースノート 1.4.0 の既知の問題
Network Observability Operator 1.4.0 リリースでは、次の既知の問題を確認できます。
-
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 -
Network Observability Operator の 1.3.0 リリース以降、Operator をインストールすると、警告カーネル taint が表示されます。このエラーの理由は、Network Observability eBPF エージェントに、HashMap テーブル全体を事前割り当てするメモリー制約があることです。Operator eBPF エージェントは
BPF_F_NO_PREALLOCフラグを設定し、HashMap がメモリーを大幅に使用している際に事前割り当てが無効化されるようにします。
3.1.47. Network Observability Operator 1.3.0 のアドバイザリー
Network Observability Operator 1.3.0 リリースでは、次のアドバイザリーを確認できます。
3.1.48. Network Observability Operator 1.3.0 の新機能と機能拡張
Network Observability Operator 1.3.0 リリースでは、次の新機能と機能拡張を確認できます。
3.1.48.1. Network Observability におけるマルチテナンシー
- システム管理者は、Loki に保存されているフローへの個々のユーザーアクセスまたはグループアクセスを許可および制限できます。詳細は、「Network Observability におけるマルチテナンシー」を参照してください。
3.1.48.2. フローベースのメトリクスダッシュボード
- このリリースでは、OpenShift Container Platform クラスター内のネットワークフローの概要を表示する新しいダッシュボードが追加されています。詳細は、「Network Observability メトリクスのダッシュボード」を参照してください。
3.1.48.3. must-gather ツールを使用したトラブルシューティング
- Network Observability Operator に関する情報を、トラブルシューティングで使用する must-gather データに追加できるようになりました。詳細は、「Network Observability の must-gather」を参照してください。
3.1.48.4. 複数のアーキテクチャーに対するサポートを開始
-
Network Observability Operator は、
amd64、ppc64le、またはarm64アーキテクチャー上で実行できるようになりました。以前は、amd64上でのみ動作しました。
3.1.49. Network Observability Operator 1.3.0 の非推奨機能
Network Observability Operator 1.3.0 リリースでは、次の非推奨機能を確認できます。
3.1.49.1. チャネルの非推奨化
今後の Operator 更新を受信するには、チャネルを v1.0.x から stable に切り替える必要があります。v1.0.x チャネルは非推奨となり、次のリリースで削除される予定です。
3.1.49.2. 非推奨の設定パラメーターの設定
Network Observability Operator 1.3 のリリースでは、spec.Loki.authToken HOST 設定が非推奨になりました。Loki Operator を使用する場合、FORWARD 設定のみを使用する必要があります。
3.1.50. Network Observability Operator 1.3.0 で修正された問題
Network Observability Operator 1.3.0 リリースで修正された次の問題を確認できます。
-
以前は、Operator が CLI からインストールされた場合、Cluster Monitoring Operator がメトリクスを読み取るために必要な
RoleとRoleBindingが期待どおりにインストールされませんでした。この問題は、Operator が Web コンソールからインストールされた場合には発生しませんでした。現在は、どちらの方法で Operator をインストールしても、必要なRoleとRoleBindingがインストールされます。(NETOBSERV-1003) -
バージョン 1.2 以降、Network Observability Operator は、フローの収集で問題が発生した場合にアラートを生成できます。以前は、バグのため、アラートを無効にするための関連設定である
spec.processor.metrics.disableAlertsが期待どおりに動作せず、効果がない場合がありました。現在、この設定は修正され、アラートを無効にできるようになりました。(NETOBSERV-976) -
以前は、Network Observability の
spec.loki.authTokenがDISABLEDに設定されている場合、kubeadminクラスター管理者のみがネットワークフローを表示できました。他のタイプのクラスター管理者は認可エラーを受け取りました。これで、クラスター管理者は誰でもネットワークフローを表示できるようになりました。(NETOBSERV-972) -
以前は、バグが原因でユーザーは
spec.consolePlugin.portNaming.enableをfalseに設定できませんでした。現在は、これをfalseに設定すると、ポートからサービスへの名前変換を無効にできます。(NETOBSERV-971) - 以前は、設定が間違っていたため、コンソールプラグインが公開するメトリクスは、Cluster Monitoring Operator (Prometheus) によって収集されませんでした。現在は設定が修正され、コンソールプラグインメトリクスが正しく収集され、OpenShift Container Platform Web コンソールからアクセスできるようになりました。(NETOBSERV-765)
-
以前は、
FlowCollectorでprocessor.metrics.tlsがAUTOに設定されている場合、flowlogs-pipeline servicemonitorは適切な TLS スキームを許可せず、メトリクスは Web コンソールに表示されませんでした。この問題は AUTO モードで修正されました。(NETOBSERV-1070) -
以前は、Kafka や Loki に使用されるような証明書設定では、namespace フィールドを指定できず、Network Observability がデプロイされているのと同じ namespace に証明書が存在する必要がありました。さらに、TLS/mTLS で Kafka を使用する場合、ユーザーは
eBPFagent Pod がデプロイされている特権付き namespace に証明書を手動でコピーし、証明書のローテーションを行う場合などに手動で証明書の更新を管理する必要がありました。現在は、FlowCollectorリソースに証明書の namespace フィールドを追加することで、Network Observability のセットアップが簡素化されています。その結果、ユーザーは Network Observability namespace に証明書を手動でコピーすることなく、Loki または Kafka を別の namespace にインストールできるようになりました。元の証明書は監視されているため、必要に応じてコピーが自動的に更新されます。(NETOBSERV-773) - 以前は、SCTP、ICMPv4、および ICMPv6 プロトコルは Network Observability エージェントのカバレッジに含まれていなかったため、ネットワークフローのカバレッジもあまり包括的ではありませんでした。これらのプロトコルを使用することで、フローカバレッジが向上することが確認されています。(NETOBSERV-934)
3.1.51. Network Observability Operator 1.3.0 の既知の問題
Network Observability Operator 1.3.0 リリースの問題をトラブルシューティングするために、次の問題とその回避策 (存在する場合) を確認できます。
-
FlowCollectorでprocessor.metrics.tlsがPROVIDEDに設定されている場合、flowlogs-pipelineservicemonitorは TLS スキームに適用されません。(NETOBSERV-1087) -
Network Observability Operator 1.2.0 リリース以降では、Loki Operator 5.6 を使用すると、Loki 証明書の変更が定期的に
flowlogs-pipelinePod に影響を及ぼすため、フローが Loki に書き込まれず、ドロップされます。この問題はしばらくすると自動的に修正されますが、Loki 証明書の移行中に一時的なフローデータの損失が発生します。この問題は、120 以上のノードを内包する大規模環境でのみ発生します。(NETOBSERV-980) -
Operator のインストール時に、警告のカーネル taint が表示される場合があります。このエラーの理由は、Network Observability eBPF エージェントに、HashMap テーブル全体を事前割り当てするメモリー制約があることです。Operator eBPF エージェントは
BPF_F_NO_PREALLOCフラグを設定し、HashMap がメモリーを大幅に使用している際に事前割り当てが無効化されるようにします。
3.1.52. ネットワーク可観測性リリースノート 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.53. Network Observability Operator 1.2.0 のアドバイザリー
Network Observability Operator 1.2.0 リリースの次のアドバイザリーを参照できます。
3.1.54. Network Observability Operator 1.2.0 の新機能と機能拡張
Network Observability Operator 1.2.0 リリースの次の新機能と機能拡張を確認できます。
3.1.54.1. Traffic Flows ビューのヒストグラム
経時的なフローのヒストグラムを表示することを選択できるようになりました。ヒストグラムを使用すると、Loki クエリー制限に達することなくフロー履歴を可視化できます。詳細は、「ヒストグラムの使用」を参照してください。
3.1.54.2. 会話の追跡
ログタイプ でフローをクエリーできるようになりました。これにより、同じ会話に含まれるネットワークフローをグループ化できるようになりました。詳細は、「会話の使用」を参照してください。
3.1.54.3. Network Observability のヘルスアラート
Network Observability Operator は、書き込み段階でのエラーが原因で flowlogs-pipeline がフローをドロップする場合、または Loki 取り込みレート制限に達した場合、自動アラートを作成するようになりました。詳細は、「健全性ダッシュボード」を参照してください。
3.1.55. Network Observability Operator1.2.0 のバグ修正
Network Observability Operator 1.2.0 リリースで修正された次の問題を確認できます。
-
これまでは、FlowCollector 仕様の
namespaceの値を変更すると、以前の namespace で実行されているeBPFagent 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.56. Network Observability Operator1.2.0 の既知の問題
Network Observability Operator 1.2.0 リリースの問題をトラブルシューティングするために、次の問題とその回避策 (存在する場合) を確認してください。
-
Loki Operator 5.6 を使用する Network Observability Operator の 1.2.0 リリースでは、Loki 証明書の移行が定期的に
flowlogs-pipelinePod に影響を及ぼし、その結果、Loki に書き込まれるフローではなくフローがドロップされます。この問題はしばらくすると自動的に修正されますが、依然として Loki 証明書の移行中に一時的なフローデータの損失が発生します。(NETOBSERV-980)
3.1.57. Network Observability Operator 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.58. Network Observability Operator1.1.0 の機能拡張
Network Observability Operator 1.1.0 の次のアドバイザリーを参照できます。
Network Observability Operator は安定版になり、リリースチャネルが v1.1.0 にアップグレードされました。
3.1.59. Network Observability Operator 1.10 で修正された問題
Network Observability Operator 1.1.0 リリースで修正された次の問題を確認できます。
-
以前は、Loki の
authToken設定がFORWARDモードに設定されていない限り、認証が強制されず、権限のないユーザーがフローを取得できました。現在は、Loki のauthTokenモードに関係なく、クラスター管理者のみがフローを取得できます。(BZ#2169468)
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}