Una situación común: tiene varias aplicaciones, una de ellas tiene una carga máxima durante el día y en otras horas nadie accede a ella (o se accede a ella, pero rara vez); mientras que otras aplicaciones pueden usar la energía del clúster por la noche. Como ejemplo de tales aplicaciones, podemos citar servicios web, algunos manejadores de datos.

Como de costumbre, los recursos del clúster no son suficientes. Tienes que encontrar algo para optimizar el uso de los recursos, y Kubernetes es excelente para esto. Tiene un escalador automático de pod horizontal , que le permite escalar aplicaciones basadas en métricas.



Las métricas generalmente son suministradas por el servidor de métricas . A continuación, hablaré sobre la sustitución del servidor de métricas con Prometheus (porque Prometheus implementa los datos que proporciona el servidor de métricas y nos deshacemos de un enlace adicional) y cómo escalar nuestras aplicaciones en Kubernetes según las métricas de Prometheus.

Para comenzar, instale el operador Prometheus . Personalmente, uso manifiestos confeccionados . Puede usar el gráfico para Helm (pero no verifiqué su rendimiento). Elimine también el servidor de métrica, si tiene uno. Después de eso, verifique si todo funciona como debería.

# 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" ] } ] } 

Luego aplique los manifiestos de este directorio . Esto instalará el adaptador Prometheus. Encontré un cuadro que contiene estos manifiestos, pero no lo verifiqué. Después de eso, debe ejecutar el comando correctamente:

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

(habrá una lista muy grande, así que no la enumeraré aquí)

Para comprender qué significan las URL metrics.k8s.io y custom.metrics.k8s.io, la documentación puede ayudarlo.

Si algo no funciona, busque, como de costumbre, en los registros. También puede buscar una solución en los problemas .

Ahora configure la escala automática.

Tengo una aplicación que consume muchos recursos de procesador y sirve la cola. Tan pronto como el tamaño de la cola exceda algún umbral, quiero aumentar el número de hogares en el conjunto de réplicas para procesar la cola más rápido. Tan pronto como su tamaño sea inferior al umbral, los recursos del clúster deberían liberarse.

Para comprender cómo escribir reglas para el adaptador Prometheus, debe leer detenidamente este documento y sus páginas relacionadas. Así es como se ve conmigo.

Solicitud a Prometeo

 wqueue_tube_total_size{tube="dmload-legacy"} 

vuelve:

 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 

Y escribo la siguiente regla para el adaptador 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"} 

Cabe señalar que tengo que asignar el parámetro del tube en service , luego usar hpa en la descripción.

Configuración de 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 

Aquí wqueue_tube_total_size_dmload_legacy que tan pronto como el número de trabajos en la cola wqueue_tube_total_size_dmload_legacy exceda de 30, agregue pods hasta que haya 20, y si targetValue cae por debajo de 30, reduzca a 2.

Aplicamos y vemos qué pasa. Mi sistema funciona durante varios días y por el momento solo reduce la cantidad de hogares:

 # 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 

Todo lo descrito se realizó en Kubernetes 1.13.2.

Conclusión

En este breve artículo, mostré cómo escalar automáticamente las aplicaciones en un clúster de Kubernetes usando métricas de Prometheus.

Los componentes del operador Prometheus se configuraron y se crearon los manifiestos necesarios.

Como resultado, según la métrica de Prometheus sobre el tamaño de la cola, resultó aumentar o disminuir el número de pods que procesan esta cola.


(el gráfico muestra cómo varía el número de hogares según el tamaño de la cola)

Gracias por su atencion!