AKSのノード起動をPrepared Image Specificationで高速化する方法

AKSでノードの追加に時間がかかり、Cluster AutoscalerがスケールアウトしてもPodをすぐに起動できない場合は、Prepared Image Specification（PIS）でコンテナーイメージや初期化処理を事前にノードイメージへ組み込むことで、スケール時の待ち時間を短縮できます。

特に効果が期待できるのは、数GB以上のコンテナーイメージを使うAI推論、GPU、Windowsコンテナー、急激なアクセス増加に応じてノード数を増やすワークロードです。一方、最初のノードプール作成・更新時には準備済みイメージの生成が必要になるため、その処理は通常より長くなります。PISは「初回の準備時間を前払いし、その後のスケールアウトを高速化する仕組み」と理解すると分かりやすいでしょう。

Prepared Image Specificationは2026年6月にパブリックプレビューとして案内された機能です。プレビュー機能はSLAや限定保証の対象外であり、Microsoftも本番利用を前提としない評価段階の機能として案内しています。まず検証用ノードプールで効果と互換性を確認してください。

AKSのノード起動時間をPrepared Image Specificationで短縮する

Prepared Image Specificationは、AKSが使用するノードイメージに、次のような内容をあらかじめ組み込むためのAzureリソースです。

コンテナーイメージのキャッシュ
BashまたはPowerShellによる初期化処理
OS設定
ランタイム依存関係
セキュリティ設定

利用者が独自のノードイメージを直接管理するのではなく、必要な状態をPISとして定義し、実際の準備済みイメージの作成や再構築はAKSに任せられる点が特徴です。(Microsoft Learn)

通常のノード追加で発生する待ち時間

通常のAKSノードでは、スケールアウトするたびに次の処理が発生します。

仮想マシンの割り当て
OSとAKSコンポーネントの起動
ノードのクラスター参加
コンテナーイメージのダウンロード
ランタイムや依存パッケージの準備
Podの初期化
Readiness Probeの成功

コンテナーイメージが大きい場合や、ノード起動後に長いセットアップスクリプトを実行している場合、ノード数を増やすたびに同じ作業が繰り返されます。

PISで事前準備される流れ

PISをノードプールに関連付けると、AKSはおおむね次の流れで準備済みイメージを作成します。

PISリソースとバージョンを作成する
キャッシュするコンテナーイメージとスクリプトを定義する
AKSが一時的なビルドノードを作成する
カスタマイズスクリプトを実行する
指定したコンテナーイメージをキャッシュする
ノードの状態を準備済みイメージとして保存する
以後のノード追加では準備済みイメージから起動する

スクリプトとコンテナーイメージの両方を指定した場合、スクリプトが先に実行され、その後にイメージがキャッシュされます。スクリプトでcontainerd、証明書、レジストリ設定、ネットワーク設定などを変更すると、後続のイメージ取得に影響する可能性があるため注意が必要です。(Microsoft Learn)

通常のAKSとPISの違いを整理すると、次のようになります。

処理	通常のAKSノード	PISを利用したノード
最初のノードプール作成・更新	比較的短い	イメージ準備があるため長くなる
以後のスケールアウト	毎回通常の準備を実施	準備済みイメージから起動
コンテナーイメージ	ノード追加後に取得	ノードイメージへ事前格納
カスタムスクリプト	ノードごとに実行	ビルド時に実行可能
起動時間のばらつき	イメージサイズや通信状況に左右される	比較的予測しやすい
大容量イメージ	ダウンロード時間が長くなりやすい	キャッシュによる効果が大きい

(Microsoft Learn)

PISで短縮できる遅延と短縮できない遅延

AKSのノード起動が遅いからといって、すべてのケースでPISが有効とは限りません。どこで時間がかかっているかを分解することが重要です。

