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

第3章 クラスターの更新の実行

3.1. CLI を使用したクラスターの更新
リンクのコピー

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

3.1.1. 単一ノードの OpenShift Container Platform の更新
リンクのコピー

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

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

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

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

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

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

3.1.2. クラスター更新の前提条件
リンクのコピー

CLI を使用してクラスターを更新する前に、以下の前提条件を満たす必要があります。

  • admin 権限を持つユーザーとしてクラスターにアクセスできる。詳細は、RBAC を使用して権限を定義および適用するを参照してください。
  • アップデートが失敗し、クラスターを以前の状態に復元する必要が生じた場合に備えて、最新の etcd バックアップを用意しておいてください。
  • Pod の障害により永続ボリュームを復元する必要が生じた場合に備えて、最新の Container Storage Interface (CSI) ボリュームスナップショットを用意しておいてください。
  • RHEL7 ワーカーを RHEL8 または RHCOS ワーカーに置き換え済みである。Red Hat は、RHEL7 から RHEL8 への RHEL ワーカーのインプレース更新をサポートしていません。このようなホストは、オペレーティングシステムをクリーンインストールして置き換える必要があります。
  • 以前に Operator Lifecycle Manager (OLM) を通じてインストールしたすべての Operator を、ターゲットリリースと互換性のあるバージョンに更新した。Operator を更新すると、クラスターの更新中にデフォルトのソフトウェアカタログが現在のマイナーバージョンから次のバージョンに切り替わったときに、有効な更新パスが確保されます。互換性の確認方法、および必要に応じてインストール済みの Operator を更新する方法については、インストール済み Operator の更新を参照してください。
  • すべてのマシン設定プール (MCP) が実行中であり、一時停止していないことを確認する。一時停止した MCP に関連付けられたノードは、更新プロセス中にスキップされます。カナリアロールアウト更新ストラテジーを実行している場合は、MCP を一時停止できます。
  • クラスターが手動で維持された認証情報を使用している場合は、新しいリリース用にクラウドプロバイダーリソースを更新します。クラスターでこれが必須要件であるかどうかを判断する方法など、詳細は、手動で管理された認証情報を使用してクラスターを更新する準備を参照してください。
  • クラスターで次のマイナーバージョンへの更新ができるように、すべての Upgradeable=False 条件に対応してください。アラートは、アップグレードできない 1 つ以上のクラスター Operator がある場合に Cluster Settings ページの上部に表示されます。引き続き、現在使用しているマイナーリリースについて、次に利用可能なパッチ更新に更新できます。
  • Operator を実行している場合、または Pod Disruption Budget を使用してアプリケーションを設定している場合は、更新プロセス中に中断が発生する可能性があります。PodDisruptionBudget で minAvailable が 1 に設定されている場合、保留中のマシン設定を適用するために、ノードの drain (Pod の退避) が実行され、退避プロセスがブロックされる可能性があります。複数のノードが再起動すると、すべての Pod が 1 つのノードだけで実行される可能性があり、PodDisruptionBudget フィールドによってノードの drain が防止される可能性があります。
重要
  • 更新が完了しなかった場合、Cluster Version Operator (CVO) は、更新の調整を試みている間、ブロックしているコンポーネントのステータスを報告します。クラスターの以前のバージョンへのロールバックはサポートされていません。更新が完了しない場合は、Red Hat サポートにお問い合わせください。
  • unsupportedConfigOverrides セクションを使用して Operator の設定を変更することはサポートされておらず、クラスターの更新をブロックする可能性があります。クラスターを更新する前に、この設定を削除する必要があります。

3.1.3. MachineHealthCheck リソースの一時停止
リンクのコピー

更新プロセスで、クラスター内のノードが一時的に利用できなくなる可能性があります。ワーカーノードの場合、MachineHealthCheck リソースは、そのようなノードを異常と判断して再起動する可能性があります。ワーカーノードの再起動を回避するには、クラスターを更新する前に、すべての MachineHealthCheck リソースを一時停止する必要があります。

