第2章 OpenShift の更新について
2.1. OpenShift の更新の概要
OpenShift Container Platform 4 では、Web コンソールまたは OpenShift CLI (oc) を使用して、OpenShift Container Platform クラスターを 1 回の操作で更新できます。プラットフォーム管理者は、Web コンソールの Administration oc adm upgrade コマンドの出力を確認して、新しい更新オプションを表示できます。
Red Hat はパブリック OpenShift Update Service (OSUS) をホストします。これは、公式レジストリーの OpenShift Container Platform リリースイメージに基づいて更新の可能性を示すグラフを提供します。グラフには、パブリック OCP リリースの更新情報が含まれます。OpenShift Container Platform クラスターはデフォルトで OSUS に接続するように設定されており、OSUS は既知の更新ターゲットに関する情報をクラスターに応答します。
クラスター管理者または自動更新コントローラーのいずれかが、Cluster Version Operator (CVO) のカスタムリソース (CR) を新しいバージョンで編集すると、更新が開始されます。クラスターを新たに指定したバージョンに合わせて調整するために、CVO はイメージレジストリーからターゲットリリースイメージを取得し、クラスターへの変更適用を開始します。
Operator Lifecycle Manager (OLM) を介して以前にインストールされた Operator は、異なる更新プロセスに従います。詳細は、インストール済み Operator の更新 を参照してください。
ターゲットリリースイメージには、特定の OCP バージョンを形成するすべてのクラスターコンポーネントのマニフェストファイルが含まれます。クラスターを新しいバージョンに更新する場合、CVO は Runlevels と呼ばれる別のステージでマニフェストを適用します。すべてではありませんが、ほとんどのマニフェストは、いずれかのクラスター Operator をサポートしています。CVO がクラスター Operator にマニフェストを適用すると、Operator が指定された新しいバージョンに適合させるために更新タスクを実行する可能性があります。
CVO は、適用された各リソースの状態と、すべてのクラスター Operator によって報告される状態を監視します。CVO は、アクティブな Runlevel のすべてのマニフェストおよびクラスター Operator が安定した状態に達した場合にのみ更新を続行します。CVO がこのプロセスを通じてコントロールプレーン全体を更新した後、Machine Config Operator (MCO) がオペレーティングシステムとクラスター内のすべてのノードの設定を更新します。
2.1.1. 更新の可用性に関するよくある質問
OpenShift Container Platform クラスターで更新が利用可能になるかどうか、またいつ利用可能になるかに影響を与える要因がいくつかあります。次のリストは、更新の入手可能性に関する一般的な質問を示しています。
各更新チャネルの違いは何ですか?
-
新しいリリースは、最初に
candidateチャネルに追加されます。 -
最終テストが成功すると、
candidateチャネルのリリースがfastチャネルに昇格され、正誤表が公開され、リリースは完全にサポートされるようになります。 遅延の後、
fastチャネルでのリリースは最終的にstableチャネルに昇格されます。この遅延は、fastチャネルとstableチャネルの唯一の違いを表します。注記最新の z-stream リリースの場合、この遅延は通常 1 ~ 2 週間かかる可能性があります。ただし、最新のマイナーバージョンへの最初の更新の遅延にはさらに時間がかかる場合があり、通常は 45 ~ 90 日かかります。
-
stableチャネルにプロモートされたリリースは、同時にeusチャネルにもプロモートされます。eusチャネルの主な目的は、EUS から EUS への更新を実行するクラスターの利便性を高めることです。
stable チャネルでのリリースは fast チャネルでのリリースよりも安全ですか、それともよりサポートされていますか?
-
fastチャネルのリリースで回帰が特定された場合、その回帰がstableチャネルのリリースで特定された場合と同じ程度に解決され、管理されます。 -
fastチャネルとstableチャネルのリリースの唯一の違いは、リリースがfastチャネル上にしばらく存在した後にのみstableチャネルに表示されることです。これにより、新しい更新のリスクが発見されるまでの時間が長くなります。 -
この遅延の後、
fastチャネルで利用可能なリリースは必ず安定チャネルでも利用可能になります。
更新はサポートされているが推奨されていないとはどういう意味ですか?
- Red Hat は、複数のソースからのデータを継続的に評価して、あるバージョンから別のバージョンへの更新が問題を引き起こすかどうかを判断します。問題が特定された場合、更新パスはユーザーに推奨されなくなる場合があります。ただし、更新パスが推奨されない場合でも、更新を実行する場合はサポートが提供されます。
Red Hat は、ユーザーが特定のバージョンに更新することをブロックしません。Red Hat は条件付き更新のリスクを宣言する場合がありますが、これは特定のクラスターに適用される場合と適用されない場合があります。
- 宣言されたリスクにより、クラスター管理者はサポートされている更新に関する詳細なコンテキストが得られます。クラスター管理者はリスクを受け入れて、その特定のターゲットバージョンに更新することができます。この更新プログラムは、条件付きリスクの観点から推奨されていないにもかかわらず、常にサポートされています。
特定のリリースへの更新が推奨されなくなった場合はどうすればよいですか?
- Red Hat がリグレッションのためにサポートされているリリースから更新の推奨事項を削除した場合、リグレッションを修正する将来のバージョンに、代替となる更新の推奨事項が提供されます。問題の修正とテスト、選択したチャネルへの昇格に、時間がかかる可能性があります。
次の z-stream リリースが高速で安定したチャネルで利用できるようになるまで、どれくらいかかりますか?
具体的な頻度はさまざまな要因によって異なりますが、最新のマイナーバージョンの新しい z-stream リリースは通常、ほぼ毎週公開されます。古いマイナーバージョンは時間の経過とともに安定してきており、新しい z-stream リリースが利用可能になるまでにさらに時間がかかる場合があります。
重要これらは、z-stream リリースに関する過去のデータに基づく推定にすぎません。Red Hat は、必要に応じてリリース頻度を変更する権利を保持しています。問題がいくらでも発生すると、このリリースサイクルに不規則性や遅れが生じる可能性があります。
-
Z-stream リリースが公開されると、そのマイナーバージョンの
fastチャネルにも表示されます。遅延後、z-stream リリースがそのマイナーバージョンのstableチャネルに表示される場合があります。
関連情報
2.1.2. OpenShift Update Service について
OpenShift Update Service (OSUS) は、Red Hat Enterprise Linux CoreOS (RHCOS) を含む OpenShift Container Platform に更新の推奨項目を提供します。コンポーネント Operator のグラフ、または 頂点 とそれらを結ぶ 辺 を含む図表が提示されます。グラフのエッジでは、安全に更新できるバージョンが表示されます。頂点は、マネージドクラスターコンポーネントの意図された状態を指定する更新ペイロードです。
クラスター内の Cluster Version Operator (CVO) は、OpenShift Update Service をチェックして、グラフの現在のコンポーネントバージョンとグラフの情報に基づき、有効な更新および更新パスを確認します。更新をリクエストすると、CVO は対応するリリースイメージを使用してクラスターを更新します。リリースアーティファクトは、コンテナーイメージとして Quay でホストされます。
OpenShift Update Service が互換性のある更新のみを提供できるようにするために、リリース検証 Pipeline で自動化を支援します。それぞれのリリースアーティファクトについて、他のコンポーネントパッケージだけでなくサポートされているクラウドプラットフォームおよびシステムアーキテクチャーとの互換性の有無が検証されます。Pipeline がリリースの適合性を確認した後に、OpenShift Update Service は更新が利用可能であることを通知します。
OpenShift Update Service は、現在のクラスターに推奨される更新をすべて表示します。OpenShift Update Service が推奨する更新パスがない場合には、更新またはターゲットリリースに関連する既知の問題がある可能性があります。
連続更新モード中は、2 つのコントローラーが実行されます。1 つのコントローラーはペイロードマニフェストを絶えず更新し、そのマニフェストをクラスターに適用し、Operator が利用可能か、アップグレード中か、失敗しているかに応じて Operator の制御されたロールアウトのステータスを出力します。2 つ目のコントローラーは OpenShift Update Service をポーリングして、更新が利用可能かどうかを判別します。
新しいバージョンへの更新のみがサポートされています。クラスターを以前のバージョンに戻すまたはロールバックすることはサポートされていません。更新が失敗した場合は、Red Hat サポートに連絡してください。
更新プロセスで、Machine Config Operator (MCO) は新規設定をクラスターマシンに適用します。MCO は、マシン設定プールの maxUnavailable フィールドで指定されたノードの数を制限し、それらを使用不可としてマークします。デフォルトで、この値は 1 に設定されます。MCO は、topology.kubernetes.io/zone ラベルに基づいて、影響を受けるノードをゾーンごとにアルファベット順に更新します。ゾーンに複数のノードがある場合、最も古いノードが最初に更新されます。ベアメタルデプロイメントなど、ゾーンを使用しないノードの場合、ノードは経過時間ごとに更新され、最も古いノードが最初に更新されます。MCO は、マシン設定プールの maxUnavailable フィールドで指定されたノード数を一度に更新します。次に、MCO は新しい設定を適用して、マシンを再起動します。
Red Hat Enterprise Linux (RHEL) マシンをワーカーとして使用する場合、まず OpenShift API をそれらのマシンで更新する必要があるため、MCO は kubelet を更新しません。
新規バージョンの仕様は古い kubelet に適用されるため、RHEL マシンを Ready 状態に戻すことができません。マシンが利用可能になるまで更新を完了することはできません。ただし、利用不可のノードの最大数は、その数のマシンがサービス停止状態のマシンとして分離されても通常のクラスター操作が継続できるようにするために設定されます。
OpenShift Update Service は Operator および 1 つ以上のアプリケーションインスタンスで構成されます。
2.1.3. 一般的な用語
- コントロールプレーン
- コントロールプレーンマシンで構成される コントロールプレーン は、OpenShift Container Platform クラスターを管理します。コントロールプレーンマシンは、コンピュートマシン (ワーカーマシンとしても知られる) のワークロードを管理します。
- Cluster Version Operator
- Cluster Version Operator (CVO) は、クラスターの更新プロセスを開始します。現在のクラスターバージョンに基づいて OSUS を確認し、利用可能または可能な更新パスを含むグラフを取得します。
- Machine Config Operator
- Machine Config Operator (MCO) は、オペレーティングシステムおよびマシン設定を管理するクラスターレベルの Operator です。プラットフォーム管理者は、MCO を介して、systemd、CRI-O、Kubelet、カーネル、NetworkManager、およびワーカーノード上のその他のシステム機能を設定および更新できます。
- OpenShift Update Service
- OpenShift Update Service (OSUS) は、Red Hat Enterprise Linux CoreOS (RHCOS) を含む OpenShift Container Platform に OTA (over-the-air) 更新を提供します。コンポーネント Operator のグラフ、または頂点とそれらを結ぶ辺を含む図表が提示されます。
- チャネル
- チャネル は、OpenShift Container Platform のマイナーバージョンに関連付けられた更新戦略を宣言します。OSUS は、この設定された戦略を使用して、その戦略と一致する更新エッジを推奨します。
- 推奨される更新エッジ
- 推奨される更新エッジ は、OpenShift Container Platform リリース間の推奨される更新です。特定の更新が推奨されるかどうかは、クラスターの設定済みチャネル、現在のバージョン、既知のバグ、およびその他の情報によって異なります。OSUS は、推奨されるエッジを、すべてのクラスターで実行される CVO に伝達します。
- 延長更新サポート (EUS)
4.7 以降の偶数番号のマイナーリリースはすべて、Extended Update Support (EUS) リリースとしてラベル付けされています。これらのリリースでは、EUS リリース間に検証済みの更新パスが導入され、お客様はワーカーのワーカーノードの更新が合理化され、ワーカーノードの再起動を減らす EUS から EUS への OpenShift Container Platform リリースの更新戦略を策定できます。
詳細は、Red Hat OpenShift 延長更新サポート (EUS) の概要 を参照してください。
2.1.4. 関連情報
- 更新プロセスの主要点に関する詳細は、クラスターの更新の仕組み を参照してください。
