Bu makale, Kubernetes'teki Yatay Kapsül Otomatik Ölçeklendiricisinin (HPA) nasıl çalıştığı ve nasıl kullanılacağı konusunda üst düzey bir genel bakış sunar.
Bu makalenin önceki bir versiyonu learnk8s.io'da yayınlandı .
Statik olarak yapılandırılmış çoğaltma sayısına sahip durum bilgisi olmayan bir uygulamayı dağıtmak optimum değildir.
Trafik modelleri hızla değişebilir ve uygulama bunlara uyum sağlayabilmelidir:
Yatay Kapsül Otomatik Ölçekleyici (HPA) ile Kubernetes, yukarıda anlatıldığı şekilde otomatik ölçeklendirme uygulamaları için mükemmel destek sağlar.
Öncelikle, herhangi bir yanlış anlaşılmayı ortadan kaldırmak için Kubernetes'te "otomatik ölçeklendirme" teriminin kullanımına açıklık getirelim.
Kubernetes birkaç otomatik ölçeklendirme özelliği içerir:
Bu makale, yalnızca Yatay Kapsül Otomatik Ölçeklendiricisine odaklanmaktadır.
Yatay Pod Autoscaler (HPA) olan yerleşik bir yatay bir veya daha fazla varsayılan veya kullanıcı tanımlı metriklere dayalı uygulamaları ölçekli sağlar Kubernetes özelliği.
Yatay ölçekleme, çoğaltma sayısını artırmak ve azaltmak anlamına gelir. Dikey ölçekleme, tek bir eşlemenin işlem kaynaklarını artırmak ve azaltmak anlamına gelir.
HPA, bir uygulama hakkındaki bir veya daha fazla ölçümü sürekli olarak izler ve ölçümleri belirli bir hedef değere mümkün olduğunca yakın tutmak için bu uygulamanın replika sayısını ayarlar.
HPA tarafından yürütülen kontrol döngüsü şu şekildedir:
Kontrol döngüsünün adımları şunlardır:
İstenen çoğaltma sayısının hesaplanması, ölçeklendirme ölçütlerine ve bu ölçütler için kullanıcı tarafından sağlanan hedef değere dayanır.
Kontrol döngüsünün her yinelemesinde, HPA, ölçümlerin ölçülen değerlerini mümkün olduğunca hedef değerlere yaklaştıran bir kopya sayısı hesaplar.
Örneğin, ölçeklendirme metriğinin, uygulamanın tüm çoğaltma Kapsüllerinde saniye başına alınan ortalama istek sayısı (istek / sn) olduğunu düşünün:
X = N * (c/t)
Xistenen kopya sayısıdır
Nmevcut kopya sayısı
cölçekleme metriğinin mevcut değeridir
tölçekleme metriğinin hedef değeridir
HPA yüksek seviyeden böyle çalışır - şimdi nasıl yapılandırıldığına bakalım.
HPA'nın yapılandırılması, HorizontalPodAutoscaler kaynakları aracılığıyla yapılır .
Bir HorizontalPodAutoscaler kaynak, aşağıdaki bilgileri belirlemenizi sağlar:
Örnek HorizontalPodAutoscaler kaynağı aşağıda verilmiştir:
apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: myhpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: myapp minReplicas: 1 maxReplicas: 10 metrics: - type: Pods pods: metric: name: myapp_requests_per_second target: type: AverageValue averageValue: 50
Yukarıdaki örnek HorizontalPodAutoscaler kaynağı aşağıdaki bilgi parçalarını içerir:
myapp
myapp_requests_per_second
Şimdi, bulmacada hala büyük bir eksik parça var.
Metrik nedir
myapp_requests_per_secondve nereden geliyor?
HPA, HorizontalPodAutoscaler kaynaklarında belirtilen ölçümleri nasıl elde eder ?
HPA'nın bu ölçümleri metrik API'lerinden sorguladığı (ve bunun karşılığında otomatik ölçeklendirme için kullanılacak tüm uygulama ölçümlerinin metrik API'leri aracılığıyla açığa çıkarılması gerektiği) ortaya çıktı:
Metrik API'leri, bir Kubernetes kümesinde, farklı metrik türlerinin farklı türlerdeki istemcilere sunulabileceği merkezi bir yerdir ve HPA bu istemcilerden biridir.
Farklı türde metriklere hizmet vermeyi amaçlayan üç farklı ölçüm API'si vardır:
API sunucusundaki bu metrik API'leri için uç nokta yolları şunlardır:
/apis/metrics.k8s.io/v1beta1/Resource Metrics API için
/apis/custom.metrics.k8s.io/v1beta1/Özel Metrikler API'si için
/apis/external.metrics.k8s.io/v1beta1/External Metrics API için
myapp_requests_per_secondYukarıdaki örnekte metrik kullanıcı tanımlı bir metrik ve (anlamını Pod aldığı saniyede istek mevcut sayıdır) Pod ile ilişkilidir.
Bu,
myapp_requests_per_secondmetriğin Özel Metrikler API'sı aracılığıyla sunulması gerektiği anlamına gelir .
Ancak bu metrik, Özel Metrikler API'sine nasıl girer?
Cevap, bu metrik için toplanan, işlenen ve Özel Metrikler API'si aracılığıyla sunulan şeyleri düzenlemeniz gerektiğidir.
Bunu yapmak için ilk olarak Özel Metrikler API'sini etkinleştirmeniz gerekir.
Bir metrik API'sinin etkinleştirilmesi , kümeye bu belirli metrikler API'sini sağlayan bir metrik API sunucusu yüklenerek yapılır :
Bir metrics API sunucusu, metrikleri bir metrik API aracılığıyla sunar, ancak genellikle metrik kaynaklarından ham ölçüm verilerini toplamaz. Bu iş, metrik toplayıcı adı verilen ( kümenin içinde veya dışında çalışabilen) başka bir bileşen tarafından yapılır :
Üç ölçüm API'sinin hepsinin etkin olduğu tipik bir kurulum bu nedenle aşağıdaki gibi görünür:
Bu kurulum, Kaynak Metrikleri API'si için cAdvisor ve Metrics Sunucusundan (resmi varsayılanlar) ve Özel Metrikler API'si ve Harici Metrikler API'si için Prometheus ve Prometheus Adaptöründen oluşan başka bir ölçüm hattından oluşan bir ölçüm hattını kullanır.
Vanilya Kubernetes kümesinde bu bileşenlerden hiçbirinin (cAdvisor dışında) varsayılan olarak yüklenmediğini unutmamak önemlidir. Metrik API'lerinden yararlanmak istiyorsanız (örneğin, HPA ile uygulamaları otomatik ölçeklendirmek için), bunları uygun şekilde yüklemeniz ve yapılandırmanız gerekir.
Metriğe
myapp_requests_per_seconddönersek, bu örnek senaryodaki durum aşağıdaki gibi görünecektir:
myapp.
myapp_requests_per_secondÖzel Metrikler API'si aracılığıyla adlandırılan bir metrik olarak sunar .
myapp_requests_per_second, Özel Metrikler API'sinden ölçüyü sorgular ve Dağıtımı otomatik ölçeklendirmek için kullanır
myapp.
Bu oldukça ağız doluydu, öyleyse bir örnek üzerinden yürüyerek özetleyelim.
İşlerin birlikte nasıl çalıştığını daha iyi görmek için, uygulamanın Kapsüllerinin saniyede aldığı ortalama istek sayısına göre bir uygulamayı HPA ile otomatik olarak ölçeklendirmek için yapmanız gereken somut adımları inceleyelim.
Aşağıda, kümede henüz etkinleştirilmiş ölçüm API'lerinin olmadığı, otomatik ölçeklenecek uygulamanın adı verilen bir Dağıtım olduğu
myapp, otomatik ölçeklendirmek istediğiniz metrik çağrıldığı
myapp_requests_per_secondve Prometheus tabanlı bir özel ölçüm hattını kullanmak istediğiniz varsayılmaktadır (yukarıda gösterildiği gibi) ).
İşte yapmanız gerekenler:
myapp_requests_per_secondve Özel Metrikler API'si aracılığıyla açığa çıkarmak için yapılandırın . Prometheus Adaptörünün yapılandırılması , bir Prometheus Adaptör konfigürasyon dosyasıyla yapılır .
myapp
myapp_requests_per_second
Ve arkanıza yaslanıp uygulamanızın her zaman mevcut talebe göre uyarlandığından emin olabilirsiniz.
Bu bilgiyi pratiğe dökmek hala çok iştir. Özellikle, doğru ölçümleri doğru şekilde toplamak ve açığa çıkarmak için Prometheus ve Prometheus Adaptörünü yapılandırmanın birçok özel detayı vardır.
Zaman izin verirse, gelecekteki bir makalede tüm bunları kurmanın tam ve pratik bir adım adım açıklamasını sunacağım.
Bununla ilgilenirseniz yorumlarda bana bildirin!
Bu derste, özellikle bir gecede antrenman yapmanız gerektiğinde son derece kullanışlı olacak, Linux terminalinde bir hack to model eğitimini tanıtacağım. P.
Çoğu web uygulamasında yazmadan çok daha fazla okuma vardır ve okuma ağırlıklı bir web uygulamasını optimize etme teknikleri oldukça iyi bilinmektedir. İşlerin gerçekten eğlenceli ve ilginç hale geldiği yer, genel durumun dışına çıkıp alışılmadık bir duruma girdiğiniz zamandır: düşük gecikmeye ihtiyacınız olduğunda, önbelleğe alınamayan sık yazma işlemleriniz olur ve yazdıklarınızı sık sık okursunuz.
Kubernetes'in yaygınlaştığını söylemek yetersiz kalır. Aslında, modern dağıtılmış sistemlerin nasıl tasarlandığını ve işletildiğini etkiledi.
Bu sadece kodlama ve teknik becerilerle ilgili değil Üç yıl önce, kurumsal dünyaya işlerin nasıl görüneceğine dair tonlarca varsayım ve beklentiyle ilk kez adım attım. Ne kadar yanıldığımı kanıtlamak üzere olduğumu çok az biliyordum.
Kubernetes Kabul Denetleyicisi nedir? Kubernetes kabul denetleyicileri, kimliği doğrulanmış istekleri Kubernetes API sunucusuna yakalayarak ve herhangi bir nesne verisi etcd veri deposunda saklanmadan önce bunları işleyerek ağ geçidi koruyucusu görevi gören eklentilerdir. Kabul denetleyicileri, bir istek nesnesini değiştirebilir / değiştirebilir (Değişen Kabul Denetleyicileri) veya bir isteğe izin verebilir / izin vermeyebilir (Kabul Denetleyicileri) ve bazen her ikisini de yapabilir.
Sprint günlerinde bir Hikaye, önceki 2 haftadaki başarılarımızı (veya başarısızlıklarımızı) yansıtıyoruz. Yakınlaştırmaya atlayıp düşüncelerimizi paylaşıp derinlemesine düşünmeden önce yaklaşık 20 dakika.