🥇Autoskalering av Kubernetes-applikasjoner ved hjelp av Prometheus og KEDA

Balloon Man av Cimuanos

Skalerbarhet er et nøkkelkrav for skyapplikasjoner. Med Kubernetes er det like enkelt å skalere en applikasjon som å øke antallet replikaer for riktig distribusjon eller ReplicaSet – men det er en manuell prosess.

Kubernetes lar applikasjoner skaleres automatisk (dvs. Pods i en distribusjon eller ReplicaSet) på en deklarativ måte ved å bruke Horizontal Pod Autoscaler-spesifikasjonen. Standardkriteriet for automatisk skalering er CPU-bruksmålinger (ressursmålinger), men du kan integrere egendefinerte og eksternt leverte beregninger.

Lag Kubernetes aaS fra Mail.ru oversatte en artikkel om hvordan du bruker eksterne beregninger for å automatisk skalere en Kubernetes-applikasjon. For å vise hvordan alt fungerer, bruker forfatteren HTTP-tilgangsberegninger, som samles inn ved hjelp av Prometheus.

I stedet for horisontal autoskalering av pods, brukes Kubernetes Event Driven Autoscaling (KEDA), en åpen kildekode Kubernetes-operatør. Den integreres naturlig med Horizontal Pod Autoscaler for å gi sømløs autoskalering (inkludert til/fra null) for hendelsesdrevne arbeidsbelastninger. Kode tilgjengelig på GitHub.

Kort oversikt over systemet

Diagrammet viser en kort beskrivelse av hvordan alt fungerer:

Applikasjonen gir HTTP-tallberegninger i Prometheus-format.
Prometheus er konfigurert til å samle inn disse beregningene.
Prometheus-skalereren i KEDA er konfigurert til å automatisk skalere applikasjonen basert på antall HTTP-treff.

Nå vil jeg fortelle deg i detalj om hvert element.

KEDA og Prometheus

Prometheus er et åpen kildekode-system overvåking og varsling verktøysett, del Cloud Native Computing Foundation. Samler inn beregninger fra ulike kilder og lagrer dem som tidsseriedata. For å visualisere data kan du bruke grafana eller andre visualiseringsverktøy som fungerer med Kubernetes API.

KEDA støtter konseptet med en scaler - den fungerer som en bro mellom KEDA og det eksterne systemet. Skaleringsimplementeringen er spesifikk for hvert målsystem og trekker ut data fra det. KEDA bruker dem deretter til å kontrollere automatisk skalering.

Skalere støtter flere datakilder, for eksempel Kafka, Redis, Prometheus. Det vil si at KEDA kan brukes til å automatisk skalere Kubernetes-distribusjoner ved å bruke Prometheus-beregninger som kriterier.

Testapplikasjon

Golang-testapplikasjonen gir tilgang via HTTP og utfører to viktige funksjoner:

Bruker Prometheus Go-klientbiblioteket til å instrumentere applikasjonen og gi http_requests-beregningen, som inneholder et antall treff. Endepunktet der Prometheus-målinger er tilgjengelige, er plassert ved URI /metrics.
```
var httpRequestsCounter = promauto.NewCounter(prometheus.CounterOpts{
       Name: "http_requests",
       Help: "number of http requests",
   })
```

Som svar på en forespørsel GET applikasjonen øker verdien av nøkkelen (access_count) i Redis. Dette er en enkel måte å gjøre arbeidet som en del av en HTTP-behandler og også sjekke Prometheus-beregninger. Den metriske verdien må være den samme som verdien access_count i Redis.

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

Applikasjonen distribueres til Kubernetes via Deployment. Det opprettes også en tjeneste ClusterIP, lar den Prometheus-serveren hente applikasjonsmålinger.

Her distribusjonsmanifest for applikasjonen.

Prometheus server

Prometheus-implementeringsmanifestet består av:

ConfigMap — å overføre Prometheus-konfigurasjonen;
Deployment — for å distribuere Prometheus i en Kubernetes-klynge;
ClusterIP — tjeneste for tilgang til UI Prometheus;
ClusterRole, ClusterRoleBinding и ServiceAccount — for automatisk gjenkjenning av tjenester i Kubernetes (Auto-discovery).

Her manifest for å kjøre Prometheus.

KEDA Prometheus ScaledObject

Skaleren fungerer som en bro mellom KEDA og det eksterne systemet som metrikk må hentes fra. ScaledObject er en tilpasset ressurs som må distribueres for å synkronisere distribusjonen med hendelseskilden, i dette tilfellet Prometheus.

ScaledObject inneholder distribusjonsskaleringsinformasjon, metadata for hendelseskilden (som tilkoblingshemmeligheter, kønavn), pollingintervall, gjenopprettingsperiode og andre data. Det resulterer i den tilsvarende autoskaleringsressursen (HPA-definisjon) for å skalere distribusjonen.

Når en gjenstand ScaledObject slettes, slettes den tilsvarende HPA-definisjonen.

Her er definisjonen ScaledObject for vårt eksempel bruker den en scaler 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]))

Tenk på følgende punkter:

Han peker på Deployment Med navn go-prom-app.
Triggertype - Prometheus. Prometheus-serveradressen er nevnt sammen med metrisk navn, terskel og PromQL-spørring, som vil bli brukt. PromQL spørring - sum(rate(http_requests[2m])).
Ifølge pollingInterval,KEDA ber om et mål fra Prometheus hvert femtende sekund. Minst én under (minReplicaCount), og det maksimale antallet pods overskrider ikke maxReplicaCount (i dette eksemplet - ti).

