AKSでWindows ServerコンテナーをAzure CLI展開する手順と2026年版の注意点

Azure Kubernetes Service（AKS）で Windows Server コンテナーを動かす場合、最初に確認すべき答えは明確です。新規検証では Azure CLI 2.87.0 以上を使い、AKS クラスター作成時に Azure CNI を指定し、Linux ノードプールとは別に Windows ノードプールを追加します。既存環境では、Windows Server 2019 / 2022 ノードプールのサポート期限と Kubernetes バージョンの組み合わせを必ず確認してください。

Microsoft Learn の「Azure CLI を使用して AKS クラスター上に Windows Server コンテナーをデプロイする」ページは、2026年6月3日に日本語版が更新されています。内容はクイックスタートですが、実務上は単なる手順確認にとどまりません。Windows Server 2019 のサポート終了、Windows Server 2022 の将来の提供終了、Windows Server 2025 のプレビュー扱い、ノードプール移行時の制約など、管理者と開発者が見落とすと展開・スケーリング・移行でつまずくポイントが含まれています。(Microsoft Learn)

この記事では、AKS に Windows Server コンテナーを Azure CLI でデプロイする流れを整理しながら、変更点、影響範囲、確認すべき設定、移行時の注意点を実務目線で解説します。

まず確認すべき重要ポイント

確認項目	要点	実務での判断
Azure CLI	2.87.0 以上が必要	Cloud Shell を使うか、ローカル CLI は az version と az upgrade で確認
ネットワーク	Windows Server コンテナー対応には Azure CNI が必要	az aks create 時に --network-plugin azure を指定
ノードプール	AKS クラスター作成時の既定ノードプールは Linux	Windows コンテナー用に Windows ノードプールを別途追加する
OS SKU	Windows2022、Windows2025 などを指定	Kubernetes バージョンとサポート期限を見て選ぶ
Windows Server 2019	2026年3月1日以降、AKS でサポート対象外	既存環境は移行計画が必須
Windows Server 2022	Kubernetes 1.25〜1.35 の既定。1.36 以降では使用不可	新規採用時も将来の Windows2025 移行を前提にする
Windows Server 2025	Kubernetes 1.32 以降でサポート、現時点ではプレビュー	本番採用は組織のプレビュー利用方針に従う
移行方法	既存ノードプールの OS を直接更新する方式ではない	新しい OS のノードプールを作り、Pod 配置とイメージを切り替える

公式クイックスタートの位置づけ

今回の Microsoft Learn の公式情報は、Azure CLI を使って AKS クラスターを作成し、Windows Server コンテナー上で ASP.NET サンプルアプリを動かすクイックスタートです。AKS は Kubernetes クラスターのデプロイと管理を行うマネージドサービスで、この手順では Windows Server コンテナーを実行できる AKS クラスターと、サンプルアプリのデプロイまでを扱います。(Microsoft Learn)

ただし、公式ページでも明記されている通り、ここで示されるクラスターは評価目的の既定設定です。本番環境にそのまま流用するのではなく、ネットワーク、ID、監視、セキュリティ、可用性、アップグレード運用を設計したうえで展開する必要があります。(Microsoft Learn)

特に注意したいのは、Windows コンテナーのデプロイ手順そのものよりも、Windows ノードプールの OS SKU と Kubernetes バージョンの組み合わせです。ここを誤ると、将来の Kubernetes アップグレード時にノードプールが使えなくなったり、スケールアウトが失敗したりする可能性があります。

AKS の Windows Server コンテナーで何が変わるのか

Windows Server 2019 ノードプールはすでにサポート終了フェーズ

公式情報では、2026年3月1日以降、AKS は Windows Server 2019 ノードプールをサポートしないと案内されています。また、Kubernetes 1.33 以降のノードプールでは Windows Server 2019 を使用できません。さらに、2027年4月1日からは Windows Server 2019 の既存ノードイメージが削除され、スケーリング操作が失敗する可能性があるとされています。(Microsoft Learn)

