ProHoster > Blog > Administrim > Autoskallimi i aplikacioneve Kubernetes me ndihmën e Prometheus dhe KEDA

Autoskallimi i aplikacioneve Kubernetes me ndihmën e Prometheus dhe KEDA

Autoskallimi i aplikacioneve Kubernetes me ndihmën e Prometheus dhe KEDABalloon Man nga Cimuanos

SkalueshmĂ«ria Ă«shtĂ« njĂ« kĂ«rkesĂ« kyçe pĂ«r aplikacionet nĂ« re. Me Kubernetes, tĂ« shkallosh njĂ« aplikacion Ă«shtĂ« po aq e lehtĂ« sa tĂ« rritĂ«sh numrin e replikeve pĂ«r pĂ«rkatĂ«sin pĂ«rkatĂ«s ose ReplicaSet — por ky Ă«shtĂ« njĂ« proces manual.

Kubernetes lejon që aplikacionet të shkallohen automatikisht (dmth Pod në përkatësinë ose ReplicaSet) në mënyrë deklarative duke përdorur specifikimin Horizontal Pod Autoscaler. Në përputhje me këtë, kriteri për shkallim automatik është metrika e përdorimit të CPU (metrika e burimeve), por mund të integrohen metrika të personalizuara dhe metrika të ofruara nga jashtë.

Ekipa Kubernetes aaS nga Mail.ru përkthimi i një artikulli rreth përdorimit të metricave të jashtme për automatikisht shkallim të aplikacioneve Kubernetes. Për të treguar se si funksionon gjithçka, autori përdor metrika të kërkesave HTTP, të cilat mblidhen me Prometheus.

NĂ« vend tĂ« automatik shkallimit horizontal tĂ« podĂ«ve, aplikohet Kubernetes Event Driven Autoscaling (KEDA) — njĂ« operator Kubernetes me burim tĂ« hapur. Ai integrohet fillimisht me Horizontal Pod Autoscaler pĂ«r tĂ« siguruar shkallim tĂ« qetĂ« (pĂ«rfshirĂ« deri/nga zero) pĂ«r ngarkesat e punĂ«s tĂ« menaxhuar nga ngjarjet. Kodi Ă«shtĂ« nĂ« dispozicion nĂ« GitHub.

Një përmbledhje e shkurtër e funksionimit të sistemit

Autoskallimi i aplikacioneve Kubernetes me ndihmën e Prometheus dhe KEDA

NĂ« diagram — njĂ« pĂ«rshkrim tĂ« pĂ«rmbledhur se si funksionon gjithçka:

  1. Aplikacioni ofron metrika për numrin e kërkesave HTTP në formatin Prometheus.
  2. Prometheus është i konfiguruar për të mbledhur këto tregues.
  3. Skaluesi Prometheus në KEDA është konfiguruar për shkallim automatik të aplikacionit në bazë të numrit të kërkesave HTTP.

Tani do të flas në detaje mbi secilin element.

KEDA dhe Prometheus

Prometheus është një grup mjetesh për monitorimin dhe alarmimin e sistemeve me burim të hapur, pjesë e Cloud Native Computing Foundation. Ai mbledh metrika nga burime të ndryshme dhe i ruan si të dhëna të serive të kohës. Për vizualizimin e të dhënave, mund të përdoren Nëse tashmë e dini se çfarë është analiza e grupeve dhe se si ta bëni në SQL, kaloni menjëherë në seksionin e fundit. ose mjete të tjera vizualizimi që punojnë me API-in e Kubernetes.

KEDA mbĂ«shtet konceptin e skaluesit — ai vepron si njĂ« urĂ« midis KEDA dhe njĂ« sistemi tĂ« jashtĂ«m. Implementimi i skaluesit Ă«shtĂ« specifik pĂ«r çdo sistem tĂ« synuar dhe nxjerr tĂ« dhĂ«na prej saj. Pastaj, KEDA i pĂ«rdor ato pĂ«r tĂ« menaxhuar shkallimin automatik.

Skalierët mbështesin disa burime të dhënash, për shembull, Kafka, Redis, Prometheus. Pra, KEDA mund të përdoret për automatizimin e shkallëzimit të shpërndarjeve Kubernetes, duke përdorur metrikat e Prometheus si kriter.

Aplikacioni prova

