Kubernetes v1.36 Pod-Level In-Place Resize: Beta’ya Yükseldi

Açık konuşayım: Kubernetes’te pod kaynaklarını canlı canlı değiştirmek, uzun süre “keşke olsa” dediğimiz işlerden biriydi. Şimdi geldi. Hem de pod seviyesinde, container’ı yeniden başlatmadan. v1.36 ile InPlacePodLevelResourcesVerticalScaling özelliği Beta’ya çıktı ve varsayılan olarak açık geliyor. Yanı upstream Kubernetes kullanıyorsanız, bu iş artık elinizin altında.

Şahsen, Geçen yıl v1.34’te Pod-Level Resources Beta olmuştu, v1.35’te In-Place Pod Vertical Scaling GA’ya çıkmıştı. Bu ikisinin birleşimi, v1.36’da ayrı bir alt yetenek olarak Beta seviyesine geldi. Kulağa biraz ağır geliyor, biliyorum. Ama kurumsal tarafta beklenen şey tam da buydu.

Pod seviyesinde resize neden bu kadar önemli?

Şöyle anlatayım. Klasik Kubernetes düzeninde her container’a ayrı CPU ve memory limiti veriyordunuz. Sonra sidecar pattern iyice yayıldı; service mesh, log forwarder, init container derken bir pod’da 4-5 container görmek sıradan hâle geldi. Her birine tek tek bütçe ayarlamak? İşte orada işler karışıyor.

Pod-level resources bu yükü hafifletmek için geldi. Bütün container’lar ortak — ki bu tartışılır — bir havuzdan besleniyor (şaşırtıcı ama gerçek). Hani aileye tek bir aylık bütçe vermek gibi; kim ne kadar harcarsa harcasın toplam çizgiyi aşmıyor. Logosoft’ta geçen sene bir e-ticaret müşterimizde Istio sidecar’larıyla uğraşırken bunu denemiştik — sonuç fena değildi, kaynak planlaması baya sadeleşti (ben de ilk duyduğumda şaşırmıştım)

Bak şimdi, Şimdi işin tadı biraz daha değişiyor: çalışan pod’un toplam bütçesini restart etmeden değiştirebiliyorsunuz. Black Friday gecesi pod öldürmeden ölçeklemek istemeyen var mı? Yok gibi.

Hangi senaryolarda gerçekten işe yarıyor?

Bireysel container limiti tanımlanmamış pod’larda bu özellik baya iş görüyor. Container’lar yeni pod-level sınırlara göre kendini ayarlıyor. Yanı peak demand gelince shared pool’u büyütüyorsunuz, sonra container başına tek tek hesap yapmıyorsunuz.

Şöyle ki, Bir de batch işleri var tabiî. Gece çalışan veri işleme job’larında sabit limit belirlemek hep zor öldü. Workload arttıkça pod-level limiti yukarı çekip, iş bitince geri indirebilirsiniz. Maliyet ve performans dengesi açısından kilit olan yer tam burası.

resizePolicy mekaniği: yeniden başlatma şart mı?

İşin can alıcı kısmına geldik şimdi. Kubelet bir pod-level resize talebi aldığında, bunu pod-level bütçeden pay alan her container için ayrı resize event gibi değerlendiriyor (en azından benim deneyimim böyle). Restart gerekip gerekmediğini anlamak için de container’ın resizePolicy ayarına bakıyor.

İki seçenek var:

• NotRequired: Kubelet, Container Runtime Interface (CRI) üzerinden cgroup limitlerini canlı canlı güncelliyor. Container restart yok, downtime yok.
• RestartContainer: Yeni sınırları güvenli şekilde uygulamak için container yeniden başlatılıyor. Stateful uygulamalarda veya JVM gibi başlangıçta heap ayarlayan runtime’larda bu daha mantıklı olabiliyor.

Aslında, Burada küçük ama önemli bir nokta var: resizePolicy şu an pod seviyesinde desteklenmiyor. Kubelet kararı neredeyse her zaman bireysel container ayarlarına göre veriyor. Yanı pod’a “bütün container’ları restart etme” diye toplu bir komut veremiyorsunuz. Bence bu eksik kalmış taraflardan biri; ileride düzelir mi, göreceğiz ama şimdilik akılda tutmak lazım.

