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