トップ > Red Hat OpenShift Container Platform > OpenShift Container Platformのライフサイクル変更について

OpenShift Container Platformのライフサイクル変更について

Red Hat OpenShift Container Platform

OpenStackやOpenShiftなどのCloud製品を担当しているソリューションアーキテクトの輿水です。

今回はOpenShift Container Platformのライフサイクル変更についてのお話です。10月にOpenShift Container Platform 4.9がリリースされたタイミングで、OpenShift 4のサポート期間が変更され、4.7以降のすべてのリリースのサポート期間が18ヶ月になりました。

f:id:mkoshimizu:20211228181756p:plain

  • 変更前

    • フルサポート約4ヶ月＋メンテナンスサポート約5ヶ月＝合計約9ヶ月間のサポート
    • Extended Update Support （EUS）リリースのみ18ヶ月間のサポート
    • 該当するEUSリリースは4.6のみ
    • EUSを利用するためにはプレミアムサポートサブスクリプションが必要

  • 変更後

    • すべてのリリースでサポート期間は18ヶ月
      • フルサポート期間：6ヶ月または次期リリース一般提供日＋90日のいずれか長い方
      • メンテナンスサポート期間：フルサポート終了日から18ヶ月まで
    • 偶数リリース（4.8, 4.10, 4.12）がExtended Update Support （EUS）リリース
    • EUSはスタンダードサポートサブスクリプションとプレミアムサポートサブスクリプション両方で利用可能
    • EUSリリースから次のEUSリリースへのテスト済アップグレードパスが提供される

f:id:mkoshimizu:20211228145543p:plain

ライフサイクル変更の理由について、Red Hat が公開している英語版ブログ「Hybrid cloud blog」に「Time Is On Your Side: A Change to the OpenShift 4 Lifecycle」という記事があります。この英語版ブログ「Hybrid cloud blog」は頻繁に更新されていて技術的なこともたくさん紹介されているのですが、英語のみなのであまり日本のユーザーの目に触れることはないように感じます。良い記事があったらなるべくご紹介したいとは思います。

今回は「Time Is On Your Side: A Change to the OpenShift 4 Lifecycle」の内容を意訳してかいつまんでご紹介します。

すべてのリリースが18か月にもかかわらず、なぜEUSの概念を維持するのか？

Red Hatは、2つの主な理由から、EUSリリースの概念を維持することを決定しました。

ひとつめは、今後の変化に備えることです。今後数年間でUpstreamのKubernetesが進化し、18か月以上を安全に提供できるようになることを期待しています。18か月よりサポートが伸びる場合は、特定のリリースで対応します。偶数リリース（4.6、4.8、4.10、4.12 ..）をEUSリリースとして宣言しますが、18か月以上のサポートを提供できるようになった場合は、その先の偶数リリースで対応します。

ふたつめはアップグレードに関係しています。アップグレード時にKubernetesのバージョンをスキップすることはできません（例えばKubernetes1.22からKubernetes1.24へのアップグレードは不可）。アップグレードはひとつずつ順次実行する必要があります。 Red Hatは、OpenShift 4.8以降の偶数リリース間、たとえば、4.8から4.10または4.10から4.12といったアップグレードに関して、テスト済の認定されたアップグレードパスを提供します。アップグレードの開始時に、ワーカーノードでのアップグレードプロセスを一時停止し、2つのバージョンのOpenShiftを実行（コントロールプレーンアップグレードを2度実行）してから、一時停止を解除できるようにしています。コントロールプレーンはシリアルにアップグレードしますが、アップグレード中のワーカーノードの再起動が1回少なくなります。 テストマトリックスのサイズをRed HatとlISVベンダーの両方にとって管理しやすい状態に保つために、この合理化されたワーカーアップグレードプロセスは、EUSリリースにのみ対応します。

スタンダードサポートサブスクリプションとプレミアムサポートサブスクリプション両方でEUS利用可能にした理由

多くの場合、ビジネス上の理由（本番環境）でひとつのプレミアムサポートサブスクリプションを購入し、他のユースケース（開発やテスト環境）ではスタンダードサポートサブスクリプションを購入します。サブスクリプションでライフサイクルが異なるという事は、クラスターのライフサイクルの状況によっては、テスト環境でのテストが本番環境と一致しない事が考えられます。そのような状況を回避するために、スタンダードサポートサブスクリプションとプレミアムサポートサブスクリプション両方で利用可能にしました。

バージョンの選択

