RHSM から最新のサブスクリプションデータをプルします。

# subscription-manager refresh

OpenShift Container Platform 3.9 から 3.10 にアップグレードする場合には、以下を行います。

(初期インストールまたは最近のクラスターのアップグレードなどで) Ansible Playbook を最後に実行した後にマスターまたはノード設定ファイルに設定変更を手動で加えた場合は、「Ansible インベントリーファイルの設定」を参照してください。手動で加えた変更に関連する変数については、アップグレードの実行前に同等の変更をインベントリーファイルに適用してください。これを実行しないと、手動による変更がアップグレード時にデフォルト値で上書きされ、Pod が適切に実行されなくなるか、または他のクラスターの安定性に問題が生じる可能性があります。

とくに、マスター設定ファイルの admissionConfig 設定に変更を加えた場合は、「Ansible インベントリーファイルの設定」で openshift_master_admission_plugin_config 変数を確認してください。これを確認しない場合、ClusterResourceOverride 設定を事前に手動で設定している場合には (「マスターでのオーバーコミットの設定」など)、Pod が Pending 状態のままになる可能性があります。

この時点で、アップグレードを単一フェーズで実行するか、または複数フェーズで実行するかを選択できます。各フェーズでアップグレードされるコンポーネントについての詳細は、「コントールプレーンとノードの別フェーズでのアップグレード」を参照してください。

インベントリーファイルがデフォルトの /etc/ansible/hosts 以外の場所に置かれている場合、-i フラグを追加してその場所を指定します。以前に atomic-openshift-installer コマンドを使用してインストールを実行したことがある場合は、必要に応じて ~/.config/openshift/hosts で最後に使用されたインベントリーファイルを確認できます。

すべてのマスターおよびノードのアップグレードの完了後に、すべてのホストを再起動します。再起動後に追加の機能が有効化されていない場合は、「アップグレードの検証」を実行できます。追加機能が有効化されている場合には、次の手順は以前に有効にした追加機能の内容によって変わります。

これをまだ実行していない場合は、「コンテナーログの集計」のトピックの「ロギング Ansible 変数の指定」を参照し、Ansible インベントリーファイルを更新して少なくとも [OSEv3:vars] セクション内に以下の必要な変数を設定します。

[OSEv3:vars]

openshift_logging_install_logging=true 1

これをまだ実行していない場合は、「クラスターメトリクスの有効化」のトピックの「メトリクス Ansible 変数の指定」を参照し、Ansible インベントリーファイルを更新して少なくとも [OSEv3:vars] セクション内で以下の必要な変数を設定します。

[OSEv3:vars]

openshift_metrics_install_metrics=true 1
openshift_metrics_hawkular_hostname=<fqdn> 2
openshift_metrics_cassandra_storage_type=(emptydir|pv|dynamic) 3

標準 infra ノード (ルーター、レジストリー、ロギング、およびメトリクス) をアップグレードします。

アプリケーションコンテナーを実行する標準ノードをアップグレードします。

GlusterFS を実行する OpenShift Container Platform ノードを一度に 1 つずつアップグレードします。

すべてのノードに Ready のマークが付けられていることを確認します。

# oc get nodes
NAME                     STATUS    ROLES        AGE       VERSION
master1.example.com      Ready     master       47d       v1.10.0+b81c8f8
master2.example.com      Ready     master       47d       v1.10.0+b81c8f8
master3.example.com      Ready     master       47d       v1.10.0+b81c8f8
infra-node1.example.com  Ready     infra        47d       v1.10.0+b81c8f8
infra-node2.example.com  Ready     infra        47d       v1.10.0+b81c8f8
node1.example.com        Ready     compute      47d       v1.10.0+b81c8f8
node2.example.com        Ready     compute      47d       v1.10.0+b81c8f8

コントロールプレーンの静的 Pod が実行されていることを確認します。

# oc get pods -n kube-system
NAME                                 READY     STATUS    RESTARTS   AGE
master-api-master1.example.com           1/1       Running   4          1h
master-controllers-master1.example.com   1/1       Running   3          1h
master-etcd-master1.example.com          1/1       Running   6          5d
[...]

