Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

クラスターの更新

OpenShift Container Platform 4.1

OpenShift Container Platform 4.1 クラスターの更新

Red Hat OpenShift Documentation Team

概要

本書では、OpenShift Container Platform 4.1 クラスターを更新し、アップグレードする方法を説明します。バージョン 4.1 では、クラスターの更新を、クラスターをオフラインにする必要のない単純なプロセスで実行できます。

第1章 Web コンソールからのマイナーバージョン内でのクラスターの更新

Web コンソールを使用して OpenShift Container Platform クラスターをマイナーバージョンに更新するか、またはアップグレードすることができます。

前提条件

1.1. OpenShift Container Platform の更新サービスについて

OpenShift Container Platform の更新サービスとは、OpenShift Container Platform と Red Hat Enterprise Linux CoreOS (RHCOS) の両方に OTA(over-the-air) 更新を提供するホスト型サービスです。コンポーネント Operator のグラフ、または頂点とそれらを結ぶを含む図表が提示されます。グラフの辺は、どのバージョンであれば安全に更新できるかを示します。 頂点は、管理されたクラスターコンポーネントの想定された状態を特定する更新のペイロードです。

クラスター内の Cluster Version Operator (CVO) は、OpenShift Container Platform の更新サービスをチェックして、グラフの現在のコンポーネントバージョンとグラフの情報に基づき、有効な更新および更新パスを確認します。ユーザーが更新をリクエストすると、OpenShift Container Platform CVO はその更新のリリースイメージを使ってクラスターをアップグレードします。リリースアーティファクトは、コンテナーイメージとして Quay でホストされます。

OpenShift Container Platform 更新サービスが互換性のある更新のみを提供できるようにするために、自動化を支援するリリース検証 Pipeline が使用されます。それぞれのリリースアーティファクトについて、他のコンポーネントパッケージだけでなくサポートされているクラウドプラットフォームおよびシステムアーキテクチャーとの互換性の有無が検証されます。Pipeline がリリースの適合性を確認した後に、OpenShift Container Platform 更新サービスは更新が利用可能であることを通知します。

連続更新モードでは、2 つのコントローラーが実行されます。1 つのコントローラーはペイロードマニフェストを絶えず更新し、それらをクラスターに適用し、Operator が利用可能か、アップグレード中か、または失敗しているかに応じて Operator の制御されたロールアウトのステータスを出力します。2 つ目のコントローラーは OpenShift Container Platform 更新サービスをポーリングして、更新が利用可能かどうかを判別します。

重要

クラスターを以前のバージョンに戻すこと、つまりロールバックはサポートされていません。サポートされているのは、新規バージョンへのアップグレードのみです。

1.2. Web コンソールを使用したクラスターの更新

更新が利用可能な場合、Web コンソールからクラスターを更新できます。

利用可能な OpenShift Container Platform アドバイザリーおよび更新については、カスタマーポータルの エラータのセクションを参照してください。

前提条件

  • admin 権限を持つユーザーとして Web コンソールにアクセスできること。

手順

  1. Web コンソールから、Administration > Cluster Settings をクリックし、 Overview タブの内容を確認します。

    1. 実稼働クラスターの場合、CHANNELstable-4.1 に設定されていることを確認します。

      重要

      実稼働クラスターの場合、stable-4.1 チャネルにサブスクライブにサブスクライブする必要があります。

    2. UPDATE STATUSUpdates Available ではない場合、クラスターをアップグレードすることはできません。
    3. DESIRED VERSION は、クラスターが実行されているか、または更新されるクラスターのバージョンを示します。
  2. Updates Available をクリックし、更新先のバージョンを選択し、Update をクリックします。UPDATE STATUSUpdating に切り替わり、Cluster Operators タブで Operator のアップグレードの進捗を確認できます。

第2章 CLI の使用によるマイナーバージョン内でのクラスターの更新

OpenShift CLI (oc) を使用して、OpenShift Container Platform クラスターの更新またはアップグレードを実行できます。

前提条件

2.1. OpenShift Container Platform の更新サービスについて

