Vertical Pod Autoscaler ile Öneri Almak
Kubernetes kümelerinde kaynak kısıtları her konteyner için bellek tüketimini kontrol altında tutan temel bir mekanizmadır. Bu yapılandırmalar sayesinde bir uygulama cluster içindeki diğer uygulamaları etkilemeden hizmet verebilir. Yönetici bu değerleri dikkatli tanımladığında atıl kaynaklar önlenir ve cluster kararlılığı yükselir. Limit tanımlanmayan pod node üzerindeki tüm serbest kaynakları kullanabilir, bu da diğer iş yüklerinde gecikmelere yol açabilir. Gelişmiş ortamlarda limitler vazgeçilmez kabul edilir. Doğru yapılandırma için önce uygulamanın normal ve tepe yük profili çıkarılmalıdır. Bu analiz metrik araçlarıyla yapıldığında sonuçlar daha isabetli olur. Ayrıca namespace düzeyinde kota ve sınır aralığı nesneleriyle genel değerler tanımlanabilir. Böylece ekipler kendi iş yükleri için tutarlı sınırlarla çalışır. Sonuç olarak limit yönetimi, kapasite kontrolü ile kararlılığı birlikte sağlayan sürekli bir süreçtir.
Kubernetes'te requests ile limit değerleri arasındaki fark kaynak yönetiminin temelini oluşturur. İstekler, zamanlayıcının (scheduler) bir pod için garanti ettiği minimum kaynak miktarıdır. Scheduler, node seçerken bu istek miktarlarına bakar ve yalnızca yeterli boş kapasiteye sahip düğümlere yerleştirme yapar. Limitler ise bir konteynerin aşamayacağı üst sınırı belirler. CPU için bu sınır aşıldığında süreç throttle edilir, ancak sonlandırılmaz. Bellek için ise limit aşıldığında konteyner OOMKilled hatasına düşerek sonlandırılır. İstekler ile limits aynı değere eşitlendiğinde pod Guaranteed hizmet kalitesi sınıfına dahil olur. Farklı miktarlar tanımlandığında patlayabilir sınıf oluşur. Hiçbir değer tanımlanmadığında en iyi çaba sınıfı söz konusu olur ve bu konteyner kaynak baskısında ilk tahliye adayı olur. Dolayısıyla hangi tür sınıfın kullanılacağına iş yükünün önceliğine göre karar verilmelidir. Önemli veritabanları için garantili sınıf, toplu işler için Burstable sınıf tercih edilebilir. Her iki miktarın da anlaşılması maliyet ve performans dengesini doğru kurmak için şarttır.
CPU limitlerinin ayarlanması servisin davranışına bağlı olarak yapılmalıdır. İşlemci birimi milicpu cinsinden ifade edilir ve 1000m değeri tek bir çekirdeğe karşılık gelir. Öncelikle uygulamanın sakin ve zirve trafik altındaki işlemci kullanımı kaydedilmelidir. Prometheus gibi araçlarla alınan veriler p99 yüzdelik değerleri üzerinden yorumlanır. Limit değeri genellikle bu zirve kullanımın biraz üzerinde tutulur. Aşırı kısıtlayıcı bir limit yavaşlamaya ve kuyruk sürelerinin uzamasına neden olur. Gereksiz geniş bir limit ise küme kapasitesinin boşa kullanılmasına sebep olur. Birçok ekip CPU limitini tamamen kaldırıp yalnızca requests değerine dayanır. Bu yaklaşım esneklik sağlasa da diğer iş yüklerinde gürültülü etkilere yol açabilir. Yük ortamlarında farklı limit değerleri denenerek ideal nokta tespit edilmelidir. Bu aşamada gerçek trafik örnekleri kullanıldığında sonuçlar çok daha anlamlı olur. Son olarak limitler, servis sürümleri güncellendikçe tekrar gözden geçirilmelidir.
Bellek limitlerinin belirlenmesi CPU'ya kıyasla daha kritik bir süreçtir, çünkü bellek sıkıştırılamaz bir kaynaktır. Limit aşıldığında işletim OOM Killer çalışır ve konteyneri sonlandırır. Dolayısıyla RAM limiti güvenli ama isabetli belirlenmelidir. Hesaba başlamadan önce uygulamanın yığın ve yığın bellek tüketimi detaylı analiz edilmelidir. JVM tabanlı servislerde heap boyutu ile konteynerin toplam RAM'i arasında dengeli bir pay bırakılmalıdır. Node.js ve Python uygulamalarında bellek sızıntıları uzun süre çalıştıkça limit ihlaline yol açabilir. Bu sebeple uzun süreli izleme ile kullanım grafiği takip edilmelidir. Kubernetes içinde container_memory_working_set_bytes örneğin metrikler, fiili kullanımı doğru yansıtır. Sınır değeri genellikle zirve kullanımın yüzde yirmi fazlasında tutulur. Ancak gereğinden fazla büyük limitler düğüm belleğinin israf edilmesine yol açar. Üretim değişkenleri değiştikçe hesaplamanın tekrar yapılması tavsiye edilir.
Kaynak isteklerinin isabetli ayarlanması, cluster zamanlamasının sağlıklı çalışması için vazgeçilmezdir. Requests değeri çok düşük tanımlandığında zamanlayıcı pod'u aşırı dolu düğümlere atar, bu da kararlılık sorunlarına neden olur. Çok yüksek tanımlandığında ise düğümler fiilen kullanılmasa bile kapasitesi tükenmiş gözükür. Bu olgu küme verimliliğini düşürür ve fazla altyapı harcaması oluşturur. Doğru bir başlangıç için geçmiş metrikler incelenmeli ve medyan kullanım değerine yakınsak bir istek tanımlanmalıdır. Dikey pod ölçekleyici gibi mekanizmalar öneri üretebilir ve bu tavsiyeler ilk ayar için değerlendirilebilir. Horizontal Pod Autoscaler ile beraber kullanılırken çakışmalara dikkat gösterilmelidir. Ayrıca ad alanı seviyesinde LimitRange kurulduğunda unutulmuş istekler kendiliğinden doldurulabilir. Periyodik değerlendirme ile ayarlar iş yükü değişimlerine uyumlu güncel tutulmalıdır.
Kubernetes kümelerinde kaynak limitlerini doğru belirlemek için öncelikle QoS sınıflarını derinlemesine anlamak gerekir. Bir pod Guaranteed sınıfına, tanımlanan request ve limit değerlerine göre atanır. Pod içindeki her container için request ve limit eşit tanımlanırsa pod kesin garantili kabul edilir ve bellek baskısı altında en son sonlandırılan grup olur. Yalnızca request tanımlanmış veya request ile limit farklı olan pod'lar esnek sınıfına girer ve kaynak fazlasını kullanabilir. Hiçbir request veya limit belirtilmeyen pod'lar BestEffort sınıfa düşer ve node üzerinde kaynak sıkıştığında ilk tahliye edilen adaylar arasında yer alır. Bu ayrım, kritik servisleri korumak için temel bir araçtır. Doğru sınıflandırma yapıldığında, yoğun yük altında bile önemli uygulamaların kesintisiz çalışması sağlanabilir. Üretim ortamında her iş yükünün önem derecesine göre QoS sınıfı bilinçli biçimde seçilmelidir. Aksi halde beklenmeyen tahliyeler ve performans düşüşleri kaçınılmaz hale gelir. Ekipler bu sınıfları, ilgili manifestolarda açıkça tanımlayarak tutarlı bir davranış elde edebilir. Ayrıca node kapasitesinin bu sınıfların toplam talebini karşılayacak şekilde planlanması gerekir. Son olarak, QoS kararlarının izlenmesi için metrikler ve uyarılar yapılandırılmalı ve düzenli gözden geçirilmelidir.
LimitRange nesnesi, bir namespace içindeki container ve pod'lar için varsayılan request ve limit değerlerini tanımlamanın pratik bir yoludur. Geliştiriciler manifestolarında kaynak belirtmeyi atladığında bile, LimitRange devreye girerek her container'a makul değerler atar. Böylece BestEffort sınıfında kalan pod sayısı azaltılabilir. Bu nesne ile minimum ve maksimum sınırlar da kesin kılınabilir. Örneğin bir container'ın belleği belirli bir üst sınırı aşarsa, API sunucusu isteği reddeder. Bu yaklaşım, aşırı kaynak tahsisini sınırlar ve küme genelinde adil dağılım sağlar. LimitRange, request ile limit oranını da kısıtlayabilir ve böylece aşırı taahhüt sorununu azaltır. Varsayılan değerler seçilirken uygulamaların tipik kullanım profilleri göz önünde bulundurulmalıdır. Çok düşük değerler sık OOMKill olaylarına, çok yüksek değerler ise kaynak israfına neden olur. Bu nedenle ekipler, LimitRange değerlerini periyodik olarak gözden geçirmeli ve uygulamaların gerçek davranışıyla karşılaştırmalıdır. Ayrıca farklı ortamlar için, örneğin geliştirme ve üretim namespace'leri için, ayrı LimitRange tanımları oluşturulabilir. Bu esneklik, kaynak yönetimini hem sadeleştirir hem de tutarlılığı korur.
ResourceQuota, bir namespace'in tüketebileceği toplam kaynak miktarını sınırlandırarak çok kiracılı kümelerde adaletli bir paylaşım sağlar. Bu nesne ile CPU ve bellek toplamları, depolama talepleri ve hatta pod, service veya secret gibi nesne sayıları sınırlanabilir. Bir namespace kotası dolduğunda, yeni kaynak talepleri API sunucusu tarafından geri çevrilir. Bu mekanizma, bir ekibin tüm kümeyi ele geçirmesini engeller. ResourceQuota kullanırken, quota kapsamındaki her pod'un request ve limit değerlerini açıkça belirtmesi gerekir, aksi halde talep kabul edilmez. Bu nedenle LimitRange ile birlikte kullanmak çoğu zaman en iyi yaklaşımdır. Kota değerleri belirlenirken geçmiş tüketim verileri ve büyüme tahminleri esas alınmalıdır. Fazla sıkı kotalar dağıtımları engelleyebilir, fazla gevşek kotalar ise amacını kaybeder. Ayrıca kota kullanım oranlarının düzenli izlenmesi, sorunların erken fark edilmesini sağlar. Kurumsal ortamlarda her ekibin kotası, iş birimi bütçesiyle uyumlu hale getirilebilir.
Vertical Pod Autoscaler, pod'ların geçmiş kullanım verilerine dayanarak request ve limit değerlerini kendiliğinden önermesini veya uygulamasını sağlayan bir bileşendir. VPA, öneri modunda çalıştığında yalnızca tavsiyeler üretir ve bunları kayıt altına alır, böylece ekipler değişiklikleri kendi onaylarına göre uygulayabilir. Auto moduna geçildiğinde ise VPA, pod'ları yeniden oluşturarak değerleri doğrudan günceller. Bu yaklaşım, manuel ayarlama yükünü ciddi biçimde azaltır. Ancak pod yeniden başlatmalarının kesinti yaratabileceği unutulmamalıdır. Bu nedenle kritik iş yüklerinde önce öneri modu ile test yapılması önerilir. VPA ile Horizontal Pod Autoscaler birlikte kullanılacaksa, aynı metrik üzerinde çakışma olmamasına dikkat edilmelidir. VPA önerilerinin, uygulamanın ölçeklenme davranışı ile uyumlu olup olmadığı değerlendirilmelidir. Öneri değerlerinin minimum ve maksimum sınırlarını belirlemek, aşırı sapmaları önler. Düzenli olarak önerileri inceleyen bir süreç kurmak, uzun vadede en verimli sonuçları getirir.
Gerçek kullanım verisine dayalı kaynak ayarı, tahminlere değil ölçümlere bağlı en güvenilir yöntemdir. Prometheus gibi araçlarla toplanan CPU ve bellek metrikleri, uygulamanın gerçek profilini ortaya koyar. Bu veriler, belirli bir zaman aralığında yüzdelik değerler, özellikle p95 ve p99, olarak analiz edildiğinde isabetli sonuçlar verir. Request değeri genellikle ortalama kullanıma yakın, limit değeri ise tepe yüklere yeterli seçilmelidir. Bellek limitlerinin, CPU limitlerine göre daha dikkatli ayarlanması gerekir, çünkü bellek aşımı OOMKill ile sonuçlanır. CPU limitlerinin ise bazı durumlarda gereksiz gecikmelere yol açabileceği tartışılmaktadır. Bu nedenle her iş yükü için ayrı bir değerlendirme yapılmalıdır. Ölçüm süreci, farklı trafik dönemlerini, örneğin kampanya veya ay sonu yoğunluğunu, kapsayacak biçimde uzatılmalıdır. Elde edilen değerler, deployment sonrası davranışla karşılaştırılarak doğrulanmalıdır. Sürekli iyileştirme döngüsü kurulduğunda, kaynak kullanımı hem maliyet hem de güvenilirlik açısından dengeli hale gelir.
Konteyner orkestrasyon kaynak kotaları nasıl planlanır
K8s çok düğümlü sistemlerde pod başına kotaları dengeli tanımlamak kararlılık için önemli bir öneme sahip unsur sağlar. Requests ile limits ayarları arasında fark tam bilinmeden tasarlanan ayarlar beklenmedik durumlara yol açar. Planlayıcı katmanı istek rakamlarına bakarak pod atamasını sağlar. Limits ancak yürütme esnasında devreye girer. Başlangıç biçiminde tüm konteyner adına izlenmiş veriler hesaplamak, Prometheus örneğin çözümlerle fiili tüketim verilerini değerlendirmek son derece isabetli stratejidir.
Tipik karşılaşılan yanlışlar hangileridir
Kaynaklar alanında başlıca görülen aksaklıklardan biri tanımların hiç girilmemesidir. Bu durumda bir tür kümede tek iş yükü mevcut makine kaynağını kullanabilir ve kalan bileşenleri olumsuz etkileyebilir. Öteki sık yanlış de istek miktarlarını gerektiğinden küçük tutmaktır. Bu durumda senaryoda konteyner sunucuya fazla atanır, bu da bellek yükü hem de bellek yetersizliği vakalarına yol doğurur. Bir başka sorun bunun yanında bütün uygulamalara aynı sınırları atamak. Her servisin ayrı yük özelliği olduğu dikkate alınmalıdır.
Uzman ipuçları ile kaynak yönetimi ayarı
Uzman mühendisler genellikle kota alanında bu yöntemi kullanır: İlk olarak yük sınamaları uygulanır sonrasında toplanan ölçümler ışığında requests miktarları ortalama tüketimin bir miktar üzerine ayarlanır. Sınırlar rakamları fakat yoğun kullanımı karşılayacak biçimde seçilmelidir. CPU açısından tavan uygulamak bazen yersiz sınırlamalara neden açabildiğinden özenli hareket edilmelidir. VPA ve Horizontal Pod Autoscaler örneğin araçlar dahi bu tanımların uzun vadede dengeli konuma gelmesinde işe yarar destek olur.
Kaynak bütçesi ve masraf takibi
K8s altyapısında sınır tanımları doğrudan bulut harcamasına yansır. Fazla kapsamlı kaynak talebi ayarlanmış bir çeşit altyapı değerlendirilmeden kalan kapasiteye harcama yapılmasına yol yol doğurur. Bu olgu nedenle takım bütçe öngörülerini açık şekilde çizmelidir ile kaynak planlaması kararlarını bu temelde öngörülerle bağdaşan konuma getirilmelidir. Harcama gözlem mekanizmaları ile ad alanı ölçeğinde raporlama sağlamak bunun yanında hangi servisin ne kaynak harcadığını belirlemeyi mümkün kılar.
Zamanlamaya bağlı talep ve planlama metotları
Pek çok kurum içi hizmet yıl boyunca değişken bir çeşit trafik profiline göre şekillenir. Satış dönemleri, faturalama dönemleri ile mevsimlik organizasyonlar sırasında yük beklentileri baştan tahmin edilmelidir. Söz konusu aralıklar açısından değişmez kotalar yerine geçecek şekilde zamanlanmış büyütme yöntemleri benimsemek maliyeti kayda değer düzeyde azaltabilir. Planlayıcı işleri ve benzer araçlar vasıtasıyla sabah erken vakitlerinde sınırlı kapasiteye indirim yapmak ise aynı zamanda başarım ve gider yönünden kıymetli kazanımlar üretebilir.
Sık merak edilen sorular ve açıklamaları
K8s kaynak limiti alanında başlıca soru yapılan konulardan biri requests ile limits miktarlarının tek tutulması seçilmeyeceğidir. Böyle bir yaklaşım Kesin hizmet düzeyi grubunu sağlar, ama tüketim çevikliğini belirgin oranda kısıtlayabilir. Başka bir yaygın merak bunun yanında limit tavana ulaşıldığında hangi yaşandığıdır. Hafıza tavanı aşıldığında servis çoğunlukla bellek yetersizliği nedeniyle sonlandırma kaderine geçer, İşlemci sınırı geçildiğinde ancak uygulama kısıtlanır ama çoğunlukla kapatılmaz. Böylece nedenle bellek alanı limitlerinin dikkatle planlanması şarttır.