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

17.2. 通信事業者コア CNF クラスターのアップグレード

17.2.1. 通信事業者コア CNF クラスターの更新

OpenShift Container Platform には、すべての偶数番号のリリースと EUS リリース間の更新パスに対する長期サポート (Extended Update Support (EUS)) があります。ある EUS バージョンから次の EUS バージョンに更新できます。y-stream バージョンと z-stream バージョン間で更新することも可能です。

17.2.1.1. 通信事業者コア CNF クラスターのクラスター更新

クラスターの更新は、バグや潜在的なセキュリティーの脆弱性を確実に修正するうえで重要なタスクです。多くの場合、クラウドネイティブネットワーク機能 (CNF) の更新には、クラスターバージョンの更新時に提供されるプラットフォームの追加機能が必要になります。また、クラスタープラットフォームがサポート対象のバージョンになるように、クラスターを定期的に更新する必要があります。

EUS リリースを最新の状態に保ち、一部の重要な z-stream リリースにのみアップグレードすることで、更新により最新の状態に保つのに必要な労力を最小限に抑えることができます。

注記

クラスターの更新パスは、クラスターのサイズとトポロジーによって異なります。ここで説明する更新手順は、3 ノードクラスターから、通信事業者スケールチームによって認定された最大規模のクラスターまで、ほとんどのクラスターに適用されます。これには、混合ワークロードクラスターのシナリオがいくつか含まれています。

説明する更新シナリオは次のとおりです。

  • コントロールプレーンのみの更新
  • y-stream の更新
  • z-stream の更新
重要

コントロールプレーンのみの更新は、以前は EUS から EUS への更新と呼ばれていました。コントロールプレーンのみの更新は、OpenShift Container Platform の偶数番号のマイナーバージョン間でのみ実行可能です。

17.2.2. 更新バージョン間のクラスター API バージョンの検証

API は、コンポーネントの更新に伴い、次第に変更されます。クラウドネイティブネットワーク機能 (CNF) API と更新されたクラスターバージョンの間に互換性があることを検証することが重要です。

17.2.2.1. OpenShift Container Platform API の互換性

新しい y-stream 更新の一部としてどの z-stream リリースに更新するかを検討するときは、移行元の z-stream バージョンにあるすべてのパッチが新しい z-stream バージョンにあることを確認する必要があります。更新後のバージョンに必要なパッチがすべて含まれていない場合、Kubernetes の組み込みの互換性が損なわれます。

たとえば、クラスターのバージョンが 4.15.32 の場合、4.15.32 に適用されているすべてのパッチを含む 4.16 z-stream リリースに更新する必要があります。

17.2.2.1.1. Kubernetes のバージョンスキューについて

クラスター Operator は、それぞれ特定の API バージョンをサポートしています。Kubernetes API は時間とともに進化し、新しいバージョンが非推奨になったり、既存の API が変更されたりする可能性があります。これは "バージョンスキュー" と呼ばれます。API の変更は、新しいリリースごとに確認する必要があります。API には Operator の複数のリリース間で互換性がある場合もありますが、互換性は保証されていません。バージョンスキューから生じる問題を軽減するために、明確な更新ストラテジーに従ってください。

関連情報

17.2.2.2. クラスターのバージョン更新パスの確認

Red Hat OpenShift Container Platform Update Graph ツールを使用して、更新先の z-stream リリースに対してパスが有効かどうかを確認します。Red Hat テクニカルアカウントマネージャーに更新の確認を取り、更新パスが通信事業者の実装で有効であることを確認してください。

重要

更新先の <4.y+1.z> または <4.y+2.z> バージョンは、更新元の <4.y.z> リリースと同じパッチレベルである必要があります。

OpenShift の更新プロセスでは、特定の <4.y.z> リリースに修正が存在する場合、更新先の <4.y+1.z> リリースにもその修正が存在する必要があります。

図17.1 バグ修正のバックポートと更新の図

バグ修正のバックポートと更新の図
重要

OpenShift の開発には、リグレッションを防ぐ厳格なバックポートポリシーがあります。たとえば、バグは 4.15.z で修正する前に 4.16.z で修正する必要があります。そのため、更新の図では、マイナーバージョンが大きくても、時系列的に古いリリースへの更新 (4.15.24 から 4.16.2 への更新など) は許可されていません。

関連情報

17.2.2.3. ターゲットリリースの選択

Red Hat OpenShift Container Platform Update Graph または cincinnati-graph-data リポジトリー を使用して、どのリリースに更新するかを決定します。

17.2.2.3.1. 利用可能な z-stream 更新の確認

新しい z-stream リリースに更新する前に、利用可能なバージョンを確認する必要があります。

注記

z-stream 更新を実行するときにチャネルを変更する必要はありません。

手順

  1. 利用可能な z-stream リリースを確認します。以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc adm upgrade

    出力例

    Copy to Clipboard Toggle word wrap 
    Cluster version is 4.14.34

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

Recommended updates:

  VERSION     IMAGE
  4.14.37     quay.io/openshift-release-dev/ocp-release@sha256:14e6ba3975e6c73b659fa55af25084b20ab38a543772ca70e184b903db73092b
  4.14.36     quay.io/openshift-release-dev/ocp-release@sha256:4bc4925e8028158e3f313aa83e59e181c94d88b4aa82a3b00202d6f354e8dfed
  4.14.35     quay.io/openshift-release-dev/ocp-release@sha256:883088e3e6efa7443b0ac28cd7682c2fdbda889b576edad626769bf956ac0858

17.2.2.3.2. コントロールプレーンのみの更新のチャネルを変更する

コントロールプレーンのみの更新では、チャネルを必要なバージョンに変更する必要があります。

注記

z-stream 更新を実行するときにチャネルを変更する必要はありません。

手順

  1. 現在設定されている更新チャネルを特定します。

    Copy to Clipboard Toggle word wrap 
    $ oc get clusterversion -o=jsonpath='{.items[*].spec}' | jq

    出力例

    Copy to Clipboard Toggle word wrap 
    {
  "channel": "stable-4.14",
  "clusterID": "01eb9a57-2bfb-4f50-9d37-dc04bd5bac75"
}

  2. 更新する新しいチャネルを参照するようにチャネルを変更します。

    Copy to Clipboard Toggle word wrap 
    $ oc adm upgrade channel eus-4.16

  3. 更新されたチャネルを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get clusterversion -o=jsonpath='{.items[*].spec}' | jq

    出力例

    Copy to Clipboard Toggle word wrap 
    {
  "channel": "eus-4.16",
  "clusterID": "01eb9a57-2bfb-4f50-9d37-dc04bd5bac75"
}

17.2.2.3.2.1. EUS から EUS への更新を早期に行うためにチャネルを変更する

OpenShift Container Platform の最新リリースへの更新パスは、マイナーリリースの最初の GA から 45 - 90 日が経過するまで、EUS チャネルでも stable チャネルでも利用できません。

新しいリリースへの更新のテストを開始する場合は、fast チャネルを使用できます。

手順

  1. チャネルを fast-<y+1> に変更します。たとえば、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc adm upgrade channel fast-4.16

  2. 新しいチャネルの更新パスを確認します。以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc adm upgrade
     Copy to Clipboard Toggle word wrap 
    Cluster version is 4.15.33

Upgradeable=False

  Reason: AdminAckRequired
  Message: Kubernetes 1.28 and therefore OpenShift 4.16 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/6958394 for details and instructions.

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

Recommended updates:

  VERSION     IMAGE
  4.16.14     quay.io/openshift-release-dev/ocp-release@sha256:6618dd3c0f5
  4.16.13     quay.io/openshift-release-dev/ocp-release@sha256:7a72abc3
  4.16.12     quay.io/openshift-release-dev/ocp-release@sha256:1c8359fc2
  4.16.11     quay.io/openshift-release-dev/ocp-release@sha256:bc9006febfe
  4.16.10     quay.io/openshift-release-dev/ocp-release@sha256:dece7b61b1
  4.15.36     quay.io/openshift-release-dev/ocp-release@sha256:c31a56d19
  4.15.35     quay.io/openshift-release-dev/ocp-release@sha256:f21253
  4.15.34     quay.io/openshift-release-dev/ocp-release@sha256:2dd69c5

  3. 更新手順に従ってバージョン 4.16 にアップグレードします (バージョン 4.15 から <y+1>)。

    注記

    fast チャネルを使用している場合でも、EUS リリース間でワーカーノードを一時停止したままにすることができます。

  4. 必要な <y+1> リリースに更新したら、チャネルを再度変更し、今度は fast-<y+2> に変更します。
  5. EUS 更新手順に従って、必要な <y+2> リリースに更新します。
17.2.2.3.3. y-stream 更新のチャネルの変更

y-stream 更新では、チャネルを次のリリースチャネルに変更します。

注記

実稼働クラスターには、stable または EUS リリースチャネルを使用してください。

手順

  1. 更新チャネルを変更します。

    Copy to Clipboard Toggle word wrap 
    $ oc adm upgrade channel stable-4.15

  2. 新しいチャネルの更新パスを確認します。以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc adm upgrade

    出力例

    Copy to Clipboard Toggle word wrap 
    Cluster version is 4.14.34

Upgradeable=False

  Reason: AdminAckRequired
  Message: Kubernetes 1.27 and therefore OpenShift 4.15 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/6958394 for details and instructions.

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

Recommended updates:

  VERSION     IMAGE
  4.15.33     quay.io/openshift-release-dev/ocp-release@sha256:7142dd4b560
  4.15.32     quay.io/openshift-release-dev/ocp-release@sha256:cda8ea5b13dc9
  4.15.31     quay.io/openshift-release-dev/ocp-release@sha256:07cf61e67d3eeee
  4.15.30     quay.io/openshift-release-dev/ocp-release@sha256:6618dd3c0f5
  4.15.29     quay.io/openshift-release-dev/ocp-release@sha256:7a72abc3
  4.15.28     quay.io/openshift-release-dev/ocp-release@sha256:1c8359fc2
  4.15.27     quay.io/openshift-release-dev/ocp-release@sha256:bc9006febfe
  4.15.26     quay.io/openshift-release-dev/ocp-release@sha256:dece7b61b1
  4.14.38     quay.io/openshift-release-dev/ocp-release@sha256:c93914c62d7
  4.14.37     quay.io/openshift-release-dev/ocp-release@sha256:c31a56d19
  4.14.36     quay.io/openshift-release-dev/ocp-release@sha256:f21253
  4.14.35     quay.io/openshift-release-dev/ocp-release@sha256:2dd69c5

17.2.3. 通信事業者コアクラスタープラットフォームの更新準備

通常、通信事業者のクラスターはベアメタルハードウェア上で実行されます。多くの場合、重要なセキュリティー修正を適用したり、新しい機能を導入したり、OpenShift Container Platform の新しいリリースとの互換性を維持したりするために、ファームウェアを更新する必要があります。

17.2.3.1. ホストファームウェアが更新と互換性があることを確認する

お客様がクラスターで実行するファームウェアバージョンの更新は、お客様の責任です。ホストファームウェアの更新は、OpenShift Container Platform の更新プロセスには含まれません。OpenShift Container Platform のバージョンと一緒にファームウェアを更新することは推奨されません。

重要

ハードウェアベンダーは、ご使用のハードウェアに最新の認定済みファームウェアバージョンを適用することを推奨しています。通信事業者のユースケースでは、ファームウェアの更新を実稼働環境に適用する前に、必ずテスト環境で検証してください。ホストファームウェアが最適なものでないと、通信事業者の CNF ワークロードの高スループット特性に悪影響が及ぶ可能性があります。

新しいファームウェア更新を徹底的にテストして、OpenShift Container Platform の最新バージョンで期待どおりに動作することを確認してください。ターゲットの OpenShift Container Platform 更新バージョンを使用して最新のファームウェアバージョンをテストするのが理想的です。

17.2.3.2. レイヤード製品が更新と互換性があることを確認する

更新を開始する前に、更新先の OpenShift Container Platform のバージョンですべてのレイヤード製品が動作することを確認します。通常、これにはすべての Operator が含まれます。

手順

  1. クラスターに現在インストールされている Operator を確認します。たとえば、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc get csv -A

    出力例

    Copy to Clipboard Toggle word wrap 
    NAMESPACE                              NAME            DISPLAY          VERSION   REPLACES                             PHASE
