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-installernmcli、および 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. 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.4. 既存クラスターにノードを追加する追加の手順

Ignition 仕様への変更により、最新バージョンの RHCOS ブートメディアを使用してノードを OpenShift Container Platform クラスターに追加する必要がある場合は、プロセスの一部として Ignition 設定を手動で変更する必要がある場合があります。

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

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

  • kernel-devel
  • usbguard

1.2.1.6. 4kN ディスクのサポート

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

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

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

1.2.1.8. 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) ツール
    • オーバーコミットの制御およびノード上のコンテナーの密度の管理
    • etcd クラスター Operator
    • 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 または静的アドレス指定のいずれかを使用する必要があります。
  • OpenJ9 を使用した AdoptOpenJDK
  • インストーラーでプロビジョニングされるインフラストラクチャー
  • 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.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.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 によって自動的に変換されています。

1.2.9.2. ローカルストレージ Operator を使用した自動デバイス検出およびプロビジョニング (テクノロジープレビュー)

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

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

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

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 の managementStateRemoved に設定されている場合、ストレージは削除されます。

    • managementStateManaged に設定されている場合、イメージレジストリー Operator は基礎となるストレージユニットにいくつかのデフォルト設定を適用しようとします。たとえば、Managed に設定されている場合、Operator はこれをレジストリーで利用可能にする前に S3 バケットで暗号の有効にしようとします。デフォルト設定を提供しているストレージに適用しない場合、managementStateUnmanaged に設定されていることを確認します。
  • Unmanaged: イメージレジストリー Operator がストレージ設定を無視することを判別します。イメージレジストリー Operator の managementStateRemoved に設定されている場合、ストレージは削除されません。バケットまたはコンテナー名などの基礎となるストレージユニット設定を指定し、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 のインストールでは、クラスター管理者が CatalogSourceSubscriptionClusterServiceVersion、および 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. イメージレジストリー 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) は、MintPassthrough、および 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-dbmirror.internal.customer.com/cloud/test-db にマップします。ICSP ファイルでミラーをレジストリースコープに拡張すると、クラスターがそのノードを再起動する必要がある回数が最小限に抑えられます。同じ例を使用して registry.redhat.iomirror.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 で改善された修復手順を提供できるようになりました。