[Monitoramento nativo da nuvem] Dimensionamento elástico de índice autodefinido (HPA) baseado em Prometheus

[Monitoramento nativo da nuvem] Dimensionamento elástico de índice autodefinido (HPA) baseado em Prometheus

O que é dimensionamento elástico

"Autoscaling é um dimensionamento elástico, que é uma função muito importante no Kubernetes. Ele pode dimensionar automaticamente cópias de pods de acordo com um determinado indicador (como CPU ou memória), de modo a gerenciar e utilizar melhor os recursos de computação e melhorar a disponibilidade e o desempenho do sistema. , enquanto reduz a sobrecarga e o custo. O dimensionamento elástico pode resolver grandes flutuações na carga de serviço ou lacunas entre o uso real de recursos e as estimativas."

Três tecnologias de dimensionamento elástico são fornecidas no cluster do Kubernetes:

• "CA (Cluster Autoscaler)" : expansão/redução automática no nível do nó

• "HPA (Horizontal Pod Autoscaler)" : O número de Pods é expandido/encolhido automaticamente

• "VPA (Vertical Pod Autoscaler)" : a configuração do pod expande/reduz automaticamente a capacidade, principalmente configuração de CPU e memória

"Expansão/redução automática do nó"

O Cluster AutoScaler detecta periodicamente se há recursos suficientes para agendar pods recém-criados e chama o provedor de nuvem para criar novos nós quando os recursos são insuficientes. O Cluster AutoScaler também monitora regularmente o uso de recursos do Node. Quando a utilização de recursos de um Node é baixa (abaixo de 50%) por um longo período, ele exclui automaticamente a máquina virtual onde ele reside do cluster. Neste ponto, o Pod original será agendado automaticamente para outros Nodes.

O aumento ou diminuição do Node pode afetar a estabilidade de todo o cluster do kubernetes. Uma vez que um problema ocorra, ele afetará todos os programas de negócios implantados em todo o cluster. Portanto, a expansão e contração dos nós do Node na produção geralmente é usada com cautela. Ao dimensionar, geralmente é feito executando scripts manualmente.

"Expansão/contração vertical de Pod (VPA)"

O nome completo do VPA é Vertical Pod Autoscaler, que é o dimensionamento vertical automático do Pod. Ele define automaticamente as solicitações de CPU e memória de acordo com o uso de recursos do contêiner, permitindo assim o agendamento adequado no nó para fornecer os recursos apropriados para cada Pod. Ele pode reduzir os contêineres que estão solicitando recursos em excesso e aumentar os com poucos recursos a qualquer momento com base em seu uso.

"Atualmente, a tecnologia VPA não está madura o suficiente. É uma função relativamente nova do Kubernetes. A atualização da configuração de recursos do Pod em execução é uma função experimental do VPA, que fará com que o Pod seja reconstruído e reiniciado, podendo ser agendado para outros nodos. superiores."

"Expansão/Redução Horizontal de Pod (HPA)"

O nome completo do HPA é Horizontal Pod Autoscaler, ou seja, o dimensionamento automático horizontal de pods. Ele ajusta automaticamente o número de cópias de pods de acordo com a utilização de recursos ou indicadores personalizados, de modo a realizar a expansão e contração de pods, para que a escala de implantação está próxima da carga de serviço real.

Princípio de dimensionamento elástico HPA

Horizontal Pod AutoscalerA função foi originalmente Kubernetes 1.1introduzida e tem sido continuamente desenvolvida, e atualmente HPAsuporta autoscaling/v1, autoscaling/v2beta1e autoscaling/v2beta2três versões principais.

Em cenários normais, como quando a pressão do negócio é baixa à noite, você pode usar o comando kubectl scale para definir o número de cópias do Pod para 1; quando você vai trabalhar durante o dia e a pressão do negócio é alta, você pode usar o comando kubectl scale para definir o número de cópias do pod para 3, mas essas operações são executadas manualmente. O controlador HPA avalia se o negócio está ocupado ou ocupado com base em indicadores de negócios e calcula automaticamente o número atual de cópias do Pod com base no algoritmo e ajusta automaticamente o número de cópias do Pod.