JVM tabanlı uygulamalarda (Java, Kotlin, Scala) memory resize’ı NotRequired olarak işaretlemeyin. Heap zaten başlangıçta ayarlanıyor, çalışan JVM yeni cgroup limitini “görmüyor”. Restart şart.

Pratik örnek: shared pool’u canlıda büyütmek

Aslında, Diyelim ki elinizde bir pod var; toplamda 2 CPU ve 4Gi memory ile başlamış olsun. İçinde main-app ve sidecar var, ikisi de bireysel limit tanımlamamış durumda. Ortak havuzu paylaşıyorlar yanı.

Ve işler burada ilginçleşiyor.

apiVersion: v1
kind: Pod
metadata:
name: shared-pool-app
spec:
resources:
limits:
cpu: "2"
memory: "4Gi"
containers:
— name: main-app
image: my-app:v1
resizePolicy:
— resourceName: "cpu"
restartPolicy: "NotRequired"
— name: sidecar
image: logger:v1
resizePolicy:
— resourceName: "cpu"
restartPolicy: "NotRequired"

Küçük bir detay: CPU’yu 4’e çıkarmak için resize subresource’ünü kullanıyoruz:

kubectl patch pod shared-pool-app --subresource resize \
--patch '{"spec":{"resources":{"limits":{"cpu":"4"}}}}'

Hani, Bitti sayılır. Container’lar ayakta kalıyor, cgroup limitleri runtime tarafından dinamik güncelleniyor. İlk denediğimde test cluster’da bakmıştım — bu arada Mart 2026’da minikube ortamında deniyordum — patch attıktan sonra kubectl describe pod ile baktım, Status.Resources alanında yeni değerler anında görünüyordu. Conditions kısmında önce PodResizeInProgress, sonra da PodResizeCompleted çıkıyor.

Durun, bir saniye.

Node-level gerçeklik: feasibility ve güvenlik

Sadece patch atmakla olmuyor tabiî; hikâyenin başlangıcı orası sadece. Kubelet perde arkasında ciddi bir kontrol süreci yürütüyor. Bu kontrolleri bilmezseniz “neden olmadı?” diye loglara gömülürsünüz — ben yaşadım, o yüzden söylüyorum.

1. Feasibility check

Kubelet resize’ı kabul etmeden önce node’da yeterli kaynak var mı diye bakıyor. Yoksa Deferred durumuna giriyor; yanı “şimdilik olmaz, müsait olunca yaparım” diyor resmen. Eski sürümlerdeki gibi hata fırlatıp pod’u düşürmekten daha medeni dürüyor açıkçası.

2. Cgroup hierarchy güncellemesi

Linux’ta cgroup yapısı hiyerarşik çalışıyor ya, işte orada pod-level cgroup büyürken container-level cgroup’lar da ona uyum sağlıyor. Tabi cgroup v2 kullanıyorsanız süreç daha temiz ilerliyor. Hâlâ cgroup v1 tarafında takılıysanız (bazı kurumsal Linux dağıtımlarında 2024’e kadar gördüm bunu), önce migration işiyle uğraşmanız gerekiyor.

3. Atomicity garantisi

Tüm operasyon ya başarıyla tamamlanıyor ya da komple başarısız oluyor; ortada yarım yamalak bir durum kalmıyor; mesela CPU güncellendi ama memory takıldı gibi bir ara hâl yok (ki iyi de olmuş). Kurumsal ortamda aranan şeylerden biri bu zaten — tahmin edilebilir davranış istiyorsunuz.

Türkiye’deki kurumsal yapılar için ne anlama geliyor?

Gelelim biraz yerel tarafa bakalım şimdi de öyleyse? Türkiye’de Kubernetes adopsiyonu son 3-4 yılda ciddi yol aldı diyebilirim; bankalar, telkomlar, e-ticaret oyuncuları AKS, OpenShift veya self-managed cluster’larla çalışıyorlar. Çoğu ekip hâlâ static resource allocation kafasında gidiyor.

