HPA에 custom metric을 target으로 적용시키기 위한 내용입니다.

ex) nginx-ingress request 증가량

필요한 환경

kubernetes cluster에 아래 항목들 구성

  • prometheus
  • metrics-server
  • nginx-ingress ( + ServiceMonitor )
  • test용 nginx

개념

Default : metrics-server API(metrics.k8s.io) + HPA

특이한 세팅 없이 metrics-server를 구축하고 hpa를 적용하면 cpu, memory 기준으로 pod autoscaling을 할 수 있습니다.

작동 방식은 metrics-server의 API service인 metrics.k8s.io을 통해 HPA가 현재 pod의 cpu, memory 값을 확인하고, 설정된 수치에 따라 scale in, out을 합니다.

Additional Custom : prometheus-adapter API(custom.metrics.k8s.io) + HPA

cpu나 memory 이외에 다른 메트릭을 기준으로 설정하기 위해서는 추가적으로 custom metric을 정의해줘야 합니다. 다른 메소드도 존재하겠지만, 저희는 prometheus를 모니터링 툴로 사용하고 있기 때문에 prometheus adapter를 이용하여 API service를 생성해 보려고 합니다.

prometheus adapter를 생성하여 custom.metrics.k8s.io라는 API service를 구축하면, prometheus로 수집하는 모든 메트릭을 hpa의 target으로 사용할 수 있습니다.

 

➡️ prometheus가 기본적으로 수집하는 것 외에 addon에서 metric을 활성화하여 Servicemonitor를 이용하여 수집하는 메트릭들도 사용 가능합니다.

➡️ 즉, nginx-ingress controller가 자체 메트릭을 노출시키도록 helm chart에서 metric을 활성화하고, 마찬가지로 prometheus를 위한 ServiceMonitor가 생성되도록 합니다. 이를 통해 prometheus에서 nginx-ingress의 자체 메트릭을 수집하게 되면, prometheus-adapter를 구축했을 때 해당 메트릭도 hpa의 target으로 지정할 수 있다는 뜻입니다.

 

Install prometheus-adapter by helm

Fetch chart

https://artifacthub.io/packages/helm/prometheus-community/prometheus-adapter

 

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm fetch prometheus-community/prometheus-adapter

tar -xzf prometheus-adapter-*

cd prometheus-adapter

 

 

Create new values_my.yaml

touch values_my.yaml

values_my.yaml에 아래 내용 작성합니다.

prometheus:
  url: <prometheus의 url>

같은 클러스터 안에서 prometheus를 실행 중이므로 위와 같이 url 지정해야 합니다.

example : http://kube-prometheus-stack-prometheus.monitor.svc

추가로 지정하고 싶은 게 있으면 values.yaml 을 참조하여 작성합니다.

 

Install

helm install prometheus-adapter . -f values_my.yaml -n monitor --create-namespace

➡️ 테스트 당시 helm chart에 resource를 지정해 놓고 돌렸었는데, 그게 원인인지 아닌지는 모르겠지만 prometheus-adapter의 endpoint 지정이 안돼서 이것 저것 시도해봤으나 결론적으로 전부 다 롤백시키고 resource 지정을 삭제했더니 정상 작동 했습니다. 추 후 resource를 좀 더 크게 주고 테스트 해봐야 할 필요가 있습니다. 아래는 endpoint 이슈로 조치해봤던 것들 관련 링크입니다.

 

https://github.com/kubernetes-sigs/metrics-server/issues/157

https://stackoverflow.com/questions/57739870/how-to-enable-kube-system-metrics-server-from-status-false-missingendpoints

 

결과 확인

kubectl get apiservices

➡️ pod 생성이 좀 걸리는 편이라서 api service 조회 시 available이 true가 뜰 때 까지 시간이 좀 소요될 수 있습니다.

 

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

kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/monitoring/pods/*/memory_rss" | jq .

 

prometheus-adapter의 configmap을 이용해서 내가 원하는 metric 생성

prometheus-adapter가 prometheus에 쿼리하는 규칙은 promQL을 활용하고, prometheus-adapter의 configmap에 정의합니다.

기본적으로 위의 방식처럼 간단하게 prometheus-adapter를 구성하게 되면 모든 메트릭이 포함되도록 되어 있습니다.

하지만 저는 nginx ingress를 거치는 request의 값이 아니라 증가량을 hpa의 target으로 설정해야 한다고 생각했기 때문에 promQL을 활용한 추가 custom metric 설정이 필요했습니다.

➡️ prometheus-adapter를 구성했을 때 기본적으로 포함되는 메트릭 쿼리들을 지워서 필요한 메트릭만 쿼리하도록 할 필요성도 있을 수 있다고 생각합니다. 이유는 PRD 환경에서는 Pod를 비롯한 kubernetes object들이 너무 많아서 prometheus에 저장되는 메트릭이 너무 많고, 이걸 무분별하게 prometheus-adapter 쪽에서 모두 일정 시간마다 쿼리하게 하는 것은 리소스 부분에서 낭비 or 위험하다고 생각하기 때문입니다. default로 지정되는 custom metric들을 비활성화 할 수 있는지는 추가적으로 테스트 예정입니다.

 

prometheus-adapter의 configmap은 helm chart의 values_my.yaml에 내용을 추가하고, helm upgrade해서 적용할 수 있습니다.

new values_my.yaml

prometheus:
  url: <http://kube-prometheus-stack-prometheus.monitor.svc>

rules:
  default: true

  custom:
  - seriesQuery: '{__name__=~"^nginx_ingress_controller_requests.*",namespace!=""}'
    seriesFilters: []
    resources:
      template: <<.Resource>>
      overrides:
        exported_service:
          resource: "service"      
        exported_namespace:
          resource: "namespace"
    name:
      matches: ""
      as: "nginx_ingress_controller_requests_rate"
    metricsQuery: round(sum(rate(<<.Series>>{<<.LabelMatchers>>}[1m])) by (<<.GroupBy>>), 0.001)

 

Helm upgrade

helm upgrade prometheus-adapter . -f values_my.yaml -n monitor

 

 

참조 : Configmap에 Custom metric를 정의하는 방법

(위의 values_my.yaml에 rule을 정의하기 위한 reference)

아래의 링크는 prometheus-adapter 공식 github에서 제공하는 config 형식인데,

이것만 가지고는 이해가 잘 안돼서 한참 헤맸습니다…

https://github.com/kubernetes-sigs/prometheus-adapter/blob/master/docs/sample-config.yaml

 

아래 링크를 찾아서, 제가 테스트하려던대로 nginx-ingress의 request 메트릭을 rate 함수를 써서 수집하는 방법을 찾아냈고, 위의 values_my.yaml 처럼 적용할 수 있었습니다.

https://blog.sighup.io/scale-workloads-with-ingress-traffic/

 

Scale workloads with Ingress traffic!

Managing clusters and helping companies on their journey towards Kubernetes always creates new possibilities. One of the most exploited ones is the autoscaling capabilities that Kubernetes provides.

blog.sighup.io

 

결과 확인

kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/default/ingress/nginx/nginx_ingress_controller_requests_rate" | jq .

kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/default/services/nginx/nginx_ingress_controller_requests_rate" | jq .

 

Custom metric을 HPA에 적용

새로 생성한 custom metric을 HPA에 적용하기 위해 hpa v2beta2 version을 사용했습니다.

nginxhpa.yaml

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Object
      object:
        metric:
          name: nginx_ingress_controller_requests_rate
        describedObject:
          apiVersion: networking.k8s.io/v1
          kind: Ingress
          name: nginx
        target:
          type: AverageValue
          averageValue: "500m"  
  behavior: 
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Pods
        value: 1
        periodSeconds: 60
      - type: Percent
        value: 10
        periodSeconds: 60
      selectPolicy: Min
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
      - type: Pods
        value: 2
        periodSeconds: 5
      - type: Percent
        value: 200
        periodSeconds: 5
      selectPolicy: Max

HPA를 작성할 때에는 Target이나 Object의 apiVersion을 잘 체크해야 합니다.

kubectl api-resources | grep ingress

예를 들어, 위의 명령어로 api resource를 검색하면 아래와 같이 나오는데,

이 중에 extensions/v1beta1 으로 적용했을 때에는 hpa 조회 시 current값이 확인되지 않았고, networking.k8s.io/v1을 적용하니까 current가 정상적으로 조회 됐습니다.

kubernetes object의 manifest를 참조하는 게 가장 정확합니다.

hpa 적용

kubectl apply -f nginxhpa.yaml

결과 확인

테스트용으로 띄운 nginx에 요청을 반복적으로 해서 테스트해봤습니다.

아래와 같이 점차 current 값이 증가하면서 hpa가 발동하여 replica가 10개까지 증가했습니다.

 

추가로 테스트 해 볼 내용

  • prometheus-adapter를 구성했을 때 기본적으로 포함되는 메트릭 쿼리들을 지워서 필요한 메트릭만 쿼리하도록 할 수 있는지 → 기본적으로 포함되는 메트릭쿼리를 전부 지우고 원하는 것만 구성할 수 있습니다. (prometheus-adapter의 helm value에서 rules.default를 false로 지정하고 custom을 비워두면 api service가 정상적으로 뜨지 않을 수 있으므로 default를 true로 하거나 custom을 넣어야 합니다.)
  • hpa에 여러 개의 Object를 Target으로 지정했을 때에도 잘 작동하는지 (cpu, memory, request 모두 target으로 지정)

 

참고

https://blog.naver.com/alice_k106/221521978267

'Monitoring' 카테고리의 다른 글

Opentelemetry - auto instrumentation with specific libraries  (0) 2023.08.28
Opentelemetry - auto instrumentation  (0) 2023.08.28
Loki Deployment to k8s  (0) 2023.02.14
Prometheus ISSUE  (0) 2023.02.14
TSDB의 데이터 수집 방식 (polling, trapping)  (0) 2023.02.14

티스토리툴바