イオンスマートテクノロジー DevSecOps Div SREチームの齋藤（ @hikkie13 ）です。
ふと、今年を振り返った時に、去る3月にAKSのアップグレード戦略について語る機会を頂いたので、その内容を改めて記事にしようかと思います。
AKS とは
AKSとはAzure Kubernetes Serviceの略称であり、Azureで提供されるマネージドのKubernetesです。
AKSのアップグレード戦略を語るイベントとは
去る2024/3/26に【2024年のAKSアップグレードを語る】ベストプラクティスと実践事例というイベントを開催しました。
光栄なことに、日本マイクロソフトの真壁さん、Microsoft MVPであるAPCommunicationsの吉川さんと対バンさせて頂きました。
そこで私は、「イオンスマートテクノロジーで実践しているAKSアップグレード戦略」というタイトルで発表をしました。
本題：AKSアップグレード戦略
アップグレード戦略の概要
AKSのアップグレードは、以下の方針で定期的に実施されています。
-
Minorバージョンアップグレード (x.y.z の y)
- Microsoftが推奨する
n-2ポリシー に従う。 - 必然的に、1年に1-2回アップグレードを実施することになる。
- Microsoftのサポート終了時期は、公式ドキュメント:Azure Kubernetes Service (AKS) でサポートされている Kubernetes のバージョンを確認する。
- Microsoftが推奨する
-
Patchバージョンアップグレード (x.y.z の z)
- 自動アップグレードを設定し、セキュリティ修正やバグ修正を迅速に適用する。
- Patchバージョンのリリースは月に一回ほど。Azureとしてskipされることもある。
LTS(Long Term Support)の採用は？
AKSにおいては 1.27以降で特定のバージョンにのみLTS(Long Term Support)という長期サポートが提供されている。通常1年間のサポートが、延長されて2年間になる。
本記事執筆時点の2024/12/24では、1.27および1.30が対象となる。
https://learn.microsoft.com/ja-jp/azure/aks/supported-kubernetes-versions?tabs=azure-cli#aks-kubernetes-release-calendar より
現状、弊社ではLTSを採用しない方針としています。
理由は以下です。
- 3rd Partyツールなどと組み合わせている場合、そちらがLTSのバージョンと整合するかを考えるのが大変
- 1回のアップグレードで発生する差分が大きくなる。（アプリケーションでいうビッグバンリリースが良くないという文脈と同じ）
- Kubernetesの新機能を活用する機会を失う。
アップグレードの実施の流れ
特別なことはしていませんが、以下の流れで実施しております。
-
事前確認
- KubernetesとAKSのChangelogを確認し、廃止予定のAPIや変更内容を把握。
- 必要に応じて、Zennの記事などを活用して最新情報をチェック。
-
テスト環境での検証
- アップグレード前にテスト環境やステージング環境で動作確認を実施。
- アプリケーションや関連するツールが正常に機能するかを確認。
-
本番環境への適用
- 切り替え方式は以下の2種類がある：
- In-place: 現行クラスタ内でRolling Upgradeを実施。
- Blue/Green: 新クラスタを作成し、トラフィックを切り替える。
- 切り替え方式は以下の2種類がある：
アップグレード切替方式
アップグレード切替方式としては主に2種類あります。
In-place: 現行クラスタ内でRolling Upgradeを実施。
https://speakerdeck.com/torumakabe/aksnoatupudetowoshou-nazukero-mazuli-jie-sositeshi-jian?slide=9 より
- この時、worker nodeの追加やPodの再作成が行われる。
- 既存PodはEvictされ、新規worker node上で起動される。
Blue/Green: 新クラスタを作成し、トラフィックを切り替える。
https://learn.microsoft.com/ja-jp/azure/architecture/guide/aks/blue-green-deployment-for-aks より
イオンスマートテクノロジーでは、2種類のアップグレード方式を使っています。
- Patchアップグレード: 全てIn-place
- Minorアップグレード: クラスタによって使い分けている。
方式の比較
2種類の方式のメリット・デメリットを表現すると以下のようになるかと思います。（個人の見解）
| 方式 | In-place | Blue/Green |
|---|---|---|
| 作業コスト | ○ | ×（クラスタの構築、トラフィック切替の準備） |
| 切替時間 | △（アプリケーションの起動時間やクラスタの設定次第） | ○（当日切り替えるだけ。重みづけルーティングの場合は設定次第だが、in-placeよりは短いことがほとんど） |
| Rollbackの可否 | × | ○ |
| 切り替えの制約 | ×（1バージョンずつ） | ○ |
| 作業時のサービス影響 | △（drain時に一時的にキャパシティが落ちる） | ○ |
アップグレードを安全に行うための考慮事項
上記にまとまっていますが、簡単に解説します。
計画メンテナンス
自動アップグレードに対して、計画メンテナンス期間を設定することができます。
ただし、以下の点には注意が必要です。
- 最低4hの枠の指定が必要
- 尚且つ、「この枠のどこかで開始される」という定義なので、4hの枠の終わり際に開始される可能性もある。(メンテナンスウィンドウではない）
- 細かい設定ができない。
- 複数条件を指定したい場合については今後の期待
Max Surge Size
-
同時に最大でどのくらいのノード数をアップグレードするかを決めるパラメータ
-
値が大きいほど、同時のいなくなるノード数やPod数が多くなる。
-
設定していない場合は、1台となる。
-
20%のように、クラスタ全体のノード数に対する割合で指定することも可能。 ※小数点以下は切り上げ -
Microsoft社の推奨は
33%
https://learn.microsoft.com/ja-jp/azure/aks/upgrade-aks-cluster?tabs=azure-cli#customize-node-surge-upgrade より -
この設定はAzure Portalからは設定できず、azコマンドもしくはterraformにて設定する必要がある。
Pod Disruption Budget
PDBとは、自発的なDisruptionによって同時にダウンするPodの数を制限する仕組みで、今回のようなアップグレード中に特定のアプリケーションのレプリカ数が0になってしまうような事態を防ぐ仕組みです。
-
minAvailableもしくはmaxUnavailableで指定する。 - パラメータには、整数もしくは割合で指定可能（小数点以下切上げ）
個人的な経験では、 minAvaiable の指定だとトラブルになりがち（PDBマターでアップグレードが止まる）のため、 maxUnavaible 前提でサービスに影響を与えないような設定をすることをお勧めします。
Podの安全な停止/起動の設定
こちらは、アップグレードに限った話ではないのですが、Podの停止・起動が発生する以上
- Graceful shutdown
- PreStop hook
- liveness/readiness/startup probe
を適切に設定することは重要です。
ここら辺を適切に設定しておかないと、アップグレード時にエラーが発生することになります。
アップグレード自体の本筋から外れるので、以下を参考ください。
その他、アップグレードに自信を持つための準備
「とは言えアップグレードは怖い・・・」という方のためには、以下の観点で練度を高めていくと良いと思います。
- 可観測性 (Observability) の向上。
- IaC管理により、「いざとなれば作り直せる」という準備
- 万が一エラーで止まった時の手立てを確認しておく。公式ドキュメント: AKSのアップグレードリトライ方法に記載がある。
- 回数を重ねて、組織として練度を高める姿勢を保つ。
まとめ
以上、イオンスマートテクノロジーにおけるAKSのアップグレード戦略について解説しました。
皆様も "Kubernetesのアップグレードに失敗しない漢" を目指してお互い頑張りましょう💪
参考資料
- AKS Changelog
- Zenn AKSリリースノート
- Microsoft Docs - AKSのアップグレード
- AKSのアップデートを手なずけろ！ まず理解 そして実践
- イオンスマートテクノロジーで実践しているAKSアップグレード戦略
イオングループで、一緒に働きませんか？
イオングループでは、エンジニアを積極採用中です。少しでもご興味もった方は、キャリア登録やカジュアル面談登録などもしていただけると嬉しいです。
皆さまとお話できるのを楽しみにしています！
Discussion