Uma situação comum: você tem vários aplicativos, um deles tem um pico de carga durante o dia e em outras horas ninguém acessa (ou é acessado, mas raramente); enquanto outros aplicativos podem usar a energia do cluster à noite. Como exemplo de tais aplicativos, podemos citar serviços da web, alguns manipuladores de dados.

Como de costume, os recursos do cluster não são suficientes. Você precisa criar algo para otimizar o uso de recursos, e o Kubernetes é ótimo para isso. Possui um autoscaler de pod horizontal , que permite dimensionar aplicativos com base em métricas.



As métricas geralmente são fornecidas pelo servidor de métricas . Em seguida, falarei sobre a substituição do servidor de métricas pelo Prometheus (porque o Prometheus implementa os dados que o servidor de métricas fornece e nos livramos de um link extra) e como escalar nossos aplicativos no Kubernetes com base nas métricas do Prometheus.

Para começar, instale o operador Prometheus . Pessoalmente, eu uso manifestos prontos . Você pode usar o gráfico para Helm (mas eu não verifiquei seu desempenho). Remova também o servidor métrico, se você tiver um. Depois disso, verifique se tudo funciona como deveria.

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

Em seguida, aplique manifestos nesse diretório . Isso instalará o adaptador Prometheus. Encontrei um gráfico que contém esses manifestos, mas não o verifiquei. Depois disso, você deve executar o comando corretamente:

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

(haverá uma lista muito grande, então não a listarei aqui)

Para entender o que significam os URLs metrics.k8s.io e custom.metrics.k8s.io, a documentação pode ajudá-lo.

Se algo não funcionar, procure, como sempre, nos logs. Você também pode procurar uma solução em problemas .

Agora configure o dimensionamento automático.

Eu tenho um aplicativo que consome muitos recursos do processador e atende a fila. Assim que o tamanho da fila exceder algum limite, desejo aumentar o número de lares na réplica definida para processar a fila mais rapidamente. Assim que seu tamanho se tornar menor que o limite, os recursos do cluster deverão ser liberados.

Para entender como escrever regras para o adaptador Prometheus, você precisa ler atentamente este documento e suas páginas relacionadas. É assim que parece comigo.

Pedido a Prometeu

 wqueue_tube_total_size{tube="dmload-legacy"} 

retorna:

 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 

E escrevo a seguinte regra para o Prometheus-adapter:

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

Deve-se notar que eu tenho que mapear o parâmetro tube em service e depois usar hpa na descrição.

Configuração 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 

wqueue_tube_total_size_dmload_legacy aqui que assim que o número de trabalhos na fila wqueue_tube_total_size_dmload_legacy exceder 30, adicione pods até os 20 e, se targetValue cair abaixo de 30, reduza para 2.

Nós aplicamos e vemos o que acontece. Meu sistema funciona por vários dias e, no momento, apenas reduz o número de lareiras:

 # 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 

Tudo descrito foi realizado no Kubernetes 1.13.2.

Conclusão

Neste pequeno artigo, mostrei como dimensionar aplicativos automaticamente em um cluster Kubernetes usando métricas do Prometheus.

Os componentes do operador Prometheus foram configurados e os manifestos necessários criados.

Como resultado, com base na métrica do Prometheus no tamanho da fila, acabou aumentando ou diminuindo o número de pods que processam essa fila.


(o gráfico mostra como o número de lareiras varia dependendo do tamanho da fila)

Obrigado pela atenção!