これは、単に「古い OS だから推奨されない」という話ではありません。スケールアウト、再イメージ、再デプロイ、障害復旧などの運用操作に直接影響します。まだ Windows Server 2019 ベースの Windows ノードプールを使っている場合は、アプリケーションの改修有無にかかわらず、移行計画を立てる必要があります。

Windows Server 2022 も永続的な既定値ではない

Windows Server 2022 は Kubernetes 1.25〜1.35 の既定 OS SKU ですが、Kubernetes 1.36 以降では使用できません。AKS では、2027年3月15日以降に Windows Server 2022 ノードプールをサポートしなくなり、2028年4月1日から既存の Windows Server 2022 ノードイメージが削除される予定です。(Microsoft Learn)

そのため、2026年時点で Windows2022 を選ぶことは自然な選択肢ですが、「次の移行先は Windows Server 2025 になる」という前提で、Dockerfile、CI/CD、検証環境、ノードセレクターの管理方法を整えておくべきです。

Windows Server 2025 は選択肢に入ったが、プレビュー扱い

公式表では、Windows2025 は Kubernetes 1.32 以降で利用でき、containerd 2.0 と Generation 2 イメージが既定になると説明されています。ただし、現時点ではプレビューであり、既定値ではありません。(Microsoft Learn)

本番環境で採用する場合は、組織のプレビュー機能利用ルール、サポート方針、利用中のミドルウェアや Windows コンテナーイメージの互換性を確認してください。特に古い .NET Framework アプリケーションや、Windows 固有の依存関係を持つアプリでは、OS イメージの変更だけで動作が変わることがあります。

Azure CLI で Windows Server コンテナーを AKS にデプロイする基本手順

ここでは公式手順の流れを、管理者が確認しやすい形に整理します。コマンド例は検証用の最小構成です。本番環境では、命名規則、タグ、ネットワーク、監視、ID、シークレット管理を組織標準に合わせて調整してください。

事前準備を確認する

Azure CLI をローカルで実行する場合は、まずバージョンを確認します。

az version

古い場合はアップグレードします。

az upgrade

公式情報では Azure CLI 2.87.0 以上が必要です。Azure Cloud Shell を使う場合は、通常は最新の Azure CLI が用意されています。(Microsoft Learn)

複数サブスクリプションを使っている場合は、作業対象を明示します。

az account list --output table
az account set --subscription "<subscription-id>"

ここでの確認を省くと、検証用クラスターを意図しないサブスクリプションに作成してしまうことがあります。特に企業環境では、課金先、ポリシー、リージョン制限が異なるため注意が必要です。

リソースグループを作成する

検証用にランダムなサフィックスを付けてリソース名の重複を避けます。

export RANDOM_SUFFIX=$(openssl rand -hex 3)
export REGION="canadacentral"
export MY_RESOURCE_GROUP_NAME="myAKSResourceGroup$RANDOM_SUFFIX"

az group create \
  --name $MY_RESOURCE_GROUP_NAME \
  --location $REGION

リージョンは自社の利用可能リージョン、データ所在地、AKS の機能提供状況に合わせて選びます。検証では近いリージョンを選びがちですが、本番ではリージョン障害時の設計、Azure Policy、ネットワーク接続、監査要件を優先してください。

AKS クラスターを作成する

Windows Server ノード用の管理者ユーザー名とパスワードを用意します。公式手順では、Windows Server のパスワード要件を満たす必要があると説明されています。特にパスワードは 14 文字以上で複雑性要件を満たす必要があります。(Microsoft Learn)

export WINDOWS_USERNAME="winadmin"
export WINDOWS_PASSWORD=$(echo "P@ssw0rd$(openssl rand -base64 10 | tr -dc 'A-Za-z0-9!@#$%^&*()' | cut -c1-6)")
export MY_AKS_CLUSTER="myAKSCluster$RANDOM_SUFFIX"

AKS クラスターを作成します。

az aks create \
  --resource-group $MY_RESOURCE_GROUP_NAME \
  --name $MY_AKS_CLUSTER \
  --node-count 2 \
  --enable-addons monitoring \
  --generate-ssh-keys \
  --windows-admin-username $WINDOWS_USERNAME \
  --windows-admin-password $WINDOWS_PASSWORD \
  --vm-set-type VirtualMachineScaleSets \
  --network-plugin azure