遅延の原因	PISの効果	判断のポイント
大容量コンテナーイメージの取得	大きい	`Pulling`から`Pulled`までが長い
ノードごとのパッケージ導入	大きい	起動スクリプトやDaemonSetで毎回導入している
Windowsコンテナーイメージの取得	大きい	ベースイメージを含めて容量が大きい
GPU関連のランタイム準備	条件次第で大きい	固定された依存関係を毎回準備している
VM SKUの割り当て待ち	原則として対象外	Azure側の容量やクォータが原因
CNIやIPアドレスの割り当て	原則として対象外	ネットワーク設計やサブネット容量が原因
PVCやCSIボリュームのマウント	原則として対象外	Podの`ContainerCreating`が長い
Key Vaultや外部サービスへの接続	原則として対象外	外部通信や認証が原因
モデルファイルの実行時ダウンロード	PISだけでは不十分	モデルがコンテナー外にある
アプリケーションの初期化	原則として対象外	initContainerやReadiness Probeが長い

PIS導入前には、次のコマンドでPodとノードのイベントを確認します。

kubectl get nodes -o wide
kubectl get events --sort-by=.lastTimestamp
kubectl describe pod <pod-name>

PodイベントでコンテナーイメージのPullingからPulledまでに長い時間がかかっていれば、PISの有力な対象です。

一方、ノードがすでにReadyなのに、initContainer、ボリュームマウント、Readiness Probeなどで待たされている場合、PISを導入しても大きく改善しない可能性があります。Microsoftのトラブルシューティングでも、効果が出ない場合はイメージ取得ではなく、ワークロード初期化など別の処理がボトルネックになっていないか確認するよう案内されています。(Microsoft Learn)

なお、ImagePullBackOffは単なる速度問題ではなく、イメージ名の誤りやレジストリ認証の失敗を示すことがあります。この状態はPISを導入する前に解消してください。(Kubernetes)

Prepared Image Specificationが向いているワークロード

PISは、準備済みイメージの作成後に何度もスケールアウトするノードプールで最も効果を発揮します。

AI・機械学習

AI推論サーバーや機械学習フレームワークを含むコンテナーイメージは、複数GBになることがあります。モデルサーバー、推論ランタイム、共通ライブラリなどを事前格納すると、GPUノードが追加された後の待ち時間を短縮できます。

ただし、モデルファイルをBlob StorageやモデルレジストリからPod起動時に取得している場合、そのダウンロード時間はPISだけでは解消できません。頻繁に更新されるモデルを巨大なコンテナーイメージへ毎回含めると、PISの再作成も頻繁になります。

実務では次のように分離すると運用しやすくなります。

更新頻度が低い推論ランタイムはPISへ格納する
更新頻度が高いモデルは外部ストレージで管理する
モデル取得時間が問題ならArtifact Streamingなども検討する
推論サーバーとモデルの更新周期を分ける

GPUワークロード

GPUノードでは、GPU関連ライブラリやワークロード固有の依存関係が起動時間に影響することがあります。PISでは、GPUドライバー、CUDAライブラリ、その他の依存関係を準備済みイメージへ含める用途が想定されています。(Microsoft Learn)

ただし、AKSやノードイメージが管理するドライバーと、カスタムスクリプトで導入するドライバーが競合しないようにしてください。OS、VM SKU、Kubernetesバージョン、GPUランタイムの組み合わせごとに検証する必要があります。

Windowsコンテナー

Windowsコンテナーイメージはサイズが大きくなりやすいため、ノード追加後のダウンロードがスケールアウト時間に直結します。PISはWindowsノードもサポートし、PowerShellによるカスタマイズスクリプトを使用できます。(Microsoft Learn)

Linux用とWindows用では、次の項目を分離して管理するのが安全です。

PISリソースまたはバージョン
カスタマイズスクリプト
キャッシュするコンテナーイメージ
検証用ノードプール
リリース手順

バーストスケーリング

イベント、キャンペーン、夜間バッチなどで短時間にノード数が増える環境では、Cluster Autoscalerがノードを追加してからワークロードが実行可能になるまでの時間が重要です。

