「がんばらない」AKSアップグレード方法を考えよう
9.8K Views
March 27, 24
スライド概要
AEON Tech Hub #2の登壇資料です
https://aeon.connpass.com/event/308120/
関連スライド
各ページのテキスト
「がんばらない」AKSアップグレード方法を考え よう 2024/03/26 AEON TECH HUB #2
自己紹介 吉川 俊甫 (ヨシカワ シュンスケ) ● ● ● ● ● 所属: 株式会社エーピーコミュニケーションズ ロール: テクニカルエバンジェリスト 受賞歴: Microsoft MVP (Microsoft Azure) 2023/06～ コミュニティ: Platform Engineering Meetup 運営メンバー 好きなAzureサービス: コンテナ系全般
AKSのアップグレード 「しんどく」ないですか？
AKSアップグレードしんどい問題 何がしんどいか ● ● ● ● ● バージョンアップが高頻度（3～5か月に1回） バージョンは1つずつ上げる必要がある アップグレードの度に夜勤でメンテナンスするの疲れる Develop / Staging / Production など、クラスターたくさんある アップグレードはできるけどダウングレードはできないから 慎重にやらなきゃ… などなど
そうは言っても… セキュリティやらサポートやら、無視するわけにはいかない 本セッションでは、バージョンアップ作業を 「がんばって乗り越える苦難な作業」ではなく、 「日常の当たり前な作業」として行うための方法を考えていきます
第1案 「アップグレードしなくていい」 アーキテクチャに移行する
Kubernetesのバージョンアップが生む価値について Kubernetesのバージョンを上げたところで、 自社プロダクトの売上や利益が増えるわけではない 新バージョンで対応した機能がプロダクトに新たな価値を生み出す ということは、ある程度成熟した今のKubernetesではほとんどない えてしてバージョンアップは「守りの作業」になりがち
俺たちがクラウドに求めていたもの これまで自社で全部やっていたことの一部をクラウド側にお任せして、 プロダクト部分に集中 したかったのでは？ 引用元: クラウドにおける共同責任 - Microsoft Azure | Microsoft Learn
しんどいのであれば手放すことも視野に入れる Azureにはコンテナを扱えるサービスが複数ある AKS使ってみたけど運用していくのにしんどさを感じたのであれば、 よりマネージドなサービスに移るのもアリ Web Apps for Containers Azure Container Instances Azure Container Apps
Azure Container Apps、いいですよ Kubernetesベースのフルマネージドサービスなので AKSから移るなら最適な選択肢 2022年5月にGAしたサービスなので、 それ以前からAKSを利用していた場合は選定の土俵に載せていないかも 改めて自社のユースケースに合うかどうか検討してみては Azureコンテナアプリケーション開発 ── 開発に注力するための実践手法 (2023/2/9発売)
第2案 バージョンアップ作業をラクにする
アーキテクチャ変更はそんな簡単にできない 前項でアーキテクチャ変更について触れたものの、 そうは言っても変更できない場合も多々ある ネットワークの都合だったり、 採用しているソフトウェアの都合だったり… 引き続きAKSを使うとして、 バージョンアップの「作業そのもの」を軽減するには…🤔
自動アップグレードを使ってみる AKSには、利用可能なバージョンがリリースされたら 自動的にアップグレードする 自動アップグレード機能 がある アップグレードの対象とするバージョンにより、 以下の 4 パターンを指定可能 ● 最新の GA バージョンにする ● 最新 GA バージョン -1 にする ● パッチリリースのみ適用する ● ノード OS イメージの更新のみを行う 参考: Azure Kubernetes Service (AKS) クラスターの自動アップグレード - Azure Kubernetes Service | Microsoft Learn
アップグレードのスケジューリング 計画メンテナンス 機能を利用して、 メンテナンスウィンドウを指定できる 毎週日曜日のN時～M時までの間に実施、といった指定や 3/26～4/1の間はアップグレードさせない、など 割と柔軟にスケジュールを指定できる 参考: 計画メンテナンスを使用してAzure Kubernetes Service (AKS) クラスターのアップグレードをスケジュールおよび制御する- Azure Kubernetes Service | Microsoft Learn
自動アップグレードと併せて Event Grid のイベントソースとしてAKSを使用できる ● 新しいバージョンが利用可能になったとき ● いま利用中のバージョンがサポート対象外になるとき ● ノードプールのアップグレード開始および成功/失敗 といったイベントが発生するので、後続処理を実行可能
やっぱり自動は怖い…という方向け Azure Kubernetes Fleet Manager というサービスを使うことで 複数のAKSクラスターのアップグレードをまとめて実行可能 アップグレードの適用順も制御可能なため、 Develop → Staging → Production のように順を追って更新できる 引用元: 複数のメンバー クラスター間での更新のオーケストレーション | Microsoft Learn
第3案 バージョンアップ作業を少なくする
AKS の Long Term Support 2023年4月に発表された Kubernetesコミュニティによる特定バージョンのサポートは1年だが、 その期間終了後にMicrosoftが 更に1年間 追加のサポートを提供する 現状 v1.27 がLTSバージョンとして設定されている 標準のサポートが2024年7月まで、LTSは 2025年7月 まで
現状わかっていること v1.27 は現在サポート期間中なので、まだLTSの詳細は不明 が、公式ドキュメントにいくつか情報が記載されているので 利用する前に目を通しておくべし 参考: Azure Kubernetes Service (AKS) クラスターの長期サポート - Azure Kubernetes Service | Microsoft Learn
LTS適用の条件 LTSを適用するための条件は以下の2つ ● クラスターの価格レベルを Premium にすること ● AKSLongTermSupport オプションを設定すること Premium 価格レベルの費用は 1クラスター1 時間あたり ¥90.256 (2024/03/25現在、東日本リージョン) Freeレベル比で1ヵ月 6～7万円のコスト増 となることに注意
LTS適用の制約 LTSはKubernetes本体に対しては適用されるが、 AKSで提供されるアドオンに関しては一部対象外となる 対象外となるアドオンは Istio / KEDA / Dapr / Application Gateway Ingress Controller など... 対象外となるアドオンを有効化しているとLTSに移動できない これらの機能が必要な場合はAKSアドオンではなく OSS版を別途インストールするなどの対処が必要
次のLTSバージョンがリリースされたら 現LTSバージョンから次のLTSバージョンへの 更新パスが提供されるらしい 参考: Azure Kubernetes Service (AKS) クラスターの長期サポート - Azure Kubernetes Service | Microsoft Learn
個人的には… 高コストかつ制約も多いのであまり積極的には利用したくない 次のLTSバージョンに移行できるにせよ、 Kubernetesのマイナーバージョンが3つ上がることになるので 相応の手間は覚悟しておいたほうがよさそう どうしてもアップグレードが間に合わなければLTSを利用しつつも、 できるだけ早く v1.28 へ上げるのがよいのでは
第4案 バージョンアップ作業の リスクを減らす
ダウングレードできない問題 前述のとおりAKSのアップグレードは 元に戻すことができない そのため、「アップグレードしても問題ないこと」を どうやって確認・担保するのか、頭を悩ませている方も多いのでは アップグレードしても 大丈夫ってことを保証できるのか！
複数環境で順番にやろうとしても… Develop 環境でまず確認して…その次は Staging 環境で… 問題なければ Production 環境で実行！ よくある話だけど、リリーススピードと合わない場面もある 新しいバージョンが出てる！ 検証してたバージョンが選べない！ Develop Upgrade Staging Upgrade Production Upgrade この間に数か月かけると…
安全を期すならクラスターBlue/Greenデプロイ 新バージョンのGreenクラスターを新たに準備して、 NW上位側でBlueクラスターからGreenクラスターへ切り替える 何か問題があってもBlueクラスターはそのまま残っているので NWの切り替えのみで切り戻し可能 引用元: AKS クラスターのブルーグリーンデプロイ - Azure Architecture Center | Microsoft Learn
Blue/Greenデプロイするなら… 最初からその前提で構成しないと、後から対応するのは大変 ● VNet / Subnetの設計 ● Blue / Green のどちらが運用系なのかをどう関係者へ伝達するか ○ 運用 / 監視オペレーターにも一定理解してもらう必要あり ● NW上位側での切り替え方式の検討 ○ 100:0 で切り替えたいのか、カナリア的に徐々に切り替えたいのか ○ WAFやCDNは必要か ○ 要件に合わせてネットワークリソースを検討する また、2つのクラスターの設定ズレを防ぐためにも Bicep/TerraformなどのInfrastructure as Codeを活用することを 強く推奨する
第5案 組織体制でカバーする
ある程度大きな組織だと 各チームバラバラに管理してたりしませんか？ プロダクトAチーム ・アプリ開発 ・アップグレード ・日々の運用 全部やる！ プロダクトBチーム ・アプリ開発 ・アップグレード ・日々の運用 全部やる！ プロダクトA用クラスター プロダクトCチーム ・アプリ開発 ・アップグレード ・日々の運用 全部やる！ プロダクトB用クラスター プロダクトC用クラスター
管理主体を分けることのメリデメ それぞれの独立性は担保されるものの、 全体で見れば同じような作業をいろんなところで行っている えてしてナレッジが共有されない サイロ サイロ サイロ
組織内の「プラットフォーム」として運用する プロダクト開発に注力化するチームと 開発チームを支える プラットフォームチーム に分割することで 全体の効率化を図る プロダクトAチーム プロダクトBチーム 開発に集中！ AKSは 利用者として使う！ 各チームが 使いやすいように 運用する！ プラットフォームチーム プロダクトCチーム
ちょっと余談: Platform Engineering について Microsoftがガイドを出してます 最近日本語でも公開されました プラットフォーム エンジニアリング ガイド | Microsoft Learn 有志のコミュニティで勉強会も開催しているので、 興味があればぜひご参加を！ Platform Engineering Meetup
まとめ
今日のおはなしのまとめ ● ● ● ● ● AKSから別サービスに移るもよし Azure側で準備されてる自動更新機能を使うもよし LTSを活用してアップグレードの回数を減らすもよし Blue / Greenでリスクを軽減するもよし 組織の力で乗り越えるもよし 「しんどさ」を軽減するための方法はいくつかあります 自組織にマッチしたやり方を試してみて 「しんどい作業」から「当たり前の作業」に変えていきましょう
ぜひTwitterもフォローしてください！ @apc_tweet
© AP Communications Co., Ltd.