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

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

Web コンソールを使用して、OpenShift Container Platform クラスターでマイナーバージョンおよびパッチの更新を実行できます。

注記

Web コンソールまたは oc adm upgrade channel <channel> を使用して更新チャネルを変更します。4.14 チャネルに変更した後、CLI を使用したクラスターの更新 の手順に従って、更新を完了することができます。

3.2.1. OpenShift Container Platform クラスターを更新する前に

更新する前に、以下を考慮してください。

  • 最近 etcd をバックアップしました。
  • PodDisruptionBudget で minAvailable が 1 に設定されている場合、エビクションプロセスをブロックする可能性がある保留中のマシン設定を適用するためにノードがドレインされます。複数のノードが再起動された場合に、すべての Pod が 1 つのノードでのみ実行される可能性があり、PodDisruptionBudget フィールドはノードのドレインを防ぐことができます。
  • クラスターが手動で維持された認証情報を使用している場合は、新しいリリース用にクラウドプロバイダーリソースを更新する必要がある可能性があります。
  • 管理者確認の要求をチェックして推奨されるアクションを実行し、準備ができたら確認する必要があります。
  • 更新にかかる時間を考慮し、ワーカーノードまたはカスタムプールノードを更新して部分的な更新を実行できます。各プールのプログレスバー内で一時停止および再開できます。
重要
  • 更新が完了しなかった場合、Cluster Version Operator (CVO) は、更新の調整を試みている間、ブロックしているコンポーネントのステータスを報告します。クラスターの以前のバージョンへのロールバックはサポートされていません。更新が完了しない場合は、Red Hat サポートにお問い合わせください。
  • unsupportedConfigOverrides セクションを使用して Operator の設定を変更することはサポートされておらず、クラスターの更新をブロックする可能性があります。クラスターを更新する前に、この設定を削除する必要があります。

3.2.2. Web コンソールを使用した更新サーバーの変更

更新サーバーの変更は任意です。OpenShift Update Service (OSUS) がローカルにインストールされ、設定されている場合は、更新時にローカルサーバーを使用できるようにサーバーの URL を upstream として設定する必要があります。

前提条件

  • cluster-admin 権限でクラスターにアクセスできる。
  • OpenShift Container Platform Web コンソールにアクセスできる。

手順

  1. Administration Cluster Settings に移動し、version をクリックします。

  2. YAML タブをクリックし、upstream パラメーター値を編集します。

    出力例

      ...
  spec:
    clusterID: db93436d-7b05-42cc-b856-43e11ad2d31a
    upstream: '<update-server-url>' 1
  ...

    1
    <update-server-url> 変数は、更新サーバーの URL を指定します。

    デフォルトの upstream は https://api.openshift.com/api/upgrades_info/v1/graph です。

  3. Save をクリックします。

関連情報

3.2.3. Web コンソールを使用した MachineHealthCheck リソースの一時停止

更新プロセスで、クラスター内のノードが一時的に利用できなくなる可能性があります。ワーカーノードの場合、マシンのヘルスチェックにより、このようなノードは正常ではないと識別され、それらが再起動される場合があります。このようなノードの再起動を回避するには、クラスターを更新する前にすべての MachineHealthCheck リソースを一時停止します。

前提条件

  • cluster-admin 権限でクラスターにアクセスできる。
  • OpenShift Container Platform Web コンソールにアクセスできる。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. Compute MachineHealthChecks に移動します。

  3. マシンヘルスチェックを一時停止するには、cluster.x-k8s.io/paused="" アノテーションを各 MachineHealthCheck リソースに追加します。たとえば、アノテーションを machine-api-termination-handler リソースに追加するには、以下の手順を実行します。

    1. machine-api-termination-handler の横にあるオプションメニュー kebab をクリックし､Edit annotations をクリックします。
    2. アノテーションの編集 ダイアログで、更に追加 をクリックします。
    3. キー および 値 フィールドにそれぞれ cluster.x-k8s.io/paused と "" の値を追加し、保存 をクリックします。

3.2.4. 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.14 など、更新するバージョンの正しいチャネルに設定されていることを確認してください。

    重要

    実稼働クラスターの場合は、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-* チャネルに変更し、そのチャネルで必要なバージョンに更新します。

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

関連情報

