Azure Kubernetes Service (AKS)でアプリケーションを実行すると、需要の変化に合わせてポッド、ポッド リソース、ノード、またはイベント ドリブン ワークロードをスケーリングできます。 AKS では、手動スケーリング、ポッドの水平オートスケーラー (HPA)、垂直ポッド オートスケーラー (VPA)、クラスター オートスケーラー、Kubernetes イベント ドリブン自動スケール (KEDA)、ノード自動プロビジョニング、および Azure Container Instances (ACI) によるバースト スケーリングがサポートされています。
適切なスケーリング方法を選択する
| スケーリング メソッド | 最適な用途 | キー メトリック | ガイド |
|---|---|---|---|
| 水平ポッド オートスケーラー (HPA) | 需要が変動するステートレスまたは分割可能なワークロード | CPU 使用率、RPS、キューの深さ | Kubernetes で水平ポッド自動スケーリング (HPA) を使用する必要がある場合 |
| 垂直ポッド オートスケーラー (VPA) | 並列化できないワークロード。ポッド リソース要求のサイズを適切に設定する | CPU/メモリ リソースの使用量 | AKS で垂直ポッド オートスケーラーを使用する |
| クラスター オートスケーラー | Pod が Pending のままの場合のノードレベルの容量 | 保留中のポッド | AKS でクラスター オートスケーラーを使用する |
| KEDA | イベント駆動型ワークロード; ゼロまでのスケールが必須 | キューの長さ、イベント バックログ | KEDA アドオンの概要 |
| ACI バーストスケーリング | ノードプールの容量を超える急増への対応 | 需要の急増 | Azure Container Instancesを使用して仮想ノードを作成する |
ポッドまたはノードを手動でスケーリングする
ポッドのレプリカとノードを手動でスケーリングして、使用可能なリソースの変更に対するアプリケーションの応答方法をテストしたり、固定容量を維持したりできます。 手動でスケーリングするには、必要なレプリカまたはノード数を定義します。 その後、Kubernetes はポッドを作成または削除しますが、AKS は該当するノード プールにノードを追加または削除します。
ノードをスケールダウンすると、AKS はクラスターのコンピューティングの種類に関連する Azure コンピューティング API を呼び出します。 Virtual Machine Scale Sets上に構築されたクラスターの場合、Virtual Machine Scale Sets API によって削除するノードが決定されます。 詳細については、Virtual Machine Scale Sets FAQ を参照してください。
作業を開始するには、次を参照してください。
ホリゾンタルポッドオートスケーラー
ワークロードで複数の同一レプリカを実行でき、需要が変動する場合は、HPA を使用します。 CPU/メモリ、アプリケーション メトリック (1 秒あたりの要求数、待機時間)、または外部キューとバックログのメトリックにスケーリングされ、ノード容量のクラスター オートスケーラーと組み合わせる必要があります。
詳細情報: Kubernetes で水平ポッド自動スケーリング (HPA) を使用する必要があるタイミング
AKS で Vertical Pod Autoscaler を使用して、ポッドの CPU 要求とメモリ要求のサイズを適切に設定する方法も参照してください。
垂直ポッドオートスケーラー (Vertical Pod Autoscaler)
垂直ポッド オートスケーラーは、ポッドの CPU とメモリの使用状況を分析し、適切なリソース要求を推奨または適用します。 VPA を使用して、レプリカを追加して効率的にスケーリングできないワークロードのサイズを適切に設定したり、スケジュールとリソース使用率を向上させたりします。
VPA は、更新モードに応じて、ポッドの作成時または削除時に推奨事項を適用し、更新されたリソース要求でポッドを再作成できます。 VPA で変更を自動的に適用できるようにする前に、ワークロードの可用性要件を確認します。
開始するには、 AKS での垂直ポッド 自動スケーラーの使用に関するページを参照してください。
クラスター オートスケーラー
クラスター オートスケーラーは、ポッドのスケジュール要件に従って、ノード プール内のノードの数を調整します。 ノード容量が不十分なためポッドをスケジュールできない場合はノードを追加し、ワークロードが他の場所で実行できる場合は使用率の低いノードを削除します。
クラスター オートスケーラーは、 HPA でよく使用されます。 HPA はワークロードの需要に基づいてポッド レプリカの数を調整し、クラスター オートスケーラーはこれらのポッドに対応するようにノード容量を調整します。
開始するには、「 AKS でクラスター オートスケーラーを使用する」を参照してください。
スケールアウト イベント
ノード プールにポッド用の十分なコンピューティング リソースがない場合、ポッドは保留中のままです。 クラスター オートスケーラーは、ノード プール リソースの制約のためにスケジュールできないポッドを検出すると、ノード プール内のノードの数が増えます。 Kubernetes は、新しいノードがプロビジョニングされて準備が整った後、保留中のポッドをスケジュールします。
VM ベースのノードのプロビジョニングには数分かかる場合があります。 急激なバースト需要があるワークロードの場合は、仮想ノードとAzure Container Instancesの使用を検討してください。
スケールイン イベント
クラスター オートスケーラーは、ノードの使用率が低いかどうかを監視し、ポッドが他のノードで実行できるかどうかを判断します。 ノードが不要になると、Kubernetes はそのポッドを再スケジュールし、AKS はノード プールからノードを削除します。
スケールイン操作では、ポッドがノード間を移動するとワークロードが中断される可能性があります。 複数のポッド レプリカを実行し、中断を最小限に抑えるために適切な可用性制御を構成します。
Kubernetes イベント駆動自動スケーリング
Kubernetes イベント ドリブン自動スケーリング (KEDA) は、イベントに基づいてワークロードをスケーリングするオープンソース コンポーネントです。 KEDA は、ワークロードがイベント ソースまたはメトリックに応答する方法を記述するカスタム リソース ( ScaledObject を含む) を使用して Kubernetes を拡張します。
KEDA は、キュー、ストリーム、メッセージ、またはその他のイベント バックログを処理するワークロードに役立ちます。 使用可能なイベントがない場合は、サポートされているワークロードをゼロにスケーリングし、バックログが大きくなるにつれてレプリカを増やすことができます。
開始するには、 KEDA アドオンの概要を参照してください。
ノードの自動プロビジョニング
ノード自動プロビジョニング (NAP) では、オープン ソース の Karpenter プロジェクトを使用して、保留中のポッド要件に従ってノードをプロビジョニングおよび管理します。 NAP は、リアルタイムワークロードの需要を満たすために、適切な仮想マシン SKU とノード数量を選択します。
NAP は、許可された一連の VM SKU から始まり、保留中のワークロードの容量を選択します。 リソースの制限とスケジュール設定を定義して、ノードのプロビジョニング方法とワークロードの分散方法を制御できます。
コントロールプレーンのスケーリングと保護機能
Kubernetes には、各リソースの種類がコントロール プレーンに異なる要求を配置する多次元スケール エンベロープがあります。 たとえば、シークレットなどのリソースを監視すると、Kubernetes API サーバーへのリスト呼び出しが生成され、ウォッチのないリソースよりも多くのコントロール プレーンの負荷が作成されます。
コントロール プレーンはクラスター全体のリソース操作を管理するため、1 つのディメンションで大きくスケーリングすると、他のディメンションで使用できる容量を減らすことができます。 たとえば、何十万ものポッドを実行すると、コントロール プレーンがサポートするポッドの変異率に影響する可能性があります。 推奨事項については、 大規模な AKS クラスターの Kubernetes クライアントのベスト プラクティスを参照してください。
AKS は、クラスター コアの合計数や、コントロール プレーン コンポーネントの CPU またはメモリ負荷などの信号に基づいて、コントロール プレーン コンポーネントを自動的にスケーリングします。
コントロール プレーンがスケールアップされたかどうかを確認するには、 large-cluster-control-plane-scaling-status ConfigMap を調べます。
kubectl describe configmap large-cluster-control-plane-scaling-status -n kube-system
コントロール プレーンの保護機能
API サーバーを自動的にスケーリングしても高負荷で安定しない場合、AKS はマネージド API サーバー ガードをデプロイできます。 この最終手段の保護機能は、コントロール プレーンが応答不能になるのを防ぐために、非システム クライアントからのリクエストを抑制します。
kubeletなどのコンポーネントからのシステム クリティカルな API サーバー呼び出しは引き続き機能します。
マネージド API サーバー ガードが適用されているかどうかを確認するには、 aks-managed-apiserver-guardFlowSchema と PriorityLevelConfigurationを確認します。
kubectl get flowschemas
kubectl get prioritylevelconfigurations
これらのリソースが存在する場合は、軽減策のガイダンスについては、 API サーバーと etcd トラブルシューティング ガイドを 参照してください。
Azure Container Instances (ACI) へのバースト
AKS をAzure Container Instancesと統合して、需要の急速な増加に対応できます。 ポッドの自動スケーリングでは、既存のノード プールでサポートできる数よりも多くのレプリカが作成される可能性があります。一方、追加の VM ベースのノードのプロビジョニングには数分かかる場合があります。 ACI は、追加の VM ノードを必要とせずにコンピューティング容量を提供します。
AKS 仮想ノード コンポーネントは Virtual Kubelet に基づいており、ACI を仮想 Kubernetes ノードとして提供します。 Kubernetes では、AKS VM ノード上で直接実行するのではなく、仮想ノードを介して対象となるポッドを ACI コンテナー インスタンスとして実行するようにスケジュールできます。
仮想ノードは、AKS クラスターと同じ仮想ネットワーク内の別のサブネットを使用します。 この構成により、AKS と ACI の間のプライベート ネットワーク接続が提供され、ACI がクラスターの論理拡張機能として機能できるようになります。
次のステップ
ワークロードに合ったスケーリング方法を実装するには、次のリソースを使用します。
- ポッドまたはノードを手動でスケーリングする
- Kubernetes で水平ポッド自動スケーリング (HPA) を使用する必要がある場合
- AKS で垂直ポッド オートスケーラーを使用する
- AKS でクラスター オートスケーラーを使用する
- KEDA アドオンを使用する
- ノードの自動プロビジョニングを使用する
- Azure Container Instancesを使用して仮想ノードを作成する
Kubernetes と AKS のコア概念の詳細については、次を参照してください。