必要なバージョンの docker-registry および router イメージを実行していることを確認します (デプロイされている場合)。

# oc get -n default dc/docker-registry -o json | grep \"image\"
    "image": "openshift3/ose-docker-registry:v3.10",
# oc get -n default dc/router -o json | grep \"image\"
    "image": "openshift3/ose-haproxy-router:v3.10",

マスター上で診断ツールを使用し、一般的な問題を検索します。

# oc adm diagnostics
...
[Note] Summary of diagnostics execution:
[Note] Completed with no errors or warnings seen.

Green ノードをスケジュール対象 (Schedulable) に設定し、新規 Pod がそれらのノードにのみ到達するようにします。

$ oc adm manage-node --schedulable=true --selector=color=green

Blue ノードを無効にし、それらをスケジュール対象外 (Unschedulable) に設定して新規 Pod がそれらのノードで実行されないようにします。

$ oc adm manage-node --schedulable=false --selector=color=blue

node-role.kubernetes.io/infra=true ラベルを使用するように、レジストリーのノードセレクターとルーターデプロイメント設定を更新します。これにより、新規の Pod が新しいインフラストラクチャーノードに配置されるように、新しいデプロイメントがトリガーされます。

クラスター内のすべての namespace (プロジェクト) でのビルドプロセスをモニターするには、以下を実行します。

$ oc get events -w --all-namespaces

大規模な環境では、ビルドはほとんど停止することがありません。しかしながら、管理上のイメージのインポートによって大きな増減が生じます。

以下のコマンドで、Blue ノードをすべて退避して削除します。

$ oc adm manage-node --selector=color=blue --evacuate
$ oc delete node --selector=color=blue

メンテナンスの準備のためにノードをドレイン (解放) します。

$ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets

ホストパッケージを更新し、ホストを再起動します。再起動により、ホストが最新バージョンを実行していることを確認できます。つまり、docker および OpenShift Container Platform プロセスが再起動されていることになり、これにより他のサービスのすべてのサービスが正しいことを確認するチェックが強制的に実行されます。

ただし、ノードホストを再起動する代わりに、影響を受けるサービスを再起動するか、または iptables 状態を保持することができます。どちらのプロセスについても、「OpenShift Container Platform iptables」のトピックで説明されています。ovs フロールールは保存される必要はありませんが、OpenShift Container Platform ノードソフトウェアを再起動するとフロールールが固定されます。

ホストを再びスケジュール対象 (Schedulable) に設定するには、以下を実行します。

$ oc adm uncordon <node_name>

「アップグレードプロセス」で使用される Ansible playbook により、master-config.yaml ファイルのバックアップが作成されているはずです。このファイルと scheduler.json ファイルがマスターに存在しているようにしてください。

/etc/origin/master/master-config.yaml.<timestamp>
/etc/origin/master/scheduler.json

「自動アップグレードの準備」の手順では、OpenShift Container Platform 3.9 から 3.10 にアップグレードする前に、以下のファイルをバックアップするように指示されています。これらのファイルが利用できることを確認してください。

マスターホスト:

/usr/lib/systemd/system/atomic-openshift-master-api.service
/usr/lib/systemd/system/atomic-openshift-master-controllers.service
/etc/sysconfig/atomic-openshift-master-api
/etc/sysconfig/atomic-openshift-master-controllers

ノードとマスターホスト:

/usr/lib/systemd/system/atomic-openshift-*.service
/etc/origin/node/node-config.yaml

etcd ホスト (etcd が共存するマスターを含む):

/etc/etcd/etcd.conf
/backup/etcd-xxxxxx/backup.db

すべてのマスターおよびノードホストで、以下を実行します。

# systemctl stop atomic-openshift-node

すべてのマスター、ノードおよび etcd メンバー (専用 etcd クラスターを使用している場合) で、以下のパッケージを削除します。

# yum remove atomic-openshift \
    atomic-openshift-clients \
    atomic-openshift-node \
    atomic-openshift-master \
    atomic-openshift-sdn-ovs \
    atomic-openshift-excluder \
    atomic-openshift-docker-excluder \
    atomic-openshift-hyperkube

