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

RHCOS は、OpenShift Container Platform 4.8 および OpenShift Container Platform 4.7.24 以降で、Red Hat Enterprise Linux (RHEL) 8.4 パッケージを使用するようになりました。これにより、最新の修正、機能、拡張機能、および最新のハードウェアサポートおよびドライバー更新を利用できます。OpenShift Container Platform 4.6 は延長更新サポート (EUS) リリースです。このリリースは、ライフサイクル全体に対して RHEL 8.2 EUS パッケージを引き続き使用します。

ストリームメタデータは、OpenShift Container Platform のインストール時に、メタデータをクラスターに挿入するための標準化された JSON 形式を提供します。自動化を強化するために、新規の openshift-install coreos print-stream-json コマンドは、スクリプト可能かつ機械読み取り可能な形式でストリームメタデータを出力する方法を提供します。

ユーザーによってプロビジョニングされるインストールの場合、openshift-install バイナリーには、AWS AMI などの OpenShift Container Platform での使用がテストされている RHCOS ブートイメージのバージョンへの参照が含まれます。https://github.com/coreos/stream-metadata-go の公式の stream-metadata-go ライブラリーを使用して、Go プログラムからストリームメタデータを解析できるようになりました。

詳細は、ストリームメタデータを使用した RHCOS AMI へのアクセス を参照してください。

OpenShift Container Platform には、マシン設定の生成および検証に役立つ Butane config transpiler が含まれるようになりました。ドキュメントでは、Butane を使用して LUKS ディスク暗号化、ブートディスクのミラーリング、およびカスタムカーネルモジュールのマシン設定を作成することを推奨しています。

詳細は、Butane を使用したマシン設定の作成 を参照してください。

クラウド管理者がカスタムの /etc/chrony.conf 設定をすでに設定している場合、RHCOS はデフォルトで PEERNTP=no オプションをクラウドプラットフォームに設定しなくなりました。これを設定していない場合、PEERNTP=no オプションがデフォルトで設定されます。詳細は、BZ#1924869 を参照してください。

ベアメタルインストール時のマルチパスの有効化が、OpenShift Container Platform 4.8 以降でプロビジョニングされるノードでサポートされるようになりました。マルチパスを有効にするには、coreos-installer install コマンドにカーネル引数を追加して、インストール済みシステム自体が初回起動からマルチパスを使用できるようにします。インストール後のサポートはマシン設定を使用してマルチパスをアクティベートすることで引き続き利用できますが、OpenShift Container Platform 4.8 以降では、インストール中にプロビジョニングされたノードのマルチパスを有効化することをお勧めします。

詳細は、Enabling multipathing with kernel arguments on RHCOS について参照してください。

install-config.yaml ファイルの platform.azure.resourceGroupName フィールドを定義して、既存のリソースグループを定義し、クラスターを Azure にインストールできるようになりました。このリソースグループは空である必要があり、単一のクラスターにのみ使用する必要があります。クラスターのコンポーネントには、リソースグループ内のすべてのリソースの所有権があります。

インストールプログラムのサービスプリンシパルの範囲をこのリソースグループに制限する場合は、環境内でインストールプログラムが使用する他のすべてのリソースに、パブリック DNS ゾーンや仮想ネットワークなどの必要なパーミッションがあることを確認する必要があります。インストールプログラムを使用してクラスターを破棄すると、ユーザー定義のリソースグループが削除されます。

install-config.yaml ファイルに compute.platform.aws.iamRole および controlPlane.platform.aws.iamRole フィールドを設定して、マシンインスタンスのプロファイルに既存の Amazon Web Services (AWS) IAM ロールを定義できるようになりました。これにより、IAM ロールについて以下を実行できます。

install-config.yaml ファイルに platform.aws.hostedZone フィールドを設定して、クラスターの既存の Route 53 プライベートホストゾーンを定義できるようになりました。独自の VPC を指定する場合も、既存のホストゾーンのみを使用できます。

Google Cloud Platform (GCP) の OpenShift Container Platform インストールプログラムは、マシン CIDR 内に可能な限り大きなサブネットを作成するようになりました。これにより、クラスターがマシン CIDR のサイズを、クラスター内のノード数に対応するように設定できます。

今回のリリースにより、デーモンセットをすべてのノードにデプロイするクラスター Operator のアップグレード期間が大幅に短縮されるようになりました。たとえば、250 ノードのテストクラスターのアップグレード期間は 7.5 時間から 1.5 時間に短縮されるため、アップグレード期間は 1 ノードの追加につき 1 分未満となります。

更新時に、Machine Config Operator (MCO) は、マシン設定プールの更新が完了していない場合に Upgradeable=False の状態を machine-config Cluster Operator に報告するようになりました。このステータスは今後のマイナー更新をブロックしますが、今後のパッチ更新をブロックしたり、現在の更新をブロックしたりすることはありません。以前のバージョンでは、MCO はワーカープールの更新が完了していなくても、コントロールプレーンマシンの設定プールの状態のみに基づいて、Upgradeable ステータスを報告していました。

