AKSのアップデートを手なずけろ！ まず理解 そして実践 日本マイクロソフト シニアクラウドソリューションアーキテクト 真壁 徹

最近、ポータルでAKSクラスタを作ると、推奨は… パッチバージョン、つまり1.27.xに 新しいバージョンが出たら自動 アップグレードする ノードVMの新しいイメージが 出たら自動アップグレードする

街の声  「自動アップデートってインプレースですよね。辞めた先輩がインプレースだけはやっ ちゃダメって言ってました」  「うちはクラスタのBlue/Green方式でバージョンアップしてるよ。大変だから、や めたいけど！でも、何かあったら怖いから！」  「怖くて一度もアップデートしてません」

3年前なら: 「わかります、ちょっと怖いですよね」 いま: 「最近、状況が変わってきてまして」

AKSアップデート 最新状況をおさらいする

AKSのアップデートは3種類ある • AKSメンテナンス（別称: AKSリリース） • 管理系機能やアドオンなどのソフトウェア更新 （パッチレベルの更新が対象。重大な更新は、Kubernetesアップグレードで行われる） • ほぼ週次で自動適用され、スキップできない（スケジュール指定は可能） • Kubernetesアップグレード（別称: クラスタアップグレード） • Kubernetesのマイナー/パッチバージョンのアップグレード • Kubernetesアップストリームは、マイナーは3～4か月、パッチバージョンは約1か月周期でリリースされる • パッチバージョンは内容次第で、AKSでは提供を見送ることがある • ターゲットバージョンや適用タイミングはユーザが決められる。自動化もできる • Nodeイメージアップグレード • NodeのOSやソフトウェアの更新 • Linux: ほぼ週次、Windows: ほぼ月次 • 適用タイミングはユーザが決められる。自動化もできる AKSが提供するアップデート手段は、 すべてインプレース（クラスタを動かし ながら、そのクラスタをアップデート）

読んでいますか？ ほぼ週刊 AKS Changelog AKS/CHANGELOG.md at master · Azure/AKS (github.com) • 事前に周知が必要な、影響の大きなアナウ ンス（機能の廃止など） • 新たに利用可能になるKubernetesバージョ ン、機能 • バグ修正内容 • 挙動の変更 • 管理系機能やアドオンなどのソフトウェア更 新内容 • 新たに利用可能になるNodeイメージ

Kubernetesのバージョン 1.27.9 メジャー （上がったこ とはない） マイナー パッチ

たとえば: Kubernetesアップグレードで行われること Node • まずAPI Serverなど、Masterで動くコンポーネントのアップグレードを行う • その後、Worker Node追加、新コンポーネント導入、Pod再作成を段階的に行う（ローリングアップグレード） • 既存Nodeで動くPodは退避(Evict)、新Nodeで再作成され、完了すると既存Nodeは削除される • アップグレード時間の短縮のため、一度に追加するNodeの数を増やせる(Surge)が、同時に再作成されるPodも増加し サービスレベルに影響するため、バランスを考慮する • 新Nodeは最新のイメージで作成される Master （不可視） Kubernetesコ ンポーネント リージョン コントロールプレーン 既存Kubernetesコンポーネント 新Kubernetesコンポーネント Node Kubernetesコ ンポーネント Pod (User) 最新Nodeイメージ

各アップデートの詳細は 付録をご覧ください

考慮すべき点の整理 種類 中分類 提供タイミング 強制適用 （※） 自動化可否 自動化スケジュール 制御可否 ノード 再作成 備考 AKSメンテナンス ほぼ週次 Yes Yes Yes No Kubernetes マイナー 年に2～3回 No Yes Yes Yes 破壊的変更の可能性 パッチ 月次（スキップあり） No Yes Yes Yes Nodeイメージ Linux ほぼ週次 No Yes Yes Yes Windows ほぼ月次 No Yes Yes Yes （※）サポート外のバージョンを継続利用し、それに高いセキュリティリスクが認められた場合、マイクロソフトはアップデートを強制適用する権利を有します

アップデートの自動化は AKSの運用負担を左右する

