Azure Kubernetes Service (AKS) — Scaling Opsiyonları

Firat Yasar
Devops Türkiye☁️ 🐧 🐳 ☸️
5 min readFeb 26, 2020

Scaling yüksek trafik alan uygulamalar için günümüzde düşünülmesi gereken en önemli konfigürasyon seçeneklerinden birisi haline gelmiştir. Artık yeni nesil, container’lar içerisinde çalışan modern uygulamalar da yüksek erişilebilir şekilde tasarlanmaktadır. Yoğun trafik altında uygulamanın sorunsuz çalışması için bu tarz mekanizmalar architect’ler için düşünülmesi gereken en önemli bileşenler haline gelmiştir.

Scaling mekanizmaları cluster mimarileri içerisinde hem fiziksel seviyede hemde uygulama bileşenleri seviyesinde uygulanabilir. Bu makalemde Azure Kubernetes Service (AKS) mimarisindeki tüm scaling mekanizmalarını ele almaya çalışacağım.

Temel olarak AKS mimarisinde iki adet scaling opsiyonu bulunur.

  • Cluster Auto Scaler: Resorurce sıkıntısından ötürü schedule olamayan podlar izlenir. Böyle bir durum saptandığında cluster otomatik olarak belli sayıda node’a genişler.
  • Horizontal Pod Autoscaler: 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 arkasına eklenir.

Yukarıda bahsedilen her iki mimari içinde node ve pod sayıları hem otomatik olarak yükseltilir hem de düşürülür. Örneğin cluster autoscaler belli periodda node üzerindeki kullanılmayan kapasiteyi hesaplar ve gereksiz olan node’ları kapatır. Bu node’lar üzerindeki pod’larda otomatik olarak silinip diğer ayakta olan node’lar üzerinde schedule edilirler.

Bazı durumlarda cluster autoscaler işlevini tamamlayamayabilir. Örneğin pod bir deployment yada replicaset’in parçası olarak oluşturulmamış olabilir, yada pod için yapılandırılmış nodeSelector yada anti-affinity konfigürasyonları olabilir, yada pod bulunduğu node üzerinde local storage kullanıyor olabilir. Böyle durumlarda pod silinip tekrardan schedule edilemez. Bu yüzden cluster autoscaler kullanılacağı zaman bu durumlar göz önünde bulundurulmalıdır.

İki scaling opsiyonuda beraber çalışabilir. Böyle durumlarda horizontal pod autoscaler uygulama için gerekli olan kaynak taleplerini takip ederken, cluster autoscaler schedule edilmiş podlar için gereki olan node sayısını takip eder.

Cluster autoscaler kullanıldığı durumlarda manuel scaling disable edilir. Eğer cluster manuel olarak scale edilmek istenirse, cluster auto scaler disable edilmelidir. Cluster autoscaler kullandığınız mimarilerde HTTP Application Routing add-on’u kullanılamamaktadır.

Cluster autoscaler nasıl konfigüre edilir?

Uygulamalarınızın gereksinimlerine bağlı olarak belli durumlarda cluster’ınızdaki node sayısını arttırmak isteyebilir siniz. Işte bu noktada cluster autoscaler devreye girer.

Cluster autoscaler uygulamanıza ait workload’u taşıyan ve kaynak yetersizliğinden ötürü schedule edilemeyen pod’larınız için cluster’ı monitor eder. Eğer böyle bir durum saptanırsa(kaynak yetersizliğinden ötürü schedule edilemeyen pod durumu) uygulama gereksinimlerine göre nodepool içerisindeki node’ların sayısı arttırılır. Aynı şey tersi durum için de geçerlidir. Node’lar düzenli olarak kontrol edilir ve uygulama tarafından node üzerindeki kaynaklara olan ihtiyaç düşerse, node sayısı da düşürülür. Cluster autoscaler tarafından bu işlem otomatik olarak sağlanır.

Şimdi hızlı şekilde cluster autoscaler konfigürasyonunun nasıl yapıldığını göstermek için yeni bir AKS Cluster oluşturalım. Cluster kurulumu sırasında cluster autoscaler özelliğinin nasıl etkinleştirildiğine göz atalım.

Öncelikle cluster objesi için bir resource group oluşturalım.

Resource group oluşturma işleminin ardından bu resource groubu kullanarak ve gerekli diğer parametreleri vererek bir AKS Cluster oluşturalım. Burada cluster autoscaler’a ilişkin dikkat edilmesi gereken üç önemli parameter vardır. Bunlar;

  • Enable-cluster-autoscaler : Bu özelliğin aktif hale getirilmesini sağlar.
  • Min-count: Çalışacak minimum pod sayısını ifade eder.
  • Max-count: Çalışabilecek maksimum pod sayısını ifade eder.