OpenShift Container Platform 4.8 では、インストーラーでプロビジョニングされるクラスターをベアメタルにデプロイするときに、Fujitsu ハードウェアと Fujitsu iRMC ベースボード管理コントローラープロトコルを使用できます。現在 Fujitsu は、ベアメタルへのインストーラーでプロビジョニングされるインストール用に iRMC S5 ファームウェアバージョン 3.05P 以降をサポートしています。OpenShift Container Platform 4.8 の機能拡張およびバグ修正には以下が含まれます。

コンピュートマシン用に Single Root I/O Virtualization (SR-IOV) ネットワークを使用する RHOSP にクラスターをデプロイすることができるようになりました。

詳細は、SR-IOV で接続されたコンピュートマシンをサポートする OpenStack へのクラスターのインストール を参照してください。

今回の更新により、Ironic Python Agent は、イントロスペクション中にインターフェイス一覧で VLAN インターフェイスを報告するようになりました。さらに、IP アドレスがインターフェイスに含まれているため、CSR を適切に作成できます。これにより、VLAN インターフェイスを含むすべてのインターフェイスで CSR を取得できます。詳細は、BZ#1888712 を参照してください。

OpenShift Update Service (OSUS) は、Red Hat Enterprise Linux CoreOS (RHCOS) を含む OpenShift Container Platform に OTA (over-the-air) 更新を提供します。以前は、パブリック API の背後にある Red Hat ホストサービスとしてのみアクセス可能でしたが、現在はローカルにインストールできます。OpenShift Update Service は Operator および 1 つ以上のアプリケーションインスタンスで設定され、OpenShift Container Platform 4.6 以降で一般に利用可能になりました。

詳細は、OpenShift Update Service について を参照してください。

console および downloads ルートについて、カスタムルート機能が新規 ingress 設定ルート設定 API の spec.componentRoutes を使用するようになりました。Console Operator 設定にはカスタムルートのカスタマイズがすでに含まれていますが、console ルートのみが対象です。console-operator 設定を使用したルート設定は非推奨になりました。そのため、console カスタムルートが ingress 設定と console-operator 設定の両方に設定されている場合、新規の ingress 設定のカスタムルート設定が優先されます。

詳細は、コンソールルートのカスタマイズ を参照してください。

CLI スニペットがクイックスタートに含まれる場合、これを Web コンソールから実行できるようになりました。この機能を使用するには、まず Web ターミナル Operator をインストールする必要があります。Web ターミナルで実行する Web ターミナルおよびコードスニペットの各種アクションは、Web ターミナル Operator をインストールしない場合は表示されません。または、Web ターミナル Operator がインストールされているかどうかに関係なく、コードスニペットをクリップボードにコピーできます。

以前のバージョンでは、クイックスタートの前提条件はクイックスタートカードの一覧ではなく、統合されたテキストとして表示されていました。スケーラビリティーを考慮し、前提条件はカードではなくポップアップで表示されるようになりました。

このリリースにより、以下が可能になります。

Default 監査ログポリシーは、OAuth アクセストークンの作成 (ログイン) および削除 (ログアウト) 要求の本体をログに記録するようになりました。以前のバージョンでは、削除要求の本体はログに記録されませんでした。

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

ヘッドレスサービスのサービス提供証明書を生成すると、*.<service.name>.<service.namespace>.svc 形式のワイルドカードサブジェクトが組み込まれるようになりました。これにより、これらの Pod の証明書を手動で生成しなくても、個別のステートフルセット Pod への TLS で保護される接続を使用できます。

詳細は、サービス証明書の追加 を参照してください。

コンプライアンス Operator は、OpenShift Container Platform クラスターのチェックおよび修復の多くを自動化します。ただし、クラスターをコンプライアンスに準拠させる完全なプロセスでは、多くの場合、管理者がコンプライアンス Operator API や他のコンポーネントと対話する必要があります。oc-compliance プラグインが利用可能となり、プロセスが簡単になりました。

詳細は、oc-compliance プラグインの使用 を参照してください。

Kubernetes API サーバーの TLS セキュリティープロファイル設定は、Kubernetes スケジューラーおよび Kubernetes コントローラーマネージャーでも適用されるようになりました。

詳細は、TLS セキュリティープロファイルの設定 を参照してください。

Kubernetes API サーバーの HTTP サーバーとして機能する場合に、kubelet の TLS セキュリティープロファイルを設定できるようになりました。

詳細は、TLS セキュリティープロファイルの設定 を参照してください。

以前のバージョンでは、oauth-proxy コマンドでは、認証に使用される htpasswd ファイルでの SHA-1 ハッシュ化されたパスワードの使用のみが許可されていました。oauth-proxy には、bcrypt パスワードハッシュを使用する htpasswd エントリーのサポートが含まれるようになりました。詳細は、BZ#1874322 を参照してください。

