1.6.15. ネットワーク
-
以前は、SR-IOV Network Operator は
SriovNetworkNodePoliciesリソースを順不同でリストしていました。これにより、sriov-device-pluginPod が継続的な再起動ループに入りました。このリリースでは、SR-IOV Network Operator はポリシーを決まった順序でリストし、sriov-device-pluginPod が継続的な再起動ループに入らないようにします。(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) を削除すると、新しいsriovOperatorConfigCR を作成できませんでした。このリリースでは、sriovOperatorConfigCR を削除すると、Single Root I/O Virtualization (SR-IOV) Network Operator が検証 Webhook を削除するため、新しいsriovOperatorConfigCR を作成できます。(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-multusnamespace 内の Multus DaemonSet Pod のログを検査するようになりました。(OCPBUGS-33959) -
以前は、
OVNKubernetesNorthdInactiveのアラートは、発生する必要がある状況で発生しませんでした。このリリースでは問題が修正され、OVNKubernetesNorthdInactiveのアラートが期待どおりに発生するようになりました。(OCPBUGS-33758) - 以前は、デフォルトルートがカスタマイズされたすべての Pod で、Kubernetes-OVN マスカレードアドレスのルートが欠落していたため、各 Pod はバックエンドとして機能するサービスを介して自己接続できませんでした。このリリースでは、欠落していた Kubernetes-OVN マスカレードアドレスのルートが Pod に追加され、問題は発生しなくなりました。(OCPBUGS-36865)
-
以前は、
iptables-alerterPod はcrictlコマンドラインインターフェイスからのエラーを処理しなかったため、Pod がhost-networkPod からのイベントを誤ってログに記録したり、Pod が再起動したりすることがありました。このリリースではエラーが正しく処理されるため、これらの問題は発生しません。(OCPBUGS-37713) - 以前は、クラスターがコンピュートノードからコントロールプレーンに到達できるようにするために、プロキシーを使用してホストされたクラスターを作成した場合、クラスターでコンピュートノードを使用できませんでした。このリリースでは、ノードのプロキシー設定が更新され、ノードがプロキシーを使用してコントロールプレーンと正常に通信できるようになりました。(OCPBUGS-37786)
以前は、ロードバランサーが設定されたオンプレミスプラットフォームにクラスターをインストールできなかった場合、
LoadBalancerサービスのLoadBalancerReady条件はSyncLoadBalancerFailedステータスを受け取りました。このステータスによって次のメッセージが生成されました。The kube-controller-manager logs might contain more details.ログはプロジェクトの
cloud-controller-managernamespace に保存されるため、このメッセージは間違っています。このリリースでは、SyncLoadBalancerFailedステータスにより正しいメッセージが伝達されます。
The cloud-controller-manager logs may contain more details.以前は、クラスターノードの IP アドレスを選択する内部コンポーネントのログレベルを制御することはできませんでした。このリリースでは、デバッグログレベルを有効にして、必要に応じてログレベルを上げたり下げたりできるようになりました。ログレベルを調整するには、次のような設定を持つ config map マニフェストファイルを作成する必要があります。
apiVersion: v1 data: enable-nodeip-debug: "true" kind: ConfigMap metadata: name: logging namespace: openshift-vsphere-infra # ...-
以前は、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)