概念 - Kubernetes スケーリング オプション
需要の増加に対応するためにポッドの数をスケーリングするだけでは不十分な場合もあります。 平日と夜間、または週末など、アプリケーションの変則的な需要に対応するために、多くの場合、クラスターには自動的にスケーリングする方法が必要になります。
Kubernetes のスケーリング オプション
Kubernetes クラスターは、次のいずれかのコンポーネントを使用してスケーリングできます。
- クラスター自動スケーラー。リソースの制約によりノード上でスケジュールできないポッドを監視します。 クラスターは、需要に合わせてノード数を自動的に増やします。
- 水平ポッド自動スケーラー (HPA)。Kubernetes クラスター内のメトリック サーバーを使ってポッドのリソース需要を監視します。 アプリケーションで必要なリソースが増えると、その需要を満たすためにポッドの数が自動的に増やされます。
また、HPA とクラスター自動スケーラーの両方で、必要に応じてポッドとノードの数を減らすことができます。 クラスター自動スケーラーは、一定期間未使用の容量があった場合、ノードの数を減らします。 クラスター自動スケーラーによって削除する必要があるポッドがノード上にある場合、クラスター内の他の場所で安全にスケジュールされます。
次のようにポッドが移動できない状況では、クラスター自動スケーラーによるスケールダウンを実行できない可能性があります。
- ポッドが直接作成されており、Deployment や ReplicaSet などのコントローラー オブジェクトによってサポートされていない。
- Pod Disruption Budget (PDB) の制限が非常に厳しく、ポッドの数が特定のしきい値を下回ることが許可されていない。
- ポッドが、別のノードでスケジュールされた場合に適用できないノード セレクターまたはアンチ アフィニティーを使用している。
KEDA と HPA の併用
KEDA は "カスタム メトリック API" として機能し、スケーラーを使ってメトリックを HPA に公開し、メトリック サーバーの開発プロセスを簡略化します。
スケーラーを使うと、さまざまなソースのメトリックを HPA に提供できます。 KEDA は、次のようなさまざまなスケーラーをサポートしています。
- Apache Kafka
- AWS CloudWatch
- AWS Kinesis Stream
- AWS SQS Queue
- Azure Blob Storage
- Azure Event Hubs
- Azure Log Analytics
- Azure Monitor
- Azure Service Bus
- Azure Storage キュー
- Google Cloud Platform Pub/Sub
- IBM MQ
- InfluxDB
- NATS Streaming
- OpenStack Swift
- PostgreSQL
- Prometheus
- RabbitMQ キュー
- Redis リスト
完全な一覧については、「Currently available scalers for KEDA」(KEDA で現在使用できるスケーラー) を参照してください。