Kubernetes HPA v2v1Fez algumas melhorias importantes sobre a versão. A melhoria mais notável é a introdução do escalonamento automático "multi-index" , ou seja, as decisões de escalonamento automático podem ser feitas com base em vários indicadores (como uso de CPU, uso de memória, carga de rede, etc.) ao mesmo tempo. Além disso, HPA v2foi adicionada a capacidade de oferecer suporte a "indicadores personalizados" , permitindo que os usuários definam e usem seus próprios indicadores de acordo com suas necessidades. Em geral, Kubernetes HPA v2é um mecanismo de dimensionamento automático mais maduro, flexível e personalizável.

"O principal mecanismo do dimensionamento elástico HPA: ajustar automaticamente o número de cópias de cargas de trabalho de negócios de acordo com a ocupação do negócio. Há dois pontos principais envolvidos aqui:"

• "Como identificar a ocupação do negócio"

• "Ajuste o número de cópias do pod de controle"

"Vamos ver primeiro a primeira pergunta: como identificar a ocupação do negócio?"

Quando apresentei o monitoramento de cluster kubernetes antes, apresentei que o componente do servidor de métricas pode obter os indicadores de tempo de execução do contêiner subjacente do cAdvisor no componente kubelet de todos os nós do cluster e, após a agregação, você pode visualizar o uso da CPU e recursos de memória por meio do kubectl top node/pod e também podem kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes ser obtidos por meio do acesso à interface. Portanto, o controlador HPA pode obter o uso de CPU e memória do Pod por meio do componente do servidor de métricas para identificar a ocupação do negócio.

O Kubernetes 1.7 apresenta a camada de agregação (Aggregator), permitindo que aplicativos de terceiros estendam a API do Kubernetes registrando-se como plug-ins de API. O componente do servidor de métricas é registrado na camada de agregação e, em seguida, você pode acessar a interface do serviço de back-end do servidor de métricas da mesma forma que acessa a interface kube-apiserver.

O Kubernetes introduz uma camada de agregação de API no serviço kube-apiserver, que é usado para encaminhar a solicitação de acesso da API estendida para o serviço do usuário. Por exemplo, quando você visita apis/metrics.k8s.io/v1beta1, aggregatoro componente será baseado groupe versionencaminhado para o metrics-serverserviço de back-end, e a camada de agregação é equivalente apenas à camada de proxy. Desta forma, podemos Kubernetesexpandir facilmente API.

Obter indicadores de CPU e memória do servidor de métricas é relativamente simples. O padrão de fato para monitoramento de cluster kubernetes é o prometheus. Se os indicadores puderem ser obtidos do prometheus para identificar a ocupação dos negócios, a flexibilidade do dimensionamento elástico será bastante aumentada. O componente prometheus-adapter pode realizar essa função. Ele extrai indicadores do prometheus e os converte em formatos de dados reconhecidos pela interface api do kubernetes e os registra na camada de agregação, para que outros serviços no cluster do kubernetes possam ser acessados ​​por meio de /apis /.

"Vamos ver a segunda pergunta: como controlar o ajuste do número de cópias do Pod?"

O controlador HPA executará periodicamente o método de reconciliação de cada objeto HPA, incluindo principalmente como operar:

• Obtenha dados de indicadores atuais: obtenha uso de CPU, uso de memória do servidor de métricas ou dados de indicadores personalizados do adaptador prometheus;

• Cálculo do número de réplicas do pod: compare os dados do indicador obtido com a expectativa de destino para determinar se deve expandir, encolher ou permanecer inalterado. Se não houver necessidade de ajustar a capacidade, ele retornará diretamente o número atual de réplicas. Caso contrário, usar as métricas HPA correspondentes ao tipo de destino. O algoritmo para calcular o número de destino de cópias da implantação;

• Atualize o número de cópias do Pod: Se o número alvo de cópias do Pod calculado na etapa anterior for inconsistente com o número atual de cópias, ou seja, é necessária expansão/redução, o controlador HPA inicia uma operação de dimensionamento para os Deploymen para ajustar o número atual de cópias e concluir a operação de expansão / redução;

• Efeitos de monitoramento e ajuste: Por fim, é possível manter as métricas finais (valor médio) de cada pod em implantação no nível esperado pelo usuário. O HPA continuará monitorando o impacto do número de novas cópias de pod no indicador dados e faça ajustes adicionais conforme necessário.

