Red HatでOpenShiftのサポートをしているid:nekopです。
OpenShift 4ではOpenShift Update ServiceというAPIサービスにより特定のバージョンからアップデート可能なバージョン情報を提供しており、このガイドされたバージョン情報を利用することによって安全なアップグレードを実現しています。
fast, stable, candidate, eusチャネル
各バージョンにはfast, stable, candidate, eusというチャネルがあり、たとえば4.10であればfast-4.10. stable-4.10, candidate-4.10, eus-4.10というチャネルがあります。
fastはRed Hatでのテストをパスし、GAされたリリースが追加されていく、いわゆる通常のリリースチャネルです。
stableはfastにリリースされたものが一定期間経過し、そのバージョンへアップグレードして利用するユーザが一定数認められ、影響の大きな問題が報告されていない、「安定した」と認められるリリースバージョンが追加されていきます。fastから最短で一週間ですが、最長は決まっておらず、fastの段階で報告された問題の影響の調査中などは追加が見送られます。なるべく既知の問題を回避したい、という場合はstableチャネルを利用することで、ある程度新規の問題に遭遇するリスクを下げることが可能になっています。
candidateはテスト前のビルドがリリースされるチャネルです。通常のユーザは利用することはあまりないでしょう。
eusに追加されるリリースはstableと同じですが、eusは偶数マイナーバージョンのみ提供され、たとえばeus-4.8からeus-4.10へアップグレード、というようにマイナーバージョンを2つ連続してアップグレードするためのチャネルです。EUSのアップグレードのドキュメントがあります。
基本的には利用するチャネルを選択して、アップグレードする際には以下のRed Hat OpenShift Container Platform Update Graph (要ログイン)というサービスでアップグレード可能なバージョンを参照し、アップグレードをしていくことになります。
ここからは少し細かい話をしていきます。アップグレード可能なバージョン、いわゆるアップグレードパスはどのように決められているのでしょうか。まれに新しいバージョンがリリースされているのにアップグレードパスがまだ用意されていない、といった問題や、以前あったはずのアップグレードパスが消えてしまっている、という問題が発生します。これらの問題はなぜ発生するのでしょうか。
アップグレードパスはどのように決められているのか
各チャネルのデータはcincinnati-graph-dataというGitHubリポジトリで管理されています。各リリースがいつfastに追加され、いつstableへ追加されたか、という情報はこのリポジトリの履歴で確認できます。
たとえば4.7.48は2022/04/13にfastに追加され、2022/04/20にstableへ追加された、ということがわかります。
各チャネル内のバージョンリストはcincinnati-graph-dataの定義を直接参照する他、APIからも以下のcurlコマンドで取得できます。
$ curl -sH 'Accept:application/json' 'https://api.openshift.com/api/upgrades_info/v1/graph?channel=fast-4.10' | python3 -mjson.tool | grep '"version": "4.' | sort -V
"version": "4.9.25",
"version": "4.9.26",
"version": "4.9.27",
"version": "4.9.28",
"version": "4.9.29",
"version": "4.10.3",
"version": "4.10.4",
"version": "4.10.5",
"version": "4.10.6",
"version": "4.10.8",
"version": "4.10.9",
"version": "4.10.10",
"version": "4.10.11",
各リリースバージョンの情報を持つリリースイメージというものがあり、リリースイメージは以下のようにアップグレード元となるバージョンのリストを保持しています。これを元にアップグレード可能なバージョン、アップグレードパスが計算されます。
$ oc adm release info -o json quay.io/openshift-release-dev/ocp-release:4.10.3-x86_64 | jq .metadata
W0426 14:45:35.563030 56281 helpers.go:151] Defaulting of registry auth file to "${HOME}/.docker/config.json" is deprecated. The default will be switched to podman config locations in the future version.
{
"kind": "cincinnati-metadata-v0",
"version": "4.10.3",
"previous": [
"4.10.0",
"4.10.0-fc.0",
"4.10.0-fc.1",
"4.10.0-fc.2",
"4.10.0-fc.3",
"4.10.0-fc.4",
"4.10.0-rc.0",
"4.10.0-rc.1",
"4.10.0-rc.2",
"4.10.0-rc.3",
"4.10.0-rc.4",
"4.10.0-rc.5",
"4.10.0-rc.6",
"4.10.0-rc.7",
"4.10.0-rc.8",
"4.10.1",
"4.10.2",
"4.9.19",
"4.9.21",
"4.9.22",
"4.9.23"
],
"metadata": {
"url": "https://access.redhat.com/errata/RHSA-2022:0056"
}
}
上記4.10.3であれば、たとえば4.9.23から4.10.3へのアップグレードが可能、4.9.19以前の4.9.zリリースからはアップデートができない、というのがわかります。
4.9.zの最新にしたら4.10.zへのアップグレードパスが無くなってしまいました、なぜですか？
たとえばこの4.10.3というリリースのあとに4.9.24というリリースがあった場合でも、上記のとおり4.10.3というバージョンは4.9.24からのアップデートが可能、という情報がないため、4.9.24から4.10.3というバージョンへのアップグレードパスは存在しないことになります。バージョンとしては新しいように見えますが、このようにバージョン番号だけではなく、各リリースバージョンの時系列のデータにも基づいているため、単純にバージョン番号だけで「新しい」こと、および「アップグレード可能かどうか」は判別できません。
これは各マイナーリリース最新リリース同士でも発生するもので、たとえば4.9.zの最新にアップデートした場合に、4.10.zの最新へのアップグレードパスがまだ無い、4.10.zへのアップグレードパスがひとつもない、という状況が発生します。4.9.zの最新からのアップデートが可能とされている4.10.zリリースがまだ存在しないためです。このような状況は通常1, 2週間で解消しますが、もし連続したマイナーバージョンアップデートを計画している場合はRed Hat OpenShift Container Platform Update Graphを参照して、最終的に目標とするバージョンへアップグレード可能な経由バージョンを選択してください。
とりあえず各マイナーバージョンの最新を適用してから次のマイナーバージョンへアップグレードしたい。とてもよくわかります。私も初見だとそうすると思います。しかし、上記の仕組み上、現マイナー最新から次マイナーの最新へのアップグレードは常に可能なわけではない、ということになります。OpenShiftのアップグレードパス特有のトリッキーなところだと思います。
4.8.zから4.9.zへのアップグレード、前に確認したときには存在していたのに今見たら消えていました、なんでですか？
fastなどの各チャネルのリリースバージョンはcincinnati-graph-dataというGitHubリポジトリで管理されている、という話をしましたが、このリポジトリはもうひとつ他のデータを持っています。blocked-edgesというアップグレードパスを明示的に制限する情報です。
アップグレード可能なバージョン、つまりアップグレードパスは各リリースイメージの情報を元に構築されるものですが、まれにリリースされた特定バージョンに影響の大きな問題が発見されることがあります。このときに利用されるのがblocked-edgeによるアップグレード禁止宣言です。たとえば4.9.28までの全ての4.9.zバージョンは、etcdのデータ不整合が発生する問題の影響を受けるため、4.8.zからのアップデートがblockされています。
上記のような影響の大きい問題が後から発見された場合は、その問題の影響を受けるユーザを増やさないようblocked-edgesの定義に追加され、アップグレードパスを無効化してユーザ保護を行います。
stableチャネルで4.yから4.(y+1)へのアップグレードパスがなかなか作成されません
stableのマイナーバージョンアップグレードは実績として30日から60日くらい様子を見てからオープンされます。低リスクであることを優先するならstableで待ってください。アップグレードを急ぐ理由があるときはfastを検討してください。
まとめ
- OpenShiftはアップグレードパスを利用することにより安全なアップグレードを実現している
- fast, stable, candidate, eusという4つのチャネルがある
- アップグレードパスの参照はRed Hat OpenShift Container Platform Update Graphサービスを利用する
- アップグレードパスはチャネル内の各リリースイメージの定義から算出、構成される
- 仕組み上、現マイナー最新から次マイナーの最新へのアップグレードができないタイミングがある
- ユーザ保護のためアップグレードパスが後から無効化されることがある
