Prometheus 및 KEDA를 사용하여 Kubernetes 애플리케이션 자동 크기 조정

풍선맨 by Cimuanos

확장성은 클라우드 애플리케이션의 핵심 요구 사항입니다. Kubernetes를 사용하면 적절한 배포를 위해 복제본 수를 늘리는 것만큼 간단하게 애플리케이션을 확장할 수 있습니다. ReplicaSet — 하지만 이는 수동 프로세스입니다.

Kubernetes를 사용하면 애플리케이션을 자동으로 확장할 수 있습니다(예: 배포 또는 ReplicaSet) Horizon Pod Autoscaler 사양을 사용하여 선언적인 방식으로 수행됩니다. 자동 조정의 기본 기준은 CPU 사용량 지표(리소스 지표)이지만 사용자 지정 지표와 외부 제공 지표를 통합할 수 있습니다.

팀 Mail.ru의 Kubernetes aaS 외부 측정항목을 사용하여 Kubernetes 애플리케이션을 자동으로 확장하는 방법에 대한 기사를 번역했습니다. 모든 것이 어떻게 작동하는지 보여주기 위해 저자는 Prometheus를 사용하여 수집된 HTTP 액세스 요청 측정항목을 사용합니다.

Pod의 수평적 Auto Scaling 대신 오픈 소스 Kubernetes 연산자인 KEDA(Kubernetes Event Driven Auto Scaling)가 사용됩니다. 이벤트 기반 워크로드에 대한 원활한 자동 크기 조정(XNUMX에서/XNUMX까지 포함)을 제공하기 위해 기본적으로 수평 포드 자동 크기 조정기와 통합됩니다. 사용 가능한 코드: GitHub의.

시스템의 간략한 개요

다이어그램은 모든 작동 방식에 대한 간략한 설명을 보여줍니다.

1. 애플리케이션은 Prometheus 형식으로 HTTP 적중 횟수 측정항목을 제공합니다.
2. Prometheus는 이러한 측정항목을 수집하도록 구성되어 있습니다.
3. KEDA의 Prometheus 스케일러는 HTTP 적중 수에 따라 애플리케이션을 자동으로 확장하도록 구성됩니다.

이제 각 요소에 대해 자세히 설명하겠습니다.

KEDA와 프로메테우스

Prometheus는 오픈 소스 시스템 모니터링 및 경고 툴킷입니다. 클라우드 네이티브 컴퓨팅 재단. 다양한 소스에서 측정항목을 수집하여 시계열 데이터로 저장합니다. 데이터를 시각화하려면 다음을 사용할 수 있습니다. 그라 파나 또는 Kubernetes API와 함께 작동하는 기타 시각화 도구.

KEDA는 스케일러 개념을 지원합니다. 이는 KEDA와 외부 시스템 사이의 가교 역할을 합니다. 스케일러 구현은 각 대상 시스템에 따라 다르며 여기에서 데이터를 추출합니다. 그런 다음 KEDA는 이를 사용하여 자동 스케일링을 제어합니다.

스케일러는 Kafka, Redis, Prometheus와 같은 여러 데이터 소스를 지원합니다. 즉, KEDA를 사용하면 Prometheus 측정항목을 기준으로 Kubernetes 배포를 자동으로 확장할 수 있습니다.

시험 적용

Golang 테스트 애플리케이션은 HTTP를 통한 액세스를 제공하고 두 가지 중요한 기능을 수행합니다.

1. Prometheus Go 클라이언트 라이브러리를 사용하여 애플리케이션을 계측하고 적중 횟수가 포함된 http_requests 지표를 제공합니다. Prometheus 측정항목을 사용할 수 있는 엔드포인트는 URI에 있습니다. /metrics.

   var httpRequestsCounter = promauto.NewCounter(prometheus.CounterOpts{
          Name: "http_requests",
          Help: "number of http requests",
      })
   

2. 요청에 대한 응답으로 GET 애플리케이션은 키 값을 증가시킵니다(access_count) Redis에서. 이는 HTTP 핸들러의 일부로 작업을 수행하고 Prometheus 측정항목을 확인하는 쉬운 방법입니다. 측정항목 값은 값과 동일해야 합니다. access_count 레디스에서.

   func main() {
          http.Handle("/metrics", promhttp.Handler())
          http.HandleFunc("/test", func(w http.ResponseWriter, r 
   *http.Request) {
              defer httpRequestsCounter.Inc()
              count, err := client.Incr(redisCounterName).Result()
              if err != nil {
                  fmt.Println("Unable to increment redis counter", err)
                  os.Exit(1)
              }
              resp := "Accessed on " + time.Now().String() + "nAccess count " + strconv.Itoa(int(count))
              w.Write([]byte(resp))
          })
          http.ListenAndServe(":8080", nil)
      }
   

