第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.
```

第5章 OpenShift のダウングレード

5.1. 概要

5.2. バックアップの確認

5.3. クラスターのシャットダウン

5.4. RPM と静的 Pod の削除

5.5. Docker のダウングレード

5.6. RPM の再インストール

5.7. etcd の復元

5.7.1. etcd v3 スナップショットの復元

手順

5.7.2. 復元後の etcd ノードの追加

手順

5.8. OpenShift Container Platform サービスの再オンライン化

手順

5.9. ダウングレードの検証

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links