Red Hat Summit17.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 更新を実行するときにチャネルを変更する必要はありません。
手順
利用可能な z-stream リリースを確認します。以下のコマンドを実行します。
$ oc adm upgrade出力例
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 更新を実行するときにチャネルを変更する必要はありません。
手順
現在設定されている更新チャネルを特定します。
$ oc get clusterversion -o=jsonpath='{.items[*].spec}' | jq出力例
{ "channel": "stable-4.14", "clusterID": "01eb9a57-2bfb-4f50-9d37-dc04bd5bac75" }更新する新しいチャネルを参照するようにチャネルを変更します。
$ oc adm upgrade channel eus-4.16更新されたチャネルを確認します。
$ oc get clusterversion -o=jsonpath='{.items[*].spec}' | jq出力例
{ "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 チャネルを使用できます。
手順
チャネルを
fast-<y+1>に変更します。たとえば、以下のコマンドを実行します。$ oc adm upgrade channel fast-4.16新しいチャネルの更新パスを確認します。以下のコマンドを実行します。
$ oc adm upgradeCluster 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更新手順に従ってバージョン 4.16 にアップグレードします (バージョン 4.15 から <y+1>)。
注記fast チャネルを使用している場合でも、EUS リリース間でワーカーノードを一時停止したままにすることができます。
-
必要な <y+1> リリースに更新したら、チャネルを再度変更し、今度は
fast-<y+2>に変更します。 - EUS 更新手順に従って、必要な <y+2> リリースに更新します。
17.2.2.3.3. y-stream 更新のチャネルの変更
y-stream 更新では、チャネルを次のリリースチャネルに変更します。
実稼働クラスターには、stable または EUS リリースチャネルを使用してください。
手順
更新チャネルを変更します。
$ oc adm upgrade channel stable-4.15新しいチャネルの更新パスを確認します。以下のコマンドを実行します。
$ oc adm upgrade出力例
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 が含まれます。
手順
クラスターに現在インストールされている Operator を確認します。たとえば、以下のコマンドを実行します。
$ oc get csv -A出力例
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 SucceededOLM を使用してインストールする Operator が更新先のバージョンと互換性があることを確認します。
Operator Lifecycle Manager (OLM) によってインストールされる Operator は、標準のクラスター Operator セットの一部ではありません。
Operator Update Information Checker を使用して、それぞれの y-stream 更新後に Operator を更新する必要があるかどうか、または次の EUS リリースに完全に更新されるまで待つことができるかどうかを確認してください。
ヒントOperator Update Information Checker を使用して、Operator の特定のリリースと互換性のある OpenShift Container Platform のバージョンを確認することもできます。
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 つのノードの更新を完了します。-
ワーカーノードを、それぞれ 2 つのノードからなる 3 つの
mcp グループの一時停止を解除するプロセスとペースは、CNF アプリケーションと設定によって決まります。
CNF Pod がクラスター内のノード間のスケジューリングに対応できる場合は、一度に複数の mcp グループの一時停止を解除し、mcp カスタムリソース (CR) の MaxUnavailable を最大 50% に設定できます。これにより、mcp グループ内の最大半数のノードを再起動して更新できます。
17.2.3.3.3. 設定されているクラスター MachineConfigPool ロールの確認
クラスター内で現在設定されている MachineConfigPool ロールを確認します。
手順
クラスター内で現在設定されている
mcpグループを取得します。$ oc get mcp出力例
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 25dmcpロールのリストをクラスター内のノードのリストと比較します。$ oc get nodes出力例
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 つのステップで行います。
-
クラスター内のノードに
mcpラベルを追加します。 -
ラベルに基づいてノードをまとめるクラスターに
mcpCR を適用します。
手順
ノードにラベルを付けて、
mcpグループに配置できるようにします。以下のコマンドを実行します。$ oc label node worker-0 node-role.kubernetes.io/mcp-1=$ oc label node worker-1 node-role.kubernetes.io/mcp-2=mcp-1およびmcp-2ラベルをノードに適用します。以下に例を示します。出力例
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クラスターの
mcpCR としてラベルを適用する YAML カスタムリソース (CR) を作成します。次の YAML をmcps.yamlファイルに保存します。--- 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: ""MachineConfigPoolリソースを作成します。$ oc apply -f mcps.yaml出力例
machineconfigpool.machineconfiguration.openshift.io/mcp-2 created
検証
クラスターに MachineConfigPool リソースが適用される様子を監視します。mcp リソースを適用すると、ノードが新しいマシン設定プールに追加されます。これには数分かかります。
ノードは、mcp グループに追加されている間は再起動しません。元のワーカーおよびマスター mcp グループは変更されません。
新しい
mcpリソースのステータスを確認します。$ oc get mcp出力例
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最終的に、リソースは完全に適用されます。
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. クラスタープラットフォームの更新の準備
クラスターを更新する前に、いくつかの基本的なチェックと検証を実行して、クラスターの更新の準備ができていることを確認します。
手順
次のコマンドを実行して、クラスター内に失敗した Pod や進行中の Pod がないことを確認します。
$ oc get pods -A | grep -E -vi 'complete|running'注記保留中の状態の Pod がある場合は、このコマンドを複数回実行する必要がある場合があります。
クラスター内のすべてのノードが利用可能であることを確認します。
$ oc get nodes出力例
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すべてのベアメタルノードがプロビジョニングされ、準備ができていることを確認します。
$ oc get bmh -n openshift-machine-api出力例
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 1d1 - 1
worker-1ノードのプロビジョニング中にエラーが発生しています。
検証
すべてのクラスター Operator の準備ができていることを確認します。
$ oc get co出力例
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 にします。
手順
次のコマンドを実行して、
mcpCR にパッチを適用し、ノードを一時停止し、それらのノードから Pod をドレインして削除します。$ oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":true}}'$ oc patch mcp/mcp-2 --type merge --patch '{"spec":{"paused":true}}'一時停止した
mcpグループのステータスを取得します。$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker出力例
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フィールドに値が設定されている場合に有効にされます。
手順
コントロールプレーンノードの root としてデバッグセッションを開始します。
$ oc debug --as-root node/<node_name>デバッグシェルで root ディレクトリーを
/hostに変更します。sh-4.4# chroot /hostクラスター全体のプロキシーが有効になっている場合は、次のコマンドを実行して、
NO_PROXY、HTTP_PROXY、およびHTTPS_PROXY環境変数をエクスポートします。$ export HTTP_PROXY=http://<your_proxy.example.com>:8080$ export HTTPS_PROXY=https://<your_proxy.example.com>:8080$ export NO_PROXY=<example.com>デバッグシェルで
cluster-backup.shスクリプトを実行し、バックアップの保存先となる場所を渡します。ヒントcluster-backup.shスクリプトは etcd Cluster Operator のコンポーネントとして維持され、etcdctl snapshot saveコマンドに関連するラッパーです。sh-4.4# /usr/local/bin/cluster-backup.sh /home/core/assets/backupスクリプトの出力例
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 バックアップを作成します。
次の例のような内容で、
etcd-backup-pvc.yamlという名前の永続ボリューム要求 (PVC) を作成します。kind: PersistentVolumeClaim apiVersion: v1 metadata: name: etcd-backup-pvc namespace: openshift-etcd spec: accessModes: - ReadWriteOnce resources: requests: storage: 200Gi1 volumeMode: Filesystem- 1
- PVC に利用できるストレージの量。この値は、要件に合わせて調整します。
以下のコマンドを実行して PVC を適用します。
$ oc apply -f etcd-backup-pvc.yaml次のコマンドを実行して、PVC が作成されたことを確認します。
$ oc get pvc出力例
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE etcd-backup-pvc Bound 51s注記動的 PVC は、マウントされるまで
Pending状態から遷移しません。次の例のような内容で、
etcd-single-backup.yamlという名前の CR ファイルを作成します。apiVersion: operator.openshift.io/v1alpha1 kind: EtcdBackup metadata: name: etcd-single-backup namespace: openshift-etcd spec: pvcName: etcd-backup-pvc1 - 1
- バックアップを保存する PVC の名前。この値は、使用している環境に応じて調整してください。
CR を適用してシングルバックアップを開始します。
$ oc apply -f etcd-single-backup.yaml
動的にプロビジョニングされたストレージが利用できない場合は、次の手順を実行して、単一の自動 etcd バックアップを作成します。
次の内容で、
etcd-backup-local-storage.yamlという名前のStorageClassCR ファイルを作成します。apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: etcd-backup-local-storage provisioner: kubernetes.io/no-provisioner volumeBindingMode: Immediate次のコマンドを実行して、
StorageClassCR を適用します。$ oc apply -f etcd-backup-local-storage.yaml次の例のような内容の
etcd-backup-pv-fs.yamlという名前の PV を作成します。apiVersion: v1 kind: PersistentVolume metadata: name: etcd-backup-pv-fs spec: capacity: storage: 100Gi1 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 次のコマンドを実行して、PV が作成されたことを確認します。
$ oc get pv出力例
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE etcd-backup-pv-fs 100Gi RWO Retain Available etcd-backup-local-storage 10s次の例のような内容で、
etcd-backup-pvc.yamlという名前の PVC を作成します。kind: PersistentVolumeClaim apiVersion: v1 metadata: name: etcd-backup-pvc namespace: openshift-etcd spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 10Gi1 - 1
- PVC に利用できるストレージの量。この値は、要件に合わせて調整します。
以下のコマンドを実行して PVC を適用します。
$ oc apply -f etcd-backup-pvc.yaml次の例のような内容で、
etcd-single-backup.yamlという名前の CR ファイルを作成します。apiVersion: operator.openshift.io/v1alpha1 kind: EtcdBackup metadata: name: etcd-single-backup namespace: openshift-etcd spec: pvcName: etcd-backup-pvc1 - 1
- バックアップを保存する永続ボリューム要求 (PVC) の名前。この値は、使用している環境に応じて調整してください。
CR を適用してシングルバックアップを開始します。
$ oc apply -f etcd-single-backup.yaml
17.2.5.3. クラスターの健全性の確認
更新時には、クラスターの健全性を頻繁に確認する必要があります。ノードのステータス、クラスター Operator のステータス、失敗した Pod を確認します。
手順
次のコマンドを実行して、クラスター Operator のステータスを確認します。
$ oc get co出力例
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クラスターノードのステータスを確認します。
$ oc get nodes出力例
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進行中の Pod や失敗した Pod がないことを確認します。次のコマンドを実行したときに、Pod が 1 つも返されないようにします。
$ 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 バージョンの検証」を参照してください。
手順
次のコマンドを実行して、管理者としての承認を完了し、クラスターの更新を開始します。
$ oc adm upgradeクラスターの更新が正常に完了しない場合は、
ReasonおよびMessageセクションに更新の失敗に関する詳細が表示されます。出力例
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 互換性の検証に関する詳細が記載されています。
検証
次のコマンドを実行して更新を確認します。
$ oc get configmap admin-acks -n openshift-config -o json | jq .data出力例
{ "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 コマンドは、互換性のある更新リリースをリスト表示します。
手順
更新を開始します。
$ oc adm upgrade --to=4.15.33重要- コントロールプレーンのみの更新: 中間の <y+1> リリースパスを指定します。
- y-stream 更新 - Kubernetes バージョンスキューポリシー に準拠した正しい <y.z> リリースを使用していることを確認します。
- z-stream の更新 - 特定のリリースへの移行に問題がないことを確認します。
出力例
Requested update to 4.15.331 - 1
Requested update値は、実際の更新に応じて変わります。
17.2.6.3. クラスターの更新の監視
更新時には、クラスターの健全性を頻繁に確認する必要があります。ノードのステータス、クラスター Operator のステータス、失敗した Pod を確認します。
手順
クラスターの更新を監視します。たとえば、バージョン 4.14 から 4.15 へのクラスターの更新を監視するには、次のコマンドを実行します。
$ 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'"出力例
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 リリースへの更新が完了したことを示しています。
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+2ca1a2317.2.6.4. OLM Operator の更新
通信事業者の環境では、ソフトウェアを実稼働クラスターにロードする前に検査する必要があります。また、実稼働クラスターが非接続ネットワーク内で設定されるため、必ずしもインターネットに直接接続されているわけではありません。クラスターが非接続ネットワーク内にあるため、新しいバージョンをクラスターごとに管理できるように、インストール時に OpenShift Operator を手動で更新するように設定します。Operator を新しいバージョンに移行するには、次の手順を実行します。
手順
更新する必要がある Operator を確認します。
$ oc get installplan -A | grep -E 'APPROVED|false'出力例
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これらの Operator の
InstallPlanリソースにパッチを適用します。$ oc patch installplan -n metallb-system install-nwjnh --type merge --patch \ '{"spec":{"approved":true}}'出力例
installplan.operators.coreos.com/install-nwjnh patched次のコマンドを実行して namespace を監視します。
$ oc get all -n metallb-system出力例
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リソースが準備完了になるはずです。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 を再度更新する必要がないことを確認します。
$ 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 バージョンに更新する必要があります。
手順
選択した <4.y.z> リリースが、適切な移行先チャネルとして現在もリスト表示されることを確認します。
$ oc adm upgrade出力例
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 リリースが表示されない場合があります。オプション: 推奨されない更新リリースの候補を表示します。以下のコマンドを実行します。
$ oc adm upgrade --include-not-recommended出力例
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 バージョンの検証」を参照してください。
手順
次のコマンドを実行して、管理者としての承認を完了し、クラスターの更新を開始します。
$ oc adm upgradeクラスターの更新が正常に完了しない場合は、
ReasonおよびMessageセクションに更新の失敗に関する詳細が表示されます。出力例
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 互換性の検証に関する詳細が記載されています。
検証
次のコマンドを実行して更新を確認します。
$ oc get configmap admin-acks -n openshift-config -o json | jq .data出力例
{ "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 コントロールプレーンの更新を開始します。たとえば、以下のコマンドを実行します。
$ oc adm upgrade --to=4.16.14出力例
Requested update to 4.16.14移行先の z-stream リリースに、使用中のプラットフォーム以外のプラットフォームに関する問題がある場合があります。次の例は、Microsoft Azure でのクラスター更新の潜在的な問題を示しています。
$ oc adm upgrade --to=4.16.15出力例
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 でホストされているクラスターに影響を与える可能性のある潜在的なエラーが示されています。ベアメタルクラスターのリスクは示されていません。
$ oc adm upgrade --to=4.16.15 --allow-not-recommended出力例
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. クラスター更新の 2 番目の部分を監視する
クラスターの 2 番目の部分が <y+1> バージョンに更新される様子を監視します。
手順
<y+1> 更新の 2 番目の部分の進行状況を監視します。たとえば、4.15 から 4.16 への更新を監視するには、次のコマンドを実行します。
$ 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'"出力例
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 リリースにすぐに更新されます。以下に例を示します。
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 も更新してください。
手順
クラスターの更新を監視します。たとえば、バージョン 4.14 から 4.15 へのクラスターの更新を監視するには、次のコマンドを実行します。
$ 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'"更新する必要がある Operator を確認します。
$ oc get installplan -A | grep -E 'APPROVED|false'これらの Operator の
InstallPlanリソースにパッチを適用します。$ oc patch installplan -n metallb-system install-nwjnh --type merge --patch \ '{"spec":{"approved":true}}'次のコマンドを実行して namespace を監視します。
$ 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 リリースに更新したコントロールプレーンを使用して、実稼働環境での実行が完全にサポートされているクラスターバージョンを提供できます。これにより、大規模なクラスターを複数のメンテナンス期間にわたって段階的にアップグレードできます。
mcpグループ内で管理されているノードの数を確認できます。次のコマンドを実行して、mcpグループのリストを取得します。$ oc get mcp出力例
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 とアンチアフィニティーの設定よって異なります。クラスター内のノードのリストを取得します。
$ oc get nodes出力例
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一時停止中の
MachineConfigPoolグループを確認します。$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker出力例
MCP Paused --- ------ master false mcp-1 true mcp-2 true注記MachineConfigPoolは、それぞれ個別に一時停止解除できます。したがって、メンテナンス期間の残り時間がなくなった場合でも、他の MCP をすぐに一時停止解除する必要はありません。クラスターは、一部のワーカーノードをまだ <y-2> リリースバージョンのまま実行できます。必要な
mcpグループを一時停止解除して、アップグレードを開始します。$ oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":false}}'出力例
machineconfigpool.machineconfiguration.openshift.io/mcp-1 patched必要な
mcpグループが一時停止解除されていることを確認します。$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker出力例
MCP Paused --- ------ master false mcp-1 false mcp-2 true各
mcpグループがアップグレードされたら、残りのノードを一時停止解除してアップグレードを続けます。$ oc get nodes出力例
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. 新しく更新されたクラスターの健全性の確認
クラスターを更新した後、次のコマンドを実行して、クラスターが再び稼働していることを確認します。
手順
次のコマンドを実行してクラスターのバージョンを確認します。
$ oc get clusterversion出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.16.14 True False 4h38m Cluster version is 4.16.14新しいクラスターバージョンが返され、
PROGRESSING列にFalseが返されるはずです。すべてのノードが準備完了であることを確認します。
$ oc get nodes出力例
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ステータスで、同じバージョンを実行しているはずです。クラスター内に一時停止中の
mcpリソースがないことを確認します。$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker出力例
MCP Paused --- ------ master false mcp-1 false mcp-2 falseすべてのクラスター Operator が利用可能であることを確認します。
$ oc get co出力例
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と報告されるはずです。すべての Pod が正常であることを確認します。
$ 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 バージョンの検証」を参照してください。
手順
次のコマンドを実行して、管理者としての承認を完了し、クラスターの更新を開始します。
$ oc adm upgradeクラスターの更新が正常に完了しない場合は、
ReasonおよびMessageセクションに更新の失敗に関する詳細が表示されます。出力例
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 互換性の検証に関する詳細が記載されています。
検証
次のコマンドを実行して更新を確認します。
$ oc get configmap admin-acks -n openshift-config -o json | jq .data出力例
{ "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 コマンドは、互換性のある更新リリースをリスト表示します。
手順
更新を開始します。
$ oc adm upgrade --to=4.15.33重要- コントロールプレーンのみの更新: 中間の <y+1> リリースパスを指定します。
- y-stream 更新 - Kubernetes バージョンスキューポリシー に準拠した正しい <y.z> リリースを使用していることを確認します。
- z-stream の更新 - 特定のリリースへの移行に問題がないことを確認します。
出力例
Requested update to 4.15.331 - 1
Requested update値は、実際の更新に応じて変わります。
17.2.7.3. クラスターの更新の監視
更新時には、クラスターの健全性を頻繁に確認する必要があります。ノードのステータス、クラスター Operator のステータス、失敗した Pod を確認します。
手順
クラスターの更新を監視します。たとえば、バージョン 4.14 から 4.15 へのクラスターの更新を監視するには、次のコマンドを実行します。
$ 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'"出力例
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 リリースへの更新が完了したことを示しています。
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+2ca1a2317.2.7.4. OLM Operator の更新
通信事業者の環境では、ソフトウェアを実稼働クラスターにロードする前に検査する必要があります。また、実稼働クラスターが非接続ネットワーク内で設定されるため、必ずしもインターネットに直接接続されているわけではありません。クラスターが非接続ネットワーク内にあるため、新しいバージョンをクラスターごとに管理できるように、インストール時に OpenShift Operator を手動で更新するように設定します。Operator を新しいバージョンに移行するには、次の手順を実行します。
手順
更新する必要がある Operator を確認します。
$ oc get installplan -A | grep -E 'APPROVED|false'出力例
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これらの Operator の
InstallPlanリソースにパッチを適用します。$ oc patch installplan -n metallb-system install-nwjnh --type merge --patch \ '{"spec":{"approved":true}}'出力例
installplan.operators.coreos.com/install-nwjnh patched次のコマンドを実行して namespace を監視します。
$ oc get all -n metallb-system出力例
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リソースが準備完了になるはずです。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 を再度更新する必要がないことを確認します。
$ 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 リリースに更新したコントロールプレーンを使用して、実稼働環境での実行が完全にサポートされているクラスターバージョンを提供できます。これにより、大規模なクラスターを複数のメンテナンス期間にわたって段階的にアップグレードできます。
mcpグループ内で管理されているノードの数を確認できます。次のコマンドを実行して、mcpグループのリストを取得します。$ oc get mcp出力例
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 とアンチアフィニティーの設定よって異なります。クラスター内のノードのリストを取得します。
$ oc get nodes出力例
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一時停止中の
MachineConfigPoolグループを確認します。$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker出力例
MCP Paused --- ------ master false mcp-1 true mcp-2 true注記MachineConfigPoolは、それぞれ個別に一時停止解除できます。したがって、メンテナンス期間の残り時間がなくなった場合でも、他の MCP をすぐに一時停止解除する必要はありません。クラスターは、一部のワーカーノードをまだ <y-2> リリースバージョンのまま実行できます。必要な
mcpグループを一時停止解除して、アップグレードを開始します。$ oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":false}}'出力例
machineconfigpool.machineconfiguration.openshift.io/mcp-1 patched必要な
mcpグループが一時停止解除されていることを確認します。$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker出力例
MCP Paused --- ------ master false mcp-1 false mcp-2 true各
mcpグループがアップグレードされたら、残りのノードを一時停止解除してアップグレードを続けます。$ oc get nodes出力例
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. 新しく更新されたクラスターの健全性の確認
クラスターを更新した後、次のコマンドを実行して、クラスターが再び稼働していることを確認します。
手順
次のコマンドを実行してクラスターのバージョンを確認します。
$ oc get clusterversion出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.16.14 True False 4h38m Cluster version is 4.16.14新しいクラスターバージョンが返され、
PROGRESSING列にFalseが返されるはずです。すべてのノードが準備完了であることを確認します。
$ oc get nodes出力例
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ステータスで、同じバージョンを実行しているはずです。クラスター内に一時停止中の
mcpリソースがないことを確認します。$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker出力例
MCP Paused --- ------ master false mcp-1 false mcp-2 falseすべてのクラスター Operator が利用可能であることを確認します。
$ oc get co出力例
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と報告されるはずです。すべての Pod が正常であることを確認します。
$ 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 コマンドは、互換性のある更新リリースをリスト表示します。
手順
更新を開始します。
$ oc adm upgrade --to=4.15.33重要- コントロールプレーンのみの更新: 中間の <y+1> リリースパスを指定します。
- y-stream 更新 - Kubernetes バージョンスキューポリシー に準拠した正しい <y.z> リリースを使用していることを確認します。
- z-stream の更新 - 特定のリリースへの移行に問題がないことを確認します。
出力例
Requested update to 4.15.331 - 1
Requested update値は、実際の更新に応じて変わります。
17.2.8.2. ワーカーノードの更新
コントロールプレーンを更新した後、作成した適切な mcp グループの一時停止を解除してワーカーノードをアップグレードします。mcp グループの一時停止を解除すると、そのグループ内のワーカーノードのアップグレードプロセスが開始します。クラスター内の各ワーカーノードが再起動し、必要に応じて新しい EUS、y-stream、または z-stream バージョンにアップグレードされます。
コントロールプレーンのみのアップグレードの場合、ワーカーノードの更新時に、再起動が 1 回だけ必要になり、ワーカーノードが <y+2> リリースバージョンにジャンプします。これは、大規模なベアメタルクラスターのアップグレードにかかる時間を短縮するために追加された機能です。
この時点で保留することも可能です。ワーカーノードが <y-2> リリースであっても、新しい EUS リリースに更新したコントロールプレーンを使用して、実稼働環境での実行が完全にサポートされているクラスターバージョンを提供できます。これにより、大規模なクラスターを複数のメンテナンス期間にわたって段階的にアップグレードできます。
mcpグループ内で管理されているノードの数を確認できます。次のコマンドを実行して、mcpグループのリストを取得します。$ oc get mcp出力例
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 とアンチアフィニティーの設定よって異なります。クラスター内のノードのリストを取得します。
$ oc get nodes出力例
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一時停止中の
MachineConfigPoolグループを確認します。$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker出力例
MCP Paused --- ------ master false mcp-1 true mcp-2 true注記MachineConfigPoolは、それぞれ個別に一時停止解除できます。したがって、メンテナンス期間の残り時間がなくなった場合でも、他の MCP をすぐに一時停止解除する必要はありません。クラスターは、一部のワーカーノードをまだ <y-2> リリースバージョンのまま実行できます。必要な
mcpグループを一時停止解除して、アップグレードを開始します。$ oc patch mcp/mcp-1 --type merge --patch '{"spec":{"paused":false}}'出力例
machineconfigpool.machineconfiguration.openshift.io/mcp-1 patched必要な
mcpグループが一時停止解除されていることを確認します。$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker出力例
MCP Paused --- ------ master false mcp-1 false mcp-2 true各
mcpグループがアップグレードされたら、残りのノードを一時停止解除してアップグレードを続けます。$ oc get nodes出力例
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. 新しく更新されたクラスターの健全性の確認
クラスターを更新した後、次のコマンドを実行して、クラスターが再び稼働していることを確認します。
手順
次のコマンドを実行してクラスターのバージョンを確認します。
$ oc get clusterversion出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.16.14 True False 4h38m Cluster version is 4.16.14新しいクラスターバージョンが返され、
PROGRESSING列にFalseが返されるはずです。すべてのノードが準備完了であることを確認します。
$ oc get nodes出力例
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ステータスで、同じバージョンを実行しているはずです。クラスター内に一時停止中の
mcpリソースがないことを確認します。$ oc get mcp -o json | jq -r '["MCP","Paused"], ["---","------"], (.items[] | [(.metadata.name), (.spec.paused)]) | @tsv' | grep -v worker出力例
MCP Paused --- ------ master false mcp-1 false mcp-2 falseすべてのクラスター Operator が利用可能であることを確認します。
$ oc get co出力例
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と報告されるはずです。すべての Pod が正常であることを確認します。
$ oc get po -A | grep -E -iv 'complete|running'Pod は 1 つも返されないはずです。
注記更新後もまだ移行中の Pod がいくつか見られる場合があります。しばらくこれを監視して、すべての Pod がクリアされることを確認してください。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}