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

リリースノート

OpenShift Container Platform 4.6

新機能のハイライトおよび OpenShift Container Platform リリースの変更内容

概要

以下の OpenShift Container Platform リリースノートでは、新機能および拡張機能のすべて、以前のバージョンからの主な技術上の変更点、主な修正、および一般公開バージョンの既知の問題についてまとめています。

第1章 OpenShift Container Platform 4.6 リリースノート

Red Hat OpenShift Container Platform では、設定や管理のオーバーヘッドを最小限に抑えながら、セキュアでスケーラブルなリソースに新規および既存のアプリケーションをデプロイするハイブリッドクラウドアプリケーションプラットフォームを開発者や IT 組織に提供します。OpenShift Container Platform は、Java、Javascript、Python、Ruby および PHP など、幅広いプログラミング言語およびフレームワークをサポートしています。

Red Hat Enterprise Linux および Kubernetes にビルドされる OpenShift Container Platform は、エンタープライズレベルの最新アプリケーションに対してよりセキュアでスケーラブルなマルチテナント対応のオペレーティングシステムを提供するだけでなく、統合アプリケーションランタイムやライブラリーを提供します。OpenShift Container Platform を使用することで、組織はセキュリティー、プライバシー、コンプライアンス、ガバナンスの各種の要件を満たすことができます。

1.1. 本リリースについて

Red Hat OpenShift Container Platform (RHBA-2020:4196) をご利用いただけるようになりました。本リリースでは、CRI-O ランタイムで Kubernetes 1.19 を使用します。以下では、OpenShift Container Platform 4.6 に関連する新機能、変更点および既知の問題について説明します。

Red Hat は OpenShift Container Platform 4.6.0 を GA バージョンとしてリリースせず、OpenShift Container Platform 4.6.1 を GA バージョンとしてリリースしています。

OpenShift Container Platform 4.6 クラスターは https://console.redhat.com/openshift で入手できます。OpenShift Container Platform 向けの Red Hat OpenShift Cluster Manager アプリケーションを使って、OpenShift クラスターをオンプレミスまたはクラウド環境のいずれかにデプロイすることができます。

OpenShift Container Platform 4.6 は、Red Hat Enterprise Linux 7.9 以降、および Red Hat Enterprise Linux CoreOS (RHCOS) 4.6 でサポートされます。

コントロールプレーン (マスターマシンとしても知られている) には RHCOS を使用する必要があり、コンピュートマシン (ワーカーマシンとしても知られている) には RHCOS または Red Hat Enterprise Linux 7.9 以降のいずれかを使用できます。

重要

コンピュートマシン用にサポートされているのは Red Hat Enterprise Linux バージョン 7.9 以降であるため、Red Hat Enterprise Linux コンピュートマシンをバージョン 8 にアップグレードすることはできません。

OpenShift Container Platform 4.6 は Extended Update Support (EUS) リリースです。Red Hat OpenShift EUS の詳細は、OpenShift ライフサイクル、および OpenShift EUS の概要 を参照してください。

OpenShift Container Platform 4.6 のリリースでは、バージョン 4.3 のライフサイクルは終了します。詳細は、Red Hat OpenShift Container Platform ライフサイクルポリシー を参照してください。

1.2. 新機能および機能拡張

今回のリリースでは、以下のコンポーネントおよび概念に関連する拡張機能が追加されました。

1.2.1. Red Hat Enterprise Linux CoreOS (RHCOS)

1.2.1.1. RHCOS PXE および ISO のライブ環境

RHCOS で利用可能な PXE メディアおよび ISO が完全にライブ環境になりました。ユーザーによってプロビジョニングされるインフラストラクチャーでの OpenShift Container Platform クラスターの RHCOS インストールに使用される以前の専用の PXE メディアおよび ISO とは異なり、RHCOS ライブ環境は Ignition で設定でき、これには coreos-installer、nmcli、および podman などのメイン RHCOS イメージと同じパッケージがすべて含まれます。これにより、インストール前またはインストール後ワークフローの任意のスクリプト作成が可能になります。たとえば、coreos-installer を実行し、プロビジョニングサーバーに成功のシグナルを送るための HTTP 要求を行うことができます。PXE ブートは通常の ignition.config.url を使用します。ISO は以下のコマンドを使用して Ignition で設定できます。 

$ coreos-installer iso ignition embed
1.2.1.2. coreos-installer が書き換えられる

coreos-installer が書き換えられ、以下をはじめとるすより多くの機能に対応するようになりました。

  • インストール済みシステムのカーネル引数の変更
  • Ignition 設定の取得。
  • 既存のパーティションの維持。
  • coreos-installer iso ignition コマンドの使用による新規ライブ ISO の Ignition の設定。
1.2.1.3. RHCOS が RHEL 8.2 を使用するようになる

RHCOS は、OpenShift Container Platform 4.6 で Red Hat Enterprise Linux (RHEL) 8.2 パッケージを使用するようになりました。これらのパッケージは、ハードウェアサポートとドライバーの更新だけでなく、修正、機能、拡張機能を提供します。

1.2.1.4. Ignition 仕様が v3 に更新

RHCOS は Ignition 仕様 v3 をサポートされる唯一の Ignition の仕様バージョンとして使用するようになりました。これにより、今後はより複雑なディスク設定のサポートが可能になります。

この変更は、インストーラーでプロビジョニングされるインフラストラクチャーを使用する場合にほぼ透過的に行われます。ユーザーによってプロビジョニングされるインフラストラクチャーのインストールの場合は、Ignition 仕様 3 を使用するようにカスタム Ignition 設定を調整する必要があります。openshift-install プログラムが Ignition 仕様 3 を生成するようになりました。

Ignition スニペットを使用する Day 1 または day 2 操作用にマシン設定を作成する場合、Ignition 仕様 v3 を使用してそれらを作成する必要があります。ただし、Machine Config Operator (MCO) は依然として Ignition 仕様 v2 をサポートします。

1.2.1.5. 既存クラスターにノードを追加する追加の手順

OpenShift Container Platform 4.6 にアップグレードされたクラスターの場合は、OpenShift Container Platform クラスターにノードを追加できます。これらの手順は、最初に OpenShift Container Platform 4.6 より前のクラスターをインストールし、その後 4.6 にアップグレードした場合にのみ適用されます。

ユーザーがプロビジョニングしたクラスターをベアメタルまたは vSphere にインストールした場合は、ブートメディアまたは OVA イメージが、クラスターがアップグレードされたバージョンと一致していることを確認する必要があります。さらに、仕様 v3 と互換性があるように、Ignition 設定ファイルを変更する必要があります。詳細な手順と Ignition 設定ファイルの例については、ナレッジベースソリューションの Adding new nodes to UPI cluster fails after upgrading to OpenShift 4.6+ を参照してください。

1.2.1.6. RHCOS および MCO でサポートされる拡張機能

RHCOS および MCO がデフォルトの RHCOS インストールに対して以下の拡張機能をサポートするようになりました。

  • kernel-devel
  • usbguard
1.2.1.7. 4kN ディスクのサポート

RHCOS は、4K セクターサイズを使用するディスクへのインストールをサポートするようになりました。

1.2.1.8. /var パーティションのサポート

RHCOS は、/var を別のパーティションとしてサポートし、/var の他のサブディレクトリーをサポートするようになりました。

1.2.1.9. OVA を使用した vSphere の静的 IP 設定

vSphere でデフォルトの Dynamic Host Configuration Protocol (DHCP) ネットワークをオーバーライドできるようになりました。これには、vSphere で OVA から仮想マシンを起動する前に、静的 IP 設定を行ってから guestinfo プロパティーを設定する必要があります。

  1. 静的 IP を設定します。 

    $ export IPCFG="ip=<ip>::<gateway>:<netmask>:<hostname>:<iface>:none nameserver=srv1 [nameserver=srv2 [nameserver=srv3 [...]]]"

    コマンドの例

    $ export IPCFG="ip=192.168.100.101::192.168.100.254:255.255.255.0:::none nameserver=8.8.8.8"

  2. vSphere で OVA から仮想マシンを起動する前に、guestinfo.afterburn.initrd.network-kargs プロパティーを設定します。 

    $ govc vm.change -vm "<vm_name>" -e "guestinfo.afterburn.initrd.network-kargs=${IPCFG}"

これにより、DHCP を使用しない環境での Red Hat Enterprise Linux CoreOS (RHCOS) の自動デプロイメントの障壁が低くなります。今回の機能拡張により、静的ネットワークを持つ環境で RHCOS OVA をプロビジョニングするための高レベルの自動化が可能になりました。

詳細は、BZ1785122 を参照してください。

1.2.2. インストールおよびアップグレード

1.2.2.1. クラスターの AWS GovCloud リージョンへのインストール

Amazon Web Services (AWS) のクラスターを GovCloud リージョンにインストールできるようになりました。AWS GovCloud は、機密ワークロードを実行する必要のある米国の政府機関、請負業者、およびその他の米国の顧客向けに設計されています。

GovCloud リージョンには Red Hat によって公開される RHCOS AMI がないため、そのリージョンに属するカスタム AMI をアップロードする必要があります。

詳細は、AWS のクラスターの government リージョンへのインストール について参照してください。

1.2.2.2. カスタム AWS API エンドポイントの定義

install-config.yaml ファイルに serviceEndpoints フィールドを定義できるようになりました。これにより、AWS のデフォルトのサービスエンドポイントを上書きするためにカスタムエンドポイントの一覧を指定できるようになりました。

1.2.2.3. クラスターの Microsoft Azure Government リージョンへのインストール

Azure のクラスターを Microsoft Azure Government (MAG) リージョンにインストールできるようになりました。Microsoft Azure Government (MAG) は、機密ワークロードを実行する必要のある米国の政府機関およびそれらのパートナー向けに設計されています。

詳細は、Azure のクラスターの government リージョンへのインストール について参照してください。

1.2.2.4. Azure で実行されるクラスターのユーザー定義の送信ルーティング

Azure で実行しているクラスターの独自の送信ルーティングを選択してインターネットに接続できるようになりました。これにより、パブリック IP アドレスおよびパブリックロードバランサーの作成を省略できます。

詳細は、ユーザー定義の送信ルーティング について参照してください。

1.2.2.5. クラスターの vSphere バージョン 7.0 へのインストール

クラスターを VMware vSphere バージョン 7.0 にデプロイできるようになりました。詳細は、VMware vSphere インフラストラクチャーの要件 について参照してください。

1.2.2.6. インストーラーでプロビジョニングされるインフラストラクチャーを使用したベアメタルへのクラスターのインストール

OpenShift Container Platform 4.6 では、インストーラーでプロビジョニングされるインフラストラクチャーを使用してベアメタルにクラスターをインストールするためのサポートが導入されました。

詳細は、ベアメタルへのクラスターのインストール について参照してください。

1.2.2.7. AWS、Azure、および GCP でのクラウド API アクセスの認証情報の要求の処理

install-config.yaml ファイルに新たな credentialsMode フィールドが加えられました。このフィールドでは、AWS、Azure、および GCP でクラウド API アクセスを要求する OpenShift Container Platform コンポーネントについて CredentialsRequest カスタムリソースを処理する方法を定義します。設定可能な新しいモードは 3 つあります。

  • mint
  • passthrough
  • Manual (手動)
重要

Azure および GCP は、BZ#1884691 の既知の問題により、install-config.yaml ファイルを使用して Manual (手動) モードの設定をサポートすることはありません。

credentialsMode フィールドがこれら 3 つのモードのいずれかに設定される場合、インストールプログラムは、OpenShift Container Platform のインストール前に適切なパーミッションについての認証情報をチェックしません。これは、クラウドポリシーのシミュレーターの制限により、指定されるユーザー認証情報を適切に検証できない場合に役立ちます。

これらのモードの詳細は、Cloud Credential Operator について参照してください。

1.2.2.8. コントロールプレーンおよびコンピュートノードのディスクのタイプおよびサイズの指定

Azure および GCP で実行されているクラスターのコントロールプレーンおよびコンピュートノードでディスクタイプおよびサイズを設定できるようになりました。これは、install-config.yaml ファイルの以下のフィールドで指定できます。

  • osDisk.diskSizeGB
  • osDisk.diskType

以下は例になります。 

...
compute:
...
  platform:
  - osDisk:
      diskSizeGB: 120
      diskType: pd-standard
  replicas: 3
controlPlane:
...
  platform:
  - osDisk:
      diskSizeGB: 120
      diskType: pd-ssd
...
1.2.2.9. Azure インストールのコントロールプレーンノードの最小ディスクサイズが増加する

Azure インストールのコントロールプレーンノードの最小ディスクサイズ要件が 512 GB から 1024 GB に増加しました。

1.2.2.10. クラスターのアップグレード前に必要な最新バージョンの Operator

OpenShift Container Platform 4.6 以降、Operator Lifecycle Manager (OLM) および OperatorHub によって使用される Red Hat が提供するデフォルトカタログが OpenShift Container Platform のマイナーバージョンに固有のインデックスイメージとして同梱されるようになりました。クラスター管理者は、OpenShift Container Platform 4.6 にアップグレードする前に、OLM で以前にインストールされたすべての Operator が最新のチャネルの最新バージョンに更新されることを確認する必要があります。

詳細および重要な Operator のアップグレードの前提条件については、デフォルト Operator カタログがクラスターのバージョンごとに同梱される を参照してください。

1.2.2.11. プロビジョニングネットワークなしのデプロイメント

OpenShift Container Platform は、プロビジョニングネットワークを使用せず、RedFish 仮想メディア用のデプロイメントをサポートするようになりました。

詳細は、OpenShift インストール環境の設定 について参照してください。

1.2.2.12. デプロイメントがルートデバイスのヒントに対応する

デプロイメントが ルートデバイスのヒント に対応するようになりました。

1.2.2.13. インストーラーについての改善点

デプロイメントは、ノードでイントロスペクションを実行し、ノードがインストール要件を満たすようにします (要件を満たさない場合にエラーを生成するのとは異なる)。

1.2.2.14. インストール時の RHOSP アベイラビリティーゾーンの選択

RHOSP にクラスターをインストールする際に、Red Hat OpenStack Platform (RHOSP) Compute (Nova) アベイラビリティーゾーンを選択できるようになりました。

詳細は、RHOSP インストールドキュメントの OpenShift Container Platform について参照してください。

1.2.2.15. Floating IP アドレスが RHOSP へのインストールに 不要になる

RHOSP で OpenShift Container Platform のインストールを完了するために Floating IP アドレスを使用する必要なくなりました。

詳細は、RHOSP インストールドキュメントの OpenShift Container Platform について参照してください。

1.2.2.16. RHCOS インストールのディスクの選択