PISを使うと、準備済みイメージからノードを起動できるため、急増時の待ち時間を短縮し、スケールアウト時間を予測しやすくできます。(Microsoft Learn)

PISを利用するための前提条件

パブリックプレビュー時点では、主に次の条件があります。

項目	条件
Azure CLI	バージョン2.85.0以降
CLI拡張機能	`aks-preview` 21.0.0b5以降
機能フラグ	`AKSPreparedImageSpecificationPreview`
OS	Ubuntu、Azure Linux、Windows
リージョン	パブリックAzureリージョン
非対応環境	ソブリンクラウド、エアギャップ環境
権限	AKSとPISを管理できるAzure RBAC権限
コンテナーイメージ	AKSおよびビルド処理から取得可能であること
配置	PISと利用するノードプールを同一リージョンに配置

(Microsoft Learn)

以下のコマンド例は、Azure Cloud ShellなどのBash環境を前提としています。

事前格納するイメージと初期化処理を選ぶ

PISへ何でも格納すればよいわけではありません。効果が高いものに絞ることが重要です。

事前格納に向いているものは次のとおりです。

毎回使用する大容量イメージ
更新頻度が低いベースイメージ
推論サーバーや共通サイドカー
セキュリティエージェント
固定バージョンのランタイム
ノードごとに繰り返し導入している依存パッケージ

反対に、次のようなものは慎重に判断します。

毎日更新されるコンテナーイメージ
環境ごとに内容が変わるファイル
APIキーやパスワード
有効期限の短いトークン
ノードごとに異なる値
外部サービスの一時的な状態に依存する処理

本番用イメージでは、:latestのような可変タグを避け、バージョンタグまたはイメージダイジェストを使用するのが安全です。ダイジェストを指定すると、レジストリ上のタグが差し替えられても、同じイメージを再現できます。(Kubernetes)

Azure CLIとプレビュー機能を有効化する

現在のAzure CLIと拡張機能を確認します。

az --version
az extension show --name aks-preview

aks-previewが未導入の場合は追加します。

az extension add --name aks-preview

すでに導入済みの場合は更新します。

az extension update --name aks-preview

続いて、サブスクリプションでPISの機能フラグを登録します。

az feature register \
  --namespace Microsoft.ContainerService \
  --name AKSPreparedImageSpecificationPreview

登録状態を確認します。

az feature show \
  --namespace Microsoft.ContainerService \
  --name AKSPreparedImageSpecificationPreview \
  --query properties.state \
  --output tsv

状態がRegisteredになった後、リソースプロバイダーの登録を更新します。

az provider register \
  --namespace Microsoft.ContainerService

(Microsoft Learn)

プライベートACRへアクセスできるIDを準備する

パブリックイメージだけを利用する場合、この手順は不要なことがあります。プライベートなAzure Container Registryを利用する場合は、PISのビルド処理とAKSノードの双方がイメージを取得できるようにします。

PISでは、ビルド時やプロビジョニング時の処理にユーザー割り当てマネージドIDを指定できます。このIDは準備済みイメージを作成する処理で使用され、実際に起動したAKSノードのIDを置き換えるものではありません。(Microsoft Learn)

環境変数を設定します。

RESOURCE_GROUP="rg-aks-prod"
LOCATION="japaneast"
AKS_NAME="aks-prod"
ACR_NAME="myacr"
PIS_IDENTITY_NAME="pis-build-identity"

ユーザー割り当てマネージドIDを作成します。

az identity create \
  --resource-group "$RESOURCE_GROUP" \
  --name "$PIS_IDENTITY_NAME" \
  --location "$LOCATION"

リソースIDとプリンシパルIDを取得します。

PIS_IDENTITY_ID=$(az identity show \
  --resource-group "$RESOURCE_GROUP" \
  --name "$PIS_IDENTITY_NAME" \
  --query id \
  --output tsv)

PIS_IDENTITY_PRINCIPAL_ID=$(az identity show \
  --resource-group "$RESOURCE_GROUP" \
  --name "$PIS_IDENTITY_NAME" \
  --query principalId \
  --output tsv)