ここで重要なのは --network-plugin azure です。Windows Server コンテナー用のノードプールをサポートする AKS クラスターでは Azure CNI を使う必要があり、公式手順でもこのパラメーターが指定されています。(Microsoft Learn)

また、管理者ユーザー名は後から変更できません。パスワードは az aks update で変更可能ですが、運用環境では作成時点で命名規則と資格情報管理方法を決めておくべきです。(Microsoft Learn)

Windows ノードプールを追加する

AKS クラスターは既定で Linux コンテナーを実行できるノードプールを持ちます。Windows Server コンテナーを実行するには、Windows ノードプールを追加する必要があります。(Microsoft Learn)

az aks nodepool add \
  --resource-group $MY_RESOURCE_GROUP_NAME \
  --cluster-name $MY_AKS_CLUSTER \
  --os-type Windows \
  --os-sku Windows2022 \
  --name npwin \
  --node-count 1

検証では Windows2022 を指定する例が分かりやすいですが、既存環境や将来の本番設計では、次の基準で選びます。

OS SKU	使いどころ	注意点
Windows2019	既存互換性確認のみ	2026年3月1日以降 AKS でサポート対象外。新規採用は避ける
Windows2022	2026年時点の標準的な検証・移行先	Kubernetes 1.36 以降では使用不可。将来移行を前提にする
Windows2025	次期 OS への検証、将来移行の準備	Kubernetes 1.32 以降。現時点ではプレビューで既定値ではない

--os-sku を指定しない場合、AKS は Kubernetes バージョンに応じた既定 SKU を使います。意図しない OS SKU を避けるため、Windows ノードプールでは明示指定する運用をおすすめします。

kubectl でクラスターに接続する

資格情報を取得します。

az aks get-credentials \
  --resource-group $MY_RESOURCE_GROUP_NAME \
  --name $MY_AKS_CLUSTER

ノードの状態を確認します。

kubectl get nodes -o wide

確認すべき列は、少なくとも次の3つです。

確認項目	見る場所	判断
ノード状態	STATUS	すべて Ready になっているか
OS イメージ	OS-IMAGE	Windows ノードが想定した Windows Server になっているか
ランタイム	CONTAINER-RUNTIME	containerd:// で始まっているか

公式手順の例でも、Linux ノードと Windows Server 2022 Datacenter ノードが同じクラスター内に表示され、コンテナーランタイムが containerd:// として確認できます。(Microsoft Learn)

サンプルアプリを Windows ノードにデプロイする

Windows Server コンテナーを AKS に配置するには、マニフェストで Windows ノードにスケジュールされるように指定する必要があります。公式手順では、ASP.NET サンプルアプリのマニフェストに nodeSelector を定義し、kubernetes.io/os: windows を指定しています。(Microsoft Learn)

sample.yaml を作成します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample
  labels:
    app: sample
spec:
  replicas: 1
  template:
    metadata:
      name: sample
      labels:
        app: sample
    spec:
      nodeSelector:
        "kubernetes.io/os": windows
      containers:
      - name: sample
        image: mcr.microsoft.com/dotnet/framework/samples:aspnetapp
        resources:
          limits:
            cpu: 1
            memory: 800M
        ports:
          - containerPort: 80
  selector:
    matchLabels:
      app: sample
---
apiVersion: v1
kind: Service
metadata:
  name: sample
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 80
  selector:
    app: sample

デプロイします。

kubectl apply -f sample.yaml

Pod の状態を確認します。

kubectl get pods -o wide

STATUS が Running になり、Windows ノード上で起動していることを確認します。nodeSelector を入れ忘れると、想定外のノード選択やスケジューリング失敗の原因になります。Windows と Linux が混在する AKS クラスターでは、Pod をどの OS のノードに置くかをマニフェストで明示するのが基本です。

外部 IP でアプリケーションを確認する

サンプルでは Service の種類に LoadBalancer を使い、インターネットからアクセスできる外部 IP を割り当てます。公式手順では、外部 IP の割り当てに数分かかる場合があり、プロビジョニングには最大 10 分かかることがあると説明されています。(Microsoft Learn)

