第28章 ネットワーク可観測性
28.1. Network Observability Operator リリースノート
Network Observability Operator を使用すると、管理者は OpenShift Container Platform クラスターのネットワークトラフィックフローを観察および分析できます。
これらのリリースノートは、OpenShift Container Platform での Network Observability Operator の開発を追跡します。
Network Observability Operator の概要は、Network Observability Operator について を参照してください。
28.1.1. Network Observability Operator 1.3.0
Network Observability Operator 1.3.0 では、次のアドバイザリーを利用できます。
28.1.1.1. チャネルの非推奨化
今後の Operator 更新を受信するには、チャネルを v1.0.x から stable に切り替える必要があります。v1.0.x チャネルは非推奨となり、次のリリースで削除される予定です。
28.1.1.2. 新機能および機能拡張
28.1.1.2.1. ネットワーク可観測性におけるマルチテナンシー
- システム管理者は、Loki に保存されているフローへの個々のユーザーアクセスまたはグループアクセスを許可および制限できます。詳細は、ネットワーク可観測性におけるマルチテナンシー を参照してください。
28.1.1.2.2. フローベースのメトリクスダッシュボード
- このリリースでは、OpenShift Container Platform クラスター内のネットワークフローの概要を表示する新しいダッシュボードが追加されています。詳細は、ネットワーク可観測性メトリクス を参照してください。
28.1.1.2.3. must-gather ツールを使用したトラブルシューティング
- Network Observability Operator に関する情報を、トラブルシューティングで使用する must-gather データに追加できるようになりました。詳細は、ネットワーク可観測性の must-gather を参照してください。
28.1.1.2.4. 複数のアーキテクチャーに対するサポートを開始
- Network Observability Operator は、amd64、ppc64le、または arm64 アーキテクチャー上で実行できるようになりました。以前は、amd64 上でのみ実行されていました。
28.1.1.3. 非推奨の機能
28.1.1.3.1. 非推奨の設定パラメーターの設定
Network Observability Operator 1.3 のリリースでは、spec.Loki.authToken HOST 設定が非推奨になりました。Loki Operator を使用する場合、FORWARD 設定のみを使用する必要があります。
28.1.1.4. バグ修正
-
以前は、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) -
以前は、ネットワーク可観測性の
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 フィールドを指定できず、ネットワーク可観測性がデプロイされているのと同じ namespace に証明書が存在する必要がありました。さらに、TLS/mTLS で Kafka を使用する場合、ユーザーは eBPF エージェント Pod がデプロイされている特権 namespace に証明書を手動でコピーし、証明書のローテーションを行う場合などに手動で証明書の更新を管理する必要がありました。現在は、
FlowCollectorリソースに証明書の namespace フィールドを追加することで、ネットワーク可観測性のセットアップが簡素化されています。その結果、ユーザーはネットワーク可観測性 namespace に証明書を手動でコピーすることなく、Loki または Kafka を別の namespace にインストールできるようになりました。元の証明書は監視されているため、必要に応じてコピーが自動的に更新されます。(NETOBSERV-773) - 以前は、SCTP、ICMPv4、および ICMPv6 プロトコルはネットワーク可観測性エージェントのカバレッジに含まれていなかったため、ネットワークフローのカバレッジもあまり包括的ではありませんでした。これらのプロトコルを使用することで、フローカバレッジが向上することが確認されています。(NETOBSERV-934)
28.1.1.5. 既知の問題
-
FlowCollectorでprocessor.metrics.tlsがPROVIDEDに設定されている場合、flowlogs-pipelineservicemonitorは TLS スキームに適用されません。(NETOBSERV-1087)
28.1.2. Network Observability Operator 1.2.0
Network Observability Operator 1.2.0 では、次のアドバイザリーを利用できます。
28.1.2.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 チャネルは非推奨となり、次のリリースで削除される予定です。
28.1.2.2. 新機能および機能拡張
28.1.2.2.1. Traffic Flow ビューのヒストグラム
- 経時的なフローのヒストグラムバーグラフを表示するように選択できるようになりました。ヒストグラムを使用すると、Loki クエリー制限に達することなくフロー履歴を可視化できます。詳細は、ヒストグラムの使用 を参照してください。
28.1.2.2.2. 会話の追跡
- ログタイプ でフローをクエリーできるようになりました。これにより、同じ会話に含まれるネットワークフローをグループ化できるようになりました。詳細は、会話の使用 を参照してください。
28.1.2.2.3. ネットワーク可観測性のヘルスアラート
-
Network Observability Operator は、書き込み段階でのエラーが原因で
flowlogs-pipelineがフローをドロップする場合、または Loki 取り込みレート制限に達した場合、自動アラートを作成するようになりました。詳細は、ヘルス情報の表示 を参照してください。
28.1.2.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)
28.1.2.4. 既知の問題
-
Loki Operator 5.6 を使用する Network Observability Operator の 1.2.0 リリースでは、Loki 証明書の移行が定期的に
flowlogs-pipelinePod に影響を及ぼし、その結果、Loki に書き込まれるフローではなくフローがドロップされます。この問題はしばらくすると自動的に修正されますが、依然として Loki 証明書の移行中に一時的なフローデータの損失が発生します。(NETOBSERV-980)
28.1.2.5. 主な技術上の変更点
-
以前は、カスタム namespace を使用して Network Observability Operator をインストールできました。このリリースでは、
ClusterServiceVersionを変更するconversion webhookが導入されています。この変更により、使用可能なすべての namespace がリストされなくなりました。さらに、Operator メトリクス収集を有効にするには、openshift-operatorsnamespace など、他の Operator と共有される namespace は使用できません。ここで、Operator をopenshift-netobserv-operatornamespace にインストールする必要があります。以前にカスタム namespace を使用して Network Observability Operator をインストールした場合、新しい Operator バージョンに自動的にアップグレードすることはできません。以前にカスタム namespace を使用して Operator をインストールした場合は、インストールされた Operator のインスタンスを削除し、openshift-netobserv-operatornamespace に Operator を再インストールする必要があります。一般的に使用されるnetobservnamespace などのカスタム namespace は、FlowCollector、Loki、Kafka、およびその他のプラグインでも引き続き使用できることに注意することが重要です。(NETOBSERV-907)(NETOBSERV-956)
28.1.3. Network Observability Operator 1.1.0
Network Observability Operator 1.1.0 については、次のアドバイザリーを利用できます。
Network Observability Operator は現在安定しており、リリースチャンネルは v1.1.0 にアップグレードされています。
28.1.3.1. バグ修正
-
以前は、Loki の
authToken設定がFORWARDモードに設定されていない限り、認証が適用されず、OpenShift Container Platform クラスター内の OpenShift Container Platform コンソールに接続できるすべてのユーザーが認証なしでフローを取得できました。現在は、Loki のauthTokenモードに関係なく、クラスター管理者のみがフローを取得できます。(BZ#2169468)