OpenShift Container Platform 4.8 は、プロビジョニングされたコントロールプレーンおよびワーカーノードの UEFI セキュアブートモードを自動的に有効にし、ノードの削除時にオフに戻すことをサポートします。この機能を使用するには、ノードの bootMode 設定を install-config.yaml ファイルで UEFISecureBoot に設定します。Red Hat は、第 10 世代 HPE ハードウェアまたは第 13 世代 Dell ハードウェア (ファームウェアバージョン 2.75.75.75 以上を実行) で、管理対象 Secure Boot を使用したインストーラーでプロビジョニングされるインストールのみをサポートします。詳細は、Configuring managed Secure Boot in the install-config.yaml file を参照してください。

インストーラーでプロビジョニングされる ベアメタルインフラストラクチャー 上のクラスターの場合、OVN-Kubernetes クラスターネットワークプロバイダーは、IPv4 アドレスファミリーと IPv6 アドレスファミリーの両方をサポートします。

以前のバージョンの OpenShift Container Platform からアップグレードするインストーラーでプロビジョニングされるベアメタルクラスターの場合、デュアルスタックネットワークをサポートするようにクラスターを変換する必要があります。詳細は、IPv4/IPv6 デュアルスタックネットワークへの変換 を参照してください。

OpenShift SDN クラスターネットワークプロバイダーの OVN-Kubernetes クラスターネットワークプロバイダーへの移行は、ユーザーによってプロビジョニングされるクラスターでサポートされます。詳細は、OpenShift SDN クラスターネットワークプロバイダーからの移行 について参照してください。

OpenShift SDN の egress IP 機能は、namespace に複数の egress IP アドレスが割り当てられている場合、その指定された namespace のノード全体にほぼ均等にネットワークトラフィックを分散するようになりました。それぞれの IP アドレスは異なるノードに存在する必要があります。詳細は、OpenShift SDN の プロジェクトの egress IP の設定 を参照してください。

OpenShift SDN または 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 クラスターネットワークプロバイダーまたは OpenShift SDN クラスターネットワークプロバイダーのいずれかを使用する場合は、policy-group.network.openshift.io/host-network: "" namespace セレクターを使用して、ネットワークポリシールールでホストネットワークトラフィックを選択できます。

OVN-Kubernetes クラスターネットワークプロバイダーを使用する場合は、namespace でネットワークポリシーの監査ロギングを有効にできます。ログは syslog と互換性のある形式であり、ローカルに保存したり、UDP 接続を介して送信したり、UNIX ドメインソケットに送信したりできます。許可された接続、ドロップされた接続、または許可された接続とドロップされた接続の両方をログに記録するかどうかを指定できます。詳細は、ネットワークポリシーイベントのロギング を参照してください。

NetworkPolicy API を実装する MultiNetworkPolicy API を使用して、macvlan の追加ネットワークに適用するネットワークポリシーを作成できます。詳細は、マルチネットワークポリシーの設定 を参照してください。

OpenShift Container Platform 4.8 は、追加の Intel および Mellanox ネットワークインターフェイスコントローラーのサポートを追加します。

詳細は、サポートされるデバイス について参照してください。

Operator でデプロイされる Network Resources Injector は、Downward API を使用して Huge Page の要求および制限についての情報を公開するように機能強化されました。Pod 仕様に Huge Page 要求または制限が含まれる場合、情報は /etc/podnetinfo パスで公開されます。

詳細は、Downward API の Huge Page リソースの挿入 について参照してください。

OpenShift Container Platform 4.8 では、Pod ネットワーク上のネットワークフローについてのメタデータをネットワークフローコレクターに送信するためのサポートを追加します。以下のプロトコルがサポートされます。

パケットデータはネットワークフローコレクターに送信されません。プロトコル、ソースアドレス、宛先アドレス、ポート番号、バイト数、その他のパケットレベルの情報などのパケットレベルのメタデータはネットワークフローコネクターに送信されます。

詳細は、ネットワークフローの追跡 について参照してください。

OpenShift Container Platform 4.8 以降のリリースには、クラスターメンバーシップ情報を使用して A/AAAA レコードを生成する機能が含まれます。これにより、ノード名が IP アドレスに解決されます。ノードが API に登録されると、クラスターは CoreDNS-mDNS を使用せずにこれらのノード情報を分散させることができます。これにより、マルチキャスト DNS に関連付けられたネットワークトラフィックがなくなります。

OpenShift Container Platform は HAProxy 2.2 に対して更新されます。これはデフォルトで、Host: xyz.com を host: xyz.com に変更するなど HTTP ヘッダー名を小文字に変換します。HTTP ヘッダー名の大文字/小文字を認識するレガシーアプリケーションの場合、Ingress コントローラーの spec.httpHeaders.headerNameCaseAdjustments API フィールドを使用して、レガシーアプリケーションが修正されるまでこれらのレガシーアプリケーションに対応します。HAProxy 2.2 が利用可能な場合、OpenShift Container Platform をアップグレードする前に、spec.httpHeaders.headerNameCaseAdjustments を使用して必要な設定を追加するようにしてください。

詳細は、HTTP ヘッダーケースの変換 について参照してください。