自動アップデート（メンテナンス）構成 • 現在、3種類の自動メンテナンス構成を設定できる • AKSメンテナンス • default • Kubernetesアップグレード • aksManagedAutoUpgradeSchedule • Nodeイメージアップグレード • aksManagedNodeOSUpgradeSchedule • 適用する曜日、時間帯、頻度（日/週/月）を指定可能 • 避けたい日/時間帯も設定できる • ベストエフォートであることに注意。緊急や重大な更新が必要になった場合はそれが優先される 計画メンテナンスを使用して Azure Kubernetes Service (AKS) クラスターのアップグレードをスケジュールおよび制御する - Azure Kubernetes Service | Microsoft Learn

aksManagedAutoUpgradeSchedule • スケジュールだけでなく、5つのアップグレードチャネルから適用内容を選択でき る • none（APIの既定） • 自動アップグレードしない • patch（ポータルの既定） • 最新パッチバージョンを自動で適用する（マイナーバージョンは変えない） • stable • 最新マイナーバージョン “-1”を自動で適用する • rapid • 最新マイナーバージョンを自動で適用する • node-images • 最新Nodeイメージを自動で適用する（Kubernetesのバージョンは同じ） • Nodeイメージアップグレードのスケジュールとチャネルを別途指定できるようになったため、いまはあまり使われない Azure Kubernetes Service (AKS) クラスターの自動アップグレード - Azure Kubernetes Service | Microsoft Learn Kubernetesアップグレード

aksManagedNodeOSUpgradeSchedule • スケジュールだけでなく、4つのアップグレードチャネルから適用内容を選択でき る • none • 自動アップグレード、パッチ適用をしない（AKSは関与しない） • Unmanaged • OS機能を使ってパッチを適用する（AKSはNode作成時の設定のみ行う） • 再起動が必要なパッチが適用された場合は、手動もしくはkuredなどのツールでNodeを再起動する • SecurityPatch（プレビュー） • セキュリティ関連パッチのみNodeの仮想ハードディスクへ適用する • Nodeの再作成と比較し短時間での完了が期待できるが、適用時にNode停止を伴う • NodeImage（API/ポータルの既定） • 最新NodeイメージでNodeを再作成する • 前述のaksManagedAutoUpgradeScheduleで”node-image”を選択すると、このチャネルで固定される Nodeイメージアップグレード ノードの OS イメージを自動アップグレードする - Azure Kubernetes Service | Microsoft Learn

AKSのアップデート戦略を 考える

アップデートに関するトラブルの原因: 代表例 • 環境や設定 • Node追加に際し、CPUやIPアドレスがサブスクリプションの上限に達してしまう • PodDisruptionBudgetのmaxUnavailableを0にするなど、Drain/Evictを妨げる設定がある • アップデートを妨げるNSGルールがある • アップデート内容 • 廃止対象のKubernetes APIを使っており、アプリケーションが期待通り構成されない • リソース管理機能（cgroups）が更新され、特定の言語ランタイムでCPU消費が急増する • Node OSのアップデート内容にバグが含まれ、名前解決が機能しなくなる • アプリケーションの安全でない停止と起動 • Drain/Evictで削除した存在しないPodにパケットが転送されたり、処理中のリクエストがあるのにPodが削 除されたりする • Podの削除とネットワーク設定が非同期で行われるKubernetesの構造的課題 • 準備の出来ていない新Podにパケットが転送される

プラットフォーム技術者の役割 • アップデートの戦略としくみ作りをリードする • 戦略と方針の決定 • 戦略の実装 • アップデートを妨げるリソースを「作れない」しくみを整える • Deployment Safeguardsなどを活用 • 例: PodDisruptionBudgetのmaxUnavailableが0のPodの作成を検知/拒否するポリシー • 廃止/非推奨APIが使われていないかチェックする • 問題の診断と解決機能 • 廃止/非推奨となるAPIの使用が検出される（1.26以降） • もし使用している場合、アップグレード操作は既定で拒否される（実行せず停止する）

アプリケーション開発者の役割 • アプリケーションが安全に停止、起動できるようにする • グレースフルシャットダウンの考慮 • preStopフックでの待機、アプリケーションでのシグナルハンドリングなど • Readiness Probeの設定 • 準備ができた、とReadiness Probeが確認できる正常性エンドポイントも必要 • 呼び出す側もエラーハンドリングを考慮する • 再試行、サーキットブレーカー、タイムアウト • 丁寧なエラーメッセージ

