第1章 Network Observability Operator リリースノート
Network Observability Operator を使用すると、管理者は OpenShift Container Platform クラスターのネットワークトラフィックフローを観察および分析できます。
これらのリリースノートは、OpenShift Container Platform での Network Observability Operator の開発を追跡します。
Network Observability Operator の概要は、Network Observability Operator について を参照してください。
1.1. Network Observability Operator 1.7.0
Network Observability Operator 1.7.0 では、次のアドバイザリーを利用できます。
1.1.1. 新機能および機能拡張
1.1.1.1. OpenTelemetry のサポート
エンリッチされたネットワークフローを、Red Hat build of OpenTelemetry などの互換性のある OpenTelemetry エンドポイントにエクスポートできるようになりました。詳細は、エンリッチされたネットワークフローデータのエクスポート を参照してください。
1.1.1.2. Network Observability Developer パースペクティブ
Developer パースペクティブで Network Observability を使用できるようになりました。詳細は、OpenShift Container Platform コンソールの統合 を参照してください。
1.1.1.3. TCP フラグフィルタリング
tcpFlags フィルターを使用して、eBPF プログラムによって処理されるパケットの量を制限できるようになりました。詳細は、フローフィルターの設定パラメーター、eBPF フローのルールフィルター、および FlowMetric API と TCP フラグを使用した SYN フラッディングの検出 を参照してください。
1.1.1.4. OpenShift Virtualization の Network Observability
Open Virtual Network (OVN)-Kubernetes などを介してセカンダリーネットワークに接続された仮想マシンから送信される eBPF エンリッチ化ネットワークフローを検出することで、OpenShift Virtualization 環境のネットワークパターンを観測できます。詳細は、仮想マシン (VM) のセカンダリーネットワークインターフェイスを Network Observability 用に設定する を参照してください。
1.1.1.5. FlowCollector カスタムリソース (CR) でのネットワークポリシーのデプロイ
このリリースでは、FlowCollector CR を設定して、Network Observability のネットワークポリシーをデプロイできます。以前は、ネットワークポリシーが必要な場合は、手動で作成する必要がありました。ネットワークポリシーを手動で作成するオプションは引き続き利用可能です。詳細は、FlowCollector カスタムリソースを使用した Ingress ネットワークポリシーの設定 を参照してください。
1.1.1.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 暗号化ライブラリーを使用します。
1.1.1.7. eBPF エージェントの機能拡張
eBPF エージェントで次の機能拡張を利用できます。
-
DNS サービスが
53以外のポートにマッピングされている場合は、spec.agent.ebpf.advanced.env.DNS_TRACKING_PORTを使用して、この DNS 追跡ポートを指定できます。 - トランスポートプロトコル (TCP、UDP、または SCTP) のフィルタリングルールに 2 つのポートを使用できるようになりました。
- プロトコルフィールドを空のままにしておくことで、ワイルドカードプロトコルを使用してトランスポートポートをフィルタリングできるようになりました。
詳細は、FlowCollector API 仕様 を参照してください。
1.1.1.8. Network Observability CLI
Network Observability CLI (oc netobserv) が一般提供になりました。1.6 テクノロジープレビューリリース以降、次の機能拡張が行われました。* フローキャプチャーと同様に、パケットキャプチャー用の eBPF エンリッチメントフィルターが追加されました。* フローキャプチャーとパケットキャプチャーの両方でフィルター tcp_flags を使用できるようになりました。* 最大バイト数または最大時間に達したときに、自動ティアダウンオプションを利用できます。詳細は、Network Observability CLI および Network Observability CLI 1.7.0 を参照してください。
1.1.2. バグ修正
-
以前は、RHEL 9.2 リアルタイムカーネルを使用すると、一部の Webhook が機能しませんでした。現在は、この RHEL 9.2 リアルタイムカーネルが使用されているかどうかを確認するための修正が導入されています。このカーネルが使用されている場合、
s390xアーキテクチャーの使用時にパケットドロップやラウンドトリップ時間などの機能が実行されないという内容の警告が表示されます。この修正は OpenShift 4.16 以降で適用されます。(NETOBSERV-1808) - 以前は、Overview タブの Manage panels ダイアログで、total、bar、donut、または donut でフィルタリングしても、結果が表示されませんでした。現在は、利用可能なパネルが正しくフィルタリングされます。(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)
1.1.3. 既知の問題
- 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
