第2章 クラスターの更新の準備
2.1. OpenShift Container Platform 4.16 への更新の準備
更新を正常に初期化するためにクラスター管理者が実行する必要がある管理タスクと、更新を確実に成功させるためのオプションのガイドラインを詳しく説明します。
2.1.1. RHEL 9.2 マイクロアーキテクチャー要件の変更
OpenShift Container Platform は現在、RHEL 9.2 ホストオペレーティングシステムをベースとしています。マイクロアーキテクチャーの要件が x86_64-v2、Power9、Z14 に増加しました。RHEL マイクロアーキテクチャー要件ドキュメント を参照してください。この ナレッジベース に記載されている手順に従って、更新前に互換性を確認できます。
正しいマイクロアーキテクチャー要件がないと、更新プロセスは失敗します。各アーキテクチャーに適切なサブスクリプションを購入してください。詳細は Get Started with Red Hat Enterprise Linux - additional architectures を参照してください。
2.1.2. Kubernetes API の削除
OpenShift Container Platform 4.16 は Kubernetes 1.29 を使用します。これにより、複数の非推奨 API が削除されました。
クラスター管理者は、クラスターを OpenShift Container Platform 4.15 から 4.16 にアップグレードする前に、手動で確認を行う必要があります。削除された API が、クラスター上で実行されている、またはクラスターと対話しているワークロード、ツール、またはその他のコンポーネントによって引き続き使用される OpenShift Container Platform 4.16 にアップグレードした後の問題を防ぐ上で役立ちます。管理者は、削除が予定されている使用中の API に対するクラスターの評価を実施し、影響を受けるコンポーネントを移行して適切な新規 API バージョンを使用する必要があります。この評価および移行が完了したら、管理者は確認応答を提供できます。
OpenShift Container Platform 4.15 クラスターを 4.16 に更新する前に、管理者の確認を提供する必要があります。
2.1.2.1. Kubernetes API の削除
OpenShift Container Platform 4.16 は Kubernetes 1.29 を使用します。これにより、以下の非推奨 API が削除されました。適切な API バージョンを使用するには、マニフェストと API クライアントを移行する必要があります。削除された API の移行について、詳細は Kubernetes documentation を参照してください。
| リソース | 削除された API | 移行先 | 大きな変更 |
|---|---|---|---|
|
|
|
| いいえ |
|
|
|
|
2.1.2.2. 削除された API に対するクラスターの評価
削除される API が使用されている場所を管理者が特定するのに役立つ方法は複数あります。ただし、OpenShift Container Platform は、アイドル状態や外部ツールが使用されるワークロードなどのすべてのインスタンスを特定できません。すべてのワークロードと削除された API のインスタンスに対する他の統合を適切に評価することは管理者の責任です。
2.1.2.2.1. 削除された API の使用を特定するためのアラートの確認
次のリリースで削除予定の API が使用されている場合に 2 つのアラートが発生します。
-
APIRemovedInNextReleaseInUse: OpenShift Container Platform の次のリリースで削除される API の場合 -
APIRemovedInNextEUSReleaseInUse: 次の OpenShift Container Platform Extended Update Support (EUS) リリースで削除される API の場合
これらのアラートのいずれかがクラスターで実行している場合は、アラートを確認し、マニフェストおよび API クライアントを移行して新規 API バージョンを使用することによりアラートをクリアします。
アラートにはこの情報が含まれないため、APIRequestCount API を使用して、使用中の API と削除された API を使用しているワークロードに関する詳細情報を取得します。さらに、API によってはこれらのアラートがトリガーされない場合もありますが、APIRequestCount がキャプチャーします。アラートは、機密性が低くなるように調整して、実稼働システムでのアラートの疲弊を回避します。
2.1.2.2.2. APIRequestCount を使用して削除された API の使用状況を特定
APIRequestCount API を使用して API 要求を追跡し、それらのいずれかが削除された API のいずれかを使用しているかどうかを確認することができます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
以下のコマンドを実行し、出力された
REMOVEDINRELEASE列を確認して、現在使用中の削除された API を特定します。$ oc get apirequestcounts
出力例
NAME REMOVEDINRELEASE REQUESTSINCURRENTHOUR REQUESTSINLAST24H ... flowschemas.v1beta2.flowcontrol.apiserver.k8s.io 1.29 0 3 ... prioritylevelconfigurations.v1beta2.flowcontrol.apiserver.k8s.io 1.29 0 1 ...
重要結果に表示される以下のエントリーは無視しても問題はありません。
-
system:serviceaccount:kube-system:generic-garbage-collectorおよびsystem:serviceaccount:kube-system:namespace-controllerユーザーは、削除するリソースの検索時に登録されたすべての API を呼び出すので、結果に表示される可能性があります。 -
system:kube-controller-managerおよびsystem:cluster-policy-controllerユーザーは、さまざまなポリシーを適用しながらすべてのリソースをウォークスルーするため、結果に表示される場合があります。
-o jsonpathを使用して結果をフィルタリングすることもできます。$ oc get apirequestcounts -o jsonpath='{range .items[?(@.status.removedInRelease!="")]}{.status.removedInRelease}{"\t"}{.metadata.name}{"\n"}{end}'出力例
1.29 flowschemas.v1beta2.flowcontrol.apiserver.k8s.io 1.29 prioritylevelconfigurations.v1beta2.flowcontrol.apiserver.k8s.io
-
2.1.2.2.3. APIRequestCount を使用して削除された API を使用しているワークロードを特定
特定の API バージョンの APIRequestCount リソースを確認することで、API を使用しているワークロードを特定できます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
以下のコマンドを実行して
usernameおよびuserAgentを確認すると、API を使用しているワークロードの特定に役立ちます。$ oc get apirequestcounts <resource>.<version>.<group> -o yaml
以下に例を示します。
$ oc get apirequestcounts flowschemas.v1beta2.flowcontrol.apiserver.k8s.io -o yaml
-o jsonpathを使用して、APIRequestCountリソースからusernameおよびuserAgentの値を抽出することもできます。$ oc get apirequestcounts flowschemas.v1beta2.flowcontrol.apiserver.k8s.io \ -o jsonpath='{range .status.currentHour..byUser[*]}{..byVerb[*].verb}{","}{.username}{","}{.userAgent}{"\n"}{end}' \ | sort -k 2 -t, -u | column -t -s, -NVERBS,USERNAME,USERAGENT出力例
VERBS USERNAME USERAGENT create system:admin oc/4.13.0 (linux/amd64) list get system:serviceaccount:myns:default oc/4.16.0 (linux/amd64) watch system:serviceaccount:myns:webhook webhook/v1.0.0 (linux/amd64)
2.1.2.3. 削除された API インスタンスの移行
削除された Kubernetes API を移行する方法は、Kubernetes ドキュメントの Deprecated API Migration Guide を参照してください。
2.1.2.4. 管理者の確認の提供
削除された API についてクラスターを評価し、削除された API を移行すると、クラスターが OpenShift Container Platform 4.15 から 4.16 にアップグレードできることを確認できます。
この管理者の確認を提供する前に、削除された API のすべての使用が解決され、必要に応じて移行されたことを確認するすべての責任は管理者にあることに注意してください。OpenShift Container Platform はその評価を支援できますが、とくにアイドル状態のワークロードや外部ツールなど、削除された API の考えられるすべての用途を特定することはできません。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
以下のコマンドを実行して、評価が完了し、クラスターが OpenShift Container Platform 4.16 で Kubernetes API を削除する準備ができていることを確認します。
$ oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.15-kube-1.29-api-removals-in-4.16":"true"}}' --type=merge
2.1.3. 条件付き更新のリスク評価
条件付き更新 は、使用可能な更新ターゲットですが、クラスターに適用される既知のリスクのため推奨されません。Cluster Version Operator (CVO) は、OpenShift Update Service (OSUS) に定期的にクエリーを実行して、更新の推奨事項に関する最新のデータを取得します。ターゲットとなりうる一部の更新には、それに関連するリスクが含まれる可能性があります。
CVO は条件付きリスクを評価します。そのリスクがクラスターに当てはまらない場合、クラスターはそのターゲットバージョンを推奨される更新パスとして使用できます。リスクが当てはまると判断された場合、または何らかの理由で CVO がリスクを評価できない場合、クラスターはその更新ターゲットを条件付き更新として使用できます。
ターゲットバージョンに更新しようとしているときに条件付き更新が発生した場合は、クラスターをそのバージョンに更新するリスクを評価する必要があります。一般的に、そのターゲットバージョンに更新する必要性が特にない場合は、推奨される更新パスが Red Hat から提供されるまで待つのが最善です。
ただし、そのバージョンに更新する明確な理由がある場合 (たとえば重要な CVE を修正する必要がある場合など)、CVE を修正する利点が、更新によってクラスターに問題が発生するリスクを上回る可能性があります。以下のタスクを実行して、Red Hat の更新リスク評価に同意するか判断してください。
- 実稼働環境で問題なく更新を完了できると確信が持てるまで、非実稼働環境で幅広くテストしてください。
- 条件付き更新の説明に記載されているリンクを使用してバグを調査し、使用しているクラスターに問題を引き起こす可能性があるか判断します。リスクを把握するためにサポートが必要な場合は、Red Hat サポートにお問い合わせください。
関連情報
2.1.4. クラスター更新前の etcd バックアップ
etcd バックアップには、クラスターとそのすべてのリソースオブジェクトの状態が記録されます。現在機能不全状態にあるクラスターを復元できない障害シナリオでは、バックアップを使用してクラスターの状態の復元を試みることができます。
更新のコンテキストでは、更新によってクラスターの以前のバージョンに戻さないと修正できない壊滅的な状態が発生した場合に、クラスターの etcd 復元を試みることができます。etcd 復元は、実行中のクラスターにとって破壊的で不安定になる可能性があるため、最後の手段としてのみ使用してください。
etcd 復元は重大な影響をもたらすため、ロールバックソリューションとして使用することは意図されていません。クラスターの以前のバージョンへのロールバックはサポートされていません。更新が完了しない場合は、Red Hat サポートにお問い合わせください。
etcd 復元の実行可能性に影響を与える要因がいくつかあります。詳細は、「etcd データのバックアップ」および「以前のクラスター状態への復元」を参照してください。
2.1.5. クラスター更新のベストプラクティス
OpenShift Container Platform は、更新中のワークロードの中断を最小限に抑える堅牢な更新エクスペリエンスを提供します。更新要求時にクラスターがアップグレード可能な状態にない限り、更新は開始されません。
この設計では、更新を開始する前にいくつかの重要な条件を強制しますが、クラスターの更新が成功する可能性を高めるために実行できるアクションは多数あります。
2.1.5.1. OpenShift Update Service 推奨バージョンの選択
OpenShift Update Service (OSUS) は、クラスターがサブスクライブしているチャネルなどをはじめとするクラスターの特性に基づき、更新に関する推奨を提示します。Cluster Version Operator は、これらの推奨事項を推奨される更新または条件付き更新として保存します。OSUS が推奨していないバージョンへの更新を試行できますが、推奨される更新パスに従うことで、ユーザーはクラスター上での既知の問題や予期せぬ結果の発生から保護されます。
更新を確実に成功させるためには、OSUS が推奨する更新ターゲットのみを選択してください。
2.1.5.2. クラスター上ですべての重大アラートに対処する
重大なアラートには、常に可能な限り早く対処する必要がありますが、クラスターの更新を開始する前にこれらのアラートに対処し、問題を解決することが特に重要です。更新を開始する前に重大アラートに対処しなければ、クラスターが問題のある状態に陥る可能性があります。
Web コンソールの Administrator パースペクティブで、Observe
2.1.5.3. クラスターの状態が Upgradable であることを確認する
1 つ以上の Operator が 1 時間以上 Upgradeable 条件を True として報告しなかった場合、クラスター内で ClusterNotUpgradeable 警告アラートがトリガーされます。このアラートがパッチ更新をブロックすることはほぼありませんが、このアラートを解決し、すべての Operator が Upgradeable に対して True と報告するまで、マイナーバージョンの更新は実行できません。
Upgradeable 条件の詳細には、追加リソースセクションの「クラスター Operator の条件タイプ」を参照してください。
2.1.5.4. 十分な予備ノードが利用可能であることを確認する
特にクラスターの更新を開始する場合は、予備のノード容量がほとんどない、またはまったくない状態でクラスターを実行するべきではありません。ノードが実行されておらず、使用できない場合、クラスターのワークロードの中断を最小限に抑えつつ更新を実行するという能力が制限される可能性があります。
クラスターの maxUnavailable 仕様の設定値によっては、使用できないノードがある場合にクラスターはマシン設定の変更をノードに適用できない可能性があります。さらに、コンピュートノードに十分な予備容量がない場合、最初のノードが更新のためにオフラインになっている間、ワークロードを一時的に別のノードに移行できない可能性があります。
ノード更新が成功する可能性を高めるために、各ワーカープールに十分な使用可能なノードがあること、およびコンピュートノードに十分な予備容量があることを確認してください。
OpenShift Container Platform のすべてのマシン設定プールにおける maxUnavailable のデフォルト設定は 1 です。この値を変更せず、一度に 1 つのコントロールプレーンノードを更新することを推奨します。コントロールプレーンプールのこの値を 3 に変更しないでください。
2.1.5.5. クラスターの PodDisruptionBudget が適切に設定されていることを確認する
PodDisruptionBudget オブジェクトを使用して、常に使用可能でなければならない Pod レプリカの最小数または割合を定義できます。この設定により、クラスター更新などのメンテナンスタスク中にワークロードが中断されないように保護できます。
ただし、クラスターの更新中にノードがドレインおよび更新されないように、特定のトポロジーに対して PodDisruptionBudget を設定できます。
クラスターの更新を計画する際には、次の要因に対する PodDisruptionBudget オブジェクトの設定を確認してください。
-
高可用性ワークロードの場合は、
PodDisruptionBudgetで禁止されることなく一時的にオフラインにできるレプリカがあることを確認してください。 -
高可用性以外のワークロードの場合は、
PodDisruptionBudgetで保護されていないこと、または最終的にこれらのワークロードをドレインするための代替メカニズム (定期的な再起動や最終的な終了の保証など) があることを確認してください。
