1.8. Network Observability Operator 1.3.0
Network Observability Operator 1.3.0 では、次のアドバイザリーを利用できます。
1.8.1. チャネルの非推奨化
今後の Operator 更新を受信するには、チャネルを v1.0.x
から stable
に切り替える必要があります。v1.0.x
チャネルは非推奨となり、次のリリースで削除される予定です。
1.8.2. 新機能および機能拡張
1.8.2.1. Network Observability におけるマルチテナンシー
- システム管理者は、Loki に保存されているフローへの個々のユーザーアクセスまたはグループアクセスを許可および制限できます。詳細は、Network Observability におけるマルチテナンシー を参照してください。
1.8.2.2. フローベースのメトリクスダッシュボード
- このリリースでは、OpenShift Container Platform クラスター内のネットワークフローの概要を表示する新しいダッシュボードが追加されています。詳細は、Network Observability メトリクス を参照してください。
1.8.2.3. must-gather ツールを使用したトラブルシューティング
- Network Observability Operator に関する情報を、トラブルシューティングで使用する must-gather データに追加できるようになりました。詳細は、Network Observability の must-gather を参照してください。
1.8.2.4. 複数のアーキテクチャーに対するサポートを開始
-
Network Observability Operator は、
amd64
、ppc64le
、またはarm64
アーキテクチャー上で実行できるようになりました。以前は、amd64
上でのみ動作しました。
1.8.3. 非推奨の機能
1.8.3.1. 非推奨の設定パラメーターの設定
Network Observability Operator 1.3 のリリースでは、spec.Loki.authToken
HOST
設定が非推奨になりました。Loki Operator を使用する場合、FORWARD
設定のみを使用する必要があります。
1.8.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.8.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 がメモリーを大幅に使用している際に事前割り当てが無効化されるようにします。