1.2. 新機能および改良された機能

OpenShift Container Platform 4.1 で、Red Hat はクラスターに対する適切なアップグレードバージョンを推奨するアップグレードチャネルの概念を導入しました。アップグレードチャネルは、アップグレードストラテジーを切り分け、更新の頻度を制御するためにも使用されます。チャネルは OpenShift Container Platform のマイナーバージョンに関連付けられます。たとえば、OpenShift Container Platform 4.2 チャネルには 4.3 リリースへのアップグレードが含まれることはありません。これにより、管理者は OpenShift Container Platform の次のマイナーバージョンへのアップグレードに関して明確な決定を行うことができます。チャネルは更新のみを制御し、インストールするクラスターのバージョンには影響を与えません。 OpenShift Container Platform の特定のパッチレベルの openshift-install バイナリーは、そのパッチレベルのインストールを常に実行します。

更新のタイプおよびアップグレードチャネルについての詳細は、「 OpenShift 4.2 Upgrades phased roll out 」を参照してください。

アップグレードは Red Hat Service Reliability Engineering (SRE) チームからのデータに基づいて段階的に展開される際にチャネルに公開されるため、初期リリースでバージョン 4.1.z から 4.2 への更新が利用できるという通知が Web コンソールですぐに表示されない可能性があります。

OpenShift Container Platform 4.2 では、openshift-installという CLI ベースのインストーラーが新たに導入されました。これは、対話型のガイド付きワークフローを使用し、30 分程度でイミュータブルなインストーラーでプロビジョニングされたインフラストラクチャーに OpenShift をプロビジョニングできるよう単純化を目的として設計されています。この方法は、OpenShift デプロイメントにおいてホスト OS およびプラットフォームの更新、およびインフラストラクチャー管理のフルスタック自動化を実現し、独自のインフラストラクチャーをプロビジョニングする際の複雑な作業を排除します。すべての必須ではないインストール設定オプションついてのみ最小限のユーザー入力が必要となり、これらのオプションはコンポーネント Operator のカスタムリソース定義 (CRD、Customer Resource Definition) を使用してインストール後に設定されます。

更新はほぼ同じ方法で実行されます。OpenShift の更新コンテンツはまずローカルコンテナーレジストリーにミラーリングする必要があり、その後管理者は oc adm upgrade に対して更新コンテンツをどこからプルするかを指定します。

OpenShift Container Platform 4.2 では、接続するネットワークが制限された環境での OpenShift Container Platform クラスターのインストールおよび更新のサポートが導入されました。これは、OpenShift Container Platform コンテンツをホストするための docker 2.2 仕様に準拠するコンテナーレジストリーを使用するように設計されています。

まず、管理者は Quay.io のコンテンツをそれぞれのローカルのコンテナーレジストリーに複製する必要があります。次に、コンテンツのプルを Quay.io からではなくローカルに実行する Ignition 設定を生成するように openshift-install を設定できます。これは、ユーザーによってプロビジョニングされるインフラストラクチャー (UPI、User-Provisioned Infrastructure) のデプロイメントでのみ機能するように設計されています。

ネットワークが制限された環境では、OLM カタログの Operator を引き続き使用できます。ただし、オフラインカタログを設定するために Operator ソースを手動でプルする必要があります。この手動プロセスは、OpenShift Container Platform 4.2 での一時的な回避策としてのみ使用されます。今後のリリースでは、自動化ソリューションが提供されます。

詳細は、「Installing in restricted networks」および「 Using Operator Lifecycle Manager on restricted networks」を参照してください。

OpenShift Container Platform 4.2 では、異なるコンピュートノードまたはワーカーノードのないクラスターをベアメタルクラスターにデプロイする機能をテクノロジープレビュー機能として利用できます。プロビジョニングするベアメタルインフラストラクチャーへのクラスターのインストール時にワーカーマシンを作成しない場合、ルーター Pod を含むすべての Pod が代わりにコントロールプレーンまたはマスターマシンにデプロイされます。このデプロイメント方法は、OpenShift Container Platform 4.2 のクラウドベースのクラスターでは利用できないことに注意してください。実稼働クラスターでテクノロジープレビュー機能を使用することは推奨していません。

