第8章 Web コンソールを使用してクラスターを更新

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

注記

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

8.1. 前提条件

  • admin 権限を持つユーザーとしてクラスターにアクセスできる。RBAC の使用によるパーミッションの定義および適用 を参照してください。
  • 更新が失敗し、クラスターを以前の状態に復元する 必要がある場合に備えて、最新の etcd バックアップ がある。
  • RHEL7 ワーカーのサポートは OpenShift Container Platform 4.12 では削除されています。OpenShift Container Platform 4.12 にアップグレードする前に、RHEL7 ワーカーを RHEL8 または RHCOS ワーカーに置き換える必要があります。Red Hat は、RHEL ワーカーの RHEL7 から RHEL8 のインプレース更新をサポートしません。このホストは、クリーンなオペレーティングシステムインストールに置き換える必要があります。
  • Operator Lifecycle Manager (OLM) で以前にインストールされたすべての Operator が、最新チャネルの最新バージョンに更新されていることを確認します。Operator を更新することで、デフォルトの OperatorHub カタログが、クラスターの更新時に現行のマイナーバージョンから次のマイナーバージョンに切り替わる際、確実に有効な更新パスがあるようにします。詳細は、インストールされている Operator の更新 を参照してください。
  • すべてのマシン設定プール (MCP) が実行中であり、一時停止していないことを確認します。一時停止した MCP に関連付けられたノードは、更新プロセス中にスキップされます。カナリアロールアウト更新ストラテジーを実行している場合は、MCP を一時停止することができます。
  • 更新にかかる時間に対応するために、ワーカーノードまたはカスタムプールノードを更新することで部分的な更新を行うことができます。各プールのプログレスバー内で一時停止および再開できます。
  • クラスターが手動で維持された認証情報を使用している場合は、新しいリリース用にクラウドプロバイダーリソースを更新します。これがクラスターの要件かどうかを判断する方法などについて、詳しくは 手動で維持された認証情報でクラスターを更新する準備 を参照してください。
  • Kubernetes 1.25 で削除された API のリストを確認し、影響を受けるすべてのコンポーネントを移行して新しい API バージョンを使用し、管理者に承認を提供します。詳細は、OpenShift Container Platform 4.14 への更新の準備 を参照してください。
  • Operator を実行している場合、または Pod 中断バジェットを使用してアプリケーションを設定している場合、アップグレードプロセス中に中断が発生する可能性があります。PodDisruptionBudget で minAvailable が 1 に設定されている場合、削除 プロセスをブロックする可能性がある保留中のマシン設定を適用するためにノードがドレインされます。複数のノードが再起動された場合に、すべての Pod が 1 つのノードでのみ実行される可能性があり、PodDisruptionBudget フィールドはノードのドレインを防ぐことができます。
重要
  • 更新が完了しなかった場合、Cluster Version Operator (CVO) は、更新の調整を試みている間、ブロックしているコンポーネントのステータスを報告します。クラスターの以前のバージョンへのロールバックはサポートされていません。更新が完了しない場合は、Red Hat サポートに連絡してください。
  • unsupportedConfigOverrides セクションを使用して Operator の設定を変更することはサポートされておらず、クラスターの更新をブロックする可能性があります。クラスターを更新する前に、この設定を削除する必要があります。

関連情報