OpenShift Container Platform の更新サービスとは、OpenShift Container Platform と Red Hat Enterprise Linux CoreOS (RHCOS) の両方に OTA(over-the-air) 更新を提供するホスト型サービスです。コンポーネント Operator のグラフ、または頂点とそれらを結ぶを含む図表が提示されます。グラフの辺は、どのバージョンであれば安全に更新できるかを示します。 頂点は、管理されたクラスターコンポーネントの想定された状態を特定する更新のペイロードです。

クラスター内の Cluster Version Operator (CVO) は、OpenShift Container Platform の更新サービスをチェックして、グラフの現在のコンポーネントバージョンとグラフの情報に基づき、有効な更新および更新パスを確認します。ユーザーが更新をリクエストすると、OpenShift Container Platform CVO はその更新のリリースイメージを使ってクラスターをアップグレードします。リリースアーティファクトは、コンテナーイメージとして Quay でホストされます。

OpenShift Container Platform 更新サービスが互換性のある更新のみを提供できるようにするために、自動化を支援するリリース検証 Pipeline が使用されます。それぞれのリリースアーティファクトについて、他のコンポーネントパッケージだけでなくサポートされているクラウドプラットフォームおよびシステムアーキテクチャーとの互換性の有無が検証されます。Pipeline がリリースの適合性を確認した後に、OpenShift Container Platform 更新サービスは更新が利用可能であることを通知します。

連続更新モードでは、2 つのコントローラーが実行されます。1 つのコントローラーはペイロードマニフェストを絶えず更新し、それらをクラスターに適用し、Operator が利用可能か、アップグレード中か、または失敗しているかに応じて Operator の制御されたロールアウトのステータスを出力します。2 つ目のコントローラーは OpenShift Container Platform 更新サービスをポーリングして、更新が利用可能かどうかを判別します。

重要

クラスターを以前のバージョンに戻すこと、つまりロールバックはサポートされていません。サポートされているのは、新規バージョンへのアップグレードのみです。

2.2. CLI を使用したクラスターの更新

更新が利用可能な場合、OpenShift CLI (oc) を使用してクラスターを更新できます。

利用可能な OpenShift Container Platform アドバイザリーおよび更新については、カスタマーポータルの エラータのセクションを参照してください。

前提条件

  • お使いの更新バージョンのバージョンに一致する OpenShift Command-line Interface (CLI) (oc として一般に知られる) のバージョンをインストールします。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインします。
  • jq パッケージをインストールします。