4.6リリースがサポート期間の長いEUSであると発表されてから、4.7や4.8,4.9がユーザーのユースケースに適した機能を持っていていたとしても、サポート期間の長い4.6を選択する傾向があるとわかりました。本来ユーザーは、必要な機能に基づいてバージョンを選択する自由があります。すべてのリリースに一貫した長期サポートを提供することで、ユーザーが利用したいバージョンを選択できると考えます。

ユーティリティ

多くのお客様は、OpenShiftの新バージョンのロールアウトのために、開発環境・テスト環境・商用環境を持っています。場合によっては、様々なベンダーが関与しており、他のベンダーに環境を引き渡す前に、ソフトウェアを使用する時間を確保する必要があります。彼らのCI/CDプロセスは平均して四半期で、四半期中のどのタイミングで新しいリリースが提供されるかによって、プラスマイナス2ヶ月になる可能性があり、最も安全または最も保守的な確保時間の見積もりは6ヶ月です。ローリングウィンドウ方式が平均12ヶ月で製品を生産している場合、リリースから6ヶ月（12ヶ月-6ヶ月=6ヶ月）のユーティリティしか得られませんでした。Red Hatは、確実に12ヶ月のユーティリティを提供する方法を考えて、18ヶ月のライフサイクルによって問題が解決できると考えます。

APIがサポートの長さを決定する

OpenShiftをサポートする期間を決定するために、KubernetesとCNCFオープンソースソフトウェアプロジェクトを調べました。ライフサイクル期間を分析する場合、ベンダーが考慮しなければならない最も重要な要素は、お客様が可能な限り特定のリリースの利用を継続した場合に何が起こるかです。たとえば、OpenShift（Kubernetes）のリリースを18か月間継続するとどうなるか？現在使用しているリリースのAPIとアップグレード先のリリースのAPI間で、アップグレードを通過できるのか？といったことです。 Kubernetes Upstreamは最大で12か月のサポートと宣言しています。 OpenShiftでサポートされているものとして公開しているAPIを考えると、お客様に安全にサポートを拡張できる最長の期間は18か月であると判断しました。 Kubernetesが現在の1.2Xから成熟するにつれて、1.3X KubernetesバージョンからOpenShiftを構築するときに、このサポート範囲を拡張できる可能性はあります。

パッチのリリース頻度

すべてのマイナーリリース（OpenShift 4.y）を18か月サポートするということは、Red Hatはいつでも6リリース（開発中の現在のリリースを数える）のコードブランチを維持することを意味します。

https://content.cloud.redhat.com/hubfs/Google%20Drive%20Integration/OpenShift%204%20Life%20Cycle%20Blog.png

OpenShift 3の場合、より迅速なリリースを必要とする重大なバグとセキュリティの問題を除いて、約1か月に1回パッチをリリースしていました。OpenShift 4にでは週に1回パッチをリリースし、お客様がコードの継続的デリバリーに近い何かを体験できるようにしました。

お客様向けに6つのバージョンのOpenShiftをサポートすることを検討しているため、OpenShift3とOpenShift4の経験をブレンドすることにしました。開発ブランチ（ナイトリーと呼ばれることもあります）では、現在のGAバージョンと、現在より1つ古いリリースに対して週に1回の頻度でパッチをリリースし続けます。3番目、4番目、および5番目に古いリリースでは、月に1回の頻度でパッチをリリースします。より早くリリースする必要がある例外もありますが、この頻度が、現在のリリースに基づく平均値になります。

OpenShiftリリース頻度

結論として、メジャーナンバー（OpenShift 4）のリリース中にライフサイクルを頻繁に変更することはありません。今回のライフサイクルの変更によって、Kubernetes Upstreamに 遅れをとるようなことはありません。何年にもわたって行ってきたように、Upstreamから1クォーター（四半期）後にリリースし続けます。 2022年にKubernetes Upstreamは年間4回のリリースから年間3回のリリースに移行します。これは、OpenShiftが2022年にOpenShift 4の3つのマイナーバージョンをリリースすることを意味します。

ブログの締めくくりには「このブログに含まれている背景情報によって、何が変わったのかだけでなく、なぜ変わったのかをよりよく理解できることを願っています。」と書かれておりましたが、いかがでしたでしょうか？

  • OpenShift 4のリリースサイクルは今後しばらくは変わらない
  • OpenShift 4のマイナーバージョンは年3回のリリース
  • パッチに関する記載の部分の図を見るとOCP 4.16 / Kube 1.29くらいまでは予定にある

ライフサイクルとリリースサイクルによれば、来春には4.10がリリースされてEUStoEUSのアップデートに関するお話ができるのではと思っております。

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。