ACR_ID=$(az acr show \
  --resource-group "$RESOURCE_GROUP" \
  --name "$ACR_NAME" \
  --query id \
  --output tsv)

ABACを有効にしていない通常のACRでは、AcrPullロールを割り当てます。

az role assignment create \
  --assignee-object-id "$PIS_IDENTITY_PRINCIPAL_ID" \
  --assignee-principal-type ServicePrincipal \
  --role "AcrPull" \
  --scope "$ACR_ID"

ACRのアクセス許可モードが「RBAC Registry + ABAC Repository Permissions」の場合は、AcrPullではなくContainer Registry Repository Readerを割り当てます。

az role assignment create \
  --assignee-object-id "$PIS_IDENTITY_PRINCIPAL_ID" \
  --assignee-principal-type ServicePrincipal \
  --role "Container Registry Repository Reader" \
  --scope "$ACR_ID"

ABAC対応ACRでは、従来のAcrPullが受け付けられず、az aks update --attach-acrによる統合も利用できません。AKSのkubelet IDにも、同様にContainer Registry Repository Readerを手動で割り当てる必要があります。(Microsoft Learn)

PISにイメージがキャッシュされていても、レジストリへのアクセス権限を削除してよいわけではありません。キャッシュミス、イメージ更新、再構築、imagePullPolicyの設定などに備え、AKS側の通常のイメージ取得権限も維持してください。

カスタマイズスクリプトを作成する

PISでは、BashとPowerShellのスクリプトを利用できます。スケールアウト時の処理を前倒ししたい場合は、executionPointにNodeImageBuildTimeを指定します。

NodeProvisionTimeを指定するとノードのプロビジョニング時に処理されるため、スクリプトの内容によってはスケールアウト時の遅延が残ります。ノードイメージへ変更を保持したい処理は、原則としてNodeImageBuildTimeを使用します。(Microsoft Learn)

Ubuntuノード向けのscripts.jsonは、例えば次のように作成します。

[
  {
    "name": "install-runtime-deps",
    "script": "set -euo pipefail\napt-get update\nDEBIAN_FRONTEND=noninteractive apt-get install -y jq libgomp1\nrm -rf /var/lib/apt/lists/*",
    "scriptType": "Bash",
    "executionPoint": "NodeImageBuildTime",
    "postScriptAction": "None"
  }
]

Azure Linuxではパッケージ管理方法が異なるため、Ubuntu用スクリプトをそのまま使用しないでください。Windowsノードでは、scriptTypeをPowerShellに変更します。

スクリプトには次の原則を適用します。

何度実行しても壊れないようにする
パッケージやダウンロード元のバージョンを固定する
ソース管理する
スクリプトを変更したら新しいPISバージョンを作る
一時的な外部サービスの状態に依存させない
シークレットを直接記述しない
containerdやネットワーク設定の変更は慎重に行う

PISのスクリプト本文はプレーンテキストとしてリソース定義に含まれるため、パスワード、トークン、秘密鍵などを埋め込んではいけません。(Microsoft Learn)

コンテナーイメージを含むPISを作成する

環境変数を設定します。

PIS_NAME="pis-ai-inference"
PIS_VERSION="v20260802"
ACR_LOGIN_SERVER=$(az acr show \
  --resource-group "$RESOURCE_GROUP" \
  --name "$ACR_NAME" \
  --query loginServer \
  --output tsv)

コンテナーイメージとカスタマイズスクリプトを指定してPISを作成します。

az aks prepared-image-specification create \
  --resource-group "$RESOURCE_GROUP" \
  --name "$PIS_NAME" \
  --version "$PIS_VERSION" \
  --location "$LOCATION" \
  --assign-identity "$PIS_IDENTITY_ID" \
  --container-images \
    "${ACR_LOGIN_SERVER}/model-server:2026.08.02" \
    "${ACR_LOGIN_SERVER}/inference:2026.08.02" \
  --customization-scripts @scripts.json