注記

一部の MachineHealthCheck リソースは一時停止する必要がない場合があります。MachineHealthCheck リソースが回復不可能な条件に依存している場合は、その MHC を一時停止する必要はありません。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンドを実行して、一時停止したい利用可能な MachineHealthCheck リソースをすべてリスト表示します。 

    $ oc get machinehealthcheck -n openshift-machine-api

  2. 各 MachineHealthCheck リソースに対して、次のコマンドを実行してマシンのヘルスチェックを一時停止します。 

    $ oc -n openshift-machine-api annotate mhc <mhc_name> cluster.x-k8s.io/paused=""

    アノテーション付きの MachineHealthCheck リソースは以下の YAML ファイルのようになります。 

    apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: example
  namespace: openshift-machine-api
  annotations:
    cluster.x-k8s.io/paused: ""
spec:
  selector:
    matchLabels:
      role: worker
  unhealthyConditions:
  - type:    "Ready"
    status:  "Unknown"
    timeout: "300s"
  - type:    "Ready"
    status:  "False"
    timeout: "300s"
  maxUnhealthy: "40%"
status:
  currentHealthy: 5
  expectedMachines: 5
    重要

    クラスターの更新後にマシンヘルスチェックを再開します。チェックを再開するには、以下のコマンドを実行して MachineHealthCheck リソースから pause アノテーションを削除します。 

    $ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused-

3.1.4. CLI を使用したクラスターの更新
リンクのコピー

OpenShift CLI (oc) を使用して、クラスターの更新を確認および要求できます。

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

前提条件

  • 更新したバージョンに対応するバージョンの OpenShift CLI(oc) をインストールしました。
  • あなたは cluster-admin 特権を持つユーザーとしてクラスターにログインしています。
  • MachineHealthCheck の すべてのリソースが一時停止されました。

手順

  1. 利用可能なアップデートを確認し、適用したいアップデートのバージョン番号をメモするには、次のコマンドを実行してください。 

    $ oc adm upgrade recommend

    出力例

    Failing=True:

  Reason: ClusterOperatorNotAvailable
  Message: Cluster operator monitoring is not available
...
Upstream update service: https://api.integration.openshift.com/api/upgrades_info/graph
Channel: candidate-4.16 (available channels: candidate-4.16, candidate-4.17, candidate-4.18, eus-4.16, fast-4.16, fast-4.17, stable-4.16, stable-4.17)

Updates to 4.16:
  VERSION     ISSUES
  4.16.32     no known issues relevant to this cluster
  4.16.30     no known issues relevant to this cluster
And 2 older 4.16 updates you can see with '--show-outdated-releases' or '--version VERSION'.

    注記
    • --version フラグを使用すると、特定のバージョンが更新先として推奨されているかどうかを判断できます。推奨される更新がない場合でも、既知の問題がある更新がまだ利用できる可能性があります。
    • コントロールプレーンのみの アップデートを実行する方法の詳細は、コントロールプレーンのみのアップデートの実行を参照してください。

  2. 組織の要件に基づいて、次のコマンドを実行して適切な更新チャネルを設定してください。たとえば、チャネルを stable-4.13 または fast-4.13 に設定できます。チャネルの詳細は、更新チャネルとリリースについてを参照してください。 

    $ oc adm upgrade channel <channel>

    コマンドの例

    $ oc adm upgrade channel stable-4.20

    重要

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

    注記

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

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

  3. 更新を適用します。

    • 最新バージョンにアップデートするには、次のコマンドを実行してください。 

      $ oc adm upgrade --to-latest=true

    • 特定のバージョンにアップデートするには、次のコマンドを実行してください。 

      $ oc adm upgrade --to=<version>

      <version> を、oc adm upgrade recommend コマンドの出力から取得した更新バージョンに置き換えてください。

      重要

      oc adm upgrade --help コマンドを使用すると、--force フラグのオプションが表示されます。これは、強く非推奨 とされています。--force オプションを使用すると、リリースの検証や前提条件のチェックなど、クラスター側の保護機能をバイパスしてしまうためです。--force フラグを使用しても、アップデートが必ず成功するとは限りません。ガードをバイパスすると、クラスターが危険にさらされます。

  4. クラスター管理者が潜在的な既知のリスクを評価し、そのリスクが現在のクラスターにおいて許容可能であると判断した場合、管理者は安全保護を解除し、次のコマンドを実行して更新を続行できます。 

    $ oc adm upgrade --allow-not-recommended --to <version>

  5. オプション: 次のコマンドを実行して、Cluster Version Operator のステータスを確認します。 

    $ oc adm upgrade status
    注記

    更新をリアルタイムで監視するには、watch ユーティリティーで oc adm upgrade status を実行してください。

  6. アップデートが完了したら、次のコマンドを実行して、クラスターのバージョンが新しいバージョンに更新されていることを確認してください。 

    $ oc adm upgrade

    出力例

    Cluster version is <version>

