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

第2章 クラスターの更新の準備

2.1. OpenShift Container Platform 4.14 への更新の準備

更新を正常に初期化するためにクラスター管理者が実行する必要がある管理タスクと、更新を確実に成功させるためのオプションのガイドラインを詳しく説明します。

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.14 は Kubernetes 1.27 を使用します。これにより、複数の非推奨 API が削除されました。

クラスター管理者は、クラスターを OpenShift Container Platform 4.13 から 4.14 にアップグレードする前に、手動で確認を行う必要があります。削除された API が、クラスター上で実行されている、またはクラスターと対話しているワークロード、ツール、またはその他のコンポーネントによって引き続き使用される OpenShift Container Platform 4.14 にアップグレードした後の問題を防ぐ上で役立ちます。管理者は、削除が予定されている使用中の API に対するクラスターの評価を実施し、影響を受けるコンポーネントを移行して適切な新規 API バージョンを使用する必要があります。この評価および移行が完了したら、管理者は確認応答を提供できます。

OpenShift Container Platform 4.13 クラスターを 4.14 に更新する前に、管理者の確認を提供する必要があります。

2.1.2.1. Kubernetes API の削除

OpenShift Container Platform 4.14 は Kubernetes 1.27 を使用します。これにより、以下の非推奨 API が削除されました。適切な API バージョンを使用するには、マニフェストと API クライアントを移行する必要があります。削除された API の移行について、詳細は Kubernetes documentation を参照してください。

表2.1 Kubernetes 1.27 から削除された API
リソース削除された API移行先

CSIStorageCapacity

storage.k8s.io/v1beta1

storage.k8s.io/v1

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
...
csistoragecapacities.v1.storage.k8s.io                                                  14                      380
csistoragecapacities.v1beta1.storage.k8s.io                          1.27               0                       16
custompolicydefinitions.v1beta1.capabilities.3scale.net                                 8                       158
customresourcedefinitions.v1.apiextensions.k8s.io                                       1407                    30148
...

    重要

    結果に表示される以下のエントリーは無視しても問題はありません。

    • 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.27	csistoragecapacities.v1beta1.storage.k8s.io
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 csistoragecapacities.v1beta1.storage.k8s.io -o yaml

    -o jsonpath を使用して、APIRequestCount リソースから username および userAgent の値を抽出することもできます。 

    $ oc get apirequestcounts csistoragecapacities.v1beta1.storage.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
list watch  system:kube-controller-manager  cluster-policy-controller/v0.0.0
list watch  system:kube-controller-manager  kube-controller-manager/v1.26.5+0abcdef
list watch  system:kube-scheduler           kube-scheduler/v1.26.5+0abcdef

2.1.2.3. 削除された API インスタンスの移行

削除された Kubernetes API を移行する方法は、Kubernetes ドキュメントの Deprecated API Migration Guide を参照してください。

2.1.2.4. 管理者の確認の提供

削除された API についてクラスターを評価し、削除された API を移行すると、クラスターが OpenShift Container Platform 4.13 から 4.14 にアップグレードできることを確認できます。

警告

この管理者の確認を提供する前に、削除された API のすべての使用が解決され、必要に応じて移行されたことを確認するすべての責任は管理者にあることに注意してください。OpenShift Container Platform はその評価を支援できますが、とくにアイドル状態のワークロードや外部ツールなど、削除された API の考えられるすべての用途を特定することはできません。

前提条件

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

手順

  • 以下のコマンドを実行して、評価が完了し、クラスターが OpenShift Container Platform 4.14 で Kubernetes API を削除する準備ができていることを確認します。 

    $ oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.13-kube-1.27-api-removals-in-4.14":"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.2. クラスター上ですべての重大アラートに対処する

重大なアラートには、常に可能な限り早く対処する必要がありますが、クラスターの更新を開始する前にこれらのアラートに対処し、問題を解決することが特に重要です。更新を開始する前に重大アラートに対処しなければ、クラスターが問題のある状態に陥る可能性があります。

Web コンソールの Administrator パースペクティブで、Observe Alerting に移動して重大なアラートを見つけます。

2.1.5.2.1. 重複したエンコーディングヘッダーが削除されていることを確認してください。

更新前に、重複する Transfer-Encoding ヘッダーの問題を記録するルートがある場合は、DuplicateTransferEncodingHeadersDetected アラートが表示されます。これは、OpenShift Container Platform 4.14 で、以前の OpenShift Container Platform リリースにおける HAProxy 2.2 から HAProxy 2.6 へのアップグレードが原因です。このアラートに対処しないと、複数の Transfer-Encoding ヘッダーを送信するアプリケーションがルートを介して到達できなくなります。

この問題を軽減するには、問題のあるアプリケーションを更新して、複数の Transfer-Encoding ヘッダーを送信しなくなりました。たとえば、アプリケーション設定ファイルで重複したヘッダーを削除する必要がある場合があります。

詳細は、Red Hat ナレッジベースアーティクル libvirt-lxc を使用した Linux コンテナー (廃止) を参照してください。

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 で保護されていないこと、または最終的にこれらのワークロードをドレインするための代替メカニズム (定期的な再起動や最終的な終了の保証など) があることを確認してください。

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.