はじめに

Container Engine for Kubernetes (OKE)のバージョンアップ手順として新しくon-demand node cycling機能が実装されました。これはWorker Nodeのアップグレード手順を簡素化してくれる機能です。

実際のところどうなのか確認してみます。

なお、この機能を使うためには「拡張クラスタ」である必要があります。
拡張クラスタは2023年3月にGAになった機能で、それ以前のクラスタは「基本クラスタ」と呼ばれています。
拡張クラスタと基本クラスタの違いはこちらをご参照ください。

環境の確認

今回は2ノードのクラスタを用意しました。

$ k get node
NAME          STATUS   ROLES   AGE    VERSION
10.0.10.13    Ready    node    4h8m   v1.25.4
10.0.10.218   Ready    node    4h8m   v1.25.4

Kubernetesのバージョンはv1.25.4で、これをv1.26.2に上げます。

OCIのコンソール上でバージョンアップができると表示されています。

ちなみに、基本クラスタから拡張クラスタにアップグレードすることもできますので、基本クラスタを使っているけど、この機能を試してみたい場合には、コンソールから拡張クラスタへのアップグレードをクリックすると、拡張クラスタに変えることができます。（拡張クラスタから基本クラスタに変更することはできません）
なお、拡張クラスタは基本クラスタと違って、クラスタそのものが課金対象となりますのでご注意ください。

動作確認用にDeploymentで2つのPodを作成しています。

$ k get pod -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP             NODE          NOMINATED NODE   READINESS GATES
nginx-76d6c9b8c-9vdft   1/1     Running   0          49m   10.244.0.4     10.0.10.13    <none>           <none>
nginx-76d6c9b8c-nc92w   1/1     Running   0          49m   10.244.0.131   10.0.10.218   <none>           <none>

バージョンアップ

コントロールプレーン -> Worker Nodeの順にバージョンアップします。

コントロールプレーン

OCIのコンソールからKubernetesの新バージョンを使用できますをクリックします。

以下の画面でバージョンを選択して、アップグレードをクリックします。

この画面になります。

少し待つとアイコンがグリーンに変わって、v1.26.2にバージョンアップできたことが確認できます。

Worker Node

OKEのWorker Nodeはノードプールという単位でプロビジョニングされています。
クラスタのコンソールから、ノードプールの詳細画面に行きます。

現状では、ノードプールのバージョンはv1.25.4のままです。
この画面で編集をクリックします。

この画面のバージョンでv1.26.2を選択して、変更の保存をクリックします。

ノードプールのバージョンがv1.26.2に変わりました。

ここまでは基本クラスタでも同じで、ここからがon-demand node cyclingの手順になります。

OCIのコンソールでサイクル・ノードをクリックします。
この画面で最大サージと最大使用不可の数値を設定します。

最大サージ
- バージョンアップ時に一度に追加するノード数の上限
最大使用不可
- バージョンアップ時に使用できないようにするノード数の上限

バージョンアップはそのノードのKubernetesのバージョンを上げるのではなく、新しいバージョンのノードを追加して、古いバージョンのノードを削除する動作になります。
そのため、バージョンアップ時に性能を落としたくない場合は、最大サージ数を1以上にして、最大使用不可を0にします。この場合は一時的にノード数が増えますので、その分コストがかかることになります。
逆に、バージョンアップ時にコストを増やしたくないのであれば、最大サージ数を0にして、最大使用不可を1以上にします。この場合は一時的にノード数が減りますので、性能（Podが起動できないなど）に影響が出る可能性があります。

今回はそれぞれ1ずつにしてみました。

コンソール上では以下のように新しいノードが追加されています。

ノードのバージョンアップ（入れ替え）が終わると以下のようになります。

ノードの動きをkubectlコマンドでも確認しました。