OpenShift Container Platform 4.2 では、ユーザーによってプロビジョニングされるインフラストラクチャーでの企業プロキシーサーバーを使用した OpenShift Container Platform クラスターのインストールおよび更新のサポートが導入されました。プロキシー情報（httpProxy、httpsProxy、および noProxy）は、インストールプロセスで使用される install-config.yaml ファイルに定義でき、cluster プロキシーオブジェクトを使用してインストール後に管理することもできます。

また、MITM HTTPS の企業プロキシーを許可する独自の CA バンドルを提供するためのサポートも提供されています。

OpenShift Container Platform はインフラストラクチャー全体を認識し、オペレーティングシステムは管理下に置かれるようになります。これにより、インストールおよび更新がプラットフォームや基礎となるオペレーティングシステム全体でシームレスに行われるようになります。すべてのものが単一エンティティーとして管理されます。

OpenShift Container Platform 4.2 では、フルスタック自動化 (IPI) と既存のインフラストラクチャー (UPI) の主に 2 つのインストールタイプに基づいてインストールが行われます。

フルスタック自動化の場合、インストーラーが OpenShift Container Platform の使用しやすい事前に設定されたデプロイにより、インフラストラクチャーのプロビジョニングを含むインストールのすべての領域を制御します。既存インフラストラクチャーのデプロイメントでは、管理者が独自のインフラストラクチャーを作成し、管理します。この場合、より多くのカスタマイズやより柔軟な運用が可能になります。

OpenShift Container Platform 4.2 では、フルスタック自動化デプロイメントのサポートが拡張し、AWS、Microsoft Azure、Google Cloud Platform (GCP)、および Red Hat OpenStack Platform が対象に含まれています。さらに、(AWS、ベアメタルおよび VMware vSphere がすでに含まれる) ユーザーによってプロビジョニングされるインフラストラクチャーでサポートされるプロバイダーの一覧に GCP が追加されました。

CAM および CPMA についての詳細は、「Where can I find Red Hat Cluster Application Migration Tool (CAM) and Red Hat Control Plane Migration Assistant (CPMA) now that OpenShift 4.2 has GA’ed」を参照してください。

Operator についてはこれまで OpenShift Container Platform 製品ドキュメントの『Applications』ガイドに記載されていましたが、今回より『 Operator』ガイドが新たにご利用いただけるようになりました。このガイドには、Operator、Operator Lifecycle Manager、および Operator SDK についての既存情報および更新された情報と、OpenShift Container Platform 4.2 に固有の新規の内容が盛り込まれています。

以前のバージョンでは、cluster-admin ロールを持つユーザーのみが Operator をインストールすることができました。OpenShift Container Platform 4.2 では、cluster-admin で namespace を選択でき、その namespace では管理者は Operator を各自でインストールできます。cluster-admin はこの namespace で ServiceAccount を定義します。この namespace にあるすべてのインストールされた Operator は、この ServiceAccount と同レベルまたはそれよりも低いレベルのパーミッションを取得します。

詳細は、「Creating policy for Operator installations and upgrades 」を参照してください。

Ingress Operator は、Azure および GCP のインストーラーでプロビジョニングされるインフラストラクチャーに関連した 4.2 のすべての Ingress 機能をサポートします。

Machine Config Operator (MCO) はクラスターレベルの設定を提供し、ローリングアップグレードを有効にし、新規ノードと既存ノード間に差異が生じることを防ぎます。

Node Feature Discovery (NFD) Operator は各ノードで利用可能なハードウェア機能を検出し、ノードラベルを使用してそれらの機能を公開します。

NFD によって管理される CPU 機能には、以下が含まれます。

NFD によって管理されるカーネル機能には、以下が含まれます。

NFD によって管理されるその他の機能には、以下が含まれます。

NFD Operator は NFD DaemonSet のインストールおよびライフサイクルを管理します。OperatorHub で NFD Operator にアクセスします。

