AKS クラスターの自動アップグレードは、「Kubernetes のバージョンをいつ、どこまで自動で上げるか」を決める重要な運用設定です。2026年7月時点の公式情報では、AKS Automatic は stable チャネルが事前構成され、AKS Standard では patch、stable、rapid、none などから運用要件に合わせて選ぶ形が整理されています。特に管理者が確認すべきなのは、AKS Automatic と AKS Standard で設定できる範囲が違うこと、node-image クラスター自動アップグレードチャネルはレガシー扱いであること、計画メンテナンス期間を4時間以上確保することです。(Microsoft Learn)
本記事では、Azure Kubernetes Service（AKS）の「Automatically Upgrade an Azure Kubernetes Service (AKS) Cluster」の更新ポイントを、影響範囲、設定変更、移行期限の考え方、管理者が確認すべき実務ポイントに分けて解説します。
Azure の AKS 自動アップグレードで押さえるべき結論
AKS の自動アップグレードは、クラスターを最新のサポート範囲に保つための仕組みです。手動アップグレードと同じプロセスで実行されますが、選択した自動アップグレードチャネルによって、適用される Kubernetes バージョンとタイミングが変わります。Microsoft Learn では、自動アップグレードはまずコントロールプレーンをアップグレードし、その後にエージェントプールを順番にアップグレードすると説明されています。(Microsoft Learn)
今回の公式情報で実務上重要なのは、次の4点です。
| 確認ポイント | 管理者が見るべきこと |
|---|---|
| AKS Automatic | stable チャネルが既定で事前構成され、基本的にチャネル変更は不要 |
| AKS Standard | patch、stable、rapid、none から選択し、保守方針に合わせて設定 |
| メンテナンス期間 | 自動アップグレードを使う場合は、4時間以上の計画メンテナンス期間を確保 |
| ノードイメージ | クラスター自動アップグレードの node-image はレガシー扱い。ノード OS 更新は別途 NodeImage などを確認 |
特に本番環境では、「自動アップグレードを有効にするかどうか」だけでなく、「どのチャネルを選び、どの時間帯に実行させ、PDB やサブネット容量がアップグレードに耐えられるか」まで確認する必要があります。
AKS 自動アップグレードとは何か
AKS 自動アップグレードは、Azure Kubernetes Service のクラスターをサポート対象の Kubernetes バージョンに保つための機能です。AKS では最新機能やセキュリティ更新を取り込むために、定期的な Kubernetes バージョン更新が必要になります。自動アップグレードを設定すると、管理者が毎回手動で az aks upgrade を実行しなくても、指定したチャネルに基づいてアップグレードが行われます。(Microsoft Learn)
ただし、自動アップグレードは「何も考えなくてよい機能」ではありません。アップグレード時にはノードのドレイン、Pod の再スケジュール、サージノードの作成、IP アドレスの消費、PodDisruptionBudget（PDB）の影響が発生します。業務システムを載せている AKS では、アプリケーション側の可用性設計とセットで検討する必要があります。
AKS Automatic と AKS Standard の違い
今回の公式情報では、AKS Automatic と AKS Standard の違いがより明確に整理されています。AKS Automatic は、運用負荷を減らすことを目的とした構成で、クラスター自動アップグレードは stable チャネルを使うように事前構成されています。一方、AKS Standard は、アップグレードチャネルやスケジュールを管理者が選択します。(Microsoft Learn)
| 項目 | AKS Automatic | AKS Standard |
|---|---|---|
| 既定の考え方 | 本番向けの既定構成を Azure 側で管理 | 管理者がアップグレード方針を選択 |
| クラスター自動アップグレード | stable が事前構成 | チャネルを手動選択 |
| チャネル変更 | 原則として固定 | patch、stable、rapid、none などを選択 |
| メンテナンス期間 | 必要に応じて設定 | 強く推奨 |
| 向いている環境 | 標準的な本番ワークロード | 厳密な変更管理、特殊なノード構成、段階的検証が必要な環境 |
実務では、新規構築で特別なネットワーク要件やノードプール制御がない場合は AKS Automatic が候補になります。既存の標準 AKS クラスターで細かいメンテナンス制御、GPU ノード、Windows ノード、独自のアップグレード手順がある場合は AKS Standard のまま、チャネルと計画メンテナンスを見直すのが現実的です。
自動アップグレードチャネルの選び方
AKS Standard では、自動アップグレードチャネルの選択が運用方針に直結します。公式情報で整理されている主なチャネルは以下のとおりです。(Microsoft Learn)
| チャネル | 動作 | 向いている環境 |
|---|---|---|
none | 自動アップグレードを無効化し、現在の Kubernetes バージョンを維持 | 変更を完全に手動管理したい検証環境。ただし放置は危険 |
patch | 現在のマイナーバージョンを維持し、最新のサポート対象パッチへ更新 | 本番環境で影響を抑えつつ、セキュリティパッチを取り込みたい場合 |
stable | 最新サポート対象マイナーバージョンの1つ前、つまり N-1 の最新パッチへ更新 | 安定性と追随性のバランスを取りたい標準的な本番環境 |
rapid | 最新サポート対象マイナーバージョンの最新パッチへ更新 | 新機能追随を優先する開発・検証環境、または短い周期で検証できる組織 |
node-image | ノードイメージ更新用の旧チャネル | レガシー扱い。新規利用は避け、ノード OS 自動アップグレードの NodeImage を検討 |
本番環境では、まず patch か stable を検討するのが現実的です。patch はマイナーバージョンを維持するため影響範囲を読みやすく、stable はサポート範囲に残りやすいという利点があります。rapid は便利ですが、アドオンやアプリケーションの Kubernetes API 互換性を継続的に検証できる体制がない場合、想定外の修正作業が増える可能性があります。
影響範囲：何が自動で変更されるのか
AKS 自動アップグレードを有効にすると、コントロールプレーンだけでなくノードプールもアップグレード対象になります。公式情報では、クラスター自動アップグレードを使っている場合、コントロールプレーンだけを先に上げてノードプールを後から個別に上げる運用はできないとされています。az aks upgrade --control-plane-only のような制御は、自動アップグレード構成とは相性がよくありません。(Microsoft Learn)
影響を受ける主な領域は次のとおりです。
| 領域 | 影響 |
|---|---|
| コントロールプレーン | Kubernetes API サーバーなどの管理面がアップグレードされる |
| ノードプール | エージェントプールが順番にアップグレードされる |
| ノードイメージ | 手動・自動にかかわらず、アップグレード時に最新でなければ更新される場合がある |
| ワークロード | ノードドレインにより Pod の退避・再配置が発生する |
| ネットワーク | サージノード利用時に追加 IP が必要になる |
| 運用監視 | Activity Log、Event Grid、アプリケーション監視でアップグレード状態を確認する必要がある |
つまり、AKS 自動アップグレードはインフラ担当だけで完結する設定ではありません。アプリケーション担当、SRE、セキュリティ担当が、PDB、レプリカ数、メンテナンス通知、障害時の切り戻し方針を事前にそろえる必要があります。
設定変更で確認すべき Azure CLI とポータル操作
AKS Standard の新規クラスターで自動アップグレードを設定する場合は、az aks create に --auto-upgrade-channel を指定します。既存クラスターでは az aks update を使います。公式情報では、AKS Automatic の場合は stable が事前構成されているため、これらの手順は AKS Standard 向けと整理されています。(Microsoft Learn)
新規クラスターで stable を指定する例です。
az aks create \
--resource-group <resource-group-name> \
--name <cluster-name> \
--auto-upgrade-channel stable \
--generate-ssh-keys既存クラスターで stable に変更する例です。
az aks update \
--resource-group <resource-group-name> \
--name <cluster-name> \
--auto-upgrade-channel stable現在の設定を確認する場合は、次のように autoUpgradeProfile を確認します。
az aks show \
--resource-group <resource-group-name> \
--name <cluster-name> \
--query autoUpgradeProfileポータルでは、AKS クラスターの「Upgrades」または「Cluster configuration」から、Kubernetes バージョンのアップグレード画面に進み、自動アップグレードのドロップダウンを確認します。画面名称はポータル更新で変わることがあるため、運用手順書にはスクリーンショットだけでなく、CLI での確認コマンドも併記しておくと安全です。
計画メンテナンスは4時間以上を確保する
自動アップグレードを本番環境で使う場合、計画メンテナンスの設定はほぼ必須です。Microsoft Learn では、自動アップグレードを正しく機能させるため、4時間以上のメンテナンス期間を使うことが推奨されています。(Microsoft Learn)
計画メンテナンスの例です。
az aks maintenanceconfiguration add \
--resource-group <resource-group-name> \
--cluster-name <cluster-name> \
--name aksManagedAutoUpgradeSchedule \
--schedule-type Weekly \
--day-of-week Sunday \
--interval-weeks 1 \
--duration 4 \
--utc-offset +09:00 \
--start-time 02:00日本向けの運用では、utc-offset +09:00 を明示し、日曜日の深夜や早朝など、業務影響が小さい時間帯に設定するケースが多いでしょう。ただし、グローバルサービスでは日本時間だけを基準にすると、海外拠点のピーク時間に重なることがあります。グローバル向けに運用する場合は、リージョン別・利用国別にトラフィックの少ない時間を確認してから設定してください。
ノード OS 自動アップグレードとの違いに注意する
AKS 管理者が混同しやすいのが、クラスター自動アップグレードとノード OS 自動アップグレードです。
クラスター自動アップグレードは Kubernetes のバージョン管理に関わります。一方、ノード OS 自動アップグレードは、ノードイメージや OS セキュリティ更新を管理する仕組みです。公式情報では、AKS Automatic のノード OS 更新は NodeImage チャネルが事前構成され、週次のセキュリティ修正とバグ修正を適用する形で整理されています。(Microsoft Learn)
| 種類 | 主な対象 | 代表的な設定 |
|---|---|---|
| クラスター自動アップグレード | Kubernetes コントロールプレーン、ノードプールの Kubernetes バージョン | --auto-upgrade-channel stable |
| ノード OS 自動アップグレード | ノード OS イメージ、セキュリティ修正、バグ修正 | --node-os-upgrade-channel NodeImage または SecurityPatch |
| 手動ノードイメージ更新 | 特定ノードプールのイメージ更新 | az aks nodepool upgrade --node-image-only |
node-image という名前のクラスター自動アップグレードチャネルは、現在はレガシー扱いで、今後の非推奨化が予定されていると説明されています。ノードイメージを自動更新したい場合は、クラスター自動アップグレードの node-image ではなく、ノード OS 自動アップグレード側の NodeImage チャネルを確認するのが基本です。(Microsoft Learn)
移行期限はどう考えるべきか
今回の「Automatically Upgrade an AKS Cluster」自体に、すべての利用者へ一律に適用される移行期限が示されているわけではありません。ただし、実務上の期限管理は必要です。
AKS はサポート対象の Kubernetes マイナーバージョンを N、N-1、N-2 の範囲で扱い、N-3 は限定的なプラットフォームサポートとして扱われます。サポート範囲から外れると、Kubernetes コンポーネントやセキュリティパッチの観点でリスクが高まります。(Microsoft Learn)
管理者は、次のように期限を置くと運用しやすくなります。
| 状態 | 推奨アクション |
|---|---|
| 現在のクラスターが N または N-1 | patch または stable を使い、計画メンテナンス内で更新 |
| 現在のクラスターが N-2 | 次のマイナーバージョン公開前に stable か手動アップグレードを計画 |
| 現在のクラスターが N-3 | 早急に N-2 以上へアップグレード。検証環境で互換性確認を優先 |
node-image チャネルを利用 | ノード OS 自動アップグレードの NodeImage へ設計を見直す |
| Azure Linux 2.0 ノードを利用 | ノード OS のサポート状況を別途確認し、サポート対象 OS へ移行計画を作成 |
特にグローバル環境では、リージョンごとに新バージョンの展開タイミングがずれる場合があります。AKS の新バージョンやノードイメージ更新は段階的にロールアウトされるため、全リージョンで同時に選択できるとは限りません。アップグレード計画では、対象リージョンごとに利用可能バージョンを確認してください。(Microsoft Learn)
本番環境で失敗しやすいポイント
AKS 自動アップグレードでよくある失敗は、チャネル選択そのものよりも、アップグレード時に必要な周辺条件を見落とすことです。
PDB が厳しすぎて Pod を退避できない
PodDisruptionBudget の maxUnavailable=0 や、レプリカ数が1の重要 Pod が多い環境では、ノードドレインが失敗する可能性があります。AKS のアップグレードではノードから Pod を退避するため、PDB とレプリカ数の整合性が重要です。公式のアップグレード推奨でも、PDB やレプリカ数の検証が重要な項目として挙げられています。(Microsoft Learn)
確認例です。
kubectl get pdb -A
kubectl get deploy,statefulset -A本番環境では、少なくとも重要アプリケーションについて、アップグレード中に1 Pod 落ちてもサービス継続できる構成にしておくべきです。
サージノード用のクォータや IP が足りない
AKS のアップグレードでは、ノードを追加してから既存ノードを置き換える「サージ」が使われることがあります。サブネットの IP が不足していたり、VM クォータが足りなかったりすると、アップグレードが途中で止まる可能性があります。Microsoft Learn では、サージノード、PDB、メンテナンス期間、ドレインタイムアウトなどを組み合わせて、低停止のアップグレードを設計することが推奨されています。(Microsoft Learn)
確認例です。
az aks show \
--resource-group <resource-group-name> \
--name <cluster-name> \
--query "agentPoolProfiles[].{name:name,count:count,maxPods:maxPods,vnetSubnetId:vnetSubnetId}"大規模クラスターや Azure CNI を使う環境では、アップグレード時の追加 IP を見込んだサブネット設計が必要です。
自動アップグレードの変更がすぐ反映されると思い込む
自動アップグレードチャネルの変更は、反映までに時間がかかる場合があります。公式情報では、自動アップグレード設定を変更した場合、反映まで24時間を見込むよう説明されています。(Microsoft Learn)
そのため、メンテナンス当日に急いでチャネルを変更するのは避けるべきです。少なくとも前日までに設定を確定し、az aks show で反映状態を確認しておくと安全です。
管理者向けの確認チェックリスト
AKS 自動アップグレードを使う前に、次の項目を確認してください。
| 確認項目 | コマンドまたは確認方法 | 判断基準 |
|---|---|---|
| 現在の Kubernetes バージョン | az aks show --query currentKubernetesVersion | N、N-1、N-2 の範囲にあるか |
| 自動アップグレードチャネル | az aks show --query autoUpgradeProfile | patch、stable、rapid、none のどれかを把握 |
| 計画メンテナンス | az aks maintenanceconfiguration list | 4時間以上、低トラフィック時間帯に設定 |
| PDB | kubectl get pdb -A | Pod 退避を完全にブロックしていないか |
| サブネット容量 | Azure Portal または VNet 設計情報 | サージノードと Pod 用 IP に余裕があるか |
| ノード OS 更新 | az aks show --query autoUpgradeProfile.nodeOsUpgradeChannel | NodeImage や SecurityPatch の方針が決まっているか |
| 監視 | Activity Log、Event Grid、Azure Monitor | アップグレード開始・失敗を検知できるか |
このチェックリストは、変更管理の承認資料にもそのまま使えます。特に金融、自治体、医療、製造業など停止影響が大きい環境では、「自動だから安全」と説明するのではなく、「自動実行される範囲と停止リスクを制御している」と説明できる状態にしておくことが重要です。
推奨される運用パターン
AKS 自動アップグレードのおすすめ構成は、環境によって変わります。
| 環境 | 推奨方針 |
|---|---|
| 開発環境 | rapid または stable で早めに互換性問題を検出 |
| 検証環境 | 本番と同じ patch または stable を先行適用 |
| 一般的な本番環境 | stable と計画メンテナンスを組み合わせる |
| 変更管理が厳しい本番環境 | patch を基本にし、マイナー更新は手動承認で実施 |
| 複数リージョンのグローバル環境 | リージョンごとに段階適用し、監視結果を見て次へ進める |
| ノード OS 更新を重視 | クラスター自動アップグレードとは別に NodeImage または SecurityPatch を設計 |
重要なのは、開発・検証・本番で同じタイミングにしないことです。検証環境を先にアップグレードし、API 非推奨、アドオン互換性、Ingress、CSI ドライバー、監視エージェントの動作を確認してから本番へ進めると、障害リスクを下げられます。
まとめ：まず現在のチャネルとメンテナンス期間を確認する
AKS の「Automatically Upgrade an Azure Kubernetes Service (AKS) Cluster」で管理者が最初に行うべきことは、現在のクラスターが AKS Automatic なのか AKS Standard なのか、自動アップグレードチャネルが何に設定されているのか、計画メンテナンスが4時間以上確保されているのかを確認することです。
AKS Automatic では stable が事前構成されているため、主な確認対象はメンテナンス期間とワークロードの耐障害性です。AKS Standard では、patch、stable、rapid、none の選択が運用リスクに直結します。レガシー扱いの node-image を使っている場合は、ノード OS 自動アップグレードの NodeImage へ設計を見直しましょう。
次に取るべき行動は明確です。まず az aks show で現在の autoUpgradeProfile を確認し、計画メンテナンス、PDB、サブネット容量、ノード OS 更新方針を棚卸ししてください。そのうえで、本番環境では patch または stable を軸に、検証環境で先行確認してから段階的に適用する運用に整えるのが安全です。
コメント