第34章 ネットワーク可観測性

34.1. Network Observability Operator リリースノート

Network Observability Operator を使用すると、管理者は OpenShift Container Platform クラスターのネットワークトラフィックフローを観察および分析できます。

これらのリリースノートは、OpenShift Container Platform での Network Observability Operator の開発を追跡します。

Network Observability Operator の概要は、Network Observability Operator について を参照してください。

34.1.1. Network Observability Operator 1.2.0

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

34.1.1.1. 次の更新の準備

インストールされた Operator のサブスクリプションは、Operator の更新を追跡および受信する更新チャネルを指定します。Network Observability Operator の 1.2 リリースまでは、利用可能なチャネルは v1.0.x だけでした。Network Observability Operator の 1.2 リリースでは、更新の追跡および受信用に stable 更新チャネルが導入されました。今後の Operator 更新を受信するには、チャネルを v1.0.x から stable に切り替える必要があります。v1.0.x チャネルは非推奨となり、次のリリースで削除される予定です。

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

34.1.1.2.1. Traffic Flow ビューのヒストグラム
  • 経時的なフローのヒストグラムバーグラフを表示するように選択できるようになりました。ヒストグラムを使用すると、Loki クエリー制限に達することなくフロー履歴を可視化できます。詳細は、ヒストグラムの使用 を参照してください。
34.1.1.2.2. 会話の追跡
  • ログタイプ でフローをクエリーできるようになりました。これにより、同じ会話に含まれるネットワークフローをグループ化できるようになりました。詳細は、会話での作業 を参照してください。
34.1.1.2.3. ネットワーク可観測性のヘルスアラート
  • Network Observability Operator は、書き込み段階でのエラーが原因で flowlogs-pipeline がフローをドロップする場合、または Loki 取り込みレート制限に達した場合、自動アラートを作成するようになりました。詳細は、ヘルス情報の表示 を参照してください。

34.1.1.3. バグ修正

  • これまでは、FlowCollector 仕様の namespace の値を変更すると、以前の namespace で実行されている eBPF エージェント Pod が適切に削除されませんでした。今は、以前の namespace で実行されている Pod も適切に削除されるようになりました。(NETOBSERV-774)
  • これまでは、FlowCollector 仕様 (Loki セクションなど) の caCert.name 値を変更しても、FlowLogs-Pipeline Pod および Console プラグイン Pod が再起動されないため、設定の変更が認識されませんでした。今は、Pod が再起動されるため、設定の変更が適用されるようになりました。(NETOBSERV-772)
  • これまでは、異なるノードで実行されている Pod 間のネットワークフローは、異なるネットワークインターフェイスでキャプチャーされるため、重複が正しく認識されないことがありました。これにより、コンソールプラグインに過度のメトリックが表示されました。現在、フローは重複として正しく識別され、コンソールプラグインは正確なメトリックを表示します。(NETOBSERV-755)
  • コンソールプラグインのレポーターオプションは、送信元ノードまたは宛先ノードのいずれかの観測点に基づいてフローをフィルタリングするために使用されます。以前は、このオプションはノードの観測点に関係なくフローを混合していました。これは、ネットワークフローがノードレベルで Ingress または Egress として誤って報告されることが原因でした。これで、ネットワークフロー方向のレポートが正しくなりました。レポーターオプションは、期待どおり、ソース観測点または宛先観測点をフィルターします。(NETOBSERV-696)
  • 以前は、フローを gRPC+protobuf リクエストとしてプロセッサーに直接送信するように設定されたエージェントの場合、送信されたペイロードが大きすぎる可能性があり、プロセッサーの GRPC サーバーによって拒否されました。これは、非常に高負荷のシナリオで、エージェントの一部の設定でのみ発生しました。エージェントは、次のようなエラーメッセージをログに記録しました: grpc: max より大きいメッセージを受信しました。その結果、それらのフローに関する情報が損失しました。現在、gRPC ペイロードは、サイズがしきい値を超えると、いくつかのメッセージに分割されます。その結果、サーバーは接続を維持します。(NETOBSERV-617)

34.1.1.4. 既知の問題

  • Loki Operator 5.6 を使用する Network Observability Operator の 1.2.0 リリースでは、Loki 証明書の移行が定期的に flowlogs-pipeline Pod に影響を及ぼし、その結果、Loki に書き込まれるフローではなくフローがドロップされます。この問題はしばらくすると自動的に修正されますが、依然として Loki 証明書の移行中に一時的なフローデータの損失が発生します。(NETOBSERV-980)

34.1.1.5. 主な技術上の変更点

  • 以前は、カスタム名前空間を使用して Network Observability Operator をインストールできました。このリリースでは、ClusterServiceVersion を変更する conversion webhook が導入されています。この変更により、使用可能なすべての名前空間がリストされなくなりました。さらに、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、およびその他のプラグインでも引き続き使用できることに注意することが重要です。(NETOBSERV-907)(NETOBSERV-956)

34.1.2. Network Observability Operator 1.1.0

Network Observability Operator 1.1.0 については、次のアドバイザリーを利用できます。

Network Observability Operator は現在安定しており、リリースチャンネルは v1.1.0 にアップグレードされています。

34.1.2.1. バグ修正

  • 以前は、Loki の authToken 設定が FORWARD モードに設定されていない限り、認証が適用されず、OpenShift Container Platform クラスター内の OpenShift Container Platform コンソールに接続できるすべてのユーザーが認証なしでフローを取得できました。現在は、Loki の authToken モードに関係なく、クラスター管理者のみがフローを取得できます。(BZ#2169468)