Škálovatelnost je klíčovým požadavkem pro cloudové aplikace. S Kubernetes je škálování aplikace stejně jednoduché, jako zvýšení počtu replik pro odpovídající nasazení nebo ReplicaSet — ale je to ruční proces.
Kubernetes umožňuje automaticky škálovat aplikace (to znamená Pod v nasazení nebo ReplicaSet) deklarativním způsobem s použitím specifikace Horizontal Pod Autoscaler. Výchozí kritérium pro automatické škálování jsou metriky využití CPU (metriky zdrojů), ale lze integrovat vlastní metriky a metriky poskytované zvenčí.
Tým přeložila článek o tom, jak používat externí metriky pro automatické škálování aplikace Kubernetes. Aby ukázal, jak to funguje, autor používá metriky HTTP přístupových požadavků, které jsou shromažďovány pomocí Prometheus.
Místo horizontálního automatického škálování podů se používá Kubernetes Event Driven Autoscaling (KEDA) — open-source operátor Kubernetes. Ten se původně integruje s Horizontal Pod Autoscaler, aby zajistil plynulé automatické škálování (včetně do / z nuly) pro pracovních zátěže řízené událostmi. Kód je dostupný na .
Krátký přehled fungování systému
Na schématu je stručný popis toho, jak vše funguje:
- Aplikace poskytuje metriky počtu přístupů k HTTP ve formátu Prometheus.
- Prometheus je nastaven na shromažďování těchto ukazatelů.
- Skladač Prometheus v KEDA je nastaven na automatické škálování aplikace na základě počtu přístupů k HTTP.
Nyní podrobně popíšu každý prvek.
KEDA a Prometheus
Prometheus je open-source nástroj pro monitorování a upozorňování systémů, části . Shromažďuje metriky z různých zdrojů a ukládá je ve formě časových řad. Pro vizualizaci dat lze použít nebo jiné vizualizační nástroje pracující s API Kubernetes.
KEDA podporuje koncept skaleru — působí jako most mezi KEDA a externím systémem. Implementace skaleru je specifická pro každý cílový systém a extrahuje z něj data. Poté KEDA tato data používá k řízení automatického škálování.
Scaleři podporují několik zdrojů dat, například Kafka, Redis, Prometheus. To znamená, že KEDA lze použít pro automatické škálování nasazení Kubernetes, přičemž metriky Prometheus slouží jako kritéria.
Testovací aplikace
Testovací aplikace v Golangu poskytuje přístup přes HTTP a vykonává dvě důležité funkce:
- Používá klientskou knihovnu Prometheus Go pro instrumentaci aplikace a poskytování metriky http_requests, která obsahuje čítač dotazů. Konečný bod, kde jsou metriky Prometheus dostupné, se nachází na URI
/metrics.var httpRequestsCounter = promauto.NewCounter(prometheus.CounterOpts{ Name: "http_requests", Help: "počet http dotazů", }) - Na žádost
GETaplikace zvyšuje hodnotu klíče (access_count) v Redis. To je jednoduchý způsob, jak vykonat práci jako součást HTTP zpracovatele a také ověřit metriky Prometheus. Hodnota metriky by měla být stejná jako hodnotaaccess_countv 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("Nelze zvýšit Redis čítač", err) os.Exit(1) } resp := "Přístup na " + time.Now().String() + "nPočet přístupů " + strconv.Itoa(int(count)) w.Write([]byte(resp)) }) http.ListenAndServe(":8080", nil) }
Aplikace je nasazena v Kubernetes přes Nasazení. Také je vytvořena služba ClusterIP, která umožňuje serveru Prometheus získávat metriky aplikace.
Tady .
Server Prometheus
Manifest nasazení Prometheus se skládá z:
ConfigMap— pro předání konfigurace Prometheus;Nasazení— pro nasazení Prometheus v Kubernetes clusteru;ClusterIP— služba pro přístup k UI Prometheus;ClusterRole,ClusterRoleBindingaServiceAccount— pro práci s automatickým objevováním služeb v Kubernetes (Auto-discovery).
Tady .
KEDA Prometheus ScaledObject
Scaleř působí jako most mezi KEDA a externím systémem, ze kterého je třeba získat metriky. ScaledObject — konfigurovatelný zdroj, který je třeba nasadit pro synchronizaci nasazení se zdrojem událostí, v tomto případě s Prometheus.
ScaledObject obsahuje informace o škálování nasazení, metadata o zdroji události (například tajemství pro připojení, název fronty), interval dotazování, dobu zotavení a další údaje. Vede k odpovídajícímu zdroji automatického škálování (definice HPA) pro škálování nasazení.
Když objekt ScaledObject odstranění odpovídajícího určení HPA se vymaže.
Tady je definice ScaledObject pro náš příklad, kde se používá škálovač 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]))
Mějte na paměti následující body:
- Ukazuje na
Nasazenís názvemgo-prom-app. - Typ spouštěče —
Prometheus. Adresa serveru Prometheus je uvedena spolu s názvem metriky, prahovou hodnotou a , který bude použit. Dotaz PromQL —sum(rate(http_requests[2m])). - Podle
pollingInterval, KEDA dotazuje cílový stav u Prometheus každých patnáct sekund. Podporován je minimálně jeden pod (minReplicaCount), zatímco maximální počet podů nesmí přesáhnoutmaxReplicaCountv tomto příkladu — deset.
Může být nastaveno minReplicaCount na nulu. V takovém případě KEDA aktivuje nasazení z nuly na jeden a pak poskytne HPA pro další automatické škálování. Může být také zmenšeno, tedy škálováno z jednoho na nulu. V případě, že jsme nezvolili nulu, protože se jedná o HTTP službu, nikoli systém na žádost.
Kouzelné uvnitř automatického škálování
Prahová hodnota se používá jako spouštěč pro škálování nasazení. V našem příkladu dotaz PromQL sum(rate (http_requests [2m])) vrací agregovanou hodnotu rychlosti HTTP požadavků (počet požadavků za sekundu), měřenou za poslední dvě minuty.
Jelikož je prahová hodnota tři, bude existovat jeden pod, dokud je hodnota sum(rate (http_requests [2m])) méně než tři. Pokud hodnota vzroste, přidá se další pod vždy, když sum(rate (http_requests [2m])) vzroste o tři. Například, pokud se hodnota pohybuje od 12 do 14, pak bude počet podů čtyři.
Teď si to pojďme zkusit nastavit!
Předběžné nastavení
Všechno, co potřebujete, je cluster Kubernetes a nakonfigurovaný nástroj kubectl. V tomto příkladu se používá cluster minikube, ale můžete použít jakýkoli jiný. Pro nastavení clustru si můžete prohlédnout .
Nainstalujte poslední verzi 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/
Nainstalujte , abyste získali přístup k clustru Kubernetes.
Nainstalujte poslední verzi 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
Instalace KEDA
KEDA můžete nasadit několika způsoby, které jsou uvedeny v . Používám monolitní YAML:
kubectl apply -f
https://raw.githubusercontent.com/kedacore/keda/master/deploy/KedaScaleController.yaml
KEDA a její komponenty se instalují do jmenného prostoru keda. Příkaz pro kontrolu:
kubectl get pods -n keda
Počkejte, až se pod KEDA Operator spustí — přejde do Běžného stavu. A poté pokračujte.
Instalace Redis pomocí Helm
Pokud nemáte nainstalovaný Helm, využijte toto . Příkaz pro instalaci na Mac:
brew install kubernetes-helm
helm init --history-max 200
helm init inicializuje místní rozhraní příkazového řádku a také instaluje Tiller do klastru Kubernetes.
kubectl get pods -n kube-system | grep tiller
Počkejte, až převede pod Tiller do stavu Běžný.
Poznámka překladatele: Autor používá Helm@2, který vyžaduje instalaci serverové komponenty Tiller. Nyní je aktuální Helm@3, pro něj serverová část není potřeba.
Po instalaci Helmu pro spuštění Redis stačí jeden příkaz:
helm install --name redis-server --set cluster.enabled=false --set
usePassword=false stable/redis
Ujistěte se, že Redis byl úspěšně spuštěn:
kubectl get pods/redis-server-master-0
Počkejte, až pod Redis přejde do stavu Dokončeno.
Nasazení aplikace
Příkaz pro nasazení:
kubectl apply -f go-app.yaml
//output
deployment.apps/go-prom-app created
service/go-prom-app-service created
Zkontrolujte, že vše bylo spuštěno:
kubectl get pods -l=app=go-prom-app
Počkejte, až Redis přejde do stavu Dokončeno.
Nasazení serveru Prometheus
Manifest Prometheus používá . Umožňuje dynamicky objevovat pod aplikace na základě štítku služby.
kubernetes_sd_configs:
- role: service
relabel_configs:
- source_labels: [__meta_kubernetes_service_label_run]
regex: go-prom-app-service
action: keep
Pro nasazení:
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
Zkontrolujte, že vše bylo spuštěno:
kubectl get pods -l=app=prometheus-server
Počkejte, až pod Prometheus přejde do stavu Dokončeno.
Použijte kubectl port-forward pro přístup k uživatelskému rozhraní Prometheus (nebo serveru API) na adrese .
kubectl port-forward service/prometheus-service 9090
Nasazení konfigurace automatického škálování KEDA
Příkaz pro vytvoření ScaledObject:
kubectl apply -f keda-prometheus-scaledobject.yaml
Zkontrolujte logy operátora KEDA:
KEDA_POD_NAME=$(kubectl get pods -n keda
-o=jsonpath='{.items[0].metadata.name}')
kubectl logs $KEDA_POD_NAME -n keda
Výsledek vypadá přibližně takto:
time="2019-10-15T09:38:28Z" level=info msg="Sleduji ScaledObject:
default/prometheus-scaledobject"
time="2019-10-15T09:38:28Z" level=info msg="Vytvořil HPA s
namespace default a jménem keda-hpa-go-prom-app"
Zkontrolujte pod aplikace. Měla by běžet jedna instance, protože minReplicaCount je rovno 1:
kubectl get pods -l=app=go-prom-app
Zkontrolujte, že prostředek HPA byl úspěšně vytvořen:
kubectl get hpa
Měli byste vidět něco jako:
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
keda-hpa-go-prom-app Deployment/go-prom-app 0/3 (avg) 1 10 1 45s
Kontrola dostupnosti: přístup k aplikaci
Pro přístup k REST endpointu naší aplikace spusťte:
kubectl port-forward service/go-prom-app-service 8080
Nyní můžete přistupovat k aplikaci Go pomocí adresy . K tomu proveďte následující příkaz:
curl http://localhost:8080/test
Výsledek vypadá přibližně takto:
Přístupno dne 2019-10-21 11:29:10.560385986 +0000 UTC
m=+406004.817901246
Počet přístupů 1
V této fázi také zkontrolujte Redis. Uvidíte, že klíč access_count se zvýšil na 1:
kubectl exec -it redis-server-master-0 -- redis-cli get access_count
//output
"1"
Ujistěte se, že hodnota metriky http_requests je stejné:
curl http://localhost:8080/metrics | grep http_requests
//output
# HELP http_requests počet http požadavků
# TYPE http_requests counter
http_requests 1
Generování zátěže
Budeme používat — nástroj pro generování zátěže:
curl -o hey https://storage.googleapis.com/hey-release/hey_darwin_amd64
&& chmod a+x hey
Můžete si také stáhnout nástroj pro nebo .
Spusťte jej:
./hey http://localhost:8080/test
Nástroj ve výchozím nastavení odesílá 200 požadavků. To lze ověřit pomocí metrik Prometheus i Redis.
curl http://localhost:8080/metrics | grep http_requests
//output
# HELP http_requests počet http požadavků
# TYPE http_requests counter
http_requests 201
kubectl exec -it redis-server-master-0 -- redis-cli get access_count
//output
201
Potvrďte hodnotu skutečné metriky (vrácené dotazem 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 tomto případě je skutečný výsledek roven 1,686057971014493 a zobrazuje se v poli value. To není dost pro škálování, protože stanovený práh je rovný 3.
Více zátěže!
V novém terminálu sledujte počet podů aplikace:
kubectl get pods -l=app=go-prom-app -w
Zvyšte zátěž pomocí příkazu:
./hey -n 2000 http://localhost:8080/test
Za chvíli uvidíte, že HPA škáluje nasazení a spouští nové pody. Zkontrolujte HPA, abyste se o tom ujistili:
kubectl get hpa
NÁZEV ODKAZ CÍLE MINPODS MAXPODS REPLIKY VĚK
keda-hpa-go-prom-app Nasazení/go-prom-app 1830m/3 (prům.) 1 10 6 4m22s
Pokud je zatížení nepravidelné, nasazení se sníží na bod, kdy běží pouze jeden pod. Pokud chcete zkontrolovat skutečnou metriku (vrácenou dotazem PromQL), použijte příkaz:
curl -g
'http://localhost:9090/api/v1/query?query=sum(rate(http_requests[2m]))'
Vymazat
//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
Závěr
KEDA umožňuje automaticky škálovat vaše nasazení Kubernetes (do/od nuly) na základě údajů z externích metrik. Například na základě metrik Prometheus, délky fronty v Redis, zpoždění spotřebitele ve vlákně Kafka.
KEDA provádí integraci s externím zdrojem a také poskytuje jeho metriky prostřednictvím Metrics Server pro Horizontal Pod Autoscaler.
Hodně štěstí!
Co dalšího si přečíst:
- .
- .
- .
Zdroj: habr.com