gitlab-operator-kubernetes.v0.17.2     GitLab                           0.17.2    gitlab-operator-kubernetes.v0.17.1   Succeeded
openshift-operator-lifecycle-manager   packageserver   Package Server   0.19.0                                         Succeeded

  2. OLM を使用してインストールする Operator が更新先のバージョンと互換性があることを確認します。

    Operator Lifecycle Manager (OLM) によってインストールされる Operator は、標準のクラスター Operator セットの一部ではありません。

    Operator Update Information Checker を使用して、それぞれの y-stream 更新後に Operator を更新する必要があるかどうか、または次の EUS リリースに完全に更新されるまで待つことができるかどうかを確認してください。

    ヒント

    Operator Update Information Checker を使用して、Operator の特定のリリースと互換性のある OpenShift Container Platform のバージョンを確認することもできます。

  3. OLM 以外の方法でインストールする Operator が更新先のバージョンと互換性があることを確認します。

    Red Hat によって直接サポートされていない、OLM によってインストールされるすべての Operator について、Operator ベンダーに問い合わせてリリースの互換性を確認してください。

    • 一部の Operator は、OpenShift Container Platform の複数のリリースと互換性があります。クラスターの更新が完了するまで、Operator を更新する必要がない場合があります。詳細は、「ワーカーノードの更新」を参照してください。
    • 最初の y-stream コントロールプレーンの更新を実行した後に Operator を更新する方法は、「すべての OLM Operator の更新」を参照してください。

関連情報

17.2.3.3. 更新前にノードに MachineConfigPool ラベルを適用する

約 8 - 10 個のノードをグループ化するために、MachineConfigPool (mcp) ノードラベルを準備します。mcp グループを使用すると、クラスターの他の部分とは別にノードのグループを再起動できます。

mcp ノードラベルを使用すると、更新プロセス中にノードセットを一時停止および一時停止解除して、任意のタイミングで更新と再起動を実行できます。

17.2.3.3.1. クラスター更新の段階的実施

更新中に問題が発生する場合があります。多くの場合、この問題はハードウェア障害やノードをリセットする必要性に関連しています。mcp ノードラベルを使用すると、重要なタイミングで更新を一時停止し、一時停止および一時停止解除したノードを追跡しながら、段階的にノードを更新できます。問題が発生した場合は、一時停止状態でないノードを使用して、すべてのアプリケーション Pod を実行し続けるのに十分な数のノードが実行されていることを確認します。

17.2.3.3.2. ワーカーノードを MachineConfigPool グループに分割する

ワーカーノードを mcp グループに分割する方法は、クラスター内のノードの数やノードロールに割り当てるノードの数によって異なります。デフォルトでは、クラスター内の 2 つのロールは、コントロールプレーンとワーカーです。

通信事業者のワークロードを実行するクラスターでは、ワーカーノードを CNF コントロールプレーンのロールと CNF データプレーンのロール間でさらに分割できます。ワーカーノードをこれら 2 つのグループに分割する mcp ロールラベルを追加します。

注記

大規模なクラスターでは、CNF コントロールプレーンのロールに 100 個ほどのワーカーノードが含まれる場合があります。クラスター内のノード数に関係なく、各 MachineConfigPool グループのノード数は、10 程度に抑えてください。これにより、一度に停止するノードの数を制御できます。複数の MachineConfigPool グループを使用すると、同時に複数のグループを一時停止解除して更新を高速化したり、更新を 2 つ以上のメンテナンス期間に分けたりすることができます。

15 個のワーカーノードを持つクラスターの例

15 個のワーカーノードを持つクラスターを考えてみます。

  • 10 個のワーカーノードは CNF コントロールプレーンノードです。
  • 5 個のワーカーノードは CNF データプレーンノードです。

CNF コントロールプレーンのロールとデータプレーンワーカーノードのロールを、それぞれ少なくとも 2 つの mcp グループに分割します。ロールごとに 2 つの mcp グループを用意することで、更新の影響を受けないノードのセットを 1 つ確保できます。

6 つのワーカーノードを持つクラスターの例

6 つのワーカーノードを持つクラスターを考えてみましょう。

  • ワーカーノードを、それぞれ 2 つのノードからなる 3 つの mcp グループに分割します。

mcp グループの 1 つをアップグレードします。CNF の互換性を検証できるように、更新したノードを 1 日間そのままにしておきます。その後、他の 4 つのノードの更新を完了します。

重要

mcp グループの一時停止を解除するプロセスとペースは、CNF アプリケーションと設定によって決まります。

CNF Pod がクラスター内のノード間のスケジューリングに対応できる場合は、一度に複数の mcp グループの一時停止を解除し、mcp カスタムリソース (CR) の MaxUnavailable を最大 50% に設定できます。これにより、mcp グループ内の最大半数のノードを再起動して更新できます。

17.2.3.3.3. 設定されているクラスター MachineConfigPool ロールの確認

クラスター内で現在設定されている MachineConfigPool ロールを確認します。

手順

  1. クラスター内で現在設定されている mcp グループを取得します。

    Copy to Clipboard Toggle word wrap 
    $ oc get mcp

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME     CONFIG                   UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-bere83   True      False      False      3              3                   3                     0                      25d
worker   rendered-worker-245c4f   True      False      False      2              2                   2                     0                      25d

  2. mcp ロールのリストをクラスター内のノードのリストと比較します。

    Copy to Clipboard Toggle word wrap 
    $ oc get nodes

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME           STATUS   ROLES                  AGE   VERSION
ctrl-plane-0   Ready    control-plane,master   39d   v1.27.15+6147456
ctrl-plane-1   Ready    control-plane,master   39d   v1.27.15+6147456
ctrl-plane-2   Ready    control-plane,master   39d   v1.27.15+6147456
worker-0       Ready    worker                 39d   v1.27.15+6147456
worker-1       Ready    worker                 39d   v1.27.15+6147456

    注記

    mcp グループの変更を適用すると、ノードロールが更新されます。

    ワーカーノードを mcp グループに分割する方法を決定します。

17.2.3.3.4. クラスターの MachineConfigPool グループの作成

mcp グループの作成は 2 つのステップで行います。

  1. クラスター内のノードに mcp ラベルを追加します。
  2. ラベルに基づいてノードをまとめるクラスターに mcp CR を適用します。

手順

  1. ノードにラベルを付けて、mcp グループに配置できるようにします。以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc label node worker-0 node-role.kubernetes.io/mcp-1=
     Copy to Clipboard Toggle word wrap 
    $ oc label node worker-1 node-role.kubernetes.io/mcp-2=

    mcp-1 および mcp-2 ラベルをノードに適用します。以下に例を示します。

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME           STATUS   ROLES                  AGE   VERSION
ctrl-plane-0   Ready    control-plane,master   39d   v1.27.15+6147456
ctrl-plane-1   Ready    control-plane,master   39d   v1.27.15+6147456
ctrl-plane-2   Ready    control-plane,master   39d   v1.27.15+6147456
worker-0       Ready    mcp-1,worker           39d   v1.27.15+6147456
worker-1       Ready    mcp-2,worker           39d   v1.27.15+6147456

  2. クラスターの mcp CR としてラベルを適用する YAML カスタムリソース (CR) を作成します。次の YAML を mcps.yaml ファイルに保存します。

    Copy to Clipboard Toggle word wrap 
    ---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: mcp-2
spec:
  machineConfigSelector:
    matchExpressions:
      - {
         key: machineconfiguration.openshift.io/role,
         operator: In,
         values: [worker,mcp-2]
        }
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/mcp-2: ""
---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: mcp-1
spec:
  machineConfigSelector:
    matchExpressions:
      - {
         key: machineconfiguration.openshift.io/role,
         operator: In,
         values: [worker,mcp-1]
        }
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/mcp-1: ""

  3. MachineConfigPool リソースを作成します。

    Copy to Clipboard Toggle word wrap 
    $ oc apply -f mcps.yaml

    出力例

    Copy to Clipboard Toggle word wrap 
    machineconfigpool.machineconfiguration.openshift.io/mcp-2 created

検証

クラスターに MachineConfigPool リソースが適用される様子を監視します。mcp リソースを適用すると、ノードが新しいマシン設定プールに追加されます。これには数分かかります。

注記

ノードは、mcp グループに追加されている間は再起動しません。元のワーカーおよびマスター mcp グループは変更されません。

  • 新しい mcp リソースのステータスを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get mcp

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME     CONFIG                   UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-be3e83   True      False      False      3              3                 3                     0                      25d
mcp-1    rendered-mcp-1-2f4c4f    False     True       True       1              0                 0                     0                      10s
mcp-2    rendered-mcp-2-2r4s1f    False     True       True       1              0                 0                     0                      10s
worker   rendered-worker-23fc4f   False     True       True       0              0                 0                     2                      25d

    最終的に、リソースは完全に適用されます。

    Copy to Clipboard Toggle word wrap 
    NAME     CONFIG                   UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-be3e83   True      False      False      3              3                 3                     0                      25d
mcp-1    rendered-mcp-1-2f4c4f    True      False      False      1              1                 1                     0                      7m33s
mcp-2    rendered-mcp-2-2r4s1f    True      False      False      1              1                 1                     0                      51s
worker   rendered-worker-23fc4f   True      False      False      0              0                 0                     0                      25d

関連情報

17.2.3.4. 通信事業者のデプロイメント環境に関する考慮事項

通信事業者の環境では、ほとんどのクラスターはインターネット非接続のネットワーク内にあります。このような環境でクラスターを更新するには、オフラインイメージリポジトリーを更新する必要があります。

関連情報

17.2.3.5. クラスタープラットフォームの更新の準備

クラスターを更新する前に、いくつかの基本的なチェックと検証を実行して、クラスターの更新の準備ができていることを確認します。

手順

  1. 次のコマンドを実行して、クラスター内に失敗した Pod や進行中の Pod がないことを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get pods -A | grep -E -vi 'complete|running'
    注記

    保留中の状態の Pod がある場合は、このコマンドを複数回実行する必要がある場合があります。

  2. クラスター内のすべてのノードが利用可能であることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get nodes

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME           STATUS   ROLES                  AGE   VERSION
ctrl-plane-0   Ready    control-plane,master   32d   v1.27.15+6147456
ctrl-plane-1   Ready    control-plane,master   32d   v1.27.15+6147456
ctrl-plane-2   Ready    control-plane,master   32d   v1.27.15+6147456
worker-0       Ready    mcp-1,worker           32d   v1.27.15+6147456
worker-1       Ready    mcp-2,worker           32d   v1.27.15+6147456

  3. すべてのベアメタルノードがプロビジョニングされ、準備ができていることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get bmh -n openshift-machine-api

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME           STATE         CONSUMER                   ONLINE   ERROR   AGE
ctrl-plane-0   unmanaged     cnf-58879-master-0         true             33d
ctrl-plane-1   unmanaged     cnf-58879-master-1         true             33d
ctrl-plane-2   unmanaged     cnf-58879-master-2         true             33d
worker-0       unmanaged     cnf-58879-worker-0-45879   true             33d
worker-1       progressing   cnf-58879-worker-0-dszsh   false            1d
    1

    1
    worker-1 ノードのプロビジョニング中にエラーが発生しています。

検証

  • すべてのクラスター Operator の準備ができていることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get co

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication                             4.14.34   True        False         False      17h
baremetal                                  4.14.34   True        False         False      32d

...

service-ca                                 4.14.34   True        False         False      32d
storage                                    4.14.34   True        False         False      32d

関連情報

17.2.4. 通信事業者コア CNF クラスター更新前の CNF Pod の設定

クラウドネイティブネットワーク機能 (CNF) を開発するときは、Red Hat best practices for Kubernetes のガイダンスに従って、更新中にクラスターが Pod をスケジュールできるようにします。

重要

Deployment リソースを使用して、常に Pod をグループでデプロイしてください。Deployment リソースは、単一障害点が生まれないように、利用可能なすべての Pod にワークロードを分散します。Deployment リソースによって管理されている Pod が削除されると、新しい Pod が自動的にその代わりになります。

関連情報

17.2.4.1. Pod Disruption Budget により CNF ワークロードを無停止で実行する

適用する PodDisruptionBudget カスタムリソース (CR) で Pod Disruption Budget を設定すると、デプロイメント内の Pod の最小数を設定して、CNF ワークロードを無停止で実行できます。この値を設定するときは注意してください。不適切に設定すると更新が失敗する可能性があります。

たとえば、デプロイメントに 4 つの Pod があり、Pod Disruption Budget を 4 に設定した場合、クラスタースケジューラーによって常に 4 つの Pod が実行され、Pod をスケールダウンできなくなります。

そうではなく、Pod Disruption Budget を 2 に設定し、4 つの Pod のうち 2 つをダウン状態としてスケジュールできるようにします。そうすれば、それらの Pod が配置されているワーカーノードを再起動できます。

注記

Pod Disruption Budget を 2 に設定しても、更新中など、一定期間にわたりデプロイメントが 2 つの Pod のみで実行されるわけではありません。クラスタースケジューラーは、2 つの古い Pod を置き換える 2 つの新しい Pod を作成します。しかし、新しい Pod がオンラインになってから古い Pod が削除されるまでには、少し時間がかかります。

関連情報

17.2.4.2. Pod が同じクラスターノード上で実行されないようにする

Kubernetes で高可用性を実現するには、クラスター内の別々のノードで重複したプロセスを実行する必要があります。これにより、1 つのノードが使用できなくなった場合でも、アプリケーションを引き続き実行できます。OpenShift Container Platform では、デプロイメント内の別々の Pod にプロセスを自動的に複製できます。デプロイメント内の Pod が同じクラスターノード上で実行されないようにするには、Pod 仕様でアンチアフィニティーを設定します。