アップデートは理解を得やすいカオスエンジニアリングであり アプリケーションの回復性を確かめる絶好の機会である トール・マカベッチ

みんなの役割 • アプリケーションを動かしてテストする • トラブルの多くは、事前にテストをしていれば認識、防止できたもの • 事前に机上で把握、対処できるのが理想だが、まあ漏れる • Kubernetesとその周辺の構成要素は多く、かつ変化するため、人間の認知能力を超えがち • 動かして試したほうが早く確実 • トレードオフを議論、調整する • アップデートを早く終わらせたい vs 影響範囲小さくじわじわ進めたい • maxSurgeやPodDisruptionBudget、Node Soak Time • 業務影響の小さな夜間や休日作業にしたい vs 対応できる人が多い平日日中にしたい • メンテナンススケジュール設定 • アプリケーション、サービスレベルの監視を確立する • アップデートの失敗がサービスレベルに影響するかを検知 • アップデートが失敗してもサービスレベルに影響がなければ、余裕をもって対処できる

アップデート戦略サンプル① AKSの既定、推奨ベース

AKSの推奨、既定を採用する • Kubernetesとエコシステム、AKSの成熟を背景にした戦略 • 年々、自動/インプレースアップグレードのリスクは下がっている • Deployment Safeguardsや問題の診断と解決機能など、リスクを減らす/対処する機能も拡充 • Kubernetesアップグレードは自動、チャネルは’patch’ • パッチアップグレード（最短で月次）の負担を軽減する • マイナーアップグレードはリスクを考慮し手動 • Nodeイメージアップグレードは自動、チャネルは’NodeImage’ • イメージアップグレード（最短で週次）の負担を軽減する • 急ぎで適用したいイメージがあれば、随時手動で適用 • スケジュールを工夫する • アプリケーションへの影響が小さい、もしくは有事に対応しやすい時間帯や曜日を指定 • “3 か月ごとに月の初日に”、 “2 か月ごとに最後の月曜日に”などの指定も可能

インプレースアップデート失敗からのリカバリ (1/2) • 原因を取り除いてアップデートを再試行 • ロールバックではなく、アップデートを完遂する • バックアップから戻す/作り直すよりもシンプル • PodDisruptionBudegetの設定ミスなどは、原因がわかればすぐに解決できる • 「問題の診断と解決」機能などを活かし、原因の特定と解決を行う • エラーの原因が推測できる場合には、ポータルの概要画面に対処法へのリンクが表示される • 解決後、目標と同じバージョンにアップデートを再試行

「問題の診断と解決」機能を活用 Azure Kubernetes Service (AKS) の問題の診断と解決の 概要 - Azure Kubernetes Service | Microsoft Learn New!!: チャット形式 （プレビュー）

インプレースアップデート失敗からのリカバリ (2/2) • Azure Backup • クラスタリソース（Kubernetesの各種リソース）と永続ボリュームが対象 • ただし、Kubernetesのバージョンはバックアップを取得した際のバージョンに戻せない • つまり前バージョンに戻すには、前バージョンのクラスタを再作成し、そこに戻すことになる • 結局、短時間でリカバリするにはInfrastructure as Codeなど再作成のしくみが必要 • Infrastructure as Code(IaC) • BicepやTerraformなどIaCツールにより、迅速で再現性高くクラスタを再作成できるようにしておく • Kubernetesの各種リソースについては、マニフェスト再投入を自動化しておく • GitOpsも有効な手段 • 永続ボリュームを使わないステートレスクラスタにできると、運用の負担は減る（永続データはAKS外のマ ネージドサービスを使う） • 永続ボリュームを使わないクラスタでは、Azure Backupでのバックアップをしないケースが多い （IaC/マニフェストで環境の再現ができれば、必須ではない）

