今回のAzure Kubernetes Service更新は、AI/Copilot機能の追加ではなく、AKS Automaticのsystem node pool運用をAzure側に寄せるGA更新です。結論から言うと、AKS Automaticでクラスタの中核コンポーネントを動かすsystem node poolについて、プロビジョニング、スケーリング、アップグレード、修復といった運用作業をAKSが管理するようになります。
管理者にとっては、system node poolのVMサイズ選定や余剰キャパシティ確保に割く時間を減らせる一方、既存クラスタのインプレース移行、kube-system周辺のカスタマイズ、Windowsノードや一部アドオンの利用には注意が必要です。MicrosoftのAzure Updatesでは、この更新が「Launched」、つまり本番利用を想定した一般提供として案内されています。(Microsoft Azure)
AKS AutomaticのManaged system node poolsとは
AKSのnode poolには、大きく分けて2つの役割があります。
| 種類 | 主な役割 | 代表的なワークロード |
|---|---|---|
| system node pool | クラスタの基本機能を支えるコンポーネントを動かす | CoreDNS、Metrics Server、KEDA、Konnectivity、Workload Identity関連コンポーネントなど |
| user node pool | 利用者のアプリケーションを動かす | Webアプリ、API、バッチ、ワーカー、ジョブなど |
従来のAKS運用では、system node poolも利用者側で管理する必要がありました。たとえば、VM SKU、ノード数、オートスケールの範囲、OS更新、可用性、システムコンポーネント分の空きリソースを考慮する必要があります。
今回GAとなったManaged system node pools in AKS Automaticでは、AKS Automaticがsystem node poolを管理します。新しいAKS Automaticクラスタでは既定で有効になり、AKS Automaticでのみ利用できる機能として位置付けられています。Microsoft Learnでは、system node poolのプロビジョニング、アップグレード、スケーリングをAKSが自動で処理し、system node pool用のコンピュートクォータ管理も利用者が追跡しなくてよいと説明されています。(Microsoft Learn)
重要なのは、これは「Kubernetes運用がすべて不要になる」という意味ではないことです。アプリケーションの設計、マニフェスト、ネットワーク、監視、セキュリティ、リリース管理は引き続き利用者側の責任です。変わるのは、主にクラスタ基盤を支えるsystem node poolの運用責任の一部です。
何が変わるのか
Managed system node poolsのGAで変わるポイントを、実務目線で整理すると次のようになります。
| 観点 | これまでの考え方 | Managed system node pools利用時 | 実務上の確認ポイント |
|---|---|---|---|
| system node poolの作成 | 管理者がVMサイズやノード数を設計 | AKS Automaticが管理 | IaCでsystem node poolを明示管理していないか確認 |
| スケーリング | 管理者がキャパシティを見積もる | AKSがsystem node poolを自動スケール | CoreDNSなどのための余剰ノード設計を見直す |
| パッチ・アップグレード | ノード更新計画が必要 | AKSがsystem node pool側を管理 | メンテナンス手順からsystem pool更新作業を分離 |
| コスト | system node poolのVMが利用者サブスクリプションに課金 | system node poolのVMは利用者サブスクリプションに課金されない | user node、監視、ネットワーク、ストレージ費用は別途確認 |
| ワークロード配置 | 設計によってはsystem nodeに影響が出る | 利用者ワークロードはmanaged system nodeに配置できない | nodeSelector、tolerations、カスタムスケジューラを確認 |
| 操作権限 | system nodeやsystem namespaceを操作できる余地がある | AKS管理領域への変更や対話的アクセスが制限される | kubectl exec、port-forward、kube-system変更に依存しない運用へ変更 |
特に大きいのは、system node poolのキャパシティ設計が管理者の作業から外れることです。CoreDNSやMetrics Serverなどの基盤コンポーネントが増えたときに、system poolの余裕を手作業で調整する運用は軽くなります。
一方で、自由度は下がります。Microsoft Learnでは、AKSが管理するsystem namespaceのリソース作成・更新・削除、managed system podへのexecやattach、managed system nodeの変更、利用者ワークロードのmanaged system nodeへの配置などが制限されると説明されています。(Microsoft Learn)
影響を受ける環境と受けにくい環境
この更新の影響は、すべてのAKSクラスタに同じように及ぶわけではありません。まず確認すべきなのは、対象がAKS Automaticかどうかです。
| 環境 | 影響度 | 確認すべきこと |
|---|---|---|
| 新規のAKS Automaticクラスタ | 高 | managed system node poolsが既定で有効になる前提で設計する |
| 既存のAKS Automaticクラスタ | 中〜高 | managed system node poolsなしのクラスタからの直接移行可否を確認する |
| AKS Standard、既存の通常AKSクラスタ | 低 | 今回の機能対象ではないが、将来のAKS Automatic採用可否を検討する |
| system node poolをIaCで細かく管理している環境 | 高 | Terraform、Bicep、ARMテンプレート、運用Runbookを見直す |
kube-systemやsystem nodeへの操作に依存する運用 | 高 | 制限に抵触しない運用手順へ変更する |
| Windowsノード、Istio、Dapr、Azure Machine Learning連携を使う環境 | 高 | 現時点の制限に該当しないか確認する |
新しいAKS Automaticクラスタでは、managed system node poolsとLocalDNSが既定で有効になります。また、AKS Automaticクラスタをmanaged system node poolsなしで作成することはできないとされています。(Microsoft Learn)
管理者が最初に確認すべき設定
AKS Automaticかどうかを確認する
まず、対象クラスタがAKS Automaticか確認します。既存環境を棚卸しする場合は、次のような観点で確認すると実務に落とし込みやすくなります。
az aks show \
--resource-group <resource-group-name> \
--name <cluster-name> \
--query "{sku:sku, kubernetesVersion:kubernetesVersion, hostedSystemProfile:hostedSystemProfile}" \
-o jsonmanaged system node poolsが有効なクラスタでは、hostedSystemProfileのenabledがtrueとして確認できます。Microsoft Learnの作成例でも、デプロイ後にhostedSystemProfile.enabledがtrueになることを確認する手順が示されています。(Microsoft Learn)
Azure CLIのバージョンを確認する
AKS Automaticの作成・確認には、Azure CLIのバージョン要件があります。Microsoft LearnではAzure CLI 2.86.0以降が必要とされています。運用端末、CI/CDエージェント、管理用コンテナイメージで古いAzure CLIを使っている場合は、先に更新してください。(Microsoft Learn)
az versionCI/CDでaz aks createやaz aks showを実行している場合、ローカルPCだけでなく、GitHub Actions、Azure DevOps、Self-hosted runner、踏み台サーバーのCLIバージョンも確認が必要です。
作成コマンドやIaCを見直す
AKS Automaticクラスタ作成では、--sku automaticを使います。ドキュメント例では、managed system node poolsを有効にする作成例として次のような形が示されています。(Microsoft Learn)
az aks create \
--resource-group <resource-group-name> \
--name <cluster-name> \
--sku automatic \
--enable-hosted-system \
--location <region>IaCでは、次のような記述が残っていないか確認します。
| 確認対象 | 見直す理由 |
|---|---|
| system node poolのVM SKU指定 | AKS Automatic側の管理と衝突する可能性がある |
| system node poolのmin/max count | system node poolのスケールを利用者が管理する前提が崩れる |
| node pool名を固定した監視・アラート | managed system node poolが通常のagent pool一覧に出ない場合がある |
kube-systemへの独自リソース配置 | AKS管理領域への変更制限に抵触する可能性がある |
| system node向けnodeSelector/tolerations | 利用者ワークロードをmanaged system nodeへ配置できない |
移行は「既存クラスタを変換」ではなく「新規作成して移す」で考える
既存のAKS Automaticクラスタを利用している場合、最も注意すべき点は移行です。Microsoft Learnでは、managed system node poolsを持たない既存のAutomaticクラスタがある場合、クラスタを再作成してワークロードを移行する必要があると説明されています。また、AKS Automaticクラスタ間で、managed system node poolsなしからありへの移行はサポートされていません。(Microsoft Learn)
つまり、実務ではブルーグリーン移行に近い考え方が安全です。
| フェーズ | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 棚卸し | Namespace、Deployment、Service、Ingress、Gateway、Secret、ConfigMap、PVC、Workload Identityを洗い出す | kube-systemに置いた独自設定を見落とす |
| 互換性確認 | Windows、Istio、Dapr、Azure ML、カスタム監視などの利用有無を確認 | 制限に該当してから作成後に気付く |
| 新クラスタ作成 | AKS Automaticで検証用クラスタを作る | リージョン、ネットワーク、DNS要件を後回しにする |
| マニフェスト検証 | kubectl apply --dry-run=serverなどでAdmission制約を確認 | privileged設定やhostPathがブロックされる |
| データ移行 | DB、Storage、Queue、外部依存の接続先を確認 | PVCだけを見て、外部DNSや証明書更新を忘れる |
| トラフィック切替 | DNS、Load Balancer、Gateway、Front Doorなどで段階的に切替 | 一気に切り替えてロールバック手順がない |
| 旧環境整理 | 旧クラスタを一定期間読み取り専用にし、ログを保全 | すぐ削除して障害調査に必要な情報を失う |
既存クラスタにアプリケーションを多数載せている場合、クラスタ移行を「Kubernetesマニフェストの再適用」だけで済ませるのは危険です。Workload Identity、証明書、Container Registryへのアクセス、Private DNS、監視設定、アラート通知先まで含めて移行対象にしてください。
制限事項と設計上の注意点
Managed system node poolsは運用負荷を下げる機能ですが、すべての構成で使えるわけではありません。現時点のMicrosoft Learnでは、AKS Automaticクラスタに関する制限として、Windowsノード、Istioベースのservice mesh add-on、Dapr、Azure Machine Learning、AKS base SKUとAutomatic SKU間の移行、カスタムPrometheusメトリック収集やログ収集などがサポート対象外として示されています。(Microsoft Learn)
| 項目 | 注意点 | 推奨アクション |
|---|---|---|
| Windowsノード | サポート対象外 | Windowsコンテナが必要な場合は別クラスタ構成を検討 |
| Istio-based service mesh add-on | サポート対象外 | Istio前提の通信制御やmTLS設計を見直す |
| Dapr、Azure Machine Learning | サポート対象外の拡張として記載 | 導入済み環境では移行前に代替方式を検証 |
| AKS base SKUからAutomatic SKUへの移行 | サポート対象外 | 新規クラスタ作成とワークロード移行で計画 |
| Prometheus/ログのカスタム収集 | サポート対象外として記載 | Azure Monitor標準構成や対応可能な収集方式へ寄せる |
| ACNS observability | 作成時の有効化は不可、作成後の有効化は可能 | クラスタ作成手順と後続設定手順を分ける |
| node resource group | ロックダウンが事前構成される | MC_リソースグループを直接変更しない運用にする |
特にネットワークとDNSは、後から修正しにくい領域です。AKS Automaticではnode resource group lockdownが事前構成され、MC_リソースグループへの変更が制限されます。クロスVNetやカスタムDNSの要件がある場合は、クラスタ作成前にネットワーク設計を確定させるべきです。(Microsoft Learn)
開発者がデプロイ前に確認すべきポイント
開発者側で最も影響を受けるのは、Podの配置とセキュリティ制約です。Managed system node poolsでは、利用者ワークロードをAKS管理のsystem nodeに配置できません。これまでsystem node向けに広いtolerationsを付けていた、あるいは独自スケジューラでsystem nodeを対象にしていた場合は、デプロイに失敗する可能性があります。
確認すべきマニフェストの例は次の通りです。
kubectl get deploy,statefulset,daemonset -A -o yaml | grep -E "nodeSelector|tolerations|schedulerName|hostNetwork|hostPath|privileged"本番反映前には、サーバー側dry-runでAdmission制約を確認しておくと安全です。
kubectl apply --dry-run=server -f ./manifestsまた、DaemonSetにも注意が必要です。Microsoft Learnでは、DaemonSetはmanaged system node poolsと利用者サブスクリプション内のノードの両方で実行されると説明されています。ノード監視、ログ収集、セキュリティエージェントをDaemonSetで配布している場合、想定外のノードに展開されないか、あるいは必要なノードに展開されているかを検証してください。(Microsoft Learn)
Ingress利用環境はGateway APIへの移行も確認する
Managed system node poolsとは別軸ですが、AKS Automaticを新規作成する際に見落としやすい関連変更があります。
Microsoft Learnでは、AKS 1.36以降の新しいAKS Automaticクラスタでは、application routing add-onにおいてManaged NGINX ingressではなくKubernetes Gateway APIが既定で有効になると説明されています。既存のAutomaticクラスタは影響を受けないものの、Kubernetes Gateway APIへの移行を開始すべきとされています。(Microsoft Learn)
既存アプリでIngressを使っている場合は、次の点を確認してください。
| 確認項目 | 理由 |
|---|---|
| Ingressリソースの有無 | Gateway APIへ移す対象を把握するため |
| NGINX固有アノテーション | Gateway APIへそのまま移せない設定があるため |
| TLS証明書の管理方法 | Secret、Key Vault連携、証明書更新手順が変わる可能性があるため |
| WAF、Front Door、Application Gatewayとの接続 | L7入口の設計がクラスタ移行と同時に変わる可能性があるため |
| ヘルスチェックとReadiness Probe | ルーティング変更時の切替失敗を防ぐため |
クラスタ基盤を新しくするタイミングで、Ingress設定だけを旧方式のまま移すと、将来の移行作業が二重になります。新規AKS Automaticクラスタを作るなら、Gateway APIへの対応可否も同時に評価するのが現実的です。
採用に向いているケース、慎重に判断すべきケース
Managed system node poolsは、AKS Automaticの思想に合う環境では大きな効果があります。一方で、Kubernetes基盤を細かく制御したい組織には合わない場合があります。
| 判断 | 具体的なケース |
|---|---|
| 採用に向いている | 新規サービスでAKS Automaticを使いたい |
| 採用に向いている | system node poolのVMサイズ、ノード数、パッチ運用を標準化・省力化したい |
| 採用に向いている | プラットフォームチームが複数アプリチームへ安全な標準クラスタを提供したい |
| 採用に向いている | system workloadとuser workloadを明確に分離したい |
| 慎重に判断 | Windowsノードが必要 |
| 慎重に判断 | Istio、Dapr、Azure Machine Learningなどの対象外機能を使っている |
| 慎重に判断 | kube-systemやsystem nodeに独自エージェント、独自設定を入れている |
| 慎重に判断 | カスタムPrometheus収集や独自ログ収集を前提にしている |
| 慎重に判断 | 既存クラスタを停止せず、そのまま機能だけ有効化したい |
判断基準はシンプルです。クラスタ基盤の自由度より、標準化・自動化・運用負荷削減を優先したいなら採用候補になります。逆に、system node poolを細かくチューニングすること自体が運用要件になっている場合は、AKS Automaticではなく通常のAKS構成を含めて検討すべきです。
本番展開前のチェックリスト
本番導入前には、最低限次の項目を確認してください。
- [ ] 対象がAKS Automaticであり、通常のAKSクラスタと混同していない
- [ ]
hostedSystemProfile.enabledがtrueであることを確認した - [ ] Azure CLIが2.86.0以降である
- [ ] 利用リージョンがAKS Automaticの対応リージョンである
- [ ] Windowsノード、Istio、Dapr、Azure Machine Learningが要件に含まれていない
- [ ]
kube-systemやsystem nodeへの独自変更に依存していない - [ ] DaemonSet、nodeSelector、tolerations、custom schedulerを確認した
- [ ] Prometheus、ログ、Azure Monitorの収集方式を確認した
- [ ] IngressからGateway APIへの移行要否を確認した
- [ ] 既存クラスタから移行する場合、ブルーグリーン切替とロールバック手順を用意した
- [ ] Terraform、Bicep、ARMテンプレート、CI/CDパイプラインのsystem node pool前提を見直した
- [ ] コスト評価でuser node、監視、ネットワーク、ストレージ料金を別途確認した
まとめ：まずは既存運用の「system node pool依存」を棚卸しする
Managed system node pools in AKS AutomaticのGAは、AKS運用における地味だが重要な変更です。system node poolのプロビジョニング、スケーリング、アップグレード、修復をAKS Automaticに任せられるため、管理者はアプリケーション基盤全体の設計やリリース品質に集中しやすくなります。
一方で、既存クラスタをそのまま変換できる機能ではありません。既存のAKS Automaticクラスタを移行する場合は、新規クラスタを作成してワークロードを移す前提で計画する必要があります。また、system namespaceへの操作、managed system podへの対話的アクセス、system nodeへのワークロード配置などは制限されます。
次に取るべき行動は、既存環境の棚卸しです。まずhostedSystemProfile、IaC、DaemonSet、Ingress、監視設定、unsupported機能の有無を確認してください。そのうえで、新規AKS Automaticクラスタを検証環境に作成し、アプリケーションのデプロイ、ネットワーク、監視、切り替え手順まで通して確認するのが安全な進め方です。
コメント