更新時に Pod のアンチアフィニティーを設定すると、Pod がクラスター内のノード全体に均等に分散されるようになります。つまり、更新時にノードの再起動が容易になります。たとえば、ノード上に 1 つのデプロイメントの Pod が 4 つあり、Pod Disruption Budget が Pod を一度に 1 つだけ削除できるように設定されている場合、そのノードの再起動には 4 倍の時間がかかります。Pod のアンチアフィニティーを設定すると、Pod がクラスター全体に分散され、このような事態の発生が防止されます。

関連情報

17.2.4.3. アプリケーションの liveness、readiness、および startup プローブ

更新をスケジュールする前に、liveness、readiness、および startup プローブを使用して、ライブアプリケーションコンテナーの健全性をチェックできます。これらは、アプリケーションコンテナーの状態の保持に依存する Pod で使用するのに非常に便利なツールです。

liveness ヘルスチェック
コンテナーが実行中かどうかを確認します。コンテナーの liveness プローブが失敗した場合、Pod が再起動ポリシーに基づいて応答します。
readiness プローブ
コンテナーがサービス要求を受け入れる準備ができているかどうかを確認します。コンテナーの readiness プローブが失敗した場合、kubelet が利用可能なサービスエンドポイントのリストからコンテナーを削除します。
startup プローブ
startup プローブは、コンテナー内のアプリケーションが起動しているかどうかを示します。その他のプローブはすべて、起動に成功するまで無効にされます。startup プローブが成功しない場合、kubelet がコンテナーを強制終了し、そのコンテナーが Pod の restartPolicy 設定の対象となります。

関連情報

17.2.5. 通信事業者コア CNF クラスターを更新する前の作業

クラスターの更新を開始する前に、ワーカーノードを一時停止し、etcd データベースをバックアップし、最終的なクラスターのヘルスチェックを実行する必要があります。

17.2.5.1. 更新前のワーカーノードの一時停止

更新を開始する前に、ワーカーノードを一時停止する必要があります。次の例では、mcp-1 と mcp-2 という 2 つの mcp グループがあります。パッチを適用して、これらの各 MachineConfigPool グループの spec.paused フィールドを true にします。

手順

  1. 次のコマンドを実行して、mcp CR にパッチを適用し、ノードを一時停止し、それらのノードから Pod をドレインして削除します。

    Copy to Clipboard Toggle word wrap 
    $ oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":true}}'
     Copy to Clipboard Toggle word wrap 
    $ oc patch mcp/mcp-2 --type merge --patch '{"spec":{"paused":true}}'

  2. 一時停止した mcp グループのステータスを取得します。

    Copy to Clipboard Toggle word wrap 
    $ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker

    出力例

    Copy to Clipboard Toggle word wrap 
    MCP     Paused
---     ------
master  false
mcp-1   true
mcp-2   true

注記

デフォルトのコントロールプレーンおよびワーカーの mcp グループは、更新中に変更されません。

17.2.5.2. 更新を開始する前の etcd データベースのバックアップ

更新を開始する前に、etcd データベースをバックアップする必要があります。

17.2.5.2.1. etcd データのバックアップ

以下の手順に従って、etcd スナップショットを作成し、静的 Pod のリソースをバックアップして etcd データをバックアップします。このバックアップは保存でき、etcd を復元する必要がある場合に後で使用することができます。

重要

単一のコントロールプレーンホストからのバックアップのみを保存します。クラスター内の各コントロールプレーンホストからのバックアップは取得しないでください。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

  • クラスター全体のプロキシーが有効になっているかどうかを確認している。

    ヒント

    oc get proxy cluster -o yaml の出力を確認して、プロキシーが有効にされているかどうかを確認できます。プロキシーは、httpProxy、httpsProxy、および noProxy フィールドに値が設定されている場合に有効にされます。

手順

  1. コントロールプレーンノードの root としてデバッグセッションを開始します。

    Copy to Clipboard Toggle word wrap 
    $ oc debug --as-root node/<node_name>

  2. デバッグシェルで root ディレクトリーを /host に変更します。

    Copy to Clipboard Toggle word wrap 
    sh-4.4# chroot /host

  3. クラスター全体のプロキシーが有効になっている場合は、次のコマンドを実行して、NO_PROXY、HTTP_PROXY、および HTTPS_PROXY 環境変数をエクスポートします。

    Copy to Clipboard Toggle word wrap 
    $ export HTTP_PROXY=http://<your_proxy.example.com>:8080
     Copy to Clipboard Toggle word wrap 
    $ export HTTPS_PROXY=https://<your_proxy.example.com>:8080
     Copy to Clipboard Toggle word wrap 
    $ export NO_PROXY=<example.com>

  4. デバッグシェルで cluster-backup.sh スクリプトを実行し、バックアップの保存先となる場所を渡します。

    ヒント

    cluster-backup.sh スクリプトは etcd Cluster Operator のコンポーネントとして維持され、etcdctl snapshot save コマンドに関連するラッパーです。

    Copy to Clipboard Toggle word wrap 
    sh-4.4# /usr/local/bin/cluster-backup.sh /home/core/assets/backup

    スクリプトの出力例

    Copy to Clipboard Toggle word wrap 
    found latest kube-apiserver: /etc/kubernetes/static-pod-resources/kube-apiserver-pod-6
found latest kube-controller-manager: /etc/kubernetes/static-pod-resources/kube-controller-manager-pod-7
found latest kube-scheduler: /etc/kubernetes/static-pod-resources/kube-scheduler-pod-6
found latest etcd: /etc/kubernetes/static-pod-resources/etcd-pod-3
ede95fe6b88b87ba86a03c15e669fb4aa5bf0991c180d3c6895ce72eaade54a1
etcdctl version: 3.4.14
API version: 3.4
{"level":"info","ts":1624647639.0188997,"caller":"snapshot/v3_snapshot.go:119","msg":"created temporary db file","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db.part"}
{"level":"info","ts":"2021-06-25T19:00:39.030Z","caller":"clientv3/maintenance.go:200","msg":"opened snapshot stream; downloading"}
{"level":"info","ts":1624647639.0301006,"caller":"snapshot/v3_snapshot.go:127","msg":"fetching snapshot","endpoint":"https://10.0.0.5:2379"}
{"level":"info","ts":"2021-06-25T19:00:40.215Z","caller":"clientv3/maintenance.go:208","msg":"completed snapshot read; closing"}
{"level":"info","ts":1624647640.6032252,"caller":"snapshot/v3_snapshot.go:142","msg":"fetched snapshot","endpoint":"https://10.0.0.5:2379","size":"114 MB","took":1.584090459}
{"level":"info","ts":1624647640.6047094,"caller":"snapshot/v3_snapshot.go:152","msg":"saved","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db"}
Snapshot saved at /home/core/assets/backup/snapshot_2021-06-25_190035.db
{"hash":3866667823,"revision":31407,"totalKey":12828,"totalSize":114446336}
snapshot db and kube resources are successfully saved to /home/core/assets/backup

    この例では、コントロールプレーンホストの /home/core/assets/backup/ ディレクトリーにファイルが 2 つ作成されます。

    • snapshot_<datetimestamp>.db: このファイルは etcd スナップショットです。cluster-backup.sh スクリプトで、その有効性を確認します。

    • static_kuberesources_<datetimestamp>.tar.gz: このファイルには、静的 Pod のリソースが含まれます。etcd 暗号化が有効にされている場合、etcd スナップショットの暗号化キーも含まれます。

      注記

      etcd 暗号化が有効にされている場合、セキュリティー上の理由から、この 2 つ目のファイルを etcd スナップショットとは別に保存することが推奨されます。ただし、このファイルは etcd スナップショットから復元するために必要になります。

      etcd 暗号化はキーではなく値のみを暗号化することに注意してください。つまり、リソースタイプ、namespace、およびオブジェクト名は暗号化されません。

17.2.5.2.2. シングル etcd バックアップの作成

次の手順でカスタムリソース (CR) を作成して適用することで、シングル etcd バックアップを作成します。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) にアクセスできる。

手順

  • 動的にプロビジョニングされたストレージが利用可能な場合は、次の手順を実行して、単一の自動 etcd バックアップを作成します。

    1. 次の例のような内容で、etcd-backup-pvc.yaml という名前の永続ボリューム要求 (PVC) を作成します。

      Copy to Clipboard Toggle word wrap 
      kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: etcd-backup-pvc
  namespace: openshift-etcd
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 200Gi
      1 
      
  volumeMode: Filesystem
      1
      PVC に利用できるストレージの量。この値は、要件に合わせて調整します。

    2. 以下のコマンドを実行して PVC を適用します。

      Copy to Clipboard Toggle word wrap 
      $ oc apply -f etcd-backup-pvc.yaml

    3. 次のコマンドを実行して、PVC が作成されたことを確認します。

      Copy to Clipboard Toggle word wrap 
      $ oc get pvc

      出力例

      Copy to Clipboard Toggle word wrap 
      NAME              STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
etcd-backup-pvc   Bound                                                       51s

      注記

      動的 PVC は、マウントされるまで Pending 状態から遷移しません。

    4. 次の例のような内容で、etcd-single-backup.yaml という名前の CR ファイルを作成します。

      Copy to Clipboard Toggle word wrap 
      apiVersion: operator.openshift.io/v1alpha1
kind: EtcdBackup
metadata:
  name: etcd-single-backup
  namespace: openshift-etcd
spec:
  pvcName: etcd-backup-pvc
      1
      1
      バックアップを保存する PVC の名前。この値は、使用している環境に応じて調整してください。

    5. CR を適用してシングルバックアップを開始します。

      Copy to Clipboard Toggle word wrap 
      $ oc apply -f etcd-single-backup.yaml

  • 動的にプロビジョニングされたストレージが利用できない場合は、次の手順を実行して、単一の自動 etcd バックアップを作成します。

    1. 次の内容で、etcd-backup-local-storage.yaml という名前の StorageClass CR ファイルを作成します。

      Copy to Clipboard Toggle word wrap 
      apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: etcd-backup-local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: Immediate

    2. 次のコマンドを実行して、StorageClass CR を適用します。

      Copy to Clipboard Toggle word wrap 
      $ oc apply -f etcd-backup-local-storage.yaml

    3. 次の例のような内容の etcd-backup-pv-fs.yaml という名前の PV を作成します。

      Copy to Clipboard Toggle word wrap 
      apiVersion: v1
kind: PersistentVolume
metadata:
  name: etcd-backup-pv-fs
spec:
  capacity:
    storage: 100Gi
      1 
      
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: etcd-backup-local-storage
  local:
    path: /mnt
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
      - key: kubernetes.io/hostname
         operator: In
         values:
         - <example_master_node>
      2
      1
      PV が使用できるストレージの量。この値は、要件に合わせて調整します。
      2
      この値は、この PV を割り当てるノードに置き換えます。

    4. 次のコマンドを実行して、PV が作成されたことを確認します。

      Copy to Clipboard Toggle word wrap 
      $ oc get pv

      出力例

      Copy to Clipboard Toggle word wrap 
      NAME                    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS                REASON   AGE
etcd-backup-pv-fs       100Gi      RWO            Retain           Available           etcd-backup-local-storage            10s

    5. 次の例のような内容で、etcd-backup-pvc.yaml という名前の PVC を作成します。

      Copy to Clipboard Toggle word wrap 
      kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: etcd-backup-pvc
  namespace: openshift-etcd
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 10Gi
      1
      1
      PVC に利用できるストレージの量。この値は、要件に合わせて調整します。

    6. 以下のコマンドを実行して PVC を適用します。

      Copy to Clipboard Toggle word wrap 
      $ oc apply -f etcd-backup-pvc.yaml

    7. 次の例のような内容で、etcd-single-backup.yaml という名前の CR ファイルを作成します。

      Copy to Clipboard Toggle word wrap 
      apiVersion: operator.openshift.io/v1alpha1
kind: EtcdBackup
metadata:
  name: etcd-single-backup
  namespace: openshift-etcd
spec:
  pvcName: etcd-backup-pvc
      1
      1
      バックアップを保存する永続ボリューム要求 (PVC) の名前。この値は、使用している環境に応じて調整してください。

    8. CR を適用してシングルバックアップを開始します。

      Copy to Clipboard Toggle word wrap 
      $ oc apply -f etcd-single-backup.yaml

関連情報

17.2.5.3. クラスターの健全性の確認

更新時には、クラスターの健全性を頻繁に確認する必要があります。ノードのステータス、クラスター Operator のステータス、失敗した Pod を確認します。