Node Tuning Operator は最初に OpenShift Container Platform 4.1 で導入されました。これはクラスターノードレベルのチューニングを管理します。デフォルトの CR は標準的なノードレベルのチューニングに使用されることが意図されています。今回の OpenShift Container Platform 4.2 の拡張機能により、高パフォーマンス化などのチューニングのカスタマイズが可能になりました。

カスタムチューニングの場合、独自のチューニング済みのカスタムリソース (CR) を作成します。新規に作成された CR は、デフォルトの CR、およびノードまたは Pod のラベルおよびプロファイルの優先順位に基づいてノードに適用されるカスタムチューニングと組み合わされます。

ローカルストレージ Operator を使用する永続ボリュームが OpenShift Container Platform 4.2 で利用可能になりました。

Container Storage Interface (CSI) が OpenShift Container Platform 4.2 で利用可能になりました。CSI は、Red Hat OpenShift Container Storage (OCS) を有効にし、それらの CSI プラグインと連動させるために Kubernetes で導入されています。CSI の導入により、Kubernetes ボリュームレイヤーの 拡張性は強化されます。

現時点では、API のみご利用いただけます。Operator に含まれる CSI ドライバーは、今後のリリースでご利用いただけます。

以下の raw ブロックボリュームは OpenShift Container Platform 4.2 で完全にサポートされるようになりました。

iSCSI を使用した raw ブロックボリュームは、テクノロジープレビューとしてご利用いただけます。

OpenShift Container Platform 4.2 のクラスター制限に関する指示が更新されました。

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

OpenShift Do (odo) は、OpenShift でアプリケーションを作成、ビルド、およびデプロイするための開発者向けの CLI ツールです。odo ツールは完全にクライアントベースで、デプロイに OpenShift Container Platform クラスター内のサーバーを必要としません。これは、ローカルコードの変更を検知し、これをクラスターに自動的にデプロイすると共に、変更を検証するためのインスタントフィードバックをリアルタイムで提供します。複数のプログラミング言語やフレームワークをサポートします。

CodeReady コンテナーは OpenShift Container Platform 4 以降の最小クラスターのローカルデスクトップインスタンスを提供します。このクラスターは、開発およびテスト目的で使用される最小限の環境を開発者に提供します。これには、OpenShift クラスターを実行する CodeReady コンテナーの仮想マシンと対話するための crc CLI が含まれます。

CRI-O は、Kubernetes のバージョニングに一致する kubernetes 固有のコンテナーエンジンであり、バージョンの不一致を生じさせないためにサポートを単純化します。既存の Docker および OCI コンテナーすべてがサポートされ、それらは CRI-O で適切に実行されるため、導入が簡単です。CRI-O は軽量な kubernetes ネイティブの、OCI と互換性のあるコンテナーランタイムであり、OpenShift Container Platform によってライフサイクルが設定され、管理されます。どのコンテナーランタイムが使用されているかについて把握する必要はありません。OpenShift Container Platform では、常に適切なコンテナーランタイムが使用され、Kubernetes Container Runtime Interface (CRI) の完全な実装が提供されます。さらに、コンテナーエンジンを個別に管理する必要もありません。CRI-O には CRI-O の制御機能およびセキュリティーを提供するチューニング可能なパラメーターが含まれます。それらは CRD で簡単に設定でき、設定はクラスター全体に伝播されます。

システム管理者は、ノードごとに sysctl をホワイトリストに設定できます。すべての安全な sysctl はデフォルトで有効にされ、すべての安全でない sysctl はデフォルトで無効にされます。詳細は、「 Using sysctls in containers 」を参照してください。

OpenShift Container Platform 4.2 では、マスターノードがスケジュール対象になりました。詳細は、「Working with nodes」を参照してください。

OpenShift Container Platform 4.2 では、Red Hat OpenStack に OpenShift Container Platform クラスターをデプロイするためのフルスタック自動化サポートが導入されました。