❝

O intervalo de sincronização de reconciliação é padronizado para 15 segundos, o que pode ser configurado por meio do horizontal-pod-autoscaler-sync-period.

❞

HPA com base em métricas de CPU

A versão HPA v1 oferece suporte ao dimensionamento elástico do uso da CPU e do uso da memória. O uso da memória geralmente é afetado pelo cache e é difícil refletir verdadeiramente a carga do sistema. Portanto, o indicador de uso da CPU geralmente é usado para dimensionamento elástico. O uso da CPU do contêiner pode ser feito por proxy para o serviço do servidor de métricas de back-end por meio da API da camada de agregação. O servidor de métricas envia solicitações para todos os componentes do kubelet e coleta as informações de execução da CPU e da memória de todos os contêineres por meio do cAdvisor, portanto que o controlador HPA pode obter para o uso da CPU do pod e, em seguida, executar o dimensionamento elástico com base no uso da CPU.

"1. Criar pod com base na implantação:"

#vi deploy-for-hpa_cpu.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-php
  template:
    metadata:
      labels:
        app: nginx-php
    spec:
      containers:
      - image: lizhenliang/nginx-php
        name: java
        resources: 
           requests:
             memory: "300Mi"
             cpu: "250m"
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx-php

"2. Criar:"

[root@k8s-01 autoscaling]# kubectl apply -f deploy-for-hpa_cpu.yml -n demo01
[root@k8s-01 autoscaling]# kubectl get pod -n demo01
NAME                                  READY   STATUS    RESTARTS   AGE
web-84885d5959-fbtxt                 1/1     Running   0          29s

"3. Documento de estratégia HPA:"

# vi hpa_for_cpu.yml
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: web
spec:
  #扩/缩容副本范围
  maxReplicas: 3
  minReplicas: 1
  #指定扩容的Deployment
  scaleTargetRef: 
    apiVersion: apps/v1
    kind: Deployment
    name: web
  targetCPUUtilizationPercentage: 60

❝

targetCPUUtilizationPercentage: 60Indica que quando a utilização geral de recursos do Pod exceder 60%, a capacidade será expandida.

❞

"4. Criar HPA:"

[root@k8s-01 autoscaling]# kubectl apply -f hpa_for_cpu.yml -n demo01
horizontalpodautoscaler.autoscaling/web created
[root@k8s-01 autoscaling]# kubectl get hpa -n demo01
NAME              REFERENCE                       TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
web               Deployment/web                  0%/60%    1         3         1          44s

❝

A coluna TARGETS mostra os indicadores. O primeiro 0% significa que o pod atual obtém o uso geral de recursos da CPU. Como não há solicitação HTTP, é 0%; 60% é o limite de expansão/redução.

MINPODS, MAXPODS: Especifique expansão/redução hpa

❞

"5. Teste de pressão:"

[root@k8s-01 autoscaling]# yum install httpd-tools
[root@k8s-01 autoscaling]# kubectl get svc -n demo01
NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
web                  ClusterIP   10.96.237.204   <none>        80/TCP     5d20h
[root@k8s-01 autoscaling]# ab -n 100000 -c 100  http://10.96.237.204/status.php

"6. Observe a expansão/contração:"

Após dezenas de segundos de teste de pressão, verifiquei o hpa e descobri que o uso geral da CPU era de 173%, superando o valor alvo de 60%, mas as réplicas ainda eram 1 e não havia expansão de capacidade:

[root@k8s-01 autoscaling]# kubectl get hpa -n demo01
NAME              REFERENCE                       TARGETS    MINPODS   MAXPODS   REPLICAS   AGE
metrics-app-hpa   Deployment/sample-httpserver2   200m/2     1         3         1          46h
web               Deployment/web                  173%/60%   1         3         1          75s

Depois de um tempo, você verá que replicas=3, o que aciona a operação de expansão:

[root@k8s-01 autoscaling]# kubectl get hpa -n demo01
NAME              REFERENCE                       TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
metrics-app-hpa   Deployment/sample-httpserver2   200m/2    1         3         1          46h
web               Deployment/web                  15%/60%   1         3         3          76s

Exibir informações do pod:

