CPU Shares ve CFS Quota Mekanizmalarının Pratik Farkları |
Namespace Bazında ResourceQuota Tanımlama
Kubernetes kümelerinde kaynak limitleri her iş yükü için bellek tüketimini denetim altında tutan önemli bir mekanizmadır. Bu yapılandırmalar sayesinde bir uygulama kümedeki diğer uygulamaları etkilemeden işlevini sürdürebilir. Yönetici bu değerleri doğru tanımladığında boşa harcanan kapasite önlenir ve küme kararlılığı yükselir. Limit tanımlanmayan pod düğüm üzerindeki tüm boş kaynakları kullanabilir, bu da yan iş yüklerinde gecikmelere yol açabilir. Üretim ortamlarda limitler olmazsa olmaz kabul edilir. Doğru yapılandırma için önce uygulamanın ortalama ve maksimum yük profili incelenmeli. Bu analiz izleme araçlarıyla gerçekleştirildiğinde sonuçlar daha tutarlı olur. Ayrıca namespace düzeyinde kota ve sınır aralığı nesneleriyle genel değerler tanımlanabilir. Böylece ekipler kendi iş yükleri için standart sınırlarla hareket eder. Sonuç olarak limit yönetimi, kapasite kontrolü ile güvenilirliği birlikte sağlayan sürekli bir uygulamadır.
Kubernetes'te istek değerleri ile limits arasındaki fark 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. 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 konteynerin geçemeyeceği üst sınırı belirler. CPU için bu sınır aşıldığında konteyner kısılır, ancak kapatılmaz. RAM için ise limit aşıldığında süreç OOMKilled hatasına düşerek sonlandırılır. İstekler ile limitler aynı miktara eşitlendiğinde konteyner Guaranteed hizmet kalitesi sınıfına dahil olur. Farklı miktarlar tanımlandığında Burstable sınıf oluşur. Hiçbir sınır tanımlanmadığında BestEffort sınıfı söz konusu olur ve bu konteyner kaynak baskısında ilk çıkarılma adayı olur. Bu nedenle hangi tür sınıfın seçileceğine 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 miktarın da kavranması maliyet ve verim dengesini doğru kurmak için gereklidir.
CPU limitlerinin belirlenmesi servisin davranışına bağlı olarak yapılmalıdır. İşlemci birimi milicpu cinsinden ifade edilir ve 1000m değeri tek bir çekirdeğe karşılık gelir. İlk olarak uygulamanın sakin ve zirve yük altındaki CPU kullanımı ölçülmeli. Prometheus gibi izleme sistemleriyle alınan veriler p95 yüzdelik 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 uzamasına neden olur. Gereksiz geniş bir limit ise cluster kapasitesinin boşa kullanılmasına yol açar. Birçok ekip CPU limitini tamamen kaldırıp yalnızca requests değerine güvenir. Bu yaklaşım boş kapasite kullanımı 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 süreçte üretime yakın trafik örnekleri kullanıldığında sonuçlar önemli ölçüde anlamlı olur. Son olarak limitler, servis sürümleri değiştikçe tekrar değerlendirilmelidir.
Bellek limitlerinin belirlenmesi 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 kernel OOM Killer devreye girer ve süreci öldürür. Bu nedenle bellek limiti konservatif ama gerçekçi belirlenmelidir. Hesaplamaya başlamadan önce uygulamanın yığın ve yığın bellek kullanımı ayrıntılı analiz edilmelidir. JVM tabanlı uygulamalarda heap ayarı ile konteynerin toplam RAM'i arasında dengeli bir boşluk bırakılmalıdır. Node.js ve Python uygulamalarında bellek sızıntıları zamanla limit aşımına 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 örneğin metrikler, gerçek kullanımı doğru yansıtır. Sınır değeri çoğunlukla zirve tüketimin yüzde yirmi üzerinde tutulur. Fakat aşırı büyük limitler düğüm belleğinin israf edilmesine neden olur. Ortam koşulları değiştikçe hesaplamanın yeniden yapılması tavsiye edilir.
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ı yoğun düğümlere yerleştirir, bu da performans sorunlarına neden olur. Gereğinden fazla tanımlandığında ise düğümler gerçekte kullanılmasa bile dolu gözükür. Bu durum küme kullanım oranını düşürür ve gereksiz altyapı harcaması doğurur. Doğru bir başlangıç için tarihsel metrikler değerlendirilmeli ve medyan kullanım seviyesine yakın bir istek tanımlanmalıdır. Vertical Pod Autoscaler gibi araçlar öneri üretebilir ve bu tavsiyeler ilk ayar için değerlendirilebilir. Horizontal Pod Autoscaler ile beraber kullanılırken çakışmalara özen gösterilmelidir. Bunun yanında ad alanı seviyesinde sınır aralığı kurulduğunda unutulmuş istekler otomatik atanabilir. Düzenli gözden geçirme ile ayarlar uygulama değişimlerine paralel tutulmalıdır.
Kubernetes kümelerinde kaynak limitlerini doğru belirlemek için öncelikle QoS sınıflarını derinlemesine anlamak gerekir. Bir pod Guaranteed 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 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 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 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 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 ö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 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ı 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 esas alınmalıdır. Fazla sıkı kotalar dağıtımları durdurabilir, 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ı 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 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 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 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 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 performans hem de güvenilirlik açısından optimize hale gelir.
K8s kaynak limitleri nasıl belirlenir
K8s kümelerinde pod başına kotaları isabetli ayarlamak performans açısından temel bir öneme sahip etki taşır. Requests ile limits kavramları arasındaki fark iyi anlaşılmadan yapılan ayarlar sorunlara kapı açabilir. Scheduler modülü requests rakamlarına bakarak kapsül dağıtımı gerçekleştirir. Sınırlar ise çalışma anında işletilir. Temel adım şeklinde bütün konteyner için ölçülmüş ölçümler hesaplamak, Prometheus benzeri yöntemlerle gerçek harcama ölçümlerini incelemek çok sağlıklı yöntemdir.
Sıkça karşılaşılan hatalar nelerden ibarettir
Kaynaklar alanında en ortaya çıkan aksaklıklardan ilk sırada tanımların hiç ayarlanmamasıdır. Bu şekilde bir tür kümede tek kapsül tüm makine kaynağını kullanabilir hem de kalan servisleri olumsuz etkileyebilir. Bir diğer tipik hata de istek değerlerini olması gerekenden düşük ayarlamaktır. Bu durumda ortamda iş yükü sunucuya fazla atanır, bunun sonucunda işlemci tıkanıklığı ile kapanma durumlarına kapı doğurur. Üçüncü yanılgı bunun yanında bütün iş yüklerine standart kotaları uygulamak. Tüm uygulamanın ayrı tüketim profili olduğu göz ardı edilmemelidir.
Tecrübeli öneriler ile kaynak yönetimi düzenlemesi
Uzman mühendisler çoğunlukla kaynak alanında önemli metodu benimser: Öncelikle iş yükü sınamaları yapılır ve elde bulgular ölçüsünde requests rakamları ortalama yükün hafifçe yukarısına konumlandırılır. Sınırlar tanımları ancak maksimum kullanımı yeterli olacak ölçüde tanımlanmalıdır. CPU bakımından sınır belirlemek ara sıra gereksiz sınırlamalara kapı açabildiğinden özenli olunmalıdır. Otomatik dikey ölçekleyici birlikte Yatay ölçekleyici ör. sistemler ayrıca bu ayarların zamanla dengeli konuma gelmesinde yararlı sonuç verir.
Kaynak bütçesi ile maliyet yönetimi
K8s ortamlarında kaynak tanımları bizzat sanal harcamasına yansıtılır. Olması gerekenden kapsamlı kaynak talebi belirlenmiş bir çeşit cluster kullanılmadan kalan atıl kaynağa harcama ödenmesine sebep doğurur. Bu olgu sebeple takım bütçe planlarını net olarak ortaya koymalı hem de kaynak planlaması belirlemelerini bu doğrultuda amaçlarla bağdaşan duruma getirmeli. Masraf kontrol mekanizmaları ile isim alanı bazında analiz yapmak de hangi bileşenin ne güç ayırdığını kavramayı kolaylaştırır.
Mevsimsel trafik hem de planlama yöntemleri
Çeşitli işletmesel uygulama dönem boyunca oynak bir çeşit trafik eğilimine sahiptir. Promosyon dönemleri, hesap kesimi dönemleri ya da mevsimlik etkinlikler esnasında kaynak projeksiyonları önceden planlanarak öngörülmelidir. Bu dönemler adına sabit kotalar yerine koyarak zamanlanmış kapasite değişimi yöntemleri tercih etmek gideri kayda değer ölçüde düşürebilir. Zamanlanmış görev iş akışları ile muadil çözümler aracılığıyla gece vakti dönemlerinde minimum kaynağa dönüş gerçekleştirmek ise ek olarak verim bununla birlikte bütçe bakımından faydalı getiriler ortaya koyabilir.
Tipik karşılaşılan sorular ile yanıtları
Kubernetes kaynak limiti meselesinde en merak yapılan sorulardan bir tanesi requests ile sınırlar miktarlarının eşit tutulup belirlenmeyeceğidir. Söz konusu yaklaşım Kesin hizmet düzeyi grubunu verir, ancak kaynak uyumluluğunu ciddi ölçüde kısıtlayabilir. Öteki diğer merak ayrıca tavan tavana ulaşıldığında hangi tür olduğudur. Bellek alanı kotası dolduğunda servis çoğunlukla OOMKilled konumuna düşer, İşlemci sınırı geçildiğinde oysa servis frenlenir ancak çoğu zaman durdurulmaz. Bu ayrım nedenle RAM limitlerinin özenle ayarlanması gerekir.