Aplikacioni Golang i testit ofron akses përmes HTTP dhe kryen dy funksione të rëndësishme:

  1. Përdor bibliotën e klientit të Prometheus Go për të instrumentuar aplikacionin dhe ofruar metrikën http_requests, e cila përmban një numërues të thirrjeve. Pikë e fundit, ku metrikat e Prometheus janë të disponueshme, ndodhet në URI /metrics.
    var httpRequestsCounter = promauto.NewCounter(prometheus.CounterOpts{
       Name: "http_requests",
       Help: "numri i thirrjeve http",
   })
  2. Në përgjigje të kërkesës GET aplikacioni rrit vlerën e çelësit (access_count) në Redis. Kjo është një mënyrë e thjeshtë për të kryer punën si pjesë e përpunuesit HTTP, si dhe për të kontrolluar metrikat e Prometheus. Vlera e metrikës duhet të jetë e njëjtë me vlerën access_count në 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("Nuk mund të rritet numëruesi redis", err)
               os.Exit(1)
           }
           resp := "Këtu është aksesuar në " + time.Now().String() + "nNumri i aksesimeve " + strconv.Itoa(int(count))
           w.Write([]byte(resp))
       })
       http.ListenAndServe(":8080", nil)
   }

Aplikacioni shpërndahet në Kubernetes përmes Zhvillimi. Gjithashtu krijohet një shërbim ClusterIP, ai lejon serverin e Prometheus të marrë metrikat e aplikacionit.

Ja manifesti i shpërndarjes për aplikacionin.

Serveri Prometheus

Manifesti i shpërndarjes së Prometheus përbëhet nga:

  • ConfigMap — pĂ«r tĂ« transmetuar konfigurimin e Prometheus;
  • Zhvillimi — pĂ«r tĂ« shpĂ«rndarĂ« Prometheus nĂ« klasterin Kubernetes;
  • ClusterIP — shĂ«rbim pĂ«r access nĂ« UI-nĂ« e Prometheus;
  • ClusterRole, ClusterRoleBinding dhe ServiceAccount — pĂ«r tĂ« punuar me autoidentifikimin e shĂ«rbimeve nĂ« Kubernetes (Auto-discovery).

Ja manifesti për të drejtuar Prometheus.

KEDA Prometheus ScaledObject

Skalieri vepron si njĂ« urĂ« midis KEDA-s dhe sistemit tĂ« jashtĂ«m nga i cili duhet marrĂ« metrikat. ScaledObject — njĂ« burim i konfiguruar, e cila duhet tĂ« shpĂ«rndahet pĂ«r tĂ« sinkronizuar shpĂ«rndarjen me burimin e ngjarjeve, nĂ« kĂ«tĂ« rast me Prometheus.

ScaledObject përmban informacion mbi shkallëzimin e shpërndarjes, metadata rreth burimit të ngjarjeve (për shembull, sekretet për lidhje, emri i radhës), intervalin e sondazhit, periudhën e rimëkëmbjes dhe të dhëna të tjera. Ai çon në burimin përkatës të automatik-skalimit (definimin HPA) për shkallëzimin e shpërndarjes.

Kur objekti ScaledObject këto fshihen, përkufizimi i tij HPA pastron.

Këtu është përkufizimi ScaledObject për shembullin tonë, në të përdoret 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]))

Keni parasysh këto pika:

  1. Ai tregon për Zhvillimi me emrin go-prom-app.
  2. Lloji i aktivizuesit është Prometheus. Adresa e serverit Prometheus përmendet së bashku me emrin e metrikës, vlerën prag dhe kërkesën PromQL, e cila do të përdoret. Kërkesa PromQL është sum(rate(http_requests[2m])).
  3. Sipas pollingInterval, KEDA pyet qĂ«llimin nga Prometheus çdo pesĂ«mbĂ«dhjetĂ« sekonda. MbĂ«shtetet njĂ« minimum prej njĂ« podi (minReplicaCount), dhe numri maksimal i podĂ«ve nuk tejkalon maxReplicaCount (nĂ« kĂ«tĂ« shembull — dhjetĂ«).

Mund tĂ« vendoset minReplicaCount tĂ« jetĂ« zero. NĂ« kĂ«tĂ« rast, KEDA aktivizon shpĂ«rndarjen nga zero nĂ« njĂ«, dhe mĂ« pas ofron HPA pĂ«r rritjen e mĂ«tejshme automatike. ËshtĂ« e mundur edhe rendi i kundĂ«rt, dmth, rritja nga njĂ« nĂ« zero. NĂ« shembullin ne nuk zgjodhĂ«m zero, sepse ky Ă«shtĂ« njĂ« shĂ«rbim HTTP dhe jo njĂ« sistem me kĂ«rkesĂ«.

Magjia brenda automatizimit të shkallëzimit

Vlera prag përdoret si një aktivizues për rritjen e shpërndarjes. Në shembullin tonë, kërkesa PromQL sum(rate (http_requests [2m])) kthen një vlerë të agreguar të shkallës së HTTP kërkesave (numri i kërkesave për sekondë), e cila matet për dy minutat e fundit.

Duke qenë se vlera prag është tre, do të ketë një pod derisa vlera sum(rate (http_requests [2m])) të jetë më e vogël se tre. Nëse vlera rritet, një pod shtohet çdo herë që sum(rate (http_requests [2m])) rritet me tre. Për shembull, nëse vlera shkon nga 12 në 14, numri i podëve është katër.

Tani le të përpiqemi ta konfigurojmë!

Konfigurimi paraprak

E gjithë çfarë ju nevojitet është një klasër Kubernetes dhe një mjet i konfiguruar kubectl. Në këtë shembull përdoret klastri minikube, por mund të merrni ndonjë tjetër. Për instalimin e klasit ka manual.

Instaloni versionin më të fundit në 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/

Instaloni kubectl, për të pasur akses në klastrin Kubernetes.

Instaloni versionin më të fundit në 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

Instalimi i KEDA

Ju mund ta zbatoni KEDA në disa mënyra, ato janë të listuara në dokumentacionin. Unë përdor një YAML monolit:

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

KEDA dhe komponentët e saj instalohen në hapësirën e emrave keda. Komanda për të kontrolluar:

kubectl get pods -n keda

Prisni qĂ« podi KEDA Operator tĂ« startojĂ« — tĂ« kalojĂ« nĂ« Running State. Dhe pas kĂ«saj vazhdoni.

Instalimi i Redis me Helm

Nëse nuk e keni instaluar Helm, përdorni këtë udhëzues. Komanda për instalimin në Mac:

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

helm init inizializon ndërfaqen lokale të komandave, si dhe instalon Tiller në klasterin Kubernetes.

kubectl get pods -n kube-system | grep tiller

Prisni që podi Tiller të kalojë në gjendjen Running.

Shënim i përkthyesit: Autori përdor Helm@2, i cili kërkon instalimin e komponentit server Tiller. Aktualisht është Helm@3, për të cilin nuk nevojitet një pjesë serveri.

Pasi të keni instaluar Helm, për të nisur Redis mjafton një komandë:

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

Sigurohuni që Redis të ketë startuar me sukses:

kubectl get pods/redis-server-master-0

Prisni që podi Redis të kalojë në gjendjen Running.

Zbatimi i aplikacionit

Komanda për zbatimin:

kubectl apply -f go-app.yaml

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

Kontrolloni që gjithçka të ketë startuar:

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

Prisni që Redis të kalojë në gjendjen Running.

Zbatimi i serverit Prometheus

Manifesti Prometheus përdor Kubernetes Service Discovery për Prometheus. Ai lejon zbulimin dinamik të pods aplikacionit bazuar në etiketën e shërbimit.

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

PĂ«r zbatimin:

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

Kontrolloni që gjithçka të ketë startuar:

kubectl get pods -l=app=prometheus-server

Prisni derisa podi Prometheus të kalojë në gjendjen Running.

Përdorni kubectl port-forward për akses në ndërfaqen e përdoruesit të Prometheus (ose serverin API) në adresën http://localhost:9090.

kubectl port-forward service/prometheus-service 9090

Zbatimi i konfiguracionit të automatikëshkallës KEDA

Komanda për krijimin ScaledObject:

kubectl apply -f keda-prometheus-scaledobject.yaml

Kontrolloni logjet e operatorit KEDA:

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

Rezultati duket më shumë si:

koha="2019-10-15T09:38:28Z" niveli=info msg="Duke vëzhguar ScaledObject:
default/prometheus-scaledobject"
koha="2019-10-15T09:38:28Z" niveli=info msg="Krijuar HPA me 
namespace default dhe emrin keda-hpa-go-prom-app"

Kontrolloni nën aplikacione. Duhet të jetë i aktivizuar një instancë, pasi minReplicaCount baraz 1:

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

Kontrolloni që burimi HPA është krijuar me sukses:

kubectl get hpa

Duhet të shihni diçka si:

EMRI                   REFERENCË                OBJETIVET     MINPODS   MAXPODS   REPLICAT   MOSHA
keda-hpa-go-prom-app   Deployment/go-prom-app   0/3 (mesatar)   1         10        1          45s

Kontrollimi i funksionalitetit: qasja në aplikacion

Për të marrë qasje në pikën përfundimtare REST të aplikacionit tonë, ekzekutoni:

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

Tani mund të aksesoni aplikacionin Go duke përdorur adresën http://localhost:8080. Për këtë, ekzekutoni komandën:

curl http://localhost:8080/test

Rezultati duket më shumë si:

Aksesi u bë më 2019-10-21 11:29:10.560385986 +0000 UTC 
m=+406004.817901246
Numri i aksesit 1

Në këtë fazë gjithashtu kontrolloni Redis. Do të shihni që çelësi access_count është rritur në 1:

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

Sigurohuni që vlera e metrikës http_requests është e njëjtë:

curl http://localhost:8080/metrics | grep http_requests
//dalja
# HELP http_requests numri i kërkesave http
# TYPE http_requests counter
http_requests 1

Krijimi i ngarkesës

Ne do tĂ« pĂ«rdorim hey — njĂ« utilitare pĂ«r gjenerimin e ngarkesĂ«s:

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

Ju gjithashtu mund të shkarkoni utilitarin për Linux ose Windows.

Ekipioni atë:

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

Për default, utilitari dërgon 200 kërkesa. Mund ta verifikoni këtë, duke përdorur metrikat Prometheus dhe gjithashtu Redis.

curl http://localhost:8080/metrics | grep http_requests
//dalja
# HELP http_requests numri i kërkesave http
# TYPE http_requests counter
http_requests 201
kubectl exec -it redis-server-master-0 -- redis-cli get access_count
//dalja
201

Konfirmoni vlerën e metrikës reale (e rikthyer nga pyetja PromQL):

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

Në këtë rast, rezultati real është 1,686057971014493 dhe shfaqet në fushën vlera. Kjo nuk është e mjaftueshme për të shkallëzuar, pasi pragun që kemi vendosur është 3.

Më shumë ngarkesë!

Në një terminal të ri, monitoroni numrin e podëve të aplikacionit:

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

Le të rrisim ngarkesën me komandën:

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

Pas një kohe do të shihni që HPA po shkallëzon shpërndarjen dhe po nis podë të reja. Kontrolloni HPA për ta verifikuar këtë:

kubectl get hpa
EMRI                   REFERENCË                OBJETIVET         MINPODS   MAXPODS   REPLICAT   MOSHA
keda-hpa-go-prom-app   Deployment/go-prom-app   1830m/3 (mesatar)   1         10        6          4m22s

Nëse ngarkesa është e paqëndrueshme, shpërndarja do të zvogëlohet në pikën ku funksionon vetëm një pod. Nëse dëshironi të kontrolloni metrikat reale (të kthyera nga kërkesa PromQL), përdorni komandën:

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

Pastrimi

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

PĂ«rfundim

KEDA lejon që të automatizohet shkallëzimi i shpërndarjeve tuaja Kubernetes (nga/në zero) në bazë të të dhënave nga metrikat e jashtme. Për shembull, në bazë të metrikave Prometheus, gjatësi e radhës në Redis, vonesën e konsumatorit në temën Kafka.

KEDA realizon integrimin me burimin e jashtëm, si dhe ofron metrikat e tij nëpërmjet Metrics Server për Horizontal Pod Autoscaler.

Suksese!

ÇfarĂ« tjetĂ«r mund tĂ« lexoni:

  1. Praktikat më të mira dhe rekomandimet për nisjen e kontejnerëve dhe Kubernetes në mjedise prodhimi.
  2. 90+ mjete të dobishme për Kubernetes: shpërndarje, menaxhim, monitorim, siguri dhe më shumë.
  3. Kanalin tonë Rreth Kubernetes në Telegram.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster