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

1.5. バグ修正

apiserver-auth

  • 以前のバージョンでは、oc login は HTTP 要求を実行して、リモートログインサーバーへの接続に使用する CA バンドルを判別していました。これにより、ログインに成功しても、ログインを試行するたびに OAuth サーバーログに remote error: tls: bad certificate エラーが生成されました。サーバー証明書チェーンはセキュアでない TLS ハンドシェイクから取得されるため、正しい CA バンドルが選択され、OAuth サーバーはログインの試行時に正しくない証明書についてのエラーをログに記録しなくなりました。(BZ#1819688)
  • 以前のバージョンでは、OAuth サーバー Pod のセキュリティーコンテキストが不完全なために、デフォルト動作を元に戻すカスタム SCC (Security Context Constraints) を取得すると、Pod がクラッシュループする可能性があります。OAuth サーバー Pod のセキュリティーコンテキストが変更され、カスタム SCC は OAuth サーバー Pod の実行を阻止しなくなりました。(BZ#1824800)
  • 以前のバージョンでは、Cluster Authentication Operator はすべての OIDC アイデンティティープロバイダーのチャレンジ認証フローを常に無効にしていました。つまり、oc login でのログインは成功しませんでした。OIDC アイデンティティープロバイダーが設定されていると、Cluster Authentication Operator は Resource Owner Password Credentials の付与を許可するかどうかを確認し、存在する場合にチャレンジベースのログインを許可するようになりました。Resource Owner Password Credentials 認証付与を許可する OIDC アイデンティティープロバイダーの oc login を使用してログインできるようになりました。(BZ#1727983)
  • 以前のバージョンでは、Cluster Authentication Operator は OAuth サーバーへの接続を適切に閉じませんでした。そのため、接続がドロップされるよりも速く開かれると、OAuth サーバーへのトラフィック量が増大しました。接続が適切に閉じられ、Cluster Authentication Operator の独自ペイロードのサービスのレベルが低下することはなくなりました。(BZ#1826341)
  • 以前のバージョンでは、設定時に kube-apiserver に到達する際にエラーが生じると、oauth-proxy コンテナーはエラーを出して終了しました。これにより、kube-apiserver およびコントローラーの安定性や速さが十分でない場合、複数のコンテナーが再起動しました。kube-apiserver に対するチェックの複数の試行が oauth-proxy コンテナーの起動時に許可されるようになりました。これにより、基礎となるインフラストラクチャーに障害が実際にある場合にのみコンテナーが失敗するようになりました。(BZ#1779388)

ベアメタルハードウェアのプロビジョニング

  • IPv4 ネットワークの使用時に UEFI ブートプロセスは ipxe.efi バイナリーを使用するため、ブートプロセスではネットワークデバイスが見つからないことを報告していました。このため、PXE (Preboot eXecution Environment) は No network devices を出してマシンを起動します。dnsmasq.conf ファイルが、IPv4 ネットワークの snponly.efi バイナリーを使用するように更新されました。PXE で起動するマシンは、ネットワーク接続があるため、UEFI ネットワークドライバーを使用し、デプロイできます。(BZ#1830161)
  • インストール時にクラスターにネットワークの問題がある場合 (イメージの低速なダウンロードなど)、インストールは失敗する可能性があります。この問題に対処するために、PXE ブートは再試行を組み込むように変更され、ベアメタルプロビジョナーとプロビジョニングされるノード間の通信における再試行のネットワークの最大数が引き上げられました。インストーラーは低速なネットワーク条件を処理できるようになります。(BZ#1822763)

ビルド

  • ビルドを開始する前に、OpenShift Container Platform ビルダーは提供された Dockerfile を解析し、ビルドに使用する修正バージョンの再構築を行いました。このプロセスには、ラベルを追加し、FROM 命令で名前が付けられたイメージの置き換えを処理することが含まれました。生成される Dockerfile は ENV および LABEL 命令を常に正しく再構築する訳ではありませんでした。生成される Dockerfile には、元の Dockerfile には含まれない = 文字が含まれる場合がありました。これにより、ビルドが構文エラーを出して失敗しました。変更した Dockerfile を生成する際に、ENV および LABEL 命令の元のテキストがそのまま使用されることにより、問題が修正されました。(BZ#1821858)
  • 以前のバージョンでは、ビルド Pod init コンテナーで失敗が生じた場合に、エラーログの最後の数行がビルドに割り当てられませんでした。そのため、誤った形式の Git URL などの init コンテナーでのビルドエラーを診断するのが困難でした。ビルドコントローラーは更新され、Init コンテナーで失敗が生じる際にエラーログがビルドに割り当てられるようになりました。ビルドの障害を診断しやすくなりました。(BZ#1809862)
  • 以前のバージョンでは、イメージのインポートの失敗または無効な Dockerfiles によって生じるビルドの失敗は、一般的なビルドエラーとしてのみ分類されました。このような問題を診断するには、デフォルト以外のビルドのロギングレベルが必要でした。イメージのインポートの失敗および無効な Dockerfiles については、新たな失敗の理由が導入されました。イメージのインポートの失敗や無効な Dockerfiles に関連するビルドの失敗が、ビルドオブジェクトのステータス内で特定できるようになりました。(BZ#1809861)
  • 以前のバージョンでは、ビルドラベルの生成および検証には完全な Kubernetes 検証ルーチンが含まれていませんでした。特定の有効なビルド設定名を持つビルドは、無効なビルドラベルの値が作成されるめに失敗しました。ビルドコントローラーおよびビルド API サーバーは、完全な Kubernetes 検証ルーチンを使用して、追加されたビルドラベルがラベルの基準を満たすようになりました。有効なビルド設定名を持つビルドにより、有効なビルドラベルの値が作成されます。(BZ#1777337)
  • 以前のバージョンでは、Buildah は、変数内に含まれる値を解析するのではなく、Dockerfiles の変数を文字通り解釈していました。そのため、Dockerfiles に変数が含まれる場合にビルドは失敗しました。Buildah が Dockerfile 変数を拡張するように更新されました。Buildah は、コンテナーイメージのビルド時に Dockerfile 環境変数の値を解析するようになりました。(BZ#1810174)
  • RunOnceDuration 受付プラグインが OpenShift 4 で無効にされている場合、activeDeadlineSeconds の値は Pod のビルドに自動的に適用されませんでした。activeDeadlineSeconds が nil に設定された Pod は、NotTerminating スコープを含むリソースクォータに一致します。そのため、ビルド Pod はクォータの制限により、NotTerminating スコープが定義されたリソースクォータを持つ namespace で起動に失敗しました。ビルドコントローラーは、Pod をビルドするために適切なデフォルトの activeDeadlineSeconds 値を適用するようになりました。ビルド Pod は NotTerminating スコープを含むリソースクォータを持つ namespace で適切に処理されるようになりました。(BZ#1829447)

クラウドコンピュート

  • クラスター Autoscaler は、ノードおよびマシンオブジェクトでのプロバイダー ID が完全に一致することを予想します。以前のバージョンでは、マシン設定に大文字と小文字が混在するリソースグループ名が含まれる場合、クラスター Autoscaler は一致するものが見つからないためにマシンを 15 分後に終了させていました。リソースグループ名はサニタイズされ、すべての文字が小文字に設定されるようになりました。今回のリリースより、大文字と小文字の組み合わせを使用してリソースグループ名を入力しても、一致するプロバイダー ID が正しく特定されるようになりました。(BZ#1837341)
  • 以前のバージョンでは、マシンおよびマシン設定仕様内の metadata フィールドは、マシンセットの作成または更新時に検証されませんでした。無効なメタデータによってアンマーシャリングのエラーが生じ、コントローラーがオブジェクトを処理できなくなりました。metadata フィールドは、マシンセットの作成および更新時に検証され、無効なエントリーがエラーを返すようになりました。無効なメタデータはマシンセットの作成前に識別され、後続のオブジェクト処理エラーの発生を防げるようになりました。(BZ#1702089)
  • スケールダウンの操作時に、マシンセットの最後のマシンには削除 (deletion) アノテーションが含まれることがあります。このマシンは、削除前に最小のマシンセットのサイズに達すると Autoscaler によって削除されません。以前のバージョンでは、最後のマシンの削除アノテーションはスケールダウン後に削除されませんでした。スケールダウン後にマシンのアノテーションのマークを解除する方法を変更する修正が導入されました。このアノテーションはマシンセットの最後のマシンで永続化しなくなりました。(BZ#1820410)
  • 以前のバージョンでは、ワーカーノードに割り当てられる AWS Identity and Access Management (IAM) ロールには、マウント時に Amazon Elastic Block Store (EBS) ボリュームを復号化するために AWS Key Management Service (KMS) キーにアクセスできる十分なパーミッションがありませんでした。そのため、Amazon Elastic Compute Cloud (EC2) インスタンスは受け入れられましたが、それらはルートドライブからの読み取りを実行できないために起動に失敗しました。カスタマーマネージドキーで KMS で暗号化された EBS ボリュームを復号化できるように、EC2 インスタンスについての必要なパーミッションが付与されました。EBS ボリュームの暗号化にカスタマーマネージドキーを使用する場合、インスタンスが正常に起動するのに必要なパーミッションを持つようになりました。(BZ#1815219)
  • マシンセット仕様の replicas フィールドは nil に設定できます。以前のバージョンでは、Autoscaler がマシンセット内のレプリカ数を判別できない場合、自動スケーリング操作は実行されませんでした。replicas フィールドが設定されていない場合、Autoscaler はマシンセットに応じて観察されるレプリカの最後の数に基づいてスケーリングの決定を行うようになりました。Autoscaling の操作は、マシン設定仕様の replicas フィールドが nil に設定されている場合でも、マシンセットコントローラーがレプリカ数を MachineSet.Status.Replicas に対して同期していることを前提としてそのまま実行できるようになりました。(BZ#1820654)
  • 以前のバージョンでは、Autoscaler は、既存ノードの削除が完了していなくても、DeleteNodes への呼び出しごとにノードグループのサイズを 1 つ減らしていました。これにより、クラスターのノード数が必要な最小数未満になりました。ノードのマシンにすでに削除タイムスタンプがある場合、ノードグループのサイズはさらに縮小されなくなりました。これにより、Autoscaler が DeleteNodes を呼び出す際に、ノード数を必要な容量未満に減らすことがなくなりました。(BZ#1804738)

Cloud Credential Operator

  • Cloud Credential Operator (CCO) は、元のクラスターが OpenShift Container Platform 4.1 でインストールされている場合にクラッシュループする可能性がありました。CCO は、CredentialsRequest オブジェクトにあるパーミッション要求を調整できませんでした。今回のバグ修正により、CCO では Infrastructure フィールドの一部が利用可能であることを前提としなくなりました。これにより、CCO は元々 OCP 4.1 でインストールされていたクラスターと連携できます。(BZ#1813343)
  • Cloud Credential Operator (CCO) は SCC (Security Context Constraints) をバイパスしなくなりました。以前のバージョンでは、CCO は CCO がタスクを実行する上で必要のない余分のパーミッションで実行されていました。今回の機能拡張により、CCO についての SCC のバイパスが不必要に行われなくなりました。(BZ#1806892)

クラスターバージョン Operator

  • Cluster Version Operator (CVO) には競合状態があり、この場合にタイムアウトした更新の調整サイクルが成功した更新と見なされていました。これは、Operator でリリースイメージ署名の取得の試行がタイムアウトしたネットワークが制限されたクラスターについてのみ生じました。このバグにより、CVO が shuffled-manifest 調整モードに入りました。このモードでは、コンポーネントが処理できない順序でマニフェストが適用されるとクラスターが破損する可能性がありました。CVO はタイムアウトした更新を失敗として処理するようになろ。更新が正常に実行される前に調整モードに入らなくなりました。(BZ#1843526)
  • 更新時のデプロイメントのロールアウトの失敗のログは CVO ログにのみに記録され、一般的なエラーメッセージのみが ClusterVersion オブジェクトに報告されました。この一般的なエラーメッセージにより、CVO ログを確認しない限り、ユーザーおよびチームがエラーをデバッグすることが困難になりました。今回のバグ修正により CVO が更新され、ロールアウトの根本的なエラーが ClusterVersion オブジェクトに公開されるようになりました。その結果、アップグレード時のデプロイメントのロールアウトをデバッグすることが容易になりました。(BZ#1768260)

コンソール kubevirt プラグイン

  • 今回のリリースでは、仮想マシンが無効なバスタイプまたは推奨されていないバスタイプでディスクを使用するように設定されている場合、作成される仮想マシンの Disks タブにはディスクインターフェイスの警告が表示されます。(BZ#1803780)
  • 以前のバージョンでは、すべての DataVolume オブジェクトは VM Disk インポートとして分類されました。この正しくない分類により、仮想マシンへの所有者の参照のない DataVolume オブジェクトについての Activity カードが非表示になりました。今回のリリースにより、仮想マシンの所有者参照のある DataVolume オブジェクトのみが VM Disk インポートとして分類され、仮想マシンへの所有者の参照を持たない DataVolume オブジェクトについての Activity カードが表示されるようになりました。(BZ#1815138)
  • 以前のバージョンでは、DataVolume オブジェクトおよびそれらの関連付けられた永続ボリューム要求 (PVC) は仮想マシンディスクの削除時に削除されませんでした。これらのオブジェクトは仮想マシンの削除時にのみ削除され、仮想マシンの削除時に DataVolume オブジェクトを保持するオプションはありませんでした。今回のリリースにより、ユーザーは仮想マシンディスクまたは仮想マシンを削除する際に DataVolume オブジェクトおよび PVC を保持するか、または削除することを選択できます。これは CD-ROM モーダルを使用して削除されたディスクについては適用されません。(BZ#1820192)
  • 以前のリリースでは、インベントリー内のディスク数は、ディスク一覧のディスク数と一致しませんでした。インベントリービューが更新され、CD-ROM およびディスクが別々に表示されるようになりました。(BZ#1803677)
  • 以前のバージョンでは、仮想マシンウィザードで使用するデフォルトの YAML で仮想マシンを作成することはできませんでした。これは、デフォルトの YAML 仮想マシンテンプレートに仮想マシンウィザードで必要な値が含まれていないためです。今回のリリースにより、デフォルトの YAML 仮想マシンテンプレートに必要な値すべてが含まれるようになりました。(BZ#1793962)
  • 以前のバージョンでは、失敗した仮想マシンの移行が成功したと報告されていました。仮想マシンの移行時に、Web コンソールでは、仮想マシンの移行に失敗するとそれを正しく報告するようになりました。(BZ#1806974)
  • 以前のバージョンでは、仮想マシンウィザードは正しい形式で cloud-init 設定を生成しなかったために、これが仮想マシンに適用されませんでした。今回のリリースにより、ウィザードによって生成された形式が修正され、仮想マシンウィザードで提供される cloud-init 設定が仮想マシンに適用されるようになりました。(BZ#1821024)
  • 以前のバージョンでは、仮想マシンテンプレートのソケットは仮想マシンウィザードで作成された最終的な仮想マシンに反映されなかったために、仮想マシンの作成後に vCPU の数が 2 倍になりました。今回のリリースにより、仮想マシンテンプレートのソケット、コアおよびスレッドは、仮想マシンの作成時に反映され、vCPU の正確な数が出されるようになりました。(BZ#1810372)
  • 仮想マシンテンプレート一覧についての URL の変更により、ユーザーは仮想マシンテンプレートの削除後に誤ったページにリダイレクトされていました。今回のリリースで URL が修正されました。(BZ#1810379)
  • 以前のバージョンでは、実行中の仮想マシンが削除されると、関連付けられた VMI が VM error のステータスで仮想マシン一覧に表示されました。今回のリリースにより、削除済みの関連付けられた仮想マシンのある古くなった VMI が一覧表示されなくなりました。(BZ#1803666)
  • 以前のバージョンでは、ディスクのインポートプロセスでは、仮想マシンのインポートリソースのみが予想されていました。そのため、仮想マシンテンプレートまたは VMI からのインポート用の仮想マシンリソースリンクは、存在しない仮想マシンを参照していました。今回のリリースにより、インポートプロセスで、インポートリソースと正しいリソースへのリンクである仮想マシンテンプレートおよび VMI を認識できるようになりました。(BZ#1840661)
  • 今回のリリースにより、仮想マシンディスクのインポートプロセスが NaN% のプロセス値を報告しなくなりました。(BZ#1836801)
  • 以前のバージョンでは、仮想マシンウィザードは、一般的なテンプレートで指定されるインターフェイスを使用する代わりに、仮想マシンルートディスクのデフォルトインターフェイスとして virtIO を使用していました。しかし、virtIO インターフェイスはすべてのオペレーティングシステムと互換性がありません。今回のリリースにより、オペレーティングシステムの適切なデフォルトインターフェイスが、使用される一般的なテンプレートに基づいて選択されるようになりました。(BZ#1803132)

Console Metal3 プラグイン

  • 以前のバージョンでは、Web コンソールの Powering on/off メッセージとベアメタルホストリンク間にはスペースがありませんでした。メッセージが適切に読み取られるようにスペースが追加されました。(BZ#1819614)
  • 以前のリリースでは、ベアメタルのインストールでは、一部のノードが利用できない場合に、Bare Metal Host Details ページが読み込まれませんでした。Bare Metal Host Details ページにはゼロ (0) Pod が表示されるようになりました。(BZ#1827490)

Web コンソール (Developer パースペクティブ)

  • 以前のバージョンでは、Topology ビューで Knative サービスに関連付けられた Pod またはリソースの一覧を表示することは容易ではありませんでした。今回のバグ修正により、Knative サービスを選択すると、サイドバーに Pod の一覧とログを表示するリンクが表示されるようになりました。(BZ#1801752)
  • Monitoring ビューの metrics タブにある PromQL エディターを使用して既存のクエリーを編集すると、カーソルは行の最後に移動します。今回のバグ修正により、PromQL エディターが予想通りに機能するようになりました。(BZ#1806114)
  • Knative イメージの場合、Add From Git オプションで、 Routing の Advanced Options は事前にフェッチされたコンテナーポートのオプションを提供しません。また、ポートのデフォルト値 8080 を更新せずにサービスを作成した場合には、リビジョンは表示されません。今回のバグ修正により、ユーザーはドロップダウンリストを使用して利用可能なポートオプションを選択するか、または別のポートを使用する必要がある場合は入力でき、リビジョンは予想通りに表示できるようになりました。(BZ#1806552)
  • 以前のバージョンでは、イメージを取得できなかったため、CLI を使用して作成された Knative サービスはコンソールを使用して編集できませんでした。編集中に関連付けられたイメージストリームが見つからない場合には、YAML ファイルでコンテナーイメージについてユーザーが指定した値が使用されるようになりました。これにより、CLI を使用してサービスを作成した場合でも、ユーザーはコンソールを使用してサービスを編集できます。(BZ#1806994)
  • Topology ビューで、Knative サービスの外部イメージレジストリーでイメージ名を編集しても新規リビジョンは作成されませんでした。今回のバグ修正により、サービスの名前が変更されると、サービスの新規リビジョンが作成されます。(BZ#1807868)
  • Add Container Image オプションを使用してから、Image stream tag from internal registry を選択した場合、ImageStreams ドロップダウンリストには、OpenShift namespace からイメージをデプロイするオプションは一覧表示されませんでした。ただし、CLI からそれらにアクセスすることができました。今回のバグ修正により、すべてのユーザーがコンソールおよび CLI を使用して OpenShift namespace のイメージにアクセスできるようになりました。(BZ#1822112)
  • 以前のバージョンでは、Pipeline Builder では、存在していない Task を参照している Pipeline を編集すると、画面全体が白くなりました。今回の修正により、アクションが必要であることを示すアイコンが表示され、Task 参照を簡単に更新できるドロップダウンリストが表示されるようになりました。(BZ#1839883)
  • Pipelines Details ページで、Parameters および Resources タブの既存のフィールドを変更する際に、新規の変更が検出されても Save ボタンが無効にされていました。検証基準が変更され、変更を送信できるように Save ボタンが有効になります。(BZ#1804852)
  • Add From Git オプションで、OpenShift Pipelines Operator によって提供される Pipeline テンプレートは Deployment または Knative Services リソースオプションが選択されている場合に失敗します。今回のバグ修正により、リソースタイプとランタイムを使用して Pipeline テンプレートを判別するサポートが追加され、リソース固有の Pipeline テンプレートが提供されるようになりました。(BZ#1796185)
  • Pipeline が Pipeline Builder を使用して作成され、array タイプの Task パラメーターが使用されると、Pipeline は起動しませんでした。今回のバグ修正により、array および string タイプのパラメーターの両方がサポートされるようになりました。(BZ#1813707)
  • Topology ビューで、namespace に Operator によってサポートされるサービスがある場合に、アプリケーションによるノードのフィルターを実行するとエラーが返されました。今回のバグ修正により、選択されたアプリケーショングループに基づいて Operator がサポートするサービスノードをフィルターに掛けるロジックが追加されました。(BZ#1810532)
  • Developer Catalog には、Clear All Filters オプションを選択するまでカタログの結果が表示されませんでした。今回のバグ修正により、すべてのカタログ項目がデフォルトで表示されるようになり、すべてのフィルターをクリアする必要がなくなりました。(BZ#1835548)
  • 以前のバージョンでは、ユーザーは knative サービスの環境変数を追加できませんでした。そのため、envVariables が必要になるアプリケーションには予想通りに機能できない場合があります。今回のリリースより、環境変数についてのサポートが追加されました。(BZ#1839114)
  • Developer Console Navigation メニューが利用できるようになり、最新の UX デザインに合わせて調整されました。(BZ#1801278)
  • Developer パースペクティブの Monitoring タブに Time Range および Refresh Interval ドロップメニューが追加されました。(BZ#1807210)
  • Start Pipeline モーダルには Pipeline リソースが必要でしたが、Pipeline リソースは namespace に作成されませんでした。ユーザーにはフィールドの上に無効の、および空のドロップダウンが表示され、フィールドのコンテキストの一部が失われました。今回のバグ修正により、Create Pipeline Resource から、Start Pipeline モーダルでのコンテキスト情報がユーザーに提供されるようになりました。ユーザーは、namespace に Pipeline リソースが作成されていない場合に、Start モーダルから Pipeline を開始しやすくなりました。(BZ#1826526)
  • レイアウトのパディングがないため、タイトルが Close ボタン上に表示されました。テキストが Close ボタンの上に置かれると、クリックすることが困難になります。レイアウトが修正され、タイトルが 閉じる ボタン上に表示されないように修正され、ボタンはマウスクリックで常にアクセスできるようになりました。(BZ#1796516)
  • Pipeline Builder は、空の文字列 ('') のデフォルト値をデフォルトなしとして誤って解釈していました。Operator で提供される一部のタスクでは、これをデフォルトにする必要があり、デフォルトなしの機能で問題が生じました。デフォルトプロパティーの有無を確認し、値が有効であることを前提としないでください。今回のリリースより、OpenShift Pipeline Operator が有効なデフォルト値として認識するすべての値が考慮されるようになりました。(BZ#1829567)
  • Pipeline Builder は Task/ClusterTask 定義を読み取り、すべてのパラメーターのタイプが string であると誤って仮定していました。array タイプの Task パラメーターが出ると、array を string にキャストし、これを表示するため、タイプが失われました。また、Task パラメーターへの値を string として生成するため、Task への接続が中断しました。array タイプが web コンソールでサポートされ、タイプが適切に再調整されるようになりました。どちらのタイプも管理することで、Pipeline Builder は予想通りに機能できるようになりました。(BZ#1813707)
  • Pipeline ページは他のページとの整合性がありません。Create Pipeline ボタンは常に有効にされており、プロジェクトが利用できない場合に考慮されませんでした。Create Pipeline ボタンは、Getting Started ガイドが有効にされている場合に削除されるようになりました。(BZ#1792693)
  • Dashboard & Metrics タブのメトリクスのクエリーが設計文書で更新されました。クエリーに関して同期するために必要なコード。クエリーが更新され、メトリクスクエリーとそれらのラベルの順序が設計と同期するようになりました。(BZ#1806518)
  • タイル説明変数は、CSV 記述で追加された CRD 記述に誤って設定されました。これにより、タイルの説明の正しい内容が表示されませんでした。タイルの説明は元の値に戻り、追加された値がそれ自体の変数に移されました。(BZ#1814639)
  • eventSources API グループは、最新のサポートされている API グループ sources.knative.dev に更新されました。今回の更新により、新規の API グループによって生成されたソースが Web コンソールの Topology ビューで認識されるようになりました。(BZ#1836805)
  • Red Hat OpenShift Serverless 1 の Serverless Operator バージョン 1.7.1 のリリースにより、Operator は一般的に利用可能になりました。Web コンソールの Developer パースペクティブの Tech Preview バッジが削除されました。(BZ#1827042)

DNS

  • 以前のバージョンでは、CoreDNS メトリクスは、クラスター内の非セキュアなチャネルで公開されていました。CoreDNS メトリクスエンドポイントをセキュアにし、セキュアなチャネル上で CoreDNS メトリクスを公開するために適切な TLS コンポーネントおよび kube-rbac-proxy サイドカーが追加されました。(BZ#1809197)
  • 以前のバージョンでは、任意のテイントをノードに追加すると、DNS Operator のオペランドに関連する問題が発生する可能性がありました。DNS Operator のオペランドは、ノードに追加されるテイントを許容するようになりました。オペランドは、すべての Linux ノードホストの /etc/hosts で実行され、これを更新します。オペランドが初期化中のノードで起動する場合に、Missing CNI default network イベントが観察される可能性がありますが、このエラーは一時的であり、無視することができます。(BZ#1813479)
  • 以前のバージョンでは、マスターノードに特定の DNS 名を持たせる際に依存関係を考慮する必要がありました。任意の有効なホスト名をマスターノードに使用できるようになりました。(BZ#1807234)
  • 以前のバージョンでは、dnses.operator.openshift.io/default オブジェクトが存在するものの、それに対応する DaemonSet が利用不可の場合、 clusteroperators/dns は、Available 状態を、正しくない NoDNS の理由と No DNS resource exists メッセージと共に報告していました。同じ条件下で、正しい理由とメッセージが表示されるようになりました。(BZ#1835725)

etcd

  • 以前のバージョンでは、etcd ピア証明書には IPv6 localhost アドレスが含まれず、https://[::1]:2379 メッセージでの接続に失敗していました。今回のバグ修正により、::1 がピア証明書のホストの 1 つとして含まれます。繰り返し失敗する https://[::1]:2379 を使用した接続の試行は表示されなくなりました。(BZ#1810997)
  • 以前のバージョンでは、CVO は設定マップの証明書を 10 分ごとに上書きしていました。これにより、多くのオーバーヘッドが発生し、これによりクラスターのパフォーマンスと安定性にマイナスの影響が及びました。証明書は設定マップに 1 回限り作成されるようになり、パフォーマンスおよび安定性が向上します。(BZ#1819472)
  • 以前のバージョンでは、クラスター etcd Operator のヘルスステータスのレポートは容易に理解できるものではありませんでした。これはログメッセージングの設定が不適切に行われていたために生じ、これにより、クラスターのステータスが不確実になりました。これは、etcd のステータスについての適切なログメッセージおよびイベントを作成するために別の機能を使用して Operator ステータスを適切に分析することで修正されています。すべてのマスターノードでの etcd Pod のステータスがより分かりやすくなりました。(BZ#1821286)
  • 以前のバージョンでは、TLS 証明書の署名が、3 年について署名されると文書で記載されていても、10 年について誤って署名されていました。証明書は 3 年についてのみ署名されるようになりました。(BZ#1837594)
  • gRPC-go 1.23.0 には、クライアント側のロードバランサーのバグがありました。このバグによりデッドロックが生じる可能性がありました。gRPC-go はバージョン 1.23.1 にアップグレードされ、バグは修正されています。(BZ#1823993)
  • すべての Pod を停止した後、復元プロセスは etcd、api-server、api-scheduler、および controller-manager のみを再起動します。ネットワーク Pod を再起動しませんでした。そのため、kubelet は通信できず、ベアメタルクラスターを起動できませんでした。復元サービスは再起動できない Pod を停止しなくなりました。クラスターは復元プロセスの実行後に起動します。(BZ#1835146)

Etcd Operator

  • 以前のバージョンでは、etcd 仕様にプロパティーがないため、oc explain etcd コマンドが仕様から参照されるプロパティーを誤って一覧表示していました。適用可能な CRD は、不足しているプロパティーを記述するように更新されました。oc explain etcd コマンドは etcd のプロパティーを完全に記述するようになりました。(BZ#1809282)
  • Etcd Operator はヘルスチェックが適切に実行しないため、誤ったイベントレポートや誤解されるログメッセージが生成されました。ヘルスステータスは、改善されたメッセージングで正しく検出されるようになり、正確なヘルスステータスが提供されるようになりました。(BZ#1832986)

イメージ

  • 以前のバージョンでは、nodeca デーモンは、レジストリーが managed に設定されている場合にのみ作成されていました。レジストリーが削除されると、nodeca デーモンは作成されません。今回のバグ修正により、nodeca デーモンが常に作成され、レジストリーが削除されても nodeca デーモンが作成されるようになりました。(BZ#1807471)

イメージレジストリー

  • 以前のバージョンでは、適切なストレージ設定なしにレジストリー設定を削除した場合、ストレージ設定がないためにリソースは終了せず、Operator はストレージを認識しないためにストレージを削除できませんでした。今回のバグ修正により、ストレージ設定はオプションになり、これによりリソースを完了できるようになりました。(BZ#1798618)
  • 以前のバージョンでは、イメージレジストリー Operator は、イメージレジストリーで作成されたリソースに nodeSelector ラベルを設定しませんでした。そのため、実行できるノードリソースが指定されないための問題が発生する可能性が生じ、レジストリーがサポート対象外のプラットフォームで実行される可能性がありました。今回のバグ修正により、不足しているラベルが作成されるリソースに追加されるようになりました。作成されたリソースでラベルを確認できるようになりました。(BZ#1809005)
  • 以前のバージョンでは、イメージを存在しない namespace にプッシュすると、イメージレジストリーは 500 のエラーコードを返していました。今回のバグ修正により、戻りコードが変更され、パーミッションがないことが示されるようになりました。イメージを存在しない namespace にプッシュすると、パーミッション拒否エラーが返されます。(BZ#1804160)
  • Azure インフラストラクチャー名は、生成される Azure コンテナーおよびストレージアカウントに使用されます。そのため、Azure インフラストラクチャー名に大文字が含まれる場合、コンテナーは正常に作成されますが、ストレージアカウントの作成は失敗しました。今回のバグ修正により、コンテナー名の作成ロジックが無効な文字を破棄するように調整され、イメージレジストリーを名前に無効な文字が含まれるインフラストラクチャーにデプロイできるようになりました。(BZ#1827807)
  • GCP ストレージと共に空でないイメージレジストリーを削除する際に、イメージレジストリーホスト名はイメージ設定ファイルから削除されませんでした。これにより、新規イメージレジストリーを作成することができませんでした。イメージレジストリーの削除時に、イメージ設定ファイルからイメージレジストリーホスト名を削除できるようにコードが変更されました。この結果として、イメージレジストリーを予想通りに削除し、作成することができます。(BZ#1827075)
  • イメージレジストリーはバケットの削除前にバケットからオブジェクトを削除していなかったため、イメージと共にバケットを削除できませんでした。コードは、バケットを削除する前にイメージを削除するように変更されました。空でないバケットを予想通りに削除することができます。(BZ#1827075)
  • イメージレジストリーのイメージは yum キャッシュをクリアしていないため、イメージサイズが大きくなる可能性があります。イメージレジストリー Dockerfile は、yum clean all コマンドを組み込むように変更されました。イメージのサイズはさらに小さくなります。(BZ#1804493)
  • イメージプルーニングのカスタムリソースの keepYoungerThan パラメーターはナノ秒を使用し、より長い時間を使用するように設定することはできません。ナノ秒は、イメージプルーナーで使用するのに適切な期間ではありません。新規パラメーターが、イメージプルーニングカスタムリソースの keepYoungerThan パラメーターを置き換え、上書きする keepYoungerThanDuration に追加されました。(BZ#1835004)
  • イメージレジストリー Operator は、ユーザーが Operator を Removed 状態に切り換える際にストレージのステータスを適切にクリーンアップしませんでした。その結果、ユーザーが Operator を Managed に戻すと、Operator は新規ストレージ Pod を作成できませんでした。Operator はストレージステータスを適切にクリーンアップするように変更され、Operator は新規ストレージ Pod を作成できるようになりました。(BZ#1785534)
  • イメージレジストリー Operator はログを取り除かないため、ログに適切でないメッセージが表示される可能性がありました。ログを取り除き、これらの不適切なメッセージを削除するようにコードが変更されました。ログに適切な情報が表示されるようになりました。(BZ#1797840)
  • デフォルトのイメージレジストリー Operator はゼロ (0) レプリカで設定されているため、値を手動で変更しない限り、問題が発生する可能性がありました。Operator は 1 でインストールするように更新されました。(BZ#1811846)
  • クラスターのインストール時に使用されるレジストリーの認証情報は、特定の namespace で利用できず、ユーザーは新規の認証情報を作成する必要がありました。レジストリーの認証情報がインストール時に提供されている場合、ユーザーはこれらの認証情報を使用してイメージをインポートできるようにコードが変更されました。(BZ#1816534)
  • イメージレジストリー Operator は 1 つの Pod でのみインストールされているため、要件を満たしませんでした。Operator は高可用性の確保のために 2 つの Pod と共にインストールできるようになりました。(BZ#1810317)

インストーラー

  • Azure プラットフォームでは、Pod のボリュームマウントを作成するために cifs-utils パッケージが必要になります。今回のリリースにより、OpenShift Container Platform のインストール時に RHEL 7 ホスト用にインストールされるパッケージに cifs-utils が含まれます。(BZ#1827982)
  • コントロールプレーン証明書の期限切れの状態からのリカバリー時に、クラスターはポート 7443 のリカバリー API サーバーに接続できません。これは、リカバリー API サーバーのポートが OpenStack、oVirt、ベアメタル、および vSphere に使用される HAProxy ポートと競合するためです。これにより、Unable to connect to the server: x509: certificate signed by unknown authority エラーが生じます。HAProxy はポート 9443 でリッスンするようになり、リカバリー API サーバーはポート 7443 を使用して期限切れのコントロールプレーン証明書のリカバリープロセスを容易にします。(BZ#1821720)
  • 以前のリリースでは、RHOSP インストーラーは、トラフィックの発信元を許可するために remote_group_id を使用してセキュリティーグループを作成していました。セキュリティールールで remote_group_id を使用すると、OVS エージェントによる多くの計算をトリガーしてフローを生成するため非効率なプロセスが生じました。このプロセスでは、フローの生成に割り当てられた期間が超過することがありました。このような場合、すでに負荷がかかっている環境ではとくに、マスターノードはワーカーノードと通信できず、デプロイメントに失敗します。remote_group_id ではなく、トラフィックの発信元をホワイトリスト化するための IP 接頭辞が使用されるようになりました。これにより、Neutron リソースの負荷が軽減され、タイムアウトの発生回数が減ります。(BZ#1825286)

  • 以前のバージョンでは、Red Hat Virtualization (RHV) に OpenShift Container Platform クラスターを作成する前に、インストールプログラムでは、ユーザーは仮想マシンテンプレートを手動で作成する必要がありました。これは、インストールプログラムが RHV バージョン 4.3.9 で以下の要件を満たしていないためです。

    • インストールプログラムは ignition を仮想マシンに渡す必要があります。
    • テンプレートは、その OS タイプを Red Hat CoreOS (RHCOS) として指定する必要があります。

    インストールプログラムは、RHCOS を OS タイプとして指定するテンプレートを作成し、Ignition を仮想マシンに渡します。ユーザーが仮想マシンテンプレートを作成する必要がなくなりました。(BZ#1821151)

  • 以前のリリースでは、ベアメタルインストーラーでプロビジョニングされるインフラストラクチャークラスターで API-VIP と INGRESS-VIP アドレスの両方にフェイルオーバーを提供する Keepalive プロセスは、ローカルコンポーネントのステータスを監視してデプロイメントが IPV6 アドレスを使用しても VIP を所有するノードを判別するスクリプトで IPV4 ローカルアドレスを使用しました。このため、IPv6 デプロイメントでは、Keepalived が正しくないコンポーネントのステータスを受信することがありました。Keepalived スクリプトは localhost を使用しており、V4 デプロイメントでは 127.0.0.1 に、V6 デプロイメントでは ::1 に解決されるため、常に正しいローカル IP アドレスを使用します。(BZ#1800969)
  • 以前のバージョンでは、インストーラーでプロビジョニングされるインフラストラクチャーを使用するベアメタルクラスターで、VIP は常に正常なロードバランサーでコントロールプレーンマシンにフェイルオーバーする訳ではありませんでした。そのため、ローカルロードバランサーが正常ではなく、OpenShift Container Platform API が ~10 秒間到達できない場合でも、コントロールプレーンマシンは API-VIP IP アドレスを引き続き所有します。API-VIP スクリプトの Keepalived チェックはセルフホスト型のロードバランサーの正常性を監視し、API-VIP は実行中のロードバランサーでコントロールプレーンノードにフェイルオーバーし、OpenShift Container Platform API のサービスダウンタイムの発生を防ぐようになりました。(BZ#1835974)
  • 以前のバージョンでは、インストールプログラムは machineCIDR と provisioningNetworkCIDR 範囲の重複の有無を明示的に確認しませんでした。その結果、重複するネットワーク範囲が不明確な場合にエラーメッセージが表示されました。インストールプログラムはこれらのネットワーク範囲の重複を明示的にチェックし、重複がある場合には明確なエラーメッセージを表示するようになりました。(BZ#1813422)
  • コントロールプレーンの Operator はブートストラッププロセスの完了前に起動できるので、ベアメタルのプロビジョニングインフラストラクチャーがブートストラップとコントロールプレーンの両方で同時にアクティブになる可能性があります。以前のバージョンでは、プロビジョニングインフラストラクチャーの両方がコンピュートマシンをプロビジョニングし、マシンすべてが同じインフラストラクチャーを使用する訳ではありませんでした。ブートストラップのプロビジョニングインフラストラクチャーはコントロールプレーンマシンのみをプロビジョニングするようになり、両方のプロビジョニングインフラストラクチャーを同時にオンラインにすることができます。(BZ#1800746)
  • 以前のバージョンでは、IPv6 のブートストラップノードへの DHCP トラフィックをブロックする際に誤ったポート番号が使用されていました。このため、コントロールプレーンマシンがブートストラップノードから DHCP リースを誤って取得した場合に競合状態が生じました。正しいポートが DHCPv6 についてブロックされ、コントロールプレーンマシンはクラスターで実行されるベアメタルインフラストラクチャーからのみプロビジョニングされるようになりました (BZ#1809691)。
  • 以前のバージョンでは、インストーラーでプロビジョニングされるインフラストラクチャーを使用するベアメタルクラスターの場合、VRRP を使用して OpenShift Container Platform クラスターの仮想 IP アドレスを管理することは、複数のクラスターを実行する場合に仮想ルーター ID がブロードキャストドメインですでに使用されている可能性があることを意味しました。このため、ノードにはすでに使用中の仮想 IP アドレスが割り当てられる可能性があります。ツールを使用して、クラスターをデプロイする前に、選択したクラスター名に使用される仮想ルーター ID を確認できるようになりました。(BZ#1821667)
  • OpenShift Container Platform version 4.1 クラスターは infrastructure.status.infraPlatform パラメーターを使用しませんでした。そのため、Operator は元はバージョン 4.1 をインストールしたクラスターの古いフィールドをチェックして使用する必要があり、これにより、アップグレード時にエラーが生じました。移行コントローラーはクラスターで利用可能な情報を使用して、アップグレード時にすべてのクラスターの新規フィールドを設定し、Operator がすべての新規パラメーターを使用し、アップグレードエラーを減らすことができるようになりました。(BZ#1814332)
  • クラスターのリソースの取得に使用される AWS API の前に削除されたリソースへの反応が非常に遅くなるため、削除されたホストゾーンの削除を試み、クラスターを複数回破棄しようとすると失敗が生じました。このため、destroy コマンドは、AWS API がホストされたゾーンをそれらの応答から削除するまでループしました。インストールプログラムは、ホストされるゾーンの notfound エラーを省略し、destroy コマンドがより速く実行されます。(BZ#1817201)
  • 以前のバージョンでは、ブートストラップサーバーのエンドポイントは、外部ロードバランサーを通過する api エンドポイントを使用していました。このため、別のポートを開いて RHEL ノードをクラスターに追加する必要がありました。ブートストラップサーバーのエンドポイントは内部の api-int エンドポイントを使用するようになり、外部ロードバランサーで別のポートを開く必要がなくなりました。(BZ#1792822)
  • 以前のリリースでは、ベアメタルクラスターの場合、ノード DNS 解決をサポートするために、ノードの /etc/resolv.conf ファイルは、ノードのコントロールプレーンの IP アドレスをノードの /etc/resolv.conf ファイルに追加してインフラストラクチャー CoreDNS のローカルインスタンスを参照しました。そのため、ホストの /etc/resolv.conf ファイルに 3 つのネームサーバーがすでに一覧表示されている場合、Pod は nameserver limits was exceeded アラートを生成していました。最初の 3 つのネームサーバーのみが生成される /etc/resolv.conf ファイルに含まれるようになり、アラートが Pod によって生成されなくなりました。(BZ#1825909)
  • 以前のリリースでは、ipxe.efi ファイルが実行中の ironic コンテナーに存在しないため、ipxe.efi が必要な場合に起動 UEFI が失敗しました。ipxe.efi ファイルがランタイム時に /shared ディレクトリーにコピーされ、UEFI ブートは影響を受けなくなりました。(BZ#1810071)
  • 以前のバージョンでは、AWS からの速度制限により、クラスターのレコードを作成できませんでした。インストールプログラムは指数関数的バックオフを使用して待機タイムアウトを長くすることができ、速度制限による失敗数が少なくなりました。(BZ#1766691)
  • 以前のバージョンでは、AWS からの速度制限により、クラスターのゾーンの取得に失敗する場合があり、これによってクラスターのインストールが実行できなくなりました。インストールプログラムは指数関数的バックオフを使用して待機タイムアウトを長くすることができ、速度制限による失敗数が少なくなりました。(BZ#1779312)
  • 以前のバージョンでは、インストールプログラムが設定ファイルへの相対パスを判別する際にシンボリックリンクをチェックしないため、インストールプログラムがシンボリックリンクから実行される場合に、インストールは失敗します。インストールプログラムはシンボリックリンクの有無を確認し、シンボリックリンクを指定したディレクトリーからインストールプログラムを実行できます。(BZ#1767066)

  • 以前のバージョンでは、インストールプログラムが使用する AWS Terraform プロバイダーにより S3 バケットでの競合状態が生じ、クラスターのインストールは以下のエラーを出して失敗することがありました。 

    When applying changes to module.bootstrap.aws_s3_bucket.ignition, provider level=error msg="\"aws\" produced an unexpected new value for was present, but now absent.

    インストールプログラムは異なる AWS Terraform プロバイダーコードを使用します。これは、S3 の最終的な一貫性を確実に処理し、インストーラーでプロビジョニングされた AWS クラスターのインストールがエラーで失敗しなくなりました。(BZ#1745196)

  • 以前のバージョンでは、CoreDNS forward プラグインはデフォルトでランダムサーバー選択ポリシーを使用していました。そのため、複数の外部 DNS リゾルバーが指定されている場合に、クラスターは OpenStack API ホスト名の解決に失敗していました。プラグインは、指定された順序で DNS サーバーを使用できるようになりました。(BZ#1809611)
  • OpenShift Container Platform をインストールできる RHOSP クラウド間にはパフォーマンスの変動性があるため、インストール時間は異なります。その結果、インストールが成功する前にインストーラーがタイムアウトする可能性があります。回避策として、インストーラーが失敗について示唆した後にクラスターのステータスを確認します。クラスターは正常である可能性があります。(BZ#1819746)
  • RHOSP では、コントロールプレーンおよびコンピュートノードは、IP アドレスを優先するネームサーバーとして /etc/resolv.conf ファイルに挿入します。その結果、ファイルにすでに 3 つのネームサーバーがあるホストは、ネームサーバーの制限についての警告を生成しました。/etc/resolve.conf の最初の 3 つのネームサーバーのみが保持されるようになりました。この場合、Pod はネームサーバーの警告を生成しなくなりました。(BZ#1791008)
  • 以前のリリースでは、トランクポートのない RHOSP クラウドは、インストーラーが失敗として誤って解釈したエラーを返す可能性がありました。その結果、クラスターの破棄がタイムアウト前にループする可能性がありました。今回の更新により、インストーラーがエラーを正しく解釈し、トランクポートをサポートしないクラウドでのクラスターの正常な破棄が可能になりました。(BZ#1814593)
  • 名前を共有する RHOSP リソースは削除できません。以前のバージョンでは、名前を共有するセキュリティーグループが存在する場合には、Ansible Playbook を使用するクラスターの破棄が RHOSP クラウドで失敗しました。down-security-groups.yaml Playbook はクラスターを破棄する際に名前の代わりにグループ ID を使用できるようになりました。Playbook が正常に終了すると、すべてのセキュリティーグループが削除されます。(BZ#1841072)
  • 一部の RHOSP 環境では、仮想マシンが一時ディスクで起動できないようにするポリシーが実行される可能性があります。そのため、ブートストラップマシンが一時ディスクから起動しようとすると、クラスターのインストールが失敗しました。ブートストラップマシンはコントロールプレーンのマシンプールからの rootVolume 設定に従い、仮想マシンが一時ディスクで起動できない環境でクラスターのインストールを正常に実行できるようになりました。(BZ#1820434)
  • 以前のバージョンでは、RHOSP で実行されるクラスターでの Floating IP アドレス (FIP) の関連付けの前に、前提条件の Terraform の手順が常に実行される訳ではありませんでした。そのため、競合状態が生じ、インストールが失敗する可能性がありました。Thereaform の手順は FIP の関連付けの前に常に実行されるようになりました。(BZ#1846297)
  • RHOSP のユーザーによってプロビジョニングされるインストールのスクリプトは一部の Ansible バージョンと互換性がないため、インストールは失敗しました。このスクリプトは、より幅広い互換性を確保できるように更新されました。これで、Ansible のバージョンに関係なくインストールは正常に実行されるようになります。(BZ#1810916)
  • 現時点で、RHOSP のユーザーによってプロビジョニングされるインフラストラクチャー Playbook は、クラスターの有効期間に作成される Cinder ボリュームを削除しません。そのため、破棄されるクラスターは Cinder ボリュームをリークします。回避策として、クラスターの破棄後に Cinder ボリュームを手動で削除します。(BZ#1814651)
  • 以前のバージョンでは、RHOSP のクラスターは、認証局 (CA) ファイルバンドルでこれに渡されたすべての証明書を処理しませんでした。そのため、クラスターはデフォルト以外の信頼される認証局によって署名された中間証明書でインストールできませんでした。CA ファイルは分割され、個別に処理されるようになりました。これにより、デフォルト以外の信頼できる認証局によって署名された中間証明書を使用するインストールが可能になりました。(BZ#1809780)

kube-apiserver

  • 以前のバージョンでは、一部のユーザーは、アップストリームのバグが Kubernetes 1.14 および 1.16 コンポーネントの組み合わせを使用するクラスターの実行を妨げていたために、4.2 から 4.3 にアップグレードできませんでした。今回の修正には、アップグレード時に OpenShift Container Platform 4.3 が OpenShift Container Platform 4.2 と互換性を持つように、アップストリームからのマージが含まれるようになりました。(BZ#1816302)
  • 以前のバージョンでは、Operator の新規バージョンの作成時に、ロックがリリースされるまでに数分かかる可能性があり、リーダーの選択の設定は、Operator がシャットダウンする UNIX シグナルを受信する際にロックを解除しないため、新規バージョンの Operator が継続する可能性がありました。今回の修正により、Operator のロールアウト時間は、コントロールプレーン Operator が正常に終了する期間を確保し、起動時にロックがリリースされるまで待機する必要がないため、大幅に改善されました。(BZ#1775224)
  • 以前のバージョンでは、アップグレード時に OpenShift Container Platform API サーバーは、ノード上のルートが誤って設定されたためにトラフィックを提供できなくても、GCP ロードバランサーに再び追加されることがありました。これは、ノードと GCP ロードバランサー間の競合状態が原因で生じました。これは、ルート設定を iptables に移動し、ローカルトラフィックと非ローカルトラフィックを区別することで修正されています。ローカル以外のトラフィックは常に受け入れられるようになりました。API サーバーのアップグレード時に、接続は正常に終了し、新しい接続は実行中の API サーバーに対してのみ負荷分散されるようになりました。(BZ#1802534)

kube-scheduler

  • 以前のバージョンでは、Descheduler はノードチェックループの初期段階で Pod が NodeAffinity ストラテジーでエビクトできるかどうかを判別するため、特定のノードに適合するためにエビクト可能であった Pod はエビクトされない可能性がありました。ノードチェックループのブレーク条件が修正され、エビクトの可能性を確認する際にすべてのノードが考慮されるようになりました。(BZ#1820253)

ロギング

  • 以前のバージョンでは、Fluentd バッファーキューは制限されず、大量の受信ログにより、ノードのファイルシステムが一杯になり、クラッシュする可能性がありました。その結果として、アプリケーションはスケジュール変更されます。この種のクラッシュを防ぐために、Fluentd バッファーキューは出力ごとに固定した量のチャンクに制限されるようになりました (デフォルト: 32)。(BZ#1780698)
  • IPv6 ベアメタルのデプロイメントでは、Elasticsearch はクラスター IPv6 アドレスではなく IPv4 ループバックアドレスにバインドされました。その結果、Elasticsearch クラスターは起動できませんでした。Elasticsearch のバインディングおよび公開ホストを設定するために Downward API が変更されました。Elasticsearch はネットワークインターフェイスにバインドでき、予想通りに起動します。(BZ#1811867)
  • クラスターロギングのクラスターロギングバージョン (CSV) は、一部のクラスターロギングコンポーネントのステータスを取得するために誤ったパスを使用していたため、ステータスは報告されませんでした。そのため、クラスターロギングは適切に機能しませんでした。パスは修正され、クラスターロギングが予想通りに機能するようになりました。(BZ#1840888)
  • Elasticsearch Operator は 4 つ以上の Elasticsearch ノードが設定された場合に 2 つ目のデプロイメントを作成するため、Cluster Logging Operator は Elasticsearch ノードの正確な数を読み取りませんでした。そのため、クラスターロギングのカスタムリソースは、1 つのデプロイメントに関連するノードの数を常に報告しました。Cluster Logging Operator は Elasticsearch ノードの数を正しく計算するために変更されました。(BZ#1732698)

Machine Config Operator

  • ワーカーノードで利用可能な複数のネットワークにより、CRI-O のコントロールプレーンでアドレスを選択することは容易ではありせん。これにより、CRI-O はコントロールプレーン以外のインターフェイスにバインドされることがよくあります。今回のバグ修正により、CRI-O systemd サービスが適切なインターフェイスを選択し、CRI-O サービスを設定するサービスに依存するようになりました。これにより、CRI-O は予想通りにコントロールプレーンのアドレスにバインドされます。(BZ#1808018)
  • 以前のバージョンでは、IPv6 ベアメタルデプロイメントで OperatorHub をネットワークが制限された環境用に設定する場合、DHCP で提供される名前がなしに OpenShift Container Platform (OCP) ノードで複数のインターフェイスが起動することがありました。これにより、マルチキャスト DNS 公開サービスがデフォルトの localhost 名で開始されました。今回のバグ修正により、Machine Config Operator はデフォルト以外の名前のみを設定し、それらが利用可能になるまで待機するようになりました。これにより、正しいホスト名がマルチキャスト DNS に公開されます。(BZ#1810333)
  • Ingress 仮想 IP 管理設定は、パスワードに固定の文字列を使用していました。別個のクラスターの 2 つの VRRP keepalived インスタンスが同じ仮想ルーター ID を持つ場合、それらのインスタンスは同じパスワードを持ち、それらは単一の仮想ルーターに属する可能性がありました。今回のバグ修正により、クラスターの設定に応じてパスワードが変更されるようになりました。その結果、異なるクラスターの Ingress 仮想 IP が異なるパスワードを持つようになりました。(BZ#1803232)
  • 以前のバージョンでは、コントロールプレーン IP を検出し、Kubelet および CRI-O の設定を実行する systemd サービスは、コントロールプレーン IP を設定する前に実行でき、これにより、nodeip-configuration 'Failed to find suitable node ip' という Kubelet および CRI-O の失敗メッセージが表示されました。システムはインターフェイスにコントロールプレーン IP が設定されるまで再試行するようになりました。(BZ#1819484)
  • 以前のバージョンでは、CoreDNS が /etc/resolv.conf ファイルのサーバー一覧の DNS 要求を転送する際に、ファイルが変更されていると、その変更は CoreDNS Corefile に反映されませんでした。今回の修正により、Coredns-monitor Pod では CoreDNS の転送一覧が /etc/resolv.conf と同期し、サーバーの一覧がファイルに表示されることが検証されています。(BZ#1790819)
  • 以前のバージョンでは、keepalived が使用するインターフェイスがブリッジ接続されている場合、ユーザーがインターフェイスをボンドまたはブリッジに動的に配置することが可能でした。これにより、keepalived が動作を再開できなくなり、仮想 IP 管理が中断する可能性がありました。今回の修正により、モニターインターフェイスが変更され、keepalived を再読み込みするようになり、新しい設定および仮想 IP 管理を読み取り、中断を最小限に抑えて動作するようになりました。(BZ#1751978)
  • 一部のルートには expires フィールドが含まれるため、IPv6 (non_virtual_ip スクリプト) はルートを処理できませんでした。その結果、non_virtual_ip で設定される必要のあるサービスが失敗します。non_virtual_ip スクリプトが更新されています。ルートが解析され、サービスが正しく設定されます。(BZ#1817236

Web コンソール (Administrator パースペクティブ)

  • モニターリングメトリクスクエリーページの Prometheus リンクがないために、コンソールの開始時に無効なモニターリングフラグが設定されました。適切なフラグが設定され、Prometheus モニターリングがメトリクスクエリーページで利用可能になりました。(BZ#1811481)
  • ユーザーがサポートされない namespace へのインストールを試行する場合、ユーザーにとって Operator グループでサポートされるインストールモードが明確ではないため、フォームが送信されませんでした。サポートされる Operator のインストールモードについてアラートが追加されました。アラートは、選択された namespace をインストール Operator で使用できる理由を明確に示します。(BZ#1821407)
  • Machine Health Checks および Machine Config は視覚的に区分けされておらず、ユーザーに混乱が生じさせました。明確化を図るために、分割バーが Machine Health Checks と Machine Config の間に追加されました。(BZ#1817879)
  • 反応コンポーネントのプロパティーがないため、ブラウザーのコンソールにエラーメッセージが表示されます。反応コンポーネントにプロパティーが追加され、エラーメッセージは出されなくなりました。(BZ#1800769)
  • 複数のアラートレシーバーは同じ名前で作成できます。同じ名前の付いたアラートのいずれかが削除されると、すべてが削除されます。Create Receiver フォームで、名前がすでに存在する場合にユーザーにエラーメッセージと共にプロンプトが出され、Create ボタンが無効になります。ユーザーは、同じ名前を持つ 2 つのレシーバーを作成できません。(BZ#1805133)
  • PVC はアルファベット順で並べ替えられていましたが、現在は数値順に並べ替えられます。(BZ#1806875)
  • サービスはアルファベット順に一覧表示され、oc は最初のオプションではありませんでした。oc オプションが一覧の先頭に追加されるようになりました。(BZ#1802429)
  • アラートが Silenced 状態に変更された後も、Status カードと通知ドロワーはサイレンスにされているアラートを引き続き表示しました。ダッシュボードおよび通知ドロワーにはサイレンスのアラートが表示されなくなりました。(BZ#1802034)
  • アラートが Silenced 状態に変更された後も、Status カードと通知ドロワーはサイレンスにされているアラートを引き続き表示しました。ダッシュボードおよび通知ドロワーにはサイレンスのアラートが表示されなくなりました。(BZ#1808059)
  • ソートは列のデータに基づいておらず、誤ってソートされました。データは正しいオペランドのステータス値でソートされるようになりました。(BZ#1812076)
  • ステータス記述子パスは、Donut チャート内で割り当てられた領域よりも長くなります。非常に長いステータス記述子パスは左右両側でクリッピングされ、値を不明確になる場合がありました。ステータス記述子のパスはドーナツグラフの下に置かれ、これを必要に応じてラップし、1 行に複数のステータス記述子を許可できるようになりました。長い値を持つステータス記述子パスが完全に表示され、ステータス記述子をすべて表示するために必要なスクロールが少なくなります。(BZ#1823870)
  • Web コンソールには、バージョンが更新チャネルに表示されない場合に Error Retrieving の正しくない更新ステータスが表示されました。バージョンが利用可能であると示唆されても、実際には利用できないことがありました。バージョンが更新チャネルに表示されない場合に、Web コンソールに Version not found が表示されるように更新されました。(BZ#1819892)
  • インストールされた Operator の一覧は Name 列でのみソート可能であり、ユーザーのソートオプションを制限します。ユーザーは name 列以外でも一覧をソートできるようになりました。(BZ#1797931)
  • Pod の詳細ページには条件が含まれませんでした。条件がないと、Pod のステータスを把握することが困難でした。Pod の詳細ページに条件セクションが用意され、これにより Pod のステータスをより簡単に判別できるようになりました。(BZ#1804869)
  • クエリーのブラウザーの結果はハードコーディングされたソートでレンダリングされました。ハードコーディングされたソートはクエリーで指定されたソートを上書きし、要求された結果とは異なる結果がレンダリングされる可能性があります。ハードコーディングされたソートが削除され、クエリーに指定されたソートが保持されるようになりました。(BZ#1808394)
  • 以前のバージョンでは、ts-loader が正しくない tsconfig.json を使用するために Web コンソールの特定のページでランタイムエラーが生じることがありました。ts-loader の問題が解決され、すべての Web コンソールページが適切に読み込まれるようになりました。(BZ#1811886)
  • Web コンソールの Developer パースペクティブから Advanced Project Details Inventory セクションに移動する場合、DeploymentConfig オブジェクトは一覧表示されませんでした。DeploymentConfig オブジェクトは追跡され、ダッシュボードの Inventory セクションに含まれるようになりました。(BZ#1825228)
  • 以前のバージョンでは、ユーザー名に # などの特殊文字が含まれる場合に、Web コンソールにユーザーの詳細は表示されませんでした。Web コンソールには、ユーザー名の特殊文字に関係なくユーザーの詳細が表示されるようになりました。(BZ#1835460)
  • 以前のバージョンでは、オブジェクトが YAML エディターで編集されると、必要な metadata フィールドが存在するかどうかを確認できませんでした。オブジェクトが保存される際にフィールドが見つからない場合は、エラーがブラウザーの JavaScript コンソールに記録されましたが、フィードバックは表示されませんでした。必要な metadata フィールドがない場合、Web コンソールには使用可能なエラーメッセージが表示されるようになりました。(BZ#1787503)
  • 以前のバージョンでは、フォームビューを使用してオブジェクトを編集する際に、オブジェクトの YAML エディターに切り替えてもすべての既存データが同期されませんでした。すべてのデータがフォームビューと YAML エディター間で正しく同期されるようになりました。(BZ#1796539)
  • 以前のバージョンでは、Tab キーで移動すると、通知ドロワーがトリガーされ、拡張される可能性がありました。今回のバグ修正により、UI 要素を使用してタブ入力しても通知ドロワーがトリガーされなくなりました。(BZ#1810568)
  • 以前のバージョンでは、カスタムリソース定義 (CRD) の既存のインスタンスを一覧表示する際に、一覧にデータを設定するために正しくない API が使用されていました。正しい API を一覧でデータを設定するために使用できます。(BZ#1819028)
  • Operators Installed Operators ページで、選択した Operator で利用可能なカスタムリソース (CR) 一覧を表示する際に、Version 列に値 Unknown が表示されます。CR にはバージョン情報がないため、このフィールドは UI から削除されました。(BZ#1829052)
  • 以前のバージョンでは、Create Operator Subscription フォームの入力時に、Update Channel フィールドが変更されると、サブスクリプションのターゲット namespace は誤ってリセットされ、フォームは送信されませんでした。Update Channel を調整する際に、ターゲット namespace の値が保持され、フォームが正常に送信されるようになりました。(BZ#1798851)
  • 以前のバージョンでは、メトリクス openshift_console_operator_build_info は適切に公開されませんでした。今回のバグ修正により、メトリクスは Prometheus で利用可能になりました。(BZ#1806787)
  • 以前のバージョンでは、Administration パースペクティブでは、サイドパネルが表示される Workloads タブを表示すると、通知ドロワーが、これを拡張するとサイドパネルの下で非表示になりました。今回のバグ修正により、CSS z-index が調整され、通知ドロワーが表示されるようになりました。(BZ#1813052)
  • 以前のバージョンでは、Web コンソールで OperatorHub はクラスター管理者のみに表示されていました。今回の更新により、Web コンソールで、OperatorHub が aggregate-olm-view および aggregate-olm-edit クラスターロールバインディングが割り当てられたユーザーに表示されるようになりました。(BZ#1819938)
  • 以前のバージョンでは、Web コンソールの Administrator パースペクティブの Home Events ページで、複数のノードイベントについてノード名が表示されませんでした。今回の更新により、すべてのイベントが対応するノードに正しくリンクされるようになりました。(BZ#1809813)
  • 以前のバージョンでは、Web コンソールの Administrator パースペクティブの Home Overview メニュー項目は、namespace を一覧表示できず、クラスターメトリクスを表示するパーミッションを持つユーザーには非表示にされました。今回の更新により、クラスターメトリクスを閲覧する権限を持つすべてのユーザーに対して Overview ナビゲーションアイテムが表示されるようになりました。(BZ#1811757)
  • 以前のバージョンでは、Installed Operators ページの OperatorHub で、インストールされた Operator の追加の API を表示するリンクでは正しいタブが開かれませんでした。今回の更新により、Provided APIs の下にある View x more リンクがインストールされた Operator の Details タグに移動されるようになりました。(BZ#1824254)
  • 以前のバージョンでは、OperatorHub でコンテナーの背景のオーバーフローはモバイルビューで非表示にされませんでした。今回の更新によりグレーの背景が修正され、オーバーフローが非表示になりました。(BZ#1809812)
  • 以前のバージョンでは、fieldDependency specDescriptor が予想通りに機能しませんでした。そのため、Control Field は Dependent Field の可視性を制御しませんでした。Dependent Field の可視性は、Control Field によって正常に有効または無効にされるようになりました。(BZ#1826074)
  • 以前のバージョンでは、デフォルトの CA 証明書がコンソール Pod 内で使用されていました。今回のバグ修正により、設定マップが存在する場合に、コンソールを default-ingress-cert 設定マップを使用するように設定でき、存在しない場合には、コンソールが代わりにデフォルトの CA 証明書を設定するようになりました。これにより、Ingress コントローラーが作成するルートへのアクセスを検証するために、(利用可能な場合は) デフォルトの Ingress 証明書を使用できます。(BZ#1824934)
  • 以前のバージョンでは、新規の Alert Receiver の作成時に、Web コンソールはルーティングラベルが必要であることを示唆しませんでした。ルーティングラベルが必要であることを視覚的に示すインジケーターとして、赤いアスタリスクが追加されました。(BZ#1803614)
  • 以前のバージョンでは、Web コンソールの ClusterRole の詳細ページの Role Bindings タブに、同じ名前を持つ namespace を使用したロールのバインディングが表示されていました。このタブには ClusterRole のバインディングのみが表示されるようになりました。(BZ#1624328)
  • 以前のバージョンでは、OLM Operator のマークダウンテーブルは、コンテンツが多数ある場合に適切にレンダリングされませんでした。Web コンソールは、これらのテーブルの表示を改善し、必要な場合に水平スクロールバーを追加しました。(BZ#1831315)
  • 以前のバージョンでは、Web コンソールですべての PVC をチェックする場合、PVC が属するストレージクラスを区別することは容易ではありませんでした。PVC ストレージクラスの列が Web コンソールに追加されたので、PVC のストレージクラス情報を見つけることがより簡単になりました。(BZ#1800459)
  • 以前のバージョンでは、コンソールの Compute Machine Config Pools Create Machine Config Pool ボタンを使用して新規 MachineConfigPool を作成すると、ノードの一致しない MachineConfigPool が生成されました。これは、一致するノードを選択するために spec.machineSelector キーを使用するテンプレートによって生じました。ただし、このキーは API によって認識されません。ノードを選択する正しいキーは spec.nodeSelector です。ノードを選択するためのキーは更新され、Web コンソールに適切なノードに一致する Machine Selector が表示されるようになりました。(BZ#1813369)
  • 以前のバージョンでは、CLI ダウンロードがアルファベット順で一覧表示されるため、oc は CLI ダウンロードページで最初に一覧表示されませんでした。oc は OpenShift Container Platform の主な CLI であるため、これは CLI ダウンロードページの上部に一覧表示されるようになりました。(BZ#1824934)
  • 以前のバージョンでは、Explorer ビューで、Access Review タブがこれらのタブを表示するパーミッションを持たないユーザーに表示されていました。この許可のないユーザーにはエラーメッセージとタブの祭よ見込みを試行する指示が表示されましたが、再試行しても結果は変わりませんでした。今回のリリースにより、Access Review タブは、タブの内容を表示するパーミッションを持たないユーザーに表示されなくなりました。(BZ#1786251)
  • 以前のリリースでは、Cluster Utilization カードビューと上位コンシューマーのポップオーバービューのメモリー消費データはメモリー使用量の計算に異なる方法を使用していたため、これらのデータに一貫性がありませんでした。今回のリリースにより、2 つのビューが同じ方法を使用してメモリー使用量を計算するため、それらが提供するデータに一貫性があります。(BZ#1812096)
  • 以前のバージョンでは、ユーザーは単一のアラートレシーバーに 2 つのルーティングラベルを作成できました。2 つのルーティングラベルが同じキーを持つ場合、一覧ページには最も新しく作成されたラベルのみが表示されました。ただし、ルーティングラベルの 1 つが正規表現を使用している場合、Details ページでは、これらが 2 つの異なるルーティングラベルとして区別されます。今回のリリースにより、ユーザーは単一のアラートレシーバーに 2 つのルーティングラベルを作成できなくなりました。(BZ#1804049)
  • 今回のリリースにより、Web コンソールが使用するライブラリーが更新され、一部のビューのパフォーマンスおよび表示に関連する問題が解決されました。(BZ#1796658)
  • マストヘッドの選択リンクには、ターゲット宛先が含まれる OnClick ハンドラーと共に href の値 # が含まれました。そのため、それらのリンクには新規タブで開くオプションがありますが、# は意図されるターゲット宛先ではなく、ダッシュボードに対して解決されます。今回のリリースより、# の href のあるリンクがボタン要素に対して更新され、Open Link In New Tab オプションが利用できなくなりました。Open Link In New Tab オプションを持つリンクには、正しい URL が表示されます。(BZ#1703757)

モニターリング

  • 以前のバージョンでは、Prometheus PVC 名に関連するメタデータを誤って処理すると、バージョン 4.4.0-4.4.8 間のアップグレードが失敗する可能性がありました。メトリクスデータを保持し、アップグレードを完了できるように、データが古い物理ボリュームから新しい物理ボリュームにコピーされるようになりました。(BZ#1832124)
  • 以前のバージョンでは、Thanos Querier はマスターノードとワーカーノードの両方でスケジュールできましたが、これはワーカーノードでのみスケジュールされることが意図されていました。Thanos Querier のマスターノードでのスケジュールを許可する容認が削除され、Thanos Querier はワーカーノードのみにデプロイされるようになりました。(BZ#1812834)
  • 以前のバージョンでは、Prometheus 記録ルールの評価は失敗することがあり、ルールから生成されるメトリクスがなくなることがありました。記録ルールは修正されました。(BZ#1802941)
  • 以前のバージョンでは、データの統計的スムーズ化により、CPU の使用率で正しくない結果が表示されました。CPU の使用量を計算する方法が更新され、oc adm top の結果が Linux top ユーティリティーと同様になります。(BZ#1812004)
  • 以前のバージョンでは、cluster-monitoring-config マップは無効であり、クラスターモニターリング Operator はデフォルト設定を使用するようデフォルト設定されるため、クラスターモニターリングへののカスタム設定が失われました。クラスターモニターリング Operator が cluster-monitoring-config 設定マップをデコードできない場合、デフォルト設定を使用せず、代わりにアラート警告が出されるようになりました。(BZ#1807430)

ネットワーク

  • Kube-proxy メトリクス実装への変更により、一部のメトリクスは Kubernetes 1.17 のリベース時に非表示になりました。今回のバグ修正により、メトリクスが SDN で公開される方法が変更され、それらが非表示にされなくなりました。(BZ#1811739)
  • 以前のバージョンでは、インストーラーで machineNetwork が導入されると、Cluster Network Operator はこれを proxy.status.noProxy に追加するように変更されませんでした。今回のバグ修正により、proxy.status.noProxy は machineNetwork を含む予想されるフィールドを含むように設定されました。(BZ#1797894)
  • 以前のバージョンでは、ノードは自己 IP を誤って検出し、これにより割り当てられた egress IP を所有することができませんでした。今回のバグ修正により、Kubernetes API からノード IP が割り当てられるようになりました。(BZ#1802557)
  • コードの変更により、サードパーティーのプラグインのステータスの設定が意図せず停止しました。つまり、Cluster Network Operator のステータスでこれが機能していると示唆されることはありませんでした。今回のバグ修正により、サードパーティーのプラグインが使用されている場合にステータスを設定するコードが追加されました。サードパーティープラグインが使用されている場合に Cluster Network Operator がステータスを正しく報告するようになりました。(BZ#1807611)
  • 以前のバージョンでは、Kuryr ブートストラップの Cluster Network Operator には、非推奨となったセキュリティーグループルールが新規ルールで置き換えられる際に、それらを削除するロジックがありませんでした。OpenShift Container Platform のアップグレードでは、古いセキュリティーグループルールがセキュリティーグループに残されました。つまり、4.3 から 4.4 にアップグレードされた環境では、セキュリティーを強化するための措置は行われませんでした。今回のバグ修正により、Cluster Network Operator は古いセキュリティーグループルールを削除し、セキュリティーグループルールが 4.3 から 4.4 のアップグレードで削除され、Pod がホスト仮想マシンへの制限されたアクセスを正しく取得できるようになりました。(BZ#1832305)
  • 以前のバージョンでは、トラフィックをブロックするネットワークポリシーを実行するために、そのポリシーに一致するサービスには、トラフィックをブロックするこれに対応するロードバランサーが必要でした。Octavia を ACL を使用し、ロードバランサーリスナーで admin 状態を作動してこれを提供しました。そのため、OpenShift Container Platform エンドポイントの Kuryr アノテーションでのセキュリティーグループと Pod に実際に設定されたセキュリティーグループの不一致により、一部のロードバランサーがネットワークポリシーの更新の対象として考慮され、トラフィックが admin 状態が無効にされた状態でブロックされました。今回のバグ修正により、エンドポイントについての Kuryr アノテーションのセキュリティーグループフィールドは、選択された Pod の既存のセキュリティーグループに一致します。ネットワークポリシーがブロックしていない場合には、すべてのロードバランサーリスナーの admin 状態が有効されるようになりました。(BZ#1824258)
  • 以前のバージョンでは、iptables にはロックの問題がありました。Pod が起動に失敗し、oc describe pod コマンドで以下のテキストを含むイベントが表示されることが稀にありました。Failed create pod sandbox …​ could not set up pod iptables rules: Another app is currently holding the xtables lock 今回のバグ修正により、-w はコードの関連する部分で iptables に渡され、iptables はロックを待機し、誤って失敗しなくなりました。(BZ#1810505)
  • 以前のバージョンでは、ノードの削除時にノードの chassis レコードは south-bound データベースから削除されませんでした。古くなった chassis レコードにより、削除されない古い chassis の論理フローが生じました。今回のバグ修正により、ノードの同期メカニズムが ovnkube-master に追加され、削除されたノードの chassis レコードが消去されるようになりました。これで、south-bound データベースの削除されたノードに対応する古くなった chassis レコードまたは論理フローがなくなりました。(BZ#1809747)
  • etcd の実行速度が遅いと、openshift-sdn では競合状態により namespace の作成イベントが失敗する可能性がありました。これにより、その namespace の Pod に接続がなくなる場合がありました。今回のバグ修正により、競合状態が削除されました。その結果、Pod は最終的に接続されるようになります。(BZ#1825355)

ノード

  • 以前のバージョンでは、kubepods.slice メモリー cgroup は最大限度から予約分を差し引いた値に設定されませんでした。これにより、ノードがメモリー不足のエラーでオーバーロードし、ワークロードをエビクトできませんでした。kubepods.slice メモリー予約が適切に設定されるようになりました。(BZ#1800319)
  • 以前のバージョンでは、デバイスのデバイスマッパーにはメトリクスがないため、システムがルートデバイスのデバイスマッパーを使用している場合にメトリクスを利用できませんでした。cadvisor は修正され、デバイスマッパーがルートデバイスに使用されるかどうかにかかわらず、メトリクスが利用可能になりました。(BZ#1849269)

Node Tuning Operator

  • Node Tuning Operator には、BZ#1702724 および BZ#1774645 に関連する tuned デーモンの動作に対応する修正が同梱されていませんでした。そのため、ユーザーによって無効なプロファイルが指定されると、オペランドの機能のサービス拒否 (Denial of Service、DoS) が発生しました。また、プロファイルを訂正してもオペランドの機能は復元されませんでした。これは、前述のバグ修正を適用することで修正され、tuned デーモンが修正された新規プロファイルを処理し、設定できるようになりました。(BZ#1823941)
  • 以前のバージョンでは、チューニングされた Pod はホストから /etc/sysctl.{conf,d/} をマウントしませんでした。これにより、ホストが提供する設定が tuned プロファイルでオーバーライドされることが可能になりました。/etc/sysctl.{conf,d/} がチューニングされる Pod のホストからマウントされるようになり、これにより、tuned プロファイルが /etc/sysctl.{conf,d/} のホスト sysctl 設定をオーバーライドしなくなりました。(BZ#1825322)

oc

  • 以前のバージョンでは、プリンターフラグが適切に接続されず、oc adm group sync コマンドには出力オプションがありませんでした。フラグが正しく接続されるようになり、すべての出力オプションが正しく機能するようになりました。(BZ#1828194)
  • 以前のバージョンでは、結果をフォーマットする関数にはハードコーディングされたサイズが設定され、配列がハードコーディングされた制限よりも少ない値で一杯になるとパニックが生じました。LDAP エントリーの数は、実際の配列の容量に基づいて制限され、関数がその結果が正しくフォーマットするようになりました。(BZ#1806876)
  • 以前のバージョンでは、oc image mirror コマンドは、--dir オプションを上書きするはずの場合でも、--from-dir オプションのみが指定される場合にエラーを出しました。--from-dir が --dir を適切に上書きし、コマンドが正常に実行されるようになりました。(BZ#1807807)
  • 以前のバージョンでは、oc adm release コマンドのヘルプの例が正しく表示されませんでした。それらは更新され、適切に表示されるようになりました。(BZ#1810310)

OLM

  • Operator Lifecycle Manager (OLM) によってインストールされたカスタムリソースには、適用元の InstallPlan オブジェクトに OwnerReference オブジェクトが付与されます。InstallPlan オブジェクトを削除すると、適用されたカスタムリソースが削除されます。今回のバグ修正により、OLM がカスタムリソースの OwnerReference オブジェクトをインストールに使用された CSV を参照するように更新されました。これにより、InstallPlan を削除しても、適用されたカスタムリソースは削除されなくなりました。(BZ#1808113)
  • 以前のバージョンでは、ガベージコレクションのリソースイベントキューが正しく設定されませんでした。そのため、Operator のアンインストール時に Operator Lifecycle Manager (OLM) によって管理される Operator 用に生成されるクラスタースコープのリソースがクリーンアップされませんでした。今回のバグ修正により、OLM が更新され、ガベージコレクションのキューが任意の namespace を参照する所有者ラベルについてヒットされるように再設定されました。その結果、OLM によって管理される Operator 用に生成されるクラスタースコープのリソースが Operator のアンインストール時に適切にクリーンアップされるようになりました。(BZ#1834136)

  • グループ (group)、バージョン (version)、および種類 (kind) (GVK) が直前のバージョンの Operator 以降変更されていない必須の API を提供する Operator がアップグレードされており、API に依存する Operator が spec.Replaces の代わりに skipRange を使用する場合、Operator Lifecycle Manager (OLM) は正しい replaces フィールドでアップグレードされた CSV を生成できません。具体的には、OLM は以下を実行します。

    1. 新規 Operator を生成に追加し、これが提供する API に present のマークを付けます。
    2. 生成から古い Operator を削除し、(新規バージョンの Operator で提供されている場合でも) これが提供する API に absent のマークを付けます。

    3. 欠落している API の解決を試行し、新規バージョンの Operator を spec.Replaces フィールドが設定されていないコピーで上書きします。

      これにより、特定の Operator の新規バージョンへのアップグレードが失敗しました。今回のバグ修正により OLM が更新され、新規 Operator を生成に追加する前に古い Operator が現行の生成から削除されるようになりました。その結果、アップグレードは予想通りに成功します。(BZ#1818788)

  • 無効な CatalogSource 設定により、nil-pointer の例外およびパニックが発生していました。catalog-operator Pod は、無効な CatalogSource オブジェクトが調整されるたびにクラッシュしていました。今回のバグ修正により、ランタイムの nil チェックおよび CatalogSource オブジェクトの検証が追加されました。その結果、無効な CatalogSource オブジェクトに代表的な条件が指定され、catalog-operator Pod がクラッシュしなくなりました。(BZ#1817833)
  • Operator Lifecycle Manager (OLM) を使用すると、ユーザーは Subscription オブジェクトの subscriptionConfig フィールドを使用してボリュームおよび volumeMount を指定できます。この機能を使用することで、ClusterServiceVersion リソース (CSV) に定義される Deployment リソースを更新できます。OLM ではそのキャッシュに CSV 用の Subscription オブジェクトが作成されず、CSV は、 Subscription オブジェクトにボリュームまたはボリュームマウントが定義された Deployment リソースを作成せずに installing phase (インストールフェーズ) に置かれることがありました。その後 OLM は、計算された Deployment リソースのハッシュが Deployment リソースの実際の Deployment ハッシュと一致しないため、CSV を Succeeded phase (成功フェーズ) に移動できませんでした。このエラーは、OLM が installing phase (インストールフェーズ) で Deployment リソースを更新したり、再作成したりしないために解決されず、このエラーは OLM が CSV を再同期してから 5 分が経過するまで残りました。その結果、OLM は CSV のインストール時に遅延することがありました。今回のバグ修正により、OLM が CSV のインストール時に Deployment リソースのハッシュエラーが生じると、OLM が Deployment リソースを再作成します。その結果、OLM が誤った Deployment リソースのハッシュにより遅延しなくなりました。(BZ#1826443)
  • 以前のバージョンでは、Operator Lifecycle Manager (OLM) は単一の Deployment リソースで複数の APIService リソースの実行を想定せず、OLM によって作成された最後の APIService リソースに関連付けられた CA のみをマウントしていました。これにより、OLM は単一の Deployment リソースで複数の APIService リソースを実行できませんでした。今回のバグ修正により、OLM が単一 Deployment リソース上のすべての APIService リソースに同じ CA を使用できるように更新されました。その結果、OLM は単一 Deployment リソースで複数の APIService リソースを実行できるようになりました。(BZ#1805412)
  • 以前のバージョンでは、Operator Lifecycle Manager (OLM) は、設定スキーマの導入時に v1alpha2 バージョンの OperatorGroup カスタムリース定義 (CRD) を正しく非推奨にしませんでした。このため、v1alpha2 OperatorGroup CRD はサポートされなくなり、それらを作成できませんでした。今回のバグ修正により v1alpha2 OperatorGroup CRD が再導入され、その結果として OLM は v1alpha2 OperatorGroup CRD を再度サポートするようになりました。(BZ#1798051)
  • 以前に解決された InstallPlan オブジェクトに同等のマニフェストのセットが含まれなくなると、新たに確定的でない方法で解決された依存関係のセットの適用がトリガーされました。複数の有効な Operator の依存関係のセットが存在する場合、同等の異なる解決が既存のセットに適用されることがありました。今回のバグ修正により、generation フィールドが InstallPlan オブジェクト API のステータスに追加され、解決されるたびに増分し、最新のステータスの生成により InstallPlan オブジェクトのみが適用されるようになりました。その結果、所定の時間に Operator の依存関係の 1 つのセットのみがクラスターに存在することになります。(BZ#1784024)
  • OperatorHub タイプの定義には、Kubernetes クライアントの生成に必要な追加の +genclient マーカーのコメントがありませんでした。そのため、生成されたクライアントが openshift/client-go 設定クライアントでは利用できませんでした。今回のバグ修正により、欠落していた +genclient マーカーのコメントが OperatorHub 設定タイプに追加され、結果として生成されるクライアントが予想通りに利用可能な状態になりました。(BZ#1816483)

openshift-apiserver

  • 以前のバージョンでは、アップグレード時に OpenShift API サーバーがクライアントで利用できなくなり、失敗が発生していました。OpenShift API サーバーは、アップグレード時も引き続きクライアントで利用可能になりました。(BZ#1791162)

openshift-controller-manager

  • 以前のバージョンでは、OpenShift Container Platform 内部レジストリーのプルシークレットの作成に使用されるクライアントには低いレート制限が設定されていました。多数の namespace が短時間に作成された場合には、イメージレジストリーのプルシークレットが作成されるまでに時間がかかりました。クライアントのレート制限が引き上げられたため、内部レジストリーのプルシークレットはトラフィック量が多い場合でも迅速に作成されるようになりました。(BZ#1785023)
  • 以前のバージョンでは、workqueue_depth などのメトリクスは Prometheus メトリクスで利用不可能でした。今回のバグ修正により、欠落していたメトリクスが利用可能になりました。(BZ#1825324)
  • openshift-controller-manager Pod が失敗しても、終了メッセージは出されませんでした。Pod が終了すると、終了メッセージが表示されるようになりました。(BZ#1804432)
  • 以前のバージョンでは、メトリクスは OpenShift Container Platform コントロールプレーンについて適切に登録されませんでした。今回のバグ修正により、コントロールプレーンのメトリクスが利用可能になりました。(BZ#1809699)
  • 以前のバージョンでは、関連付けられたトークンが削除されると、内部レジストリーのプルシークレットが孤立した状態になりました。今回のバグ修正により、プルシークレットとトークン間に参照が作成され、関連付けられたトークンが削除されてもプルシークレットが孤立しなくなりました。(BZ#1765294)
  • 以前のバージョンでは、OpenShift Container Platform がグローバルプロキシーで設定されている場合、プロキシーは外部イメージレジストリーへの接続時に使用されませんでした。外部レジストリーからイメージをプルする際に、OpenShift Container Platform はクラスター全体のプロキシー設定を使用するようになりました。(BZ#1805168)
  • 以前のリリースでは、デプロイメントのローリング更新時に、コントローラーが長時間使用できなくなる可能性がありました。今回のバグ修正により、デプロイメントの Pod の終了時に、コントローラーがリースをプロアクティブにリリースできるようにすることで遅延が最小限に抑えられます。(BZ#1809719)
  • 以前のバージョンでは、openshift-controller-manager-operator は、昇格した SELinux 権限へのアクセスを使用して実行される可能性がありました。今回のバグ修正により、適切な SCC (Security Context Constraints) が適用されるようになりました。(BZ#1806913)
  • 以前のバージョンでは、アップグレード時に openshift-controller-manager は Operator がアップグレードされ、利用可能であることを誤って報告していました。Operator が正常に更新されると、Operator はこれを正常に報告するようになりました。(BZ#1804434)
  • インストールまたはアップグレード時に、openshift-controller-manager は進捗の状態を適切に報告しませんでした。その結果、インストールまたはアップグレードが失敗する可能性があります。Operator はインストールまたはアップグレードが正常に実行されると、その進捗を正しく報告するようになりました。(BZ#1814446)
  • 以前のバージョンでは、image-resolve-plugin は、alpha.image.policy.openshift.io/resolve-names アノテーションがリソースの作成後に追加された場合にイメージを解決しませんでした。image-resolve-plugin は修正され、 alpha.image.policy.openshift.io/resolve-names アノテーションがリソースの作成後に追加されてもイメージを解決するようになりました。(BZ#1805155)
  • 以前のバージョンでは、IPv6 クラスターを使用する場合に、コントローラーマネージャー Operator はそのメトリクスを公開しませんでした。そのため、メトリクスが適切に収集されず、これにより、ユーザーにはパフォーマンスデータをグラフ化したり、クエリーする方法がありませんでした。コントローラーマネージャー Operator は IPv6 インターフェイスに適切にバインドされ、メトリクスは適切に収集され、ユーザーに表示されるようになりました。(BZ#1813233)

ルーティング

  • 以前のバージョンでは、サービ出力ドバランサーに Azure マスターノードを含めることができませんでした。このため、ワーカーノードがマスターノードでもあるコンパクトなクラスターで Ingress の機能が中断しました。Azure は、ノードのネットワークインターフェイスカード (NIC) を単一ロードバランサーに関連付けることを常に許可します。今回の更新により、インストーラーは LoadBalancer タイプの API とサービスの両方に使用される統一されたロードバランサーとネットワークセキュリティーグループを作成するように変更されました。サービ出力ドバランサーには Azure のマスターノードを含めることができ、Ingress はコンパクトなクラスターでも機能するようになりました。(BZ#1794839)
  • 以前のバージョンでは、openshift-router はシークレットが無効な場合に、デフォルトの証明書シークレットコンテンツの監視を設定しませんでした。起動時に、openshift-router は、ルーター Pod が起動するために必要なシークレットが無効な場合、そのシークレットの読み取りに失敗しました。そのため、ユーザーは無効なシークレットを更新し、現在のルーター Pod を削除する必要がありました。今回の更新により、ルーターは、ルーター Pod を削除せずにデフォルトの証明書シークレットの変更の有無を監視するようになりました。シークレットが無効な場合、ルーターはデフォルトのルーター証明書を使用し、これを提供します。シークレットが有効である場合、ルーターはそのシークレットからデフォルトの証明書を提供します。(BZ#1820400)
  • 以前のバージョンでは、AWS China リージョンで実行される場合に Ingress Operator は DNS の設定に失敗しました。今回の更新により、Ingress Operator は AWS China リージョンで実行されるタイミングを検出し、Route 53 API エンドポイントで DNS を設定できるようになりました。(BZ#1805224)
  • 以前のバージョンでは、Ingress Operator は Azure および Google Cloud Provider (GCP) で管理される DNS レコードに対する upsert 操作を継続的に実行しました。今回の更新により、Ingress Operator は、レコードがすでに公開されており、コントローラーがレコードに対して最後に upsert 操作を実行してからレコードや DNS ゾーン設定が変更されていない場合に、DNS レコードに対する upsert 操作を防ぎます。Ingress Operator によるクラウドプロバイダー API への呼び出し回数が減り、これにより openshift-ingress namespace での クラウドプロバイダーのレート制限 イベントの発生を防ぐことができる可能性があります。さらに、Ingress Operator ログには upserted DNS record ログメッセージの数が少なくなります。(BZ#1809354)
  • 以前のバージョンでは、ingress-to-route コントローラーは、Kubernetes 1.18 で非推奨となった extensions/v1beta1 API グループからの ingresses リソースを使用していました。今回の更新により、ingress-to-route コントローラーは networking.k8s.io/v1beta1 API グループからの ingresses リソースを使用するようになりました。(BZ#1801415)
  • 以前のバージョンでは、ルーターは、競合するルートが検出されると、アクティブではないルートをプロモートしませんでした。ルートが検出されると、ルーターはすべての非アクティブなルートを再処理し、削除されたルートと競合しなくなったルートをアクティブにするようになりました。(BZ#1821095)
  • 以前のバージョンでは、タイプ LoadBalancer のサービスまたは LoadBalancerService エンドポイント公開ストラテジータイプの Ingress コントローラーが削除されると、サービスはそのまま存在し、pending 状態になりました。サービスコントローラーは OpenShift Container Platform 3.10 で変更され、LoadBalancer 以外のサービスが作成または削除される際に不要な GetLoadBalancer クラウドプロバイダー API 呼び出しを防ぐように変更されました。Kubernetes 1.15 の後続の変更により、これらの不要な API 呼び出しは別の方法で不可能にされました。その結果、これらの 2 つの変更の相互作用により、タイプ LoadBalancer のサービスについてのサービスコントローラーのクリーンアップロジックに障害が生じました。今回の更新により、OpenShift Container Platform 3.10 で追加された変更が削除されました。LoadBalancer タイプのサービスおよび LoadBalancerService タイプの Ingress コントローラーを削除できるようになりました。(BZ#1798282)
  • 以前のバージョンでは、エンドポイント公開ストラテジーにロードバランサーの管理が含まれていない場合に、Ingress Operator によって不明確な LoadBalancerManager の状況条件の理由が設定されました。IngressController リソース が LoadBalancerService 以外のエンドポイント公開ストラテジータイプを使用するように設定される場合、Ingress Operator は Ingress コントローラーのロードバランサーを管理しません。今回の更新により、LoadBalancerManager の状況条件には、Operator が Ingress コントローラーのロードバランサーを管理しない理由がより明確に示されるようになりました。メッセージには、unsupported または does not support などのフレーズが使用されなくなりました。(BZ#1826113)
  • 以前のバージョンでは、標準以外の proto-version パラメーターを持つ Forwarded HTTP ヘッダーは、Ingress コントローラーが HTTP 要求をアプリケーションに転送する際に追加されました。そのため、Forwarded ヘッダーは標準に準拠しておらず、アプリケーションがヘッダー値を解析しようとする際に問題が生じる可能性がありました。今回の更新により、Forwarded ヘッダーが標準に準拠し、Ingress コントローラーは Forwarded ヘッダーに proto-version パラメーターを指定しなくなりました。(BZ#1803001)
  • 以前のバージョンでは、アクティブなセッション数を表示する Prometheus カウンターはルーターの再起動後も保持され、無限に増加していました。今回の更新により、haproxy_frontend_current_session および haproxy_server_current_session はアクティブなセッション数を正確に示すようになりました。このカウンターの値は、ルーターの再起動時にリセットされるようになりました。(BZ#1832539)
  • ルート経由で公開されるサービスのバッキング Pod が利用不可である場合 (クラッシュループ、削除などによる)、ルーターは 503 エラーを出して応答します。以前のリリースでは、そのルートの haproxy_server_http_responses_total メトリクスは利用可能でなくなっていたため、そのルートでのモニターリングは実行できませんでした。今回の更新により、すべてのバックエンドメトリクスが報告され、ユーザーは Pod が起動しないタイミングを追跡できるようになりました。(BZ#1835845)

サンプル

  • 以前のバージョンの Samples Operator はサンプルコンテンツが s390x および ppc64le アーキテクチャーで利用可能にされていない場合でも、それらのアーキテクチャーで削除されず、ブートストラップが正常に実行されませんでした。これにより、サンプルコンテンツが実際には利用可能ではないのにこれがあることが予想されたため、s390x および ppc64le アーキテクチャーでのクラスターのアップグレードが失敗しました。Samples Operator に必要なサンプルコンテンツが含まれていない場合でも、そのアップグレードが強制的に実行されるようになりました。これにより、s390x および ppc64le アーキテクチャーで利用できないサンプルコンテンツによって生じるクラスターのアップグレードの障害が修正されました。(BZ#1835112)
  • 以前のバージョンの OpenShift Container Platform リリースで利用可能なイメージストリームのサンプルが後続のリリースで削除された場合、その後続のリリースへのアップグレード時に、削除されたイメージストリームが完了までにイメージストリームのインポートが必要であるとして誤って追跡される可能性がありました。しかし、イメージストリームのインポートは発生しないため、サンプルはアップグレードを完了済みとして報告しませんでした。これにより、クラスターのアップグレードが失敗しました。Samples Operator は、アップグレードが予定されるリリースではなく、以前のリリースに存在するイメージストリームの追跡を無視できるように更新されました。イメージストリームはリリース間で削除されるようになり、アップグレード時に Samples Operator が失敗しなくなりました。(BZ#1811143)
  • 以前のバージョンでは、Samples Operator は削除済みとしてブートストラップされる際に、無効な設定や欠落しているイメージプルシークレットについてのアラートを送信していました。これにより、無効な設定および欠落しているイメージプルシークレットについての誤解を生じさせるアラートがユーザーに送信されました。Samples Operator が削除されている場合、これによってこれらのアラートが送信されるはずがないためです。Samples Operator は、それが削除済みの状態でブートストラップが実行される際にサンプルのインポートに関連するアラートを送信しないように更新されました。(BZ#1813175)
  • 以前のバージョンでは、以前のリリースで利用可能であり、その後のリリースで削除されたテンプレートのサンプルには、needing updates (要更新) というマークが付けられる場合がありました。テンプレートの更新を試みると、さまざまなエラーと失敗ステータスが出されました。これらのテンプレートは、削除後に更新を受信しないように更新されました。そのため、削除されたサンプルテンプレートはエラーや障害を生成しません。(BZ#1828065)

ストレージ

  • 以前のバージョンでは、ボリュームは、適切なアベイラビリティーゾーンのサポートなしに作成された特定の Azure リージョンでのプロビジョニングに失敗する可能性がありました。今回の修正により、すべての Azure リージョンでボリュームのプロビジョニングを有効にするために、アベイラビリティーゾーンのサポートがプロビジョニング時に検出されるようになりました。(BZ#1828174)
  • 以前のバージョンでは、namespace は VolumeSnapshotClass が関連付けられた VolumeSnapshot リソースの前に削除される場合に Terminating のままになり、VolumeSnapshot オブジェクトはクラスターに残りました。この場合、関連付けられたリソースを削除することができなくなるためです。今回の修正により、VolumeSnapshot 機能は、関連する VolumeSnapshotClass リソースがすでに削除されているかどうかを検査するようになり、対応する VolumeSnapshotClass が存在しない場合も VolumeSnapshot リソースが正常に削除されるようになりました。(BZ#1808123)
  • 以前のバージョンでは、VolumeSnapshotContents リソースが nil の場合に CSI スナップショットコントローラーがクラッシュする可能性がありました。システムは、VolumeSnapshotContent リソースの使用前にこれが nil であるかどうかを確認します。(BZ#1814280)
  • 以前のバージョンでは、ローカルストレージ Operator をアップグレードする際に、LocalVolume リソースも変更されない限り、関連付けられたディスクメーカーおよびプロビジョナー Pod はどちらも古くなっている可能性があります。今回の修正により、デーモンセットのハッシュがアノテーションに含まれるようになりました。ハッシュが一致しない場合、Pod はデプロイされ、ローカルストレージ Operator の更新時にディスクメーカーおよびプロビジョナー Pod が正常に更新されるようになりました。(BZ#1822213)
  • 以前のバージョンでは、oc get volumesnapshot はリソースの名前および作成時間のみを表示し、ステータスは表示されませんでした。今回の修正により、oc get volumesnapshot には、関連付けられた VolumeSnapshotContent リソース、 VolumeSnapshot リソースソース、その他関連情報などの追加の詳細情報が含まれるようになりました。(BZ#1800437)
  • 以前のバージョンでは、oc get volumesnapshotclass はリソースの名前および作成時間のみを表示し、削除ポリシーまたはドライバー情報を表示しませんでした。今回の修正により、oc get volumesnapshotclass に、関連付けられた CSI ドライバーおよび削除ポリシーなどの追加の詳細情報が含まれるようになりました。(BZ#1800470)
  • 以前のバージョンでは、oc get volumesnapshotcontent はリソースの名前および作成時間のみを表示し、追加の詳細情報を表示しませんでした。今回の修正により、 oc get volumesnapshotcontent には、関連付けられた VolumeSnapshot リソース、VolumeSnapshotClass リソース、その他関連情報などの追加の詳細情報が含まれるようになりました。(BZ#1800477)
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.