手順

  1. 次のコマンドを実行して、クラスター Operator のステータスを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get co

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication                             4.14.34   True        False         False      4d22h
baremetal                                  4.14.34   True        False         False      4d22h
cloud-controller-manager                   4.14.34   True        False         False      4d23h
cloud-credential                           4.14.34   True        False         False      4d23h
cluster-autoscaler                         4.14.34   True        False         False      4d22h
config-operator                            4.14.34   True        False         False      4d22h
console                                    4.14.34   True        False         False      4d22h
...
service-ca                                 4.14.34   True        False         False      4d22h
storage                                    4.14.34   True        False         False      4d22h

  2. クラスターノードのステータスを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get nodes

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME           STATUS   ROLES                  AGE     VERSION
ctrl-plane-0   Ready    control-plane,master   4d22h   v1.27.15+6147456
ctrl-plane-1   Ready    control-plane,master   4d22h   v1.27.15+6147456
ctrl-plane-2   Ready    control-plane,master   4d22h   v1.27.15+6147456
worker-0       Ready    mcp-1,worker           4d22h   v1.27.15+6147456
worker-1       Ready    mcp-2,worker           4d22h   v1.27.15+6147456

  3. 進行中の Pod や失敗した Pod がないことを確認します。次のコマンドを実行したときに、Pod が 1 つも返されないようにします。

    Copy to Clipboard Toggle word wrap 
    $ oc get po -A | grep -E -iv 'running|complete'

17.2.6. コントロールプレーンのみのクラスター更新の完了

次の手順に従って、コントロールプレーンのみのクラスター更新を実行し、更新が完了するまで監視します。

重要

コントロールプレーンのみの更新は、以前は EUS から EUS への更新と呼ばれていました。コントロールプレーンのみの更新は、OpenShift Container Platform の偶数番号のマイナーバージョン間でのみ実行可能です。

17.2.6.1. コントロールプレーンのみまたは y-stream の更新の承認

4.11 以降のすべてのバージョンに更新する場合は、更新の続行を手動で承認する必要があります。

重要

更新を承認する前に、更新先のバージョンで削除されている Kubernetes API を使用していないことを確認してください。たとえば、OpenShift Container Platform 4.17 では、API の削除はありません。詳細は、「Kubernetes API の削除」を参照してください。

前提条件

  • クラスターで実行されているすべてのアプリケーションの API が、OpenShift Container Platform の次期 y-stream リリースと互換性があることを確認した。互換性の詳細は、「更新バージョン間のクラスター API バージョンの検証」を参照してください。

手順

  • 次のコマンドを実行して、管理者としての承認を完了し、クラスターの更新を開始します。

    Copy to Clipboard Toggle word wrap 
    $ oc adm upgrade

    クラスターの更新が正常に完了しない場合は、Reason および Message セクションに更新の失敗に関する詳細が表示されます。

    出力例

    Copy to Clipboard Toggle word wrap 
    Cluster version is 4.15.45

Upgradeable=False

  Reason: MultipleReasons
  Message: Cluster should not be upgraded between minor versions for multiple reasons: AdminAckRequired,ResourceDeletesInProgress
  * Kubernetes 1.29 and therefore OpenShift 4.16 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/7031404 for details and instructions.
  * Cluster minor level upgrades are not allowed while resource deletions are in progress; resources=PrometheusRule "openshift-kube-apiserver/kube-apiserver-recording-rules"

ReleaseAccepted=False

  Reason: PreconditionChecks
  Message: Preconditions failed for payload loaded version="4.16.34" image="quay.io/openshift-release-dev/ocp-release@sha256:41bb08c560f6db5039ccdf242e590e8b23049b5eb31e1c4f6021d1d520b353b8": Precondition "ClusterVersionUpgradeable" failed because of "MultipleReasons": Cluster should not be upgraded between minor versions for multiple reasons: AdminAckRequired,ResourceDeletesInProgress
  * Kubernetes 1.29 and therefore OpenShift 4.16 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/7031404 for details and instructions.
  * Cluster minor level upgrades are not allowed while resource deletions are in progress; resources=PrometheusRule "openshift-kube-apiserver/kube-apiserver-recording-rules"

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

Recommended updates:

  VERSION     IMAGE
  4.16.34     quay.io/openshift-release-dev/ocp-release@sha256:41bb08c560f6db5039ccdf242e590e8b23049b5eb31e1c4f6021d1d520b353b8

    注記

    この例については、Red Hat のナレッジベース記事 (Preparing to upgrade to OpenShift Container Platform 4.16) に、リリース間の API 互換性の検証に関する詳細が記載されています。

検証

  • 次のコマンドを実行して更新を確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get configmap admin-acks -n openshift-config -o json | jq .data

    出力例

    Copy to Clipboard Toggle word wrap 
    {
  "ack-4.14-kube-1.28-api-removals-in-4.15": "true",
  "ack-4.15-kube-1.29-api-removals-in-4.16": "true"
}

    注記

    この例では、コントロールプレーンのみの更新で、クラスターをバージョン 4.14 から 4.15 に更新してから、4.15 から 4.16 に更新します。

関連情報

17.2.6.2. クラスターの更新の開始

ある y-stream リリースから次のリリースに更新する場合、中間の z-stream リリースにも互換性があることを確認する必要があります。

注記

oc adm upgrade コマンドを実行すると、更新先のリリースが実行可能なリリースであることを確認できます。oc adm upgrade コマンドは、互換性のある更新リリースをリスト表示します。

手順

  1. 更新を開始します。

    Copy to Clipboard Toggle word wrap 
    $ oc adm upgrade --to=4.15.33
    重要
    • コントロールプレーンのみの更新: 中間の <y+1> リリースパスを指定します。
    • y-stream 更新 - Kubernetes バージョンスキューポリシー に準拠した正しい <y.z> リリースを使用していることを確認します。
    • z-stream の更新 - 特定のリリースへの移行に問題がないことを確認します。

    出力例

    Copy to Clipboard Toggle word wrap 
    Requested update to 4.15.33
    1

    1
    Requested update 値は、実際の更新に応じて変わります。

関連情報

17.2.6.3. クラスターの更新の監視

更新時には、クラスターの健全性を頻繁に確認する必要があります。ノードのステータス、クラスター Operator のステータス、失敗した Pod を確認します。

手順

  • クラスターの更新を監視します。たとえば、バージョン 4.14 から 4.15 へのクラスターの更新を監視するには、次のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ watch "oc get clusterversion; echo; oc get co | head -1; oc get co | grep 4.14; oc get co | grep 4.15; echo; oc get no; echo; oc get po -A | grep -E -iv 'running|complete'"

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.14.34   True        True          4m6s    Working towards 4.15.33: 111 of 873 done (12% complete), waiting on kube-apiserver

NAME                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication                 4.14.34   True        False         False      4d22h
baremetal                      4.14.34   True        False         False      4d23h
cloud-controller-manager       4.14.34   True        False         False      4d23h
cloud-credential               4.14.34   True        False         False      4d23h
cluster-autoscaler             4.14.34   True        False         False      4d23h
console                        4.14.34   True        False         False      4d22h

...

storage                        4.14.34   True        False         False      4d23h
config-operator                4.15.33   True        False         False      4d23h
etcd                           4.15.33   True        False         False      4d23h

NAME           STATUS   ROLES                  AGE     VERSION
ctrl-plane-0   Ready    control-plane,master   4d23h   v1.27.15+6147456
ctrl-plane-1   Ready    control-plane,master   4d23h   v1.27.15+6147456
ctrl-plane-2   Ready    control-plane,master   4d23h   v1.27.15+6147456
worker-0       Ready    mcp-1,worker           4d23h   v1.27.15+6147456
worker-1       Ready    mcp-2,worker           4d23h   v1.27.15+6147456

NAMESPACE               NAME                       READY   STATUS              RESTARTS   AGE
openshift-marketplace   redhat-marketplace-rf86t   0/1     ContainerCreating   0          0s

検証

更新中、この watch コマンドは、一度に 1 つまたは複数のクラスター Operator を循環し、MESSAGE 列に Operator 更新のステータスを表示します。

クラスター Operator の更新プロセスが完了すると、各コントロールプレーンノードが 1 つずつ再起動します。

注記

更新のこの部分で、クラスター Operator が再度更新中であることやデグレード状態であることを示すメッセージが報告されます。これは、ノードを再起動している間、コントロールプレーンノードがオフラインになるためです。

最後のコントロールプレーンノードの再起動が完了するとすぐに、更新されたクラスターのバージョンが表示されます。

コントロールプレーンの更新が完了すると、次のようなメッセージが表示されます。この例では、中間の y-stream リリースへの更新が完了したことを示しています。

Copy to Clipboard Toggle word wrap 
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.15.33   True        False         28m     Cluster version is 4.15.33

NAME                         VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication               4.15.33   True        False         False	  5d
baremetal                    4.15.33   True        False         False	  5d
cloud-controller-manager     4.15.33   True        False         False	  5d1h
cloud-credential             4.15.33   True        False         False	  5d1h
cluster-autoscaler           4.15.33   True        False         False	  5d
config-operator              4.15.33   True        False         False	  5d
console                      4.15.33   True        False         False	  5d

...

service-ca                   4.15.33   True        False         False	  5d
storage                      4.15.33   True        False         False	  5d

NAME           STATUS   ROLES                  AGE   VERSION
ctrl-plane-0   Ready    control-plane,master   5d    v1.28.13+2ca1a23
ctrl-plane-1   Ready    control-plane,master   5d    v1.28.13+2ca1a23
ctrl-plane-2   Ready    control-plane,master   5d    v1.28.13+2ca1a23
worker-0       Ready    mcp-1,worker           5d    v1.28.13+2ca1a23
worker-1       Ready    mcp-2,worker           5d    v1.28.13+2ca1a23

17.2.6.4. OLM Operator の更新

通信事業者の環境では、ソフトウェアを実稼働クラスターにロードする前に検査する必要があります。また、実稼働クラスターが非接続ネットワーク内で設定されるため、必ずしもインターネットに直接接続されているわけではありません。クラスターが非接続ネットワーク内にあるため、新しいバージョンをクラスターごとに管理できるように、インストール時に OpenShift Operator を手動で更新するように設定します。Operator を新しいバージョンに移行するには、次の手順を実行します。

手順

  1. 更新する必要がある Operator を確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get installplan -A | grep -E 'APPROVED|false'

    出力例

    Copy to Clipboard Toggle word wrap 
    NAMESPACE           NAME            CSV                                               APPROVAL   APPROVED
metallb-system      install-nwjnh   metallb-operator.v4.16.0-202409202304             Manual     false
openshift-nmstate   install-5r7wr   kubernetes-nmstate-operator.4.16.0-202409251605   Manual     false

  2. これらの Operator の InstallPlan リソースにパッチを適用します。

    Copy to Clipboard Toggle word wrap 
    $ oc patch installplan -n metallb-system install-nwjnh --type merge --patch \
'{"spec":{"approved":true}}'

    出力例

    Copy to Clipboard Toggle word wrap 
    installplan.operators.coreos.com/install-nwjnh patched

  3. 次のコマンドを実行して namespace を監視します。

    Copy to Clipboard Toggle word wrap 
    $ oc get all -n metallb-system

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                                                       READY   STATUS              RESTARTS   AGE
pod/metallb-operator-controller-manager-69b5f884c-8bp22    0/1     ContainerCreating   0          4s
pod/metallb-operator-controller-manager-77895bdb46-bqjdx   1/1     Running             0          4m1s
pod/metallb-operator-webhook-server-5d9b968896-vnbhk       0/1     ContainerCreating   0          4s
pod/metallb-operator-webhook-server-d76f9c6c8-57r4w        1/1     Running             0          4m1s

...

NAME                                                             DESIRED   CURRENT   READY   AGE
replicaset.apps/metallb-operator-controller-manager-69b5f884c    1         1         0       4s
replicaset.apps/metallb-operator-controller-manager-77895bdb46   1         1         1       4m1s
replicaset.apps/metallb-operator-controller-manager-99b76f88     0         0         0       4m40s
replicaset.apps/metallb-operator-webhook-server-5d9b968896       1         1         0       4s
replicaset.apps/metallb-operator-webhook-server-6f7dbfdb88       0         0         0       4m40s
replicaset.apps/metallb-operator-webhook-server-d76f9c6c8        1         1         1       4m1s

    更新が完了すると、必要な Pod が Running 状態になり、必要な ReplicaSet リソースが準備完了になるはずです。

    Copy to Clipboard Toggle word wrap 
    NAME                                                      READY   STATUS    RESTARTS   AGE
pod/metallb-operator-controller-manager-69b5f884c-8bp22   1/1     Running   0          25s
pod/metallb-operator-webhook-server-5d9b968896-vnbhk      1/1     Running   0          25s

...

NAME                                                             DESIRED   CURRENT   READY   AGE
replicaset.apps/metallb-operator-controller-manager-69b5f884c    1         1         1       25s
replicaset.apps/metallb-operator-controller-manager-77895bdb46   0         0         0       4m22s
replicaset.apps/metallb-operator-webhook-server-5d9b968896       1         1         1       25s
replicaset.apps/metallb-operator-webhook-server-d76f9c6c8        0         0         0       4m22s

