第2章 クラスターの自動インプレースアップグレードの実行

通常インストール (advanced installation) を使用してインストールしていて、使用したインベントリーファイルが利用可能である場合、アップグレード Playbook を使用して OpenShift クラスターのアップグレードプロセスを自動化できます。

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 へのアップグレードが正常に終了するまでの期間になります。

3.7 から 3.9 へのコントロールプレーンの自動アップグレードでは、以下の手順が実行されます。

3.7 から 3.9 へのノードの自動アップグレードではノードのローリングアップデートを実行します。以下が実行されます。

自動化されたアップグレード Playbook は、インベントリーファイルと共に ansible-playbook コマンドを使用して Ansible で直接実行されます。これは通常インストール (advanced installation) 方式と同様です。以下のいずれのシナリオでも、同じ v3_9 アップグレード Playbook を使用することができます。

自動アップグレードを準備するには、以下を実行します。

上記を確認した後に、以下のセクションでアップグレードプロセスのしくみをさらに確認し、カスタマイズする場合はアップグレードの追加のカスタマイズオプションについて決定します。アップグレードを実行する準備が整ったら、最新の OpenShift Container Platform 3.9 リリースへのアップグレードに進んでください。

$ ansible-playbook -i <path/to/inventory/file> \
    </path/to/upgrade/playbook> \
    -e openshift_upgrade_nodes_serial="20%"

$ ansible-playbook -i <path/to/inventory/file> \
    </path/to/upgrade/playbook> \
    -e openshift_upgrade_nodes_serial="2" \
    -e openshift_upgrade_nodes_label="region=group1"

$ ansible-playbook -i <path/to/inventory/file> \
    </path/to/upgrade/playbook> \
    -e openshift_upgrade_nodes_serial=10 \
    -e openshift_upgrade_nodes_max_fail_percentage=20 \
    -e openshift_upgrade_nodes_drain_timeout=600

[OSEv3:vars]
openshift_master_upgrade_pre_hook=/usr/share/custom/pre_master.yml
openshift_master_upgrade_hook=/usr/share/custom/master.yml
openshift_master_upgrade_post_hook=/usr/share/custom/post_master.yml

---
# Trivial example forcing an operator to ack the start of an upgrade
# file=/usr/share/custom/pre_master.yml

- name: note the start of a master upgrade
  debug:
      msg: "Master upgrade of {{ inventory_hostname }} is about to start"

- name: require an operator agree to start an upgrade
  pause:
      prompt: "Hit enter to start the master upgrade"

既存の OpenShift Container Platform 3.7 または 3.9 クラスターを最新の 3.9 リリースにアップグレードするには、以下を実行します。

既存の EFK ロギングスタックデプロイメントをアップグレードするには、提供されている /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml Ansible Playbook を使用する必要があります。これは既存のクラスターでロギングを最初にデプロイする際に使用する Playbook ですが、既存のロギングデプロイメントをアップグレードする場合にも使用されます。

        image: <image_name>:<vX.Y>
        imagePullPolicy: IfNotPresent

既存のクラスターメトリクスのデプロイメントをアップグレードするには、提供されている /usr/share/ansible/openshift-ansible/playbooks/openshift-metrics/config.yml Ansible Playbook を使用する必要があります。これは、既存クラスターでメトリクスを最初にデプロイしている場合に使用する Playbook ですが、既存のメトリクスデプロイメントをアップグレードする場合にも使用されます。

混在環境のアップグレード (Red Hat Enterprise Linux および Red Hat Enterprise Linux Atomic Host を含む環境など) では、openshift_pkg_version および openshift_image_tag の両方を設定する必要があります。混在環境では、openshift_pkg_version のみを指定する場合、その番号が Red Hat Enterprise Linux および Red Hat Enterprise Linux Atomic Host のイメージに使用されます。

OpenShift Container Platform のアップグレード時に、GlusterFS Pod が実行されているノードのセットをアップグレードする必要があります。

drain および unschedule は daemonset の一部として実行されているために GlusterFS Pod を停止せず、退避しません。そのため、これらのノードをアップグレードする際には特別な考慮が必要になります。

また、複数のノードでアップグレードを同時に実行される可能性もあり、これにより複数のノードが GlusterFS Pod をホストしている場合にデータ可用性の問題が生じる可能性があります。

シリアルアップグレードが実行されている場合でも、次のノードの GlusterFS が終了する前に GlusterFS が自動修復操作のすべてを完了するのに必要な時間が確保される保証はありません。そのため、クラスターの状態が正常でなくなるか、または不明な状態になる可能性があります。したがって、以下の手順を実行することをお勧めします。

デフォルトの gcePD ストレージプロバイダーは RWO (Read-Write Only) アクセスモードを使用するため、レジストリーでローリングアップグレードを実行したり、レジストリーを複数 Pod に拡張したりすることはできません。そのため、OpenShift Container Platform のアップグレード時に以下の環境変数を Ansible インベントリーファイルに指定する必要があります。

[OSEv3:vars]

openshift_hosted_registry_storage_provider=gcs
openshift_hosted_registry_storage_gcs_bucket=bucket01
openshift_hosted_registry_storage_gcs_keyfile=test.key
openshift_hosted_registry_storage_gcs_rootdirectory=/registry

以下を確認します。