OpenShift Container Platform が HAProxy 2.2 に更新され、HTTP ヘッダーにいくつかの追加の制限が適用されます。これらの制限は、アプリケーションの潜在的なセキュリティーの弱点を軽減することを目的としています。特に、HTTP 要求行でホスト名を指定する HTTP クライアント要求は、要求行と要求の HTTP host ヘッダーの両方でポート番号が指定または省略されていない場合は、拒否される可能性があります。たとえば、ヘッダー host: hostname を持つ要求 GET http://hostname:80/path は、HTTP 400 "Bad request" レスポンスで拒否されます。これは、host ヘッダーではポート番号が指定されていないのに、要求ラインではポート番号が指定されているためです。この制限の目的は、リクエストスマグリング攻撃を軽減することです。

このより厳格な HTTP ヘッダー検証は、HTTP/2 が有効化されたときに OpenShift Container Platform の以前のバージョンでも有効化されていました。これは、OpenShift Container Platform 4.7 クラスターで HTTP/2 を有効にし、HTTP 400 エラーを確認することで、問題のあるクライアント要求をテストできることを意味します。HTTP/2 を有効にする方法は、HTTP/2 Ingress 接続の有効化 を参照してください。

OpenShift Container Platform 4.8 では、内部ロードバランサーを使用して GCP で作成された Ingress コントローラーのグローバルアクセスオプションのサポートが追加されました。グローバルアクセスオプションが有効にされる場合、ロードバランサーと同じ VPC ネットワークおよびコンピュートリージョン内の任意のリージョンのクライアントは、クラスターで実行されるワークロードに到達できます。

詳細は、GCP での Ingress コントローラーのグローバルアクセスの設定 について参照してください。

OpenShift Container Platform 4.8 では、スレッド数を設定し、クラスターが処理できる受信接続の量を増やすサポートを追加しています。

詳細は、Ingress コントローラースレッド数の設定 について参照してください。

OpenShift Container Platform 4.8 は、とくに HostNetwork または NodePortService エンドポイント公開ストラテジーのタイプについて、クラウド以外のプラットフォームでの Ingress コントローラーの PROXY プロトコルの設定をサポートします。

詳細は、Ingress コントローラーの PROXY プロトコルの設定 について参照してください。

OpenShift Container Platform 4.8 では、インストーラーでプロビジョニングされるクラスターは、コントロールプレーンノードの Network Time Protocol (NTP) サーバーおよびワーカーノードの NTP クライアントを設定し、デプロイできます。これにより、ルーティング可能なネットワークから切断されている場合でも、ワーカーはコントロールプレーンノードの NTP サーバーから日時を取得できます。デプロイメント後に NTP サーバーおよび NTP クライアントを設定し、デプロイすることもできます。

Kuryr-Kubernetes を使用した Red Hat OpenStack Platform (RHOSP) への OpenShift Container Platform 4.8 デプロイメントでは、default/kubernetes サービスの API ロードバランサーは Cluster Network Operator (CNO) によって管理されなくなり、kuryr-controller 自体により管理されます。これは以下を意味します。

ベアメタルクラスター用の支援付きインストーラーおよびインストーラーでプロビジョニングされるインストールは、provisioning ネットワークなしでクラスターをデプロイする機能を提供します。OpenShift Container Platform 4.8 以降では、Cluster Baremetal Operator (CBO) を使用してインストール後に provisioning ネットワークを有効にすることができます。

ベアメタルインストールのコントロールプレーンノードで実行する仮想 IP (VIP) アドレスが必要な場合は、コントロールプレーンノードでのみ実行する apiVIP および ingressVIP VIP アドレスを設定する必要があります。デフォルトで、OpenShift Container Platform は、ワーカーマシン設定プールの任意のノードが apiVIP および ingressVIP VIP アドレスをホストできるようにします。多くのベアメタル環境では、コントロールプレーンノードとは別のサブネットにワーカーノードをデプロイするため、コントロールプレーンノードで apiVIP および ingressVIP 仮想 IP アドレスを排他的に実行するように設定すると、ワーカーノードを別のサブネットにデプロイすることに関連して発生する問題を防ぐことができます。詳細は、コントロールプレーンで実行されるネットワークコンポーネントの設定 を参照してください。

OpenShift Container Platform 4.8 では、Red Hat OpenStack Platform (RHOSP) およびベアメタルインストーラーでプロビジョニングされたクラスターの apiVIP および ingressVIP トラフィックを処理するように外部ロードバランサーを設定できます。外部の負荷分散サービスとコントロールプレーンノードは同じ L2 ネットワークで実行する必要があります。また、VLAN を使用して負荷分散サービスとコントロールプレーンノード間のトラフィックをルーティングする際に同じ VLAN で実行する必要があります。

apiVIP および ingressVIP トラフィックを処理するためのロードバランサーの設定は、VMware インストーラーでプロビジョニングされたクラスターではサポートされていません。

OpenShift Container Platform 4.8 では、デュアルスタックネットワークを使用するように設定されているクラスターに対して、OVN-Kubernetes IPsec サポートを追加しています。

