Azure Kubernetes Service（AKS）のOSアップグレードで最初に押さえるべき答えは、Kubernetesのバージョンだけを見ていては不十分という点です。AKSノードのOSはosSkuとKubernetesバージョンの組み合わせで決まり、Ubuntu 20.04、Ubuntu 22.04、Azure Linux 2.0などには廃止・移行期限があります。期限を過ぎると、セキュリティ更新が止まるだけでなく、ノードプールのスケールや修復に影響する可能性があります。(Microsoft Learn)
この記事では、2026年6月初旬時点のMicrosoft Learn公式情報をもとに、Azure Kubernetes Serviceの「Upgrade Operating System (OS) Version in Azure Kubernetes Service (AKS) Clusters」で何が変わるのか、どのノードプールが影響を受けるのか、管理者・開発者が今すぐ確認すべき設定と移行時の注意点を整理します。
AKSのOSアップグレードで重要なのは「Kubernetes」と「OS SKU」を分けて見ること
AKSでは、ノードプールのOSバージョンは主に次の3つで決まります。
| 確認項目 | 意味 | 実務で見るポイント |
|---|---|---|
--os-type | LinuxまたはWindowsのOS種別 | LinuxノードかWindowsノードかを確認する |
--os-sku | Ubuntu、AzureLinux、Ubuntu2404などのOS SKU | 既定追従型か、特定バージョン固定型かを確認する |
--kubernetes-version | ノードプールまたはクラスターのKubernetesバージョン | そのOS SKUがサポート範囲内か確認する |
公式ドキュメントでは、Ubuntu、AzureLinux、AzureContainerLinuxなどの既定OS SKUは、Kubernetesバージョンに応じて検証済みのOSバージョンへ更新される扱いです。一方、Ubuntu2404やAzureLinux3のようなバージョン付きOS SKUは、特定のOSバージョンを明示的に選ぶための指定です。(Microsoft Learn)
実務では、「AKSをアップグレードした」だけではなく、「ノードプールがどのOS SKUで動いているか」まで確認する必要があります。特に、過去に互換性維持や検証目的でバージョン付きOS SKUを指定した環境では、Kubernetesアップグレード時にOS SKUが移行の足かせになることがあります。
今回の公式情報で押さえるべき変更点
今回のポイントは、AKSノードで利用されるOSバージョンのライフサイクルがより明確になり、移行期限を過ぎた場合の影響が具体的に示されていることです。
| 対象OS | 主な期限・状態 | 影響 | 推奨対応 |
|---|---|---|---|
| Ubuntu 20.04 | 2027年3月17日以降、AKSでサポートおよびセキュリティ更新が提供されない | 既存ノードイメージ削除、Ubuntu 20.04ノードプールのスケール不可 | Kubernetes 1.35以降へのアップグレードなどでサポート済みUbuntuへ移行 |
| Ubuntu 22.04 | 2027年6月30日以降、AKSでサポートおよびセキュリティ更新が提供されない | 新規ノードプール作成不可、新規ノードイメージなし、既存ノードプールへのセキュリティパッチなし | Ubuntu 24.04以降へ移行 |
| Azure Linux 2.0 | 2025年11月30日以降サポート終了、2026年3月31日以降ノードイメージ削除の対象 | ノードプールのスケール不可 | サポート対象のKubernetesバージョンへアップグレード、またはAzureLinux3へ移行 |
Ubuntu 22.04については、2027年6月30日まではAKS上で継続利用できますが、期限後は新しいノードイメージやセキュリティパッチを受け取れなくなります。さらに、2028年4月30日にはUbuntu 22.04のノードイメージと関連コードが削除され、スケーリングや修復操作に失敗する可能性があるとされています。(Microsoft Learn)
ここで重要なのは、稼働中のPodが即座に停止するかどうかだけで判断しないことです。ノード障害、オートスケール、ノード再作成、ノードイメージ更新、障害復旧の場面で「ノードを増やせない」「置き換えられない」状態になると、可用性や復旧時間に直接影響します。
影響を受けやすいAKSクラスター
今回のOSアップグレード情報で特に注意すべきなのは、次のようなAKSクラスターです。
| クラスターの状態 | リスク | 確認すべきこと |
|---|---|---|
| 古いKubernetesバージョンを使い続けている | 新しいOS SKUへ移行できない可能性がある | 現在のKubernetesバージョンとアップグレードパス |
Ubuntu2204などバージョン付きOS SKUを明示指定している | 既定OS SKUへ自動追従しない | 今後も固定が必要か、Ubuntuへ戻すべきか |
| Azure Linux 2.0を利用している | サポート終了とスケール不可リスク | AzureLinux3または対応Kubernetesバージョンへの移行 |
| Windowsノードプールを利用している | 既存ノードプールのOS SKU更新では対応できない場合がある | 新しいWindows OS SKUのノードプール追加とワークロード移行 |
| GPU、FIPS、CVMなど特殊要件がある | 対象OS SKUやVMサイズの制約で更新に失敗する可能性がある | OS SKU、VMサイズ、FIPS/CVM対応状況 |
公式情報では、Linuxの既存ノードプールはaz aks nodepool updateでサポートされるOS SKU間の移行が可能ですが、対象OSに対応するノードイメージがKubernetesバージョン、VMサイズ、FIPS設定に存在しない場合は失敗する可能性があります。また、WindowsのWindows2019、Windows2022、Windows2025は既存ノードプールのupdateコマンドによるOS SKU変更がサポートされず、目的のOS SKUを指定したノードプールを追加する必要があります。(Microsoft Learn)
まず確認すべきAKSノードプールの設定
運用中のAKSで最初に行うべき作業は、ノードプールごとのOS SKU、Kubernetesバージョン、ノードイメージを棚卸しすることです。
az aks nodepool list \
--resource-group <resource-group-name> \
--cluster-name <cluster-name> \
--query "[].{name:name, mode:mode, osType:osType, osSku:osSku, kubernetes:orchestratorVersion, image:nodeImageVersion}" \
-o table確認結果は、次のように分類すると判断しやすくなります。
| 分類 | 例 | 判断 |
|---|---|---|
| 既定OS SKU | Ubuntu、AzureLinux | Kubernetesアップグレードに合わせて既定OSへ追従しやすい |
| バージョン付きOS SKU | Ubuntu2204、Ubuntu2404、AzureLinux3 | 検証・固定の理由がなければ将来の移行計画が必要 |
| サポート終了・終了予定OS | Ubuntu 20.04、Ubuntu 22.04、Azure Linux 2.0 | 期限前に移行計画を作る |
| Windowsノード | Windows2019、Windows2022など | 新ノードプール追加による移行を前提にする |
加えて、ノードOS自動アップグレードチャネルも確認しておくべきです。AKSのノードOS自動アップグレードは、Kubernetesバージョンのアップグレードとは別に、ノードレベルのOSセキュリティ更新を扱う仕組みです。(Microsoft Learn)
az aks show \
--resource-group <resource-group-name> \
--name <cluster-name> \
--query "autoUpgradeProfile"nodeOsUpgradeChannelがNoneやUnmanagedの場合、OS更新の責任範囲が運用チーム側に寄ります。セキュリティパッチをAKS管理に寄せたい場合は、SecurityPatchやNodeImageの利用を検討します。ただし、これらは「OSのメジャーバージョン移行」と同じ意味ではありません。パッチ適用とUbuntu 22.04から24.04への移行は別物として計画してください。
Ubuntu系ノードプールの移行判断
Ubuntuを使っている場合、判断の軸は「既定OS SKUに寄せるか」「バージョン付きOS SKUで段階検証するか」です。
Ubuntuを使っている場合
--os-sku Ubuntuは既定OS SKUです。公式情報では、Kubernetes 1.25から1.34ではUbuntu 22.04、Kubernetes 1.35以降ではUbuntu 24.04が既定になるとされています。つまり、Ubuntuを使っているノードプールは、Kubernetes 1.35以降へ上げることでUbuntu 24.04へ移行する流れになります。(Microsoft Learn)
この方式は、AKSの検証済み既定に追従したい本番環境に向いています。独自のOS固定要件がなければ、長期的にはUbuntuのような既定OS SKUを使うほうが管理しやすくなります。
Ubuntu2404を使う場合
Ubuntu2404は、Kubernetes自体をすぐに1.35以降へ上げずにUbuntu 24.04を検証したい場合に有効です。公式情報では、Ubuntu 24.04はKubernetes 1.32から1.38でサポートされ、Ubuntu 24.04のAKSノードイメージではcontainerd 2.0が既定で使われるため、コンテナランタイムの挙動に依存するワークロードは検証が必要です。(Microsoft Learn)
az aks nodepool update \
--resource-group <resource-group-name> \
--cluster-name <cluster-name> \
--name <node-pool-name> \
--os-sku Ubuntu2404検証環境では、アプリケーションの起動、ログ出力、サイドカー、DaemonSet、CSIドライバー、セキュリティエージェント、監視エージェントが通常通り動くかを確認してください。特に、ホストOSのパス、カーネル機能、iptables/nftables、containerdの挙動に依存しているコンポーネントは影響を受けやすい部分です。
Ubuntu2204を使っている場合
Ubuntu2204は、Ubuntu 22.04へ明示的に固定するためのOS SKUです。ロールバックや互換性維持には役立ちますが、2027年6月30日の期限を考えると、恒久的な固定先としては適しません。公式情報では、Ubuntu2204はKubernetes 1.25から1.36でサポートされる一方、Kubernetes 1.37以降へ上げる前にサポート対象のOS SKUへ更新する必要があるとされています。(Microsoft Learn)
本番環境でUbuntu2204を使っている場合は、次の順で進めると安全です。
| 手順 | 実施内容 | 目的 |
|---|---|---|
| 1 | ステージング環境でUbuntu2404またはUbuntuへの移行を試す | 互換性確認 |
| 2 | PDB、レプリカ数、監視、ログを確認する | ノード入れ替え時の停止を防ぐ |
| 3 | 低トラフィック時間帯に一部ノードプールから移行する | 影響範囲を限定 |
| 4 | 問題がなければ本番ノードプールへ展開する | 段階移行 |
| 5 | Ubuntu2204固定の理由がなくなったら既定OS SKUへ戻す | 将来の移行負担を減らす |
Azure Linux系ノードプールの移行判断
Azure Linuxを利用している場合は、Azure Linux 2.0からAzure Linux 3.0への移行が重要です。公式情報では、AzureLinuxはKubernetes 1.27から1.31ではAzure Linux 2.0、Kubernetes 1.32以降ではAzure Linux 3.0が既定になります。AzureLinux3は、Kubernetesをすぐに上げずにAzure Linux 3.0を検証・移行するためのOS SKUとして利用できます。(Microsoft Learn)
az aks nodepool update \
--resource-group <resource-group-name> \
--cluster-name <cluster-name> \
--name <node-pool-name> \
--os-sku AzureLinux3Azure Linux 2.0を利用している環境では、単なるセキュリティパッチ対応ではなく、OSメジャーバージョン移行として計画してください。特に、ホストに近いレイヤーで動くDaemonSet、セキュリティ製品、監視エージェント、ログ収集エージェント、GPU関連ドライバーは、事前検証の優先度が高いです。
Windowsノードプールは「更新」より「追加して移行」で考える
Windowsノードプールは、Linuxノードプールと同じ感覚で既存ノードプールのOS SKUを更新できるとは限りません。公式情報では、Windows2019、Windows2022、Windows2025はaz aks nodepool updateでのOS SKU変更がサポートされず、目的のOS SKUを指定したノードプールを追加する必要があるとされています。(Microsoft Learn)
実務では、次の流れが現実的です。
| 手順 | 作業 |
|---|---|
| 1 | 新しいWindows OS SKUのノードプールを追加する |
| 2 | 対象ワークロードのnodeSelector、taints/tolerations、affinityを確認する |
| 3 | ステージング相当のワークロードを新ノードプールへ配置する |
| 4 | IIS、.NET、Windowsコンテナイメージ、ログ収集、監視の動作を確認する |
| 5 | 本番ワークロードを段階的に移行する |
| 6 | 旧ノードプールをcordon/drainし、問題がなければ削除する |
Windowsコンテナは、ベースイメージとホストOSの互換性が問題になりやすいため、Linux以上に事前検証が重要です。
OSアップグレード前に確認すべき展開上の注意点
OSアップグレードでは、ノードの再イメージ化や入れ替えが発生する場合があります。つまり、アプリケーション側から見ると「ノードがdrainされ、Podが別ノードで再作成される」イベントとして現れます。
AKSのアップグレード推奨では、メンテナンスウィンドウ、max surge、PDB、node drain timeout、node soak timeを組み合わせることで、低停止のアップグレードを実現しやすくなるとされています。公式情報では、本番環境のmaxSurgeは33%が推奨値として示されています。(Microsoft Learn)
| 確認項目 | 見るべき理由 | よくある失敗 |
|---|---|---|
| PDB | Pod退避時の同時停止数を制御する | maxUnavailable: 0相当で退避できない |
| レプリカ数 | Pod退避中もサービスを継続する | レプリカ1のまま本番運用している |
| max surge | 追加ノードを使って入れ替え速度を上げる | サブネットIPやクォータ不足でノード作成に失敗 |
| drain timeout | Podの終了待ち時間を調整する | バッチや重いアプリが終了しきれない |
| メンテナンスウィンドウ | 影響の少ない時間帯に更新する | 自動更新が業務ピーク時間に重なる |
| 監視・ログ | 移行後の異常を早く検知する | ノード入れ替え後にエージェントが起動していない |
特に注意したいのは、PDBです。AKSのアップグレードではノードのdrainが必要になり、Podの終了が遅い場合やPDBが厳しすぎる場合に失敗することがあります。PDBを無理にバイパスする強制アップグレードも選択肢としては存在しますが、サービス停止につながる可能性があるため、まずはPDB設定、レプリカ数、Pod終了処理を見直すべきです。(Microsoft Learn)
ノードOS自動アップグレードチャネルの選び方
OSアップグレードを考える際は、メジャーバージョン移行とは別に、日常的なノードOS更新の運用も見直しておくと効果的です。
AKSのノードOS自動アップグレードチャネルには、None、Unmanaged、SecurityPatch、NodeImageなどがあります。SecurityPatchはAKSでテストされたセキュリティパッチを管理適用し、必要な場合のみreimageする設計です。NodeImageはセキュリティ修正とバグ修正を含む新しいVHDでノードを更新し、週次の更新 cadence が示されています。(Microsoft Learn)
| チャネル | 向いている環境 | 注意点 |
|---|---|---|
None | 完全に手動管理したい環境 | セキュリティ更新の責任が運用側に残る |
Unmanaged | OS側の仕組みに任せる環境 | Windowsでは自動適用にならない点に注意 |
SecurityPatch | セキュリティパッチを早めに適用したいLinux環境 | Windowsノードプールでは非対応 |
NodeImage | バグ修正込みでノードイメージを定期更新したい環境 | ノード再イメージ化による影響を考慮する |
既存クラスターに設定する場合は、次のように指定できます。
az aks update \
--resource-group <resource-group-name> \
--name <cluster-name> \
--node-os-upgrade-channel SecurityPatchただし、SecurityPatchやNodeImageを有効にしていても、Ubuntu 22.04からUbuntu 24.04のようなOSメジャーバージョン移行を自動で完全に解決してくれるわけではありません。廃止期限があるOSを利用している場合は、OS SKUとKubernetesバージョンの移行計画を別途作成してください。
メンテナンスウィンドウは「設定すれば有効」ではない
AKSのplanned maintenanceは、クラスターやノードOSの更新タイミングを業務影響の少ない時間帯に寄せるための機能です。公式情報では、aksManagedAutoUpgradeScheduleはクラスター自動アップグレード、aksManagedNodeOSUpgradeScheduleはノードOSセキュリティパッチのスケジュール制御に使うと説明されています。(Microsoft Learn)
注意したいのは、planned maintenanceは自動アップグレードを有効化・無効化する機能ではない点です。あくまで、すでに設定されている自動アップグレードやメンテナンスの実行タイミングを調整する機能です。また、緊急性の高いメンテナンスは、指定した期間外に実行される可能性もあります。(Microsoft Learn)
運用設計では、次のように分けて考えると整理しやすくなります。
| 目的 | 使う設定 |
|---|---|
| Kubernetesバージョンの自動アップグレード時刻を制御 | aksManagedAutoUpgradeSchedule |
| ノードOSセキュリティパッチの時刻を制御 | aksManagedNodeOSUpgradeSchedule |
| AKSの週次リリースやアドオン更新の時刻を制御 | default maintenance configuration |
本番環境では、少なくとも4時間以上のメンテナンスウィンドウを確保し、業務ピーク、バッチ時間帯、バックアップ時間帯、リリース作業時間帯と重ならないように設計しましょう。
管理者・開発者が今すぐやるべきチェックリスト
AKSのOSアップグレード対応は、インフラ管理者だけで完結しません。ノードOSが変わると、アプリケーション、監視、セキュリティ、CI/CD、コンテナイメージの互換性にも影響します。
| 担当 | 確認すること |
|---|---|
| AKS管理者 | 全ノードプールのosSku、Kubernetesバージョン、ノードイメージを一覧化する |
| AKS管理者 | Ubuntu 20.04、Ubuntu 22.04、Azure Linux 2.0の利用有無を確認する |
| AKS管理者 | nodeOsUpgradeChannelとplanned maintenanceを確認する |
| インフラ担当 | サブネットIP、VMクォータ、max surge、可用性ゾーンを確認する |
| 開発者 | アプリのPod再作成、終了処理、Readiness Probe、Liveness Probeを確認する |
| 開発者 | containerd 2.0やOS変更による挙動差がないか検証する |
| SRE/運用担当 | PDB、レプリカ数、監視アラート、ログ収集を確認する |
| セキュリティ担当 | FIPS、CVM、セキュリティエージェント、脆弱性管理方針を確認する |
最初の一歩としては、全ノードプールを一覧化し、次の3分類に分けるのがおすすめです。
- すぐ移行が必要：Azure Linux 2.0、Ubuntu 20.04、期限が迫るOSを利用
- 計画移行が必要：Ubuntu 22.04、
Ubuntu2204固定、古いWindowsノード - 継続監視：
UbuntuやAzureLinuxなど既定OS SKUを利用し、アップグレード方針が明確
移行時に失敗しやすいポイント
AKSのOSアップグレードで失敗しやすいのは、コマンドそのものよりも、事前設計の不足です。
互換性確認を本番ノードプールで初めて行う
Ubuntu 24.04やAzure Linux 3.0に変えると、ホストOS、カーネル、containerd、システムライブラリ、セキュリティ設定の差分が出る可能性があります。特に、DaemonSet、CSI、CNI、監視、セキュリティ、GPU関連コンポーネントは事前検証が必要です。
本番環境でいきなり全ノードプールを更新するのではなく、まず非本番クラスターまたは小さな検証用ノードプールで動作を確認してください。
PDBが厳しすぎてノードをdrainできない
PDBは可用性を守るための重要な設定ですが、設定が厳しすぎるとアップグレード時にPodを退避できません。minAvailableやmaxUnavailableを見直し、レプリカ数とセットで検証することが重要です。
サブネットIPやVMクォータを見落とす
maxSurgeを使うと、アップグレード中に追加ノードが作成されます。ノード数、Pod数、maxPods、サブネットサイズ、VMクォータに余裕がないと、アップグレードが途中で失敗することがあります。大規模クラスターやAzure CNIを使う環境では、IP不足を特に注意してください。
バージョン付きOS SKUを恒久設定にしてしまう
Ubuntu2404やAzureLinux3は、検証や段階移行に便利です。しかし、将来のOSアップグレードをAKSの既定に追従させたい場合は、最終的にUbuntuやAzureLinuxのような既定OS SKUへ戻す方針も検討してください。
AKS OSアップグレードの実務的な進め方
AKSのOSアップグレードは、次の順序で進めると安全です。
| フェーズ | 作業 | 完了条件 |
|---|---|---|
| 棚卸し | ノードプールのosSku、Kubernetes、node imageを確認 | 影響対象ノードプールが一覧化されている |
| 方針決定 | 既定OS SKUに寄せるか、バージョン付きOS SKUで段階移行するか決める | ノードプールごとの移行先が決まっている |
| 検証 | 非本番環境でOS SKU更新または新ノードプール移行を試す | アプリ、監視、ログ、セキュリティが正常 |
| 運用準備 | PDB、max surge、メンテナンスウィンドウ、クォータを調整 | ノード入れ替え時の停止リスクが抑えられている |
| 段階展開 | 低リスクなノードプールから移行 | 監視上の異常がない |
| 本番展開 | 重要ノードプールを計画時間帯に移行 | 旧OSノードプールが残っていない |
| 後処理 | 不要な旧ノードプール、固定OS SKU、古い例外設定を整理 | 次回アップグレード時の負債が減っている |
移行後は、kubectl get nodes --show-labelsやAzure Portalでノードイメージバージョンを確認し、意図したOSイメージへ更新されているかを確認します。AKSの公式情報では、ノードラベルにkubernetes.azure.com/node-image-versionのような形でノードイメージバージョンが表示される例が示されています。(Microsoft Learn)
まとめ：AKSのOSアップグレードは「期限」「OS SKU」「展開設計」をセットで管理する
Azure Kubernetes ServiceのOSアップグレード対応では、Kubernetesバージョンだけでなく、ノードプールごとのOS SKUとOSライフサイクルを必ず確認する必要があります。
特に、Ubuntu 20.04、Ubuntu 22.04、Azure Linux 2.0を使っている場合は、セキュリティ更新の停止だけでなく、ノードイメージ削除、スケール不可、修復失敗といった運用リスクにつながります。UbuntuやAzureLinuxのような既定OS SKUを使うのか、Ubuntu2404やAzureLinux3のようなバージョン付きOS SKUで段階検証するのかを、ノードプール単位で判断してください。
次に取るべき行動は明確です。まず全AKSクラスターでノードプールのosSku、Kubernetesバージョン、node image、nodeOsUpgradeChannelを棚卸しします。そのうえで、期限が近いOSを使うノードプールから優先順位を付け、非本番環境で検証し、PDB・max surge・メンテナンスウィンドウを整えてから段階的に展開しましょう。
コメント