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

1.8.17. ネットワーキング

  • このアップデート以前は、IBM Cloud および IBM Power Virtual Server の Ingress 用の CredentialsRequest マニフェストに include.release.openshift.io アノテーションが欠落していました。その結果、oc adm release extract --credentials-requests --included コマンドはこれらのマニフェストを除外し、手動で管理された認証情報を使用したインストールは、Ingress Operator が \*.apps DNS レコードを作成できなかったため失敗し、DNSReady=False ステータスになりました。今回のリリースでは、不足していたアノテーションが CredentialsRequest マニフェストに追加されました。その結果、手動で管理した認証情報を使用したインストールは成功します。OCPBUGS-105469
  • 今回のアップデート以前は、イングレスコントローラーの ワイルドカード ポリシーにより、管理者がルーターを再起動するまで、新しいルートで以前のホスト名を再利用することが妨げられていました。その結果、影響を受けたルートは HostAlreadyClaimed エラーを報告しました。今回のリリースでは、ワイルドカード ポリシーが有効な場合、イングレスコントローラーで新しいルートが以前のホスト名をすぐに再利用できるようになりました。その結果、管理者はルーターを再起動することなく、ホスト名をシームレスに更新できます。OCPBUGS-105469
  • このアップデート以前は、Web コンソール 検索 ページで Ingress リソースを検索した後、Ingress の作成を クリックすると、Ingress 作成フォームではなく 404: ページが見つかりません エラーにリダイレクトされていました。その結果、ユーザーは 検索 ページから直接 Ingress リソースを作成できず、コンソールの別の部分から作成フォームにアクセスする必要がありました。今回のリリースにより、検索 ページの Ingress を作成 ボタンが正しい URL にリンクされるようになりました。その結果、検索 ページから Ingress を作成を クリックすると、想定どおり Ingress 作成フォームが開きます。OCPBUGS-105469
  • このアップデート以前は、Ingress Controller が NLB を使用している場合、HAProxy トンネルのタイムアウトは AWS Network Load Balancer (NLB) のアイドルタイムアウトである 350 秒よりも長くなっていました。その結果、NLB は通知なしにアイドル状態の接続を削除し、クライアントの TCP リセットを引き起こした。今回のリリースでは、Ingress Operator がトンネルのタイムアウト時間を短縮し、HAProxy が NLB によって切断される前にアイドル状態の接続を閉じることができるようになりました。その結果、クライアントは TCP リセットではなく、正常な接続切断を受け取ります。OCPBUGS-105469
  • このアップデート以前は、HAProxy はすべてのクライアント送信元アドレスを IPv4 とみなしており、Forwarded ヘッダー内で IPv6 アドレスを括弧で囲んでいませんでした。その結果、IPv6 クライアントからのリクエストによって、アプリケーションがクライアントアドレスを解析できない原因となる、規格に準拠していないヘッダーが生成される可能性がありました。今回のリリースでは、HAProxy は各送信元アドレスの IP ファミリーをチェックし、IPv6 アドレスを括弧で囲むように変更しました。その結果、イングレスコントローラーは、IPv4 および IPv6 クライアントアドレスの両方に対して、正しくフォーマットされた 転送 ヘッダーを生成します。OCPBUGS-105469
  • 今回のアップデート以前は、AWS ネットワークロードバランサー (NLB) では、ネイティブクライアント IP アドレスの保持がデフォルトで有効になっていました。その結果、内部 NLB ルートに接続した Pod が、同じノード上のルーター Pod にトラフィックを返す場合に、ヘアピン接続障害が発生し、接続タイムアウトを引き起こしました。今回のリリースでは、IngressController API にプロトコルフィールドが追加され、新しい NLB Ingress Controller はデフォルトで PROXY プロトコルバージョン 2 を使用するようになり、ネイティブクライアント IP の保持が無効になります。その結果、ヘアピン接続が失敗することはなくなり、アップグレード時にプロトコルフィールドを設定するよう管理者に通知する情報アラートが表示されるようになりました。OCPBUGS-105469
  • このアップデート以前は、基盤となるインターフェイスの LLDP 設定が br-ex ブリッジ上で保持されていませんでした。その結果、br-ex で LLDP を 有効にするには、サポートされていない回避策が必要となり、ネットワーク設定が破損したり、再起動時にノードの接続が失われたりする可能性がありました。今回のリリースでは、基盤となるインターフェイスからの LLDP 設定が br-ex 上に保持されます。その結果、LLDP は ネットワークを中断することなく有効化できます。OCPBUGS-105469
  • このアップデート以前は、OpenShift Router は起動時に、ルートごとに外部管理されている証明書を検証するために、同期的に順次 SubjectAccessReview (SAR) API 呼び出しを実行していました。その結果、外部証明書ルートが多いクラスターでは、kubelet は起動プローブのタイムアウト値である 120 秒を超えたルーター Pod をすべて強制終了しました。今回のリリースでは、SAR キャッシュメカニズムである sarCache とセマフォによって、ルーターにおける同時 SAR API 呼び出しが制限されます。このプロセスは、ライターリースの同時実行性を持つルートステータスの増加と並行して発生します。その結果、OpenShift Router の初期化時間が大幅に短縮されます。この変更により、起動プローブウィンドウ内で外部証明書を持つ数千ものルートをロードできるようになり、ルーター Pod が CrashLoopBackOff ループに陥るのを防ぎます。OCPBUGS-105469
  • 今回のアップデート以前は、NMState コンソールプラグインは、NodeNetworkConfigurationPolicy (NNCP) リソースを作成する際に、空のノード選択を正しく処理していませんでした。その結果、Web コンソールでノードを選択せずに NNCP を作成すると、ポリシーの作成を妨げるエラーが発生しました。今回のリリースにより、コンソールプラグインは空のノード選択を正しく処理するようになりました。その結果、エラーなく Web コンソールから NNCP リソースを作成できます。OCPBUGS-105469
  • このアップデート以前は、クラスター DNS Operator は、ノードのいずれかの taint が許容されている場合、そのノード をスケジューリング可能 と判断していました。その結果、多くの taint を持つノードが、誤って スケジューリング 可能とマークされる可能性があります。今回のリリースでは、クラスター DNSOperator は、ノードを スケジュール可能と マークする前に、すべての taint が許容範囲内であることを確認します。その結果、多くの taint を持つノードは、すべての taint が許容される場合にのみ、正しく スケジューリング可能 とマークされます。OCPBUGS-105469
  • 今回のアップデート以前は、カスタムリソースである NodeNetworkConfigurationPolicy (NNCP) の nodeSelector フィールドの説明において、単純なキーと値の一致のみがサポートされていることが明確に示されていませんでした。その結果、ユーザーは matchLabels と matchExpressions の 構造が nodeSelector フィールドで機能することを期待していました。しかし、彼らがその概念を用いようとした際に、その政策は却下された。今回のリリースでは、nodeSelector フィールドの説明において、キーと値の直接的なペアマッチングのみがサポートされていることが明確化されました。その結果、oc explain nncp.spec.nodeSelector は サポートされている構文を正確に説明します。OCPBUGS-105469
  • 今回のアップデート以前は、OVN-Kubernetes はライブマイグレーションのステータスチェック中に virt-launcher Pod を識別するために vm.kubevirt.io/name ラベルを使用していました。その結果、同じ名前空間内の多数の仮想マシンが同じ spec.template.spec.hostname 値を持つ場合、それらの仮想マシンは virt-launcher Pod 上で同じラベル値を共有することになります。これにより、3 番目以降の仮想マシンは、OVN-Kubernetes が他の仮想マシンから Pod を誤って識別したため 、ライブマイグレーションステータスの検出に失敗しました: Pod で予期しないライブマイグレーション状態 というエラーで起動に失敗しました。今回のリリースにより、OVN-Kubernetes は、多数の仮想マシンが同じホスト名を共有している場合でも 、virt-launcher Pod を正しく識別できるようになりました。その結果、同じ名前空間内の他の仮想マシンが同じホスト名値を使用しているかどうかに関わらず、仮想マシンは正常に起動します。OCPBUGS-105469
  • 今回のアップデート以前は、Web コンソールの ユーザー定義ネットワークの作成 フォームでは、送信前にサブネット CIDR 値から空白文字が削除されていませんでした。その結果、空白文字を含む CIDR 値をコピーすると、検証エラーが発生した。今回のリリースでは、フォームが検証前に CIDR 入力から空白文字を削除するようになりました。その結果、ユーザーは空白を含む CIDR 値をエラーなくコピーできるようになった。OCPBUGS-105469
  • このアップデート以前は、localnet OVN-Kubernetes セカンダリーネットワーク上の仮想マシン Pod が削除された場合、OVN-Kubernetes がノースバウンドデータベースから論理スイッチポートを削除しない可能性がありました。その結果、交換された Pod ポートの横に、同じ MAC アドレスを持つ孤立した論理スイッチポートが残ってしまい、ネットワーク接続の問題を引き起こした。今回のリリースにより、OVN-Kubernetes は削除された Pod の論理スイッチポートを正しく削除するようになりました。その結果、仮想マシン Pod は、接続の問題なくローカルネットのセカンダリーネットワーク上に再作成できます。OCPBUGS-105469
  • このアップデート以前は、Pod の入れ替わりが激しい環境では、FRR-K8s デーモンを使用している際に、学習済みの BGP(Border Gateway Protocol) ルートがクラスターからアンインストールされる可能性がありました。その結果、これらのルートに依存するトラフィックが失敗し、RouteAdvertisements 機能または MetalLB Operator によって管理される BGP 設定に影響が出ました。今回のリリースにより、FRR はバージョン 8 からバージョン 10 にアップグレードされました。その結果、学習された BGP ルートはルーティングテーブルに正しく保存されたままになります。OCPBUGS-105469
  • このアップデート以前は、openshift-Ingress 名前空間の istio-proxy および discovery コンテナーは、terminationMessagePolicy を FallbackToLogsOnError に設定していませんでした。その結果、コンテナーがエラーで終了した場合、利用できる診断情報が少なくなった。このリリースでは、両方のコンテナーで terminationMessagePolicy=FallbackToLogsOnError が設定されます。その結果、これらのコンテナーがエラーで終了した際には、コンテナーログが終了メッセージとして使用され、ゲートウェイ API の障害診断が改善されます。OCPBUGS-105469
  • このアップデート以前は、openshift-ovn-kubernetes 名前空間のコンテナーは terminationMessagePolicy をFallbackToLogsOnError に設定していませんでした。その結果、コンテナーがエラーで終了した場合、利用できる診断情報が少なくなった。このリリースでは、影響を受けるコンテナーで terminationMessagePolicy=FallbackToLogsOnError が設定されます。その結果、これらのコンテナーがエラーで終了した際には、コンテナーログが終了メッセージとして使用され、OVN-Kubernetes の障害診断が改善されます。OCPBUGS-105469
  • 今回のアップデート以前は、グランドマスタークロック (T-GM) ptp プロセスの起動順序に競合状態が存在していました。その結果、起動時にシステム時刻が PTP グランドマスタークロックによって通知された時刻から 37 秒ずれることが時折発生した。これは、オペレーティングシステムが GNSS の時刻と同期するのに数時間かかる可能性があることを意味していました。今回のリリースでは、競合状態を解消するために、プロセスの起動ロジックの順序が変更されました。その結果、システム時刻は最初の 37 秒のオフセットなしに、PTP グランドマスタークロックと直接同期します。OCPBUGS-105469
  • 今回のアップデート以前は、DNSOperator は、希望する Pod 数と最新の Pod 数の差を、進行中のロールアウトの証拠として扱っていました。その結果、クラスターのスケールアップによって、DNS 設定の変更が行われていないにもかかわらず、Operator が Progressing=True と報告する事態が発生した。今回のリリースでは、DNSOperator は、観測された世代とスケジュールされた Pod 数をチェックすることで、デーモンセットが アクティブに展開されていることを検証します。その結果、クラスターのスケールアップによって 、Progressing=True という 誤ったレポートが発生することはなくなりました。OCPBUGS-105469
  • 今回のアップデート以前は、Web コンソールで特定のシステムサービスの Pod セレクターを編集しようとすると、ページが空白になってしまうという問題が発生していました。その結果、これらのサービスの Pod セレクターを変更できず、ブラウザーを更新する必要がありました。今回のリリースにより、Web コンソールはシステムサービスに対する Pod セレクターの編集アクションを適切に処理するようになりました。その結果、空白ページが表示されることなく Pod セレクターを編集できます。OCPBUGS-105469
  • このアップデート以前は、Precision Time Protocol (PTP)Operator は、デジタル位相同期ループ (DPLL) ピンの管理状態フィールドを利用して、ピンレポートを検証し、クロック同期状態を判断していました。その結果、DPLL API が管理状態 (選択可能 など) と運用状態 (接続済み など) を分離する RHEL 9.6 以降のカーネルで実行した場合、Telecom Grandmaster (T-GM) および Telecom Boundary Clock (T-BC) 設定はロックを達成できず、ロック解除 状態を報告しました。今回のリリースにより、PTP Operator は RHEL 9.6 で導入された新しい DPLL ピン動作状態フィールドをサポートします。その結果、T-GM および T-BC 設定は、RHEL 9.6 以降のカーネル上で実行された場合、正しくロックを達成し、適切な同期状態を報告します。OCPBUGS-105469
  • 今回のアップデート以前は、クラスターイングレス Operator がゲートウェイ API を OLM 管理から Sail ライブラリーパスに移行した際、Operator は通知なしに OLM サブスクリプションの管理を停止していました。その結果、管理者は購読契約が解約されたことを知る術がなかった。今回のリリースでは、孤立したサブスクリプションを検出し、修復ガイダンスを提供するため、OrphanedOSSMSubscription Prometheus アラート、メトリクス、および ClusterOperator ステータス条件が追加されました。その結果、管理者は購読が孤立した際に通知を受け取り、次のステップに関する明確なガイダンスを得ることができます。OCPBUGS-105469
  • 今回のアップデート以前は、Ingress Node Firewall Operator は Kubernetes のラベルセレクターのセマンティクスではなく、厳密なラベルマッチングを使用していました。その結果、起動後に追加されたノードについては、IngressNodeFirewallNodeState オブジェクトが作成されませんでした。今回のリリースでは、Operator は適切な Kubernetes ラベルセレクターマッチングを使用するようになりました。その結果、Operator は、動的に追加されたノード、またはラベルが変更されたノードに対して、IngressNodeFirewallNodeState オブジェクトを作成します。OCPBUGS-105469
  • 今回のアップデート以前は、HAProxy 2.8 において、空のバックエンドを動的に構築する際に問題が発生することが判明していました。その結果、Dynamic Config Manager は新しいバックエンドサーバーの登録に失敗し、設定エラーが発生しました。今回のリリースでは、HAProxy が更新され、空のバックエンドにサーバーを動的に追加する際に、バックエンドサーバー ID を追加するパッチが適用されました。その結果、ルートが動的に生成される際に、Dynamic Config Manager は新しいバックエンドサーバーを正しく登録します。OCPBUGS-105469
  • このアップデート以前は、デュアルスタッククラスターにおいて、IPv6 Egress IP アドレスは利用可能なノードに割り当てられていませんでした。その結果、IPv6 の EgressIP アドレスに依存するトラフィックは、期待される送信元アドレスで送信されませんでした。今回のリリースにより、OVN-Kubernetes は利用可能なノードに IPv6 の送信 IP アドレスを正しく割り当てるようになりました。その結果、IPv4 と IPv6 の両方の EgressIP アドレスが想定どおりに割り当てられます。OCPBUGS-105469
  • このアップデート以前は、Telecom Boundary Clock (T-BC) 設定の場合、masterOffsetSource のデュアルパブリッシャーオーバーライドと競合状態により、クラウドイベントプロキシーが CLOCK_REALTIME 同期状態を誤って導出していました。その結果、CLOCK_REALTIME 同期状態メトリクスとクラウドイベントは LOCKED と FREERUN の間で振動したり、誤った状態のままになったりしました。このリリースでは、phc2sys が 唯一の発行者として機能し、状態は O-RAN O-Cloud Notification API v04.00 表 37 に従って worst_of (phc2sys_state、upstream PTP ロック状態) を使用して導出されます。その結果、CLOCK_REALTIME は、不要な発振を起こすことなく、phc2sys の オフセットと上流の PTP ロック状態の両方を正確に反映します。OCPBUGS-105469
  • このアップデート以前は、gatewayclass コントローラーは、OperatorLifecycleManager 機能が有効になっているかどうかを確認せずに、Subscription および InstallPlan OLM リソースの監視を設定していました。その結果、OLM のないクラスターでは、起動中にコントローラーが永久にブロックされ、ゲートウェイ API が機能しなくなりました。今回のリリースでは、OLM リソースの監視機能が OperatorLifecycleManagerEnabled チェックによって保護されるようになりました。その結果、ゲートウェイクラス コントローラーは OLM のないクラスターでも正常に起動します。OCPBUGS-105469
  • 今回のアップデート以前は、MetalLBOperator の RBAC ルールによって不要な権限が付与されていました。その結果、サービスアカウントは必要以上に広範な特権を保持しており、セキュリティーリスクが増大していました。今回のリリースでは、不要な RBAC 権限が削除されました。その結果、ClusterRole に は操作に必要な権限のみが反映されます。OCPBUGS-105469
  • このアップデート以前は、ovn-ipsec コンテナーの起動スクリプトは s390x システム上でホストのマウントポイントから platform-python を実行しようとしていましたが、実行ファイルがホスト上に存在しませんでした。その結果、IPsec Pod の起動に失敗し、s390x 上での IPsec 対応クラスターのインストールが完了しませんでした。今回のリリースでは、Cluster Network Operator はホストから /usr/libexec をマウントしなくなり、コンテナーがバンドルされている実行ファイルを使用できるようになりました。その結果、s390x システム上で IPsec 対応クラスターのインストールが正常に完了します。OCPBUGS-105469
  • 今回のアップデート以前は、Kubernetes NMState Operator はステータスフィールドの所有権を取得せずにステータス更新を適用していました。その結果、アップグレード後にフィールド所有権の競合が発生し、ステータス更新が拒否されたため、NMState CR のステータスは永久に凍結されたままとなった。今回のリリースでは、Kubernetes NMState Operator がアップデート適用時にステータスフィールドの所有権を取得します。その結果、Operator のアップグレード後、NMState CR ステータスが正しく更新されます。OCPBUGS-105469
  • このアップデート以前は、NTP フェイルオーバーシナリオにおける重複 PTP イベントの修正後、openshift_ptp_clock_state メトリクスは phc2sys サービス と chronyd サービスの両方に対して同時に CLOCK_REALTIME 値を報告していました。その結果、報告されたクロック状態は、実際にアクティブなプロセスと一致しなくなった。実行されていないプロセスでも CLOCK_REALTIME が ロックされていると表示される場合があり、ノードがどの時刻ソースに同期しているかが不明確になります。今回のリリースでは、クロック同期が phc2sys サービス と chronyd サービスの間で切り替わる際に、非アクティブなプロセスの古い CLOCK_REALTIME メトリクスが削除されます。その結果、一度に存在できる CLOCK_REALTIME openshift_ptp_clock_state メトリクスは 1 つだけとなり、メトリクスは現在アクティブなプロセスに対応します。OCPBUGS-105469
  • 今回のアップデート以前は、クラスターイングレス Operator は OpenShift Service Mesh (OSSM)3.3 をベースとした sail-operator ライブラリーを使用しており、ゲートウェイ API 統合のために Istio バージョン 1.28.5 がデプロイされていました。その結果、Istio 統合の Gateway API を使用するクラスターは、上流の Istio 1.28 リリースストリームから既知の修正済み CVE を含む古い Istio バージョンを実行していました。今回のリリースでは、ベンダー提供の sail-operator ライブラリーが OSSM 3.4.0 にアップグレードされ、Istio 1.28.8 がデプロイされます。その結果、Istio 統合を使用した Gateway API のデプロイメントには、OSSM 3.4.0 リリース以降に蓄積された CVE 修正、バグ修正、および API の改善が含まれます。OCPBUGS-105469
  • このアップデート以前は、nmstate-configuration.sh スクリプトは、適用された NMState 設定のチェックサムと現在の設定のチェックサムを比較して再設定をスキップするかどうかを決定する際に、無効なシェルテスト式を使用していました。その結果、この比較は常にサイレントに失敗し、設定が変更されていない場合でも、スクリプトは実行されるたびに br-ex と br0 の Open vSwitch ブリッジを削除してしまいました。configure-ovs.sh と nmstatectl の 両方が、設定がすでに適用されていると判断してブリッジの再作成をスキップしたため、削除された br-ex ブリッジは再作成されませんでした。これにより、カスタマイズされた br-ex ブリッジなど、クラスターインストールから NMState 設定を使用するノードを再起動すると、ネットワーク全体が停止するという問題が発生しました。今回のリリースでは、nmstate-configuration.sh は 設定比較に有効なシェル構文を使用するようになりました。その結果、NMState 設定が変更されていない場合、スクリプトは OVS ブリッジの削除と再適用を正しくスキップし、クラスターインストール時に NMState 設定が設定されたノードは再起動後もネットワーク接続を維持します。OCPBUGS-105469
  • このアップデート以前は、FRRouting (FRR) 双方向フォワーディング検出 (BFD) デーモンである bfdd は、各仮想ルーティングおよび転送 (VRF) プラグインごとに多数の User Datagram Protocol (UDP) ソケットを開いていました。この状況は、BFD が明示的に有効になっておらず、デフォルトのファイルディスクリプタ制限である MAX_FDS が 1024 に設定されている場合でも発生します。その結果、ClusterUserDefinedNetworks と RouteAdvertisements CR が多数存在するクラスターでは、FRR がファイルディスクリプタの制限を使い果たすため、frr-k8s Pod は CrashLoopBackOff 状態になります。今回のリリースでは、多数の VRF を持つ大規模な実稼働ネットワークに対応するため、FRR MAX_FDS の 値が 1024 から 65536 に変更されました。その結果、frr-k8s Pod は、多数の ClusterUserDefinedNetworks および RouteAdvertisements CR を持つクラスターでも、ファイルディスクリプタの枯渇に陥ることなく、正常に起動および実行できます。OCPBUGS-105469
  • このアップデート以前は、openshift-network-diagnostics 名前空間の network-check-source ServiceMonitor は、tlsConfig で insecureSkipVerify: true を 設定していました。その結果、Prometheus は network-check-sourcePod がメトリクスをスクレイピングする際に提示した TLS 証明書を検証せず、スクレイピング接続が中間者攻撃に対して脆弱な状態になった。今回のリリースでは、ネットワークチェックソースである ServiceMonitor がサービス CA 署名付き 証明書を使用するようになり、TLS 証明書の検証が無効にされなくなりました。その結果、Prometheus は network-check-source メトリクスをスクレイピングする際に証明書を検証します。OCPBUGS-105469
  • 今回のアップデート以前は、ts2phc プロセスは、上流の Precision Time Protocol (PTP) が通信境界クロック (T-BC) 上で安定する前に開始されていました。その結果、T-BC の収束が遅くなり、ハードウェアクロックが安定する前に、phc2sys が 不適切な時間オフセットに基づいてシステムクロックを早すぎるタイミングで調整してしまうという問題が発生した。今回のリリースでは、T-BC 上の ts2phc に、時間ソースが完全に認定され、phc2sys の 準備が整うまで遅延が追加されますが、T-GM の動作は変更されません。その結果、T-BC は検証されていないクロックソースに対して同期を試みることはできません。OCPBUGS-105469
  • このアップデート以前は、多数の clusterNetwork Classless Inter-Domain Routing (CIDR) で設定されたクラスターでは、OVN-Kubernetes が EgressIP 用に作成する優先度 102 のルーティングなしの論理ルーターポリシーは、同じクラスターネットワーク CIDR 上のノード間の Pod トラフィックのみに一致していました。その結果、割り当てられた EgressIP を持つ Pod が、異なるクラスターネットワーク CIDR 内のノード上の Pod に到達しようとした際、トラフィックはルーティング拒否ポリシーに一致せず、代わりに優先度の低い EgressIP ルーティング拒否ポリシーに一致してしまい、Pod 間のトラフィックが誤って出力ゲートウェイルーターを経由して送信され、接続が切断されてしまった。今回のリリースでは、ルーティング変更を行わない論理ルーターポリシーが、異なるクラスターネットワーク CIDR 間での Pod 間トラフィックにも対応するようになりました。その結果、EgressIP アドレスが割り当てられた Pod は、異なるクラスターネットワーク CIDR 内のノード上の Pod に到達できるようになります。OCPBUGS-105469
  • 今回のアップデート以前は、Network Time Protocol (NTP) フェイルオーバープラグインが有効になっている場合、ts2phc プロセスが標準出力パイプへの書き込み中にデッドロックを起こしていました。その結果、ts2phc は ログ出力を生成できず、グランドマスター (T-GM) クロックはロック状態に達することができなかった。今回のリリースにより、ts2phc の 標準出力におけるデッドロックが解消されました。その結果、NTP フェイルオーバーが有効になっている場合、ts2phc は 正しくログを記録し、グランドマスターの時計は期待どおりにロックされます。OCPBUGS-105469
  • このアップデート以前は、ptpSettings.logReduce の 設定が変更され、linuxptp デーモンが PTP プロファイルを再読み込みすると、クロックが一時的に HOLDOVER 状態に移行し、ホールドオーバー期間が経過しても LOCKED 状態に戻らないことがありました。これは、基となる PTP オフセットが正常な状態を維持していたにもかかわらず発生していました。その結果、影響を受けたクロックはプロファイルの再読み込み後、再ロックする代わりに、無期限に フリーラン 状態を報告し続けた。今回のリリースでは、ptpSettings.logReduce の変更によってトリガーされるプロファイルの再読み込み後、クロックが正しく再ロックされるようになりました。その結果、再読み込み後、クロックは予想通り ロック 状態に戻ります。OCPBUGS-105469
  • このアップデート以前は、OpenShift Container Platform 4.22 の IngressController API には haproxyVersion フィールドがありませんでした。その結果、顧客は 4.22 から 5.0 にアップグレードする前に HAProxy のバージョンを固定することができず、アップグレード後に予期しない HAProxy のバージョン変更が発生する可能性がありました。今回のリリースでは、OpenShift Container Platform 4.22.11 の IngressController API に haproxyVersion フィールドが追加されました。その結果、管理者は IngressController リソースで haproxyVersion: "2.8" を設定することで、OpenShift Container Platform5.0 へのアップグレード後も HAProxy がバージョン 2.8 に維持されるようにすることができます。OCPBUGS-105469
  • このアップデート以前は、phc2sysOpts: -a -r で設定された Boundary Clock (BC) および Telecom Boundary Clock (T-BC) ノードでは、cloud-event-proxy サイドカーは os-clock-sync-state (CLOCK_REALTIME) 同期状態を phc2sys CLOCK_REALTIME オフセットログ行からのみ判断していました。その結果、上流またはリモートのタイムソースが失われ、phc2sys が 再設定後にシンクとして CLOCK_REALTIME を 選択しなくなった場合、オフセットサンプルが生成されず、cloud-event-proxy は最後に認識された状態を LOCKED として無期限に報告し続けました。/sync/sync-status/os-clock-sync-state を監視するアプリケーションは、インターフェイスレベルのロック状態が正しく FREERUN を報告していたにもかかわらず、同期チェーンが実際に切断されている間は FREERUN を 検出しませんでした。今回のリリースでは、cloud-event-proxy は、再設定後に phc2sys がCLOCK_REALTIME を シンクとして選択しなくなったことを検知し、os-clock-sync-state に対して FREERUN を発行します。CLOCK_REALTIME の オフセット報告が再開されると、通常のオフセットおよびしきい値処理が再開されます。その結果、os-clock-sync-state を監視するアプリケーションは、BC ノードおよび T-BC ノードで CLOCK_REALTIME 同期が失われた場合に、FREERUN を 正しく監視します。OCPBUGS-105469
  • 今回のアップデート以前は、Ingress Operator は、関連性のない変更が発生した場合に、デフォルト値が空でないフィールドを空に戻していました。また、イメージ URL を除く 初期化 コンテナー内のすべての変更を無視していました。その結果、これらのフィールドに異なる値が入力されると、イングレス Operator は無限のリコンシリエーションループに陥り、同じ変更を繰り返し元に戻したり再適用したりしていました。今回のリリースでは、API サーバーによってデフォルト値が設定され、Operator によって管理されるフィールドが、コピーとハッシュの計算に含まれるようになりました。その結果、無関係な変更は一度だけ報告され、無限のリコンシリエーションループが発生することはありません。OCPBUGS-105469
  • 今回のアップデート以前は、Multus はコンテナーにネットワークインターフェイスを割り当てる際に、SR-IOV および PCI デバイス ID を Pod 全体でソートしていました。その結果、各コンテナーが同じデバイスリソースを要求するマルチコンテナー Pod では、Pod の再起動によって、誤ったネットワークインターフェイスが誤ったコンテナーに割り当てられる可能性があります。その結果、ネットワークステータス周辺機器相互接続 (PCI) アドレスが PCIDEVICE_* 環境変数と一致しなくなり、コンテナーが誤った Virtual Function (VF) を使用する状態になった。今回のリリースでは、Multus は Pod 全体でデバイスをソートするのではなく、kubelet のデバイス割り当て順序を保持するようになりました。その結果、各コンテナーは割り当てられたデバイスとネットワークアタッチメント間の正しいマッピングを受け取り、マルチコンテナーワークロードにおいて SR-IOV ネットワークインターフェイスが正しく割り当てられることが保証されます。OCPBUGS-105469
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

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

Legal Notice

Theme

© 2026 Red Hatトップに戻る