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