egress ルーター CNI プラグインは一般に利用可能です。Cluster Network Operator は、EgressRouter API オブジェクトをサポートするように強化されています。OVN-Kubernetes を使用するクラスターに egress ルーターを追加するプロセスは簡素化されます。egress ルーターオブジェクトの作成時に、Operator はネットワーク接続定義とデプロイメントを自動的に追加します。デプロイメントの Pod は egress ルーターとして機能します。

詳細は、egress ルーター Pod の使用についての考慮事項 を参照してください。

IP フェイルオーバーがベアメタルの OpenShift Container Platform クラスターでサポートされるようになりました。IP フェイルオーバーは keepalived を使用して、一連のホストでの外部からアクセスできる VIP アドレスのセットをホストします。各 VIP は 1 度に 1 つのホストによって提供されます。keepalived は Virtual Router Redundancy Protocol (VRRP) を使用して、(一連のホストの) どのホストがどの VIP を提供するかを判別します。ホストが利用不可の場合や keepalived が監視しているサービスが応答しない場合は、VIP は一連のホストの別のホストに切り換えられます。したがって、VIP はホストが利用可能である限り常に提供されます。

詳細は、IP フェイルオーバーの設定 を参照してください。

OpenShift Container Platform 4.8 では、カスタムノードセレクターと容認を使用して、CoreDNS を特定のノードで実行または実行しないようにデーモンセットを設定できます。

詳細は、DNS Pod 配置の制御 を参照してください。

Red Hat OpenStack Platform (RHOSP) の OpenShift Container Platform クラスターは、すべてのデプロイメントタイプのプロバイダーネットワークをサポートするようになりました。

クラスター管理者は、headerBufferMaxRewriteByte および headerBufferBytes Ingress コントローラーの調整パラメーターを設定して、Ingress コントローラーごとに tune.maxrewrite および tune.bufsize HAProxy メモリーオプションを設定できるようになりました。

詳細は、Ingress コントローラー設定パラメーター を参照してください。

Google Cloud Platform (GCP) 永続ディスク (PD) Container Storage Interface (CSI) ドライバーは、GCP 環境に自動的にデプロイされ、管理されるため、ドライバーを手動でインストールしなくてもこれらのボリュームを動的にプロビジョニングできます。この機能は以前は OpenShift Container Platform 4.7 のテクノロジープレビュー機能として導入されましたが、OpenShift Container Platform 4.8 では一般に利用可能となり、デフォルトで有効にされます。

詳細は、GCP PD CSI Driver Operator を参照してください。

Azure Disk CSI Driver Operator は、永続ボリューム要求 (PVC) の作成に使用できるデフォルトのストレージクラスを提供します。このドライバーを管理する Azure Disk CSI Driver Operator はテクノロジープレビュー機能としてご利用いただけます。

詳細は、Azure Disk CSI Driver Operator を参照してください。

vSphere CSI Driver Operator は、永続ボリューム要求 (PVC) の作成に使用できるデフォルトのストレージクラスを提供します。このドライバーを管理する vSphere CSI Driver Operator はテクノロジープレビュー機能としてご利用いただけます。

詳細は、vSphere CSI Driver Operator を参照してください。

OpenShift Container Platform 4.8 以降では、以下の in-tree ボリュームプラグインの同等の CSI ドライバーへの自動移行が、テクノロジープレビュー機能として利用可能になりました。

詳細は、CSI の自動移行 を参照してください。

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

インストール時に Cinder ボリュームのアベイラビリティーゾーンを選択できるようになりました。イメージレジストリー の特定アベイラビリティーゾーンで Cinder ボリュームを使用することもできます。

Operator Lifecycle Manager (OLM) を使用して Operator をインストールするクラスター管理者の場合、現在の API または低レベルの API に関連したエラー状態が生じる可能性があります。以前のバージョンでは、OLM が Operator をインストールしたり、更新したりする要求を満たせないことに関する洞察を得ることがほとんどできませんでした。これらのエラーは、オブジェクトプロパティーの誤字や RBAC が欠落しているなどの簡単な問題から、メタデータの解析により項目をカタログから読み込むことができないなどのより複雑な問題にまで及びます。

管理者は各種の低レベル API 間の対話プロセスへの理解や、これらの問題のデバッグのために OLM Pod ログにアクセスする必要がないため、OpenShift Container Platform 4.8 では OLM に以下の拡張機能を導入し、管理者により包括的なエラーレポートおよびメッセージが提供されるようになりました。

InstallPlan オブジェクトで定義されるインストール計画では、API サーバーの可用性や他のライターとの競合などによる一時的なエラーが発生する可能性があります。以前のバージョンでは、これらのエラーにより、手動クリーンアップが必要な部分的に適用されるインストール計画が終了しました。今回の機能拡張により、カタログ Operator は、インストール計画の実行中に最大 1 分間エラーを再試行するようになりました。新規の .status.message フィールドには、再試行の実行時に人間が判読できる通知が提供されます。

以前のバージョンでは、Operator グループまたは複数の Operator グループのない namespace でサブスクリプションを作成すると、phase=Installing のままになるインストール計画と共に Operator のインストールが停止されました。今回の機能拡張により、インストール計画が phase=Failed にすぐに移行し、管理者が無効な Operator グループを修正してからサブスクリプションを再度削除し、作成できるようになりました。

