ProHoster > Blog > Uprava > Samodejno skaliranje aplikacij Kubernetes z uporabo Prometheusa in KEDA

Samodejno skaliranje aplikacij Kubernetes z uporabo Prometheusa in KEDA

Samodejno skaliranje aplikacij Kubernetes z uporabo Prometheusa in KEDABalloon Man avtorja Cimuanosa

Razširljivost je ključna zahteva za aplikacije v oblaku. S Kubernetesom je skaliranje aplikacije tako preprosto kot povečanje števila replik za ustrezno uvajanje oz. ReplicaSet — vendar je to ročni postopek.

Kubernetes omogoča samodejno prilagajanje velikosti aplikacij (tj. Podov v razmestitvi oz ReplicaSet) na deklarativen način z uporabo specifikacije Horizontal Pod Autoscaler. Privzeto merilo za samodejno skaliranje so meritve uporabe procesorja (metrike virov), vendar lahko integrirate meritve po meri in zunanje podane meritve.

Ekipa Kubernetes aaS iz Mail.ru prevedel članek o uporabi zunanjih meritev za samodejno prilagajanje velikosti aplikacije Kubernetes. Da bi prikazal, kako vse deluje, avtor uporablja metriko zahteve za dostop HTTP, ki se zbira s pomočjo Prometheusa.

Namesto horizontalnega samodejnega skaliranja podov se uporablja Kubernetes Event Driven Autoscaling (KEDA), odprtokodni operater Kubernetes. Izvorno se integrira s Horizontal Pod Autoscaler, da zagotovi brezhibno samodejno skaliranje (vključno z/od nič) za delovne obremenitve, ki jih poganjajo dogodki. Koda na voljo na GitHub.

Kratek pregled sistema

Samodejno skaliranje aplikacij Kubernetes z uporabo Prometheusa in KEDA

Diagram prikazuje kratek opis, kako vse deluje:

  1. Aplikacija ponuja meritve števila zadetkov HTTP v formatu Prometheus.
  2. Prometheus je konfiguriran za zbiranje teh meritev.
  3. Prometheus skalirnik v KEDA je konfiguriran za samodejno skaliranje aplikacije glede na število zadetkov HTTP.

Zdaj vam bom podrobno povedal o vsakem elementu.

KEDA in Prometej

Prometheus je komplet orodij za spremljanje in opozarjanje odprtokodnega sistema, del Cloud Native Computing Foundation. Zbira metrike iz različnih virov in jih shranjuje kot podatke o časovni vrsti. Za vizualizacijo podatkov, ki jih lahko uporabite grafana ali druga orodja za vizualizacijo, ki delujejo z API-jem Kubernetes.

KEDA podpira koncept skalerja – deluje kot most med KEDA in zunanjim sistemom. Implementacija skalerja je specifična za vsak ciljni sistem in iz njega izvleče podatke. KEDA jih nato uporabi za nadzor samodejnega skaliranja.

Scalers podpirajo več virov podatkov, na primer Kafka, Redis, Prometheus. To pomeni, da se lahko KEDA uporablja za samodejno prilagajanje razmestitev Kubernetes z uporabo meritev Prometheus kot merila.

Testna aplikacija

Testna aplikacija Golang omogoča dostop prek HTTP in opravlja dve pomembni funkciji:

  1. Uporablja odjemalsko knjižnico Prometheus Go za instrumentiranje aplikacije in zagotavlja metriko http_requests, ki vsebuje število zadetkov. Končna točka, kjer so na voljo meritve Prometheus, se nahaja na URI /metrics. 
    var httpRequestsCounter = promauto.NewCounter(prometheus.CounterOpts{
       Name: "http_requests",
       Help: "number of http requests",
   })
  2. Kot odgovor na zahtevo GET aplikacija poveča vrednost ključa (access_count) v Redisu. To je preprost način za opravljanje dela kot del obdelovalnika HTTP in preverjanje metrik Prometheus. Vrednost meritve mora biti enaka vrednosti access_count v Redisu. 
    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)
   }

Aplikacija je nameščena v Kubernetes prek Deployment. Ustvari se tudi storitev ClusterIP, strežniku Prometheus omogoča pridobivanje metrik aplikacije.

