サポートコンソール開発者トライアルの開始お問い合わせ

1.9. Network Observability Operator 1.3.0

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

1.9.1. チャネルの非推奨化

今後の Operator 更新を受信するには、チャネルを v1.0.x から stable に切り替える必要があります。v1.0.x チャネルは非推奨となり、次のリリースで削除される予定です。

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

1.9.2.1. Network Observability におけるマルチテナンシー

1.9.2.2. フローベースのメトリクスダッシュボード

  • このリリースでは、OpenShift Container Platform クラスター内のネットワークフローの概要を表示する新しいダッシュボードが追加されています。詳細は、Network Observability メトリクス を参照してください。

1.9.2.3. must-gather ツールを使用したトラブルシューティング

  • Network Observability Operator に関する情報を、トラブルシューティングで使用する must-gather データに追加できるようになりました。詳細は、Network Observability の must-gather を参照してください。

1.9.2.4. 複数のアーキテクチャーに対するサポートを開始

  • Network Observability Operator は、amd64、ppc64le、または arm64 アーキテクチャー上で実行できるようになりました。以前は、amd64 上でのみ動作しました。

1.9.3. 非推奨の機能

1.9.3.1. 非推奨の設定パラメーターの設定

Network Observability Operator 1.3 のリリースでは、spec.Loki.authToken HOST 設定が非推奨になりました。Loki Operator を使用する場合、FORWARD 設定のみを使用する必要があります。

1.9.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)
  • 以前は、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 を使用する場合、ユーザーは eBPF agent Pod がデプロイされている特権付き namespace に証明書を手動でコピーし、証明書のローテーションを行う場合などに手動で証明書の更新を管理する必要がありました。現在は、FlowCollector リソースに証明書の namespace フィールドを追加することで、Network Observability のセットアップが簡素化されています。その結果、ユーザーは Network Observability namespace に証明書を手動でコピーすることなく、Loki または Kafka を別の namespace にインストールできるようになりました。元の証明書は監視されているため、必要に応じてコピーが自動的に更新されます。(NETOBSERV-773)
  • 以前は、SCTP、ICMPv4、および ICMPv6 プロトコルは Network Observability エージェントのカバレッジに含まれていなかったため、ネットワークフローのカバレッジもあまり包括的ではありませんでした。これらのプロトコルを使用することで、フローカバレッジが向上することが確認されています。(NETOBSERV-934)

1.9.5. 既知の問題

  • FlowCollector で processor.metrics.tls が PROVIDED に設定されている場合、flowlogs-pipeline servicemonitor は TLS スキームに適用されません。(NETOBSERV-1087)
  • Network Observability Operator 1.2.0 リリース以降では、Loki Operator 5.6 を使用すると、Loki 証明書の変更が定期的に flowlogs-pipeline Pod に影響を及ぼすため、フローが Loki に書き込まれず、ドロップされます。この問題はしばらくすると自動的に修正されますが、Loki 証明書の移行中に一時的なフローデータの損失が発生します。この問題は、120 以上のノードを内包する大規模環境でのみ発生します。(NETOBSERV-980)
  • Operator のインストール時に、警告のカーネル taint が表示される場合があります。このエラーの理由は、Network Observability eBPF エージェントに、HashMap テーブル全体を事前割り当てするメモリー制約があることです。Operator eBPF エージェントは BPF_F_NO_PREALLOC フラグを設定し、HashMap がメモリーを大幅に使用している際に事前割り当てが無効化されるようにします。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.