はじめに
こんにちは、ACS事業部の吉川です。
Azure Kubernetes Service(AKS)の運用に従事しているみなさま、定期的に行う必要のあるアップグレード作業、大変じゃないですか？
AKSには自動でアップグレードを行ってくれる 自動アップグレード機能 というものがあります。
2019年1月にプレビュー提供されたこの機能、いつの間にかドキュメントからプレビューの表記が消えていました。
(英語版ドキュメントの更新履歴を見るに2021年8月ごろにGAした模様？)
Cluster auto upgrade GA · MicrosoftDocs/azure-docs@aa106a1 · GitHub
正式に利用可能なのか、ということで試してみたので記事にまとめます。
※後述しますが、プレビュー中の別機能と組み合わせて使うということもありプロダクション環境での利用には向いていません。
自動アップグレードを有効化する
現状、自動アップグレードはポータル上では設定できずCLIを利用する必要があります。
AKSクラスター新規作成時に自動アップグレードを有効化する際は、以下のように --auto-upgrade-channel オプションを付与します。
# リソース名/リージョンの定義 rgName=rg-sample aksName=aks-sample location=japaneast # リソースグループ作成 az group create --location $location --name $rgName # 自動アップグレードを有効化したAKSクラスター作成 az aks create -g $rgName -n $aksName -l $location \ --kubernetes-version 1.23.8 \ --node-count 3 \ --auto-upgrade-channel stable
既存のAKSクラスターで自動アップグレードを有効化することも可能です。
az aks update -g $rgName -n $aksName --auto-upgrade-channel stable
--auto-upgrade-channel オプションで指定する値によって、アップグレードの挙動が変わります。
本記事作成時点で提供されているAKSのバージョンは以下のとおりです。
az aks get-versions --location $location --output table
KubernetesVersion Upgrades ------------------- ------------------------ 1.24.6 None available 1.24.3 1.24.6 1.23.12 1.24.3, 1.24.6 1.23.8 1.23.12, 1.24.3, 1.24.6 1.22.15 1.23.8, 1.23.12 1.22.11 1.22.15, 1.23.8, 1.23.12
例えば、バージョン 1.22.11 のクラスターで自動アップグレードを有効化した場合、それぞれの設定値ごとのアップグレード先バージョンを整理すると以下の表のようになります。
| 値 | アップグレードの挙動 | アップグレード先のバージョン |
|---|---|---|
| none | 自動アップグレードを行わない | - |
| patch | 現状のAKSクラスターと同マイナーバージョン内で最新のパッチバージョンまで自動でアップグレードする | 1.22.15 |
| stable | 最新のマイナーバージョン-1 の中で最新のバッチバージョンまで自動でアップグレードする | 1.23.12 |
| rapid | 最新のマイナーバージョン・最新のパッチバージョンまで自動でアップグレードする | 1.24.6 |
| node-image | 最新のノードイメージにアップグレードする | - |
メンテナンスウインドウの設定
自動アップグレードを有効化した後、好き勝手な時間にアップグレードが動き出すようでは運用上困ってしまいます。
AKSは メンテナンス期間の設定 が可能なので、これと組み合わせるのが一般的な使い方となるでしょう。
なお、現時点ではメンテナンス期間の設定はプレビュー中の機能です。利用の際は注意してください。
以下のようにAzure CLIを用いてメンテナンス期間を設定します。
下記の例では、UTCで金曜日の16時（日本時間で土曜の1時）に設定しています。
az aks maintenanceconfiguration add \ -g $rgName --cluster-name $aksName \ --name default --weekday Friday --start-hour 16
{ "id": "/subscriptions/########-####-####-####-############/resourceGroups/rg-sample/providers/Microsoft.ContainerService/managedClusters/aks-sample/maintenanceConfigurations/default", "name": "default", "notAllowedTime": null, "resourceGroup": "rg-sample", "systemData": null, "timeInWeek": [ { "day": "Friday", "hourSlots": [ 16 ] } ], "type": null }
実際のアップグレード時の挙動
実際にアップグレードが行われる際にどんな挙動となるかを見てみましょう。
ここではバージョン 1.23.8 のAKSクラスターに対しアップグレード チャネルを stable に設定した環境を使用します。
コントロールプレーンのアップグレード
メンテナンス期間に設定した時間になってしばらくすると、コントロールプレーンのアップグレードが始まりました。
少し待つと状態が 成功(実行中) に変わり、コントロールプレーンのアップグレードは完了です。
ノードプールのアップグレード
アップグレード前のノードプールは以下のような状態です。
NAME STATUS ROLES AGE VERSION aks-nodepool1-91460337-vmss000000 Ready agent 11h v1.23.8 aks-nodepool1-91460337-vmss000001 Ready agent 11h v1.23.8 aks-nodepool1-91460337-vmss000002 Ready agent 11h v1.23.8
コントロールプレーンのアップグレード後、新しいバージョンのノードが追加されます。
同タイミングで従来のノードのうち1台に SchedulingDisabled が付与され、該当ノードで稼働していたPodが終了し別ノード上で起動していきます。
kubectl drain <ノード名> を実行したときと同じ挙動のようです。
NAME STATUS ROLES AGE VERSION aks-nodepool1-91460337-vmss000000 Ready,SchedulingDisabled agent 11h v1.23.8 aks-nodepool1-91460337-vmss000001 Ready agent 11h v1.23.8 aks-nodepool1-91460337-vmss000002 Ready agent 11h v1.23.8 aks-nodepool1-91460337-vmss000003 Ready agent 36s v1.23.12
しばらくすると SchedulingDisabled が付与されたノードが削除されます。
NAME STATUS ROLES AGE VERSION aks-nodepool1-91460337-vmss000001 Ready agent 11h v1.23.8 aks-nodepool1-91460337-vmss000002 Ready agent 11h v1.23.8 aks-nodepool1-91460337-vmss000003 Ready agent 59s v1.23.12
新ノード追加→既存ノードdrain→drainしたノードの削除 という挙動がノード数分繰り返され、最終的には全ノードが新バージョンのものに置き換わり、AKSクラスターのアップグレードは完了となります。
なお、アップグレード前と同名のノードが作成されていますが、1度削除されイメージから再生成されています。
NAME STATUS ROLES AGE VERSION aks-nodepool1-91460337-vmss000000 Ready agent 8m16s v1.23.12 aks-nodepool1-91460337-vmss000001 Ready agent 5m18s v1.23.12 aks-nodepool1-91460337-vmss000002 Ready agent 80s v1.23.12
なお、一度にどれだけの数のノードを更新するかは --max-surge を指定することで調整可能です。
# 割合で指定する場合 az aks nodepool add -n <ノードプール名> -g $rgName --cluster-name $aksName --max-surge 33% # 台数で指定する場合 az aks nodepool add -n <ノードプール名> -g $rgName --cluster-name $aksName --max-surge 5
Azure Kubernetes Service (AKS) クラスターのアップグレード - Azure Kubernetes Service | Microsoft Learn
おわりに
AKSの運用をラクにする、自動アップグレード機能のご紹介でした。
といっても、マイナーバージョンレベルの更新でも大きな変更が入ることがあるので、まだまだ完全に自動更新に任せるのはちょっと怖いかな、というのが個人的な感想です。
AKSはバージョンのダウングレードができないため、何か問題があったときにはクラスターの再作成が必要となるのも考慮すべきポイントです。
そのため、
- 異常時に作り直すことができる（作り直しの作業時間を確保可能な）環境で利用する
- 大きな変更が入ることが少ないパッチバージョンのみの自動更新にとどめる
といったあたりが主な利用用途になるのではと思います。
とはいえ、面倒な更新作業がいくらかでも削減できるならば利用価値はあるかと思います。
アップグレード戦略を検討する際に、自動アップグレードも合わせてご検討ください。
