仮想マシン (VM) のサイズを変更して、増加するデプロイに対応したり、より大きなワークロードを実行したりできます。 AKS のサポート ポリシーで説明されているように、AKS で 仮想マシン スケール セット を使用する場合、 AKS インスタンスの直接サイズ変更はサポートされません。
AKS エージェント ノードは、Azure portal で通常の Azure IaaS リソースとして表示されます。 しかし、これらの仮想マシンは、カスタムの Azure リソース グループ (通常は先頭に MC_* が付加されている) にデプロイされます。 IaaS API またはリソースを使用してこれらのノードに直接カスタマイズすることはできません。 AKS API 経由で行われないカスタム変更は、アップグレード、スケーリング、更新、または再起動によって保持されません。
この記事では、目的の SKU サイズで新しいノード プールを作成し、既存のノードをコードしてドレインし、既存のノード プールを削除することで、ノード プールのサイズを変更するための推奨される方法について説明します。
重要
この方法は、 仮想マシン スケール セットベースの AKS クラスターに固有です。 Virtual Machines ベースのノード プールを使用する場合、1 つの Azure CLI コマンドを使用して既存のノード プール内の VM サイズを簡単に更新でき、同じノード プールに複数の VM サイズを含めることができます。 詳細については、 仮想マシン ノード プールのドキュメントを参照してください。
VMSS ノード プールのサイズを変更する (プレビュー)
重要
AKS のプレビュー機能は、セルフサービスのオプトイン単位で利用できます。 プレビューは、"現状有姿のまま" および "利用可能な限度" で提供され、サービス レベル アグリーメントおよび限定保証から除外されるものとします。 AKS プレビューは、ベストエフォート ベースでカスタマー サポートによって部分的にカバーされます。 そのため、これらの機能は運用環境での使用を目的としていません。 詳細については、次のサポート記事を参照してください。
az aks nodepool update --node-vm-size <new-size>を使用して、1 つのコマンドで既存の VMSS ベースのノード プールの VM サイズ (SKU) のサイズを変更できるようになりました。 この更新プログラムをトリガーすると、AKS リソース プロバイダーは次の方法でローリング アップグレードを実行します。
- ターゲット VM サイズで新しいノードを急増させる。
- 古いノードのコード化とドレイン。
- 古いノードの削除。
これにより、この記事の残りの部分で説明されている手動の作成/cordon/drain/delete ワークフローが回避されます。
サイズ変更のロールアウトのしくみ
サイズ変更ロールアウトでは、 ノード イメージのアップグレード と Kubernetes バージョンのアップグレードと同じローリング アップグレード エンジンが使用されるため、ノード プールで既に構成されている次のアップグレード関連の設定が適用されます。 特に、サイズ変更では次の点が考慮されます。
-
最大サージ (
--max-surge): ロールアウト中にターゲット VM サイズを持つ追加ノードの数を制御します。 値を大きくすると、プールのサイズが速くなりますが、コンピューティングと IP クォータが多くなります。値を小さくすると遅くなりますが、中断が少なくなります。 AKS の既定値は1であり、運用ノード プールには33%をお勧めします。 -
ノード ドレイン タイムアウト (
--drain-timeout): AKS が、古いノードのポッドの強制削除を行う前に、そのノードのポッドの強制削除を待機する時間。 既定値は 30 分です。 これを適切な PodDisruptionBudgets と組み合わせることで、ワークロードを安全にドレインできるようにします。 -
ノード のソーク期間 (
--node-soak-duration): 新しいノードが準備完了になってから次のバッチに進むまで AKS が待機する時間。 ロールアウトを続行する前に、新しい VM サイズでワークロードを安定させるのに役立ちます。
サイズ変更によってアップグレード パイプラインが再利用されるため、同じ前提条件が適用されます。サブスクリプションに十分なターゲット VM サイズの置換容量とサージ ノード用の使用可能なサブネット IP があることを確認し、PodDisruptionBudgets で一度に少なくとも 1 つのレプリカを削除できるようにしてください。そうしないと、ドレイン中にサイズ変更をブロックできます。 エンド ツー エンドの推奨事項については、 AKS ノード プールのアップグレードのベスト プラクティスに関するページを参照してください。
前提条件
- AKS API バージョン
2026-01-02-preview以降。 - aks-preview Azure CLI拡張機能の最新バージョン。
ノード プールのサイズを変更する
az aks nodepool update パラメーターで --node-vm-size コマンドを使用して、既存の VMSS ベースのノード プールの VM サイズを変更します。
az aks nodepool update \
--resource-group MyResourceGroup \
--cluster-name MyManagedCluster \
--name nodepool1 \
--node-vm-size Standard_D4s_v3
検証とサポートされていない組み合わせ
AKS リソース プロバイダーはサイズ変更要求を検証し、互換性のない VM サイズの変更をブロックします。 次の変更は、インプレース VMSS サイズ変更の一部として サポートされていません 。
- ディスク コントローラーの種類の変更 (SCSI から NVMe など)。
- CPU アーキテクチャの変更 (例: x64 から ARM64)。
- コンフィデンシャル コンピューティングのサポートの変更 (SNP の有効化または無効化など)。
- ハイパーバイザーの生成 (V1 から V2 など) の変更。
- 同じ操作で、サイズ変更と Kubernetes バージョンのアップグレード または ノード数の変更 を組み合わせる。
ターゲット VM のサイズに上記のいずれかの変更が必要な場合は、代わりに、次のセクションで説明する手動の cordon-and-drain ワークフローを使用してください。
Note
インプレース リサイズでは、古いノードをドレインする前に、対象の VM サイズで新しいノードをプロビジョニングするための一時的な追加容量が必要です。 ノード プールが --max-surge 0 で構成されている場合 (つまり、 --max-unavailable が有効です)、サイズ変更要求は 400 Bad Requestで拒否されます。 次に進むには、 --max-surge を、サイズ変更時に少なくとも 1 に設定します。
az aks nodepool update \
--resource-group MyResourceGroup \
--cluster-name MyManagedCluster \
--name nodepool1 \
--node-vm-size Standard_D4s_v3 \
--max-surge 33%
必要に応じて、元の --max-surge と --max-unavailable の値をサイズ変更の完了後に復元します。
目的の SKU を使用して新しいノード プールを作成する
Note
各 AKS クラスターには、少なくとも 1 つのノードを含むシステム ノード プールが、少なくとも 1 つ含まれている必要があります。 この例では、サイズ変更するシステム ノード プールを置き換えるために--modeのSystemを使って、新しいシステム ノード プールを追加します。
ノード プールのモードはいつでも更新できます。
--modeを User に設定して、ユーザー ノード プールを追加することもできます。
サイズを変更するときは、可用性ゾーンなど、すべてのワークロード要件を考慮し、それに応じて VMSS ノード プールを構成してください。 必要に応じて、次のコマンドを変更する必要があります。 構成オプションの完全な一覧については、az aks nodepool add のリファレンス ページを参照してください。
az aks nodepool addコマンドを使用して、新しいノード プールを作成します。 この例では、mynodepoolVM SKU を持つ既存のノード プール (Standard_DS3_v2) を置き換えるために、3 つのノードとnodepool1VM SKU を含む新しいノード プールStandard_DS2_v2を作成します。az aks nodepool add \ --resource-group myResourceGroup \ --cluster-name myAKSCluster \ --name mynodepool \ --node-count 3 \ --node-vm-size Standard_DS3_v2 \ --mode System \ --no-wait新しいノード プールが作成されるまで数分かかります。
kubectl get nodesコマンドを使用して、新しいノード プールの状態を取得します。kubectl get nodes出力は次の出力例のようになります。新しいノード プール
mynodepoolと既存のノード プールnodepool1の両方が表示されます。NAME STATUS ROLES AGE VERSION aks-mynodepool-98765432-vmss000000 Ready agent 23m v1.21.9 aks-mynodepool-98765432-vmss000001 Ready agent 23m v1.21.9 aks-mynodepool-98765432-vmss000002 Ready agent 23m v1.21.9 aks-nodepool1-12345678-vmss000000 Ready agent 10d v1.21.9 aks-nodepool1-12345678-vmss000001 Ready agent 10d v1.21.9 aks-nodepool1-12345678-vmss000002 Ready agent 10d v1.21.9
既存のノードの切断
切断では、指定されたノードをスケジュール不可としてマークし、追加のポッドがノードに追加されないようにします。
kubectl get nodesコマンドを使用して、切断するノードの名前を取得します。kubectl get nodes出力は次の出力例のようになり、既存のノード プール内の隔離したいノード
nodepool1を示します。NAME STATUS ROLES AGE VERSION aks-nodepool1-12345678-vmss000000 Ready agent 7d21h v1.21.9 aks-nodepool1-12345678-vmss000001 Ready agent 7d21h v1.21.9 aks-nodepool1-12345678-vmss000002 Ready agent 7d21h v1.21.9kubectl cordonコマンドを使用して既存のノードを切断し、スペース区切りリスト内の目的のノードを指定します。 例えば次が挙げられます。kubectl cordon aks-nodepool1-12345678-vmss000000 aks-nodepool1-12345678-vmss000001 aks-nodepool1-12345678-vmss000002出力は次の出力例のようになります。ノードが切断されていることを示しています。
node/aks-nodepool1-12345678-vmss000000 cordoned node/aks-nodepool1-12345678-vmss000001 cordoned node/aks-nodepool1-12345678-vmss000002 cordoned
既存のノードのドレイン
重要
ノードを適切にドレインして実行中のポッドを強制削除するには PodDisruptionBudgets (PDB) で一度に少なくとも 1 つのポッド レプリカを確実に移動できるようにします。 それ以外の場合、ドレイン/退去操作はできません。 これを確認するには、 kubectl get pdb -A を実行し、 ALLOWED DISRUPTIONS が少なくとも 1 以上であることを確認します。
ノードをドレインすると、そのノードで実行中のポッドは退避され、他のスケジュール可能なノードで再スケジュールされます。
kubectl drainフラグと--ignore-daemonsetsフラグを指定して、--delete-emptydir-dataコマンドを使用して既存のノードをドレインし、スペース区切りの一覧で目的のノードを指定します。 例えば次が挙げられます。重要
AKS で作成された
--delete-emptydir-dataとcorednsポッドを強制削除するには、metrics-serverを使用する必要があります。 このフラグを使用しない場合は、エラーが発生します。 詳細については、emptydir に関するドキュメントを参照してください。kubectl drain aks-nodepool1-12345678-vmss000000 aks-nodepool1-12345678-vmss000001 aks-nodepool1-12345678-vmss000002 --ignore-daemonsets --delete-emptydir-dataドレイン操作が完了したら、すべてのポッド (デーモン セットによって制御されるポッドを除く) が新しいノード プールで実行されている必要があります。 これは、
kubectl get podsコマンドを使用して確認できます。kubectl get pods -o wide -A
ポッドの削除に関する問題のトラブルシューティング
ノードをドレインすると、次のエラーが発生する可能性があります。
Error when evicting pods/[podname] -n [namespace] (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
既定では、クラスターには AKS によって管理されるポッドの中断予算（たとえば coredns-pdb や konnectivity-agent）があり、MinAvailable は 1 です。 たとえば、2 つの coredns ポッドが実行されている場合、一度に中断できるポッドは 1 つだけです。 そのうちの 1 つが再作成され、使用できませんが、ポッドの中断予算のために、もう 1 つの coredns ポッドを削除することはできません。 この問題は、最初の coredns ポッドがスケジュールされて実行された後に解決され、2 つ目のポッドを適切に削除して再作成できます。
ヒント
スムーズな退避エクスペリエンスを得るため、そしてスロットリングを回避するために、ノードを 1 つずつドレインすることを検討してください。 詳細については、次を参照してください。
既存のノード プールを削除する
重要
ノード プールを削除すると、AKS は cordon および drain を実行しません。 削除を予定しているノード プールで現在実行されているポッドを再スケジュールすることによる中断を最小限に抑えるために、削除する前にノード プール内のすべてのノードで cordon と drain を実行します。
az aks nodepool deleteコマンドを使用して、元のノード プールを削除します。az aks nodepool delete \ --resource-group myResourceGroup \ --cluster-name myAKSCluster \ --name nodepool1kubectl get nodesコマンドを使用して、アプリケーションとポッドが正常に実行されている新しいノード プールのみが AKS クラスターにあることを確認します。kubectl get nodes出力は次の出力例のようになります。新しいノード プールの
mynodepoolのみが表示されます。NAME STATUS ROLES AGE VERSION aks-mynodepool-98765432-vmss000000 Ready agent 63m v1.21.9 aks-mynodepool-98765432-vmss000001 Ready agent 63m v1.21.9 aks-mynodepool-98765432-vmss000002 Ready agent 63m v1.21.9
次のステップ
切断とドレインによってノード プールのサイズを変更した後は、複数のノードプールの使用について詳細を確認してください。