検証

  • Operator を再度更新する必要がないことを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get installplan -A | grep -E 'APPROVED|false'

    出力は返されないはずです。

    注記

    Operator によっては、最終バージョンの前にインストールする必要がある中間の z-stream リリースバージョンがあるため、更新を 2 回承認する必要がある場合があります。

関連情報

17.2.6.4.1. 2 回目の y-stream 更新の実行

最初の y-stream 更新を完了したら、y-stream のコントロールプレーンのバージョンを新しい EUS バージョンに更新する必要があります。

手順

  1. 選択した <4.y.z> リリースが、適切な移行先チャネルとして現在もリスト表示されることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc adm upgrade

    出力例

    Copy to Clipboard Toggle word wrap 
    Cluster version is 4.15.33

Upgradeable=False

  Reason: AdminAckRequired
  Message: Kubernetes 1.29 and therefore OpenShift 4.16 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/7031404 for details and instructions.

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

Recommended updates:

  VERSION     IMAGE
  4.16.14     quay.io/openshift-release-dev/ocp-release@sha256:0521a0f1acd2d1b77f76259cb9bae9c743c60c37d9903806a3372c1414253658
  4.16.13     quay.io/openshift-release-dev/ocp-release@sha256:6078cb4ae197b5b0c526910363b8aff540343bfac62ecb1ead9e068d541da27b
  4.15.34     quay.io/openshift-release-dev/ocp-release@sha256:f2e0c593f6ed81250c11d0bac94dbaf63656223477b7e8693a652f933056af6e

    注記

    新しい y-stream リリースの最初の GA 直後に更新すると、oc adm upgrade コマンドを実行したときに、利用可能な新しい y-stream リリースが表示されない場合があります。

  2. オプション: 推奨されない更新リリースの候補を表示します。以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc adm upgrade --include-not-recommended

    出力例

    Copy to Clipboard Toggle word wrap 
    Cluster version is 4.15.33

Upgradeable=False

  Reason: AdminAckRequired
  Message: Kubernetes 1.29 and therefore OpenShift 4.16 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/7031404 for details and instructions.

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

Recommended updates:

  VERSION     IMAGE
  4.16.14     quay.io/openshift-release-dev/ocp-release@sha256:0521a0f1acd2d1b77f76259cb9bae9c743c60c37d9903806a3372c1414253658
  4.16.13     quay.io/openshift-release-dev/ocp-release@sha256:6078cb4ae197b5b0c526910363b8aff540343bfac62ecb1ead9e068d541da27b
  4.15.34     quay.io/openshift-release-dev/ocp-release@sha256:f2e0c593f6ed81250c11d0bac94dbaf63656223477b7e8693a652f933056af6e

Supported but not recommended updates:

  Version: 4.16.15
  Image: quay.io/openshift-release-dev/ocp-release@sha256:671bc35e
  Recommended: Unknown
  Reason: EvaluationFailed
  Message: Exposure to AzureRegistryImagePreservation is unknown due to an evaluation failure: invalid PromQL result length must be one, but is 0
  In Azure clusters, the in-cluster image registry may fail to preserve images on update. https://issues.redhat.com/browse/IR-461

    注記

    この例では、Microsoft Azure でホストされているクラスターに影響を与える可能性のある潜在的なエラーが示されています。ベアメタルクラスターのリスクは示されていません。

17.2.6.4.2. y-stream リリースの更新の承認

y-stream リリース間で移行する場合、更新を明示的に承認するために patch コマンドを実行する必要があります。oc adm upgrade コマンドの出力に、実行する特定のコマンドを示す URL が表示されます。

重要

更新を承認する前に、更新先のバージョンで削除されている Kubernetes API を使用していないことを確認してください。たとえば、OpenShift Container Platform 4.17 では、API の削除はありません。詳細は、「Kubernetes API の削除」を参照してください。

前提条件

  • クラスターで実行されているすべてのアプリケーションの API が、OpenShift Container Platform の次期 y-stream リリースと互換性があることを確認した。互換性の詳細は、「更新バージョン間のクラスター API バージョンの検証」を参照してください。

手順

  • 次のコマンドを実行して、管理者としての承認を完了し、クラスターの更新を開始します。

    Copy to Clipboard Toggle word wrap 
    $ oc adm upgrade

    クラスターの更新が正常に完了しない場合は、Reason および Message セクションに更新の失敗に関する詳細が表示されます。

    出力例

    Copy to Clipboard Toggle word wrap 
    Cluster version is 4.15.45

Upgradeable=False

  Reason: MultipleReasons
  Message: Cluster should not be upgraded between minor versions for multiple reasons: AdminAckRequired,ResourceDeletesInProgress
  * Kubernetes 1.29 and therefore OpenShift 4.16 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/7031404 for details and instructions.
  * Cluster minor level upgrades are not allowed while resource deletions are in progress; resources=PrometheusRule "openshift-kube-apiserver/kube-apiserver-recording-rules"

ReleaseAccepted=False

  Reason: PreconditionChecks
  Message: Preconditions failed for payload loaded version="4.16.34" image="quay.io/openshift-release-dev/ocp-release@sha256:41bb08c560f6db5039ccdf242e590e8b23049b5eb31e1c4f6021d1d520b353b8": Precondition "ClusterVersionUpgradeable" failed because of "MultipleReasons": Cluster should not be upgraded between minor versions for multiple reasons: AdminAckRequired,ResourceDeletesInProgress
  * Kubernetes 1.29 and therefore OpenShift 4.16 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/7031404 for details and instructions.
  * Cluster minor level upgrades are not allowed while resource deletions are in progress; resources=PrometheusRule "openshift-kube-apiserver/kube-apiserver-recording-rules"

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

Recommended updates:

  VERSION     IMAGE
  4.16.34     quay.io/openshift-release-dev/ocp-release@sha256:41bb08c560f6db5039ccdf242e590e8b23049b5eb31e1c4f6021d1d520b353b8

    注記

    この例については、Red Hat のナレッジベース記事 (Preparing to upgrade to OpenShift Container Platform 4.16) に、リリース間の API 互換性の検証に関する詳細が記載されています。

検証

  • 次のコマンドを実行して更新を確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get configmap admin-acks -n openshift-config -o json | jq .data

    出力例

    Copy to Clipboard Toggle word wrap 
    {
  "ack-4.14-kube-1.28-api-removals-in-4.15": "true",
  "ack-4.15-kube-1.29-api-removals-in-4.16": "true"
}

    注記

    この例では、コントロールプレーンのみの更新で、クラスターをバージョン 4.14 から 4.15 に更新してから、4.15 から 4.16 に更新します。

関連情報

17.2.6.5. y-stream コントロールプレーンの更新の開始

移行先の完全な新しいリリースを決定したら、oc adm upgrade –to=x.y.z コマンドを実行できます。

手順

  • y-stream コントロールプレーンの更新を開始します。たとえば、以下のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ oc adm upgrade --to=4.16.14

    出力例

    Copy to Clipboard Toggle word wrap 
    Requested update to 4.16.14

    移行先の z-stream リリースに、使用中のプラットフォーム以外のプラットフォームに関する問題がある場合があります。次の例は、Microsoft Azure でのクラスター更新の潜在的な問題を示しています。

    Copy to Clipboard Toggle word wrap 
    $ oc adm upgrade --to=4.16.15

    出力例

    Copy to Clipboard Toggle word wrap 
    error: the update 4.16.15 is not one of the recommended updates, but is available as a conditional update. To accept the Recommended=Unknown risk and to proceed with update use --allow-not-recommended.
  Reason: EvaluationFailed
  Message: Exposure to AzureRegistryImagePreservation is unknown due to an evaluation failure: invalid PromQL result length must be one, but is 0
  In Azure clusters, the in-cluster image registry may fail to preserve images on update. https://issues.redhat.com/browse/IR-461

    注記

    この例では、Microsoft Azure でホストされているクラスターに影響を与える可能性のある潜在的なエラーが示されています。ベアメタルクラスターのリスクは示されていません。

    Copy to Clipboard Toggle word wrap 
    $ oc adm upgrade --to=4.16.15 --allow-not-recommended

    出力例

    Copy to Clipboard Toggle word wrap 
    warning: with --allow-not-recommended you have accepted the risks with 4.14.11 and bypassed Recommended=Unknown EvaluationFailed: Exposure to AzureRegistryImagePreservation is unknown due to an evaluation failure: invalid PromQL result length must be one, but is 0
In Azure clusters, the in-cluster image registry may fail to preserve images on update. https://issues.redhat.com/browse/IR-461

Requested update to 4.16.15

17.2.6.6. <y+1> クラスター更新の 2 番目の部分を監視する

クラスターの 2 番目の部分が <y+1> バージョンに更新される様子を監視します。

手順

  • <y+1> 更新の 2 番目の部分の進行状況を監視します。たとえば、4.15 から 4.16 への更新を監視するには、次のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ watch "oc get clusterversion; echo; oc get co | head -1; oc get co | grep 4.15; oc get co | grep 4.16; echo; oc get no; echo; oc get po -A | grep -E -iv 'running|complete'"

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.15.33   True        True          10m     Working towards 4.16.14: 132 of 903 done (14% complete), waiting on kube-controller-manager, kube-scheduler

NAME                         VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication               4.15.33   True        False         False      5d3h
baremetal                    4.15.33   True        False         False      5d4h
cloud-controller-manager     4.15.33   True        False         False      5d4h
cloud-credential             4.15.33   True        False         False      5d4h
cluster-autoscaler           4.15.33   True        False         False      5d4h
console                      4.15.33   True        False         False      5d3h
...
config-operator              4.16.14   True        False         False      5d4h
etcd                         4.16.14   True        False         False      5d4h
kube-apiserver               4.16.14   True        True          False      5d4h    NodeInstallerProgressing: 1 node is at revision 15; 2 nodes are at revision 17

NAME           STATUS   ROLES                  AGE    VERSION
ctrl-plane-0   Ready    control-plane,master   5d4h   v1.28.13+2ca1a23
ctrl-plane-1   Ready    control-plane,master   5d4h   v1.28.13+2ca1a23
ctrl-plane-2   Ready    control-plane,master   5d4h   v1.28.13+2ca1a23
worker-0       Ready    mcp-1,worker           5d4h   v1.27.15+6147456
worker-1       Ready    mcp-2,worker           5d4h   v1.27.15+6147456

NAMESPACE                                          NAME                                                              READY   STATUS      RESTARTS       AGE
openshift-kube-apiserver                           kube-apiserver-ctrl-plane-0                                       0/5     Pending     0              <invalid>

    最のコ後ントロールプレーンノードが完了すると、クラスターのバージョンが新しい EUS リリースにすぐに更新されます。以下に例を示します。

    Copy to Clipboard Toggle word wrap 
    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.16.14   True        False         123m    Cluster version is 4.16.14

NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication                             4.16.14   True        False         False	  5d6h
baremetal                                  4.16.14   True        False         False	  5d7h
cloud-controller-manager                   4.16.14   True        False         False	  5d7h
cloud-credential                           4.16.14   True        False         False	  5d7h
cluster-autoscaler                         4.16.14   True        False         False	  5d7h
config-operator                            4.16.14   True        False         False	  5d7h
console                                    4.16.14   True        False         False	  5d6h
#...
operator-lifecycle-manager-packageserver   4.16.14   True        False         False	  5d7h
service-ca                                 4.16.14   True        False         False	  5d7h
storage                                    4.16.14   True        False         False	  5d7h

NAME           STATUS   ROLES                  AGE     VERSION
ctrl-plane-0   Ready    control-plane,master   5d7h    v1.29.8+f10c92d
ctrl-plane-1   Ready    control-plane,master   5d7h    v1.29.8+f10c92d
ctrl-plane-2   Ready    control-plane,master   5d7h    v1.29.8+f10c92d
worker-0       Ready    mcp-1,worker           5d7h    v1.27.15+6147456
worker-1       Ready    mcp-2,worker           5d7h    v1.27.15+6147456

関連情報

17.2.6.7. すべての OLM Operator の更新

複数バージョンのアップグレードの第 2 フェーズとして、すべての Operator を承認し、アップグレードするその他の Operator のインストールプランをさらに追加する必要があります。

「OLM Operator の更新」で説明されているのと同じ手順に従います。必要に応じて、OLM 以外の Operator も更新してください。

手順

  1. クラスターの更新を監視します。たとえば、バージョン 4.14 から 4.15 へのクラスターの更新を監視するには、次のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ watch "oc get clusterversion; echo; oc get co | head -1; oc get co | grep 4.14; oc get co | grep 4.15; echo; oc get no; echo; oc get po -A | grep -E -iv 'running|complete'"

  2. 更新する必要がある Operator を確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get installplan -A | grep -E 'APPROVED|false'

  3. これらの Operator の InstallPlan リソースにパッチを適用します。

    Copy to Clipboard Toggle word wrap 
    $ oc patch installplan -n metallb-system install-nwjnh --type merge --patch \
