1.2. 移行の計画

OpenShift Container Platform 4.2 への移行を実行する前に、十分な時間を取って移行を適切に計画できるようにしてください。OpenShift Container Platform 4 ではアーキテクチャーの変更および拡張機能が導入されるため、OpenShift Container Platform 3 クラスターの管理に使用した手順は OpenShift Container Platform 4 で適用されない可能性があります。

注記

この計画ガイドでは、OpenShift Container Platform 3.11 から OpenShift Container Platform 4.2 への移行を前提としています。

本書では、最も重要な OpenShift Container Platform 3 と OpenShift Container Platform 4 の相違点と、最も注目すべき移行に関する考慮事項についての概要を説明します。OpenShift Container Platform 4 クラスターの設定についての詳細は、OpenShift Container Platform ドキュメントの該当するセクションを参照してください。新規機能および他の重要な技術上の変更点についての詳細は、『OpenShift Container Platform 4.2 リリースノート』を参照してください。

既存の OpenShift Container Platform 3 クラスターを OpenShift Container Platform 4 にアップグレードすることはできません。新規の OpenShift Container Platform 4 インストールで開始する必要があります。コントロールプレーンの設定およびアプリケーションのワークロードの移行に役立つツールを使用できます。

1.2.1. OpenShift Container Platform 3 と OpenShift Container Platform 4 の比較

OpenShift Container Platform 3 では、管理者は Red Hat Enterprise Linux (RHEL) ホストを個別にデプロイし、その後に OpenShift Container Platform をこれらのホストにインストールし、クラスターを作成しました。管理者は、これらのホストを適切に設定し、更新を実行する必要があります。

OpenShift Container Platform 4 では、これまでとは大きく異なる方法で OpenShift Container Platform クラスターがデプロイされ、管理されるようになりました。OpenShift Container Platform 4 には、Operator、MachineSet、および Red Hat Enterprise Linux CoreOS (RHCOS) などの、クラスターの操作に対するコアとなる新たなテクノロジーおよび機能が含まれます。このテクノロジーの移行により、クラスターは管理者が以前に実行していた一部の機能を自己管理できるようになります。また、プラットフォームの安定性と一貫性を確保し、インストールおよびスケーリングを単純化することが可能です。

詳細は、『OpenShift Container Platform アーキテクチャー』を参照してください。

1.2.1.1. アーキテクチャーの違い

イミュータブルなインフラストラクチャー

OpenShift Container Platform 4 は、コンテナー化されたアプリケーションを実行するために設計された Red Hat Enterprise Linux CoreOS (RHCOS) を使用し、効率的なインストール、Operator ベースの管理、および単純化されたアップグレードを可能にします。RHCOS は、RHEL のようなカスタマイズ可能なオペレーティングシステムではなく、イミュータブルなコンテナーホストです。RHCOS により、OpenShift Container Platform 4 は基礎となるコンテナーホストのデプロイメントを管理し、自動化できます。RHCOS は OpenShift Container Platform の一部です。これは、すべてがコンテナー内で実行され、OpenShift Container Platform を使用してデプロイされることを意味します。

OpenShift Container Platform 4 では、コントロールプレーンノードは RHCOS を実行する必要があるため、コントロールプレーンのフルスタック自動化が維持されます。これにより、OpenShift Container Platform 3 よりも簡単に更新がロールアウトされ、アップグレードが簡単になります。

詳細は、『Red Hat Enterprise Linux CoreOS』を参照してください。

Operator

Operator は、Kubernetes アプリケーションをパッケージ化し、デプロイし、管理する方法です。Operator は、ソフトウェアの他の部分を実行する際の運用上の複雑さを軽減します。Operator は環境を監視し、現在の状態を使用してリアルタイムの意思決定を行います。高度な Operator は、自動的にアップグレードし、障害に自動的に対応するように設計されています。

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

1.2.1.2. インストールおよび更新の違い

インストールプロセス

OpenShift Container Platform 3.11 をインストールするには、Red Hat Enterprise Linux (RHEL) ホストを準備し、クラスターが必要とする設定値をすべて設定してから、Ansible Playbook を実行してクラスターをインストールし、セットアップする必要がありました。

OpenShift Container Platform 4.2 では、OpenShift インストールプログラムを使用してクラスターに必要なリソースの最小セットを作成できます。クラスターの実行後に、Operator を使用してクラスターをさらに設定し、新規サービスをインストールすることができます。初回の起動後に、Red Hat Enterprise Linux CoreOS (RHCOS) システムは、OpenShift Container Platform クラスターで実行される Machine Config Operator (MCO) によって管理されます。