Hmm, bunu nasıl anlatsamdı…

Bunun sebeplerinden biri de FinOps kültürünün tam oturmamış olması bence. In-place resize burada devreye giriyor; HPA ile beraber ya da onun yerine VPA ile birlikte kullanıp pod kaynaklarını dinamik yöneterek %30-40 arası tasarruf görmek mümkün olabiliyor. Bir telekom müşterimizde geçen yıl yaptığımız proof of concept’te buna baya yaklaştık.

Peki enterprise ile startup ayrımı burada nerede çıkıyor? Tam burada çıkıyor aslında:

Neyse, küçük bir detay: Daha derinlemesine pod-level resource yönetimini merak ediyorsanız, Kubernetes v1.36 Pod-Level Resource Managers: Sidecar Derdi Bitiyor yazımda konuyu başka bir açıdan anlatmıştım.

Karsilasabileceginiz tipik sorunlar?

Sıkça Sorulan Sorular

In-place pod resize, HPA’nın yerini alıyor mu?

Hayır, aslında ikisi bambabamı farklı sorunları çözüyor. HPA yatay ölçekleme yapıyor — yanı pod sayısını artırıyor. In-place resize işe dikey ölçekleme, hani mevcut pod’un kaynaklarını olduğu yerde büyütüyor. Bence en güzel yanı da şu: genelde birlikte kullanılıyorlar. VPA ile entegre ettiğinizde özellikle çok güçlü bir kombinasyon çıkıyor ortaya.

Bu özellik AKS, EKS veya GKE’ye ne zaman geliyor?

Kubernetes v1.36 upstream’de Beta aşamasında. Managed servislerin v1.36’yı GA olarak sunması genelde 2-4 ay sürüyor (ciddiyim). Mesela AKS preview kanallarında bayağı erken görebilirsiniz, ama production stable kanalda biraz sabır gerekiyor. Açıkçası acele etmemek de mantıklı.

Pod restart olmadan resize her zaman mümkün mü gerçekten?

Hayır, her zaman değil. CPU resize çoğu durumda restart istemiyor, bu kısım genelde sorunsuz. Ama memory shrink veya (söylemesi ayıp) bazı runtime davranışları — hani JVM heap gibi şeyler — restart gerektirebiliyor. Bu yüzden resizePolicy‘yi container bazında doğru ayarlamak gerçekten kritik, atlamayın.

resize subresource için hangi RBAC yetkisi lazım?

Standart pod patch yetkisi burada yetmiyor. Verbs listesine ayrıca patch, resources kısmına da pods/resize eklemeniz gerekiyor. Bence bu aslında çok doğru bir tasarım kararı — resize gibi kritik bir operasyonu ayrı bir yetki seviyesine bağlamak güvenlik açısından çok daha temiz.

Cgroup v1 ile de çalışıyor mu?

Size bir şey söyleyeyim, Teknik olarak evet, ama tecrübeme göre önerilmiyor. Cgroup v2 ile davranış çok daha öngörülebilir oluyor. RHEL 8 veya eski Ubuntu 20.04 gibi cgroup v1’in default geldiği dağıtımlarda manuel migration yapmanız gerekiyor — biraz zahmetli,. Değer.

Kaynaklar ve İleri Okuma

Kubernetes Blog: In-Place Vertical Scaling for Pod-Level Resources Graduates to Beta
Kubernetes Resmî Dokümantasyonu: Resize Container Resources
KEP-2837: Pod-Level Resources Enhancement Proposal

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

GitHub Actions’da Özel Runner İmajları: Kontrol Artık Sizde!29 Mar 2026

Kubernetes 1.36 Ön İzleme: Neler Geliyor, Neler Gidiyor?14 Nis 2026

Copilot Cloud Agent Artık İmzalı Commit Atıyor: Neyi Değiştiriyor?3 Nis 2026

Copilot Güvenlik Taramasında: Riski Okutan Yeni Hamle10 Nis 2026