インプレースアップグレードの代替戦略(Blue/Green) AKS クラスターのブルーグリーンデプロイ - Azure Architecture Center | Microsoft Learn • クラスタの前段にゲートウェイ/プロキシを置き、新旧クラスタ（ブルー/グリーン）を切り替える • 新バージョンのクラスタの試験を十分に行ったうえで切り替えられる • 切り替え後に新クラスタが安定したら、旧クラスタは削除しコストを抑える • なるべくデータをクラスタ内に置かず、クラスタ外のサービスを活用する

Blue/Green クラスタアップグレードの要点 • IaC、アプリ配布やテストの自動化が整備されていないと、負担は大きい • リスクが低いといって、安易に選択しない • むしろその作業が新たなリスクを生む可能性もある • まずインプレースアップグレードを検討し、リスクを許容できない場合に Blue/Greenアップグレードを選ぶ • インプレースを基本方針としても、後からアップグレード内容に応じて Blue/Greenを選択できるようにしておくと安心 • 前もってクラスタの前段にプロキシ/ゲートウェイを配置しておく • 追加クラスタを作れるだけのIPアドレスレンジを確保 • アップグレードに限らず、「クラスタの設計を見直したい = 作り直したい」ケースでも有用（よくある）

アップデート戦略サンプル② 事前検証のしくみ化

Upgrade Stage: Staging 本番とは別のクラスタでの事前検証をしくみ化する • 事前検証から本番適用へのフロー、手段を確立する • ステージング/検証環境を先にアップデートし、十分に検証できる時間を設ける • Azure Kubernetes Fleet Managerの更新オーケストレーション機能が有用 • クラスタをグループ化し、アップデート後に待機時間を設定できる • たとえば3日待機する設定にすれば、本番適用前に3日検証できる • 問題が見つかった場合、途中で停止できる Azure Kubernetes Fleet Manager アーキテクチャの概要 | Microsoft Learn Upgrade Group: Staging Wait Upgrade Stage: Production Upgrade Group: Production begin end 都合のよいタイミングで開始 （API/CLIで自動化も可能）

重要: 自動テスト • ステージングへの事前適用期間で、問題に気づけるか • 開発環境をアップデートし、開発者に気づいてもらうやり方もあるが、不確実 • 何かしら、自動的に検証するしくみの導入を推奨 • 網羅的なE2Eテストは不要 • たとえば、KubernetesやNodeのアップデートで、UIの一部だけが壊れることは稀 • Podが起動しない、通信できないなど、わかりやすく壊れる • 主要なフロー、正常性エンドポイントのチェックで良しとするケースも多い • ステージング、検証環境を自動・継続的にテストする • 商用と同様の合成監視を行うアイデアもある • 商用の合成監視構成をコピーして、監視先をステージングに向ければいい • 監視とは、継続的なテストとも言える

まとめ

24x365で動いているあのサービスも、AKSを使っている • Office 365 • Teams • Bing Copilot • GitHub Copilot • Xbox • OpenAI ChatGPT

まとめ  いまは「アップデートが大変」から「できるだけ自動化して楽をする」への転換期  知識がドキュメントとして公開され、支援機能やツールも整ってきた  Kubernetesコミュニティもバージョンアップ体験を気にかけている  自動化とリスクをトレードオフとせず、両立させる  リスクを理解し、受け入れ可能なラインを議論、合意する  自動化しつつリスクを下げるしくみを作る  自動化は、はじめの一歩を踏み出す勇気が重要  はじめからすべてを自動化する必要はなく、部分的、段階的に取り組み、経験と能力、自信を得る  慣れてしまえば どうということはない

No content

付録 AKSアップデートの詳細

AKSメンテナンス

AKSメンテナンスで行われること Node 管理系機能 /アドオン • 各リージョンに、新たに利用可能な管理系機能/アドオンやイメージが追加される • 管理系機能/アドオンが、自動でAKSクラスタに適用される • 新Nodeイメージは、自動でAKSクラスタに適用されない（適用タイミングはユーザが選択する。後述） • ほかのアップデートと違い、Nodeの再作成は行われない Master （不可視） 管理系機能 /アドオン Pod (User) リージョン コントロールプレーン 既存管理系機能/アドオン 新管理系機能/アドオン 既存Node OSイメージ 新Nodeイメージ

