Azure Kubernetes Service (AKS)のノード プール バージョンロールバック機能を使用すると、Kubernetes のアップグレード後に予期しない動作から回復できます。 問題が発生した場合は、以前の Kubernetes バージョンとノード イメージの組み合わせにノード プールをロールバックして、ビジネス継続性を確保し、ダウンタイムを最小限に抑えることができます。 この記事では、ロールバック機能を使用するタイミングと方法、その機能と制限事項、ロールバック後のアクションのベスト プラクティスについて説明します。
[前提条件]
- Azure CLI バージョン 2.64.0 以降が必要です。
az --versionコマンドを使用してバージョンを検索します。 インストールまたはアップグレードする必要がある場合は、「Install Azure CLIを参照してください。 -
aks-previewAzure CLI 拡張機能インストールされ、最新バージョンに更新されます。 - API バージョン
2025-08-02-preview以降。
aks-preview Azure CLI 拡張機能をインストールする
Important
AKS のプレビュー機能は、セルフサービスのオプトイン単位で利用できます。 プレビューは、"現状有姿のまま" および "利用可能な限度" で提供され、サービス レベル アグリーメントおよび限定保証から除外されるものとします。 AKS プレビューは、ベストエフォート ベースでカスタマー サポートによって部分的にカバーされます。 そのため、これらの機能は運用環境での使用を目的としていません。 詳細については、次のサポート記事を参照してください。
aks-previewコマンドとaz extension add コマンドを使用して、az extension update拡張機能をインストールまたは更新します。
# Install the aks-preview extension
az extension add --name aks-preview
# Update the aks-preview extension
az extension update --name aks-preview
ノード プール バージョンのロールバックでサポートされる機能
ノード プール バージョンのロールバック機能では、次の機能がサポートされています。
| 特徴 | Description |
|---|---|
| バージョンを元に戻す | Kubernetes とノード イメージの両方のバージョンを以前の状態に復元します。 |
| 手動トリガー、自動実行 | ロールバックには手動による開始が必要ですが、トリガーされると、システムはそれ以上の介入なしにロールバック プロセス全体を自動的に処理します。 |
| ノード プールの互換性 | 仮想マシン (VM) プールと Virtual Machine Scale Sets (VMSS) ベースのノード プールの両方を含むすべての種類のノード プールで動作します。 |
| オペレーティング システムのサポート | Ubuntu、Azure Linux、Windows プールを含むすべてのオペレーティング システム (OS) ストック 保持ユニット (SKU) と互換性があります。 |
| 簡略化されたプロセス | スナップショット管理は必要ありません。 |
ノード プールのロールバックの制限事項と考慮事項
ノード プールのロールバック機能を使用する場合は、次の制限事項に注意してください。
- バージョンの変更のみに限定されます。 その他のノード プールの変更は元に戻されません。
- ロールバック中に同時操作は許可されません。
- 構成されている場合は、ロールバックの前にクラスターの自動アップグレードを無効にする必要があります。
- アップグレード完了後 7 日間のみ使用できます。
- 複数のバージョンに戻るために連続ロールバックを実行することはできません。
- ロールバックでは、OS SKU の変更を元に戻すことはできません。 ノード プールの OS SKU (たとえば、Ubuntu から Azure Linux) を変更した場合、ロールバックは、別の OS SKU に属し、拒否される以前のノード イメージ バージョンの復元を試みます。 OS SKU の変更を元に戻すには、代わりに
az aks nodepool update --os-skuコマンドを使用します。
ノード プールのロールバックを使用する場合は、次の考慮事項に注意してください。
| セキュリティへの影響 | 運用上の考慮事項 |
|---|---|
| * 脆弱性の公開: ロールバックすると、新しいバージョンからセキュリティ パッチと更新プログラムが削除されます。 そのため、問題の解決中にロールバックを一時的にのみ使用してから、できるだけ早く再アップグレードすることをお勧めします。 |
*
サービスの中断: ロールバック プロセスによって、一時的なワークロードの中断が発生する可能性があります。 * リソースの可用性: ロールバック操作に十分な容量を確保します。 * テスト要件: アップグレードを再試行する前に、基になる問題を修正することを計画します。 |
ロールバックを使用する理由
ロールバックは、運用環境に重要な復旧メカニズムを提供します。
- ビジネス継続性: アップグレードによって予期しない問題が発生した場合のダウンタイムを最小限に抑える
- リスク軽減: 複雑な復旧手順なしで既知の適切な構成をすばやく復元する
- 簡単な復旧: 手動による介入やバックアップからのクラスターの再構築を回避する
ノード プールのロールバックを使用するタイミング
次のシナリオでは、ロールバックを復旧オプションとして検討してください。
- アップグレードエラーが発生する: インフラストラクチャの問題、リソースの制約、または互換性の問題により、アップグレードが正常に実行されません。
- アプリケーションの中断: ワークロードでは、新しい Kubernetes バージョンで重大なエラーまたはデータの破損が発生します。
- パフォーマンスが低下する: 新しいバージョンでは、許容できない待機時間、スループットの問題、またはリソースの消費が発生します。
- テストのギャップが生じる: 運用前のテスト中にキャッチされなかった運用環境で問題が発生します。
ノード プールのロールバック ワークフロー
次の図は、ノード プールのロールバック ワークフローを示しています。
ロールバック プロセスでは、ノード プール内のすべてのノードが以前のバージョンの状態に復元されます。 ワークフローの主な側面は次のとおりです。
- すべてまたは何もしない方法: ロールバックが正常に完了するには、すべてのノードが正常に以前のバージョンに戻す必要があります。 いずれかのノードがロールバックに失敗した場合、アップグレード操作と同様に、クラスターの状態を明確に伝えるために操作全体が失敗します。
- Progress の追跡: Azureアクティビティ ログを使用してロールバックの状態を監視し、操作履歴をリアルタイムで更新する操作状態 API を使用します。
ノード プールのバージョンをロールバックする
Important
ノード プールのバージョンをロールバックするときは、次の情報に注意してください。
- 古いバージョンを長期的に使用すると、セキュリティ リスクが高まり、最終的にはバージョン スキューの制限によるアップグレードが妨げる可能性があります。 ロールバックは、永続的なソリューションではなく、一時的な復旧メカニズムとして扱います。
- REST API を使用する場合は、最初に Get Upgrade Profile API を呼び出して、最近使用したバージョンを取得できます。 この情報を使用して、ロールバック要求のターゲット バージョンを指定します。
az aks nodepool rollbackコマンドを使用して、ノード プールのバージョンをロールバックします。 次の例では、リソース グループmyNodePool内のmyAKSClusterという名前の AKS クラスター内のmyResourceGroupという名前のノード プールをロールバックします。az aks nodepool rollback --name myNodePool --resource-group myResourceGroup --cluster-name myAKSCluster
ノード プールのロールバック状態を監視する
次のメソッドを使用して、ノード プールのロールバック操作の状態を監視し、正常なロールバックを検証できます。
- クラスターの アクティビティ ログ を検索します。
- クラスターで特定 のアップグレード関連イベント を検索します。
- Azure Event Grid を使用して
AKS イベントをサブスクライブします。 - 自動アップグレード チャネルをサブスクライブする場合は、アップグレード通知に AKS Communication Manager を使用できます。
ロールバック後のベスト プラクティス
ノード プールが正常にロールバックされたら、次のベスト プラクティスを使用して安定性とセキュリティを確保します。
- 根本原因を調査する: 別のアップグレードを試みる前に、アップグレードが失敗した理由を特定します。 アプリケーション ログ、リソース メトリック、互換性の要件を確認します。
- 非運用環境でのテスト: 運用環境を再度アップグレードする前に、開発環境またはステージング環境で新しいバージョンを検証し、問題を再現して解決します。
-
再アップグレードを計画する: ロールバックされたバージョンを無期限に維持しないでください。 セキュリティ パッチとサポートを維持するために、再アップグレードをスケジュールします。
- 重大なセキュリティの問題の場合: 修正が検証された後、数日以内に再アップグレードします。
- アプリケーションの互換性の問題の場合: コードの調整後数週間以内に再アップグレードします。
- 推奨される最大期間: セキュリティの脆弱性の蓄積を回避するために 30 日間。
よく寄せられる質問 (FAQ)
ノード プールのロールバック中に他の操作を実行できますか?
いいえ。ロールバックは、他の操作を開始する前に完了する必要があります。 異なる操作を実行するには、最初にロールバックを中止します。
ノード プールのロールバックでは、Kubernetes のバージョンとノード イメージの両方が元に戻されますか?
はい。ロールバックは、最近使用した Kubernetes バージョンとそれに対応するノード イメージに戻ります。 両方のコンポーネントが変更された場合、システムはそのバージョンの最後の互換性のあるノード イメージを使用して以前の Kubernetes バージョンを復元します。
ノード プールのバージョンを変更せずにノード イメージのみをロールバックできますか?
はい。過去 7 日以内にノード イメージの更新のみを実行した場合 (ノード プールのバージョンをアップグレードせずに)、ロールバックによって以前の仮想ハード ディスク (VHD) イメージが復元され、同じ Kubernetes バージョンが維持されます。
サポート対象外のバージョンにロールバックできますか?
いいえ。AKS でサポートされなくなった Kubernetes バージョンにロールバックすることはできません。 たとえば、ノード プールがバージョン 1.27.9 (現在はサポート対象外) で、1.28.5 にアップグレードした場合、1.27.9 はサポートされているバージョン一覧に含まれなくなったため、ロールバックできません。 バージョンの可用性を確認するには、 AKS Kubernetes バージョンサポート ポリシー を常に確認してください。
ノード プールのロールバックを実行する前に、自動アップグレードを無効にする必要がありますか?
はい。クラスターで自動アップグレードが有効になっている場合は、ロールバックを実行する前に無効にする必要があります。 さらに、クラスターが Azure Kubernetes Fleet Manager 自動アップグレード プロファイルの update グループに含まれている場合は、ロールバックを実行する前に、更新グループからクラスターを削除する必要があります。 そうしないと、ロールバックが完了した後に、自動アップグレード プロセスによってノード プールが自動的にアップグレードされる可能性があります。
OS SKU を変更した後 (たとえば、Ubuntu から Azure Linux に) ロールバックできますか?
No. ノード プールのロールバックはバージョンの変更に限定され、OS SKU の変更は元に戻しません。 ある OS SKU から別の OS SKU (Ubuntu から Azure Linux など) に移行した後、以前のノード イメージのバージョンは古い OS SKU に属し、現在の構成と互換性がありません。 ロールバック操作では、次のようなエラーで以前のイメージ バージョンが拒否されます。
NodeImageVersion 'AKSUbuntu-2204gen2containerd-202602.13.5' is not accepted. NodeImageVersion can only be current version 'AKSAzureLinux-V3gen2-202602.13.5' or 'latest'
OS SKU を元に戻すには、az aks nodepool update パラメーターで --os-sku コマンドを使用します。 詳細については、「 OS バージョンのロールバック」を参照してください。
関連するコンテンツ
AKS でのノード プールのアップグレードの詳細については、次の記事を参照してください。