以前のバージョンでは、インストールプログラムがベアメタルクラスターをデプロイするために作成するインフラストラクチャーを使用する場合、RHCOS のデプロイに使用するディスクを指定できませんでした。今回のリリースにより、RHCOS をインストールするディスクを選択でき、rootDeviceHints がターゲットディスクの選択についてのガイダンスを提供するようになりました。(BZ#1805237)

1.2.2.17. AWS クラスターでの M5 インスタンスの使用がデフォルトになる

AWS での IPI および UPI インストールで、M5 インスタンスが推奨されるようになりました。したがって、AWS にデプロイされる新規クラスターはデフォルトで M5 インスタンスを使用します。M5 インスタンスを利用できない場合、インストーラーは M4 インスタンスを使用します。(BZ#1710981)

1.2.2.18. IBM Z および LinuxONE

本リリースでは、IBM Z および LinuxONE は OpenShift Container Platform 4.6 と互換性があります。インストール手順については、IBM Z および LinuxONE へのクラスターのインストール について参照してください。

制限

IBM Z および LinuxONE の OpenShift Container Platform については、以下の制限に注意してください。

  • IBM Z 向けの OpenShift Container Platform には、以下のテクノロジープレビューが含まれていません。

    • ログ転送
    • Precision Time Protocol (PTP) ハードウェア
    • CSI ボリュームスナップショット
    • OpenShift Pipeline

  • 以下の OpenShift Container Platform 機能はサポートされていません。

    • OpenShift Container Platform Virtualization
    • Red Hat OpenShift Service Mesh
    • CodeReady Containers (CRC)
    • OpenShift Container Platform Metering
    • Multus CNI プラグイン
    • FIPS 暗号
    • etcd に保存されるデータの暗号化
    • マシンヘルスチェックによる障害のあるマシンの自動修復
    • OpenShift Container Platform のデプロイメント時の Tang モードのディスク暗号化
    • OpenShift Container Platform Serverless
    • Helm コマンドラインインターフェイス (CLI) ツール
    • オーバーコミットの制御およびノード上のコンテナーの密度の管理
    • CSI ボリュームのクローン作成
    • NVMe
    • ファイバーチャネルを使用した永続ストレージ
  • ワーカーノードは Red Hat Enterprise Linux CoreOS (RHCOS) を実行する必要があります。
  • 永続共有ストレージは NFS を使用してプロビジョニングされる必要があります。
  • 共有されていない永続ストレージは、iSCSI、FC、DASD/FCP と共に LSO を使用するなど、ローカルストレージを使用してプロビジョニングする必要があります。

  • これらの機能は、4.6 について IBM Z の OpenShift Container Platform にのみ利用できます。

    • IBM System Z/LinuxONE で有効にされている HyperPAV (FICON 接続の ECKD ストレージの仮想マシン用)。
サポートされる機能

本リリースでは、IBM Z および LinuxONE で以下の機能がサポートされるようになりました。

  • iSCSI を使用した永続ストレージ
  • ローカルボリュームを使用した永続ストレージ (Local Storage Operator)
  • OpenShift Do (odo)
1.2.2.19. IBM Power Systems

本リリースでは、IBM Power Systems は OpenShift Container Platform 4.6 と互換性があります。IBM Power Systems へのクラスターのインストール、または ネットワークが制限された環境での IBM Power Systems へのクラスターのインストール について参照してください。

制限

IBM Power Systems の OpenShift Container Platform については、以下の制限に注意してください。

  • IBM Power Systems 向けの OpenShift Container Platform には、以下のテクノロジープレビュー機能が含まれていません。

    • OpenShift Virtualization
    • OpenShift Serverless(knative、FaaS 統合)

  • 以下の OpenShift Container Platform 機能はサポートされていません。

    • Red Hat OpenShift Service Mesh (istio、jaeger、 kiali)
    • CodeReady Workspace
    • CodeReady Containers (CRC)
    • Tekton をベースとする OpenShift Pipeline
    • OpenShift Container Platform Metering
    • Multus プラグイン (SR-IOV、IPVAN、VLAN を使用したブリッジ、静的 IPAM)
    • SR-IOV CNI プラグイン
    • Red Hat Single Sign-On
    • OpenShift Metering(Presto、Hive)
  • ワーカーノードは Red Hat Enterprise Linux CoreOS (RHCOS) を実行する必要があります。
  • 永続ストレージは、ローカルボリューム、Network File System (NFS)、OpenStack Cinder、または Container Storage Interface (CSI) を使用する Filesystem モードである必要があります。
  • ネットワークは、Red Hat Openshift SDN で DHCP または静的アドレス指定のいずれかを使用する必要があります。
  • AdoptOpenJDK with Eclipse OpenJ9
  • インストーラーでプロビジョニングされるインフラストラクチャー
  • NVIDIA GPU のデバイスマネージャー
  • Special Resources Operator
  • OpenShift Ansible Service Broker Operator (非推奨)
  • RHEL の dotNET
サポートされる機能

  • 現時点で、4 つの Operator がサポートされています。

    • Cluster-Logging-Operator
    • Cluster-NFD-Operator
    • Elastic Search-Operator
    • Local Storage Operator
  • ベアメタルでのユーザーによってプロビジョニングされるインフラストラクチャーのデプロイメントシナリオ
  • OpenShift Cluster Monitoring
  • Node Tuning Operator
  • OpenShift Jenkins
  • OpenShift Logging
  • OpenShift Do (odo)
  • Machine Configuration Operator (インストーラーでプロビジョニングされるインフラストラクチャーでのインストールで使用される)
  • Node Feature Discovery Operator
  • OpenShift Container Platform コア (CVO Operator)
  • ユーザーによってプロビジョニングされるインフラストラクチャーを使用するクラスターのインストールプログラム
  • OVS
  • RHEL8 ベースのコンテナーのサポート
  • RHEL CoreOS
  • Ansible Engine
  • Red Hat Software Collections
  • HostPath
  • iSCSI
  • 4K ディスクのサポート
1.2.2.20. Red Hat Virtualization (RHV) のフルスタックインストーラーの機能拡張
  • Container Storage Interface (CSI) ドライバー Operator を使用して、RHV ストレージドメインから OpenShift Container Platform クラスターにストレージを動的にプロビジョニングできます。
  • RHV 仮想マシンワーカーノードの自動スケーリングを使用して、ワークロードおよびリソースの制御を強化できます。
  • ローカルミラーを使用して、非接続または制限されたインストールを実行できます。この機能は、金融、公共部門などに、またセキュアな環境が必要な場合に役立ちます。
  • 外部ロードバランサーなど、OpenShift Container Platform は、ユーザーによってプロビジョニングされるインフラストラクチャーを使用して RHV にインストール できます。このプロセスでは、一連の Ansible Playbook を使用し、より柔軟なインストールを可能にします。
  • インストーラーでプロビジョニングされるインフラストラクチャーで RHV に OpenShift Container Platform をインストールするには、内部 DNS に静的 IP アドレスは必要ありません。

  • OpenShift Container Platform バージョン 4.6 には RHV バージョン 4.4.2 以降が必要です。

    重要

    RHV バージョン 4.3 で OpenShift Container Platform バージョン 4.5 を実行している場合、OpenShift Container Platform をバージョン 4.6 に更新する前に RHV をバージョン 4.4.2 以降にアップグレードします。

1.2.2.21. インストーラーでプロビジョニングされるインフラストラクチャーを使用したベアメタルのデプロイメントについての障害のあるノードの修復の強化

障害のあるコントロールプレーンノードの再起動による修復が可能になりました。これらのノードのラベルとアノテーションは、再起動による修復方法を使用する場合に保持されます。

1.2.3. セキュリティーおよびコンプライアンス

1.2.3.1. コンプライアンス Operator

コンプライアンス Operator が利用できるようになりました。この機能により、OpenSCAP ツールを使用して、デプロイメントがセキュリティー標準に準拠していることを確認し、修復オプションを提供できます。詳細は、OperatorHub について 参照してください。

1.2.3.2. OAuth トークンの非アクティブタイムアウトの設定

OAuth トークンを非アクティブになってから一定期間を経過した後に期限切れになるように設定できます。デフォルトでは、トークンの非アクティブタイムアウトは設定されません。内部 OAuth サーバーおよび OAuth クライアントのタイムアウトを設定できます。

詳細は、Configuring token inactivity timeout for the internal OAuth server および Configuring token inactivity timeout for an OAuth client を参照してください。

1.2.3.3. OAuth トークンストレージのセキュアな形式

OAuth アクセストークンおよび OAuth 認証トークンオブジェクト名が、機密性のないオブジェクト名として保存されるようになりました。

以前のバージョンでは、シークレット情報は OAuth アクセストークンおよび OAuth 認証トークンオブジェクト名として使用されました。etcd が暗号化される場合、値のみが暗号化されるため、この機密情報は暗号化されませんでした。

重要

クラスターを OpenShift Container Platform 4.6 にアップグレードする場合、OpenShift Container Platform 4.5 からの古いトークンには依然としてオブジェクト名で公開されるシークレット情報が含まれます。デフォルトでは、トークンの有効期限は 24 時間ですが、この設定は管理者が変更できます。機密データは、すべての古いトークンの有効期限が切れるか、または管理者によって削除されるまで依然として公開される可能性があります。

1.2.3.4. File Integrity Operator が利用可能になる

クラスターノード上でファイルの整合性チェックを継続的に実行する、OpenShift Container Platform Operator の File Integrity Operator が利用可能になりました。これは、各ノードで特権付きの AIDE (advanced intrusion detection environment; 高度な侵入検知環境) コンテナーを各ノードで初期化し、実行するデーモンセットをデプロイし、ステータスオブジェクトをデーモンセット Pod の初回実行時に変更されるファイルのログと共に提供します。

1.2.3.5. クラスターの復元の失敗についてのクラスタースクリプトの更新

cluster-backup.sh スクリプトおよび cluster-restore.sh スクリプトが更新され、ユーザーは復元に失敗した理由をより明確に理解できるようにより明確な情報が提供されるようになりました。

1.2.4. マシン API

1.2.4.1. 複数ブロックデバイスマッピングのサポート

マシン API が AWS で実行されるマシンの複数のブロックデバイスマッピングをサポートするようになりました。複数のブロックデバイスが指定されている場合、ログ、データを空のディレクトリー Pod に保存し、Docker イメージをマシンのルートデバイスから分離したブロックデバイスに保存できるようになりました。

1.2.4.2. Machine API providerSpec のデフォルト設定および検証

providerSpec からの入力が etcd に対して永続化する前に、デフォルト設定および検証が特定のクラウドプロバイダー API で有効にされるようになりました。検証は、マシンおよびマシンセットの作成時にこれらに対して実行されます。設定がクラウドプロバイダーによるマシンの作成を防ぐことが認識される場合にフィードバックが返されます。たとえば、マシンセットは、場所の情報が必要な場合にこれが指定されないと拒否されます。

1.2.4.3. Azure で実行されるマシンセットによる Spot 仮想マシンのサポート

Azure で実行されているマシンセットが Spot 仮想マシンに対応するようになりました。マシンを Spot 仮想マシンとしてデプロイするマシンセットを作成し、標準の仮想マシン価格と比較してより多くのコストを節約できます。詳細は、マシンを Spot 仮想マシンとしてデプロイするマシンセット について参照してください。

マシンセット YAML ファイルの providerSpec フィールドに spotVMOptions を追加して Spot 仮想マシンを設定します。 

providerSpec:
  value:
    spotVMOptions: {}
1.2.4.4. GCP で実行されるマシンセットによるプリエンプション可能な仮想マシンインスタンスのサポート

GCP で実行されるマシンセットがプリエンプション可能な仮想マシンインスタンスに対応するようになりました。マシンをプリエンプション可能な仮想マシンインスタンスとしてデプロイするマシンセットを作成し、標準のインスタンス価格と比較してより多くのコストを節約できます。詳細は、マシンをプリエンプション可能な仮想マシンインスタンスとしてデプロイするマシンセット について参照してください。

マシンセット YAML ファイルの providerSpec フィールドの下に preemptible を追加してプリエンプション可能な仮想マシンインスタンスを設定します。 

providerSpec:
  value:
    preemptible: true

1.2.5. Web コンソール

1.2.5.1. Web コンソールでのアップグレードエクスペリエンスの強化
  • 管理者は、便利なテキストと Web コンソールのリンクによって、アップグレードチャネルの違いについてより的確に把握できるようになりました。
  • バグ修正および拡張機能の一覧へのリンクが、各マイナーリリースまたはパッチリリースについて追加されるようになりました。
  • 異なるアップグレードパスを視覚的に表示できるようになりました。
  • 新規のパッチリリース、新規のマイナーリリースおよび新規チャネルが利用可能になると、アラートが管理者に送られるようになりました。
1.2.5.2. OperatorHub を使用した Operator インストールワークフローの改善

管理者が OperatorHub を使用して Operator をインストールすると、Operator が適切にインストールされるようにフィードバックが即時に使用されるようになりました。

1.2.5.3. オペランドの詳細ビューの改善

オペランドの詳細ビューで specDescriptor フィールドのスキーマグループと Operands のステータスを表示できるようになりました。これにより、ステータスの確認とオペランドインスタンスの spec の設定が容易になりました。

1.2.5.5. 管理リソースの編集時の警告メッセージ

一部のリソースは、Operator がデプロイメント、ルート、サービス、または設定マップによって管理されるように管理対象になります。ユーザーによるこれらのリソースの編集は推奨されません。代わりに、ユーザーは Operator とそのオペランドのカスタムリソースを編集し、Operator がその関連リソースを更新することを予想します。今回の更新により、以下が可能になります。

  • Managed by ラベル が、管理するリソースのクリック可能なリソースリンクと共にリソース名の下に表示されます。
  • リソースを変更または削除すると、ユーザーに変更が元に戻される可能性があることを示すメッセージが表示されます。
1.2.5.6. k8sResourcePrefix specDescriptor フィールドによる CRD インスタンスのサポート

Operator の作成者、メンテナーおよびプロバイダーは、Kubernetes コア API 以外に CRD リソースタイプを割り当てるために k8sResourcePrefixspecDescriptor フィールドを Group/Version/Kind で指定できるようになりました。

詳細は、OLM Descriptor Reference を参照してください。

1.2.5.7. リソースページでの列の管理

Manage columns アイコン manage columns が、Pods ページなどの一部のリソースページに追加されるようになりました。アイコンをクリックすると、デフォルトの列名はモーダルの左側にあるチェックボックスで一覧表示され、追加の列名が右側に表示されます。チェックボックスの選択を解除すると、その列がテーブルビューから削除されます。チェックボックスを選択すると、その列がテーブルビューに追加されます。モーダルの両側からの最大 9 列の組み合わせが一度に表示可能になりました。Save をクリックすると、変更が保存されます。Restore Default Columns をクリックすると、列のデフォルト設定が復元されます。

1.2.5.8. Developer パースペクティブ
  • ユーザーアクセ出力ルまたは権限に基づいて、ユーザーは Administrator または Developer パースペクティブのいずれかにダイレクトされるようになりました。
  • ユーザーのログイン時に、Developer パースペクティブのインタラクティブな Getting Started(スタート) ツアーが提供されるようになりました。
  • List ビューと Topology ビューで同じ情報が提供されるようになり、ユーザーはアプリケーションのサイズとコンポーネントの数に基づいて最適なビューを選択できるようになりました。
  • すべてのワークロードタイプのサポートが Topology および List ビューで提供されるようになり、使用されているコンピュートリソースをより明確に把握できるようになりました。
  • Developer カタログ からチャートをインストールする際に、Helm チャートのバージョンおよびアプリケーションのバージョンを選択できるようになりました。さらに、入力した値を維持しながらフォームと YAML エディターを切り替えることもできます。

  • Knative Eventing ワークフローが強化されました。

    • 信頼できるイベント配信メカニズムを構築するための Knative Eventing チャネルのサポートが追加されました。
    • チャネルのサブスクリプションを作成し、ブローカーについての関連付けられたフィルターを使用してトリガを作成し、Knative サービスをサブスクライバーとして選択できるようになりました。
    • イベントソースの作成時に、シンクをその namespace または URI から Knative サービス、チャネル、またはブローカーなどの Knative リソースとして指定できるようになりました。
    • チャネル、サブスクリプション、ブローカー、またはトリガーで Knative サービスによってサブスクライブされるイベントソースの関係を可視化できるようになりました。イベントソース関係の詳細は、サイドパネルでも確認できます。
    • 特定のイベントタイプのフィルター機能が提供されます。
  • 適切なランタイムアイコンやツールチップを表示するためのランタイムラベルの追加など、ユーザービリティーに関連した拡張機能が追加されました。
  • ワークロードから基本的な Horizontal Pod Autoscaling (HPA) を追加し、編集し、削除し、HPA を作成し、これを割り当てるワークロードを指定できるようになりました。
  • OpenShift Service Mesh がクラスターで有効にされ、指定の namespace が有効にされている場合、Topology ビューの Kiali リンクをクリックし、設定された Kiali ダッシュボードの適切な namespace に移動できるようになりました。
  • Monitoring ビューでは、Monitoring ダッシュボードでリソース固有のメトリクスをフィルターできるようになりました。実行されるアラートを表示し、それらをサイレンスにし、プロジェクトに設定されたアラートルールを表示することもできます。

1.2.6. スケーリング

1.2.6.1. クラスターの最大数

OpenShift Container Platform 4.6 の クラスターの最大値 に関するガイダンスが更新されました。

ご使用の環境のクラスター制限を見積もるには、OpenShift Container Platform Limit Calculator を使用できます。

1.2.6.2. リアルタイムプロファイルが Node Tuning Operator に追加される

部分的な Tuned リアルタイムプロファイルサポートは OpenShift Container Platform 4.4 で利用可能になりました。リアルタイムプロファイルは、Red Hat Enterprise Linux (RHEL) 上の Tuned でのリアルタイムプロファイルの機能と完全に互換性を持つようになりました。

1.2.6.3. Performance Addon Operator が完全にサポートされる

Performance Addon Operator は、管理者が低レイテンシーのワークロードおよびリアルタイムのワークロードについてワーカーノードを調整するのに役立ちます。これは、PerformanceProfile カスタムリソースの形式でチューニングのハイレベルの意図を汲み取り、待ち時間を短縮する目的で Linux カーネル、オペレーティングシステム、Huge Page、および kubelet を設定するために必要なすべてのアクションにこれを反映します。

以前のリリースで提供される機能に加え、このバージョンには以下が含まれます。

  • CPU の負荷分散は Pod ごとに有効にできます。
  • 複数の Huge Page サイズを同時に指定できます。
  • 統合収集やステータスレポートの改善など、サポート機能が改善されました。
  • フィールド内の緊急設定をオーバーライドする方法が設計され、文書化されました。
1.2.6.4. Intel デバイスによるデータプレーンパフォーマンスの最適化

OpenShift Container Platform 4.6 は以下をサポートします。

  • OpenNESS Operator for Intel FPGA PAC N3000
  • OpenNESS SR-IOV Operator for Wireless FEC Accelerators
注記

N3000 Operator では、ツリーカーネルモジュールから Open Programmable Accelerator Engine (OPAE) で事前ビルドされたドライバーコンテナーが必要です。事前ビルドされたドライバーコンテナーは Intel によってビルドされ、出荷されており、現在 OpenShift Container Platform 4.6.16 でサポートされます。異なる OpenShift Container Platform バージョンが必要な場合には、Intel® Premier Support Access または openness.n3000.operator@intel.com のプレミアサポートポータルから Intel にお問い合わせください。

詳細は、OpenNESS Operator for Wireless FEC Accelerators を参照してください。

これらの Operator は、低電力、低コスト、低レイテンシーを実現する vRAN デプロイメントの要件をサポートし、さまざまなユースケースでパフォーマンスの上下を管理する機能も提供します。最もコンピュート集中型の 4G および 5G ワークロードの 1 (L1) forward error correction (FEC) の 1 つで、信頼できないまたはノイズのある通信チャネルにおけるデータ送信エラーを解決します。

5G の使用が増え、5G ネットワークに依存するユーザーが増加するにつれ、5G レベルの高パフォーマンスを維持するには高パフォーマンス FEC を提供することが極めて重量です。FEC は通常、Intel PAC N300 や Intel vRAN Dedicated Accelerator ACC100 のように、Field Programmable Gate Arrays (FPGA) アクセラレーターカードに実装されています。

詳細は、Optimizing data plane performance with the Intel FPGA PAC N3000 and Intel vRAN Dedicated Accelerator ACC100 を参照してください。

1.2.6.5. コンソールでのベアメタルホストの管理

これまでは、Web コンソールでベアメタルホストをメンテナーンスする方法は文書化されていませんでした。このコンテンツが追加されました。詳しくは、ベアメタルホストの管理 をご覧ください。

1.2.7. 開発者のエクスペリエンス

1.2.7.1. oc set probe コマンドの拡張

oc set probe コマンドは、起動プローブの設定をサポートするように拡張されました。

1.2.7.2. oc adm upgrade コマンドがアップグレード可能な状態に言及するようになりました。

oc adm upgrade コマンドはすべての Upgradeable=False 状態に言及するようになり、管理者は Upgradeable=False 状態のために特定の更新が拒否される可能性があることを把握できるようになりました。

1.2.8. ネットワーク

1.2.8.1. OVN-Kubernetes クラスターネットワークプロバイダーの一般利用が可能になる

OVN-Kubernetes クラスターネットワークプロバイダーが一般に利用できるようになりました。ネットワークプロバイダーは Kubernetes Container Network Interface (CNI) プラグインとして実装されます。OpenShift SDN の機能パリティーについての詳細は、OVN-Kubernetes Container Network Interface (CNI) ネットワークプロバイダー について参照してください。

本リリースでは、OpenShift SDN はデフォルトのクラスターネットワークプロバイダーのままになります。

注記

OVN-Kubernetes の Red Hat Enterprise Linux (RHEL) 7.8 でのサポートは OpenShift Container Platform 4.6 の一般利用開始日 (GA) には利用可能になりません。

1.2.8.2. ノードサービスポート範囲の拡張

ノードサービスポート範囲は、デフォルトの 30000-32767 の範囲を超えて拡張できます。この拡張された範囲を Service オブジェクトで使用することができます。詳細は、ノードポートサービス範囲の設定 を参照してください。

1.2.8.3. SR-IOV Network Operator InfiniBand デバイスのサポート

Single Root I/O Virtualization (SR-IOV) Network Operator が InfiniBand (IB) ネットワークデバイスをサポートするようになりました。クラスターの IB ネットワークデバイスについての詳細は、SR-IOV InfiniBand ネットワーク割り当ての設定 について参照してください。

1.2.8.4. プロビジョニングネットワーク用の DHCP 範囲が拡大

大規模なデプロイメントのサポートを強化するために、プロビジョニングネットワークのデフォルトの DHCP 範囲が、本リリースの残りのサブネットを組み込むために拡大されます。DHCP のサブネットの数を減らす必要のあるユーザーは、それぞれのニーズに合わせて引き続きこれを設定できます。(BZ#1841135)

1.2.8.5. Pod ネットワーク接続の確認

Operator は、PodNetworkConnectivityCheck リソースを設定して、Operator によって管理される Pod から各ネットワーク接続を確認できます。これにより、クラスター内の重要なネットワーク接続に関する問題の特定とトラブルシューティングがより簡単に行えます。

このリソースは、最新の到達可能な状態、最後の 10 回の成功、10 回の失敗、および検知された停止の詳細を追跡します。また、結果はログに記録され、停止が検知され、解決されるとイベントが作成されます。

デフォルトでは、以下のネットワーク接続がチェックされます。

  • Kubernetes API サーバーの以下との接続

    • OpenShift API サーバーサービス
    • 各 OpenShift API サーバーエンドポイント
    • 各 etcd エンドポイント
    • 内部 API ロードバランサー
    • 外部 API ロードバランサー

  • OpenShift API サーバーと以下との接続

    • Kubernetes API サーバーサービス
    • 各 Kubernetes API サーバーエンドポイント
    • 各 etcd エンドポイント
    • 内部 API ロードバランサー
    • 外部 API ロードバランサー
1.2.8.6. セカンダリーデバイスメトリクスのネットワーク割り当てへの関連付けが可能になる

セカンダリーデバイス (インターフェイス) は、各種の用途に合わせて使用されます。セカンダリーデバイスのメトリクスを同じ分類で集計するために、それらを分類する方法を確保する必要があります。

kubelet は一連のネットワークで監視可能なメトリクスをすでに公開しています。これらのメトリクスのラベルには、とくに以下が含まれます。

  • Pod の名前
  • Pod の namespace
  • インターフェイス名 (例: et0)

これは、インターフェイス名が参照する内容が明確でないため、Multus などを介して新しいインターフェイスが Pod に追加されるまで機能します。インターフェイスのラベルはインターフェイス名を参照しますが、そのインターフェイスの用途は明確ではありません。多くの異なるインターフェイスがある場合、監視しているメトリクスが参照するネットワークを把握することはできません。これは、新規の pod_network_name_info メトリクスを導入することで対応できます。このメトリクスは、kubelet によって公開される値と、ネットワークのタイプを特定するメトリクスが関連するネットワーク割り当て定義の名前の両方を含むクエリーをビルドするために使用できます。

詳細は、セカンダリーインターフェイスメトリクスをネットワーク割り当てへの関連付け について参照してください。

1.2.8.7. CNF テストが検出モードで実行可能

Cloud-native Network Functions (CNF) テストが新規の設定を適用するのではなく、クラスターでの設定の検索を試行するオプションのモードがあります。CNF テストイメージは、CNF 適合性テストスイート (CNF conformance test suite) のコンテナー化されたバージョンです。これは、CNF ワークロードの実行に必要なすべてのコンポーネントがインストールされている OpenShift Container Platform クラスターに対して実行されることが意図されています。

テストは、実行されるたびに環境設定を実行する必要があります。これには、SRI-OV ノードポリシー、パフォーマンスプロファイル、または PTP プロファイルの作成などの項目が関係します。テストですでに設定されているクラスターを設定できるようにすると、クラスターの機能が影響を受ける可能性があります。また、SR-IOV ノードポリシーなどの設定項目への変更により、設定の変更が処理されるまで環境が一時的に利用できなくなる可能性があります。

検出モード は、設定を変更せずにクラスターの機能を検証します。既存の環境設定はテストに使用されます。テストは必要な設定項目の検索を試行し、それらの項目を使用してテストを実行します。特定のテストの実行に必要なリソースが見つからない場合、テストは省略され、ユーザーに適切なメッセージが表示されます。テストが完了すると、事前に設定された設定項目のクリーンアップは行われず、テスト環境は別のテストの実行にすぐに使用できます。

1.2.8.8. HAProxy バージョンのアップグレード

OpenShift Container Platform 4.6 の Ingress は HAProxy バージョン 2.0.16 を使用するようになりました。

1.2.8.9. X-Forwarded ヘッダーの制御

forwardedHeaderPolicy パラメーターを設定して X-Forwarded ヘッダーの制御が可能になりました。

haproxy.router.openshift.io/set-forwarded-headers ルートアノテーションの導入により、ルートごとに X-forwarded ヘッダーの適用および設定がサポートされるようになりました。

詳細は、X-Forwarded ヘッダー について参照してください。

1.2.8.10. ルートパスの変更

受信要求のルートパスの変更が haproxy.router.openshift.io/rewrite-target 変数でサポートされるようになりました。

詳細は、ルート設定 について参照してください。

1.2.8.11. Ingress 終了ポリシー

終了ポリシーは、Ingress オブジェクトの route.openshift.io/termination アノテーションを使用して定義できるようになりました。

詳細は、Ingress オブジェクトを使用したルートの作成 について参照してください。

1.2.8.12. AWS の Ingress コントローラーネットワークロードバランサー

新規および既存の AWS クラスターの Ingress Controller Network Load Balancer (NLB) の設定がサポートされるようになりました。

詳細は、ネットワークロードバランサーを使用した AWS での ingress クラスタートラフィックの設定 について参照してください。

1.2.8.13. AWS Route53 の Ingress Operator エンドポイント設定

AWS Route53 エンドポイント設定は Ingress Operator でサポートされるようになりました。

詳細は、AWS Route53 の Ingress Operator エンドポイント設定 について参照してください。

1.2.8.14. Ingress Controller unique-id 設定

一意に定義された要求 ID で HTTP ヘッダーを挿入するように Ingress Controller を設定することがサポートされるようになりました。これは、クラスタートラフィックの追跡に使用できます。

詳細は、IngressController 仕様 を参照してください。

1.2.8.15. ネットワークポリシーによるホストネットワーク Ingress コントローラーの選択のサポート

OVN-Kubernetes クラスターネットワークプロバイダーを使用する場合、Ingress コントローラーがクラスターネットワークまたはホストネットワークで実行されるかどうかにかかわらず、ネットワークポリシールールの Ingress コントローラーからトラフィックを選択することができます。ネットワークポリシールールでは、policy-group.network.openshift.io/ingress="" namespace セレクターラベルが Ingress コントローラーからのトラフィックと一致します。network.openshift.io/policy-group: ingress namespace セレクターラベルは引き続き使用できますが、これはレガシーラベルであり、OpenShift Container Platform の将来のリリースで削除される可能性があります。

OpenShift Container Platform の以前のリリースでは、以下の制限がありました。

  • OVN-Kubernetes クラスターネットワークプロバイダーを使用するクラスターは、ホストネットワーク上の Ingress コントローラーからのトラフィックを選択できませんでした。

詳細は、ネットワークポリシーについて を参照してください。

1.2.8.16. ネットワークポリシーによるホストネットワークトラフィックの選択のサポート

OVN-Kubernetes クラスターネットワークプロバイダーを使用する場合はpolicy-group.network.openshift.io/host-network: "" namespace セレクターを使用して、ネットワークポリシールールでホストネットワークトラフィックを選択できます。

1.2.9. ストレージ

1.2.9.1. CSI ドライバーが Cluster Storage Operator で管理される

Container Storage Interface (CSI) ドライバー Operator および AWS Elastic Block Store (EBS)、Red Hat Virtualization (oVirt)、および OpenStack Manila 共有ファイルシステムサービス のドライバーは、OpenShift Container Platform の Cluster Storage Operator で管理されるようになりました。

AWS EBS および oVirt の場合、この機能はデフォルトで CSI ドライバー Operator およびドライバーを openshift-cluster-csi-drivers namespace にインストールします。Manila の場合、CSI ドライバー Operator は openshift-cluster-csi-drivers にインストールされ、ドライバーは openshift-manila-csi-driver namespace にインストールされます。

重要

CSI ドライバー Operator およびドライバーを OpenShift Container Platform 4.5 クラスターにインストールしている場合、以下を実行します。

  • OpenShift Container Platform の新規バージョンに更新する前に、AWS EBS CSI ドライバー Operator およびドライバーをアンインストールする必要があります。
  • OpenStack Manila CSI ドライバー Operator は Operator Lifecycle Manager (OLM) で利用できなくなりました。これは Cluster Version Operator によって自動的に変換されています。元の openshift-manila-csi-driver-operator namespace はまだ存在している可能性があり、クラスター管理者が手動で削除できます。
1.2.9.2. ローカルストレージ Operator を使用した自動デバイス検出およびプロビジョニング (テクノロジープレビュー)

ローカルストレージ Operator は以下を実行できるようになりました。

  • クラスターで利用可能なディスクの一覧を自動的に検出します。自動検出が継続的に適用されるノードの一覧またはすべてのノードを選択できます。
  • 割り当てられたデバイスからローカル永続ボリュームを自動的にプロビジョニングします。適切なデバイスがフィルターされ、永続ボリュームはフィルターされたデバイスに基づいてプロビジョニングされます。

詳細は、ローカルストレージデバイスの自動検出およびプロビジョニング について参照してください。

1.2.9.3. AWS EFS (テクノロジープレビュー) 機能の外部プロビジョナーが削除される

Amazon Web Services (AWS) Elastic File System (EFS) テクノロジープレビュー機能が削除され、サポートされなくなりました。

1.2.10. レジストリー

1.2.10.1. 無効なイメージを容認するイメージプルーナー

イメージプルーナーは、OpenShift Container Platform の新規インストールにおいてデフォルトで無効なイメージ参照を容認できるようになりました。これにより、無効なイメージが見つかる場合でもプルーニングを継続できるようになりました。

1.2.10.2. イメージプルーナーのログレベルの変更

クラスター管理者は、Pruning Custom Resource の logLevel をログをデバッグするように設定できます。

1.2.10.3. イメージレジストリーによる Azure Government のサポート

イメージレジストリーは Azure Government 用にセットアップし、設定できるようになりました。

詳細は、Azure Government のレジストリーストレージの設定 について参照してください。

1.2.10.4. イメージレジストリー Operator のログレベルの変更

クラスター管理者は、イメージレジストリー Operator の logLevel をログをデバッグするように設定できるようになりました。

logLevel でサポートされる値は以下になります。

  • Normal
  • Debug
  • Trace
  • TraceAll

イメージレジストリー Operator YAML ファイルの例

spec:
logLevel: Normal
operatorLogLevel: Normal

1.2.10.5. イメージレジストリー Operator の spec.storage.managementState の変更

イメージレジストリー Operator は、AWS または Azure のインストーラーでプロビジョニングされるインフラストラクチャーを使用してクラスターの新規インストールまたはアップグレード時に spec.storage.managementState パラメーターを Managed に設定します。

  • Managed: イメージレジストリー Operator が基礎となるストレージを管理することを判別します。イメージレジストリー Operator の managementState が Removed に設定されている場合、ストレージは削除されます。

    • managementState が Managed に設定されている場合、イメージレジストリー Operator は基礎となるストレージユニットにいくつかのデフォルト設定を適用しようとします。たとえば、Managed に設定されている場合、Operator はこれをレジストリーで利用可能にする前に S3 バケットで暗号の有効にしようとします。デフォルト設定を提供しているストレージに適用しない場合、managementState が Unmanaged に設定されていることを確認します。
  • Unmanaged: イメージレジストリー Operator がストレージ設定を無視することを判別します。イメージレジストリー Operator の managementState が Removed に設定されている場合、ストレージは削除されません。バケットまたはコンテナー名などの基礎となるストレージユニット設定を指定し、spec.storage.managementState がまだいずれの値にも設定されていない場合、イメージレジストリー Operator はこれを Unmanaged に設定します。

1.2.11. Operator ライフサイクル

1.2.11.1. Operator バージョンの依存関係

Operator の開発者は、dependencies.yaml ファイルで olm.package タイプを使用し、Operator に他の Operator の特定バージョンについての依存関係を含めることができるようになりました。

詳細は、Operator Lifecycle Manager の依存関係の解決 について参照してください。

1.2.11.2. Operator バンドルでサポートされる追加のオブジェクト

Operator Bundle Format が以下の追加の Kubernetes オブジェクトをサポートするようになりました。

  • PodDisruptionBudget
  • PriorityClass
  • VerticalPodAutoScaler

詳細は、Operator Framework パッケージ形式 について参照してください。

1.2.11.3. opm の使用による選択的なバンドルイメージのミラーリング

Operator 管理者は、opm index prune コマンドを使用して、ミラーリングするバンドルイメージを選択できるようになりました。

詳細は、インデックスイメージのプルーニング について参照してください。

1.2.11.4. グローバル Operator の変換 Webhook のサポート

Operator 開発者は、グローバル Operator とも呼ばれるすべての namespace をターゲットとする Operator に変換 Webhook を使用できるようになりました。

詳細は、Webhook の定義 について参照してください。

1.2.11.5. Operator API がサポートされる

OpenShift Container Platform 4.5 でテクノロジープレビュー機能として導入された Operator API がデフォルトでサポートされ、有効にされるようになりました。Operator Lifecycle Manager (OLM) を使用した Operator のインストールでは、クラスター管理者が CatalogSource、Subscription、ClusterServiceVersion、および InstallPlan などの複数の API を認識している必要がありました。この単一 Operator API リソースは、OpenShift Container Platform クラスターで Operator のライフサイクルを検出し、管理するためのよりシンプルなエクスペリエンスを実現するための最初のステップになります。

関連するリソースは、Subscription リソースを使用して CSV がインストールされている Operator の新規 Operator API について自動的にラベル付けされるようになりました。クラスター管理者は、この単一 API で CLI を使用し、インストールされた Operator と対話できます。以下は例になります。 

$ oc get operators
$ oc describe operator <operator_name>
1.2.11.5.1. クラスターアップグレード前のテクノロジープレビュー Operator API の削除

OpenShift Container Platform 4.5 の Operator API のテクノロジープレビュー機能バージョンを有効にしている場合、OpenShift Container Platform 4.6 にアップグレードする前にこれを無効にする必要があります。これを怠ると、この機能では Cluster Version Operator (CVO) のオーバーライド が必要になるために、クラスターのアップグレードがブロックされます。

前提条件

  • テクノロジープレビューの Operator OLM が有効にされた OpenShift Container Platform 4.5 クラスター

手順

  1. Operator API ラベルは OpenShift Container Platform 4.6 の関連するリソースに自動的に適用されるため、以前に手動で適用した operators.coreos.com/<name> ラベルを削除する必要があります。

    1. 以下のコマンドを実行し、status.components.refs セクションを確認して、現時点で Operator のラベル付けされているリソースを確認できます。 

      $ oc describe operator <operator_name>

      以下は例になります。 

      $ oc describe operator etcd-test

      出力例

      ...
Status:
  Components:
    Label Selector:
      Match Expressions:
        Key:       operators.coreos.com/etcd-test
        Operator:  Exists
    Refs:
      API Version:  apiextensions.k8s.io/v1
      Conditions:
        Last Transition Time:  2020-07-02T05:50:40Z
        Message:               no conflicts found
        Reason:                NoConflicts
        Status:                True
        Type:                  NamesAccepted
        Last Transition Time:  2020-07-02T05:50:41Z
        Message:               the initial names have been accepted
        Reason:                InitialNamesAccepted
        Status:                True
        Type:                  Established
      Kind:                    CustomResourceDefinition 1
      Name:                    etcdclusters.etcd.database.coreos.com 2
...

      1
      リソースタイプ。
      2
      リソース名。

    2. 関連するすべてのリソースからラベルを削除します。以下は例になります。 

      $ oc label sub etcd operators.coreos.com/etcd-test- -n test-project
$ oc label ip install-6c5mr operators.coreos.com/etcd-test- -n test-project
$ oc label csv etcdoperator.v0.9.4 operators.coreos.com/etcd-test- -n test-project
$ oc label crd etcdclusters.etcd.database.coreos.com operators.coreos.com/etcd-test-
$ oc label crd etcdbackups.etcd.database.coreos.com operators.coreos.com/etcd-test-
$ oc label crd etcdrestores.etcd.database.coreos.com operators.coreos.com/etcd-test-

  2. Operator のカスタムリソース定義 (CRD) を削除します。 

    $ oc delete crd operators.operators.coreos.com

  3. OLM Operator から OperatorLifecycleManagerV2=true 機能ゲートの名前を変更します。

    1. OLM Operator の Deployment を編集します。 

      $ oc -n openshift-operator-lifecycle-manager \
    edit deployment olm-operator

    2. 以下のフラグを Deployment オブジェクトの args セクションから削除します。 

      ...
    spec:
      containers:
      - args:
...
        - --feature-gates 1
        - OperatorLifecycleManagerV2=true 2
      1 2
      これらのフラグを削除します。
    3. 変更を保存します。

  4. OLM の CVO 管理を再度有効にします。 

    $ oc patch clusterversion version \
    --type=merge -p \
    '{
       "spec":{
          "overrides":[
             {
                "kind":"Deployment",
                "name":"olm-operator",
                "namespace":"openshift-operator-lifecycle-manager",
                "unmanaged":false,
                "group":"apps/v1"
             }
          ]
       }
    }'

  5. Operator リソースが利用できなくなったことを確認します。 

    $ oc get operators

    出力例

    error: the server doesn't have a resource type "operators"

OpenShift Container Platform 4.6 へのアップグレードは、この機能によってブロックされなくなるはずです。

1.2.11.6. Node Maintenance Operator がメンテナーンス要求を検証する

Node Maintenance Operator がマスターノードのメンテナーンス要求を検証し、マスター (etcd) クォーラム (定足数) の違反を防ぐようになりました。その結果、マスターノードは、etcd-quorum-guard Pod の Disruption Budget (停止状態の予算) が許可する場合にのみ maintenance に設定できます。(BZ#1826914)

1.2.11.7. NodeMaintenance カスタムリソースを使用したノードのメンテナーンスモードへの設定

以前は、NodeMaintenance カスタムリソース (CR) を使ってノードをメンテナーンスモードにすることは文書化されていませんでした。このコンテンツが追加されました。詳しくは、ノードメンテナーンスモードについて をご覧ください。

1.2.11.8. イメージレジストリー Operator およびオペランドに個別にログレベルを設定する

ユーザーは、イメージレジストリー Operator およびオペランドにログレベルを個別に設定できるようになりました。(BZ#1808118)

1.2.12. ビルド

1.2.12.1. ビルドが HTTPS プロキシーの背後で Git クローンをサポート

ビルドで、HTTPS プロキシーの背後にある Git クローンをサポートするようになりました。

1.2.13. イメージ

1.2.13.1. Cloud Credential Operator モードのサポート

既存のデフォルトモードの操作のほかに、Cloud Credential Operator (CCO) は、Mint、Passthrough、および Manual モードで動作するように明示的に設定できるようになりました。この機能により、CCO がクラウド認証情報を使用してインストールおよびその他のタスクについてクラスターの CredentialsRequest カスタムリソースを処理する方法について透明性と柔軟性が提供されます。

1.2.13.2. Power および Z の Cluster Samples Operator

Power および Z アーキテクチャーのイメージストリームおよびテンプレートは、デフォルトで利用可能となり、Cluster Samples Operator によってインストールされるようになりました。

1.2.13.3. Cluster Samples Operator アラート

サンプルがインポートされない場合、Cluster Samples Operator は動作が低下したステータスに移行する代わりにアラートを通知するようになりました。

詳細は、代替のレジストリーまたはミラーリングされたレジストリーでの Cluster Samples Operator イメージストリームの使用 について参照してください。

1.2.14. メータリング

1.2.14.1. メータリング Report カスタムリソースの保持期間の設定

メータリングの Report カスタムリソース (CR) で保持期間を設定できるようになりました。メータリングの Report CR には新規の expiration フィールドがあります。expiration の保持期間の値が Report CR に設定され、他の Report または ReportQuery CR が期限切れの Report CR に依存しない場合、メータリング Operator は保持期間の終了時にクラスターから Report CR を削除します。詳細は、メータリング Report CR の 有効期限 について参照してください。

1.2.15. ノード

1.2.15.1. ノード監査ログポリシーの設定

使用する監査ログポリシープロファイルを選択して、ノード監査ログに記録する情報量を制御できます。

詳細は、ノード監査ログポリシーの設定 について参照してください。

1.2.15.2. Pod トポロジー分散制約の設定

Pod トポロジー分散制約を設定して、ノード、ゾーン、リージョンその他のユーザー定義のトポロジードメイン間で Pod の配置をより詳細に制御できるようになりました。これにより、高可用性とリソースの使用率が向上します。

詳細は、Pod トポロジー分散制約を使用した Pod 配置の制御 について参照してください。

1.2.15.3. 新しい Descheduler ストラテジーが利用可能になる (テクノロジープレビュー)

Descheduler では、PodLifeTime ストラテジーを設定できるようになりました。このストラテジーは、特定の設定可能な期間に達すると Pod をエビクトします。

詳細は、Descheduler ストラテジー を参照してください。

1.2.15.4. namespace および優先度による Descheduler のフィルター (テクノロジープレビュー)

Descheduler ストラテジーが namespace および優先度に基づいて Pod をエビクションの対象として考慮する必要があるかどうかについて設定できるようになりました。

詳細は、namespace による Pod のフィルター、および 優先度による Pod のフィルター について参照してください。

1.2.15.5. RemoveDuplicates descheduler ストラテジーの新規パラメーター (テクノロジープレビュー)

RemoveDuplicates ストラテジーは、Kind タイプの一覧を指定できるオプションのパラメーター ExcludeOwnerKinds を提供するようになりました。Pod でこれらのタイプのいずれかが OwnerRef として一覧表示される場合、Pod はエビクション対象として考慮されません。

詳細は、Descheduler ストラテジー を参照してください。

1.2.15.6. レジストリーにスコープ指定された ImageContentSourcePolicy オブジェクトの生成

oc adm catalog mirror コマンドは、元のコンテナーイメージリポジトリーを、通常は非接続環境内のミラーリングされる新しい場所にマップする ImageContentSourcePolicy (ICSP) オブジェクトを生成します。新規または変更後の ICSP がクラスターに適用されると、これは CRI-O の設定ファイルに変換され、各ノードに配置されます。ノードに設定ファイルを配置するプロセスには、ノードの再起動が含まれます。

今回の機能拡張により、--icsp-scope フラグが oc adm catalog mirror に追加されました。スコープはレジストリーまたはリポジトリーのいずれかにすることができます。デフォルトで、oc adm catalog mirror コマンドは各エントリーがリポジトリーに固有となる ICSP を生成します。たとえば、registry.redhat.io/cloud/test-db を mirror.internal.customer.com/cloud/test-db にマップします。ICSP ファイルでミラーをレジストリースコープに拡張すると、クラスターがそのノードを再起動する必要がある回数が最小限に抑えられます。同じ例を使用して registry.redhat.io は mirror.internal.customer.com にマップします。

ICSP の範囲が広く設定されると、今後 ICSP の変更が必要となる回数を減らすことができ、クラスターがすべてのノードを再起動しなければならない回数も減ります。

1.2.16. クラスターロギング

ログ転送 API が一般に利用可能になる

ログ転送 API が一般に利用できるようになりました。ログ転送 API により、カスタムリソースをログを転送するようにエンドポイントで設定し、コンテナー、インフラストラクチャー、および監査ログをクラスター内外の特定のエンドポイントに送信できます。ログ転送 API は Kafka ブローカーへの転送をサポートし、TLS を含む syslog RFC 3164 および RFC 5424 をサポートするようになりました。アプリケーションログを特定のプロジェクトからエンドポイントに転送することもできます。

一般利用開始日 (GA) より、ログ転送 API には複数の変更が含まれます。それらには、ログ転送カスタムリソース (CR) のパラメーター名の変更が含まれます。ログ転送テクノロジープレビューを使用している場合、必要な変更を既存のログ転送 CR に手動で加える必要があります。

ログメッセージへのラベルの追加

ログ転送 API を使用すると、アウトバウンドログメッセージに付けられるログメッセージにフリーテキストのラベルを追加できます。たとえば、データセンター別にログにラベルを付けることも、タイプ別にログにラベルを付けることもできます。オブジェクトに追加されるラベルもログメッセージと共に転送されます。

新規クラスターロギングダッシュボード

OpenShift Container Platform Web コンソールに 2 つの新規ダッシュボードが追加されました。これらは、クラスターロギングおよび Elasticsearch インスタンスの詳細な調査およびトラブルシューティングに使用するために、重要、低レベルのメトリクスと共にチャートを表示します。

OpenShift Logging ダッシュボードには、クラスターリソース、ガベージコレクション、クラスターのシャード、Fluentd 統計など、クラスターレベルでの Elasticsearch インスタンスについての詳細を表示するチャートが含まれます。

Logging/Elasticsearch Nodes ダッシュボードには、Elasticsearch インスタンスの詳細を表示するチャートが含まれます。これらのチャートの多くはノードレベルのものであり、これには、インデックス、シャード、リソースなどの詳細が含まれます。

Fluentd を調整するための新規パラメーター

新規 Fluentd パラメーターにより、Fluentd ログコレクターのパフォーマンスを調整できます。これらのパラメーターを使用して、以下を変更できます。

  • Fluentd チャンクおよびチャンクバッファーのサイズ
  • Fluentd チャンクのフラッシュ動作
  • Fluentd チャンクの転送の再試行動作

これらのパラメーターは、クラスターロギングインスタンスでの待ち時間とスループット間のトレードオフを判別するのに役立ちます。

1.2.17. モニターリング

1.2.17.1. ユーザー定義プロジェクトのモニターリング

OpenShift Container Platform 4.6 では、デフォルトのプラットフォームのモニターリングに加えて、ユーザー定義プロジェクトのモニターリングを有効にできます。追加のモニタリングソリューションなしに、OpenShift Container Platform で独自のプロジェクトをモニターできるようになりました。この新機能を使用することで、コアプラットフォームコンポーネントとユーザー定義プロジェクトのモニターリングが一元化されます。

この新機能により、以下のタスクを実行できます。

  • ユーザー定義プロジェクトのモニターリングを有効にし、これを設定する。
  • 独自の Pod およびサービスからメトリクスを使用する記録ルールおよびアラートルールの作成。
  • 単一のマルチテナントインターフェイスを使用したメトリクスおよびアラートについての情報へのアクセス
  • プラットフォームメトリクスとユーザー定義プロジェクトのメトリクスの相互相関 (cross-correlate)。

詳細は、モニタリングの概要 を参照してください。

1.2.17.2. アラートルールの変更

OpenShift Container Platform 4.6 には、以下のアラートルールの変更が含まれます。

  • PrometheusOperatorListErrors アラートが追加されています。アラートは、コントローラーでリスト操作の実行時にエラーを通知します。
  • PrometheusOperatorWatchErrors アラートが追加されています。アラートは、コントローラーで監視操作の実行時にエラーを通知します。
  • KubeQuotaExceeded アラートは KubeQuotaFullyUsed に置き換えられます。以前のバージョンでは、KubeQuotaExceeded アラートは、リソースクォータが 90% のしきい値を超える場合に実行されました。KubeQuotaFullyUsed アラートは、リソースクォータが十分に使用される場合に実行されます。
  • etcd アラートは、メトリクスのカスタムラベルの追加をサポートするようになりました。
  • KubeAPILatencyHigh および KubeAPIErrorsHigh アラートは KubeAPIErrorBudgetBurn アラートによって置き換えられます。KubeAPIErrorBudgetBurn は、API エラーと待ち時間についてのアラートを統合し、状態が深刻な場合にのみ実行されます。
  • kubelet によって公開される readiness および liveness プローブメトリクスが収集されるようになりました。これにより、コンテナーに関する過去の liveness および readiness データが提供されます。これは、コンテナーの問題のトラブルシューティングに役立ちます。
  • Thanos Ruler のアラートルールが更新され、記録ルールおよびアラートルールが正しく評価されない場合にアラートが送信されます。今回の更新により、Thanos Ruler でのルールおよびアラートの評価が完了しない場合に重大アラートが失われなくなりました。
  • KubeStatefulSetUpdateNotRolledOut アラートは、ステートフルなセットがデプロイされる際に実行されないように更新されます。
  • KubeDaemonSetRolloutStuck アラートは、デーモンセットのロールアウトの進捗に対応するように更新されます。
  • 原因ベースのアラートの重大度が critical から warning に調整されます。
注記

Red Hat は、メトリクス、記録ルールまたはアラートルールの後方互換性を保証しません。

1.2.17.3. Prometheus ルールの検証

OpenShift Container Platform 4.6 では、検証用の受付プラグインを呼び出す Webhook を使用した Prometheus ルールの検証が導入されました。今回の機能拡張により、すべてのプロジェクトの PrometheusRule カスタムリソースが Prometheus Operator ルールの検証 API に対してチェックされるようになりました。

1.2.17.4. メトリクスおよびアラートルールが Thanos Querier に追加される

Thanos Querier は、単一のマルチテナントインターフェイスで、OpenShift Container Platform のコアメトリクスおよびユーザー定義プロジェクトのメトリクスを集約し、オプションでこれらの重複を排除します。OpenShift Container Platform 4.6 では、サービスモニターおよびアラートルールが Thanos Querier 用にデプロイされ、モニターリングスタックによる Thanos Querier のモニターリングが可能になりました。

1.2.17.5. 仮想マシンの Pending Changes アラートの更新

仮想マシンの Pending Changes アラートでより有用な情報が提供されるようになりました。(BZ#1862801)

1.2.18. Insights Operator

1.2.18.1. Insights Operator のデータ収集機能の拡張

OpenShift Container Platform 4.6 では、Insights Operator は以下の追加情報を収集します。

  • Pod の Disruption Budget (停止状態の予算)
  • ボリュームスナップショットのカスタムリソース定義
  • 正常ではない Pod からの最新の Pod ログ
  • イメージを使用するコンテナーの数および対応する Pod の存在期間など、Red Hat イメージの実行に関するデータ
  • クラッシュループするコンテナーがある Pod の JSON ダンプ
  • MachineSet リソースの設定
  • 匿名化された HostSubnet リソースの設定
  • MachineConfigPool リソースの設定
  • default および openshift-* プロジェクトの InstallPlan リソースおよびそれらのカウント
  • Openshift namespace からの ServiceAccount リソース統計

さらに、今回のリリースにより Insights Operator はすべてのクラスターノードについての情報を収集します。これに対し、以前のバージョンは正常でないノードについての情報のみ収集しました。

この追加情報により、Red Hat は、Red Hat OpenShift Cluster Manager で改善された修復手順を提供できるようになりました。

1.3. 主な技術上の変更点

OpenShift Container Platform 4.6 では、主に以下のような技術的な変更点が加えられています。

デフォルト Operator カタログがクラスターのバージョンごとに同梱される

OpenShift Container Platform 4.6 以降、Operator Lifecycle Manager (OLM) および OperatorHub によって使用される Red Hat が提供するデフォルトカタログが OpenShift Container Platform のマイナーバージョンに固有のインデックスイメージとして同梱されるようになりました。これにより、Operator プロバイダーはクラスターのバージョンごとに意図的に指定した範囲の Operator バージョンを提供できます。

Bundle Format に基づくこれらのインデックスイメージは、以前のバージョンの OpenShift Container Platform 4 向けに提供される、非推奨の Package Manifest Format をベースとする App Registry カタログイメージを置き換えます。OpenShift Container Platform 4.1 から 4.5 は、単一の App Registry カタログを引き続き共有します。

注記

OpenShift Container Platform 4.6 以降については、App Registry カタログイメージは Red Hat によって提供されませんが、Package Manifest Format に基づくカスタムカタログイメージは引き続きサポートされます。

Bundle Format およびインデックスイメージについての詳細は、Operator Framework パッケージ形式 について参照してください。

Operator のアップグレードに関する重要な要件

クラスター管理者は、OpenShift Container Platform 4.6 にアップグレードする前に、Operator Lifecycle Manager (OLM) で以前にインストールされたすべての Operator が最新チャネルの最新バージョンに更新されることを確認する必要があります。Operator の更新により、Operator は、クラスターのアップグレード時にデフォルトの OperatorHub カタログが OpenShift Container Platform 4.5 の APP Registry の使用から OpenShift Container Platform 4.6 の新規のイメージベースのカタログの使用に切り替わる際の有効なアップクレードパスを確保できます。

インストールされた Operator が最新チャネルにあり、自動または手動のいずれかの承認ストラテジーを使用してアップグレードされていることを確認する方法については、インストールされた Operator のアップグレード について参照してください。

追加リソース

  • OpenShift Container Platform 4.6 に必要な、デプロイされた Red Hat Integration コンポーネントの最小バージョン (Red Hat Fuse、Red Hat AMQ、および Red Hat 3scale を含む) の一覧については、以下の Red Hat ナレッジベースアーティクルを参照してください。

    https://access.redhat.com/articles/5423161

CNI ネットワークプロバイダーがクラスターノードにインストールされている OVS を使用する

OpenShift SDN および OVN-Kubernetes Container Network Interface (CNI) クラスターネットワークプロバイダーは、クラスターノードにインストールされている Open vSwitch (OVS) バージョンを使用するようになりました。以前のバージョンでは、OVS は各ノードのコンテナーで実行され、デーモンセットで管理されていました。ホスト OVS を使用すると、OVS のコンテナー化されたバージョンをアップグレードする際にダウンタイムが発生する可能性がなくなります。

非推奨の API 使用時の警告

非推奨の API に対するすべての呼び出しで、警告が client-go および oc に表示されるようになりました。非推奨の API を呼び出すと、ターゲットの Kubernetes 削除リリースおよび代替 API(該当する場合) を含む警告メッセージが返されます。

以下は例になります。 

warnings.go:67] batch/v1beta1 CronJob is deprecated in v1.22+, unavailable in v1.25+

これは、Kubernetes 1.19 に含まれる新機能です。

COPY および ADD ビルド命令の強化

OpenShift Container Platform ビルドの COPY および ADD 命令のパフォーマンスが向上しました。buildah における COPY および ADD 命令の初回の実装では、docker と比較してパフォーマンスの低下が確認されました。今回の機能拡張により、とくに大規模なソースリポジトリーについて、ビルドをより迅速に実行できるようになりました。(BZ#1833328)

Operator SDK v0.19.4

OpenShift Container Platform 4.6 では Operator SDK v0.19.4 をサポートし、主に以下のような技術的な変更点が加えられています。

  • Operator SDK は OpenShift Container Platform 全体と連携し、UBI-8 および Python 3 の使用に切り替わります。ダウンストリームのベースイメージは UBI-8 を使用し、Python 3 が含まれるようになりました。
  • run local が優先されるため、コマンド run --local が非推奨になりました。
  • run packagemanifests が優先されるため、コマンドの run --olm および --kubeconfig が非推奨になりました。
  • CRD を作成するか、または生成するコマンドについて、デフォルトの CRD バージョンが apiextensions.k8s.io/v1beta1 から apiextensions.k8s.io/v1 に変更されました。
  • --kubeconfig フラグが <run|cleanup> packagemanifests コマンドに追加されます。

Ansible ベースの Operator の拡張機能には、以下が含まれます。

  • Ansible Operator がサポートされるリリースとして利用可能になりました。
  • Ansible Operator に healthz エンドポイントおよび liveness プローブが含まれるようになりました。

Helm ベースの Operator の拡張機能には、以下が含まれます。

  • Helm Operator は、クラスタースコープのリリースリソースが変更される際に監視し、調整できます。
  • Helm Operator は、ネイティブ Kubernetes オブジェクトの 3 方向のストラテジーのマージのパッチを使用してロジックを調整できるようになりました。これにより、配列のパッチストラテジーが適切に反映され、適用されるようになりました。
  • Helm Operator のデフォルトの API バージョンが helm.operator-sdk/v1alpha1 に変更されました。
UBI 8 が OpenShift Container Platform のすべてのイメージに使用される

OpenShift Container Platform のすべてのイメージが、デフォルトで Universal Base Image (UBI) バージョン 8 を使用するようになりました。

Jenkins Node.js エージェントのアップグレード

デフォルトの Jenkins Node.js エージェントが Node.js バージョン 12 にアップグレードされました。

oc adm must-gather コマンドのデフォルトによって収集されない監査ログ

oc adm must-gather コマンドは、デフォルトで監査ログを収集しなくなりました。oc コマンドを使用して監査ログを収集するために追加のパラメーターを加える必要があります。以下は例になります。 

$ oc adm must-gather -- /usr/bin/gather_audit_logs
OpenShift Container Platform リリースのバイナリー sha256sum.txt.sig ファイルの名前が変更される

OpenShift Container Platform リリースに含まれる sha256sum.txt.sig ファイルの名前が sha256sum.txt.gpg に変更されました。このバイナリーファイルには、各インストーラーおよびクライアントバイナリーのハッシュが含まれており、これらはバイナリーの整合性を確認するために使用されます。

バイナリーファイルの名前を変更すると、GPG が sha256sum.txt を正しく検証できるようになりますが、これは、命名の競合により実行できませんでした。

1.4. 非推奨および削除された機能

以前のリリースで利用可能であった一部の機能が非推奨になるか、または削除されました。

非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、本製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。OpenShift Container Platform 4.6 で非推奨となり、削除された主な機能の最新の一覧については、以下の表を参照してください。非推奨になったか、または削除された機能の詳細情報は、表の後に記載されています。

以下の表では、機能は以下のステータスでマークされています。

  • GA: 一般公開機能
  • DEP: 非推奨機能
  • REM: 削除された機能
表1.1 非推奨および削除機能のトラッカー
機能OCP 4.4OCP 4.5OCP 4.6

サービスカタログ

DEP

REM

REM

テンプレートサービスブローカー

DEP

REM

REM

OperatorSource リソース

DEP

DEP

REM

CatalogSourceConfig リソース

DEP

REM

REM

Package Manifest Format (Operator Framework)

DEP

DEP

DEP

oc adm catalog build

DEP

DEP

DEP

v1beta1 CRD

GA

DEP

DEP

メータリング Operator

GA

GA

DEP

AWS EFS の外部プロビジョナー

REM

REM

REM

Microsoft Azure クラスターのクレデンシャルの作成

GA

GA

REM

1.4.1. 非推奨の機能

1.4.1.1. 独自の RHEL 7 コンピュートマシンの持ち込み

独自の (BYO) Red Hat Enterprise Linux (RHEL) 7 コンピュートマシンを持ち込むストラテジーは非推奨になりました。RHEL 7 コンピュートマシンのサポートは、OpenShift 4 の今後のリリースで削除される予定です。

1.4.1.2. メータリング Operator

メータリング Operator は非推奨となり、今後のリリースで削除されます。

1.4.2. 削除された機能

1.4.2.1. OperatorSource リソース

Operator Framework の Marketplace API の一部である OperatorSource リソースは複数の OpenShift Container Platform リリースで非推奨となり、削除されました。OpenShift Container Platform 4.6 では、openshift-marketplace namespace の OperatorHub のデフォルトカタログは polling 機能が有効にされている CatalogSource リソースのみを使用するようになりました。デフォルトのカタログは、参照されるインデックスイメージの新規更新を 15 分ごとにポーリングします。

1.4.2.2. MongoDB テンプレート

MongoDB ベースのサンプルがすべて置き換えられ、非推奨とされるか、または削除されました。

1.4.2.3. AWS EFS の外部プロビジョナー (テクノロジープレビュー)

Amazon Web Services (AWS) Elastic File System (EFS) テクノロジープレビュー機能が削除され、サポートされなくなりました。

1.4.2.4. TLS 検証で Common Name フィールドにフォールバックする

Subject Alternative Names がない場合に X.509 証明書の Common Name フィールドにホスト名としてフォールバックする動作は削除されました。証明書は、Subject Alternative Names フィールドを適切に設定する必要があります。

1.4.2.5. Microsoft Azure のクレデンシャルの作成のサポートが削除されました

OpenShift Container Platform 4.6.57 以降、Microsoft Azure クラスターのミントモードで Cloud Credential Operator (CCO) を使用するためのサポートが OpenShift Container Platform 4.6 から削除されました。この変更は、2022 年 6 月 30 日に Microsoft が Azure AD Graph API を廃止する予定であるためであり、z-stream 更新でサポートされているすべてのバージョンの OpenShift Container Platform にバックポートされます。

ミントモードを使用する以前にインストールされた Azure クラスターの場合、CCO は既存のシークレットを更新しようとします。シークレットに以前に作成されたアプリ登録サービスプリンシパルのクレデンシャルが含まれている場合、そのシークレットは kube-system/azure-credentials のシークレットの内容で更新されます。この動作は、パススルーモードに似ています。

クレデンシャルモードがデフォルト値の "" に設定されているクラスターの場合、更新された CCO は、ミントモードでの動作からパススルーモードでの動作に自動的に変更されます。クラスターでクレデンシャルモードが明示的にミントモード ("Mint") に設定されている場合は、値を "" または "Passthrough" に変更する必要があります。

注記

ミントモードで必要な Contributor のロールに加えて、変更されたアプリ登録サービスプリンシパルには、パススルーモードで使用される User Access Administrator のロールが必要になりました。

Azure AD Graph API は引き続き利用可能ですが、OpenShift Container Platform のアップグレードバージョンの CCO は、以前に作成されたアプリ登録サービスプリンシパルをクリーンアップしようとします。Azure AD Graph API を廃止する前にクラスターをアップグレードすると、リソースを手動でクリーンアップする必要がなくなる場合があります。

Azure AD Graph API が廃止された後、クラスターがミントモードをサポートしなくなったバージョンの OpenShift Container Platform にアップグレードされた場合、CCO は関連する credentialsrequest に OrphanedCloudResource 条件を設定しますが、エラーを致命的なものとして扱いません。この条件には、unable to clean up App Registration / Service Principal: <app_registration_name> と類似したメッセージが含まれます。Azure AD Graph API が廃止された後のクリーンアップでは、Azure CLI ツールまたは Azure Web コンソールを使用して手動で介入し、残りのアプリ登録サービスプリンシパルを削除する必要があります。

リソースを手動でクリーンアップするには、影響を受けるリソースを見つけて削除する必要があります。

  1. Azure CLI ツールを使用して、次のコマンドを実行し、 OrphanedCloudResource 条件メッセージから <app_registration_name> を使用するアプリ登録サービスプリンシパルをフィルター処理します。 

    $ az ad app list --filter "displayname eq '<app_registration_name>'" --query '[].objectId'

    出力例

    [
  "038c2538-7c40-49f5-abe5-f59c59c29244"
]

  2. 次のコマンドを実行して、アプリ登録サービスプリンシパルを削除します。 

    $ az ad app delete --id 038c2538-7c40-49f5-abe5-f59c59c29244
注記

リソースを手動でクリーンアップした後、CCO はリソースがクリーンアップされたことを確認できないため、OrphanedCloudResource 状態が持続します。

1.5. バグ修正

apiserver-auth

  • 以前のバージョンでは、一部の条件によって、Ingress Operator がその CA 証明書を router-certs シークレットにプッシュできず、Cluster Authentication Operator はヘルスチェックで証明書に信頼チェーンを構築せず、その状態は Degraded になり、アップグレードができなくなりました。CA は、デフォルトルーター CA のチェック時に default-ingress-cert 設定マップから常に組み込まれるようになり、Cluster Authentication Operator はアップグレードをブロックしなくなりました。(BZ#1866818)
  • 以前のバージョンでは、Operator で JSON 応答が生じるために、Cluster Authentication Operator は、サポートされていないログインフローが要求される際に Accept: application/json を無視する OIDC サーバーから返される HTML ページを解析できませんでした。その結果、Operator は IDP 設定を反映できませんでした。Cluster Authentication Operator は、それが要求されるフローをサポートしないという理由で、HTML ページが OIDC サーバーから返される際にエラーを出して失敗しなくなりました。(BZ#1877803)
  • 以前のバージョンでは、設定マップおよびシークレットは Cluster Authentication Operator によって適切に検証されませんでした。これにより、OAuth サーバーの新規デプロイメントが無効なファイルまたは不明なファイルでロールアウトされ、Pod がクラッシュする可能性がありました。設定マップおよびシークレットは Cluster Authentication Operator によって適切に検証されるようになり、参照される設定マップまたはシークレットに無効なデータが含まれる場合に新規デプロイメントがロールアウトされないようになりました。(BZ#1777137)

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

  • 以前のバージョンでは、ironic-image コンテナーの設定では、idrac-redfish-virtual-media ブートドライバーを有効にする設定が欠落していました。このため、ユーザーは Metal3 の idrac-virtual-media ブート URL を選択できませんでした。欠落していた ironic-image コンテナー設定が追加されるようになり、ユーザーは Metal3 の idrac-virtual-media URL を選択できるようになりました。(BZ#1858019)
  • 以前のバージョンでは、一部の Dell ファームウェアバージョンの Redfish を使用した永続的なブートの設定のサポートは中止されていました。Dell iDRAC ファームウェアをバージョン 4.20.20.20 に更新すると、問題は解決されます。(BZ#1828885)
  • 本リリースでは、多数のノードが同時に検査された場合に検査のタイムアウトが発生する問題は解決されています。(BZ#1830256)
  • 以前のバージョンでは、ironic-image コンテナーの設定では、idrac-redfish-virtual-media ブートドライバーを有効にする設定が欠落していました。このため、ユーザーは Metal3 の idrac-virtual-media ブート URL を選択できませんでした。欠落していた ironic-image コンテナー設定が追加されるようになり、ユーザーは Metal3 の idrac-virtual-media URL を選択できるようになりました。(BZ#1853302)
  • 以前のバージョンでは、ベアメタルの ironic イメージを提供するために使用される openshift-machine-api namespace の metal3 Pod の HTTPd コンテナーはディレクトリーの一覧表示を許可しました。今回のリリースにより、このコンテナーでディレクトリーの一覧が許可されなくなりました。(BZ#1859334)"

Build

  • buildah ライブラリーのエラーは、特定の HTTP エラーを無視する可能性があります。ビルドはターゲットレジストリーの一時的な問題により、イメージのプッシュに失敗する可能性がありました。今回のバグ修正により、イメージ Blob をプッシュする際にこれらのエラーに対応できるように buildah が更新されました。これにより、buildah は、アップストリームイメージが一時的に利用不可の場合にイメージをプッシュできなくなりました。(BZ#1816578)
  • 以前のバージョンでは、OpenShift Container Platform ビルドで使用されるコンテナーイメージ署名ポリシーにはローカルイメージの設定が含まれていませんでした。特定のレジストリーからのイメージのみを許可する場合、ローカルイメージの使用が許可されていないため、ビルドの postCommit スクリプトは失敗していました。コンテナーイメージ署名ポリシーが更新され、ローカルストレージ層を直接参照するイメージが常に許可されるようになりました。ビルドに postCommit フックが含まれる場合、ビルドが正常に実行されるようになりました。(BZ#1838372)
  • 以前のバージョンでは、Docker ストラテジービルドで使用される Dockerfile は ARG 命令を使用して Dockerfile で最初の FROM 命令が発生する前にビルド引数を定義する場合、その命令は、Dockerfile が Build または BuildConfig リソースで指定されたオーバーライドを組み込むように事前に処理されていると、ドロップされていました。それらの引数の参照はその後、事前に処理された Dockerfile を使用してイメージをビルドする際に適切に解決されませんでした。事前処理のロジックは、更新された Dockerfile コンテンツを生成する際に最初の FROM 命令の前に発生する ARG 命令を保持するように変更され、この問題が発生しなくなりました。(BZ#1842982)
  • 以前のバージョンでは、Buildah はイメージのイメージアーキテクチャーおよび OS フィールドを削除していました。これにより、生成されるイメージがアーキテクチャーおよび OS を特定できないため、一般的なコンテナーツールが失敗していました。今回のバグ修正では、明示的にオーバーライドされない限り、Buildah がイメージおよびアーキテクチャーを上書きするのを防ぐようになりました。これにより、イメージにアーキテクチャーおよび OS フィールドが常に設定され、イメージの不一致についての警告が表示されなくなります。(BZ#1858779)
  • 以前のバージョンでは、Dockerfile のビルドはビルド引数を正しく拡張しない場合があったために失敗していました。今回の更新で Dockerfile ビルド引数の処理が修正され、Dockerfile ビルドが正常に実行されるようになりました。(BZ#1839683)
  • 以前のバージョンでは、Buildah は Blob キャッシュからイメージを読み取る外部からの呼び出しを行い、Source-to-Image (S2I) ビルドが失敗しました。この問題は Buildah v1.14.11 で修正され、この修正は 4.6 の OpenShift Container Platform ビルドにも追加されました。(BZ#1844469)
  • 以前のバージョンでは、Buildah は COPY -from Dockerfile 命令でイメージを参照できませんでした。その結果、COPY –from=<image> が含まれるマルチステージ Dockerfile ビルドが失敗しました。Buildah が COPY -from 命令をサポートするバージョンに更新されました。これらの命令が含まれるビルドが正常に実行できるようになりました。(BZ#1844596)

クラウドコンピュート

  • 以前のバージョンでは、マシンセットの replicas フィールドが nil 値に設定されていると、Autoscaler はマシンセット内のレプリカの現在の数を判別することができませんでした。そのため、スケーリング操作を実行できませんでした。今回のリリースにより、Autoscaler は nil 値が設定されている場合に、ステータスの replicas フィールドで報告されるマシンセットで観察されるレプリカの最後の数を使用するようになりました。(BZ#1852061)
  • 以前のバージョンでは、同じタイプのノード間でメモリーの差異が 128 MB を超える場合、Autoscaler は各種の障害ドメイン全体でワークロードのバランスを取ることができませんでした。今回のリリースにより、メモリー差異の最大の制限値が 256 MB に増えました。(BZ#1824215)
  • 以前のバージョンでは、マシンセットの replicas フィールドにはデフォルト値がありませんでした。そのため、このフィールドがないと、マシンセットコントローラーは警告なしに失敗しました。replicas フィールドにはデフォルト値が使用されるようになりました。replicas フィールドが設定されていない場合、デフォルトの 1 つのレプリカが使用されます。(BZ#1844596)
  • 以前のバージョンでは、マシンヘルスチェックコントローラーはマシンの削除の試行前にマシンが削除されていることを確認しませんでした。その結果、コントローラーは複数の削除要求を送信する可能性があり、これにより誤ったロギングおよびイベントレポートが出される可能性がありました。マシンヘルスチェックコントローラーは、削除を試行する前にマシンが削除されているかどうかを確認するようになりました。その結果、重複ログおよびイベントは縮小されています。(BZ#1844986)
  • 以前のバージョンでは、マシン API Operator は stable 状態の場クラスター Operator マシン API を更新しました。その結果、リソースは複数の状態間ですぐに切り替わりました。リソースのステータスは、変更がロールアウトされた後にのみ変更されるようになりました。ステータスは stable のままになります。(BZ#1855839)
  • 以前のリリースでは、balanceSimilarNodeGroups、ignoreDaemonSetsUtilization、または skipNodesWithLocalStorage の ClusterAutoscaler リソース値を false に設定しても、クラスターの Autoscaler がデプロイされる際に登録されませんでした。これらの値は、クラスター Autoscaler のデプロイ時に適切に読み取られるようになりました。(BZ#1854907)
  • 稀な例として、重複するマシン API コントローラーインスタンスがデプロイされる可能性があります。その結果、クラスターはアクセスできなくなるマシンをリークする可能性がありました。リーダーの選択メカニズムがすべてのマシン API コンポーネントに追加され、重複インスタンスが作成されないようにできるようになりました。マシン API コントローラーは、指定される数のインスタンスのみを実行します。(BZ#1861896)
  • Red Hat Virtualization (RHV) クラスターでは、マシンの手動スケーリングが失敗する可能性がありました。Web コンソールまたは CLI からのマシンのスケーリングが機能するようになりました。(BZ#1817853)
  • 以前のバージョンでは、must-gather は BareMetalHost レコードを収集しませんでした。その結果、デバッグ情報が不完全になる可能性がありました。BareMetalHost レコードが must-gather によって収集されるようになりました。(BZ#1841886)
  • 以前のバージョンでは、Azure で実行されるクラスターで、コンピュートマシンがインストール時に Failed ステージに変換されました。そのため、仮想マシンは作成後に認識されませんでした。これにより、マシンへのアクセスを試みると、ログに多数のエラーがメッセージが含まれ、仮想マシンが正常に起動した後でも失敗する可能性があります。修正として、Creating 状態のマシンはすでに作成済みとして識別されるようになりました。ログに含まれるエラーの数は少なくなり、マシンが失敗する可能性は低くなります。(BZ#1836141)
  • 以前のバージョンでは、マシンヘルスチェックは spec.maxUnhealthy の負の値を受け入れる可能性がありました。そのため、調整を試行するたびに、負の値で多数のイベントが作成されました。spec.maxUnhealthy の負の値。現時点では 0 として処理されます。これにより、誤ったログメッセージの数が減ります。(BZ#1862556)

Cloud Credential Operator

  • 以前のバージョンでは、OpenShift Container Platform バージョン 4.5 からバージョン 4.6 にアップグレードする際に、一部のフィールドが 4.6 のデフォルト値に更新されました。これは、4.5 フィールドの値が保持されないため、4.6 から 4.5 にダウングレードする機能に影響を与えました。フィールドを 4.5 で指定されないままにする代わりに、今回のバグ修正により 4.5 の値が明示的に保持され、それがダウングレードの試行時にデフォルト値として再度指定できるようになりました。4.6 から 4.5 へのダウングレードが正常に実行できるようになりました。(BZ#1868376)
  • 以前のバージョンでは、Cloud Credential Operator のリーダーの選択では controller-runtime からのデフォルト値を使用し、2 秒ごとに etcd への書き込みを行いました。本リリースでは、カスタムのリーダー選択が実装され、90 秒ごとにのみ書き込みが行われ、通常のシャットダウン時にロックがすぐに解放されるようになりました。(BZ#1858403)

クラスターバージョン Operator

  • Cluster Version Operator は、HTTPS ではなく HTTP を使用するメトリクスを提供し、暗号化されていないデータが原因で中間者攻撃の対象になりました。Cluster Version Operator は HTTPS を使用してメトリクスを提供し、データは暗号化されるようになりました。(BZ#1809195)
  • クラスター管理者が クラスターバージョンのオーバーライドを設定している場合、アップグレードプロセスは停止します。今回のリリースより、オーバーライドが設定されるとアップグレードがブロックされるようになりました。アップグレードは、管理者がオーバーライドを削除するまで開始されません。(BZ#1822844)
  • プロキシー設定の trustedCA プロパティーによって参照される設定マップ から信頼される CA を読み込むために使用される Cluster Version Operator。参照される設定マップはユーザーが維持し、ユーザー設定の破損した証明書により Operator のプロキシーへのアクセスが中断されました。今回のリリースにより、Operator は、プロキシー設定の参照される trustedCA 設定マップが有効になるとネットワーク Operator が設定する openshift-config-managed/trusted-ca-bundle から trustedCA 設定を読み込むようになりました。(BZ#1797123)
  • HTTPS 署名はシリアル化されたストアを取得し、これにより Cluster Version Operator がタスクを完了する前にタイムアウトする可能性がありました。今回のリリースより、外部 HTTPS 署名の取得が並行して行われ、すべてのストアが試行されるようになりました。(BZ#1840343)
  • 以前のバージョンでは、オプション --to-image を使用した z-stream クラスターのアップグレード (例: oc adm upgrade --to-image) 時に、Cluster Version Operator は、検証目的で現行バージョンではなく、アップグレードするクラスターのバージョンを使用していました。これにより、z-stream のアップグレードが失敗しました。Cluster Version Operator に Upgradeable=false が設定されている場合でも、--to-image オプションを使用して z-stream クラスターのアップグレードが可能になりました。(BZ#1822513)
  • 以前のバージョンでは、Cluster Version Operator (CVO) は Pod 仕様の shareProcessNamespace パラメーターを同期しませんでした。これにより、レジストリー Operator は shareProcessNamespace 設定を更新しませんでした。CVO は shareProcessNamespace、DNSPolicy、および TerminationGracePeriodSeconds パラメーターを同期し、レジストリー Operator の更新の問題を修正するようになりました。(BZ#1866554)

コンソール kubevirt プラグイン

  • 以前のリリースでは、同じ NIC プロファイルを持つ NIC を正常にインポートできませんでした。または、誤ったネットワークが選択されていました。Web コンソールは、ユーザーに対し、このような NIC に Pod ネットワークではなく同じネットワークを強制的に選択させるようになりました。(BZ#1852473)
  • 仮想マシンの一覧が virtualmachineimports データのレンダリングを待機するため、仮想マシンは管理者以外のユーザーでログインしている場合に表示されませんでした。仮想マシンの一覧が正しくレンダリングされるようになりました。(BZ#1843780)
  • Create VM ウィザードの Edit Disk モーダルでは、クローン作成された PVC namespace を反映しませんでした。別の namespace から datavolume ディスクを編集することはできませんでした。ディスクモーダルは、datavolume ディスクの正しい namespace を適切に登録するようになりました。(BZ#1859518)
  • datavolume 名がハードコーディングされているため、仮想マシンおよびテンプレートで URL ソースの参照時に同じ名前を使用することはできませんでした。自動生成された一意の文字列が datavolume 名に追加され、新しい仮想マシンおよびテンプレートが同じ名前を持てるようになりました。(BZ#1860936)
  • ネットワーク使用率データには、データの配列が空であるために Not Available が表示されました。チェックが実装され、空の配列がデータなしとして解釈されるようになりました。(BZ#1850438)
  • 今回のリリースにより、Import VM 機能が Web コンソールの Developer パースペクティブから削除されました。(BZ#1876377)

Console Metal3 プラグイン

  • EI が最新バージョンの検索をするため、ユーザーインターフェイスは古いノードメンテナーンス CRD を検出しませんでした。そのため、Node Maintenance アクションでは、古い NodeMaintenance CR (ある場合) が見落されていました。UI は両方の NodeMaintenance CR を監視するようになりました。(BZ#1837156)
  • ユーザーインターフェイスは正常なシャットダウンを正しく評価せず、コンソールのシャットダウン時に誤った警告が表示されることがありました。インターフェイスはノード Pod の読み込みを待機し、シャットダウン時に正しい警告が表示されるようになりました。(BZ#1872893)

コンテナー

  • 以前のバージョンでは、ビルドコンテキストからコンテンツをコピーする COPY または ADD 命令を処理するロジックは、.dockerignore ファイルが存在する場合に効率的にフィルターされませんでした。COPY および ADD の速度は、ソースの場所のそれぞれの項目を宛先にコピーする必要があるかどうかを評価する累積するオーバーヘッドによって大幅に遅くなります。今回のバグ修正により、ロジックが書き換えられ、.dockerignore ファイルが存在する場合でも、ビルド時に COPY および ADD 命令を処理する速度が大幅に遅くなることはなくなりました。(BZ#1828119, BZ#1813258)
  • 以前のバージョンでは、ビルダーのロジックが新規レイヤーの内容を 2 回計算するため、イメージのビルドおよびプッシュは error reading blob from source のエラーメッセージを出して失敗しました。レイヤーコンテンツをキャッシュするロジックは、それらの計算の結果が一貫性を維持するかどうかに依存します。2 つの計算の間で新しいレイヤーのコンテンツが変更された場合、キャッシュは必要な時にレイヤーの内容を提供することができません。新規レイヤーのコンテンツは 2 回計算されなくなり、イメージのビルドとプッシュは失敗しなくなりました。(BZ#1720730)

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

  • 以前のバージョンでは、Topology ビューで Knative アプリケーションを削除しようとすると、存在しない Knative ルート に関する誤検出エラーが報告されました。この問題は修正され、エラーは表示されなくなりました。(BZ#1866214)
  • 以前のバージョンでは、Web コンソールの Developer パースペクティブでセキュアでないレジストリーからのイメージをインポートできませんでした。今回のバグ修正により、ユーザーが Deploy image フォームでセキュアではないレジストリーを使用できるようにチェックボックスが追加されました。(BZ#1826740)
  • ユーザーがアプリケーションを作成する From Catalog オプションを選択した場合、Developer Catalog には、アプリケーションを作成するためにテンプレートの一覧ではなく空のページが表示されました。これは 1.18.0 Jaeger Operator のインストール時に発生しました。この問題は修正され、テンプレートが予想通りに表示されるようになりました。(BZ#1845279)
  • Web コンソールの Developer パースペクティブの Pipeline Builder で Pipeline の並列タスクを削除する際に、インターフェイスでは並列タスクに接続されたタスクの再編成を正しく行わず、孤立したタスクが作成されました。今回の修正により、削除された並列タスクに接続されているタスクが元の Pipeline に再接続されるようになりました。(BZ#1856155)
  • ユーザーがサイドパネルを同時に開いた状態で Web コンソールを使用して Pipeline の作成をキャンセルした場合、Web コンソールは JavaScript 例外を出してクラッシュしました。これは、内部の状態の処理を改善することで修正されました。(BZ#1856267)
  • 必要なパーミッションを持つユーザーは、別のプロジェクトからイメージを取得したり、デプロイしたりできませんでした。この問題を修正するために、必要なロールバインディングが作成されました。(BZ#1843222)
  • Import from Git 機能を使用して Git リポジトリーからアプリケーションをデプロイしようとすると、web コンソールの Developer パースペクティブは、クラスターから到達可能なプライベートリポジトリーについて Git repository is not reachable という誤検出エラーを報告していました。これは、プライベートリポジトリーをエラーメッセージのクラスターで利用可能にすることについての情報を追加して修正されています。(BZ#1877739)
  • Go アプリケーションが web コンソールの Developer パースペクティブで作成されても、アプリケーションへのルートは作成されませんでした。これは、build-tools のバグと誤って設定されたポートによって引き起こされました。この問題は、ユーザーが指定するポートまたはデフォルトのポート 8080 をターゲットポートとして選択することで修正されます。(BZ#1874817)
  • Import from Git 機能を使用してアプリケーションを作成すると、Web コンソールからのアプリケーションの Git リポジトリーの後続の変更を加えることができませんでした。これは、Git リポジトリー URL の後続の編集でアプリケーション名を変更することで生じました。これは、アプリケーションの Git リポジトリー URL を編集する際にアプリケーション名を読み取り専用にすることで修正されました。(BZ#1873095)
  • 以前のバージョンでは、管理者またはプロジェクトの一覧の権限を持たないユーザーには、プロジェクトのメトリクスが表示されませんでした。今回のバグ修正により、クラスターメトリクスへのアクセス時にユーザー権限のチェックが削除されるようになりました。(BZ#1842875)
  • user@example.com など、ユーザー名に @ 文字が含まれるユーザーは、web コンソールの Developer パースペクティブから Pipeline を起動できませんでした。これは、Kubernetes ラベルの制限によって生じました。この問題は、Started by メタデータを Kubernetes ラベルから Kubernetes アノテーションに移動することで修正されました。(BZ#1868653)
  • 以前のバージョンでは、ユーザーがメトリクスを選択した場合、QueryEditor はクエリーを表示していました。ただし、ユーザーがクエリーを削除または変更し、同じメトリクスを再度選択した場合、QueryEditor は更新されません。今回の修正により、ユーザーがクエリーをクリアし、同じクエリーの選択を試みると、クエリー入力テキストエリアにクエリーが表示されるようになりました。(BZ#1843387)
  • Che Workspace Operator は Workspace リソースのサポートを削除し、これを DevWorkspace CRD に置き換えました。そのため、コマンドラインターミナルは最新の Che Workspace Operator で有効にされませんでした。今回の修正により、OpenShift コマンドラインターミナルが DevWorkspace リソースを使用するように移行しました。コマンドラインターミナルは、Che Workspace Operator のインストール時に OpenShift コンソールで有効にされます。(BZ#1844938)
  • 以前のバージョンでは、トラフィックが複数のリビジョンに分散される場合、Knative サービスのルートデコレーターは、ユーザーをリビジョン固有のルートにリダイレクトしていました。ルートデコレーターは、Knative ベースサービスルートを常に参照するように更新されました。(BZ#1860768)
  • 以前のバージョンでは、ユーザーが外部プライベートコンテナーレジストリーのシークレットを追加し、レジストリーからコンテナーイメージをインポートすると、Pod が起動しませんでした。そのため、デプロイメントは、サービスアカウントまたはデプロイメントが手動で更新されるまで停止しました。今回のバグ修正により、新規デプロイメントは内部コンテナーレジストリーを使用して Pod を起動できるようになりました。今回のバグ修正により、ユーザーは、サービスアカウントまたはデプロイメントへの追加の変更なしに、外部のプライベートコンテナーレジストリーからコンテナーイメージをインポートできるようになりました。(BZ#1926340)
  • コンソールでは、仕様の resources および serviceAccountName フィールドを使用する KafkaSource オブジェクトの以前のバージョンを使用していました。KafkaSource オブジェクトの v1beta1 バージョンでは、ユーザーが v1beta1 バージョンで KafkaSource オブジェクトを作成できないために、これらのフィールドが削除されました。この問題は修正され、ユーザーは v1beta1 バージョンで KafkaSource オブジェクトを作成できるようになりました。(BZ#1892695)
  • 以前のバージョンでは、helm リリースをインスタンス化するためにチャートをダウンロードする際に相対チャート URL にアクセスできませんでした。これは、Helm チャートリポジトリーで参照されるリモートリポジトリーからの index.yaml ファイルがフェッチされ、そのまま使用されるために生じました。これらのインデックスファイルには、相対チャート URL が含まれているものもあります。この問題は相対チャート URL を絶対 URL に変換することによって修正され、これによりチャート URL にアクセスできるようになりました。(BZ#1916406)
  • 以前のバージョンでは、ユーザーは Topology ビューで Knative サービスおよびソースを表示できませんでした。これは、Null Pointer Exception (NPE) が原因でトリガーに Knative サービスと In-Memory Channe の両方がサブスクライバーとして設定されていたために生じました。この問題は、Null Pointer Exception を修正することで解決され、Knative データモデルは適切なデータを返し、Knative リソースは Topology ビューに適切に表示されます。(BZ#1907827)
  • 以前のバージョンでは、API サーバーはリソースの作成に失敗し、リソースクォータのリソースの更新中の競合により 409 のステータスコードを返すことがありました。この問題は修正され、{product title} Web コンソールは 409 のステータスコードを受信する間に要求を再試行しようとします。要求を完了するには、最大 3 回試行が行われます。これは通常は十分な回数です。409 が継続的に発生する場合、コンソールにエラーが表示されます。(BZ#1928230)
  • 以前のバージョンでは、チャートリポジトリー httpClient() はプロキシー環境変数を考慮しないため、開発者カタログに helm チャートは表示されませんでした。この問題は修正され、helm チャートが開発者カタログに表示されるようになりました。(BZ#1919138)
  • テクノロジープレビューのバッジが Eventing ユーザーインターフェイスに表示されます (GA リリース用)。テクノロジープレビューのバッジが Eventing ユーザーインターフェイスから削除されるようになりました。(BZ#1899382)
  • 以前のバージョンでは、アプリケーションは相関 Pod データがデプロイメント設定で利用できない場合にクラッシュしました。これは、コンソールのデプロイメントがデプロイメント設定が読み込まれるとすぐに表示される Pod ステータスドーナツの 2 セットのデータを取得するためです。API が 250 を超える Pod を返す場合、一部の情報は省略され、利用できません。この問題は修正され、プロジェクトに 250 を超える Pod が含まれる場合でも Pod データを利用できるため、DeploymentConfig の詳細ページがクラッシュしなくなります。(BZ#1921603)
  • 以前のバージョンでは、トリガー、サブスクリプション、チャネル、および IMC イベントソースに対応する静的モデルはベータ API バージョンを使用していました。Serverless 0.10 リリースにより、イベントソースでサポートされる最新バージョンが v1 バージョンに更新されました。今回のバグ修正により、ユーザーインターフェイスモデルが更新され、サポートされている最新バージョンを参照するようになりました。(BZ#1896625)
  • 以前のバージョンでは、条件付きタスクが失敗すると、完了したパイプライン実行で、失敗した条件付きタスクごとに永続的な保留状態のタスクが表示されました。この問題は、失敗した条件付きタスクを無効にし、省略 (skipped) アイコンをそれらのタスクに追加することで修正されています。これにより、パイプライン実行の状態をより明確に把握することができます。(BZ#1916378)
  • 以前のバージョンでは、ユーザーのパーミッションが不十分であるために、他のプロジェクトからイメージをプルするためのユーザーのアクセスは拒否されました。今回のバグ修正により、ロールバインディングについてのすべてのユーザーインターフェイスのチェックが削除され、ユーザーのコマンドラインの使用に役立つ oc コマンドアラートが表示されるようになりました。今回のバグ修正により、ユーザーの異なる namespace からのイメージの作成がブロックされなくなり、他のプロジェクトからイメージをデプロイできるようになりました。(BZ#1933727)
  • サンプルアプリケーションの作成時に、Developer パースペクティブは、相互に依存し、特定の順序で実行する必要のある複数のリソースを作成します。以前のバージョンでは、受付プラグインはこれらのリソースのいずれも確認できず、Developer パースペクティブでサンプルアプリケーションを生成できないことがありました。この問題は修正されています。このコードはリソースを必要な順序で作成するため、サンプルアプリケーションの作成の安定性が高くなります。(BZ#1933666)
  • 以前のバージョンでは、ユーザーは Developer パースペクティブからプライベートサービスとして Knative サービスを作成できませんでした。この問題は、networking.knative.dev/visibility': 'cluster-local ラベルを更新して修正されています。(BZ#1978159)
  • 以前のバージョンでは、OpenShift Container Platform Web コンソールで Bitbucket リポジトリーを使用してデプロイメント用に作成されたトポロジー URL は、スラッシュ文字を含むブランチ名が含まれている場合は機能しませんでした。これは Bitbucket API (BCLOUD-9969) の問題が原因でした。今回のリリースでは、この問題が緩和されています。ブランチ名にスラッシュが含まれている場合、トポロジー URL はリポジトリーのデフォルトのブランチページを指します。(BZ#1972694)
  • 以前のバージョンでは、プライベートリポジトリーの git Import フローで作成されたパイプラインは実行できませんでした。この問題は、パイプラインの ServiceAccount オブジェクトのアノテーションに秘密の名前を追加し、提供された秘密にパイプライン固有のアノテーションを追加することで修正されています。(BZ#1970984)

DNS

  • 以前のバージョンでは、CoreDNS 1.6.6 の実行時に、断続的に無効なメモリーアドレスまたは nil ポインター逆参照エラーが発生し、Kuby API アクセスのタイムアウトが生じていました。これは、Endpoint Tombstones でエラーを正しく処理することで修正されるようになりました。CoreDNS は、断続的なパニックなしに意図されたとおりに動作するようになりました。(BZ#1868315)
  • 以前のバージョンでは、DNS Operator は API によって設定されたデフォルト値への応答として、DNS および Service オブジェクトの更新を繰り返し試行していました。今回の更新により、DNS Operator がそれによって指定されていない値を DNS および Service オブジェクトの値に等しい値として見なすようになりました。そのため、DNS Operator は API のデフォルト値への応答として、DNS または Service オブジェクトを更新しなくなりました。(BZ#1842741)

etcd

  • 以前のバージョンでは、ETCDCTL_ENDPOINTS のブートストラップのエンドポイントは、ブートストラップノードの削除後に削除されました。そのため、etcdctl コマンドには予期しないエラーが表示されました。ブートストラップエンドポイントは ETCDCTL_ENDPOINTS に追加されなくなったため、 etcdctl コマンドには、ブートストラップエンドポイントに関連するエラーが表示されなくなりました。(BZ#1835238)

イメージ

  • 以前のバージョンでは、マニフェスト一覧でダイジェストを使用したイメージのインポートが失敗しました。今回の修正により、マニフェスト一覧内で選択したマニフェストのダイジェストを使用して、マニフェストの一覧からマニフェストへの変換が修正されました。そのため、マニフェスト一覧のダイジェストによるインポートが予想通りに機能するようになりました。(BZ#1751258)

イメージレジストリー

  • 以前のバージョンでは、一部の内部パッケージは内部エラー構造を使用していたため、null ポインターの問題が生じました。今回のリリースより、内部エラーインターフェイスが返され、nil エラーが正しく変換されるようになりました。(BZ#1815562)
  • Operator は空の場合に httpSecrets を生成しなかったため、値が正しく設定されませんでした。今回のリリースにより、Operator は httpSecret を生成し、設定ファイルの作成時にこれをすべてのレプリカに使用するようになりました。(BZ#1824834)
  • 以前のバージョンでは、イメージプルーナーが無効になると無効なアラートが表示されました。このアラートは削除されました。(BZ#1845642)
  • レジストリー Operator タイプのアサーションは変数に対して 2 回実行され、2 回目に結果はチェックされませんでした。これにより、誤ったアサーションが生じ、パニック状態が生じました。チェックされたタイプのアサーションが使用され、Operator でパニックが発生しなくなりました。(BZ#1879426)
  • 以前のバージョンでは、Operator ブートストラップの storageManaged 設定が true に設定され、ユーザーが設定ファイルを手動で更新する場合に競合が生じました。追加の設定フィールド、spec.storage.storageManagementState が作成されました。ユーザーは Managed または Unmanaged を指定でき、Operator はその設定を反映します。(BZ#1833109)
  • コンテンツがストレージに書き込まれる際に OpenStack のイメージレジストリーを削除すると、イメージレジストリーのストレージが削除されず、409 HTTP の戻りコードエラーがログに記録されました。今回のバグ修正により、ストレージを削除する前にストレージの内容が削除されるようになりました。イメージレジストリー Operator が削除されると、そのストレージも削除されるようになりました。(BZ#1835770)
  • OpenStack でのインストール時に、イメージレジストリー Operator のブートストラッププロセスで Swift ストレージにアクセスできない場合、ブートストラップは完了しませんでした。これにより、イメージレジストリー設定リソースの作成に失敗し、修正がブロックされたり、その設定が変更されました。今回のバグ修正により、Swift ストレージへのアクセス時に問題が発生した場合に、ブートストラップでエラーが発生することが回避されるようになりました。エラーがある場合に、それはログに記録され、ブートストラップが完了し、設定リソースが作成されるようになります。イメージレジストリー Operator の柔軟性が高くなり、Swift ストレージにアクセスできない場合、PVC を使用して内部イメージレジストリーをブートストラップするようになりました。(BZ#1846263)
  • イメージレジストリー Operator は、Azure エンドポイントの呼び出しを過剰に実行することを防ぎます。Azure はクォータを適用し、Operator は以前のバージョンでは、ストレージのアカウントキーについて絶えずクエリーしていました。今回のバグ修正により、キーが必要となるたびにキーの取得時にリモートになることを防ぐために、キーが設定される期間ローカルにキャッシュされるようになりました。(BZ#1853734)
  • 以前のバージョンでは、Operator は、ジョブが失敗状態になる可能性があっても、Operator のステータスのレポート時に、実行されているジョブを正常と解釈していました。Operator のステータスを報告する際に実行中のジョブが無視されるようになりました。(BZ#1857684)
  • イメージレジストリーのパージプロセスは、ディレクトリーを 2 回一覧表示するために S3 ストレージでの実行時に失敗していました。ディレクトリーは 1 回のみ一覧表示され、イメージのパージプロセスが正常に完了するようになりました。(BZ#1861304)
  • 以前のバージョンでは、イメージレジストリー Operator が削除されると、プルーナージョブは、存在しないレジストリーに到達できずに失敗しました。プルーナージョブは etcd オブジェクトのみを削除し、削除されている場合はレジストリーへの ping を試行しなくなりました。(BZ#1867792)
  • ユーザーがバケット名を手動で追加している場合、Operator はバケットを作成しませんでした。今回のリリースより、Operator はユーザーによって指定される名前に基づいてバケットを正常に作成できるようになりました。(BZ31875013)
  • 以前のバージョンでは、イメージレジストリー Operator は Too large resource version エラーメッセージが出されると、クラスターからイベントを取得できませんでした。今回のリリースにより、client-go ライブラリーが更新され、Operator が Too large resource version エラーメッセージから回復できるようにリフレクターが修正されました。(BZ#1880354)
  • 以前のバージョンでは、Image Registry Operator 設定ファイルの spec.requests.read/write.maxWaitInQueue に指定される値は検証されませんでした。指定された値が期間として解析できない文字列である場合、変更は適用されず、誤った値に関するメッセージが繰り返しログに記録されました。今回のリリースにより、検証が追加され、ユーザーがこのフィールドに無効な値を指定できなくなりました。(BZ#1833245)
  • 以前のバージョンでは、イメージのプルーニング時にイメージオブジェクト間の依存関係の追跡の速度が遅くなりました。イメージのプルーニングが完了するまでに長い時間がかかることがありました。基礎となるイメージプルーニングのメカニズムが再設計されました。今回のリリースより、イメージのプルーニングの速度が上がり、並列処理が強化されました。(BZ#1860163)

インストーラー

  • 以前のバージョンでは、マシンが resourcePoolPath の取得を試行する際に、マシンは複数のリソースプールを検索し、正しいものを解決できませんでした。今回のリリースにより、resourcePoolPath 情報でマシンセットに追加されたプロパティーを使用して、正しいものを解決できるようになりました。(BZ#1852545)
  • 以前のバージョンでは、ノードのサブネットのプロビジョニング時に DHCP 割り当てプールの最後を計算する際にハードコーディングされた値が設定されました。これにより、マシン CIDR が 18 よりも小さい OpenStack の OpenShift Container Platform クラスターにデプロイする際にエラーが生じました。今回のバグ修正によりノード数のハードコーディングが削除され、代わりに DHCP 割り当てプールの最後が動的に計算されるようになりました。任意の長さのマシン CIDR で OpenStack にクラスターをデプロイすることができるようになりました (すべての必要なノードに十分な大きさである場合)。(BZ#1871048)
  • 以前のバージョンでは、一部の利用可能なネットワークは、oVirt ネットワークの解析に影響を与える ovirt-engine-sdk-go API エラーにより、クラスターのインストール時に表示されませんでした。この問題は解決されています。(BZ#1838559)
  • 以前のバージョンでは、vSphere web コンソールウィザードには、OpaqueNetwork も有効なオプションであるものの、タイプ Network および DistributedVirtualPortgroup のネットワークのみが表示されました。OpaqueNetwork がウィザードでオプションとして加えられ、このタイプのネットワークも選択できるようになりました。(BZ#1844103)
  • 以前のバージョンでは、Manila Operator はカスタムの自己署名証明書をサポートしなかったため、Manila Operator は自己署名証明書を使用する一部の環境で Manila CSI ドライバーをデプロイできませんでした。Operator はユーザーが指定する CA 証明書をシステム設定マップからフェッチし、ドライバーのコンテナーにマウントし、ドライバーの設定を更新するようになりました。その結果、Manila Operator は自己署名証明書が設定された環境に Manila CSI ドライバーをデプロイし、これを管理できます。(BZ#1839226)
  • 以前のバージョンでは、platform.aws.userTags パラメーターを name または kubernetes.io/cluster/ タグをインストールプログラムが作成するリソースに追加するように設定すると、マシン API が既存のコントロールプレーンマシンを識別できず、別のコントロールプレーンホストのセットを作成しました。これにより、etcd クラスターのメンバーシップに関する問題が生じました。platform.aws.userTags パラメーターにエラーが発生しやすいタグを設定できなくなり、クラスターに追加のコントロールプレーンホストや 障害のある etcd クラスターが含まれる可能性は低くなります。(BZ#1862209)
  • 以前のバージョンでは、ヘルスチェックプローブは、ユーザーによってプロビジョニングされるインフラストラクチャーの Azure クラスターにデプロイされるロードバランサーに対して定義されませんでした。ロードバランサーが定義されていないため、それらは API エンドポイントが利用不可になる時を検知せず、トラフィックをそれらの利用不可のエンドポイントに転送するため、クライアントの障害が発生していました。今回のリリースより、ヘルスチェックプローブがロードバランサーで使用され、API エンドポイントが利用できない場合に正しく検知され、オフラインノードへのトラフィックのルーティングを停止するようになりました。(BZ#1836016)
  • 以前のバージョンでは、インストールプログラムは * を proxy.noProxy フィールドの有効な値として受け入れず、インストール時に * に設定される no proxy の設定クラスターを作成できませんでした。インストールプログラムは、* をパラメーターの有効な値として受け入れるようになり、インストール時に no proxy を * に設定できるようになりました。(BZ#1877486)
  • 以前のバージョンでは、GCP にクラスターをインストールすると、US が場所として常に使用されていましたが、米国外の一部のリージョンにクラスターをインストールすることができませんでした。インストールプログラムは、指定するリージョンに適切な場所を設定し、インストールが他の場所で正常に実行されるようになりました。(BZ#1871030)
  • 以前のバージョンでは、インストーラーでプロビジョニングされるインフラストラクチャーを使用して vSphere にクラスターをインストールしている場合、同じ IP アドレスを Ingress と API に割り当てることができました。これにより、ブートストラップマシンとコントロールプレーンマシンのいずれかに同じ IP アドレスが設定される可能性がありました。インストールプログラムは、IP アドレスが異なること、コントロールプレーンとブートストラップマシンに固有の IP アドレスがあることを検証するようになりました。(BZ#1853859)
  • 以前のバージョンでは、インターフェイスで新規の DHCP4 または DHCP6 リースの取得時に、 local-dns-prepender は resolv.conf ファイルを、クラスターに必要なすべてのリゾルバーを含めるように更新しませんでした。dhcp4-change および dhcp6-change のアクションタイプは、常に local-dns-prepender に更新を開始させます (BZ#1866534)。
  • 以前のバージョンでは、クラスターを asia-northeast3、asia-southeast-2、us-west3、および us-west4 などの GCP リージョンにデプロイできませんでした。これらのリージョンを使用できるようになりました。(BZ#1847549)
  • 以前のリリースでは、OpenStack インストールプログラムは InstanceID() 関数に一貫性のない出力形式を使用していました。インスタンス ID はメタデータから取得するか、要求ををサーバーに送信して取得します。後者の場合、結果には必ず/接頭辞が付き、これが正しい形式になります。インスタンス ID がメタデータから取られる場合、システムはノードの有無を確認できず、エラーによって失敗しました。メタデータ形式には '/' 接頭辞も含まれるようになり、ID 形式は常に正しいため、システムが常にノードが存在を常に検証できるようになりました。(BZ#1850149)
  • 以前のバージョンでは、FIPS がクラスターに対して有効にされている場合、ベアメタルのインストーラーでプロビジョニングされるインフラストラクチャープラットフォームのプロビジョニングサービスは失敗しました。今回の更新により、FIPS が有効になり、インストールが正常に完了すると、プロビジョニングサービスは予想通りに実行されます。(BZ#1804232)
  • 以前のバージョンでは、プロビジョニングネットワークがクラスターのプロビジョニング VIP を含むサブネット全体を使用できるように DHCP 範囲を設定できました。そのため、ブートストラップ仮想マシン IP およびクラスターのプロビジョニング IP が割り当てられず、インストールに失敗しました。今回の修正により、VIP が検証され、それらが DHCP 範囲と重複しないようになりました。(BZ#1843587)
  • 以前のリリースでは、証明書の後に 2 つの行末文字シーケンスが続くと、インストールが失敗しました。今回の更新により、認証局 (CA) 証明書の信頼バンドルパーサーが修正され、グラフィック文字を無視するようになりました。そのため、CA 証明書信頼バンドルでは、証明書の前後、または証明書の中に入る任意の数の行末文字シーケンスを使用できるようになりました。(BZ#1813354)
  • 以前のバージョンでは、インタラクティブなインストーラープロンプトがクラスターの ExternalNetwork リソースを要求すると、考えられるすべてのネットワークの選択肢が一覧表示されました。これには無効なオプションが含まれました。今回の更新により、インタラクティブなインストーラーが可能なオプションをフィルターし、外部ネットワークのみを一覧表示するようになりました。(BZ#1881532)
  • 以前のバージョンでは、ベアメタルの kube-apiserver ヘルスチェックプローブはハードコーディングされた IPv4 アドレスを使用してロードバランサーと通信しました。今回の更新により、ヘルスチェックが localhost を使用するように修正されました。これは IPv4 と IPv6 ケースのいずれにも対応します。さらに、healthz ではなく、API サーバーの readyz エンドポイントがチェックされます。(BZ#1847082)
  • 依存するすべてのステップを一覧表示しない Terraform 手順により、Red Hat OpenStack Platform (RHOSP) 上のクラスターで競合状態が発生していました。これにより、Terraform ジョブが Resource not found エラーメッセージを出して失敗することがありました。この手順は、競合状態を回避するために depends_on として一覧表示されるようになりました。(BZ#1734460)
  • 以前のバージョンでは、クラスター API はマシンの更新前に RHOSP フレーバーを検証しませんでした。その結果、フレーバーが無効であるマシンは起動できませんでした。フレーバーは、マシンの更新前に検証され、無効なフレーバーを持つマシンはすぐにエラーを返すようになりました。(BZ#1820421)
  • 以前のバージョンでは、それらの名前にピリオド (.) が含まれる RHOSP のクラスターは、インストールのブートストラップフェーズで失敗していました。RHOSP のクラスター名でピリオドは許可されなくなりました。クラスター名にピリオドが含まれる場合、インストールプロセスの初期段階でエラーメッセージが生成されます。(BZ#1857158)
  • 以前のバージョンでは、ヘルスチェックプローブは、AWS にデプロイされるユーザーによってプロビジョニングされるインフラストラクチャーのロードバランサーに対して定義されませんでした。ロードバランサーは API エンドポイントが利用できなくなる時を検出しませんでした。これにより、クライアントの失敗が生じました。今回の更新により、ヘルスチェックプローブが追加され、ロードバランサーはトラフィックをオフラインノードにルーティングしません。(BZ#1836018)
  • 以前のバージョンでは、Terraform vSphere プロバイダーの DiskPostCloneOperation 機能は、Red Hat CoreOS OVA イメージからクローンされる仮想マシンの thin_provisioned および eagerly_scrub プロパティーをチェックしました。プロビジョニングのタイプがクローン時に変更され、ソースのプロビジョニングタイプと一致しないと、チェックは失敗しました。DiskPostCloneOperation 機能は、それらのプロパティーを無視するようになり、Red Hat CoreOS OVA のクローン作成は正常に実行されるようになりました。(BZ#1862290)
  • ./openshift-install destroy cluster の実行時に、インストーラーは、インストーラータグの削除を、それらを使用するリソースが削除される前に試行しました。その後に、インストーラーはタグの削除に失敗しました。今回の更新により、インストーラーは対応するリソースの削除後にタグを削除するようになりました。(BZ#1846125)

kube-apiserver

  • 以前のバージョンでは、Cluster Version Operator (CVO) は、LatencySensitive 機能ゲートが使用されている場合に、クラスターにアップグレード不可のマークを付けました。今回の更新により、CVO は LatencySensitive 機能ゲートをクラスターのアップグレードのブロックとしてみなさなくなりました。この問題を解決するには、ソリューションを含む最新の 4.5.z または stable バージョンへのアップグレードを強制的に実行します。(BZ#1861431)

kube-controller-manager

  • 以前のバージョンでは、デーモンセットコントローラーは、デーモンセットを再作成する際に expectation をクリアしませんでした。そのため、デーモンセットは、expectation が期限切れになるまで 5 分間停止した状態になる可能性があります。デーモンセットコントローラーは expectation を正しくクリアするようになりました。(BZ#1843319)
  • UID 範囲の割り当ては、プロジェクトの削除時に更新されないため、namespace の作成および削除の頻度の高いクラスターでは UID 範囲を使い切られる可能性があります。この問題を解決するために、kube-controller-manager Pod は定期的に再起動され、これにより修復の手順がトリガーされ、UID 範囲がクリアされます。(BZ#1808588)
  • 以前のバージョンでは、エンドポイントコントローラーは、インフォーマーの再同期の間隔ごとに多数の API 要求を送信していました。これにより、多数のエンドポイントを持つ大規模なクラスターでパフォーマンスが低下していました。ストレージの各種の不整合とエンドポイントの比較により、エンドポイントコントローラーは実際の必要以上の、多数の追加の更新をクラスターに対して実行する必要のあると誤って仮定していました。今回の修正により、エンドポイントのストレージおよび比較機能が更新され、それらの一貫性が強化されました。これにより、エンドポイントコントローラーは、必要に応じて更新のみを送信するようになりました。(BZ#1854434)
  • 以前のバージョンでは、NotFound エラーはコントローラーのロジックにより誤って処理されました。このため、デプロイメント、デーモンセット、レプリカセットコントローラーなどのコントローラーは、Pod が欠落していることを認識しませんでした。今回の修正により、コントローラーが更新され、Pod が以前に削除されたことを示す Pod の NotFound イベントに正常に対応するようになりました。(BZ#1843187)

kube-scheduler

  • 以前のバージョンでは、Pod をドライランモードでエビクトする際に、特定の Descheduler ストラテジーがエビクションを 2 回ログに記録していました。エビクション用に単一のログエントリーのみが作成されるようになりました。(BZ#1841187)

ロギング

  • 以前のバージョンでは、Elasticsearch インデックスメトリクスは、デフォルトで Prometheus によって収集されました。そのため、Prometheus ではインデックスレベルのメトリクスのサイズが原因でストレージがすぐに不足し、ユーザーは Prometheus の機能を維持するために Prometheus の保持時間を短縮するなどして介入する必要がありました。Elasticsearch インデックスメトリクスを収集しないようにデフォルトの動作が変更されました。(BZ#1858249)
  • OpenShift Elasticsearch Operator は Kibana デプロイメントのシークレットハッシュを更新しないため、シークレットが更新されても Kibana Pod は再起動されませんでした。このコードは、デプロイメントのハッシュを正しく更新するように変更され、これは Pod を予想通りに再デプロイされるようにトリガーします。(BZ#1834576)
  • Fluentd init コンテナーの導入により、Fluentd は OpenShift Elasticsearch Operator (EO) をデプロイせずにクラスターにデプロイできませんでした。このコードは、EO のない Fluentd を許可するように変更されました。その結果、Elasticsearch のないクラスターで、Fluentd は予想通りに機能します。(BZ#1849188)
  • iframe で Kibana を開く機能は明示的に拒否されませんでした。そのため、Kibana がクリックジャックなどの攻撃を受ける可能性が生じます。このコードは、iframe の使用をブロックする x-frame-options:deny を明示的に設定するように変更されました。(BZ#1832783)

Machine Config Operator

  • ベアメタル環境では、infra-dns コンテナーは各ホストで実行され、ノード名の解決および他の内部 DNS レコードをサポートします。NetworkManager スクリプトは、infra-dns コンテナーを参照するように、ホストの /etc/resolv.conf も更新します。さらに、Pod が作成されると、ホストから DNS 設定ファイル (/etc/resolv.conf ファイル) を受信します。

    NetworkManager スクリプトがホストの /etc/resolv.conf ファイルを更新する前に HAProxy Pod が作成された場合、api-int 内部 DNS レコードが解決できないために Pod は繰り返し失敗する可能性があります。今回のバグ修正により、Machine Config Operator (MCO) が更新され、HAProxy Pod の /etc/resolv.conf ファイルがホストの /etc/resolv.conf ファイルと同じであることを確認できます。その結果、HAProxy Pod ではこれらのエラーが発生しなくなりました。(BZ#1849432)

  • keepalived は、API とデフォルトルーターの両方に高可用性 (HA) を提供するために使用されます。各ノードの Keepalived インスタンスは、ローカルエンティティーのヘルスエンドポイント (例: kube-apiserver) を curl してローカルの健全性を監視します。以前のバージョンでは、curl コマンドは TCP 接続に失敗する場合にのみ失敗し、HTTP の 200 以外のエラーでは失敗しませんでした。これにより、ローカルエンティティーが正常でなくても、Keepalived が別の正常なノードにフェイルオーバーしない可能性があり、API 要求にエラーが発生しました。

    今回のバグ修正により、Machine Config Operator (MCO) が curl コマンドを変更するように更新され、サーバーが 200 以外のリターンコードを出して応答する場合にも失敗するようになりました。その結果、ローカルエンティティーで障害が発生した場合に、API および Ingress ルーターは正常なノードに正常にフェイルオーバーするようになりました。(BZ#1844387)

  • ベアメタル環境では、IPv4 用に一部の DNS レコードがハードコーディングされていました。これにより、IPv6 環境で一部のレコードが正しく処理されないため、これらのレコードを外部 DNS サーバーで作成する必要が生じる可能性がありました。今回のバグ修正により、Machine Config Operator (MCO) が更新され、DNS レコードは使用中のインターネットプロトコルのバージョンに基づいて正しく設定されるようになりました。これにより、内部レコードが IPv4 と IPv6 の両方で正しく機能するようになりました。(BZ#1820785)
  • 以前のバージョンでは、マシン設定に指定されたカーネル引数は、配列内の個別の引数の文字列に分割する必要がありました。これらの引数は、rpm-ostree コマンドに連結する前に検証されませんでした。カーネルコマンドラインの単一行で許可されるように、スペースを使用して連結した複数のカーネル引数は、無効な rpm-ostree コマンドを作成します。今回のバグ修正により、マシン設定コントローラーが更新され、カーネルと同様の方法でそれぞれの kernelArgument 項目を解析できるようになりました。その結果、ユーザーはエラーを出さずに、スペースを使用して連結した複数の引数を指定できます。(BZ#1812649)
  • 以前のバージョンでは、コントロールプレーンはベアメタル環境でのユーザーワークロードに対して常にスケジュール可能になりました。今回のバグ修正により、Machine Config Operator (MCO) が更新され、コントロールプレーンノードはワーカーを使用する一般的なデプロイメントで NoSchedule として適切に設定されるようになりました。(BZ#1828250)
  • 以前のバージョンでは、Machine Config Operator (MCO) を使用する際に、不要な API VIP の移動により、クライアント接続エラーが発生する可能性がありました。今回のバグ修正により、API VIP ヘルスチェックが更新され、移動する回数を制限できるようになりました。その結果、API VIP の移動によって生じるエラーが少なくなりました。(BZ#1823950)

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

  • Operand のリストビューに Operand タブがありませんでした。今回のバグ修正により、この問題は解決されています。(BZ#1842965)
  • IPv6 が無効になると、ダウンロード Pod ソケットをバインドできず、ダウンロード Pod がクラッシュしました。IPv6 が有効にされていないと、IPv4 がソケットに使用されるようになりました。ダウンロード Pod は、IPv4 および IPv6 を有効にするかどうかに関わらず機能するようになりました。(BZ#1846922)
  • Operator ステータスの表示値は、手動の承認ストラテジーを考慮しませんでした。そのため、upgrade available ステータスが表示され、アップグレードに追加のアクションが必要であることを通知しませんでした。手動の承認のアップグレードを待機する Operator についての新規ステータスメッセージが追加されました。Operator のアップグレードに追加のアクションが必要であることを明確に確認できるようになりました (BZ#1826481)。
  • 失敗したオペランドフォーム送信の catch ロジックは、常に定義される訳ではない生成されるエラーオブジェクトのプロパティーへのアクセスを試行します。特定の失敗した要求タイプでは、ランタイムエラーが発生します。今回のバグ修正により、この問題は解決されています。(BZ#1846863)
  • Victory はすべてがゼロ (0) のデータセットを適切に処理しません。すべてがゼロ (0) のデータセットの Y 軸のティックマークではゼロが繰り返されます。エリアチャートのロジックは、データセットがすべてゼロ (0) の場合に、Y ドメインの [0,1] を強制的に実行するように更新されました。今回のリリースより、すべてがゼロ (0) のデータセットの Y 軸のティッククマークは 0 および 1 になりました。(BZ#1856352)
  • 現時点でインストールされているバージョンは、OperatorHub の Operator の詳細ペインには表示されません。そのため、現在インストールされているバージョンが最新バージョンであるかどうかをユーザーが判断できませんでした。現在インストールされている Operator バージョンが最新バージョンでない場合、インストールされているバージョンが OperatorHub の Operator の詳細ペインに表示されるようになりました。(BZ#1856353)
  • create role binding リンクには、一貫性のない仕方で namespace が使用されたり、クラスターリンクが使用されているため、 create role binding ページは正しくありませんでした。今回のバグ修正により、利用可能な場合に namespace を使用し、別のケースではクラスターを使用するようにリンクが更新されました。正しいページが使用されるようになりました。(BZ#1871996)
  • 以前のバージョンでは、Web コンソールは singlestat パネルの Grafana 値マップに対応しないため、singlestat パネルでは Grafana 値マップを表示できませんでした。サポートが追加され、singlestat パネルに Grafana 値マップを表示できるようになりました。(BZ#1866928)
  • oc debug が BZ#1812813 で更新され、oc debug がワーカーノードに対してのみ機能するという問題の回避策として、空のノードセレクターで新規のデバッグプロジェクトを作成できるようになりました。Web コンソールでは、ターミナルが開く前にユーザーが Node → Terminal ページに移動する際に namespace を選択するように指示することで問題を回避できます。この場合、oc とは異なるユーザーエクスペリエンスが提供されます。Web コンソールでは、 Node → Terminal ページへの移動時に空のノードセレクターで新規のデバッグプロジェクトを作成できます。Web コンソールの Node → Terminal ページの動作は、oc debug の動作と連携しています。(BZ#1881953)
  • すべてのレシーバーが削除されると、Web コンソールにランタイムエラーが発生し、ユーザーには空の画面が表示されました。null チェックがコードに追加され、ユーザーには No Receivers の空の状態についての画面が表示されます。(BZ#1849556)
  • 場合によっては、レガシーオペランド作成形式のリソース要件のウィジェットに渡される値が immutablejs マップインスタンスではない可能性があります。リソース要件のウィジェットの現行の値で immutablejs Map.getIn 関数の参照を試行する際にランタイムエラーが出力されました。immutablejs Map.getIn 関数を参照する際にオプションのチェーンを使用します。ランタイムエラーは出力されず、ウィジェットは値なしでレンダリングされます。(BZ#1883679)
  • imagemanifestvuln リソースで検索を使用する場合にブランクページが表示されました。コンポーネントは props.match.params.ns を使用しており、これは定義されていないことがありました。その結果、ランタイムエラーが生じました。この問題は解決されています。(BZ#1859256)
  • 以前のバージョンでは、オペランド一覧の右側のアクションメニューは、メニューが開かれた直後に閉じられました。これは、Operator が提供する API のタブのいずれかをクリックし、Installed Operators の詳細ページで確認できます。このメニューは正常に機能し、ユーザーの対話なしに閉じられることはなくなりました。(BZ#1840706)
  • API にキーワードフィールドがないため、ユーザーは OperatorHub のキーワードで検索できませんでした。今回のバグ修正により、この問題は解決されています。(BZ#1840786)
  • 以前のバージョンでは、Web コンソールの OperatorHub に Operator の誤ったアイコンが表示されることがありました。この問題は本リリースでは解決されています。(BZ#1844125)
  • 今回のリリースでは、Web コンソールの OperatorHub インストールページからクラスターモニターリングドキュメントへの破損していたリンクが修正されました。(BZ#1856803)
  • 以前のバージョンでは、EtcdRestores ページの Create EtcdRestore をクリックすると、Web コンソールの応答が停止しました。今回のリリースにより、Create EtcdRestore フォームビューのワークフローが正しく読み込まれるようになりました。(BZ#1845815)
  • 以前のバージョンでは、Operand フォーム配列およびオブジェクトフィールドには、フォームでフィールドの説明を取得し、表示するロジックがありませんでした。そのため、配列またはオブジェクトタイプのフィールドの説明はレンダリングされませんでした。今回のバグ修正により、配列およびオブジェクトフィールドの説明が Operand 作成フォームで表示されるようになりました。(BZ#1854198)
  • 以前のバージョンでは、Deployment Configuration Overview ページは、新規 Pod の起動時に、e is undefined エラーを出してクラッシュしました。この問題は本リリースでは解決されています。(BZ#1853705)
  • 以前のバージョンでは、OpenShift Dedicated ユーザーはクラスターのアップグレードを実行できない場合でも、Web コンソールのクラスターアップグレードインターフェイスが OpenShift Dedicated に表示されました。クラスターアップグレードインターフェイスは OpenShift Dedicated で非表示になりました。(BZ#1874257)
  • 以前のバージョンでは、オペランドテンプレートの空のオブジェクトは、フォームの送信またはフォームと YAML ビュー間の切り替え時にプルーニングされました。今回のリリースにより、フォームデータから空の構造をプルーニングする際にテンプレートデータがマスクとして使用され、テンプレートに定義されていない値のみがプルーニングされるようになりました。テンプレートで定義される空の値はそのままになります。(BZ#1847921)
  • ツールチップの詳細は、クラスターロギング のドーナツチャートにカーソルを合わせと切り捨てられることがありました。今回のバグ修正により、ツールチップの詳細全体がこのチャートに表示されるようになりました。(BZ#1842408)
  • Create Instance ページの Registry フィールドでは、スキーマプロパティーの説明の一部のテキストと、Linkify でファジーなハイパーリンクの作成に使用される形式が一致していました。そのため、意図しないハイパーリンクが生成されました。今回のバグ修正により、Linkify のファジーなリンクの機能が無効にされました。適切なプロトコルスキームを使用する URL 文字列のみがハイパーリンクとしてレンダリングされるようになりました。(BZ#1841025)
  • ListDropdown コンポーネントがロード中の状態にない場合でも、AWS の Secret フィールドには常にロード中であることを示すアイコンが表示されます。今回のバグ修正により、コンポーネントのロジックが修正され、ドロップダウンリストが ロード中の状態にある場合にのみロード中であることを示すアイコンが表示されるようになりました。プレースホルダーは、ドロップダウンリストがロード中の状態にない場合に表示されます。(BZ#1845817)
  • 以前のバージョンでは、ログに長い行が含まれる場合に、Web コンソールの Resource Log ページが遅くなり、応答しなくなりました。今回のバグ修正により、Resource Log ページに表示されるログ行ごとに文字数を制限し、完全なログコンテンツを表示する代替方法を提供することで、パフォーマンスの問題が修正されました。(BZ#1874558)
  • 以前のバージョンでは、クエリーが間違っているため、Used および Total のノードファイルシステム計算が正しくありませんでした。今回のリリースより、クエリーが更新され、データが正しく計算されるようになりました。(BZ31874028)
  • Web コンソールの Overview ページには、ネットワーク使用率データを表示するためのコンテナーレベルの使用状況メトリクスが誤って含まれていました。今回のバグ修正により、正しくないメトリクスをノードレベルの使用状況メトリクスに置き換え、ネットワーク使用率データを正確に表示できるようになりました。(BZ#1855556)
  • 以前のバージョンでは、Operator の Created At タイムスタンプの形式は特定の形式を必要とせず、Web コンソールでタイムスタンプが一貫性のない状態で表示されました。Created At タイムスタンプの値が Operator の有効な日付として入力されると、コンソールの他のタイムスタンプと一貫性のある状態でタイムスタンプが表示されるようになりました。有効な日付形式で値を入力しない場合、Created At タイムスタンプは無効な文字列として表示されます。(BZ#1855378)
  • Web コンソールには、OperatorHub の古いロゴが表示されました。今回のバグ修正により、古いロゴが現在のロゴに置き換えられました。(BZ#1810046)
  • 以前のバージョンでは、Web コンソールで Operator リソースのフィールド名が camelCase または Start Case として一貫性のない状態で表示されました。今回のリリースより、オペランドフォーム生成ロジックで、デフォルトで Start Case を使用してフォームフィールドにラベル付けされるようになりました。デフォルトは CSV または CRD オブジェクトで上書きできます。(BZ#1854196)
  • 以前のバージョンでは、Resource Log ビューには単一行ログが表示されず、改行制御文字 (/n) がない場合は Pod ログの最後の行が表示されませんでした。ログビューが更新され、単一行ログおよび改行文字で終了されない最終行について Pod ログの内容全体が表示されるようになりました。(BZ#1876853)
  • 以前のバージョンでは、OpenShift Container Platform Web コンソールの YAML エディターではすべてのリソースの metadata.namespace エントリーが許可されていました。namespace: <namespace> が namespace 値を取らないリソースについて追加される場合に、エラーが返されました。metadata.namespace エントリーは、リソースが namespace の値を取らない場合、設定の保存時に削除されるようになりました。(BZ#1846894)
  • 以前のバージョンでは、名前値エディターの削除アイコン (-) がツールチップを提供しないため、ユーザーはこのアイコンの内容を明確に把握できませんでした。削除アイコン (-) で、アクションを明確にするツールチップを提供するようになりました。(BZ#1853706)
  • 以前のバージョンでは、( および ) などの特殊文字を含むリソース名により、リソースの詳細が OpenShift Container Platform コンソールに表示できなくなる可能性がありました。リソース名に特殊文字が含まれる場合も、リソースの詳細が適切に表示されるようになりました。(BZ#1845624)

モニターリング

  • 以前のバージョンでは、Prometheus の設定のリロードは、設定が完全に生成されていない間にトリガーされることがありました。これにより、収集またはアラートターゲットがないことから PrometheusNotIngestingSamples および PrometheusNotConnectedToAlertmanagers アラートがトリガーされました。設定のリロードプロセスでは、Prometheus をリロードする前にディスクの設定が有効になり、アラートが実行されないようになりました。(BZ#1845561)
  • 以前のバージョンでは、AlertmanagerConfigInconsistent アラートは、 Alertmanager Pod の一部がステートフルセットのローリング更新のために一時的に実行されないために、アップグレード時に実行される可能性がありました。アラート自体が解決しても、これによってクラスター管理者に混乱をきたす可能性があります。AlertmanagerConfigInconsistent は実行中の Alertmanager Pod を考慮しなくなり、一部の Alertmanager Pod が実行されていない、一時的な状態にある場合のアップグレード時に実行されなくなりました。(BZ#1846397)
  • 以前のバージョンでは、一部のアラートに正しい重大度が設定されておらず、正しくないものもあり、これによりアップグレードの問題が発生しました。多くのアラートの重大度レベルは、critical から warning に変更され、KubeStatefulSetUpdateNotRolledOut および KubeDaemonSetRolloutStuck アラートは調整され、KubeAPILatencyHigh および KubeAPIErrorsHigh アラートは削除されました。これらのアラートは適切であるため、アップグレードの問題が発生しなくなるはずです。(BZ#1824988)
  • 以前のバージョンでは、KubeTooManyPods アラートは kubelet_running_pod_count を使用しました。これには、完了した Pod が含まれ、KubeTooManyPods アラートについては正しくない情報が含まれました。KubeTooManyPods アラートのノードで実行させる Pod の実際の数を確認するために container_memory_rss を使用できます。(BZ#1846805)
  • 以前のバージョンでは、node_exporter デーモンはデフォルトで maxUnavailable 値の 1 に設定されており、ロールアウトは完全にシリアライズされ、大規模なクラスターの場合には速度が遅くなりました。node_exporter デーモンセットはワークロードの可用性に影響しないため、maxUnavailable はクラスターサイズでスケーリングし、ロールアウトが高速になりました。(BZ#1867603)

ネットワーク

  • 今回のリリースにより、Kuryr-Kubernetes は kuryr.conf に設定した値を使用するのではなく、Container Network Interface (CNI) レベルの Pod サブポートのブリッジインターフェイスの検出を試行するようになりました。この方法は、kuryr.conf に設定された値を使用せずに仮想マシンがインターフェイスを呼び出す場合に対応します。(BZ#1829517)
  • 以前のバージョンでは、OpenShift SDN は HTTP で暗号化されていないメトリクスを公開していました。OpenShift SDN は TLS 経由でメトリクスを公開するようになりました。(BZ#1809205)
  • 以前のバージョンでは、サービスの OpenShift SDN をアイドリングする際に、サービスおよびそのエンドポイントを常に正しい順序で削除しませんでした。そのため、サービスのノードポートが削除されないことがありました。サービスが再びスケールアップされると、それは到達不可能になります。OpenShift SDN では、ノードポートが常に適切に削除されるようにするようになりました。(BZ#1857743)
  • 以前のバージョンでは、レガシーの iptables バイナリーの依存関係がないために、egress ルーター Pod は初期化に失敗しました。egress ルーター Pod が正常に初期化されるようになりました。(BZ#1822945)
  • 以前のバージョンでは、OVN-Kubernetes クラスターネットワークプロバイダーを使用しているクラスターでネットワークポリシーを削除する際に、競合状態により、関連付けられた namespace の削除時にネットワークポリシーが削除されませんでした。ネットワークポリシーオブジェクトは常に正しく削除されるようになりました。(BZ#1859682)
  • 以前のバージョンでは、マルチテナント分離モードで OpenShift SDN Pod ネットワークプロバイダーを使用する場合、Pod は externalIPs が設定されたサービスに到達できませんでした。Pod は、サービス外部 IP アドレスが設定されたサービスに到達できるようになりました。(BZ#1762580)
  • 以前のバージョンでは、OVN-Kubernetes は HTTP で暗号化されていないメトリクスを公開しました。OVN-Kubernetes は TLS 経由でメトリクスを公開するようになりました。(BZ#1822720)
  • 以前のリリースでは、Red Hat OpenStack Platform 上の OpenShift Container Platform では、OVN-Octavia ドライバーを使用する場合にリスナーを同じポート上の異なるプロトコルに割り当てることができませんでした。複数のプロトコルを同じポートで公開できるようになりました。(BZ#1846396)

ノード

  • 以前のバージョンでは、ソフトエビクションのしきい値および猶予期間が指定されていない場合に、Kubelet の起動に失敗しました。今回のリリースにより、Kubelet の設定時にこれらの値が存在することが検証されるようになりました。(BZ#1805019)
  • ユーザーは、負の値や数字以外の文字などの無効な文字を kubeconfig オブジェクトの CPU およびメモリー要求に入力する可能性があると、kubelet は起動しませんでした。コードは、kubelet 設定のメモリー要求値が有効であることを確認するように変更されました。その結果、無効な値が拒否されます。(BZ#1745919)
  • 以前のバージョンでは、システムがルートデバイスのデバイスマッパーを使用している場合、cadvisor によって返されるキーホストレベルの IO メトリクスの数がゼロに設定されませんでした。cadvisor は、デバイスマッパーが root に使用される場合にこのメトリクスを報告するように修正されました。(BZ#1831908)

oauth-apiserver

  • 以前のバージョンでは、認証 Operator が Accept: application/json ヘッダーを無視する OpenID Connect Authentication (OIDC) サーバーから HTML ペイロードを受信すると、Operator はペイロードについてのエラーをログに記録しました。Operator には、OIDC サーバーの応答のトラブルシューティングに使用するために要求したページの URL が含まれるようになりました。(BZ#1861789)

oc

  • 以前のバージョンでは、oc project コマンドには self-provisioner ロールの権限がプロジェクトを切り替えるために必要でした。つまり、ユーザーによっては、そのロールがない場合にプロジェクトを切り替えることができませんでした。self-provisioner ロールの要件は取り除かれ、プロジェクトにアクセスできるすべてのユーザーは oc project を使用してプロジェクトを切り替えることができます。(BZ#1849983)
  • 以前のバージョンでは、空の lastTimestamp を持つイメージを並べ替える際に、lastTimestamp でのイベントの並べ替えによりエラーが生じる可能性がありました。並べ替えは空の要素に対しても機能し、lastTimestamp で並び換えを実行しても適切に機能します。(BZ#1880283)
  • 以前のバージョンでは、oc create job コマンドに --save-config フラグのロジックがないため、--save-config オプションは予想通りに機能しませんでした。--save-logic フラグについてロジックが追加され、正常に機能するようになりました。(BZ#1844998)

OLM

  • Operator Lifecycle Manager (OLM) は、サブスクリプション CRD の subscription.spec.config.nodeSelector フィールドを公開しましたが、以前は ClusterServiceVersion オブジェクト (CSV) で定義されたデプロイメントに nodeSelectors ラベルを適用しませんでした。これにより、ユーザーは CSV デプロイメントに nodeSelectors を設定できませんでした。今回のバグ修正により、subscription.spec.config.nodeSelector フィールドに定義される nodeSelector ラベルが CSV のデプロイメントに伝播するように OLM が更新されました。その結果、フィールドが予想通りに機能するようになりました。(BZ#1860035)
  • 以前のバージョンでは、Operator Lifecycle Manager (OLM) は、installing フェーズに入る ClusterServiceVersion オブジェクト (CSV) を複数回インストールする場合も、既存の有効な CA 証明書を再利用しませんでした。OLM は新規の Webhook ハッシュをデプロイメントに適用し、新しいレプリカセットが作成されます。その後、実行中の Operator は再デプロイされ、インストール時に複数回デプロイされる場合もあります。今回のバグ修正により OLM が更新され、CA がすでに存在しているかどうかを確認し、有効な場合はこれを再利用できるようになりました。その結果、OLM が既存の有効な CA を検出すると、OLM が CA を再利用できるようになりました。(BZ#1868712)
  • Operator Lifecycle Manager (OLM) は、API サービスを提供する Operator 用にインストールされたサービスリソースに OwnerReferences メタデータを追加します。以前のバージョンでは、このクラスの Operator が証明書のローテーション時に OLM によって再デプロイされると、重複する OwnerReference が関連するサービスに追加され、これにより、 OwnerReferences の数がバインドされなくなりました。今回のバグ修正により、OwnerReferences を追加する際に、OLM は (見つかる場合に) 既存の OwnerReference を更新するようになりました。その結果、OLM によってサービスに追加される OwnerReferences の数がバインドされます。(BZ#1842399)
  • Operator Lifecycle Manager (OLM) は、バンドルイメージを展開する前にこれらをプルすることができませんでした。そのため、opm alpha bundle validate コマンドが image not found または同様のエラーで失敗しました。今回のバグ修正により、OLM がバンドルバリデーターの展開を試行する前にバンドルイメージをプルできるようになりました。その結果、opm alpha bundle validate コマンドは、検証を実行する前にイメージを正常にプルし、展開できます。(BZ#1857502)
  • 以前のバージョンでは、Web コンソールでは、パッケージで宣言された最初のチャネルからのアイコンを返して、OperatorHub に表示される Operator アイコンを選択していました。これにより、表示されるアイコンがパッケージに公開される最新のアイコンとは異なる場合がありました。これは、デフォルトのチャネルからアイコンを選択することにより修正され、最新のアイコンが表示されるようになりました。(BZ#1843652)
  • 以前のバージョンでは、podman または docker ツールオプションを使用する場合に、ホワイトアウトファイルが展開されたコンテンツに表示されていました。今回のリリースにより、podman および docker のツールオプションで展開した後に、ホワイトアウトファイルは存在しなくなります。(BZ#1841178)

openshift-controller-manager

  • 以前のバージョンでは、API サーバーで断続的に可用性の問題が生じると、OpenShift Controller Manager Operator がデプロイメントを取得する際に断続的な問題が生じる可能性がありました。デプロイメントの取得に失敗したために Operator がパニックを引き起こすことがありました。今回のリリースにより、このエラー状態を処理し、報告し、操作を再試行するためのチェックが追加されました。Operator は、API サーバーからのデプロイメントを取得する断続的な問題を適切に処理するようになりました。(BZ#1852964)

RHCOS

  • 以前のリリースでは、DHCP を使用しないネットワーク上で NIC が多数あるマシンを起動するのに時間がかかりました。これは、マシン上のすべてのインターフェイスで、一度に 1 つのインターフェイスで DHCP を起動しようとする従来のネットワークスクリプトを使用する initramfs によって生じました。initramfs は、レガシースクリプトの代わりに NetworkManager を使用するようになりました。NetworkManager は、物理接続を持たないインターフェイスで DHCP を試行しません。NetworkManager は、1 度に 1 つではなく、インターフェイスで並行して DHCP を試行します。これらの変更により、DHCP のタイムアウトの待機時間が短縮されます。(BZ#1836248)

  • 以前のバージョンでは、インストール時にカーネル引数を変更することができませんでした。カーネル引数は、coreos-installer コマンドを使用してインストール済みのシステムで変更することができます。たとえば、以下を使用して、インストール済みのシステムを、別のシリアルコンソール引数を使用するように設定できます。 

    $ coreos-installer install ... ＼
 --delete-karg console=ttyS0,115200n8 ＼
 --append-karg console=ttyS1,115200n8

    (BZ#1712511)

  • MCO がワーカーノードのデプロイに使用される場合、Ignition 設定でユーザー定義の iSCSI イニシエーター名が自動的に動的に生成される名前に置き換えられるため、このファイルのロードに失敗しました。iSCSI イニシエーター名は、Ignition 設定で名前が指定されない場合にのみ動的に生成されるようになりました。(BZ#1868174)
  • プロビジョニング時の Azure 仮想マシンへの手動による変更により、インカーネーション番号が変更され、インカーネーション番号の不一致により afterburn の読み取り状態のレポートが失敗しました。Afterburn は、準備状態になる直前に新規のインカーネーション番号がフェッチするようになりました。(BZ#1853068)
  • ボンディングインターフェイスなどの一部のインターフェイスがコンソールで表示されませんでした。NetworkManager のディスパッチスクリプトは、以前に使用された Udev ルールに置き換わりました。今回の修正により、永続的なハードウェアアドレスを持つネットワークインターフェイスや、コンソールで表示する永続的なハードウェアアドレスを持つデバイスでサポートされるネットワークインターフェイスが有効になりました。(BZ#1866048)

ルーティング

  • 以前のバージョンでは、HAProxy ルーター 503 ページは一部の Web アプリケーションのファイアウォールで使用される標準に準拠しませんでした。この問題を解決するために 503 ページが更新されました。(BZ#1852728)

  • Ingress Operator が NodePortService エンドポイント公開ストラテジータイプに設定された IngressController オブジェクトを調整すると、Operator は ingress コントローラーの NodePort サービスを API から取得し、Operator がサービスを作成するか、または更新する必要であるかどうかを判別します。サービスが存在しない場合は、Operator は spec.sessionAffinity フィールドの空の値を使用してこれを作成します。サービスが存在する場合、Operator はこれを Ingress Operator が予想する対象と比較し、そのサービスに更新が必要であるかどうかを判別します。この比較では、API にサービス spec.sessionAffinity フィールドのデフォルト値 None を設定すると、Operator は更新を検出し、spec.sessionAffinity フィールドを空の値に戻します。

    これにより、Ingress Operator は空白に対して NodePort サービスの更新を繰り返し試行します。Ingress Operator は、NodePort サービスを比較する際に指定されていない値とデフォルト値が等しいと見なすように変更されました。Operator は API のデフォルトへの対応として、 Ingress Controller NodePort サービスを更新しなくなりました。(BZ#1842742)

  • 以前のバージョンでは、ルートが正しくない状態でクラスターを更新した場合、HAProxy は非アクティブな状態に初期化されました。ただし、アップグレードはアラートをトリガーせず、クラスターは Ingress コントローラーを利用可能と誤って報告しました。ルートが破損したアップグレードに失敗するように、HAProxy の初期の同期ロジックが修正されました。その結果、ルートが正しくないクラスターのアップグレードは成功せず、HAProxyReloadFail または HAProxyDown アラートが報告されます。(BZ#1861455)
  • HTTP/2 ALPN を使用する際に接続の再使用/結合についてのリスクがあるため、カスタム (ワイルドカード以外の) 証明書を使用するルートでのみ HTTP/2 ALPN を有効にするために使用する警告メッセージが CLI の Ingress コントローラーの出力に追加されました。そのため、独自のカスタム証明書を持たないルートは、フロントエンドまたはバックエンドのいずれかで HTTP/2 ALPN で有効にされません。(BZ#1827364)
  • 以前のバージョンでは、HAProxy がリロードされると、HAProxy Prometheus カウンターメトリクスの値が減少し、これによりカウンターメトリクス定義の明示的な違反が生じました。ルーターコードは、最後のメトリクス収集のタイミングを記録するように修正されました。これにより、リロード時に保持されたカウンター値以外の収集を防ぐことができます。その結果、カウンターメトリクスには、ルーターの再読み込み時の減少の後に続く急な増加が表示されません。(BZ#1752814)

サンプル

  • 以前のバージョンでは、Samples Operator のアラートルールの registry.redhat.io ホスト名のスペルに誤りがありました。ルールは、アラートメッセージで正しいホスト名を使用するようになりました。(BZ#1863014)
  • 以前のバージョンでは、OpenShift Container Platform をアップグレードする際に、Samples Operator は API サーバーが断続的に利用不可になる場合にアップグレードをブロックする可能性がありました。Operator は断続的な接続を正常に処理し、アップグレードがブロックされなくなりました。(BZ#1854857)

ストレージ

  • ローカルストレージ Operator ロギングのエラーメッセージの内容はあまりに一般的であり、デバッグに役立ちませんでした。LocalVolume オブジェクトが作成され、指定されたデバイスが見つからないか、または無効な場合に、詳細情報が提供されるようになりました。(BZ#1840127)
  • ストレージ Operator は v1alpha1 CRD で Upgradable=False が設定されている場合に調整を停止しました。そのため、Cluster Storage Operator はこれらの CRD がクラスターで検出される際に z-stream のアップグレードを実行できませんでした。今回の修正により、調整ループの順序が変更されました。z-stream のアップグレードが正常に完了し、v1alpha1 CRD がエラーなしで検出されるようになりました。(BZ#1873299)
  • 再起動プロセスで新規 IP アドレスを Pod に割り当てるため、Manila ボリュームは NFS ドライバー Pod の再起動後にアンマウントできませんでした。Pod は、ドライバー Pod の再起動後も、ホストネットワークおよびホスト IP アドレスを使用してボリュームをマウントおよびアンマウントするようになりました。(BZ#1867152)
  • 今回のバグ修正により、小規模ボリュームの fsGroup を変更する際に不要なログが減少します。(BZ#1877001)
  • vSphere クラウドプロバイダーの条件により、負荷が大きいことを原因として、稀な状況下で永続ボリュームのプロビジョニングが失敗する可能性がありました。今回のバグ修正により条件が修正され、vSphere ボリュームを確実にプロビジョニングできるようになりました。(BZ#1806034)
  • OCP 4.3.z から 4.4.0 へのアップグレードは、クラスターで v1alpha1 VolumeSnapshot CRD を手動でインストールした場合や、それらが独立した CSI ドライバーによってインストールされている場合に失敗します。OpenShift Container Platform 4.4 では v1beta1 VolumeSnapshot CRD が導入されましたが、これは v1alpha1 VolumeSnapshot CRD と互換性がありません。Cluster Storage Operator は v1alpha1 VolumeSnapshot CRD の有無をチェックするようになりました。検出されると、アップグレードを続行するために v1alpha1 VolumeSnapshot CRD を削除する必要があることを示すメッセージが表示されます。(BZ#1835869)
  • VolumeSnapshotContent オブジェクトの削除ポリシーが変更されると、 VolumeSnapshot リソースインスタンスは、これらのインスタンスに関連するファイナライザーが更新されないために削除できませんでした。今回のバグ修正により、VolumeSnapshotContent オブジェクトの削除ポリシーが変更されるとファイナライザーが削除され、関連付けられたリソースオブジェクトの削除後に VolumeSnapshot リソースインスタンスを削除できるようになりました。(BZ#1842964)
  • 以前のバージョンでは、デフォルトの OpenShift RBAC ルールでは、通常のユーザーが VolumeSnapshot および VolumeSnapshotClass リソースにアクセスしたり、作成したりすることができませんでした。デフォルトの OpenShift RBAC ルールは、basic-users による VolumeSnapshot リソースの読み取り/書き込みを許可し、VolumeSnapshotClass リソースの読み取りを許可します。さらに、storage-admins はデフォルトで VolumeSnapshotContent オブジェクトの読み取り/書き込みが可能です。(BZ#1842408)
  • 以前のバージョンでは、ローカルストレージ Operator が 1 つのデバイスを複数の PV に作成することを防ぐための検証は行われませんでした。今回のリリースにより、このシナリオの検証が追加され、ローカルストレージ Operator によってすでにプロビジョニングされているブロックデバイスで PV の作成を試行すると失敗するようになります。(BZ#1744385)

Insights Operator

  • 以前のバージョンでは、Insights Operator は単一のレポートで証明書署名要求 (CSR) を数の制限なく収集することができました。これにより、多くの CSR を持つクラスターについて過剰なデータ収集が発生していました。Insights Operator は、単一のレポートで最大 5000 CSR のデータを収集するようになりました。(BZ#1881044)

1.6. テクノロジープレビューの機能

現在、今回のリリースに含まれる機能にはテクノロジープレビューのものがあります。これらの実験的機能は、実稼働環境での使用を目的としていません。これらの機能に関しては、Red Hat カスタマーポータルの以下のサポート範囲を参照してください。

テクノロジープレビュー機能のサポート範囲

以下の表では、機能は以下のステータスでマークされています。

  • TP: テクノロジープレビュー
  • GA: 一般公開機能
  • -: 利用不可の機能
表1.2 テクノロジープレビュートラッカー
機能OCP 4.4OCP 4.5OCP 4.6

Precision Time Protocol (PTP)

TP

TP

TP

oc CLI プラグイン

TP

TP

TP

experimental-qos-reserved

TP

TP

TP

Pod Unidler

TP

GA

GA

一時ストレージの制限/要求

TP

TP

TP

Descheduler

TP

TP

TP

Podman

TP

TP

TP

PID Namespace のコントロール共有

TP

GA

GA

OVN-Kubernetes クラスターネットワークプロバイダー

TP

TP

GA

Prometheus に基づく HPA カスタムメトリクスアダプター

TP

TP

TP

メモリー使用率のための HPA

TP

TP

TP

3 ノードのベアメタルデプロイメント

TP

GA

GA

サービスバインディング

TP

TP

TP

ログ転送

TP

TP

GA

ユーザー定義プロジェクトのモニターリング

TP

TP

GA

コンピュートノードトポロジーマネージャー

TP

GA

GA

Cinder での raw ブロック

TP

TP

TP

CSI ボリュームスナップショット

TP

TP

TP

CSI ボリュームのクローン作成

TP

TP

GA

CSI ボリューム拡張

TP

TP

TP

CSI AWS EBS Driver Operator

-

TP

TP

OpenStack Manila CSI ドライバー Operator

-

GA

GA

Red Hat Virtualization (oVirt) CSI ドライバー Operator

-

-

GA

CSI インラインの一時ボリューム

-

TP

TP

Local Storage Operator を使用した自動デバイス検出およびプロビジョニング

-

-

TP

OpenShift Pipeline

TP

TP

TP

Vertical Pod Autoscaler

-

TP

TP

Operator API

-

TP

GA

カーネルモジュールのノードへの追加

TP

TP

TP

Docker Registry v1 API

  

DEP

CPU マネージャー

TP

TP

GA

1.7. 既知の問題

  • ユーザーによってプロビジョニングされるインフラストラクチャーで vSphere 上の仮想マシンの電源をオンにすると、ノードのスケールアッププロセスは予想通りに機能しない可能性があります。ハイパーバイザー設定の既知の問題により、ハイパーバイザー内にマシンが作成されますが、電源がオンになりません。マシンセットをスケールアップした後にノードが Provisioning 状態のままである場合、vSphere インスタンス自体で仮想マシンのステータスを調査できます。VMware コマンド govc tasks および govc events を使用して、仮想マシンのステータスを判別します。以下のようなエラーメッセージがあるかどうかを確認します。 

    [Invalid memory setting: memory reservation (sched.mem.min) should be equal to memsize(8192). ]

    この VMware KBase の記事 にある手順に従って、問題の解決を試行できます。詳細は、Red Hat ナレッジベースのソリューションの [UPI vSphere] Node scale-up doesn't work as expected を参照してください。(BZ#1918383)

  • OpenShift Container Platform 4.6.8 では、Cluster Logging Operator (CLO) で証明書が再生成される方法が変更されたバグ修正が導入されました。今回の修正により、OpenShift Elasticsearch Operator (EO) がクラスターの再起動を試行する際に CLO が証明書を再生成する可能性が出る問題が生じました。これにより、EO とクラスター間の通信で問題が生じ、EO ノードが一致しない証明書を持つことが予想されます。

    Elasticsearch のアップグレード時に、一致しない証明書によって問題が発生する可能性がありました。回避策として、CLO と EO を別々にアップグレードできます。これが機能しない場合は、以下のコマンドを実行して Elasticsearch Pod を再起動します。 

    $ oc delete pod -l component=es

    Pod の再起動後に、一致しない証明書が修正され、アップグレードの問題が解決されます。(BZ#1906641)

  • 現時点で、OVN-Kubernetes クラスターネットワークプロバイダーを使用した OpenShift Container Platform 4.5 から 4.6 へのアップグレードは機能しません。この問題は、今後の 4.6.z リリースで解決される予定です。(BZ#1880591)
  • 現時点で、クラスターの 75 を超えるノードにスケーリングすると、OVN-Kubernetes クラスターネットワークプロバイダーのデータベースが破損し、クラスターが使用不可の状態になる可能性があります。(BZ#1887585)
  • 現時点で、OVN-Kubernetes クラスターネットワークプロバイダーを使用したクラスターでの Red Hat Enterprise Linux (RHEL) ワーカーノードのスケールアップは機能しません。これは、今後の RHEL 7.8.z および RHEL 7.9.z リリースで解決されます。(BZ#1884323, BZ#1871935)
  • 現時点で、Red Hat Enterprise Linux (RHEL) 7.8 で実行されているワーカーノードをスケールアップすると、OVN-Kubernetes ネットワークプロバイダーは新規ノードで初期化できません。(BZ#1884323)
  • OpenShift Container Platform 4.6 から 4.5 へのダウングレードについては、今後の 4.5.z リリースで修正されます。(BZ#1882394, BZ#1886148, BZ#1886127)
  • 現時点で、Red Hat Enterprise Linux (RHEL) ワーカーノードを使用した OpenShift Container Platform 4.5 から 4.6 へのアップグレードは機能しません。この問題は、今後の 4.6.z リリースで解決される予定です。まず、RHEL をアップグレードしてからクラスターをアップグレードし、通常の RHEL アップグレード Playbook を再度実行します。(BZ#1887607)
  • OpenShift Container Platform 4.5 から 4.6 へのアップグレードは、外部ネットワークがボンディングデバイスに設定されていると失敗します。ovs-configuration サービスが失敗し、ノードに到達できなくなります。この問題は、今後の 4.6.z リリースで解決される予定です。(BZ#1887545)
  • 現時点で、Huge Page はいくつかの NUMA (Non-Uniform Memory Access) ノードで要求されると適切に検出されません。これが生じるのは、テストで 1 つの NUMA の Huge Page 数とノード全体の Huge Page の合計数が比較されるためであり、クラスターに複数の NUMA ノードが含まれる場合に cnf-tests スイートでエラーが報告されます。(BZ#1889633)
  • パケット転送を確認し、受信するために使用される Data Plane Development Kit (DPDK) テストは常に失敗します。(BZ#1889631)
  • 未加工 (raw) 設定のないマシン設定が 1 つ以上あると、SCTP (Stream Control Transmission Protocol) 検証フェーズに失敗します。たとえば、これにはカーネル引数のみが含まれるマシン設定が含まれます。(BZ#1889275)
  • cnf-tests スイートが PTP を実行しているノードの数を適切に検出しないため、Precision Time Protocol (PTP) 検証フェーズは失敗します。(BZ#1889741)
  • ノード上のデバイスが利用可能になるまで待機しないため、ネットワークインターフェイスカード (NIC) の検証フェーズは失敗します。Pod がノードで実行を開始するまでの待機時間が短すぎるため、Pod のステータスが Pending のままとなり、誤ってテストされる可能性があります。(BZ#1890088)
  • ose-egress-dns-proxy イメージには、コンテナーの起動を防ぐ既知の不具合があります。このイメージは以前のリリースについても破損状態されたため、4.6 のリグレッションとみなされません。(BZ#1888024)

  • OpenShift Container Platform 4.1 では、匿名ユーザーは検出エンドポイントにアクセスできました。後のリリースでは、一部の検出エンドポイントは集約された API サーバーに転送されるため、このアクセスを無効にして、セキュリティーの脆弱性の可能性を減らすことができます。ただし、既存のユースケースに支障がで出ないように、認証されていないアクセスはアップグレードされたクラスターで保持されます。

    OpenShift Container Platform 4.1 から 4.6 にアップグレードされたクラスターのクラスター管理者の場合、認証されていないアクセスを無効にするか、またはこれを引き続き許可することができます。特定の必要がなければ、認証されていないアクセスを無効にすることが推奨されます。認証されていないアクセスを引き続き許可する場合は、それに伴ってリスクが増大することに注意してください。

    警告

    認証されていないアクセスに依存するアプリケーションがある場合、認証されていないアクセスを取り消すと HTTP 403 エラーが生じる可能性があります。

    以下のスクリプトを使用して、検出エンドポイントへの認証されていないアクセスを無効にします。 

    ## Snippet to remove unauthenticated group from all the cluster role bindings
$ for clusterrolebinding in cluster-status-binding discovery system:basic-user system:discovery system:openshift:discovery ;
do
### Find the index of unauthenticated group in list of subjects
index=$(oc get clusterrolebinding ${clusterrolebinding} -o json | jq 'select(.subjects!=null) | .subjects | map(.name=="system:unauthenticated") | index(true)');
### Remove the element at index from subjects array
oc patch clusterrolebinding ${clusterrolebinding} --type=json --patch "[{'op': 'remove','path': '/subjects/$index'}]";
done

    このスクリプトは、認証されていないサブジェクトを以下のクラスターロールバインディングから削除します。

    • cluster-status-binding
    • discovery
    • system:basic-user
    • system:discovery
    • system:openshift:discovery

    (BZ#1821771)

  • operator-sdk new または operator-sdk create api コマンドを --helm-chart フラグを指定せずに実行すると、デフォルトのボイラープレート Nginx チャートを使用する Helm ベースの Operator がビルドされます。このサンプルチャートはアップストリーム Kubernetes で正常に機能しますが、OpenShift Container Platform では正常にデプロイできません。

    この問題を回避するには、--helm-chart フラグを使用して、OpenShift Container Platform に正常にデプロイされる Helm チャートを提供します。以下は例になります。 

    $ operator-sdk new <operator_name> --type=helm \
  --helm-chart=<repo>/<name>

    (BZ#1874754)

  • Redfish Virtual Media 機能を使用してベアメタルノードに OpenShift Container Platform をインストールすると、Baseboard Management Controller (BMC) がプロビジョニングネットワークから仮想メディアイメージの読み込みを試行する際に失敗します。これは、BMC がプロビジョニングネットワークを使用しない場合や、そのネットワークでプロビジョニングネットワークにルーティングが設定されていない場合に発生します。回避策として、仮想メディアを使用する場合はプロビジョニングネットワークをオフにするか、前提条件として BMC をプロビジョニングネットワークにルーティングする必要があります。(BZ#1872787)
  • OpenShift Container Platform インストールプログラムは、既知の問題により GCP および Azure で install-config.yaml ファイルを使用して手動モード設定をサポートしません。その代わりに、Azure の IAM の手動作成 について、および GCP の IAM の手動作成 について説明されているように、クラスターのインストールプロセスのマニフェストの生成段階で設定マップをマニフェストディレクトリーに手動で挿入する必要があります。(BZ#1884691)
  • 電源環境で Pod が FC の Persistent Volume Claim (永続ボリューム要求、PVC) および targetWWN をパラメーターとして作成されると、FC ボリュームの割り当ては no fc disk found エラーを出して失敗し、Pod は ContainerCreating state 状態のままになります。(BZ#1887026)
  • egress IP を提供するノードがシャットダウンすると、そのノードでホストされる Pod は egress IP を提供する別のノードに移動しません。これにより、egress IP を提供するノードがシャットダウンすると、Pod の送信トラフィックは常に失敗します。(BZ#1877273)
  • 既知の問題により us-gov-east-1 リージョンにインストールする場合、プライベートの非接続クラスターのインストールは AWS GovCloud ではサポートされません。(BZ#1881262).

  • インストーラーでプロビジョニングされるインフラストラクチャーの Google Cloud Platform (GCP) で実行しているクラスターを破棄する際に、インフラストラクチャー ID の接頭辞のないマシンが使用するファイアウォールルールが保持されます。これにより、インストールプログラムの破棄プロセスが失敗します。回避策として、GCP Web コンソールでマシンのファイアウォールルールを手動で削除する必要があります。 

    $ gcloud compute firewall-rules delete <firewall_rule_name>

    見つからないインフラストラクチャー ID を持つマシンのファイアウォールルールが削除されると、クラスターを破棄できます。(BZ#1801968)

  • opm alpha bundle build コマンドは、Windows 10 で失敗します。(BZ#1883773)

  • OpenShift Container Platform 4.6 では、リソースメトリクス API サーバーはカスタムリソースのサポートを提供します。リソースメトリクス API サーバーは OpenAPI 仕様を実装せず、以下のメッセージが kube-apiserver ログに送信されます。 

    controller.go:114] loading OpenAPI spec for "v1beta1.metrics.k8s.io" failed with: OpenAPI spec does not exist
controller.go:127] OpenAPI AggregationController: action for item v1beta1.metrics.k8s.io: Rate Limited Requeue.

    場合によっては、これらのエラーによって KubeAPIErrorsHigh アラートが実行される可能性はありますが、OpenShift Container Platform 機能の低下についての根本的な問題は認識されません。(BZ#1819053)

  • ルール API バックエンドは、ストア API ストアがルール API ストアの前に検出される場合に検出されないことがあります。これが発生すると、ルール API クライアントなしでストア参照が作成され、Thanos Querier からの Rules API エンドポイントはルールを返しません。(BZ#1870287)

  • AWS アカウントが、グローバル条件を使用してすべてのアクションを拒否するか、または特定のパーミッションを要求する AWS Organizations サービスコントロールポリシー (SCP) を使用するように設定されている場合、パーミッションを検証する AWS ポリシーシミュレーター API が誤検出を生成します。パーミッションを検証できない場合、提供される認証情報にインストールに必要なパーミッションがある場合でも、OpenShift Container Platform AWS のインストールに失敗します。

    この問題を回避するには、credentialsMode パラメーターの値を install-config.yaml 設定ファイルに設定して、AWS ポリシーシミュレーターのパーミッションチェックをバイパスできます。credentialsMode の値は、Cloud Credential Operator (CCO) の動作を 3 つのサポートされるモード のいずれかに変更します。

    サンプル install-config.yaml 設定ファイル

    apiVersion: v1
baseDomain: cluster1.example.com
credentialsMode: Mint 1
compute:
- architecture: amd64
  hyperthreading: Enabled
...

    1
    この行は、credentialsMode パラメーターを Mint に設定するために追加されます。

    このチェックを省略する場合、指定する認証情報に、指定されたモードに必要なパーミッション があることを確認します。

    (BZ#1829101)

  • RHOSP 上で実行され、Kuryr を使用するクラスターは、それぞれの hostNetworking Pod に不要な Neutron ポートを作成します。これらのポートは安全に削除できます。ポートの自動削除は、OpenShift Container Platform の今後のリリースで予定されています。(BZ#1888318)
  • Kuryr で設定された RHOSP のデプロイメントでは、kuryr-cni Pod がクラッシュループになる可能性がありました (NetlinkError: (17, 'File exists') エラーを報告する)。回避策として、ノードを再起動する必要があります。OpenShift Container Platform の今後のリリースでこの問題を解決する修正が提供されることが予定されています。(BZ#1869606)
  • egress ルーター Pod を DNS プロキシーモードでデプロイする場合、Pod は初期化に失敗します。(BZ#1888024)
  • RHCOS リアルタイム (RT) カーネルは、現時点ではコンピュートノードでのみサポートされており、コントロールプレーンノードではサポートされていません。コンパクトなクラスターは、OpenShift Container Platform 4.6 の RT カーネルではサポートされていません。(BZ#1887007)

  • セキュリティーを強化するために、NET_RAW および SYS_CHROOT 機能は CRI-O 機能のデフォルトリストで選択できなくなりました。

    • NET_RAW: 保護されていない場合、この機能により、Pod で Low ポート、ソース IP アドレス、ソース MAC アドレスなどのヘッダーフィールドを変更できるパケットを作成できるようになります。この機能により、悪意のあるハッキングが試行される可能性があります。
    • SYS_CHROOT: 通常ワークロードに chroot は必要ありません。特権付きの操作へのアクセスは、必要な場合にのみ付与される必要があります。

    NET_RAW および SYS_CHROOT 機能は OpenShift Container Platform 4.5.16 のデフォルト機能として削除されています。4.5.16 よりも前のリリースで作成されたクラスターへの影響を軽減するために、デフォルトの機能一覧は、 99-worker-generated-crio-capabilities および 99-master-generated-crio-capabilities などの別個のマシン設定に含まれるようになりました。OpenShift Container Platform は、以前のリリースから更新する際に新規マシン設定を作成します。

    アップグレード後に、NET_RAW および SYS_CHROOT 機能を無効にしてから、ワークロードをテストすることが推奨されます。これらの機能を削除する準備ができたら、 99-worker-generated-crio-capabilities および 99-master-generated-crio-capabilities マシン設定を削除します。

    重要: 以前のリリースから更新する場合は、4.6 に更新する前に 4.5.16 に更新してください。(BZ#1874671).

  • OpenShift Container Platform Machine API ベアメタルアクチュエーターは、基礎となるベアメタルホストが削除されると Machine オブジェクトを削除します。この動作は、基礎となるクラウドプロバイダーリソースが削除される場合に Machine オブジェクトをすべて削除する代わりに failed (失敗) フェーズに移行する他のクラウドプロバイダーアクチュエーターの動作と一致しません。(BZ#1868104)
  • クラスターを vSphere でインストーラーでプロビジョニングされるインフラストラクチャーでインストールされたバージョン 4.5 から 4.6 にアップグレードする場合、コントロールプレーンノードの IP アドレスがアップグレード時に変更される場合にアップグレードに失敗します。回避策として、バージョン 4.6 にアップグレードする前にコントロールプレーンノードの IP アドレスを予約する必要があります。予約の設定については、DHCP サーバーのドキュメントを参照してください。(BZ#1883521)

  • TLS 検証を必要とする oc コマンドの場合、証明書が Subject Alternative Name を設定しない場合、検証は Common Name フィールドにフォールバックせず、コマンドは以下のエラーを出して失敗します。 

    x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

    回避策として、適切な Subject Alternative Name が設定された証明書を使用するか、または oc コマンドに GODEBUG=x509ignoreCN=0 を付けてこの動作を一時的に上書きできます。

    今後の 4.6 z-stream はエラーではなく警告を返す可能性があり、ユーザーは証明書を準拠するよう更新するためにより長い時間を確保できる可能性があります。

    (BZ#1889204)

  • Helm パッケージマネージャーを使用して Agones をインストールし、Developer パースペクティブを使用して namespace のチャートリソースの調査を試行すると、リソースの詳細ではなくエラーメッセージが表示されます。(BZ#1866087)
  • Topology ビューでデプロイメントを選択する場合は、Actions → Edit <deployment_name> をクリックしてからこれを変更します。変更した Deployment YAML ファイルは Pod Template spec のボリュームマウントを上書きするか、または削除します。(BZ#1867965)
  • Add → From Catalog オプションを使用し、Template でフィルターし、テンプレートを選択してからテンプレートをインスタンス化する際に、成功または失敗のいずれのメッセージも Developer パースペクティブに表示されません。(BZ#1876535)
  • 省略されたタスクを持つ PipelineRun は、タスクを誤って Failed と表示します。(BZ#1880389)
  • Application Stages ビューの Application Details ページでは、アプリケーション環境のプロジェクトの正しくないリンクが提供されます。(BZ#1889348)
  • 負荷の大きい Pod 作成の状況では、作成が error reserving pod name …​: name is reserved のメッセージを出して失敗します。CNI 実行可能ファイルの CRI-O のコンテキストは終了し、プロセスを強制終了します。Pod の作成は最終的に成功しますが、長い時間がかかります。そのため、kubelet は CRI-O が Pod を作成していないものと見なします。kubelet は要求を再び送信し、名前の競合が発生します。この問題は現在調査中です。(BZ#1785399)
  • クラスターネットワークプロバイダーが OVN-Kubernetes の場合、クラスター内のノードに割り当てられないサービスの外部 IP アドレスを使用する場合、外部 IP アドレスへのネットワークトラフィックはルーティングできません。回避策として、サービスの外部 IP アドレスがクラスター内のノードに常に割り当てられるようにします。(BZ#1890270)

  • 管理者は、redhat-operators カタログをミラーリングして、ネットワークが制限された環境 (非接続クラスターとしても知られる) の OpenShift Container Platform 4.6 クラスターで Operator Lifecycle Manager (OLM) を使用できます。ただし、以下の Operator は、予想されるパブリックホスト名 registry.redhat.io ではなく、プライベートホスト名 registry-proxy.engineering.redhat.com で mapping.txt ファイルのエントリーを返します。

    • amq-online.1.5.3
    • amq-online.1.6.0

    これにより、イメージのプルはアクセス不可能なプライベートレジストリー (通常は内部 Red Hat テスト用) に対して失敗します。この問題を回避するには、mapping.txt ファイルを生成した後に以下のコマンドを実行します。 

    $ sed -i -e 's/registry-proxy.engineering.redhat.com/registry.redhat.io/g' \
    -e 's/rh-osbs\/amq7-/amq7\//g' \
    -e 's/amq7\/tech-preview-/amq7-tech-preview\//g' \
    ./redhat-operator-index-manifests/imageContentSourcePolicy.yaml \
    ./redhat-operator-index-manifests/mapping.txt

    PowerVM での IBM Power Systems の OpenShift Container Platform については、以下の制限を優先的に考慮してください。

    • マスターノード用に 2 つの仮想 CPU
    • ワーカーノード用に 4 つの仮想 CPU
    • すべてのノード用に 0.5 プロセッサー
    • すべてのノード用に 32 GB の仮想 RAM

  • Red Hat Operator の公開プロセスのバグにより、OpenShift Container Platform 4.6 インデックスイメージのステージ環境用のバージョンが一時的に公開されました。このバグが解決され、イメージが正しいコンテンツですぐに再公開されました。

    このステージレジストリーイメージの使用時に Operator のインストールまたはアップグレードを試行する場合、openshift-marketplace namespace のジョブは、予想されるパブリックホスト名の registry.redhat.io ではなく、プライベートホスト名の registry.stage.redhat.io を示す以下のエラーを出して失敗する可能性がありました。

    出力例

    ImagePullBackOff for
Back-off pulling image "registry.stage.redhat.io/openshift4/ose-elasticsearch-operator-bundle@sha256:6d2587129c746ec28d384540322b40b05833e7e00b25cca584e004af9a1d292e"

    出力例

    rpc error: code = Unknown desc = error pinging docker registry registry.stage.redhat.io: Get "https://registry.stage.redhat.io/v2/": dial tcp: lookup registry.stage.redhat.io on 10.0.0.1:53: no such host

    これにより、イメージのプルはアクセス不可能なプライベートレジストリー (通常は内部 Red Hat テスト用) に対して失敗し、関連する Operator のインストールおよびアップグレードは失敗しました。この問題の回避策については、問題のあるサブスクリプションの更新 について参照してください。(BZ#1909152)

  • oc annotate コマンドは、等号 (=) が含まれる LDAP グループ名では機能しません。これは、コマンドがアノテーション名と値の間に等号を区切り文字として使用するためです。回避策として、oc patch または oc edit を使用してアノテーションを追加します。(BZ#1917280)
  • OVN-Kubernetes ネットワークプロバイダーは、NodePort タイプサービスおよび LoadBalancer タイプサービスの externalTrafficPolicy 機能をサポートしていません。service.spec.externalTrafficPolicy フィールドは、サービスのトラフィックをノードローカルまたはクラスター全体のエンドポイントにルーティングするかどうかを決定します。現在、このようなトラフィックはデフォルトでクラスター全体のエンドポイントにルーティングされており、トラフィックをノードローカルエンドポイントに制限する方法はありません。この問題は、今後のリリースで解決される予定です。(BZ#1903408)
  • 現在、Kubernetes ポートの衝突の問題により、Pod が再デプロイされた後でも、Pod 間の通信が機能しなくなる可能性があります。詳細および回避策については、Red Hat ナレッジベースソリューションの Port collisions between pod and cluster IPs on OpenShift 4 with OVN-Kubernetes を参照してください。(BZ#1939676、BZ#1939045)

1.8. エラータの非同期更新

OpenShift Container Platform 4.6 のセキュリティー、バグ修正、拡張機能の更新は、Red Hat Network 経由で非同期エラータとして発表されます。OpenShift Container Platform 4.6 のすべてのエラータは Red Hat カスタマーポータルから入手 できます。非同期エラータについては、OpenShift Container Platform ライフサイクル を参照してください。

Red Hat カスタマーポータルのユーザーは、Red Hat Subscription Management (RHSM) のアカウント設定でエラータの通知を有効にすることができます。エラータの通知を有効にすると、登録しているシステムに関連するエラータが新たに発表されるたびに、メールで通知が送信されます。

注記

OpenShift Container Platform のエラータ通知メールを生成させるには、Red Hat カスタマーポータルのユーザーアカウントでシステムが登録されており、OpenShift Container Platform エンタイトルメントを使用している必要があります。

以下のセクションは、これからも継続して更新され、今後の OpenShift Container Platform 4.6 バージョンの非同期リリースで発表されるエラータの拡張機能およびバグ修正に関する情報を追加していきます。たとえば、OpenShift Container Platform 4.6.z などのバージョン付けされた非同期リリースについてはサブセクションで説明します。さらに、エラータの本文がアドバイザリーで指定されたスペースに収まらないリリースについては、詳細についてその後のサブセクションで説明します。

重要

OpenShift Container Platform のいずれのバージョンについても、クラスターの更新 に関する指示には必ず目を通してください。

1.8.1. RHBA-2020:4196 - OpenShift Container Platform 4.6 イメージリリースおよびバグ修正アドバイザリー

発行日: 2020-10-27

OpenShift Container Platform release 4.6 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2020:4196 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは、RHBA-2020:4197 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.1 --pullspecs

1.8.2. RHSA-2020:4297 - Moderate (中程度): OpenShift Container Platform 4.6 パッケージセキュリティーの更新

発行日: 2020-10-27

jenkins-2-plugins、openshift-clients、podman、 runc、および skopeo の更新が OpenShift Container Platform 4.6 で利用可能になりました。更新の詳細については、RHSA-2020:4297 アドバイザリーに記載されています。

1.8.3. RHSA-2020:4298 - Moderate (中程度): OpenShift Container Platform 4.6 イメージセキュリティーの更新

発行日: 2020-10-27

いくつかのイメージの更新が OpenShift Container Platform 4.6 で利用可能になりました。更新の詳細については、RHSA-2020:4298 アドバイザリーに記載されています。

1.8.4. RHBA-2020:4339 - OpenShift Container Platform 4.6.3 バグ修正の更新

発行日: 2020-11-09

OpenShift Container Platform リリース 4.6.3 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2020:4339 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは、 RHBA-2020:4340 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.3 --pullspecs
1.8.4.1. バグ修正
  • 既知の問題により、GPU Operator および Node Feature Discovery (NFD) Operator は、OpenShift Container Platform 4.6.1 の新規インストールでは使用できませんでした。GPU および NFD Operator を使用するには、OpenShift Container Platform 4.5 をインストールし、クラスターをバージョン 4.6.1 にアップグレードする必要がありました。この問題は修正され、GPU および NFD Operator は OpenShift Container Platform 4.6.3 以降の新規インストールで利用可能になりました。(BZ#1890673)
1.8.4.2. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.5. RHBA-2020:4987 - OpenShift Container Platform 4.6.4 バグ修正の更新

発行日: 2020-11-16

OpenShift Container Platform リリース 4.6.4 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2020:4987 アドバイザリーにまとめられています。本リリース用の RPM パッケージはありません。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.4 --pullspecs
1.8.5.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.6. RHBA-2020:5115 - OpenShift Container Platform 4.6.6 バグ修正の更新

発行日: 2020-11-30

OpenShift Container Platform リリース 4.6.6 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2020:5115 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは、RHBA-2020:5116 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.6 --pullspecs
1.8.6.1. バグ修正

  • OpenShift Container Platform 4.6 よりも前のバージョンでは、Marketplace Operator が OperatorSource カスタムリソース定義 (CRD) を使用する場合、ネットワークが制限されたネットワーク (非接続クラスターとしても知られる) でクラスターを使用するクラスター管理者は、openshift-marketplace namespace のデフォルトの OperatorSource オブジェクトを無効にし、デフォルトソースと同じ名前のカスタム CatalogSource オブジェクトを作成することができました。OpenShift Container Platform 4.6 では、Marketplace Operator は OperatorSource CRD が削除されるため、 CatalogSource オブジェクトを直接使用するようになりました。その結果、openshift-marketplace には OperatorHub API によって管理されるデフォルトのカタログソースが含まれます。

    非接続の OpenShift Container Platform 4.6 クラスターでデフォルトのカタログソースを無効にした後に、管理者がデフォルトソースと同じ名前でカタログソースの作成を試行すると、OperatorHub API は以前はカスタムカタログソースを削除していました。カタログソースが OperatorHub API を使用して無効にされず、デフォルトのカタログソースに変更が加えられている場合 (例: spec.image パラメーターが非接続環境の内部レジストリーを参照するように変更されている場合)、仕様はデフォルトの仕様に復元されました。

    今回のバグ修正により、クラスター管理者は OperatorHub API を使用して無効にされている場合に、デフォルトソースと同じ名前のカスタムカタログソースを作成し、更新し、削除できるようになりました。その結果、管理者はデフォルトのカタログソースを無効にし、削除または上書きすることなくデフォルト名を使用してカスタムカタログソースを作成できるようになりました。デフォルトのカタログソースを再度有効にされると、デフォルトの仕様が復元されます。(BZ#1895952)

1.8.6.2. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.7. RHSA-2020:5159 - 低: OpenShift Container Platform 4.6 パッケージのセキュリティー更新

発行日: 2020-11-30

golang の更新が OpenShift Container Platform 4.6 で利用可能になりました。更新の詳細については、RHSA-2020:5159 アドバイザリーに記載されています。

1.8.8. RHSA-2020:5259 - OpenShift Container Platform 4.6.8 バグ修正およびセキュリティー更新

発行日: 2020-12-14

OpenShift Container Platform release 4.6.8 が公開されました。この更新に含まれるバグ修正の一覧は、RHSA-2020:5259 アドバイザリーに一覧表示されます。この更新に含まれる RPM パッケージは、 RHSA-2020:5260 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.8 --pullspecs
1.8.8.1. 機能
1.8.8.1.1. Red Hat Enterprise Linux CoreOS (RHCOS) の新規のブートイメージが利用可能になる

新規 RHCOS ブートイメージが OpenShift Container Platform 4.6.8 リリースの一部として利用可能になりました。更新された RHCOS ブートイメージにより、クラスターのブート機能が強化されます。(BZ#1899176)

1.8.8.1.2. EUS 4.6 アップグレードチャネルが利用可能になる

eus-4.6 アップグレードチャネルが利用可能になりました。このチャネルは Extended Update Support (EUS) を提供します。EUS バージョンでは、プレミアムサブスクリプションをお持ちのお客様の場合、メンテナーンスフェーズを 14 カ月に拡張されています。OpenShift Container Platform詳細は、OpenShift Container Platform アップグレードチャネルおよびリリース について参照してください。

1.8.8.2. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.9. RHSA-2020:5614 - OpenShift Container Platform 4.6.9 バグ修正およびセキュリティー更新

発行日: 2020-12-21

openshift-clients、openvswitch2.13、および python-sushy のセキュリティー更新を含む OpenShift Container Platform リリース 4.6.9 が公開されました。この更新に含まれるバグ修正の一覧は、RHSA-2020:5614 アドバイザリーに一覧表示されます。この更新に含まれる RPM パッケージは、 RHSA-2020:5615 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.9 --pullspecs
1.8.9.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.10. RHSA-2021:0037: OpenShift Container Platform 4.6.12 バグ修正およびセキュリティー更新

発行日: 2021-01-18

セキュリティー更新を含む OpenShift Container Platform リリース 4.6.12 が利用可能になりました。この更新に含まれるバグ修正の一覧は、RHSA-2021:0037 アドバイザリーに一覧表示されます。この更新に含まれる RPM パッケージは、RHSA-2021:0038 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.12 --pullspecs
1.8.10.1. バグ修正
  • OpenShift Container Platform 4.6.9 で導入されたパフォーマンス関連の修正により、ネットワークポリシーを持つクラスターで、ネットワークポリシーを持たない namespace であってもアップグレード後にネットワーク接続の問題が生じました。これらのパフォーマンス関連の修正は元に戻され、ネットワークポリシーを持つクラスターが再び適切に動作するようになりました。(BZ#1915007)
  • 以前のリリースでは、Red Hat OpenStack Platform (RHOSP) での OpenShift Container Platform の起動前 (pre-flight) のインストーラーの検証がフレーバーのメタデータに対して実行されました。これにより、インストールの完了に必要な容量がある可能性のある、baremetal と検出されるフレーバーへのインストールが阻止される可能性がありました。通常、これは RHOSP 管理者がベアメタルフレーバーに適切なメタデータを設定しないことによって生じます。baremetal と検出されるフレーバーでの検証が省略され、間違って失敗がが報告されることがなくなりました。(BZ#1889416)
  • 以前のリリースでは、ephemeral-storage リソース計算は機能ゲートとして提供されませんでしたが、これは機能が無効にされている場合でも利用可能でした。これにより、Pod のスケジュールが失敗しました。ephemeral-storage リソースは機能ゲートとして使用でき、無効にされる場合は機能が削除されるようになりました。(BZ#1913263)
  • terser の依存関係のバグにより、YAML Editor コンポーネントの永続的なアンマウントおよび再マウントが生じました。これにより、Web コンソールの YAML エディターが数秒ごとに YAML ファイルの上部に移動しました。これは、デフォルトのパラメーター値を削除することで一時的に修正され、これにより YAML エディターが予想通りに機能するようになりました。(BZ#1910066)
  • 以前のバージョンでは、クラスターはデーモンセットが準備状態になる前に must-gather ログを収集することがありました。これにより、空のファイルが作成されました。これは、すべての生成されるファイルに実際のコンテンツが含まれるようにするために、must-gather ログを収集する前にデーモンセットが準備状態にあることを確認できるようにすることにより修正されています。(BZ#1852619)
1.8.10.2. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.11. RHSA-2021:0171 - OpenShift Container Platform 4.6.13 バグ修正およびセキュリティー更新

発行日: 2021-01-25

セキュリティー更新を含む OpenShift Container Platform リリース 4.6.13 が利用可能になりました。この更新に含まれるバグ修正の一覧は、RHSA-2021:0171 アドバイザリーに一覧表示されます。この更新に含まれる RPM パッケージは、RHSA-2021:0172 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.13 --pullspecs
1.8.11.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.12. RHBA-2021:0235: OpenShift Container Platform 4.6.15 バグ修正の更新

発行日: 2021-02-01

OpenShift Container Platform リリース 4.6.15 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:0235 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは、RHBA-2021:0237 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.15 --pullspecs
1.8.12.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.13. RHSA-2021:0308: OpenShift Container Platform 4.6.16 バグ修正およびセキュリティー更新

発行日: 2021-02-08

セキュリティー更新を含む OpenShift Container Platform リリース 4.6.16 が利用可能になりました。この更新に含まれるバグ修正の一覧は、RHSA-2021:0308 アドバイザリーに一覧表示されます。この更新に含まれる RPM パッケージは RHBA-2021:0309 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.16 --pullspecs
1.8.13.1. 機能
1.8.13.1.1. Insights Operator の機能拡張

Insights Operator は以下の追加情報を収集します。

  • MachineConfigPool オブジェクトの設定ファイル
  • インストール計画の数。
  • 汎用コントロールプレーンの設定ファイル
  • クラスターで実行されている Red Hat イメージのセット
  • openshift* namespace の Pod のクラッシュループについての情報

この情報は、トラブルシューティングに役立ちます。詳細は、BZ#1887759、BZ#1889676、BZ#1905031、および BZ#1913645 を参照してください。

1.8.13.2. バグ修正
  • 以前のバージョンでは、Windows バイナリーのビルドプロセスでバージョン情報メタデータが生成されませんでした。今回の更新により、Red Hat の golang コンパイラーでのビルドプロセス中に Windows バージョン情報が生成され、Windows バイナリーのバージョン情報が表示されるようになりました。(BZ#1891892)
  • ベアメタルのインストーラーでプロビジョニングされるインフラストラクチャーに組み込まれる Ironic API サービスは、8 つのワーカーではなく 4 つのワーカーを使用するようになりました。この変更により、RAM の使用率が低下します。(BZ#1899107)

  • 以前のバージョンでは、認証リソースの serviceAccountIssuer フィールドを変更することで、新規の発行者でトークンを検証し、以前の発行者でトークンを拒否するよう kubi-apiserver が更新されました。kubi-apiserver は複数の発行者に対応しないため、serviceAccountIssuer を変更すると、バインドされたトークンに依存するアプリケーションが中断される可能性があります。既存のトークンが kubi-apiserver から 401 応答を受信する際に、アプリケーションが新規トークンを要求するようにコーディングされない限り、ハードウェアが再起動するか、または無効なトークンがその期間の 80% を超えるまで無効なトークンが使用されます。この時点で、kubelet は新規トークンを要求します。

    回避策として、中断が許容される場合に serviceAccountIssuer フィールドのみを変更し、すべての Pod の再起動をオプションとして実行します。(BZ#1905573)

  • 以前のバージョンでは、create role binding フォームにロール名がありませんでした。今回の更新により、create role binding フォームでロール名が表示されるようになりました。(BZ#1905788)
  • 以前のバージョンでは、クライアントスロットリングの下限の設定により、クラスターにインストールされる CRD の数が増えることがありました。そのため、API 検出に到達する要求はクライアントコードによって制限されました。今回の修正により、制限の数が現在の量の 2 倍に引き上げられ、クライアント側のスロットリングの頻度が低くなりました。(BZ#1906332)
  • 正しくないユーザー名を使用してイメージの署名を検証する場合、イメージ署名の検証を実行できません。適切なユーザー名を使用すると、イメージ署名の検証が意図された通りに機能します。(BZ#1906796)
  • 以前のバージョンでは、トリガーが同じブローカーから Knative Service (KSVC) および In Memory Channel (IMC) に移動すると、Knative リソースは Topology ビューに表示されませんでした。今回の更新により、Knative データが適切に返され、Topology ビューが Knative リソースを適切に表示されるようになりました。(BZ#1907827)
  • 以前のバージョンでは、oc debug command への変更時に init コンテナーのサポートが失われました。そのため、init コンテナーをデバッグできませんでした。今回の更新により、oc debug command で init コンテナーのサポートが追加され、init コンテナーのデバッグが可能になりました。(BZ#1913109)
  • 以前のバージョンでは、Operator sync の実行中に設定ステータスの更新がない場合、最新の (適用済みの) swift 設定が表示されませんでした。今回の更新により、同期プロセスが修正され、設定のステータスを設定の仕様の値に一致するようになりました。その結果、設定のステータスおよび設定の仕様は、現在の適用された設定と同期するようになりました。(BZ#1916857)
  • 以前のバージョンでは、断続的な DNS エラーにより、ノードの /etc/hosts ファイルに無効なエントリーが作成されていました。今回の更新により、DNS 要求からのエラーメッセージをフィルターできるようになりました。これにより最終的に、dns-node-resolver が無効な /etc/hosts エントリーを作成しないように要求するプロンプトを出す有効なレコードが返されます。(BZ#1916907)
  • 以前のバージョンでは、プロビジョニングのインターフェイスで IPv6 リンクローカルアドレスが失われ、追加のワーカーをプロビジョニングできない可能性がありました。これは修正されています。(BZ#1918779)
1.8.13.3. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.14. RHBA-2021:0424: OpenShift Container Platform 4.6.17 バグ修正およびセキュリティー更新

発行日: 2021-02-15

セキュリティー更新を含む OpenShift Container Platform リリース 4.6.17 が利用可能になりました。この更新に含まれるバグ修正の一覧は、RHBA-2021:0424 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは、RHSA-2021:0423 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.17 --pullspecs
1.8.14.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.15. RHBA-2021:0510: OpenShift Container Platform 4.6.18 バグ修正の更新

発行日: 2021-02-22

OpenShift Container Platform リリース 4.6.18 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:0510 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは、RHBA-2021:0511 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.18 --pullspecs
1.8.15.1. 機能
1.8.15.1.1. Insights Operator の機能拡張

今回の更新により、Insights Operator が ContainerRuntimeConfig オブジェクトの情報を収集するようになりました。この情報は、トラブルシューティングに役立ちます。詳細は、BZ#1891544 を参照してください。

1.8.15.1.2. クラウドプロバイダーの認証情報のローテーションのサポート

今回のリリースにより、クラウドプロバイダーの認証情報の管理に Cloud Credential Operator (CCO) が使用するシークレットを手動で更新できるようになりました。詳細は、クラウドプロバイダーの認証情報の手動によるローテーション について参照してください。

1.8.15.2. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.16. RHBA-2021:0634: OpenShift Container Platform 4.6.19 バグ修正の更新

発行日: 2021-03-01

OpenShift Container Platform release 4.6.19 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:0634 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは、 RHBA-2021:0633 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.19 --pullspecs
1.8.16.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.17. RHBA-2021:0674 - OpenShift Container Platform 4.6.20 バグ修正の更新

発行日: 2021-03-09

OpenShift Container Platform リリース 4.6.20 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:0674 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは RHBA-2021:0673 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.20 --pullspecs
1.8.17.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.18. RHBA-2021:0753 - OpenShift Container Platform 4.6.21 バグ修正の更新

発行日: 2021-03-16

OpenShift Container Platform release 4.6.21 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:0753 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは RHBA-2021:0750 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.21 --pullspecs
1.8.18.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.19. RHBA-2021:0825 - OpenShift Container Platform 4.6.22 バグ修正の更新

発行日: 2021-03-23

OpenShift Container Platform release 4.6.22 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:0825 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは RHBA-2021:0826 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.22 --pullspecs
1.8.19.1. バグ修正
  • 以前のバージョンでは、Zeroconf ライブラリーは、マルチキャスト DNS (mDNS) 応答を正常にレート制限しませんでした。その結果、ネットワークレコードは過剰な mDNS トラフィックで一杯になりました。今回の更新により、Zeroconf ライブラリーにレート制限が追加され、これにより mDNS トラフィックが大幅に削減されるようになりました。(BZ#1936539)
  • 以前のバージョンでは、API サーバーはリソースの作成に失敗し、これにより、リソースクォータの更新時に 409 ステータスコードを返す可能性がありました。そのため、リソースは作成に失敗し、API 要求を再試行する必要がある場合がありました。今回の更新により、OpenShift Web コンソールは 409 のステータスコードを受信する際に要求を 3 回試行します。この回数は要求を実行するのに十分な回数です。409 ステータスコードが継続的に発生する場合、コンソールにエラーが表示されます。(BZ#1938230)
  • 以前のバージョンでは、Prometheus コンテナーの負荷が大きい場合に liveness プローブが失敗しました (例: write-ahead Logging (WAL) の再生時)。この大きな負荷により、複数の問題が発生し、無限の再起動ループが発生しました。今回の更新により、liveness プローブが削除され、その結果として、負荷が大きくなっても無限の再起動ループが生じなくなりました。(BZ#1935586)
  • iptables の書き換えルールにより、サービス IP と Pod IP の両方を介してサービスに接続するために固定ソースポートを使用するクライアントでは、ポートの競合による問題が発生する可能性があります。今回の更新により、ポートの競合が発生した場合に通知用に新たな Open vSwitch (OVS) ルールが挿入され、このような競合を避けるために追加のソースネットワークアドレス変換 (SNAT) ルールが追加されました。その結果、サービスへの接続時にポートの競合が発生しなくなりました。(BZ#1937547)
  • 以前のバージョンでは、ノードには Ready のマークが付けられ、それらは同期前に Pod を許可しました。そのため、Pod status が同期しなくなる可能性があり、ノードの遮断されないと、起動時に nodeAffinity のままになるものが多数ありました。今回の更新により、ノードは少なくとも 1 度は PI サーバーと同期するまで、ノードは Ready とマークされなくなりました。その結果、Pod はクラスターのコールドスタートの再実行後に nodeAffinity のままにならなくなりました。(BZ#1930960)
  • 以前のバージョンでは、アイドル状態にされたワークロードを使用してクラスターを以前のバージョンからアップグレードする場合、アイドル状態にされたワークロードは、oc idle 機能の更新により、OpenShift Container Platform 4.6/4.7 にアップグレードした後は HTTP 要求で起動しませんでした。今回の更新により、アイドリングの変更が Ingress Operator の起動時にエンドポイントからサービスにミラーリングされるようになりました。その結果、アップグレード後のワークロードのアイドリング解除が予想通りに機能するようになりました。(BZ#1927364)
1.8.19.2. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.20. RHBA-2021:0952 - OpenShift Container Platform 4.6.23 バグ修正およびセキュリティー更新

発行日: 2021-03-30

セキュリティー更新を含む OpenShift Container Platform リリース 4.6.23 が利用可能になりました。この更新に含まれるバグ修正の一覧は、RHBA-2021:0952 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは、RHSA-2021:0956 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.23 --pullspecs
1.8.20.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.21. RHBA-2021:1153 - OpenShift Container Platform 4.6.25 バグ修正の更新

発行日: 2021-04-20

OpenShift Container Platform リリース 4.6.25 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:1153 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは RHBA-2021:1154 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.25 --pullspecs
1.8.21.1. 機能
1.8.21.1.1. AWS の VMC へのクラスターのインストール

OpenShift Container Platform クラスターは、クラスターを VMware Cloud (VMC) on AWS にデプロイして VMware vSphere インフラストラクチャーにインストールできます。詳細は、クラスターの VMC へのデプロイ について参照してください。

1.8.21.1.2. 正常でない SAP Pod についての Insights Operator の拡張機能

Insights Operator は正常でない SAP Pod についてのデータを収集できるようになりました。SDI インストールが失敗すると、どの初期化 Pod が失敗したかを確認して問題を検出できます。Insights Operator は、SAP/SDI namespace で失敗した Pod についての情報を収集できるようになりました。詳細は、BZ#1935775 を参照してください。

1.8.21.1.3. SAP ライセンス管理の強化

今回の更新により、以下のコマンドを使用してライセンス管理 Pod で失敗を検出できるようになりました。 

# oc logs deploy/license-management-l4rvh

出力例

Found 2 pods, using pod/license-management-l4rvh-74595f8c9b-flgz9
+ iptables -D PREROUTING -t nat -j VSYSTEM-AGENT-PREROUTING
+ true
+ iptables -F VSYSTEM-AGENT-PREROUTING -t nat
+ true
+ iptables -X VSYSTEM-AGENT-PREROUTING -t nat
+ true
+ iptables -N VSYSTEM-AGENT-PREROUTING -t nat
iptables v1.6.2: can't initialize iptables table `nat': Permission denied

結果が Permission denied を返す場合は、iptables または kernal のアップグレードが必要になる場合があります。詳細は、BZ#1939059 を参照してください。

1.8.21.1.4. メモリーおよびアップタイムのメタデータの Insights Operator アーカイブへの追加

今回の更新により、uptime および memory alloc メタデータが Insights Operator アーカイブに追加され、小規模なメモリーリークが適切に調査できるようになりました。詳細は、BZ#1942457 を参照してください。

1.8.21.2. バグ修正
  • 以前のバージョンでは、NetworkManager の起動前に VMware vSphere メタデータからのホスト名が設定されず、ホスト名が後に設定される場合にこのメタデータが無視されました。今回のリリースにより、ホスト名が vsphere-hostname.service で設定され、この情報が vSphere メタデータで利用可能な場合に NetworkManager が起動するようになりました。(BZ#1904825)
  • 以前のバージョンでは、自動生成された Docker 設定シークレットには、統合された内部レジストリールートの認証情報が含まれませんでした。いずれかのルートでレジストリーにアクセスするための認証情報がないため、レジストリーへのアクセスを試行した Pod は認証情報がないために失敗しました。今回のリリースにより、デフォルトの Docker 認証情報シークレットへの設定されたすべてのレジストリールートが含まれ、Pod はそのルートのいずれかによって統合レジストリーに到達できるようになりました。(BZ#1931857)
  • 以前のバージョンでは、/etc/pki/ca-trust/extracted ファイルは書き込み不可能になる可能性があり、この場合、イメージレジストリー Operator は CA 証明書を Pod の信頼ストアに追加できませんでした。今回のリリースにより、emptyDir ボリュームは /etc/pki/ca-trust/extracted にマウントされ、ボリュームは常に Pod で書き込み可能になりました。(BZ#1936984)
  • 以前のバージョンでは、ユーザーによってプロビジョニングされるインフラストラクチャーの vSphere の nodeip-configuration サービスの正しくない設定が OpenShift Container Platform 4.7 の Machine Config Operator (MCO) で修正されていましたが、OpenShift Container Platform 4.6 では修正されていませんでした。そのため、OpenShift Container Platform をバージョン 4.6.z から異なる 4.6.z にアップグレードしてから 4.7 にアップグレードすると、コントロールプレーンマシンが 4.6.z のアップグレードを完了する前にコントロールプレーンが 4.7 のアップグレードを完了している場合に、4.7 バージョンの MCO がアップグレード全体を停止していました。今回のリリースにより、nodeip-configuration サービスの誤った設定が修正され、アップグレードが正常に実行できるようになりました。(BZ#1940585)
  • 以前のバージョンでは、HTTP リクエストが不要になる場合も閉じられず、Go ルーチンのリークが発生し、これにより時間の経過と共にメモリー使用量が増大しました。今回のリリースにより、HTTP リクエストは不要になると常に閉じられるようになりました。(BZ#1941563)
  • 以前のバージョンでは、BZ#1936587 はグローバル CoreDNS キャッシュの最大 TTL を 900 秒に設定しました。その結果、アップストリームリゾルバーから受信される NXDOMAIN レコードが 900 秒間キャッシュされました。今回の更新により、最大 30 秒間、ネガティブな DNS 応答レコードが明示的にキャッシュされるようになりました。その結果、NXDOMAINs レコードの解決は 900 秒間キャッシュされなくなりました。(BZ#1944245)
1.8.21.3. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.22. RHBA-2021:1232 - OpenShift Container Platform 4.6.26 バグ修正の更新

発行日: 2021-04-27

OpenShift Container Platform release 4.6.26 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:1232 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは RHBA-2021:1229 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.26 --pullspecs
1.8.22.1. 機能
1.8.22.1.1. SAP Pod データを収集するための Insights Operator の拡張機能

Insights Operator は、SAP クラスターから Datahubs リソースを収集できるようになりました。このデータにより、SAP クラスターは Insights Operator アーカイブの非 SAP クラスターと区別できます。これは、SAP クラスターのみから収集されたすべてのデータが欠落しており、クラスターに SDI インストールがあるかどうかを判別することができない場合でも同様です。詳細は、BZ#1942907 を参照してください。

1.8.22.2. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.23. RHBA-2021:1427 - OpenShift Container Platform 4.6.27 バグ修正の更新

発行日: 2021-05-04

OpenShift Container Platform リリース 4.6.27 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:1427 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは RHBA-2021:1428 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.27 --pullspecs
1.8.23.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.24. RHBA-2021:1487 - OpenShift Container Platform 4.6.28 バグ修正の更新

発行日: 2021-05-12

OpenShift Container Platform リリース 4.6.28 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:1487 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは RHBA-2021:1488 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.28 --pullspecs
1.8.24.1. バグ修正
  • 以前のバージョンでは、インストール時に SDN Pod はインストールの他の部分が完了するまで繰り返しクラッシュし、再起動していました。そのため、インストール時間が長くなりました。今回の更新により、SDN Pod は部分的にインストールされたクラスターの状態を読み取り、適切な時間まで待機できるようになりました。その結果、SDN Pod はクラッシュせず、インストールは遅延しなくなります。(BZ#1950407)
  • 以前のバージョンでは、Cluster Samples Operator は監視するオブジェクトのコントローラーのキャッシュに変更を加える可能性がありました。これにより、Kubernetes がコントローラーキャッシュを管理する際にエラーが生じました。今回の更新により、Cluster Samples Operator がコントローラーキャッシュの情報を使用する方法が修正されました。そのため、Cluster Samples Operator はコントローラーキャッシュを変更してもエラーが生じなくなりました。(BZ#1950809)
  • 以前のバージョンでは、アプリケーションのリソースが順不同に作成されるため、Web コンソールからサンプルアプリケーションを作成すると失敗する可能性がありました。今回の更新により、これらのリソースが作成される順序が指定され、これによりサンプルアプリケーションを作成するプロセスが安定します。(BZ#1933666)
1.8.24.2. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.25. RHBA-2021:1521 - OpenShift Container Platform 4.6.29 バグ修正の更新

発行日: 2021-05-20

OpenShift Container Platform リリース 4.6.29 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:1521 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは RHBA-2021:1522 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.29 --pullspecs
1.8.25.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.26. RHBA-2021:1565 - OpenShift Container Platform 4.6.30 バグ修正およびセキュリティー更新

発行日: 2021-05-25

セキュリティー更新を含む OpenShift Container Platform リリース 4.6.30 が利用可能になりました。この更新に含まれるバグ修正の一覧は、RHBA-2021:1565 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは、RHSA-2021:1566 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.30 --pullspecs
1.8.26.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.27. RHBA-2021:2100 - OpenShift Container Platform 4.6.31 バグ修正の更新

発行日: 2021-06-01

OpenShift Container Platform リリース 4.6.31 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:2100 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは RHBA-2021:2101 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.31 --pullspecs
1.8.27.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.28. RHBA-2021:2157 - OpenShift Container Platform 4.6.32 バグ修正の更新

発行日: 2021-06-08

OpenShift Container Platform リリース 4.6.32 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:2157 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは RHBA-2021:2158 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.32 --pullspecs
1.8.28.1. バグ修正
  • これまでは、[ロール]ページの[Role Bindings]タブから新しいバインディングを作成すると、Web コンソールで誤ったロール名と namespace がフォームに入力されていました。このリリースでは、新しいバインディングにはデフォルトの cluster-admin ロールが設定されています。(BZ#1950490)
  • 以前のバージョンでは、namespace は Machine Config Operator relatedObjects リソースになく、そのために一部のオンプレミスサービスのログは must-gather で収集されませんでした。今回のリリースにより、必要な namespace が Machine Config Operator relatedObjects リソースに追加され、オンプレミスサービスのログは must-gather で収集されるようになりました。(BZ#1955715)
  • 以前のバージョンでは、CCO デプロイメントが正常ではない場合に、Cloud Credential Operator (CCO) および Cluster Version Operator (CVO) の両方が報告しました。これにより、問題がある場合に 2 つのレポートが作成されました。今回のリリースにより、CCO はデプロイメントが正常ではない場合に報告しなくなりました。(BZ#1958959)
  • これまでは、あるサービスのメンバーで発生したトラフィックがロードバランサーによって同じメンバーにリダイレクトされた場合、Open Virtual Network(OVN) はパケットのソース IP アドレスをロードバランサーの IP アドレスに変更していました。ネットワークポリシーを適用すると、この種のトラフィックが不必要にブロックされることがありました。このリリースでは、Kuryr はネットワークポリシーの namespace にあるすべてのサービスの IP アドレスに対するトラフィックを開き、そのトラフィックはブロックされません。(BZ#1963846)
1.8.28.2. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.29. RHBA-2021:2267 - OpenShift Container Platform 4.6.34 バグ修正の更新

発行日: 2021-06-14

OpenShift Container Platform リリース 4.6.34 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:2267 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは RHBA-2021:2268 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.34 --pullspecs
1.8.29.1. 機能
1.8.29.1.1. Insights Operator の拡張機能

今回の更新で、ユーザーは virt_platform メトリクスを収集できるようになりました。virt_platform メトリクスは、クラスターの仮想プラットフォームを判別するために Insights Operator のルールに必要です。この情報は、config/metric ファイルの Insights Operator アーカイブに保存されます。詳細は、BZ#1965219 を参照してください。

1.8.29.2. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.30. RHBA-2021:2410 - OpenShift Container Platform 4.6.35 バグ修正の更新

発行日: 2021-06-22

OpenShift Container Platform リリース 4.6.35 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:2410 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは RHBA-2021:2407 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.35 --pullspecs
1.8.30.1. 機能
1.8.30.1.1. Insights Operator の拡張機能

今回の更新により、Insights OperatorGather メソッドは、正常でない Operator に関連する Pod や、Operator と同じ namespace にある Pod からログを収集できるようになりました。これにより、Insights Operator は、Operator に関連する namespace を判断し、Pod ログをバンドルに含めることができます。その結果、Insights Operator は、Operator に関連する正常でない Pod だけではなく、Operator の namespace に存在するすべての Pod からログを収集するようになりました。

1.8.30.2. バグ修正
  • 以前は、IPv4 アドレスを持つノードでシングルスタック IPv6 クラスターを開始すると、kubelet はノード IP に IPv6 IP ではなく IPv4 IP を使用していた可能性がありました。その結果、ホストネットワーク Pod には IPv6 IP ではなく IPv4 IP が含まれるため、IPv6 のみの Pod からは到達できなくなっていました。この更新により、ノード IP ピッキングコードが修正され、kubelet が IPv6 IP を使用するようになりました。(BZ#1942488)
  • BZ#1953097 の修正は、サイズが 1232 バイトの CoreDNS bufsize プラグインを有効化しました。一部のプリミティブ DNS リゾルバーは、512 バイトを超える UDP 経由で DNS 応答メッセージを受信できません。その結果、Go の内部 DNS ライブラリーなどの一部の DNS リゾルバーは、DNS Operator から詳細な DNS 応答を受け取ることができません。今回の更新で、すべてのサーバーで CoreDNS bufsize が 512 バイトに設定されました。その結果、UDP DNS メッセージが適切に受信されるようになりました。(BZ#1970140)
  • これまでは、HTTP 接続の実行時に適切なタイムアウトが設定されていなかったため、接続が開かれたままになっていました。その結果、これらの接続は最大限度に達するまで蓄積され、その結果、Operator は入ってくるイベントを処理することができなくなりました。今回の更新により、Operator が使用する HTTP クライアントにタイムアウトが追加され、タイムアウトに達した後、開いている接続が確実に閉じられるようになりました。(BZ#1959563)
  • 以前のバージョンでは、ルートを介して公開されたサービスから selector を削除すると、サービスの Pod 用に作成される endpointslices が重複し、サーバーエントリーの重複が原因で HAProxy の再読み込みエラーが発生していました。この更新により、HAProxy 設定ファイルを書き出すときに誤って重複するサーバー行が除外されるため、サービスからセレクターを削除してもルーターが失敗することはなくなりました。(BZ#1965329)
1.8.30.3. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.31. RHBA-2021:2498 - OpenShift Container Platform 4.6.36 バグ修正およびセキュリティー更新

発行日: 2021-06-29

OpenShift Container Platform リリース 4.6.36 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:2498 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは、RHSA-2021:2499 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.36 --pullspecs
1.8.31.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.32. RHBA-2021:2641 - OpenShift Container Platform 4.6.38 バグ修正およびセキュリティー更新

発行日: 2021-07-13

OpenShift Container Platform リリース 4.6.38 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:2641 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは RHBA-2021:2642 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.38 --pullspecs
1.8.32.1. バグ修正
  • 以前は、IPv4 アドレスを持つノードでシングルスタック IPv6 クラスターを開始すると、kubelet はノード IP に IPv6 アドレスではなく IPv4 アドレスを使用していた可能性がありました。その結果、ホストネットワーク Pod には IPv6 アドレスではなく IPv4 アドレスが含まれるため、IPv6 のみの Pod からは到達できなくなっていました。この更新により、ノード IP ピッキングコードが修正され、kubelet が IPv6 アドレスを使用するようになりました。(BZ#1942506)
  • 以前のバージョンでは、CRI-O ログには、イメージのプル元のソースについての情報が含まれていませんでした。そのため、CRI-O では、イメージがレジストリーミラーから取り出されたものかどうかを見分けることができませんでした。今回の更新により、CRI-O にイメージのプルソースに関するレベルログ情報が追加されました。その結果、ログの情報レベルにプルソースが表示されるようになりました。(BZ#1976293)
  • 以前は、イメージミラーリング中に作成された承認ヘッダーが、一部のレジストリーのヘッダーサイズ制限を超える可能性がありました。これにより、ミラーリング操作中にエラーが発生します。現在は、oc adm catalog mirror コマンドの --skip-multiple-scopes オプションが true に設定され、承認ヘッダーがヘッダーサイズの制限を超えないようになりました。(BZ#1946839)
  • この更新の前は、Pipeline ServiceAccount は、プライベート Git リポジトリーの git import フロー中に作成されたシークレットを使用していなかったため、これらの Pipeline は失敗していました。この更新では、シークレットと Pipeline ServiceAccount にアノテーションを追加することで、問題を修正しています。プライベート Git リポジトリーの Pipeline が正しく実行されるようになりました。(BZ#1970470)
  • これまでは、プロジェクトを切り替えたときに、kubeconfig のすべてのオプションがコピーされるわけではありませんでした。その結果、kubeconfig での認証に Exec を使用するプロジェクトを切り替えると、情報が失われました。今回の更新では、oc projects と Exec を使用するプロジェクトを切り替えて認証する際に、必要な情報がすべてコピーされます。(BZ#1973613)
  • これまでは、1 つまたは複数のコントロールプレーンノードに 2 つ目の内部 IP アドレスが追加された場合、IP アドレスの変更をメンバーシップの変更の可能性として検出するため、etcd Operator が劣化していました。その結果、ノードに対する etcd のサービング証明書が再生成されませんでした。今回の更新により、etcd Operator は新規ノードおよび既存ノードの IP アドレスの変更を区別するようになりました。その結果、既存のノードへの変更に対して etcd Operator がサービング証明書を再生成し、新しい IP アドレスを追加しても etcd Operator が劣化することがなくなりました。(BZ#1965535)
  • 以前のバージョンでは、OpenShift Container Platform Web コンソールで Bitbucket リポジトリーを使用してデプロイメント用に作成されたトポロジー URL は、バックスラッシュ (\) またはスラッシュ (/) を含むブランチ名が含まれている場合は機能しませんでした。これは Bitbucket API (BCLOUD-9969) の問題が原因でした。現在のリリースではこの問題は軽減されています。ブランチ名にバックスラッシュまたはスラッシュが含まれている場合、トポロジー URL はリポジトリーのデフォルトのブランチページを指します。この問題は OpenShift Container Platform の今後のリリースで修正されます。(BZ#1972694)
1.8.32.2. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.33. RHBA-2021:2684 - OpenShift Container Platform 4.6.39 バグ修正の更新

発行日: 2021-07-21

OpenShift Container Platform リリース 4.6.39 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:2684 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは RHBA-2021:2685 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.39 --pullspecs
1.8.33.1. バグ修正
  • これまでは、非 root ユーザーで oc image extract コマンドを実行すると、operation not permitted エラーで失敗していました。これは、解凍時に拡張属性を設定するための権限が不足していたためです。今回の更新では、拡張セキュリティー属性はコマンドを root で実行した場合にのみ設定されるため、コマンドは root ユーザーと非 root ユーザーの両方で動作します。(BZ#1969929)
  • 以前のバージョンでは、開発者コンソールでサービスクラスターをローカルにするためにラベルが変更された場合、ユーザーは Knative サービスを作成できませんでした。Knative サービスの更新では、ユーザーが開発者コンソールから cluster-local として Knative サービスを作成できるようにするために、cluster-local でサポートされている最新のラベルを使用します。(BZ1978159)
1.8.33.2. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.34. RHBA-2021:2767 - OpenShift Container Platform 4.6.40 バグ修正の更新

発行日: 2021-07-28

OpenShift Container Platform リリース 4.6.40 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:2767 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは RHBA-2021:2768 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.40 --pullspecs
1.8.34.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.35. RHBA-2021:2886 - OpenShift Container Platform 4.6.41 バグ修正の更新

発行日: 2021-08-04

OpenShift Container Platform リリース 4.6.41 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:2886 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは RHBA-2021:2888 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.41 --pullspecs
1.8.35.1. 機能
1.8.35.1.1. ストラテジーごとのビルド数の新しい Telemetry メトリクス

Telemetry には新規の openshift:build_by_strategy:sum 測定メトリクスが含まれており、このメトリクスは、ストラテジータイプごとのビルド数を Telemeter クライアントに送信します。このメトリクスにより、サイト信頼性エンジニア (SRE) と製品マネージャーは、OpenShift Container Platform クラスターで実行されるビルドの種類を可視化できます。(BZ#1969964)

1.8.35.2. バグ修正
  • 以前は、IPv4 アドレスを持つノードでシングルスタック IPv6 クラスターを開始すると、kubelet はノード IP に IPv6 IP ではなく IPv4 IP を使用していた可能性がありました。その結果、ホストネットワーク Pod には IPv6 IP ではなく IPv4 IP が含まれるため、IPv6 のみの Pod からは到達できなくなっていました。この更新により、ノード IP ピッキングコードが修正され、kubelet が IPv6 IP を使用するようになりました。(BZ#1942506)
1.8.35.3. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.36. RHBA-2021:3008 - OpenShift Container Platform 4.6.42 バグ修正およびセキュリティー更新

発行日: 2021-08-11

OpenShift Container Platform リリース 4.6.42 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:3008 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは、RHSA-2021:3009 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.42 --pullspecs
1.8.36.1. バグ修正
  • 従来、ホストネットワークの Pod には IPv4 の IP が設定されていたため、IPv6 のみの Pod からは到達できませんでした。今回の更新では、ノードが IPv6 の IP を持つように node-IP-picking code が修正されました。その結果、ホストネットワークの Pod に到達できるようになりました。(BZ1942506)
1.8.36.2. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.37. RHBA-2021:3197 - OpenShift Container Platform 4.6.43 バグ修正の更新

発行日: 2021-08-25

OpenShift Container Platform リリース 4.6.43 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:3197 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは、RHSA-2021:3198 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.43 --pullspecs
1.8.37.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.38. RHBA-2021:3395 - OpenShift Container Platform 4.6.44 バグ修正の更新

発行日: 2021-09-08

OpenShift Container Platform リリース 4.6.44 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:3395 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは、RHSA-2021:3396 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.44 --pullspecs
1.8.38.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.39. RHBA-2021:3517 - OpenShift Container Platform 4.6.45 バグ修正の更新

発行日: 2021-09-22

OpenShift Container Platform リリース 4.6.45 が公開されました。この更新に含まれるバグ修正の一覧は、RHBA-2021:3517 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは RHBA-2021:3518 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.45 --pullspecs
1.8.39.1. 機能
1.8.39.1.1. クラスターに対する新しい最小ストレージ要件

OpenShift Container Platform のクラスターをインストールするために必要な最小ストレージが、120GB から 100GB に減少しました。この更新は、サポート対応のすべてのプラットフォームに適用されます。

1.8.39.2. バグ修正
  • 以前のバージョンでは、無効なイメージストリームまたは未解決のイメージでデプロイメントが作成された場合には、デプロイメントコントローラーと API サーバーの imagepolicy プラグインの間の状態が一致しませんでした。そのため、レプリカセットの数が無限に発生し、etcd クォータの上限に到達してしまう可能性がありました。これが原因で、OpenShift Container Platform クラスター全体がクラッシュする可能性がありました。今回の更新により、API サーバーの imagepolicy プラグインの機能を減らしました。そのため、デプロイメントでは、不整合なイメージストリームは解決されません。(BZ#1981784).
1.8.39.3. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.40. RHBA-2021:3643 - OpenShift Container Platform 4.6.46 バグ修正およびセキュリティー更新

発行日: 2021-09-29

セキュリティー更新を含む OpenShift Container Platform リリース 4.6.46 が利用可能になりました。この更新に含まれるバグ修正の一覧は、RHBA-2021:3643 アドバイザリーにまとめられています。この更新に含まれる RPM パッケージは、RHSA-2021:3642 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.46 --pullspecs
1.8.40.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.41. RHBA-2021:3737 - OpenShift Container Platform 4.6.47 バグ修正の更新

発行日: 2021-10-13

OpenShift Container Platform リリース 4.6.47 が公開されました。更新に含まれるバグ修正は、RHBA-2021:3737 アドバイザリーに記載されています。本リリース用の RPM パッケージはありません。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.47 --pullspecs
1.8.41.1. バグ修正
  • 以前は、カスタム CA 証明書を使用して Red Hat OpenStack Platform (RHOSP) エンドポイントに接続するための HTTP トランスポートにプロキシー設定がありませんでした。その結果、クラスターは RHOSP にデプロイされたときに完全には機能しませんでした。この更新により、カスタム CA 証明書で接続するときにプロキシー設定が HTTP トランスポートに渡されます。その結果、すべてのクラスターコンポーネントが期待どおりに動作します。(BZ#2002752)
1.8.41.2. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.42. RHBA-2021:3829 - OpenShift Container Platform 4.6.48 バグ修正の更新

発行日: 2021-10-20

OpenShift Container Platform リリース 4.6.48 が公開されました。更新に含まれるバグ修正は、RHBA-2021:3829 アドバイザリーに記載されています。この更新に含まれる RPM パッケージは、RHBA-2021:3828 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.48 --pullspecs
1.8.42.1. 機能
1.8.42.1.1. Kubernetes 1.19.14 からの更新

この更新には、Kubernetes 1.19.14 からの変更が含まれています。より詳しい情報は、1.19.14、1.19.13、1.19.12、1.19.11、1.19.10、1.19.9、1.19.8、1.19.7、1.19.6、1.19.5 のチェンジログをご覧ください。

1.8.42.2. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.43. RHBA-2021:4009 - OpenShift Container Platform 4.6.49 バグ修正およびセキュリティー更新

発行日: 2021-11-03

セキュリティー更新を含む OpenShift Container Platform リリース 4.6.49 が利用可能になりました。更新に含まれるバグ修正は、RHBA-2021:4009 アドバイザリーに記載されています。この更新に含まれる RPM パッケージは、RHSA-2021:4008 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.49 --pullspecs
1.8.43.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.44. RHBA-2021:4800 - OpenShift Container Platform 4.6.51 バグ修正およびセキュリティー更新

発行日: 2021-12-02

セキュリティー更新を含む OpenShift Container Platform リリース 4.6.51 が利用可能になりました。更新に含まれるバグ修正は、RHBA-2021:4800 アドバイザリーに記載されています。この更新に含まれる RPM パッケージは、RHSA-2021:4799 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.51 --pullspecs
1.8.44.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.45. RHBA-2021:5010 - OpenShift Container Platform 4.6.52 バグ修正およびセキュリティー更新

発行日: 2021-12-14

セキュリティー更新を含む OpenShift Container Platform リリース 4.6.52 が利用可能になりました。更新に含まれるバグ修正は、RHBA-2021:5010 アドバイザリーに記載されています。この更新に含まれる RPM パッケージは、RHBA-2021:5009 アドバイザリーで提供されています。

このリリースには、CVE-2021-44228、CVE-2021-45046、CVE-2021-4104、CVE-2021-4125 の重要なセキュリティー更新が含まれています。これらはすべて Apache Log4j ユーティリティーに関係しています。これらの不具合の修正は、RHSA-2021:5106、RHSA-2021:5141、および RHSA-2021:5186 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.52 --pullspecs
1.8.45.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.46. RHBA-2022:0025 - OpenShift Container Platform 4.6.53 バグ修正およびセキュリティー更新

発行日: 2022-01-12

セキュリティー更新を含む OpenShift Container Platform リリース 4.6.53 が利用可能になりました。更新に含まれるバグ修正は、RHBA-2022:0025 アドバイザリーに記載されています。この更新に含まれる RPM パッケージは、RHSA-2022:0024 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.53 --pullspecs
1.8.46.1. バグ修正
  • 以前は、Unified Extensible Firmware Interface (UEFI) モードで、ironic-python-agent が Red Hat Enterprise Linux CoreOS (RHCOS) イメージのダウンロード後に UEFI ブートローダーエントリーを作成していました。Red Hat Enterprise Linux (RHEL) 8.4 に基づく RHCOS イメージを使用すると、このエントリーを使用したイメージの起動に失敗する可能性があります。したがって、UEFI エントリーの順序によっては、ironic-python-agent によってインストールされたエントリーがイメージの起動時に使用されると、起動に失敗し、BIOS エラー画面が出力される可能性があります。今回の更新により、ironic-python-agent は、固定のブートエントリーを使用する代わりに、イメージにある CSV ファイルに基づいてブートエントリーを設定します。その結果、イメージはエラーなしで適切に起動します。(BZ#2025495)
1.8.46.2. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.47. RHBA-2022:0180 - OpenShift Container Platform 4.6.54 バグ修正およびセキュリティー更新

発行日: 2022-01-26

セキュリティー更新を含む OpenShift Container Platform リリース 4.6.54 が利用可能になりました。更新に含まれるバグ修正は、RHBA-2022:0180 アドバイザリーに記載されています。本リリース用の RPM パッケージはありません。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.54 --pullspecs
1.8.47.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.48. RHBA-2022:0566 - OpenShift Container Platform 4.6.55 バグ修正およびセキュリティー更新

発行日: 2022-02-23

セキュリティー更新を含む OpenShift Container Platform リリース 4.6.55 が利用可能になりました。更新に含まれるバグ修正は、RHBA-2022:0566 アドバイザリーに記載されています。この更新に含まれる RPM パッケージは、RHSA-2022:0565 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.55 --pullspecs
1.8.48.1. 機能
1.8.48.1.1. Whereabouts CNI IPAM プラグインの IP 照合

Whereabouts CNI IPAM プラグインの新しい機能拡張により、Kubernetes cronjob として実行される IP 調整ジョブである ip-reconciler が追加されます。以前は、Pod の CNI DEL 要求が終了しなかった場合、Pod の IP アドレスは使用されていなくても割り当てられたままでした。そのような IP アドレスは定期的に収集され、再割り当てできるようになりました。(BZ#2028968)

1.8.48.2. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.49. RHBA-2022:0867 - OpenShift Container Platform 4.6.56 バグ修正およびセキュリティー更新

発行日: 2022-03-23

セキュリティー更新を含む OpenShift Container Platform リリース 4.6.56 が利用可能になりました。更新に含まれるバグ修正は、RHBA-2022:0867 アドバイザリーに記載されています。この更新に含まれる RPM パッケージは、RHSA-2022:0866 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.56 --pullspecs
1.8.49.1. バグ修正
  • 以前は、Red Hat OpenStack Platform (RHOSP) 認証情報シークレットの作成と kube-controller-manager 起動の間のエラーにより、RHOSP 認証情報が正しく設定されませんでした。したがって、LoadBalancer サービスは RHOSP で作成されませんでした。この更新により、kube-controller-manager の起動時に RHOSP 認証情報が取得されます。その結果、RHOSP シークレット認証情報が適切に初期化されるようになりました。(BZ#2059677)
1.8.49.2. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.50. RHBA-2022:1621 - OpenShift Container Platform 4.6.57 バグ修正およびセキュリティー更新

発行日: 2022-05-04

セキュリティー更新を含む OpenShift Container Platform リリース 4.6.57 が利用可能になりました。更新に含まれるバグ修正は、RHBA-2022:1621 アドバイザリーに記載されています。この更新に含まれる RPM パッケージは、RHSA-2022:1620 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.57 --pullspecs
1.8.50.1. 削除された機能

OpenShift Container Platform 4.6.57 以降、Microsoft Azure クラスターのミントモードで Cloud Credential Operator (CCO) を使用するためのサポートが OpenShift Container Platform 4.6 から削除されました。この変更は、2022 年 6 月 30 日に Microsoft が Azure AD Graph API を廃止する予定であるためであり、z-stream 更新でサポートされているすべてのバージョンの OpenShift Container Platform にバックポートされます。詳細については、削除された Microsoft Azure のクレデンシャルの作成のサポート を参照してください。

1.8.50.2. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.51. RHSA-2022:2264 - OpenShift Container Platform 4.6.58 バグ修正およびセキュリティー更新

発行日: 2022-05-25

セキュリティー更新を含む OpenShift Container Platform リリース 4.6.58 が利用可能になりました。更新に含まれるバグ修正は、RHSA-2022:2264 アドバイザリーに記載されています。この更新に含まれる RPM パッケージは、RHSA-2022:2263 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.58 --pullspecs
1.8.51.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.52. RHBA-2022:4948 - OpenShift Container Platform 4.6.59 バグ修正およびセキュリティー更新

発行日: 2022-06-17

セキュリティー更新を含む OpenShift Container Platform リリース 4.6.59 が利用可能になりました。更新に含まれるバグ修正は、RHBA-2022:4948 アドバイザリーに記載されています。この更新に含まれる RPM パッケージは、RHSA-2022:4947 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.59 --pullspecs
1.8.52.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.53. RHBA-2022:5572 - OpenShift Container Platform 4.6.60 バグ修正の更新

発行日: 2022-07-21

セキュリティー更新を含む OpenShift Container Platform リリース 4.6.60 が公開されました。更新に含まれるバグ修正は、RHBA-2022:5572 アドバイザリーに記載されています。この更新に含まれる RPM パッケージは、RHBA-2022:5571 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.60 --pullspecs
1.8.53.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

1.8.54. RHSA-2022:6262 - OpenShift Container Platform 4.6.61 バグ修正の更新

発行日: 2022-09-09

セキュリティー修正を含む OpenShift Container Platform リリース 4.6.61 が利用可能になりました。更新に含まれるバグ修正は、RHSA-2022:6262 アドバイザリーに記載されています。この更新に含まれる RPM パッケージは、RHBA-2022:6261 アドバイザリーで提供されています。

以下のコマンドを実行して、本リリースでコンテナーイメージを表示できます。 

$ oc adm release info 4.6.61 --pullspecs
1.8.54.1. 更新

既存の OpenShift Container Platform 4.6 クラスターをこの最新リリースに更新する方法については CLI を使用したクラスターの更新 を参照してください。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.