'{"spec":{"approved":true}}'

  4. 次のコマンドを実行して namespace を監視します。

    Copy to Clipboard Toggle word wrap 
    $ oc get all -n metallb-system

    更新が完了すると、必要な Pod が Running 状態になり、必要な ReplicaSet リソースが準備完了になるはずです。

検証

更新中、この watch コマンドは、一度に 1 つまたは複数のクラスター Operator を循環し、MESSAGE 列に Operator 更新のステータスを表示します。

クラスター Operator の更新プロセスが完了すると、各コントロールプレーンノードが 1 つずつ再起動します。

注記

更新のこの部分で、クラスター Operator が再度更新中であることやデグレード状態であることを示すメッセージが報告されます。これは、ノードを再起動している間、コントロールプレーンノードがオフラインになるためです。

関連情報

17.2.6.8. ワーカーノードの更新

コントロールプレーンを更新した後、作成した適切な mcp グループの一時停止を解除してワーカーノードをアップグレードします。mcp グループの一時停止を解除すると、そのグループ内のワーカーノードのアップグレードプロセスが開始します。クラスター内の各ワーカーノードが再起動し、必要に応じて新しい EUS、y-stream、または z-stream バージョンにアップグレードされます。

コントロールプレーンのみのアップグレードの場合、ワーカーノードの更新時に、再起動が 1 回だけ必要になり、ワーカーノードが <y+2> リリースバージョンにジャンプします。これは、大規模なベアメタルクラスターのアップグレードにかかる時間を短縮するために追加された機能です。

重要

この時点で保留することも可能です。ワーカーノードが <y-2> リリースであっても、新しい EUS リリースに更新したコントロールプレーンを使用して、実稼働環境での実行が完全にサポートされているクラスターバージョンを提供できます。これにより、大規模なクラスターを複数のメンテナンス期間にわたって段階的にアップグレードできます。

  1. mcp グループ内で管理されているノードの数を確認できます。次のコマンドを実行して、mcp グループのリストを取得します。

    Copy to Clipboard Toggle word wrap 
    $ oc get mcp

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-c9a52144456dbff9c9af9c5a37d1b614   True      False      False      3              3                   3                     0                      36d
mcp-1    rendered-mcp-1-07fe50b9ad51fae43ed212e84e1dcc8e    False     False      False      1              0                   0                     0                      47h
mcp-2    rendered-mcp-2-07fe50b9ad51fae43ed212e84e1dcc8e    False     False      False      1              0                   0                     0                      47h
worker   rendered-worker-f1ab7b9a768e1b0ac9290a18817f60f0   True      False      False      0              0                   0                     0                      36d

    注記

    一度にアップグレードする mcp グループの数を決定してください。これは、一度に停止できる CNF Pod の数、および Pod Disruption Budget とアンチアフィニティーの設定よって異なります。

  2. クラスター内のノードのリストを取得します。

    Copy to Clipboard Toggle word wrap 
    $ oc get nodes

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME           STATUS   ROLES                  AGE    VERSION
ctrl-plane-0   Ready    control-plane,master   5d8h   v1.29.8+f10c92d
ctrl-plane-1   Ready    control-plane,master   5d8h   v1.29.8+f10c92d
ctrl-plane-2   Ready    control-plane,master   5d8h   v1.29.8+f10c92d
worker-0       Ready    mcp-1,worker           5d8h   v1.27.15+6147456
worker-1       Ready    mcp-2,worker           5d8h   v1.27.15+6147456

  3. 一時停止中の MachineConfigPool グループを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker

    出力例

    Copy to Clipboard Toggle word wrap 
    MCP     Paused
---     ------
master  false
mcp-1   true
mcp-2   true

    注記

    MachineConfigPool は、それぞれ個別に一時停止解除できます。したがって、メンテナンス期間の残り時間がなくなった場合でも、他の MCP をすぐに一時停止解除する必要はありません。クラスターは、一部のワーカーノードをまだ <y-2> リリースバージョンのまま実行できます。

  4. 必要な mcp グループを一時停止解除して、アップグレードを開始します。

    Copy to Clipboard Toggle word wrap 
    $ oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":false}}'

    出力例

    Copy to Clipboard Toggle word wrap 
    machineconfigpool.machineconfiguration.openshift.io/mcp-1 patched

  5. 必要な mcp グループが一時停止解除されていることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker

    出力例

    Copy to Clipboard Toggle word wrap 
    MCP     Paused
---     ------
master  false
mcp-1   false
mcp-2   true

  6. 各 mcp グループがアップグレードされたら、残りのノードを一時停止解除してアップグレードを続けます。

    Copy to Clipboard Toggle word wrap 
    $ oc get nodes

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME           STATUS                        ROLES                  AGE    VERSION
ctrl-plane-0   Ready                         control-plane,master   5d8h   v1.29.8+f10c92d
ctrl-plane-1   Ready                         control-plane,master   5d8h   v1.29.8+f10c92d
ctrl-plane-2   Ready                         control-plane,master   5d8h   v1.29.8+f10c92d
worker-0       Ready                         mcp-1,worker           5d8h   v1.29.8+f10c92d
worker-1       NotReady,SchedulingDisabled   mcp-2,worker           5d8h   v1.27.15+6147456

17.2.6.9. 新しく更新されたクラスターの健全性の確認

クラスターを更新した後、次のコマンドを実行して、クラスターが再び稼働していることを確認します。

手順

  1. 次のコマンドを実行してクラスターのバージョンを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get clusterversion

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.16.14   True        False         4h38m   Cluster version is 4.16.14

    新しいクラスターバージョンが返され、PROGRESSING 列に False が返されるはずです。

  2. すべてのノードが準備完了であることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get nodes

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME           STATUS   ROLES                  AGE    VERSION
ctrl-plane-0   Ready    control-plane,master   5d9h   v1.29.8+f10c92d
ctrl-plane-1   Ready    control-plane,master   5d9h   v1.29.8+f10c92d
ctrl-plane-2   Ready    control-plane,master   5d9h   v1.29.8+f10c92d
worker-0       Ready    mcp-1,worker           5d9h   v1.29.8+f10c92d
worker-1       Ready    mcp-2,worker           5d9h   v1.29.8+f10c92d

    クラスター内のすべてのノードが Ready ステータスで、同じバージョンを実行しているはずです。

  3. クラスター内に一時停止中の mcp リソースがないことを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker

    出力例

    Copy to Clipboard Toggle word wrap 
    MCP     Paused
---     ------
master  false
mcp-1   false
mcp-2   false

  4. すべてのクラスター Operator が利用可能であることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get co

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication                             4.16.14   True        False         False      5d9h
baremetal                                  4.16.14   True        False         False      5d9h
cloud-controller-manager                   4.16.14   True        False         False      5d10h
cloud-credential                           4.16.14   True        False         False      5d10h
cluster-autoscaler                         4.16.14   True        False         False      5d9h
config-operator                            4.16.14   True        False         False      5d9h
console                                    4.16.14   True        False         False      5d9h
control-plane-machine-set                  4.16.14   True        False         False      5d9h
csi-snapshot-controller                    4.16.14   True        False         False      5d9h
dns                                        4.16.14   True        False         False      5d9h
etcd                                       4.16.14   True        False         False      5d9h
image-registry                             4.16.14   True        False         False      85m
ingress                                    4.16.14   True        False         False      5d9h
insights                                   4.16.14   True        False         False      5d9h
kube-apiserver                             4.16.14   True        False         False      5d9h
kube-controller-manager                    4.16.14   True        False         False      5d9h
kube-scheduler                             4.16.14   True        False         False      5d9h
kube-storage-version-migrator              4.16.14   True        False         False      4h48m
machine-api                                4.16.14   True        False         False      5d9h
machine-approver                           4.16.14   True        False         False      5d9h
machine-config                             4.16.14   True        False         False      5d9h
marketplace                                4.16.14   True        False         False      5d9h
monitoring                                 4.16.14   True        False         False      5d9h
network                                    4.16.14   True        False         False      5d9h
node-tuning                                4.16.14   True        False         False      5d7h
openshift-apiserver                        4.16.14   True        False         False      5d9h
openshift-controller-manager               4.16.14   True        False         False      5d9h
openshift-samples                          4.16.14   True        False         False      5h24m
operator-lifecycle-manager                 4.16.14   True        False         False      5d9h
operator-lifecycle-manager-catalog         4.16.14   True        False         False      5d9h
operator-lifecycle-manager-packageserver   4.16.14   True        False         False      5d9h
service-ca                                 4.16.14   True        False         False      5d9h
storage                                    4.16.14   True        False         False      5d9h

    すべてのクラスター Operator の AVAILABLE 列に True と報告されるはずです。

  5. すべての Pod が正常であることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get po -A | grep -E -iv 'complete|running'

    Pod は 1 つも返されないはずです。

    注記

    更新後もまだ移行中の Pod がいくつか見られる場合があります。しばらくこれを監視して、すべての Pod がクリアされることを確認してください。

17.2.7. y-stream クラスターの更新の完了

次の手順に従って、y-stream クラスターの更新を実行し、更新が完了するまで監視します。y-stream 更新の完了は、コントロールプレーンのみの更新よりも簡単です。

17.2.7.1. コントロールプレーンのみまたは y-stream の更新の承認

4.11 以降のすべてのバージョンに更新する場合は、更新の続行を手動で承認する必要があります。

重要

更新を承認する前に、更新先のバージョンで削除されている Kubernetes API を使用していないことを確認してください。たとえば、OpenShift Container Platform 4.17 では、API の削除はありません。詳細は、「Kubernetes API の削除」を参照してください。

前提条件

  • クラスターで実行されているすべてのアプリケーションの API が、OpenShift Container Platform の次期 y-stream リリースと互換性があることを確認した。互換性の詳細は、「更新バージョン間のクラスター API バージョンの検証」を参照してください。

手順

  • 次のコマンドを実行して、管理者としての承認を完了し、クラスターの更新を開始します。

    Copy to Clipboard Toggle word wrap 
    $ oc adm upgrade

    クラスターの更新が正常に完了しない場合は、Reason および Message セクションに更新の失敗に関する詳細が表示されます。

    出力例

    Copy to Clipboard Toggle word wrap 
    Cluster version is 4.15.45

Upgradeable=False

  Reason: MultipleReasons
  Message: Cluster should not be upgraded between minor versions for multiple reasons: AdminAckRequired,ResourceDeletesInProgress
  * Kubernetes 1.29 and therefore OpenShift 4.16 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/7031404 for details and instructions.
  * Cluster minor level upgrades are not allowed while resource deletions are in progress; resources=PrometheusRule "openshift-kube-apiserver/kube-apiserver-recording-rules"

ReleaseAccepted=False

  Reason: PreconditionChecks
  Message: Preconditions failed for payload loaded version="4.16.34" image="quay.io/openshift-release-dev/ocp-release@sha256:41bb08c560f6db5039ccdf242e590e8b23049b5eb31e1c4f6021d1d520b353b8": Precondition "ClusterVersionUpgradeable" failed because of "MultipleReasons": Cluster should not be upgraded between minor versions for multiple reasons: AdminAckRequired,ResourceDeletesInProgress
  * Kubernetes 1.29 and therefore OpenShift 4.16 remove several APIs which require admin consideration. Please see the knowledge article https://access.redhat.com/articles/7031404 for details and instructions.
  * Cluster minor level upgrades are not allowed while resource deletions are in progress; resources=PrometheusRule "openshift-kube-apiserver/kube-apiserver-recording-rules"

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

Recommended updates:

  VERSION     IMAGE
  4.16.34     quay.io/openshift-release-dev/ocp-release@sha256:41bb08c560f6db5039ccdf242e590e8b23049b5eb31e1c4f6021d1d520b353b8

    注記

    この例については、Red Hat のナレッジベース記事 (Preparing to upgrade to OpenShift Container Platform 4.16) に、リリース間の API 互換性の検証に関する詳細が記載されています。

検証

  • 次のコマンドを実行して更新を確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get configmap admin-acks -n openshift-config -o json | jq .data

    出力例

    Copy to Clipboard Toggle word wrap 
    {
  "ack-4.14-kube-1.28-api-removals-in-4.15": "true",
  "ack-4.15-kube-1.29-api-removals-in-4.16": "true"
}

    注記

    この例では、コントロールプレーンのみの更新で、クラスターをバージョン 4.14 から 4.15 に更新してから、4.15 から 4.16 に更新します。

関連情報

17.2.7.2. クラスターの更新の開始

ある y-stream リリースから次のリリースに更新する場合、中間の z-stream リリースにも互換性があることを確認する必要があります。

注記

oc adm upgrade コマンドを実行すると、更新先のリリースが実行可能なリリースであることを確認できます。oc adm upgrade コマンドは、互換性のある更新リリースをリスト表示します。

