OpenShift 4.14 以降の延長アップデートサポート (Extended Update Support) の追加を発表

Red Hat はここに、OpenShift 4.14 以降の Red Hat OpenShift の偶数番号リリースの EUS 期間について、オプションとして 12 カ月延長できるようになったことを発表いたします。これにより、これらの OpenShift の EUS リリースのライフサイクルは 3 年間有効になります。

ここデンバーで OpenShift Commons Gathering と共に Red Hat Summit を開催するにあたり、Red Hat OpenShift を日常業務でご利用いただいているお客様の声を聞かせていただけることを楽しみにしています。過去数年間、OpenShift をご利用いただいているお客様は、OpenShift テクノロジーを、より長いライフサイクルを必要とする特殊な市場のユースケースに応用してきました。複数の層で構成されるコンプライアンス要件や、OpenShift には政府と企業が通常とは異なる方法で扱う重要なサービスが含まれるという事実により、Red Hat のお客様は、Red Hat に対してオープンソースのコンポーネントの有効期間を延長する方法を求めています。Red Hat は毎年、複数の基準に基づいてライフサイクルを延長する可能性について調査しています。今年になって、Red Hat は適切な条件を組み合わせることにより、同様の状況にいるお客様を支援することができることを確認しました。

Red Hat では、お客様の複雑なニーズに対応するために、Red Hat OpenShift の Extended Update Support (EUS) サービスを拡張して、OpenShift デプロイメントのサポートライフサイクルを大幅に延長するオプションを提供します。

OpenShift 4.12 のリリース時に導入された既存の EUS は 6 カ月ですが、今後は期間をさらに延長してサポートが提供されます。この新たな 12 カ月の EUS 期間はアドオン・サブスクリプションとして利用可能で、OpenShift のライフサイクルは合計 3 年間になります。

EUS 期間が延長されたことで、OpenShift 4.14 は 2026 年 10 月 31 日までサポートされることになります。

次の Extended Update Support (EUS) リリースは、次の OpenShift 4.16 リリースになります。EUS リリースによるライフサイクルへの調整についても、以下で視覚的に確認できます。

対象となるサポートのレベル

EUS の追加期間には、重大な影響 (Critical Impact) および重要な影響 (Important Impact) を与える問題に対するセキュリティアップデートのバックポートや、緊急で優先度の高いバグ修正が含まれます。正式には、Red Hat OpenShift Container Platform ライフサイクルポリシーのページで公開されます。このページは、最新の OpenShift ライフサイクルに関する信頼できる情報源です。

EUS の追加フェーズで提供されるサポートの SLA は、購入済みのベースオファリング (Premium または Standard) から継承されます。

対象となるコンポーネント

EUS の追加期間は、OpenShift Kubernetes Engine に含まれるプラットフォーム対応の Operator すべてに適用されます。他の Operator は自動的には含まれず、引き続き独自のライフサイクルを維持します。

OpenShift Platform Plus または OpenShift Container Platform を基本サブスクリプションとして購入するお客様は、そのオファリングに適用される同等の追加の Extended Update Support を購入できますが、この EUS は、そのオファリングで利用可能なコンポーネントに対してのみ適用されます。

Red Hat は、この追加の EUS を、今後はさらに多くの Red Hat Operator に展開していく予定です。階層化された Operator の関連のあるものについては、常にライフサイクルページで最新のライフサイクル情報を確認してください。

アップグレードへの影響

OpenShift 4.14 は、コントロールプレーン・サービスとワーカーノード間の N-2 バージョンスキューのサポートを維持します。ここで、N は関連する OpenShift マイナーリリースを表します。たとえば、OpenShift 4.14 に移行したコントロールプレーンの場合、アップグレードシーケンスの一部として 4.13 および/または 4.12 上のワーカーノードと相互運用できることを意味します。

コントロールプレーンのノード自体については、アップグレードは依然として順次またシーケンシャルに行われます。ただし、ワーカーノードには、ワーカープールを一時停止する機能があり、2 つ目のリリースとそれに伴う再起動をスキップすることができます。バージョンスキューのサポートと組み合わせることで、実行中のワークロードに対する複数のアップグレードの追加の影響を軽減することができます。

4.14 から今後の 4.18 リリースへのコントロールプレーンおよびワーカーノードのアップグレードフローのサンプル。

この機能の追加のテストは、N-3 バージョンのスキューポリシーのサポートに移行するアップストリームの Kubernetes バージョンスキューの拡張に合わせて今後のリリースでさらに拡張される予定です。

ソースとアップグレード先のリリース間の期間が次第に長くなるにつれて、最新の EUS リリースを取得するために必要なシーケンシャルアップグレードの数が増えていきます。必要となるシーケンシャルアップグレードの回数が増えるほど、アップグレードの複雑さ、ワークロードの中断のレベル、さらにアップグレードの完了までに要する時間も増加します。そのため、容量がある場合には、ブルーグリーンアップグレードのプロセスでのアップグレードで、新しいクラスターをスケールアップしてワークロードを移行し、古いクラスターを廃止する方法が望ましい場合があります。

クラスターはすべて異なるため、アップグレードにはそれぞれのクラスターごとに独自のパスが必要です。これらの OpenShift EUS をクラスタに利用することを選択する際には、それと同時にアップグレードの計画を検討し、選択することをお勧めします。

詳細情報を参照する方法

Red Hat は、Kubernetes エコシステム内の Long Term Support (LTS) ワーキンググループに参加し、Kubernetes とその関連テクノロジーの有効期間を延ばす方法に関するアイデアを育むように支援しています。このトピックに関心のあるユーザーはぜひこのコミュニティに参加してください。

今後開催される「What's New in OpenShift 4.16」バーチャルイベントで詳細をご確認ください。YouTube または Twitch でフォローしていただくと、配信日についての通知を受け取ることができます。

まだ OpenShift ユーザーではなく、ご興味をお持ちの方は、こちらの Try It にアクセスしてください。