Container Service for Kubernetes:Horizontal Pod Autoscaler (HPA) の実装

始める前に

HPA 機能をより適切に使用するために、このトピックを読む前に、Kubernetes 公式ドキュメント Horizontal Pod Autoscaling を読んで、HPA の基本原則、アルゴリズムの詳細、およびスケーリング構成を理解することをお勧めします。

さらに、Container Service for Kubernetes (ACK) クラスタは、スケジューリングレイヤーの弾力性のためのさまざまな ワークロードスケーリング ソリューションと、リソースレイヤーの弾力性のための ノードスケーリング ソリューションを提供します。 HPA 機能を使用する前に、自動スケーリング を読んで、さまざまなソリューションの適用可能なシナリオと使用制限を理解することをお勧めします。

前提条件

• ACK マネージドクラスター または ACK 専用クラスター が作成されています。 詳細については、「クラスターの作成」をご参照ください。

• kubectl コマンドを使用して HPA を実装する場合は、kubectl クライアントが Kubernetes クラスタに接続されていることを確認する必要があります。 詳細については、「クラスターの kubeconfig ファイルを取得し、kubectl を使用してクラスターに接続する」をご参照ください。

ACK コンソールで HPA が有効になっているアプリケーションを作成する

ACK は HPA と統合されています。 ACK コンソールで HPA が有効になっているアプリケーションを作成できます。 アプリケーションの作成時、または既存のアプリケーションに対して HPA を有効にできます。 ワークロードに対して HPA が有効になっているアプリケーションは 1 つだけ作成することをお勧めします。

kubectl を使用して HPA が有効になっているアプリケーションを作成する

オーケストレーションテンプレートを使用して HPA を作成し、HPA を有効にするデプロイメントに HPA を関連付けることもできます。 その後、kubectl コマンドを実行して HPA を有効にできます。 ワークロードに対して HPA が有効になっているアプリケーションは 1 つだけ作成することをお勧めします。 次の例では、NGINX アプリケーションに対して HPA が有効になっています。

1. nginx.yml という名前のファイルを作成し、次の内容をファイルにコピーします。

   重要

   アプリケーションに必要な request リソースを構成する必要があります。 そうしないと、HPA を有効にできません。 リソースプロファイリング機能を使用して、リソース使用量の履歴データを分析し、コンテナのリクエストと制限を構成するための推奨事項を取得できます。 詳細については、「リソースプロファイリング」をご参照ください。

   展開して YAML テンプレートを表示する

   apiVersion: apps/v1 
   kind: Deployment
   metadata:
     name: nginx
     labels:
       app: nginx
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: nginx  
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
         - name: nginx
           image: nginx:1.7.9 # 実際の <image_name:tags> に置き換えます。
           ports:
           - containerPort: 80
           resources:
             requests:       # このパラメーターは HPA メトリクスの計算に必要です。 そうしないと、HPA は不明なステータスを表示します。
               cpu: 500m

2. 次のコマンドを実行して、NGINX アプリケーションを作成します。

   kubectl apply -f nginx.yml

3. hpa.yml という名前のファイルを作成し、次の内容をファイルにコピーして HPA を作成します。

   scaleTargetRef パラメーターを使用して、HPA を nginx デプロイメントに関連付け、ポッド内のすべてのコンテナの平均 CPU 使用率が 50% に達したときにスケーリング操作をトリガーします。

   Kubernetes バージョンが 1.24 以後のクラスターの YAML テンプレート

   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: nginx-hpa
   spec:
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: nginx
     minReplicas: 1  # デプロイメントで実行する必要があるコンテナの最小数。 このパラメーターの値は、1 以上の整数である必要があります。
     maxReplicas: 10  # デプロイメントをスケーリングできるコンテナの最大数。 このパラメーターの値は、minReplicas よりも大きくなければなりません。
     metrics:
     - type: Resource
       resource:
         name: cpu
         target:
           type: Utilization
           averageUtilization: 50 # ターゲットリソースの平均使用率。これは、リソース使用量の平均値とそのリクエスト量の比率です。
                  

   Kubernetes バージョンが 1.24 より前のクラスターの YAML テンプレート

   apiVersion: autoscaling/v2beta2
   kind: HorizontalPodAutoscaler
   metadata:
     name: nginx-hpa
   spec:
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: nginx
     minReplicas: 1  # 1 以上の整数である必要があります。
     maxReplicas: 10  # minReplicas よりも大きくなければなりません。
     metrics:
     - type: Resource
       resource:
         name: cpu
         target:
           type: Utilization
           averageUtilization: 50
                  

   CPU とメモリの両方のメトリクスを指定する必要がある場合は、2 つの HPA を作成する代わりに、metrics フィールドの下に cpu と memory の両方のタイプのリソースを指定できます。 HPA は、いずれかのメトリクスがスケーリングしきい値に達したことを検出すると、スケーリング操作を実行します。

   metrics:
     - type: Resource
       resource:
         name: cpu
         target:
           type: Utilization
           averageUtilization: 50
     - type: Resource
       resource:
         name: memory
         target:
           type: Utilization
           averageUtilization: 50