手順

  1. 更新を開始します。

    Copy to Clipboard Toggle word wrap 
    $ oc adm upgrade --to=4.15.33
    重要
    • コントロールプレーンのみの更新: 中間の <y+1> リリースパスを指定します。
    • y-stream 更新 - Kubernetes バージョンスキューポリシー に準拠した正しい <y.z> リリースを使用していることを確認します。
    • z-stream の更新 - 特定のリリースへの移行に問題がないことを確認します。

    出力例

    Copy to Clipboard Toggle word wrap 
    Requested update to 4.15.33
    1

    1
    Requested update 値は、実際の更新に応じて変わります。

関連情報

17.2.7.3. クラスターの更新の監視

更新時には、クラスターの健全性を頻繁に確認する必要があります。ノードのステータス、クラスター Operator のステータス、失敗した Pod を確認します。

手順

  • クラスターの更新を監視します。たとえば、バージョン 4.14 から 4.15 へのクラスターの更新を監視するには、次のコマンドを実行します。

    Copy to Clipboard Toggle word wrap 
    $ watch "oc get clusterversion; echo; oc get co | head -1; oc get co | grep 4.14; oc get co | grep 4.15; echo; oc get no; echo; oc get po -A | grep -E -iv 'running|complete'"

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.14.34   True        True          4m6s    Working towards 4.15.33: 111 of 873 done (12% complete), waiting on kube-apiserver

NAME                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication                 4.14.34   True        False         False      4d22h
baremetal                      4.14.34   True        False         False      4d23h
cloud-controller-manager       4.14.34   True        False         False      4d23h
cloud-credential               4.14.34   True        False         False      4d23h
cluster-autoscaler             4.14.34   True        False         False      4d23h
console                        4.14.34   True        False         False      4d22h

...

storage                        4.14.34   True        False         False      4d23h
config-operator                4.15.33   True        False         False      4d23h
etcd                           4.15.33   True        False         False      4d23h

NAME           STATUS   ROLES                  AGE     VERSION
ctrl-plane-0   Ready    control-plane,master   4d23h   v1.27.15+6147456
ctrl-plane-1   Ready    control-plane,master   4d23h   v1.27.15+6147456
ctrl-plane-2   Ready    control-plane,master   4d23h   v1.27.15+6147456
worker-0       Ready    mcp-1,worker           4d23h   v1.27.15+6147456
worker-1       Ready    mcp-2,worker           4d23h   v1.27.15+6147456

NAMESPACE               NAME                       READY   STATUS              RESTARTS   AGE
openshift-marketplace   redhat-marketplace-rf86t   0/1     ContainerCreating   0          0s

検証

更新中、この watch コマンドは、一度に 1 つまたは複数のクラスター Operator を循環し、MESSAGE 列に Operator 更新のステータスを表示します。

クラスター Operator の更新プロセスが完了すると、各コントロールプレーンノードが 1 つずつ再起動します。

注記

更新のこの部分で、クラスター Operator が再度更新中であることやデグレード状態であることを示すメッセージが報告されます。これは、ノードを再起動している間、コントロールプレーンノードがオフラインになるためです。

最後のコントロールプレーンノードの再起動が完了するとすぐに、更新されたクラスターのバージョンが表示されます。

コントロールプレーンの更新が完了すると、次のようなメッセージが表示されます。この例では、中間の y-stream リリースへの更新が完了したことを示しています。

Copy to Clipboard Toggle word wrap 
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.15.33   True        False         28m     Cluster version is 4.15.33

NAME                         VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication               4.15.33   True        False         False	  5d
baremetal                    4.15.33   True        False         False	  5d
cloud-controller-manager     4.15.33   True        False         False	  5d1h
cloud-credential             4.15.33   True        False         False	  5d1h
cluster-autoscaler           4.15.33   True        False         False	  5d
config-operator              4.15.33   True        False         False	  5d
console                      4.15.33   True        False         False	  5d

...

service-ca                   4.15.33   True        False         False	  5d
storage                      4.15.33   True        False         False	  5d

NAME           STATUS   ROLES                  AGE   VERSION
ctrl-plane-0   Ready    control-plane,master   5d    v1.28.13+2ca1a23
ctrl-plane-1   Ready    control-plane,master   5d    v1.28.13+2ca1a23
ctrl-plane-2   Ready    control-plane,master   5d    v1.28.13+2ca1a23
worker-0       Ready    mcp-1,worker           5d    v1.28.13+2ca1a23
worker-1       Ready    mcp-2,worker           5d    v1.28.13+2ca1a23

17.2.7.4. OLM Operator の更新

通信事業者の環境では、ソフトウェアを実稼働クラスターにロードする前に検査する必要があります。また、実稼働クラスターが非接続ネットワーク内で設定されるため、必ずしもインターネットに直接接続されているわけではありません。クラスターが非接続ネットワーク内にあるため、新しいバージョンをクラスターごとに管理できるように、インストール時に OpenShift Operator を手動で更新するように設定します。Operator を新しいバージョンに移行するには、次の手順を実行します。

手順

  1. 更新する必要がある Operator を確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get installplan -A | grep -E 'APPROVED|false'

    出力例

    Copy to Clipboard Toggle word wrap 
    NAMESPACE           NAME            CSV                                               APPROVAL   APPROVED
metallb-system      install-nwjnh   metallb-operator.v4.16.0-202409202304             Manual     false
openshift-nmstate   install-5r7wr   kubernetes-nmstate-operator.4.16.0-202409251605   Manual     false

  2. これらの Operator の InstallPlan リソースにパッチを適用します。

    Copy to Clipboard Toggle word wrap 
    $ oc patch installplan -n metallb-system install-nwjnh --type merge --patch \
'{"spec":{"approved":true}}'

    出力例

    Copy to Clipboard Toggle word wrap 
    installplan.operators.coreos.com/install-nwjnh patched

  3. 次のコマンドを実行して namespace を監視します。

    Copy to Clipboard Toggle word wrap 
    $ oc get all -n metallb-system

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                                                       READY   STATUS              RESTARTS   AGE
pod/metallb-operator-controller-manager-69b5f884c-8bp22    0/1     ContainerCreating   0          4s
pod/metallb-operator-controller-manager-77895bdb46-bqjdx   1/1     Running             0          4m1s
pod/metallb-operator-webhook-server-5d9b968896-vnbhk       0/1     ContainerCreating   0          4s
pod/metallb-operator-webhook-server-d76f9c6c8-57r4w        1/1     Running             0          4m1s

...

NAME                                                             DESIRED   CURRENT   READY   AGE
replicaset.apps/metallb-operator-controller-manager-69b5f884c    1         1         0       4s
replicaset.apps/metallb-operator-controller-manager-77895bdb46   1         1         1       4m1s
replicaset.apps/metallb-operator-controller-manager-99b76f88     0         0         0       4m40s
replicaset.apps/metallb-operator-webhook-server-5d9b968896       1         1         0       4s
replicaset.apps/metallb-operator-webhook-server-6f7dbfdb88       0         0         0       4m40s
replicaset.apps/metallb-operator-webhook-server-d76f9c6c8        1         1         1       4m1s

    更新が完了すると、必要な Pod が Running 状態になり、必要な ReplicaSet リソースが準備完了になるはずです。

    Copy to Clipboard Toggle word wrap 
    NAME                                                      READY   STATUS    RESTARTS   AGE
pod/metallb-operator-controller-manager-69b5f884c-8bp22   1/1     Running   0          25s
pod/metallb-operator-webhook-server-5d9b968896-vnbhk      1/1     Running   0          25s

...

NAME                                                             DESIRED   CURRENT   READY   AGE
replicaset.apps/metallb-operator-controller-manager-69b5f884c    1         1         1       25s
replicaset.apps/metallb-operator-controller-manager-77895bdb46   0         0         0       4m22s
replicaset.apps/metallb-operator-webhook-server-5d9b968896       1         1         1       25s
replicaset.apps/metallb-operator-webhook-server-d76f9c6c8        0         0         0       4m22s

検証

  • Operator を再度更新する必要がないことを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get installplan -A | grep -E 'APPROVED|false'

    出力は返されないはずです。

    注記

    Operator によっては、最終バージョンの前にインストールする必要がある中間の z-stream リリースバージョンがあるため、更新を 2 回承認する必要がある場合があります。

関連情報

17.2.7.5. ワーカーノードの更新

コントロールプレーンを更新した後、作成した適切な mcp グループの一時停止を解除してワーカーノードをアップグレードします。mcp グループの一時停止を解除すると、そのグループ内のワーカーノードのアップグレードプロセスが開始します。クラスター内の各ワーカーノードが再起動し、必要に応じて新しい EUS、y-stream、または z-stream バージョンにアップグレードされます。

コントロールプレーンのみのアップグレードの場合、ワーカーノードの更新時に、再起動が 1 回だけ必要になり、ワーカーノードが <y+2> リリースバージョンにジャンプします。これは、大規模なベアメタルクラスターのアップグレードにかかる時間を短縮するために追加された機能です。

重要

この時点で保留することも可能です。ワーカーノードが <y-2> リリースであっても、新しい EUS リリースに更新したコントロールプレーンを使用して、実稼働環境での実行が完全にサポートされているクラスターバージョンを提供できます。これにより、大規模なクラスターを複数のメンテナンス期間にわたって段階的にアップグレードできます。

  1. mcp グループ内で管理されているノードの数を確認できます。次のコマンドを実行して、mcp グループのリストを取得します。

    Copy to Clipboard Toggle word wrap 
    $ oc get mcp

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-c9a52144456dbff9c9af9c5a37d1b614   True      False      False      3              3                   3                     0                      36d
mcp-1    rendered-mcp-1-07fe50b9ad51fae43ed212e84e1dcc8e    False     False      False      1              0                   0                     0                      47h
mcp-2    rendered-mcp-2-07fe50b9ad51fae43ed212e84e1dcc8e    False     False      False      1              0                   0                     0                      47h
worker   rendered-worker-f1ab7b9a768e1b0ac9290a18817f60f0   True      False      False      0              0                   0                     0                      36d

    注記

    一度にアップグレードする mcp グループの数を決定してください。これは、一度に停止できる CNF Pod の数、および Pod Disruption Budget とアンチアフィニティーの設定よって異なります。

  2. クラスター内のノードのリストを取得します。

    Copy to Clipboard Toggle word wrap 
    $ oc get nodes

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME           STATUS   ROLES                  AGE    VERSION
ctrl-plane-0   Ready    control-plane,master   5d8h   v1.29.8+f10c92d
ctrl-plane-1   Ready    control-plane,master   5d8h   v1.29.8+f10c92d
ctrl-plane-2   Ready    control-plane,master   5d8h   v1.29.8+f10c92d
worker-0       Ready    mcp-1,worker           5d8h   v1.27.15+6147456
worker-1       Ready    mcp-2,worker           5d8h   v1.27.15+6147456

  3. 一時停止中の MachineConfigPool グループを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker

    出力例

    Copy to Clipboard Toggle word wrap 
    MCP     Paused
---     ------
master  false
mcp-1   true
mcp-2   true

    注記

    MachineConfigPool は、それぞれ個別に一時停止解除できます。したがって、メンテナンス期間の残り時間がなくなった場合でも、他の MCP をすぐに一時停止解除する必要はありません。クラスターは、一部のワーカーノードをまだ <y-2> リリースバージョンのまま実行できます。

  4. 必要な mcp グループを一時停止解除して、アップグレードを開始します。

    Copy to Clipboard Toggle word wrap 
    $ oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":false}}'

    出力例

    Copy to Clipboard Toggle word wrap 
    machineconfigpool.machineconfiguration.openshift.io/mcp-1 patched

  5. 必要な mcp グループが一時停止解除されていることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker

    出力例

    Copy to Clipboard Toggle word wrap 
    MCP     Paused
---     ------
master  false
mcp-1   false
mcp-2   true

  6. 各 mcp グループがアップグレードされたら、残りのノードを一時停止解除してアップグレードを続けます。

    Copy to Clipboard Toggle word wrap 
    $ oc get nodes

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME           STATUS                        ROLES                  AGE    VERSION
ctrl-plane-0   Ready                         control-plane,master   5d8h   v1.29.8+f10c92d
ctrl-plane-1   Ready                         control-plane,master   5d8h   v1.29.8+f10c92d
ctrl-plane-2   Ready                         control-plane,master   5d8h   v1.29.8+f10c92d
worker-0       Ready                         mcp-1,worker           5d8h   v1.29.8+f10c92d
worker-1       NotReady,SchedulingDisabled   mcp-2,worker           5d8h   v1.27.15+6147456

17.2.7.6. 新しく更新されたクラスターの健全性の確認

クラスターを更新した後、次のコマンドを実行して、クラスターが再び稼働していることを確認します。