Kan installere minReplicaCount lik null. I dette tilfellet aktiverer KEDA null-til-en-distribusjonen og avslører deretter HPA for ytterligere automatisk skalering. Omvendt rekkefølge er også mulig, det vil si skalering fra én til null. I eksemplet valgte vi ikke null fordi dette er en HTTP-tjeneste og ikke et on-demand-system.

Magien i autoskalering

Terskelen brukes som en utløser for å skalere distribusjonen. I vårt eksempel, PromQL-spørringen sum(rate (http_requests [2m])) returnerer den aggregerte HTTP-forespørselsfrekvensen (forespørsler per sekund), målt over de siste to minuttene.

Siden terskelverdien er tre, betyr det at det vil være én under mens verdien sum(rate (http_requests [2m])) mindre enn tre. Hvis verdien øker, legges det til en ekstra sub hver gang sum(rate (http_requests [2m])) øker med tre. For eksempel, hvis verdien er fra 12 til 14, er antallet pods fire.

La oss nå prøve å sette den opp!

forhåndsinnstilling

Alt du trenger er en Kubernetes-klynge og et konfigurert verktøy kubectl. Dette eksemplet bruker en klynge minikube, men du kan ta hvilken som helst annen. For å installere en klynge er det lederskap.

Installer den nyeste versjonen på 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/

Satt kubectlfor å få tilgang til Kubernetes-klyngen.

Installer den nyeste versjonen på 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 installasjon

Du kan distribuere KEDA på flere måter, de er oppført i dokumentasjon. Jeg bruker monolittisk YAML:

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

KEDA og dets komponenter er installert i navneområdet keda. Kommando for å sjekke:

kubectl get pods -n keda

Vent til KEDA-operatøren starter og går til Running State. Og etter det, fortsett.

Installere Redis ved hjelp av Helm

Hvis du ikke har Helm installert, bruk denne ledelse. Kommando for å installere på Mac:

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

helm init initialiserer det lokale kommandolinjegrensesnittet og installerer også Tiller til Kubernetes-klyngen.

kubectl get pods -n kube-system | grep tiller

Vent til Tiller-poden går inn i kjøretilstand.

Oversetterens notat: Forfatteren bruker Helm@2, som krever at Tiller-serverkomponenten er installert. Nå er Helm@3 relevant, det krever ingen serverdel.

Etter å ha installert Helm, er én kommando nok til å starte Redis:

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

Bekreft at Redis har startet vellykket:

kubectl get pods/redis-server-master-0

Vent til Redis går inn i staten Running.

Applikasjonsimplementering

Implementeringskommando:

kubectl apply -f go-app.yaml

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

Sjekk at alt har startet:

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

Vent til Redis går inn i tilstanden Running.

Distribuere en Prometheus-server

Prometheus-manifestet bruker Kubernetes Service Discovery for Prometheus. Den tillater dynamisk oppdagelse av applikasjonsputer basert på tjenesteetiketten.

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

For å distribuere:

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

Sjekk at alt har startet:

kubectl get pods -l=app=prometheus-server

Vent til Prometheus skal gå inn i staten Running.

bruk kubectl port-forward for å få tilgang til Prometheus brukergrensesnitt (eller API-server) på http://localhost:9090.

kubectl port-forward service/prometheus-service 9090

Implementere KEDA Autoscaling Configuration

Kommando for å opprette ScaledObject:

kubectl apply -f keda-prometheus-scaledobject.yaml

Sjekk KEDA-operatørloggene:

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

Resultatet ser omtrent slik ut:

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"

Sjekk under søknader. Én forekomst må kjøres pga minReplicaCount tilsvarer 1:

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

Bekreft at HPA-ressursen ble opprettet:

kubectl get hpa

Du bør se noe sånt som:

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

Helsesjekk: applikasjonstilgang

For å få tilgang til applikasjonens REST-endepunkt, kjør:

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

Du kan nå få tilgang til Go-appen din ved å bruke adressen http://localhost:8080. For å gjøre dette, kjør kommandoen:

curl http://localhost:8080/test

Resultatet ser omtrent slik ut:

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

Sjekk også Redis på dette tidspunktet. Du vil se at nøkkelen access_count økt til 1:

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

Sørg for at den metriske verdien er http_requests det samme:

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

Lastoppretting

Vi vil bruke hey – verktøy for å generere last:

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

Du kan også laste ned verktøyet for Linux eller Windows.

Kjør det:

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

Som standard sender verktøyet 200 forespørsler. Du kan bekrefte dette ved å bruke Prometheus-beregninger så vel som 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

Valider verdien av den faktiske beregningen (returnert av PromQL-spørringen):

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

I dette tilfellet er det faktiske resultatet 1,686057971014493 og vises i feltet value. Dette er ikke nok for skalering, siden terskelen vi setter er 3.

Mer belastning!

I den nye terminalen, overvåk antall applikasjonsputer:

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

La oss øke belastningen ved å bruke kommandoen:

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

Etter en stund vil du se HPA skalere distribusjonen og lansere nye pods. Sjekk din HPA for å være sikker på:

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

Hvis belastningen er inkonsekvent, vil distribusjonen reduseres til det punktet hvor bare én pod kjører. Hvis du vil sjekke den faktiske metrikken (returnert av PromQL-spørringen), bruker du kommandoen:

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

rengjøring

//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

Konklusjon

KEDA lar deg automatisk skalere Kubernetes-distribusjonene dine (til/fra null) basert på data fra eksterne beregninger. For eksempel, basert på Prometheus-målinger, kølengde i Redis, forbrukerlatens i Kafka-emnet.

KEDA integreres med en ekstern kilde og gir også sine beregninger gjennom Metrics Server til Horizontal Pod Autoscaler.

Lykke til!

Hva annet å lese:

Kilde: www.habr.com

Autoskalering av Kubernetes-applikasjoner ved hjelp av Prometheus og KEDA