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

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

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

1.2.1.1. OpenShift Container Platform アップグレードの段階的ロールアウト

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 コンソールですぐに表示されない可能性があります。

1.2.1.2. CLI ベースのインストール

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

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

1.2.1.3. ネットワークが制限されたインストール

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」を参照してください。

1.2.1.4. 3 ノードのベアメタルデプロイメント(テクノロジープレビュー)

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

1.2.1.5. クラスター全体の egress プロキシー

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

重要

クラスター全体のプロキシーは、サポートされるプロバイダーについてユーザーによってプロビジョニングされるインフラストラクチャーのインストールを使用している場合にのみサポートされます。

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

1.2.1.6. 新規のプラットフォーム境界

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

1.2.1.7. IPI および UPI

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

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

1.2.1.8. フルスタック自動化によるデプロイ

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

1.2.1.9. Red Hat Cluster Application Migration Tool および Red Hat Control Plane Migration Assistant

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」を参照してください。

1.2.2. Operator

1.2.2.1. Operator 関連の新規製品ドキュメント

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

1.2.2.2. スコープ付き Operator のインストール

以前のバージョンでは、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 」を参照してください。

1.2.2.3. Ingress Operator

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

1.2.2.4. Machine Config Operator

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

1.2.2.5. Node Feature Discovery Operator

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

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

  • cpuid
  • hardware_multithreading
  • power
  • pstate

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

  • config
  • selinux_enabled
  • version
  • os_version

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

  • NVMe
  • NUMA
  • SR-IOV
  • GPU

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

1.2.2.6. Node Tuning Operator の拡張機能

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

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

1.2.3. Storage

1.2.3.1. ローカルストレージ Operator を使用した永続ボリューム

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

1.2.3.2. OpenShift Container Storage Interface (CSI)

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

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

1.2.3.3. raw ブロックボリュームのサポート

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

  • ローカルボリューム
  • クラウドプロバイダー(AWS、GCP、Azure、および vSphere)

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

1.2.4. スケーリング

1.2.4.1. クラスターの制限

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

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

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

1.2.5.1. OpenShift Do

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

1.2.5.2. CodeReady コンテナー

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

1.2.6. ノード

1.2.6.1. CRI-O サポート

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 で簡単に設定でき、設定はクラスター全体に伝播されます。

1.2.6.2. sysctl 設定のホワイトリスト化

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

1.2.6.3. マスターノードがスケジュール対象になる

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

重要

Pod をマスターノードにスケジュールすることも可能ですが、クラスターからすべてのワーカーノードを削除する機能はベアメタルに制限されています。「3 ノードのベアメタルデプロイメント (テクノロジープレビュー)」を参照してください。

1.2.7. ネットワーク

1.2.7.1. OpenStack 上にインストーラーでプロビジョニングされる OpenShift

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 でデプロイできます。

1.2.7.2. OVN (テクノロジープレビュー)

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

  • OVS による仮想ネットワークの実装により統合がより容易になる。
  • SDN ポートフォリオの統合。
  • iptables のスケーリング関連の問題がほぼ存在しなくなる。
  • Windows ノードを持つ異種のクラスター。
  • オンプレミスおよびクラウドノードにまたがる機能
  • フルネットワークポリシーサポート
  • Pod ごとの Egress IP。
  • 分散 L4 Ingress/Egress ファイアウォール。
  • 分散サービスロードバランサー。
  • トラフィックの分離とマルチテナンシー。
  • Data Plane Development Kit (DPDK) サポート。
  • 暗号化されたトンネル。
  • IPv6 および DHCPv6。
  • QoS、コントロールおよびデータプレーンの分離。

1.2.7.3. プライベートクラスターの内部 Ingress コントローラーの有効化

クラウドプラットフォームで 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 」を参照してください。

1.2.7.4. Kubernetes CNI プラグインの追加および機能強化

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

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

  • RDMA および RoCE サポート
  • SR-IOV VF の DPDK モード
  • 受付コントローラー
  • Operator

新規 CNI プラグイン:

  • IPVLAN
  • VLAN を使用したブリッジ
  • 静的 IPAM

1.2.7.5. OpenShift クラスターでの GPU の有効化

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

1.2.8. Web コンソール

1.2.8.1. コンソールのカスタマイズオプション

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

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

1.2.8.2. 新規 API Explorer

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

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

1.2.8.3. Machine Autoscaler

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

1.2.8.4. Developer パースペクティブ

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

1.2.8.5. Prometheus クエリー

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

1.2.8.6. アイデンティティープロバイダー

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

1.2.8.7. Web コンソールの一般的な更新情報

  • ダッシュボードのデザインが新たになり、メトリクスが新たに追加されました。
  • CatalogDeveloper パースペクティブに移動しました: DeveloperAdd+From Catalog に移動します。
  • プロジェクトのステータスは、プロジェクトの詳細ページの Workloads タブに移動しました。
  • OperatorHub は Operators メニューの下に置かれています。
  • チャージバックのサポートが利用可能になりました。アプリケーションごとに要求される予約済みおよび使用済みのリソースを表示できます。
  • 現時点で非推奨となっているサービスカタログを有効にしなくても、ネイティブテンプレートのサポートが利用可能になりました。