1.6.15. ネットワーク


  • 以前は、SR-IOV Network Operator は SriovNetworkNodePolicies リソースを順不同でリストしていました。これにより、sriov-device-plugin Pod が継続的な再起動ループに入りました。このリリースでは、SR-IOV Network Operator はポリシーを決まった順序でリストし、sriov-device-plugin Pod が継続的な再起動ループに入らないようにします。(OCPBUGS-36243)
  • 以前は、新しい Pod 内に作成されたインターフェイスは非アクティブのままになり、Gratuitous Address Resolution Protocol (GARP) 通知が生成されていました。通知がクラスターに届かず、そのためにクラスター内の他の Pod の ARP テーブルが新しい Pod の MAC アドレスを更新できませんでした。この状況が原因で、ARP テーブルエントリーの有効期限が切れるまでクラスタートラフィックが停止しました。このリリースでは、GARP 通知がクラスターに届くように、Pod 内のインターフェイスがアクティブになった後に GARP 通知が送信されるようになりました。その結果、周囲の Pod は以前の動作時よりも早く新しい Pod を識別できるようになります。(OCPBUGS-30549)
  • 以前は、クラスターに対して FIPS を有効にすると、SR-IOV デバイスプラグイン Pod が失敗していました。このリリースでは、SR-IOV デバイスプラグイン Pod で FIPS が有効になっているため、クラスターに対して FIPS を有効にしても Pod は失敗しません。(OCPBUGS-41131)
  • 以前は、予約された CPU の数が少ないパフォーマンスプロファイルを使用する OpenShift Container Platform ノードを再起動すると、競合状態が発生していました。これは、Single Root I/O Virtualization (SR-IOV) Virtual Function (VF) が同じ MAC アドレスを共有し、VF を使用するすべての Pod で通信問題が発生することが原因で発生しました。このリリースでは、Operator が VF に重複する MAC アドレスが存在しないことを確認するように、SR-IOV Network Operator 設定デーモンが更新されました。(OCPBUGS-33137)
  • 以前は、sriovOperatorConfig カスタムリソース (CR) を削除すると、新しい sriovOperatorConfig CR を作成できませんでした。このリリースでは、sriovOperatorConfig CR を削除すると、Single Root I/O Virtualization (SR-IOV) Network Operator が検証 Webhook を削除するため、新しい sriovOperatorConfig CR を作成できます。(OCPBUGS-37567)
  • 以前は、別のロードバランサーを使用するためにクラスターを切り替えると、Ingress Operator は IngressController カスタムリソース (CR) ステータスの classicLoadBalancer および networkLoadBalancer パラメーターから値を削除しませんでした。この状況により、CR のステータスで classicLoadBalancer および networkLoadBalancer パラメーターからの誤った情報が報告されました。このリリースでは、別のロードバランサーを使用するためにクラスターを切り替えると、これらのパラメーターから Ingress Operator が値を削除し、CR はより正確で混乱の少ないメッセージステータスを報告します。(OCPBUGS-38646)
  • 以前は、マルチキャスト送信者とマルチキャスト受信者が同じノード上に存在する場合、マルチキャストパケットは目的のターゲットノードに到達しませんでした。これは、OVN-Kubernetes RPM パッケージの更新が原因で発生していました。このリリースでは、OVN-Kubernetes RPM パッケージでこのリグレッションが修正され、問題は発生しなくなりました。(OCPBUGS-34778)
  • 以前は、Ingress Operator の LoadBalancer サービスを作成すると、変更が有効ではないことを示すログメッセージが生成されました。本来このログメッセージは、Infra カスタムリソースの変更に対してのみトリガーされます。このリリースでは、Ingress Operator の LoadBalancer サービスを作成してもこのログメッセージは生成されなくなりました。(OCPBUGS-34413)
  • 以前は、DNSNameResolver コントローラーは、time-to-live (TTL) 値の期限が切れた IP アドレスを持つ DNS の DNS 要求を CoreDNS Pod に送信していました。これにより、これらの Pod で DNS 要求が継続的に生成され、メモリーリークの問題が発生していました。このリリースでは、DNSNameResolver コントローラーは、DNS 名に対する更新後の IP アドレスと TTL 値のリストを受信するまで待機してから、DNS 名にさらに要求を送信します。その結果、コントローラーはエラーとなる要求を生成して Pod に送信しなくなります。CoreDNS Pod は、DNS 要求にタイムリーに応答し、DNSNameResolver オブジェクトを最新の IP アドレスと TTL で更新できるようになりました。(OCPBUGS-33750)
  • 以前は、must-gather ツールを使用すると、Multus Container Network Interface (CNI) ログファイル (multus.log) がノードのファイルシステムに保存されていました。この状況が原因で、ツールはノード内に不要なデバッグ Pod を生成しました。このリリースでは、Multus CNI は multus.log ファイルを作成しなくなり、代わりに CNI プラグインパターンを使用して、openshift-multus namespace 内の Multus DaemonSet Pod のログを検査するようになりました。(OCPBUGS-33959)
  • 以前は、OVNKubernetesNorthdInactive のアラートは、発生する必要がある状況で発生しませんでした。このリリースでは問題が修正され、OVNKubernetesNorthdInactive のアラートが期待どおりに発生するようになりました。(OCPBUGS-33758)
  • 以前は、デフォルトルートがカスタマイズされたすべての Pod で、Kubernetes-OVN マスカレードアドレスのルートが欠落していたため、各 Pod はバックエンドとして機能するサービスを介して自己接続できませんでした。このリリースでは、欠落していた Kubernetes-OVN マスカレードアドレスのルートが Pod に追加され、問題は発生しなくなりました。(OCPBUGS-36865)
  • 以前は、iptables-alerter Pod は crictl コマンドラインインターフェイスからのエラーを処理しなかったため、Pod が host-network Pod からのイベントを誤ってログに記録したり、Pod が再起動したりすることがありました。このリリースではエラーが正しく処理されるため、これらの問題は発生しません。(OCPBUGS-37713)
  • 以前は、クラスターがコンピュートノードからコントロールプレーンに到達できるようにするために、プロキシーを使用してホストされたクラスターを作成した場合、クラスターでコンピュートノードを使用できませんでした。このリリースでは、ノードのプロキシー設定が更新され、ノードがプロキシーを使用してコントロールプレーンと正常に通信できるようになりました。(OCPBUGS-37786)
  • 以前は、ロードバランサーが設定されたオンプレミスプラットフォームにクラスターをインストールできなかった場合、LoadBalancer サービスの LoadBalancerReady 条件は SyncLoadBalancerFailed ステータスを受け取りました。このステータスによって次のメッセージが生成されました。

    The kube-controller-manager logs might contain more details.

    ログはプロジェクトの cloud-controller-manager namespace に保存されるため、このメッセージは間違っています。このリリースでは、SyncLoadBalancerFailed ステータスにより正しいメッセージが伝達されます。

    The cloud-controller-manager logs may contain more details.

    (OCPBUGS-31664)

  • 以前は、クラスターノードの IP アドレスを選択する内部コンポーネントのログレベルを制御することはできませんでした。このリリースでは、デバッグログレベルを有効にして、必要に応じてログレベルを上げたり下げたりできるようになりました。ログレベルを調整するには、次のような設定を持つ config map マニフェストファイルを作成する必要があります。

    apiVersion: v1
    data:
      enable-nodeip-debug: "true"
    kind: ConfigMap
    metadata:
      name: logging
      namespace: openshift-vsphere-infra
    # ...

    (OCPBUGS-32348)

  • 以前は、Operator に既存ルートの spec.host または spec.subdomain フィールドを更新する権限がなかったため、Ingress Operator はカナリアルートを正常に更新できませんでした。このリリースでは、Operator のサービスアカウントのクラスターロールに必要な権限が追加され、Ingress Operator はカナリアルートを更新できるようになりました。(OCPBUGS-36465)
  • 以前は、サポートされているオンプレミスプラットフォームで Keepalived などの一部のネットワークコンテナーを実行するには、管理者権限が必要でした。このリリースでは、サポートされているオンプレミスプラットフォームでこれらのコンテナーを実行するための管理者権限は不要になりました。(OCPBUGS-36175)
  • 以前は、NodeNetworkConfigurationPolicy (NNCP) カスタムリソース (CR) がデフォルトのスパニングツリープロトコル (STP) 実装を使用するように設定されている場合、CR 設定ファイルには stp.enabled: true と表示されていましたが、OpenShift Container Platform Web コンソールでは STP チェックボックスのチェックが外されていました。このリリースでは、NNCP CR YAML ファイルで stp.enabled: false を定義しなければ、Web コンソールで STEP チェックボックスのチェックは外されません。(OCPBUGS-36238)
  • 以前は、CanaryRepetitiveFailures 状態のタイミング更新の問題により、Ingress Controller のステータスが Degraded=False と誤表示されていました。このリリースでは、CanaryRepetitiveFailures 条件が存在する間 (適切な表示期間) は、Ingress Controller のステータスが Degraded=True として正しくマークされるようになりました。(OCPBUGS-39220)
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

Legal Notice

Theme

© 2026 Red Hat
トップに戻る