ResolutionFailed イベントは、namespace での依存関係の解決に失敗すると作成されますが、namespace に参照されるカタログソースに存在しないパッケージまたはチャネルを参照するサブスクリプションが含まれる場合に、より具体的なテキストを提供するようになりました。以前のバージョンでは、このメッセージは汎用的なメッセージでした。

no candidate operators found matching the spec of subscription '<name>'

今回の機能拡張により、メッセージがより具体的になりました。

no operators found in package <name> in the catalog referenced by subscription <name>

no operators found from catalog <name> in namespace openshift-marketplace referenced by subscription <name>

no operators found in channel <name> of package <name> in the catalog referenced by subscription <name>

no operators found with name <name>.<version> in channel <name> of package <name> in the catalog referenced by subscription <name>

Operator のレガシーパッケージマニフェスト形式のサポートは、OpenShift Container Platform 4.8 以降で削除されます。バンドル形式は、OpenShift Container Platform 4.6 以降の Operator Lifecycle Manager (OLM) の推奨 Operator パッケージ形式です。非推奨のパッケージマニフェスト形式で最初に作成された Operator プロジェクトがある場合、Operator SDK pkgman-to-bundle コマンドを使用してプロジェクトをバンドル形式に移行できます。

詳細は、パッケージマニフェストプロジェクトのバンドル形式への移行 を参照してください。

Operator をインストールおよび管理するには、Operator Lifecycle Manager (OLM) では、Operator バンドルがクラスターのカタログで参照されるインデックスイメージに一覧表示される必要があります。Operator の作成者は、Operator SDK を使用して Operator のバンドルおよびそれらのすべての依存関係を含むインデックスを作成できます。これは、リモートクラスターでのテストおよびコンテナーレジストリーへの公開に役立ちます。

詳細は、バンドルされた Operator を含むカタログの公開 を参照してください。

Operator SDK の run bundle-upgrade サブコマンドは、より新しいバージョンのバンドルイメージを指定することにより、インストールされた Operator をトリガーしてそのバージョンにアップグレードするプロセスを自動化します。以前のバージョンでは、サブコマンドは、run bundle サブコマンドを使用して最初にインストールした Operator のみをアップグレードすることができました。今回の機能拡張により、run bundle-upgrade は、従来の Operator Lifecycle Manager (OLM) ワークフローで最初にインストールされた Operator でも機能するようになりました。

詳細は、Operator Lifecycle Manager での Operator アップグレードのテスト を参照してください。

API が OpenShift Container Platform バージョンから削除されると、削除された API を依然として使用しているクラスターバージョンで実行されている Operator が適切に機能しなくなります。Operator の作成者は、Operator ユーザーの中断を回避するために、API の非推奨および削除に対応するように Operator プロジェクトを更新する計画を立てる必要があります。

詳細は、OpenShift Container Platform バージョンとの Operator 互換性の制御 を参照してください。

ビルド

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

以前のバージョンでは、ビルドは、企業アーティファクトリーポジトリーへのアクセスに必要なことがあるクラスターの PKI 認証局を使用できませんでした。現在では、mountTrustedCA を true に設定することにより、クラスターのカスタム PKI 認証局をマウントするように BuildConfig オブジェクトを設定できるようになりました。

vSphere でマシンを実行している場合、MachineAutoscaler リソース定義で minReplicas 値を 0 に設定できるようになりました。この値を 0 に設定すると、クラスター Autoscaler は、マシンが使用中であるかどうかに応じてマシンセットを 0 に/からスケーリングします。詳細は、MachineAutoscaler リソース定義 を参照してください。

/etc/kubernetes/kubelet-ca.crt 認証局 (CA) の自動ローテーションでは、ノードのドレイン (解放) またはクラスターの再起動において Machine Config Operator (MCO) は不要になりました。

この変更の一環として、以下の変更では MCO によるノードのドレイン (解放) が不要になりました。

MCO がこれらの変更のいずれかを検出すると、その変更を適用し、ノードの遮断を解除します。

詳細は、Machine Config Operator について を参照してください。

以前のバージョンでは、マシンセットを作成するには、ホストのパフォーマンスを向上させるために、ユーザーが CPU ピニング設定、NUMA ピニング設定、および CPU トポロジーの変更を手動で設定する必要がありました。今回の機能拡張により、ユーザーは MachineSet リソースのポリシーを選択し、設定を自動的に設定できるようになりました。詳細は、BZ#1941334 を参照してください。

hugepages プロパティーを MachineSet リソースに提供できるようになりました。今回の機能拡張により、oVirt のカスタムプロパティーで MachineSet リソースのノードが作成され、それらのノードにハイパーバイザーの hugepages を使用するように指示されるようになりました。詳細は、BZ#1948963 を参照してください。

