AKSにおけるKubernetesの自動アップグレードの状況は変わってきている
真壁徹氏：ただ今紹介していただきました、真壁です。よろしくお願いします。マイクロソフトで9年ぐらいソリューションアーキテクトをやっていますが、AKS（Azure Kubernetes Service）が得意です。お客さまの案件をたくさんお手伝いしているので、みなさんがこれまで困っていたアップデートについて、今日いろいろと話せればと思います。40分ほどお時間をいただいて進めようと思います。よろしくお願いします。
自己紹介もほどほどにして、本題に入りたいと思います。最近ポータルでAKSのクラスタを作った方がいると思うのですが、「おや？」と思いませんでしたか？ 以前もアップグレードの設定はあったのですが控えめで、自動アップグレードしないみたいなオプションで入っていて、それが既定だったと思います。
（スライドを示して）最近は、「『Kubernetes』の自動アップグレードはおすすめ」。あとは「KubernetesのいわゆるワーカーノードのOSのイメージは自動アップグレードがおすすめ」。こんな感じになっています。初めに見た時はビックリしました。
街の声を集めてみました。自動アップグレードはいわゆるインプレースなんですよね。クラスタを動かしながら、動いているクラスタをアップグレードする。カッコイイ表現をすると、これは飛行機を飛ばしながら空中で給油する、もしくは飛ばしながらエンジンとかを交換する、そんな感じです。こういうのをインプレースというのですが、「辞めた先輩は『インプレースだけは止めろ』と言って辞めていった」みたいな話はけっこうあります。
クラスタを2つ並べて、Blue/Greenという、新しくアップデートするクラスタを新しく作って、動かしているものはそのままにして、新しいバージョンでテストをしてOKだったらスッとトラフィックを切り替える方式があります。「何かあったら怖い」というお客さまは、けっこうBlue/Greenアップグレードをしています。
あとはたまに、「作ってから1回もアップデートしていません」という人もいるのですが、これは止めてくださいね。止めてください。
これが街の声です。
2021年なら「怖い」「Blue/Greenしたい」という声はわかります。「そうしましょう」と言っていたんですが、今それを言われると「ん？ ちょっと待ってください。最近、状況が変わってきましてね」というのを今日の話の枕にしようかなと思っています。実際に状況が変わってきています。
3種類のAKSのアップデート
ということで、AKSのアップデートの機能や諸々それにまつわる最新状況をおさらいします。（スライドを示して）知っている方はいると思うんですが、AKSを利用していてもアップデートをよくわかっていない方は意外といます。先ほどの「1回もアップグレードしたことがない」みたいな方もいるので、意外と知られていません。なのでおさらいをします。
アップデートは3種類あります。1つ目はAKSメンテナンスと言われているもので、言葉は悪いですが、Azure側で勝手に毎週パッチを当てているような状況ですね。気づいていないお客さまはかなり多いです。
何がアップグレードされているかというと、管理系の機能やアドオンですね。いわゆるネットワークのプラグインやストレージのドライバなど、ああいうアドオンがちょこちょことパッチレベルで当たっています。これがAKSメンテナンスです。
2つ目が、これが今日の一番のトピックになると思いますが、Kubernetesのアップグレードですね。今は1.29（Kubernetes 1.29）が最新かな？ 1.29については後ほど話しますが、これはマイナーバージョンです。
マイナーバージョンをアップグレードしたり、あとはパッチバージョンで1.29.0とか1.29.1などがありますが、これらのアップグレードをKubernetesアップグレードと呼んでいます。これを怖いと言っているお客さまがけっこう多いです。自動もできるし、ユーザーが手動で「このバージョンに、このタイミングで上げたい」ということもできます。
最後にNodeイメージアップグレードということで、KubernetesのWorker Nodeの、いわゆるOSやシステムソフトウェアに入っているイメージをアップグレードします。これはLinux、Windowsにもありますが、Linuxの場合はほぼ週次、Windowsの場合はほぼ月次で新しいイメージが使えるようになります。これも自動適用もできるし、手動の適用もできます。
すべてのアップグレードはインプレースです。動かしながらアップグレードします。
（スライドを示して）「このあたりの情報は、どこかにまとまっていないの？」と、よく聞かれるのですが、まとまっています。今日の資料は、後ほど「Speaker Deck」に上げます。Speaker Deckでダウンロードしてもらうと資料にリンクが入っていて、リンクが押せるようになります。
このリンクを見てもらいたいのですが、「GitHub」にAKSのCHANGELOGが出ています。ほぼ毎週出ています。
「どんな変更がこれからありますか？」とか「新しいイメージのバージョンが出ましたよ」とか、すべてここにまとまっていると言っても過言ではないので、ぜひ見てください。
重大な変更で、「次のバージョンやその次のバージョンでこういう大きな破壊的変更があるよ」というのは毎週のようにしつこく出ているので、ここを毎週、毎週見なくても2週間おきぐらいに見ておけば、だいたい状況がわかります。ぜひ見てもらえればと思います。
バージョンの数字について
（スライドを示して）先ほど話してしまったし、知っている方が多いと思いますが、KubernetesのバージョンはX.Y.Zみたいな感じになっています。一番左のXがメジャーで、これは1回も上がったことがないですね。2番目がマイナー、最後がパッチということでセマンティックバージョンの体をしているのですが、違います。
セマンティックバージョンは、APIが使えなくなって変更になったらメジャーを上げないといけないのですが、Kubernetesはマイナーを上げてきます。なので、ずっと1のままです。今後1から2に上がる日が来るかもしれないですが、セマンティックバージョニングとはちょっと違うということだけ覚えておいてください。
アップグレードで行われること
「アップグレードでどういうことが行われるの？」ということは、簡単にここで紹介しておきたいと思います。3つあるうちの1つですね。Kubernetesアップグレードでどんなことが行われているかを簡単に紹介します。
まず、この絵の左側に「リージョンコントロールプレーン」とあります。各Azureのリージョンが、日本なら東日本、西日本とあります。例えば今はKubernetes 1.29が最新ですが、1.30が来たら「1.30のソフトウェアが使えるよ」とアップロードされます。
MasterとNodeのそれぞれにコンポーネントがアップロードされるのですが、これがアップロードされると、ユーザーがアップグレードでそのバージョンを選べるようになります。あとは毎週のようにLinuxやWindowsのOSのシステムイメージがアップロードされていて、これもアップロードされた瞬間にユーザーが選べるようになります。
手動アップグレードをするとしましょう。例えば1.29から1.30に上げようとする時に、ポチッとボタンを押しました。（スライドを示して）ここでは右側のAKSクラスタをイメージしていますが、この絵でいう真ん中あたりの、ユーザーからは見えないMaster Nodeの上のAPIサーバーやコントローラーといった、コントロールプレーン系のコンポーネントからバージョンアップします。
それらがアップグレードされて、それが終わったらWoker Nodeのアップグレードに移るという順番になっています。Woker Nodeのアップグレードはローリングアップグレードです。新しいNodeを新しいイメージに追加して、その上に新しいバージョンのKubernetes、Nodeのコンポーネントを入れます。
それが立ち上がってくると、古いというか、既存のNode上で動いていたユーザーのPodも動かせる状態になります。Drainと言いますが、まずそのNodeに新しいPodが配置されないようにして（Cordon）、そのあとEviction、退出と呼ばれますが、そのPodを消します。消して、新しいNodeでPodが動きます。これを順々に繰り返していくのがKubernetesアップグレードですね。
AKSメンテナンスやNodeイメージのアップグレードなどの細かい話、あとはそれぞれに気をつけたほうがいいことや仕様は、この資料のお尻に付録を付けてあるので、この今日のイベントが終わったあとに、資料を見てもらえればと思います。
3種類のアップデート、それぞれで考慮すべきこと
3つのアップデートで考慮すべき点を整理してきました。いくつかの視点というか、気をつけなければいけない切り口があります。
提供タイミングはやはり気になりますよね。それはどのぐらいの頻度で出てくるのか。これは気になるところだと思います。
あとは強制的に適用されるのか、されないのか。自動化できるのか。自動化できる場合にはスケジュールですね。夜中にできるとか、週末にできるとか、「ここではしてほしくない」とか、そういう自動化のスケジュールを制御できるのか。
あとはNodeを作り直すのかということは、けっこうポイントだと思います。こういうところは気になるところかなと思います。
一番気にしなければいけないのは、やはりKubernetesのマイナーバージョンアップです。ここではAPIの破壊的な変更が入る可能性があって、一番ケアしなければいけません。
自動化しようと思ったらすべて自動化できます。マネージドサービスなのですべてAzureに任せて、自分たちはメンテナンスやアップグレードのポチ（とボタンを押すこと）をまったくやらないこともできます。
自動化する時には自分のやりたいタイミング、時間帯がいいです。これはすべて選べます。ここがポイントです。
ということで、自動化をするか、しないか。どうするかはAKSの運用負担にかなり影響します。
アップデートのメンテナンス構成
3つのメンテナンスのアップデートがあるという話をしましたが、それぞれメンテナンス構成というものがあって、それごとにスケジュールや、チャネルと呼ばれる、どういうアップデートをするのかを選ぶことができます。
例えばaksManagedAutoUpgradeSchedule。「わからんわ！」となりそうなやつですね。
これがKubernetesのアップデートの細かい指定です。スケジュールとチャネルを選ぶことができます。デフォルトはnoneで、自動アップグレードはしません。すべてユーザーのやりたいタイミングで、アップデートしたいバージョンを指定してやるのがAPIの規定です。
最近、ポータルの推奨がpatchになりました。例えば1.27.9だとすると、このお尻の9は、10が出た場合や11が出た場合に自動アップグレードします。ただ、1.27の27のマイナーバージョンが上がっても上げないよというのが、patchチャネルです。これがポータルのおすすめになりますね。
その他のstable、rapidは、マイナーバージョンも大胆に自動で上げます。これを選ぶのは若干チャレンジなのかなという気はしますが、選ぶことはできます。
（スライドを示して）NodeOSのイメージも自動化してチャネルを選ぶことができます。規定はNodeImageで、これは新しいNodeイメージが出たら先ほど話したとおりNodeをローリングアップデートをします。ほぼ毎週新しいNodeイメージが出てくるので、これが嫌な場合にはnoneやUnmanagedというチャネルを選びます。
Unmanagedをしているケースが多いかもしれないですね。Unmanagedだと、例えばUbuntuであればUnattended-upgrade。再起動を伴わないアップデートが自動で適用されます。毎日適用されます。朝だったかな？ 日本だと朝方※に適用されているかと思います。再起動が必要なアップデートは溜まっていって、再起動された時にそのパッチが当たるかたちになります。
Unmanagedというのは「OSの機能に任せちゃうよ」ということですね。AKSとしては「OSの機能でアップデートしてください」という設定をするだけです。ここまでが最新のAKSのアップデート事情です。
※話者補足: 現在はsystemdのタイマーでUTCの6時、18時に開始し、かつ12時間のランダム遅延が指定されている。
（次回につづく）