[root@k8s-01 autoscaling]# kubectl get pod -n demo01
NAME                                 READY   STATUS    RESTARTS   AGE
web-84885d5959-d9l4h                 1/1     Running   0          90s
web-84885d5959-fbtxt                 1/1     Running   0          6m9s
web-84885d5959-xgn4n                 1/1     Running   0          90s

kubectl describe hpa information, você pode ver que há um evento de mensagem que o número de réplicas expandiu para 3:

Após a interrupção do teste de pressão, a pressão de uso da CPU cairá. Depois de aguardar alguns minutos, a operação de redução será acionada novamente e as réplicas serão definidas como 1 novamente:

[root@k8s-01 autoscaling]# kubectl get hpa -n demo01         
NAME              REFERENCE                       TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
web               Deployment/web                  0%/60%    1         3         1          7m59s

kubectl describe hpa Visualize as informações de hpa, você encontrará dois eventos de mensagem de redução, um mostra o número de cópias diminuindo de 3 para 2 eventos de mensagem e o outro mostra o número de cópias diminuindo de 2 para 1 evento de mensagem:

HPA baseado em indicadores personalizados do Prometheus

Com base no uso da CPU e no uso da memória obtido pelo componente do servidor de métricas, a flexibilidade do dimensionamento elástico é um pouco ruim. Se você quiser usar indicadores personalizados, como o QPS das solicitações HTTP e o número de erros 5XX, o Prometheus é basicamente usado para monitoramento no campo nativo da nuvem. Os indicadores personalizados são fornecidos pelo Prometheus e, em seguida, agregados ao apiserver usando o adaptador prometheus para obter o mesmo efeito de obtenção de CPU e memória do componente metric-server.

O processo principal do HPA baseado nos indicadores personalizados do Prometheus é o seguinte:

implantação do componente do adaptador prometheus

"1. Instalar prometheus-adaptercomponentes:"

[root@k8s-01 ~]# helm repo add stable http://mirror.azure.cn/kubernetes/charts
"prometheus-community" has been added to your repositories
[root@k8s-01 ~]# helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "prometheus-community" chart repository
Update Complete. ⎈ Happy Helming!⎈ 
[root@k8s-01 ~]# helm repo list
NAME                    URL                                               
stable                  http://mirror.azure.cn/kubernetes/charts   

[root@k8s-01 ~]# helm install prometheus-adapter stable/prometheus-adapter --namespace monitoring --set prometheus.url=http://prometheus,prometheus.port=9090
NAME: prometheus-adapter
LAST DEPLOYED: Tue Aug  1 23:44:08 2023
NAMESPACE: monitoring
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
prometheus-adapter has been deployed.
In a few minutes you should be able to list metrics using the following command(s):

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

❝

curl http://192.168.31.160:32478/metrics

❞

"2. Verifique se a instalação do componente foi bem-sucedida:"

[root@k8s-01 ~]# kubectl get pod -n monitoring
NAME                                      READY   STATUS    RESTARTS   AGE
prometheus-adapter-76d8fb4549-6vzzg       1/1     Running   0          3m25s

[root@k8s-01 ~]# kubectl get apiservices                                                 
NAME                                   SERVICE                          AVAILABLE   AGE
...
v1beta1.custom.metrics.k8s.io          monitoring/prometheus-adapter   True        2m28s