OpenShift Container Platform 4.8 は、一部の ImageContentSourcePolicy オブジェクト変更のワークロードの中断を防ぎます。この機能により、ユーザーおよびチームはワークロードの中断なしにミラーおよびレジストリーを追加することができます。その結果、/etc/containers/registries.conf ファイルの以下の変更に対して、ワークロードの中断は発生しなくなりました。

/etc/containers/registries.conf ファイルのその他の変更については、Machine Config Operator はデフォルトでノードをドレイン (解放) して変更を適用します。詳細は、BZ#1943315 を参照してください。

operator.openshift.io/v1 API グループが Descheduler で利用可能になりました。Descheduler の operator.openshift.io/v1beta1 API グループのサポートは今後のリリースで削除される可能性があります。

Descheduler をインストールした openshift-kube-descheduler-operator namespace に openshift.io/cluster-monitoring=true ラベルを追加することで、 Descheduler の Prometheus メトリクスを有効にできるようになりました。

以下の Descheduler メトリクスを利用できます。

今回のリリースにより、Pod 仕様の Huge Page の要求および制限を設定する際に、Downward API を使用してコンテナー内から Pod の割り当てを表示できるようになりました。この拡張機能は DownwardAPIHugePages 機能ゲートに依存します。OpenShift Container Platform 4.8 は機能ゲートを有効にします。

詳細は、Downward API を使用した Huge Page リソースの消費 について参照してください。

Node Feature Discovery (NFD) Operator は、OpenShift Container Platform クラスターの各ノードで利用可能なハードウェア機能を検出します。次に、これはノードラベルでノードオブジェクトを変更します。これにより、NFD Operator は特定のノードの機能を公開できます。OpenShift Container Platform 4.8 は、NFD Operator の 3 つの追加のラベルをサポートします。

Poison Pill Operator を使って、正常ではないノードが自動的に再起動するようにできます。これにより、ステートフルアプリケーションと ReadWriteOnce(RWO) ボリュームのダウンタイムを最小限に抑え、一時的な障害が発生した場合に計算能力を回復します。

Poison Pill Operator は、あらゆる種類のクラスターとハードウェアで動作します。

詳しくは、Remediating nodes with the Poison Pill Operator をご覧ください。

/etc/kubernetes/kubelet-ca.crt 認証局 (CA) の自動ローテーションでは、ノードのドレイン (解放) またはクラスターの再起動において Machine Config Operator (MCO) は不要になりました。

この変更の一環として、以下の変更では MCO によるノードのドレイン (解放) が不要になりました。

MCO がこれらの変更のいずれかを検出すると、その変更を適用し、ノードの遮断を解除します。

詳細は、Machine Config Operator について を参照してください。

OpenShift Container Platform vertical pod autoscaler (VPA) が一般に利用可能になりました。VPA は、Pod 内のコンテナーの履歴および現在の CPU とメモリーリソースを自動的に確認し、確認された使用についての値に基づいてリソース制限および要求を更新できます。

以下のように VerticalPodAutoscalerController オブジェクトを変更して、1 つのレプリカのみを必要とする Pod で VPA を使用することもできます。以前のバージョンでは、VPA は 2 つ以上のレプリカを必要とする Pod でのみ機能しました。

詳細は、vertical pod autoscaler を使用した Pod リソースレベルの自動調整 について参照してください。

デフォルトで、ワークロードオブジェクトは、VPA が Pod を自動的に更新できるようにするためにレプリカを 2 つ以上指定する必要があります。そのため、2 つ未満を指定するワークロードオブジェクトの場合 VPA は機能しません。このクラスター全体の最小値は、VerticalPodAutoscalerController オブジェクトを変更して minReplicas パラメーターを追加することで変更できます。

詳細は、vertical pod autoscaler を使用した Pod リソースレベルの自動調整 について参照してください。

OpenShift Container Platform は、ノードの起動時に system-reserved 設定の最適なサイジング値を自動的に判別できます。以前のバージョンでは、system-reserved 設定の CPU およびメモリーの割り当ては、手動で決定し、設定する必要のある固定された制限値でした。

リソースの自動割り当てが有効な場合、各ノードのスクリプトにより、ノードにインストールされている CPU およびメモリーの容量に基づいて、予約されたそれぞれのリソースに最適な値が計算されます。

詳細は、ノードのリソースの自動割り当て について参照してください。

イメージのプルおよびプッシュ用に許可され、ブロックされるレジストリーの一覧を作成する際に、レジストリー内に個別のリポジトリーを指定できるようになりました。以前のバージョンでは、レジストリーのみを指定できました。

詳細は、特定レジストリーの追加 および 特定レジストリーのブロック を参照してください。

cron ジョブカスタムリソースが一般に利用できるようになりました。この変更の一環として、cron ジョブのパフォーマンスを大幅に向上させる新しいコントローラーが実装されました。cron ジョブの詳細は、ジョブと Cron ジョブについて を参照してください。

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

OpenShift Container Platform 4.8 では、次のリリースで削除される API が使用中の場合に実行される 2 つの新規アラートが導入されました。

新しい APIRequestCount API を使用して、非推奨の API を使用する内容を追跡することができます。これにより、次のリリースにアップグレードするためにアクションが必要であるかどうかについて計画できます。