詳細は、「インストールプロセス」を参照してください。

RHEL ワーカーマシンを OpenShift Container Platform 4.2 クラスターに追加する場合、Ansible Playbook を使用して、クラスターの実行後に RHEL ワーカーマシンを追加します。詳細は、「RHEL コンピュートマシンの OpenShift Container Platform クラスターへの追加」を参照してください。

インフラストラクチャーオプション

OpenShift Container Platform 3.11 では、ユーザーが準備し、維持するインフラストラクチャーにクラスターをインストールする必要があります。OpenShift Container Platform 4 では、独自のインフラストラクチャーを提供するだけでなく、OpenShift Container Platform インストールプログラムがプロビジョニングし、クラスターが維持するインフラストラクチャーにクラスターをデプロイするオプションを提供します。

詳細は、「OpenShift Container Platform インストールの概要」を参照してください。

クラスターのアップグレード

OpenShift Container Platform 3.11 では、Ansible Playbook を実行してクラスターをアップグレードします。OpenShift Container Platform 4.2 では、クラスターが、クラスターノードの Red Hat Enterprise Linux CoreOS (RHCOS) への更新を含む独自の更新を管理します。Web コンソールまたは OpenShift CLI から oc adm upgrade コマンドを使用することでクラスターを容易にアップグレードでき、Operator は自動的にアップグレードされます。OpenShift Container Platform 4.2 クラスターに Red Hat Enterprise Linux ワーカーマシンがある場合、Ansible Playbook を引き続き実行してそれらのワーカーマシンをアップグレードする必要があります。

詳細は、『クラスターの更新』を参照してください。

1.2.2. 移行に関する考慮事項

OpenShift Container Platform 3.11 から OpenShift Container Platform 4 への移行に影響を与える可能性のある変更やその他の考慮事項を確認します。

1.2.2.1. ストレージに関する考慮事項

OpenShift Container Platform 3.11 から OpenShift Container Platform 4.2 に移行する際に、以下のストレージの変更を考慮してください。

ローカルボリュームの永続ストレージ

ローカルストレージは、OpenShift Container Platform 4.2 ではローカルストレージ Operator を使用する場合にのみサポートされます。OpenShift Container Platform 3.11 のローカルプロビジョナーメソッドの使用はサポートされません。

詳細は、「ローカルボリュームを使用した永続ストレージ」を参照してください。

FlexVolume 永続ボリューム

FlexVolume プラグインの場所が OpenShift Container Platform 3.11 で変更になりました。OpenShift Container Platform 4.2 の新しい場所は /etc/kubernetes/kubelet-plugins/volume/exec です。割り当て可能な FlexVolume プラグインはサポートされなくなりました。

詳細は、「FlexVolume を使用した永続ストレージ」を参照してください。

Container Storage Interface (CSI) 永続ストレージ

Container Storage Interface (CSI) を使用した永続ストレージは OpenShift Container Platform 3.11 では テクノロジープレビューとして利用可能でした。CSI バージョン 1.1.0 は OpenShift Container Platform 4.2 で完全にサポートされていますが、これは CSI ドライバーに同梱されません。そのため、独自のドライバーをインストールする必要があります。

詳細は、「Container Storage Interface (CSI) を使用した永続ストレージ」を参照してください。

Red Hat OpenShift Container Storage

OpenShift Container Platform 3.11 で使用できる Red Hat OpenShift Container Storage 3 は、バッキングストレージとして Red Hat Gluster Storage を使用します。

OpenShift Container Platform 4 で使用できる Red Hat OpenShift Container Storage 4 は、バッキングストレージとして Red Hat Ceph Storage を使用します。

詳細は、「Persistent storage using Red Hat OpenShift Container Storage」および「interoperability matrix」の記事を参照してください。

サポートされていない永続ストレージオプション

OpenShift Container Platform 3.11 の以下の永続ストレージオプションのサポートが OpenShift Container Platform 4.2 で変更になりました。

  • GlusterFS はサポート対象外になりました。
  • スタンドアロン製品としての CephFS がサポートされなくなりました。
  • スタンドアロン製品としての Ceph RBD がサポートされなくなりました。
  • iSCSI がテクノロジープレビューとしてご利用いただけます。

OpenShift Container Platform 3.11 でこれらのいずれかを使用していた場合は、OpenShift Container Platform 4.2 で完全にサポートされる別の永続ストレージオプションを選択する必要があります。

詳細は、「永続ストレージについて」を参照してください。

1.2.2.2. ネットワークの考慮事項