4. 次のコマンドを実行して、HPA を作成します。

   kubectl apply -f hpa.yml

   この時点で、kubectl describe hpa <HPA名> コマンドを実行すると、次の出力に類似した警告が返されます。これは、HPA がまだデプロイされていることを示しています。 この例の HPA 名は nginx-hpa です。 kubectl get hpa コマンドを実行して、HPA のステータスを確認できます。

   Warning  FailedGetResourceMetric       2m (x6 over 4m)  horizontal-pod-autoscaler  missing request for cpu on container nginx in pod default/nginx-deployment-basic-75675f5897-mqzs7
   
   Warning  FailedComputeMetricsReplicas  2m (x6 over 4m)  horizontal-pod-autoscaler  failed to get cpu utilization: missing request for cpu on container nginx in pod default/nginx-deployment-basic-75675f5

5. HPA が作成され、ポッドがスケーリング条件に達するまで待ちます。これは、この例では、NGINX のポッド CPU 使用率が 50% を超えたときです。 その後、kubectl describe hpa <HPA名> コマンドを再度実行して、水平スケーリングステータスを確認します。

   次の出力が返された場合、HPA は想定どおりに実行されています。

   Type    Reason             Age   From                       Message
     ----    ------             ----  ----                       -------
     Normal  SuccessfulRescale  5m6s  horizontal-pod-autoscaler  New size: 1; reason: All metrics below target

関連操作

デフォルトのスケーリング動作がビジネス要件を満たしていない場合は、behavior パラメーターの scaleUp フィールドと scaleDown フィールドを指定して、よりきめ細かいスケールアウトとスケールインの設定を行うことができます。 詳細については、構成可能なスケーリング動作 を参照してください。

behavior でサポートされている一般的なシナリオは次のとおりです。

• トラフィックの急増時に迅速なスケーリングを実現します。

• 負荷の変動が頻繁に発生するシナリオでは、迅速なスケールアップと遅いスケールダウンを実装します。

• 状態に敏感なアプリケーションのスケールダウンを防ぎます。

• リソースに制約のあるシナリオやコストに敏感なシナリオでは、安定化ウィンドウ stabilizationWindowSeconds を使用してスケールアップの速度を制限し、一時的な変動による頻繁な調整を減らします。

behavior パラメーターと構成例の詳細については、「HPA のスケーリング動作を微調整する」をご参照ください。

よくある質問

• HPA メトリクスの現在のフィールドに不明と表示される場合はどうすればよいですか?

• HPA がメトリクスを収集できず、スケーリングを実行できない場合はどうすればよいですか?

• ローリングアップデート中に HPA によって過剰なポッドが追加される場合はどうすればよいですか?

• スケーリングしきい値に達したときに HPA がポッドをスケーリングしない場合はどうすればよいですか?

• HPA のメトリック収集間隔を構成するにはどうすればよいですか?

• CronHPA と HPA は競合なく相互作用できますか? CronHPA を有効にして HPA と相互作用させるにはどうすればよいですか?

• CPU またはメモリの使用量が急激に増加したときに HPA によって過剰なポッドが追加される問題を修正するにはどうすればよいですか?

• 監査ログのメトリック値がしきい値よりも低いときに HPA がアプリケーションをスケールアウトする場合はどうすればよいですか?

• HPA は、ポッドがスケールインされる順序を決定できますか?

• HPA によって収集された使用率メトリックの単位は何を意味しますか?

• kubectl get hpa コマンドを実行した後に TARGETS 列に不明と表示される場合はどうすればよいですか?

• HPA でサポートされているメトリクスを見つけるにはどうすればよいですか?

• NGINX Ingress ログの形式をカスタマイズした後に、水平自動スケーリングを構成するにはどうすればよいですか?

参考資料

その他の関連ドキュメント

• Alibaba Cloud メトリクスに基づいて HPA を実装するために、Kubernetes でサポートされている外部メトリクスを構成する方法の詳細については、「Alibaba Cloud メトリクスに基づいて水平自動スケーリングを実装する」をご参照ください。

• HPA を実装するために、Managed Service for Prometheus メトリクスを HPA でサポートされているメトリクスに変換する方法の詳細については、「Managed Service for Prometheus メトリクスに基づいて水平自動スケーリングを実装する」をご参照ください。

• HPA の使用時に発生する可能性のあるよくある質問については、トラブルシューティングのために「ノード自動スケーリングに関するよくある質問」をご参照ください。

• CronHPA と HPA が競合なく相互作用できるようにする方法の詳細については、「CronHPA を HPA と互換性を持たせる」をご参照ください。

その他の ワークロードスケーリング ソリューション

• アプリケーションリソースの使用量に定期的な変更があり、Crontab のような戦略に従ってポッドを定期的にスケーリングする必要がある場合は、「スケジュールされた水平スケーリングに CronHPA を使用する」をご参照ください。

• アプリケーションリソースの使用量にルールで定義するのが難しい周期的な変更がある場合は、Advanced Horizontal Pod Autoscaling (AHPA) を使用してリソース使用サイクルを自動的に識別し、履歴メトリクスに基づいてポッドをスケーリングできます。 詳細については、「AHPA に基づく予測スケーリング」をご参照ください。

• ポッドが十分な計算リソースを取得できるように、ポッドリソースの使用量に基づいてポッドのリソース制限を自動的に設定する必要がある場合は、「Vertical Pod Autoscaler (VPA)」をご参照ください。

• メッセージキュー、タイミング戦略、カスタムメトリック、その他の Kubernetes イベントに基づいてポッドのスケーリングポリシーを柔軟にカスタマイズする必要がある場合は、「イベント駆動型自動スケーリング」をご参照ください。

組み合わせソリューション

ノード自動スケーリング 機能と HPA を使用して、クラスタノードリソースが不足しているときにノードを自動的にスケーリングできます。 詳細については、「ノード自動スケーリングを有効にする」をご参照ください。