OpenShift Container Platform 4.8 には、以下のモニターリングスタックコンポーネントおよび依存関係に対するバージョンの更新が含まれます。

kube-state-metrics はバージョン 2.0.0 にアップグレードされました。以下のメトリクスは kube-state-metrics バージョン 1.9 で非推奨となり、バージョン 2.0.0 で事実上削除されます。

サードパーティーの Alertmanager UI へのリンクは、OpenShift Container Platform Web コンソールの Monitoring → Alerting ページから削除されます。また、サードパーティーの Grafana UI へのリンクは、Monitoring → Dashboards ページから削除されます。openshift-monitoring プロジェクトの Networking → Routes ページに移動して、Administrator パースペクティブの Web コンソールで Grafana UI および Alertmanager UI へのルートに引き続きアクセスできます。

OpenShift Container Platform Web コンソールの Monitoring → Dashboards ページで新しい拡張機能を利用できます。

単一ノードクラスターでテストを実行すると、SR-IOV および SCTP テストを含む特定のテストのタイムアウトが長くなり、コントロールプレーンとワーカーノードを必要とするテストは省略されます。ノードの再起動が必要な再設定では、OpenShift コントロールプレーンを含む環境全体が再起動されるため、完了するまでに時間がかかります。コントロールプレーンおよびワーカーノードを必要とするすべての PTP テストは省略されます。テストは起動時にノード数をチェックし、それに応じてテスト動作を調整するため、追加の設定は必要ありません。

PTP テストが検出モードで実行できます。このテストは、クラスター外に設定された PTP マスターを検索します。以下のパラメーターが必要です。

Performance Addon Operator を使用すると、パフォーマンスプロファイルを設定して、各ネットワークデバイスの Network Interface Card (NIC) キュー数を調整できます。デバイスネットワークキューを使用すると、パケットを複数の異なる物理キューに分散でき、各キューはパケット処理用に個別のスレッドを取得します。

Data Plane Development Kit (DPDK) ベースのワークロードの場合、NIC キューを予約済みまたはハウスキーピング CPU の数に制限して、必要な低レイテンシーを実現するために NIC キューを減らすことが重要です。

詳細は、Performance Addon Operator を使用した NIC キューの削減 について参照してください。

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

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

Performance Profile Creator (PPC) ツールを使用してパフォーマンスプロファイルを作成できるようになりました。このツールは、クラスターから must-gather データおよびいくつかのユーザー指定のプロファイル引数を消費し、この情報を使用して、ハードウェアおよびトポロジーに適したパフォーマンスプロファイルを生成します。

詳細は、コントロールプレーンプロファイルの作成 について参照してください。

Node Feature Discovery (NFD) Operator が利用可能になりました。これを使用して、ハードウェア機能およびシステム設定を検出する Node Feature Discovery という Kubernetes アドオンをオーケストレーションしてノードレベルの情報を公開します。

Driver Toolkit をドライバーコンテナーのベースイメージとして使用し、Kubernetes で特別なソフトウェアおよびハードウェアデバイスを有効化できるようになりました。これは現在、テクノロジープレビュー機能です。

新規の拡張機能は、バックアップ後および復元前の etcd スナップショットのステータスを検証します。以前のバージョンでは、バックアッププロセスは、取得されたスナップショットが完了したことを検証しませんでした。また、復元プロセスは、復元されるスナップショットが有効であり、破損していないことを検証しませんでした。バックアップまたは復元中にディスクが破損している場合は、エラーが管理者に明確に報告されるようになりました。詳細は、BZ#1965024 を参照してください。

OpenShift Container Platform 4.8 では、ネットワークが制限された環境で操作しているユーザーは、Insights Operator アーカイブを Insights Advisor に収集し、アップロードして潜在的な問題を診断できます。さらに、ユーザーはアップロード前に、Insights Operator アーカイブに含まれる機密データを難読化できます。

詳細は、限定的なネットワーク環境でのリモートヘルスレポートの使用 を参照してください。

OpenShift Container Platform Web コンソールの Insights Advisor は、0 の問題が検出されたと正しく報告するようになりました。以前のバージョンでは、Insights Advisor は情報を提供していませんでした。

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

この追加情報により、Red Hat は Insights Advisor の改善された修復手順を提供できます。

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

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

Cloud Credential Operator (CCO) ユーティリティー (ccoctl) を、Amazon Web Services Security Token Service (AWS STS) を使用するように設定できるようになりました。CCO が STS を使用するように設定されている場合、短期的で権限に制限のあるセキュリティー認証情報を提供する IAM ロールをコンポーネントに割り当てます。

この機能は以前は OpenShift Container Platform 4.7 のテクノロジープレビュー機能として導入されましたが、OpenShift Container Platform 4.8 では一般に利用可能となりました。

詳細は、STS での手動モードの使用 を参照してください。

OpenShift サンドボックスコンテナーの新機能、バグ修正、既知の問題、および非同期エラータ更新を確認するには、OpenShift sandboxed containers 1.0 release notes を参照してください。