🥇Autoskaling Kubernetes-aplikoj uzante Prometheus kaj KEDA

Balonulo de Cimuanos

Skalebleco estas ŝlosila postulo por nubaj aplikoj. Kun Kubernetes, grimpi aplikaĵon estas tiel simpla kiel pliigi la nombron da kopioj por la taŭga disvastigo aŭ ReplicaSet — sed ĝi estas mana procezo.

Kubernetes permesas al aplikoj esti aŭtomate skalitaj (t.e. Pods en deplojo aŭ ReplicaSet) en deklara maniero uzante la Horizontal Pod Autoscaler-specifon. La defaŭlta kriterio por aŭtomata skalo estas CPU-uzometriko (rimedometriko), sed vi povas integri kutimajn kaj ekstere provizitajn metrikojn.

teamo Kubernetes aaS de Mail.ru tradukis artikolon pri kiel uzi eksterajn metrikojn por aŭtomate skali aplikaĵon de Kubernetes. Por montri kiel ĉio funkcias, la aŭtoro uzas mezurojn pri HTTP-alira peto, kiuj estas kolektitaj per Prometheus.

Anstataŭ horizontala aŭtoskalado de balgoj, Kubernetes Event Driven Autoscaling (KEDA) estas uzata, malfermfonta Kubernetes-funkciigisto. Ĝi integriĝas denaske kun Horizontal Pod Autoscaler por disponigi senjuntan aŭtoskalon (inkluzive al/de nulo) por okazaĵ-movitaj laborkvantoj. Kodo havebla ĉe GitHub.

Mallonga superrigardo de la sistemo

La diagramo montras mallongan priskribon de kiel ĉio funkcias:

La aplikaĵo provizas HTTP-trafkalkulajn metrikojn en Prometheus-formato.
Prometheus estas agordita por kolekti ĉi tiujn metrikojn.
La Prometheus scaler en KEDA estas agordita por aŭtomate skali la aplikaĵon surbaze de la nombro da HTTP-sukcesoj.

Nun mi rakontos al vi detale pri ĉiu elemento.

KEDA kaj Prometeo

Prometheus estas malfermfonta sistemo monitora kaj atentiga ilaro, parto Cloud Native Computing Foundation. Kolektas metrikojn de diversaj fontoj kaj konservas ilin kiel temposeriajn datumojn. Por bildigi datumojn vi povas uzi grafana aŭ aliaj bildigaj iloj, kiuj funkcias kun la Kubernetes API.

KEDA subtenas la koncepton de skalilo - ĝi funkcias kiel ponto inter KEDA kaj la ekstera sistemo. La efektivigo de scaler estas specifa por ĉiu celsistemo kaj ĉerpas datumojn de ĝi. KEDA tiam uzas ilin por kontroli aŭtomatan skalon.

Skaliloj subtenas plurajn datumfontojn, ekzemple, Kafka, Redis, Prometheus. Tio estas, KEDA povas esti uzata por aŭtomate skali Kubernetes-deplojojn uzante Prometheus-metrikojn kiel kriteriojn.

Testa aplikaĵo

La Golang-testa aplikaĵo disponigas aliron per HTTP kaj plenumas du gravajn funkciojn:

Uzas la klientbibliotekon de Prometheus Go por instrumentigi la aplikaĵon kaj provizi la http_requests-metrikon, kiu enhavas furorkalkulon. La finpunkto kie Prometheus-metrikoj estas haveblaj situas ĉe la URI /metrics.
```
var httpRequestsCounter = promauto.NewCounter(prometheus.CounterOpts{
       Name: "http_requests",
       Help: "number of http requests",
   })
```

Responde al peto GET la aplikaĵo pliigas la valoron de la ŝlosilo (access_count) en Redis. Ĉi tio estas facila maniero fari la laboron kiel parto de HTTP-traktilo kaj ankaŭ kontroli Prometheus-metrikojn. La metrika valoro devas esti la sama kiel la valoro access_count en 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)
   }

La aplikaĵo estas deplojita al Kubernetes per Deployment. Ankaŭ estas kreita servo ClusterIP, ĝi permesas al la Prometheus-servilo akiri aplikajn metrikojn.

tie deplojo manifesto por la aplikaĵo.

Prometheus Server