Upstream is unset, so the cluster will use an appropriate default.
Channel: stable-<version> (available channels: candidate-<version>, eus-<version>, fast-<version>, stable-<version>)

No updates available. You may force an update to a specific release image, but doing so might not be supported and might result in downtime or data loss.

  7. クラスターを次のマイナーバージョン (バージョン Xy から X.(y+1) など) にアップデートする場合は、新機能に依存するワークロードをデプロイする前に、ノードが更新されていることを確認してください。以下のコマンドを実行します。 

    $ oc get nodes

    出力例

    NAME                           STATUS   ROLES    AGE   VERSION
ip-10-0-168-251.ec2.internal   Ready    master   82m   v1.33.4
ip-10-0-170-223.ec2.internal   Ready    master   82m   v1.33.4
ip-10-0-179-95.ec2.internal    Ready    worker   70m   v1.33.4
ip-10-0-182-134.ec2.internal   Ready    worker   70m   v1.33.4
ip-10-0-211-16.ec2.internal    Ready    master   82m   v1.33.4
ip-10-0-250-100.ec2.internal   Ready    worker   69m   v1.33.4

3.1.5. oc adm upgrade status を使用したクラスター更新ステータス
リンクのコピー

クラスターの更新時に、oc adm upgrade コマンドが返す更新のステータスに関する情報は限定的です。クラスター管理者は、oc adm upgrade status コマンドを使用して、制御プレーンとワーカーノードの更新状況など、クラスターの更新に関する特定の情報を取得できます。ワーカーノードはコンピュートノードとも呼ばれます。

oc adm upgrade status コマンドは読み取り専用で、クラスターの状態は変更されません。

oc adm upgrade status コマンドは、バージョン 4.12 以降のクラスターで使用できます。

oc adm upgrade status コマンドは、コントロールプレーンの更新、ワーカーノードの更新、およびヘルスインサイトの 3 つのセクションを出力します。

コントロールプレーンのアップデート

更新中のクラスター制御プレーンに関する詳細を表示し、高レベルの評価、完了ステータス、所要時間の見積もり、またはクラスター Operator の状態を示します。このセクションには、コントロールプレーンノードの更新情報を含む表も表示されます。

コントロールプレーンの更新セクションでは、--details=Operators または --details-all フラグが使用されている場合、更新されるクラスターオペレータのリストを表示する追加のテーブルも表示できます。OpenShift Container Platform は非同期かつ分散型という特性を持っているため、更新中に Operator がこのセクションに複数回表示される場合や、まったく表示されない場合があることに注意してください。このセクションは、クラスター Operator が更新中であることが確認された場合にのみ表示されます。更新処理中は、一定期間、更新クラスター Operator が表示されないことがありますが、これは正常な動作です。実行されるすべてのアクションが、監視可能な更新クラスター Operator に割り当てられるとは限りません。

