OpenShiftのアップグレード

OpenShiftのアップグレードについて

• OpenShift 3.9には、Kubernetes 1.8および1.9の機能や修正が統合されています。OpenShift 3.7からアップグレードする場合、クラスターは自動的に3.9にアップグレードされます。

• メジャーバージョン間でアーキテクチャが大きく変更されているため、OpenShift Enterprise 2からOpenShift 3にはアップグレードできません。この場合はクリーンインストールが必要です。

• 基本的に、ノードとマスターは1つのマイナーバージョン間で前方および後方互換性があります。ただし、バージョンが一致しない状態で長期間運用するのは避け、できるだけ早くクラスター全体をアップグレードすることが推奨されます。

アップグレード方法

1. インプレースアップグレード
• クラスター内のすべてのホストでアップグレードを行う方法です。
• マスターが先にアップグレードされ、その後ノードがアップグレードされます。ポッドは他のノードに移動して、ダウンタイムを最小限に抑えます。
• 注意: クイックインストール方法は非推奨です。3.7から3.9へのアップグレードには使用できません。

2. ブルーグリーンデプロイメント
• ダウンタイムを減らすために、2つの同一環境を稼働させ、1つを更新してテストします。
• アップグレード中、ノードの一部はスケジューリング不可にし、ポッドを他のノードに移動させます。アップグレードが成功した後、ノードは再びスケジューリング可能になります。

自動化されたクラスターアップグレード

• 自動アップグレードの内容:
• 設定変更を適用
• Etcdデータの保存
• APIのアップグレード（3.7 → 3.8 → 3.9）
• ルーターやレジストリのアップグレード
• デフォルトのイメージストリームとテンプレートの更新

• 重要な注意点:
• アップグレードを行う前に、すべての前提条件を満たしていることを確認してください。これを怠ると、アップグレードが失敗することがあります。

• GlusterFSを使用している場合:
• コンテナ化されたGlusterFSを使用している場合、ノードのポッドがDaemonSetとして実行されるため、ノードがポッドを排出しません。アップグレードの際は以下の手順を踏んでください：
1. マスター、Etcd、インフラサービス（ルーター、レジストリ、ログ、メトリック）をアップグレード
2. アプリケーションコンテナを実行しているノードをアップグレード
3. GlusterFSを実行しているノードを1台ずつアップグレード

アップグレード前の準備

• アップグレードは1つのマイナーバージョンを超えて行えない:
• 例えば、3.5 → 3.6 → 3.7というように、1バージョンずつ順番にアップグレードしなければなりません。

クラスターのインクリメンタルアップグレード

自動化されたアップグレードの準備

1. OpenShift Container Platform 3.7から3.9へのアップグレードの場合、各マスターおよびノードホストで3.7のリポジトリを無効にし、3.8および3.9のリポジトリを有効にします：

2. 各Red Hat Enterprise Linux 7システムで、最新のatomic-openshift-utilsパッケージをインストールして、openshift-ansible-*パッケージも更新します：

3. OpenShift 3.9では、マスターノードはデフォルトでスケジュール不可にはなっていません。アップグレードプロセス中に自動的にスケジュール可能に設定されます。

4. openshift_disable_swap=falseをインベントリファイルに追加した場合や、ノードで手動でスワップを設定した場合は、アップグレードを実行する前にスワップメモリを無効にしてください。

マスターおよびアプリケーションノードのアップグレード

1. インベントリファイルで openshift_deployment_type=openshift-enterprise という変数を設定します。

2. カスタムDockerレジストリを使用している場合は、openshift_web_console_prefix と template_service_broker_prefix の変数にレジストリのアドレスを明示的に指定する必要があります。これらの値はアップグレードプロセス中にAnsibleによって使用されます。

3. サービスの再起動やノードの再起動を有効にしたい場合は、インベントリファイルで openshift_rolling_restart_mode=system を設定します。このオプションを設定しない場合、アップグレード中にサービスの再起動は行われますが、システムの再起動は行われません。

4. 全ノードを一度にアップグレードする場合は、単一のAnsibleプレイブック（upgrade.yml）を実行します。複数段階でアップグレードを行う場合は、プレイブックを分けて実行します。この方法については「クラスターの複数段階でのアップグレード」に記載されています。

5. すべてのホストを再起動します。再起動後、追加機能をデプロイしていなければ、アップグレードが正常に完了したことを確認できます。

クラスターの複数段階でのアップグレード

• マスターノード

• マスターノードで実行されているノードサービス

• マスターノードおよびスタンドアロンのEtcdホストで実行されているDockerサービス

• ノードサービス

• スタンドアロンノードで実行されているDockerサービス

2段階のアップグレードプロセス

Ansibleフックの使用

1. openshift_master_upgrade_pre_hook: 各マスターノードのアップグレード前に実行されるフック。

2. openshift_master_upgrade_hook: 各マスターノードのアップグレード後、マスターサービスやノードが再起動する前に実行されるフック。

3. openshift_master_upgrade_post_hook: 各マスターノードのアップグレード後、サービスやシステムの再起動が行われた後に実行されるフック。

アップグレードの確認

1. すべてのノードが「Ready」状態になっていることを確認します：

1. docker-registry と router のイメージバージョンを確認します。タグは3.9のリリースと一致している必要があります：

1. マスターノードで診断ツールを使用して、一般的な問題を確認します：

参考資料

1. まず、Red Hat Enterprise Linux 7の各システムに最新のatomic-openshift-utilsパッケージがインストールされていることを確認します。

2. もしカスタムDockerレジストリを使っている場合は、openshift_web_console_prefixとtemplate_service_broker_prefixという設定にレジストリのアドレスを指定します。

3. 次に、すべてのノードでスワップメモリを無効にします。

4. すべてのホストを再起動し、再起動後にアップグレードが正しく行われたか確認します。

5. 必要に応じて、インベントリファイルのノードセレクターを確認します。

6. 各マスターおよびノードホストで、3.7リポジトリを無効にし、3.8および3.9リポジトリを有効にします。

7. 適切なAnsible Playbookを使って、アップグレードを1フェーズまたは複数フェーズで実行します。

8. 最後に、インベントリファイルにopenshift_deployment_type=openshift-enterpriseを設定します。

1. 各マスターおよびノードホストで、3.7リポジトリを無効にし、3.8および3.9リポジトリを有効にします。

2. まず、Red Hat Enterprise Linux 7の各システムに最新のatomic-openshift-utilsパッケージがインストールされていることを確認します。

3. 必要に応じて、インベントリファイルのノードセレクターを確認します。

4. 次に、すべてのノードでスワップメモリを無効にします。

5. インベントリファイルにopenshift_deployment_type=openshift-enterpriseを設定します。

6. もしカスタムDockerレジストリを使っている場合は、openshift_web_console_prefixとtemplate_service_broker_prefixという設定にレジストリのアドレスを指定します。

7. 適切なAnsible Playbookを使用して、アップグレードを1フェーズまたは複数フェーズで実行します。

8. すべてのホストを再起動し、再起動後にアップグレードを確認します。