第1章 アップグレード方式およびストラテジー
1.1. クラスターのアップグレードについて
OpenShift Container Platform の新規バージョンがリリースされると、既存のクラスターをアップグレードして最新の拡張機能およびバグ修正を適用できます。これには、リリース 3.7 から 3.9 などの以前のマイナーバージョンからのアップグレードや、マイナーバージョン (3.9.z リリース) 内での非同期エラータ更新の適用が含まれます。最新の変更点を確認するには、『OpenShift Container Platform 3.10 リリースノート』を参照してください。
メジャーバージョン間の「コアとなるアーキテクチャーの変更」により、OpenShift Enterprise 2 環境は OpenShift Container Platform 3 にアップグレードできず、新規インストールが必要になります。
OpenShift Container Platform のアップグレードプロセスでは、Ansible Playbook を使用して、クラスターのアップグレードに必要なタスクを自動化します。初期インストール時や前回の正常なアップグレードで使用した「インベントリーファイル」を使用して、アップグレード Playbook を実行する必要があります。この方法を使用する場合には、アップグレードストラテジー (インプレースアップグレード) か、Blue-Green デプロイメントのいずれかを選択できます。
特に記述がない限り、特定のメジャーバージョンに含まれるノードおよびマスターには、前方と後方の「マイナーバージョン 1 つずつ」と互換性があるので、クラスターのアップグレードはスムーズに実行できます。ただし、クラスター全体をアップグレードするのに、一致しないバージョンを必要以上の時間をかけて実行することはできません。
アップグレードの前に、OpenShift Container Platform サービスがすべて実行されていることを確認します。コントロールプレーンのアップグレードが失敗した場合は、マスターのバージョンをチェックし、すべてのバージョンが同じであることを確認します。マスターがすべて同じバージョンである場合、アップグレードを再実行します。バージョンが異なる場合は、マスターをバージョン付けされた低いバージョンのマスターに一致するようにダウングレードしてからアップグレードを再実行します。
1.2. アップグレードストラテジー
OpenShift Container Platform クラスターのアップグレードでは、インプレースアップグレードまたは Blue-Green デプロイメントの 2 つのストラテジーを使用できます。
1.2.1. インプレースアップグレード
インプレースアップグレードでは、クラスターのアップグレードは実行中の単一クラスターのすべてのホストで実行されます。これはまずマスターで実行され、次にノードで実行されます。Pod はノードのアップグレードの開始前にそのノードから退避し、他の実行中のノードで再作成されます。これは、ユーザーアプリケーションのダウンタイムを短縮するのに役立ちます。
1.2.2. Blue-Green デプロイメント
「Blue-Green デプロイメント」アップグレード方式はインプレース方式と同様のフローに従います。まずマスターおよび etcd サーバーがアップグレードされます。ただしこの方式では、新規ノードをインプレースでアップグレードするのではなく、新規ノード用の並列環境が作成されます。
この方式では、新規デプロイメントの検証後、管理者は古いノードセット (例:「Blue」デプロイメント) から新規セット (例:「Green」デプロイメント) にトラフィックを切り換えることができます。問題が検出される場合も、古いデプロイメントへのロールバックを簡単かつすぐに実行できます。