パッケージが正常に削除されたことを確認します。

# rpm -qa | grep atomic-openshift

コントロールプレーンホスト (マスターおよび etcd ホスト) で静的な pod 定義を移動しましす。

# mkdir /etc/origin/node/pods-backup
# mv /etc/origin/node/pods/* /etc/origin/node/pods-backup/

各ホストを再起動します。

# systemctl reboot

OpenShift Container Platform 3.10 のリポジトリーを無効にし、3.9 のリポジトリーを再び有効にします。

# subscription-manager repos \
    --disable=rhel-7-server-ose-3.10-rpms \
    --enable=rhel-7-server-ose-3.9-rpms

各マスターで、以下のパッケージをインストールします。

# yum install atomic-openshift \
    atomic-openshift-clients \
    atomic-openshift-node \
    atomic-openshift-master \
    openvswitch \
    atomic-openshift-sdn-ovs \
    tuned-profiles-atomic-openshift-node \
    atomic-openshift-excluder \
    atomic-openshift-docker-excluder

各ノードで、以下のパッケージをインストールします。

# yum install atomic-openshift \
    atomic-openshift-node \
    openvswitch \
    atomic-openshift-sdn-ovs \
    tuned-profiles-atomic-openshift-node \
    atomic-openshift-excluder \
    atomic-openshift-docker-excluder

各ホストでパッケージが正常にインストールされたことを確認します。

# rpm -qa | grep atomic-openshift
# rpm -q openvswitch

それぞれの OpenShift Container Platform マスターで、バックアップからマスターおよびノード設定を復元し、すべての関連するサービスを有効にしてから再起動します。

# cp ${MYBACKUPDIR}/etc/sysconfig/atomic-openshift-master-api /etc/sysconfig/atomic-openshift-master-api
# cp ${MYBACKUPDIR}/etc/sysconfig/atomic-openshift-master-controllers /etc/sysconfig/atomic-openshift-master-controllers
# cp ${MYBACKUPDIR}/etc/origin/master/master-config.yaml.<timestamp> /etc/origin/master/master-config.yaml
# cp ${MYBACKUPDIR}/etc/origin/node/node-config.yaml.<timestamp> /etc/origin/node/node-config.yaml
# cp ${MYBACKUPDIR}/etc/origin/master/scheduler.json.<timestamp> /etc/origin/master/scheduler.json
# cp ${MYBACKUPDIR}/usr/lib/systemd/system/atomic-openshift-master-api.service /usr/lib/systemd/system/atomic-openshift-master-api.service
# cp ${MYBACKUPDIR}/usr/lib/systemd/system/atomic-openshift-master-controllers.service /usr/lib/systemd/system/atomic-openshift-master-controllers.service
# rm /etc/systemd/system/atomic-openshift-node.service
# systemctl daemon-reload
# systemctl enable atomic-openshift-master-api
# systemctl enable atomic-openshift-master-controllers
# systemctl enable atomic-openshift-node
# systemctl start atomic-openshift-master-api
# systemctl start atomic-openshift-master-controllers
# systemctl start atomic-openshift-node

各 OpenShift Container Platform ノードで、必要に応じて「ノードの設定マップ」を更新し、atomic-openshift-node サービスを有効化して再起動します。

# cp /etc/origin/node/node-config.yaml.<timestamp> /etc/origin/node/node-config.yaml
# rm /etc/systemd/system/atomic-openshift-node.service
# systemctl daemon-reload
# systemctl enable atomic-openshift-node
# systemctl start atomic-openshift-node

ダウングレードを検証するには、すべてのノードに Ready のマークが付けられていることを確認します。

# oc get nodes
NAME                        STATUS                     AGE
master.example.com          Ready,SchedulingDisabled   165d
node1.example.com           Ready                      165d
node2.example.com           Ready                      165d

デプロイされている場合には、レジストリーおよびルーターが正常にダウングレードされたことを確認します。

「診断ツール」をマスターで使用し、共通の問題を検索し、提案される方法を確認します。

# oc adm diagnostics
...
[Note] Summary of diagnostics execution:
[Note] Completed with no errors or warnings seen.