作業員向けメモの更新
ワーカーノードの更新情報を表示します。ワーカーノードセクションは、クラスターに設定されている各ワーカープールに関する情報の概要を表示する表から始まります。空でないワーカープールの各出力には、そのプールに属するノードに関する更新情報をリスト表示した専用の表が表示されます。クラスターにワーカーノードが存在しない場合、出力にはワーカーノードのセクションは含まれません。--details=nodes または --details=all フラグを使用すると、ノードテーブルにすべての行を表示できます。
健康に関する洞察
進行中の更新に関連する可能性のある、クラスター内に存在する状態やイベントに関する洞察を表示します。--details=health フラグを使用すると、このセクションの項目を、ドキュメントへのリンク、より詳細なフォームの説明、インサイトに関連するクラスターリソースなど、より多くのコンテンツを含む、より詳細な形式に展開できます。
注記

oc adm upgrade status コマンドは、現在 Hosted Control Plane クラスターではサポートされていません。

以下は、更新が正常に進行中の場合に表示される出力の例です。 

= Control Plane =
Assessment:      Progressing
Target Version:  4.17.1 (from 4.17.0)
Updating:        machine-config
Completion:      97% (32 operators updated, 1 updating, 0 waiting)
Duration:        54m (Est. Time Remaining: <10m)
Operator Status: 32 Healthy, 1 Unavailable

Control Plane Nodes
NAME                                        ASSESSMENT    PHASE      VERSION   EST    MESSAGE
ip-10-0-53-40.us-east-2.compute.internal    Progressing   Draining   4.17.0    +10m
ip-10-0-30-217.us-east-2.compute.internal   Outdated      Pending    4.17.0    ?
ip-10-0-92-180.us-east-2.compute.internal   Outdated      Pending    4.17.0    ?

= Worker Upgrade =

WORKER POOL   ASSESSMENT    COMPLETION   STATUS
worker        Progressing   0% (0/2)     1 Available, 1 Progressing, 1 Draining
infra         Progressing   50% (1/2)    1 Available, 1 Progressing, 1 Draining

Worker Pool Nodes: Worker
NAME                                       ASSESSMENT    PHASE      VERSION   EST    MESSAGE
ip-10-0-4-159.us-east-2.compute.internal   Progressing   Draining   4.17.0    +10m
ip-10-0-99-40.us-east-2.compute.internal   Outdated      Pending    4.17.0    ?

Worker Pool Nodes: infra
NAME                                             ASSESSMENT    PHASE      VERSION   EST    MESSAGE
ip-10-0-4-159-infra.us-east-2.compute.internal   Progressing   Draining   4.17.0    +10m
ip-10-0-20-162.us-east-2.compute.internal        Completed     Updated    4.17.1    -

= Update Health =

SINCE   LEVEL   IMPACT   MESSAGE
54m4s   Info    None     Update is proceeding well

3.1.6. CLI を使用した更新サーバーの変更
リンクのコピー

クラスターが更新パスに関する情報を取得するために使用する更新サーバーを変更できます。

更新サーバーの変更は任意です。OpenShift Update Service (OSUS) がローカルにインストールされ、設定されている場合は、更新時にローカルサーバーを使用できるようにサーバーの URL を upstream として設定する必要があります。upstream のデフォルト値は https://api.openshift.com/api/upgrades_info/v1/graph です。

手順

  • クラスターバージョンの アップストリーム パラメーター値を変更するには、次のコマンドを実行します。 

    $ oc patch clusterversion/version --patch '{"spec":{"upstream":"<update_server_url>"}}' --type=merge

    <update_server_url> を アップデートサーバーの URL に置き換えてください。

    出力例

    clusterversion.config.openshift.io/version patched

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

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

Legal Notice

Theme

© 2026 Red Hatトップに戻る