インストーラーは、Kubernetes OpenStack Cloud Provider と共に OpenStack API を使用して、仮想マシン (VM) 、ネットワーク、セキュリティーグループ、オブジェクトストレージなど、OpenShift Container Platform をデプロイし、クラスターを Red Hat OpenStack Platform で実行できるよう適切に設定するために必要なすべての OpenStack リソースを作成します。

OpenShift Container Platform 4.2 は Red Hat OpenStack バージョン 13 でデプロイできます。

現時点でテクノロジープレビューである Open vSwitch の Open Virtual Networking (OVN) には、お客様主導の機能要件を加速するなど、数多くの利点があります。これらの要件には事前に有効にされるものがあり、以下のような各種の利点が含まれます。

クラウドプラットフォームで Ingress コントローラーを作成する場合、Ingress コントローラーはデフォルトでパブリッククラウドロードバランサーによって公開されます。

ユーザーは、Ingress コントローラーを内部クラウドロードバランサーで公開できるようになりました。以下は例になります。

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  namespace: openshift-ingress-operator
  name: internal
spec:
  endpointPublishingStrategy:
    type: LoadBalancerService
    loadBalancer:
      scope: Internal

実装の詳細については、Kubernetes サービスドキュメントを参照してください。

.spec.endpointPublishingStrategy.loadBalancer.scope は、いったん設定されると変更することができません。スコープを変更するには、Ingress コントローラーを削除し、再作成します。

デフォルト Ingress コントローラーは、削除および再作成を実行して内部で利用可能にすることができます。

詳細は、「 Ingress Operator in OpenShift Container Platform 」を参照してください。

機能の拡大に向けて、いくつかの Kubernetes CNI プラグインが OpenShift Container Platform 4.2 で追加され、拡張されています。

これらの SR-IOV ソリューションは OpenShift Container Platform 4.2 でも引き続きテクノロジープレビューとしてご利用いただけます。

新規 CNI プラグイン:

GPU が Red Hat Enterprise Linux (RHEL) 7 ノードでサポートされるようになりました。これらは CUDA ドライバーおよびドライバーコンテナーのサポートがないため、RHEL CoreOS ノードではサポートされません。

OpenShift Container Platform Web コンソールをカスタマイズして、カスタムロゴ、リンク、通知バナー、およびコマンドラインのダウンロードを設定できます。これは、Web コンソールを企業や政府の特定要件を満たすように調整する必要がある場合にとくに役立ちます。

詳細は、「Customizing the web console」を参照してください。

API リソースは、Home Explore にある Explore API Resources ダッシュボードで簡単に検索し、管理できます。

各 API のスキーマとサポートされるパラメーターを確認し、API のインスタンスを管理し、各 API のアクセスを確認できます。

Machine Autoscaler を使用してクラスターをスケーリングできるようになりました。Machine Autoscaler は、クラスターにデプロイされる MachineSet でマシン数を調整します。追加のデプロイメントをサポートするための十分なリソースがクラスターにない場合にマシンを追加します。インスタンスの最小数または最大数の変更などが生じると、それらの変更は MachineAutoscaler がターゲットに設定する MachineSet に即時に適用されます。

Developer パースペクティブは、開発者中心の視点を Web コンソールに追加します。これは、複数のオプションを使用したアプリケーションの作成や OpenShift Container Platform へのデプロイメントなど、開発者のユースケースに固有のワークフローを提供します。これは、プロジェクト内のアプリケーションを視覚的に表示し、それらのビルドステータスおよびアプリケーションに関連するコンポーネントやサービスを表示し、対話およびモニタリングを容易にします。また、Serverless 機能 (テクノロジープレビュー)、および Eclipse Che を使用してアプリケーションコードを編集するためのワークスペースを作成する機能を組み込みます。

Prometheus クエリーを Web コンソールで直接実行できるようになりました。Monitoring Metrics に移動します。

クラスターの OAuth 設定ページでは、ユーザーがクラスターにログインするために使用するアイデンティティープロバイダー (IDP) が追加されています。IDP には GitHub、GitLab、Google、LDAP、Keystone などが含まれます。