while true; do
  export EXTERNAL_IP=$(kubectl get service sample -o jsonpath="{.status.loadBalancer.ingress[0].ip}" 2>/dev/null)
  if [[ -n "$EXTERNAL_IP" && "$EXTERNAL_IP" != "<pending>" ]]; then
    kubectl get service sample
    break
  fi
  echo "Still waiting for external IP assignment..."
  sleep 5
done

EXTERNAL-IP が <pending> のままでも、すぐに失敗と判断しないでください。まずは数分待ちます。それでも割り当てられない場合は、リージョンのリソース制限、パブリック IP のクォータ、ロードバランサー関連のポリシー、サブネットやネットワーク制約を確認します。

本番環境では、検証用のようにアプリを直接 LoadBalancer で公開する構成が適切とは限りません。Ingress Controller、内部ロードバランサー、Private Link、WAF、ゼロトラストアクセスなど、組織の公開ルールに合わせて設計してください。

影響を受ける環境

今回の情報で特に確認が必要なのは、次のような環境です。

対象	影響
AKS で Windows Server 2019 ノードプールを使っている環境	サポート対象外。Kubernetes 1.33 以降では利用不可。将来スケーリング失敗のリスク
Windows Server 2022 ノードプールを新規採用する環境	Kubernetes 1.36 以降で利用不可になるため、将来移行を前提に設計が必要
Windows コンテナーイメージを自社ビルドしている開発チーム	Dockerfile の FROM、ベースイメージタグ、動作検証の見直しが必要
CI/CD で AKS に直接デプロイしているチーム	nodeSelector、イメージタグ、マニフェスト差し替え手順の確認が必要
gMSA や Managed Identity を使う Windows ワークロード	新しいノードプールに合わせて ID とアクセス権の再設定が必要
自動スケールや障害時再作成に依存する本番環境	古いノードイメージ削除後にスケーリングや再イメージが失敗する可能性

Linux ノードプールだけで構成された AKS クラスターは、Windows Server ノードプールの OS SKU 変更による直接影響は限定的です。ただし、同じ AKS クラスターで Linux と Windows を混在させている場合、Kubernetes のバージョンアップ計画は Windows 側の制約も含めて判断する必要があります。

既存 Windows ノードプールの移行で注意すべきこと

ノードプールの OS バージョンは直接更新ではなく新規作成で移行する

AKS の Windows ワークロードで OS バージョンを上げる場合、既存ノードプールをそのまま別の Windows Server バージョンへ更新する方式はサポートされていません。Microsoft Learn では、新しい OS バージョンのノードプールを作成し、Windows バージョンがノードプール内で一致するようにする必要があると説明されています。(Microsoft Learn)

実務では、次の順番で進めるのが安全です。

手順	作業	失敗しやすいポイント
現状把握	既存ノードプール、Kubernetes バージョン、OS イメージを確認	Kubernetes だけ見て OS SKU を見落とす
イメージ準備	Dockerfile の FROM を新 OS 向けに更新	古いベースイメージのまま動作確認してしまう
検証環境	新 OS の Windows ノードプールでテスト	本番と異なる権限・ネットワークで検証してしまう
マニフェスト更新	nodeSelector とコンテナーイメージを変更	Windows ノード指定だけで OS SKU 指定をしない
段階移行	Pod を新ノードプールへ移す	一括切替でロールバック手段が不足する
旧環境整理	旧ノードプールを縮退・削除	gMSA や Managed Identity の参照が残る

OS SKU まで指定して Pod の配置を制御する

単に Windows ノードへ配置するだけなら、次の指定で足ります。

nodeSelector:
  "kubernetes.io/os": windows

しかし、Windows Server 2022 から Windows Server 2025 へ移行するような場面では、Windows ノードであることに加えて、どの OS SKU のノードへ配置するかを制御した方が安全です。Microsoft Learn の移行手順では、OS SKU に合わせて次のような nodeSelector を使う方法が示されています。(Microsoft Learn)