Tu manifest uvajanja za aplikacijo.

Strežnik Prometheus

Manifest uvajanja Prometheus je sestavljen iz:

  • ConfigMap — za prenos konfiguracije Prometheus;
  • Deployment — za namestitev Prometheusa v gručo Kubernetes;
  • ClusterIP — storitev za dostop do UI Prometheus;
  • ClusterRole, ClusterRoleBinding и ServiceAccount — za samodejno zaznavanje storitev v Kubernetes (Auto-discovery).

Tu manifest za vodenje Prometheusa.

KEDA Prometheus ScaledObject

Skaler deluje kot most med KEDA in zunanjim sistemom, iz katerega je treba pridobiti meritve. ScaledObject je vir po meri, ki ga je treba razmestiti za sinhronizacijo uvajanja z virom dogodka, v tem primeru Prometheus.

ScaledObject vsebuje informacije o skaliranju uvajanja, metapodatke o izvoru dogodka (kot so skrivnosti povezave, ime čakalne vrste), interval pozivanja, obdobje obnovitve in druge podatke. Rezultat je ustrezen vir samodejnega skaliranja (definicija HPA) za skaliranje uvajanja.

Ko predmet ScaledObject je izbrisana, je ustrezna definicija HPA počiščena.

Tukaj je definicija ScaledObject za naš primer uporablja skaler 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]))

Upoštevajte naslednje točke:

  1. Pokaže na Deployment Z imenom go-prom-app.
  2. Vrsta sprožilca - Prometheus. Naslov strežnika Prometheus je omenjen skupaj z imenom metrike, pragom in Poizvedba PromQL, ki bo uporabljen. Poizvedba PromQL - sum(rate(http_requests[2m])).
  3. Glede na pollingInterval,KEDA od Prometeja zahteva tarčo vsakih petnajst sekund. Vsaj ena pod (minReplicaCount), največje število strokov pa ne presega maxReplicaCount (v tem primeru - deset).

Lahko se namesti minReplicaCount enako nič. V tem primeru KEDA aktivira uvedbo nič proti ena in nato izpostavi HPA za nadaljnje samodejno skaliranje. Možen je tudi obratni vrstni red, to je skaliranje od ena do nič. V primeru nismo izbrali ničle, ker je to storitev HTTP in ne sistem na zahtevo.

Čarovnija v samodejnem skaliranju

Prag se uporablja kot sprožilec za povečanje uvajanja. V našem primeru je poizvedba PromQL sum(rate (http_requests [2m])) vrne skupno stopnjo zahtev HTTP (zahtev na sekundo), izmerjeno v zadnjih dveh minutah.

Ker je mejna vrednost tri, to pomeni, da bo ena pod vrednostjo sum(rate (http_requests [2m])) manj kot tri. Če se vrednost poveča, se vsakič doda še en sub sum(rate (http_requests [2m])) poveča za tri. Na primer, če je vrednost od 12 do 14, je število strokov štiri.

Zdaj pa ga poskusimo nastaviti!

prednastavitev

Vse, kar potrebujete, je gruča Kubernetes in konfiguriran pripomoček kubectl. Ta primer uporablja gručo minikube, lahko pa vzamete katero koli drugo. Za namestitev grozda obstaja vodstvo.

Namestite najnovejšo različico na 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/

Set kubectlza dostop do gruče Kubernetes.

Namestite najnovejšo različico na 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

Namestitev KEDA

KEDA lahko namestite na več načinov, ki so navedeni v dokumentacijo. Uporabljam monolitni YAML:

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

KEDA in njene komponente so nameščene v imenski prostor keda. Ukaz za preverjanje:

kubectl get pods -n keda

Počakajte, da se KEDA Operator zažene in pojdite na Running State. In po tem nadaljujte.

Namestitev Redisa z uporabo Helma

Če nimate nameščenega Helma, uporabite to vodstvo. Ukaz za namestitev na Mac:

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

helm init inicializira lokalni vmesnik ukazne vrstice in tudi namesti Tiller v gručo Kubernetes.

kubectl get pods -n kube-system | grep tiller

Počakajte, da krmilna enota preide v stanje delovanja.