カスタマイズスクリプトが不要な場合は、--customization-scriptsを省略できます。

az aks prepared-image-specification create \
  --resource-group "$RESOURCE_GROUP" \
  --name "$PIS_NAME" \
  --version "$PIS_VERSION" \
  --location "$LOCATION" \
  --assign-identity "$PIS_IDENTITY_ID" \
  --container-images \
    "${ACR_LOGIN_SERVER}/model-server:2026.08.02" \
    "${ACR_LOGIN_SERVER}/inference:2026.08.02"

PISリソースの作成は、必要な内容を定義する操作です。実際のターゲットノードイメージの準備は、PISバージョンをクラスターやノードプールに関連付けたときに行われます。(Microsoft Learn)

作成したバージョンを確認します。

az aks prepared-image-specification version show \
  --resource-group "$RESOURCE_GROUP" \
  --pis-name "$PIS_NAME" \
  --name "$PIS_VERSION" \
  --output jsonc

PISバージョンのリソースIDを取得する

ノードプールから参照するのは、PIS本体ではなくPISバージョンのリソースIDです。

PIS_VERSION_ID=$(az aks prepared-image-specification version show \
  --resource-group "$RESOURCE_GROUP" \
  --pis-name "$PIS_NAME" \
  --name "$PIS_VERSION" \
  --query id \
  --output tsv)

echo "$PIS_VERSION_ID"

新しいノードプールへPISを適用する

既存の本番ノードプールを直接変更するより、まず新しい検証用ノードプールを作成する方が安全です。

NODEPOOL_NAME="aipool"

az aks nodepool add \
  --resource-group "$RESOURCE_GROUP" \
  --cluster-name "$AKS_NAME" \
  --name "$NODEPOOL_NAME" \
  --mode User \
  --node-vm-size "<VM_SKU>" \
  --node-count 1 \
  --enable-cluster-autoscaler \
  --min-count 0 \
  --max-count 10 \
  --prepared-image-specification-id "$PIS_VERSION_ID"

GPUノードでは、<VM_SKU>を対象リージョンで利用可能なGPU対応SKUに置き換えます。Windowsノードプールの場合は、クラスター側のWindows構成を準備したうえで--os-type Windowsを指定します。

初回のノードプール作成時には、PISに基づく準備済みイメージの構築が行われるため、通常より時間がかかる可能性があります。効果を評価するときは、初回作成時間ではなく、準備完了後の2回目以降のスケールアウトを比較します。(Microsoft Learn)

既存ノードプールへPISを適用する

既存ノードプールをPISバージョンへ切り替える場合は、次のコマンドを使用します。

az aks nodepool update \
  --resource-group "$RESOURCE_GROUP" \
  --cluster-name "$AKS_NAME" \
  --name "$NODEPOOL_NAME" \
  --prepared-image-specification-id "$PIS_VERSION_ID"

ノードプールの更新を伴うため、本番環境では次の項目を事前に確認します。

PodDisruptionBudget
ワークロードの冗長性
ノードの最大サージ設定
メンテナンス時間帯
GPUやWindows固有の互換性
ロールバック先となる旧PISバージョン
クォータとノード追加余力

PISが関連付けられていることを確認します。

az aks nodepool show \
  --resource-group "$RESOURCE_GROUP" \
  --cluster-name "$AKS_NAME" \
  --name "$NODEPOOL_NAME" \
  --query "{state:provisioningState,pisId:preparedImageSpecificationId}" \
  --output yaml

pisIdに対象のPISバージョンIDが表示されれば、ノードプールから参照されています。(Microsoft Learn)

スケールアウト時間を比較する

PISの効果は、感覚ではなく同じ条件のノードプールで比較します。

比較条件はできるだけそろえてください。

同じリージョン
同じVM SKU
同じOS
同じOSディスク構成
同じKubernetesバージョン
同じネットワーク構成
同じコンテナーイメージ
同じノード数
同じ時間帯または近い時間帯

