2026年4月17日の Azure Updates で、Azure Kubernetes Service（AKS）における Ubuntu 22.04 サポート終了のカウントダウンが明確になりました。結論から言うと、AKS 管理者は 2027年6月30日までに Ubuntu 24.04 以降へ移行する計画を作る必要があります。単なる OS 更新ではなく、ノードイメージ戦略、Kubernetes バージョン計画、メンテナンスウィンドウ、障害時の復旧手順まで見直すべき変更です。
特に注意したいのは、「Ubuntu 22.04 のノードがすぐ止まる」という話ではない一方で、期限後は新しいノードプール作成、ノードイメージ更新、セキュリティパッチ、将来のスケーリングや修復に影響が出る点です。AKS の本番クラスターを運用している Kubernetes administrators や cloud architects は、2027年を待たずに、2026年中に検証環境で Ubuntu 24.04 への移行パターンを固めておくのが現実的です。Microsoft Learn と AKS の GitHub issue では、Ubuntu 22.04 は 2027年6月30日に AKS で retirement となり、Ubuntu 24.04 以降への移行が推奨されています。(GitHub)
AKS の Ubuntu 22.04 サポート終了で何が変わるのか
今回のポイントは、AKS のノード OS として使われる Ubuntu 22.04 の扱いが、段階的に「通常運用できる対象」から外れていくことです。2027年6月30日までは Ubuntu 22.04 を AKS で継続利用できますが、その日を過ぎると AKS は Ubuntu 22.04 に対するサポートやセキュリティ更新の提供を終了します。さらに、期限までに移行しない場合、新しいノードプールの作成ができなくなり、AKS は新しいノードイメージを生成せず、既存ノードプールへのセキュリティパッチも受け取れなくなります。(Microsoft Learn)
| 時期 | AKS 利用者への影響 | 運用上の意味 |
|---|---|---|
| 2027年6月30日まで | Ubuntu 22.04 を継続利用可能 | ただし、移行検証と本番切り替えの準備期間と考える |
| 2027年6月30日以降 | Ubuntu 22.04 のサポートとセキュリティ更新が終了 | セキュリティ、監査、脆弱性対応のリスクが高まる |
| 2027年6月30日以降 | 新しい Ubuntu 22.04 ノードプール作成や新規ノードイメージ提供に影響 | スケールアウトやノード入れ替え計画が制約される |
| 2028年4月30日 | Ubuntu 22.04 のノードイメージと関連コードが削除される予定 | スケーリングや remediation 操作が失敗する可能性がある |
ここで重要なのは、2027年6月30日は「移行開始日」ではなく「移行完了期限」だということです。本番 AKS クラスターでは、PDB、DaemonSet、Ingress Controller、CSI Driver、CNI、監視エージェント、セキュリティエージェントなどがノード更新時の挙動に影響します。期限直前に osSku を切り替えるだけでは、業務停止やロールバック不能に近い状態を招きかねません。
なぜ Kubernetes バージョン計画とセットで考えるべきなのか
AKS の Ubuntu 22.04 retirement は、OS だけの話に見えます。しかし実務では、Kubernetes のマイナーバージョン、OS SKU、ノードイメージ、LTS の利用可否が絡みます。
Microsoft Learn では、Ubuntu OS SKU の既定 OS バージョンは Kubernetes バージョンに応じて変わり、Ubuntu 22.04 は Kubernetes 1.25〜1.34 の既定、Ubuntu 24.04 は Kubernetes 1.35 以降の既定とされています。また、Ubuntu2404 は Kubernetes 1.32〜1.38 でサポートされるバージョン指定 OS SKU と説明されています。(Microsoft Learn)
| 現在の状態 | 推奨される考え方 | 注意点 |
|---|---|---|
osSku: Ubuntu を使用 | Kubernetes 1.35 以降へ上げると Ubuntu 24.04 へ移行 | Kubernetes アップグレード検証も同時に必要 |
osSku: Ubuntu2204 を使用 | Ubuntu2404 または Ubuntu へ明示的に変更 | versioned OS SKU は自動移行を期待しない |
| Kubernetes 1.32〜1.34 に残したい | Ubuntu2404 で OS だけ先に検証する選択肢がある | 対応する Kubernetes バージョン範囲を確認する |
| Kubernetes 1.33 以降で LTS を使いたい | 先にノードプールを Ubuntu 24.04 に更新する | LTS 有効化前の前提条件として扱う |
Kubernetes のサポート期限も同時に確認すべきです。AKS は GA の Kubernetes マイナーバージョンについて、最新の N と N-1、N-2 の 3 つをサポートする方針を示しており、Kubernetes 1.35 は 2027年3月、1.36 は 2027年6月がサポート終了予定として掲載されています。(Microsoft Learn)
つまり、2027年の計画では「Ubuntu 22.04 を 24.04 に変える」だけでは足りません。クラスターごとに、Kubernetes 1.35 以降へ進めるのか、いったん Kubernetes 1.32〜1.34 のまま Ubuntu2404 を使うのかを決める必要があります。
ノードイメージ戦略で最初に決めるべきこと
AKS の node image strategy では、まず「既定 OS SKU に寄せるか」「バージョン指定 OS SKU を使うか」を決めます。
原則として、多くの一般的なワークロードでは Ubuntu のような既定 OS SKU に寄せるほうが運用はシンプルです。Kubernetes バージョンに合わせて、AKS が検証済みの既定 OS バージョンへ進めやすくなるためです。一方、OS バージョンに強い依存があるセキュリティ製品、eBPF 系ツール、GPU ワークロード、低レイヤーの監視エージェント、独自 DaemonSet を使っている場合は、Ubuntu2404 のような versioned OS SKU で段階的に検証する価値があります。
自動ノードイメージ更新は「OS メジャー移行」の代わりではない
AKS には node OS autoupgrade channel があり、SecurityPatch や NodeImage などのチャネルを使ってノード OS のセキュリティ更新やノードイメージ更新を管理できます。Microsoft Learn では、node OS image auto-upgrade はクラスターの Kubernetes バージョンには影響しないと説明されており、新しい AKS クラスターでは API version 2023-06-01 以降、既定が NodeImage とされています。(Microsoft Learn)
ただし、ここで誤解しやすい点があります。NodeImage を有効にしていても、Ubuntu 22.04 から Ubuntu 24.04 への移行計画が不要になるわけではありません。ノードイメージ更新は、サポートされている範囲のノードを最新に保つ仕組みです。OS SKU や Kubernetes バージョンの前提を変える major OS migration は、別のランブックとして管理すべきです。
| 運用目的 | 使う仕組み | 期待できること | 期待しすぎてはいけないこと |
|---|---|---|---|
| セキュリティ更新を継続的に取り込む | SecurityPatch / NodeImage | ノード OS パッチや VHD 更新を管理しやすい | Ubuntu 24.04 への移行計画そのものは不要にならない |
| Kubernetes バージョンを上げる | cluster upgrade / node pool upgrade | API、コントロールプレーン、ノードプールを段階的に更新できる | アプリ互換性の検証なしに安全とは言えない |
| OS メジャーバージョンを変える | osSku 更新または Kubernetes 1.35+ への移行 | Ubuntu 24.04 へ進められる | DaemonSet や runtime 依存の問題は自動では解消しない |
Ubuntu 24.04 移行で確認すべき互換性ポイント
Ubuntu 24.04 へ移行するときは、アプリケーションコンテナの中身だけでなく、ノード側に依存する仕組みを重点的に確認します。Microsoft Learn では、AKS の Ubuntu 24.04 ノードイメージは containerd 2.0 を既定で使うため、container runtime の挙動に依存するワークロードは検証が必要とされています。また、Ubuntu2404 は Kubernetes 1.32〜1.38 でサポートされ、FIPS はサポートされないと説明されています。(Microsoft Learn)
特に次の項目は、検証環境で実際に Pod を動かして確認してください。
| 確認対象 | 見るべきポイント | 失敗しやすい例 |
|---|---|---|
| DaemonSet | 監視、ログ収集、セキュリティ、CNI 関連の起動可否 | hostPath、privileged、kernel module 依存で起動しない |
| container runtime 依存 | containerd 2.0 でログ、イメージ pull、sandbox 作成が正常か | 古い sidecar や独自ツールが runtime の挙動を前提にしている |
| ネットワーク | CNI、NetworkPolicy、Ingress、DNS の挙動 | ノード切り替え後に名前解決や通信制御だけ失敗する |
| ストレージ | CSI Driver、PV 再アタッチ、stateful workload | Drain 後にボリューム再接続が遅延する |
| セキュリティ要件 | FIPS、脆弱性スキャン、エージェント対応状況 | OS 変更後に監査ツールが未対応と判定する |
| オートスケール | Cluster Autoscaler、HPA、Karpenter/NAP 相当の挙動 | 新 OS のノードが意図した taint/label で作られない |
独自性のある観点として、「コンテナは同じだから大丈夫」と考えないことが重要です。Kubernetes ではアプリはコンテナ内で動きますが、実際の運用事故はノード側の DNS、iptables/nftables、cgroup、container runtime、CSI、エージェント連携で起きることが少なくありません。Ubuntu 24.04 検証では、アプリの HTTP 200 だけでなく、ログ・メトリクス・セキュリティイベント・スケールアウト・ノード修復まで見る必要があります。
実務向けアップグレードランブック
AKS の Ubuntu 22.04 retirement 対応は、全クラスターを一括で更新するよりも、ノードプール単位で段階的に進めるほうが安全です。Microsoft Learn では、Linux の os-sku は既存ノードプールに対して az aks nodepool update で更新できる一方、ターゲット OS が Kubernetes バージョン、VM サイズ、FIPS などに対応していない場合は失敗する可能性があると説明されています。(Microsoft Learn)
現状棚卸し
まず、サブスクリプション内の AKS クラスターとノードプールを棚卸しします。
az aks list \
--query "[].{name:name, resourceGroup:resourceGroup, kubernetesVersion:kubernetesVersion}" \
-o tableクラスターごとにノードプールの OS SKU、Kubernetes バージョン、ノードイメージを確認します。
az aks nodepool list \
--resource-group <RESOURCE_GROUP> \
--cluster-name <CLUSTER_NAME> \
--query "[].{name:name, mode:mode, osType:osType, osSku:osSku, kubernetesVersion:orchestratorVersion, nodeImageVersion:nodeImageVersion, vmSize:vmSize, count:count}" \
-o tableこの時点で、Ubuntu2204 を明示指定しているノードプール、Kubernetes 1.32〜1.34 に残る予定のノードプール、クリティカルな本番ワークロードを分けて管理台帳を作ります。
移行パターンを選ぶ
| パターン | 向いているケース | 実施イメージ |
|---|---|---|
Kubernetes 1.35+ へ上げて Ubuntu を使う | 標準的な AKS 運用。Kubernetes 更新も進められる | クラスター/ノードプールを段階的に 1.35 以降へ更新 |
Kubernetes は据え置き、Ubuntu2404 にする | Kubernetes 更新をまだ避けたいが OS 移行検証を先に進めたい | Kubernetes 1.32 以降の範囲で osSku を更新 |
| Blue-Green で並行ノードプールを作る | 重要システム、即時ロールバック要件、厳しい停止許容 | 新旧ノードプールを並行稼働し、段階的に Pod を移す |
| 新クラスターへ移行する | ネットワーク、ID、ポリシー、GitOps も見直す | 新 AKS クラスターを作り、環境ごと切り替える |
AKS には Blue-Green node pool upgrades の仕組みもあり、既存の blue node pool を維持しながら、新しい green node pool で検証してから切り替えられます。ただし、アップグレード中は二重のノード容量が必要になり、コストとクォータを事前に確保する必要があります。(Microsoft Learn)
検証環境で Ubuntu 24.04 ノードを作る
Kubernetes バージョンを上げずに Ubuntu 24.04 を試す場合は、対応バージョンの範囲で Ubuntu2404 を使う方法があります。公式ドキュメントでは、既存ノードプールの os-sku を Ubuntu2404 に更新する例が示されています。(Microsoft Learn)
az aks nodepool update \
--resource-group <RESOURCE_GROUP> \
--cluster-name <CLUSTER_NAME> \
--name <NODE_POOL_NAME> \
--os-sku Ubuntu2404本番では、いきなり既存ノードプールを書き換えるより、同じ VM サイズ・taint・label・autoscaler 設定を持つ検証用ノードプールを追加し、対象 namespace の一部だけを移すほうが安全です。
ノード更新前のチェックリスト
更新前には、少なくとも次を確認します。
| チェック項目 | 合格基準 |
|---|---|
| PDB | 重要 Pod が Drain を永久にブロックしない |
| レプリカ数 | 単一レプリカの stateless Pod が本番に残っていない |
| クォータ | surge または Blue-Green 用の追加 VM を作成できる |
| メンテナンスウィンドウ | 業務影響が少ない時間帯に 4 時間以上を確保できる |
| ロールバック | 旧ノードプールへ戻す手順、または旧 OS SKU へ戻す条件が明文化されている |
| 監視 | ノード更新中のエラー、Pod 再起動、レイテンシ、5xx を検知できる |
| IaC | Terraform、Bicep、GitOps の osSku と Kubernetes バージョンが手作業とずれていない |
AKS の planned maintenance では、クラスターアップグレードとノード OS アップグレードに別々のスケジュールを設定できます。Microsoft Learn では、aksManagedAutoUpgradeSchedule は cluster auto-upgrade、aksManagedNodeOSUpgradeSchedule は node OS security patching を制御する用途と説明され、auto-upgrade では 4 時間以上のメンテナンスウィンドウが推奨されています。(Microsoft Learn)
2027年までのクラスターリスクをどう評価するか
Ubuntu 22.04 retirement で最も危険なのは、期限そのものよりも「運用チームがリスクを低く見積もること」です。2027年6月30日までは動き続けるため、表面的には問題が見えません。しかし、期限後はパッチ、ノード作成、イメージ更新、スケール、修復といった運用の基盤部分が弱くなります。
| リスク | 影響 | 優先度が高いクラスター |
|---|---|---|
| セキュリティパッチ停止 | 脆弱性対応、監査、コンプライアンスに影響 | インターネット公開、決済、個人情報、規制対象 |
| ノードイメージ更新停止 | 新しい AKS 機能や修正を取り込めない | 長期運用している基盤クラスター |
| スケールアウト制約 | 障害時や繁忙期にノードを増やせない可能性 | オートスケール前提の本番サービス |
| 修復操作失敗 | reimage、redeploy、remediation が効かない可能性 | 自動復旧に依存する 24/7 システム |
| 互換性問題の先送り | 期限直前に containerd、CNI、CSI 問題が発覚 | DaemonSet や低レイヤー依存が多い環境 |
| 人的リスク | 期限直前の変更凍結、担当者不在、承認遅延 | グローバル運用、複数リージョン、本番承認が重い組織 |
現実的な優先順位は、外部公開の本番クラスター、規制対象データを扱うクラスター、ノード数が多いクラスター、特殊な DaemonSet を持つクラスターからです。開発環境や検証環境は後回しに見えますが、むしろ最初に移行して互換性情報を集める役割を持たせるべきです。
2026年中にやるべきスケジュール案
大規模な AKS 環境では、2027年に入ってからの着手では遅い可能性があります。グローバル組織では、年末年始、会計年度末、凍結期間、地域ごとの休暇が重なり、実際に本番変更できる週は想像以上に少なくなります。
| 時期 | 実施内容 | 成果物 |
|---|---|---|
| 2026年Q2 | 全 AKS クラスターとノードプールの棚卸し | OS SKU、Kubernetes version、重要度、担当者の一覧 |
| 2026年Q3 | Ubuntu 24.04 検証ノードプールを作成 | 互換性テスト結果、失敗した DaemonSet、修正チケット |
| 2026年Q4 | 非本番環境を段階移行 | 標準手順、監視項目、ロールバック条件 |
| 2027年Q1 | 低リスク本番から移行 | 本番実績、所要時間、PDB/容量問題の改善 |
| 2027年Q2前半 | 重要本番を移行完了 | 2027年6月30日前の完了証跡 |
| 2027年6月末まで | 例外クラスターをゼロにする | 監査可能な移行完了レポート |
このスケジュールで進めると、2027年6月30日は「最後の追い込み」ではなく「すでに移行済みであることを確認する日」になります。
よくある失敗パターン
Ubuntu と Ubuntu2204 の違いを把握していない
Ubuntu は AKS 側の既定 OS SKU であり、Kubernetes バージョンに応じて既定 OS が変わります。一方、Ubuntu2204 は Ubuntu 22.04 を明示する versioned OS SKU です。前者は Kubernetes 1.35 以降への移行で Ubuntu 24.04 に進みやすい一方、後者は明示的に Ubuntu2404 や Ubuntu へ変える判断が必要です。
ノードイメージ自動更新を有効にしているから安心だと思う
NodeImage や SecurityPatch は重要ですが、OS retirement 対応の代替ではありません。期限後にサポート対象外の OS に残ることを防ぐには、OS SKU と Kubernetes バージョンの計画が必要です。
検証がアプリの疎通確認だけで終わる
HTTP のヘルスチェックが通っても、ログが落ちていない、メトリクスが欠落している、セキュリティエージェントが動いていない、スケールアウト時に Pod が Pending になる、といった問題は本番で初めて見つかりがちです。Ubuntu 24.04 検証では、障害復旧とスケール操作まで含めて確認してください。
PDB と容量不足で Drain が進まない
AKS のノード更新は Pod の退避を伴います。PDB が厳しすぎる、追加ノードを作るクォータがない、ゾーンごとの容量が足りない、といった状態では、計画どおりに更新できません。特に Blue-Green 方式では二重容量が必要になるため、事前のコスト・クォータ確認が必須です。
管理者が次に取るべき行動
まず、全 AKS クラスターのノードプールについて osSku、Kubernetes バージョン、ノードイメージ、ワークロード重要度を棚卸ししてください。次に、Ubuntu2204 を明示しているノードプールと、Kubernetes 1.34 以下で長く運用する予定のノードプールを優先的にリストアップします。
そのうえで、2026年中に Ubuntu 24.04 の検証ノードプールを作り、DaemonSet、CSI、CNI、containerd 2.0、監視、セキュリティ、スケールアウトを確認します。本番移行では、通常ワークロードは rolling upgrade、重要ワークロードは Blue-Green、環境再設計が必要な場合は新クラスター移行を選びます。
AKS の Ubuntu 22.04 retirement は、単なる OS サポート終了ではありません。2027年以降のクラスターリスクを下げるための、ノードイメージ戦略とアップグレードランブックを整備するタイミングです。最初の一手はシンプルです。今日、全ノードプールの osSku と Kubernetes バージョンを出し、2027年6月30日までに Ubuntu 24.04 へ移行する対象を見える化しましょう。
コメント