Kubernetes Kümelerinde Kaynak Limitleri Nasıl Belirlenir
Kubernetes kümelerinde kaynak sınırları her pod için bellek tüketimini sınırlar içinde tutan temel bir mekanizmadır. Bu yapılandırmalar sayesinde bir uygulama kümedeki diğer bileşenleri etkilemeden işlevini sürdürebilir. Sistem yöneticisi bu değerleri dengeli tanımladığında boşa harcanan kapasite önlenir ve cluster kararlılığı yükselir. Limit tanımlanmayan pod düğüm üzerindeki tüm boş kaynakları tüketebilir, bu da yan iş yüklerinde gecikmelere yol açabilir. Kurumsal ortamlarda limitler vazgeçilmez kabul edilir. Doğru planlama için önce uygulamanın ortalama ve zirve yük profili çıkarılmalıdır. Bu analiz metrik araçlarıyla yapıldığında sonuçlar daha tutarlı olur. Ayrıca ad alanı düzeyinde ResourceQuota ve sınır aralığı nesneleriyle genel değerler belirlenebilir. Böylece ekipler kendilerine ait iş yükleri için standart sınırlarla hareket eder. Sonuç olarak limit yönetimi, kapasite kontrolü ile güvenilirliği birlikte destekleyen sürekli bir uygulamadır.
Kubernetes'te istek değerleri ile limits arasındaki fark kaynak dağıtımının temelini oluşturur. Requests, zamanlayıcının (scheduler) bir pod için garanti ettiği minimum kaynak miktarıdır. Zamanlayıcı, node seçerken bu istek miktarlarına bakar ve yalnızca yeterli serbest kapasiteye sahip düğümlere yerleştirme yapar. Limits ise bir pod'un geçemeyeceği üst sınırı belirler. İşlemci için bu sınır aşıldığında süreç kısılır, ancak sonlandırılmaz. Bellek için ise limit aşıldığında süreç OOMKilled hatasına düşerek öldürülür. İstekler ile limits aynı miktara 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 BestEffort sınıfı geçerli olur ve bu konteyner 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 önceliğine göre karar verilmeli. Önemli veritabanları için garantili sınıf, batch işler için esnek sınıf tercih edilebilir. Her iki değerin da anlaşılması maliyet ve verim dengesini doğru kurmak için şarttır.
CPU limitlerinin belirlenmesi iş yükünün davranışına bağlı olarak gerçekleştirilmelidir. CPU birimi millicore cinsinden ifade edilir ve 1000m değeri tek bir core'a karşılık gelir. İlk olarak uygulamanın düşük yük ve zirve yük altındaki işlemci kullanımı ölçülmeli. Prometheus gibi izleme sistemleriyle alınan veriler p95 persentil değerleri üzerinden yorumlanır. Limit değeri genellikle bu zirve tüketimin biraz üzerinde tutulur. Çok düşük bir limit gecikmelere ve bekleme sürelerinin artması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 dayanır. Bu yaklaşım esneklik sağlasa da diğer iş yüklerinde gürültülü etkilere neden olabilir. Yük ortamlarında çeşitli limit değerleri denenerek en uygun nokta tespit edilmelidir. Bu aşamada gerçek trafik örnekleri kullanıldığında sonuçlar çok daha değerli olur. Son olarak limitler, uygulama sürümleri değiştikçe tekrar gözden geçirilmelidir.
Bellek limitlerinin belirlenmesi CPU'ya göre daha kritik bir konudur, çünkü bellek sıkıştırılamaz bir kaynaktır. Limit aşıldığında kernel OOM Killer devreye girer ve konteyneri öldürür. Dolayısıyla RAM limiti konservatif ama gerçekçi ayarlanmalıdır. Hesaba başlamak uygulamanın heap ve stack tüketimi ayrıntılı analiz edilmelidir. JVM tabanlı uygulamalarda heap boyutu ile konteynerin toplam belleği arasında dengeli bir boşluk bırakılmalıdır. Node ve Python uygulamalarında bellek sızıntıları uzun süre çalıştıkça limit ihlaline yol açabilir. Bu sebeple sürekli izleme ile kullanım grafiği incelenmelidir. Küme içinde çalışma kümesi bellek metriği gibi metrikler, fiili kullanımı doğru yansıtır. Sınır değeri genellikle zirve tüketimin yüzde yirmi üzerinde tutulur. Ancak aşırı büyük limitler node belleğinin boşa edilmesine neden olur. Ortam değişkenleri değiştikçe hesaplamanın tekrar yapılması tavsiye edilir.
Kaynak isteklerinin doğru ayarlanması, küme 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 neden olur. Çok yüksek tanımlandığında ise düğümler gerçekte kullanılmadığı halde bile dolu görünür. Bu durum cluster kullanım oranını düşürür ve fazla bulut harcaması oluşturur. Sağlıklı bir ilk değer için geçmiş metrikler değerlendirilmeli ve medyan kullanım değerine yakın bir istek tanımlanmalıdır. Dikey pod ölçekleyici örneğin araçlar öneri sunabilir ve bu öneriler başlangıç yapılandırma için değerlendirilebilir. Horizontal Pod Autoscaler ile beraber kullanılırken çakışmalara özen edilmelidir. Ayrıca namespace seviyesinde LimitRange tanımlandığında unutulmuş istekler otomatik doldurulabilir. Düzenli değerlendirme ile değerler iş yükü değişimlerine uyumlu 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 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 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 sık rastlanan 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 kaldırabilecek ş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 ö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ı minimize edilebilir. 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 engeller. Bu yaklaşım, aşırı kaynak tahsisini önler 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 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ı 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 reddedilir. 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 temel 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 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ı 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ü 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 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ı engeller. 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 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 ayarlanması 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 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 performans hem de güvenilirlik açısından dengeli hale gelir.
K8s kaynak limitleri ne şekilde belirlenir
Kubernetes çok düğümlü sistemlerde konteyner kısıtlarını dengeli yapılandırmak kararlılık bakımından kritik bir görev sağlar. İstekler ile sınırlar kavramları arasındaki ayrışma açık özümsenmeden tasarlanan konfigürasyonlar beklenmedik durumlara yol açar. Scheduler modülü requests tanımlarına göre kapsül yerleştirmesi yapar. Limits oysa çalışma sürecinde devreye girer. Temel adım anlamında her konteyner açısından ölçülmüş veriler hesaplamak, Prometheus örneğin çözümlerle anlık yük kayıtlarını toplamak son derece doğru yoldur.
Sık karşılaşılan sorunlar nelerdir
Kaynaklar meselesinde en sık ortaya çıkan aksaklıklardan biri sınırların hiçbir zaman girilmemesidir. Bu durumda bir tür sistemde bir konteyner tüm makine kapasitesini yiyebilir ile diğer uygulamaları etkileyebilir. Bir diğer yaygın yanılgı ise requests tanımlarını fazla alt tutmaktır. Bu durumda ortamda konteyner makineye fazla atanır, bu da işlemci sıkışıklığı hem de sonlandırma vakalarına yol doğurur. Son yanlış bunun yanında bütün iş yüklerine aynı kotaları tanımlamaktır. Her iş yükünün farklı yük profili olduğunu dikkate alınmalıdır.
Tecrübeli ipuçları ve sınır ayarı
Tecrübeli yöneticiler çoğunlukla kota konusunda şu stratejiyi kullanır: İlk olarak yük ölçümleri gerçekleştirilir sonrasında alınan sonuçlar ölçüsünde istek rakamları tipik yükün az yukarısına ayarlanır. Limits değerleri ise zirve tüketimi karşılayacak şekilde ayarlanmalıdır. İşlemci açısından sınır tanımlamak zaman zaman fazla darboğazlara neden açtığından itinalı davranılmalıdır. Vertical Pod Autoscaler birlikte HPA benzeri bileşenler da bu süreçte ayarların ilerleyen dönemde optimize konuma ulaşmasında faydalı destek olur.
Kaynak gideri ve maliyet planlaması
Kubernetes ortamlarında sınır yapılandırmaları doğrudan doğruya dijital giderine tesir eder. Gereğinden yüksek kaynak talebi belirlenmiş bir cluster atıl kalan kapasiteye harcama yapılmasına neden kapı açabilir. Bu sorun dolayısıyla birim harcama öngörülerini net biçimde çizmelidir ile kota kararlarını bu doğrultuda hedeflerle tutarlı hale dönüştürmelidir. Gider kontrol sistemleri birlikte namespace ölçeğinde değerlendirme yapmak bunun yanında hangi bileşenin ne kadar kaynak ayırdığını görmeyi sağlar.
Dönemsel talep ile vakit ayarı metotları
Çeşitli kurumsal uygulama dönem süresince oynak bir çeşit yük profiline sahiptir. İndirim dönemleri, hesap kesimi aralıkları ya da geçici olaylar esnasında kota öngörüleri önceden planlanarak hesaplanmalıdır. Bu tür aralıklar için statik sınırlar yerine geçecek şekilde ayarlanmış küçültme yöntemleri benimsemek maliyeti önemli oranda düşürebilir. Takvim tabanlı görevleri ve eşdeğer çözümler yoluyla akşam vakitlerinde az boyuta geçiş gerçekleştirmek ayrıca hem başarım hem de gider noktasında kıymetli kazanımlar doğurabilir.
Tipik sorulan sorular hem de açıklamaları
Kubernetes sınır hususunda en çok merak duyulan meselelerden ilk sırada istek ile limits değerlerinin aynı tutulması ayarlanmayacağıdır. Böyle bir seçim Guaranteed hizmet düzeyi sınıfını yaratır, ancak kapasite çevikliğini kayda değer oranda sınırlayabilir. Başka bir öteki merak de tavan kotaya dayanıldığında hangi tür gerçekleştiğidir. Bellek tavanı dolduğunda pod genellikle zorla sonlandırılma kaderine geçer, CPU kotası geçildiğinde ancak pod frenlenir fakat genellikle kapatılmaz. Bu sebeple bellek limitlerinin özenle ayarlanması önemlidir.