3.2.5. Web コンソールで条件付き更新を表示する

条件付き更新を使用して、特定の更新に関連するリスクを表示および評価できます。

前提条件

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

手順

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

  2. Update cluster モーダルの Select new version ドロップダウンで Include supported but not recommended versions を有効にして、ドロップダウンリストに条件付き更新を入力できます。

    注記

    Supported but not recommended バージョンを選択すると、そのバージョンの潜在的な問題に関する詳細情報が提供されます。

  3. 更新の潜在的なリスクについて詳しく説明した通知を確認してください。

関連情報

3.2.6. カナリアロールアウト更新の実行

特定のユースケースでは、特定ノードを残りのクラスターと同時に更新しない、制御された更新プロセスが必要になる場合があります。これらのユースケースには、以下のようなものがありますが、これに限定されません。

  • 更新時に利用できないミッションクリティカルなアプリケーションがあります。更新後の小規模なバッチで、ノードのアプリケーションを徐々にテストすることができます。
  • すべてのノードを更新することができない小規模なメンテナンス期間がある場合や、複数のメンテナンスウィンドウがあります。

ローリング更新のプロセスは、通常の更新ワークフロー ではありません。大規模なクラスターの場合は、複数のコマンドを実行する必要がある時間のかかるプロセスになります。この複雑さにより、クラスター全体に影響を与える可能性のあるエラーが発生する場合があります。組織がローリング更新を使用し、開始前にプロセスの実装を慎重に計画するかどうかを慎重に検討することが推奨されます。

このトピックで説明されているローリング更新プロセスでは、以下が関係します。

  • 1 つ以上のカスタムマシン設定プール (MCP) の作成。
  • これらのノードをカスタム MCP に移動するためにすぐに更新しない各ノードのラベル付け。
  • カスタム MCP の一時停止。これにより、それらのノードへの更新が回避されます。
  • クラスターの更新の実行。
  • それらのノードで更新をトリガーする 1 つのカスタム MCP の一時停止解除。
  • これらのノードでアプリケーションをテストし、新たに更新されたノードでアプリケーションが想定どおりに機能していることを確認。
  • 必要に応じて、小規模なバッチの残りのノードからカスタムラベルを削除し、それらのノードでアプリケーションのテスト。
注記

MCP の一時停止は、慎重に考慮した上で短時間に限定して実行する必要があります。

カナリアロールアウト更新プロセスを使用する場合は、カナリアロールアウト更新の実行 を参照してください。

3.2.7. 単一ノードの OpenShift Container Platform の更新

コンソールまたは CLI のいずれかを使用して、単一ノードの OpenShift Container Platform クラスターを更新またはアップグレードできます。

ただし、以下の制限事項に注意してください。

  • 他にヘルスチェックを実行するノードがないので、MachineHealthCheck リソースを一時停止する時に課される前提条件は必要ありません。
  • etcd バックアップを使用した単一ノードの OpenShift Container Platform クラスターの復元は、正式にはサポートされていません。ただし、更新に失敗した場合は、etcd バックアップを実行することが推奨されます。コントロールプレーンが正常である場合には、バックアップを使用してクラスターを以前の状態に復元できる場合があります。

  • 単一ノードの OpenShift Container Platform クラスターを更新するには、ダウンタイムが必要です。更新には、自動再起動も含まれる可能性があります。ダウンタイムの時間は、以下のシナリオのように更新ペイロードによって異なります。

    • 更新ペイロードに再起動が必要なオペレーティングシステムの更新が含まれる場合には、ダウンタイムは、クラスター管理およびユーザーのワークロードに大きく影響します。
    • 更新に含まれるマシン設定の変更で、再起動の必要がない場合には、ダウンタイムは少なくなり、クラスター管理およびユーザーワークロードへの影響は低くなります。この場合、クラスターに、ワークロードの再スケジューリングするノードが他にないため、単一ノードの OpenShift Container Platform でノードのドレイン (解放) のステップが省略されます。
    • 更新ペイロードにオペレーティングシステムの更新またはマシン設定の変更が含まれていない場合は、API が短時間してすぐに解決します。
重要

更新パッケージのバグなどの制約があり、再起動後に単一ノードが再起動されないことがあります。この場合、更新は自動的にロールバックされません。

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.