애플리케이션은 다음을 통해 Kubernetes에 배포됩니다. Deployment. 서비스도 생성됩니다 ClusterIP, 이를 통해 Prometheus 서버는 애플리케이션 측정항목을 얻을 수 있습니다.

여기에 애플리케이션의 배포 매니페스트.

프로메테우스 서버

Prometheus 배포 매니페스트는 다음으로 구성됩니다.

• ConfigMap — Prometheus 구성을 전송합니다.
• Deployment — Kubernetes 클러스터에 Prometheus를 배포하는 경우
• ClusterIP — UI Prometheus에 액세스하기 위한 서비스
• ClusterRole, ClusterRoleBinding и ServiceAccount — Kubernetes에서 서비스 자동 감지(자동 검색)용입니다.

여기에 Prometheus 실행을 위한 매니페스트.

KEDA 프로메테우스 ScaledObject

스케일러는 측정항목을 가져와야 하는 외부 시스템과 KEDA 사이의 브리지 역할을 합니다. ScaledObject 배포를 이벤트 소스(이 경우 Prometheus)와 동기화하기 위해 배포해야 하는 사용자 지정 리소스입니다.

ScaledObject 배포 확장 정보, 이벤트 소스 메타데이터(예: 연결 비밀, 대기열 이름), 폴링 간격, 복구 기간 및 기타 데이터가 포함됩니다. 배포를 확장하기 위해 해당 자동 크기 조정 리소스(HPA 정의)가 생성됩니다.

객체일 때 ScaledObject 삭제되면 해당 HPA 정의가 지워집니다.

정의는 다음과 같습니다. ScaledObject 이 예에서는 스케일러를 사용합니다. Prometheus:

apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
metadata:
 name: prometheus-scaledobject
 namespace: default
 labels:
   deploymentName: go-prom-app
spec:
 scaleTargetRef:
   deploymentName: go-prom-app
 pollingInterval: 15
 cooldownPeriod:  30
 minReplicaCount: 1
 maxReplicaCount: 10
 triggers:
 - type: prometheus
   metadata:
     serverAddress: 
http://prometheus-service.default.svc.cluster.local:9090
     metricName: access_frequency
     threshold: '3'
     query: sum(rate(http_requests[2m]))

다음 사항을 고려하십시오.

1. 그는 다음을 가리킨다. Deployment 이름으로 go-prom-app.
2. 트리거 유형 - Prometheus. Prometheus 서버 주소는 측정항목 이름, 임계값 및 PromQL 쿼리, 이는 사용될 것입니다. PromQL 쿼리 - sum(rate(http_requests[2m])).
3. 에 따르면 pollingInterval,KEDA는 XNUMX초마다 프로메테우스에게 표적을 요청합니다. (minReplicaCount), 최대 Pod 수는 다음을 초과하지 않습니다. maxReplicaCount (이 예에서는 - XNUMX).

설치 가능 minReplicaCount XNUMX과 같습니다. 이 경우 KEDA는 XNUMX대XNUMX 배포를 활성화한 다음 추가 자동 확장을 위해 HPA를 공개합니다. 역순, 즉 XNUMX에서 XNUMX으로 크기 조정도 가능합니다. 이 예에서는 이것이 주문형 시스템이 아니라 HTTP 서비스이기 때문에 XNUMX을 선택하지 않았습니다.

자동 확장의 마법

임계값은 배포를 확장하기 위한 트리거로 사용됩니다. 이 예에서는 PromQL 쿼리 sum(rate (http_requests [2m])) 지난 XNUMX분 동안 측정된 집계된 HTTP 요청 비율(초당 요청 수)을 반환합니다.

임계값이 XNUMX이므로 값이 XNUMX개 미만인 동안 XNUMX개 미만이 된다는 의미입니다. sum(rate (http_requests [2m])) XNUMX개 미만. 값이 증가하면 매번 하위가 추가됩니다. sum(rate (http_requests [2m])) 12개 증가합니다. 예를 들어 값이 14~XNUMX이면 Pod 수는 XNUMX개입니다.

이제 설정해 보겠습니다!

사전 설정

Kubernetes 클러스터와 구성된 유틸리티만 있으면 됩니다. kubectl. 이 예에서는 클러스터를 사용합니다. minikube, 하지만 다른 것을 가져갈 수 있습니다. 클러스터를 설치하려면 지도력.