AKS Release-Tracker AKS Release Status (azure.com) リージョン別にAKSリリースの 適用状況が分かる リリースの順序や進捗がわかる ペアリージョンでの同時リリー スを避けている（Japan East/Westなど）

Kubernetesアップグレード

Kubernetesアップグレードで行われること Node • まずAPI Serverなど、Masterで動くコンポーネントのアップグレードを行う • その後、Worker Node追加、新コンポーネント導入、Pod再作成を段階的に行う（ローリングアップグレード） • 既存Nodeで動くPodは退避(Evict)、新Nodeで再作成され、完了すると既存Nodeは削除される • アップグレード時間の短縮のため、一度に追加するNodeの数を増やせる(Surge)が、同時に再作成されるPodも増加し サービスレベルに影響するため、バランスを考慮する • 新Nodeは最新のイメージで作成される Master （不可視） Kubernetesコ ンポーネント リージョン コントロールプレーン 既存Kubernetesコンポーネント 新Kubernetesコンポーネント Node Kubernetesコ ンポーネント Pod (User) 最新Nodeイメージ

Kubernetes マイナーバージョンアップの影響 kubernetes/CHANGELOG/CHANGELOG-1.27.md at master · kubernetes/kubernetes (github.com) 機能の廃止や非 推奨化 1.26 -> 1.27の場合 APIの変更 • 「マイナー」の語感に反し、機 能の廃止や非推奨化など、 APIの変更が含まれる • 破壊的な変更が含まれるか 否かは、リリースされるまでわか らない • リリースされたら、リリースノート に目を通し、テストしておくこと が望ましい

Kubernetes/AKSマイナーバージョン関連スケジュール K8s バージョン アップストリームのリリー ス AKS プレビュー AKS GA サポート終了 プラットフォームのサポー ト 1.24 2022 年 4 月 2022 年 5 月 2022 年 7 月 2023年7月 1.28 GA まで 1.25 2022 年 8 月 2022 年 10 月 2022 年 12 月 2024 年 1 月 2 日 1.29 GA まで 1.26 2022 年 12 月 2023 年 2 月 2023 年 4 月 2024年3月 1.30 GA まで 1.27* 2023年4月 2023 年 6 月 2023年7月 2024 年 7 月 (LTS は 2025 年 7 月まで) 1.31 GA まで 1.28 2023 年 8 月 2023年9月 2023年10月 1.32 GA まで 1.29 2023年12月 2024年2月 2024年3月 1.33 一般提供まで • おおよそ3～4か月で新バージョンが利用可能になる • 最新のGAバージョンと、その前の2バージョンがサポートされる(N-2) • N-3もサポートされるが、脆弱性や不具合の修正はプラットフォーム（Azure）に関するものに限られる • よって、年に1～2回のアップグレードを計画しておく • AKSにはLTS（2年サポート）もあるが、アドオンやエコシステムのソフトウェアがサポートを打ち切る可能性がある。また、いず れアップグレードは必要。先送りでむしろリスクが高まる可能性は考慮する Azure Kubernetes Service (AKS) でサポートされている Kubernetes のバージョン。 - Azure Kubernetes Service | Microsoft Learn

Kubernetesパッチバージョンアップ • パッチバージョンアップ = 修正プログラムの適用 • APIや機能仕様は変わらないので、マイナーバージョンアップほど影響は大きくない • セキュリティ関連の修正を含むため、リリース後の速やかな適用を推奨 • パッチバージョンのサポート対象は N-2 • 新しいパッチバージョンのリリース後、最も古いバージョンはサポート対象から外れる Azure Kubernetes Service (AKS) でサポートされている Kubernetes のバージョン。 - Azure Kubernetes Service | Microsoft Learn サポートされるバージョンの一覧（パッチ は間が飛ぶことがある） 1.25の新たなパッチバージョン がリリースされると、1.25.6が 削除される

Nodeイメージアップグレード

Nodeイメージアップグレードで行われること Node • 最新のNodeイメージを使って、Nodeを追加する • 既存Nodeで動くPodは退避(Evict)、新Nodeで再作成され、完了すると既存Nodeは削除される Master （不可視） リージョン コントロールプレーン Node Pod (User) 最新Nodeイメージ