Kubernetes-ის აპლიკაციების ავტომატური მასშტაბირება Prometheus-ისა და KEDA-ს გამოყენებით

Balloon Man Cimuanos-ის მიერ

მასშტაბურობა არის მთავარი მოთხოვნა ღრუბლოვანი აპლიკაციებისთვის. Kubernetes-ით აპლიკაციის მასშტაბირება ისეთივე მარტივია, როგორც რეპლიკების რაოდენობის გაზრდა შესაბამისი განლაგებისთვის ან ReplicaSet — მაგრამ ეს ხელით პროცესია.

Kubernetes საშუალებას აძლევს აპლიკაციების ავტომატურად მასშტაბირებას (ანუ Pods განლაგების დროს ან ReplicaSet) დეკლარაციულად Horizontal Pod Autoscaler სპეციფიკაციის გამოყენებით. ავტომატური სკალირების ნაგულისხმევი კრიტერიუმია CPU-ის გამოყენების მეტრიკა (რესურსების მეტრიკა), მაგრამ თქვენ შეგიძლიათ დააკავშიროთ მორგებული და გარედან მოწოდებული მეტრიკა.

გუნდი Kubernetes aaS Mail.ru-დან თარგმნა სტატია იმის შესახებ, თუ როგორ გამოვიყენოთ გარე მეტრიკა Kubernetes აპლიკაციის ავტომატურად მასშტაბირებისთვის. იმის საჩვენებლად, თუ როგორ მუშაობს ყველაფერი, ავტორი იყენებს HTTP წვდომის მოთხოვნის მეტრიკას, რომელიც გროვდება პრომეთეს გამოყენებით.

პოდების ჰორიზონტალური ავტოსკალირების ნაცვლად გამოიყენება Kubernetes Event Driven Autoscaling (KEDA), ღია კოდის Kubernetes ოპერატორი. ის ბუნებრივად ინტეგრირდება Horizontal Pod Autoscaler-თან, რათა უზრუნველყოს უწყვეტი ავტომატური სკალირება (მათ შორის ნულამდე) მოვლენებზე ორიენტირებული სამუშაო დატვირთვისთვის. კოდი ხელმისაწვდომია GitHub.

სისტემის მოკლე მიმოხილვა

დიაგრამა გვიჩვენებს მოკლე აღწერას, თუ როგორ მუშაობს ყველაფერი:

1. აპლიკაცია უზრუნველყოფს HTTP ჰიტების რაოდენობის მეტრიკას პრომეთეს ფორმატში.
2. პრომეთე კონფიგურირებულია ამ მეტრიკის შესაგროვებლად.
3. პრომეთეს სკალერი KEDA-ში კონფიგურირებულია აპლიკაციის ავტომატურად მასშტაბირებაზე HTTP ჰიტების რაოდენობის მიხედვით.

ახლა მე დეტალურად გეტყვით თითოეული ელემენტის შესახებ.

KEDA და პრომეთე

პრომეთე არის ღია კოდის სისტემის მონიტორინგისა და გაფრთხილების ინსტრუმენტარიუმის ნაწილი Cloud Native Computing Foundation. აგროვებს მეტრიკას სხვადასხვა წყაროდან და ინახავს მათ დროის სერიების მონაცემებად. მონაცემების ვიზუალიზაციისთვის შეგიძლიათ გამოიყენოთ გრაფანა ან სხვა ვიზუალიზაციის ხელსაწყოები, რომლებიც მუშაობენ Kubernetes API-სთან.

KEDA მხარს უჭერს სკალერის კონცეფციას - ის მოქმედებს როგორც ხიდი KEDA-სა და გარე სისტემას შორის. სკალერის დანერგვა სპეციფიკურია თითოეული სამიზნე სისტემისთვის და ამოიღებს მონაცემებს მისგან. შემდეგ KEDA იყენებს მათ ავტომატური სკალირების გასაკონტროლებლად.

სკალერები მხარს უჭერენ მონაცემთა მრავალ წყაროს, მაგალითად, კაფკა, რედისი, პრომეთე. ანუ, KEDA შეიძლება გამოყენებულ იქნას Kubernetes-ის განლაგების ავტომატურად სკალირების მიზნით პრომეთეს მეტრიკის კრიტერიუმების გამოყენებით.

სატესტო აპლიკაცია

Golang ტესტის აპლიკაცია უზრუნველყოფს წვდომას HTTP-ით და ასრულებს ორ მნიშვნელოვან ფუნქციას:

1. იყენებს Prometheus Go კლიენტის ბიბლიოთეკას, რათა დააინსტალიროთ აპლიკაცია და უზრუნველყოს http_requests მეტრიკა, რომელიც შეიცავს დარტყმების რაოდენობას. საბოლოო წერტილი, სადაც ხელმისაწვდომია პრომეთეს მეტრიკა, მდებარეობს URI-ზე /metrics.

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

2. მოთხოვნის საპასუხოდ GET აპლიკაცია ზრდის გასაღების მნიშვნელობას (access_count) რედისში. ეს არის მარტივი გზა სამუშაოს შესასრულებლად, როგორც HTTP დამმუშავებლის ნაწილი და ასევე შეამოწმეთ პრომეთეს მეტრიკა. მეტრიკული მნიშვნელობა უნდა იყოს იგივე, რაც მნიშვნელობა 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, ის პრომეთეს სერვერს საშუალებას აძლევს მიიღოს განაცხადის მეტრიკა.

აქ განლაგების მანიფესტი განაცხადისთვის.

პრომეთეს სერვერი

პრომეთეს განლაგების მანიფესტი შედგება:

• ConfigMap - პრომეთეს კონფიგურაციის გადატანა;
• Deployment - პრომეთეს კუბერნეტის კლასტერში განლაგებისთვის;
• ClusterIP — UI Prometheus-ზე წვდომის სერვისი;
• ClusterRole, ClusterRoleBinding и ServiceAccount — Kubernetes-ში სერვისების ავტომატური გამოვლენისთვის (ავტომატური აღმოჩენა).

აქ მანიფესტი პრომეთეს გასაშვებად.

KEDA Prometheus ScaledObject

სკალერი მოქმედებს როგორც ხიდი KEDA-სა და გარე სისტემას შორის, საიდანაც საჭიროა მეტრიკის მიღება. ScaledObject არის მორგებული რესურსი, რომელიც უნდა განთავსდეს განლაგების სინქრონიზაციისთვის მოვლენის წყაროსთან, ამ შემთხვევაში პრომეთესთან.

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. პრომეთეს სერვერის მისამართი მითითებულია მეტრულ სახელთან, ბარიერთან და PromQL შეკითხვა, რომელიც გამოყენებული იქნება. PromQL შეკითხვა - sum(rate(http_requests[2m])).
3. მიხედვით pollingIntervalKEDA ითხოვს სამიზნეს პრომეთეს ყოველ თხუთმეტ წამში. მინიმუმ ერთი ქვეშ (minReplicaCount), ხოლო წიპწების მაქსიმალური რაოდენობა არ აღემატება maxReplicaCount (ამ მაგალითში - ათი).

შეიძლება დამონტაჟდეს minReplicaCount ნულის ტოლი. ამ შემთხვევაში, KEDA ააქტიურებს ნულიდან ერთ განლაგებას და შემდეგ ავლენს HPA-ს შემდგომი ავტომატური მასშტაბისთვის. საპირისპირო თანმიმდევრობაც შესაძლებელია, ანუ სკალირება ერთიდან ნულამდე. მაგალითში, ჩვენ არ ავირჩიეთ ნული, რადგან ეს არის HTTP სერვისი და არა მოთხოვნის სისტემა.

მაგია ავტოსკალირების შიგნით

ბარიერი გამოიყენება როგორც ტრიგერით განლაგების მასშტაბის. ჩვენს მაგალითში, PromQL შეკითხვა sum(rate (http_requests [2m])) აბრუნებს გაერთიანებულ HTTP მოთხოვნის სიჩქარეს (მოთხოვნები წამში), რომელიც იზომება ბოლო ორი წუთის განმავლობაში.

ვინაიდან ბარიერის მნიშვნელობა არის სამი, ეს ნიშნავს, რომ იქნება ერთი ქვემოთ, ხოლო მნიშვნელობა sum(rate (http_requests [2m])) სამზე ნაკლები. თუ მნიშვნელობა იზრდება, ყოველ ჯერზე ემატება დამატებითი ქვე sum(rate (http_requests [2m])) იზრდება სამით. მაგალითად, თუ მნიშვნელობა არის 12-დან 14-მდე, მაშინ წიპწების რაოდენობა არის ოთხი.

ახლა ვცადოთ მისი დაყენება!

წინასწარ დაყენება

ყველაფერი რაც თქვენ გჭირდებათ არის 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/

უცნობია კუბექტლიკუბერნეტის კლასტერზე წვდომისთვის.

დააინსტალირეთ უახლესი ვერსია 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 ოპერატორის დაწყებას და გადადით Running State. და ამის შემდეგ გააგრძელეთ.

Redis-ის დაყენება Helm-ის გამოყენებით

თუ Helm არ გაქვთ დაყენებული, გამოიყენეთ ეს ხელმძღვანელობით. Mac-ზე ინსტალაციის ბრძანება:

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

helm init ახდენს ადგილობრივი ბრძანების ხაზის ინტერფეისის ინიციალიზებას და ასევე ინსტალაციას Tiller კუბერნეტის კლასტერამდე.

kubectl get pods -n kube-system | grep tiller

დაელოდეთ, სანამ Tiller pod შევიდეს გაშვებულ მდგომარეობაში.

მთარგმნელის შენიშვნა: ავტორი იყენებს Helm@2, რომელიც მოითხოვს Tiller სერვერის კომპონენტის დაინსტალირებას. ახლა 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

დაელოდეთ რედისის მდგომარეობას 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

დაელოდეთ რედისის მდგომარეობას შესვლას Running.

პრომეთეს სერვერის დაყენება

პრომეთეს მანიფესტი იყენებს კუბერნეტის სერვისის აღმოჩენა პრომეთესთვის. ეს საშუალებას აძლევს აპლიკაციის პოდების დინამიურ აღმოჩენას სერვისის ეტიკეტზე დაყრდნობით.

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 პრომეთეს მომხმარებლის ინტერფეისზე (ან API სერვერზე) წვდომისთვის http://localhost:9090.

kubectl port-forward service/prometheus-service 9090

KEDA Autoscaling-ის კონფიგურაციის დანერგვა

შექმნის ბრძანება 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

ჩატვირთვა შექმნა

ჩვენ გამოვიყენებთ hey - დატვირთვის გენერირების პროგრამა:

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

ასევე შეგიძლიათ ჩამოტვირთოთ პროგრამა Linux ან Windows.

გაუშვით:

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

ნაგულისხმევად, პროგრამა აგზავნის 200 მოთხოვნას. ამის გადამოწმება შეგიძლიათ პრომეთეს მეტრიკის, ასევე 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.

მეტი დატვირთვა!

ახალ ტერმინალში აკონტროლეთ აპლიკაციების პოდების რაოდენობა:

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

თუ დატვირთვა არათანმიმდევრულია, განლაგება შემცირდება იმ წერტილამდე, სადაც მხოლოდ ერთი პოდი მუშაობს. თუ გსურთ შეამოწმოთ რეალური მეტრიკა (დაბრუნებული 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-ის განლაგება (ნულამდე) გარე მეტრიკის მონაცემებზე დაყრდნობით. მაგალითად, პრომეთეს მეტრიკაზე დაყრდნობით, რიგის სიგრძე რედისში, მომხმარებელთა შეყოვნება კაფკას თემაში.

KEDA ინტეგრირდება გარე წყაროსთან და ასევე აწვდის მის მეტრიკას Metrics სერვერის მეშვეობით Horizontal Pod Autoscaler-ზე.

გისურვებთ წარმატებებს!

კიდევ რა წაიკითხოთ:

1. საუკეთესო პრაქტიკა და საუკეთესო პრაქტიკა კონტეინერებისა და Kubernetes-ის საწარმოო გარემოში გაშვებისთვის.
2. 90+ სასარგებლო ინსტრუმენტი Kubernetes-ისთვის: განლაგება, მართვა, მონიტორინგი, უსაფრთხოება და სხვა.
3. ჩვენი არხი Kubernetes-ის გარშემო Telegram-ში.

წყარო: www.habr.com