Mac에 최신 버전을 설치하세요:

curl -Lo minikube 
https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 
&& chmod +x minikube
sudo mkdir -p /usr/local/bin/
sudo install minikube /usr/local/bin/

세트 쿠 베틀Kubernetes 클러스터에 액세스합니다.

Mac에 최신 버전을 설치하세요:

curl -LO 
"https://storage.googleapis.com/kubernetes-release/release/$(curl -s
https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl"
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
kubectl version

KEDA 설치

KEDA를 여러 가지 방법으로 배포할 수 있으며 그 방법은 다음 목록에 나와 있습니다. 선적 서류 비치. 저는 모놀리식 YAML을 사용하고 있습니다.

kubectl apply -f
https://raw.githubusercontent.com/kedacore/keda/master/deploy/KedaScaleController.yaml

KEDA와 그 구성요소는 네임스페이스에 설치됩니다. keda. 확인할 명령:

kubectl get pods -n keda

KEDA Operator가 시작될 때까지 기다린 후 다음으로 이동합니다. Running State. 그 후에 계속하십시오.

Helm을 사용하여 Redis 설치

Helm이 설치되어 있지 않으면 다음을 사용하십시오. 안내. Mac에 설치하는 명령:

brew install kubernetes-helm
helm init --history-max 200

helm init 로컬 명령줄 인터페이스를 초기화하고 설치도 수행합니다. Tiller Kubernetes 클러스터에.

kubectl get pods -n kube-system | grep tiller

Tiller 포드가 실행 중 상태로 들어갈 때까지 기다립니다.

번역가의 쪽지: 작성자는 Tiller 서버 구성 요소를 설치해야 하는 Helm@2를 사용합니다. 이제 Helm@3이 적합하므로 서버 부분이 필요하지 않습니다.

Helm을 설치한 후 Redis를 시작하려면 하나의 명령으로 충분합니다.

helm install --name redis-server --set cluster.enabled=false --set 
usePassword=false stable/redis

Redis가 성공적으로 시작되었는지 확인합니다.

kubectl get pods/redis-server-master-0

Redis가 상태가 될 때까지 기다립니다. Running.

애플리케이션 배포

배포 명령:

kubectl apply -f go-app.yaml

//output
deployment.apps/go-prom-app created
service/go-prom-app-service created

모든 것이 시작되었는지 확인하세요.

kubectl get pods -l=app=go-prom-app

Redis가 상태에 들어갈 때까지 기다립니다. Running.

Prometheus 서버 배포

Prometheus 매니페스트는 다음을 사용합니다. Prometheus용 Kubernetes 서비스 검색. 서비스 레이블을 기반으로 애플리케이션 Pod를 동적으로 검색할 수 있습니다.

kubernetes_sd_configs:
   - role: service
   relabel_configs:
   - source_labels: [__meta_kubernetes_service_label_run]
     regex: go-prom-app-service
     action: keep

배치하다, 파견하다:

kubectl apply -f prometheus.yaml

//output
clusterrole.rbac.authorization.k8s.io/prometheus created
serviceaccount/default configured
clusterrolebinding.rbac.authorization.k8s.io/prometheus created
configmap/prom-conf created
deployment.extensions/prometheus-deployment created
service/prometheus-service created

모든 것이 시작되었는지 확인하세요.

kubectl get pods -l=app=prometheus-server

프로메테우스가 상태가 될 때까지 기다리세요 Running.

사용 kubectl port-forward Prometheus 사용자 인터페이스(또는 API 서버)에 액세스하려면 http://localhost:9090.

kubectl port-forward service/prometheus-service 9090

KEDA 자동 확장 구성 배포

생성하는 명령 ScaledObject:

kubectl apply -f keda-prometheus-scaledobject.yaml

KEDA 운영자 로그를 확인하세요.

KEDA_POD_NAME=$(kubectl get pods -n keda 
-o=jsonpath='{.items[0].metadata.name}')
kubectl logs $KEDA_POD_NAME -n keda

결과는 다음과 같습니다.

time="2019-10-15T09:38:28Z" level=info msg="Watching ScaledObject:
default/prometheus-scaledobject"
time="2019-10-15T09:38:28Z" level=info msg="Created HPA with 
namespace default and name keda-hpa-go-prom-app"

응용프로그램에서 확인하세요. 하나의 인스턴스가 실행 중이어야 합니다. minReplicaCount 1과 같음:

kubectl get pods -l=app=go-prom-app

HPA 리소스가 성공적으로 생성되었는지 확인합니다.

kubectl get hpa

