サポートコンソール開発者トライアルの開始お問い合わせ

3.5. RHEL コンピュートマシンを含むクラスターの更新

OpenShift Container Platform クラスターでマイナーバージョンおよびパッチの更新を実行できます。クラスターに Red Hat Enterprise Linux (RHEL) マシンが含まれる場合は、それらのマシンを更新するために追加の手順を実行する必要があります。

重要

OpenShift Container Platform クラスターでの RHEL コンピュートマシンの使用は非推奨となり、今後のリリースでは削除される予定です。

3.5.1. 前提条件

  • admin 権限を持つユーザーとしてクラスターにアクセスできる。RBAC の使用によるパーミッションの定義および適用 を参照してください。
  • 更新が失敗し、クラスターを以前の状態に復元する必要がある場合に備えて、最新の etcd バックアップ を用意している。
  • RHEL7 ワーカーは、RHEL8 または RHCOS ワーカーに置き換えられます。Red Hat は、RHEL7 から RHEL8 への RHEL ワーカーのインプレース更新をサポートしていません。このようなホストは、オペレーティングシステムをクリーンインストールして置き換える必要があります。
  • クラスターが手動で維持された認証情報を使用している場合は、新しいリリース用にクラウドプロバイダーリソースを更新します。これがクラスターの要件かどうかを判断する方法などの詳細は、手動で維持された認証情報でクラスターを更新する準備 を参照してください。
  • Operator を実行している場合、または Pod 中断バジェットを使用してアプリケーションを設定している場合は、更新プロセス中に中断が発生する可能性があります。PodDisruptionBudget で minAvailable が 1 に設定されている場合、削除 プロセスをブロックする可能性がある保留中のマシン設定を適用するためにノードがドレインされます。複数のノードが再起動された場合に、すべての Pod が 1 つのノードでのみ実行される可能性があり、PodDisruptionBudget フィールドはノードのドレインを防ぐことができます。

関連情報

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

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

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

前提条件

  • cluster-admin 権限を持つユーザーとして Web コンソールにアクセスできる。
  • OpenShift Container Platform Web コンソールにアクセスできる。
  • すべての MachineHealthCheck リソースを一時停止している。
  • Operator Lifecycle Manager (OLM) を通じて以前にインストールされたすべての Operator を、ターゲットリリースと互換性のあるバージョンに更新している。Operator を更新することで、デフォルトの OperatorHub カタログが、クラスターの更新時に現行のマイナーバージョンから次のマイナーバージョンに切り替わる際、確実に有効な更新パスがあるようにします。「関連情報」セクションの「インストール済み Operator の更新」を参照し、互換性を確認する方法の詳細を確認して、インストールされている Operator を必要に応じて更新してください。
  • マシン設定プール (MCP) は実行中であり、一時停止されていない。一時停止した MCP に関連付けられたノードは、更新プロセス中にスキップされます。カナリアロールアウト更新ストラテジーを実行している場合は、MCP を一時停止できる。
  • RHEL7 ワーカーは、RHEL8 または RHCOS ワーカーに置き換えられます。Red Hat は、RHEL7 から RHEL8 への RHEL ワーカーのインプレース更新をサポートしていません。このようなホストは、オペレーティングシステムをクリーンインストールして置き換える必要があります。

手順

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

  2. 実稼働クラスターの場合は、チャネル が、stable-4.16 など、更新先バージョンの正しいチャネルに設定されていることを確認してください。

    重要

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

    注記

    次のマイナーバージョンに移行する準備ができたら、そのマイナーバージョンに対応するチャネルを選択します。更新チャネルの宣言が早ければ早いほど、クラスターはターゲットバージョンへの更新パスをより効果的に推奨できます。クラスターは、利用可能なすべての可能な更新プログラムを評価し、最適な更新プログラムの推奨事項を選択するために、しばらく時間がかかる場合があります。更新の推奨事項は、その時点で利用可能な更新オプションに基づいているため、時間の経過とともに変化する可能性があります。

    ターゲットマイナーバージョンへの更新パスが表示されない場合は、次のマイナーバージョンがパスで利用可能になるまで、現在のバージョンの最新のパッチリリースにクラスターを更新し続けます。

    • Update Status が Updates Available ではない場合、クラスターを更新することはできません。
    • Select Channel は、クラスターが実行されているか、更新されるクラスターのバージョンを示します。

  3. 更新するバージョンを選択し、Save をクリックします。

    入力チャネルの Update Status が Update to <product-version> in progress に切り替わり、Operator およびノードの進捗バーを監視して、クラスター更新の進捗を確認できます。

    注記

    クラスターを次のマイナーバージョン (バージョン 4.10 から 4.11 など) に更新する場合は、新しい機能を利用するワークロードをデプロイする前に、ノードが更新されていることを確認してください。更新されていないワーカーノードを持つプールは Cluster Settings ページに表示されます。

  4. 更新が完了し、Cluster Version Operator が利用可能な更新を更新したら、追加の更新が現在のチャネルで利用可能かどうかを確認します。

    • 更新が利用可能な場合は、更新ができなくなるまで、現在のチャネルでの更新を継続します。
    • 利用可能な更新がない場合は、チャネル を次のマイナーバージョンの stable-*、eus-* または fast-* チャネルに変更し、そのチャネルで必要なバージョンに更新します。

    必要なバージョンに達するまで、いくつかの中間更新を実行する必要がある場合があります。

    重要

    Red Hat Enterprise Linux (RHEL) ワーカーマシンを含むクラスターを更新する場合、それらのワーカーは、更新プロセス時に一時的に使用できなくなります。クラスターの更新の終了において各 RHEL マシンがのステートが NotReady になる際に、更新 Playbook を各 RHEL マシンに対して実行する必要があります。