Microsoftは、PISの効果確認項目として次の指標を挙げています。

指標	確認内容
ノードプロビジョニング時間	ノード作成から`Ready`まで
スケールアウト完了時間	Autoscalerの起動からノード`Ready`まで
イメージビルド時間	準備済みイメージの構築時間
ビルド成功率	スクリプトやイメージ取得の失敗有無
Pod起動時間	Pod作成からコンテナー起動まで
イメージ取得時間	PISなしノードとの比較

(Microsoft Learn)

検証では、次のような流れが実用的です。

PISなしのノードプールを0台から数台へ増やす
ノードがReadyになるまでの時間を記録する
対象PodがReadyになるまでの時間を記録する
PISありのノードプールで同じ操作を行う
一度だけでなく複数回実施する
平均値だけでなく最大値も比較する

PISは起動時間のばらつきを抑える目的でも使われるため、平均値だけでなく、最も遅かったケースも確認することが重要です。

PISのバージョンを安全に更新する

PISリソースとPISバージョンは別の概念です。タグなどのメタデータを更新しても、既存バージョンに格納されたイメージやスクリプトは変更されません。

コンテナーイメージやスクリプトを変更するときは、同じPIS名で新しいバージョンを作成します。

PIS_VERSION="v20260815"

その後、更新内容を指定して再度az aks prepared-image-specification createを実行し、新しいバージョンIDを取得します。

推奨される更新手順は次のとおりです。

新しいPISバージョンを作成する
非本番ノードプールへ適用する
イメージ構築とノード起動を確認する
ワークロードの動作を確認する
本番ノードプールを新バージョンへ切り替える
旧バージョンを一定期間残す
不要になったバージョンを削除する

Kubernetesバージョンをアップグレードすると、AKSは参照中のPISバージョンに対して準備済みVHDを再構築します。PISの内容が変わらない場合、Kubernetesアップグレードだけを理由に新しいPISバージョンを作る必要はありません。ただし、対象のKubernetesバージョンとノードイメージでスクリプトが正常に動くか、事前の非本番検証は必要です。(Microsoft Learn)

PIS利用時に失敗しやすいポイント

スクリプトにシークレットを記述している

PISのスクリプトはリソース定義の一部です。ACRのパスワード、APIキー、SASトークン、秘密鍵などを含めないでください。

認証が必要な処理では、マネージドIDや実行時のKey Vault連携を利用します。

`latest`タグをキャッシュしている

latestの参照先が更新されても、既存のPISバージョンが自動的に意図した状態へ更新されるとは限りません。また、ノード間で異なるイメージが実行される原因になります。

PISとDeploymentの両方で同じバージョンタグまたはダイジェストを使用してください。

PISとDeploymentで異なるイメージを指定している

PISにはmodel-server:1.0を格納しているのに、Deploymentがmodel-server:1.1を指定していれば、新しいイメージのダウンロードが発生します。

PIS定義とKubernetesマニフェストを同じリリースパイプラインで更新すると、食い違いを防ぎやすくなります。

`NodeProvisionTime`で長い処理を実行している

ノードごとの処理を減らす目的なのに、長時間のスクリプトをNodeProvisionTimeで実行すると、スケールアウト時の遅延が残ります。

ノードイメージへ保存できる処理は、NodeImageBuildTimeへ移します。

スクリプトが再実行を想定していない

Kubernetesバージョン変更やノードイメージ更新によって、PISの再構築が発生することがあります。

ファイルやユーザーがすでに存在していても失敗しないようにし、スクリプトを冪等に設計してください。

PISを作っただけで高速化されたと思っている

PISリソースを作成しただけでは、既存ノードプールが自動的に利用するわけではありません。ノードプールのpreparedImageSpecificationIdが正しいバージョンを参照しているか確認します。

初回の作成時間だけを比較している

初回は準備済みイメージの構築があるため、通常のノードプールより遅くなることがあります。比較すべきなのは、イメージ構築後の繰り返しスケールアウトです。

