[デモ] AROクラスターの更新
デモの概要
このモジュールでは、インストラクターがAROクラスター更新方法の概要をご紹介します。
前準備
AROクラスターは、セルフマネージド版のOpenShiftと同様に、 WebコンソールやOpenShift CLIを使用したアップグレードが可能です。 ここでは、OpenShiftのWebコンソールを利用した、AROクラスターのアップグレード方法をご紹介します。
OpenShiftクラスターのrootユーザーであるkubeadminユーザー、または、 クラスター管理権限となるcluster-adminロールが割り当てられたユーザーで、 AROクラスターにログインして、「クラスター設定」画面に移動します。
AROクラスターのデフォルトだと、更新チャネルが未設定の状態なので、チャネルを設定します。 未設定の横の鉛筆マークをクリックして、チャネル名(この例では、stable-4.10)を入力して、 「保存」をクリックします。
| AROでは、 「stable」チャネルのみがサポート対象のチャネル となります。 |
一部のワーカノードを更新対象外にする( カナリアロールアウト更新)ことができます。 その場合は、ラベルをつけた特定のノードのプール(Machine Config Pool, MCP)を作成する必要があります。
$ : ↓AROクラスターにkubeadminユーザでログイン
$ oc login --token=sha256~XXXXX --server=https://api.testmydomain01.japaneast.aroapp.io:6443
$ : ↓AROクラスターのコンピュートノードのリスト表示
$ oc get -l 'node-role.kubernetes.io/master!=' -o 'jsonpath={range .items[*]}{.metadata.name}{"\n"}{end}' nodes
testmyaro01-jnlll-worker-japaneast1-t676g
testmyaro01-jnlll-worker-japaneast2-8nbm2
testmyaro01-jnlll-worker-japaneast3-6tqgr
$ : ↓「oc label」コマンドによる「node-role.kubernetes.io/workerpool-canary=」ラベルの付与
$ oc label node testmyaro01-jnlll-worker-japaneast3-6tqgr node-role.kubernetes.io/workerpool-canary=
node/testmyaro01-jnlll-worker-japaneast3-6tqgr labeled
$ : ↓「node-role.kubernetes.io/workerpool-canary=」ラベルが付与されたノードを対象とする
$ : OpenShiftのMachineConfigPoolリソースを作成
$ cat << EOF > worker-canary.yaml
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
name: workerpool-canary
spec:
machineConfigSelector:
matchExpressions:
- {
key: machineconfiguration.openshift.io/role,
operator: In,
values: [worker,workerpool-canary]
}
nodeSelector:
matchLabels:
node-role.kubernetes.io/workerpool-canary: ""
EOF
$ oc create -f worker-canary.yaml
machineconfigpool.machineconfiguration.openshift.io/workerpool-canary created
$ : ↓OpenShiftのMachineConfigPoolリソース一覧を表示
$ oc get mcp
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
master rendered-master-b3a0f025835fde2aeb292b6344891769 True False False 3 3 3 0 5h8m
worker rendered-worker-e3b5c7f3534a74ba469358659178d170 True False False 2 2 2 0 5h8m
workerpool-canary rendered-workerpool-canary-e3b5c7f3534a74ba469358659178d170 True False False 1 1 1 0 60sここで作成したMCP「workerpool-canary」を指定して、 ワーカーノードのアップグレード対象外にすることが可能です。
AROクラスターのアップグレード
「クラスター設定」画面から「Select a version」をクリックして、 アップグレードするバージョン(リリース)を選択します。 このとき、「Full cluster update」を選択すると、全てのコントローラ/ワーカーノードがアップグレードされます。
「Partial cluster update」を選択すると、一部または全てのワーカーノードをアップグレードから除外できます。 ここでは、前述したMCP「workerpool-canary」に含まれるワーカーノードを選択しています。 そして「更新」をクリックして、AROクラスターのアップグレードを開始します。
アップグレードを開始すると、次のような画面が表示されます。 ここでは、「Partial cluster update」を選択して、 1台のワーカーノードをアップグレード対象外としています。
アップグレードしたワーカーノードでアプリケーションが問題なく実行されることを確認したら、 「Resume update」をクリックして、残り1台のワーカーノードのアップグレードを完了できます。
AROクラスターのマイナーリリース間のアップグレード
ARO/OpenShiftは、4.10から4.11など、マイナーリリース間のアップグレードも可能です。 AROクラスターの更新情報と更新イメージを配布するサービスは、Red Hatによって管理されています。 そのため、セルフマネージド版OpenShiftのマイナーリリース間のアップグレードパスが Red Hatによって提供開始されたタイミングで、AROクラスターでも当該アップグレードパスを利用できるようになります。
AROクラスターで、マイナーリリース間のアップグレードが可能になった場合、 次のような画面が表示されて、 アップグレード対象のstableチャネルが利用可能であることが分かるようになっています。
このとき、前述と同様の手順で、更新チャネルを「stable-4.10」から「stable-4.11」に変更すると、 4.11へのアップグレードを選択・実施できるようになります。
上記画像にある + その他 をクリックすることで、
現在更新可能なリリースの一覧を確認できます。「stable-4.11」チャネルを設定しても、
4.11系だけでなく4.10系にもアップグレードが可能です。
| AROの正式リリースとして提供開始される前に、 ARO利用者がstableチャネルで利用可能な最新リリースにアップグレードすることは可能であり、 かつ、サポート対象となります。 ここで挙げてきた例のように、ARO v4.11がリリースされる前に、 利用者が「stable-4.11」チャネルを設定して、 ARO 4.10からARO 4.11にアップグレードできるため、 アップグレードの先行テストなどに利用できます。 こちらの情報については、 Microsoftの公式ドキュメントもご参照ください。 |