Kubernetes Horizontal Pod AutoScaling
Metric Server & Pod Yatay Ölçeklendirme
Merhabalar,
Bu yazımda Pod’a bir yük geldiğinde otomatik olarak belli bir threshold’dan sonra bir tane pod replicasının nasıl çoğaltabilceğimizi inceliycez.
Horizontal (Yatay) Pod Autoscaler (HPA): Bu scaling opsiyonu Kubernetes cluster içerisindeki Metric Server bileşenini kullanır. Bu sayede pod’lar tarafından talep edilen resource talepleri belirlenir. Uygulamaların daha fazla kaynağa ihtiyaç duyduğu zamanlarda talebi karşılamak için belli sayıda pod service’in arkasına eklenir. Kısaca, varolan kaynak havuzunuza daha fazla pod’un replica sayısının artırılmasıdır.
Note: Kuberenetes cluster’ımızda CPU ve RAM belli bir threshold’tan sonra replica sayısınu artırmak için kubernetes cluster’ımızda metric server’ın yüklü olması gerekiyor.
Metric server kurulumu: Var olan kubernetes cluster’ımıza metric-server kurmak için çalıştırcağımız komut;
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
Sonrasında kubectl get pods -n kube-system ile pod’a baktığımızda gördüğünüz gibi running state geçemedi. Loglarına bakıp hataları fix’leyelim.
kubectl logs -f -n kube-system metric_pod_name ile loglara baktığımızda,
Failed to scrape node” err=”Get \”https://192.168.1.6:10250/metrics/resource\": x509: cannot validate certificate for
Bu hatayı düzeltmek için deployment dosyasına certificate insecure olarak bir command ekliyoruz.
.
.
.
command:
- /metrics-server
- — kubelet-insecure-tls
kubectl get pods -n kube-system ile tekrar baktığımızda,
Yukarıdaki görüldüğü gibi metric-server pod’umuz desired state ile replica sayısı kadar ayağa kalktı. Node’un CPU ve RAM kullanan değerlerini görmek için,
Note: Metric server kurmamısın amacı belli bir CPU veya RAM değerine pod’umuz geldiğin de yatay da bir tane daha pod kaldırması gerektiğinde threshold değerini metric-server’dan aldığı değerler doğrultusunda yapıyor.
Ilk olarak Horizontal Pod Autoscaler yaml’ını bir tanıyalım.
behavior:
scaleDown:
policies:
- type: Pods
value: 4
periodSeconds: 60
- type: Percent
value: 10
periodSeconds: 60
Spesifikasyonun davranış (behavior )bölümünde bir veya daha fazla ölçeklendirme ilkesi belirtilebilir. Yukarıdaki behavior davranısını biraz açıklamak gerekirse;
- Ilk policy açıklamak gerekir ise periodsecondas; 60 sn içinde 4 tane pod’un scale-down izin verirken. Ikinci kısımndaki tpye: Percent, yüzdesel olarak mevcut pod kopyasının en fazla %10'unun bir dakika içinde küçültülmesine izin verir.
behavior:
scaleDown:
stabilizationWindowSeconds: 300
stabilizationWindowSeconds; Ölçeklendirme için kullanılan metrikler sürekli dalgalanmaya devam ettiğinde, kopya sayısının artırmak veya azaltmak için metric-server’dan aldığı metricler ölçme süresidir. Önemli bir parametrik değerdir. Çünkü pod’a t anında çalışan yük ile çalışmayan yük arasında ki oran aynı değildir. t anında herhangi bir yük geldiğinde pod replicasını scale-down yada scale-up yaparkenki durumundaki ortalama ölçme süredir ve önemlidir.
Aşağıdaki yaml’da detaylı bir horizontal autoscaling pod örneği görülmektedir.
- scaleTargetRef: Autoscale kullanılacak pod ile ilgili ayarlar. Tabiki de burada pod’un önüne konumladırdığımız obje ne ise onu belirtiyoruz.
- name: Hpa yapacağımız pod’un ismi
- minReplicas: En az kaç pod çalışacağı burada tanımlıyoruz
- maxReplicas: En fazla kaç pod çalışacağı burada tanımlıyoruz.
- behavior: Kendi belirlediğimiz threshold ile podların durumuna göre scale up ya da scale down yapılıp yapılmayacağını ayarlıyoruz.
- scaleDown: Pod replica sayısının neye göre düşürüleceğini belirlemek için kullanılıyor.
- scaleUp: Pod replica sayısının neye göre arttırılacağını belirlemek için kullanılıyor.
- stabilizationWindowSeconds: Sistemin en az kaç saniye bu haliyle stabil kalacağını belirlemek için kullanılıyor. Sürekli scale up ve scale down işlemlerini engelliyoruz.
- policies: Scability politikaları belirleme.
- Percent type: Kaynağın ne kadar süreyle bu durumda kalırsa işlem yapılacağını belirliyor. Örnek vermek gerekirse, bizim yaml dosyamız için eğer 1 pod 50 saniye boyunca %50 cpudan fazla kaynak kullanırsa sistem scale up olur.
- selectPolicy: Hpa trigger etme durumunu belirliyoruz. Max ve Min girebiliriz.
Şimdide Horizontal Pod Autoscaler örneğimizi yapalım. Bunun için bir tane python ile yazılmış ekrana basit bir çıktı gösteren image’dan ilerliycez ve public’dir denemek isterseniz çekip test’lerinizi yapabilirsiniz. Ilk olarak bir tane hpa adında namespace oluşturalım.
kubectl create ns hpakubectl get ns
Deployment ve service objemize bakalım.
kubectl apply -f hpa-dep-svc.yamlkubectl get pods -n hpakubectl get svc -n hpa
Şuan kullanılan CPU ve RAM bakmak için,
kubectl top pods -n hpa
Şimdi yazımısın konusuna gelelim. İstersek imperative ya da declarative olarak horizontal autoscaling pods objesini oluşturabiliriz. Imperative olarak;
kubectl autoscale -n hpa deployment deployment_name --min=1 --max=5 --cpu-percent=50
Minimun 1 pods maksimum 5 pod olacak şekilde tabikide CPU’unun %50 kullanımı geçtiğinde oluşacak yeni bir pod replicası oluşturacaktır. Pod’un şuanki CPU ve RAM oranına bakmak için,
kubectl get -n hpa horizontalpodautoscalers.autoscaling
Yukarida görüldüğü gibi şuan CPU’nun %8 kullanıyor ve %50 geçtiğinde yeni bir pod ayağa kaldırcak.
Note: Buradaki %8 bizim deployment yaml verdiğimiz resource CPU’sunun %8 işaret etmektedir.
Şimdi servise durmadan istek atarak biraz CPU kullanımı artıralım. Bunun için;
while true; do curl http://192.168.1.6:32562 && sleep 0.05 && echo ""; done;
Anlık olarak CPU oranı bakalım. Bunun için,
kubectl get horizontalpodautoscalers.autoscaling -n hpa
Gördüğünüz gibi CPU kullanımı %50 üzerine geçtiği için birinci pod’un kendisi hemen bir tane replica ayağa kaldırdı.
Son olarak baktığımda maksimum pod sayımız 5 fakat gördüğünüz gibi 4 replica ayağa kaldırdı. Benim verdiğinm sleep saniyesi çok fazla CPU tükemediği için 10 dk bekleme rağmen 5 Pod’u ayağa kaldırmadı ama yine CPU %50'nin üzerine çıkarsa o pod’uda ayağa kaldıracaktır.
Not: Bu imperative’nin bir kötü yanı ise şuan CPU kullanımı artırmak için kullandığımız “while true; do curl http://192.168.1.6:32562 && sleep 0.05 && echo “”; done;” kapattığımızda scale-down yapmıştır.
Şimdide declarative olarak bir tane horizontal autoscaling pod yaml yazalım.
kubectl apply -f hpa1.yamlkubectl get horizontalpodautoscalers.autoscaling -n hpakubectl top pods -n hpa
İkinci horizontalautoscaling pods yaml’mıza bakalım. Burada ek olarak memory ekliyorum.
kubectl apply -f hpa2.yamlkubectl get horizontalpodautoscalers.autoscaling -n hpakubectl top pods -n hpa
Buradaki hpa2.yaml bakacak olursak burada CPU ve RAM kullanımı verdiğimiz threshold’ların üzerinde ise bir tane pod ayağa kaldırmaktadır.
Not: Bu iki yaml dosyasında da belli bir süredeki metric’leri almadan direk olarak ‘t’ anındaki değerleri göre pod replicası ayağa kaldırmasıdır.
Son hpa3.yaml’mızda bir ‘t’ anındaki metric aldığı CPU ve RAM değerine göre değilde belli bir süredeki metriclere göre scale-down ve scale-up durumuna bakalım.
kubectl apply -f hpa3.yamlkubectl get horizontalpodautoscalers.autoscaling -n hpakubectl top pods -n hpa
Yukarıdaki şekilde görüldüğü üzere RAM kullanımı pod başına %20 geçtiği için aynı poddan 1 tane replica daha ayağa kaldırmıştır. Maximum pod değeri 5 olarak verdiğimizi unutmayın.
Note: Scale-up ’ta stabilizationWindowSeconds değeri “0” olduğu için hemen bir pod replicasi ayağa kaldırdı, ama scale-down stabilizationWindowSeconds değeri 120 olduğu için 2 dakikalık metric değerlerine göre scale-down yapacaktır.
Diğer bir bilgilendir me ise gördüğünüz üzere apiVersion beta sürümünde daha tam stabil geçmemiştir.
Bu yazımızın da sonuna gelmiş bulunmaktayız. Araştırmalarım ve sektörde karşılaştığım senaryolar üzerine yazılarımı yazmaya devam edeceğim. Umarım faydalı bir yazı olmuştur. Yazımı okuduğunuz için teşekkürler.
Referanslar;