Une situation courante: vous avez plusieurs applications, l'une d'entre elles a une charge de pointe pendant la journée, et à d'autres heures, personne n'y accède (ou on y accède, mais rarement); tandis que d'autres applications peuvent utiliser la puissance du cluster la nuit. Comme exemple de telles applications, nous pouvons citer les services Web, certains gestionnaires de données.

Comme d'habitude, les ressources du cluster ne suffisent pas du tout. Vous devez trouver quelque chose pour optimiser l'utilisation des ressources, et Kubernetes est idéal pour cela. Il dispose d'un autoscaler à pod horizontal , qui vous permet de faire évoluer les applications en fonction de métriques.



Les métriques sont généralement fournies par le serveur de métriques . Ensuite, je vais parler du remplacement du serveur de métriques par Prometheus (parce que Prometheus implémente les données que le serveur de métriques fournit et nous nous débarrassons d'un lien supplémentaire) et comment faire évoluer nos applications dans Kubernetes en fonction des métriques de Prometheus.

Pour commencer, installez l' opérateur Prometheus . Personnellement, j'utilise des manifestes prêts à l' emploi. Vous pouvez utiliser le tableau pour Helm (mais je n'ai pas vérifié ses performances). Supprimez également le serveur de métriques, si vous en avez un. Après cela, vérifiez si tout fonctionne comme il se doit.

# kubectl get --raw "/apis/metrics.k8s.io/v1beta1/" | jq { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "metrics.k8s.io/v1beta1", "resources": [ { "name": "nodes", "singularName": "", "namespaced": false, "kind": "NodeMetrics", "verbs": [ "get", "list" ] }, { "name": "pods", "singularName": "", "namespaced": true, "kind": "PodMetrics", "verbs": [ "get", "list" ] } ] } 

Ensuite, appliquez les manifestes de ce répertoire . Cela installera l'adaptateur Prometheus. J'ai trouvé un tableau contenant ces manifestes, mais je ne l'ai pas vérifié. Après cela, vous devez exécuter la commande correctement:

 kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq 

(il y aura une très grande liste, donc je ne la listerai pas ici)

Pour comprendre la signification des URL metrics.k8s.io et custom.metrics.k8s.io, la documentation peut vous aider.

Si quelque chose ne fonctionne pas, regardez comme d'habitude dans les journaux. Vous pouvez également rechercher une solution aux problèmes .

Configurez maintenant la mise à l'échelle automatique.

J'ai une application qui consomme beaucoup de ressources processeur et sert la file d'attente. Dès que la taille de la file d'attente dépasse un certain seuil, je souhaite augmenter le nombre de foyers dans le jeu de répliques pour traiter la file d'attente plus rapidement. Dès que sa taille devient inférieure au seuil, les ressources du cluster doivent être libérées.

Pour comprendre comment écrire des règles pour l'adaptateur Prometheus, vous devez lire attentivement ce document et ses pages associées. Voilà à quoi ça ressemble avec moi.

Demande à Prométhée

 wqueue_tube_total_size{tube="dmload-legacy"} 

il renvoie:

 wqueue_tube_total_size{endpoint="pprof-port",instance="10.116.2.237:8542",job="wqueue-pprof",namespace="default",pod="wqueue-b9fdd9455-66mwm",service="wqueue-pprof",tube="dmload-legacy"} 32 

Et j'écris la règle suivante pour l'adaptateur Prometheus:

 - seriesQuery: wqueue_tube_total_size{tube="dmload-legacy"} resources: overrides: namespace: resource: namespace tube: resource: service name: {as: "wqueue_tube_total_size_dmload_legacy"} metricsQuery: wqueue_tube_total_size{tube="dmload-legacy"} 

Il convient de noter que je dois mapper le paramètre de tube en service , puis utiliser hpa dans la description.

Configuration HPA:

 --- kind: HorizontalPodAutoscaler apiVersion: autoscaling/v2beta1 metadata: name: dmload-v3-legacy namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: dmload-v3-legacy minReplicas: 2 maxReplicas: 20 metrics: - type: Object object: metricName: wqueue_tube_total_size_dmload_legacy target: apiVersion: v1 kind: Service name: dmload-legacy targetValue: 30 

Ici, je souligne que dès que le nombre de tâches dans la file d'attente wqueue_tube_total_size_dmload_legacy dépasse 30, ajoutez des pods jusqu'à ce qu'il y en ait 20, et si targetValue tombe en dessous de 30, puis réduisez à 2.

Nous postulons et voyons ce qui se passe. Mon système fonctionne pendant plusieurs jours et pour le moment il ne fait que réduire le nombre de foyers:

 # kubectl describe hpa dmload-v3-legacy Name: dmload-v3-legacy Namespace: default Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"autoscaling/v2beta1","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"dmload-v3-legacy","namespace":"d... CreationTimestamp: Thu, 24 Jan 2019 16:16:43 +0300 Reference: Deployment/dmload-v3-legacy Metrics: ( current / target ) "wqueue_tube_total_size_dmload_legacy" on Service/dmload-legacy: 14 / 30 Min replicas: 2 Max replicas: 20 Deployment pods: 15 current / 14 desired Conditions: Type Status Reason Message ---- ------ ------ ------- AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 14 ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from Service metric wqueue_tube_total_size_dmload_legacy ScalingLimited False DesiredWithinRange the desired count is within the acceptable range Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulRescale 59m (x14 over 40h) horizontal-pod-autoscaler New size: 13; reason: All metrics below target Normal SuccessfulRescale 59m (x13 over 40h) horizontal-pod-autoscaler New size: 12; reason: All metrics below target Normal SuccessfulRescale 57m (x14 over 40h) horizontal-pod-autoscaler New size: 11; reason: All metrics below target Normal SuccessfulRescale 56m (x14 over 40h) horizontal-pod-autoscaler New size: 10; reason: All metrics below target Normal SuccessfulRescale 56m (x11 over 38h) horizontal-pod-autoscaler New size: 8; reason: All metrics below target Normal SuccessfulRescale 55m (x6 over 36h) horizontal-pod-autoscaler New size: 7; reason: All metrics below target Normal SuccessfulRescale 47m (x103 over 40h) horizontal-pod-autoscaler (combined from similar events): New size: 20; reason: Service metric wqueue_tube_total_size_dmload_legacy above target Normal SuccessfulRescale 3m38s (x19 over 41h) horizontal-pod-autoscaler New size: 17; reason: All metrics below target Normal SuccessfulRescale 2m8s (x23 over 41h) horizontal-pod-autoscaler New size: 16; reason: All metrics below target Normal SuccessfulRescale 98s (x20 over 40h) horizontal-pod-autoscaler New size: 15; reason: All metrics below target Normal SuccessfulRescale 7s (x18 over 40h) horizontal-pod-autoscaler New size: 14; reason: All metrics below target 

Tout ce qui a été décrit a été réalisé sur Kubernetes 1.13.2.

Conclusion

Dans ce court article, j'ai montré comment faire évoluer automatiquement les applications dans un cluster Kubernetes en utilisant des métriques de Prometheus.

Les composants de l'opérateur Prometheus ont été configurés et les manifestes nécessaires créés.

En conséquence, sur la base de la métrique de Prometheus sur la taille de la file d'attente, il s'est avéré augmenter ou diminuer le nombre de pods qui traitent cette file d'attente.


(le graphique montre comment le nombre de foyers varie en fonction de la taille de la file d'attente)

Merci de votre attention!