Pod Seviyesinde Kaynak Tanımlama Adımları
Kubernetes kümelerinde kaynak kısıtları her pod için CPU tüketimini kontrol altında tutan temel bir mekanizmadır. Bu ayarlar sayesinde bir uygulama kümedeki diğer servisleri etkilemeden işlevini sürdürebilir. Sistem yöneticisi bu değerleri dikkatli tanımladığında atıl kaynaklar önlenir ve küme kararlılığı artar. Limit tanımlanmayan pod düğüm üzerindeki tüm kullanılabilir kaynakları tüketebilir, bu da diğer iş yüklerinde kesintilere yol açabilir. Üretim ortamlarda limitler zorunlu kabul edilir. Doğru tasarım için önce uygulamanın tipik ve tepe yük profili incelenmeli. Bu analiz metrik araçlarıyla gerçekleştirildiğinde sonuçlar çok daha güvenilir olur. Ayrıca namespace düzeyinde ResourceQuota ve LimitRange nesneleriyle genel değerler belirlenebilir. Böylece ekipler kendi iş yükleri için öngörülebilir sınırlarla hareket eder. Sonuç olarak limit yönetimi, kapasite kontrolü ile kararlılığı birlikte güçlendiren sürekli bir süreçtir.
Kubernetes'te istek değerleri ile limit değerleri arasındaki ayrım kaynak yönetiminin temelini oluşturur. Requests, zamanlayıcının (scheduler) bir pod için ayırdığı minimum kaynak miktarıdır. Scheduler, düğüm seçerken bu istek miktarlarına bakar ve yalnızca yeterli serbest kapasiteye sahip node'lara yerleştirme yapar. Limits ise bir konteynerin tavanı üst sınırı belirler. İşlemci için bu sınır aşıldığında süreç yavaşlatılır, ancak sonlandırılmaz. Bellek için ise limit aşıldığında konteyner OOMKilled durumuna düşerek öldürülür. İstekler ile limitler aynı değere eşitlendiğinde konteyner Guaranteed QoS sınıfına girer. Farklı miktarlar tanımlandığında patlayabilir sınıf oluşur. Hiçbir değer tanımlanmadığında en iyi çaba sınıfı geçerli olur ve bu pod kaynak baskısında ilk çıkarılma adayı olur. Dolayısıyla hangi tür sınıfın seçileceğine iş yükünün kritikliğine göre karar verilmelidir. Kritik veritabanları için garantili sınıf, batch işler için esnek sınıf uygun olabilir. Her iki miktarın da anlaşılması maliyet ve verim dengesini sağlıklı kurmak için gereklidir.
CPU limitlerinin belirlenmesi servisin davranışına bağlı olarak gerçekleştirilmelidir. CPU birimi milicpu cinsinden ifade edilir ve 1000m değeri tek bir core'a karşılık gelir. Öncelikle uygulamanın boşta ve zirve yük altındaki işlemci kullanımı kaydedilmelidir. Prometheus gibi izleme sistemleriyle alınan metrikler p99 persentil değerleri üzerinden yorumlanır. Sınır değeri çoğunlukla bu zirve kullanımın biraz üzerinde tutulur. Çok düşük bir limit gecikmelere ve kuyruk sürelerinin artmasına neden olur. Çok yüksek bir limit ise küme kapasitesinin boşa kullanılmasına sebep olur. Pek çok ekip CPU limitini hiç kaldırıp yalnızca istek değerine dayanır. Bu yaklaşım esneklik sağlasa da komşu iş yüklerinde sorunlu etkilere neden olabilir. Test ortamlarında çeşitli limit değerleri denenerek ideal nokta tespit edilmelidir. Bu aşamada üretime yakın trafik örnekleri kullanıldığında sonuçlar çok daha değerli olur. Son olarak limitler, servis sürümleri güncellendikçe tekrar gözden geçirilmelidir.
Bellek limitlerinin hesaplanması CPU'ya göre çok daha hassas 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 süreci öldürür. Bu nedenle bellek limiti konservatif ama isabetli belirlenmelidir. Hesaba başlamadan önce uygulamanın yığın ve yığın bellek tüketimi ayrıntılı analiz edilmelidir. JVM tabanlı servislerde heap boyutu ile pod'un toplam belleği arasında dengeli bir boşluk bırakılmalıdır. Node.js ve Python uygulamalarında RAM 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 incelenmelidir. Kubernetes içinde çalışma kümesi bellek metriği örneğin metrikler, fiili kullanımı doğru gösterir. Limit değeri genellikle zirve kullanımın yüzde on beş üzerinde tutulur. Ancak gereğinden fazla büyük limitler node belleğinin israf edilmesine neden olur. Ortam değişkenleri farklılaştıkça hesaplamanın yeniden yapılması tavsiye edilir.
Kaynak isteklerinin isabetli ayarlanması, cluster planlamasının sağlıklı çalışması için kritik öneme sahiptir. İstek değeri gereğinden az tanımlandığında zamanlayıcı pod'u aşırı dolu düğümlere atar, bu da performans sorunlarına yol açar. Gereğinden fazla tanımlandığında ise düğümler gerçekte kullanılmasa bile kapasitesi tükenmiş gözükür. Bu durum cluster verimliliğini azaltır ve fazla bulut harcaması oluşturur. Sağlıklı bir başlangıç için tarihsel metrikler değerlendirilmeli ve medyan kullanım değerine yakınsak bir istek belirlenmelidir. Vertical Pod Autoscaler örneğin araçlar öneri sunabilir ve bu öneriler başlangıç yapılandırma için kullanılabilir. Yatay pod ölçekleyici ile beraber kullanılırken çatışmalara dikkat gösterilmelidir. Bunun yanında ad alanı seviyesinde sınır aralığı tanımlandığında unutulmuş istekler otomatik atanabilir. Periyodik değerlendirme ile değerler uygulama gelişimine uyumlu güncel tutulmalıdır.
Kubernetes kümelerinde resource limit değerlerini doğru belirlemek için öncelikle QoS sınıflarını iyi 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 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 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 sık rastlanan 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 kurulmalı 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 etkili bir yoludur. Geliştiriciler manifestolarında kaynak belirtmeyi unuttuğunda 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 engeller. 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 riskini 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üncellemeli 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ığı korur.
ResourceQuota, bir namespace'in tüketebileceği toplam kaynak miktarını sınırlandırarak çok kiracılı kümelerde dengeli bir paylaşım sağlar. Bu nesne ile CPU ve bellek toplamları, depolama talepleri ve hatta pod, service veya secret gibi nesne sayıları kısıtlanabilir. 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 ideal 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ı yitirir. Ayrıca kota kullanım oranlarının düzenli izlenmesi, sorunların erken tespit 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ı 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 otomatik olarak günceller. Bu yaklaşım, manuel ayarlama yükünü önemli ölçüde 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 gözlem 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 tutarlı 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 dayanan 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 uygun 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 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 sınırları ne şekilde planlanır
Kubernetes çok düğümlü sistemlerde CPU ve bellek sınırlarını akılcı yapılandırmak kararlılık noktasında kritik bir görev oynar. İstekler ile sınırlar kavramları arasındaki ayrım açık kavranmadan uygulanan tanımlamalar beklenmedik durumlara yol getirebilir. Planlayıcı bileşeni istek rakamlarına göre kapsül konumlandırması yapar. Sınırlar ancak çalışma zamanında devreye girer. Başlangıç biçiminde her bir uygulama adına izlenmiş veriler hesaplamak, izleme aracı örneğin yöntemlerle canlı harcama bilgilerini değerlendirmek çok isabetli adımdır.
Tipik yapılan pürüzler hangileridir
Kaynak meselesinde başlıca görülen hatalardan ilk sırada limitlerin hiçbir zaman ayarlanmamasıdır. Bu durumda bir kümede tek bir pod mevcut sunucu belleğini ele geçirebilir hem de öteki uygulamaları durdurabilir. İkinci tipik sorun bunun yanında istek rakamlarını gereğinden küçük tutmaktır. Bunun sonucunda ortamda pod sunucuya çok yerleştirilir, bu da işlemci sıkışıklığı ve bellek yetersizliği olaylarına neden açar. Üçüncü yanlış öte yandan bütün uygulamalara benzer limitleri uygulamak. Bütün iş yükünün kendine özgü yük davranışı olduğunu göz ardı edilmemelidir.
Uzman ipuçları ile kota optimizasyonu
Deneyimli yöneticiler çoğunlukla sınır hususunda şu metodu benimser: Başlangıçta trafik sınamaları yapılır ardından çıkan ölçümler ölçüsünde istek değerleri normal tüketimin biraz üstüne ayarlanır. Sınırlar miktarları oysa yoğun yükü destekleyecek biçimde seçilmelidir. CPU adına sınır koymak kimi zaman anlamsız kısıtlamalara yol açabildiğinden dikkatli yaklaşılmalıdır. VPA ile HPA örneğin sistemler da bu aşamada değerlerin zamanla optimize biçime dönüşmesinde yararlı destek olur.
Kota harcaması ve gider yönetimi
K8s sistemlerinde kota tanımları doğrudan sanal faturasına yansıtılır. Gereğinden büyük sınır atanmış bir tür ortam değerlendirilmeden bekleyen atıl kaynağa ödeme yapılmasına yol neden açabilir. Bu sorun nedenle takım maliyet hedeflerini belirgin surette ortaya koymalı hem de kota kararlarını bu temelde planlarla tutarlı hale getirmelidir. Maliyet izleme araçları ile ad alanı düzeyinde analiz sağlamak ayrıca hangi servisin ne kaynak ayırdığını anlamayı mümkün kılar.
Zamanlamaya bağlı trafik ve zamanlama metotları
Çeşitli kurumsal uygulama dönem içinde oynak bir tür kullanım davranışına sahip olur. Promosyon zamanları, faturalama günleri yahut mevsimlik organizasyonlar boyunca yük tahminleri önceden planlanarak öngörülmelidir. Söz konusu dönemler adına statik tanımlar yerine geçecek şekilde programlanmış kapasite değişimi stratejileri benimsemek gideri ciddi oranda kısabilir. Planlayıcı iş akışları hem de benzer mekanizmalar yoluyla akşam saatlerinde minimum güce geçiş sağlamak ise hem de performans bununla birlikte maliyet açısından kıymetli faydalar sağlayabilir.
Sıkça sorulan sorular ve yanıtlar hem de cevapları
K8s kota hususunda en çok soru edilen konulardan ilki requests ve sınırlar rakamlarının özdeş tutulup ayarlanmayacağıdır. Böyle bir tercih Guaranteed hizmet kalitesi düzeyini verir, fakat kaynak esnekliğini önemli oranda azaltabilir. Diğer bir yaygın soru bunun yanında kota aşıldığında ne yaşandığıdır. RAM kotası dolduğunda uygulama genellikle kapatılma durumuna geçer, İşlemci limiti aşıldığında fakat servis kısılır ama genellikle sonlandırılmaz. Böylece bu yüzden bellek alanı tavanlarının itinayla planlanması önemlidir.