Kubernetes üzerinde çalışan bir SaaS uygulaması yavaşladığında ilk öneri çoğu zaman yeni node eklemektir. Oysa sorun, cluster’ın toplam kapasitesinden önce podların yanlış tanımlanan CPU ve bellek bütçeleri olabilir. Fazla yüksek requests değerleri boş kapasiteyi kullanılamaz gösterirken, dar CPU limitleri yoğun anlarda gecikmeyi artırabilir. Bu rehber Kubernetes requests ve limits ayarlarını maliyet, performans ve operasyon kanıtı üzerinden değerlendirmek isteyen teknik ekipler içindir; amaç ezber bir YAML dağıtmak değil, doğru karar sürecini kurmaktır.

Requests yerleşimi, limits çalışma sınırını etkiler

Standart container kaynak tanımlarında scheduler, podu yerleştirirken requests değerlerini dikkate alır. Request, uygulamanın her an o kadar kaynak tükettiği anlamına gelmez; yerleşim hesabında kullanılan kaynak talebidir. CPU request, çekişme sırasında CPU payını da etkileyebilir. Limit ise çalışma zamanındaki kısıtlamaya yöneliktir. CPU limiti uygulamayı kısıtlayabilir; bellek sınırının aşılması ise container’ın OOM nedeniyle sonlandırılmasıyla sonuçlanabilir. İki kaynak türü aynı davranışı göstermez.

Bu ayrım bütçe görüşmesinde kritiktir. Kullanımı düşük görünen node üzerinde yeni podun Pending kalması çelişki olmayabilir: mevcut podların talep ettiği kaynaklar yerleşim kapasitesini doldurmuştur. Öte yandan çalışan podun daha fazla CPU kullanamaması, node’un tamamen dolu olduğu anlamına gelmeyebilir. Önce requests toplamını, gerçek tüketimi ve limit kaynaklı kısıtlamayı ayrı görünümlerde inceleyin.

Ölçüm penceresine yoğun iş saatlerini de katın

Sadece gece ölçülen kaynak kullanımıyla üretim bütçesi belirlenmez. Trafiğin arttığı saatler, toplu işlemler, raporlama, deploy sonrası ısınma ve cron işleri temsilî gözleme dâhil edilmelidir. Ortalama CPU, kısa ama kullanıcıyı etkileyen darboğazları saklayabilir. Bellekte ise uygulamanın çalışma kümesi, önbellek davranışı ve zaman içinde büyüme eğilimi incelenmelidir. Tek bir ekran görüntüsü, kalıcı boyutlandırma kararı için yeterli değildir.

• Uygulama gecikmesini ve hata oranını kaynak ölçümleriyle aynı zaman çizgisinde izleyin.
• CPU tüketimini, throttling sinyalini ve request/limit tanımlarını birlikte görün.
• Bellek kullanımı, OOMKilled kayıtları ve yeniden başlama sayılarını eşleştirin.
• Rollout sırasında aynı anda çalışan ek podların kaynak talebini kaydedin.
• Node’un toplam donanımı yerine podlara ayrılabilir kapasiteyi esas alın.

CPU throttling varsa önce nedenini ayırın

CPU limiti, container’ın kullanabileceği işlemci zamanını kısıtlayabilir. Bu durumda sunucuda boş CPU görünse bile uygulamanın yanıt süresi uzayabilir. Ancak her throttling sinyali kullanıcı etkisi yaratmaz; kısa çalışma patlamaları ile kalıcı performans sorunu farklıdır. Metrikleri uygulamanın gecikme yüzdelikleri, kuyruk bekleme süresi ve iş tamamlama oranıyla ilişkilendirin. Kaynak ölçümü tek başına hizmet kalitesi kanıtı değildir.

İlk adım limiti gelişigüzel kaldırmak olmamalıdır. Paylaşılan ortamlarda komşu iş yüklerini korumak, maliyet kontrolü ve namespace politikaları önemlidir. Temsilî yük altında kontrollü limit değişikliği yapın; gecikme düzeliyor mu, tüketim nereye çıkıyor, diğer uygulamalar etkileniyor mu gözleyin. Bazı iş yüklerinde daha esnek CPU sınırı uygun olabilir; karar ölçüm ve izolasyon gereksinimine dayanmalıdır.

Bellek limiti için aynı reçeteyi kullanmayın

CPU’ya uygulanabilen esneklik bellek için aynı güvenceyi vermez. Bellek sınırına yaklaşan uygulama garbage collection baskısı yaşayabilir veya sınırı aştığında sonlandırılabilir. Yeni pod açılması hizmetin otomatik düzeldiği anlamına gelmez; ısınma süresi ve tekrar eden bellek baskısı kesinti döngüsü oluşturabilir. Önce bellek sızıntısı, uygunsuz önbellek büyümesi ve eşzamanlı iş sayısı gibi uygulama kaynaklı nedenleri araştırın.