$ k get node -w
NAME          STATUS   ROLES   AGE     VERSION
10.0.10.13    Ready    node    6h58m   v1.25.4
10.0.10.218   Ready    node    6h58m   v1.25.4
10.0.10.218   Ready,SchedulingDisabled   node    6h58m   v1.25.4
10.0.10.218   NotReady,SchedulingDisabled   node    6h59m   v1.25.4
10.0.10.91    NotReady                      <none>   0s      v1.26.2
10.0.10.91    NotReady                      <none>   51s     v1.26.2
10.0.10.91    Ready                         <none>   54s     v1.26.2
10.0.10.91    Ready                         node     73s     v1.26.2
10.0.10.13    Ready,SchedulingDisabled      node     7h1m    v1.25.4
10.0.10.199   NotReady                      <none>   0s      v1.26.2
10.0.10.199   NotReady                      <none>   20s     v1.26.2
10.0.10.13    NotReady,SchedulingDisabled   node     7h2m    v1.25.4
10.0.10.199   NotReady                      <none>   62s     v1.26.2
10.0.10.199   Ready                         <none>   66s     v1.26.2
10.0.10.199   Ready                         <none>   68s     v1.26.2
10.0.10.199   Ready                         node     90s     v1.26.2
10.0.10.199   Ready                         node     2m35s   v1.26.2
10.0.10.91    Ready                         node     4m14s   v1.26.2

削除されてから追加しているような動きですね。
最終的にはこうなりました。

$ k get node
NAME          STATUS   ROLES   AGE     VERSION
10.0.10.199   Ready    node    96s     v1.26.2
10.0.10.91    Ready    node    3m15s   v1.26.2

Podの動きも確認しました。

$ k get pod -o wide -w
NAME                    READY   STATUS    RESTARTS   AGE     IP           NODE         NOMINATED NODE   READINESS GATES
nginx-76d6c9b8c-9vdft   1/1     Running   0          3h40m   10.244.0.4   10.0.10.13   <none>           <none>
nginx-76d6c9b8c-f744z   1/1     Running   0          2m12s   10.244.0.5   10.0.10.13   <none>           <none>
nginx-76d6c9b8c-9vdft   1/1     Running   0          3h41m   10.244.0.4   10.0.10.13   <none>           <none>
nginx-76d6c9b8c-9vdft   1/1     Terminating   0          3h41m   10.244.0.4   10.0.10.13   <none>           <none>
nginx-76d6c9b8c-f744z   1/1     Running       0          3m9s    10.244.0.5   10.0.10.13   <none>           <none>
nginx-76d6c9b8c-f744z   1/1     Terminating   0          3m9s    10.244.0.5   10.0.10.13   <none>           <none>
nginx-76d6c9b8c-tcbdd   0/1     Pending       0          0s      <none>       <none>       <none>           <none>
nginx-76d6c9b8c-tcbdd   0/1     Pending       0          0s      <none>       10.0.10.91   <none>           <none>
nginx-76d6c9b8c-tcbdd   0/1     ContainerCreating   0          0s      <none>       10.0.10.91   <none>           <none>
nginx-76d6c9b8c-44qhc   0/1     ContainerCreating   0          0s      <none>       10.0.10.91   <none>           <none>
nginx-76d6c9b8c-f744z   0/1     Terminating         0          3m10s   10.244.0.5   10.0.10.13   <none>           <none>
nginx-76d6c9b8c-9vdft   0/1     Terminating         0          3h41m   10.244.0.4   10.0.10.13   <none>           <none>
nginx-76d6c9b8c-44qhc   1/1     Running             0          35s     10.244.0.131   10.0.10.91   <none>           <none>
nginx-76d6c9b8c-tcbdd   1/1     Running             0          35s     10.244.0.132   10.0.10.91   <none>           <none>

最終的にはこうなりました。

$ k get pod -o wide
NAME                    READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
nginx-76d6c9b8c-44qhc   1/1     Running   0          4m29s   10.244.0.131   10.0.10.91   <none>           <none>
nginx-76d6c9b8c-tcbdd   1/1     Running   0          4m29s   10.244.0.132   10.0.10.91   <none>           <none>

ノードが減ってから増える動作でしたので、最終的は２つのPodが一つのノードに寄せられた形になりました。
今回は２ノードのクラスタでしたのでこのようになりました。通常は3ノード以上だと思いますが、3ノード以上の場合には、最後に追加されたノードに（Daemonsetを除き）Podがない状態になると思います。
これを防ぎたいのであれば、追加してから削除する動作（「最大使用不可」を0）にする必要がありますね。

まとめ

今回確認したon-demand node cyclingを使わない場合は、ノードプールのバージョンを上げた後に以下の手順を手動で実施する必要があります。

ノードの追加（スケール）
kubectl drain
ノードの削除

これをやらないで良いので、バージョンアップが楽になったと感じました。