[root@k8s-01 ~]# kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1 |jq|more
{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "custom.metrics.k8s.io/v1beta1",
  "resources": [
    {
      "name": "namespaces/file_descriptors",
      "singularName": "",
      "namespaced": false,
      "kind": "MetricValueList",
      "verbs": [
        "get"
      ]
    },
    {
      "name": "namespaces/kube_ingress_annotations",
      "singularName": "",
      "namespaced": false,
      "kind": "MetricValueList",
      "verbs": [
        "get"
      ]
    },
...

❝

Verifique o log do componente prometheus-adapter, tome cuidado para não aparecer algo como http://prometheus:9090/api/v1/series?match%5B%5D=%7B__name__%3D~%22%5Econtainer_.%2A% 22%2Ccontainer%21 %3D%22POD%22%2Cnamespace%21%3D%22%22%2Cpod%21%3D%22%22%7D&start=1690905427.938 timeout Este erro.

❞

A operação de desinstalação do helm é a seguinte:

[root@k8s-01 ~]# helm ls -n kube-system
NAME                    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                           APP VERSION
prometheus-adapter      kube-system     1               2023-08-01 23:44:08.027994527 +0800 CST deployed        prometheus-adapter-4.3.0        v0.11.0    
[root@k8s-01 ~]# helm uninstall prometheus-adapter -n kube-system
release "prometheus-adapter" uninstalled

Implantar aplicativo golang

"1. Inicialize golango projeto do projeto:"

[root@swarm-manager ~]# mkdir metrics
[root@swarm-manager ~]# cd metrics/
[root@swarm-manager metrics]# go mod init metrics

"2. Escreva metrics.go:"

package main

import (
 "github.com/prometheus/client_golang/prometheus"
 "github.com/prometheus/client_golang/prometheus/promhttp"
 "net/http"
 "strconv"
)

func main() {
 metrics := prometheus.NewCounterVec(
  prometheus.CounterOpts{
   Name: "http_requests_total",
   Help: "Number of total http requests",
  },
  []string{"status"},
 )
 prometheus.MustRegister(metrics)

 http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
  path := r.URL.Path
  statusCode := 200
  switch path {
  case "/metrics":
   promhttp.Handler().ServeHTTP(w, r)
  default:
   w.WriteHeader(statusCode)
   w.Write([]byte("Hello World!"))
  }
  metrics.WithLabelValues(strconv.Itoa(statusCode)).Inc()
 })
 http.ListenAndServe(":3000", nil)
}

❝

O projeto go expõe principalmente o indicador http_requests_total por meio do endpoint /metrics.

❞

"3. Compilação e empacotamento locais:"

[root@swarm-manager metrics]# go mod tidy
[root@swarm-manager metrics]# go build -o metrics metrics.go

"4. Crie uma imagem espelhada e envie-a para o hub do Docker:"

Escreva Dockerfile:

FROM golang:latest
MAINTAINER simon "[email protected]"
RUN mkdir -p /app
WORKDIR /app
COPY ./metrics /app
EXPOSE 3000

RUN chmod +x ./metrics
ENTRYPOINT ["./metrics"]

Construir a imagem:

docker build -t metrics .

"5. implantação k8s:"

# sample-httpserver-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: sample-httpserver
  name: sample-httpserver
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sample-httpserver
  strategy: {}
  template:
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/path: /metrics
        prometheus.io/port: "3000"
      labels:
        app: sample-httpserver
    spec:
      containers:
        - image: addozhang/httpserver-n-metrics:latest
          name: httpserver-n-metrics
          ports:
            - containerPort: 3000
          resources:
            requests:
              memory: '300Mi'
---
apiVersion: v1
kind: Service
metadata:
  name: sample-httpserver
  labels:
    app: sample-httpserver
spec:
  ports:
  - name: web
    port: 3000
    targetPort: 3000
  selector:
    app: sample-httpserver

"6. O índice de aquisição da interface é normal:"

[root@k8s-01 demo01]# kubectl get svc -n demo01     
NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
nginx-service       ClusterIP   None            <none>        80/TCP     249d
sample-httpserver   ClusterIP   10.96.153.13    <none>        3000/TCP   32s
tomcat-service      ClusterIP   None            <none>        8080/TCP   249d
web                 ClusterIP   10.96.237.204   <none>        80/TCP     47h
[root@k8s-01 demo01]# curl 10.96.153.13:3000/metrics
# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 3.5147e-05
go_gc_duration_seconds{quantile="0.25"} 3.8423e-05
go_gc_duration_seconds{quantile="0.5"} 4.1267e-05
go_gc_duration_seconds{quantile="0.75"} 5.0566e-05
go_gc_duration_seconds{quantile="1"} 9.0761e-05
go_gc_duration_seconds_sum 0.001240037
go_gc_duration_seconds_count 25
......

"7, tarefa de captura de configuração do prometheus:"

- job_name: 'app'
  kubernetes_sd_configs:
  - role: pod
  relabel_configs:
  - action: keep
    source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
    regex: true
  - source_labels: [__meta_kubernetes_namespace]
    target_label: namespace
  - source_labels: [__meta_kubernetes_pod_name]
    target_label: pod

"8. Verificação de captura de índice:"