Request çok düşük seçildiğinde scheduler daha fazla iş yükünü aynı node’a sığdırabilir. Hepsi yoğunlaştığında node bellek baskısı oluşabilir. Request ve limit arasındaki fark bu nedenle “ücretsiz kapasite” değildir. Bellek ayarlarını uygulama davranışı, node rezervleri ve diğer podların yoğunluklarıyla birlikte planlayın. OOM kaydını yalnızca altyapı paketi yetersizliği diye etiketlemek, uygulamadaki kök nedeni gözden kaçırabilir.

HPA hedefleri requests değerlerinden etkilenebilir

HPA CPU kullanım yüzdesini request’e göre hesaplayan bir hedef kullanıyorsa, request değişikliği ölçekleme davranışını da değiştirir. Aynı tüketimde request’i düşürmek daha yüksek kullanım oranı gösterebilir; yükseltmek bunun tersini yapabilir. Bu yüzden kaynak bütçesi ile otomatik ölçekleme ayarları ayrı ekiplerin bağımsız değişiklikleri olmamalıdır. Kullanılan HPA metriğinin request’e bağlı olup olmadığını açıkça kaydedin.

Kuyruk uzunluğu veya iş gecikmesi gibi farklı metrikler kullanılıyorsa yorum da değişir. Her uygulamaya CPU tabanlı HPA eklemek, darboğazı veritabanında olan servisi düzeltmeyebilir. Ölçeklenen pod sayısının bağlantı havuzu, harici API kotası ve depolama üzerinde yaratacağı etki ayrıca değerlendirilmelidir. Çok pod, her zaman daha yüksek iş kapasitesi değildir.

Yeni node kararından önce kaynak bütçesi çıkarın

Node maliyetini yalnız mevcut pod sayısına bölmek yanıltıcıdır. Requests toplamı, gerçek pik tüketim, sistem bileşenleri, rollout fazlalığı ve bakım sırasında ihtiyaç duyulan yedek alan ayrı yazılmalıdır. Bir node bakımdayken kritik iş yükleri kalan kapasitede çalışabiliyor mu? Bu soru requests değerlerini sınırsız düşürerek değil, kontrollü yerleşim ve yük testiyle yanıtlanmalıdır.

Önce gereksiz yüksek talepleri azaltmak bazen büyüme ihtiyacını öteleyebilir. Ancak maliyet düşüşü garanti değildir: cluster sözleşmesi, minimum node düzeni ve yüksek erişilebilirlik gereksinimi bütçeyi belirler. Kubernetes Cluster Hosting değerlendirmesinde donanım kadar uygulamaların kaynak profilleri de paylaşılmalıdır. Böylece teklif yalnız tahmine değil, operasyon ihtiyacına dayanır.

Kaynak değişikliğini küçük ve geri alınabilir yapın

Aynı anda request, limit, replika sayısı ve HPA hedefini değiştirmek sonucu yorumlamayı zorlaştırır. Tek iş yükünden başlayın; önce mevcut tanımı sürüm kontrolünde saklayın. Test ortamındaki gözlemi production’ın daha küçük bir bölümünde doğrulayın. Uygulama gecikmesi veya hata oranı kabul sınırını aşarsa hangi manifest sürümüne dönüleceği belli olsun. Değişiklik kaydına yalnız yeni YAML değil, öncesi ve sonrası ölçüm de ekleyin.

Namespace seviyesindeki ResourceQuota ve LimitRange kurallarını ayrıca kontrol edin. Bildiğiniz container tanımı, varsayılanlar veya admission politikaları nedeniyle farklı çalışıyor olabilir. Manifest dosyasıyla yetinmeyip çalışan podun etkin kaynak tanımlarını okuyun. Özel kaynaklar, init container’lar veya pod seviyesindeki özellikler kullanılıyorsa standart container hesabının ötesinde sürüme uygun inceleme yapılmalıdır.

Teknik ve finans ekipleri için kabul listesi

• Yoğun saatler ve deploy anları ölçüm penceresinde temsil edildi.
• Requests, limits ve gerçek kullanım ayrı raporlandı.
• Throttling veya OOM kaydı kullanıcı etkisiyle ilişkilendirildi.
• HPA hedeflerinin kaynak değişikliğinden nasıl etkilendiği belirlendi.
• Bakım ve rollout için yeterli yedek kapasite bırakıldı.
• Değişikliğin performans sonucu ve geri dönüş adımı kaydedildi.

Kaynak planını sürekli ölçüm ve kontrollü değişikliklerle yürütmek için DevOps hizmeti kapsamını ayrıca değerlendirebilirsiniz. Kubernetes kaynak bütçenizi ve büyüme ihtiyacınızı birlikte gözden geçirelim. Mevcut node düzeni, kritik uygulamalar ve yoğun saat ölçümleri ilk teknik görüşmenin verimli başlamasını sağlar; özel izleme ve optimizasyon kapsamı görüşmede netleştirilir.