Gerekli parametreler kullanılarak AKS cluster oluşturulduktan sonra yapılan autoscaler ayarını kontrol edebilmek için NodePool üzerindeki scale ayarına bakabiliriz.

Scale ayarı kontrol edildiğinde scale metodunun ne olduğu, maksimum ve minimum count ayarlarını görüntüleyebilirsiniz.

Belirli durumlarda maksimum ve minimum sayıları değiştirilmek istenebilir. Bunu portal üzerinden kolaylıkla yapabilirsiniz. Yada aşağıdaki komutu kullanarak scale konfigürasyonunuzu update edebilirsiniz.

Node seviyesinde cluster autoscale konfigürasyonunu yapmak Azure platformu üzerinde yukarıdaki adımlardan ibarettir.

Peki Pod Seviyesinde scaling konfigürasyonu nasıl yapılır?

Kubernetes mimarisinde pod’ların yatay olarak scale olması desteklenmektedir. Hatta bu özellik horizontal pod autoscaling olarak isimlendirilir. Bu scaling mimarisind CPU utilizasyonu yada diğer metrik değerlere göre pod’ların scale olması sağlanabilir. Tabi bu scaling yapısının çalışması için Metric Server bileşenine ihtiyaç vardır. Metric server bileşeni sayesinde pod’ların resource utilizasyonları monitor edilir.

Metric Server AKS mimarisinde 1.10 versiyonu ile birlikte kurulu olarak gelmektedir. Eğer daha önceki versiyonları kullanıyorsanız, Metric Server’ı kurmak için aşağıdaki komutları sırasıyla çalıştırmanız yeterli olacaktır.

git clone https://github.com/kubernetes-incubator/metrics-server.git

kubectl create -f metrics-server/deploy/1.8+/

Horizontal pod autoscaling’in çalışması için gerekli ikinci gereksinim ise pod definition’larında aşağıdaki gibi CPU request ve limit tanımlamalarının yapılmasıdır.

Bu gereksinimler tamamlandıktan sonra, HorizontalPodAutoscaler objesini aşağıdaki gibi oluşturularak ilgili objelere bind edilebilir.

Objeyi iki şekilde oluşturabiliriz. Ya aşağıdaki gibi yaml file’ını kullanarak deploy ederiz. Yada imperative metodu kullanarak komut yoluyla horizontalPodAutoscaler objesini oluşturabilirz.

Öncelikle aşağıdaki definition file’ını yorumlayalım. Resimde verdiğim numaraların ne anlama geldiğini açıklayarak devam edelim.

  1. HPA(HorizontalPodAutoscaler) objesinin hangi obje için oluşturulacağı bu kısımda belirlenir. Bir deployment objesi için bu özelliği kullanacağımız için kind olarak Deployment yazılmıştır.
  2. Bu kısımda hangi deployment objesi için bu konfigürasyonun yapıldığı belirtilir. Bu amaçla deployment objesinin ismi yazılmıştır.
  3. targetCPUUtilizationPercentage kısmı bize pod’un scale olması için gerekli metric değeri verir. CPU utilizasyonu %50 olduğunda scaling işleminin yapılacağı anlamına gelir.
  4. Max ve Min replica kısmı ise bize çalışacak maksimum ve minimum pod sayısını verir.

Yukarıdaki definition dosyasını kubectl apply -f komutu ile kullanarak HPA objesini oluşturabilirsiniz.

Yada aşağıdaki komutu çalıştırarak da aynı sonucu elde edebilirsiniz.

kubectl autoscale deployment azure-vote-front — cpu-percent=50 — min=3 — max=10

HPA objesini oluşturduktan sonra kontrol amaçlı kubectl get hpa komutunu çalıştırabilirsiniz. Komutun çıktısında cluster üzerindeki HPA objeleri tüm parametreleri ile listelenecektir.

Özet olarak AKS cluster üzerinde node seviyesinde ve pod seviyesinde yapılandırabileceğiniz scaling ayarları mevcut. Node seviyesinde çalışan cluster autoscaler pod schedule işlemlerini kontrol edip, pod’lar schedule olamadığında yeni bir node ekleme işleminden sorumludur. Horizontal Pod Autoscaler ise Kubernetes ile birlikte gelen Metric server bileşenini kullanıp pod utilizasyonuna göre scaling’in horizontal olarak yapılmasını sağlayan bileşendir. İki scaling özelliğini de düzgün şekilde konfigüre edip birlikte kullanarak Kubernetes cluster üzerinde yüksek trafikli kolayca ölçeklenebilir modern uygulamalara sahip olabilirsiniz.

Kaynak: https://docs.microsoft.com/en-us/azure/aks/tutorial-kubernetes-scale

Kaynak2: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/

--

--