手順

  1. 次のコマンドを実行してクラスターのバージョンを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get clusterversion

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.16.14   True        False         4h38m   Cluster version is 4.16.14

    新しいクラスターバージョンが返され、PROGRESSING 列に False が返されるはずです。

  2. すべてのノードが準備完了であることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get nodes

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME           STATUS   ROLES                  AGE    VERSION
ctrl-plane-0   Ready    control-plane,master   5d9h   v1.29.8+f10c92d
ctrl-plane-1   Ready    control-plane,master   5d9h   v1.29.8+f10c92d
ctrl-plane-2   Ready    control-plane,master   5d9h   v1.29.8+f10c92d
worker-0       Ready    mcp-1,worker           5d9h   v1.29.8+f10c92d
worker-1       Ready    mcp-2,worker           5d9h   v1.29.8+f10c92d

    クラスター内のすべてのノードが Ready ステータスで、同じバージョンを実行しているはずです。

  3. クラスター内に一時停止中の mcp リソースがないことを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker

    出力例

    Copy to Clipboard Toggle word wrap 
    MCP     Paused
---     ------
master  false
mcp-1   false
mcp-2   false

  4. すべてのクラスター Operator が利用可能であることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get co

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication                             4.16.14   True        False         False      5d9h
baremetal                                  4.16.14   True        False         False      5d9h
cloud-controller-manager                   4.16.14   True        False         False      5d10h
cloud-credential                           4.16.14   True        False         False      5d10h
cluster-autoscaler                         4.16.14   True        False         False      5d9h
config-operator                            4.16.14   True        False         False      5d9h
console                                    4.16.14   True        False         False      5d9h
control-plane-machine-set                  4.16.14   True        False         False      5d9h
csi-snapshot-controller                    4.16.14   True        False         False      5d9h
dns                                        4.16.14   True        False         False      5d9h
etcd                                       4.16.14   True        False         False      5d9h
image-registry                             4.16.14   True        False         False      85m
ingress                                    4.16.14   True        False         False      5d9h
insights                                   4.16.14   True        False         False      5d9h
kube-apiserver                             4.16.14   True        False         False      5d9h
kube-controller-manager                    4.16.14   True        False         False      5d9h
kube-scheduler                             4.16.14   True        False         False      5d9h
kube-storage-version-migrator              4.16.14   True        False         False      4h48m
machine-api                                4.16.14   True        False         False      5d9h
machine-approver                           4.16.14   True        False         False      5d9h
machine-config                             4.16.14   True        False         False      5d9h
marketplace                                4.16.14   True        False         False      5d9h
monitoring                                 4.16.14   True        False         False      5d9h
network                                    4.16.14   True        False         False      5d9h
node-tuning                                4.16.14   True        False         False      5d7h
openshift-apiserver                        4.16.14   True        False         False      5d9h
openshift-controller-manager               4.16.14   True        False         False      5d9h
openshift-samples                          4.16.14   True        False         False      5h24m
operator-lifecycle-manager                 4.16.14   True        False         False      5d9h
operator-lifecycle-manager-catalog         4.16.14   True        False         False      5d9h
operator-lifecycle-manager-packageserver   4.16.14   True        False         False      5d9h
service-ca                                 4.16.14   True        False         False      5d9h
storage                                    4.16.14   True        False         False      5d9h

    すべてのクラスター Operator の AVAILABLE 列に True と報告されるはずです。

  5. すべての Pod が正常であることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get po -A | grep -E -iv 'complete|running'

    Pod は 1 つも返されないはずです。

    注記

    更新後もまだ移行中の Pod がいくつか見られる場合があります。しばらくこれを監視して、すべての Pod がクリアされることを確認してください。

17.2.8. z-stream クラスターの更新の完了

次の手順に従って、z-stream クラスターの更新を実行し、更新が完了するまで監視します。z-stream 更新の完了は、コントロールプレーンのみの更新や y-stream 更新よりも簡単です。

17.2.8.1. クラスターの更新の開始

ある y-stream リリースから次のリリースに更新する場合、中間の z-stream リリースにも互換性があることを確認する必要があります。

注記

oc adm upgrade コマンドを実行すると、更新先のリリースが実行可能なリリースであることを確認できます。oc adm upgrade コマンドは、互換性のある更新リリースをリスト表示します。

手順

  1. 更新を開始します。

    Copy to Clipboard Toggle word wrap 
    $ oc adm upgrade --to=4.15.33
    重要
    • コントロールプレーンのみの更新: 中間の <y+1> リリースパスを指定します。
    • y-stream 更新 - Kubernetes バージョンスキューポリシー に準拠した正しい <y.z> リリースを使用していることを確認します。
    • z-stream の更新 - 特定のリリースへの移行に問題がないことを確認します。

    出力例

    Copy to Clipboard Toggle word wrap 
    Requested update to 4.15.33
    1

    1
    Requested update 値は、実際の更新に応じて変わります。

関連情報

17.2.8.2. ワーカーノードの更新

コントロールプレーンを更新した後、作成した適切な mcp グループの一時停止を解除してワーカーノードをアップグレードします。mcp グループの一時停止を解除すると、そのグループ内のワーカーノードのアップグレードプロセスが開始します。クラスター内の各ワーカーノードが再起動し、必要に応じて新しい EUS、y-stream、または z-stream バージョンにアップグレードされます。

コントロールプレーンのみのアップグレードの場合、ワーカーノードの更新時に、再起動が 1 回だけ必要になり、ワーカーノードが <y+2> リリースバージョンにジャンプします。これは、大規模なベアメタルクラスターのアップグレードにかかる時間を短縮するために追加された機能です。

重要

この時点で保留することも可能です。ワーカーノードが <y-2> リリースであっても、新しい EUS リリースに更新したコントロールプレーンを使用して、実稼働環境での実行が完全にサポートされているクラスターバージョンを提供できます。これにより、大規模なクラスターを複数のメンテナンス期間にわたって段階的にアップグレードできます。

  1. mcp グループ内で管理されているノードの数を確認できます。次のコマンドを実行して、mcp グループのリストを取得します。

    Copy to Clipboard Toggle word wrap 
    $ oc get mcp

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-c9a52144456dbff9c9af9c5a37d1b614   True      False      False      3              3                   3                     0                      36d
mcp-1    rendered-mcp-1-07fe50b9ad51fae43ed212e84e1dcc8e    False     False      False      1              0                   0                     0                      47h
mcp-2    rendered-mcp-2-07fe50b9ad51fae43ed212e84e1dcc8e    False     False      False      1              0                   0                     0                      47h
worker   rendered-worker-f1ab7b9a768e1b0ac9290a18817f60f0   True      False      False      0              0                   0                     0                      36d

    注記

    一度にアップグレードする mcp グループの数を決定してください。これは、一度に停止できる CNF Pod の数、および Pod Disruption Budget とアンチアフィニティーの設定よって異なります。

  2. クラスター内のノードのリストを取得します。

    Copy to Clipboard Toggle word wrap 
    $ oc get nodes

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME           STATUS   ROLES                  AGE    VERSION
ctrl-plane-0   Ready    control-plane,master   5d8h   v1.29.8+f10c92d
ctrl-plane-1   Ready    control-plane,master   5d8h   v1.29.8+f10c92d
ctrl-plane-2   Ready    control-plane,master   5d8h   v1.29.8+f10c92d
worker-0       Ready    mcp-1,worker           5d8h   v1.27.15+6147456
worker-1       Ready    mcp-2,worker           5d8h   v1.27.15+6147456

  3. 一時停止中の MachineConfigPool グループを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker

    出力例

    Copy to Clipboard Toggle word wrap 
    MCP     Paused
---     ------
master  false
mcp-1   true
mcp-2   true

    注記

    MachineConfigPool は、それぞれ個別に一時停止解除できます。したがって、メンテナンス期間の残り時間がなくなった場合でも、他の MCP をすぐに一時停止解除する必要はありません。クラスターは、一部のワーカーノードをまだ <y-2> リリースバージョンのまま実行できます。

  4. 必要な mcp グループを一時停止解除して、アップグレードを開始します。

    Copy to Clipboard Toggle word wrap 
    $ oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":false}}'

    出力例

    Copy to Clipboard Toggle word wrap 
    machineconfigpool.machineconfiguration.openshift.io/mcp-1 patched

  5. 必要な mcp グループが一時停止解除されていることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker

    出力例

    Copy to Clipboard Toggle word wrap 
    MCP     Paused
---     ------
master  false
mcp-1   false
mcp-2   true

  6. 各 mcp グループがアップグレードされたら、残りのノードを一時停止解除してアップグレードを続けます。

    Copy to Clipboard Toggle word wrap 
    $ oc get nodes

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME           STATUS                        ROLES                  AGE    VERSION
ctrl-plane-0   Ready                         control-plane,master   5d8h   v1.29.8+f10c92d
ctrl-plane-1   Ready                         control-plane,master   5d8h   v1.29.8+f10c92d
ctrl-plane-2   Ready                         control-plane,master   5d8h   v1.29.8+f10c92d
worker-0       Ready                         mcp-1,worker           5d8h   v1.29.8+f10c92d
worker-1       NotReady,SchedulingDisabled   mcp-2,worker           5d8h   v1.27.15+6147456

17.2.8.3. 新しく更新されたクラスターの健全性の確認

クラスターを更新した後、次のコマンドを実行して、クラスターが再び稼働していることを確認します。

手順

  1. 次のコマンドを実行してクラスターのバージョンを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get clusterversion

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.16.14   True        False         4h38m   Cluster version is 4.16.14

    新しいクラスターバージョンが返され、PROGRESSING 列に False が返されるはずです。

  2. すべてのノードが準備完了であることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get nodes

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME           STATUS   ROLES                  AGE    VERSION
ctrl-plane-0   Ready    control-plane,master   5d9h   v1.29.8+f10c92d
ctrl-plane-1   Ready    control-plane,master   5d9h   v1.29.8+f10c92d
ctrl-plane-2   Ready    control-plane,master   5d9h   v1.29.8+f10c92d
worker-0       Ready    mcp-1,worker           5d9h   v1.29.8+f10c92d
worker-1       Ready    mcp-2,worker           5d9h   v1.29.8+f10c92d

    クラスター内のすべてのノードが Ready ステータスで、同じバージョンを実行しているはずです。

  3. クラスター内に一時停止中の mcp リソースがないことを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker

    出力例

    Copy to Clipboard Toggle word wrap 
    MCP     Paused
---     ------
master  false
mcp-1   false
mcp-2   false

  4. すべてのクラスター Operator が利用可能であることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get co

    出力例

    Copy to Clipboard Toggle word wrap 
    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
authentication                             4.16.14   True        False         False      5d9h
baremetal                                  4.16.14   True        False         False      5d9h
cloud-controller-manager                   4.16.14   True        False         False      5d10h
cloud-credential                           4.16.14   True        False         False      5d10h
cluster-autoscaler                         4.16.14   True        False         False      5d9h
config-operator                            4.16.14   True        False         False      5d9h
console                                    4.16.14   True        False         False      5d9h
control-plane-machine-set                  4.16.14   True        False         False      5d9h
csi-snapshot-controller                    4.16.14   True        False         False      5d9h
dns                                        4.16.14   True        False         False      5d9h
etcd                                       4.16.14   True        False         False      5d9h
image-registry                             4.16.14   True        False         False      85m
ingress                                    4.16.14   True        False         False      5d9h
insights                                   4.16.14   True        False         False      5d9h
kube-apiserver                             4.16.14   True        False         False      5d9h
kube-controller-manager                    4.16.14   True        False         False      5d9h
kube-scheduler                             4.16.14   True        False         False      5d9h
kube-storage-version-migrator              4.16.14   True        False         False      4h48m
machine-api                                4.16.14   True        False         False      5d9h
machine-approver                           4.16.14   True        False         False      5d9h
machine-config                             4.16.14   True        False         False      5d9h
marketplace                                4.16.14   True        False         False      5d9h
monitoring                                 4.16.14   True        False         False      5d9h
network                                    4.16.14   True        False         False      5d9h
node-tuning                                4.16.14   True        False         False      5d7h
openshift-apiserver                        4.16.14   True        False         False      5d9h
openshift-controller-manager               4.16.14   True        False         False      5d9h
openshift-samples                          4.16.14   True        False         False      5h24m
operator-lifecycle-manager                 4.16.14   True        False         False      5d9h
operator-lifecycle-manager-catalog         4.16.14   True        False         False      5d9h
operator-lifecycle-manager-packageserver   4.16.14   True        False         False      5d9h
service-ca                                 4.16.14   True        False         False      5d9h
storage                                    4.16.14   True        False         False      5d9h

    すべてのクラスター Operator の AVAILABLE 列に True と報告されるはずです。

  5. すべての Pod が正常であることを確認します。

    Copy to Clipboard Toggle word wrap 
    $ oc get po -A | grep -E -iv 'complete|running'

    Pod は 1 つも返されないはずです。

    注記

    更新後もまだ移行中の Pod がいくつか見られる場合があります。しばらくこれを監視して、すべての Pod がクリアされることを確認してください。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat, Inc.