Namespace Bazında ResourceQuota Tanımlama
Kubernetes kümelerinde kaynak limitleri her iş yükü için CPU tüketimini denetim altında tutan temel bir mekanizmadır. Bu ayarlar sayesinde bir uygulama kümedeki diğer uygulamaları etkilemeden hizmet verebilir. Sistem yöneticisi bu değerleri dikkatli tanımladığında boşa harcanan kapasite önlenir ve küme kararlılığı yükselir. Limit tanımlanmayan pod düğüm üzerindeki tüm serbest kaynakları kullanabilir, bu da komşu iş yüklerinde kesintilere yol açabilir. Kurumsal ortamlarda limitler olmazsa olmaz kabul edilir. Doğru tasarım için önce uygulamanın ortalama ve tepe yük profili çıkarılmalıdır. Bu analiz ölçüm araçlarıyla sağlandığında sonuçlar daha tutarlı olur. Ayrıca namespace düzeyinde ResourceQuota ve LimitRange nesneleriyle varsayılan değerler tanımlanabilir. Böylece ekipler kendilerine ait iş yükleri için öngörülebilir sınırlarla çalışır. Sonuç olarak limit yönetimi, maliyet kontrolü ile kararlılığı birlikte destekleyen sürekli bir süreçtir.
Kubernetes'te requests ile limits arasındaki ayrım kaynak dağıtımının temelini oluşturur. İstekler, zamanlayıcının (scheduler) bir pod için rezerve ettiği minimum kaynak miktarıdır. Scheduler, düğüm seçerken bu değerlere bakar ve yalnızca yeterli boş kapasiteye sahip düğümlere yerleştirme yapar. Limitler ise bir konteynerin tavanı üst sınırı belirler. CPU için bu sınır aşıldığında konteyner throttle edilir, ancak sonlandırılmaz. RAM için ise limit aşıldığında konteyner OOMKilled hatasına düşerek sonlandırılır. Requests ile limits aynı miktara eşitlendiğinde pod Guaranteed QoS sınıfına girer. Farklı miktarlar tanımlandığında patlayabilir sınıf oluşur. Hiçbir sınır tanımlanmadığında BestEffort sınıfı geçerli olur ve bu pod kaynak baskısında ilk çıkarılma adayı olur. Dolayısıyla hangi sınıfın seçileceğine iş yükünün kritikliğine göre karar verilmeli. Önemli veritabanları için Guaranteed sınıf, toplu işler için esnek sınıf tercih edilebilir. Her iki miktarın da anlaşılması maliyet ve verim dengesini doğru kurmak için şarttır.
CPU limitlerinin tanımlanması iş yükünün davranışına bağlı olarak yapılmalıdır. İşlemci birimi millicore cinsinden ifade edilir ve 1000m değeri tek bir çekirdeğe karşılık gelir. Öncelikle uygulamanın düşük yük ve yoğun trafik altındaki işlemci kullanımı ölçülmeli. Prometheus gibi izleme sistemleriyle alınan veriler p99 yüzdelik değerleri üzerinden değerlendirilir. Sınır değeri genellikle bu zirve kullanımın biraz yukarısında tutulur. Aşırı kısıtlayıcı bir limit gecikmelere ve bekleme sürelerinin uzamasına neden olur. Çok yüksek bir limit ise küme kapasitesinin verimsiz kullanılmasına yol açar. Birçok ekip CPU limitini hiç kaldırıp yalnızca requests değerine dayanır. Bu yaklaşım esneklik sağlasa da komşu iş yüklerinde sorunlu etkilere neden olabilir. Yük ortamlarında farklı limit değerleri denenerek ideal nokta bulunmalıdır. Bu aşamada üretime yakın trafik senaryoları kullanıldığında sonuçlar önemli ölçüde anlamlı olur. Son olarak limitler, uygulama sürümleri değiştikçe tekrar değerlendirilmelidir.
Bellek limitlerinin hesaplanması 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 devreye girer ve süreci öldürür. Dolayısıyla bellek limiti konservatif ama isabetli ayarlanmalıdır. Hesaba başlamak uygulamanın heap ve stack tüketimi ayrıntılı incelenmelidir. Java tabanlı servislerde heap boyutu ile pod'un toplam belleği arasında makul bir boşluk bırakılmalıdır. Node ve Python uygulamalarında RAM sızıntıları uzun süre çalıştıkça limit aşımına yol açabilir. Bu yüzden sürekli izleme ile bellek eğrisi incelenmelidir. Kubernetes içinde container_memory_working_set_bytes örneğin metrikler, gerçek kullanımı isabetli gösterir. Sınır değeri genellikle zirve tüketimin yüzde yirmi fazlasında tutulur. Fakat aşırı büyük limitler düğüm belleğinin boşa edilmesine neden olur. Üretim değişkenleri değiştikçe hesaplamanın yeniden yapılması önerilir.
Kaynak isteklerinin isabetli ayarlanması, cluster planlamasının sağlıklı çalışması için vazgeçilmezdir. İstek değeri çok düşük girildiğinde scheduler 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ılmadığı halde bile dolu görünür. Bu durum cluster kullanım oranını düşürür ve fazla bulut maliyeti doğurur. Sağlıklı bir ilk değer için geçmiş metrikler incelenmeli ve medyan kullanım değerine yakın bir istek belirlenmelidir. Vertical Pod Autoscaler gibi mekanizmalar öneri üretebilir ve bu öneriler başlangıç ayar için kullanılabilir. Yatay pod ölçekleyici ile beraber kullanılırken çatışmalara dikkat gösterilmelidir. Ayrıca namespace seviyesinde LimitRange tanımlandığında eksik istekler otomatik atanabilir. Periyodik değerlendirme ile değerler iş yükü değişimlerine paralel tutulmalıdır.
Kubernetes kümelerinde kaynak sınırlarını doğru belirlemek için öncelikle QoS sınıflarını dikkatli anlamak gerekir. Bir pod BestEffort 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 Guaranteed 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 Burstable sınıfına girer ve kaynak fazlasını kullanabilir. Hiçbir request veya limit belirtilmeyen pod'lar en düşük öncelikli sınıfa düşer ve node üzerinde kaynak sıkıştığında ilk sonlandırılan adaylar arasında yer alır. Bu ayrım, kritik servisleri güvence altına almak 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 öngörülebilir 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 kurulmalı ve düzenli gözden geçirilmelidir.
LimitRange nesnesi, bir namespace içindeki container ve pod'lar için öntanımlı 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 zorunlu 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 yol açar. 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ı hazırlanabilir. Bu esneklik, kaynak yönetimini hem sadeleştirir hem de tutarlılığı destekler.
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 reddedilir. Bu mekanizma, bir ekibin tüm kümeyi tüketmesini 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ı durdurabilir, 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 ayarlanabilir.
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ı raporlar, 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 özen gösterilmelidir. 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 sağlıklı 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 anlamlı 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 belirlenmesi 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 gerekir. Ö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 teyit edilmelidir. 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ı ne şekilde ayarlanır
K8s kümelerinde pod başına kotaları doğru yapılandırmak hizmet kalitesi için büyük bir etki sağlar. İstekler ve limits ayarları iki değer arasındaki farklılık net kavranmadan hazırlanan yapılandırmalar verimsizliğe neden açar. Planlayıcı modülü requests değerlerine bağlı olarak kapsül konumlandırması tamamlar. Limits ise işletim sürecinde geçerli olur. Ön hazırlık şeklinde her konteyner bazında ölçülmüş ölçümler hesaplamak, kubectl top ör. araçlarla anlık yük verilerini derlemek çok sağlıklı adımdır.
Sıkça yapılan sorunlar hangileridir
Kaynaklar meselesinde en çok görülen aksaklıklardan ilki kotaların baştan yapılmamasıdır. Böyle bir sistemde tek bir kapsül tüm sunucu kaynağını ele geçirebilir hem de öteki uygulamaları etkileyebilir. Öteki görülen yanlış buna karşın requests miktarlarını gerektiğinden küçük bırakmaktır. Bu durumda koşulda iş yükü makineye çok yüklenir, ve bu disk sıkışıklığı ve sonlandırma olaylarına sebep açabilir. Son hata bunun yanında her pod'lara benzer kotaları atamak. Her bileşenin özgün kaynak ihtiyacı özelliği göz önüne alınmadan dikkate alınmalıdır.
Deneyimli öneriler ve sınır iyileştirmesi
Uzman operatörler sıklıkla kota alanında önemli yöntemi uygular: İlk olarak kullanım ölçümleri çalıştırılır ardından alınan veriler ışığında istek değerleri normal tüketimin hafifçe ötesine konumlandırılır. Sınırlar değerleri ise zirve tüketimi kaldıracak düzeyde ayarlanmalıdır. CPU için limit koymak zaman zaman anlamsız sınırlamalara kapı yaratabildiğinden itinalı olunmalıdır. Dikey ölçekleme aracı ile Horizontal Pod Autoscaler örneğin sistemler bununla birlikte bu aşamada tanımların süreç içinde optimize hale dönüşmesinde faydalı destek olur.
Sınır gideri hem de masraf yönetimi
K8s sistemlerinde kaynak limiti tanımları doğrudan doğruya dijital giderine tesir eder. Fazla geniş kaynak belirlenmiş bir çeşit cluster atıl yatan atıl kaynağa para yapılmasına yol yol açabilir. Bu olgu nedenle takım bütçe beklentilerini açık biçimde belirlemeli hem de sınır tercihlerini bu doğrultuda hedeflerle uyumlu duruma dönüştürmelidir. Gider takip araçları birlikte isim alanı düzeyinde raporlama yapmak bunun yanında hangi tür servisin hangi ölçüde güç kullandığını anlamayı olanak verir.
Dönemsel talep ile zamanlama yöntemleri
Bir çok işletmesel uygulama zaman ilerledikçe dalgalı bir çeşit trafik davranışına göre şekillenir. İndirim dönemleri, ödeme zamanları ya da mevsimlik olaylar boyunca kaynak talebi öngörüleri önceden tahmin edilmelidir. Söz konusu aralıklar adına statik sınırlar yerine geçecek şekilde programlanmış büyütme stratejileri uygulamak maliyeti ciddi ölçüde hafifletebilir. Cron görevleri ile benzeri mekanizmalar yoluyla gece saatlerinde sınırlı kapasiteye indirim sağlamak ise hem verim ile birlikte gider bakımından faydalı faydalar üretebilir.
Sık yöneltilen soru-cevap ile açıklamaları
K8s kota alanında başlıca soru yöneltilen sorudan ilk sırada istek ve limits rakamlarının eşit tutulup tutulmayacağıdır. Bu tür tercih Guaranteed servis sınıfı sınıfını oluşturur, yalnız kapasite çevikliğini ciddi ölçüde sınırlayabilir. Öteki öteki merak bunun yanında tavan kotaya dayanıldığında hangi tür yaşandığıdır. Bellek kotası aşıldığında uygulama sıklıkla bellek yetersizliği nedeniyle sonlandırma konumuna düşer, İşlemci kotası geçildiğinde ise uygulama kısıtlanır fakat çoğu zaman durdurulmaz. Böylece bu yüzden hafıza tavanlarının itinayla tanımlanması zorunludur.