OpenShift Container Platform 3.11 から OpenShift Container Platform 4.2 に移行する際に、考慮事項となる以下のネットワークの変更を確認してください。

ネットワーク分離モード

OpenShift Container Platform 3.11 では、ユーザーは ovn-multitenantを使用するように頻繁に切り替えましたが、デフォルトのネットワーク分離モードは ovs-subnetでした。OpenShift Container Platform 4.2 のデフォルトのネットワーク分離モードは NetworkPolicy になりました。

OpenShift Container Platform 3.11 クラスターで ovs-subnet または ovs-multitenant モードを使用していた場合、OpenShift Container Platform 4.2 クラスターでは NetworkPolicy モードに切り換えることが推奨されます。NetworkPolicy はアップストリームでサポートされ、より柔軟であり、ovs-multitenant が実行する機能を提供します。OpenShift Container Platform 4.2 で NetworkPolicy を使用する際に ovs-multitenant 動作を維持する必要がある場合、NetworkPolicy を使用したマルチテナント分離の設定手順を実行します。

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

ホスト間のトラフィックの暗号化

OpenShift Container Platform 3.11 では、IPsec を使用してホスト間のトラフィックを暗号化できます。OpenShift Container Platform 4.2 は IPsec をサポートしません。サービス間で相互 TLS を有効にするために、Red Hat OpenShift Service Mesh を使用することが推奨されます。

詳細は、Red Hat OpenShift Service Mesh について参照してください。

1.2.2.3. ロギングについての考慮事項

OpenShift Container Platform 3.11 から OpenShift Container Platform 4.2 に移行する際に、考慮事項となる以下のロギングの変更を確認してください。

クラスターロギングのデプロイ

OpenShift Container Platform 4 は、クラスターロギングカスタムリソースを使用してクラスターロギングの単純なデプロイメントメカニズムを提供します。デプロイが完了すると、クラスターロギングは OpenShift Container Platform 3.11 の場合と同じように使用できます。

詳細は、「クラスターロギングのデプロイおよび設定について」を参照してください。

集計ロギングデータ

集計ロギングデータを OpenShift Container Platform 3.11 から新規の OpenShift Container Platform 4 クラスターに移行することはできません。

詳細は、「クラスターロギングについて」を参照してください。

1.2.2.4. セキュリティーに関する考慮事項

OpenShift Container Platform 3.11 から OpenShift Container Platform 4.2 へ移行する際に、考慮事項となる以下のセキュリティーの変更を確認してください。

検出エンドポイントへの認証されていないアクセス

OpenShift Container Platform 3.11 では、認証されていないユーザーは検出エンドポイント (例: /api/* および /apis/*) にアクセスできました。セキュリティー上の理由から、検出エンドポイントへの認証されていないアクセスは OpenShift Container Platform 4.2 で許可されなくなりました。認証されていないアクセスを許可する必要がある場合は、必要に応じて RBAC を設定できます。 ただし、これにより内部クラスターコンポーネントが外部ネットワークに公開される可能性があるため、セキュリティー上の影響を考慮してください。

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

アイデンティティープロバイダーの設定は、以下の主な変更点を含め、 OpenShift Container Platform 4 で変更されています。

  • OpenShift Container Platform 4.2 の要求ヘッダーアイデンティティープロバイダーには相互 TLS が必要ですが、OpenShift Container Platform 3.11 ではこれは必要ではありませんでした。
  • OpenID Connect アイデンティティープロバイダーの設定は OpenShift Container Platform 4.2 で単純化されています。OpenShift Container Platform 3.11 で以前に指定される必要のあったデータが、プロバイダーの /.well-known/openid-configuration エンドポイントから取得できるようになりました。

詳細は、「アイデンティティープロバイダー設定について」を参照してください。

1.2.2.5. モニタリングに関する考慮事項

OpenShift Container Platform 3.11 から OpenShift Container Platform 4.2 に移行する際に、考慮事項となる以下のモニタリングの変更を確認してください。

インフラストラクチャーの可用性についてのモニタリングアラート

モニタリング構造の可用性を確保するためにトリガーするデフォルトのアラートは OpenShift Container Platform 3.11 では DeadMansSwitch と呼ばれていました。この名前は OpenShift Container Platform 4 で Watchdog に変更されています。OpenShift Container Platform 3.11 で PagerDuty 統合をこのアラートでセットアップしている場合、OpenShift Container Platform 4 では Watchdog アラートについて PagerDuty 統合をセットアップする必要があります。

詳細は、「カスタム Alertmanager 設定の適用」を参照してください。