다음과 같은 내용이 표시됩니다.

NAME                   REFERENCE                TARGETS     MINPODS   MAXPODS   REPLICAS   AGE
keda-hpa-go-prom-app   Deployment/go-prom-app   0/3 (avg)   1         10        1          45s

상태 확인: 애플리케이션 액세스

애플리케이션의 REST 엔드포인트에 액세스하려면 다음을 실행하세요.

kubectl port-forward service/go-prom-app-service 8080

이제 주소를 사용하여 Go 앱에 액세스할 수 있습니다. http://localhost:8080. 이렇게 하려면 다음 명령을 실행하세요.

curl http://localhost:8080/test

결과는 다음과 같습니다.

Accessed on 2019-10-21 11:29:10.560385986 +0000 UTC 
m=+406004.817901246
Access count 1

이 시점에서 Redis도 확인해보세요. 당신은 그 열쇠를 볼 수 있습니다 access_count 1로 증가:

kubectl exec -it redis-server-master-0 -- redis-cli get access_count
//output
"1"

측정항목 값이 다음과 같은지 확인하세요. http_requests 똑같다:

curl http://localhost:8080/metrics | grep http_requests
//output
# HELP http_requests number of http requests
# TYPE http_requests counter
http_requests 1

부하 생성

우리는 사용할 것이다 안녕 — 부하 생성을 위한 유틸리티:

curl -o hey https://storage.googleapis.com/hey-release/hey_darwin_amd64 
&& chmod a+x hey

다음 유틸리티를 다운로드할 수도 있습니다. Linux 또는 Windows.

실행하세요:

./hey http://localhost:8080/test

기본적으로 유틸리티는 200개의 요청을 보냅니다. Prometheus 측정항목과 Redis를 사용하여 이를 확인할 수 있습니다.

curl http://localhost:8080/metrics | grep http_requests
//output
# HELP http_requests number of http requests
# TYPE http_requests counter
http_requests 201
kubectl exec -it redis-server-master-0 -- redis-cli get access_count
//output
201

PromQL 쿼리에서 반환된 실제 지표 값을 확인합니다.

curl -g 
'http://localhost:9090/api/v1/query?query=sum(rate(http_requests[2m]))'
//output
{"status":"success","data":{"resultType":"vector","result":[{"metric":{},"value":[1571734214.228,"1.686057971014493"]}]}}

이 경우 실제 결과는 1,686057971014493 필드에 표시됩니다. value. 우리가 설정한 임계값은 3이므로 이는 확장에 충분하지 않습니다.

더 많은 부하!

새 터미널에서 애플리케이션 Pod 수를 모니터링합니다.

kubectl get pods -l=app=go-prom-app -w

다음 명령을 사용하여 부하를 늘려보겠습니다.

./hey -n 2000 http://localhost:8080/test

잠시 후 HPA가 배포를 확장하고 새 포드를 시작하는 것을 볼 수 있습니다. HPA를 확인하여 다음 사항을 확인하세요.

kubectl get hpa
NAME                   REFERENCE                TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
keda-hpa-go-prom-app   Deployment/go-prom-app   1830m/3 (avg)   1         10        6          4m22s

로드가 일관되지 않으면 하나의 Pod만 실행되는 지점까지 배포가 줄어듭니다. 실제 측정항목(PromQL 쿼리에서 반환됨)을 확인하려면 다음 명령을 사용하세요.

curl -g 
'http://localhost:9090/api/v1/query?query=sum(rate(http_requests[2m]))'

청소

//Delete KEDA
kubectl delete namespace keda
//Delete the app, Prometheus server and KEDA scaled object
kubectl delete -f .
//Delete Redis
helm del --purge redis-server

결론

KEDA를 사용하면 외부 지표의 데이터를 기반으로 Kubernetes 배포를 자동으로 확장할 수 있습니다(XNUMX부터). 예를 들어 Prometheus 지표, Redis의 대기열 길이, Kafka 주제의 소비자 대기 시간을 기반으로 합니다.

KEDA는 외부 소스와 통합되며 Metrics Server를 통해 수평형 포드 자동 스케일러(Horizontal Pod Autoscaler)에 해당 메트릭을 제공합니다.

행운을 빕니다!

그 밖에 읽을 내용:

1. 프로덕션 환경에서 컨테이너 및 Kubernetes를 실행하기 위한 모범 사례 및 모범 사례.
2. Kubernetes를 위한 90개 이상의 유용한 도구: 배포, 관리, 모니터링, 보안 등.
3. Telegram의 Kubernetes 주변 채널.

출처 : habr.com