【OCI】OKEのサイクル・ノードでKubernetesのバージョンアップはどれぐらい楽になるのか

はじめに

こんにちは！クラウド事業部の中根です。

OKEではクラスタタイプを選択でき、無料の基本クラスタと有料の拡張クラスタが存在します。
拡張クラスタでは、基本クラスタで使えない様々な機能を使うことができます。
その中に、主にKubernetesのバージョンアップの時に使えるサイクル・ノードという機能があります。
なんだか便利そうですが、K8sバージョンアップの経験がなくてピンときません。

この機能がどれだけ便利なのかを知るために、検証してみました。
クラスタタイプを基本/拡張どちらにするか、の判断材料の１つとして参考になれば幸いです。

検証

準備：古いバージョンのOKEクラスタ作成

OKEクラスタをクイック作成で作成します。
クラスタ名とマイナーバージョンを最新より下のバージョンにするところ以外はデフォルト値で作成します。

クラスタの詳細画面で、バージョンアップが推奨されていることが確認できます。
クラスタ（コントロールプレーン）

ノードプール（ワーカーノード）

出来上がったら、Podをデプロイしておきます。

kubectl create deployment test-deploy --image=docker.io/nginx:latest --replicas=4

$ kubectl get po -o wide
NAME                           READY   STATUS    RESTARTS   AGE   IP            NODE         NOMINATED NODE   READINESS GATES
test-deploy-857694fcdf-4w7th   1/1     Running   0          18s   10.0.10.131   10.0.10.74   <none>           <none>
test-deploy-857694fcdf-dc9f9   1/1     Running   0          18s   10.0.10.136   10.0.10.74   <none>           <none>
test-deploy-857694fcdf-sfvjg   1/1     Running   0          18s   10.0.10.110   10.0.10.53   <none>           <none>
test-deploy-857694fcdf-swdj6   1/1     Running   0          18s   10.0.10.126   10.0.10.5    <none>           <none>

準備：コントロールプレーンのバージョンアップ

クラスタ詳細から、「アップグレード」を押下します。

新しいバージョンを選択し、「アップグレード」を押下します。

更新完了まで待ちます。私がやった時は10分かからない程度でした。
更新中もkubectl等の操作はできます。

（検証時は1.34が最新だったので、アップグレードが推奨されてしまってます）

ワーカーノードのバージョンアップ

バージョンアップ方法の紹介

ワーカーノードには管理対象ノード、仮想ノード、自己管理ノードがありますが、サイクル・ノード機能の対象である管理対象ノードを前提とします。

管理対象ノードのバージョンアップは３つの方法があります。

サイクル・ノード
拡張クラスタで使える機能で、パラメータを1,2個指定するだけで後は自動で全部やってくれます。
ノードの手動削除
ノードプールのノードを自分で削除して入れ替える方法です。ノードを削除するだけでよく、Podのdrainや新しいノード作成は自動ですが、全てのノードを手動削除する必要があります。
ノードプールの置換
新しいノードプールを作成して、置換する方法です。ノードのlabel付与やPodのdrainなど、手動でやる作業が比較的多いです。

本記事では、1と2の方法を実際にやってみます。

サイクル・ノード

まずはノードプールの編集画面から、バージョンをクラスタ・バージョンに変更し、イメージもバージョンを合わせて変更し、「更新」を押下します。

補足：「Cannot update Kubernetes version which has already been set by OKE worker node image.」エラーについて
バージョンを変更するだけではだめで、イメージも更新しないと、「Cannot update Kubernetes version which has already been set by OKE worker node image.」というエラーで更新ができませんでした。
イメージの変更はドキュメントには記載が無かったので、イメージ変更が不要な場合もあるかもしれません。

ノードプールのバージョンアップが完了しても、まだ肝心のノードは古いバージョンのままです。
ノードのバージョンアップのため、ノードプールの画面から「サイクル・ノード」を押下します。

以下のように設定し、「サイクル・ノード」を押下します。
最大サージと最大使用不可は、可用性やコストなど状況に応じて選択しましょう。

サイクルオプション：ノードの交換
最大サージ： 0
最大使用不可： 1

以下のように順番にアップグレードされていきます。

ノードプールがアクティブになったらアップグレード完了です。

参考までに、検証時はサイクル・ノード開始からアップグレード完了まで16分7秒かかりました。
ほとんど素のクラスタで検証したので、実運用ではもっと時間がかかることが予想されます。
サイクル・ノードを実行すれば後は待つだけなのが、後述する手動削除と比べて嬉しい点です。

参考：サイクルオプション「ブート・ボリュームの置換え」

サイクルオプションを「ブート・ボリュームの置換え」に変更した場合も試してみました。
事前準備として、古いバージョンでノードプールを一度作成してから、ノードプールのバージョンアップをしておきます。

以下のように設定し、「サイクル・ノード」を押下します。

サイクルオプション：ブート・ボリュームの置換え
最大使用不可： 1

参考までに、検証時はサイクル・ノード開始からアップグレード完了まで16分20秒かかりました。
こちらの方が再作成しない分早そうだと思って試したのですが、今回の検証においてはそんなに変わらず、むしろ遅いぐらいでした。

ノードの手動削除

事前準備として、古いバージョンでノードプールを一度作成してから、ノードプールのバージョンアップをしておきます。
ノードプールのバージョンが新しくなっていて、ノードのバージョンは古いままであることを確認します。

あとは、ノードを１つ削除　→　再起動まで待つ　→　次のノードを削除　の繰り返しです。

ノードを削除すると、以下のようにノードが再作成されます。

無事に再起動完了したら、ノードの数だけ繰り返します。

全てのノードのバージョンが最新化されたら完了です。

検証だと、トータルでは14分3秒かかりました。
そして、１つのノード削除～再起動完了まで5分弱でした。つまり、5分ごとに手作業が発生します。
検証でノードが少なかったのでできましたが、実運用ではもっと多いでしょうからとても大変そうです。
基本クラスタで頑張る場合は、スクリプト等で自動化することを検討したほうが良さそうです。

所感

ノード数が3〜4台程度の小規模クラスタであれば、サイクル・ノードを使わずに手動削除で対応することも十分現実的です。
一方で、ノード数の増加に比例して、ノード削除の作業回数と待ち時間は増加します。
本検証では、1ノードあたり約5分の待ち時間が発生しており、ノード数が10台を超える場合、単純な作業時間だけでも無視できない負担になります。
サイクル・ノードを使う代わりに自動化スクリプトを作成することもできそうですが、相応の開発・保守コスト等が発生します。
Kubernetesのバージョンアップは多くても4か月に1度の作業ですが、ヒューマンエラーや作業者の拘束時間を減らせるという点で、ノード数が増えるほど拡張クラスタを選ぶ価値がありそうです。　　

参考資料

お知らせ

私達クラウド事業部はクラウド技術を活用したSI/SESのご支援をしております。

www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。