関連情報

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

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

3.5.3.1. 更新用の Ansible フックについて

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

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

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

3.5.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.5.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.5.4. クラスター内の RHEL コンピュートマシンの更新

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

重要

RHEL コンピューティングマシンでは、Red Hat Enterprise Linux (RHEL) バージョン 8.6 以降がサポートされています。

RHEL をオペレーティングシステムとして使用する場合は、コンピュートマシンを別の OpenShift Container Platform のマイナーバージョンに更新することもできます。マイナーバージョンの更新の実行時に、RHEL から RPM パッケージを除外する必要はありません。

重要

RHEL 7 コンピューティングマシンを RHEL 8 に更新することはできません。新しい RHEL 8 ホストをデプロイする必要があり、古い RHEL 7 ホストを削除する必要があります。

前提条件

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

    重要

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

  • RHEL コンピュートマシンクラスターの追加に使用したマシンへのローカルアクセスがあること。RHEL マシンを定義する hosts Ansible インベントリーファイルおよび upgrade Playbook にアクセスできる必要があります。
  • マイナーバージョンへの更新の場合、RPM リポジトリーはクラスターで実行しているのと同じバージョンの OpenShift Container Platform を使用します。

手順

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

    # systemctl disable --now firewalld.service
    注記

    デフォルトでは、"最小" インストールオプションを持つベース OS RHEL により、firewalld サービスが有効になります。ホストで firewalld サービスを有効にすると、ワーカーで OpenShift Container Platform ログにアクセスできなくなります。ワーカーの OpenShift Container Platform ログへのアクセスを継続する場合は、firewalld を後で有効にしないでください。

  2. OpenShift Container Platform 4.16 で必要なリポジトリーを有効にします。

    1. Ansible Playbook を実行するマシンで、必要なリポジトリーを更新します。 

      # subscription-manager repos --disable=rhocp-4.15-for-rhel-8-x86_64-rpms \
                             --enable=rhocp-4.16-for-rhel-8-x86_64-rpms
      重要

      OpenShift Container Platform 4.11 の時点で、Ansible Playbook は RHEL 8 に対してのみ提供されています。RHEL 7 システムが OpenShift Container Platform 4.10 Ansible Playbook のホストとして使用された場合、Ansible ホストを RHEL 8 に更新するか、RHEL 8 システムに新しい Ansible ホストを作成し、古い Ansible ホストからインベントリーをコピーする必要があります。

    2. Ansible Playbook を実行するマシンで、Ansible パッケージを更新します。 

      # yum swap ansible ansible-core

    3. Ansible Playbook を実行するマシンで、openshift-ansible を含む必要なパッケージを更新します。 

      # yum update openshift-ansible openshift-clients

    4. 各 RHEL コンピュートノードで、必要なリポジトリーを更新します。 

      # subscription-manager repos --disable=rhocp-4.15-for-rhel-8-x86_64-rpms \
                             --enable=rhocp-4.16-for-rhel-8-x86_64-rpms

  3. RHEL ワーカーマシンを更新します。

    1. 次の例に示すように、/<path>/inventory/hosts にある Ansible インベントリーファイルを確認し、その内容を更新して、RHEL 8 マシンが [workers] セクションにリストされるようにします。 

      [all:vars]
ansible_user=root
#ansible_become=True

openshift_kubeconfig_path="~/.kube/config"

[workers]
mycluster-rhel8-0.example.com
mycluster-rhel8-1.example.com
mycluster-rhel8-2.example.com
mycluster-rhel8-3.example.com

    2. openshift-ansible ディレクトリーに移動します。 

      $ cd /usr/share/ansible/openshift-ansible

    3. upgrade Playbook を実行します。 

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

      upgrade Playbook は OpenShift Container Platform パッケージのみを更新します。オペレーティングシステムパッケージは更新されません。

  4. すべてのワーカーを更新したら、すべてのクラスターノードが新規バージョンに更新されていることを確認します。 

    # oc get node

    出力例

    NAME                        STATUS                        ROLES    AGE    VERSION
mycluster-control-plane-0   Ready                         master   145m   v1.29.4
mycluster-control-plane-1   Ready                         master   145m   v1.29.4
mycluster-control-plane-2   Ready                         master   145m   v1.29.4
mycluster-rhel8-0           Ready                         worker   98m    v1.29.4
mycluster-rhel8-1           Ready                         worker   98m    v1.29.4
mycluster-rhel8-2           Ready                         worker   98m    v1.29.4
mycluster-rhel8-3           Ready                         worker   98m    v1.29.4

  5. オプション: upgrade Playbook で更新されていないオペレーティングシステムパッケージを更新します。4.16 にないパッケージを更新するには、以下のコマンドを使用します。 

    # yum update
    注記

    4.16 のインストール時に使用したものと同じ RPM リポジトリーを使用している場合は、RPM パッケージを除外する必要はありません。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.