La Prometheus-deploja manifesto konsistas el:

ConfigMap — translokigi la agordon de Prometheus;
Deployment — por deploji Prometheus en Kubernetes-areo;
ClusterIP — servo por aliro al UI Prometheus;
ClusterRole, ClusterRoleBinding и ServiceAccount — por aŭtomata detekto de servoj en Kubernetes (aŭtomata malkovro).

tie manifest por kurado de Prometeo.

KEDA Prometheus ScaledObject

La scaler funkcias kiel ponto inter KEDA kaj la ekstera sistemo de kiu metriko devas esti akirita. ScaledObject estas kutima rimedo, kiu devas esti deplojita por sinkronigi la deplojon kun la okazaĵfonto, ĉi-kaze Prometeo.

ScaledObject enhavas deplojajn skalinformojn, okazaĵfontajn metadatenojn (kiel ekzemple ligsekretoj, atendovicnomo), balotintervalon, normaligperiodon, kaj aliajn datenojn. Ĝi rezultigas la respondan aŭtoskalan rimedon (HPA-difino) por skali la deplojon.

Kiam objekto ScaledObject estas forigita, la responda HPA-difino estas forigita.

Jen la difino ScaledObject por nia ekzemplo, ĝi uzas skalilon 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]))

Konsideru la sekvajn punktojn:

Li montras al Deployment Kun nomo go-prom-app.
Tipo de ellasilo - Prometheus. La Prometheus servila adreso estas menciita kune kun la metrika nomo, sojlo kaj PromQL-demando, kiu estos uzata. Demando de PromQL - sum(rate(http_requests[2m])).
Laŭ pollingInterval,KEDA petas celon de Prometeo ĉiujn dek kvin sekundojn. Almenaŭ unu sub (minReplicaCount), kaj la maksimuma nombro da balgoj ne superas maxReplicaCount (en ĉi tiu ekzemplo - dek).

Povas instali minReplicaCount egala al nulo. En ĉi tiu kazo, KEDA aktivigas la nul-al-unu deplojon kaj tiam elmontras la HPA por plia aŭtomata skalo. La inversa ordo ankaŭ eblas, tio estas, grimpi de unu al nulo. En la ekzemplo, ni ne elektis nulon ĉar ĉi tio estas HTTP-servo kaj ne laŭpeta sistemo.

La magio ene de aŭtoskalado

La sojlo estas uzata kiel ellasilo por skali la deplojon. En nia ekzemplo, la demando PromQL sum(rate (http_requests [2m])) resendas la aldonitan HTTP-peton (petoj je sekundo), mezurita dum la lastaj du minutoj.

Ĉar la sojla valoro estas tri, tio signifas, ke estos unu sub dum la valoro sum(rate (http_requests [2m])) malpli ol tri. Se la valoro pliiĝas, ĉiufoje aldoniĝas plia subaĵo sum(rate (http_requests [2m])) pliiĝas je tri. Ekzemple, se la valoro estas de 12 ĝis 14, tiam la nombro da balgoj estas kvar.

Nun ni provu agordi ĝin!

Antaŭ-agordo

Ĉio, kion vi bezonas, estas Kubernetes-grupo kaj agordita ilo kubectl. Ĉi tiu ekzemplo uzas areton minikube, sed vi povas preni ajnan alian. Por instali grapolon ekzistas gvidado.

Instalu la lastan version en 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/

Instali kubectlpor aliri la Kubernetes-areton.

Instalu la lastan version en 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

Instalado de KEDA

Vi povas deploji KEDA en pluraj manieroj, ili estas listigitaj en dokumentado. Mi uzas monolitan YAML:

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

KEDA kaj ĝiaj komponantoj estas instalitaj en la nomspacon keda. Ordono por kontroli:

kubectl get pods -n keda

Atendu ke KEDA Operator komenciĝu kaj iru al Running State. Kaj post tio, daŭrigu.

Instalante Redis uzante Helm

Se vi ne havas Helm instalitan, uzu ĉi tion gvidado. Komando por instali en Mac:

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

helm init pravigigas la lokan komandlinian interfacon kaj ankaŭ instalas Tiller al la Kubernetes-areto.

kubectl get pods -n kube-system | grep tiller

Atendu, ke la Tiller pod eniru la Kurantan staton.