No alvo do prometheus, você pode ver que os indicadores de aplicativo implementados estão conectados com sucesso:

Use a consulta PromQL:sum(rate(http_requests_total[30s])) by (pod)

Criação de recursos HPA

"1. Criar hpa:"

# vi app-hpa-v2.yml
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: metrics-app-hpa 
  namespace: demo01
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: sample-httpserver
  minReplicas: 1
  maxReplicas: 3
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_qps
      target:
        type: AverageValue
        averageValue: 2000m   # 2000m 即2个/秒

"2. prometheus-adapterO componente configura as regras de cálculo dos indicadores personalizados, informando prometheus-adaptercomo prometheusobter os indicadores e calcular os indicadores de que precisamos: kubectl edit cm prometheus-adapter -n monitoring"

❝

prometheus-adapter não pode carregar a configuração dinamicamente, você precisa kubectl delete pod prometheus-adapter-xx, deixe o pod reiniciar para carregar a configuração mais recente.

❞

"3. Você pode acessar o api-server para obter os novos indicadores calculados e gerados pelo adaptador prometheus:"

[root@k8s-01 ~]# kubectl get --raw '/apis/custom.metrics.k8s.io/v1beta1/namespaces/demo01/pods/*/http_requests_qps' | jq         
{
  "kind": "MetricValueList",
  "apiVersion": "custom.metrics.k8s.io/v1beta1",
  "metadata": {
    "selfLink": "/apis/custom.metrics.k8s.io/v1beta1/namespaces/demo01/pods/%2A/http_requests_qps"
  },
  "items": [
    {
      "describedObject": {
        "kind": "Pod",
        "namespace": "demo01",
        "name": "sample-httpserver-695f994dbd-s2s2g",
        "apiVersion": "/v1"
      },
      "metricName": "http_requests_qps",
      "timestamp": "2023-08-02T15:32:56Z",
      "value": "66m",
      "selector": null
    }
  ]
}

❝

"Observação: Aqui value: 66m, o sufixo "m" do valor é identificado milli-requests per seconds, então 66m aqui significa 0,06/s 0,06 solicitações por segundo."

❞

"4. Com os dados do indicador, o adaptador prometheus pode criar hpa com base no indicador: kubectl apply -f app-hpa-v2.yml"

# vi app-hpa-v2.yml
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: metrics-app-hpa
  namespace: demo01
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: sample-httpserver
  minReplicas: 1
  maxReplicas: 3
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_qps
      target:
        type: AverageValue
        averageValue: 2000m   # 2000m 即2个/秒

"5. Verifique se hpa obtém indicadores do componente do adaptador prometheus normalmente:"

O número atual de réplicas de pod é 1:

"6. Teste de pressão da interface:"

[root@k8s-01 ~]# kubectl get svc -n demo01
NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
nginx-service       ClusterIP   None            <none>        80/TCP     249d
sample-httpserver   ClusterIP   10.96.153.13    <none>        3000/TCP   8m11s
[root@k8s-01 ~]# ab -n 100000 -c 30  http://10.96.153.13:3000/metrics
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 10.96.153.13 (be patient)
Completed 10000 requests
Completed 20000 requests

"7. Verificação de dimensionamento elástico:"

Verifique o status HPA, a coluna de alvos mostra que o índice atual atingiu cerca de 10900m, e o 2 atrás da barra significa que ele será esticado elasticamente quando atingir 2 e 10900m/1000=10, que obviamente é mais que 2, e a coluna de réplicas mostra que a expansão atual para o número máximo de réplicas é 3:

Verifique as informações de descrição hpa, você pode ver que há um evento que descreve claramente o índice http_requests_qps excedendo a configuração de destino de 2 e o número de cópias é definido como 3:

Olhando para as informações do pod novamente, descobriu-se que o número de réplicas foi de fato expandido para 3:

"8. Verificação da retração elástica:"

Depois de parar o teste de pressão da interface, o índice hpa cai e o 200m é obviamente menor que 2. Após cerca de 5 minutos de estabilidade, o hpa começa a encolher, reduzindo o número de cópias de 3 para 1:

Visualizar as informações de descrição do hpa também confirma que o hpa diminui:

Vamos confirmar que o Pod se tornou 1: