🥇ปรับขนาดแอปพลิเคชัน Kubernetes อัตโนมัติโดยใช้ Prometheus และ KEDA

มนุษย์บอลลูน โดย Cimuanos

ความสามารถในการปรับขนาดเป็นข้อกำหนดสำคัญสำหรับแอปพลิเคชันระบบคลาวด์ ด้วย Kubernetes การปรับขนาดแอปพลิเคชันทำได้ง่ายเพียงแค่เพิ่มจำนวนเรพลิกาสำหรับการปรับใช้ที่เหมาะสมหรือ ReplicaSet — แต่มันเป็นกระบวนการที่ต้องทำด้วยตนเอง

Kubernetes อนุญาตให้ปรับขนาดแอปพลิเคชันโดยอัตโนมัติ (เช่น พ็อดในการปรับใช้หรือ ReplicaSet) ในลักษณะที่ประกาศโดยใช้ข้อกำหนดเฉพาะของแนวนอน Pod Autoscaler เกณฑ์เริ่มต้นสำหรับการปรับขนาดอัตโนมัติคือตัววัดการใช้งาน CPU (ตัววัดทรัพยากร) แต่คุณสามารถรวมตัววัดแบบกำหนดเองและตัววัดที่จัดเตรียมไว้จากภายนอกได้

ทีม Kubernetes aaS จาก Mail.ru แปลบทความเกี่ยวกับวิธีใช้ตัวชี้วัดภายนอกเพื่อปรับขนาดแอปพลิเคชัน Kubernetes โดยอัตโนมัติ เพื่อแสดงให้เห็นว่าทุกอย่างทำงานอย่างไร ผู้เขียนใช้ตัววัดคำขอเข้าถึง HTTP ซึ่งรวบรวมโดยใช้ Prometheus

แทนที่จะใช้การปรับขนาดพ็อดอัตโนมัติในแนวนอน ระบบจะใช้ Kubernetes Event Driven Autoscaling (KEDA) ซึ่งเป็นโอเปอเรเตอร์ Kubernetes แบบโอเพ่นซอร์ส โดยผสานรวมเข้ากับแนวนอน Pod Autoscaler เพื่อให้การปรับขนาดอัตโนมัติได้อย่างราบรื่น (รวมถึง/จากศูนย์) สำหรับปริมาณงานที่ขับเคลื่อนด้วยเหตุการณ์ รหัสมีจำหน่ายที่ GitHub.

ภาพรวมโดยย่อของระบบ

แผนภาพแสดงคำอธิบายสั้นๆ ว่าทุกอย่างทำงานอย่างไร:

แอปพลิเคชันนี้มีการวัดจำนวนการเข้าชม HTTP ในรูปแบบ Prometheus
Prometheus ได้รับการกำหนดค่าให้รวบรวมตัววัดเหล่านี้
ตัวปรับขนาด Prometheus ใน KEDA ได้รับการกำหนดค่าให้ปรับขนาดแอปพลิเคชันโดยอัตโนมัติตามจำนวนการเข้าชม HTTP

ตอนนี้ฉันจะบอกคุณโดยละเอียดเกี่ยวกับแต่ละองค์ประกอบ

เคดาและโพรมีธีอุส

Prometheus เป็นชุดเครื่องมือตรวจสอบและแจ้งเตือนระบบโอเพ่นซอร์สส่วนหนึ่ง มูลนิธิ Cloud Native Computing. รวบรวมตัวชี้วัดจากแหล่งต่างๆ และจัดเก็บเป็นข้อมูลอนุกรมเวลา หากต้องการแสดงข้อมูลเป็นภาพคุณสามารถใช้ กราฟาน่า หรือเครื่องมือแสดงภาพอื่นๆ ที่ทำงานร่วมกับ Kubernetes API

KEDA สนับสนุนแนวคิดของตัวปรับขนาด โดยทำหน้าที่เป็นสะพานเชื่อมระหว่าง KEDA และระบบภายนอก การใช้งาน Scaler นั้นเฉพาะเจาะจงกับแต่ละระบบเป้าหมายและแยกข้อมูลจากระบบนั้น KEDA จะใช้สิ่งเหล่านี้เพื่อควบคุมการปรับขนาดอัตโนมัติ

Scaler รองรับแหล่งข้อมูลหลายแหล่ง เช่น Kafka, Redis, Prometheus กล่าวคือ KEDA สามารถใช้เพื่อปรับขนาดการใช้งาน Kubernetes ได้โดยอัตโนมัติโดยใช้ตัววัด Prometheus เป็นเกณฑ์

ทดสอบการใช้งาน

แอปพลิเคชันทดสอบ Golang ให้การเข้าถึงผ่าน HTTP และทำหน้าที่สำคัญสองประการ:

ใช้ไลบรารีไคลเอ็นต์ Prometheus Go เพื่อควบคุมแอปพลิเคชันและจัดเตรียมตัววัด http_requests ซึ่งมีจำนวน Hit ตำแหน่งข้อมูลที่มีตัววัด Prometheus อยู่ที่ URI /metrics.
```
var httpRequestsCounter = promauto.NewCounter(prometheus.CounterOpts{
       Name: "http_requests",
       Help: "number of http requests",
   })
```

เพื่อตอบสนองต่อการร้องขอ GET แอปพลิเคชันเพิ่มค่าของคีย์ (access_count) ในเรดิส นี่เป็นวิธีง่ายๆ ในการทำงานโดยเป็นส่วนหนึ่งของตัวจัดการ HTTP และยังตรวจสอบตัววัด Prometheus อีกด้วย ค่าเมตริกจะต้องเหมือนกับค่า 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ซึ่งช่วยให้เซิร์ฟเวอร์ Prometheus สามารถรับตัววัดแอปพลิเคชันได้

ที่นี่ รายการปรับใช้สำหรับแอปพลิเคชัน.

เซิร์ฟเวอร์โพรมีธีอุส

รายการปรับใช้ Prometheus ประกอบด้วย:

ConfigMap — เพื่อถ่ายโอนการกำหนดค่า Prometheus
Deployment — สำหรับการปรับใช้ Prometheus ในคลัสเตอร์ Kubernetes
ClusterIP — บริการสำหรับการเข้าถึง UI Prometheus
ClusterRole, ClusterRoleBinding и ServiceAccount — สำหรับการตรวจจับบริการอัตโนมัติใน Kubernetes (การค้นหาอัตโนมัติ)

ที่นี่ รายการสำหรับการเรียกใช้ Prometheus.

KEDA โพรมีธีอุส สเกลอ็อบเจ็กต์

Scaler ทำหน้าที่เป็นสะพานเชื่อมระหว่าง KEDA และระบบภายนอกซึ่งจำเป็นต้องรับตัววัด ScaledObject เป็นทรัพยากรแบบกำหนดเองที่จำเป็นต้องปรับใช้เพื่อซิงโครไนซ์การปรับใช้งานกับแหล่งที่มาของเหตุการณ์ ในกรณีนี้คือ Prometheus

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

โปรดทราบประเด็นต่อไปนี้:

เขาชี้ไปที่ Deployment ด้วยชื่อ go-prom-app.
ประเภททริกเกอร์ - Prometheus. ที่อยู่เซิร์ฟเวอร์ Prometheus ได้รับการกล่าวถึงพร้อมกับชื่อตัวชี้วัด เกณฑ์ และ แบบสอบถาม PromQLซึ่งจะถูกนำมาใช้ แบบสอบถาม PromQL - sum(rate(http_requests[2m])).
ตามที่ pollingIntervalKEDA ร้องขอเป้าหมายจากโพรทุก ๆ สิบห้าวินาที อย่างน้อยหนึ่งรายการภายใต้ (minReplicaCount) และจำนวนพ็อดสูงสุดต้องไม่เกิน maxReplicaCount (ในตัวอย่างนี้ - สิบ)

ติดตั้งได้ minReplicaCount เท่ากับศูนย์ ในกรณีนี้ KEDA จะเปิดใช้งานการปรับใช้แบบศูนย์ต่อหนึ่ง จากนั้นจึงเปิดเผย HPA เพื่อการปรับขนาดอัตโนมัติเพิ่มเติม ลำดับย้อนกลับก็เป็นไปได้เช่นกัน นั่นคือ ปรับขนาดจากหนึ่งถึงศูนย์ ในตัวอย่าง เราไม่ได้เลือกศูนย์เนื่องจากนี่คือบริการ HTTP และไม่ใช่ระบบตามความต้องการ

ความมหัศจรรย์ภายในการปรับขนาดอัตโนมัติ

เกณฑ์นี้ใช้เป็นทริกเกอร์ในการปรับขนาดการปรับใช้ ในตัวอย่างของเรา แบบสอบถาม PromQL sum(rate (http_requests [2m])) ส่งคืนอัตราการร้องขอ HTTP แบบรวม (คำขอต่อวินาที) ซึ่งวัดในช่วงสองนาทีที่ผ่านมา

เนื่องจากค่าเกณฑ์คือ XNUMX หมายความว่าจะมีค่าอยู่ใต้ค่าหนึ่ง sum(rate (http_requests [2m])) น้อยกว่าสาม หากค่าเพิ่มขึ้น จะมีการเพิ่มส่วนย่อยเพิ่มเติมในแต่ละครั้ง sum(rate (http_requests [2m])) เพิ่มขึ้นสาม เช่น หากค่าอยู่ระหว่าง 12 ถึง 14 จำนวนพ็อดจะเป็น XNUMX

ทีนี้มาลองตั้งค่ากัน!

การตั้งค่าล่วงหน้า

สิ่งที่คุณต้องมีคือคลัสเตอร์ 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/

ติดตั้ง Kubectlเพื่อเข้าถึงคลัสเตอร์ Kubernetes

ติดตั้งเวอร์ชันล่าสุดบน 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 ได้หลายวิธี ซึ่งระบุไว้ในนั้น เอกสาร. ฉันใช้ YAML แบบเสาหิน:

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

KEDA และส่วนประกอบได้รับการติดตั้งในเนมสเปซ keda. คำสั่งให้ตรวจสอบ:

kubectl get pods -n keda

รอให้ KEDA Operator เริ่มต้นและไปที่ Running State. และหลังจากนั้นก็ทำต่อ

การติดตั้ง Redis โดยใช้ Helm

หากคุณไม่ได้ติดตั้ง Helm ให้ใช้สิ่งนี้ ความเป็นผู้นำ. คำสั่งให้ติดตั้งบน Mac:

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

helm init เริ่มต้นอินเทอร์เฟซบรรทัดคำสั่งภายในเครื่องและติดตั้งด้วย Tiller ไปยังคลัสเตอร์ Kubernetes

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

รอให้ Redis เข้าสู่สถานะ Running.

การปรับใช้เซิร์ฟเวอร์ Prometheus

รายการ Prometheus ใช้ การค้นพบบริการ Kubernetes สำหรับ Prometheus. ช่วยให้สามารถค้นพบพ็อดแอปพลิเคชันแบบไดนามิกตามป้ายกำกับบริการ

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 เพื่อเข้าถึงอินเทอร์เฟซผู้ใช้ Prometheus (หรือเซิร์ฟเวอร์ API) ได้ที่ http://localhost:9090.

kubectl port-forward service/prometheus-service 9090

การปรับใช้การกำหนดค่าการปรับขนาดอัตโนมัติ KEDA

คำสั่งในการสร้าง 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

การสร้างโหลด

เราจะใช้ เฮ้ — ยูทิลิตี้สำหรับสร้างโหลด:

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

คุณยังสามารถดาวน์โหลดยูทิลิตี้นี้ได้ ลินุกซ์ หรือ Windows.

เรียกใช้:

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

ตามค่าเริ่มต้น ยูทิลิตีจะส่งคำขอ 200 รายการ คุณสามารถตรวจสอบสิ่งนี้ได้โดยใช้ตัววัด Prometheus และ 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 ของคุณโดยอัตโนมัติ (เป็น/จากศูนย์) ตามข้อมูลจากตัววัดภายนอก ตัวอย่างเช่น อิงตามตัววัด Prometheus ความยาวคิวใน Redis เวลาแฝงของผู้บริโภคในหัวข้อ Kafka

KEDA ทำงานร่วมกับแหล่งที่มาภายนอกและยังจัดเตรียมตัววัดผ่านเซิร์ฟเวอร์ตัววัดไปยังตัวปรับขนาดอัตโนมัติพ็อดแนวนอนอีกด้วย

โชคดี!

มีอะไรให้อ่านอีก:

ที่มา: will.com

การปรับขนาดแอปพลิเคชัน Kubernetes อัตโนมัติโดยใช้ Prometheus และ KEDA