手順

  1. クラスターが利用可能であることを確認します。

    $ oc get clusterversion
    
    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
    version   4.1.0     True        False         158m    Cluster version is 4.1.0
  2. 現在の更新チャネル情報を確認し、チャネルが stable-4.1 に設定されていることを確認します。

    $ oc get clusterversion -o json|jq ".items[0].spec"
    
    {
      "channel": "stable-4.1",
      "clusterID": "990f7ab8-109b-4c95-8480-2bd1deec55ff",
      "upstream": "https://api.openshift.com/api/upgrades_info/v1/graph"
    }
    重要

    実稼働クラスターの場合、stable-4.1 チャネルにサブスクライブにサブスクライブする必要があります。

  3. 利用可能な更新を確認し、適用する必要のある更新のバージョン番号をメモします。

    $ oc adm upgrade
    
    Cluster version is 4.1.0
    
    Updates:
    
    VERSION IMAGE
    4.1.2   quay.io/openshift-release-dev/ocp-release@sha256:9c5f0df8b192a0d7b46cd5f6a4da2289c155fd5302dec7954f8f06c878160b8b
  4. 更新を適用します。

    • 最新バージョンに更新するには、以下を実行します。

      $ oc adm upgrade --to-latest=true 1
    • 特定のバージョンに更新するには、以下を実行します。

      $ oc adm upgrade --to=<version> 1
      1 1
      <version> は、直前のコマンドの出力から得られる更新バージョンです。
  5. クラスターバージョン Operator を確認します。

    $ oc get clusterversion -o json|jq ".items[0].spec"
    
    {
      "channel": "stable-4.1",
      "clusterID": "990f7ab8-109b-4c95-8480-2bd1deec55ff",
      "desiredUpdate": {
        "force": false,
        "image": "quay.io/openshift-release-dev/ocp-release@sha256:9c5f0df8b192a0d7b46cd5f6a4da2289c155fd5302dec7954f8f06c878160b8b",
        "version": "4.1.2" 1
      },
      "upstream": "https://api.openshift.com/api/upgrades_info/v1/graph"
    }
    1
    desiredUpdate スタンザの version 番号が指定した値と一致する場合、更新は進行中です。
  6. クラスターバージョン履歴で、更新のステータスをモニターします。すべてのオブジェクトの更新が終了するまでに時間がかかる可能性があります。

    $ oc get clusterversion -o json|jq ".items[0].status.history"
    
    [
      {
        "completionTime": null,
        "image": "quay.io/openshift-release-dev/ocp-release@sha256:9c5f0df8b192a0d7b46cd5f6a4da2289c155fd5302dec7954f8f06c878160b8b",
        "startedTime": "2019-06-19T20:30:50Z",
        "state": "Partial",
        "verified": true,
        "version": "4.1.2"
      },
      {
        "completionTime": "2019-06-19T20:30:50Z",
        "image": "quay.io/openshift-release-dev/ocp-release@sha256:b8307ac0f3ec4ac86c3f3b52846425205022da52c16f56ec31cbe428501001d6",
        "startedTime": "2019-06-19T17:38:10Z",
        "state": "Completed",
        "verified": false,
        "version": "4.1.0"
      }
    ]

    履歴には、クラスターに適用された最新バージョンの一覧が含まれます。この値は、CVO が更新を適用する際に更新されます。この一覧は日付順に表示され、最新の更新は一覧の先頭に表示されます。履歴の更新には、ロールアウトが完了した場合には Completed と表示され、更新が失敗したか、または完了しなかった場合には Partial と表示されます。

    重要

    アップグレードに失敗する場合、Operator は停止し、失敗しているコンポーネントのステータスを報告します。クラスターの以前のバージョンへのロールバックはサポートされていません。アップグレードできない場合は、Red Hat サポートにお問い合わせください。

  7. 更新が完了したら、クラスターのバージョンが新たなバージョンに更新されていることを確認できます。

    $ oc get clusterversion
    
    NAME      VERSION     AVAILABLE   PROGRESSING   SINCE     STATUS
    version   4.1.2       True        False         2m        Cluster version is 4.1.2

第3章 RHEL コンピュートマシンを含むクラスターの更新

OpenShift Container Platform クラスターの更新またはアップグレードを実行できます。クラスターに Red Hat Enterprise Linux (RHEL) マシンが含まれる場合は、それらのマシンを更新するために追加の手順を実行する必要があります。

前提条件

3.1. OpenShift Container Platform の更新サービスについて

OpenShift Container Platform の更新サービスとは、OpenShift Container Platform と Red Hat Enterprise Linux CoreOS (RHCOS) の両方に OTA(over-the-air) 更新を提供するホスト型サービスです。コンポーネント Operator のグラフ、または頂点とそれらを結ぶを含む図表が提示されます。グラフの辺は、どのバージョンであれば安全に更新できるかを示します。 頂点は、管理されたクラスターコンポーネントの想定された状態を特定する更新のペイロードです。

クラスター内の Cluster Version Operator (CVO) は、OpenShift Container Platform の更新サービスをチェックして、グラフの現在のコンポーネントバージョンとグラフの情報に基づき、有効な更新および更新パスを確認します。ユーザーが更新をリクエストすると、OpenShift Container Platform CVO はその更新のリリースイメージを使ってクラスターをアップグレードします。リリースアーティファクトは、コンテナーイメージとして Quay でホストされます。

OpenShift Container Platform 更新サービスが互換性のある更新のみを提供できるようにするために、自動化を支援するリリース検証 Pipeline が使用されます。それぞれのリリースアーティファクトについて、他のコンポーネントパッケージだけでなくサポートされているクラウドプラットフォームおよびシステムアーキテクチャーとの互換性の有無が検証されます。Pipeline がリリースの適合性を確認した後に、OpenShift Container Platform 更新サービスは更新が利用可能であることを通知します。

連続更新モードでは、2 つのコントローラーが実行されます。1 つのコントローラーはペイロードマニフェストを絶えず更新し、それらをクラスターに適用し、Operator が利用可能か、アップグレード中か、または失敗しているかに応じて Operator の制御されたロールアウトのステータスを出力します。2 つ目のコントローラーは OpenShift Container Platform 更新サービスをポーリングして、更新が利用可能かどうかを判別します。

重要

クラスターを以前のバージョンに戻すこと、つまりロールバックはサポートされていません。サポートされているのは、新規バージョンへのアップグレードのみです。

3.2. Web コンソールを使用したクラスターの更新

更新が利用可能な場合、Web コンソールからクラスターを更新できます。

利用可能な OpenShift Container Platform アドバイザリーおよび更新については、カスタマーポータルの エラータのセクションを参照してください。

前提条件

  • admin 権限を持つユーザーとして Web コンソールにアクセスできること。

手順

  1. Web コンソールから、Administration > Cluster Settings をクリックし、 Overview タブの内容を確認します。

    1. 実稼働クラスターの場合、CHANNELstable-4.1 に設定されていることを確認します。

      重要

      実稼働クラスターの場合、stable-4.1 チャネルにサブスクライブにサブスクライブする必要があります。

    2. UPDATE STATUSUpdates Available ではない場合、クラスターをアップグレードすることはできません。
    3. DESIRED VERSION は、クラスターが実行されているか、または更新されるクラスターのバージョンを示します。
  2. Updates Available をクリックし、更新先のバージョンを選択し、Update をクリックします。UPDATE STATUSUpdating に切り替わり、Cluster Operators タブで Operator のアップグレードの進捗を確認できます。

3.3. (オプション) RHEL マシンで Ansible タスクを実行するためのフックの追加

OpenShift Container Platform の更新時に フック を使用し、RHEL コンピュートマシンで Ansible タスクを実行できます。

3.3.1. アップグレード用の Ansible Hook について

OpenShift Container Platform の更新時に フック を使用し、特定操作の実行中に Red Hat Enterprise Linux (RHEL) ノードでカスタムタスクを実行できます。フックを使用して、特定の更新タスクの前後に実行するタスクを定義するファイルを指定できます。OpenShift Container Platform クラスターで RHEL コンピュートノードを更新する際に、フックを使用してカスタムインフラストラクチャーを検証したり、変更したりすることができます。

フックが失敗すると操作も失敗するため、フックはべき等性があるか、または複数回実行でき、同じ結果を出せるように設計する必要があります。

フックには以下のような重要な制限があります。まず、フックには定義された、 またはバージョン付けされたインターフェースがありません。フックは内部の openshift-ansible 変数を使用できますが、これらの変数は今後の OpenShift Container Platform のリリースで変更されるか、または削除される予定です。次に、フックにはエラー処理機能がないため、フックにエラーが生じると更新プロセスが中止されます。エラーの発生時には、まず問題に対応してからアップグレードを再び開始する必要があります。

3.3.2. Ansible インベントリーファイルでのフックを使用する設定

Red Hat Enterprise Linux (RHEL) コンピュートマシン (ワーカーマシンとしても知られている) の更新時に使用するフックを、all:vars セクションの下にある hosts インベントリーファイルで定義します。

前提条件

  • RHEL コンピュートマシンクラスターの追加に使用したマシンへのアクセスがあること。RHEL マシンを定義する hosts Ansible インベントリーファイルにアクセスできる必要があります。

手順

  1. フックの設計後に、フック用に Ansible タスクを定義する YAML ファイルを作成します。このファイルは、以下に示すように一連のタスクで構成される必要があり、Playbook にすることはできません。

    ---
    # Trivial example forcing an operator to acknowledge the start of an upgrade
    # file=/home/user/openshift-ansible/hooks/pre_compute.yml
    
    - name: note the start of a compute machine update
      debug:
          msg: "Compute machine upgrade of {{ inventory_hostname }} is about to start"
    
    - name: require the user agree to start an upgrade
      pause:
          prompt: "Press Enter to start the compute machine update"
  2. hosts Ansible インベントリーファイルを変更してフックファイルを指定します。フックファイルは、以下に示すように [all:vars] セクションのパラメーター値として指定されます。

    インベントリーファイルのフック定義の例

    [all:vars]
    openshift_node_pre_upgrade_hook=/home/user/openshift-ansible/hooks/pre_node.yml
    openshift_node_post_upgrade_hook=/home/user/openshift-ansible/hooks/post_node.yml

    フックへのパスでの曖昧さを避けるために、それらの定義では相対パスの代わりに絶対パスを使用します。

3.3.3. RHEL コンピュートマシンで利用できるフック

Red Hat Enterprise Linux (RHEL) コンピュートマシンを OpenShift Container Platform クラスターで更新する際に、以下のフックを使用できます。

フック名説明

openshift_node_pre_cordon_hook

  • 各ノードの遮断 (cordon) に実行されます。
  • このフックは 各ノード に対して連続して実行されます。
  • タスクが異なるホストに対して実行される必要がある場合、そのタスクは delegate_to または local_action を使用する必要があります。

openshift_node_pre_upgrade_hook

  • 各ノードの遮断 (cordon) 、更新 に実行されます。
  • このフックは 各ノード に対して連続して実行されます。
  • タスクが異なるホストに対して実行される必要がある場合、そのタスクは delegate_to または local_action を使用する必要があります。

openshift_node_pre_uncordon_hook

  • 各ノードの更新 、遮断の解除 (uncordon) 前に 実行されます。
  • このフックは 各ノード に対して連続して実行されます。
  • タスクが異なるホストに対して実行される必要がある場合、そのタスクは delegate_to または local_action を使用する必要があります。

openshift_node_post_upgrade_hook

  • 各ノードの遮断の解除 (uncordon) に実行されます。これは、最後の ノード更新アクションになります。
  • このフックは 各ノード に対して連続して実行されます。
  • タスクが異なるホストに対して実行される必要がある場合、そのタスクは delegate_to または local_action を使用する必要があります。

3.4. クラスター内の RHEL コンピュートマシンの更新

クラスターの更新後は、クラスター内の Red Hat Enterprise Linux (RHEL) コンピュートマシンを更新する必要があります。

前提条件

  • クラスターが更新されていること。

    重要

    RHEL マシンには、更新プロセスを完了するためにクラスターで生成されるアセットが必要になるため、クラスターを更新してから、クラスター内の RHEL コンピュートマシンを更新する必要があります。

  • RHEL コンピュートマシンクラスターの追加に使用したマシンへのアクセスがあること。RHEL マシンを定義する hosts Ansible インベントリーファイルおよび upgrade Playbook にアクセスできる必要があります。

手順

  1. ホストで firewalld を停止し、無効にします。

    # systemctl disable --now firewalld.service
    注記

    firewalld は、後で有効にすることはできません。これを実行する場合、ワーカー上の OpenShift Container Platform ログにはアクセスできません。

  2. /<path>/inventory/hosts で Ansible インベントリーファイルを確認し、以下の例に示されているようにすべてのコンピュートまたはワーカーマシンが [workers] セクションに一覧表示されていることを確認します。

    [all:vars]
    ansible_user=root
    #ansible_become=True
    
    openshift_kubeconfig_path="~/.kube/config"
    openshift_pull_secret_path="~/pull-secret.txt"
    
    [workers]
    mycluster-worker-0.example.com
    mycluster-worker-1.example.com
    mycluster-worker-2.example.com
    mycluster-worker-3.example.com

    すべての RHEL コンピュートマシンが [workers] セクションに一覧表示されていない場合には、それらをこのセクションに移す必要があります。

  3. openshift-ansible ディレクトリーに切り替え、upgrade Playbook を実行します。

    $ cd /usr/share/ansible/openshift-ansible
    $ ansible-playbook -i /<path>/inventory/hosts playbooks/upgrade.yml 1
    1
    <path> については、作成した Ansible インベントリーファイルへのパスを指定します。

法律上の通知

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.