Concept - Options de mise à l’échelle de Kubernetes

  • 5 minutes

Parfois, la mise à l’échelle du nombre de pods pour gérer une demande accrue n’est pas suffisante. Pour faire face à l’évolution des demandes applicatives, par exemple entre les journées de travail et les soirées ou pendant les week-ends, les clusters ont souvent besoin d’être mis à l’échelle automatiquement.

Options de mise à l’échelle de Kubernetes

Les clusters Kubernetes peuvent être mis à l’échelle à l’aide de l’un des composants suivants :

  • L’Autoscaler de cluster, qui recherche les pods qui ne peuvent pas être planifiés sur des nœuds en raison de contraintes de ressources. Le cluster augmente automatiquement le nombre de nœuds pour répondre à la demande.
  • L’Autoscaler de pod horizontal (HPA), qui utilise le serveur de métriques d’un cluster Kubernetes pour superviser la demande en ressources des pods. Si une application a besoin de davantage de ressources, le nombre de pods est automatiquement augmenté pour répondre à la demande.

Le HPA et l’Autoscaler de cluster peuvent également réduire le nombre de pods et de nœuds en fonction des besoins. L’Autoscaler de cluster diminue le nombre de nœuds en cas de capacité inutilisée pendant une période de temps. Les pods d’un nœud que l’Autoscaler de cluster doit supprimer sont planifiés sans problème ailleurs dans le cluster.

L’Autoscaler de cluster pourrait ne pas être en mesure d’effectuer un scale-down dans les situations où les pods ne peuvent pas se déplacer, par exemple :

  • Un pod est créé directement et n’est pas pris en charge par un objet de contrôleur, comme un Deployment ou un ReplicaSet.
  • Un budget d’interruption de pods est trop restrictif et n’autorise pas la diminution du nombre de pods au-dessous d’un certain seuil.
  • Un pod utilise des sélecteurs de nœud ou l’anti-affinité qui ne peuvent pas être respectés s’ils sont planifiés sur un autre nœud.

Utilisation de KEDA avec le HPA

KEDA agit en tant qu’API de métriques personnalisées, à l’aide de scalers pour exposer des métriques au HPA, ce qui simplifie le processus de développement d’un serveur de métriques.

Les scalers aident à fournir des métriques provenant de différentes sources au HPA. KEDA prend en charge un large éventail de scalers, notamment :

  • Apache Kafka
  • AWS CloudWatch
  • AWS Kinesis Stream
  • AWS SQS Queue
  • Stockage Blob Azure
  • Azure Event Hubs
  • Azure Log Analytics
  • Azure Monitor
  • Azure Service Bus
  • File d’attente de stockage Azure
  • Google Cloud Platform Pub/Sub
  • IBM MQ
  • InfluxDB
  • NATS Streaming
  • OpenStack Swift
  • PostgreSQL
  • Prometheus
  • File d’attente RabbitMQ
  • Redis Lists

Pour obtenir la liste complète, consultez les Scalers actuellement disponibles pour KEDA.

Contrôle des connaissances

1.

Votre charge de travail effectue une transformation de photo nécessitant beaucoup de processeur. Quelle option de mise à l’échelle devez-vous choisir ?

2.

Votre cluster utilise presque toutes les ressources disponibles pendant les heures de pointe. Quelle option de mise à l’échelle devez-vous utiliser ?

3.

Votre service traite les messages à partir d’une file d’attente Apache Kafka. Quelle option de mise à l’échelle devez-vous choisir ?