Noto de la tradukinto: La aŭtoro uzas Helm@2, kiu postulas ke la Tiller-servila komponanto estu instalita. Nun Helm@3 rilatas, ĝi ne postulas servilan parton.

Post instalo de Helm, unu komando sufiĉas por komenci Redis:

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

Kontrolu, ke Redis komenciĝis sukcese:

kubectl get pods/redis-server-master-0

Atendu, ke Redis iru en ŝtaton Running.

Apliko Deplojo

Deploja komando:

kubectl apply -f go-app.yaml

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

Kontrolu, ke ĉio komenciĝis:

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

Atendu ke Redis eniru ŝtaton Running.

Deplojante Prometheus Server

La manifesto Prometeo uzas Kubernetes Service Discovery por Prometeo. Ĝi permesas dinamikan malkovron de aplikaĵopodoj bazitaj sur la serva etikedo.

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

Por disfaldi:

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

Kontrolu, ke ĉio komenciĝis:

kubectl get pods -l=app=prometheus-server

Atendu, ke Prometeo iru en ŝtaton Running.

Uzu kubectl port-forward por aliri la uzantinterfacon de Prometheus (aŭ API-servilon) ĉe http://localhost:9090.

kubectl port-forward service/prometheus-service 9090

Deplojante KEDA Autoscaling Agordo

Komando por krei ScaledObject:

kubectl apply -f keda-prometheus-scaledobject.yaml

Kontrolu la protokolojn de KEDA-funkciigisto:

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

La rezulto aspektas kiel ĉi tio:

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"

Kontrolu sub aplikoj. Unu kazo devas funkcii ĉar minReplicaCount egalas 1:

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

Kontrolu, ke la HPA-rimedo estis kreita sukcese:

kubectl get hpa

Vi devus vidi ion kiel:

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

Sankontrolo: aliro al aplikaĵo

Por aliri la REST-finpunkton de nia aplikaĵo, rulu:

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

Vi nun povas aliri vian Go-aplikaĵon uzante la adreson http://localhost:8080. Por fari tion, rulu la komandon:

curl http://localhost:8080/test

La rezulto aspektas kiel ĉi tio:

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

Je ĉi tiu punkto ankaŭ kontrolu Redis. Vi vidos ke la ŝlosilo access_count pliigita al 1:

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

Certigu, ke la metrika valoro estas http_requests la sama:

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

Ŝarĝu Kreado

Ni uzos hej - utileco por generi ŝarĝon:

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

Vi ankaŭ povas elŝuti la ilon por linux aŭ fenestroj.

Rulu ĝin:

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

Defaŭlte, la ilo sendas 200 petojn. Vi povas kontroli ĉi tion uzante Prometheus-metrikojn same kiel 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

Validu la valoron de la reala metriko (revenita de la PromQL-demando):

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

En ĉi tiu kazo la reala rezulto estas 1,686057971014493 kaj estas montrata sur la kampo value. Ĉi tio ne sufiĉas por grimpi, ĉar la sojlo, kiun ni fiksas, estas 3.

Pli da ŝarĝo!

En la nova terminalo, kontrolu la nombron da aplikaĵpodoj:

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

Ni pliigu la ŝarĝon per la komando:

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

Post iom da tempo, vi vidos HPA grimpi la deplojon kaj lanĉi novajn podojn. Kontrolu vian HPA por certigi:

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

Se la ŝarĝo estas malkonsekvenca, la deplojo estos reduktita al la punkto kie nur unu balgo funkcias. Se vi volas kontroli la realan metrikon (revenitan de la PromQL-demando), tiam uzu la komandon:

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

konkludo

KEDA permesas vin aŭtomate skali viajn Kubernetes-deplojojn (al/de nulo) surbaze de datumoj de eksteraj metrikoj. Ekzemple, surbaze de Prometheus-metriko, vostolongo en Redis, konsumanta latenco en Kafka temo.

KEDA integriĝas kun ekstera fonto kaj ankaŭ provizas ĝiajn metrikojn per Metrics Server al Horizontal Pod Autoscaler.

Bonŝancon!

Kion alian legi:

fonto: www.habr.com

Aŭtoskalaj aplikaĵoj de Kubernetes uzante Prometheus kaj KEDA