nodeSelector:
  "kubernetes.azure.com/os-sku": "Windows2025"

Windows ノードプールが複数ある環境では、この指定を使わないと、意図しない Windows ノードに Pod が配置される可能性があります。段階移行中は特に、kubernetes.io/os だけでなく kubernetes.azure.com/os-sku の活用を検討してください。

Dockerfile の FROM を更新してから検証する

Windows コンテナーでは、ベースイメージの OS バージョンが重要です。Microsoft Learn の移行手順でも、事前準備として Dockerfile の FROM を新しい OS バージョンに更新し、コンテナーアプリが新 OS で動くことを検証するよう案内されています。(Microsoft Learn)

例として、古い Windows Server ベースのイメージを使っている場合は、次の観点で確認します。

確認対象	確認内容
ベースイメージ	servercore、nanoserver、.NET Framework イメージなどのタグ
アプリ依存関係	IIS、.NET Framework、COM、レジストリ、フォント、証明書
ビルドパイプライン	Dockerfile、イメージタグ、ACR への push 手順
実行時設定	環境変数、ボリューム、ポート、ヘルスチェック
セキュリティ	実行ユーザー、権限、脆弱性スキャン、署名済みイメージ

OS 移行では、マニフェストだけを変えても不十分です。アプリケーションイメージ、ノードプール、スケジューリング条件をセットで変更します。

gMSA と Managed Identity は新ノードプールで再確認する

Windows ワークロードで Group Managed Service Accounts（gMSA）を使っている場合、新しいノードプールに合わせて Managed Identity の構成を更新する必要があります。Microsoft Learn では、Managed Identity はノードプール単位で構成されるため、Pod が新しいノードプールに移る場合はアクセス設定の更新が必要だと説明されています。(Microsoft Learn)

これは gMSA に限りません。Key Vault、Azure SQL、Storage Account、Container Registry などに Managed Identity でアクセスしている場合も、新しいノードプールから同じリソースへアクセスできるかを確認してください。

移行後に「Pod は Running だがアプリだけ認証エラーになる」というケースは、ノードプール変更に伴う ID・権限の見落としで起きやすい問題です。

管理者が確認すべきチェックリスト

既存環境を持つ管理者は、まず棚卸しから始めます。

az aks nodepool list \
  --resource-group <resource-group> \
  --cluster-name <aks-cluster> \
  --output table

ノードの OS イメージも確認します。

kubectl get nodes -o wide

確認結果をもとに、次の項目を埋めてください。

確認項目	確認結果	判断
AKS クラスター名		対象環境を間違えていないか
Kubernetes バージョン		Windows OS SKU のサポート範囲内か
Windows ノードプール名		移行対象を特定できているか
OS SKU / OS イメージ		Windows2019 が残っていないか
ノード数		移行時の一時的な増加に対応できるか
利用リージョン		新ノードイメージや VM サイズが利用可能か
Managed Identity		新ノードプールで権限を再設定できるか
gMSA		Windows Pod の認証が継続できるか
自動アップグレード		ノードイメージ更新の運用方針があるか
監視		新旧ノードプールのメトリックとログを追えるか

AKS のノードイメージは継続的に更新されます。Microsoft Learn では、Windows ノードイメージは月次でリリースされ、古いノードイメージはセキュリティやスケーリング、ノード readiness の問題につながる可能性があるため、最新化と自動アップグレードの利用が推奨されています。(Microsoft Learn)

開発者が確認すべきチェックリスト

開発者側では、AKS の設定だけでなく、アプリケーションイメージとマニフェストの管理が重要です。

確認項目	見る場所	対応
ベースイメージ	Dockerfile の FROM	移行先 OS に合うタグへ更新
イメージタグ	CI/CD 設定	latest 依存を避け、検証済みタグを使う
nodeSelector	Kubernetes マニフェスト	Windows ノード、必要なら OS SKU を明示
リソース制限	resources.limits / requests	CPU・メモリ不足による不安定化を防ぐ
起動確認	kubectl get pods -o wide	期待する Windows ノードに配置されたか確認
ログ確認	kubectl logs	OS 変更後の例外や依存関係エラーを確認
ヘルスチェック	readiness / liveness probe	起動直後だけ成功する状態を避ける
ロールバック	旧イメージと旧マニフェスト	すぐ戻せる単位で変更する

