Red Hat SummitNetwork Observability
OpenShift Container Platform での Network Observability Operator の設定と使用
概要
第1章 Network Observability Operator リリースノート
Network Observability Operator の新機能、セキュリティーアドバイザリー、修正された問題、既知の問題に関する情報を確認し、OpenShift Container Platform 用 Operator の最新バージョンにおける変更点やパフォーマンスの向上について最新情報を提供します。
Network Observability Operator を使用すると、管理者は OpenShift Container Platform クラスターのネットワークトラフィックフローを観察および分析できます。
これらのリリースノートは、OpenShift Container Platform での Network Observability Operator の開発を追跡します。
1.1. Network Observability Operator 1.11.2 のアドバイザリー
Network Observability Operator 1.11.2 リリースのアドバイザリーを確認できます。
1.2. Network Observability Operator 1.11.1 のアドバイザリー
Network Observability Operator 1.11.1 リリースのアドバイザリーを確認できます。
1.3. Network Observability Operator 1.11.1 で修正された問題
Network Observability Operator 1.11.1 リリースには、eBPF エージェントのパフォーマンスと OpenShift Container Platform の Web コンソールにおけるユーザーエクスペリエンスを向上させるための修正がいくつか含まれています。
- eBPF エージェントのメモリー使用量の最適化
今回のアップデート以前は、eBPF エージェントのリグレッションにより、無効化されている機能のためにカーネルメモリーが意図せず予約されてしまうという問題が発生していました。その結果、エージェントのメモリー使用量が予想以上に増加していました。
今回のアップデートにより、eBPF エージェントは、機能が無効化されている場合に、予約済みのカーネルメモリーを最小限に抑えるようになりました。その結果、エージェントのメモリー使用量が削減され、リソース割り当ての効率が向上しました。
- Prometheus のみのモードにおける DNS グラフの可用性向上
今回のアップデート以前は、Loki が無効で DNS トラッキングが有効な場合、OpenShift Container Platform コンソールプラグインが DNS グラフを表示できませんでした。その代わりに、有効な Prometheus データを持つグラフであっても、Prometheus メトリクスを使用してリクエストを実行できないというエラーが表示されていました。
今回のアップデートにより、このエラーは設定されたメトリクスがない特定のグラフに対してのみ表示されるようになりました。その結果、有効な DNS グラフはすべて Web コンソールに正しく表示されるようになりました。
- Topology ビューにおけるエラー処理の改善
今回のアップデート以前は、Loki がインストールされていない環境では、Topology ビュー内で特定のクエリーを実行すると、Prometheus メトリクスが欠落しているためにエラーが発生することがありました。このエラーは、ブラウザーのキャッシュをクリアするまで解消されない場合がありました。
今回のアップデートにより、メトリクスの欠落が原因で発生する無効なスコープがコンソールに表示されなくなりました。さらに、コンソールのエラー処理が更新され、より実用的な情報が提供されるようになりました。そのため、上記の状況でキャッシュを手動でクリアする必要がなくなりました。
1.4. Network Observability Operator 1.11 のアドバイザリー
Network Observability Operator 1.11 リリースのアドバイザリーを確認できます。
1.5. Network Observability Operator 1.11 の新機能と機能拡張
Network Observability Operator 1.11 リリースの新機能と機能拡張を紹介します。これには、FlowCollectorSlice リソースを使用した階層型ガバナンス、新しい Service デプロイメントモデル、および健全性ルールの一般提供などが含まれます。
- FlowCollectorSlice リソースを使用したテナントごとの階層型ガバナンス
今回のリリースにより、階層型ガバナンスをサポートする
FlowCollectorSliceAPI が導入されました。これにより、プロジェクト管理者がそれぞれの namespace のサンプリングとサブネットのラベル付けを個別に管理できるようになります。この機能は、クラスター全体の設定変更を行わずに個々のチームがセルフサービスで可視性を確保する必要がある大規模環境において、グローバルな処理のオーバーヘッドを削減し、テナントの自律性を提供するために実装されました。その結果、組織は一元的なクラスター制御を維持しながら、トラフィックを選択的に収集し、データ拡充タスクをプロジェクトレベルに委譲できるようになります。
FlowCollectorリソースの新しい Service デプロイメントモデル今回のリリースにより、
FlowCollectorカスタムリソースに新しいServiceデプロイメントモデルが導入されました。このモデルは、DirectモデルとKafkaモデルの中間となる選択肢を提供します。Serviceモデルでは、eBPF エージェントはdaemonセットとしてデプロイされ、flowlogs-pipelineコンポーネントはスケーラブルなサービスとしてデプロイされます。このモデルは、コンポーネントインスタンス間でのキャッシュの重複を削減することで、大規模クラスターのパフォーマンスを向上させます。
- 健全性ルールの一般提供
以前のバージョンでテクノロジープレビュー機能として導入された健全性アラート機能が、Network Observability Operator 1.11 リリースで健全性ルールとして完全にサポートされるようになりました。
重要Network Observability の健全性ルールは、OpenShift Container Platform 4.16 以降で利用可能です。
この eBPF ベースのシステムは、ネットワークメトリクスとインフラストラクチャーメタデータを関連付けることで、トラフィックの急増や遅延の傾向など、クラスターの健全性に関するプロアクティブな通知と自動化された分析情報を提供します。これにより、OpenShift Container Platform の Web コンソールにある Network Health ダッシュボードを使用して、カテゴリー分けされたアラートを管理したり、しきい値をカスタマイズしたり、レコーディングルールを作成して可視化のパフォーマンスを向上させることができます。
- ネットワークトラフィックの可視化とフィルタリングの強化
今回のリリースにより、OpenShift Container Platform の Web コンソールに、強化された可視化ツールとフィルタリングツールが導入されました。
- インラインフィルター編集: フィルター入力フィールド内でフィルターチップを直接編集できるようになりました。この機能拡張により、これまで切り捨てられて表示されていた長いフィルター値をより効率的に変更できるようになり、値を手動でコピーして貼り付ける必要がなくなります。今回のアップデートでは、保存済みフィルター機能と一貫性のあるインライン編集方式を採用しています。
- 外部トラフィックのクイックフィルター: 新しいクイックフィルターを使用すると、外部からの Ingress および Egress トラフィックをアクティブに監視できます。この機能拡張により、ネットワーク管理が効率化され、外部ネットワーク通信に関連する問題を迅速に特定して対処できるようになります。
- 直感的なリソースアイコン: OpenShift Container Platform コンソールで、Kubernetes の kind、グループ、フィルターにそれぞれ専用のアイコンが使用されるようになりました。これらのアイコンにより、より直感的で視覚的に一貫性のある操作が実現し、ネットワークトポロジーのナビゲーションが容易になり、適用されたフィルターを一目で識別しやすくなります。
- DNS 解決の分析
今回のリリースには、ネットワークフローレコードにドメイン名を付加するための eBPF ベースの DNS トラッキング機能が含まれています。
この機能は、管理者がネットワークルーティングの障害と、
NXDOMAINエラーなどのサービス検出の問題を即座に区別できるようにすることで、平均検知時間 (MTTI) を短縮するために実装されました。- Gateway API との統合
今回のリリースにより、
GatewayClassリソース作成時の Network Observability Operator と Gateway API の自動統合が導入されました。この機能は、FlowCollectorリソースの手動設定を必要とすることなく、クラスターの Ingress および Egress トラフィックに対する高レベルのトラフィック属性付与を提供します。重要Gateway API との統合は、OpenShift Container Platform 4.19 以降で利用可能です。
OpenShift Container Platform Web コンソールの Observe → Network Traffic ビューで、ネットワークフローと Gateway API リソースの自動マッピングを確認できます。Owner 列にゲートウェイ名が表示され、関連する Gateway リソースページへの直接リンクが提供されます。
- Overview ビューと Topology ビューのデータ回復力の向上
今回のリリースにより、一部のバックグラウンドクエリーが失敗した場合でも、有効なデータが引き続き Overview および Topology ビューに表示されるようになりました。この機能拡張により、部分的なサービス中断が発生した際に、Topology ビューのスコープおよびグループのドロップダウンメニューにアクセスできるようになります。
さらに、Overview ページにはトラブルシューティングに役立つアクティブなエラーメッセージが表示されるようになりました。これにより、監視ワークフローを中断することなく、システムの健全性をより明確に把握できます。
- 不明なネットワークフローの分類の改善
今回のリリースにより、不明なソースからのネットワークフローが、外部、不明なサービス、不明なノード、不明な Pod という 4 つの明確なグループに分類されるようになりました。
この機能拡張では、サブネットラベルを使用して不明な IP サブネットを区別することで、より明確なネットワークトポロジーを提供します。この可視性の向上により、潜在的なセキュリティー脅威を特定しやすくなり、クラスター内の不明な要素をより的確に分析することが可能になります。
- Network Observability の新規インストールのパフォーマンス向上
新規インストールにおける Network Observability Operator のデフォルトのパフォーマンスが向上しました。より高いフロー量に対応できるように、
cacheActiveTimeoutのデフォルト値が 5 秒から 15 秒に増加し、cacheMaxFlowsの値が 100,000 から 120,000 に増加しました。重要これらの新しいデフォルト値は新規インストールにのみ適用されます。既存のインストール環境では現在の設定が維持されます。
これらの変更により、CPU 負荷が最大 40% 削減されます。
- LokiStack のステータス監視とレポートの改善
今回のリリースにより、Network Observability Operator が
LokiStackリソースの状態を監視し、エラーや設定上の問題を報告するようになりました。Network Observability Operator は、保留中または障害が発生した Pod や特定の警告状態など、LokiStackの状態を検証します。この機能拡張により、より実用的な情報が
FlowCollectorのステータスに表示されるようになります。これにより、ネットワークオブザーバビリティーのLokiStackコンポーネントのトラブルシューティングを効率化できます。- フィルターメニューの Loki インデックス付きフィールドの視覚的インジケーター
今回のリリースにより、一部のバックグラウンドクエリーが失敗した場合でも、有効なデータが引き続き Overview および Topology ビューに表示されるようになりました。この機能拡張により、部分的なサービス中断が発生した際に、Topology ビューのスコープおよびグループのドロップダウンメニューにアクセスできるようになります。
この機能拡張により、どのフィールドにインデックスが付けられているかが示されるため、クエリーのパフォーマンスが向上します。データのフィルタリング時にインデックス付きフィールドを使用すると、コンソール内でネットワークフローを閲覧および分析するのに必要な時間が短縮されます。
1.6. Network Observability Operator 1.11 の既知の問題
Network Observability Operator 1.11 リリースには以下の既知の問題が影響します。
- サンプリングレートの上昇時に
lowVolumeThresholdが原因で健全性ルールがトリガーされない サンプリングレートの上昇によりデータ量が
lowVolumeThresholdフィルターを下回った場合、ネットワークオブザーバビリティーのアラートがトリガーされない可能性があります。その結果、評価または表示されるアラートの数が減少します。この問題を回避するには、アラートの評価が一貫して行われるように、
lowVolumeThresholdの値をサンプリングレートに合わせて調整します。- Loki が無効な場合、DNS メトリクスを利用できない
"Loki なし" のインストール環境で
DNSTracking機能が有効になっている場合、DNS グラフに必要なメトリクスを利用できません。そのため、ダッシュボードで DNS の遅延やレスポンスコードを表示することができません。この問題を回避するには、
DNSTrackingオプションを無効にするか、FlowCollectorリソースでspec.loki.enableを true に設定して Loki を有効にする必要があります。
1.7. Network Observability Operator 1.11 で修正された問題
Network Observability Operator 1.11 リリースには、修正された問題がいくつか含まれています。これらの修正により、パフォーマンスとユーザーエクスペリエンスが向上します。
- グラフに日付がない
今回のアップデート以前は、依存関係の互換性を損なう変更が原因で、グラフのツールチップの日付が意図したとおりに表示されていませんでした。その結果、OpenShift Container Platform Web コンソールプラグインの Overview タブのグラフで日付情報が欠落するという問題がユーザーに発生し、データのコンテキストに影響が出ていました。
今回のリリースにより、チャートのツールチップに表示される日付が復元されました。
- Direct モードの警告メッセージがスケールアップ後に更新されない
今回のアップデート以前は、スケーリング後にクラスター情報が更新されていませんでした。そのため、大規模クラスターで変更内容が反映されず、警告メッセージが表示され続けるという問題が発生していました。
今回のリリースにより、クラスター情報が変更された際に自動的に更新されるようになりました。その結果、
Directモードの大規模クラスター向け警告メッセージがクラスターサイズの変更に合わせて更新されるようになり、ユーザーにとっての視認性が向上しました。- OVN の IP がエンリッチされていない
このアップデート以前は、OVN-Kubernetes によって宣言された一部の IP がエンリッチされていませんでした。そのため、
100.64.0.xなどのエンリッチされていない IP アドレスがMachinesネットワークに表示されていませんでした。その結果、エンリッチされていない IP アドレスにより、ユーザーに対して不正確なネットワークの可視性が提供されていました。今回のリリースにより、OVN-Kubernetes で不足していた IP がエンリッチされるようになりました。その結果、OVN-Kubernetes によって宣言された IP が正しくエンリッチされ、
Machinesネットワークに表示されるようになり、Machinesネットワークにおけるネットワークトラフィックソースの可視性が向上しました。- Operator API 検出の信頼性向上
今回のアップデート以前は、Network Observability Operator の起動時に発生する競合状態により、API 検出が通知なく失敗することがありました。その結果、Operator が OpenShift Container Platform クラスターを認識できず、必須の
ClusterRoleBindingリソースが欠落し、コンポーネントが正しく機能しなくなる可能性がありました。今回のリリースにより、Network Observability Operator が継続的に API の可用性を確認し、検出に失敗した場合はリコンシリエーションがブロックされるようになりました。その結果、Operator が環境を正しく識別し、必要なすべてのロールが作成されていることを確認するようになりました。
- IPFIX のエクスポートに不足していた変換フィールドの追加
今回のアップデート以前は、IPFIX エクスポート処理中に、一部のネットワークフローフィールドの変換が欠落していました。その結果、エクスポートされた IPFIX データが不完全であるか、データを外部のデータコレクターで解釈するのが困難でした。
今回のリリースにより、
flowlogs-pipelineIPFIX エクスポーターに不足していた変換フィールド (xlat) が追加されました。IPFIX のエクスポートで、一貫性のあるネットワークオブザーバビリティーを実現するために、完全に揃った変換フィールドが提供されるようになりました。- FlowMetric フォーム作成リンクとデフォルト設定の修正
今回のアップデート以前は、
FlowMetricのカスタムリソースを作成するためのリンクをクリックすると、意図されたフォームビューではなく、誤って YAML エディターに誘導されていました。さらに、エディターに誤ったデフォルト値があらかじめ入力されていました。今回のリリースにより、期待されるデフォルト設定が入力されている
FlowMetricリソース作成フォームに正しく誘導されるようになりました。その結果、ユーザーがユーザーインターフェイスを通じてFlowMetricリソースを簡単に作成できるようになりました。- Topology ビューの仮想マシンリソースタイプのアイコン
このアップデート以前は、Topology ビューで、仮想マシン (VM) の所有者タイプに誤って汎用的な疑問符 (?) アイコンが表示されていました。
今回のリリースにより、ユーザーインターフェイスに仮想マシンリソース専用のアイコンが追加されました。その結果、ユーザーがネットワークトポロジー内の仮想マシントラフィックをより容易に識別および区別できるようになりました。
- DNS 最適化、DNS アラートの更新
このアップデート以前は、ネットワークオブザーバビリティーで曖昧な URL が使用されていたため、多数の DNS "NXDOMAIN" エラーが返されていました。
今回のリリースにより、この URL の曖昧さが解消され、DNS がより的確に使用されるようになりました。
第2章 Network Observability Operator リリースノートのアーカイブ
2.1. Network Observability Operator リリースノートのアーカイブ
これらのリリースノートは、OpenShift Container Platform の Network Observability Operator の開発履歴を記録したものです。これらはあくまで参考用に提供されています。
Network Observability Operator を使用すると、管理者は OpenShift Container Platform クラスターのネットワークトラフィックフローを観察および分析できます。
2.1.1. Network Observability Operator 1.10.1 のアドバイザリー
Network Observability Operator 1.10.1 リリースのアドバイザリーを確認できます。
2.1.2. Network Observability Operator 1.10.1 の CVE
Network Observability Operator 1.10.1 リリースの CVE を確認できます。
2.1.3. Network Observability Operator 1.10.1 で修正された問題
Network Observability Operator 1.10.1 リリースには、修正された問題がいくつか含まれています。これらの修正により、パフォーマンスとユーザーエクスペリエンスが向上します。
- 15 ノードを超えるクラスターでの Direct モードに対して警告が生成されます
この更新前は、大規模なクラスターでは
Directデプロイメントモデルを使用しないという推奨事項は、ドキュメントにのみ記載されていました。このリリースでは、Network Observability Operator は、15 ノードを超えるクラスターで Direct デプロイメントモードが使用されると警告を生成するようになりました。
- OpenShiftSDN でネットワークポリシーのデプロイメントが無効化されました
この更新前は、OpenShift SDN がクラスターネットワークプラグインだった場合、
FlowCollectorネットワークポリシーを有効にすると、ネットワークオブザーバビリティー Pod 間の通信が切断されていました。この問題は、サポート対象のデフォルトネットワークプラグインである OVN-Kubernetes では発生しません。このリリースでは、Network Observability Operator は OpenShift SDN が検出されてもネットワークポリシーをデプロイしようとせず、代わりに警告が表示されます。さらに、ネットワークポリシーを有効にするためのデフォルト値が変更され、OVN-Kubernetes がクラスターネットワークプラグインとして検出された場合にのみ、デフォルトで有効になるようになりました。
- サブネットラベル文字の検証が追加されました
この更新前は、サブネットラベルの "name" 設定で許可される文字は制限されておらず、ユーザーはスペースや特殊文字を含むテキストを入力できました。そのため、ユーザーがフィルターを適用しようとすると Web コンソールプラグインでエラーが生成され、サブネットラベルのフィルターアイコンをクリックしても頻繁に失敗していました。
このリリースでは、設定されたサブネットラベル名は、
FlowCollectorカスタムリソースで設定されると即座に検証されます。この検証により、名前に英数字、:、_、-のみ含まれることが確認されます。その結果、Web コンソールプラグインからのサブネットラベルのフィルタリングが期待どおりに機能するようになりました。- Network Observability CLI は実行ごとに一意の一時ディレクトリーを使用します
この更新前は、Network Observability CLI は現在の作業ディレクトリーで単一の一時 (
tmp) ディレクトリーを作成または再利用していました。これにより、個別の実行間で競合やデータ破損が発生する可能性がありました。このリリースでは、Network Observability CLI は実行ごとに一意の一時ディレクトリーを作成するようになり、潜在的な競合が防止され、ファイル管理の健全性が向上しました。
2.1.4. Network Observability Operator 1.10 アドバイザリー
Network Observability Operator 1.10 リリースのアドバイザリーを確認できます。
2.1.5. Network Observability Operator 1.10 の新機能と機能拡張
Network Observability Operator 1.10 リリースでは、セキュリティーが強化され、パフォーマンスが向上し、ネットワークフローの管理を改善するための新しい CLI UI ツールが導入されています。
2.1.5.1. ネットワークポリシーの更新
Network Observability Operator は、Pod トラフィックを制御するために、Ingress と Egress の両方のネットワークポリシーの設定をサポートするようになりました。この機能拡張によりセキュリティーが向上します。
デフォルトで、spec.NetworkPolicy.enable 仕様が true に設定されるようになりました。そのため、Loki または Kafka を使用する場合は、Loki Operator と Kafka インスタンスを専用の namespace にデプロイすることを推奨します。これにより、ネットワークポリシーを正しく設定し、すべてのコンポーネント間の通信を許可することが可能になります。
2.1.5.2. Network Observability Operator CLI UI の更新
このリリースでは、Network Observability Operator CLI (oc netobserv) ユーザーインターフェイス (UI) に次の新機能と更新が追加されました。
テーブルビューの機能拡張
- カスタマイズ可能な列: Manage Columns をクリックして、表示する列を選択し、ニーズに合わせてテーブルをカスタマイズできます。
- スマートフィルタリング: ライブフィルターに自動提案機能が組み込まれ、適切なキーと値を選択しやすくなりました。
-
パケットプレビュー: パケットをキャプチャーするときに、行をクリックして
pcapの内容を直接調べることができます。
ターミナルベースの折れ線グラフの機能拡張
- メトリクスの可視化: リアルタイムグラフが CLI で直接レンダリングされます。
- パネルの選択: 事前定義済みのビューから選択するか、Manage Panels ポップアップメニューを使用してビューをカスタマイズし、特定のメトリクスのグラフを選択的に表示できます。
2.1.5.3. ネットワークオブザーバビリティーコンソールの強化
Network Observability コンソールプラグインに、FlowCollector カスタムリソース (CR) を設定するための新しいビューが追加されています。このビューから、次のタスクを完了できます。
-
FlowCollectorCR を設定します。 - リソースフットプリントを計算します。
- 設定の警告やメトリクスのカーディナリティーが高いなどの問題に対する可視性を高めます。
2.1.5.4. パフォーマンスの向上
Network Observability Operator 1.10 では、特に大規模なクラスターで顕著に表れる Operator のパフォーマンスとメモリーフットプリントが改善されました。
2.1.6. Network Observability Operator 1.10 のテクノロジープレビュー機能
Network Observability Operator 1.10 リリースのテクノロジープレビュー機能を確認できます。
2.1.6.1. Network Observability Operator カスタムアラート (テクノロジープレビュー)
このリリースでは、新しいアラート機能とカスタムアラート設定が導入されています。これらの機能はテクノロジープレビュー機能であり、明示的に有効にする必要があります。
新しいアラートを表示するには、OpenShift Container Platform Web コンソールで、Observe → Alerting → Alerting rules をクリックします。
2.1.6.2. Network Observability Operator Network Health ダッシュボード (テクノロジープレビュー)
Network Observability Operator で、テクノロジープレビューのアラート機能を有効にすると、Observe をクリックして OpenShift Container Platform Web コンソールで新しい Network Health ダッシュボードを表示できます。
Network Health ダッシュボードは、トリガーされたアラートの概要を提供し、重大な問題、警告、および軽微な問題に分類します。また、保留中のアラートも表示します。
2.1.7. Network Observability Operator 1.10 で削除された機能
Network Observability Operator 1.10 リリースの使用に影響する可能性のある削除された機能をご確認ください。
2.1.7.1. FlowCollector API バージョン v1beta1 の削除
FlowCollector カスタムリソース (CR) API バージョン v1beta1 が削除され、サポートされなくなりました。v1beta2 バージョンを使用してください。
2.1.8. Network Observability Operator 1.10 の既知の問題
Network Observability Operator 1.10 リリースの使用に影響する可能性のある、次の既知の問題と推奨される回避策 (存在する場合) をご確認ください。
2.1.8.1. OpenShift Container Platform 4.14 以前で 1.10 へのアップグレードが失敗する
OpenShift Container Platform 4.14 以前で Network Observability Operator 1.10 にアップグレードすると、ソフトウェアカタログの FlowCollector カスタムリソース定義 (CRD) 検証エラーが原因で失敗する可能性があります。
この問題を回避するには、次の操作を行う必要があります。
OpenShift Container Platform Web コンソールのソフトウェアカタログから、両方のバージョンの Network Observability Operator をアンインストールします。
-
FlowCollectorCRD は、フロー収集プロセスに中断が発生しないように、インストールしたままにしておきます。
-
次のコマンドを実行して、
FlowCollectorCRD の現在の名前を確認します。$ oc get crd flowcollectors.flows.netobserv.io -o jsonpath='{.spec.versions[0].name}'想定される出力:
v1beta1次のコマンドを実行して、
FlowCollectorCRD の現在の提供ステータスを確認します。$ oc get crd flowcollectors.flows.netobserv.io -o jsonpath='{.spec.versions[0].served}'想定される出力:
true次のコマンドを実行して、
v1beta1バージョンのservedフラグをfalseに設定します。$ oc patch crd flowcollectors.flows.netobserv.io --type='json' -p "[{'op': 'replace', 'path': '/spec/versions/0/served', 'value': false}]"次のコマンドを実行して、
servedフラグがfalseに設定されていることを確認します。$ oc get crd flowcollectors.flows.netobserv.io -o jsonpath='{.spec.versions[0].served}'想定される出力:
false- Network Observability Operator 1.10 をインストールします。
2.1.8.2. eBPF エージェントと OpenShift Container Platform の旧バージョンとの互換性
Network Observability コマンドラインインターフェイス (CLI) のパケットキャプチャー機能で使用される eBPF エージェントは、OpenShift Container Platform バージョン 4.16 以前と互換性がありません。
この制限により、eBPF ベースの Packet Capture Agent (PCA) が古いクラスター上で正しく機能しなくなります。
この問題を回避するには、互換性のある古い eBPF エージェントコンテナーイメージを使用するように PCA を手動で設定する必要があります。詳細は、Red Hat ナレッジベースソリューション eBPF agent compatibility with older Openshift versions in Network Observability CLI 1.10+ を参照してください。
2.1.8.3. NetworkPolicy が有効な場合、OpenShiftSDN 環境で eBPF エージェントがフローを送信できない
OpenShiftSDN CNI プラグインを使用する OpenShift Container Platform 4.14 クラスターで Network Observability Operator 1.10 を実行すると、eBPF エージェントが flowlogs-pipeline コンポーネントにフローレコードを送信できません。これは、NetworkPolicy が有効な状態 (spec.networkPolicy.enable: true) で FlowCollector カスタムリソースが作成された場合に発生します。
その結果、フローデータが flowlogs-pipeline コンポーネントによって処理されず、Network Traffic ダッシュボードまたは設定されたストレージ (Loki) に表示されません。eBPF エージェント Pod のログには、コレクターへの接続を試みたときに i/o timeout エラーが表示されます。
time="2025-10-17T13:53:44Z" level=error msg="couldn't send flow records to collector" collector="10.0.68.187:2055" component=exporter/GRPCProto error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 10.0.68.187:2055: i/o timeout\""
この問題を回避するには、spec.networkPolicy.enable を false に設定して、Network Observability Operator 1.10 の FlowCollector リソースで NetworkPolicy を無効にします。
これにより、eBPF エージェントが、自動的にデプロイされたネットワークポリシーからの干渉を受けずに、flowlogs-pipeline コンポーネントと通信できるようになります。
2.1.9. Network Observability Operator 1.10 で修正された問題
Network Observability Operator 1.10 リリースには、修正された問題がいくつか含まれています。これらの修正により、パフォーマンスとユーザーエクスペリエンスが向上します。
2.1.9.1. MetricName および Remap フィールドの検証
この更新前は、ユーザーが無効なメトリクス名を使用して FlowMetric カスタムリソース (CR) を作成することができました。FlowMetric CR は正常に作成されましたが、その元となるメトリクスはユーザーに何のエラーフィードバックを提供せず、サイレントに失敗していました。
このリリースでは、FlowMetric、metricName、および remap フィールドが作成前に検証されるようになりました。そのため、ユーザーが無効な名前を入力した場合、すぐに通知されます。
2.1.9.2. html-to-image エクスポートのパフォーマンスの向上
この更新前は、基盤となるライブラリーのパフォーマンスの問題により、html-to-image エクスポート機能に時間がかかり、その結果ブラウザーがフリーズしていました。
このリリースでは、html-to-image ライブラリーのパフォーマンスが向上し、エクスポートの待機時間が短縮され、イメージ生成中にブラウザーがフリーズすることがなくなりました。
2.1.9.3. eBPF privileged モードの警告の改善
この更新前は、privileged モードを必要とする eBPF 機能をユーザーが選択しても、privileged モードが設定されていないこと、または有効にする必要があることがユーザーに明確に通知されずに、機能が失敗することがよくありました。
このリリースでは、設定に矛盾がある場合、検証フックによってすぐにユーザーに警告が表示されます。これにより、ユーザーの理解が向上し、誤った設定を防ぐことができます。
2.1.9.4. OpenTelemetry エクスポーターへのサブネットラベルの追加
この更新前は、OpenTelemetry メトリクスエクスポーターに、ネットワークフローラベル SrcSubnetLabel と DstSubnetLabel が欠落していたため、空のラベルが表示されていました。
このリリースでは、これらのラベルがエクスポーターによって正しく提供されるようになりました。また、明確さと OpenTelemetry 標準との整合性を向上させるために、source.subnet.label と destination.subnet.label に名前が変更されました。
2.1.9.5. Network Observability コンポーネントのデフォルト toleration の削減
この更新前は、すべてのネットワークオブザーバビリティーコンポーネントにデフォルトの toleration が設定されており、NoSchedule の taint が付与されているノードも含め、すべてのノードでコンポーネントをスケジュールすることが許可されていました。これにより、クラスターのアップグレードがブロックされることがありました。
このリリースでは、Direct モードで設定されている場合、eBPF エージェントと Flowlogs-Pipeline に対してのみ、デフォルトの toleration が維持されるようになりました。Kafka モードで設定されている場合、OpenShift Container Platform Web コンソールプラグインおよび Flowlogs-Pipeline から toleration が削除されるようになりました。
さらに、toleration は FlowCollector カスタムリソース (CR) で随時設定できますが、以前は toleration を空のリストに置き換えることは不可能でした。現在は、toleration を空のリストに置き換えることが可能です。
2.1.10. Network Observability Operator 1.9.3 アドバイザリー
Network Observability Operator 1.9.3 リリースのアドバイザリーを確認できます。
2.1.11. Network Observability Operator 1.9.2 アドバイザリー
Network Observability Operator 1.9.2 リリースのアドバイザリーを確認できます。
2.1.12. Network Observability 1.9.2 のバグ修正
Network Observability Operator 1.9.1 リリースで修正された問題を確認できます。
-
この更新前は、OpenShift Container Platform バージョン 4.15 以前では
TC_ATTACH_MODE設定はサポートされていませんでした。これにより、コマンドラインインターフェイス (CLI) エラーが発生し、パケットとフローの観測が妨げられました。このリリースでは、Traffic Control eXtension (TCX) のフックアタッチメントモードが、これらの古いバージョン向けに調整されました。これにより、tcxフックのエラーが解消され、フローとパケットの観測が可能になります。
2.1.13. Network Observability Operator 1.9.1 のアドバイザリー
Network Observability Operator 1.9.1 リリースのアドバイザリーを確認できます。
Network Observability Operator 1.9.1 では、次のアドバイザリーを利用できます。
2.1.14. Network Observability Operator 1.9.1 で修正された問題
Network Observability Operator 1.9.1 リリースで修正された問題を確認できます。
-
この更新前は、アタッチモードの設定が間違っていたため、OpenShift Container Platform 4.15 でネットワークフローが観測されていませんでした。そのため、特に特定のカタログで、ユーザーがネットワークフローを正しく監視できていませんでした。このリリースでは、OpenShift Container Platform バージョン 4.16.0 より前のバージョンのデフォルトアタッチモードが
tcに設定されているため、OpenShift Container Platform 4.15 でフローが観測されるようになりました。(NETOBSERV-2333) - この更新前は、IPFIX コレクターが再起動すると、IPFIX エクスポーターの設定時に接続が失われ、コレクターへのネットワークフローの送信が停止することがありました。このリリースでは、接続が復元され、ネットワークフローが引き続きコレクターに送信されます。(NETOBSERV-2315)
- この更新前は、IPFIX エクスポーターを設定すると、ポート情報のないフロー (ICMP トラフィックなど) が無視され、ログにエラーが記録されていました。TCP フラグと ICMP データも IPFIX エクスポートから欠落していました。このリリースでは、これらの詳細が含まれるようになりました。欠落しているフィールド (ポートなど) によってエラーが発生しなくなり、エクスポートされたデータに含まれるようになりました。(NETOBSERV-2307)
- この更新前は、OpenShift Container Platform 4.18 でユーザー定義ネットワーク (UDN) マッピング機能の設定上の問題と警告が表示されていました。これは、OpenShift のバージョンがコード内で誤って設定されていたことが原因でした。これはユーザーエクスペリエンスに影響を与えていました。このリリースでは、UDN マッピングが OpenShift Container Platform 4.18 をサポートするようになり、警告が表示されなくなったため、ユーザーエクスペリエンスがスムーズになりました。(NETOBSERV-2305)
-
この更新前は、Network Traffic ページの拡張機能に、OpenShift Container Platform Console 4.19 との互換性の問題がありました。その結果、展開時に空のメニュースペースが表示され、ユーザーインターフェイスに一貫性がありませんでした。このリリースでは、
NetflowTraffic部分とtheme hookの互換性の問題が解決されました。Network Traffic ビューのサイドメニューが適切に管理されるようになり、ユーザーインターフェイスの操作性が向上しました。(NETOBSERV-2304)
2.1.15. Network Observability Operator 1.9.0 のアドバイザリー
Network Observability Operator 1.9.0 リリースのアドバイザリーを確認できます。
2.1.16. Network Observability Operator 1.9.0 の新機能と機能拡張
Network Observability Operator 1.9.0 リリースの新機能と機能拡張を確認できます。
2.1.16.1. ネットワークオブザーバビリティーにおけるユーザー定義ネットワーク
今回のリリースにより、ネットワークオブザーバビリティーで ユーザー定義ネットワーク (UDN) 機能が一般提供になりました。ネットワークオブザーバビリティーで UDNMapping 機能が有効になっている場合、Traffic フローテーブルに UDN labels 列が表示されます。Source Network Name と Destination Network Name の情報に基づいてログをフィルタリングできます。
2.1.16.2. フローログ取り込み時のフィルタリング
このリリースでは、生成されるネットワークフローの数と Network Observability コンポーネントのリソース使用量を削減するためのフィルターを作成できます。設定できるフィルターは次のとおりです。
- eBPF エージェントフィルター
- flowlogs-pipeline フィルター
2.1.16.3. IPsec のサポート
この更新により、OpenShift Container Platform で IPsec が有効な場合、Network Observability に次の機能拡張が導入されます。
- IPsec Status という新しい列が Network Observability の Traffic フロービューに表示され、フローが正常に IPsec で暗号化されたかどうか、または暗号化/復号化中にエラーが発生したかどうかが表示されます。
- 暗号化されたトラフィックの割合を示す新しいダッシュボードが生成されます。
2.1.16.4. Network Observability CLI
パケット、フロー、メトリクスのキャプチャーで、次のフィルタリングオプションが利用できるようになりました。
-
--samplingオプションを使用して、サンプリングされるパケットの比率を設定します。 -
--queryオプションを使用して、カスタムクエリーを使用してフローをフィルタリングします。 -
--interfacesオプションを使用して、監視するインターフェイスを指定します。 -
--exclude_interfacesオプションを使用して、除外するインターフェイスを指定します。 -
--include_listオプションを使用して、生成するメトリクス名を指定します。
詳細は以下を参照してください。
2.1.17. 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 パフォーマンスが向上しました。
2.1.18. Network Observability Operator 1.9.0 のテクノロジープレビュー機能
Network Observability Operator 1.9.0 リリースのテクノロジープレビュー機能を確認できます。
現在、このリリースに含まれる機能にはテクノロジープレビューのものがあります。これらの実験的機能は、実稼働環境での使用を目的としていません。これらの機能に関しては、Red Hat カスタマーポータルの以下のサポート範囲を参照してください。
2.1.18.1. eBPF Manager Operator と Network Observability の連携
eBPF Manager Operator は、すべての eBPF プログラムを管理することで、攻撃対象領域を削減し、コンプライアンス、セキュリティー、競合防止を実現します。ネットワークオブザーバビリティーは、eBPF Manager Operator を使用してフックをロードできます。これにより、特権モードや、CAP_BPF や CAP_PERFMON などの追加の Linux ケイパビリティーを eBPF エージェントに提供する必要がなくなります。eBPF Manager Operator と Network Observability の連携は、64 ビット AMD アーキテクチャーでのみサポートされています。
2.1.19. Network Observability Operator 1.9.0 の CVE
Network Observability Operator 1.9.0 リリースの CVE を確認できます。
2.1.20. 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)
2.1.21. 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)
2.1.22. Network Observability Operator 1.8.1 のアドバイザリー
Network Observability Operator 1.8.1 リリースのアドバイザリーを確認できます。
2.1.23. Network Observability Operator 1.8.1 の CVE
Network Observability Operator 1.8.1 リリースの CVE を確認できます。
2.1.24. Network Observability Operator 1.8.1 で修正された問題
Network Observability Operator 1.8.1 リリースで修正された問題を確認できます。
- この修正により、OpenShift Container Platform の今後のバージョンでは、Observe メニューが 1 回だけ表示されるようになります。(NETOBSERV-2139)
2.1.25. Network Observability Operator 1.8.0 のアドバイザリー
Network Observability Operator 1.8.0 リリースのアドバイザリーを確認できます。
2.1.26. Network Observability Operator 1.8.0 の新機能と機能拡張
Network Observability Operator 1.8.0 リリースの新機能と機能拡張を確認できます。
2.1.26.1. パケット変換
変換されたエンドポイント情報を使用してネットワークフローをエンリッチできるようになりました。サービスだけでなく特定のバックエンド Pod も表示されるため、どの Pod がリクエストを処理したか確認できます。
詳細は以下を参照してください。
2.1.26.2. OVN-Kubernetes ネットワークイベントトラッキング
OVN-Kubernetes ネットワークイベントトラッキングは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
Network Observability のネットワークイベントトラッキングを使用して、ネットワークポリシー、管理ネットワークポリシー、Egress ファイアウォールなどの OVN-Kubernetes イベントに関する情報を取得できるようになりました。
詳細は以下を参照してください。
2.1.26.3. 1.8 における eBPF パフォーマンスの改善
- ネットワークオブザーバビリティーで、CPU ごとのマップではなくハッシュマップが使用されるようになりました。つまり、ネットワークフローデータがカーネル空間で追跡され、新しいパケットもそこに集約されます。ネットワークフローの重複排除がカーネル内で実行できるようになったため、カーネルとユーザー空間の間のデータ転送サイズによってパフォーマンスが向上します。これらの eBPF パフォーマンスの向上により、eBPF エージェントで CPU リソースが 40% から 57% 削減される可能性があります。
2.1.26.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を使用する任意のフィールド
詳細は以下を参照してください。
2.1.27. 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)
2.1.28. 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)
2.1.29. Network Observability Operator 1.7.0 アドバイザリー
Network Observability Operator 1.7.0 リリースのアドバイザリーを確認できます。
2.1.30. Network Observability Operator 1.7.0 の新機能と機能拡張
Network Observability Operator 1.7.0 リリースの次の新機能と機能拡張を確認できます。
2.1.30.1. OpenTelemetry のサポート
エンリッチされたネットワークフローを、Red Hat build of OpenTelemetry などの互換性のある OpenTelemetry エンドポイントにエクスポートできるようになりました。
詳細は以下を参照してください。
2.1.30.2. ネットワークオブザーバビリティーの Developer パースペクティブ
Developer パースペクティブで Network Observability を使用できるようになりました。
詳細は以下を参照してください。
2.1.30.3. TCP フラグフィルタリング
tcpFlags フィルターを使用して、eBPF プログラムによって処理されるパケットの量を制限できるようになりました。
詳細は以下を参照してください。
2.1.30.4. OpenShift Virtualization のネットワークオブザーバビリティー
Open Virtual Network (OVN)-Kubernetes などを介してセカンダリーネットワークに接続された仮想マシンから送信される eBPF エンリッチ化ネットワークフローを検出することで、OpenShift Virtualization 環境のネットワークパターンを観測できます。
詳細は以下を参照してください。
2.1.30.5. FlowCollector カスタムリソース (CR) でのネットワークポリシーのデプロイ
今回のリリースにより、FlowCollector カスタムリソース (CR) を設定して、ネットワークオブザーバビリティーのためのネットワークポリシーをデプロイできるようになりました。以前は、ネットワークポリシーが必要な場合は、手動で作成する必要がありました。ネットワークポリシーを手動で作成するオプションは引き続き利用可能です。
詳細は以下を参照してください。
2.1.30.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 暗号化ライブラリーを使用します。
2.1.30.7. eBPF エージェントの機能拡張
eBPF エージェントで次の機能拡張を利用できます。
-
DNS サービスが
53以外のポートにマッピングされている場合は、spec.agent.ebpf.advanced.env.DNS_TRACKING_PORTを使用して、この DNS トラッキングポートを指定できます。 - トランスポートプロトコル (TCP、UDP、または SCTP) のフィルタリングルールに 2 つのポートを使用できるようになりました。
- プロトコルフィールドを空のままにしておくことで、ワイルドカードプロトコルを使用してトランスポートポートをフィルタリングできるようになりました。
詳細は以下を参照してください。
2.1.30.8. Network Observability CLI
Network Observability CLI (oc netobserv) が一般提供になりました。バージョン 1.6 のテクノロジープレビューリリース以降、以下の機能拡張が行われました。
- フローキャプチャーと同様に、パケットキャプチャー用の eBPF エンリッチメントフィルターが追加されました。
-
フローキャプチャーとパケットキャプチャーの両方でフィルター
tcp_flagsを使用できるようになりました。 - 最大バイト数または最大時間に達したときに、自動ティアダウンオプションを利用できます。
詳細は以下を参照してください。
2.1.31. 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)
2.1.32. 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 への呼び出しがブロックされます。回避策として、次のネットワークポリシーを使用してください。kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: allow-from-hostnetwork namespace: netobserv spec: podSelector: matchLabels: app: netobserv-operator ingress: - from: - namespaceSelector: matchLabels: policy-group.network.openshift.io/host-network: '' policyTypes: - Ingress
2.1.33. Network Observability Operator リリースノート 1.6.2 のアドバイザリー
Network Observability Operator 1.6.2 リリースのアドバイザリーを確認できます。
2.1.34. Network Observability Operator リリースノート 1.6.2 の CVE
Network Observability Operator 1.6.2 リリースの CVE を確認できます。
2.1.35. Network Observability Operator リリースノート 1.6.2 の修正された問題
Network Observability Operator 1.6.2 リリースで修正された問題を確認できます。
- セカンダリーインターフェイスのサポートが追加されたときに、インターフェイスの通知を確認するために、ネットワークごとの namespace を netlink に登録する作業を複数回繰り返す必要がありました。同時に、TC とは異なり、TCX フックではインターフェイスがダウンしたときにハンドラーを明示的に削除する必要があったため、失敗したハンドラーによってファイル記述子のリークが発生しました。これで、Pod の作成および削除時にファイル記述子がリークしなくなりました。(NETOBSERV-1805)
2.1.36. Network Observability Operator リリースノート 1.6.2 の既知の問題
Network Observability Operator 1.6.2 リリースの既知の問題を確認できます。
- コンソールプラグインとの互換性の問題があり、OpenShift Container Platform クラスターの将来のバージョンに Network Observability をインストールできない可能性がありました。1.6.2 にアップグレードすると、互換性の問題が解決され、Network Observability を期待どおりにインストールできるようになります。(NETOBSERV-1737)
2.1.37. Network Observability Operator リリースノート 1.6.1 のアドバイザリー
Network Observability Operator 1.6.1 リリースのアドバイザリーを確認できます。
2.1.38. Network Observability Operator リリースノート 1.6.1 の CVE
Network Observability Operator 1.6.1 リリースの CVE を確認できます。
2.1.39. 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 コンソールの Topology ビューで、任意のグラフノードの横にある 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)
2.1.40. Network Observability Operator リリースノート 1.6.0 のアドバイザリー
Network Observability Operator 1.6.0 リリースのアドバイザリーを確認できます。
2.1.41. Network Observability Operator 1.6.0 の新機能と機能拡張
Network Observability Operator 1.6.0 の次の新機能と機能拡張を確認できます。
2.1.41.1. Loki を使用しない場合の Network Observability Operator の使用の強化
Network Observability Operator を使用すると、Prometheus メトリクスを使用でき、ストレージのために Loki に依存する度合いが低下します。
詳細は以下を参照してください。
2.1.41.2. カスタムメトリクス API
FlowMetrics API を使用して、フローログデータからカスタムメトリクスを作成できます。フローログデータを Prometheus ラベルと組み合わせて使用することで、ダッシュボード上のクラスター情報をカスタマイズできます。識別する必要があるフローおよびメトリクスのサブネットに、カスタムラベルを追加できます。この機能拡張により、新しいラベル SrcSubnetLabel と DstSubnetLabel を使用して、フローログとメトリクスの両方に存在する外部トラフィックをより簡単に識別することもできます。外部トラフィックがある場合、これらのフィールドが空になるため、外部トラフィックを識別できます。
詳細は以下を参照してください。
2.1.41.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 に更新する必要があります。
詳細は以下を参照してください。
2.1.41.4. eBPF 収集のルールベースのフィルタリング
ルールベースのフィルタリングを使用して、作成されるフローの量を削減できます。このオプションを有効にすると、eBPF エージェント統計の Netobserv/Health ダッシュボードに、Filtered flows rate ビューが表示されます。
詳細は以下を参照してください。
2.1.42. 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)
2.1.43. 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)
2.1.44. Network Observability Operator 1.5.0 アドバイザリー
Network Observability Operator 1.5 リリースの次のアドバイザリーを参照できます。
2.1.45. Network Observability Operator 1.5.0 の新機能と機能拡張
Network Observability Operator 1.5 リリースの次の新機能と機能拡張を確認できます。
2.1.45.1. DNS トラッキングの機能拡張
1.5 では、UDP に加えて TCP プロトコルもサポートされるようになりました。また、新しいダッシュボードが、Network Traffic ページの Overview ビューに追加されました。
詳細は以下を参照してください。
2.1.45.2. ラウンドトリップタイム (RTT)
fentry/tcp_rcv_established Extended Berkeley Packet Filter (eBPF) フックポイントから取得した TCP ハンドシェイクのラウンドトリップタイム (RTT) を使用して、平滑化されたラウンドトリップタイム (SRTT) を読み取り、ネットワークフローを分析できます。Web コンソールの Overview、Network Traffic、および Topology ページで、ネットワークトラフィックを監視し、RTT メトリクス、フィルタリング、およびエッジラベルを使用してトラブルシューティングを行うことができます。
詳細は以下を参照してください。
2.1.45.3. メトリクス、ダッシュボード、アラートの機能拡張
Observe → Dashboards → NetObserv の Network Observability メトリクスダッシュボードに、Prometheus アラートの作成に使用できる新しいメトリクスタイプがあります。利用可能なメトリクスを includeList 仕様で定義できるようになりました。以前のリリースでは、これらのメトリクスは ignoreTags 仕様で定義されていました。
これらのメトリクスの完全なリストについては、以下を参照してください。
2.1.45.4. Loki を使用していない場合の Network Observability の向上
Loki を使用していない場合でも、DNS、パケットドロップ、および RTT メトリクスを使用して Netobserv ダッシュボードの Prometheus アラートを作成できます。旧バージョンの Network Observability 1.4 では、これらのメトリクスは、Network Traffic、Overview、および Topology ビューでのクエリーと分析にのみ使用できました。これらのビューを使用するには、Loki が必要でした。
詳細は以下を参照してください。
2.1.45.5. アベイラビリティーゾーン
クラスターのアベイラビリティーゾーンに関する情報を収集するように FlowCollector リソースを設定できます。この設定では、ノードに適用される topology.kubernetes.io/zone ラベル値を使用してネットワークフローデータをエンリッチします。
詳細は以下を参照してください。
2.1.45.6. 主な機能拡張
Network Observability Operator の 1.5 リリースでは、OpenShift Container Platform Web コンソールプラグインと Operator 設定が改良され、新機能が追加されています。
2.1.45.7. パフォーマンスの強化
Kafka 使用時の eBPF のパフォーマンスを向上させるために、
spec.agent.ebpf.kafkaBatchSizeのデフォルトが10MBから1MBに変更されました。重要既存のインストールからアップグレードする場合、この新しい値は自動的に設定されません。アップグレード後に eBPF Agent のメモリー消費のパフォーマンスリグレッションが確認された場合は、
kafkaBatchSizeを減らして別の値にすることを検討してください。
2.1.45.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 をフィルタリングできます。
2.1.45.9. 設定の機能拡張
-
spec.loki.mode仕様をLokiStackモードにすると、URL、TLS、クラスターロール、クラスターロールバインディング、およびauthToken値を自動的に設定され、インストールが簡素化されます。Manualモードを使用すると、これらの設定をより詳細に制御できます。 -
API バージョンが
flows.netobserv.io/v1beta1からflows.netobserv.io/v1beta2に変更されます。
2.1.46. 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)
2.1.47. 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 がメモリーを大幅に使用している際に事前割り当てが無効化されるようにします。
2.1.48. Network Observability Operator 1.4.2 のアドバイザリー
Network Observability Operator 1.4.2 では、次のアドバイザリーを利用できます。
2.1.49. Network Observability Operator 1.4.2 の CVE
Network Observability Operator 1.4.2 リリースでは、次の CVE を確認できます。
2.1.50. Network Observability Operator 1.4.1 のアドバイザリー
Network Observability Operator 1.4.1 の次のアドバイザリーを確認できます。
2.1.51. Network Observability Operator リリース 1.4.1 の CVE
Network Observability Operator 1.4.1 リリースでは、次の CVE を確認できます。
2.1.52. 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)
2.1.53. Network Observability リリースノート 1.4.0 のアドバイザリー
Network Observability Operator 1.4.0 リリースの次のアドバイザリーを確認できます。
2.1.54. Network Observability リリースノート 1.4.0 の新機能と機能拡張
Network Observability Operator 1.4.0 リリースでは、次の新機能と機能拡張を確認できます。
2.1.54.1. 主な機能拡張
Network Observability Operator の 1.4 リリースでは、OpenShift Container Platform Web コンソールプラグインと Operator 設定が改良され、新機能が追加されています。
2.1.54.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 とワークロードの分割ビューで表示されます。
詳細は以下を参照してください。
2.1.54.3. 設定の機能拡張
- 証明書設定など、設定された ConfigMap または Secret 参照に対して異なる namespace を指定できるオプションが追加されました。
-
spec.processor.clusterNameパラメーターが追加されたため、クラスターの名前がフローデータに表示されるようになりました。これは、マルチクラスターコンテキストで役立ちます。OpenShift Container Platform を使用する場合は、自動的に決定されるように空のままにします。
詳細は以下を参照してください。
2.1.54.4. Loki を使用しないネットワークオブザーバビリティー
Network Observability Operator は、Loki なしでも機能し、使用できるようになりました。Loki がインストールされていない場合は、フローを KAFKA または IPFIX 形式にエクスポートし、Network Observability メトリクスダッシュボードに入力することのみ可能です。
詳細は以下を参照してください。
2.1.54.5. DNS トラッキング
1.4 では、Network Observability Operator は eBPF トレースポイントフックを使用して DNS トラッキングを有効にします。Web コンソールの Network Traffic ページと Overview ページで、ネットワークの監視、セキュリティー分析の実施、DNS 問題のトラブルシューティングを行なえます。
詳細は以下を参照してください。
2.1.54.6. SR-IOV のサポート
Single Root I/O Virtualization (SR-IOV) デバイスを使用して、クラスターからトラフィックを収集できるようになりました。
詳細は以下を参照してください。
2.1.54.7. IPFIX エクスポーターのサポート
eBPF エンリッチ化ネットワークフローを IPFIX コレクターにエクスポートできるようになりました。
詳細は以下を参照してください。
2.1.54.8. パケットドロップ
Network Observability Operator の 1.4 リリースでは、eBPF トレースポイントフックを使用してパケットドロップトラッキングを有効にできます。パケットドロップの原因を検出して分析し、ネットワークパフォーマンスを最適化するための決定を行えるようになりました。OpenShift Container Platform 4.14 以降では、ホストのドロップと OVS のドロップの両方が検出されます。OpenShift Container Platform 4.13 では、ホストのドロップのみが検出されます。
詳細は以下を参照してください。
2.1.54.9. s390x アーキテクチャーのサポート
Network Observability Operator が、s390x アーキテクチャー上で実行できるようになりました。以前は、amd64、ppc64le、または arm64 で実行されていました。
2.1.55. Network Observability リリースノート 1.4.0 の削除された機能
Network Observability Operator 1.4.0 リリースでは、次の削除された機能を確認できます。
2.1.55.1. チャネルの削除
最新の Operator 更新を受信するには、チャネルを v1.0.x から stable に切り替える必要があります。v1.0.x チャネルは削除されました。
2.1.56. Network Observability リリースノート 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)
2.1.57. Network Observability リリースノート 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 がメモリーを大幅に使用している際に事前割り当てが無効化されるようにします。
2.1.58. Network Observability Operator 1.3.0 のアドバイザリー
Network Observability Operator 1.3.0 リリースでは、次のアドバイザリーを確認できます。
2.1.59. Network Observability Operator 1.3.0 の新機能と機能拡張
Network Observability Operator 1.3.0 リリースでは、次の新機能と機能拡張を確認できます。
2.1.59.1. Network Observability におけるマルチテナンシー
- システム管理者は、Loki に保存されているフローへの個々のユーザーアクセスまたはグループアクセスを許可および制限できます。詳細は、「Network Observability におけるマルチテナンシー」を参照してください。
2.1.59.2. フローベースのメトリクスダッシュボード
- このリリースでは、OpenShift Container Platform クラスター内のネットワークフローの概要を表示する新しいダッシュボードが追加されています。詳細は、「ネットワークオブザーバビリティーメトリクスのダッシュボード」を参照してください。
2.1.59.3. must-gather ツールを使用したトラブルシューティング
- Network Observability Operator に関する情報を、トラブルシューティングで使用する must-gather データに追加できるようになりました。詳細は、「ネットワークオブザーバビリティーの must-gather」を参照してください。
2.1.59.4. 複数のアーキテクチャーに対するサポートを開始
-
Network Observability Operator は、
amd64、ppc64le、またはarm64アーキテクチャー上で実行できるようになりました。以前は、amd64上でのみ動作しました。
2.1.60. Network Observability Operator 1.3.0 の非推奨機能
Network Observability Operator 1.3.0 リリースでは、次の非推奨機能を確認できます。
2.1.60.1. チャネルの非推奨化
今後の Operator 更新を受信するには、チャネルを v1.0.x から stable に切り替える必要があります。v1.0.x チャネルは非推奨となり、次のリリースで削除される予定です。
2.1.60.2. 非推奨の設定パラメーターの設定
Network Observability Operator 1.3 のリリースでは、spec.Loki.authToken HOST 設定が非推奨になりました。Loki Operator を使用する場合、FORWARD 設定のみを使用する必要があります。
2.1.61. 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)
2.1.62. 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 がメモリーを大幅に使用している際に事前割り当てが無効化されるようにします。
2.1.63. Network Observability リリースノート 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 チャネルは非推奨となり、次のリリースで削除される予定です。
2.1.64. Network Observability Operator 1.2.0 のアドバイザリー
Network Observability Operator 1.2.0 リリースの次のアドバイザリーを参照できます。
2.1.65. Network Observability Operator 1.2.0 の新機能と機能拡張
Network Observability Operator 1.2.0 リリースの次の新機能と機能拡張を確認できます。
2.1.65.1. Traffic Flows ビューのヒストグラム
経時的なフローのヒストグラムを表示することを選択できるようになりました。ヒストグラムを使用すると、Loki クエリー制限に達することなくフロー履歴を可視化できます。詳細は、「ヒストグラムの使用」を参照してください。
2.1.65.2. 会話トラッキング
ログタイプ でフローをクエリーできるようになりました。これにより、同じ会話に含まれるネットワークフローをグループ化できるようになりました。詳細は、「会話の使用」を参照してください。
2.1.65.3. ネットワークオブザーバビリティーの健全性アラート
Network Observability Operator は、書き込み段階でのエラーが原因で flowlogs-pipeline がフローをドロップする場合、または Loki 取り込みレート制限に達した場合、自動アラートを作成するようになりました。詳細は、「健全性ダッシュボード」を参照してください。
2.1.66. Network Observability Operator 1.2.0 のバグ修正
Network Observability Operator 1.2.0 リリースで修正された次の問題を確認できます。
-
これまでは、FlowCollector 仕様の
namespaceの値を変更すると、以前の namespace で実行されているeBPFagent Pod が適切に削除されませんでした。今は、以前の namespace で実行されている Pod も適切に削除されるようになりました。(NETOBSERV-774) -
これまでは、FlowCollector 仕様 (Loki セクションなど) の
caCert.name値を変更しても、FlowLogs-Pipeline Pod およびコンソールプラグイン Pod が再起動されないため、設定の変更が認識されませんでした。今は、Pod が再起動されるため、設定の変更が適用されるようになりました。(NETOBSERV-772) - これまでは、異なるノードで実行されている Pod 間のネットワークフローは、異なるネットワークインターフェイスでキャプチャーされるため、重複が正しく認識されないことがありました。その結果、コンソールプラグインに表示されるメトリクスが過大に見積もられていました。現在は、フローが重複として正しく識別され、コンソールプラグインで正確なメトリクスが表示されます。(NETOBSERV-755)
- コンソールプラグインの "レポーター" オプションは、送信元ノードまたは宛先ノードのいずれかの観測点に基づいてフローをフィルタリングするために使用されます。以前は、このオプションはノードの観測点に関係なくフローを混合していました。これは、ネットワークフローがノードレベルで Ingress または Egress として誤って報告されることが原因でした。これで、ネットワークフロー方向のレポートが正しくなりました。"レポーター" オプションは、期待どおり、ソース観測点または宛先観測点をフィルターします。(NETOBSERV-696)
- 以前は、フローを gRPC+protobuf リクエストとしてプロセッサーに直接送信するように設定されたエージェントの場合、送信されたペイロードが大きすぎる可能性があり、プロセッサーの GRPC サーバーによって拒否されました。これは、非常に高負荷のシナリオで、エージェントの一部の設定でのみ発生しました。エージェントは、次のようなエラーメッセージをログに記録しました: grpc: max より大きいメッセージを受信しました。その結果、それらのフローに関する情報が損失しました。現在、gRPC ペイロードは、サイズがしきい値を超えると、いくつかのメッセージに分割されます。その結果、サーバーは接続を維持します。(NETOBSERV-617)
2.1.67. Network Observability Operator 1.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)
2.1.68. 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、およびその他のプラグインでも引き続き使用できることに注意することが重要です。
2.1.69. Network Observability Operator 1.1.0 の機能拡張
Network Observability Operator 1.1.0 の次のアドバイザリーを参照できます。
Network Observability Operator は安定版になり、リリースチャネルが v1.1.0 にアップグレードされました。
2.1.70. Network Observability Operator 1.10 で修正された問題
Network Observability Operator 1.1.0 リリースで修正された次の問題を確認できます。
-
以前は、Loki の
authToken設定がFORWARDモードに設定されていない限り、認証が強制されず、権限のないユーザーがフローを取得できました。現在は、Loki のauthTokenモードに関係なく、クラスター管理者のみがフローを取得できます。(BZ#2169468)
第3章 Network Observability について
Network Observability Operator を使用し、eBPF テクノロジーを利用してネットワークトラフィックを観測することで、Prometheus メトリクスと Loki ログを通じてトラブルシューティング用の詳細情報を入手できます。
OpenShift Container Platform コンソールでこの保存された情報を表示および分析して、さらに詳細な分析やトラブルシューティングを行うことができます。
3.1. Network Observability Operator
Network Observability Operator は、クラスタースコープの FlowCollector API カスタムリソースを提供します。このリソースは、Loki または Prometheus でネットワークフローを収集、補完、保存する eBPF エージェントとサービスのパイプラインを管理します。
FlowCollector インスタンスは、監視パイプラインを形成する Pod とサービスをデプロイします。
eBPF エージェントは daemonset オブジェクトとしてデプロイされ、ネットワークフローを作成します。このパイプラインは、ネットワークフローを収集し、Kubernetes メタデータでエンリッチしてから、Loki への保存や Prometheus メトリクスの生成を行います。
3.2. Network Observability Operator のオプションの依存関係
Network Observability Operator を、オプションの依存関係と統合します。これには、フローストレージ用の Loki Operator、回復力のある大規模データ処理とスケーラビリティー用の AMQ Streams (Kafka) などが含まれます。
サポートされているオプションの依存関係には、フローストレージ用の Loki Operator や、Kafka を使用した大規模データ処理用の AMQ Streams などがあります。
- Loki Operator
- 収集されたすべてのフローを最大限の詳細度で保存するために、Loki をバックエンドとして使用できます。Loki をインストールするには、Red Hat がサポートする Loki Operator を使用することを推奨します。Loki を使用せずに Network Observability を使用するように選択することもできますが、いくつかの要素を考慮する必要があります。詳細は、「Loki を使用しないネットワークオブザーバビリティー」を参照してください。
- AMQ Streams Operator
Kafka は、大規模なデプロイメント向けに OpenShift Container Platform クラスターにスケーラビリティー、復元力、高可用性を提供します。
注記Kafka を使用する場合は、Red Hat がサポートする AMQ Streams Operator を使用することを推奨します。
3.3. OpenShift Container Platform コンソールの統合
Network Observability Operator は OpenShift Container Platform コンソールと統合され、概要、トポロジービュー、トラフィックフローテーブルを提供します。
Observe → Dashboards のネットワークオブザーバビリティーメトリクスダッシュボードは、管理者アクセス権を持つユーザーのみが利用できます。
開発者アクセスと namespace へのアクセスが制限されている管理者に対してマルチテナンシーを有効にするには、ロールを定義して権限を指定する必要があります。詳細は、「Network Observability でのマルチテナンシーの有効化」を参照してください。
3.3.1. ネットワークオブザーバビリティーメトリクスのダッシュボード
OpenShift Container Platform コンソールのネットワークオブザーバビリティーメトリクスダッシュボードを確認します。このダッシュボードでは、全体的なトラフィックフローの集約、フィルタリングオプション、Operator の健全性を監視するための専用ダッシュボードが提供されます。
OpenShift Container Platform コンソールの Overview タブでは、クラスター上のネットワークトラフィックフローの全体的な集計メトリクスを表示できます。クラスター、ノード、namespace、所有者、Pod、サービスごとに情報を表示するように選択できます。フィルターと表示オプションにより、メトリクスをさらに絞り込むことができます。詳細は、「Overview ビューからのネットワークトラフィックの観測」を参照してください。
Observe → Dashboards の Netobserv ダッシュボードには、OpenShift Container Platform クラスター内のネットワークフローの簡易的な概要が表示されます。Netobserv/Health ダッシュボードは、Operator の健全性に関するメトリクスを提供します。詳細は、「ネットワークオブザーバビリティーメトリクス」および「健全性情報の表示」を参照してください。
3.3.2. ネットワークオブザーバビリティーのトポロジービュー
OpenShift Container Platform コンソールのネットワークオブザーバビリティートポロジービューには、コンポーネント間のトラフィックフローがグラフィカル表示され、さまざまなフィルターや表示オプションを使用して絞り込むことができます。
OpenShift Container Platform コンソールには、OpenShift Container Platform コンポーネント間のトラフィックをネットワークグラフとして表示する Topology タブがあります。フィルターと表示オプションを使用して、グラフを絞り込むことができます。クラスター、ゾーン、udn、ノード、namespace、所有者、Pod、サービスの情報にアクセスできます。
3.3.3. トラフィックフローテーブル
OpenShift Container Platform Web コンソールの Traffic flow テーブルでは、生のネットワークフローが詳細に表示され、詳細な分析のための強力なフィルタリングオプションと設定可能な列が提供されます。
OpenShift Container Platform Web コンソールの Traffic flows タブには、ネットワークフローのデータとトラフィック量が表示されます。
3.4. Network Observability CLI
Network Observability CLI (oc netobserv) は、Network Observability Operator を完全にインストールしなくても、フローとパケットデータをストリーミングして、ネットワークの問題を迅速かつリアルタイムで把握できる軽量ツールです。
Network Observability CLI は、eBPF エージェントを利用して収集したデータを一時的なコレクター Pod にストリーミングするフローおよびパケット可視化ツールです。キャプチャー中に永続的なストレージは必要ありません。実行後、出力がローカルマシンに転送されます。そのため、Network Observability Operator をインストールしなくても、パケットとフローデータをすばやくライブで把握できます。
第4章 Network Observability Operator のインストール
Network Observability Operator を使用する前に、Loki Operator をインストールすることを推奨します。Loki なしでも Network Observability を使用できますが、メトリクスまたは外部エクスポーターのみが必要な場合には、特別な考慮事項が適用されます。
Loki Operator は、マルチテナンシーと認証を実装するゲートウェイを Loki と統合して、データフローストレージを実現します。LokiStack リソースは、スケーラブルで高可用性のマルチテナントログ集約システムである Loki と、OpenShift Container Platform 認証を備えた Web プロキシーを管理します。LokiStack プロキシーは、OpenShift Container Platform 認証を使用してマルチテナンシーを適用し、Loki ログストアでのデータの保存とインデックス作成を容易にします。
4.1. Loki を使用しないネットワークオブザーバビリティー
ネットワークオブザーバビリティーで利用できる機能を、Loki Operator をインストールした場合とインストールしない場合で比較します。
フローを Kafka コンシューマーまたは IPFIX コレクターのみにエクスポートする場合、またはダッシュボードメトリクスのみ必要な場合は、Loki をインストールしたり、Loki 用のストレージを提供したりする必要はありません。次の表は、Loki を使用した場合と使用しない場合の利用可能な機能を比較しています。
| Loki を使用する場合 | Loki を使用しない場合 | |
|---|---|---|
| エクスポーター | X | X |
| マルチテナンシー | X | X |
| 完全なフィルタリングと集計機能 [1] | X | |
| 部分的なフィルタリングと集計機能 [2] | X | X |
| フローベースのメトリクスとダッシュボード | X | X |
| Traffic flows ビューの概要[3] | X | X |
| Traffic flows ビューテーブル | X | |
| トポロジービュー | X | X |
| OpenShift Container Platform コンソールの Network Traffic タブの統合 | X | X |
- Pod ごとなど。
- ワークロードまたは namespace ごとなど。
- パケットドロップの統計情報は Loki でのみ利用可能です。
4.2. Loki Operator のインストール
ソフトウェアカタログからサポート対象の Loki Operator バージョンをインストールして、セキュアな LokiStack インスタンスを有効にします。これにより、ネットワークオブザーバビリティーのための自動クラスター内認証と認可が提供されます。
ネットワークオブザーバビリティーでサポートされている Loki Operator のバージョンは、Loki Operator バージョン 6.0 以降 です。これらのバージョンでは、openshift-network テナント設定モードを使用して LokiStack インスタンスを作成する機能が提供されており、ネットワークオブザーバビリティーに対する完全に自動化されたクラスター内認証および認可がサポートされています。
前提条件
- 管理者権限がある。
- OpenShift Container Platform Web コンソールにアクセスできる。
- サポートされているオブジェクトストアにアクセスできる。例: AWS S3、Google Cloud Storage、Azure、Swift、Minio、OpenShift Data Foundation。
手順
- OpenShift Container Platform Web コンソールで、Ecosystem → Software Catalog をクリックします。
- 使用可能な Operator のリストから Loki Operator を選択し、Install をクリックします。
- Installation Mode で、All namespaces on the cluster を選択します。
検証
- Loki Operator がインストールされていることを確認します。Ecosystem → Installed Operators ページにアクセスして、Loki Operator を探します。
- Loki Operator がすべてのプロジェクトで Succeeded の Status でリストされていることを確認します。
Loki をアンインストールするには、Loki のインストールに使用した方法に対応するアンインストールプロセスを参照してください。削除する必要がある ClusterRoles と ClusterRoleBindings、オブジェクトストアに保存されたデータ、および永続ボリュームが残っている可能性があります。
4.2.1. Loki ストレージのシークレットの作成
Amazon Web Services (AWS) などのクラウドストレージ認証情報を使用してシークレットを作成し、Loki Operator がログの永続化に必要なオブジェクトストアにアクセスできるようにします。
Loki Operator は、AWS S3、Google Cloud Storage、Azure、Swift、Minio、OpenShift Data Foundation など、いくつかのログストレージオプションをサポートしています。次の例は、AWS S3 ストレージのシークレットを作成する方法を示しています。この例で作成されたシークレット loki-s3 は、「LokiStack カスタムリソースの作成」で参照されています。このシークレットは、Web コンソールまたは CLI で作成できます。
手順
- Web コンソールを使用して、Project → All Projects ドロップダウンに移動し、Create Project を選択します。
-
プロジェクトに
netobservという名前を付けて、Create をクリックします。 右上隅にあるインポートアイコン + に移動します。YAML ファイルをエディターにペーストします。
以下は、S3 ストレージのシークレット YAML ファイルの例です。
apiVersion: v1 kind: Secret metadata: name: loki-s3 namespace: netobserv-loki stringData: access_key_id: QUtJQUlPU0ZPRE5ON0VYQU1QTEUK access_key_secret: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo= bucketnames: s3-bucket-name endpoint: https://s3.eu-central-1.amazonaws.com region: eu-central-1各項目の説明:
metadata.namespace-
Loki S3 シークレットの namespace を指定します。この例では
netobserv-lokiを使用していますが、コンポーネントごとに異なる namespace を使用することも可能です。 stringData.access_key_id- S3 バケットのアクセスキー ID を指定します。
stringData.access_key_secret- S3 バケットのシークレットアクセスキーを指定します。
stringData.bucketnames- S3 バケットの名前を指定します。
stringData.endpoint- S3 サービスのエンドポイント URL を指定します。
stringData.region- バケットが配置されている AWS リージョンを指定します。
検証
- シークレットを作成すると、Web コンソールの Workloads → Secrets にリストされたシークレットが表示されます。
4.2.2. LokiStack カスタムリソースの作成
Web コンソールまたは OpenShift CLI (oc) を使用して LokiStack カスタムリソースをデプロイし、Loki オブジェクトストレージの正しい namespace、デプロイメントサイズ、シークレット名が設定されていることを確認します。
LokiStack カスタムリソース (CR) をデプロイして、namespace または新しいプロジェクトを作成できます。
手順
- Ecosystem → Installed Operators に移動し、Project ドロップダウンから All projects を表示します。
- Loki Operator を探します。詳細の Provided APIs で、LokiStack を選択します。
- Create LokiStack をクリックします。
Form View または YAML view で次のフィールドが指定されていることを確認します。
apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: loki namespace: netobserv-loki spec: size: 1x.small storage: schemas: - version: v13 effectiveDate: '2022-06-01' secret: name: loki-s3 type: s3 storageClassName: gp3 tenants: mode: openshift-network各項目の説明:
metadata.namespace-
LokiStackリソースの namespace を指定します。この例ではnetobserv-lokiを使用していますが、コンポーネントごとに異なる namespace を使用することも可能です。 spec.sizeデプロイメントのサイズを指定します。Loki Operator 5.8 以降のバージョンでは、Loki の実稼働インスタンスでサポートされているサイズオプションは
1x.extra-small、1x.small、または1x.mediumです。重要デプロイメントサイズの
1xの数は変更できません。spec.storageClassNameReadWriteOnceアクセスモード用にクラスターで使用できるストレージクラス名を指定します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。クラスターで使用可能なストレージクラスを確認するには、oc get storageclassesコマンドを使用します。重要ロギングに使用する
LokiStackカスタムリソースを再利用しないでください。
- Create をクリックします。
4.2.3. cluster-admin ユーザーロールの新規グループの作成
cluster-admin ユーザーとして複数の namespace のアプリケーションログを照会すると、クラスター内の全 namespace の合計文字数が 5120 を超え、Parse error: input size too long (XXXX > 5120) エラーが発生します。LokiStack のログへのアクセスをより適切に制御するには、cluster-admin ユーザーを cluster-admin グループのメンバーにします。cluster-admin グループが存在しない場合は、作成して必要なユーザーを追加します。
次の手順を使用して、cluster-admin 権限のあるユーザー用に、新しいグループを作成します。
手順
以下のコマンドを入力して新規グループを作成します。
$ oc adm groups new cluster-admin以下のコマンドを実行して、必要なユーザーを
cluster-adminグループに追加します。$ oc adm groups add-users cluster-admin <username>以下のコマンドを実行して
cluster-adminユーザーロールをグループに追加します。$ oc adm policy add-cluster-role-to-group cluster-admin cluster-admin
4.2.4. カスタム管理者グループのアクセス権
必ずしも管理者でなくてもクラスター全体のログを確認する必要がある場合、またはここで使用したいグループがすでに定義されている場合は、adminGroup フィールドを使用してカスタムグループを指定できます。LokiStack カスタムリソース (CR) の adminGroups フィールドで指定されたグループのメンバーであるユーザーには、管理者と同じログの読み取りアクセス権があります。
管理者ユーザーは、クラスター全体のすべてのネットワークログにアクセスできます。
LokiStack CR の例
apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
name: loki
namespace: netobserv
spec:
tenants:
mode: openshift-network
openshift:
adminGroups:
- cluster-admin
- custom-admin-group 4.2.5. Loki デプロイメントのサイズ
Loki のサイズは 1x.<size> の形式に従います。この場合の 1x はインスタンスの数を、<size> は性能を指定します。
デプロイメントサイズの 1x の数は変更できません。
| 1x.demo | 1x.extra-small | 1x.small | 1x.medium | |
|---|---|---|---|---|
| Data transfer | デモ使用のみ | 100 GB/日 | 500 GB/日 | 2 TB/日 |
| 1 秒あたりのクエリー数 (QPS) | デモ使用のみ | 200 ミリ秒で 1 - 25 QPS | 200 ミリ秒で 25 - 50 QPS | 200 ミリ秒で 25 - 75 QPS |
| レプリケーション係数 | なし | 2 | 2 | 2 |
| 合計 CPU 要求 | なし | 仮想 CPU 14 個 | 仮想 CPU 34 個 | 仮想 CPU 54 個 |
| 合計メモリー要求 | なし | 31Gi | 67Gi | 139Gi |
| 合計ディスク要求 | 40Gi | 430Gi | 430Gi | 590Gi |
4.2.6. LokiStack の取り込み制限と健全性アラート
LokiStack インスタンスには、デフォルトの取り込みおよびクエリー制限が含まれています。管理者は、パフォーマンスを管理し、システムアラートやエラーを防ぐためにこれらの制限をオーバーライドできます。
コンソールプラグインまたは flowlogs-pipeline ログに Loki エラーが表示される場合は、取り込みとクエリーの制限を更新することを推奨します。
設定された制限の例を次に示します。
spec:
limits:
global:
ingestion:
ingestionBurstSize: 40
ingestionRate: 20
maxGlobalStreamsPerTenant: 25000
queries:
maxChunksPerQuery: 2000000
maxEntriesLimitPerQuery: 10000
maxQuerySeries: 3000これらの設定の詳細は、「LokiStack API リファレンス」を参照してください。
4.3. Network Observability Operator のインストール
Network Observability Operator をインストールし、セットアップウィザードを使用して FlowCollector カスタムリソース定義 (CRD) を作成し、初期設定を完了します。
FlowCollector を作成するときに、Web コンソールで仕様を設定できます。
Operator の実際のメモリー消費量は、クラスターのサイズとデプロイされたリソースの数によって異なります。それに応じて、メモリー消費量を調整する必要がある場合があります。詳細は、「Flow Collector 設定に関する重要な考慮事項」セクションの「Network Observability コントローラーマネージャー Pod のメモリーが不足する」を参照してください。
前提条件
- Loki を使用する場合は、Loki Operator バージョン 5.7 以降 をインストールしている。
-
cluster-admin権限を持っている必要があります。 -
サポートされているアーキテクチャーである
amd64、ppc64le、arm64、s390xのいずれか。 - Red Hat Enterprise Linux (RHEL) 9 でサポートされる任意の CPU。
- メインネットワークプラグインとして OVN-Kubernetes を使用して設定する必要があり、オプションで Multus および SR-IOV を使用したセカンダリーインターフェイスを使用する必要があります。
さらに、このインストール例では、すべてのコンポーネントで使用される netobserv namespace を使用します。必要に応じて、別の namespace を使用できます。
手順
- OpenShift Container Platform Web コンソールで、Ecosystem → Software Catalog をクリックします。
- ソフトウェアカタログで使用可能な Operator のリストから Network Observability Operator を選択し、Install をクリックします。
-
Enable Operator recommended cluster monitoring on this Namespaceチェックボックスを選択します。 - Operators → Installed Operators に移動します。Network Observability の Provided APIs で、Flow Collector リンクを選択します。
- Network Observability FlowCollector setup ウィザードに従います。
- Create をクリックします。
検証
これが成功したことを確認するには、Observe に移動すると、オプションに Network Traffic が表示されます。
OpenShift Container Platform クラスター内に アプリケーショントラフィック がない場合は、デフォルトのフィルターが "No results" と表示され、視覚的なフローが発生しないことがあります。フィルター選択の横にある Clear all filters を選択して、フローを表示します。
4.3.1. FlowCollector の設定に関する重要な考慮事項
後からの再設定によって発生する Pod の障害を回避するために、初回デプロイ前に FlowCollector の重要な設定オプションを確認してください。重要な設定としては、Kafka との統合、エンリッチされたフローデータのエクスポート、SR-IOV トラフィックの監視、DNS およびパケットドロップの高度なトラッキングなどが挙げられます。
FlowCollector インスタンスを作成すると、それを再設定することはできますが、Pod が終了して再作成されるため、中断が生じる可能性があります。
そのため、初めて FlowCollector を作成する際には、以下のオプションを設定することを検討してください。
4.3.2. FlowCollector CRD の削除された保存バージョンの移行
アップグレードエラーを防ぎ、Network Observability Operator 1.6 に正常に移行するために、FlowCollector カスタムリソース定義 (CRD) の storedVersion リストから非推奨の v1alpha1 バージョンを手動で削除します。
保存されたバージョンを削除するには、次の 2 つのオプションがあります。
- Storage Version Migrator Operator を使用します。
- Network Observability Operator をアンインストールして再インストールし、インストールがクリーンな状態であることを確認します。
前提条件
-
古いバージョンの Operator がインストールされており、最新バージョンの Operator をインストールするようにクラスターを準備する必要がある。または、Network Observability Operator 1.6 をインストールしようとして、
Failed risk of data loss updating "flowcollectors.flows.netobserv.io": new CRD removes version v1alpha1 that is listed as a stored version on the existing CRDエラーが発生している。
手順
古い
FlowCollectorCRD バージョンが、storedVersionで引き続き参照されていることを確認します。$ oc get crd flowcollectors.flows.netobserv.io -ojsonpath='{.status.storedVersions}'結果のリストに
v1alpha1が表示される場合は、手順 a に進んで Kubernetes Storage Version Migrator を使用するか、手順 b に進んで CRD と Operator をアンインストールして再インストールします。オプション 1: Kubernetes Storage Version Migrator:
StorageVersionMigrationオブジェクトを定義する YAML を作成します (例:migrate-flowcollector-v1alpha1.yaml)。apiVersion: migration.k8s.io/v1alpha1 kind: StorageVersionMigration metadata: name: migrate-flowcollector-v1alpha1 spec: resource: group: flows.netobserv.io resource: flowcollectors version: v1alpha1- ファイルを保存します。
次のコマンドを実行して、
StorageVersionMigrationを適用します。$ oc apply -f migrate-flowcollector-v1alpha1.yamlFlowCollectorCRD を更新して、storedVersionからv1alpha1を手動で削除します。$ oc edit crd flowcollectors.flows.netobserv.io
オプション 2: 再インストール: Network Observability Operator 1.5 バージョンの
FlowCollectorCR をファイル (例:flowcollector-1.5.yaml) に保存します。$ oc get flowcollector cluster -o yaml > flowcollector-1.5.yaml-
「Network Observability Operator のアンインストール」の手順に従って、Operator をアンインストールし、既存の
FlowCollectorCRD を削除します。 - Network Observability Operator の最新バージョン 1.6.0 をインストールします。
-
手順 b で保存したバックアップを使用して
FlowCollectorを作成します。
-
「Network Observability Operator のアンインストール」の手順に従って、Operator をアンインストールし、既存の
検証
以下のコマンドを実行します。
$ oc get crd flowcollectors.flows.netobserv.io -ojsonpath='{.status.storedVersions}'結果のリストには
v1alpha1が表示されなくなり、最新バージョンのv1beta1のみが表示されます。
4.4. Network Observability でのマルチテナンシーの有効化
クラスターロールと namespace ロールを設定して、プロジェクト管理者と開発者に Loki および Prometheus のフローとメトリクスへのきめ細かな制限付きアクセスを許可することで、ネットワークオブザーバビリティーにおけるマルチテナンシーを有効にします。
アクセスはプロジェクト管理者に対して有効になります。一部の namespace だけにアクセスが制限されているプロジェクト管理者は、それらの namespace のフローにのみアクセスできます。
開発者の場合、Loki と Prometheus の両方でマルチテナンシー機能を利用できますが、必要なアクセス権が異なります。
前提条件
- Loki を使用している場合は、少なくとも Loki Operator バージョン 5.7 がインストールされている。
- プロジェクト管理者としてログインしている。
手順
テナントごとのアクセスの場合、Developer パースペクティブを使用するために、
netobserv-loki-readerクラスターロールとnetobserv-metrics-readernamespace ロールを付与する必要があります。このレベルのアクセスを提供するために、次のコマンドを実行します。$ oc adm policy add-cluster-role-to-user netobserv-loki-reader <user_group_or_name>$ oc adm policy add-role-to-user netobserv-metrics-reader <user_group_or_name> -n <namespace>クラスター全体のアクセスの場合、クラスター管理者以外のユーザーに、
netobserv-loki-reader、cluster-monitoring-view、およびnetobserv-metrics-readerクラスターロールを付与する必要があります。この場合、Administrator パースペクティブまたは Developer パースペクティブのいずれかを使用できます。このレベルのアクセスを提供するために、次のコマンドを実行します。$ oc adm policy add-cluster-role-to-user netobserv-loki-reader <user_group_or_name>$ oc adm policy add-cluster-role-to-user cluster-monitoring-view <user_group_or_name>$ oc adm policy add-cluster-role-to-user netobserv-metrics-reader <user_group_or_name>
4.5. Kafka のインストール (オプション)
Kafka Operator は、大規模な環境でサポートされています。Kafka は、回復性とスケーラビリティーの高い方法でネットワークフローデータを転送するために、高スループットかつ低遅延のデータフィードを提供します。
Loki Operator および Network Observability Operator がインストールされたのと同じように、Kafka Operator を Operator Hub から Red Hat AMQ Streams としてインストールできます。Kafka をストレージオプションとして設定する場合は、「Kafka を使用した FlowCollector リソースの設定」を参照してください。
Kafka をアンインストールするには、インストールに使用した方法に対応するアンインストールプロセスを参照してください。
4.6. Network Observability Operator のアンインストール
OpenShift Container Platform Web コンソールの Operator Hub の Ecosystem → Installed Operator 領域で作業し、Network Observability Operator をアンインストールします。
手順
FlowCollectorカスタムリソースを削除します。- Provided APIs 列の Network Observability Operator の横にある Flow Collector をクリックします。
-
cluster の Options メニュー
をクリックし、Delete FlowCollector を選択します。
Network Observability Operator をアンインストールします。
- Ecosystem → Installed Operators 領域に戻ります。
-
Network Observability Operator の隣にある Options メニュー
をクリックし、Uninstall Operator を選択します。
-
Home → Projects を選択し、
openshift-netobserv-operatorを選択します。 - Actions に移動し、Delete Project を選択します。
FlowCollectorカスタムリソース定義 (CRD) を削除します。- Administration → CustomResourceDefinitions に移動します。
-
FlowCollector を探し、Options メニュー
をクリックします。
Delete CustomResourceDefinition を選択します。
重要Loki Operator と Kafka は、インストールされていた場合、残っているため、個別に削除する必要があります。さらに、オブジェクトストアに保存された残りのデータ、および削除する必要がある永続ボリュームがある場合があります。
第5章 OpenShift Container Platform の Network Observability Operator
OpenShift Container Platform の Network Observability Operator は、モニタリングパイプラインをデプロイします。このパイプラインは、eBPF agent によって生成されたネットワークトラフィックフローを収集および拡充します。
5.1. 状況の表示
oc get コマンドを使用して FlowCollector リソースのステータスと、eBPF agent、flowlogs-pipeline、およびコンソールプラグイン Pod のステータスを確認し、Network Observability Operator の動作ステータスを表示します。
Network Observability Operator は Flow Collector API を提供します。Flow Collector リソースが作成されると、Pod とサービスをデプロイしてネットワークフローを作成して Loki ログストアに保存し、ダッシュボード、メトリクス、およびフローを OpenShift Container Platform Web コンソールに表示します。
手順
次のコマンドを実行して、
FlowCollectorの状態を表示します。$ oc get flowcollector/cluster出力例
NAME AGENT SAMPLING (EBPF) DEPLOYMENT MODEL STATUS cluster EBPF 50 DIRECT Ready次のコマンドを実行して、
netobservnamespace で実行している Pod のステータスを確認します。$ oc get pods -n netobserv出力例
NAME READY STATUS RESTARTS AGE flowlogs-pipeline-56hbp 1/1 Running 0 147m flowlogs-pipeline-9plvv 1/1 Running 0 147m flowlogs-pipeline-h5gkb 1/1 Running 0 147m flowlogs-pipeline-hh6kf 1/1 Running 0 147m flowlogs-pipeline-w7vv5 1/1 Running 0 147m netobserv-plugin-cdd7dc6c-j8ggp 1/1 Running 0 147mflowlogs-pipelinePod はフローを収集し、収集したフローをエンリッチさせてから、フローを Loki ストレージに送信します。netobserv-pluginPod は、OpenShift Container Platform コンソール用の可視化プラグインを作成します。次のコマンドを入力して、namespace
netobserv-privilegedで実行している Pod のステータスを確認します。$ oc get pods -n netobserv-privileged出力例
NAME READY STATUS RESTARTS AGE netobserv-ebpf-agent-4lpp6 1/1 Running 0 151m netobserv-ebpf-agent-6gbrk 1/1 Running 0 151m netobserv-ebpf-agent-klpl9 1/1 Running 0 151m netobserv-ebpf-agent-vrcnf 1/1 Running 0 151m netobserv-ebpf-agent-xf5jh 1/1 Running 0 151mnetobserv-ebpf-agentPod は、ノードのネットワークインターフェイスを監視してフローを取得し、それをflowlogs-pipelinePod に送信します。Loki Operator を使用している場合は、次のコマンドを入力して、
netobservnamespace にあるLokiStackカスタムリソースのcomponentPod のステータスを確認します。$ oc get pods -n netobserv出力例
NAME READY STATUS RESTARTS AGE lokistack-compactor-0 1/1 Running 0 18h lokistack-distributor-654f87c5bc-qhkhv 1/1 Running 0 18h lokistack-distributor-654f87c5bc-skxgm 1/1 Running 0 18h lokistack-gateway-796dc6ff7-c54gz 2/2 Running 0 18h lokistack-index-gateway-0 1/1 Running 0 18h lokistack-index-gateway-1 1/1 Running 0 18h lokistack-ingester-0 1/1 Running 0 18h lokistack-ingester-1 1/1 Running 0 18h lokistack-ingester-2 1/1 Running 0 18h lokistack-querier-66747dc666-6vh5x 1/1 Running 0 18h lokistack-querier-66747dc666-cjr45 1/1 Running 0 18h lokistack-querier-66747dc666-xh8rq 1/1 Running 0 18h lokistack-query-frontend-85c6db4fbd-b2xfb 1/1 Running 0 18h lokistack-query-frontend-85c6db4fbd-jm94f 1/1 Running 0 18h
5.2. Network Observablity Operator のアーキテクチャー
Network Observability Operator のアーキテクチャーを確認します。特に、フローを収集して補完し、データをストレージ用として Loki に、またはメトリクス用として Prometheus に送信する eBPF agent を、FlowCollector リソースがどのように管理するか詳しく説明します。
Network Observability Operator は、FlowCollector API を提供します。これは、インストール時にインスタンス化され、eBPF agent、flowlogs-pipeline、netobserv-plugin コンポーネントをリコンサイルするように設定されています。FlowCollector は、クラスターごとに 1 つだけサポートされます。
eBPF agent は、各クラスター上で実行され、ネットワークフローを収集するためのいくつかの権限を持っています。flowlogs-pipeline はネットワークフローデータを受信し、データに Kubernetes 識別子を追加します。Loki を使用することを選択した場合、flowlogs-pipeline はフローログデータを Loki に送信し、保存およびインデックス作成を行います。netobserv-plugin は、動的 OpenShift Container Platform Web コンソールプラグインであり、Loki にクエリーを実行してネットワークフローデータを取得します。クラスター管理者は、Web コンソールでデータを表示できます。
Loki を使用しない場合は、Prometheus を使用してメトリクスを生成できます。これらのメトリクスと関連するダッシュボードには、Web コンソールからアクセスできます。詳細は、"Loki を使用しない Network Observability" を参照してください。
Network Observability Operator には、3 つのデプロイメントモデルの選択肢があります。
Network Observability Operator は、Loki やその他のデータストアを管理しません。Loki Operator を使用して、Loki を別途インストールする必要があります。Kafka を使用する場合は、Kafka Operator を使用して別途インストールする必要があります。
- Service デプロイメントモデル
-
FlowCollectorリソースのspec.deploymentModelフィールドがServiceに設定されている場合、エージェントがノードごとにデーモンセットとしてデプロイされます。flowlogs-pipelineは、サービスを含む標準的なデプロイメントです。spec.processor.consumerReplicasフィールドを使用することで、flowlogs-pipelineコンポーネントをスケーリングできます。 - Direct デプロイメントモデル
-
spec.deploymentModelフィールドがDirectに設定されている場合、エージェントとflowlogs-pipelineが両方ともノードごとにデーモンセットとしてデプロイされます。このモデルは、テクノロジーの評価や小規模なクラスターに適しています。しかし、大規模なクラスターでは、flowlogs-pipelineの各インスタンスが同じクラスター情報をキャッシュするため、メモリー効率が低下します。 - Kafka デプロイメントモデル (オプション)
Kafka 方式を使用する場合、
eBPF agentがネットワークフローデータを Kafka に送信します。spec.processor.consumerReplicasフィールドを使用することで、flowlogs-pipelineコンポーネントをスケーリングできます。flowlogs-pipelineコンポーネントは、次の図に示すように、Kafka トピックからデータを読み取り、その後 Loki にデータを送信します。
5.3. Network Observability Operator のステータスと設定の表示
oc describe flowcollector/cluster コマンドを使用して、Network Observability Operator の現在のステータス、設定の詳細、生成されたリソースを検査します。
手順
次のコマンドを実行して、Network Observability Operator のステータスと設定を表示します。
$ oc describe flowcollector/cluster
第6章 Network Observability Operator の設定
Network Observability Operator を設定するには、クラスター全体の FlowCollector API リソース (クラスター) を更新して、コンポーネント設定とフロー収集設定を管理します。
FlowCollector はインストール中に明示的に作成されます。このリソースはクラスター全体で動作するため、単一の FlowCollector のみが許可され、cluster という名前を付ける必要があります。詳細は、「FlowCollector API リファレンス」を参照してください。
6.1. FlowCollector リソースの表示
統合されたセットアップや詳細フォームを介して、または YAML を直接編集して Network Observability Operator を設定することで、OpenShift Container Platform Web コンソールで FlowCollector リソースを表示および変更します。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
-
cluster を選択し、YAML タブを選択します。そこで、
FlowCollectorリソースを変更して Network Observability Operator を設定できます。
6.1.1. FlowCollector リソースの例
eBPF サンプリング、会話トラッキング、Loki の統合、コンソールのクイックフィルターの設定を示す、包括的な注釈付きの FlowCollector カスタムリソースの例を確認してください。
6.1.1.1. FlowCollector リソースのサンプル
apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
name: cluster
spec:
namespace: netobserv
deploymentModel: Service
networkPolicy:
enable: true
agent:
type: eBPF
ebpf:
sampling: 50
privileged: false
features: []
processor:
addZone: false
subnetLabels:
openShiftAutoDetect: true
customLabels: []
consumerReplicas: 3
loki:
enable: true
mode: LokiStack
lokiStack:
name: loki
namespace: netobserv-loki
consolePlugin:
enable: true
exporters: []各項目の説明:
spec.agent.type-
eBPFを使用する必要があります。eBPF は OpenShift Container Platform でサポートされている唯一の選択肢であるためです。 spec.agent.ebpf.sampling-
サンプリング間隔を指定します。デフォルトでは、eBPF サンプリングは
50に設定されているため、パケットがサンプリングされる確率は 50 分の 1 になります。サンプリング間隔の値が小さいほど、より多くの計算、メモリー、およびストレージリソースが必要になります。値が0または1の場合は、すべてのパケットがサンプリングされます。デフォルト値から始めて、実験結果を基に調整し、クラスターに最適な設定を決定することを推奨します。 spec.agent.ebpf.privileged- eBPF エージェント Pod を特権モードで実行するかどうかを指定します。デフォルト以外のネットワークの監視やパケットドロップのトラッキングなど、いくつかの機能を利用するには、特権ユーザーとして実行する必要があります。セキュリティー上の理由から、最小特権の原則に従い、この設定はそれらの機能のいずれかが必要な場合にのみ有効にしてください。特権モードを必要とする機能を、明示的に true に設定せずに有効にした場合、警告が表示されます。
spec.processor.addZone- ネットワークフローにクラウドアベイラビリティーゾーンを注入するために使用されます。
spec.processor.subnetLabels- CIDR マッチングに基づいてネットワークフローに注入するカスタマイズされたラベルのリストを指定します。
spec.processor.consumerReplicas- プロセッサー Pod (flowlogs-pipeline) のレプリカ数を指定します。「リソース管理およびパフォーマンスに関する考慮事項」セクションで、クラスターサイズに基づく推奨値を参照してください。
spec.loki.mode-
Loki への接続設定方法を、インストールモードに応じて指定します。「Loki Operator のインストール」で説明されているインストールパスを使用する場合は、モードは
LokiStackに設定する必要があり、spec.loki.lokiStackはインストールされたLokiStackリソースの名前と namespace を参照する必要があります。 spec.loki.lokistack.namespace-
LokiStackリソースの namespace を指定します。この値は、LokiStackカスタムリソースで定義されているmetadata.namespaceと一致する必要があります。この例ではnetobserv-lokiを使用していますが、コンポーネントごとに異なる namespace を使用することも可能です。
6.2. Kafka を使用した FlowCollector リソースの設定
高スループットかつ低遅延のデータフィードを実現するために、Kafka を使用するように FlowCollector リソースを設定します。
実行中の Kafka インスタンスを用意し、そのインスタンス内に OpenShift Container Platform Network Observability 専用の Kafka トピックを作成する必要があります。詳細は、AMQ Streams を使用した Kafka ドキュメント を参照してください。
前提条件
- Kafka のインストールが完了している。Red Hat は、AMQ Streams Operator を使用する Kafka をサポートしています。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- Network Observability Operator の Provided APIs という見出しの下で、Flow Collector を選択します。
- クラスターを選択し、YAML タブをクリックします。
次のサンプル YAML に示すように、Kafka を使用するように OpenShift Container Platform Network Observability Operator の
FlowCollectorリソースを変更します。FlowCollectorリソースの Kafka 設定のサンプルapiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: deploymentModel: Kafka kafka: address: "kafka-cluster-kafka-bootstrap.netobserv" topic: network-flows tls: enable: false各項目の説明:
spec.deploymentModel-
デプロイメントモデルを指定します。Kafka デプロイメントモデルを有効にするには、
ServiceではなくKafkaに設定してください。 spec.kafka.address-
Kafka ブートストラップサーバーのアドレスを指定します。ポート 9093 で TLS を使用するため、
kafka-cluster-kafka-bootstrap.netobserv:9093など、必要に応じてポートを指定できます。 spec.kafka.topic- Kafka で作成したトピックの名前を指定します。Kafka で作成したトピック名と同じである必要があります。
spec.kafka.tls-
通信の暗号化を指定します。Kafka との間の通信を TLS または mTLS ですべて暗号化するには、この設定を使用します。有効にする場合、Kafka CA 証明書が、
flowlogs-pipelineプロセッサーコンポーネントをデプロイする namespace (デフォルト:netobserv) と、eBPF エージェントをデプロイする namespace (デフォルト:netobserv-privileged) の両方で、ConfigMap または Secret として利用可能である必要があります。証明書を参照するには、spec.kafka.tls.caCertを使用します。mTLS を使用する場合は、これらの namespace でクライアントシークレットも利用できるようにしてください。シークレットは、Red Hat AMQ Streams User Operator を使用して生成できます。シークレットを参照するには、spec.kafka.tls.userCertを使用します。
6.3. エンリッチされたネットワークフローデータのエクスポート
FlowCollector リソースを設定して、補完されたネットワークフローデータを Kafka、IPFIX、または OpenTelemetry エンドポイントに同時にエクスポートし、Splunk や Prometheus などのツールによる外部使用を可能にします。
Kafka または IPFIX の場合、Splunk、Elasticsearch、Fluentd など、Kafka または IPFIX の入力をサポートするプロセッサーまたはストレージで、エンリッチされたネットワークフローデータを利用できます。
OpenTelemetry の場合、ネットワークフローデータとメトリクスを、Red Hat build of OpenTelemetry、Prometheus など、互換性のある OpenTelemetry エンドポイントにエクスポートできます。
設定後、ネットワークフローデータを利用可能な出力先に送信できます。詳細は、「ネットワークフロー形式のリファレンス」を参照してください。
前提条件
-
Network Observability の
flowlogs-pipelinePod から、Kafka、IPFIX、または OpenTelemetry コレクターエンドポイントを利用できる。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
FlowCollectorを編集して、spec.exportersを次のように設定します。apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: exporters: - type: Kafka kafka: address: "kafka-cluster-kafka-bootstrap.netobserv" topic: netobserv-flows-export tls: enable: false - type: IPFIX ipfix: targetHost: "ipfix-collector.ipfix.svc.cluster.local" targetPort: 4739 transport: tcp - type: OpenTelemetry openTelemetry: targetHost: my-otelcol-collector-headless.otlp.svc targetPort: 4317 type: grpc logs: enable: true metrics: enable: true prefix: netobserv pushTimeInterval: 20s expiryTime: 2m # fieldsMapping: # input: SrcAddr # output: source.address各項目の説明:
spec.exporters.type-
エクスポートのタイプを指定します。フローを
IPFIX、OpenTelemetry、およびKafkaに個別または同時にエクスポートできます。 spec.exporters.kafka.topic- Network Observability Operator がすべてのフローをエクスポートする Kafka トピックを指定します。
spec.exporters.kafka.tls.enable-
Kafka との間の通信を SSL/TLS または mTLS のどちらで暗号化するかを指定します。有効にする場合、Kafka CA 証明書が、
flowlogs-pipelineプロセッサーコンポーネントがデプロイされている namespace (デフォルト:netobserv) で、ConfigMapまたはSecretとして利用可能である必要があります。証明書を参照するには、spec.exporters.tls.caCertを使用します。mTLS の場合は、クライアントシークレットもこれらの namespace で利用可能であり、spec.exporters.tls.userCertを使用して参照する必要があります。 spec.exporters.ipfix.transport-
トランスポートプロトコルを指定します。デフォルト値は
tcpですが、udpを指定することもできます。 spec.exporters.openTelemetry.type-
OpenTelemetry 接続プロトコルを指定します。使用可能なオプションは
httpとgrpcです。 spec.exporters.openTelemetry.logs- ログをエクスポートするための OpenTelemetry 設定を指定します。エクスポートされるログは、Loki 用に作成されるログと同一です。
spec.exporters.openTelemetry.metrics-
メトリクスをエクスポートするための OpenTelemetry 設定を指定します。エクスポートされるメトリクスは、Prometheus 用に作成されるメトリクスと同一です。メトリクスは、
FlowCollectorリソースのspec.processor.metrics.includeListパラメーター、またはFlowMetricsリソースで定義されます。 spec.exporters.openTelemetry.metrics.pushTimeInterval- OpenTelemetry コレクターにメトリクスを送信する時間間隔を指定します。
spec.exporters.openTelemetry.fieldsMapping-
OpenTelemetry 形式の出力をカスタマイズするためのマッピングを必要に応じて指定します。Network Observability のフロー形式は、OpenTelemetry 準拠の形式に自動的に名前が変更されますが、このパラメーターを使用すると、カスタムオーバーライドが可能になります。たとえば、YAML サンプルでは、
SrcAddrが Network Observability の入力フィールドです。これは、OpenTelemetry の出力ではsource.addressに名前が変更されます。「ネットワークフローの形式リファレンス」で、Network Observability の形式と OpenTelemetry の形式の両方を確認できます。
6.4. FlowCollector リソースの更新
Web コンソールを使用する代わりに、flowcollector カスタムリソースで oc patch コマンドを使用して、eBPF サンプリングなどの特定の仕様を迅速に更新します。
手順
次のコマンドを実行して、
flowcollectorCR にパッチを適用し、spec.agent.ebpf.sampling値を更新します。$ oc patch flowcollector cluster --type=json -p "[{"op": "replace", "path": "/spec/agent/ebpf/sampling", "value": <new value>}] -n netobserv"
6.5. ネットワークフロー取り込み時のフィルタリング
生成されるネットワークフローの数を減らすためにフィルターを作成します。ネットワークフローをフィルタリングすると、Network Observability コンポーネントのリソース使用量を削減できます。
次の 2 種類のフィルターを設定できます。
- eBPF エージェントフィルター
- flowlogs-pipeline フィルター
6.5.1. eBPF エージェントフィルター
eBPF エージェントフィルターはパフォーマンスを最大化します。このフィルターは、ネットワークフロー収集プロセスの最も早い段階で有効になるためです。
Network Observability Operator を使用して eBPF エージェントフィルターを設定するには、「複数のルールを使用した eBPF フローデータのフィルタリング」を参照してください。
6.5.2. flowlogs-pipeline フィルター
flowlogs-pipeline フィルターでは、トラフィックの選択をより細かく制御できます。このフィルターは、ネットワークフロー収集プロセスの遅い段階で有効になるためです。これは主にデータの保存を改善するために使用されます。
flowlogs-pipeline フィルターは、次の例に示すように、単純なクエリー言語を使用してネットワークフローをフィルタリングします。
(srcnamespace="netobserv" OR (srcnamespace="ingress" AND dstnamespace="netobserv")) AND srckind!="service"クエリー言語では次の構文を使用します。
| カテゴリー | 演算子 |
|---|---|
| 論理ブール演算子 (大文字と小文字の区別なし) |
|
| 比較演算子 |
|
| 単項演算子 |
|
flowlogs-pipeline フィルターは、FlowCollector リソースの spec.processor.filters セクションで設定できます。以下に例を示します。
flowlogs-pipeline フィルターの YAML の例
apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
name: cluster
spec:
namespace: netobserv
agent:
processor:
filters:
- query: |
(SrcK8S_Namespace="netobserv" OR (SrcK8S_Namespace="openshift-ingress" AND DstK8S_Namespace="netobserv"))
outputTarget: Loki
sampling: 10各項目の説明:
spec.processor.filters.outputTarget-
条件に一致したフローの出力先を指定します。出力先は、
Loki、Prometheus、または外部システムなどです。このパラメーターを省略すると、設定されているすべての出力にフローが送信されます。 spec.processor.filters.sampling-
保存またはエクスポートする一致したフローの数を制限するために、サンプリング間隔を必要に応じて指定します。たとえば、
10という値は、フローが保存される確率が 10 分の 1 であることを意味します。
6.6. クイックフィルターの設定
使用可能なソース、宛先、ユニバーサルフィルターキーのリストを使用して、FlowCollector リソース内のクイックフィルターを変更します。
値を二重引用符で囲むと、完全一致が可能になります。それ以外の場合、テキスト値には部分一致が使用されます。キーの最後にあるバング (!) 文字は、否定を意味します。YAML の変更に関する詳細なコンテキストは、サンプルの FlowCollector リソースを参照してください。
フィルターマッチングタイプ "all of" または "any of" は、ユーザーがクエリーオプションから変更できる UI 設定です。これは、このリソース設定の一部ではありません。
使用可能なすべてのフィルターキーのリストを次に示します。
| Universal* | ソース | 送信先 | 説明 |
|---|---|---|---|
| namespace |
|
| 特定の namespace に関連するトラフィックをフィルタリングします。 |
| name |
|
| 特定の Pod、サービス、またはノード (ホストネットワークトラフィックの場合) など、特定のリーフリソース名に関連するトラフィックをフィルター処理します。 |
| kind |
|
| 特定のリソースの種類に関連するトラフィックをフィルタリングします。リソースの種類には、リーフリソース (Pod、Service、または Node)、または所有者リソース (Deployment および StatefulSet) が含まれます。 |
| owner_name |
|
| 特定のリソース所有者に関連するトラフィックをフィルタリングします。つまり、ワークロードまたは Pod のセットです。たとえば、Deployment 名、StatefulSet 名などです。 |
| resource |
|
|
一意に識別する正規名で示される特定のリソースに関連するトラフィックをフィルタリングします。正規の表記法は、namespace の種類の場合は |
| address |
|
| IP アドレスに関連するトラフィックをフィルタリングします。IPv4 と IPv6 がサポートされています。CIDR 範囲もサポートされています。 |
| mac |
|
| MAC アドレスに関連するトラフィックをフィルタリングします。 |
| port |
|
| 特定のポートに関連するトラフィックをフィルタリングします。 |
| host_address |
|
| Pod が実行しているホスト IP アドレスに関連するトラフィックをフィルタリングします。 |
| protocol | 該当なし | 該当なし | TCP や UDP などのプロトコルに関連するトラフィックをフィルタリングします。 |
-
ソースまたは宛先のいずれかのユニバーサルキーフィルター。たとえば、フィルタリング
name: 'my-pod'は、使用される一致タイプ (Match all または Match any) に関係なく、my-podからのすべてのトラフィックとmy-podへのすべてのトラフィックを意味します。
6.7. リソース管理およびパフォーマンスに関する考慮事項
パフォーマンス基準を管理し、ネットワークオブザーバビリティーのためのリソース消費を最適化するために必要な、eBPF サンプリング、機能の有効化、リソース制限などの重要な設定を確認します。
Network Observability に必要なリソースの量は、クラスターのサイズと、クラスターがオブザーバビリティーデータを取り込んで保存するための要件によって異なります。リソースを管理し、クラスターのパフォーマンス基準を設定するには、次の設定を設定することを検討してください。これらの設定を行うことにより、最適なセットアップとオブザーバビリティーのニーズを満たすことができる可能性があります。
次の設定は、最初からリソースとパフォーマンスを管理するのに役立ちます。
- eBPF サンプリング
-
サンプリング仕様
spec.agent.ebpf.samplingを設定して、リソースを管理できます。デフォルトでは、eBPF サンプリングは50に設定されているため、フローがサンプリングされる確率は 50 分の 1 になります。サンプリング間隔の値が小さいほど、より多くの計算、メモリー、およびストレージリソースが必要になります。値が0または1の場合、すべてのフローがサンプリングされます。デフォルト値から始めて、実験結果を基に調整し、クラスターに最適な設定を決定することを推奨します。 - eBPF の機能
- 有効にされた機能が増えるほど、CPU とメモリーへの影響が大きくなります。該当する機能の完全なリストは、"ネットワークトラフィックのモニタリング" を参照してください。
- Loki を使用しない場合
- Loki ではなく Prometheus を代わりに使用することで、Network Observability に必要なリソースの量を削減できます。たとえば、Network Observability を Loki なしで設定すると、サンプリング間隔の値に応じて、メモリー使用量が合計で 20 - 65% 削減され、CPU 使用率が 10 - 30% 低下します。詳細は、「Loki を使用しないネットワークオブザーバビリティー」を参照してください。
- インターフェイスの制限または除外
-
spec.agent.ebpf.interfacesおよびspec.agent.ebpf.excludeInterfacesの値を設定して、観測されるトラフィック全体を削減します。デフォルトでは、エージェントは、excludeInterfacesおよびlo(ローカルインターフェイス) にリストされているインターフェイスを除く、システム内のすべてのインターフェイスを取得します。インターフェイス名は、使用される Container Network Interface (CNI) によって異なる場合があることに注意してください。 - パフォーマンスのファインチューニング
Network Observability をしばらく実行した後、次の設定を使用してパフォーマンスを微調整できます。
-
リソース要件と制限:
spec.agent.ebpf.resourcesおよびspec.processor.resources仕様を使用して、クラスターで予想される負荷とメモリー使用量に合わせてリソース要件と制限を調整します。多くの中規模のクラスターには、デフォルトの制限の 800MB で十分な場合があります。 -
キャッシュの最大フロータイムアウト: eBPF エージェントの
spec.agent.ebpf.cacheMaxFlowsおよびspec.agent.ebpf.cacheActiveTimeout仕様を使用して、エージェントによってフローが報告される頻度を制御します。値が大きいほど、エージェントで生成されるトラフィックが少なくなり、これは CPU 負荷の低下と相関します。ただし、値を大きくするとメモリー消費量がわずかに増加し、フロー収集でより多くの遅延が発生する可能性があります。
-
リソース要件と制限:
6.7.1. リソースの留意事項
Network Observability Operator の設定は、クラスターのワークロードのサイズに基づいて調整できます。以下のベースラインの例を使用して、環境に適したリソース制限と設定を決定してください。
表に概要を示した例は、特定のワークロードに合わせて調整されたシナリオを示しています。各例は、ワークロードのニーズに合わせて調整を行うためのベースラインとしてのみ考慮してください。
これらの推奨値の導出に使用されたテスト環境は以下のとおりです。
-
極小規模: 10 ノードのクラスター、ワーカーあたり 4 つの仮想 CPU と 16 GiB のメモリー、
LokiStackのサイズは1x.extra-small、AWS M6i インスタンスでテスト済み。 -
小規模: 25 ノードのクラスター、ワーカーあたり 16 個の仮想 CPU と 64 GiB のメモリー、
LokiStackのサイズは1x.small、AWS M6i インスタンスでテスト済み。 -
大規模: 250 ノードのクラスター、ワーカーあたり 16 個の仮想 CPU と 64 GiB のメモリー、
LokiStackのサイズは1x.medium、AWS M6i インスタンスでテスト済み。ワーカーノードとコントローラーノードに加えて、3 つのインフラストラクチャーノード (サイズM6i.12xlarge) と 1 つのワークロードノード (サイズM6i.8xlarge) がテストされました。
| 基準 | 極小規模 (10 ノード) | 小規模 (25 ノード) | 大規模 (250 ノード) |
|---|---|---|---|
|
Operator のメモリー制限: |
|
|
|
|
eBPF エージェントのサンプリング間隔: |
|
|
|
|
eBPF エージェントのメモリー制限: |
|
|
|
|
eBPF エージェントのキャッシュサイズ: |
|
|
|
|
プロセッサーのメモリー制限: |
|
|
|
|
Processor replicas: |
|
|
|
|
Deployment model: |
|
|
|
| Kafka パーティション: Kafka のインストール | 該当なし |
|
|
| Kafka ブローカー: Kafka のインストール | 該当なし |
|
|
6.7.2. メモリーと CPU の合計平均使用量
異なる eBPF サンプリング値を使用した 2 つの異なるトラフィックシナリオ (Test 1 と Test 2) における、ネットワークオブザーバビリティーコンポーネントの CPU およびメモリーの合計平均使用量を詳しく示した表について説明します。
次の表は、2 つの異なるテスト (Test 1、Test 2) について、サンプリング値が 1 および 50 であるクラスターの合計リソース使用量の平均を示しています。テストは次の点で異なります。
-
Test 1は、OpenShift Container Platform クラスター内の namespace、Pod、およびサービスの合計数に加え、大量の Ingress トラフィックを考慮しており、eBPF エージェントに負荷をかけた、特定のクラスターサイズに対して多数のワークロードが発生するユースケースを表しています。たとえば、Test 1は、76 個の namespace、5153 個の Pod、および 2305 個のサービスで構成され、ネットワークトラフィックの規模は ~350 MB/秒です。 -
Test 2は、OpenShift Container Platform クラスター内の namespace、Pod、およびサービスの合計数に加え、大量の Ingress トラフィックを考慮しており、特定のクラスターサイズに対して多数のワークロードが発生するユースケースを表しています。たとえば、Test 2は、553 個の namespace、6998 個の Pod、および 2508 個のサービスで構成され、ネットワークトラフィックの規模は ~950 MB/秒です。
さまざまなテストでさまざまなタイプのクラスターユースケースが例示されているため、この表の数値は並べて比較しても直線的に増加しません。代わりに、これらは個人のクラスター使用状況を評価するためのベンチマークとして使用することを目的としています。表に概要を示した例は、特定のワークロードに合わせて調整されたシナリオを示しています。各例は、ワークロードのニーズに合わせて調整を行うためのベースラインとしてのみ考慮してください。
Prometheus にエクスポートされたメトリクスは、リソースの使用状況に影響を与える可能性があります。メトリクスのカーディナリティー値は、リソースがどの程度影響を受けるかを判断するのに役立ちます。詳細は、関連情報セクションの「ネットワークフローの形式」を参照してください。
| サンプリング値 | 使用されるリソース | テスト 1 (25 ノード) | テスト 2 (250 ノード) |
|---|---|---|---|
| Sampling = 50 | NetObserv の CPU 合計使用量 | 1.35 | 5.39 |
| NetObserv RSS (メモリー) の合計使用量 | 16 GB | 63 GB | |
| Sampling = 1 | NetObserv の CPU 合計使用量 | 1.82 | 11.99 |
| NetObserv RSS (メモリー) の合計使用量 | 22 GB | 87 GB |
概要: この表は、すべての機能が有効になっているエージェント、FLP、Kafka、Loki を含む Network Observability の平均合計リソース使用量を示しています。有効な機能の詳細は、「ネットワークトラフィックの観測」で説明されている機能を参照してください。このテストで有効になっているすべての機能が記載されています。
第7章 テナントごとのネットワークオブザーバビリティーモデル
FlowCollectorSlice リソースを使用すると、クラスター全体のガバナンスを維持しながら、ネットワークトラフィック分析の管理をプロジェクト管理者に委譲できます。
7.1. テナントごとの階層型ガバナンスとテナントの自律性
クラスター管理者は、特定の namespace 内におけるネットワークトラフィックのオブザーバビリティーの管理をプロジェクト管理者に許可しつつ、クラスター全体のガバナンスを維持することができます。
Network Observability Operator では、階層型設定モデルを使用してマルチテナンシーをサポートしています。このアーキテクチャーは、大規模なデプロイメントや Hosted Control Plane 環境において、個々のチームがクラスター管理者の介入なしにセルフサービスで可視性を確保する必要がある場合に役立ちます。
階層型モデルは以下の構成要素から成ります。
- グローバルガバナンス
-
クラスター管理者は、グローバルな
FlowCollectorリソースを管理します。このリソースでは、オブザーバビリティーのインフラストラクチャーを定義し、テナントごとの設定を許可するかどうかを決定します。 - テナントの自律性
-
プロジェクト管理者は、
FlowCollectorSliceリソースを管理します。この namespace スコープのカスタムリソース (CR) を使用することで、チームが各自のワークロードに対して特定のオブザーバビリティー設定を定義できるようになります。
7.2. きめ細かなフロー収集のための FlowCollectorSlice リソース
FlowCollectorSlice は、きめ細かなマルチテナントのネットワークフロー収集を可能にするカスタムリソース定義 (CRD) です。namespace やサブネットに基づいて論理的なスライスを定義することで、トラフィックを選択的に収集し、クラスター全体ではなく特定のワークロードに対してカスタムのサンプリングを適用できます。
これは、既存の FlowCollector カスタムリソースを補完するものです。すべてのトラフィックに一律に適用される単一のグローバル設定ではなく、きめ細かく、選択的で、マルチテナントに対応したフロー収集を可能にします。
スライスベースの収集が有効な場合、少なくとも 1 つの FlowCollectorSlice に一致するトラフィックのみが収集されます。そのため、管理者は観測対象のネットワークフローを正確に制御できます。
7.2.1. FlowCollectorSlice の利点
デフォルトでは、ネットワークフロー収集はクラスター内のすべてのトラフィックに一律に適用されます。これにより、データ量が過剰になり、柔軟性が制限される可能性があります。
FlowCollectorSlice を使用することで、以下の利点が得られます。
- 特定の namespace またはワークロードに対する選択的なフロー収集を可能にします。
- マルチテナントおよび環境ベースのオブザーバビリティーをサポートします。
- 不要なトラフィックをフィルタリングすることで、ストレージと処理のコストを削減します。
- オプトイン方式の設定により、下位互換性を維持します。
7.2.2. FlowCollector と FlowCollectorSlice の関係
FlowCollector リソースは、クラスター全体のフロー収集動作を定義するものです。一方、FlowCollectorSlice リソースは、スライスベースのフィルタリングが有効な場合に、収集対象とするトラフィックを定義するものです。
FlowCollector.spec.slicesConfig フィールドは、スライス定義の適用方法を制御します。
7.2.3. 収集モード
スライスの動作は、FlowCollector.spec.slicesConfig.collectionMode フィールドによって制御されます。このフィールドを以下のいずれかの収集モードに設定してください。
- AlwaysCollect
- すべてのクラスター namespace からネットワークフローを収集します。
-
FlowCollectorSliceリソースで定義されているサブネットおよびサンプリング設定を適用します。 -
FlowCollectorSliceリソース内の namespace 選択ロジックを無視します。 - 後方互換性のために、デフォルトの収集動作を維持します。
- AllowList
-
少なくとも 1 つの
FlowCollectorSliceリソースに一致するトラフィックのみを収集します。 - 必要に応じて、namespace 許可リストを使用すると、選択した namespace を収集対象に含めることができます。
-
少なくとも 1 つの
7.2.4. FlowCollectorSlice status
各 FlowCollectorSlice リソースは、以下の情報を報告する status サブリソースを公開します。
- 検証結果
- リコンシリエーションの状態
- スライスが正常に適用されたかどうか
このステータスにより、管理者はスライス定義がアクティブであり、期待どおりに機能していることを確認できます。
7.3. Network Observability Operator FlowCollectorSlice の有効化
FlowCollector リソースで FlowCollectorSlice 機能を有効にすると、クラスター管理者はフロー収集とデータエンリッチメントの管理を特定の namespace に委譲できるようになります。
プロジェクト管理者が自身の設定を管理できるようになる前に、クラスター管理者は FlowCollector カスタムリソースを有効にして、FlowCollectorSlice カスタムリソースを監視するように設定する必要があります。
前提条件
- Network Observability Operator がインストールされている。
-
クラスター内に
FlowCollectorカスタムリソースが存在する。 -
cluster-admin特権を持っている。
手順
以下のコマンドを実行して、
FlowCollectorカスタムリソースを編集します。$ oc edit flowcollector clusterspec.processor.slicesConfigフィールドを設定して、スライスの使用を許可する namespace を定義します。apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: processor: slicesConfig: enable: true collectionMode: AllowList namespacesAllowList: - /openshift-.*|netobserv.*/各項目の説明:
spec.processor.sliceConfig.enable-
FlowCollectorSlice機能が有効にするかどうかを指定します。有効でない場合、kind がFlowCollectorSliceのリソースはすべて無視されます。 spec.processor.sliceConfig.collectionMode-
FlowCollectorSliceカスタムリソースがフロー収集プロセスにどのように影響するかを指定します。AlwaysCollectに設定すると、FlowCollectorSliceの有無に関わらず、すべてのフローが収集されます。AllowListに設定すると、FlowCollectorSliceリソースが存在する namespace、またはグローバルのnamespacesAllowListで設定されている namespace に関連するフローのみが収集されます。 spec.processor.sliceConfig.namespacesAllowListFlowCollectorSliceの有無にかかわらず、常にフローの収集対象とする namespace のリストを指定します。注記namespacesAllowListフィールドは、複数の namespace を収集対象とするための/openshift-.*/のような正規表現や、特定の namespace を一致させるためのnetobservのような完全一致をサポートしています。
- 変更を保存し、エディターを終了します。
検証
-
Web コンソールの Network Traffic ページに、
netobservnamespace とopenshift-で始まる namespace からのネットワークフローのみが表示されることを確認します。
7.3.1. Network Observability Operator FlowCollectorSlice の無効化
Network Observability Operator でスライスベースのフィルタリングを無効にすると、既存の FlowCollectorSlice リソースを保持したまま、クラスター全体のフロー収集を再開できます。
手順
以下のコマンドを実行して、
FlowCollectorリソースを編集します。$ oc edit flowcollector clusterspec.processor.slicesConfig.collectionModeフィールドをAlwaysCollectに設定します。apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: processor: slicesConfig: enable: true collectionMode: AlwaysCollect ...変更を保存します。
すべてのトラフィックに対するフロー収集が再開されます。既存の
FlowCollectorSliceリソースは、将来の使用に備えてそのまま保持されます。
7.4. FlowCollectorSlice をプロジェクト管理者として設定する
プロジェクト管理者は、分散型のネットワークトラフィック分析を行うための FlowCollectorSlice カスタムリソースを設定することで、自身の namespace 内でフロー収集とデータエンリッチメントを管理できます。
前提条件
- Network Observability Operator がインストールされている。
-
namespace の
project-admin権限を持っている。
手順
flowCollectorSlice.yamlという名前の YAML ファイルを作成します。apiVersion: flows.netobserv.io/v1alpha1 kind: FlowCollectorSlice metadata: name: flowcollectorslice-sample namespace: my-app spec: sampling: 1 subnetLabels: - name: EXT:Database cidrs: - 192.168.50.0/24以下のコマンドを実行して設定を適用します。
$ oc apply -f flowCollectorSlice.yaml
検証
- OpenShift Container Platform コンソールで、Observe → Network Traffic に移動します。
-
EXT:Databaseラベルを使用して、192.168.50.0/24サブネットへのフローが観測されていることを確認します。
7.5. FlowCollectorSlice [flows.netobserv.io/v1alpha1]
- 説明
- FlowCollectorSlice は、FlowCollector の設定の一部を namespace テナントごとに分散させることができる API です。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| APIVersion はオブジェクトのこの表現のバージョンスキーマを定義します。サーバーは認識されたスキーマを最新の内部値に変換し、認識されない値は拒否することがあります。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources を参照してください。 |
|
|
| kind はこのオブジェクトが表す REST リソースを表す文字列の値です。サーバーは、クライアントが要求を送信するエンドポイントからこれを推測できることがあります。これを更新することはできません。CamelCase を使用します。詳細: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds |
|
|
| 標準オブジェクトのメタデータ。詳細: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata |
|
|
| FlowCollectorSliceSpec は、FlowCollectorSlice の望ましい状態を定義します。 |
7.5.1. .metadata
- 説明
- 標準オブジェクトのメタデータ。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata を参照してください。
- 型
-
object
7.5.2. .spec
- 説明
- FlowCollectorSliceSpec は、FlowCollectorSlice の望ましい状態を定義します。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
FlowCollectorSlice で設定されたサブネットラベルは、関連する namespace のフローに限定されないことに注意してください。この設定を使用すると、クラスター全体の任意のフローにラベルを付けることができます。ただし、ルールが競合する場合は、クラスタースコープの FlowCollector で定義されたサブネットラベルが優先されます。 |
7.5.3. .spec.subnetLabels
- 説明
subnetLabelsを使用すると、クラスター外部のワークロードや Web サービスを識別するために、サブネットと IP のラベル付けをカスタマイズすることができます。デフォルトのクイックフィルターや提供されているサンプルメトリクスと連携して動作させるには、外部サブネットにEXT:というプレフィックスを付けてラベル付けするか、一切ラベル付けしないでおく必要があります。
FlowCollectorSlice で設定されたサブネットラベルは、関連する namespace のフローに限定されないことに注意してください。この設定を使用すると、クラスター全体の任意のフローにラベルを付けることができます。ただし、ルールが競合する場合は、クラスタースコープの FlowCollector で定義されたサブネットラベルが優先されます。
- 型
-
array
7.5.4. .spec.subnetLabels[]
- 説明
- SubnetLabel を使用すると、クラスター外部のワークロードや Web サービスの識別などのために、サブネットと IP にラベルを付けることができます。
- 型
-
object - 必須
-
cidrs -
name
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
マッチしたフローにフラグを設定するために使用するラベル名。デフォルトのクイックフィルターや提供されているサンプルメトリクスと連携して動作させるには、外部サブネットに |
第8章 ネットワークポリシー
管理者は、netobserv namespace 用のネットワークポリシーを作成できます。このポリシーにより、Network Observability Operator への受信および送信アクセスを保護します。
8.1. FlowCollector カスタムリソースを使用したネットワークポリシーの設定
Pod のトラフィックを制御するために、Ingress および Egress ネットワークポリシーを設定できます。これにより、セキュリティーが強化され、必要なネットワークフローデータだけが収集されます。これにより、ノイズが削減され、コンプライアンスがサポートされるとともに、ネットワーク通信に対する可視性が向上します。
FlowCollector カスタムリソース (CR) を設定することで、Network Observability 用の Egress および Ingress ネットワークポリシーをデプロイできます。デフォルトでは、spec.NetworkPolicy.enable 仕様は true に設定されています。
ネットワークポリシーを持つ別の namespace に Loki、Kafka、または任意のエクスポーターをインストールした場合は、Network Observability コンポーネントがそれらと通信できることを確認する必要があります。セットアップについて、次の点を考慮してください。
-
Loki への接続 (
FlowCollectorCR のspec.lokiパラメーターで定義) -
Kafka への接続 (
FlowCollectorCR のspec.kafkaパラメーターで定義) -
任意のエクスポーターへの接続 (FlowCollector CR の
spec.exportersパラメーターで定義) -
Loki を使用していて、Loki をポリシーターゲットに含める場合は、外部オブジェクトストレージへの接続 (
LokiStack関連のシークレットで定義)
手順
- Web コンソールで、Ecosystem → Installed Operators ページに移動します。
- Network Observability の Provided APIs という見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
FlowCollectorCR を設定します。設定例は次のとおりです。ネットワークポリシー用の
FlowCollectorCR の例apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: namespace: netobserv networkPolicy: enable: true additionalNamespaces: ["openshift-console", "openshift-monitoring"] # ...各項目の説明:
spec.networkPolicy.enable-
ネットワークポリシー管理を有効にするかどうかを指定します。デフォルト値は
trueです。 spec.networkPolicy.additionalNamespaces-
ネットワークポリシーの対象とする namespace を指定します。デフォルト値は
["openshift-console", "openshift-monitoring"]です。
第9章 ネットワークオブザーバビリティーの DNS 解決分析
DNS 解決分析が eBPF ベースのデコードを使用してサービス検出の問題を特定する仕組みを理解し、FlowCollector リソースで DNS トラッキングを有効にして、ネットワークフローレコードにドメイン名を付加する手順を実行してください。
9.1. DNS 解決分析の戦略的利点
DNS 解決分析は、eBPF フローレコードにドメイン名とステータスコードを付加し、ネットワーク伝送障害とサービス検出の問題を区別するために使用します。
標準のフローログには、ポート 53 でトラフィックが発生したことしか記録されません。DNS 解決分析を使用すると、次のタスクを実行できます。
-
平均検知時間 (MTTI) の短縮: ネットワークルーティングの障害と、
NXDOMAINエラーなどの DNS 解決の障害を即座に区別します。 -
内部サービスの遅延の測定: CoreDNS が特定の内部ルックアップ (例:
my-service.namespace.svc.cluster.local) に応答するのにかかる時間を追跡します。 - 外部依存関係の監査: サイドカーや手動パケットキャプチャーを必要とせずに、ワークロードがどの外部 API またはサードパーティードメインと通信しているかを監査します。
- セキュリティー体制の強化: 内部ワークロードによって照会される完全修飾ドメイン名 (FQDN) を監査することで、潜在的なデータ漏洩やコマンドアンドコントロール (C2) アクティビティーを検出します。
9.1.1. DNS フローのエンリッチメント
この機能が有効な場合、eBPF エージェントによりフローレコードがエンリッチされます。このメタデータを使用すると、単なる送信元 IP アドレスによってではなく、接続の意図 (ドメイン) に基づいてトラフィックをグループ化およびフィルタリングできます。
拡張された DNS デコードにより、eBPF エージェントは、DNS リクエストのクエリー名とともに、ポート 53 上の UDP および TCP の DNS トラフィックを検査できるようになります。
9.2. ネットワークオブザーバビリティーの DNS ドメイントラッキングの設定
Network Observability Operator で DNS トラッキングを有効にすると、クラスター内のネットワークフローの DNS クエリー名、レスポンスコード、および遅延を監視できます。
前提条件
- Network Observability Operator がインストールされている。
-
cluster-admin特権を持っている。 -
FlowCollectorカスタムリソースをよく理解している。
手順
以下のコマンドを実行して、
FlowCollectorリソースを編集します。$ oc edit flowcollector clusterDNS トラッキング機能を有効化するように eBPF エージェントを設定します。
apiVersion: flows.netobserv.io/v1alpha1 kind: FlowCollector metadata: name: cluster spec: agent: type: eBPF ebpf: features: - DNSTracking各項目の説明:
spec.agent.type.ebpf.features-
eBPF エージェントで有効にする機能のリストを指定します。DNS トラッキングを有効にするには、このリストに
DNSTrackingを追加します。
- 保存してからエディターを終了します。
検証
- OpenShift Container Platform の Web コンソールで、Observe → Network Traffic に移動します。
- Traffic Flows ビューで、Manage columns アイコンをクリックします。
- DNS Query Name、DNS Response Code、DNS Latency の各列が選択されていることを確認します。
-
Port を
53に設定して結果をフィルタリングします。 - フローテーブルの列にドメイン名と DNS メタデータが入力されていることを確認します。
9.3. DNS フローのエンリッチメントと分析に関するリファレンス
ネットワークフローに付加されたメタデータを特定し、DNS データを活用してネットワークを最適化し、クラスターのパフォーマンスとストレージへの影響を把握してください。
以下の表は、DNS トラッキングが有効な場合にネットワークフローに付加されるメタデータフィールドについて説明しています。
クエリー名が欠落したり、切り捨てられたりするのは、圧縮ポインターまたはキャッシュの制限によるものである可能性があります。
| フィールド | 説明 | 例 |
|---|---|---|
|
| 照会対象の完全修飾ドメイン名 (FQDN)。 |
|
|
| DNS サーバーから返されたステータスコード。 |
|
|
| クエリーとレスポンスを照合するために使用されるトランザクション ID。 |
|
9.3.1. DNS データを活用したネットワークの最適化
取得した DNS メタデータを使用すると、以下のような運用上の成果が得られます。
- 外部依存関係の監査: 許可されていない外部 API や高リスクのドメインにワークロードがアクセスしていないことを確認します。
-
パフォーマンスチューニング:
DNS Latencyを監視して、CoreDNSPod の追加のスケーリングが必要かどうか、または上位の DNS プロバイダーに遅延が発生しているかどうかを特定します。
9.3.2. 設定ミスによるエラーの特定
NXDOMAIN レスポンスが頻繁に発生する場合、通常、それはアプリケーションコードにおけるサービス検出エラー、または古い環境変数の存在を示しています。
Kubernetes では、サービスや Pod に対する DNS 検索が原因で、NXDOMAIN エラーが頻繁に発生する場合があります。このような結果は、必ずしも設定ミスや URL の破損を示すものではありませんが、パフォーマンスに悪影響を与える可能性があります。
my-svc.my-namespace.svc など、一見有効なサービスまたは Pod ホスト名が返されるにもかかわらず NXDOMAIN エラーが返される場合は、リゾルバーが異なるサフィックスに対して DNS を照会するように設定されている可能性があります。完全修飾ドメイン名の末尾にドットを追加し、ドメイン名に曖昧さがないことをリゾルバーに伝えることで、これを最適化できます。
たとえば、https://my-svc.my-namespace.svc の代わりに、末尾にドットを付けた https://my-svc.my-namespace.svc.cluster.local. を使用します。
9.3.3. Loki ストレージに関する考慮事項
DNS トラッキングは、フローごとのラベル数とメタデータの量を増加させます。Loki ストレージのサイズが、ログ容量の増加に対応できることを確認してください。
第10章 ネットワークトラフィックの観測
管理者は、OpenShift Container Platform Web コンソールでネットワークトラフィックを観測し、詳細なトラブルシューティングと分析を行うことができます。この機能は、トラフィックフローのさまざまなグラフィカル表現から洞察を得るのに役立ちます。
10.1. Overview ビューからのネットワークトラフィックの観測
Network Traffic の Overview ビューでは、集計されたフローメトリクスとアプリケーション間の通信に関する視覚的な情報が得られます。管理者はこれらのメトリクスを使用して、データ量の監視、接続のトラブルシューティング、およびクラスター全体の異常なトラフィックパターンの検出を行うことができます。
Overview ビューには、OpenShift Container Platform クラスター内のネットワークトラフィックの集計が表示され、通信中のアプリケーションと、転送されているデータ量を確認できます。送信元、宛先、フロータイプ別の詳細な分析結果とともに、上位のトラフィックフローと平均バイトレートも表示されます。
管理者は、接続の問題をトラブルシューティングしたり、異常なトラフィックパターンを検出したり、アプリケーションのパフォーマンスを最適化したりできます。ネットワークの動作状況を素早く把握できるため、アクションの優先順位付けが容易になり、リソースの効率的な使用を実現できます。
10.1.1. Overview ビューの使用
OpenShift Container Platform コンソールのネットワークトラフィックの Overview ビューに移動すると、フローレート統計情報のグラフ表示を確認したり、利用可能なオプションを使用して表示範囲を設定したりできます。
前提条件
- 管理者権限でクラスターにアクセスできる。
手順
- Observe → Network Traffic に移動します。
- Network Traffic ページで、Overview タブをクリックします。
- メニューアイコンをクリックして、各フローレートデータの範囲を設定します。
10.1.2. Overview ビューの詳細オプションの設定
グラフの範囲、ラベルの切り捨て、パネル管理などの高度なオプションを設定することで、ネットワークトラフィックの Overview ビューをカスタマイズし、フローレート統計情報やトラフィックデータの表示を最適化できます。
詳細オプションにアクセスするには、Show advanced options をクリックします。Display options ドロップダウンメニューを使用して、グラフの詳細を設定できます。利用可能なオプションは次のとおりです。
- Scope: ネットワークトラフィックが流れるコンポーネントを表示する場合に選択します。スコープは、Node、Namespace、Owner、Zones、Cluster、または Resource に設定できます。Owner はリソースの集合体です。Resource は、ホストネットワークトラフィックの場合は Pod、サービス、ノード、または不明な IP アドレスです。デフォルト値は Namespace です。
- Truncate labels: ドロップダウンリストから必要なラベルの幅を選択します。デフォルト値は M です。
10.1.2.1. パネルとディスプレイの管理
表示する必要なパネルを選択したり、並べ替えたり、特定のパネルに焦点を当てたりすることができます。パネルを追加または削除するには、Manage panels をクリックします。
デフォルトでは、次のパネルが表示されます。
- 上位 X の平均バイトレート
- 上位 X のバイトレートと合計の積み上げ値
他のパネルは Manage panels で追加できます。
- 上位 X の平均パケットレート
- 上位 X のパケットレートと合計の積み上げ値
Query options を使用すると、Top 5、Top 10、または Top 15 のレートを表示するかどうかを選択できます。
10.1.3. パケットドロップトラッキング
eBPF ベースのパケットドロップトラッキング機能を使用して、ネットワークのパケットドロップを監視および分析します。この機能は、ドロップ場所を特定し、ホストまたは OVS 固有のドロップ理由を検出して、Overview ビューに専用のグラフィカルパネルを提供します。
Overview ビューで、パケットロスが発生したネットワークフローレコードのグラフィック表示を設定できます。eBPF トレースポイントフックを採用すると、TCP、UDP、SCTP、ICMPv4、ICMPv6 プロトコルのパケットドロップに関する貴重な知見を得ることができ、その結果、以下のアクションにつながる可能性があります。
- 識別: パケットドロップが発生している正確な場所とネットワークパスを特定します。ドロップが発生しやすい特定のデバイス、インターフェイス、またはルートがあるか判断します。
- 根本原因分析: eBPF プログラムによって収集されたデータを調査し、パケットドロップの原因を把握します。たとえば、輻輳、バッファーの問題、特定のネットワークイベントなどの原因です。
- パフォーマンスの最適化: パケットドロップをより明確に把握し、バッファーサイズの調整、ルーティングパスの再設定、Quality of Service (QoS) 対策の実装など、ネットワークパフォーマンスを最適化するための手順を実行できます。
パケットドロップトラッキングが有効になっている場合、デフォルトで Overview に次のパネルが表示されます。
- 上位 X のパケットドロップの状態と合計の積み上げ値
- 上位 X のパケットドロップの原因と合計の積み上げ値
- 上位 X の平均パケットドロップレート
- 上位 X のパケットドロップレートと合計の積み上げ値
他のパケットドロップパネルは Manage panels で追加できます。
- 上位 X の平均ドロップバイトレート
- 上位 X の平均ドロップバイトレートと合計の積み上げ値
10.1.3.1. パケットドロップの種類
ネットワークオブザーバビリティーによって検出されるパケットドロップには、ホストドロップと OVS ドロップの 2 種類があります。ホストドロップには SKB_DROP というプレフィックスが付き、OVS ドロップには OVS_DROP というプレフィックスが付きます。ドロップされたフローは、各ドロップタイプの説明へのリンクとともに、Traffic flows テーブルのサイドパネルに表示されます。ホストドロップの理由の例は次のとおりです。
-
SKB_DROP_REASON_NO_SOCKET: ソケットが検出されないため、パケットがドロップされました。 -
SKB_DROP_REASON_TCP_CSUM: TCP チェックサムエラーによりパケットがドロップされました。
OVS ドロップの理由の例は次のとおりです。
-
OVS_DROP_LAST_ACTION: 暗黙的なドロップアクション (設定されたネットワークポリシーなど) によりドロップされた OVS パケット。 -
OVS_DROP_IP_TTL: IP TTL の期限切れにより OVS パケットがドロップされました。
パケットドロップトラッキングを有効化および使用する方法の詳細は、このセクションの 関連情報 を参照してください。
10.1.4. DNS トラッキング
eBPF ベースの DNS トラッキングを使用して DNS アクティビティーを監視し、Overview ビューの専用グラフィカルパネルから、クエリーパターンの把握、セキュリティー脅威の検出、遅延の問題のトラブルシューティングを行います。
Overview ビューで、ネットワークフローの Domain Name System (DNS) トラッキングのグラフィカル表示を設定できます。extended Berkeley Packet Filter (eBPF) トレースポイントフックを使用する DNS トラッキングは、さまざまな目的に使用できます。
- ネットワーク監視: ネットワーク管理者は、DNS のクエリーやレスポンスに関する知見を得ることで、異常なパターン、潜在的なボトルネック、またはパフォーマンスの問題を特定できます。
- セキュリティー分析: マルウェアによって使用されるドメイン名生成アルゴリズム (DGA) などの不審な DNS アクティビティーを検出したり、セキュリティーを侵害する可能性のある不正な DNS 解決を特定したりします。
- トラブルシューティング: DNS 解決手順を追跡し、遅延を追跡し、設定ミスを特定することにより、DNS 関連の問題をデバッグします。
デフォルトでは、DNS トラッキングが有効な場合、Overview に、次の空でないメトリクスがドーナツグラフまたは折れ線グラフで表示されます。
- 上位 X の DNS レスポンスコード
- 上位 X の平均 DNS 遅延と合計
- 上位 X の 90 パーセンタイルの DNS 遅延
他の DNS トラッキングのパネルは Manage panels で追加できます。
- 下位 X の最小 DNS 遅延
- 上位 X の最大 DNS 遅延
- 上位 X の 99 パーセンタイルの DNS 遅延
この機能は、IPv4 および IPv6 の UDP および TCP プロトコルでサポートされています。
このビューの有効化と使用の詳細は、このセクションの 関連情報 を参照してください。
10.1.5. ラウンドトリップタイム
TCP ラウンドトリップタイム (RTT) メトリクスを使用して、ネットワークフローの遅延を分析します。その際、eBPF フックポイントを使用してパフォーマンスのボトルネックを特定し、Overview ビューの専用パネルから TCP 関連の問題をトラブルシューティングします。
TCP の平滑化されたラウンドトリップタイム (sRTT) を使用して、ネットワークフローの遅延を分析できます。fentry/tcp_rcv_established eBPF フックポイントから取得した RTT を使用して TCP ソケットから sRTT を読み取ると、次のことに役立てることができます。
- ネットワーク監視: TCP の遅延に関する知見を得ることで、ネットワーク管理者は、異常なパターン、潜在的なボトルネック、またはパフォーマンスの問題を特定できます。
- トラブルシューティング: 遅延を追跡し、設定ミスを特定することにより、TCP 関連の問題をデバッグします。
デフォルトでは、RTT が有効になっている場合、Overview に次の TCP RTT メトリクスが表示されます。
- 上位 X の 90 パーセンタイルの TCP ラウンドトリップタイムと合計
- 上位 X の平均 TCP ラウンドトリップタイムと合計
- 下位 X の最小 TCP ラウンドトリップタイムと合計
他の RTT パネルは Manage panels で追加できます。
- 上位 X の最大 TCP ラウンドトリップタイムと合計
- 上位 X の 99 パーセンタイルの TCP ラウンドトリップタイムと合計
このビューの有効化と使用の詳細は、このセクションの 関連情報 を参照してください。
10.1.6. eBPF フローのルールフィルター
eBPF フローのルールフィルタリングを使用して、ポートと CIDR 表記に基づいてキャプチャー基準を指定することで、パケットキャプチャー量を制御しながら、専用の健全性ダッシュボードと Prometheus メトリクスを通じてフィルターのパフォーマンスを監視します。
ルールベースのフィルタリングを使用して、eBPF フローテーブルにキャッシュされるパケットの量を制御できます。たとえば、ポート 100 から送信されるパケットのみを取得するようにフィルターを指定できます。フィルターに一致するパケットのみがキャプチャーされ、残りはドロップされます。
複数のフィルタールールを適用できます。
10.1.6.1. Ingress および Egress トラフィックのフィルタリング
Classless Inter-Domain Routing (CIDR) 表記は、ベース IP アドレスとプレフィックス長を組み合わせることにより、IP アドレス範囲を効率的に表すものです。Ingress と Egress トラフィックの両方において、送信元 IP アドレスが、CIDR 表記で設定されたフィルタールールを照合するために最初に使用されます。一致するものがあれば、フィルタリングが続行されます。一致するものがない場合、宛先 IP を使用して、CIDR 表記で設定されたフィルタールールを照合します。
送信元 IP または宛先 IP の CIDR のいずれかを照合した後、peerIP を使用して特定のエンドポイントを特定し、パケットの宛先 IP アドレスを識別できます。定められたアクションに基づいて、フローデータが eBPF フローテーブルにキャッシュされるかされないかが決まります。
10.1.6.2. ダッシュボードとメトリクスの統合
このオプションを有効にすると、eBPF agent statistics の Netobserv/Health ダッシュボードに、Filtered flows rate ビューが表示されるようになります。さらに、Observe → Metrics で、netobserv_agent_filtered_flows_total をクエリーして、FlowFilterAcceptCounter、FlowFilterNoMatchCounter、または FlowFilterRecjectCounter の理由を含むメトリクスを観測できます。
10.1.6.3. フローフィルターの設定パラメーター
FlowCollector リソースでフローフィルタールールを設定する際に必須および任意のパラメーターを参照してください。これには、CIDR 範囲、フィルターアクション、プロトコル、特定のポート設定などが含まれます。
| パラメーター | 説明 |
|---|---|
|
|
eBPF フローのフィルタリング機能を有効にするには、 |
|
|
フローフィルタールールの IP アドレスと CIDR マスクを指定します。IPv4 と IPv6 の両方のアドレス形式をサポートしています。すべての IP と照合する場合、IPv4 の場合は |
|
|
フローフィルタールールに対して実行されるアクションを示します。可能な値は
|
| パラメーター | 説明 |
|---|---|
|
|
フローフィルタールールの方向を定義します。可能な値は |
|
|
フローフィルタールールのプロトコルを定義します。可能な値は、 |
|
|
フローをフィルタリングするための TCP フラグを定義します。可能な値は、 |
|
|
フローのフィルタリングに使用するポートを定義します。送信元ポートまたは宛先ポートのどちらにも使用できます。単一のポートをフィルタリングするには、単一のポートを整数値として設定します。たとえば、 |
|
|
フローのフィルタリングに使用する送信元ポートを定義します。単一のポートをフィルタリングするには、単一のポートを整数値として設定します (例: |
|
|
destPorts は、フローのフィルタリングに使用する宛先ポートを定義します。単一のポートをフィルタリングするには、単一のポートを整数値として設定します (例: |
|
| フローのフィルタリングに使用する ICMP タイプを定義します。 |
|
| フローのフィルタリングに使用する ICMP コードを定義します。 |
|
|
フローのフィルタリングに使用する IP アドレスを定義します (例: |
10.1.7. ユーザー定義ネットワーク
ユーザー定義ネットワーク (UDN) を使用して柔軟なネットワークセグメンテーションを行う方法と、Network Observability Operator を活用して、トラフィックフローテーブルの専用ラベルと名前フィルターでそのセグメントを監視する方法を説明します。
ユーザー定義ネットワーク (UDN) は、カスタムの Layer 2 および Layer 3 ネットワークセグメントを有効にすることで、Kubernetes Pod ネットワークのデフォルトの Layer 3 トポロジーが持つ柔軟性とセグメンテーション機能を強化するものです。これらのセグメントはすべてデフォルトで分離されています。これらのセグメントは、デフォルトの OVN-Kubernetes CNI プラグインを使用するコンテナー Pod および仮想マシンのプライマリーネットワークまたはセカンダリーネットワークとして機能します。
UDN を使用することで、幅広いネットワークアーキテクチャーとトポロジーが可能になり、ネットワークの柔軟性、セキュリティー、パフォーマンスが向上します。
Network Observability で UDNMapping 機能が有効になっている場合、Traffic フローテーブルに UDN labels 列が表示されます。Source Network Name と Destination Network Name でフィルタリングできます。
10.1.8. OVN-Kubernetes ネットワークイベント
OVN-Kubernetes ネットワークイベントトラッキング機能を使用して、クラスター内のネットワークポリシー、管理ネットワークポリシー、および Egress ファイアウォールルールを監視および監査します。
OVN-Kubernetes ネットワークイベントトラッキングは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
ネットワークイベントの追跡から得られる情報は、次のタスクに役立ちます。
- ネットワークモニタリング: 許可されたトラフィックとブロックされたトラフィックを監視し、ネットワークポリシーと管理ネットワークポリシーに基づきパケットが許可されているか、あるいはブロックされているかを検出します。
- ネットワークセキュリティー: 送信トラフィックを追跡し、Egress ファイアウォールルールに準拠しているか確認できます。許可されていない送信接続を検出し、Egress ルールに違反する送信トラフィックにフラグを立てます。
このビューの有効化と使用の詳細は、このセクションの 関連情報 を参照してください。
10.2. Traffic flows ビューからのネットワークトラフィックの観測
Traffic flows ビューを使用して、クラスターコンポーネント間のリアルタイムおよび過去のネットワーク通信を監視します。eBPF を介して収集された詳細なフローデータを分析することで、ネットワークトラフィックの監査、ネットワークポリシーの検証、および外部レポートや分析のためのデータエクスポートが可能になります。
Network Observability Operator の Traffic flows ビューは、OpenShift Container Platform クラスター全体のネットワークアクティビティーを、詳細な表形式で表示します。このビューは eBPF テクノロジーを活用してフローデータを収集します。管理者はこのビューを使用して、Pod、サービス、およびノード間のリアルタイムおよび過去の通信を監視できます。この可視性は、ネットワークトラフィックの監査、ネットワークポリシーの検証、およびクラスターインフラストラクチャー内の予期しない通信パターンの特定に不可欠です。
Traffic flows インターフェイスでは、個々の行を操作することで詳細なフロー情報を取得し、特定の接続の詳細を分析できます。このビューは、Display options メニューによる高度なカスタマイズをサポートしています。このメニューでは、行の密度を調整したり、列を管理したりできます。特定の列を選択して並べ替えることで、送信元と宛先のエンドポイント、トラフィック量など、環境にとって最も関連性の高いデータポイントを強調するように表をカスタマイズできます。
外部での分析やレポート作成を支援するために、Traffic flows ビューはデータエクスポート機能を備えています。データセット全体をエクスポートすることも、特定のフィールドを選択してネットワークアクティビティーに的を絞ったレポートを生成することもできます。この機能により、長期的な監査ツールやサードパーティーの監視ツールでネットワークフローデータを確実に利用できるようになります。その結果、OpenShift Container Platform 環境のネットワークの健全性を柔軟に記録および分析する方法が得られます。
10.2.1. Traffic flows ビューの使用
Traffic flows テーブルを使用して、詳細なネットワークフロー情報を表示および分析します。
管理者は、Traffic flows テーブルに移動して、ネットワークフロー情報を確認できます。
前提条件
- 管理者権限を持っている。
手順
- Observe → Network Traffic に移動します。
- Network Traffic ページで、Traffic flows タブをクリックします。
- 各行をクリックすると、対応するフロー情報が表示されます。
10.2.2. Traffic flows の表示設定
Traffic flows ビューには、表示密度、データ列、およびデータのエクスポートオプションをカスタマイズするための設定が含まれています。
10.2.2.1. 表示オプション
Traffic flows ビューでは、以下の要素を利用できます。
- Show advanced options
- 現在のビューをカスタマイズおよびエクスポートするためのメニューを指定します。
- Display options ドロップダウン
- データ表の行サイズを指定します。デフォルト値は Normal です。
- Manage columns
- Traffic flows テーブルに表示される列を選択および並べ替えるためのダイアログを指定します。
10.2.3. トラフィックフローデータのエクスポート
外部での分析やレポート作成のために、Traffic flows ビューからネットワークフローデータを CSV ファイルにエクスポートできます。
手順
- Export data をクリックします。
- ウィンドウ内で、Export all data チェックボックスをオンにすると、すべてのデータがエクスポートされます。チェックボックスをオフにすると、エクスポートに必須のフィールドが選択されます。
- Export をクリックします。
10.2.4. FlowCollector カスタムリソースを使用した IPsec の設定
FlowCollector リソースで IPsec トラッキングを有効にして、暗号化されたトラフィックを監視し、トラフィックフロービューに IPsec ステータス列を追加して、専用の暗号化ダッシュボードを生成します。
OpenShift Container Platform では、IPsec はデフォルトで無効になっています。「IPsec 暗号化の設定」の手順に従って IPsec を有効にできます。
前提条件
- OpenShift Container Platform で IPsec 暗号化を有効にした。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
IPsec の
FlowCollectorカスタムリソースを設定します。IPsec の
FlowCollectorの設定例apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: namespace: netobserv agent: type: eBPF ebpf: features: - "IPSec"
検証
IPsec が有効な場合:
- IPsec Status という新しい列が Network Observability の Traffic フロービューに表示され、フローが正常に IPsec で暗号化されたかどうか、または暗号化/復号化中にエラーが発生したかどうかが表示されます。
- 生成された暗号化トラフィックの割合を示す新しいダッシュボード。
10.2.5. 会話トラッキングの使用
Web コンソールで関連するネットワークフローをグループ化および分析するために、FlowCollector カスタムリソースを設定して会話トラッキングを有効にします。
管理者は、同じ会話の一部であるネットワークフローをグループ化できます。会話は、IP アドレス、ポート、プロトコルによって識別されるピアのグループとして定義され、その結果、一意の Conversation ID が得られます。Web コンソールで対話イベントをクエリーできます。これらのイベントは、Web コンソールでは次のように表示されます。
- Conversation start: このイベントは、接続が開始されているか、TCP フラグがインターセプトされたときに発生します。
-
Conversation tick: このイベントは、接続がアクティブである間、
FlowCollectorspec.processor.conversationHeartbeatIntervalパラメーターで定義された指定間隔ごとに発生します。 -
Conversation end: このイベントは、
FlowCollectorspec.processor.conversationEndTimeoutパラメーターに達するか、TCP フラグがインターセプトされたときに発生します。 - Flow: これは、指定された間隔内に発生するネットワークトラフィックフローです。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
spec.processor.logTypes、conversationEndTimeout、およびconversationHeartbeatIntervalパラメーターが観察のニーズに応じて設定されるように、FlowCollectorカスタムリソースを設定します。設定例は次のとおりです。会話トラッキング用に
FlowCollectorを設定するapiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: processor: logTypes: Flows advanced: conversationEndTimeout: 10s conversationHeartbeatInterval: 30s各項目の説明:
spec.processor.logTypes-
エクスポートするイベントの種類を指定します。
Flowsに設定すると、フローイベントのみがエクスポートされます。Allに設定すると、会話イベントとフローイベントの両方がエクスポートされ、Network Traffic ページに表示されます。会話イベントだけに絞り込むには、Conversation start、Conversation tick、および Conversation end イベントをエクスポートするようにConversationsを指定します。Conversation end イベントのみをエクスポートするには、EndedConversationsを指定します。ストレージ要件はAllで最も高く、EndedConversationsで最も低くなります。 spec.processor.advanced.conversationEndTimeout- タイムアウトに達した場合、または TCP フラグがインターセプトされた場合に Conversation end イベントがトリガーされるまでの期間を指定します。
spec.processor.advanced.conversationHeartbeatIntervalネットワーク接続がアクティブな間の Conversation tick イベントの間隔を指定します。
注記logTypeオプションを更新しても、以前の選択によるフローはコンソールプラグインから消去されません。たとえば、午前 10 時までlogTypeをConversationsに設定し、その後EndedConversationsに移行すると、コンソールプラグインは、午前 10 時まではすべての会話イベントを表示し、午前 10 時以降は終了した会話のみを表示します。
-
Traffic flows タブの Network Traffic ページを更新します。Event/Type と Conversation Id という 2 つの新しい列があることに注意してください。クエリーオプションとして Flow が選択されている場合、すべての Event/Type フィールドは
Flowになります。 - Query Options を選択し、Log Type として Conversation を選択します。Event/Type は、必要なすべての会話イベントを表示するようになりました。
- 次に、特定の会話 ID でフィルタリングするか、サイドパネルから Conversation と Flow ログタイプのオプションを切り替えることができます。
10.2.6. パケットドロップの使用
Web コンソールでネットワークデータの損失を監視および可視化するために、FlowCollector リソースを設定して Network Observability Operator のパケットドロップトラッキングを有効にします。
パケットロスは、ネットワークフローデータの 1 つ以上のパケットが宛先に到達できない場合に発生します。パケットのドロップは、次に示す YAML の例の仕様に合わせて FlowCollector を編集することで追跡できます。
この機能を有効にすると、CPU とメモリーの使用量が増加します。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
パケットドロップ用に
FlowCollectorカスタムリソースを設定します。以下はその例です。FlowCollectorの設定例apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: namespace: netobserv agent: type: eBPF ebpf: features: - PacketDrop privileged: true各項目の説明:
spec.agent.ebpf.features-
有効にする機能を指定します。各ネットワークフローのパケットドロップの報告を開始するには、
PacketDropを含めます。 spec.agent.ebpf.privileged-
特権モードを有効にするかどうかを指定します。パケットドロップトラッキングを有効にするには、
trueに設定する必要があります。
検証
Network Traffic ページを更新すると、Overview、Traffic Flow、Topology ビューにパケットドロップに関する新しい情報が表示されます。
- Manage panels で、Overview に表示するパケットドロップのグラフィカル表示を新しく選択します。
Manage columns で、Traffic flows テーブルに表示するパケットドロップ情報を選択します。
-
Traffic Flows ビューでは、サイドパネルを展開してパケットドロップの詳細情報を表示することもできます。ホストドロップには
SKB_DROPというプレフィックスが付き、OVS ドロップにはOVS_DROPというプレフィックスが付きます。
-
Traffic Flows ビューでは、サイドパネルを展開してパケットドロップの詳細情報を表示することもできます。ホストドロップには
- Topology ビューでは、ドロップが発生した場所が赤線で表示されます。
10.2.7. DNS トラッキングの使用
Web コンソールでネットワークパフォーマンスの監視、セキュリティー分析、DNS トラブルシューティングを行うために、FlowCollector カスタムリソースを設定して DNS トラッキングを有効にします。
次に示す YAML の例の仕様に合わせて FlowCollector を編集することで、DNS を追跡できます。
この機能を有効にすると、eBPF agent で CPU とメモリーの使用量の増加が観察されます。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- Network Observability の Provided APIs という見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
FlowCollectorカスタムリソースを設定します。設定例は次のとおりです。DNS トラッキング用に
FlowCollectorを設定するapiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: namespace: netobserv agent: type: eBPF ebpf: features: - DNSTracking sampling: 1-
spec.agent.ebpf.featuresパラメーターリストを設定すると、Web コンソールで各ネットワークフローの DNS トラッキングを有効にできます。 -
より正確なメトリクスと DNS レイテンシー をキャプチャーするために、
sampling値を1に設定できます。sampling値が 1 より大きい場合、DNS レスポンスコード と DNS ID を含むフローを観測できますが、DNS レイテンシー を観測できる可能性は低くなります。
-
Network Traffic ページを更新すると、Overview ビューと Traffic Flow ビューで表示する新しい DNS 表示と適用可能な新しいフィルターが表示されます。
- Manage panels で新しい DNS の選択肢を選択すると、Overview にグラフィカルな表現と DNS メトリクスが表示されます。
- Manage columns で新しい選択肢を選択すると、DNS 列が Traffic Flows ビューに追加されます。
DNS Id、DNS Error、DNS Latency、DNS Response Code などの特定の DNS メトリクスでフィルタリングして、サイドパネルから詳細情報を確認します。DNS Latency 列と DNS Response Code 列がデフォルトで表示されます。
注記TCP ハンドシェイクパケットには DNS ヘッダーがありません。DNS ヘッダーのない TCP プロトコルフローの場合、トラフィックフローデータに表示される DNS Latency、ID、および Response code の値が "n/a" になります。"DNSError" が "0" の Common フィルターを使用すると、フローデータをフィルタリングして、DNS ヘッダーを持つフローのみを表示できます。
10.2.8. RTT トレーシングの使用
Web コンソールを使用してクラスター全体のネットワーク遅延を監視および分析するために、FlowCollector カスタムリソースを設定してラウンドトリップタイム (RTT) トレーシングを有効にします。
次に示す YAML の例の仕様に合わせて FlowCollector を編集することで、RTT を追跡できます。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs という見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
RTT トレーシング用に
FlowCollectorカスタムリソースを設定します。次に例を示します。FlowCollectorの設定例apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: namespace: netobserv agent: type: eBPF ebpf: features: - FlowRTT各項目の説明:
spec.agent.ebpf.features-
有効にする eBPF 機能のリストを指定します。ラウンドトリップタイム (RTT) ネットワークフローのトレースを開始するには、このリストに
FlowRTTを追加します。
検証
Network Traffic ページを更新すると、Overview、Traffic flows、Topology の各ビューに RTT 情報が表示されます。
- Overview ビューで、Manage panels をクリックして、表示する RTT のグラフィカル表示を選択します。
- Traffic flows テーブルで、Flow RTT 列がデフォルトで表示されていることを確認します。列を管理するには、Manage columns をクリックします。
Traffic flows ビューで、サイドパネルを展開して RTT のメタデータを表示します。
-
フィルター検索バーに
protocol=TCPと入力して、TCP プロトコルのフローデータをフィルタリングします。 -
TCP でフィルタリングされたすべてのフローの FlowRTT 値が
0より大きいことを確認します。 -
フィルター検索バーに
time_flow_rtt>=10000000と入力して、FlowRTT の値が10,000,000ナノ秒 (10 ms) より大きいものをフィルタリングします。 - フィルターを解除します。
-
フィルター検索バーに
- Topology ビューで、Display オプションのドロップダウンメニューをクリックします。Edge labels リストで、RTT を選択します。
10.2.9. eBPF Manager Operator の使用
eBPF Manager Operator を Network Observability と統合することで、eBPF プログラムを管理し、エージェントの特権の必要性を低減します。
eBPF Manager Operator は、すべての eBPF プログラムを管理することで、攻撃対象領域を削減し、コンプライアンス、セキュリティー、競合防止を実現します。ネットワークオブザーバビリティーは、eBPF Manager Operator を使用してフックをロードできます。そのため、特権モードや、CAP_BPF や CAP_PERFMON などの追加の Linux ケイパビリティーを eBPF エージェントに提供する必要がなくなります。eBPF Manager Operator と Network Observability の連携は、64 ビット AMD アーキテクチャーでのみサポートされています。
eBPF Manager Operator と Network Observability の連携は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
手順
- Web コンソールで、Ecosystem → Operator Hub に移動します。
- eBPF Manager をインストールします。
-
bpfmannamespace の Workloads → Pod をチェックして、すべてが稼働していることを確認します。 eBPF Manager Operator を使用するように
FlowCollectorカスタムリソースを設定します。FlowCollectorの設定例apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: agent: ebpf: features: - EbpfManager
検証
- Web コンソールで、Ecosystem → Installed Operators に移動します。
eBPF Manager Operator → All instances タブをクリックします。
各ノードについて、
netobservという名前のBpfApplicationと、BpfProgramオブジェクトのペア (Traffic Control (TCx) Ingress 用と TCx Egress 用のもの) が存在することを確認します。他の eBPF エージェント機能を有効にすると、オブジェクトが増える可能性があります。
10.2.10. ヒストグラムの使用
ヒストグラムは、ネットワークフローログを視覚的に表示するものです。トラフィック量の傾向を分析したり、特定の時間間隔でフローデータをフィルタリングしたりするために使用できます。
Show histogram をクリックすると、フローの履歴を棒グラフとして可視化するためのツールバーが表示されます。ヒストグラムは、時間の経過に伴うログの数を示します。ヒストグラムの一部を選択して、ツールバーに続く表でネットワークフローデータをフィルタリングできます。
10.2.11. アベイラビリティーゾーンの使用
FlowCollector カスタムリソースを設定してアベイラビリティーゾーンに関するデータを収集することで、Web コンソールで異なるクラスターゾーン間のネットワークトラフィックの可視化と分析が可能になります。
クラスターのアベイラビリティーゾーンに関する情報を収集するように FlowCollector を設定できます。この設定により、ノードに適用される topology.kubernetes.io/zone ラベル値を使用してネットワークフローデータをエンリッチできます。
手順
- Web コンソールで、Ecosystem → Installed Operator に移動します。
- NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
FlowCollectorカスタムリソースを設定し、spec.processor.addZoneパラメーターをtrueに設定します。設定例は次のとおりです。アベイラビリティーゾーン収集用に
FlowCollectorを設定するapiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: # ... processor: addZone: true # ...
検証
Network Traffic ページを更新すると、Overview、Traffic Flow、Topology ビューにアベイラビリティーゾーンに関する新しい情報が表示されます。
- Overview タブに、使用可能な Scope として Zones が表示されます。
- Network Traffic → Traffic flows の SrcK8S_Zone フィールドと DstK8S_Zone フィールドに Zones が表示されます。
- Topology ビューで、Scope または Group として Zones を設定できます。
10.2.12. 複数のルールを使用した eBPF フローデータのフィルタリング
FlowCollector カスタムリソースで複数のフィルタリングルールを設定することで、IP アドレスやパケットの状態に基づいて特定の eBPF フローを受け入れるか拒否するかを決定し、ネットワークトラフィックデータの収集を絞り込むことができます。
- フィルタールールでは重複する Classless Inter-Domain Routing (CIDR) を使用することはできません。
- IP アドレスが複数のフィルタールールにマッチする場合、最も具体的な CIDR 接頭辞 (最も長い接頭辞) を持つルールが優先されます。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- Network Observability の Provided APIs という見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
-
FlowCollectorカスタムリソースを設定します。
10.2.13. eBPF フローデータのフィルタリングの例
複数のルールを使用して eBPF フローをフィルタリングし、eBPF フローテーブルにキャッシュされるパケットのフローを制御するには、以下の FlowCollector カスタムリソースの例を使用してください。
10.2.13.1. すべての North-South トラフィックと 1:50 の East-West トラフィックをサンプリングする YAML の例
デフォルトでは、他のすべてのフローが拒否されます。
apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
name: cluster
spec:
namespace: netobserv
deploymentModel: Service
agent:
type: eBPF
ebpf:
flowFilter:
enable: true
rules:
- action: Accept
cidr: 0.0.0.0/0
sampling: 1
- action: Accept
cidr: 10.128.0.0/14
peerCIDR: 10.128.0.0/14
- action: Accept
cidr: 172.30.0.0/16
peerCIDR: 10.128.0.0/14
sampling: 50各項目の説明:
spec.agent.ebpf.flowFilter.enable-
eBPFフローのフィルタリングを有効にするかどうかを指定します。フローのフィルタリングを有効にするには、trueに設定します。 spec.agent.ebpf.flowFilter.rules.action-
フローフィルタールールのアクションを指定します。有効な値は
AcceptまたはRejectです。 spec.agent.ebpf.flowFilter.rules.cidr-
フローフィルタールールの IP アドレスと
CIDRマスクを指定します。このパラメーターは、IPv4とIPv6の両方のアドレス形式をサポートしています。すべての IP アドレスに一致させるには、IPv4の場合は0.0.0.0/0、IPv6の場合は::/0を使用します。 spec.agent.ebpf.flowFilter.rules.peerCIDR-
フローのフィルタリングに使用するピア IP の
CIDRを指定します。 spec.agent.ebpf.flowFilter.rules.sampling-
条件に一致したフローのサンプリング間隔を指定します。この値は、
spec.agent.ebpf.samplingで定義されているグローバルのサンプリング設定をオーバーライドします。
10.2.13.2. パケットドロップでフローをフィルタリングする YAML の例
デフォルトでは、他のすべてのフローが拒否されます。
apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
name: cluster
spec:
namespace: netobserv
deploymentModel: Service
agent:
type: eBPF
ebpf:
privileged: true
features:
- PacketDrop
flowFilter:
enable: true
rules:
- action: Accept
cidr: 172.30.0.0/16
pktDrops: true各項目の説明:
spec.agent.ebpf.privileged- 特権モードを有効にするかどうかを指定します。特権モードはパケットドロップを報告するために必要です。
spec.agent.ebpf.features-
有効にする eBPF 機能のリストを指定します。
PacketDrop値をこのリストに追加すると、各ネットワークフローのパケットドロップが報告されます。 spec.agent.ebpf.flowFilter.enable-
eBPFフローのフィルタリングを有効にするかどうかを指定します。 spec.agent.ebpf.flowFilter.rules.action-
フローフィルタールールのアクションを指定します。有効な値は
AcceptまたはRejectです。 spec.agent.ebpf.flowFilter.rules.pktDrops- パケットドロップを含むフローをフィルタリングするかどうかを指定します。
10.2.14. エンドポイント変換 (xlat)
エンドポイント変換 (xlat) は、eBPF を使用してネットワークフローログを Pod レベルの変換済みのメタデータでエンリッチし、サービスやロードバランサーの背後でトラフィックを処理する特定のバックエンド Pod を可視化します。
ネットワークオブザーバビリティーと extended Berkeley Packet Filter (eBPF) を使用することで、トラフィックを処理しているエンドポイントを統合ビューで可視化できます。通常、トラフィックがサービス、egressIP、またはロードバランサーを通過する場合、トラフィックフロー情報は、利用可能な Pod の 1 つにルーティングされるときに抽象化されます。トラフィックに関する情報を取得しようとすると、サービス IP やポートなどのサービス関連情報のみが表示され、リクエストを処理している特定の Pod に関する情報は表示されません。多くの場合、サービストラフィックと仮想サービスエンドポイントの両方の情報が 2 つの別々のフローとしてキャプチャーされるため、トラブルシューティングが複雑になります。
この問題の解決において、エンドポイント xlat は次のように役立ちます。
- カーネルレベルでネットワークフローをキャプチャーします。この場合のパフォーマンスへの影響は、最小限に抑えられます。
- 変換されたエンドポイント情報を使用してネットワークフローを拡充し、サービスだけでなく特定のバックエンド Pod も表示することで、どの Pod がリクエストを処理したか確認できます。
ネットワークパケットが処理されると、eBPF フックは、変換されたエンドポイントに関するメタデータでフローログをエンリッチします。これには、Network Traffic ページに 1 行で表示できる次の情報が含まれます。
- ソース Pod IP
- 送信元ポート
- 宛先 Pod IP
- 宛先ポート
- Conntrack Zone ID
10.2.15. エンドポイント変換 (xlat) の使用
ネットワークフローに変換済みのパケット情報を追加するために、FlowCollector リソースでエンドポイント変換 (xlat) を有効にします。この情報を使用すると、専用の xlat 列を通じて、サービストラフィックを処理している特定の Pod とオブジェクトを特定できます。
Network Observability と eBPF を使用すると、Kubernetes サービスからのネットワークフローを変換されたエンドポイント情報でエンリッチして、トラフィックを処理するエンドポイントに関する詳細情報を得ることができます。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs という見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
PacketTranslationのFlowCollectorカスタムリソースを、設定します。以下はその例です。FlowCollectorの設定例apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: namespace: netobserv agent: type: eBPF ebpf: features: - PacketTranslation-
spec.agent.ebpf.features仕様リストにPacketTranslationパラメーターをリストすることで、変換されたパケット情報を使用してネットワークフローを充実させることができます。
-
Network Traffic ページを更新し、変換済みのパケットに関する情報をフィルタリングします。
- Destination kind: Service に基づき、ネットワークフローデータをフィルタリングします。
変換された情報が表示される場所を区別する xlat 列と、次のデフォルト列が表示されます。
- Xlat Zone ID
- Xlat Src Kubernetes Object
- Xlat Dst Kubernetes Object
- 追加の xlat 列の表示は、Manage columns で管理できます。
10.2.16. ユーザー定義ネットワークの使用
FlowCollector カスタムリソースを設定して、ユーザー定義ネットワーク (UDN) のマッピングを有効にすることで、Web コンソールでカスタムネットワークインターフェイスを通過するトラフィックを可視化します。
ユーザー定義ネットワーク (UDN) は、ネットワークオブザーバビリティーリソースで有効にできます。次の例は、FlowCollector リソースの設定を示しています。
前提条件
- Red Hat OpenShift Networking で UDN を設定した。詳細は、「CLI を使用した UserDefinedNetwork の作成」または「Web コンソールを使用した UserDefinedNetwork の作成」を参照してください。
手順
次のコマンドを実行して、ネットワークオブザーバビリティーの
FlowCollectorリソースを編集します。$ oc edit flowcollectorFlowCollectorリソースのebpfセクションを設定します。apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: agent: ebpf: sampling: 1 privileged: true features: - UDNMapping各項目の説明:
spec.agent.ebpf.sampling-
ネットワークイベントのサンプリングレートを指定します。すべてのネットワークイベントをキャプチャーするには、値を
1に設定します。サンプリング値を1にするとリソースの消費が多すぎる場合は、ニーズに合わせてより適切なサンプリング値を設定してください。 spec.agent.ebpf.privileged-
特権モードを有効にするかどうかを指定します。ユーザー定義ネットワークのマッピングを行うには、
trueに設定する必要があります。
検証
Network Traffic ページを更新して、Traffic Flow と Topology ビューで更新された UDN の情報を表示します。
-
Network Traffic > Traffic flows では、
SrcK8S_NetworkNameフィールドとDstK8S_NetworkNameフィールドで UDN を確認できます。 - Topology ビューでは、Network を Scope または Group に設定できます。
-
Network Traffic > Traffic flows では、
10.2.17. ネットワークイベントの表示
セキュリティーポリシー、ファイアウォール、および分離ルールがトラフィックフローにどのように影響するかを Web コンソールで監査するために、FlowCollector カスタムリソースを設定してネットワークイベントトラッキングを有効にします。
OVN-Kubernetes ネットワークイベントトラッキングは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
FlowCollector を編集して、次のリソースによってドロップまたは許可されたネットワークフローなどのネットワークトラフィックイベントに関する情報を表示できます。
-
NetworkPolicy -
AdminNetworkPolicy -
BaselineNetworkPolicy -
EgressFirewall -
UserDefinedNetwork分離 - マルチキャスト ACL
前提条件
-
clusterという名前のFeatureGateカスタムリソース (CR) でTechPreviewNoUpgrade機能セットを設定することで、OVNObservabilityを有効にした。詳細は、「CLI を使用した機能セットの有効化」および「CLI を使用して OVS サンプリングで OVN-Kubernetes ネットワークトラフィックを確認する」を参照してください。 -
NetworkPolicy、AdminNetworkPolicy、BaselineNetworkPolicy、UserDefinedNetworkの分離、マルチキャスト、またはEgressFirewallのいずれかのネットワーク API を 1 つ以上作成した。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs という見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
NetworkEventsの表示を有効にするには、FlowCollectorCR を設定します。例:FlowCollectorの設定例apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: agent: type: eBPF ebpf: # sampling: 1 privileged: true features: - "NetworkEvents"各項目の説明:
spec.agent.ebpf.sampling-
ネットワークイベントのサンプリングレートを指定します。すべてのネットワークイベントをキャプチャーするには、値を
1に設定します。サンプリング値を1にするとリソースの消費が多すぎる場合は、ニーズに合わせてより適切なサンプリング値を設定してください。この値はオプションです。 spec.agent.ebpf.privileged-
eBPF エージェントを特権モードで実行するかどうかを指定します。これは
trueに設定してください。OVN オブザーバビリティーライブラリーが、ローカルの Open vSwitch (OVS) ソケットおよび Open Virtual Network (OVN) データベースにアクセスする必要があるためです。
検証
- Network Traffic ビューに移動し、Traffic flows テーブルを選択します。
Network Events という新しい列が表示されます。ここでは、有効にしたネットワーク API (
NetworkPolicy、AdminNetworkPolicy、BaselineNetworkPolicy、UserDefinedNetworkの分離、マルチキャスト、Egress ファイアウォール) のいずれかがもたらす影響に関する情報を表示できます。この列で確認できるイベントの kind の例は次のとおりです。
Network Events の出力例
<Dropped_or_Allowed> by <network_event_and_event_name>, direction <Ingress_or_Egress>
10.3. Topology ビューからのネットワークトラフィックの観測
Network Traffic ページの Topology ビューでは、OpenShift Container Platform クラスター全体のネットワークフローとトラフィック量がグラフィカルに表示されます。管理者は、このビューを使用してアプリケーションのトラフィックデータを監視したり、さまざまなネットワークコンポーネント間の関係を可視化したりできます。
この視覚的表現では、ネットワークエンティティーをノードとして、トラフィックフローをエッジとして表しています。グラフ内の個々のコンポーネントを選択すると、そのリソースに関する特定のメトリクスと健全性の詳細を含むサイドパネルにアクセスできます。このようなインタラクティブなアプローチにより、クラスター内のトラフィックパターンや接続の問題を迅速に特定できます。
複雑な環境を管理するために、Topology ビューには、レイアウトとデータ密度をカスタマイズできる高度な設定オプションが含まれています。ビューの Scope (範囲) を調整したり、リソースの所有権を表す Groups (グループ) を適用したり、さまざまな Layout (レイアウト) アルゴリズムを選択してグラフィック表示を最適化したりできます。さらに、Edge labels (エッジラベル) を有効にすることで、平均バイトレートなどのリアルタイムの測定値をフローの線上に直接表示できます。
レポート作成や外部での分析のために、Topology ビューはエクスポート機能を備えています。現在のグラフィック表示を PNG イメージとしてダウンロードすることも、特定のビュー設定への直接リンクを生成して他の管理者と共有することもできます。これらのツールにより、ネットワークに関する分析情報を容易に利用して記録に残すことができます。
10.3.1. Topology ビューの使用
Topology ビューにアクセスして、クラスターネットワークの関係を視覚的に確認し、個々のコンポーネントを選択して詳細なトラフィックメトリクスとメタデータを表示します。
管理者は、Topology ビューに移動して、コンポーネントの詳細とメトリクスを確認できます。
前提条件
- 管理者権限を持っている。
手順
- Observe → Network Traffic に移動します。
- Network Traffic ページで、Topology タブをクリックします。
- Topology タブで各コンポーネントをクリックし、その詳細とメトリクスを表示します。
10.3.2. Topology ビューの詳細オプションの設定
表示設定のカスタマイズ、コンポーネントのグループ化とレイアウトの設定、ネットワークグラフの画像としてのエクスポートを行うために、Topology ビューで利用可能な詳細オプションを確認します。
Show advanced options を使用して、ビューをカスタマイズおよびエクスポートできます。詳細オプションビューには、次の機能があります。
- Find in view で必要なコンポーネントを検索します。
Display options: 次のオプションを設定するには:
- Edge labels: 指定した測定値をエッジラベルとして表示します。デフォルトでは、Average rate が Bytes 単位で表示されます。
- Scope: ネットワークトラフィックが流れるコンポーネントのスコープを選択します。デフォルト値は Namespace です。
- Groups: コンポーネントをグループ化することにより、所有権をわかりやすくします。デフォルト値は None です。
- Layout: グラフィック表示のレイアウトを選択します。デフォルト値は ColaNoForce です。
- 表示: 表示する必要がある詳細を選択します。デフォルトでは、すべてのオプションがチェックされています。使用可能なオプションは、Edges、Edges label、および Badges です。
- Truncate labels: ドロップダウンリストから必要なラベルの幅を選択します。デフォルト値は M です。
- グループを Collapse groups を展開または折りたたみます。グループはデフォルトで展開されています。Groups の値が None の場合、このオプションは無効になります。
10.3.2.1. トポロジービューのエクスポート
ビューをエクスポートするには、Export topology view をクリックします。ビューは PNG 形式でダウンロードされます。
10.4. ネットワークトラフィックのフィルタリング
データ検索の最適化、特定のログタイプの分析、および方向性のあるトラフィックの表示の管理を行うために、Network Traffic ビューで利用可能なクエリーオプションとフィルタリングパラメーターを確認します。
デフォルトでは、Network Traffic ページには、FlowCollector インスタンスで設定されているデフォルトのフィルターに基づいて、クラスター内のトラフィックフローデータが表示されます。フィルターオプションを使用して、プリセットフィルターを変更することにより、必要なデータを観察できます。
または、Namespaces、Services、Routes、Nodes、および Workloads ページの Network Traffic タブでトラフィックフローデータにアクセスして、対応する集約のフィルタリングされたデータを提供します。
- クエリーオプション
以下に示すように、Query Options を使用して検索結果を最適化できます。
- Log Type: 利用可能なオプション Conversation と Flows では、フローログ、新しい会話、完了した会話、および長い会話の更新を含む定期的なレコードであるハートビートなどのログタイプ別にフローをクエリーする機能が提供されます。会話は、同じピア間のフローの集合体です。
- Match filters: 高度なフィルターで選択されたさまざまなフィルターパラメーター間の関係を決定できます。利用可能なオプションは、Match all と Match any です。Match all はすべての値に一致する結果を提供し、Match any は入力された値のいずれかに一致する結果を提供します。デフォルト値は Match all です。
- Datasource: クエリーに使用するデータソース (Loki、Prometheus、Auto) を選択できます。Loki ではなく Prometheus をデータソースとして使用すると、パフォーマンスが大幅に向上します。ただし、Prometheus がサポートするフィルターと集計は限られています。デフォルトのデータソースは Auto です。Auto の場合、Prometheus をサポートしているクエリーでは Prometheus を使用し、サポートしていないクエリーでは Loki を使用します。
Drops filter: 次のクエリーオプションを使用して、各レベルのドロップパケットを表示できます。
- Fully dropped の場合、パケットが完全にドロップされたフローレコードが表示されます。
- Containing drops の場合、ドロップが発生したが送信可能なフローレコードが表示されます。
- Without drops の場合、送信されたパケットを含むレコードが表示されます。
- All の場合、上記のレコードがすべて表示されます。
- Limit: 内部バックエンドクエリーのデータ制限。マッチングやフィルターの設定に応じて、トラフィックフローデータの数が指定した制限内で表示されます。
- クイックフィルター
-
Quick filters ドロップダウンメニューのデフォルト値は、
FlowCollector設定で定義されます。コンソールからオプションを変更できます。 - 高度なフィルター
- ドロップダウンリストからフィルタリングするパラメーターを選択することで、高度なフィルター (Common、Source、Destination) を設定できます。フローデータは選択に基づいてフィルタリングされます。適用されたフィルターを有効または無効にするには、フィルターオプションの下にリストされている適用されたフィルターをクリックします。
One way と
Back and forth のフィルタリングを切り替えることができます。
One way フィルターを使用すると、選択したフィルターに基づき Source および Destination トラフィックのみが表示されます。Swap を使用すると、Source および Destination トラフィックの方向ビューを変更できます。
Back and forth フィルターは、Source および Destination フィルターに対応する戻りトラフィックも含めて表示します。ネットワークトラフィックの方向性があるフローは、Traffic flows テーブルの Direction 列に、ノード間トラフィックの場合は Ingress`or `Egress として、シングルノード内のトラフィックの場合は `Inner` として表示されます。
Reset defaults をクリックすると、既存のフィルターが削除され、FlowCollector 設定で定義されたフィルターが適用されます。
テキスト値の指定規則を理解するには、Learn More をクリックしてください。
第11章 ネットワークオブザーバビリティーの健全性ルール
Network Observability Operator は、組み込みのメトリクスと OpenShift Container Platform モニタリングスタックを使用して、クラスターネットワークの健全性を報告するアラートを提供します。
ネットワークオブザーバビリティーの健全性アラートを利用するには、OpenShift Container Platform 4.16 以降が必要です。
11.1. ネットワークの健全性とパフォーマンスに関するオブザーバビリティールール
ネットワークオブザーバビリティーには、Prometheus ベースのルールを管理するシステムが組み込まれています。OpenShift Container Platform のアプリケーションとインフラストラクチャーの健全性とパフォーマンスを監視するには、これらのルールを使用します。
Network Observability Operator は、これらのルールを PrometheusRule リソースに変換します。Network Observability Operator は、以下のルールタイプをサポートしています。
-
アラートルール: ネットワーク異常やインフラストラクチャー障害の通知を行うために、Prometheus
AlertManagerによって管理されるルールを指定します。 - レコーディングルール: ダッシュボードのパフォーマンスと可視化を向上させるために、複雑な Prometheus Query Language (PromQL) 式を事前に計算して新しい時系列データとして保存することを指定します。
以下のコマンドを実行して、netobserv namespace 内の PrometheusRule リソースを表示します。
$ oc get prometheusrules -n netobserv -o yaml11.1.1. ネットワーク健全性の監視とアラートルール
Network Observability Operator には、ネットワークの異常やインフラストラクチャーの障害を検出するためのルールベースのシステムが組み込まれています。Operator は、設定をアラートルールに変換することで、OpenShift Container Platform の Web コンソールを介した自動監視とトラブルシューティングを可能にします。
11.1.1.1. 結果の監視
Network Observability Operator は、以下の領域にネットワークの状態を表示します。
- Alerting UI
-
特定のアラートは Observe → Alerting に表示されます。ここにある通知は Prometheus
AlertManagerを通じて管理されています。 - Network Health ダッシュボード
- Observe → Network Health にある専用ダッシュボードでは、クラスターネットワークの健全性に関する概要を確認できます。
Network Health ダッシュボードでは、問題の範囲を絞り込めるように、違反が以下のタブに分類されます。
- Global: クラスター全体の総合的な健全性。
- Nodes: インフラストラクチャーノードに固有の違反。
- Namespaces: 個々の namespace に固有の違反。
-
Workloads:
DeploymentsやDaemonSetsなどのリソースに固有の違反。
11.1.1.2. 事前定義済みの健全性ルール
Network Observability Operator には、一般的なネットワーク環境向けのデフォルトルールが用意されています。これらのルールは、対応する機能が FlowCollector カスタムリソース (CR) で有効になっている場合にのみ有効になります。
以下のリストに、利用可能なデフォルトルールの一部を示します。
PacketDropsByDevice-
ネットワークデバイスからのパケットドロップ率が高い場合にトリガーされます。これは標準的なノードエクスポーターのメトリクスに基づいており、
PacketDropエージェント機能は必要ありません。 PacketDropsByKernel-
カーネルによるパケットドロップ率が高い場合にトリガーされます。
PacketDropエージェント機能が必要です。 IPsecErrors-
IPsec 暗号化エラーが検出された場合にトリガーされます。
IPSecエージェント機能が必要です。 NetpolDenied-
ネットワークポリシーによって拒否されたトラフィックが検出された場合にトリガーされます。
NetworkEventsエージェント機能が必要です。 LatencyHighTrend-
TCP 遅延の大幅な増加が検出された場合にトリガーされます。
FlowRTTエージェント機能が必要です。 DNSErrors-
DNS エラーが検出された際にトリガーされます。
DNSTrackingエージェント機能が必要です。
Network Observability Operator の運用アラート:
NetObservNoFlows- パイプラインがアクティブであるにもかかわらず、フローが観測されない場合にトリガーされます。
NetObservLokiError- Loki のエラーが原因でフローがドロップされた場合にトリガーされます。
ルールとランブックの完全なリストについては、Network Observability Operator のランブック を参照してください。
11.1.1.3. ルールの依存関係と機能の要件
Network Observability Operator は、FlowCollector カスタムリソース (CR) で有効になっている機能に基づいてルールを作成します。
たとえば、パケットドロップ関連のルールは、PacketDrop エージェント機能が有効な場合にのみ作成されます。ルールはメトリクスに基づいて構築されます。必要なメトリクスが不足している場合、設定に関する警告が表示される可能性があります。メトリクスは、FlowCollector リソースの spec.processor.metrics.includeList オブジェクトで設定します。
11.2. レコーディングルールによるパフォーマンス最適化
大規模クラスターの場合、レコーディングルールにより、Prometheus がネットワークデータを処理する方法が最適化されます。レコーディングルールを設定することで、ダッシュボードの応答性が向上し、複雑なクエリーの計算負荷が軽減されます。
11.2.1. 最適化の利点
レコーディングルールは、複雑な Prometheus Query Language (PromQL) 式を事前に計算し、その結果を新しい時系列データとして保存します。アラートルールとは異なり、レコーディングルールはしきい値を監視しません。
レコーディングルールを使用することには、次のような利点があります。
- パフォーマンスの向上
- Prometheus クエリーを事前に計算しておくことで、長期的な傾向をその都度計算するのを回避し、ダッシュボードの読み込み速度を向上できます。
- リソース効率
- 一定間隔でデータを計算すると、ダッシュボードの更新ごとにデータを再計算する場合と比較して、Prometheus サーバーの CPU 負荷が軽減されます。
- クエリーの簡素化
-
cluster:network_traffic:rate_5mなどの短いメトリクス名を使用すると、カスタムダッシュボードでの複雑な集計が簡素化されます。
11.2.2. ルールモードの比較
以下の表は、期待される結果に基づいてルールモードを比較したものです。
| 説明 | アラートルール | レコーディングルール |
|---|---|---|
| 目的 | 問題の通知。 | 高レベルのメトリクスの履歴を保存します。 |
| データの結果 | アラート状態を生成します。 | 永続的なメトリクスを作成します。 |
| 表示 | Alerting UI と Network Health ビュー。 | Metrics Explorer と Network Health ビュー。 |
| 通知 |
| 通知はトリガーされません。 |
11.3. ネットワークオブザーバビリティーの健全性ルールの構造とカスタマイズ
Network Observability Operator の健全性ルールは、FlowCollector カスタムリソース (CR) の spec.processor.metrics.healthRules オブジェクト内のルールテンプレートとバリアントを使用して定義されます。デフォルトのテンプレートとバリアントをカスタマイズして、柔軟できめ細かなアラートを作成できます。
テンプレートごとに、それぞれ固有のしきい値とグループ化設定を持つバリアントのリストを定義できます。詳細は、「デフォルトのアラートテンプレートのリスト」を参照してください。
次の例はアラートを示しています。
apiVersion: flows.netobserv.io/v1beta1
kind: FlowCollector
metadata:
name: flow-collector
spec:
processor:
metrics:
healthRules:
- template: PacketDropsByKernel
mode: Alert # or Recording
variants:
# triggered when the whole cluster traffic (no grouping) reaches 10% of drops
- thresholds:
critical: "10"
# triggered when per-node traffic reaches 5% of drops, with gradual severity
- thresholds:
critical: "15"
warning: "10"
info: "5"
groupBy: Node各項目の説明:
spec.processor.metrics.healthRules.template- 定義済みのルールテンプレートの名前を指定します。
spec.processor.metrics.healthRules.mode-
ルールを
Alertとして機能させるか、Recordingルールとして機能させるかを指定します。この設定は、バリアントごとに定義することも、テンプレート全体に対して定義することもできます。 spec.processor.metrics.healthRules.variants.thresholds-
ルールをトリガーする数値を指定します。1 つのバリアント内で、複数の重大度 (
critical、warning、infoなど) を定義できます。 cluster-wide variant-
groupBy設定なしで定義したバリアントを指定します。上記の例では、このバリアントはクラスター全体のトラフィックが 10% 減少したときにトリガーされます。 spec.processor.metrics.healthRules.variants.groupBy- メトリクスを集計するために使用するディメンションを指定します。上記の例では、アラートは *Node8 ごとに個別に評価されます。
ルールをカスタマイズすると、そのテンプレートのデフォルト設定が置き換えられます。デフォルト設定を維持する場合は、手動で複製する必要があります。
11.3.1. 健全性ルールの PromQL 式とメタデータ
Prometheus Query Language (PromQL) のベースクエリーと、それをカスタマイズして特定のニーズに合わせて Network Observability アラートを設定する方法を説明します。
ネットワークオブザーバビリティーの FlowCollector カスタムリソース (CR) 内の健全性ルール API は、Prometheus Operator API にマッピングされ、PrometheusRule を生成します。次のコマンドを実行すると、デフォルトの netobserv namespace 内の PrometheusRule を確認できます。
$ oc get prometheusrules -n netobserv -oyaml11.3.1.1. 受信トラフィックの急増に関するアラートのクエリー例
この例では、受信トラフィックの急増に関するアラートの PromQL ベースクエリーパターンを示します。
sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m])) by (DstK8S_Namespace)
このクエリーは、過去 30 分間に openshift-ingress namespace からいずれかのワークロードの namespace に送信されたバイトレートを計算します。
このクエリーをカスタマイズして、一部のレートのみを保持したり、特定の期間にクエリーを実行したり、最終的なしきい値を設定したりできます。
- ノイズのフィルタリング
このクエリーに
> 1000を追加すると、1 KB/sを超える観測レートのみが保持され、通信量が少ないコンシューマーからのノイズが除去されます。(sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m])) by (DstK8S_Namespace) > 1000)バイトレートは、
FlowCollectorカスタムリソース (CR) 設定で定義されたサンプリング間隔と相対的な関係にあります。サンプリング間隔が1:100の場合、実際のトラフィックは報告されたメトリクスの約 100 倍であると考えられます。- 期間の比較
offset修飾子を使用すると、特定の期間に同じクエリーを実行できます。たとえば、offset 1d使用すると 1 日前にクエリーを実行でき、offset 5hを使用すると 5 時間前にクエリーを実行できます。sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m] offset 1d)) by (DstK8S_Namespace))100 * (<query now> - <query from the previous day>) / <query from the previous day>という数式を使用すると、前日と比較した増加率を計算できます。今日のバイトレートが前日よりも低い場合、この値は負になることがあります。- 最終的なしきい値
-
最終的なしきい値を適用すると、目的のパーセンテージに満たない増加分を除外できます。たとえば、
> 100は 100% 未満の増加分を除外します。
まとめると、PrometheusRule の完全な式は次のようになります。
...
expr: |-
(100 *
(
(sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m])) by (DstK8S_Namespace) > 1000)
- sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m] offset 1d)) by (DstK8S_Namespace)
)
/ sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m] offset 1d)) by (DstK8S_Namespace))
> 10011.3.1.2. アラートのメタデータフィールド
Network Observability Operator は、モニタリングスタックなど、他の OpenShift Container Platform 機能のコンポーネントを使用して、ネットワークトラフィックの可視性を強化します。詳細は、「モニタリングスタックアーキテクチャー」を参照してください。
ルールを定義するには、いくつかのメタデータを設定する必要があります。このメタデータは、モニタリングスタックの Prometheus および Alertmanager サービス、または Network Health ダッシュボードによって使用されます。
次の例は、メタデータが設定された AlertingRule リソースを示しています。
apiVersion: monitoring.openshift.io/v1
kind: AlertingRule
metadata:
name: netobserv-alerts
namespace: openshift-monitoring
spec:
groups:
- name: NetObservAlerts
rules:
- alert: NetObservIncomingBandwidth
annotations:
netobserv_io_network_health: '{"namespaceLabels":["DstK8S_Namespace"],"threshold":"100","unit":"%","upperBound":"500"}'
message: |-
NetObserv is detecting a surge of incoming traffic: current traffic to {{ $labels.DstK8S_Namespace }} has increased by more than 100% since yesterday.
summary: "Surge in incoming traffic"
expr: |-
(100 *
(
(sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m])) by (DstK8S_Namespace) > 1000)
- sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m] offset 1d)) by (DstK8S_Namespace)
)
/ sum(rate(netobserv_workload_ingress_bytes_total{SrcK8S_Namespace="openshift-ingress"}[30m] offset 1d)) by (DstK8S_Namespace))
> 100
for: 1m
labels:
app: netobserv
netobserv: "true"
severity: warning各項目の説明:
spec.groups.rules.alert.labels.netobserv-
trueに設定すると、このアラートが、Network Health ダッシュボードによって検出されるべきアラートとして指定されます。 spec.groups.rules.alert.labels.severity-
アラートの重大度を指定します。有効な値は、
critical、warning、またはinfoです。
message アノテーションで定義されている PromQL 式からの出力ラベルを活用できます。この例では、結果が DstK8S_Namespace ごとにグループ化されるため、メッセージテキストで {{ $labels.DstK8S_Namespace }} という式が使用されています。
netobserv_io_network_health アノテーションは任意であり、Network Health ページでアラートをどのようにレンダリングするかを制御します。
netobserv_io_network_health アノテーションは、次のフィールドで構成される JSON 文字列です。
| フィールド | 型 | 説明 |
|---|---|---|
|
| 文字列のリスト | namespace を保持する 1 つ以上のラベル。指定すると、アラートが Namespaces タブに表示されます。 |
|
| 文字列のリスト | ノード名を保持する 1 つ以上のラベル。指定すると、アラートが Nodes タブに表示されます。 |
|
| 文字列のリスト |
所有者/ワークロードの名前を保持する 1 つ以上のラベル。 |
|
| 文字列のリスト |
所有者/ワークロードの種類を保持する 1 つ以上のラベル。 |
|
| 文字列 |
アラートしきい値。 |
|
| 文字列 | 表示目的でのみ使用されるデータ単位。 |
|
| 文字列 | 閉じた尺度でスコアを計算するために使用される上限値。この上限を超えるメトリクス値は丸められます。 |
|
| オブジェクトのリスト |
アラートに応じて表示されるリンクのリスト。各リンクには、 |
|
| 文字列 |
URL を構築するための、Network Traffic ページへのリンクに関する情報。 |
namespaceLabels と nodeLabels は相互に排他的です。どちらも指定されていない場合は、Global タブにアラートが表示されます。
| フィールド | 説明 |
|---|---|
|
| 追加で注入するフィルター (たとえば、DNS 関連のアラートの場合は DNS レスポンスコード)。 |
|
|
フィルターに戻りトラフィックを含めるかどうか ( |
|
|
フィルターがトラフィックの送信元ではなく宛先を対象とするかどうか ( |
11.3.2. カスタム健全性ルールの設定
Prometheus Query Language (PromQL) を使用して、特定のネットワークメトリクス (トラフィックの急増など) に基づいてアラートをトリガーするカスタム AlertingRule リソースを定義します。
前提条件
-
PromQLに関する知識。 - OpenShift Container Platform 4.16 以降がインストールされている。
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - Network Observability Operator がインストールされている。
手順
-
AlertingRuleリソースを含む、custom-alert.yamlという名前の YAML ファイルを作成します。 次のコマンドを実行して、カスタムアラートルールを適用します。
$ oc apply -f custom-alert.yaml
検証
次のコマンドを実行して、
PrometheusRuleリソースがnetobservnamespace に作成されたことを確認します。$ oc get prometheusrules -n netobserv -oyaml出力に、作成した
netobserv-alertsルールが含まれているはずです。これにより、リソースが正しく生成されたことを確認できます。- OpenShift Container Platform Web コンソールの Network Health ダッシュボード → Observe をチェックして、ルールがアクティブであることを確認します。
11.4. 定義済みルールの無効化
FlowCollector カスタムリソース (CR) の spec.processor.metrics.disableAlerts フィールドで、ルールテンプレートを無効にできます。この設定には、ルールテンプレート名のリストを指定できます。アラートテンプレート名のリストは、「デフォルトのルールのリスト」を参照してください。
テンプレートが無効化され、かつ spec.processor.metrics.healthRules フィールドでオーバーライドされている場合、無効化の設定が優先され、アラートルールは作成されません。
第12章 ダッシュボードとアラートでのメトリクスの使用
Network Observability Operator は、flowlogs-pipeline コンポーネントを使用して、フローログからメトリクスを生成します。カスタムアラートを設定し、ネットワークアクティビティー分析用のダッシュボードを表示するには、これらのメトリクスを使用します。
12.1. Network Observability メトリクスのダッシュボードの表示
OpenShift Container Platform コンソールの Overview タブを使用してネットワークオブザーバビリティーメトリクスダッシュボードを表示し、全体的なトラフィックフローとシステムの健全性を監視します。必要に応じて、ノード、namespace、所有者、Pod、サービスでメトリクスをフィルタリングできます。
手順
- Web コンソールの Observe → Dashboards で、Netobserv ダッシュボードを選択します。
次のカテゴリーのネットワークトラフィックメトリクスを表示します。各カテゴリーには、ノード、namespace、送信元、宛先ごとのサブセットがあります。
- バイトレート
- パケットドロップ
- DNS
- RTT
- Netobserv/Health ダッシュボードを選択します。
Operator の健全性に関する次のカテゴリーのメトリクスを表示します。各カテゴリーには、ノード、namespace、送信元、宛先ごとのサブセットがあります。
- フロー
- フローのオーバーヘッド
- フローレート
- エージェント
- プロセッサー
Operator
Infrastructure および Application メトリクスは、namespace とワークロードの分割ビューで表示されます。
12.2. ネットワークオブザーバビリティーメトリクス
netobserv_ というプレフィックスが付いたネットワークオブザーバビリティーメトリクスの包括的なリストを確認します。これは、FlowCollector リソースで設定でき、トラフィックを監視して Prometheus アラートを作成するために使用できます。
flowlogs-pipeline によって生成されるメトリクスは、FlowCollector カスタムリソースの spec.processor.metrics.includeList で設定して追加または削除できます。
Prometheus ルールの includeList メトリクスを使用してアラートを作成することもできます。「アラートの作成」の例を参照してください。
コンソールで Observe → Metrics を選択するなどして Prometheus でこれらのメトリクスを探す場合、またはアラートを定義する場合、すべてのメトリクス名に netobserv_ という接頭辞が付きます。たとえば、netobserv_namespace_flows_total です。利用可能なメトリクス名は以下のとおりです。
- includeList のメトリクス名
名前の後にアスタリスク
*が付いているものは、デフォルトで有効です。-
namespace_egress_bytes_total -
namespace_egress_packets_total -
namespace_ingress_bytes_total -
namespace_ingress_packets_total -
namespace_flows_total* -
node_egress_bytes_total -
node_egress_packets_total -
node_ingress_bytes_total* -
node_ingress_packets_total -
node_flows_total -
workload_egress_bytes_total -
workload_egress_packets_total -
workload_ingress_bytes_total* -
workload_ingress_packets_total -
workload_flows_total
-
- PacketDrop のメトリクス名
PacketDrop機能が (privilegedモードにより)spec.agent.ebpf.featuresで有効になっている場合、次の追加のメトリクスを使用できます。-
namespace_drop_bytes_total -
namespace_drop_packets_total* -
node_drop_bytes_total -
node_drop_packets_total -
workload_drop_bytes_total -
workload_drop_packets_total
-
- DNS のメトリクス名
DNSTracking機能がspec.agent.ebpf.featuresで有効になっている場合、次の追加のメトリクスを使用できます。-
namespace_dns_latency_seconds* -
node_dns_latency_seconds -
workload_dns_latency_seconds
-
- FlowRTT のメトリクス名
FlowRTT機能がspec.agent.ebpf.featuresで有効になっている場合、次の追加のメトリクスを使用できます。-
namespace_rtt_seconds* -
node_rtt_seconds -
workload_rtt_seconds
-
- ネットワークイベントメトリクス名
NetworkEvents機能が有効になっている場合、このメトリクスはデフォルトで利用できます。-
namespace_network_policy_events_total
-
12.3. アラートの作成
Netobserv ダッシュボードメトリクスに基づいてカスタム AlertingRule リソースを作成し、OpenShift Container Platform コンソールでアラートをトリガーする条件を定義します。
前提条件
- cluster-admin ロールを持つユーザー、またはすべてのプロジェクトの表示権限を持つユーザーとしてクラスターにアクセスできる。
- Network Observability Operator がインストールされています。
手順
- インポートアイコン + をクリックして、YAML ファイルを作成します。
アラートルール設定を YAML ファイルに追加します。次の YAML サンプルでは、クラスターの Ingress トラフィックが宛先ワークロードごとの指定しきい値 (10 MBps) に達したときに、アラートが作成されます。
apiVersion: monitoring.openshift.io/v1 kind: AlertingRule metadata: name: netobserv-alerts namespace: openshift-monitoring spec: groups: - name: NetObservAlerts rules: - alert: NetObservIncomingBandwidth annotations: message: |- {{ $labels.job }}: incoming traffic exceeding 10 MBps for 30s on {{ $labels.DstK8S_OwnerType }} {{ $labels.DstK8S_OwnerName }} ({{ $labels.DstK8S_Namespace }}). summary: "High incoming traffic." expr: sum(rate(netobserv_workload_ingress_bytes_total {SrcK8S_Namespace="openshift-ingress"}[1m])) by (job, DstK8S_Namespace, DstK8S_OwnerName, DstK8S_OwnerType) > 10000000 for: 30s labels: severity: warning-
netobserv_workload_ingress_bytes_totalメトリクスは、spec.processor.metrics.includeListでデフォルトで有効です。
-
- Create をクリックして設定ファイルをクラスターに適用します。
12.4. カスタムメトリクス
FlowMetric API を使用してフローログデータからカスタムメトリクスを定義します。このとき、ログフィールドを Prometheus ラベルとして活用してダッシュボード情報をカスタマイズし、特定のクラスターデータを監視します。
収集されるすべてのフローログデータには、送信元名や宛先名など、ログごとのラベルが付けられたフィールドがいくつかあります。これらのフィールドを Prometheus ラベルとして活用して、ダッシュボード上のクラスター情報をカスタマイズできます。
12.5. FlowMetric API を使用したカスタムメトリクスの設定
特定の監視ニーズを満たすために、フローログフィールドをラベルとしてマッピングしてカスタム Prometheus メトリクスを作成するように FlowMetric API を設定します。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しで、FlowMetric を選択します。
- Project: ドロップダウンリストで、Network Observability Operator インスタンスのプロジェクトを選択します。
- Create FlowMetric をクリックします。
-
FlowMetricリソースを設定します。「カスタムメトリクスの設定例」を参照してください。
検証
- Pod が更新されたら、Observe → Metrics に移動します。
-
Expression フィールドにメトリクス名を入力して、対応する結果を表示します。
topk(5, sum(rate(netobserv_cluster_external_ingress_bytes_total{DstK8S_Namespace="my-namespace"}[2m])) by (DstK8S_HostName, DstK8S_OwnerName, DstK8S_OwnerType))などの式を入力することもできます。
12.5.1. カスタムメトリクスの設定例
外部トラフィック量やレイテンシーの急増など、デフォルトのメトリクスの対象に含まれていない特定のネットワーク動作を監視するには、FlowMetric カスタムリソース (CR) を使用します。以下の例は、ネットワークフローから特定の Prometheus メトリクスを生成するために必要な設定を示しています。
12.5.1.1. クラスター外部ソースからの Ingress バイト数を追跡する
外部ネットワークからクラスターに流入するデータ量を測定するには、以下の FlowMetric 設定を使用します。このメトリクスは、潜在的な帯域幅の問題や予期しない外部データ転送コストを特定するのに役立ちます。
apiVersion: flows.netobserv.io/v1alpha1
kind: FlowMetric
metadata:
name: flowmetric-cluster-external-ingress-traffic
namespace: netobserv
spec:
metricName: cluster_external_ingress_bytes_total
type: Counter
valueField: Bytes
direction: Ingress
labels: [DstK8S_HostName,DstK8S_Namespace,DstK8S_OwnerName,DstK8S_OwnerType]
filters:
- field: SrcSubnetLabel
matchType: Absence各項目の説明:
metadata.namespace-
FlowMetricリソースを作成する namespace を指定します。これは、FlowCollectorリソースのspec.namespaceフィールドで定義されている namespace と一致する必要があります。デフォルトではnetobservです。 spec.metricName-
Prometheus メトリクスの名前を指定します。OpenShift Container Platform の Web コンソールには、
netobserv-<metricName>というプレフィックス付きで表示されます。 spec.type-
メトリクスのタイプを指定します。
Counterタイプは、バイト数やパケット数をカウントするのに役立ちます。 spec.direction- キャプチャーするトラフィックの方向を指定します。指定しない場合は、Ingress と Egress の両方がキャプチャーされ、重複したカウントが発生する可能性があります。
spec.labels-
メトリクスの見え方、異なるエンティティー間の関係、およびメトリクスのカーディナリティーを定義するラベルを指定します。たとえば、
SrcK8S_Nameはカーディナリティーが高いメトリクスです。 spec.filters-
リストした条件に基づいて結果を絞り込むための基準を指定します。この例では、
SrcSubnetLabelが存在しないフローのみを照合することによって、クラスターの外部トラフィックのみを選択します。これは、サブネットラベル機能が (spec.processor.subnetLabelsで) 有効になっていることを前提としています。これはデフォルトで有効になっています。
12.5.1.2. クラスター外部の Ingress トラフィックの RTT 遅延を監視する
外部接続のパフォーマンスを分析し、高遅延のパスを特定するには、以下の FlowMetric 設定を使用してください。このメトリクスは、標準的な Prometheus の遅延ダッシュボードに合わせるために、ナノ秒を秒に変換します。
apiVersion: flows.netobserv.io/v1alpha1
kind: FlowMetric
metadata:
name: flowmetric-cluster-external-ingress-rtt
namespace: netobserv
spec:
metricName: cluster_external_ingress_rtt_seconds
type: Histogram
valueField: TimeFlowRttNs
direction: Ingress
labels: [DstK8S_HostName,DstK8S_Namespace,DstK8S_OwnerName,DstK8S_OwnerType]
filters:
- field: SrcSubnetLabel
matchType: Absence
- field: TimeFlowRttNs
matchType: Presence
divider: "1000000000"
buckets: [".001", ".005", ".01", ".02", ".03", ".04", ".05", ".075", ".1", ".25", "1"]各項目の説明:
metadata.namespace-
FlowMetricリソースを作成する namespace を指定します。これは、FlowCollectorリソースのspec.namespaceフィールドで定義されている namespace と一致する必要があります。デフォルトではnetobservです。 spec.type-
メトリクスのタイプを指定します。
Histogramタイプは、TimeFlowRttNsなどの遅延値に役立ちます。 spec.divider- メトリクスを分割するために使用する値を指定します。フローではラウンドトリップタイム (RTT) がナノ秒単位で提供されるため、1,000,000,000 を除数として秒に変換してください。これは Prometheus ガイドラインの標準です。
spec.buckets- RTT の精度を高めるためにカスタムバケットを指定します。最適な精度の範囲は 5ms から 250ms です。
12.6. Traffic flows テーブルのネストされたフィールドまたは配列フィールドからメトリクスを作成する
FlowMetric カスタムリソースを作成して、Traffic flows テーブル内のネストされたフィールドまたは配列フィールド (Network events や Interfaces など) のメトリクスを生成します。
OVN Observability/NetworkEvents の表示はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
OVN Observability とネットワークイベントの表示および追跡機能は、OpenShift Container Platform 4.17 および 4.18 でのみ利用できます。
次の例は、ネットワークポリシーイベントの Network events フィールドからメトリクスを生成する方法を示しています。
前提条件
-
NetworkEvents featureを有効にする。これを行う方法は、関連情報を参照してください。 - ネットワークポリシーが指定されている。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しで、FlowMetric を選択します。
- Project ドロップダウンリストで、Network Observability Operator インスタンスのプロジェクトを選択します。
- Create FlowMetric をクリックします。
FlowMetricリソースを作成して、次の設定を追加します。ポリシー名と namespace ごとにネットワークポリシーイベントをカウントする設定
apiVersion: flows.netobserv.io/v1alpha1 kind: FlowMetric metadata: name: network-policy-events namespace: netobserv spec: metricName: network_policy_events_total type: Counter labels: [NetworkEvents>Type, NetworkEvents>Namespace, NetworkEvents>Name, NetworkEvents>Action, NetworkEvents>Direction] filters: - field: NetworkEvents>Feature value: acl flatten: [NetworkEvents] remap: "NetworkEvents>Type": type "NetworkEvents>Namespace": namespace "NetworkEvents>Name": name "NetworkEvents>Direction": direction各項目の説明:
spec.labels-
Traffic flows テーブルの Network Events のネストされたフィールドを表すラベルを指定します。各ネットワークイベントには、特定のタイプ、namespace、名前、アクション、方向があります。使用している OpenShift Container Platform のバージョンで
NetworkEventsが利用できない場合は、代わりにInterfacesを指定することもできます。 spec.flatten- 個別の項目として表現される項目のリストを含むオプションのフィールドを指定します。
spec.remap- Prometheus 上で名前を変更するためのオプションのフィールド群を指定します。
検証
- Web コンソールで、Observe → Dashboards に移動し、下にスクロールして Network Policy タブを表示します。
- 作成したメトリクスとネットワークポリシー仕様に基づき、メトリクスのフィルタリングが適用されているはずです。
カーディナリティーが高いと、Prometheus のメモリー使用量に影響する可能性があります。ネットワークフロー形式で、特定のラベルのカーディナリティーが高いかどうかを確認できます。「ネットワークフロー形式のリファレンス」を参照してください。
12.7. FlowMetric API を使用したカスタムグラフの設定
FlowMetric カスタムリソースのチャートセクションを定義して、OpenShift Container Platform Web コンソールダッシュボードのカスタムチャートを生成します。
管理者は、Dashboard メニューでカスタムチャートを表示できます。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しで、FlowMetric を選択します。
- Project: ドロップダウンリストで、Network Observability Operator インスタンスのプロジェクトを選択します。
- Create FlowMetric をクリックします。
-
FlowMetricリソースを設定します。「FlowMetric グラフの設定例」を参照してください。
検証
- Pod が更新されたら、Observe → Dashboards に移動します。
NetObserv / Main ダッシュボードを検索します。NetObserv / Main ダッシュボードの下、または必要に応じて作成したダッシュボード名の下にある次の 2 つのパネルを確認します。
- すべてのディメンションにわたりグローバルな外部 Ingress レートを合計したテキスト形式の単一の統計
- 上記と同じメトリクスを示す、宛先ワークロードごとの時系列グラフ
クエリー言語の詳細は、Prometheus のドキュメント を参照してください。
12.7.1. FlowMetric グラフの設定例
以下の FlowMetric カスタムリソースの例は、外部からの Ingress トラフィックとラウンドトリップタイム (RTT) の遅延を追跡するために、OpenShift Container Platform の Web コンソールでグラフを定義する方法を示しています。
12.7.1.1. クラスター外部ソースの Ingress バイト数のグラフ
クラスター外部ソースからの Ingress トラフィックのレートを追跡するには、以下の設定を使用してください。これらのグラフは、ワークロードごとの帯域幅使用量を把握するのに役立ちます。
apiVersion: flows.netobserv.io/v1alpha1
kind: FlowMetric
metadata:
name: flowmetric-cluster-external-ingress-traffic
namespace: netobserv
# ...
charts:
- dashboardName: Main
title: External ingress traffic
unit: Bps
type: SingleStat
queries:
- promQL: "sum(rate($METRIC[2m]))"
legend: ""
- dashboardName: Main
sectionName: External
title: Top external ingress traffic per workload
unit: Bps
type: StackArea
queries:
- promQL: "sum(rate($METRIC{DstK8S_Namespace!=\"\"}[2m])) by (DstK8S_Namespace, DstK8S_OwnerName)"
legend: "{{DstK8S_Namespace}} / {{DstK8S_OwnerName}}"
# ...各項目の説明:
metadata.namespace-
FlowMetricリソースを作成する namespace を指定します。これは、FlowCollectorのspec.namespaceで定義されている namespace と一致する必要があります。デフォルトではnetobservです。 spec.charts.dashboardName-
ダッシュボードの名前を指定します。異なる
dashboardNameを使用すると、接頭辞がNetobservである新しいダッシュボードが作成されます。たとえば、Netobserv / <dashboard_name> です。
12.7.1.2. クラスター外部 Ingress トラフィックの RTT 遅延のグラフ
クラスター外部からの Ingress トラフィックのラウンドトリップタイム (RTT) を監視するには、以下の設定を使用してください。以下の例では、histogram_quantile 関数を使用して 50 パーセンタイルと 99 パーセンタイル (p50 と p99) を表示します。
apiVersion: flows.netobserv.io/v1alpha1
kind: FlowMetric
metadata:
name: flowmetric-cluster-external-ingress-traffic
namespace: netobserv
# ...
charts:
- dashboardName: Main
title: External ingress TCP latency
unit: seconds
type: SingleStat
queries:
- promQL: "histogram_quantile(0.99, sum(rate($METRIC_bucket[2m])) by (le)) > 0"
legend: "p99"
- dashboardName: Main
sectionName: External
title: "Top external ingress sRTT per workload, p50 (ms)"
unit: seconds
type: Line
queries:
- promQL: "histogram_quantile(0.5, sum(rate($METRIC_bucket{DstK8S_Namespace!=\"\"}[2m])) by (le,DstK8S_Namespace,DstK8S_OwnerName))*1000 > 0"
legend: "{{DstK8S_Namespace}} / {{DstK8S_OwnerName}}"
- dashboardName: Main
sectionName: External
title: "Top external ingress sRTT per workload, p99 (ms)"
unit: seconds
type: Line
queries:
- promQL: "histogram_quantile(0.99, sum(rate($METRIC_bucket{DstK8S_Namespace!=\"\"}[2m])) by (le,DstK8S_Namespace,DstK8S_OwnerName))*1000 > 0"
legend: "{{DstK8S_Namespace}} / {{DstK8S_OwnerName}}"
# ...各項目の説明:
metadata.namespace-
FlowMetricリソースを作成する namespace を指定します。これは、FlowCollectorのspec.namespaceで定義されている namespace と一致する必要があります。デフォルトではnetobservです。 spec.charts.dashboardName-
ダッシュボードの名前を指定します。異なる
dashboardNameを使用すると、接頭辞がNetobservである新しいダッシュボードが作成されます。たとえば、Netobserv / <dashboard_name> です。
12.7.1.3. ヒストグラムの平均を計算する
ヒストグラムを作成するときに自動的に生成されるメトリクス $METRIC_sum をメトリクス $METRIC_count で割ることで、ヒストグラムの平均を表示できます。前述の例では、これを実行するための Prometheus クエリーは次のとおりです。
promQL: "(sum(rate($METRIC_sum{DstK8S_Namespace!=\"\"}[2m])) by (DstK8S_Namespace,DstK8S_OwnerName) / sum(rate($METRIC_count{DstK8S_Namespace!=\"\"}[2m])) by (DstK8S_Namespace,DstK8S_OwnerName))*1000"12.8. FlowMetric API と TCP フラグを使用した SYN フラッディングの検出
TCP フラグを監視するカスタムの AlertingRule および FlowMetric 設定をデプロイし、クラスターに対する SYN フラッディング攻撃をリアルタイムで検出し、警告できるようにします。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しで、FlowMetric を選択します。
- Project ドロップダウンリストで、Network Observability Operator インスタンスのプロジェクトを選択します。
- Create FlowMetric をクリックします。
FlowMetricリソースを作成して、次の設定を追加します。TCP フラグを使用して、宛先ホストとリソースごとにフローをカウントする設定
apiVersion: flows.netobserv.io/v1alpha1 kind: FlowMetric metadata: name: flows-with-flags-per-destination spec: metricName: flows_with_flags_per_destination_total type: Counter labels: [SrcSubnetLabel,DstSubnetLabel,DstK8S_Name,DstK8S_Type,DstK8S_HostName,DstK8S_Namespace,Flags]TCP フラグを使用して、ソースホストとリソースごとにフローをカウントする設定
apiVersion: flows.netobserv.io/v1alpha1 kind: FlowMetric metadata: name: flows-with-flags-per-source spec: metricName: flows_with_flags_per_source_total type: Counter labels: [DstSubnetLabel,SrcSubnetLabel,SrcK8S_Name,SrcK8S_Type,SrcK8S_HostName,SrcK8S_Namespace,Flags]SYN フラッディングを警告するための次の
AlertingRuleリソースをデプロイします。SYN フラッディングの
AlertingRuleapiVersion: monitoring.openshift.io/v1 kind: AlertingRule metadata: name: netobserv-syn-alerts namespace: openshift-monitoring # ... spec: groups: - name: NetObservSYNAlerts rules: - alert: NetObserv-SYNFlood-in annotations: message: |- {{ $labels.job }}: incoming SYN-flood attack suspected to Host={{ $labels.DstK8S_HostName}}, Namespace={{ $labels.DstK8S_Namespace }}, Resource={{ $labels.DstK8S_Name }}. This is characterized by a high volume of SYN-only flows with different source IPs and/or ports. summary: "Incoming SYN-flood" expr: sum(rate(netobserv_flows_with_flags_per_destination_total{Flags="2"}[1m])) by (job, DstK8S_HostName, DstK8S_Namespace, DstK8S_Name) > 300 for: 15s labels: severity: warning app: netobserv - alert: NetObserv-SYNFlood-out annotations: message: |- {{ $labels.job }}: outgoing SYN-flood attack suspected from Host={{ $labels.SrcK8S_HostName}}, Namespace={{ $labels.SrcK8S_Namespace }}, Resource={{ $labels.SrcK8S_Name }}. This is characterized by a high volume of SYN-only flows with different source IPs and/or ports. summary: "Outgoing SYN-flood" expr: sum(rate(netobserv_flows_with_flags_per_source_total{Flags="2"}[1m])) by (job, SrcK8S_HostName, SrcK8S_Namespace, SrcK8S_Name) > 300 for: 15s labels: severity: warning app: netobserv # ...この例では、アラートのしきい値は
300ですが、この値は環境に応じて調整できます。しきい値が低すぎると誤検出が発生する可能性があります。また、しきい値が高すぎると実際の攻撃を見逃す可能性があります。
検証
- Web コンソールで、Network Traffic テーブルビューの Manage Columns をクリックし、TCP flags をクリックします。
- Network Traffic テーブルビューで、TCP protocol SYN TCPFlag でフィルタリングします。同じ byteSize を持つフローが多数ある場合は、SYN フラッドが発生しています。
- Observe → Alerting に移動し、Alerting Rules タブを選択します。
- netobserv-synflood-in alert でフィルタリングします。SYN フラッディングが発生すると、アラートが起動するはずです。
第13章 Network Observability Operator の監視
OpenShift Container Platform Web コンソールを使用して、Network Observability Operator の健全性に関連するアラートを監視します。これにより、システムの安定性を維持し、運用上の問題を迅速に検出できます。
13.1. 健全性ダッシュボード
OpenShift Container Platform の Web コンソールで Network Observability Operator の健全性ダッシュボードを表示すると、Operator とそのコンポーネントの健全性ステータス、リソース使用量、および内部統計情報を監視できます。
メトリクスは、OpenShift Container Platform Web コンソールの Observe → Dashboards ページにあります。Network Observability Operator の健全性に関する次のカテゴリーのメトリクスを表示できます。
- 1 秒あたりのフロー数
- Sampling
- 過去 1 分間のエラー数
- 1 秒あたりのドロップされたフロー数
- flowlogs-pipeline 統計
- flowlogs-pipeline 統計ビュー
- eBPF エージェント統計ビュー
- Operator 統計
- リソースの使用状況
13.2. 健全性アラート
Network Observability Operator によって生成される健全性アラートについて説明します。健全性アラートは、Loki の取り込みエラー、フローの取り込みがゼロ、または eBPF フローのドロップといった状況が発生した場合にバナーを表示します。
アラートがトリガーされると、ダッシュボードに誘導する健全性アラートのバナーが Network Traffic ページと Home ページに表示されることがあります。アラートは次の場合に生成されます。
-
NetObservLokiErrorアラートは、Loki 取り込みレート制限に達した場合など、Loki エラーが原因でflowlogs-pipelineワークロードがフローをドロップすると発生します。 -
NetObservNoFlowsアラートは、一定時間フローが取り込まれない場合に発生します。 -
NetObservFlowsDroppedアラートは、Network Observability eBPF エージェントの HashMap テーブルがいっぱいで、eBPF エージェントがパフォーマンスが低下した状態でフローを処理している場合、または容量制限がトリガーされた場合に発生します。
13.3. 健全性情報の表示
OpenShift Container Platform の Web コンソール内の Netobserv/Health ダッシュボードを表示して、Network Observability Operator とそのコンポーネントの健全性ステータスとリソース使用状況を監視します。
前提条件
- Network Observability Operator がインストールされています。
-
cluster-adminロールまたはすべてのプロジェクトの表示パーミッションを持つユーザーとしてクラスターにアクセスできる。
手順
- Web コンソールの Administrator パースペクティブから、Observe → Dashboards に移動します。
- Dashboards ドロップダウンメニューから、Netobserv/Health を選択します。
- ページに表示された Operator の健全性に関するメトリクスを確認します。
13.3.1. 健全性アラートの無効化
NetObservLokiError や NetObservNoFlows などの特定の健全性アラートを無効にするには、FlowCollector リソースを編集し、spec.processor.metrics.disableAlerts 仕様を使用します。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
次の YAML サンプルのように、
spec.processor.metrics.disableAlertsを追加して健全性アラートを無効にします。apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: processor: metrics: disableAlerts: [NetObservLokiError, NetObservNoFlows]各項目の説明:
spec.processor.metrics.disableAlerts- 無効にするアラートの種類を 1 つ以上指定します。
13.4. NetObserv ダッシュボードの Loki レート制限アラートの作成
Loki メトリクスに基づいてカスタム AlertingRule リソースを作成して、HTTP 429 エラーによって示される Loki 取り込みレート制限への到達を監視し、アラートをトリガーします。
Netobserv ダッシュボードメトリクスのカスタム警告ルールを作成して、Loki のレート制限に達した場合にアラートをトリガーできます。
前提条件
- cluster-admin ロールを持つユーザー、またはすべてのプロジェクトの表示権限を持つユーザーとしてクラスターにアクセスできる。
- Network Observability Operator がインストールされています。
手順
- インポートアイコン + をクリックして、YAML ファイルを作成します。
アラートルール設定を YAML ファイルに追加します。次の YAML サンプルでは、Loki のレート制限に達した場合にアラートが作成されます。
apiVersion: monitoring.openshift.io/v1 kind: AlertingRule metadata: name: loki-alerts namespace: openshift-monitoring spec: groups: - name: LokiRateLimitAlerts rules: - alert: LokiTenantRateLimit annotations: message: |- {{ $labels.job }} {{ $labels.route }} is experiencing 429 errors. summary: "At any number of requests are responded with the rate limit error code." expr: sum(irate(loki_request_duration_seconds_count{status_code="429"}[1m])) by (job, namespace, route) / sum(irate(loki_request_duration_seconds_count[1m])) by (job, namespace, route) * 100 > 0 for: 10s labels: severity: warning- Create をクリックして設定ファイルをクラスターに適用します。
13.5. eBPF エージェントアラートの使用
FlowCollector カスタムリソースの spec.agent.ebpf.cacheMaxFlows 値を増やして、eBPF エージェントハッシュマップがいっぱいになったときに発生する NetObservAgentFlowsDropped アラートを解決します。
容量制限がトリガーされると、NetObservAgentFlowsDropped アラートもトリガーされます。このアラートが表示された場合は、次の例に示すように、FlowCollector の cacheMaxFlows を増やすことを検討してください。
cacheMaxFlows を増やすと、eBPF エージェントのメモリー使用量が増加する可能性があります。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- Network Observability Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
次の YAML サンプルに示すように、
spec.agent.ebpf.cacheMaxFlowsの値を増やします。apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: namespace: netobserv deploymentModel: Service agent: type: eBPF ebpf: cacheMaxFlows: 200000各項目の説明:
spec.agent.ebpf.cacheMaxFlows-
キャッシュするフローの最大数を指定します。
NetObservAgentFlowsDroppedアラートが発生した場合は、この値を現在のレベルから引き上げてください。
第14章 リソースのスケジューリング
taint と toleration は、どのノードに特定の Pod を配置するかを制御するのに役立ちます。Network Observability コンポーネントの配置を制御するには、これらの手段をノードセレクターとともに使用します。
ノードセレクターは、ノードのカスタムラベルと Pod で指定されたセレクターを使用して定義されるキー/値のペアのマップを指定します。
Pod がノードで実行する要件を満たすには、Pod にはノードのラベルと同じキー/値のペアがなければなりません。
14.1. 特定ノードへのネットワークオブザーバビリティーのデプロイ
特定ノードへのネットワークオブザーバビリティーコンポーネントのデプロイを制御するには、NodeSelector、Tolerations、Affinity などのスケジューリング仕様を使用して FlowCollector リソースを設定します。
spec.agent.ebpf.advanced.scheduling、spec.processor.advanced.scheduling、および spec.consolePlugin.advanced.scheduling 仕様で、次の設定が可能です。
-
NodeSelector -
Tolerations -
Affinity -
PriorityClassName
spec.<component>.advanced.scheduling のサンプル FlowCollector リソース
apiVersion: flows.netobserv.io/v1beta2
kind: FlowCollector
metadata:
name: cluster
spec:
# ...
advanced:
scheduling:
tolerations:
- key: "<taint key>"
operator: "Equal"
value: "<taint value>"
effect: "<taint effect>"
nodeSelector:
<key>: <value>
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: name
operator: In
values:
- app-worker-node
priorityClassName: """
# ...第15章 セカンダリーネットワーク
Network Observability Operator を設定して、SR-IOV や OVN-Kubernetes などのセカンダリーネットワークからネットワークフローデータを収集し、データをエンリッチすることができます。
15.1. 前提条件
- セカンダリーインターフェイスや L2 ネットワークなど、追加のネットワークインターフェイスを備えた OpenShift Container Platform クラスターへのアクセス。
15.2. SR-IOV インターフェイストラフィックの監視の設定
spec.agent.ebpf.privileged フィールドを true に設定することで、Single Root I/O Virtualization (SR-IOV) デバイス上のトラフィックを監視するように FlowCollector リソースを設定します。これにより、eBPF エージェントが他のネットワーク namespace を監視できるようになります。
eBPF エージェントは、デフォルトで監視されるホストネットワーク namespace に加えて、他のネットワーク namespace も監視します。Virtual Function (VF) インターフェイスを持つ Pod が作成されると、新しいネットワーク namespace が作成されます。SRIOVNetwork ポリシーの IPAM 設定を指定すると、VF インターフェイスがホストネットワーク namespace から Pod ネットワーク namespace に移行されます。
前提条件
- SR-IOV デバイスを使用して OpenShift Container Platform クラスターにアクセスできる。
-
SRIOVNetworkカスタムリソース (CR) のspec.ipam設定は、インターフェイスのリストにある範囲または他のプラグインからの IP アドレスを使用して設定する必要があります。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
FlowCollectorカスタムリソースを設定します。設定例は次のとおりです。SR-IOV モニタリング用に
FlowCollectorを設定するapiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: namespace: netobserv deploymentModel: Service agent: type: eBPF ebpf: privileged: true-
SR-IOV モニタリングを有効にするには、
spec.agent.ebpf.privilegedフィールドの値をtrueに設定する必要があります。
-
SR-IOV モニタリングを有効にするには、
15.3. 仮想マシン (VM) のセカンダリーネットワークインターフェイスを Network Observability 用に設定する
eBPF エージェントを privileged モードに設定し、セカンダリーネットワークのインデックス作成を定義することで、仮想マシンのセカンダリーネットワークトラフィックを監視するように FlowCollector を設定します。これにより、OpenShift Virtualization からのフローのキャプチャーとエンリッチメントを可能にします。
デフォルトの内部 Pod ネットワークに接続されている仮想マシンからのネットワークフローは、ネットワークオブザーバビリティーによって自動的にキャプチャーされます。
手順
次のコマンドを実行して、仮想マシンのランチャー Pod に関する情報を取得します。この情報はステップ 5 で使用します。
$ oc get pod virt-launcher-<vm_name>-<suffix> -n <namespace> -o yamlapiVersion: v1 kind: Pod metadata: annotations: k8s.v1.cni.cncf.io/network-status: |- [{ "name": "ovn-kubernetes", "interface": "eth0", "ips": [ "10.129.2.39" ], "mac": "0a:58:0a:81:02:27", "default": true, "dns": {} }, { "name": "my-vms/l2-network", "interface": "podc0f69e19ba2", "ips": [ "10.10.10.15" ], "mac": "02:fb:f8:00:00:12", "dns": {} }] name: virt-launcher-fedora-aqua-fowl-13-zr2x9 namespace: my-vms spec: # ... status: # ...各項目の説明:
name- セカンダリーネットワークの名前を指定します。
interface- セカンダリーネットワークのネットワークインターフェイスを指定します。
ips- セカンダリーネットワークによって使用される IP アドレスのリストを指定します。
mac- セカンダリーネットワークによって使用される MAC アドレスを指定します。
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- NetObserv Operator の Provided APIs 見出しの下で、Flow Collector を選択します。
- cluster を選択し、YAML タブを選択します。
追加のネットワーク調査で調べた情報に基づいて
FlowCollectorを設定します。apiVersion: flows.netobserv.io/v1beta2 kind: FlowCollector metadata: name: cluster spec: agent: ebpf: privileged: true processor: advanced: secondaryNetworks: - index: - MAC name: my-vms/l2-network # ...各項目の説明:
spec.agent.ebpf.privileged-
eBPF エージェントを
privilegedモードで実行することを指定します。これは、仮想マシンランチャー Pod 上のセカンダリーネットワークインターフェイスからフローを収集するために必要です。 spec.processor.advanced.secondaryNetworks.index-
仮想マシンランチャー Pod のインデックス作成に使用するフィールドを指定します。セカンダリーインターフェイスのネットワークフローのエンリッチメントを取得するには、
MACアドレスをインデックスフィールドとして使用することを推奨します。Pod 間で MAC アドレスが重複している場合は、IPやInterfaceなどの追加のインデックスフィールドを加えると、正確なエンリッチメントを確実に行うことができます。 MAC-
インデックスフィールドの値として MAC アドレスを指定します。追加のネットワーク情報に MAC アドレスが含まれている場合は、
indexフィールドリストにMACを追加してください。 spec.processor.advanced.secondaryNetworks.name-
仮想マシンランチャー Pod の
k8s.v1.cni.cncf.io/network-statusアノテーションに記述されているセカンダリーネットワークの名前を指定します。通常、形式は<namespace>/<network_attachment_definition_name>です。
検証
仮想マシンのトラフィックを観測します。
- Network Traffic ページに移動します。
-
k8s.v1.cni.cncf.io/network-statusアノテーションで見つかった仮想マシンの IP を使用して、Source IP でフィルタリングします。 - エンリッチする必要がある Source フィールドと Destination フィールドの両方を表示し、仮想マシンランチャー Pod と仮想マシンインスタンスを所有者として指定します。
第16章 Network Observability CLI
16.1. Network Observability CLI のインストール
Network Observability CLI (oc netobserv) は、クラスターのネットワークトラフィックのデバッグとトラブルシューティングに使用されるスタンドアロンの OpenShift CLI (oc) プラグインです。これは、Network Observability Operator とは独立して動作し、ネットワークのパフォーマンスに関する即時診断情報を収集します。
16.1.1. Network Observability CLI について
Network Observability CLI (oc netobserv) を使用して、ネットワークの問題を迅速にデバッグおよびトラブルシューティングします。このツールを使用することで、Network Observability Operator をインストールしなくても、フローとパケットに関するライブ分析情報が即座に提供されます。
Network Observability CLI は、eBPF エージェントを利用して収集したデータを一時的なコレクター Pod にストリーミングするフローおよびパケット可視化ツールです。キャプチャー中に永続的なストレージは必要ありません。実行後、出力がローカルマシンに転送されます。
CLI のキャプチャーは、8 - 10 分などの短い期間のみ実行されるように設計されています。実行時間が長すぎると、実行中のプロセスを削除するのが難しくなる可能性があります。
16.1.2. Network Observability CLI のインストール
Network Observability CLI は、ネットワークオブザーバビリティーのデバッグおよびトラブルシューティングを迅速に行う軽量な方法です。これは、別途インストールする必要があります。
Network Observability CLI (oc netobserv) のインストールは、Network Observability Operator のインストールとは別の手順です。つまり、Operator がソフトウェアカタログからインストールされている場合でも、CLI を別途インストールする必要があります。
ユーザーは、必要に応じて、Krew を使用して netobserv CLI プラグインをインストールできます。詳細は、「Krew を使用した CLI プラグインのインストール」を参照してください。
前提条件
-
OpenShift CLI (
oc) をインストールしておく。 - macOS または Linux オペレーティングシステムがある。
-
dockerまたはpodmanをインストールする必要があります。
インストールコマンドの実行には、podman または docker を使用できます。この手順では podman を使用します。
手順
次のコマンドを実行して、Red Hat レジストリー にログインします。
$ podman login registry.redhat.io次のコマンドを実行して、イメージから
oc-netobservファイルを抽出します。$ podman create --name netobserv-cli registry.redhat.io/network-observability/network-observability-cli-rhel9:1.11 $ podman cp netobserv-cli:/oc-netobserv . $ podman rm netobserv-cli次のコマンドを実行して、抽出したファイルをシステムの
PATHにあるディレクトリー (/usr/local/bin/など) に移動します。$ sudo mv oc-netobserv /usr/local/bin/
検証
oc netobservが利用可能であることを確認します。$ oc netobserv versionこのコマンドを実行すると、次の例のような結果が生成されるはずです。
Netobserv CLI version <version>16.2. Network Observability CLI の使用
Network Observability CLI は、ネットワークフローとパケットテレメトリーを端末内で直接フィルタリングおよび可視化します。このツールは、サードパーティーの分析ユーティリティーとのシームレスな統合のために、取得したデータを JSON、データベースファイル、またはパケットキャプチャー (PCAP) ファイルとしてエクスポートします。
16.2.1. フローのキャプチャー
ネットワークフローをキャプチャーし、リソースまたはゾーンに基づいてフィルターを CLI で直接適用します。これは、2 つの異なるゾーン間のラウンドトリップタイム (RTT) を可視化するなど、複雑なユースケースを解決するために役立ちます。
CLI 上で表形式の可視化を行うことで、データの閲覧やフローの検索が可能になります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
Network Observability CLI (
oc netobserv) プラグインがインストールされている。
手順
次のコマンドを実行して、フィルターを有効にしてフローをキャプチャーします。
$ oc netobserv flows --enable_filter=true --action=Accept --cidr=0.0.0.0/0 --protocol=TCP --port=49051ターミナルの
live table filterプロンプトでフィルターを追加して、受信するフローをさらに絞り込みます。以下に例を示します。live table filter: [SrcK8S_Zone:us-west-1b] press enter to match multiple regular expressions at once- PageUp キーと PageDown キーを使用して、None、Resource、Zone、Host、Owner、および all of the above を切り替えます。
-
キャプチャーを停止するには、Ctrl+C を押します。キャプチャーされたデータは、CLI のインストールに使用したのと同じパスにある
./outputディレクトリー内の 2 つの異なるファイルに書き込まれます。 キャプチャーされたデータを、JSON ファイル
./output/flow/<capture_date_time>.jsonで確認します。このファイルには、キャプチャーされたデータの JSON 配列が含まれています。JSON ファイルの例:
{ "AgentIP": "10.0.1.76", "Bytes": 561, "DnsErrno": 0, "Dscp": 20, "DstAddr": "f904:ece9:ba63:6ac7:8018:1e5:7130:0", "DstMac": "0A:58:0A:80:00:37", "DstPort": 9999, "Duplicate": false, "Etype": 2048, "Flags": 16, "FlowDirection": 0, "IfDirection": 0, "Interface": "ens5", "K8S_FlowLayer": "infra", "Packets": 1, "Proto": 6, "SrcAddr": "3e06:6c10:6440:2:a80:37:b756:270f", "SrcMac": "0A:58:0A:80:00:01", "SrcPort": 46934, "TimeFlowEndMs": 1709741962111, "TimeFlowRttNs": 121000, "TimeFlowStartMs": 1709741962111, "TimeReceived": 1709741964 }SQLite を使用して、
./output/flow/<capture_date_time>.dbデータベースファイルを検査できます。以下に例を示します。次のコマンドを実行してファイルを開きます。
$ sqlite3 ./output/flow/<capture_date_time>.dbSQLite
SELECTステートメントを実行してデータをクエリーします。次に例を示します。sqlite> SELECT DnsLatencyMs, DnsFlagsResponseCode, DnsId, DstAddr, DstPort, Interface, Proto, SrcAddr, SrcPort, Bytes, Packets FROM flow WHERE DnsLatencyMs >10 LIMIT 10;出力例
12|NoError|58747|10.128.0.63|57856||17|172.30.0.10|53|284|1 11|NoError|20486|10.128.0.52|56575||17|169.254.169.254|53|225|1 11|NoError|59544|10.128.0.103|51089||17|172.30.0.10|53|307|1 13|NoError|32519|10.128.0.52|55241||17|169.254.169.254|53|254|1 12|NoError|32519|10.0.0.3|55241||17|169.254.169.254|53|254|1 15|NoError|57673|10.128.0.19|59051||17|172.30.0.10|53|313|1 13|NoError|35652|10.0.0.3|46532||17|169.254.169.254|53|183|1 32|NoError|37326|10.0.0.3|52718||17|169.254.169.254|53|169|1 14|NoError|14530|10.0.0.3|58203||17|169.254.169.254|53|246|1 15|NoError|40548|10.0.0.3|45933||17|169.254.169.254|53|174|1
16.2.2. パケットのキャプチャー
ネットワークパケットをキャプチャーするには、Network Observability CLI を使用します。正確なリアルタイムデバッグを実現するために、ターミナル内でフィルターを適用して調整できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
Network Observability CLI (
oc netobserv) プラグインがインストールされている。
手順
フィルターを有効にしてパケットキャプチャーを実行します。
$ oc netobserv packets --action=Accept --cidr=0.0.0.0/0 --protocol=TCP --port=49051ターミナルの
live table filterプロンプトでフィルターを追加して、受信するパケットを絞り込みます。フィルターの例は次のとおりです。live table filter: [SrcK8S_Zone:us-west-1b] press enter to match multiple regular expressions at once- PageUp キーと PageDown キーを使用して、None、Resource、Zone、Host、Owner、および all of the above を切り替えます。
- キャプチャーを停止するには、Ctrl+C を押します。
キャプチャーされたデータを確認します。このデータは、CLI のインストールに使用したのと同じパスにある
./output/pcapディレクトリー内の 1 つのファイルに書き込まれます。-
./output/pcap/<capture_date_time>.pcapファイルは Wireshark で開くことができます。
-
16.2.3. メトリクスの取得
サービスモニターを使用して、Prometheus でオンデマンドネットワークオブザーバビリティーダッシュボードを生成します。これにより、ネットワークメトリクスをすばやく表示および分析できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
Network Observability CLI (
oc netobserv) プラグインがインストールされている。
手順
次のコマンドを実行して、フィルターを有効にしてメトリクスをキャプチャーします。
出力例
$ oc netobserv metrics --enable_filter=true --cidr=0.0.0.0/0 --protocol=TCP --port=49051ターミナルで提供されているリンクを開いて NetObserv / On-Demand ダッシュボードを表示します。
URL の例
https://console-openshift-console.apps.rosa...openshiftapps.com/monitoring/dashboards/netobserv-cli注記有効になっていない機能は空のグラフとして表示されます。
16.2.4. Network Observability CLI のクリーンアップ
oc netobserv cleanup を使用して、Network Observability CLI によってインストールされたすべてのコンポーネントをクラスターから手動で削除します。クライアントはキャプチャー後にこのコマンドを自動的に実行しますが、接続の問題が発生した場合は手動で実行する必要があります。
手順
以下のコマンドを実行します。
$ oc netobserv cleanup
16.3. Network Observability CLI (oc netobserv) リファレンス
Network Observability CLI (oc netobserv) は、Network Observability Operator と同等の機能およびフィルター機能を提供します。コマンドライン引数を使用して、機能を動的に切り替えたり、特定のクラスターネットワークトラフィックフローを分離したりできます。
16.3.1. Network Observability CLI の使用
Network Observability CLI (oc netobserv) を使用して、コマンドライン引数を渡してさらに分析するためのフローデータ、パケットデータ、メトリクスをキャプチャーしたり、Network Observability Operator がサポートする機能を有効にしたりできます。
16.3.1.1. 構文
oc netobserv コマンドの基本構文:
oc netobserv の構文
$ oc netobserv [<command>] [<feature_option>] [<command_options>] - 1
- 機能オプションは、
oc netobserv flowsコマンドでのみ使用できます。oc netobserv packetsコマンドでは使用できません。
16.3.1.2. 基本コマンド
| コマンド | 説明 |
|---|---|
| flows | フロー情報をキャプチャーします。サブコマンドは、「フローキャプチャーのオプション」表を参照してください。 |
| packets | パケットデータをキャプチャーします。サブコマンドは、「パケットキャプチャーのオプション」表を参照してください。 |
| metrics | メトリクスデータをキャプチャーします。サブコマンドは、「メトリクスキャプチャーのオプション」の表を参照してください。 |
| follow | バックグラウンドで実行しているときはコレクターログに従います。 |
| stop | エージェントデーモンセットを削除して収集を停止します。 |
| copy | コレクターが生成したファイルをローカルにコピーします。 |
| cleanup | Network Observability CLI コンポーネントを削除します。 |
| version | ソフトウェアのバージョンを出力します。 |
| help | ヘルプを表示します。 |
16.3.1.3. フローキャプチャーのオプション
フローキャプチャーには、必須コマンドのほか、パケットドロップ、DNS 遅延、ラウンドトリップタイム、フィルタリングに関する追加機能の有効化などの追加オプションがあります。
oc netobserv flows の構文
$ oc netobserv flows [<feature_option>] [<command_options>]| オプション | 説明 | Default |
|---|---|---|
| --enable_all | すべての eBPF 機能の有効化 | false |
| --enable_dns | DNS トラッキングの有効化 | false |
| --enable_ipsec | IPsec トラッキングの有効化 | false |
| --enable_network_events | ネットワークイベントモニタリングの有効化 | false |
| --enable_pkt_translation | パケット変換の有効化 | false |
| --enable_pkt_drop | パケットドロップの有効化 | false |
| --enable_rtt | RTT トラッキングの有効化 | false |
| --enable_udn_mapping | ユーザー定義ネットワークマッピングの有効化 | false |
| --get-subnets | サブネット情報の取得 | false |
| --privileged | eBPF エージェント特権モードの強制 | auto |
| --sampling | パケットサンプリング間隔 | 1 |
| --background | バックグラウンドでの実行 | false |
| --copy | 出力ファイルをローカルにコピー | prompt |
| --log-level | コンポーネントログ | info |
| --max-time | 最大キャプチャー時間 | 5m |
| --max-bytes | 最大キャプチャーバイト数 | 50000000 = 50MB |
| --action | アクションのフィルタリング | Accept |
| --cidr | CIDR のフィルタリング | 0.0.0.0/0 |
| --direction | 方向のフィルタリング | - |
| --dport | 送信先ポートのフィルタリング | - |
| --dport_range | 送信先ポート範囲のフィルタリング | - |
| --dports | 2 つの送信先ポートのどちらかでフィルタリング | - |
| --drops | ドロップされたパケットのみでフローをフィルタリング | false |
| --icmp_code | ICMP コードのフィルタリング | - |
| --icmp_type | ICMP タイプのフィルタリング | - |
| --node-selector | 特定のノードでのキャプチャー | - |
| --peer_ip | ピア IP のフィルタリング | - |
| --peer_cidr | ピア CIDR のフィルタリング | - |
| --port_range | ポート範囲のフィルタリング | - |
| --port | ポートのフィルタリング | - |
| --ports | 2 つのポートのどちらかでフィルタリング | - |
| --protocol | プロトコルのフィルタリング | - |
| --query | カスタムクエリーを使用したフローのフィルタリング | - |
| --sport_range | 送信元ポート範囲のフィルタリング | - |
| --sport | 送信元ポートのフィルタリング | - |
| --sports | 2 つの送信元ポートのどちらかでフィルタリング | - |
| --tcp_flags | TCP フラグのフィルタリング | - |
| --interfaces | 監視するインターフェイスのリスト (コンマ区切り) | - |
| --exclude_interfaces | 除外するインターフェイスのリスト (コンマ区切り) | lo |
PacketDrop および RTT 機能を有効にして TCP プロトコルとポート 49051 でフローキャプチャーを実行する例:
$ oc netobserv flows --enable_pkt_drop --enable_rtt --action=Accept --cidr=0.0.0.0/0 --protocol=TCP --port=4905116.3.1.4. パケットキャプチャーのオプション
フィルターを使用すると、フローのキャプチャーと同じようにパケットのキャプチャーデータをフィルタリングできます。パケットドロップ、DNS、RTT、ネットワークイベントなどの特定の機能は、フローおよびメトリクスのキャプチャーでのみ使用できます。
oc netobserv packets の構文
$ oc netobserv packets [<option>]| オプション | 説明 | Default |
|---|---|---|
| --background | バックグラウンドでの実行 | false |
| --copy | 出力ファイルをローカルにコピー | prompt |
| --log-level | コンポーネントログ | info |
| --max-time | 最大キャプチャー時間 | 5m |
| --max-bytes | 最大キャプチャーバイト数 | 50000000 = 50MB |
| --action | アクションのフィルタリング | Accept |
| --cidr | CIDR のフィルタリング | 0.0.0.0/0 |
| --direction | 方向のフィルタリング | - |
| --dport | 送信先ポートのフィルタリング | - |
| --dport_range | 送信先ポート範囲のフィルタリング | - |
| --dports | 2 つの送信先ポートのどちらかでフィルタリング | - |
| --drops | ドロップされたパケットのみでフローをフィルタリング | false |
| --icmp_code | ICMP コードのフィルタリング | - |
| --icmp_type | ICMP タイプのフィルタリング | - |
| --node-selector | 特定のノードでのキャプチャー | - |
| --peer_ip | ピア IP のフィルタリング | - |
| --peer_cidr | ピア CIDR のフィルタリング | - |
| --port_range | ポート範囲のフィルタリング | - |
| --port | ポートのフィルタリング | - |
| --ports | 2 つのポートのどちらかでフィルタリング | - |
| --protocol | プロトコルのフィルタリング | - |
| --query | カスタムクエリーを使用したフローのフィルタリング | - |
| --sport_range | 送信元ポート範囲のフィルタリング | - |
| --sport | 送信元ポートのフィルタリング | - |
| --sports | 2 つの送信元ポートのどちらかでフィルタリング | - |
| --tcp_flags | TCP フラグのフィルタリング | - |
TCP プロトコルとポート 49051 でパケットキャプチャーを実行する例:
$ oc netobserv packets --action=Accept --cidr=0.0.0.0/0 --protocol=TCP --port=4905116.3.1.5. メトリクスキャプチャーのオプション
フローキャプチャーと同じように、メトリクスキャプチャーでも機能を有効にしてフィルターを使用できます。生成されたグラフはダッシュボードに適宜表示されます。
oc netobserv metrics 構文
$ oc netobserv metrics [<option>]| オプション | 説明 | Default |
|---|---|---|
| --enable_all | すべての eBPF 機能の有効化 | false |
| --enable_dns | DNS トラッキングの有効化 | false |
| --enable_ipsec | IPsec トラッキングの有効化 | false |
| --enable_network_events | ネットワークイベントモニタリングの有効化 | false |
| --enable_pkt_translation | パケット変換の有効化 | false |
| --enable_pkt_drop | パケットドロップの有効化 | false |
| --enable_rtt | RTT トラッキングの有効化 | false |
| --enable_udn_mapping | ユーザー定義ネットワークマッピングの有効化 | false |
| --get-subnets | サブネット情報の取得 | false |
| --privileged | eBPF エージェント特権モードの強制 | auto |
| --sampling | パケットサンプリング間隔 | 1 |
| --background | バックグラウンドでの実行 | false |
| --log-level | コンポーネントログ | info |
| --max-time | 最大キャプチャー時間 | 1h |
| --action | アクションのフィルタリング | Accept |
| --cidr | CIDR のフィルタリング | 0.0.0.0/0 |
| --direction | 方向のフィルタリング | - |
| --dport | 送信先ポートのフィルタリング | - |
| --dport_range | 送信先ポート範囲のフィルタリング | - |
| --dports | 2 つの送信先ポートのどちらかでフィルタリング | - |
| --drops | ドロップされたパケットのみでフローをフィルタリング | false |
| --icmp_code | ICMP コードのフィルタリング | - |
| --icmp_type | ICMP タイプのフィルタリング | - |
| --node-selector | 特定のノードでのキャプチャー | - |
| --peer_ip | ピア IP のフィルタリング | - |
| --peer_cidr | ピア CIDR のフィルタリング | - |
| --port_range | ポート範囲のフィルタリング | - |
| --port | ポートのフィルタリング | - |
| --ports | 2 つのポートのどちらかでフィルタリング | - |
| --protocol | プロトコルのフィルタリング | - |
| --query | カスタムクエリーを使用したフローのフィルタリング | - |
| --sport_range | 送信元ポート範囲のフィルタリング | - |
| --sport | 送信元ポートのフィルタリング | - |
| --sports | 2 つの送信元ポートのどちらかでフィルタリング | - |
| --tcp_flags | TCP フラグのフィルタリング | - |
| --include_list | 生成するメトリクス名のリスト (コンマ区切り) | namespace_flows_total,node_ingress_bytes_total,node_egress_bytes_total,workload_ingress_bytes_total |
| --interfaces | 監視するインターフェイスのリスト (コンマ区切り) | - |
| --exclude_interfaces | 除外するインターフェイスのリスト (コンマ区切り) | lo |
TCP ドロップのメトリクスキャプチャーの実行例
$ oc netobserv metrics --enable_pkt_drop --protocol=TCP第17章 FlowCollector API リファレンス
FlowCollector API は、ネットワークフローを収集するためのデプロイメントを制御および設定するために使用される基礎となるスキーマです。このリファレンスガイドは、このような重要な設定を管理するのに役立ちます。
17.1. FlowCollector API 仕様
- 説明
-
FlowCollectorは、基盤となるデプロイメントを操作および設定するネットワークフロー収集 API のスキーマです。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| APIVersion はオブジェクトのこの表現のバージョンスキーマを定義します。サーバーは認識されたスキーマを最新の内部値に変換し、認識されない値は拒否することがあります。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources を参照してください。 |
|
|
| kind はこのオブジェクトが表す REST リソースを表す文字列の値です。サーバーは、クライアントが要求を送信するエンドポイントからこれを推測できることがあります。これを更新することはできません。CamelCase を使用します。詳細: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds |
|
|
| 標準オブジェクトのメタデータ。詳細: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata |
|
|
|
FlowCollector リソースの望ましい状態を定義します。 *: このドキュメントで「サポート対象外」または「非推奨」と記載されている場合、Red Hat はその機能を公式にサポートしていません。たとえば、コミュニティーによって提供され、メンテナンスに関する正式な合意なしに受け入れられた可能性があります。製品のメンテナーは、ベストエフォートに限定してこれらの機能に対するサポートを提供する場合があります。 |
17.1.1. .metadata
- 説明
- 標準オブジェクトのメタデータ。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata を参照してください。
- 型
-
object
17.1.2. .spec
- 説明
FlowCollector リソースの望ましい状態を定義します。
*: このドキュメントで「サポート対象外」または「非推奨」と記載されている場合、Red Hat はその機能を公式にサポートしていません。たとえば、コミュニティーによって提供され、メンテナンスに関する正式な合意なしに受け入れられた可能性があります。製品のメンテナーは、ベストエフォートに限定してこれらの機能に対するサポートを提供する場合があります。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| フローを抽出するためのエージェント設定。 |
|
|
|
|
|
|
|
-
-
-
Kafka は、スケーラビリティー、回復性、および高可用性の面でより優れています (詳細は、https://www.redhat.com/en/topics/integration/what-is-apache-kafka を参照してください)。
メモリー効率が低いため、大規模クラスターで |
|
|
|
|
|
|
|
Kafka の設定。フロー収集パイプラインの一部において、Kafka をブローカーとして使用できるようになります。この設定を利用できるのは、 |
|
|
|
|
|
|
| Network Observability Pod がデプロイされる namespace。 |
|
|
|
|
|
|
|
|
|
|
|
|
17.1.3. .spec.agent
- 説明
- フローを抽出するためのエージェント設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
17.1.4. .spec.agent.ebpf
- 説明
-
ebpfは、spec.agent.typeがeBPFに設定されている場合、eBPF ベースのフローレポーターに関連する設定を示します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
有効にする追加機能のリスト。これらはデフォルトですべて無効になっています。追加機能を有効にすると、パフォーマンスに影響が出る可能性があります。可能な値は次のとおりです。
-
-
-
-
-
-
-
この機能を使用するには、カーネルデバッグファイルシステムをマウントする必要があるため、eBPF エージェント Pod を
- |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
eBPF エージェントコンテナーの特権モード。 |
|
|
|
|
|
|
| eBPF プローブのサンプリング間隔。100 を指定すると、100 分の 1 のパケットが送信されます。0 または 1 を指定すると、すべてのパケットがサンプリングされます。 |
17.1.5. .spec.agent.ebpf.advanced
- 説明
-
advancedを使用すると、eBPF エージェントの内部設定のいくつかの側面を設定できます。このセクションは、GOGCやGOMAXPROCS環境変数などのデバッグと詳細なパフォーマンスの最適化を主な目的としています。これらの値はお客様の責任のもと設定してください。このセクションでは、デフォルトの Linux ケイパビリティーをオーバーライドすることもできます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| 特権モードで実行されていない場合に、Linux ケイパビリティーをオーバーライドします。デフォルトのケイパビリティーは、BPF、PERFMON、NET_ADMIN です。 |
|
|
|
|
|
|
| scheduling は、Pod がノードでどのようにスケジュールされるかを制御します。 |
17.1.6. .spec.agent.ebpf.advanced.scheduling
- 説明
- scheduling は、Pod がノードでどのようにスケジュールされるかを制御します。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| 指定した場合、Pod のスケジューリング制約。ドキュメントは、https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling を参照してください。 |
|
|
|
|
|
|
| 指定した場合、Pod の優先度を示します。ドキュメントは、https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#how-to-use-priority-and-preemption を参照してください。指定されていない場合はデフォルトの優先度が使用され、デフォルトの優先度がない場合は 0 が使用されます。 |
|
|
|
|
17.1.7. .spec.agent.ebpf.advanced.scheduling.affinity
- 説明
- 指定した場合、Pod のスケジューリング制約。ドキュメントは、https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling を参照してください。
- 型
-
object
17.1.8. .spec.agent.ebpf.advanced.scheduling.tolerations
- 説明
-
tolerationsは、一致する taint を持つノードに Pod がスケジュールできるようにする toleration のリストです。ドキュメントは、https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling を参照してください。 - 型
-
array
17.1.9. .spec.agent.ebpf.flowFilter
- 説明
-
flowFilterは、フローフィルタリングに関する eBPF エージェント設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
eBPF フローのフィルタリング機能を有効にするには、 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
17.1.10. .spec.agent.ebpf.flowFilter.rules
- 説明
-
rulesは、eBPF エージェントのフィルタリングルールのリストを定義します。フィルタリングが有効になっている場合、どのルールにも一致しないフローはデフォルトで拒否されます。デフォルトを変更するには、すべてを受け入れるルール ({ action: "Accept", cidr: "0.0.0.0/0" }) を定義してから拒否ルールで調整します。 - 型
-
array
17.1.11. .spec.agent.ebpf.flowFilter.rules[]
- 説明
-
EBPFFlowFilterRuleは、フローフィルタリングルールに関する eBPF エージェント設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
17.1.12. .spec.agent.ebpf.metrics
- 説明
-
metricsは、メトリクスに関する eBPF エージェント設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
eBPF エージェントのメトリクス収集を無効にするには、 |
|
|
| Prometheus スクレイパーのメトリクスサーバーエンドポイント設定。 |
17.1.13. .spec.agent.ebpf.metrics.server
- 説明
- Prometheus スクレイパーのメトリクスサーバーエンドポイント設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| メトリクスサーバーの HTTP ポート。 |
|
|
| TLS 設定。 |
17.1.14. .spec.agent.ebpf.metrics.server.tls
- 説明
- TLS 設定。
- 型
-
object - 必須
-
type
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TLS 設定のタイプを選択します。
- |
17.1.15. .spec.agent.ebpf.metrics.server.tls.provided
- 説明
-
typeがProvidedに設定されている場合の TLS 設定。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.16. .spec.agent.ebpf.metrics.server.tls.providedCaFile
- 説明
-
typeがProvidedに設定されている場合の CA ファイルへの参照。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| config map またはシークレット内のファイル名。 |
|
|
| ファイルを含む config map またはシークレットの名前。 |
|
|
| ファイルを含む config map またはシークレットの namespace。省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
ファイル参照のタイプ ( |
17.1.17. .spec.agent.ebpf.resources
- 説明
-
resourcesは、このコンテナーが必要とするコンピューティングリソースです。詳細は、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ を参照してください。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| limits は、許可されるコンピュートリソースの最大量を示します。詳細は、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ を参照してください。 |
|
|
| requests は、必要なコンピュートリソースの最小量を示します。コンテナーで requests が省略されている場合、明示的に limits が指定されていれば、limits がデフォルト値として使用されます。指定されていなければ、実装で定義されている値がデフォルト値として使用されます。リクエストは制限を超えることはできません。詳細は、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ を参照してください。 |
17.1.18. .spec.consolePlugin
- 説明
-
consolePluginは、利用可能な場合、OpenShift Container Platform コンソールプラグインに関連する設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| コンソールプラグインのデプロイメントを有効にします。 |
|
|
|
|
|
|
|
コンソールプラグインバックエンドの |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| OpenShift Container Platform Console のプラグインとしてではなく、スタンドアロンのコンソールとしてデプロイします。OpenShift Container Platform で使用する場合は、統合されたエクスペリエンスが提供されないため、推奨されません。[サポート対象外 (*)] |
|
|
|
|
17.1.19. .spec.consolePlugin.advanced
- 説明
-
advancedを使用すると、コンソールプラグインの内部設定のいくつかの側面を設定できます。このセクションは、GOGCやGOMAXPROCS環境変数などのデバッグと詳細なパフォーマンスの最適化を主な目的としています。これらの値はお客様の責任のもと設定してください。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
17.1.20. .spec.consolePlugin.advanced.scheduling
- 説明
-
schedulingは、Pod がノードでどのようにスケジュールされるかを制御します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| 指定した場合、Pod のスケジューリング制約。ドキュメントは、https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling を参照してください。 |
|
|
|
|
|
|
| 指定した場合、Pod の優先度を示します。ドキュメントは、https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#how-to-use-priority-and-preemption を参照してください。指定されていない場合はデフォルトの優先度が使用され、デフォルトの優先度がない場合は 0 が使用されます。 |
|
|
|
|
17.1.21. .spec.consolePlugin.advanced.scheduling.affinity
- 説明
- 指定した場合、Pod のスケジューリング制約。ドキュメントは、https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling を参照してください。
- 型
-
object
17.1.22. .spec.consolePlugin.advanced.scheduling.tolerations
- 説明
-
tolerationsは、一致する taint を持つノードに Pod がスケジュールできるようにする toleration のリストです。ドキュメントは、https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling を参照してください。 - 型
-
array
17.1.23. .spec.consolePlugin.autoscaler
- 説明
-
autoscaler[非推奨 (*)] プラグインの Deployment 用に設定する水平 Pod オートスケーラーの仕様。非推奨化のお知らせ: マネージドオートスケーラーは将来のバージョンで削除されます。代わりに、任意のオートスケーラーを設定し、spec.consolePlugin.unmanagedReplicasをtrueに設定することもできます。HorizontalPodAutoscaler のドキュメント (自動スケーリング/v2) を参照してください。 - 型
-
object
17.1.24. .spec.consolePlugin.portNaming
- 説明
-
portNamingは、ポートからサービス名への変換の設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| コンソールプラグインのポートからサービス名への変換を有効にします。 |
|
|
|
|
17.1.25. .spec.consolePlugin.quickFilters
- 説明
-
quickFiltersは、コンソールプラグインのクイックフィルタープリセットを設定します。外部トラフィック用のフィルターは、サブネットラベルが内部トラフィックと外部トラフィックを区別するように設定されていることを前提としています (spec.processor.subnetLabelsを参照)。 - 型
-
array
17.1.26. .spec.consolePlugin.quickFilters[]
- 説明
-
QuickFilterは、コンソールのクイックフィルターのプリセット設定を定義します。 - 型
-
object - 必須
-
filter -
name
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| コンソールに表示されるフィルターの名前 |
17.1.27. .spec.consolePlugin.resources
- 説明
-
resources(コンピューティングリソースから見た場合にコンテナーに必要)。詳細は、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ を参照してください。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| limits は、許可されるコンピュートリソースの最大量を示します。詳細は、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ を参照してください。 |
|
|
| requests は、必要なコンピュートリソースの最小量を示します。コンテナーで requests が省略されている場合、明示的に limits が指定されていれば、limits がデフォルト値として使用されます。指定されていなければ、実装で定義されている値がデフォルト値として使用されます。リクエストは制限を超えることはできません。詳細は、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ を参照してください。 |
17.1.28. .spec.exporters
- 説明
-
exportersは、カスタム消費またはストレージ用の追加のオプションのエクスポーターを定義します。 - 型
-
array
17.1.29. .spec.exporters[]
- 説明
-
FlowCollectorExporterは、エンリッチされたフローを送信する追加のエクスポーターを定義します。 - 型
-
object - 必須
-
type
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| エンリッチされた IPFIX フローの送信先の IP アドレスやポートなどの IPFIX 設定。 |
|
|
| エンリッチされたフローの送信先のアドレスやトピックなどの Kafka 設定。 |
|
|
| エンリッチされたログやメトリクスの送信先の IP アドレスやポートなどの OpenTelemetry 設定。 |
|
|
|
|
17.1.30. .spec.exporters[].ipfix
- 説明
- エンリッチされた IPFIX フローの送信先の IP アドレスやポートなどの IPFIX 設定。
- 型
-
object - 必須
-
enterpriseID -
targetHost -
targetPort
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| enterpriseID、または Private Enterprise Number (PEN)。現在のところ、Network Observability には割り当てられた番号がないため、設定できるように未指定のままになっています。PEN は、Kubernetes 名、RTT などの非標準のデータを収集するために必要です。 |
|
|
| IPFIX 外部レシーバーのアドレス。 |
|
|
| IPFIX 外部レシーバー用のポート。 |
|
|
|
IPFIX 接続に使用されるトランスポートプロトコル ( |
17.1.31. .spec.exporters[].kafka
- 説明
- エンリッチされたフローの送信先のアドレスやトピックなどの Kafka 設定。
- 型
-
object - 必須
-
address -
topic
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| Kafka サーバーのアドレス |
|
|
| SASL 認証の設定。[サポート対象外 (*)]。 |
|
|
| TLS クライアント設定。TLS を使用する場合は、アドレスが TLS に使用される Kafka ポート (通常は 9093) と一致することを確認します。 |
|
|
| 使用する Kafka トピック。これは必ず存在する必要があります。Network Observability はこれを作成しません。 |
17.1.32. .spec.exporters[].kafka.sasl
- 説明
- SASL 認証の設定。[サポート対象外 (*)]。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| クライアント ID を含むシークレットまたは config map への参照 |
|
|
| クライアントシークレットを含むシークレットまたは config map への参照 |
|
|
|
使用する SASL 認証のタイプ。SASL を使用しない場合は |
17.1.33. .spec.exporters[].kafka.sasl.clientIDReference
- 説明
- クライアント ID を含むシークレットまたは config map への参照
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| config map またはシークレット内のファイル名。 |
|
|
| ファイルを含む config map またはシークレットの名前。 |
|
|
| ファイルを含む config map またはシークレットの namespace。省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
ファイル参照のタイプ ( |
17.1.34. .spec.exporters[].kafka.sasl.clientSecretReference
- 説明
- クライアントシークレットを含むシークレットまたは config map への参照
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| config map またはシークレット内のファイル名。 |
|
|
| ファイルを含む config map またはシークレットの名前。 |
|
|
| ファイルを含む config map またはシークレットの namespace。省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
ファイル参照のタイプ ( |
17.1.35. .spec.exporters[].kafka.tls
- 説明
- TLS クライアント設定。TLS を使用する場合は、アドレスが TLS に使用される Kafka ポート (通常は 9093) と一致することを確認します。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| TLS を有効にします。 |
|
|
|
|
|
|
|
|
17.1.36. .spec.exporters[].kafka.tls.caCert
- 説明
-
caCertは、認証局の証明書の参照を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.37. .spec.exporters[].kafka.tls.userCert
- 説明
-
userCertは、ユーザー証明書の参照を定義し、mTLS に使用されます。一方向 TLS を使用する場合は、このプロパティーを無視できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.38. .spec.exporters[].openTelemetry
- 説明
- エンリッチされたログやメトリクスの送信先の IP アドレスやポートなどの OpenTelemetry 設定。
- 型
-
object - 必須
-
targetHost -
targetPort
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| OpenTelemetry 準拠の形式にマッピングされるカスタムフィールド。デフォルトでは、Network Observability の形式の提案 (https://github.com/rhobs/observability-data-model/blob/main/network-observability.md#format-proposal) が使用されます。L3 または L4 エンリッチ化ネットワークログは、現在、受け入れられている標準が存在しないため、デフォルトを独自の形式で自由にオーバーライドできます。 |
|
|
| メッセージに追加するヘッダー (任意)。 |
|
|
| ログの OpenTelemetry 設定。 |
|
|
| メトリクスの OpenTelemetry 設定。 |
|
|
|
OpenTelemetry 接続のプロトコル。使用可能なオプションは |
|
|
| OpenTelemetry レシーバーのアドレス。 |
|
|
| OpenTelemetry レシーバーのポート。 |
|
|
| TLS クライアント設定。 |
17.1.39. .spec.exporters[].openTelemetry.fieldsMapping
- 説明
- OpenTelemetry 準拠の形式にマッピングされるカスタムフィールド。デフォルトでは、Network Observability の形式の提案 (https://github.com/rhobs/observability-data-model/blob/main/network-observability.md#format-proposal) が使用されます。L3 または L4 エンリッチ化ネットワークログは、現在、受け入れられている標準が存在しないため、デフォルトを独自の形式で自由にオーバーライドできます。
- 型
-
array
17.1.40. .spec.exporters[].openTelemetry.fieldsMapping[]
- 説明
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| |
|
|
| |
|
|
|
17.1.41. .spec.exporters[].openTelemetry.logs
- 説明
- ログの OpenTelemetry 設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
ログを OpenTelemetry レシーバーに送信するには、 |
17.1.42. .spec.exporters[].openTelemetry.metrics
- 説明
- メトリクスの OpenTelemetry 設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
メトリクスを OpenTelemetry レシーバーに送信するには、 |
|
|
| メトリクスをコレクターに送信する頻度を指定します。 |
17.1.43. .spec.exporters[].openTelemetry.tls
- 説明
- TLS クライアント設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| TLS を有効にします。 |
|
|
|
|
|
|
|
|
17.1.44. .spec.exporters[].openTelemetry.tls.caCert
- 説明
-
caCertは、認証局の証明書の参照を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.45. .spec.exporters[].openTelemetry.tls.userCert
- 説明
-
userCertは、ユーザー証明書の参照を定義し、mTLS に使用されます。一方向 TLS を使用する場合は、このプロパティーを無視できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.46. .spec.kafka
- 説明
-
Kafka の設定。フロー収集パイプラインの一部において、Kafka をブローカーとして使用できるようになります。この設定を利用できるのは、
spec.deploymentModelがKafkaの場合です。 - 型
-
object - 必須
-
address -
topic
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| Kafka サーバーのアドレス |
|
|
| SASL 認証の設定。[サポート対象外 (*)]。 |
|
|
| TLS クライアント設定。TLS を使用する場合は、アドレスが TLS に使用される Kafka ポート (通常は 9093) と一致することを確認します。 |
|
|
| 使用する Kafka トピック。これは必ず存在する必要があります。Network Observability はこれを作成しません。 |
17.1.47. .spec.kafka.sasl
- 説明
- SASL 認証の設定。[サポート対象外 (*)]。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| クライアント ID を含むシークレットまたは config map への参照 |
|
|
| クライアントシークレットを含むシークレットまたは config map への参照 |
|
|
|
使用する SASL 認証のタイプ。SASL を使用しない場合は |
17.1.48. .spec.kafka.sasl.clientIDReference
- 説明
- クライアント ID を含むシークレットまたは config map への参照
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| config map またはシークレット内のファイル名。 |
|
|
| ファイルを含む config map またはシークレットの名前。 |
|
|
| ファイルを含む config map またはシークレットの namespace。省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
ファイル参照のタイプ ( |
17.1.49. .spec.kafka.sasl.clientSecretReference
- 説明
- クライアントシークレットを含むシークレットまたは config map への参照
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| config map またはシークレット内のファイル名。 |
|
|
| ファイルを含む config map またはシークレットの名前。 |
|
|
| ファイルを含む config map またはシークレットの namespace。省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
ファイル参照のタイプ ( |
17.1.50. .spec.kafka.tls
- 説明
- TLS クライアント設定。TLS を使用する場合は、アドレスが TLS に使用される Kafka ポート (通常は 9093) と一致することを確認します。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| TLS を有効にします。 |
|
|
|
|
|
|
|
|
17.1.51. .spec.kafka.tls.caCert
- 説明
-
caCertは、認証局の証明書の参照を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.52. .spec.kafka.tls.userCert
- 説明
-
userCertは、ユーザー証明書の参照を定義し、mTLS に使用されます。一方向 TLS を使用する場合は、このプロパティーを無視できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.53. .spec.loki
- 説明
-
loki(フローストア) のクライアント設定。 - 型
-
object - 必須
-
mode
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
Loki にフローを保存するには、 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Loki が Loki Operator を使用して管理されている場合は、
- Loki がモノリシックなワークロードとしてインストールされている場合は、
- Loki がマイクロサービスとしてインストールされているが、Loki Operator がない場合は、
- 上記のオプションが、いずれもお使いのセットアップに合わない場合は、 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
17.1.54. .spec.loki.advanced
- 説明
-
advancedを使用すると、Loki クライアントの内部設定のいくつかの側面を設定できます。このセクションは、デバッグと詳細なパフォーマンスの最適化を主な目的としています。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
17.1.55. .spec.loki.lokiStack
- 説明
-
LokiStackモードの Loki 設定。これは、Loki Operator を簡単に設定するのに役立ちます。他のモードでは無視されます。 - 型
-
object - 必須
-
name
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| 使用する既存の LokiStack リソースの名前。 |
|
|
|
この |
17.1.56. .spec.loki.manual
- 説明
-
Manualモードの Loki 設定。これは最も柔軟な設定です。他のモードでは無視されます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
-
-
-
Loki Operator を使用する場合、 |
|
|
|
|
|
|
|
|
|
|
| Loki ステータス URL の TLS クライアント設定。 |
|
|
|
|
|
|
|
|
|
|
| Loki URL の TLS クライアント設定。 |
17.1.57. .spec.loki.manual.statusTls
- 説明
- Loki ステータス URL の TLS クライアント設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| TLS を有効にします。 |
|
|
|
|
|
|
|
|
17.1.58. .spec.loki.manual.statusTls.caCert
- 説明
-
caCertは、認証局の証明書の参照を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.59. .spec.loki.manual.statusTls.userCert
- 説明
-
userCertは、ユーザー証明書の参照を定義し、mTLS に使用されます。一方向 TLS を使用する場合は、このプロパティーを無視できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.60. .spec.loki.manual.tls
- 説明
- Loki URL の TLS クライアント設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| TLS を有効にします。 |
|
|
|
|
|
|
|
|
17.1.61. .spec.loki.manual.tls.caCert
- 説明
-
caCertは、認証局の証明書の参照を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.62. .spec.loki.manual.tls.userCert
- 説明
-
userCertは、ユーザー証明書の参照を定義し、mTLS に使用されます。一方向 TLS を使用する場合は、このプロパティーを無視できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.63. .spec.loki.microservices
- 説明
-
Microservicesモードの Loki 設定。このオプションは、Loki がマイクロサービスデプロイメントモード (https://grafana.com/docs/loki/latest/fundamentals/architecture/deployment-modes/#microservices-mode) を使用してインストールされている場合に使用します。他のモードでは無視されます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Loki URL の TLS クライアント設定。 |
17.1.64. .spec.loki.microservices.tls
- 説明
- Loki URL の TLS クライアント設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| TLS を有効にします。 |
|
|
|
|
|
|
|
|
17.1.65. .spec.loki.microservices.tls.caCert
- 説明
-
caCertは、認証局の証明書の参照を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.66. .spec.loki.microservices.tls.userCert
- 説明
-
userCertは、ユーザー証明書の参照を定義し、mTLS に使用されます。一方向 TLS を使用する場合は、このプロパティーを無視できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.67. .spec.loki.monolithic
- 説明
-
Monolithicモードの Loki 設定。このオプションは、Loki がモノリシックデプロイメントモード (https://grafana.com/docs/loki/latest/fundamentals/architecture/deployment-modes/#monolithic-mode) を使用してインストールされている場合に使用します。他のモードでは無視されます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| Loki URL の TLS クライアント設定。 |
|
|
|
|
17.1.68. .spec.loki.monolithic.tls
- 説明
- Loki URL の TLS クライアント設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| TLS を有効にします。 |
|
|
|
|
|
|
|
|
17.1.69. .spec.loki.monolithic.tls.caCert
- 説明
-
caCertは、認証局の証明書の参照を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.70. .spec.loki.monolithic.tls.userCert
- 説明
-
userCertは、ユーザー証明書の参照を定義し、mTLS に使用されます。一方向 TLS を使用する場合は、このプロパティーを無視できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.71. .spec.networkPolicy
- 説明
-
networkPolicyは、Network Observability のコンポーネントを分離するためのネットワークポリシー設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| Network Observability で使用される (メインおよび特権付きの) namespace にネットワークポリシーをデプロイします。このネットワークポリシーにより、Network Observability コンポーネントが適切に分離され、コンポーネント間の不要な接続が防止されます。OVNKubernetes で使用する場合、このオプションはデフォルトで有効になっており、それ以外の場合は無効になっています (他の CNI ではテストされていません)。無効な場合は、Network Observability コンポーネントのネットワークポリシーを手動で作成できます。 |
17.1.72. .spec.processor
- 説明
-
processorは、エージェントからフローを受信してエンリッチし、メトリクスを生成して Loki 永続化レイヤーや利用可能なエクスポーターに転送するコンポーネントの設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
プロセッサーランタイムの |
|
|
|
- 通常のネットワークフローをエクスポートする場合は
-
-
- |
|
|
|
|
|
|
|
マルチクラスター機能を有効にするには、 |
|
|
|
|
|
|
| FlowCollectorSlices カスタムリソースを管理するグローバル設定。 |
|
|
|
|
|
|
|
|
17.1.73. .spec.processor.advanced
- 説明
-
advancedを使用すると、フロープロセッサーの内部設定のいくつかの側面を設定できます。このセクションは、GOGCやGOMAXPROCS環境変数などのデバッグと詳細なパフォーマンスの最適化を主な目的としています。これらの値はお客様の責任のもと設定してください。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| フローコレクターのポート (ホストポート)。慣例により、一部の値は禁止されています。1024 より大きい値とし、4500、4789、6081 は使用できません。 |
|
|
|
|
|
|
| scheduling は、Pod がノードでどのようにスケジュールされるかを制御します。 |
|
|
| リソース識別のためにチェックするセカンダリーネットワークを定義します。正確な識別を確実に行うために、インデックス値からクラスター全体で一意の識別子が形成されるようにする必要があります。同じインデックスが複数のリソースで使用されている場合、それらのリソースに誤ったラベルが付けられる可能性があります。 |
17.1.74. .spec.processor.advanced.scheduling
- 説明
- scheduling は、Pod がノードでどのようにスケジュールされるかを制御します。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| 指定した場合、Pod のスケジューリング制約。ドキュメントは、https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling を参照してください。 |
|
|
|
|
|
|
| 指定した場合、Pod の優先度を示します。ドキュメントは、https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#how-to-use-priority-and-preemption を参照してください。指定されていない場合はデフォルトの優先度が使用され、デフォルトの優先度がない場合は 0 が使用されます。 |
|
|
|
|
17.1.75. .spec.processor.advanced.scheduling.affinity
- 説明
- 指定した場合、Pod のスケジューリング制約。ドキュメントは、https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling を参照してください。
- 型
-
object
17.1.76. .spec.processor.advanced.scheduling.tolerations
- 説明
-
tolerationsは、一致する taint を持つノードに Pod がスケジュールできるようにする toleration のリストです。ドキュメントは、https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling を参照してください。 - 型
-
array
17.1.77. .spec.processor.advanced.secondaryNetworks
- 説明
- リソース識別のためにチェックするセカンダリーネットワークを定義します。正確な識別を確実に行うために、インデックス値からクラスター全体で一意の識別子が形成されるようにする必要があります。同じインデックスが複数のリソースで使用されている場合、それらのリソースに誤ったラベルが付けられる可能性があります。
- 型
-
array
17.1.78. .spec.processor.advanced.secondaryNetworks[]
- 説明
- 型
-
object - 必須
-
index -
name
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
17.1.79. .spec.processor.deduper
- 説明
-
deduperを使用すると、重複として識別されたフローをサンプリングまたはドロップして、リソース使用量を節約できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
プロセッサーの重複排除モードを設定します。エージェントは別々のノードから報告された同じフローを重複排除できないため、これはエージェントベースの重複排除に加えて設定されます。
-
- 重複と見なされる 50 (デフォルト) のフローのうち 1 つだけランダムに保持するには、
- プロセッサーベースの重複排除をオフにするには、 |
|
|
|
|
17.1.80. .spec.processor.filters
- 説明
-
filtersを使用すると、生成されるフローの量を制限するカスタムフィルターを定義できます。これらのフィルターは、Kubernetes namespace によるフィルター処理などを含め、eBPF エージェントフィルター (spec.agent.ebpf.flowFilter内) よりも柔軟性が高くなりますが、パフォーマンスの向上は少なくなります。 - 型
-
array
17.1.81. .spec.processor.filters[]
- 説明
-
FLPFilterSetは、すべての条件を満たす FLP ベースのフィルタリングに必要な設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
指定されている場合、これらのフィルターのターゲットが、1 つの出力 ( |
|
|
| 保存するネットワークフローを選択するクエリー。このクエリー言語の詳細は、https://github.com/netobserv/flowlogs-pipeline/blob/main/docs/filtering.md を参照してください。 |
|
|
|
|
17.1.82. .spec.processor.kafkaConsumerAutoscaler
- 説明
-
kafkaConsumerAutoscaler[非推奨 (*)] は、Kafka メッセージを消費するflowlogs-pipeline-transformer用に設定する水平 Pod オートスケーラーの仕様です。Kafka が無効な場合、この設定は無視されます。非推奨化のお知らせ: マネージドオートスケーラーは将来のバージョンで削除されます。代わりに、任意のオートスケーラーを設定し、spec.processor.unmanagedReplicasをtrueに設定することもできます。HorizontalPodAutoscaler のドキュメント (自動スケーリング/v2) を参照してください。 - 型
-
object
17.1.83. .spec.processor.metrics
- 説明
-
Metricsは、メトリクスに関するプロセッサー設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Prometheus スクレイパーのメトリクスサーバーエンドポイント設定 |
17.1.84. .spec.processor.metrics.healthRules
- 説明
-
healthRulesは、Prometheus 用に作成される健全性ルールのリストであり、テンプレートとバリアントによって整理されています。各健全性ルールは、mode フィールドに基づいて、アラートルールとレコーディングルールのどちらかを生成するように設定できます。健全性ルールの詳細情報: https://github.com/netobserv/network-observability-operator/blob/main/docs/HealthRules.md - 型
-
array
17.1.85. .spec.processor.metrics.healthRules[]
- 説明
- 型
-
object - 必須
-
template -
variants
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
mode は、この健全性ルールをアラートルールとして生成するか、レコーディングルールとして生成するかを定義します。指定可能な値は、 |
|
|
|
健全性ルールテンプレートの名前。指定可能な値は、 |
|
|
| このテンプレートのバリアントのリスト |
17.1.86. .spec.processor.metrics.healthRules[].variants
- 説明
- このテンプレートのバリアントのリスト
- 型
-
array
17.1.87. .spec.processor.metrics.healthRules[].variants[]
- 説明
- 型
-
object - 必須
-
thresholds
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
オプションのグループ化基準。指定可能な値は、 |
|
|
| 低ボリュームしきい値を使用すると、S/N 比を改善するために、トラフィック量が少なすぎるメトリクスを無視できます。これは絶対レート (コンテキストに応じて、1 秒あたりのバイト数または 1 秒あたりのパケット数) の形で指定します。指定した場合、浮動小数点数として解析可能である必要があります。 |
|
|
|
mode は、この特定のバリアントにおける健全性ルールのモードをオーバーライドします。指定されていない場合、親の健全性ルールのモードを継承します。指定可能な値は、 |
|
|
| 重大度ごとの健全性ルールのしきい値。これらの値は、アラートがトリガーされる基準となるエラーのパーセンテージとして表されます。浮動小数点数として解析可能である必要があります。アラートモードとレコーディングモードの両方に必要です。 |
|
|
| トレンド型の健全性ルールの場合に、基準値との比較に使用する期間。たとえば、"2h" は 2 時間の平均と比較することを意味します。デフォルトは 2h です。 |
|
|
| トレンド型の健全性ルールの場合に、基準値との比較に使用する時間オフセット。たとえば、"1d" は昨日と比較することを意味します。デフォルトは 1d です。 |
17.1.88. .spec.processor.metrics.healthRules[].variants[].thresholds
- 説明
- 重大度ごとの健全性ルールのしきい値。これらの値は、アラートがトリガーされる基準となるエラーのパーセンテージとして表されます。浮動小数点数として解析可能である必要があります。アラートモードとレコーディングモードの両方に必要です。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
重大度 |
|
|
|
重大度 |
|
|
|
重大度 |
17.1.89. .spec.processor.metrics.server
- 説明
- Prometheus スクレイパーのメトリクスサーバーエンドポイント設定
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| メトリクスサーバーの HTTP ポート。 |
|
|
| TLS 設定。 |
17.1.90. .spec.processor.metrics.server.tls
- 説明
- TLS 設定。
- 型
-
object - 必須
-
type
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TLS 設定のタイプを選択します。
- |
17.1.91. .spec.processor.metrics.server.tls.provided
- 説明
-
typeがProvidedに設定されている場合の TLS 設定。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.92. .spec.processor.metrics.server.tls.providedCaFile
- 説明
-
typeがProvidedに設定されている場合の CA ファイルへの参照。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| config map またはシークレット内のファイル名。 |
|
|
| ファイルを含む config map またはシークレットの名前。 |
|
|
| ファイルを含む config map またはシークレットの namespace。省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
ファイル参照のタイプ ( |
17.1.93. .spec.processor.resources
- 説明
-
resourcesは、このコンテナーが必要とするコンピューティングリソースです。詳細は、https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ を参照してください。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| limits は、許可されるコンピュートリソースの最大量を示します。詳細: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ |
|
|
| requests は、必要なコンピュートリソースの最小量を示します。コンテナーで requests が省略されている場合、明示的に limits が指定されていれば、limits がデフォルト値として使用されます。指定されていなければ、実装で定義されている値がデフォルト値として使用されます。リクエストは制限を超えることはできません。詳細: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ |
17.1.94. .spec.processor.slicesConfig
- 説明
- FlowCollectorSlices カスタムリソースを管理するグローバル設定。
- 型
-
object - 必須
-
enable
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
-
- |
|
|
|
|
|
|
|
|
17.1.95. .spec.processor.subnetLabels
- 説明
-
subnetLabelsを使用すると、サブネットと IP にカスタムラベルを定義したり、OpenShift Container Platform で認識されているサブネットの自動ラベル付けを有効にしたりできます。自動ラベル付けは、クラスターの外部トラフィックを識別するために使用されます。サブネットがフローの送信元 IP または宛先 IP と一致する場合、対応するフィールドSrcSubnetLabelまたはDstSubnetLabelが追加されます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
17.1.96. .spec.processor.subnetLabels.customLabels
- 説明
customLabelsを使用すると、クラスター外部のワークロードや Web サービスを識別するために、サブネットと IP のラベル付けをカスタマイズすることができます。デフォルトのクイックフィルターや提供されているサンプルメトリクスと連携して動作させるには、外部サブネットにEXT:というプレフィックスを付けてラベル付けするか、一切ラベル付けしないでおく必要があります。
openShiftAutoDetectが無効な場合や、OpenShift Container Platform を使用していない場合は、内部トラフィックと外部トラフィックを区別するために、クラスターサブネットのラベルを手動で設定することを推奨します。
openShiftAutoDetectが有効な場合、customLabelsは、検出されたサブネットが重複している場合に、検出されたサブネットをオーバーライドします。
- 型
-
array
17.1.97. .spec.processor.subnetLabels.customLabels[]
- 説明
- SubnetLabel を使用すると、クラスター外部のワークロードや Web サービスの識別などのために、サブネットと IP にラベルを付けることができます。
- 型
-
object - 必須
-
cidrs -
name
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
マッチしたフローにフラグを設定するために使用するラベル名。デフォルトのクイックフィルターや提供されているサンプルメトリクスと連携して動作させるには、外部サブネットに |
17.1.98. .spec.prometheus
- 説明
-
prometheusは、コンソールプラグインからメトリクスを取得するために使用されるクエリー設定などの Prometheus 設定を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| コンソールプラグインで使用される、クライアント設定などの Prometheus クエリー設定。 |
17.1.99. .spec.prometheus.querier
- 説明
- コンソールプラグインで使用される、クライアント設定などの Prometheus クエリー設定。
- 型
-
object - 必須
-
mode
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
- 自動設定を試行するには、
- 手動設定の場合は、 |
|
|
|
|
17.1.100. .spec.prometheus.querier.manual
- 説明
-
Manualモードの Prometheus 設定。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| AlertManager の設定。これは、健全性情報を表示するために、サイレンスが適用されたアラートを照会する目的でコンソールで使用されます。OpenShift Container Platform で使用する場合、コンソール API を使用するために空のままにしておくことができます [サポート対象外 (*)]。 |
|
|
|
ログインしたユーザートークンをクエリーで Prometheus に転送するには、 |
|
|
| Prometheus URL の TLS クライアント設定。 |
|
|
|
|
17.1.101. .spec.prometheus.querier.manual.alertManager
- 説明
- AlertManager の設定。これは、健全性情報を表示するために、サイレンスが適用されたアラートを照会する目的でコンソールで使用されます。OpenShift Container Platform で使用する場合、コンソール API を使用するために空のままにしておくことができます [サポート対象外 (*)]。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| Prometheus AlertManager URL の TLS クライアント設定。 |
|
|
|
|
17.1.102. .spec.prometheus.querier.manual.alertManager.tls
- 説明
- Prometheus AlertManager URL の TLS クライアント設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| TLS を有効にします。 |
|
|
|
|
|
|
|
|
17.1.103. .spec.prometheus.querier.manual.alertManager.tls.caCert
- 説明
-
caCertは、認証局の証明書の参照を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.104. .spec.prometheus.querier.manual.alertManager.tls.userCert
- 説明
-
userCertは、ユーザー証明書の参照を定義し、mTLS に使用されます。一方向 TLS を使用する場合は、このプロパティーを無視できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.105. .spec.prometheus.querier.manual.tls
- 説明
- Prometheus URL の TLS クライアント設定。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| TLS を有効にします。 |
|
|
|
|
|
|
|
|
17.1.106. .spec.prometheus.querier.manual.tls.caCert
- 説明
-
caCertは、認証局の証明書の参照を定義します。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
17.1.107. .spec.prometheus.querier.manual.tls.userCert
- 説明
-
userCertは、ユーザー証明書の参照を定義し、mTLS に使用されます。一方向 TLS を使用する場合は、このプロパティーを無視できます。 - 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 証明書を含む config map またはシークレットの名前。 |
|
|
| 証明書を含む config map またはシークレットの namespace省略した場合、デフォルトでは、Network Observability がデプロイされているのと同じ namespace が使用されます。namespace が異なる場合は、必要に応じてマウントできるように、config map またはシークレットがコピーされます。 |
|
|
|
証明書参照のタイプ ( |
第18章 FlowMetric 設定パラメーター
FlowMetric API は、収集されたネットワークフローログからカスタムのオブザーバビリティーメトリクスを生成するために使用されます。
18.1. FlowMetric [flows.netobserv.io/v1alpha1]
- 説明
- FlowMetric は、収集されたフローログからカスタムメトリクスを作成することを可能にする API です。
- 型
-
object
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| APIVersion はオブジェクトのこの表現のバージョンスキーマを定義します。サーバーは認識されたスキーマを最新の内部値に変換し、認識されない値は拒否することがあります。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources を参照してください。 |
|
|
| kind はこのオブジェクトが表す REST リソースを表す文字列の値です。サーバーは、クライアントが要求を送信するエンドポイントからこれを推測できることがあります。これを更新することはできません。CamelCase を使用します。詳細: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds |
|
|
| 標準オブジェクトのメタデータ。詳細: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata |
|
|
|
FlowMetricSpec は、FlowMetric の目的の状態を定義します。提供されている API を使用すると、ニーズに応じてこれらのメトリクスをカスタマイズできます。
新しいメトリクスを追加したり、既存のラベルを変更したりする場合は、大きな影響を与える可能性があります。そのため、Prometheus ワークロードのメモリー使用量を注意深く監視する必要があります。https://rhobs-handbook.netlify.app/products/openshiftmonitoring/telemetry.md/#what-is-the-cardinality-of-a-metric
すべての Network Observability メトリクスのカーディナリティーを確認するには、 |
18.1.1. .metadata
- 説明
- 標準オブジェクトのメタデータ。詳細は、https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata を参照してください。
- 型
-
object
18.1.2. .spec
- 説明
FlowMetricSpec は、FlowMetric の目的の状態を定義します。提供されている API を使用すると、ニーズに応じてこれらのメトリクスをカスタマイズできます。
新しいメトリクスを追加したり、既存のラベルを変更したりする場合は、大きな影響を与える可能性があります。そのため、Prometheus ワークロードのメモリー使用量を注意深く監視する必要があります。https://rhobs-handbook.netlify.app/products/openshiftmonitoring/telemetry.md/#what-is-the-cardinality-of-a-metric
を参照してください。すべての Network Observability メトリクスのカーディナリティーを確認するには、
promql:count({name=~"netobserv.*"}) by (name)を実行します。- 型
-
object - 必須
-
type
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
|
|
|
| 管理者ビューの Dashboards メニューにある OpenShift Container Platform コンソールのチャート設定。 |
|
|
|
Ingress、Egress、または任意の方向のフローをフィルタリングします。 |
|
|
| ゼロ以外の場合、値の換算係数 (除数)。メトリクス値 = フロー値/除数。 |
|
|
|
|
|
|
|
|
|
|
| Prometheus に表示されるメトリクスのヘルプテキスト。 |
|
|
|
|
|
|
|
メトリクスの名前。Prometheus では、自動的に "netobserv_" という接頭辞が付けられます。 |
|
|
|
生成されるメトリクスラベルにフローフィールドとは異なる名前を使用するには、 |
|
|
| メトリクスタイプ: "Counter"、"Histogram"、または"Gauge"。"Counter" は、バイト数やパケット数など、時間の経過とともに増加し、レートを計算できる値に使用します。"Histogram" は、遅延など、個別にサンプリングする必要がある値に使用します。"Gauge" は、経時的な正確さが必要がないその他の値に使用します (ゲージは、Prometheus がメトリクスを取得するときに N 秒ごとにのみサンプリングされます)。 |
|
|
|
|
18.1.3. .spec.charts
- 説明
- 管理者ビューの Dashboards メニューにある OpenShift Container Platform コンソールのチャート設定。
- 型
-
array
18.1.4. .spec.charts[]
- 説明
- メトリクスに関連するグラフ/ダッシュボード生成を設定します。
- 型
-
object - 必須
-
dashboardName -
queries -
title -
type
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| 配置先のダッシュボードの名前。この名前が既存のダッシュボードを示すものでない場合は、新しいダッシュボードが作成されます。 |
|
|
|
このグラフに表示するクエリーのリスト。 |
|
|
|
配置先のダッシュボードセクションの名前。この名前が既存のセクションを示すものでない場合は、新しいセクションが作成されます。 |
|
|
| グラフのタイトル。 |
|
|
| グラフの種類。 |
|
|
| このグラフの単位。現在サポートされている単位はごく少数です。一般的な数字を使用する場合は空白のままにします。 |
18.1.5. .spec.charts[].queries
- 説明
-
このグラフに表示するクエリーのリスト。
typeがSingleStatで、複数のクエリーが指定されている場合、このグラフは複数のパネル (クエリーごとに 1 つ) に自動的に展開されます。 - 型
-
array
18.1.6. .spec.charts[].queries[]
- 説明
- PromQL クエリーを設定します。
- 型
-
object - 必須
-
legend -
promQL -
top
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
このグラフに表示する各時系列に適用するクエリーの凡例。複数の時系列を表示する場合は、それぞれを区別する凡例を設定する必要があります。これは |
|
|
|
Prometheus に対して実行する |
|
|
|
タイムスタンプごとに表示する上位 N 個の系列。 |
18.1.7. .spec.filters
- 説明
-
filtersは、考慮されるフローを制限するために使用するフィールドと値のリストです。使用可能なフィールドのリストは、ドキュメント https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/network_observability/json-flows-format-reference を参照してください。 - 型
-
array
18.1.8. .spec.filters[]
- 説明
- 型
-
object - 必須
-
field -
matchType
-
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
|
フィルタリングするフィールドの名前 (例: |
|
|
| 適用するマッチングのタイプ |
|
|
|
フィルタリングする値。 |
第19章 ネットワークフロー形式のリファレンス
ネットワークフロー形式の仕様をご確認ください。この仕様は、フローデータを Kafka にエクスポートするために内部的に使用されます。
19.1. ネットワークフロー形式のリファレンス
これはネットワークフロー形式の仕様です。この形式は、Prometheus メトリクスラベルに、および内部で Loki ストアに Kafka エクスポーターが設定されているときに使用されます。
"フィルター ID" 列は、クイックフィルターを定義するときに使用する関連名を示します (FlowCollector 仕様の spec.consolePlugin.quickFilters を参照)。
"Loki ラベル" 列は、Loki に直接クエリーを実行する場合に役立ちます。ラベルフィールドは、stream selectors を使用して選択する必要があります。
"カーディナリティー" 列は、このフィールドが FlowMetrics API で Prometheus ラベルとして使用される場合の暗黙のメトリクスカーディナリティーに関する情報を示します。この API の使用に関する詳細は、FlowMetrics のドキュメントを参照してください。
| 名前 | 型 | 説明 | フィルター ID | Loki ラベル | カーディナリティー | OpenTelemetry |
|---|---|---|---|---|---|---|
|
| number | バイト数 | 該当なし | いいえ | avoid | bytes |
|
| number | DNS トラッカーの ebpf フック関数から返されたエラー番号 |
| いいえ | fine | dns.errno |
|
| number | DNS レコードの DNS フラグ | 該当なし | いいえ | fine | dns.flags |
|
| string | 解析された DNS ヘッダーの RCODEs 名 |
| いいえ | fine | dns.responsecode |
|
| number | DNS レコード id |
| いいえ | avoid | dns.id |
|
| number | DNS リクエストとレスポンスの間の時間 (ミリ秒単位) |
| いいえ | avoid | dns.latency |
|
| string | DNS クエリー名 |
| いいえ | careful | 該当なし |
|
| number | Differentiated Services Code Point (DSCP) の値 |
| いいえ | fine | dscp |
|
| string | 宛先 IP アドレス (ipv4 または ipv6) |
| いいえ | avoid | destination.address |
|
| string | 送信先ノード IP |
| いいえ | fine | destination.k8s.host.address |
|
| string | 送信先ノード名 |
| いいえ | fine | destination.k8s.host.name |
|
| string | 宛先 Kubernetes オブジェクトの名前 (Pod 名、Service 名、Node 名など)。 |
| いいえ | careful | destination.k8s.name |
|
| string | 宛先 namespace |
| はい | fine | destination.k8s.namespace.name |
|
| string | 宛先ネットワーク名 |
| いいえ | fine | 該当なし |
|
| string | 宛先所有者の名前 (Deployment 名、StatefulSet 名など)。 |
| はい | fine | destination.k8s.owner.name |
|
| string | 宛先所有者の種類 (Deployment、StatefulSet など)。 |
| いいえ | fine | destination.k8s.owner.kind |
|
| string | 宛先 Kubernetes オブジェクトの種類 (Pod、Service、Node など)。 |
| はい | fine | destination.k8s.kind |
|
| string | 宛先アベイラビリティーゾーン |
| はい | fine | destination.zone |
|
| string | 宛先 MAC アドレス |
| いいえ | avoid | destination.mac |
|
| number | 送信先ポート |
| いいえ | careful | destination.port |
|
| string | 宛先サブネットラベル |
| いいえ | fine | destination.subnet.label |
|
| string[] |
RFC-9293 に基づく、フローに含まれる TCP フラグのリスト。パケットごとの組み合わせ ( |
| いいえ | careful | tcp.flags |
|
| number |
ノード観測点から解釈されたフローの方向。次のいずれかになります。 |
| はい | fine | host.direction |
|
| string | IPsec 暗号化のステータス (Egress 時、カーネルの xfrm_output 関数によって指定) または復号化のステータス (Ingress 時、xfrm_input 経由) |
| いいえ | fine | 該当なし |
|
| number | ICMP コード |
| いいえ | fine | icmp.code |
|
| number | ICMP のタイプ |
| いいえ | fine | icmp.type |
|
| number[] |
ネットワークインターフェイス観測点からのフローの方向。次のいずれかになります。 |
| いいえ | fine | interface.directions |
|
| string[] | ネットワークインターフェイス |
| いいえ | careful | interface.names |
|
| string | クラスター名またはクラスター識別子 |
| はい | fine | k8s.cluster.name |
|
| string | フローのレイヤー: 'app' または 'infra' |
| はい | fine | k8s.layer |
|
| object[] |
ネストされたフィールドで構成されるネットワークポリシーアクションなどのネットワークイベント: |
| いいえ | avoid | 該当なし |
|
| number | パケット数 | 該当なし | いいえ | avoid | packets |
|
| number | カーネルによってドロップされたバイト数 | 該当なし | いいえ | avoid | drops.bytes |
|
| string | 最新のドロップの原因 |
| いいえ | fine | drops.latestcause |
|
| number | 最後にドロップされたパケットの TCP フラグ | 該当なし | いいえ | fine | drops.latestflags |
|
| string | 最後にドロップされたパケットの TCP 状態 |
| いいえ | fine | drops.lateststate |
|
| number | カーネルによってドロップされたパケットの数 | 該当なし | いいえ | avoid | drops.packets |
|
| number | L4 プロトコル |
| いいえ | fine | protocol |
|
| number | このフローで使用されるサンプリング間隔 | 該当なし | いいえ | fine | 該当なし |
|
| string | 送信元 IP アドレス (ipv4 または ipv6) |
| いいえ | avoid | source.address |
|
| string | 送信元ノード IP |
| いいえ | fine | source.k8s.host.address |
|
| string | 送信元ノード名 |
| いいえ | fine | source.k8s.host.name |
|
| string | 送信元 Kubernetes オブジェクトの名前 (Pod 名、サービス名、ノード名など) |
| いいえ | careful | source.k8s.name |
|
| string | 送信元 namespace |
| はい | fine | source.k8s.namespace.name |
|
| string | 送信元ネットワーク名 |
| いいえ | fine | 該当なし |
|
| string | 送信元所有者の名前 (Deployment 名、StatefulSet 名など)。 |
| はい | fine | source.k8s.owner.name |
|
| string | 送信元所有者の種類 (Deployment、StatefulSet など)。 |
| いいえ | fine | source.k8s.owner.kind |
|
| string | 送信元 Kubernetes オブジェクトの種類 (Pod、Service、Node など)。 |
| はい | fine | source.k8s.kind |
|
| string | 送信元アベイラビリティーゾーン |
| はい | fine | source.zone |
|
| string | 送信元 MAC アドレス |
| いいえ | avoid | source.mac |
|
| number | 送信元ポート |
| いいえ | careful | source.port |
|
| string | 送信元サブネットラベル |
| いいえ | fine | source.subnet.label |
|
| number | このフローの終了タイムスタンプ (ミリ秒単位) | 該当なし | いいえ | avoid | timeflowend |
|
| number | TCP の平滑化されたラウンドトリップタイム (SRTT) (ナノ秒単位) |
| いいえ | avoid | tcp.rtt |
|
| number | このフローの開始タイムスタンプ (ミリ秒単位) | 該当なし | いいえ | avoid | timeflowstart |
|
| number | このフローがフローコレクターによって受信および処理されたときのタイムスタンプ (秒単位) | 該当なし | いいえ | avoid | timereceived |
|
| string[] | ユーザー定義ネットワークのリスト |
| いいえ | careful | 該当なし |
|
| string | パケット変換の送信先アドレス |
| いいえ | avoid | 該当なし |
|
| number | パケット変換の送信先ポート |
| いいえ | careful | 該当なし |
|
| string | パケット変換の送信元アドレス |
| いいえ | avoid | 該当なし |
|
| number | パケット変換の送信元ポート |
| いいえ | careful | 該当なし |
|
| number | パケット変換のゾーン ID |
| いいえ | avoid | 該当なし |
|
| string | 会話トラッキングにおける会話の識別子 |
| いいえ | avoid | 該当なし |
|
| string |
レコードの種類: 通常のフローログの場合は |
| はい | fine | 該当なし |
第20章 Network Observability のトラブルシューティング
Network Observability Operator とそのコンポーネントに関連する一般的な問題をトラブルシューティングするための診断アクションを実行します。
20.1. must-gather ツールの使用
must-gather ツールを使用して、Pod のログや設定の詳細など、Network Observability Operator リソースに関する診断情報を収集し、クラスターの問題のトラブルシューティングに役立ててください。
手順
- must-gather データを保存するディレクトリーに移動します。
次のコマンドを実行して、クラスター全体の must-gather リソースを収集します。
$ oc adm must-gather --image-stream=openshift/must-gather \ --image=quay.io/netobserv/must-gather
20.2. OpenShift Container Platform コンソールでのネットワークトラフィックメニューエントリーの設定
OpenShift Container Platform コンソールの Observe メニューにないネットワークトラフィックメニューエントリーを復元するには、FlowCollector リソースとコンソール Operator 設定にコンソールプラグインを手動で登録します。
前提条件
- OpenShift Container Platform バージョン 4.10 以降がインストールされている。
手順
次のコマンドを実行して、
spec.consolePlugin.registerフィールドがtrueに設定されているかどうかを確認します。$ oc -n netobserv get flowcollector cluster -o yaml出力例
apiVersion: flows.netobserv.io/v1alpha1 kind: FlowCollector metadata: name: cluster spec: consolePlugin: register: falseオプション: Console Operator 設定を手動で編集して、
netobserv-pluginプラグインを追加します。$ oc edit console.operator.openshift.io cluster出力例
... spec: plugins: - netobserv-plugin ...オプション: 次のコマンドを実行して、
spec.consolePlugin.registerフィールドをtrueに設定します。$ oc -n netobserv edit flowcollector cluster -o yaml出力例
apiVersion: flows.netobserv.io/v1alpha1 kind: FlowCollector metadata: name: cluster spec: consolePlugin: register: true次のコマンドを実行して、コンソール Pod のステータスが
runningであることを確認します。$ oc get pods -n openshift-console -l app=console次のコマンドを実行して、コンソール Pod を再起動します。
$ oc delete pods -n openshift-console -l app=console- ブラウザーのキャッシュと履歴をクリアします。
次のコマンドを実行して、Network Observability プラグイン Pod のステータスを確認します。
$ oc get pods -n netobserv -l app=netobserv-plugin出力例
NAME READY STATUS RESTARTS AGE netobserv-plugin-68c7bbb9bb-b69q6 1/1 Running 0 21s次のコマンドを実行して、Network Observability プラグイン Pod のログを確認します。
$ oc logs -n netobserv -l app=netobserv-plugin出力例
time="2022-12-13T12:06:49Z" level=info msg="Starting netobserv-console-plugin [build version: , build date: 2022-10-21 15:15] at log level info" module=main time="2022-12-13T12:06:49Z" level=info msg="listening on https://:9001" module=server
20.3. Kafka をインストールした後、Flowlogs-Pipeline がネットワークフローを消費しない
フローパイプラインが Kafka からのネットワークフローを消費できない場合は、フローパイプライン Pod を手動で再起動して、フローコレクターと Kafka デプロイメント間の接続を復元することで問題を解決します。
最初に deploymentModel: KAFKA を使用してフローコレクターをデプロイし、次に Kafka をデプロイした場合、フローコレクターが Kafka に正しく接続されない可能性があります。Flowlogs-pipeline が Kafka からのネットワークフローを消費しないフローパイプライン Pod を手動で再起動します。
手順
次のコマンドを実行して、フローパイプライン Pod を削除して再起動します。
$ oc delete pods -n netobserv -l app=flowlogs-pipeline-transformer
20.4. br-int インターフェイスと br-ex インターフェイスの両方からのネットワークフローが表示されない
br-int や br-ex などの仮想ブリッジデバイスのインターフェイス制限を解除することで、ネットワークフローが欠落している問題を解決し、eBPF エージェントが適切なレイヤー 3 インターフェイスに接続できるようにします。
br-ex と br-int は、OSI レイヤー 2 で動作する仮想ブリッジデバイスです。eBPF エージェントは、IP レベルと TCP レベル、それぞれレイヤー 3 と 4 で動作します。ネットワークトラフィックが物理ホストや仮想 Pod インターフェイスなどの他のインターフェイスによって処理される場合、eBPF エージェントは br-ex および br-int を通過するネットワークトラフィックをキャプチャすることが期待できます。eBPF エージェントのネットワークインターフェイスを br-ex および br-int のみに接続するように制限すると、ネットワークフローは表示されません。
ネットワークインターフェイスを br-int および br-ex に制限する interfaces または excludeInterfaces の部分を手動で削除します。
手順
interfaces: [ 'br-int', 'br-ex' ]フィールド。これにより、エージェントはすべてのインターフェイスから情報を取得できます。または、レイヤー 3 インターフェイス (例:eth0) を指定することもできます。以下のコマンドを実行します。$ oc edit -n netobserv flowcollector.yaml -o yaml出力例
apiVersion: flows.netobserv.io/v1alpha1 kind: FlowCollector metadata: name: cluster spec: agent: type: EBPF ebpf: interfaces: [ 'br-int', 'br-ex' ]1 - 1
- ネットワークインターフェイスを指定します。
20.5. ネットワークオブザーバビリティーコントローラーマネージャー Pod のメモリーが不足する
Network Observability Operator のメモリー問題を解決するには、Subscription オブジェクトのメモリー制限を増やし、コントローラーマネージャー Pod のメモリー不足を防ぎます。
Subscription オブジェクトの spec.config.resources.limits.memory 仕様を編集することで、Network Observability Operator のメモリー制限を引き上げることができます。
手順
- Web コンソールで、Ecosystem → Installed Operators に移動します。
- Network Observability をクリックし、Subscription を選択します。
Actions メニューから、Edit Subscription をクリックします。
または、CLI を使用して次のコマンドを実行して、
Subscriptionオブジェクトの YAML 設定を開くこともできます。$ oc edit subscription netobserv-operator -n openshift-netobserv-operator
Subscriptionオブジェクトを編集してconfig.resources.limits.memory仕様を追加し、メモリー要件を考慮して値を設定します。リソースに関する考慮事項の詳細は、関連情報を参照してください。apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: netobserv-operator namespace: openshift-netobserv-operator spec: channel: stable config: resources: limits: memory: 800Mi1 requests: cpu: 100m memory: 100Mi installPlanApproval: Automatic name: netobserv-operator source: redhat-operators sourceNamespace: openshift-marketplace startingCSV: <network_observability_operator_latest_version>2
20.6. Loki へのカスタムクエリーの実行
コマンドラインインターフェイスを使用して、カスタム Loki クエリーを実行して利用可能なラベルを取得したり、送信元の namespace など、特定の基準でログをフィルタリングしたりすることで、ネットワークフローデータのトラブルシューティングを行います。
これを行う方法の例が 2 つあり、<api_token> を独自のものに置き換えることで、ニーズに合わせて調整できます。
これらの例では、Network Observability Operator および Loki デプロイメントに netobserv namespace を使用します。さらに、例では、LokiStack の名前が loki であると想定しています。オプションで、例 (具体的には -n netobserv または loki-gateway URL) を調整して、異なる namespace と命名を使用することもできます。
前提条件
- Network Observability Operator と組み合わせて使用するために、Loki Operator がインストールされている。
手順
利用可能なすべてのラベルを取得するには、次のコマンドを実行します。
$ oc exec deployment/netobserv-plugin -n netobserv -- curl -G -s -H 'X-Scope-OrgID:network' -H 'Authorization: Bearer <api_token>' -k https://loki-gateway-http.netobserv.svc:8080/api/logs/v1/network/loki/api/v1/labels | jq送信元の namespace
my-namespaceからすべてのフローを取得するには、次のコマンドを実行します。$ oc exec deployment/netobserv-plugin -n netobserv -- curl -G -s -H 'X-Scope-OrgID:network' -H 'Authorization: Bearer <api_token>' -k https://loki-gateway-http.netobserv.svc:8080/api/logs/v1/network/loki/api/v1/query --data-urlencode 'query={SrcK8S_Namespace="my-namespace"}' | jq
20.7. Loki の ResourceExhausted エラーのトラブルシューティング
Loki の ResourceExhausted エラーを解決するには、FlowCollector リソースの batchSize を調整するか、Loki 設定の最大メッセージサイズ設定を調整して、フローデータがメモリー制限内に収まるようにします。
Network Observability によって送信されたネットワークフローデータが、設定された最大メッセージサイズを超えると、Loki は ResourceExhausted エラーを返すことがあります。Red Hat Loki Operator を使用している場合、この最大メッセージサイズは 100 MiB に設定されています。
手順
- Ecosystem → Installed Operators に移動し、Project ドロップダウンメニューから All projects を表示します。
- Provided APIs リストで、Network Observability Operator を選択します。
Flow Collector をクリックし、YAML view タブをクリックします。
-
Loki Operator を使用している場合は、
spec.loki.batchSize値が 98 MiB を超えていないことを確認してください。 -
Red Hat Loki Operator とは異なる Loki インストール方法 (Grafana Loki など) を使用している場合は、Grafana Loki サーバー設定 の
grpc_server_max_recv_msg_sizeが、FlowCollectorリソースのspec.loki.batchSize値より大きいことを確認してください。大きくない場合は、grpc_server_max_recv_msg_size値を増やすか、spec.loki.batchSize値を制限値よりも小さくなるように減らす必要があります。
-
Loki Operator を使用している場合は、
- FlowCollector を編集した場合は、Save をクリックします。
20.8. Loki の empty ring エラー
Loki の "empty ring" エラーを調査して解決するには、Pod の健全性を確認したり、古い永続ボリューム要求をクリアしたり、Pod を再起動して接続を復元したりして、ネットワークフローが適切に保存および表示されるようにします。
Loki の "empty ring" エラーにより、フローが Loki に保存されず、Web コンソールに表示されなくなります。このエラーはさまざまな状況で発生する可能性があります。これらすべてに対処できる 1 つの回避策はありません。Loki Pod 内のログを調査し、LokiStack が健全な状態で準備が整っていることを確認するために、いくつかのアクションを実行できます。
このエラーが発生する状況には次のようなものがあります。
LokiStackをアンインストールし、同じ namespace に再インストールすると、古い PVC が削除されないため、このエラーが発生する可能性があります。-
アクション:
LokiStackを再度削除し、PVC を削除してから、LokiStackの再インストールをお試しください。
-
アクション:
証明書のローテーション後、このエラーにより、
flowlogs-pipelinePod およびconsole-pluginPod との通信が妨げられる可能性があります。- アクション: Pod を再起動すると、接続を復元できます。
20.9. LokiStack レート制限エラー
Loki のレート制限エラーを解決し、データ損失を防ぐには、LokiStack リソースを更新して、ネットワークオブザーバビリティーデータストリームの取り込みレートとバースト制限を引き上げます。
Loki テナントにレート制限が設定されていると、データが一時的に失われ、429 エラー (Per stream rate limit exceeded (limit:xMB/sec) while attempting to ingest for stream) が発生する可能性があります。このエラーを通知するようにアラートを設定することを検討してください。詳細は、このセクションの関連情報として記載されている「NetObserv ダッシュボードの Loki レート制限アラートの作成」を参照してください。
次に示す手順を実行して、perStreamRateLimit および perStreamRateLimitBurst 仕様で LokiStack CRD を更新できます。
手順
- Ecosystem → Installed Operators に移動し、Project ドロップダウンから All projects を表示します。
- Loki Operator を見つけて、LokiStack タブを選択します。
YAML view を使用して LokiStack インスタンスを作成するか既存のものを編集し、
perStreamRateLimitおよびperStreamRateLimitBurst仕様を追加します。apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: loki namespace: netobserv spec: limits: global: ingestion: perStreamRateLimit: 61 perStreamRateLimitBurst: 302 tenants: mode: openshift-network managementState: Managed- Save をクリックします。
検証
perStreamRateLimit および perStreamRateLimitBurst 仕様を更新すると、クラスター内の Pod が再起動し、429 レート制限エラーが発生しなくなります。
20.10. 大きなクエリーを実行すると Loki エラーが発生する
インデックス付きフィルターの使用、長期間にわたる Prometheus の利用、カスタムメトリクスの作成、Loki および FlowCollector のパフォーマンス設定の調整などにより、大規模なクエリーを実行する際に発生する Loki のタイムアウトやリクエストエラーを軽減する方法を説明します。
大規模なクエリーを長時間実行すると、timeout や too many outstanding requests などの Loki エラーが発生する可能性があります。この問題を完全に修正する方法はありませんが、軽減する方法はいくつかあります。
- クエリーを調整してインデックス付きフィルターを追加する
-
Loki クエリーを使用すると、インデックスが付けられたフィールドまたはラベルと、インデックスが付けられていないフィールドまたはラベルの両方に対してクエリーを実行できます。ラベルにフィルターを含むクエリーのパフォーマンスが向上します。たとえば、インデックス付きフィールドではない特定の Pod をクエリーする場合は、その namespace をクエリーに追加できます。インデックス付きフィールドのリストは、"Network flows format reference" の
Loki label列にあります。 - Loki ではなく Prometheus にクエリーすることを検討する
- 長い時間範囲でクエリーを実行するには、Loki よりも Prometheus の方が適しています。ただし、Loki の代わりに Prometheus を使用できるかどうかは、ユースケースによって異なります。たとえば、Prometheus のクエリーは Loki よりもはるかに高速であり、時間範囲が長くてもパフォーマンスに影響はありません。しかし、Prometheus メトリクスには、Loki のフローログほど多くの情報は含まれていません。Network Observability OpenShift Web コンソールは、クエリーに互換性がある場合は、自動的に Loki よりも Prometheus を優先します。互換性がない場合は、デフォルトで Loki が使用されます。クエリーが Prometheus に対して実行されない場合は、いくつかのフィルターまたは集計を変更して切り替えることができます。OpenShift Web コンソールでは、Prometheus の使用を強制できます。互換性のないクエリーが失敗するとエラーメッセージが表示され、クエリーを互換性のあるものにするためにどのラベルを変更すればよいかを判断するのに役立ちます。たとえば、フィルターまたは集計を Resource または Pods から Owner に変更します。
- FlowMetrics API を使用して独自のメトリクスを作成することを検討する
- 必要なデータが Prometheus メトリクスとして利用できない場合は、FlowMetrics API を使用して独自のメトリクスを作成できます。詳細は、「FlowMetrics API リファレンス」および「FlowMetric API を使用したカスタムメトリクスの設定」を参照してください。
- クエリーパフォーマンスを向上させるために Loki を設定する
問題が解決しない場合は、クエリーのパフォーマンスを向上させるために Loki を設定することを検討してください。一部のオプションは、Operator と
LokiStackの使用、Monolithicモード、Microservicesモードなど、Loki に使用したインストールモードによって異なります。-
LokiStackまたはMicroservicesモードでは、クエリーレプリカの数を増やして みてください。 -
クエリーのタイムアウト を増やします。また、
FlowCollectorspec.loki.readTimeoutで、Loki への Network Observability の読み取りタイムアウトを増やす必要があります。
-
'%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}