AKS のノードプールで Azure Linux 2.0（CBL‑Mariner）から 3.0 へ切り替える際、「NodeImageVersion の表記だけでは判別が難しい」「自動アップグレードにしているのに 2.0 のまま」「次のリリースで勝手に 3.0 になるのか」など、実運用で迷いやすいポイントが数多くあります。本記事は、実際の問い合わせで挙がりやすい質問に答えつつ、ゼロダウンタイムを意識した移行の作法、確認コマンド、落とし穴までをまとめて解説します。
AKS の Azure Linux 2.0 → 3.0 移行を取り巻く前提
まず全体像を押さえます。Azure Linux 3.0 は AKS v1.32 以降で既定の Azure Linux ノード OS となりました。一方、既存のノードプールが自動で 3.0 に切り替わるわけではありません。さらに、Azure Linux 2.0 は段階的にリタイアメント／提供終了がアナウンスされています。運用者は「いつまでに」「どのノードプールを」「どのやり方で」移行するかを明確にし、業務影響を抑えたローリング更新計画を組む必要があります。
重要なマイルストーン（要対応）
- 2025‑11‑30：AKS で Azure Linux 2.0 へのサポート・セキュリティ更新が終了。
- 2026‑03‑31：Azure Linux 2.0 のノードイメージが AKS から削除。スケール不可（増設できない）になるため、残置は運用リスクになります。
上記に照らして、早めに 3.0 へ移行し、以降は 3.0 系のイメージで継続運用するのが実務上の最適解です。
質問に対する端的な答え（先に結論）
- NodeImageVersion の見分け方：先頭接頭辞で判別します（下表参照）。
AKSCBLMariner‑V2…は Azure Linux 2.0、AKSAzureLinux‑V3…は Azure Linux 3.0。…katagen2や…gen2などのサフィックスは機能・世代（Gen2 など）の表現で、メジャー OS バージョンの判定には影響しません。 - AKS v1.32.6 で自動アップグレード設定なのに 2.0 のままな理由：自動アップグレードは主に制御プレーンと「新規に作る」ノードプールの既定 OSを対象にします。既存ノードプールの OS バージョンは自動で 3.0 へ切替わりません（OS SKU の明示更新 or ノードイメージのローリング適用が必要）。
- 次の Kubernetes リリースで自動的に 3.0 へ切り替わる？いいえ。既存ノードプールは自動切替の対象外です。
- ノード数を 1→2→1 と増減すれば 3.0 ノードが残る？非推奨。スケールダウンの削除選定は「最新ノードを残す」保証がなく、期待どおりに 3.0 ノードが残らないことがあります。
az aks nodepool update --os-sku AzureLinux3 …の動作：インプレース再イメージ（ローリング）で実行され、既存 VM が順次再構築されて OS が 3.0 に置換されます。新旧ノードをつくり直す “入れ替え方式” を手で組む必要はありません。- 3.0 へ移行済みかの確認方法：
az aks nodepool show --query nodeImageVersion等でAKSAzureLinux‑V3を確認。加えてkubectl get nodeで OS イメージやカーネルの確認が可能です（後述）。
NodeImageVersion の見分け方（確実に判別）
| 例 | 意味 | 判定 | 補足 |
|---|---|---|---|
AKSCBLMariner‑V2katagen2‑202508.20.x | CBL‑Mariner ベースの Azure Linux 2.0（Kata/Gen2 バリアント） | 2.0 | katagen2 はバリアント表記。メジャー OS は先頭の AKSCBLMariner‑V2 で決まります。 |
AKSAzureLinux‑V3gen2‑202510.03.0 | Azure Linux 3.0 の Gen2 イメージ | 3.0 | 3.0 系は AKSAzureLinux‑V3 が先頭に入ります。 |
AKSUbuntu‑2204‑2025xx.xx.x | Ubuntu 22.04 系 | — | Ubuntu 系と混在運用している場合の参考。 |
覚え方：「CBLMariner‑V2 ＝ 2.0」「AzureLinux‑V3 ＝ 3.0」。サフィックスは気にしすぎない、がコツです。
なぜ自動アップグレードでも 2.0 が残るのか
AKS の自動アップグレード（クラスタ／ノードイメージ）と OS メジャーバージョンの関係は以下のとおりです。
| 対象 | 自動アップグレードの挙動 | Azure Linux 3.0 への影響 |
|---|---|---|
| 制御プレーン | 選択したチャネル（stable 等）に沿って自動更新 | OS とは無関係。クラスタ API が更新されるのみ。 |
| 既存ノードプールの OS | 原則自動ではメジャー切替なし | 2.0 → 3.0 は手動介入が必要（--os-sku AzureLinux3）。 |
| 新規で作るノード／ノードプール | AKS v1.32+ では既定 OS が Azure Linux 3.0 に | 新規は 3.0 ベースになるが、既存は別。 |
つまり、「クラスタを v1.32 に上げた＝既存ノードが 3.0 になる」ではないのです。既存プールは OS SKU の明示更新、もしくはブルーグリーンで 3.0 プールを新設する等の対応が必要です。
推奨の移行手順（ローリング・インプレース）
最短ルートは Azure CLI で OS SKU を AzureLinux3 に更新する方法です。AKS がノードを順次再イメージし、Pod を疎通させながら 3.0 へ置換します。
実行コマンド（最小構成）
az aks nodepool update \
--resource-group <RG名> \
--cluster-name <クラスター名> \
--name <ノードプール名> \
--os-sku AzureLinux3
ダウンタイムを抑えるためのチューニング
ローリングの速度・並行度は、ノードプールの「アップグレード設定」で制御します。事前に以下を設定してから実行すると安全です。
| 設定 | CLI サンプル | 推奨値の目安 | 効果 |
|---|---|---|---|
| max surge（並行入替数） | az aks nodepool update -g RG -n NP --cluster-name CL \ --max-surge 33% | 小規模（<=3台）：1、中規模（4–30台）：33% 目安 | 追加ノードを確保してから drain するため、業務影響を抑えつつ時間短縮 |
| node soak duration（次ノードへ進むまでの待機） | ... --node-soak-duration 5 | 0–5 分 | 各ステップの健全性確認の余裕を確保 |
| drain timeout（退避の上限時間） | ... --drain-timeout 45 | 30–60 分 | 長時間 Pod の退避待ちで停止しないよう制御 |
重要：--max-surge はノードプールの永続設定です。OS SKU 変更だけでなく、今後のノードイメージ更新・Kubernetes マイナー更新にも引き継がれます。初回に適切な値へ見直しておくと、以降の運用が安定します。
業務影響をさらに減らすチェックリスト
- Pod Disruption Budget（PDB）を各アプリに設定（最小稼働 Pod 数の保証）。
- HPA/CA（オートスケーラー）を一時的に抑制するか、スケールの上限・下限を再確認。
- Azure CNI の場合はサージ分も含めた IP アドレスの余裕を確保。
- 有給時間帯 or メンテナンスウィンドウ内に実施（Planned Maintenance を活用）。
- 高可用構成：システムプールは最低 3 台以上を確保。
「スケールアップ→ダウン」流儀がダメな理由
「一時的にノードを増やして 3.0 ノードを作り、その後減らす」という手順は、スケールダウンの削除対象ロジック（スコアリング）により新しい 3.0 ノードが消される可能性が否定できません。可観測性の低い運用になりがちで、再現性・確実性の観点から非推奨です。正攻法で --os-sku AzureLinux3 を指定し、ローリングに任せるのが安全です。
移行完了の確認コマンド
Azure CLI（ノードプール単位）
# ノードプールのイメージ名を確認
az aks nodepool show -g <RG名> -n <ノードプール名> --cluster-name <クラスター名> \
--query nodeImageVersion -o tsv
# 出力例：AKSAzureLinux‑V3gen2‑202510.03.0 なら 3.0 へ置換済み
Azure CLI（一覧）
az aks nodepool list -g <RG名> --cluster-name <クラスター名> \
--query "[].{name:name, osSku:osSKU, nodeImageVersion:nodeImageVersion}" -o table
kubectl（ノード単位）
# OS イメージ／カーネル／コンテナランタイムを確認
kubectl get nodes -o custom-columns=NAME:.metadata.name,OSIMAGE:.status.nodeInfo.osImage,KERNEL:.status.nodeInfo.kernelVersion,CR:.status.nodeInfo.containerRuntimeVersion
# 例：OSIMAGE が "Azure Linux 3.0 ..." であれば 3.0
ブルーグリーンでの切替（要件が厳しい場合）
メンテ窓が極小・停止ゼロに近づけたい等の要件では、3.0 の新規ノードプールを併設し、ワークロードを段階移行するブルーグリーン方式が有効です。
- ユーザープール（3.0 / 同数 or 余裕ある台数）を新設。
- 重要デプロイメントから順に
nodeSelector/tolerations/affinity等で 3.0 プールへ移す。 - トラフィック確認後、旧 2.0 プールを縮退・削除。
この方式はインプレースよりコスト（併設期間の台数増）を要する一方、切替の可逆性・段階検証に優れます。レギュレーションや SLO 次第で選択してください。
よくある落とし穴と対処
- CLI/拡張機能が古い：エラー Changing property ‘agentPoolProfile.OSSKU’ is not allowed 等は CLI/拡張や API バージョンの非対応が典型。
az upgradeとaz extension update -n aks-previewを実施。 - IP 枯渇でサージ失敗：Azure CNI では
max-surge分の VM と Pod IP を確保する必要があります。サブネット拡張 or サージ値を一時的に引き下げ。 - PDB 未設定で退避不可：退避（drain）不能な Pod があると進行停止。PDB を設定し、ステートフル系は
PodManagementPolicyやterminationGracePeriodSecondsを見直し。 - GPU/特殊ワークロード：ドライバやカーネル機能の互換性（FIPS、WASM、Pod サンドボックス等）を事前検証。必要に応じて一時的にブルーグリーンを選択。
ロールバックは可能か？（注意点）
OS SKU の移行は基本的に再度の OS SKU 変更で可逆ですが、対象 Kubernetes バージョンにその OS の対応イメージが存在することが前提です。例えば 3.0 → 2.0 へ戻す場合、該当 K8s バージョンで Azure Linux 2.0 が未対応・提供終了なら失敗します。保守窓口・検証環境での事前テストを推奨します。
運用設計の指針（長期安定運用のために）
- バージョン方針の明文化：「Kubernetes × OS × ノードイメージ」のサポート矩形をチーム内で共有。LTS 方針と合わせて決裁。
- 変更をコード化：IaC（Bicep/Terraform）に OS SKU とアップグレード設定（max surge、soak、drain timeout）を明記。
- 変更前検証と SLO 計測：更新ごとに Pre‑prod で
kubectl get ev／アプリ指標を監視し、最小の soak で済むよう継続改善。 - 通知の自動化：AKS リリースノート・NodeImage 更新・OS リタイアメント情報を監視してアラート化。
実践シナリオ：既存 1 プール（1 ノード）を安全に 3.0 へ
- 事前確認：
az aks nodepool show ... --query "{osSKU:osSKU,nodeImageVersion:nodeImageVersion}"。PDB を設定。必要に応じて一時的に--min-count 2へスケール。 - アップグレード設定：
az aks nodepool update ... --max-surge 1 --node-soak-duration 3 --drain-timeout 45。 - OS SKU 変更：
az aks nodepool update ... --os-sku AzureLinux3。 - 検証：アプリ健全性／ログ／メトリクス。
az aks nodepool show --query nodeImageVersionがAKSAzureLinux‑V3...であることを確認。 - 調整：単一ノード構成を継続する場合は、将来の更新に備えメンテ窓と PDB を維持。
Q&A：現場でよく聞かれる補足
Q. AKSCBLMariner‑V2katagen2‑202508.xx.x は 2.0？ 3.0？
A. 2.0 です。CBLMariner‑V2 のプレフィックスで確定。katagen2 はバリアント表記です。
Q. AKS を 1.32.x に上げれば自動で 3.0 になる？
A. いいえ。既存ノードは自動切替されません。az aks nodepool update --os-sku AzureLinux3 を実行してください。
Q. 入替は「新規ノードを作って旧ノード削除」なの？ それともインプレース？
A. インプレース再イメージです。AKS がノードを順に cordon/drain → 再イメージ → 復帰させます。サージ設定に応じてバッファノードが追加されるため、ワークロードの停止を最小化できます。
Q. 3.0 へ移行済みかの見分け方は？
A. nodeImageVersion が AKSAzureLinux‑V3... であれば完了。kubectl get nodes の osImage でも確認できます。
コマンドスニペット集（コピーして使える）
移行（ローリング）
# 推奨：まずアップグレード設定を見直す
az aks nodepool update -g <RG> -n <NP> --cluster-name <CL> \
--max-surge 33% --node-soak-duration 5 --drain-timeout 45
# OS SKU を AzureLinux3 に更新（インプレース）
az aks nodepool update -g -n --cluster-name
--os-sku AzureLinux3 状態確認
az aks nodepool list -g <RG> --cluster-name <CL> \
--query "[].{name:name, osSKU:osSKU, nodeImageVersion:nodeImageVersion}" -o table
kubectl get nodes -o custom-columns=NAME:.metadata.name,OSIMAGE:.status.nodeInfo.osImage トラブル時（IP 不足でサージ失敗）
# 一時的にサージを下げて再実行
az aks nodepool update -g <RG> -n <NP> --cluster-name <CL> --max-surge 1
まとめ：最短・安全・確実な判断基準
- イメージの判別：
AKSCBLMariner‑V2...は 2.0、AKSAzureLinux‑V3...は 3.0。サフィックスは気にしすぎない。 - 自動では切り替わらない：既存ノードは 自動で 3.0 になりません。明示的に
--os-sku AzureLinux3で更新。 - 安全な道：ローリング・インプレース（max surge / soak / drain timeout を調整）。スケール増減での「押し切り」は非推奨。
- 期日を守る：2025‑11‑30 以降は 2.0 の更新なし、2026‑03‑31 以降は 2.0 イメージ撤去。早めの移行が吉。
- 確認を怠らない：
nodeImageVersion／osImageを必ずチェック。IaC に方針を刻んで再現性を担保。
付録：判断の早見表
| あなたの現状 | 推奨アクション | 理由 |
|---|---|---|
| AKS v1.32+、既存プールが 2.0 | az aks nodepool update --os-sku AzureLinux3 | 既存は自動切替されないため。インプレースで最短・安全。 |
| 停止ゼロ／段階検証が必須 | 3.0 の新規プールを作りブルーグリーン移行 | 可逆性・検証容易性を優先。コストは上がるが確実。 |
| IP に余裕がない | max-surge を引き下げ／サブネット拡張 | サージで追加される VM/Pod IP を確保するため。 |
| GPU/特権機能を利用 | 検証環境で先行確認→本番 | ドライバ・カーネル依存性の事前確認が必須。 |
参考スクリプト：運用チェックを自動化
複数クラスタ／プールの移行進捗を一覧化する簡易スクリプトの例です（Cloud Shell 等で）。
# すべてのノードプールの OS SKU と NodeImageVersion を棚卸し
for rg in $(az group list --query "[].name" -o tsv); do
for cl in $(az aks list -g $rg --query "[].name" -o tsv 2>/dev/null); do
echo "=== $rg / $cl ==="
az aks nodepool list -g $rg --cluster-name $cl \
--query "[].{name:name, mode:mode, osSKU:osSKU, nodeImageVersion:nodeImageVersion}" -o table
done
done
最後に
Azure Linux 2.0 → 3.0 移行は、手順自体はシンプルでも「いつ・どうやって・どこまで止めずにやるか」が肝です。--os-sku AzureLinux3 によるインプレース更新と、max-surge/node-soak-duration/drain-timeout の最適化、そして PDB の整備だけで、移行の難易度は驚くほど下がります。サポート期限を見据え、今日から段階的に進めていきましょう。
コメント