ノードがほとんど増減しない環境では、一度限りのイメージ準備コストが効果を上回る場合があります。(Microsoft Learn)

PISでエラーが発生したときの確認項目

準備済みイメージの作成に失敗する

次の項目を確認します。

scripts.jsonのJSON形式が正しいか
BashとPowerShellの指定が対象OSに合っているか
スクリプトの終了コードが0になっているか
ACRへの認証に成功しているか
ビルド用マネージドIDにプル権限があるか
リソースグループのAzure RBAC権限が不足していないか
外部パッケージリポジトリへ接続できるか
containerdや証明書設定を壊していないか

カスタマイズスクリプトが失敗した場合、AKSはデバッグできるようビルドVMを削除せず、割り当て解除状態で残す場合があります。その後の再ビルドでは、関連するビルドリソースが再作成されます。(Microsoft Learn)

ノードプールの作成に失敗する

次の項目を確認します。

PISバージョンIDが存在するか
PISとノードプールが同じリージョンか
指定したVM SKUのクォータが足りているか
対象VM SKUが準備済みイメージで利用可能か
対象リージョンでプレビュー機能が利用可能か
OSとスクリプトの種類が一致しているか

(Microsoft Learn)

導入しても速くならない

次の順番で確認します。

遅いイメージがPISに含まれているか
ノードプールが正しいPISバージョンを参照しているか
新しいノードが準備済みイメージから起動しているか
DeploymentがPISと同じタグまたはダイジェストを使っているか
実際のボトルネックがイメージ取得なのか
モデル取得、PVC、initContainer、Readiness Probeが遅くないか

イメージ取得ではなく、アプリケーション起動や外部データ取得が原因なら、PIS以外の改善が必要です。(Microsoft Learn)

Artifact Streamingや他の機能との使い分け

PISと似た機能を混同しないようにします。

機能	主な目的	コンテナーイメージ	スクリプト	適した用途
Prepared Image Specification	準備済みノードイメージの作成	事前キャッシュ	対応	繰り返しスケールするノード
Artifact Streaming	大容量アーティファクトの高速利用	ストリーミング	非対応	モデルや大容量データの利用
Custom Node Configuration	ノード実行時の設定	キャッシュしない	実行時設定向け	sysctlなどのランタイム設定
Node Pool Snapshot	ノードプール構成の複製・復元	キャッシュ目的ではない	対象外	構成の再利用や複製
イメージ事前取得DaemonSet	既存ノード上でイメージ取得	取得可能	任意	すでに存在するノードの準備

Artifact StreamingとPISは排他的ではありません。PISで安定したコンテナーイメージと依存関係を準備し、大容量モデルやアーティファクトはストリーミングする構成も検討できます。(Microsoft Learn)

PISの利用を停止する方法

ノードプールからPISの参照を外すには、空文字列を指定します。

az aks nodepool update \
  --resource-group "$RESOURCE_GROUP" \
  --cluster-name "$AKS_NAME" \
  --name "$NODEPOOL_NAME" \
  --prepared-image-specification-id ""

PISバージョンを削除するときは、先にどのノードプールからも参照されていないことを確認します。

az aks nodepool list \
  --resource-group "$RESOURCE_GROUP" \
  --cluster-name "$AKS_NAME" \
  --query "[?preparedImageSpecificationId != null]"

参照中のPISバージョンを削除すると、AKSが準備済みイメージを再構築またはローリングできなくなる可能性があります。必ず別バージョンへの切り替え、またはPIS参照の解除を先に行ってください。(Microsoft Learn)

AKSのノード起動が遅いときの実践的な進め方

Prepared Image Specificationを導入するときは、最初からすべてのノードプールへ適用しない方が安全です。

まず、ノード追加からPod起動までを計測し、コンテナーイメージの取得やノード初期化が主要なボトルネックであることを確認します。次に、大容量で更新頻度の低いイメージを1～2個選び、検証用PISと検証用ノードプールを作成します。