Opomba prevajalca: Avtor uporablja Helm@2, ki zahteva namestitev strežniške komponente Tiller. Zdaj je Helm@3 aktualen, ne potrebuje strežniškega dela.

Po namestitvi Helma je za zagon Redisa dovolj en ukaz:

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

Preverite, ali se je Redis uspešno zagnal:

kubectl get pods/redis-server-master-0

Počakajte, da Redis preide v stanje Running.

Namestitev aplikacije

Ukaz za uvajanje:

kubectl apply -f go-app.yaml

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

Preverite, ali se je vse začelo:

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

Počakajte, da Redis preide v stanje Running.

Namestitev strežnika Prometheus

Manifest Prometheus uporablja Odkritje storitve Kubernetes za Prometheus. Omogoča dinamično odkrivanje sklopov aplikacij na podlagi storitvene oznake.

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

Za uvajanje:

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

Preverite, ali se je vse začelo:

kubectl get pods -l=app=prometheus-server

Počakajte, da Prometheus preide v stanje Running.

Uporabi kubectl port-forward za dostop do uporabniškega vmesnika Prometheus (ali strežnika API) na http://localhost:9090.

kubectl port-forward service/prometheus-service 9090

Uvajanje konfiguracije samodejnega skaliranja KEDA

Ukaz za ustvarjanje ScaledObject:

kubectl apply -f keda-prometheus-scaledobject.yaml

Preverite dnevnike operaterja KEDA:

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

Rezultat izgleda nekako takole:

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"

Preverite pod aplikacijami. En primerek se mora izvajati, ker minReplicaCount je enako 1:

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

Preverite, ali je bil vir HPA uspešno ustvarjen:

kubectl get hpa

Videti bi morali nekaj takega:

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

Pregled zdravja: dostop do aplikacije

Za dostop do končne točke REST naše aplikacije zaženite:

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

Zdaj lahko z naslovom dostopate do svoje aplikacije Go http://localhost:8080. Če želite to narediti, zaženite ukaz:

curl http://localhost:8080/test

Rezultat izgleda nekako takole:

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

Na tej točki preverite tudi Redis. Videli boste, da je ključ access_count povečano na 1:

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

Prepričajte se, da je metrična vrednost http_requests enako:

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

Ustvarjanje obremenitve

Uporabili bomo hej — pripomoček za ustvarjanje obremenitve:

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

Lahko tudi prenesete pripomoček za Linux ali Windows.

Zaženi:

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

Privzeto pripomoček pošlje 200 zahtev. To lahko preverite z uporabo metrik Prometheus in 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

Preverite vrednost dejanske metrike (ki jo vrne poizvedba 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"]}]}}

V tem primeru je dejanski rezultat 1,686057971014493 in se prikaže v polju value. To ni dovolj za skaliranje, saj je prag, ki smo ga nastavili, 3.

Več obremenitve!

V novem terminalu spremljajte število podov aplikacij:

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

Povečajmo obremenitev z ukazom: 

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

Čez nekaj časa boste videli, kako HPA spreminja uvajanje in lansira nove sklope. Preverite HPA in se prepričajte:

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

Če je obremenitev nedosledna, se bo razporeditev zmanjšala do točke, ko bo delovala samo ena enota. Če želite preveriti dejansko metriko (ki jo vrne poizvedba PromQL), uporabite ukaz:

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

Čiščenje

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

Zaključek

KEDA vam omogoča samodejno prilagajanje razmestitev Kubernetes (na/od nič) na podlagi podatkov iz zunanjih meritev. Na primer na podlagi meritev Prometheus, dolžine čakalne vrste v Redisu, zakasnitve potrošnikov v temi Kafka.

KEDA se integrira z zunanjim virom in posreduje svoje meritve prek strežnika Metrics v Horizontal Pod Autoscaler.

Srečno!

Kaj še prebrati:

  1. Najboljše prakse in najboljše prakse za izvajanje vsebnikov in Kubernetes v produkcijskih okoljih.
  2. 90+ uporabnih orodij za Kubernetes: uvajanje, upravljanje, spremljanje, varnost in drugo.
  3. Naš kanal Around Kubernetes v Telegramu.

Vir: www.habr.com

Dodaj komentar