検索

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

download PDF

5.1. 概要

OpenShift Container Platform の「アップグレード」後に、極端なケースではあるものの、クラスターを以前のバージョンにダウングレードする必要がある場合があります。以下のセクションでは、OpenShift Container Platform 3.10 から 3.9 へのダウングレードパスなどの、クラスターの各システムでダウングレードを実行するために必要な手順について説明します。

重要

現時点で、これらの手順は OpenShift Container Platform の「RPM ベースのインストール」でのみサポートされており、クラスター全体でダウンタイムが生じることが前提とされています。

5.2. バックアップの確認

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

    /etc/origin/master/master-config.yaml.<timestamp>
    /etc/origin/master/scheduler.json
  2. 「自動アップグレードの準備」の手順では、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. クラスターのシャットダウン

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

    # systemctl stop atomic-openshift-node

5.4. RPM と静的 Pod の削除

*-excluder パッケージは、インストール時に、エントリーをホストの /etc/yum.conf ファイルの exclude ディレクティブに追加します。

  1. すべてのマスター、ノードおよび 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
  2. パッケージが正常に削除されたことを確認します。

    # rpm -qa | grep atomic-openshift
  3. コントロールプレーンホスト (マスターおよび etcd ホスト) で静的な pod 定義を移動しましす。

    # mkdir /etc/origin/node/pods-backup
    # mv /etc/origin/node/pods/* /etc/origin/node/pods-backup/
  4. 各ホストを再起動します。

    # systemctl reboot

5.5. Docker のダウングレード

OpenShift Container Platform 3.9 も 3.10 も Docker 1.13 が必要ですので、Docker をダウングレードする必要はありません。

5.6. RPM の再インストール

  1. 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
  2. 各マスターで、以下のパッケージをインストールします。

    # 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
  3. 各ノードで、以下のパッケージをインストールします。

    # yum install atomic-openshift \
        atomic-openshift-node \
        openvswitch \
        atomic-openshift-sdn-ovs \
        tuned-profiles-atomic-openshift-node \
        atomic-openshift-excluder \
        atomic-openshift-docker-excluder
  4. 各ホストでパッケージが正常にインストールされたことを確認します。

    # 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 ホストで実行される必要があります。その後に残りのノードをクラスターに追加することができます。

手順
  1. etcd サービスのマスク解除

    # systemctl unmask etcd
  2. すべての etcd サービスを停止します。

    # systemctl stop etcd.service
  3. 古いデータについては、etcdctl が復元手順が実行されるノードでその再作成を実行するため、それらすべてをクリアします。

    # rm -Rf /var/lib/etcd
  4. 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
  5. パーミッションおよび selinux コンテキストを復元ファイルに復元します。

    # chown -R etcd.etcd /var/lib/etcd/
    # restorecon -Rv /var/lib/etcd
  6. etcd サービスを起動します。

    # systemctl start etcd
  7. エラーメッセージの有無を確認します。

    # journalctl -fu etcd.service

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

最初のインスタンスを実行後に、複数の etcd サーバーをクラスターに追加できます。

手順
  1. ETCD_NAME 変数でインスタンスの etcd 名を取得します。

    # grep ETCD_NAME /etc/etcd/etcd.conf
  2. etcd がピア通信をリッスンする IP アドレスを取得します。

    # grep ETCD_INITIAL_ADVERTISE_PEER_URLS /etc/etcd/etcd.conf
  3. ノードが以前のバージョンで etcd クラスターに含まれていた場合には、以前の etcd データを削除します。

    # rm -Rf /var/lib/etcd/*
  4. 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"
  5. 新しいホストの /etc/etcd/etcd.conf ファイルに、以前のコマンドからの値を追加します。

    # vi /etc/etcd/etcd.conf
  6. クラスターに参加するノードで etcd サービスを起動します。

    # systemctl start etcd.service
  7. エラーメッセージの有無を確認します。

    # journalctl -fu etcd.service
  8. すべての etcd ノードが追加されるまで、以前の手順を繰り返します。
  9. 全ノードを追加したら、クラスターのステータスと、健全性を確認します。

    # 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 をオンラインに戻します。

手順

  1. それぞれの 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
  2. 各 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. ダウングレードの検証

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

    # oc get nodes
    NAME                        STATUS                     AGE
    master.example.com          Ready,SchedulingDisabled   165d
    node1.example.com           Ready                      165d
    node2.example.com           Ready                      165d
  2. デプロイされている場合には、レジストリーおよびルーターが正常にダウングレードされたことを確認します。

    1. v3.9 バージョンの docker-registryrouter のイメージを実行していることを確認します。

      # 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",
    2. docker-registryrouter 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
  3. 「診断ツール」をマスターで使用し、共通の問題を検索し、提案される方法を確認します。

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

詳細情報

試用、購入および販売

コミュニティー

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.