APC 技術ブログ

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

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

Azure Kubernetes Serviceを自動でアップグレードしてみよう

はじめに

こんにちは、ACS事業部の吉川です。

Azure Kubernetes Service(AKS)の運用に従事しているみなさま、定期的に行う必要のあるアップグレード作業、大変じゃないですか?
AKSには自動でアップグレードを行ってくれる 自動アップグレード機能 というものがあります。

azure.microsoft.com

2019年1月にプレビュー提供されたこの機能、いつの間にかドキュメントからプレビューの表記が消えていました。

learn.microsoft.com

(英語版ドキュメントの更新履歴を見るに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は メンテナンス期間の設定 が可能なので、これと組み合わせるのが一般的な使い方となるでしょう。

learn.microsoft.com

なお、現時点ではメンテナンス期間の設定はプレビュー中の機能です。利用の際は注意してください。

以下のように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はバージョンのダウングレードができないため、何か問題があったときにはクラスターの再作成が必要となるのも考慮すべきポイントです。
そのため、

  • 異常時に作り直すことができる(作り直しの作業時間を確保可能な)環境で利用する
  • 大きな変更が入ることが少ないパッチバージョンのみの自動更新にとどめる

といったあたりが主な利用用途になるのではと思います。

とはいえ、面倒な更新作業がいくらかでも削減できるならば利用価値はあるかと思います。
アップグレード戦略を検討する際に、自動アップグレードも合わせてご検討ください。

本記事の投稿者: 吉川 俊甫
AKSをメインにインフラ系のご支援を担当しています。AKS以外のコンテナもぼちぼち触っていきます。
Shunsuke Yoshikawa - Credly