第1章 OpenShift の更新について
1.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) がオペレーティングシステムとクラスター内のすべてのノードの設定を更新します。
1.1.1. 更新の可用性に関するよくある質問
OpenShift Container Platform クラスターで更新が利用可能になるかどうか、またいつ利用可能になるかに影響を与える要因がいくつかあります。次のリストは、更新の入手可能性に関する一般的な質問を示しています。
各更新チャネルの違いは何ですか?
-
新しいリリースは、最初に
candidateチャネルに追加されます。 -
最終テストが成功すると、
candidateチャネルのリリースがfastチャネルに昇格され、正誤表が公開され、リリースは完全にサポートされるようになります。 遅延の後、
fastチャネルでのリリースは最終的にstableチャネルに昇格されます。この遅延は、fastチャネルとstableチャネルの唯一の違いを表します。注記最新の z-stream リリースの場合、この遅延は通常 1 ~ 2 週間かかる可能性があります。ただし、最新のマイナーバージョンへの最初の更新の遅延にはさらに時間がかかる場合があり、通常は 45 ~ 90 日かかります。
-
stableチャネルにプロモートされたリリースは、同時に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チャネルに表示される場合があります。
関連情報
1.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 は新しい設定を適用して、マシンを再起動します。
OpenShift Container Platform のすべてのマシン設定プールにおける maxUnavailable のデフォルト設定は 1 です。この値を変更せず、一度に 1 つのコントロールプレーンノードを更新することを推奨します。コントロールプレーンプールのこの値を 3 に変更しないでください。
Red Hat Enterprise Linux (RHEL) マシンをワーカーとして使用する場合、まず OpenShift API をそれらのマシンで更新する必要があるため、MCO は kubelet を更新しません。
新規バージョンの仕様は古い kubelet に適用されるため、RHEL マシンを Ready 状態に戻すことができません。マシンが利用可能になるまで更新を完了することはできません。ただし、利用不可のノードの最大数は、その数のマシンがサービス停止状態のマシンとして分離されても通常のクラスター操作が継続できるようにするために設定されます。
OpenShift Update Service は Operator および 1 つ以上のアプリケーションインスタンスで構成されます。
1.1.3. クラスター Operator の状態タイプについて
クラスター Operator のステータスには、Operator の現在の正常性状態を通知する状態タイプが含まれています。以下の定義では、一般的な ClusterOperator の状態タイプをいくつか取り上げています。追加の状態タイプがあり、Operator 固有の言語を使用する Operator は省略されています。
Cluster Version Operator (CVO) は、クラスター管理者が OpenShift Container Platform クラスターのステータス状態をよりよく理解できるように、クラスター Operator からステータス状態を収集します。
-
Available: 条件タイプ
Availableは、Operator が機能しており、クラスターで使用可能であることを示します。ステータスがFalseの場合、オペランドの少なくとも 1 つの部分が機能していないため、管理者が介入する必要があります。 Progressing: 条件タイプ
Progressingは、Operator がアクティブに新しいコードをロールアウトしている、設定の変更を伝達している、またはある安定状態から別の安定状態に移行していることを示します。Operator が以前の既知の状態を調整している場合は、状態タイプ
ProgressingはTrueとして報告されません。監視されたクラスターの状態が変化し、Operator がそれに反応している場合は、ある安定状態から別の安定状態に移行しているため、ステータスはTrueとして報告されます。Degraded: 状態タイプ
Degradedは、Operator の現在の状態が一定期間にわたって必要な状態に一致しないことを示します。期間はコンポーネントによって異なる場合がありますが、Degradedステータスは、Operator の状態が継続的に監視されていることを表します。そのため、Operator のDegraded状態が変動することはありません。ある状態から別の状態への移行期間が短すぎるために
Degradedを報告できない場合は、別の状態タイプが報告される可能性があります。Operator は、通常の更新中、Degradedを報告しません。Operator は、最終的に管理者の介入を必要とする永続的なインフラストラクチャー障害への対応として、機能Degradedを報告する場合があります。注記この状態タイプは、調査と調整が必要な可能性があることを示しているにすぎません。Operator が使用可能である限り、
Degraded状態によってユーザーワークロードの障害やアプリケーションのダウンタイムが発生することはありません。Upgradeable: 条件タイプ
Upgradeableは、Operator が、現在のクラスターの状態に基づいて、安全に更新できるかどうかを示します。メッセージフィールドには、クラスターを正常に更新するために管理者が行う必要があることについて、人間が判読できる説明が含まれています。CVO は、この状態がTrue、Unknown、または状態がない場合に更新を許可します。UpgradeableステータスがFalseの場合、マイナー更新のみが影響を受け、CVO は、強制されない限り、影響を受ける更新をクラスターが実行できないようにします。
1.1.4. クラスターバージョン条件タイプについて
Cluster Version Operator (CVO) は、クラスター Operator およびその他のコンポーネントを監視し、クラスターバージョンとその Operator の両方のステータスを収集します。このステータスには、OpenShift Container Platform クラスターの正常性と現在の状態を通知する条件タイプが含まれます。
Available、Progressing、Upgradeable に加えて、クラスターのバージョンと Operator に影響する条件タイプがあります。
-
Failing: クラスターバージョン条件タイプ
Failingは、クラスターが目的の状態に到達できず、異常であり、管理者の介入が必要であることを示します。 -
Invalid: クラスターバージョン条件タイプ
Invalidは、サーバーがアクションを実行できないエラーがクラスターバージョンにあることを示します。この条件が設定されているかぎり、CVO は現在の状態のみを調整します。 -
RetrievedUpdates: クラスターバージョン条件タイプ
RetrievedUpdatesは、利用可能な更新が上流の更新サーバーから取得されたかどうかを示します。取得前の条件はUnknownです。更新が最近失敗したか、取得できなかった場合は、False、availableUpdatesフィールドが最新および正確である場合は、Trueです。 -
ReleaseAccepted:
Trueステータスのクラスターバージョン条件タイプReleaseAcceptedは、要求されたリリースペイロードが、イメージの検証および前提条件のチェック中、失敗せずに、正常に読み込まれたことを示します。 -
ImplicitlyEnabledCapabilities:
Trueステータスのクラスターバージョン条件タイプImplicitlyEnabledCapabilitiesは、ユーザーが現在spec.capabilitiesを介して要求していない有効な機能があることを示します。関連するリソースが以前に CVO によって管理されていた場合、CVO は機能の無効化をサポートしません。
1.1.5. 一般的な用語
- コントロールプレーン
- コントロールプレーンマシンで設定される コントロールプレーン は、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 に伝達します。
