Metrics Server ile Anlık Kaynak İzleme
Kubernetes kümelerinde kaynak limitleri her iş yükü için bellek tüketimini kontrol altında tutan kritik bir mekanizmadır. Bu ayarlar sayesinde bir uygulama cluster içindeki diğer uygulamaları etkilemeden çalışabilir. Sistem yöneticisi bu değerleri doğru tanımladığında atıl kaynaklar önlenir ve küme kararlılığı yükselir. Limit tanımlanmayan pod düğüm üzerindeki tüm serbest kaynakları tüketebilir, bu da yan iş yüklerinde performans düşüşüne yol açabilir. Kurumsal ortamlarda limitler zorunlu kabul edilir. Doğru planlama için önce uygulamanın ortalama ve zirve yük profili çıkarılmalıdır. Bu analiz ölçüm araçlarıyla sağlandığında sonuçlar daha tutarlı olur. Ayrıca ad alanı düzeyinde ResourceQuota ve sınır aralığı nesneleriyle varsayılan 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 kararlılığı birlikte sağlayan sürekli bir süreçtir.
Kubernetes'te istek değerleri ile limit değerleri arasındaki fark kaynak dağıtımının temelini oluşturur. İstekler, zamanlayıcının (scheduler) bir pod için ayırdığı minimum kaynak miktarıdır. Zamanlayıcı, düğüm seçerken bu değerlere bakar ve yalnızca yeterli boş kapasiteye sahip düğümlere yerleştirme yapar. Limitler ise bir pod'un aşamayacağı üst sınırı belirler. CPU için bu sınır aşıldığında konteyner yavaşlatılır, ancak kapatılmaz. Bellek için ise limit aşıldığında konteyner OOMKilled durumuna düşerek öldürülür. İstekler ile limits aynı değere eşitlendiğinde konteyner Guaranteed QoS sınıfına girer. Farklı miktarlar tanımlandığında Burstable 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 çıkarılma adayı olur. Dolayısıyla hangi sınıfın kullanılacağına iş yükünün önceliğine göre karar verilmelidir. Kritik veritabanları için garantili sınıf, batch işler için esnek sınıf tercih edilebilir. Her iki değerin da kavranması maliyet ve verim dengesini doğru kurmak için gereklidir.
CPU limitlerinin belirlenmesi servisin davranışına göre gerçekleştirilmelidir. İşlemci birimi millicore cinsinden ifade edilir ve 1000m değeri tek bir çekirdeğe karşılık gelir. İlk olarak uygulamanın boşta ve zirve trafik altındaki işlemci kullanımı kaydedilmelidir. Prometheus gibi izleme sistemleriyle alınan metrikler p99 persentil değerleri üzerinden değerlendirilir. Sınır değeri genellikle bu zirve tüketimin biraz yukarısında tutulur. Çok düşük bir limit gecikmelere ve kuyruk sürelerinin artmasına neden olur. Çok yüksek 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 esneklik sağlasa da komşu iş yüklerinde sorunlu etkilere neden olabilir. Yük ortamlarında farklı limit seviyeleri denenerek ideal nokta bulunmalıdır. Bu aşamada gerçek trafik senaryoları kullanıldığında sonuçlar önemli ölçüde anlamlı olur. Son olarak limitler, uygulama sürümleri güncellendikçe tekrar gözden geçirilmelidir.
Bellek limitlerinin hesaplanması CPU'ya göre daha hassas bir süreçtir, çünkü bellek sıkıştırma yapılamaz bir kaynaktır. Limit aşıldığında işletim OOM Killer çalışır ve konteyneri sonlandırır. Dolayısıyla bellek limiti konservatif ama isabetli ayarlanmalıdır. Hesaplamaya başlamadan önce uygulamanın heap ve yığın bellek kullanımı detaylı incelenmelidir. Java tabanlı servislerde heap ayarı ile konteynerin toplam belleği arasında makul 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 yüzden sürekli izleme ile kullanım grafiği incelenmelidir. Kubernetes içinde çalışma kümesi bellek metriği gibi metrikler, fiili kullanımı isabetli gösterir. Sınır değeri çoğunlukla zirve tüketimin yüzde on beş fazlasında tutulur. Fakat aşırı büyük limitler node belleğinin boşa edilmesine yol açar. Ortam değişkenleri farklılaştıkça hesaplamanın tekrar yapılması önerilir.
Kaynak isteklerinin isabetli ayarlanması, küme zamanlamasının verimli çalışması için vazgeçilmezdir. Requests değeri gereğinden az tanımlandığında 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 gerçekte kullanılmasa bile kapasitesi tükenmiş görünür. Bu durum cluster kullanım oranını düşürür ve fazla bulut maliyeti oluşturur. Sağlıklı bir ilk değer için geçmiş metrikler değerlendirilmeli ve ortalama kullanım seviyesine yakın bir istek tanımlanmalıdır. Vertical Pod Autoscaler örneğin mekanizmalar öneri sunabilir ve bu öneriler ilk yapılandırma için değerlendirilebilir. Yatay pod ölçekleyici ile birlikte kullanılırken çatışmalara dikkat edilmelidir. Ayrıca namespace seviyesinde sınır aralığı tanımlandığında eksik istekler otomatik atanabilir. Düzenli gözden geçirme ile değerler iş yükü 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 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 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 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 sorunsuz ç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 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ı 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 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ü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ı oluşturulabilir. Bu esneklik, kaynak yönetimini hem kolaylaştırır 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 geri çevrilir. 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 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 temel 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ı raporlar, böylece ekipler değişiklikleri kendi kontrolüne 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 özen gösterilmelidir. 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 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 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 optimize hale gelir.
Kümelenmiş uygulama kaynak kotaları ne şekilde planlanır
K8s çok düğümlü sistemlerde kaynak limitlerini doğru ayarlamak sistem sağlığı açısından önemli bir etki oynar. Requests ile limits kavramları arasında ayrışma tam kavranmadan hazırlanan tanımlamalar verimsizliğe neden açabilir. Planlayıcı katmanı istek miktarlarına bağlı olarak pod yerleştirmesi sağlar. Sınırlar fakat çalıştırma anında işletilir. İlk adım anlamında her bir servis için izlenmiş veriler belirlemek, Prometheus gibi araçlarla gerçek tüketim ölçümlerini incelemek en sağlıklı yöntemdir.
Sık rastlanan pürüzler nelerdir
Kaynak konusunda en çok görülen aksaklıklardan biri tanımların asla ayarlanmamasıdır. Bu şekilde bir kümede tek bir pod tüm node kaynağını kullanabilir ve kalan servisleri durdurabilir. İkinci yaygın yanlış buna karşın istek tanımlarını gereğinden düşük seçmektir. Böylece koşulda pod sunucuya gereğinden fazla atanır, ve bu işlemci yükü ile OOMKilled olaylarına yol yol açabilir. Üçüncü yanlış de her iş yüklerine aynı kotaları atamak. Her bileşenin ayrı yük karakteri göz önüne alınmadan hatırlanmalıdır.
Deneyimli tavsiyeler ve kaynak yönetimi iyileştirmesi
Uzman operatörler çoğu zaman kaynak planlaması bağlamında şu stratejiyi benimser: İlk olarak iş yükü ölçümleri çalıştırılır ve elde veriler temelinde istek miktarları olağan kullanımın bir miktar üstüne ayarlanır. Sınırlar tanımları oysa maksimum yükü yeterli olacak ölçüde seçilmelidir. CPU adına limit koymak bazen anlamsız sınırlamalara kapı yaratabildiğinden itinalı hareket edilmelidir. VPA birlikte Yatay ölçekleme aracı benzeri bileşenler dahi bu sürecte tanımların süreç içinde ayarlanmış konuma dönüşmesinde işe yarar olabilir.
Kaynak maliyeti ve masraf yönetimi
Kubernetes altyapısında kota yapılandırmaları bizzat bulut faturasına etki eder. Fazla geniş sınır belirlenmiş bir tür cluster kullanılmadan duran kullanılmayan güce harcama ödenmesine yol açabilir. Bu olgu sebeple birim maliyet planlarını belirgin biçimde belirlemeli ve sınır seçimlerini bu öngörülerle tutarlı duruma getirilmelidir. Gider gözlem sistemleri birlikte isim alanı ölçeğinde raporlama gerçekleştirmek de hangi tür bileşenin ne kapasite tükettiğini kavramayı mümkün kılar.
Periyodik trafik hem de planlama stratejileri
Çeşitli kurumsal sistem yıl süresince düzensiz bir tür talep davranışına göre şekillenir. Satış dönemleri, hesap kesimi dönemleri veya dönemsel etkinlikler süresince yük projeksiyonları baştan tahmin edilmelidir. Böyle aralıklar için sabit limitler yerine olarak ayarlanmış büyütme politikaları uygulamak maliyeti dikkat çekici boyutta azaltabilir. Zamanlanmış görev görevleri ile muadil mekanizmalar yoluyla akşam dönemlerinde minimum kaynağa değişim uygulamak bunun yanında aynı zamanda hız bununla birlikte bütçe açısından kıymetli faydalar doğurabilir.
Tipik karşılaşılan sorular hem de çözümleri
Kubernetes kaynak meselesinde en çok ilgi yöneltilen sorulardan biri requests ve sınırlar rakamlarının tek tutulup ayarlanmayacağıdır. Bu tür seçim Kesin QoS sınıfını oluşturur, ancak kaynak kullanımı esnekliğini önemli boyutta sınırlayabilir. Bir diğer sorgu bunun yanında limit tavana ulaşıldığında hangi tür ortaya çıktığıdır. RAM tavanı geçildiğinde pod genellikle OOMKilled kaderine geçer, İşlemci limiti aşıldığında ancak uygulama kısıtlanır fakat çoğu zaman durdurulmaz. Böylece nedenle bellek kotalarının titizlikle tanımlanması gerekir.