特に Windows コンテナーでは、ベースイメージのサイズが大きくなりやすく、イメージ pull に時間がかかることがあります。ノード切り替え時に起動時間が延びる場合は、ACR のリージョン、イメージサイズ、不要なレイヤー、キャッシュ戦略も見直してください。

よくある失敗と対処法

失敗例	原因	対処
Windows Pod が起動しない	Windows ノードプールがない、または nodeSelector がない	az aks nodepool add とマニフェストを確認
EXTERNAL-IP が <pending> のまま	LoadBalancer の割り当て待ち、クォータ、ネットワーク制約	まず数分待ち、クォータとポリシーを確認
クラスター作成時にパスワードエラー	Windows Server の複雑性要件を満たしていない	14文字以上、複雑性要件を満たす値にする
Kubernetes アップグレード後に Windows ノードが使えない	OS SKU と Kubernetes バージョンの非互換	事前にサポート表を確認し、新 OS ノードプールへ移行
移行後に認証だけ失敗する	Managed Identity / gMSA の設定が旧ノードプール前提	新ノードプールに対する権限を再設定
スケールアウトが失敗する	古いノードイメージやサポート終了 OS に依存	ノードイメージ更新、自動アップグレード、OS 移行を実施
本番公開が想定外に外部公開される	検証用の LoadBalancer をそのまま使った	Ingress、内部 LB、WAF、Private Link など本番設計に変更

本番展開ではクイックスタートをそのまま使わない

公式クイックスタートは、Windows Server コンテナーを AKS で動かす最短手順を理解するには有用です。一方で、本番環境では次の設計が欠かせません。

領域	本番で検討すべきこと
ネットワーク	VNet 設計、サブネット分離、内部公開、Private DNS、Egress 制御
ID	Managed Identity、Workload Identity、RBAC、最小権限
セキュリティ	ACR のアクセス制御、イメージスキャン、シークレット管理、Pod Security
可用性	複数ノード、ゾーン、PodDisruptionBudget、ローリング更新
監視	Azure Monitor、Container insights、ログ、アラート
アップグレード	Kubernetes、ノードイメージ、Windows OS SKU の更新計画
コスト	Windows ノードの VM サイズ、常時稼働台数、スケール設定
運用	障害時の再作成、ロールバック、検証環境との同期

特に Windows ノードプールは、Linux ノードプールよりも OS バージョンの制約を強く意識する必要があります。アプリケーションのライフサイクルと AKS の Kubernetes バージョン、Windows Server のサポート期限を別々に管理すると、アップグレードのたびに調整コストが膨らみます。

おすすめは、半年から1年先の Kubernetes アップグレード予定を見ながら、Windows ノードプールの OS SKU、ベースコンテナーイメージ、マニフェストを同時に棚卸しすることです。

次に取るべき行動

AKS で Windows Server コンテナーを使う管理者・開発者は、まず次の3点を確認してください。

• 既存 AKS に Windows Server 2019 ノードプールが残っていないか
• Windows Server 2022 ノードプールを使う場合、Kubernetes 1.36 以降へのアップグレード計画と矛盾しないか
• Dockerfile、Kubernetes マニフェスト、Managed Identity、gMSA が新しい Windows ノードプールへ移行できる状態か

新規検証では、Azure CLI 2.87.0 以上、Azure CNI、Windows ノードプール、nodeSelector の4点を押さえれば、Windows Server コンテナーを AKS に展開できます。ただし、本番ではクイックスタートの構成をそのまま使わず、OS SKU のサポート期限とノードプール移行を前提に設計することが重要です。

Windows コンテナーの AKS 運用で失敗しやすいのは、デプロイコマンドではなく、OS バージョン、Kubernetes バージョン、コンテナーイメージ、Pod 配置条件のずれです。まず現状のノードプールを棚卸しし、Windows Server 2025 への将来移行を見据えて、検証環境からマニフェストとイメージの更新を進めましょう。