AKSのAzure Linux 2.0イメージ削除開始：スケールアウトとDRの前提を見直す

結論：稼働確認に加え、必要時に容量を増やせることを確認する

編集上の判断：対象はAKS上でAzure Linux 2.0を使用しているノードプールです。実ノードのOSとイメージを棚卸しし、移行の優先度を、負荷増加時の追加容量、障害時の代替容量、移行時の一時容量に分けて判断してください。既存ノードがReadyでも、これから追加するノードのイメージが利用可能とは限りません。

編集上の提案：移行できていない場合は、既存の稼働ノードを無計画に減らさず、サポート対象の代替プールとワークロードの適合性を検証します。本記事は個別環境の設計保証や法的助言を行うものではありません。実装適用には検証環境での事前テスト、および委託・支援を含む業務範囲の確認が必要です。

背景と技術的要因：サポート終了とイメージ削除は別の段階

確認済み事実：Microsoft Learn日本語版「Azure Linuxコンテナーホストを使用する」は、サポート・セキュリティ更新の終了、イメージの202512.06.0での凍結、その後の削除とスケーリング不可を説明しています。英語版のOSアップグレード資料も同じ終了日・削除開始日を示しています。

編集上の技術評価：パッチ供給の終了は脆弱性対応の問題、イメージ削除は新たなノード供給の問題です。負荷を既存ノード内で処理できる状態と、ノード喪失後もサービス容量を維持できる状態を、別の受入条件として扱うことを提案します。

適用日・対象・バージョン：2026年10月31日は削除開始日

確認済み事実：対象はAzure Linux 2.0のAKSノードイメージと、それを利用するノードプールです。サポート・セキュリティ更新終了日は2025-11-30、凍結イメージのリリース番号は202512.06.0、削除開始日は2026-10-31です。時刻、リージョン別の完了日、今回の削除開始日を初めて公表した日は確認できず、いずれもnullとして扱います。番号からリリース日を逆算しません。

確認済み事実：OSアップグレード資料では、AzureLinuxの既定OSはKubernetes 1.32以降でAzure Linux 3.0とされ、バージョンを明示するAzureLinux3も移行先として示されています。これは任意の旧Kubernetesバージョンが現在サポート中であることを意味しません。APIバージョン変更の一律適用日は確認できずnullです。

確認済み事実と資料の読み分け：日本語のOSアップグレード資料にはサポート終了日を2025年1月30日とする記述があります。本記事は、別の日本語公式ページと英語版で一致する2025-11-30を採用しました。資料の表示更新日は日本語の利用資料2026-07-06、OSアップグレード資料の日本語版2026-09-15・英語版2026-09-10です。これらを公表日・適用日と同一視しません。

設計・実装：OS SKU、IaCと依存コンポーネントを同時に照合する

確認済み事実：公式資料は既存プールの移行にaz aks nodepool updateの--os-skuを案内しています。移行先に、対象Kubernetesバージョン、VMサイズ、FIPS設定に対応するイメージがなければ失敗する可能性があります。OS SKUとKubernetesバージョンを組み合わせて評価する必要があります。

編集上の提案：ポータルやCLIから取得したプール設定、実ノードのOS情報、nodeImageVersionを台帳に記録します。Bicepのノードプール定義にあるosSKU・orchestratorVersion、Terraformで採用するプロバイダーの対応属性とバージョンを照合し、planまたはwhat-ifでプール置換、再イメージ化、ノード数の変更をレビューしてください。特定APIバージョンやプロバイダー版でAzureLinux3を指定できるとは本記事では保証しません。

編集上の設計パターン：既存プールの更新と、対応OSの別プールを追加して順次移す方式を比較します。CNI・CSI・監視・セキュリティ用DaemonSet、カーネル依存モジュール、特権コンテナー、ホストパス、CPUアーキテクチャ、FIPS要件を試験対象に含めます。ラベル、taint、ノード選択条件、ゾーン指定が新プールへの移動を妨げないことも確認します。

運用・監視・DRと責任分界：ノード供給失敗を検知する

編集上の提案：ノード数とPodの稼働数に加え、ノードプール操作の失敗、Cluster Autoscalerの拡張失敗、Pending Podとスケジューリングイベントを相関させます。イメージ削除、クォータ不足、IP不足、PDBによる移行停滞を同じ原因として処理しないよう、操作ログ・理由・対象プールを保存してください。

編集上のDR検証：復旧先リージョンのIaCにも旧OS設定が残っていないか確認し、必要容量のノード追加から、ボリューム接続、Pod再配置、外部接続までを試験します。RTO・RPOは計測値で評価し、旧イメージへの再作成を前提とする切戻し案は見直します。ノードイメージ削除の案内だけから、ストレージの復元やアプリケーションの整合性が保証されるとは判断できません。

編集上の責任分界整理：事業者側のイメージ提供・サポートと、利用者・運用受託者側で確認するOS選択、依存ソフトの適合性、容量計画、移行試験、監視・復旧手順を作業項目に分けます。実際の担当と支援範囲は契約・運用体制で確認し、未担当の検証作業を残さないようにします。