準備済みイメージの初回構築後、ノード数を0台から複数台へ増やすテストを数回行い、PISなしのノードプールと比較してください。ノードがReadyになる時間だけでなく、実際のPodがReadyになるまでの時間も比較します。

効果を確認できたら、PISをリリース成果物としてバージョン管理し、非本番検証、新バージョンへの切り替え、旧バージョンの保持、不要バージョンの削除という流れを運用手順に組み込みます。

PISは、単にAKSノードを高速化する機能ではありません。スケール時に繰り返していた準備作業を、管理可能なイメージビルド工程へ移す仕組みです。AI、GPU、Windowsなど、ノード起動時間がサービス性能に直結するワークロードでは、ボトルネックを正しく切り分けたうえで検証する価値があります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

AKSのノード起動をPrepared Image Specificationで高速化する方法

AKSのノード起動時間をPrepared Image Specificationで短縮する

通常のノード追加で発生する待ち時間

PISで事前準備される流れ

PISで短縮できる遅延と短縮できない遅延

Prepared Image Specificationが向いているワークロード

AI・機械学習

GPUワークロード

Windowsコンテナー

バーストスケーリング

PISを利用するための前提条件

事前格納するイメージと初期化処理を選ぶ

Azure CLIとプレビュー機能を有効化する

プライベートACRへアクセスできるIDを準備する

カスタマイズスクリプトを作成する

コンテナーイメージを含むPISを作成する

PISバージョンのリソースIDを取得する

新しいノードプールへPISを適用する

既存ノードプールへPISを適用する

スケールアウト時間を比較する

PISのバージョンを安全に更新する

PIS利用時に失敗しやすいポイント

スクリプトにシークレットを記述している

`latest`タグをキャッシュしている

PISとDeploymentで異なるイメージを指定している

`NodeProvisionTime`で長い処理を実行している

スクリプトが再実行を想定していない

PISを作っただけで高速化されたと思っている

初回の作成時間だけを比較している

PISでエラーが発生したときの確認項目

準備済みイメージの作成に失敗する

ノードプールの作成に失敗する

導入しても速くならない

Artifact Streamingや他の機能との使い分け

PISの利用を停止する方法

AKSのノード起動が遅いときの実践的な進め方

この記事を書いた人

コメント

コメントするコメントをキャンセル

AKSのノード起動をPrepared Image Specificationで高速化する方法

AKSのノード起動時間をPrepared Image Specificationで短縮する

通常のノード追加で発生する待ち時間

PISで事前準備される流れ

PISで短縮できる遅延と短縮できない遅延

Prepared Image Specificationが向いているワークロード

AI・機械学習

GPUワークロード

Windowsコンテナー

バーストスケーリング

PISを利用するための前提条件

事前格納するイメージと初期化処理を選ぶ

Azure CLIとプレビュー機能を有効化する

プライベートACRへアクセスできるIDを準備する

カスタマイズスクリプトを作成する

コンテナーイメージを含むPISを作成する

PISバージョンのリソースIDを取得する

新しいノードプールへPISを適用する

既存ノードプールへPISを適用する

スケールアウト時間を比較する

PISのバージョンを安全に更新する

PIS利用時に失敗しやすいポイント

スクリプトにシークレットを記述している

latestタグをキャッシュしている

PISとDeploymentで異なるイメージを指定している

NodeProvisionTimeで長い処理を実行している

スクリプトが再実行を想定していない

PISを作っただけで高速化されたと思っている

初回の作成時間だけを比較している

PISでエラーが発生したときの確認項目

準備済みイメージの作成に失敗する

ノードプールの作成に失敗する

導入しても速くならない

Artifact Streamingや他の機能との使い分け

PISの利用を停止する方法

AKSのノード起動が遅いときの実践的な進め方

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

`latest`タグをキャッシュしている

`NodeProvisionTime`で長い処理を実行している

コメントするコメントをキャンセル