第5章 OpenShift のダウングレード
5.1. 概要
OpenShift Container Platform の「アップグレード」後に、極端なケースではあるものの、クラスターを以前のバージョンにダウングレードする必要がある場合があります。以下のセクションでは、OpenShift Container Platform 3.10 から 3.9 へのダウングレードパスなどの、クラスターの各システムでダウングレードを実行するために必要な手順について説明します。
現時点で、これらの手順は OpenShift Container Platform の「RPM ベースのインストール」でのみサポートされており、クラスター全体でダウンタイムが生じることが前提とされています。
5.2. バックアップの確認
「アップグレードプロセス」で使用される 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
5.3. クラスターのシャットダウン
すべてのマスターおよびノードホストで、以下を実行します。
# systemctl stop atomic-openshift-node
5.4. RPM と静的 Pod の削除
*-excluder パッケージは、インストール時に、エントリーをホストの /etc/yum.conf ファイルの exclude ディレクティブに追加します。
すべてのマスター、ノードおよび 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
5.5. Docker のダウングレード
OpenShift Container Platform 3.9 も 3.10 も Docker 1.13 が必要ですので、Docker をダウングレードする必要はありません。
5.6. RPM の再インストール
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
5.7. etcd の復元
etcd 設定ファイルの復元手順では、適切なファイルを置き換えてからサービスを再起動します。
etcd ホストが破損し、/etc/etcd/etcd.conf
ファイルが失われる場合は、以下を使用してこれを復元します。
$ ssh master-0 # cp /backup/yesterday/master-0-files/etcd.conf /etc/etcd/etcd.conf # restorecon -Rv /etc/etcd/etcd.conf
この例では、バックアップファイルは /backup/yesterday/master-0-files/etcd.conf
パスに保存されます。ここでは外部 NFS 共有、S3 バケットまたは他のストレージソリューションとして使用できます。
5.7.1. etcd v3 スナップショットの復元
スナップショットの整合性については、復元時にオプションで検証できます。スナップショットが etcdctl snapshot save
を使用して取得される場合、これには etcdctl snapshot restore
でチェックされる整合性ハッシュが含まれます。スナップショットがデータディレクトリーからコピーされる場合には整合性ハッシュはなく、復元は --skip-hash-check
を使用して実行されます。
v3 データのみを復元する手順は単一 etcd ホストで実行される必要があります。その後に残りのノードをクラスターに追加することができます。
手順
etcd サービスのマスク解除
# systemctl unmask etcd
すべての etcd サービスを停止します。
# systemctl stop etcd.service
古いデータについては、
etcdctl
が復元手順が実行されるノードでその再作成を実行するため、それらすべてをクリアします。# rm -Rf /var/lib/etcd
snapshot restore
コマンドを実行し、/etc/etcd/etcd.conf
ファイルの値を置き換えます。# etcdctl3 snapshot restore /backup/etcd-xxxxxx/backup.db \ --data-dir /var/lib/etcd \ --name master-0.example.com \ --initial-cluster "master-0.example.com=https://192.168.55.8:2380" \ --initial-cluster-token "etcd-cluster-1" \ --initial-advertise-peer-urls https://192.168.55.8:2380 \ --skip-hash-check=true 2017-10-03 08:55:32.440779 I | mvcc: restore compact to 1041269 2017-10-03 08:55:32.468244 I | etcdserver/membership: added member 40bef1f6c79b3163 [https://192.168.55.8:2380] to cluster 26841ebcf610583c
パーミッションおよび
selinux
コンテキストを復元ファイルに復元します。# chown -R etcd.etcd /var/lib/etcd/ # restorecon -Rv /var/lib/etcd
etcd サービスを起動します。
# systemctl start etcd
エラーメッセージの有無を確認します。
# journalctl -fu etcd.service
5.7.2. 復元後の etcd ノードの追加
最初のインスタンスを実行後に、複数の etcd サーバーをクラスターに追加できます。
手順
ETCD_NAME
変数でインスタンスの etcd 名を取得します。# grep ETCD_NAME /etc/etcd/etcd.conf
etcd がピア通信をリッスンする IP アドレスを取得します。
# grep ETCD_INITIAL_ADVERTISE_PEER_URLS /etc/etcd/etcd.conf
ノードが以前のバージョンで etcd クラスターに含まれていた場合には、以前の etcd データを削除します。
# rm -Rf /var/lib/etcd/*
etcd が正しく実行されている etcd ホストで、新しいメンバーを追加します。
# etcdctl3 member add *<name>* \ --peer-urls="*<advertise_peer_urls>*"
このコマンドでは、以下のような変数が出力されます。
ETCD_NAME="master2" ETCD_INITIAL_CLUSTER="master-0.example.com=https://192.168.55.8:2380" ETCD_INITIAL_CLUSTER_STATE="existing"
新しいホストの
/etc/etcd/etcd.conf
ファイルに、以前のコマンドからの値を追加します。# vi /etc/etcd/etcd.conf
クラスターに参加するノードで etcd サービスを起動します。
# systemctl start etcd.service
エラーメッセージの有無を確認します。
# journalctl -fu etcd.service
- すべての etcd ノードが追加されるまで、以前の手順を繰り返します。
全ノードを追加したら、クラスターのステータスと、健全性を確認します。
# etcdctl3 endpoint health --endpoints="https://<etcd_host1>:2379,https://<etcd_host2>:2379,https://<etcd_host3>:2379" https://master-0.example.com:2379 is healthy: successfully committed proposal: took = 1.423459ms https://master-1.example.com:2379 is healthy: successfully committed proposal: took = 1.767481ms https://master-2.example.com:2379 is healthy: successfully committed proposal: took = 1.599694ms # etcdctl3 endpoint status --endpoints="https://<etcd_host1>:2379,https://<etcd_host2>:2379,https://<etcd_host3>:2379" https://master-0.example.com:2379, 40bef1f6c79b3163, 3.2.5, 28 MB, true, 9, 2878 https://master-1.example.com:2379, 1ea57201a3ff620a, 3.2.5, 28 MB, false, 9, 2878 https://master-2.example.com:2379, 59229711e4bc65c8, 3.2.5, 28 MB, false, 9, 2878
5.8. OpenShift Container Platform サービスの再オンライン化
変更を終了した後に、OpenShift Container Platform をオンラインに戻します。
手順
それぞれの 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
5.9. ダウングレードの検証
ダウングレードを検証するには、すべてのノードに Ready のマークが付けられていることを確認します。
# oc get nodes NAME STATUS AGE master.example.com Ready,SchedulingDisabled 165d node1.example.com Ready 165d node2.example.com Ready 165d
デプロイされている場合には、レジストリーおよびルーターが正常にダウングレードされたことを確認します。
v3.9
バージョンの docker-registry と router のイメージを実行していることを確認します。# oc get -n default dc/docker-registry -o json | grep \"image\" "image": "openshift3/ose-docker-registry:v3.9", # oc get -n default dc/router -o json | grep \"image\" "image": "openshift3/ose-haproxy-router:v3.9",
docker-registry と router pod が実行中で、Ready の状態であることを確認します。
# oc get pods -n default NAME READY STATUS RESTARTS AGE docker-registry-2-b7xbn 1/1 Running 0 18m router-2-mvq6p 1/1 Running 0 6m
「診断ツール」をマスターで使用し、共通の問題を検索し、提案される方法を確認します。
# oc adm diagnostics ... [Note] Summary of diagnostics execution: [Note] Completed with no errors or warnings seen.