Uygulama Profiline Göre Başlangıç Değerleri
Kubernetes kümelerinde kaynak sınırları her konteyner için bellek tüketimini denetim altında tutan önemli bir mekanizmadır. Bu ayarlar sayesinde bir uygulama sistemdeki diğer uygulamaları etkilemeden hizmet verebilir. Operasyon ekibi bu değerleri doğru tanımladığında kaynak israfı önlenir ve cluster kararlılığı artar. Limit tanımlanmayan pod node üzerindeki tüm serbest kaynakları tüketebilir, bu da komşu iş yüklerinde gecikmelere 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 analiz edilmeli. Bu analiz izleme araçlarıyla sağlandığında sonuçlar çok daha güvenilir olur. Ayrıca ad alanı düzeyinde kota ve sınır aralığı nesneleriyle varsayılan değerler atanabilir. Böylece ekipler kendilerine ait iş yükleri için standart sınırlarla hareket eder. Sonuç olarak limit yönetimi, maliyet kontrolü ile kararlılığı birlikte sağlayan sürekli bir çalışmadır.
Kubernetes'te requests ile limits arasındaki ayrım kaynak planlamasının temelini oluşturur. İstekler, zamanlayıcının (scheduler) bir konteyner için garanti ettiği minimum kaynak miktarıdır. Zamanlayıcı, düğüm seçerken bu istek miktarlarına bakar ve yalnızca yeterli boş kapasiteye sahip node'lara yerleştirme yapar. Limits ise bir pod'un tavanı üst sınırı belirler. CPU için bu sınır aşıldığında süreç kısılır, ancak kapatılmaz. RAM için ise limit aşıldığında konteyner OOMKilled durumuna düşerek öldürülür. Requests 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 sınır tanımlanmadığında en iyi çaba sınıfı söz konusu olur ve bu konteyner kaynak baskısında ilk çıkarılma adayı olur. Bu nedenle hangi sınıfın kullanılacağına iş yükünün kritikliğine göre karar verilmeli. Önemli veritabanları için garantili sınıf, batch işler için Burstable sınıf tercih edilebilir. Her iki değerin da anlaşılması kapasite ve verim dengesini doğru kurmak için gereklidir.
CPU limitlerinin ayarlanması servisin davranışına göre yapılmalıdır. CPU birimi millicore cinsinden ifade edilir ve 1000m değeri tek bir çekirdeğe karşılık gelir. İlk olarak uygulamanın düşük yük ve yoğun yük altındaki CPU kullanımı ölçülmeli. Prometheus gibi izleme sistemleriyle alınan veriler p99 persentil değerleri üzerinden yorumlanır. Sınır değeri genellikle bu zirve tüketimin 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 cluster kapasitesinin boşa kullanılmasına sebep olur. Birçok ekip CPU limitini tamamen kaldırıp yalnızca istek değerine güvenir. Bu yaklaşım boş kapasite kullanımı sağlasa da diğer iş yüklerinde sorunlu etkilere neden olabilir. Yük ortamlarında farklı limit seviyeleri denenerek en uygun nokta bulunmalıdır. Bu süreçte üretime yakın trafik senaryoları 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 hesaplanması CPU'ya kıyasla daha hassas bir konudur, çünkü bellek sıkıştırma yapılamaz bir kaynaktır. Limit aşıldığında işletim OOM Killer devreye girer ve konteyneri öldürür. Dolayısıyla RAM limiti güvenli ama gerçekçi ayarlanmalıdır. Hesaba başlamak uygulamanın yığın ve yığın bellek tüketimi ayrıntılı incelenmelidir. Java tabanlı servislerde heap boyutu ile konteynerin toplam belleği arasında makul bir pay 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 yüzden sürekli izleme ile bellek eğrisi takip edilmelidir. Kubernetes içinde çalışma kümesi bellek metriği gibi metrikler, gerçek kullanımı doğru yansıtır. Sınır değeri genellikle zirve tüketimin yüzde on beş fazlasında tutulur. Ancak aşırı büyük limitler node belleğinin israf edilmesine yol açar. Üretim değişkenleri farklılaştıkça hesaplamanın yeniden yapılması önerilir.
Kaynak isteklerinin doğru ayarlanması, cluster planlamasının sağlıklı çalışması için vazgeçilmezdir. İstek değeri çok düşük tanımlandığında scheduler pod'u aşırı dolu düğümlere yerleştirir, bu da performans sorunlarına yol açar. Çok yüksek tanımlandığında ise düğümler gerçekte kullanılmasa bile dolu gözükür. Bu durum cluster verimliliğini düşürür ve gereksiz bulut harcaması oluşturur. Doğru bir başlangıç için geçmiş metrikler değerlendirilmeli ve ortalama kullanım değerine yakın bir istek belirlenmelidir. Vertical Pod Autoscaler örneğin araçlar öneri üretebilir ve bu tavsiyeler ilk yapılandırma için kullanılabilir. Horizontal Pod Autoscaler ile birlikte kullanılırken çatışmalara dikkat gösterilmelidir. Ayrıca namespace seviyesinde sınır aralığı tanımlandığında eksik istekler otomatik doldurulabilir. Periyodik değerlendirme ile değerler iş yükü değişimlerine paralel güncel tutulmalıdır.
Kubernetes kümelerinde kaynak sınırlarını doğru belirlemek için öncelikle QoS sınıflarını iyi anlamak gerekir. Bir pod Burstable 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 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 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 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 dikkate alınmalı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ü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 kolaylaştırır 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 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ı sınırlanabilir. Bir namespace kotası dolduğunda, yeni kaynak talepleri API sunucusu tarafından reddedilir. 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 reddedilir. 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ı kaybeder. 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 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 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 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 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 bağlı en güvenilir yöntemdir. Prometheus gibi araçlarla toplanan CPU ve bellek metrikleri, uygulamanın fiili 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 uygun 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 neden olabileceğ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 şekilde 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 CPU ve bellek sınırları nasıl belirlenir
K8s üretim altyapısında pod başına kotaları akılcı belirlemek hizmet kalitesi noktasında kritik bir öneme sahip unsur taşır. İstekler ile sınırlar ayarları arasındaki fark net anlaşılmadan yapılan yapılandırmalar verimsizliğe neden açabilir. Scheduler servisi istek tanımlarına bakarak konteyner konumlandırması yapar. Limits fakat çalıştırma zamanında işletilir. Ön hazırlık anlamında her bir pod bazında izlenmiş rakamlar tanımlamak, kubectl top benzeri yöntemlerle anlık harcama ölçümlerini toplamak oldukça sağlıklı yöntemdir.
Sıkça yapılan yanlışlar hangileridir
Kaynak meselesinde en çok karşılaşılan hatalardan ilki sınırların baştan tanımlanmamasıdır. Bu tür bir tür ortamda tek konteyner bütün sunucu kaynağını tüketebilir bununla birlikte diğer bileşenleri durdurabilir. İkinci görülen yanılgı buna karşın requests değerlerini gereğinden alt seçmektir. Bu senaryoda konteyner düğüme aşırı yüklenir, bu da işlemci tıkanıklığı hem de sonlandırma olaylarına yol açabilir. Bir başka yanılgı bunun yanında tüm iş yüklerine tek tip sınırları atamak. Her servisin ayrı tüketim profili bulunduğu hatırlanmalıdır.
Deneyimli püf noktaları ve kaynak yönetimi düzenlemesi
Uzman mühendisler çoğu zaman kaynak alanında önemli yaklaşımı uygular: Önce yük denemeleri uygulanır ardından elde ölçümler ışığında istek rakamları olağan kullanımın bir miktar ötesine konumlandırılır. Sınırlar değerleri fakat maksimum talebi karşılayacak şekilde seçilmelidir. İşlemci adına limit tanımlamak ara sıra gereksiz kısıtlamalara neden açabildiğinden itinalı olunmalıdır. Vertical Pod Autoscaler ile Yatay ölçekleme aracı ör. bileşenler da bu ayarların ilerleyen dönemde iyileştirilmiş biçime dönüşmesinde etkili olur.
Kaynak yönetimi harcaması hem de gider planlaması
K8s ortamlarında kota belirlemeleri bizzat bulut maliyetine yansıtılır. Gereğinden geniş kaynak talebi atanmış bir tür ortam boşta duran kapasiteye yatırım yapılmasına neden getirir. Bu durum dolayısıyla ekip maliyet öngörülerini net surette ortaya koymalı ile kaynak kararlarını bu çerçevede hedeflerle örtüşen duruma getirmeli. Masraf gözlem sistemleri ile küme bölümü ölçeğinde değerlendirme uygulamak de hangi uygulama bileşenin ne kaynak tükettiğini belirlemeyi olanak verir.
Periyodik iş yükü ve zamanlama yöntemleri
Pek çok ticari servis dönem süresince düzensiz bir kullanım profiline göre şekillenir. Satış aralıkları, faturalama dönemleri veya sezonluk programlar boyunca kota beklentileri baştan hesaplanmalıdır. Söz konusu aralıklar bakımından sabit limitler yerine planlanmış kapasite değişimi yaklaşımları uygulamak maliyeti dikkat çekici düzeyde kısabilir. Planlayıcı işleri hem de benzer çözümler üzerinden gece vakti dönemlerinde az boyuta değişim uygulamak ise hem hız bununla birlikte maliyet açısından değerli kazanımlar sağlayabilir.
Sıkça sorulan sorular ve yanıtlar ve yanıtları
K8s kota konusunda başlıca sorgulama yöneltilen sorudan bir tanesi requests hem de limits değerlerinin özdeş olup ayarlanmayacağıdır. Bu tercih Guaranteed servis sınıfı düzeyini yaratır, ama kapasite esnekliğini önemli oranda kısıtlayabilir. Öteki öteki sorgu de sınır aşıldığında ne yaşandığıdır. RAM kotası tükendiğinde pod çoğunlukla bellek yetersizliği nedeniyle sonlandırma konumuna düşer, İşlemci tavanı dolduğunda oysa servis yavaşlatılır ancak çoğunlukla öldürülmez. Bu fark dolayısıyla bellek alanı tavanlarının özenle planlanması şarttır.