Şunu fark ettim: Geçen hafta Logosoft’ta bir e-ticaret müşterimizin Black Friday hazırlığını konuşuyorduk. Adam dert yanıyor: “Aşkın, biz peak saatte pod’ları yeniden başlatmak istemiyoruz, ama sidecar’lı yapımız var ve her container’a ayrı limit koymak işkence.” Ben de “v1.36’yı bekle” dedim. İşte o gün geldi sayılır.
Kubernetes 1.36 ile birlikte In-Place Pod-Level Resources Vertical Scaling Beta seviyesine yükseldi. Yanı artık çalışan bir Pod’un toplam CPU/memory bütçesini, çoğu durumda container’ları restart etmeden değiştirebiliyorsunuz (kendi tecrübem). Küçük gıbı duruyor, ama üretimde işin rengi değişiyor; hele trafik dalgalıysa, insan bir anda “ha, tamam” diyor — dürüst olayım, biraz hayal kırıklığı —
Önce şu hikâyeyi düzgünce anlayalım
Dürüst olmak gerekirse, Şu özellik öyle bir anda gökten zembille inmedi (ben de ilk duyduğumda şaşırmıştım). Bir yolculuğun son halkası. Şöyle özetleyeyim: önce Pod seviyesinde kaynak modeli oturdu, sonra container bazında canlı resize geldi, en son da ikisi birbirine bağlandı; yanı parçalar tek tek olgunlaştı, sonra asıl birleşim yapıldı.
Bunu biraz açayım.
- v1.34: Pod-Level Resources Beta’ya geçti (yanı Pod’a toplu kaynak limiti tanımlayabilme)
- v1.35: In-Place Pod Vertical Scaling GA öldü (container bazında canlı resize)
- v1.36: Bu ikisinin birleşimi — Pod seviyesinde canlı resize Beta’da (bu kritik)
Açık konuşayım, Kubernetes ekibi burada parçaları sırayla toparlamış, açık konuşayım fena da yapmamış. Bir anda her şeyi aynı release’e yığmamışlar, çünkü o iş genelde sonra patlıyor. Mantıklı davranmışlar.
Pod-level resource modeli neydi, hatırlatayım
Bunu yaşayan biri olarak söyleyeyim, Klasik modelde her container’a ayrı ayrı requests ve limits yazardınız. Uygulama var, log shipper sidecar bir düşüneyim… var, service mesh proxy var diyelim; üçüne de tek tek limit giriyorsunuz. İşte tam burada insanın içi sıkılıyor, çünkü biri boşta dururken diğeri yoruluyor, ama siz yine de hepsini ayrı ayrı idare etmeye çalışıyorsunuz.
Pod-level model bunu biraz daha akıllı hâle getiriyor: Pod’un kendisine tek bir bütçe veriyorsunuz (mesela spec.resources.limits.cpu: "2"), container’lar bu havuzdan paylaşımlı kullanıyor. Çok daha gerçekçi duruyor. Bana sorarsanız Kubernetes’in son dönemde attığı en ayakları yere basan adımlardan biri bu (evet, doğru duydunuz)
Çok konuştum, örnekle göstereyim.
Peki canlı resize neden bu kadar önemli?
Düşünün: Bir Pod’ünüz var, sidecar’lı, iki CPU pod-level limit ile çalışıyor. Trafik bir anda 3 katına çıktı. Eskiden iki yol vardı; ya HPA ile yeni pod açacaktınız (warm-up süresiyle uğraşacaksınız), ya da Deployment’ı patch’leyip pod’u yeniden yaratacaktınız (connection drop, cache kaybı, biraz da sınır).
Küçük bir detay: Şimdi üçüncü bir seçenek var: Pod’u öldürmeden, container’ları restart etmeden, toplam bütçeyi büyütmek. Cgroup limitleri runtime tarafında dinamik olarak güncelleniyor. Çoğu uygulama bunu ya hiç fark etmiyor ya da çok kısa bir dalgalanma olarak geçiyor. Kullanıcı tarafında olay büyümüyor.
Durun, bir saniye.
Bir bankacılık projesinde JVM tabanlı bir uygulamamız vardı, açılış süresi 4 dakika. Her resize için 4 dakika downtime kabul edilemezdi. Bu kabiliyetin o tür senaryolar için tam ilaç gıbı.
Resize nasıl çalışıyor — teknik detay
Bence, İşin püf noktası şurada: Pod-level bir resize tetiklendiğinde Kubelet bunu sadece tek bir ayar değişikliği gıbı görmüyor; Pod’dan limit miras alan her container için ayrı bir resize olayı olarak değerlendiriyor. Neden önemli bu? Yanı bireysel limit tanımlamadıysanız — ki bu modelde çoğu zaman öyle — hepsi yeni bütçeye göre tekrar hizalanıyor.
Restart gerekip gerekmediğine işe her container’ın kendi resizePolicy‘sine bakılarak karar veriliyor:
- NotRequired: Kubelet, CRI üzerinden cgroup limitlerini canlı günceller. Restart yok.
- RestartContainer: Yeni limit güvenli şekilde uygulanabilsin diye container yeniden başlatılır.
resizePolicy Pod seviyesinde desteklenmiyor. Kubelet neredeyse her zaman container bazlı ayarlara bakıyor. İlk bakışta kafa karıştırıyor gıbı geliyor ama aslında mantığı var — çünkü hangı container’ın restart kaldıracağını siz daha iyi biliyorsunuz.
Pratik bir örnek üzerinden gidelim
Bir Pod düşünün: 2 CPU pod-level limit var, iki container çalışıyor (main app + logger sidecar), ikisinin de bireysel limiti yok. Manifest şöyle:
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"Siz CPU’yu 2’den 4’e çıkarmak istiyorsunuz diyelim. Komut da şu kadar sade: Daha fazla bilgi için GA4’ü Bırakıp Next.js + Supabase’e Geçmek: Neden? yazımıza bakabilirsiniz.
Kısa bir not düşeyim buraya.
kubectl patch pod shared-pool-app --subresource resize \
--patch '{"spec":{"resources":{"limits":{"cpu":"4"}}}}'Dikkat ettiyseniz --subresource resize kullanılıyor. Bu normal patch’ten farklı bir endpoint demek oluyor ve RBAC tarafında ayrıca kontrol edebiliyorsunuz. Yanı yetkiyi gelişi güzel dağıtmıyorsunuz; iyi de oluyor aslında.
Lafı gevelemeden söyleyeyim: Patch atmak işin sadece başlangıcı. Kubelet birkaç kontrolü sırayla yapıyor ve burada küçük detaylar önemli hâle geliyor; yoksa olay kağıt üstünde güzel görünür ama node tarafında tıkanır.
1. Feasibility check (uygunluk kontrolü)
Kubelet önce node’da bu yeni bütçenin sığıp sığmadığına bakıyor. Yanı diğer pod’ların kullandığı kaynakları da hesaba katıp “Bu node’da 2 CPU daha var mı?” sorusunu cevaplıyor. Yer yoksa resize Deferred veya Infeasible statüsüne düşüyor.
2.Cgroup uygulaması
Daha açık söyleyeyim, dürüst olmak gerekirse, Yer varsa Kubelet, container runtime (containerd, CRI-O vs.) üzerinden cgroup limitlerini güncelliyor.Bu kısım modern cgroup v2 sistemlerde nispeten hafif kalıyor; milisaniyeler içinde bitiyor denebilir.Ama tabii her ortamda aynı değil,sunucu zaten nefes nefese işe iş uzayabiliyor. Daha fazla bilgi için azd Nisan 2026: Multi-Language Hooks ve Sessiz Devrim yazımıza bakabilirsiniz.
3.Status güncellemesi
Pod statüs’ünde resize’ın durumu görünüyor.kubectl describe pod ile takıp edebilirsiniz.Bazen insan oraya bakınca rahatlıyor,bazen de “hâlâ InProgress mi?” diye söyleniyor ama neyse ki iz sürmek mümkün.
| Statüs | Anlamı | Neyapmalı? |
|---|---|---|
| InProgress | Resize devam ediyor | Bekleyin |
| Deferred | Şu an node’da yer yok, sonra denenecek | Node kapasitesini kontrol et |
| Infeasible | Bu resize bu node’da hiç olmaz | Pod’u taşımayı düşün |
| Completed | Tamam, yeni limitler aktif | Zaten iş bitmiş, izlemeye devam |
Açık konuşayım, Türkiye’de Kubernetes adoption’ı son 3 yılda baya hızlandı ama hâlâ büyük şirketlerin çoğunda bare-minimum kullanım görüyorum.Yani kümeyi kurmuşlar, deployment’ları aktarmışlar, ama autoscaling ve resource optimization tarafı zayıf kalmış.Müşterilerde sık gördüğüm şey şu: over-provision yapılıyor, çünkü herkes “ne ölür ne olmaz” diye biraz fazla pay bırakıyor. Daha fazla bilgi için Docker İmajını Küçültmek: 1,58 GB’dan 186 MB’a yazımıza bakabilirsiniz.
B u yeni özellik FinOps açısından baya iş görüyor. Artık pod’ları en kötü senaryoya göre şişirmek zorunda değilsiniz.Normal yükte küçük başlatın, peak’te in-place büyütün, sakinleşince tekrar küçültün. Cosmos DB Maliyet Optimizasyonu: AI Yüklerinde 7 Taktık w yazımda da değindiğim gıbı,bulut maliyet optimizasyonu artık otomasyona ve dinamik kaynak yönetimine kayıyor. Peki neden? Çünkü sabit kapasite yaklaşımı çoğu yerde gereksiz para yakıyor. DSC v3.2.0 Çıktı: Windows Resource’ları, Bicep ve Daha yazımızda bu konuya da değinmiştik.
Küçük ekipseniz (5-15 kişilik dev takım) :B u özelliği bir custom controller ile birleştirin. Prometheus metrikleri okuyup CPU %80’i aşınca pod’u büyüten basit bir operatör yazın. İki üç günlük iş gıbı duruyor, ama karşılığını alırsınız. Vertical Pod Autoscaler (VPA) ile entegre etmeye kalkmayın daha; VPA’nın in-place mode’u henüz bu özelliği tam kullanacak yerde değil bence. Hem aceleye gerek yok, biraz otursun.
Yanı, E nterprise yapıdaysanız:P önce dev/test ortamlarında deneyin. Production’a almadan önce mutlaka oyun planı çıkarın bir düşüneyim… : Hangı workload’lar resize’a uygun? Hangileri JVM gıbı içeride memory pool yönetiyor (bunlarda memory shrink tehlikeli olabilir)? Stateful set’lerde de dikkatli olun; orada küçük hata can sıkabiliyor. Siz ne dersiniz, böyle şeyleri önce lab’de mi yoklarsınız? Copilot Code Review Faturalandırması: Actions Dakikası Devri yazımızda bu konuya da değinmiştik.
B ir uyarı: Her şey güllük gülistanlık değil
Beta’da olduğunu unutmayın.Kağıt üstünde hoş duruyor ama pratikte birkaç testte şunlara denk geldim; yanı herkesin ortamında aynı davranmaz:
- M emory shrink riskli:M emory’yi büyütmek nispeten güvenli ama küçültmek — özellikle JVM,.NET veya Node.js gıbı runtime’l arda — OOM kill’e yol açabilir.
RestartContainer - Resize sonucu Pod’un QoS class’ı (Guaranteed/Burstable/BestEffort) değişebilir.Bu da scheduling kararlarını etkileyebilir.
- Observability eksik:Şu an metrik tarafı zayıf.Kaç tane resize başarısız öldü, ne kadar sürdü — bunları kendiniz tooling ile takıp etmelisiniz.Biraz zahmetli, evet.
- Pod-level resizePolicy yok:Yukarıda belirttim ama tekrar ediyorum — Pod seviyesinde tek bir resize policy tanımlayamıyorsunuz, container container yönetiyorsunuz. Neyse, durum bu. — ciddi fark yaratıyor
Pod resize is forbidden: pod resources cannot be changed when individual containers have explicit limits. Çözümü neydi? Container’lardaki bireysel CPU limitlerini kaldırdım,sadece Pod-level limit bıraktım.Mantıklı bir hata mesajı aslında ama dokümantasyonda yeterince öne çıkarılmamış; insan ilk başta başka yerden şüpheleniyor. Tam da öyle.
Peki, açık konuşayım, Kubernetes 1.36 baya dolu bir release öldü.Bu özelliği tek başına değil, diğer yeniliklerle birlikte düşünmek lazım.Bu blogda da yazdım,Kubernetes v1.36 ‘da User Namespaces GA: Rootless Devri Geldiw ile güvenlik tarafı ciddi bir sıçrama yaptı.Kubernetes v1.36 Controller Staleness: Artık Daha Az Acıd a operasyonel iyileştirmeler var.Az önce performans dedim ama aslında güvenlik ve operasyon tarafını birlikte okumak gerekiyor; tek başına bakınca resim eksik kalıyor. Peki bunu neden söylüyorum?
Bunlar bir araya gelince,1.36 aslında “production-grade Kubernetes” tanımının yeniden çizildiği bir versiyon öldü bence.Eskiden “Kubernetes hazır mı?” sorusuna ben hep “duruma göre” cevabını verirdim.Artık daha rahat “evet,ama doğru patternleri kullan” diyorum.Tabi yine körlemesine değil; biraz test şart,biraz gözlem şart.
Neyse uzatmayalım,durum kabaca bu.
Tam da öyle.
Evet.
Peki neden?
Siz ne dersiniz?
Bu kadar mı?
Hayır,biraz işi var.
Ama yol doğru görünüyor.
- B ir test cluster’ında 1.36 ‘ya çıkın( AKS’te preview kanalı kullanabilirsiniz)
InPlacePodLevelResourcesVerticalScalingfeature gate ‘ının açık olduğunu doğrulayın(default olarak Beta’da açık) — ciddi fark yaratıyor- S tateless bir uygulamanızı Pod-level resources ile yeniden tanımlayın
- M anual
kubectl patch --subresource resizekomutuyla deneyin (bu kritik) - L ogları,metriği,app davranışını takıp edin
- M emnun kaldıysanız bir otomasyon( operator/controller) yazmayı düşünün
Sıkça Sorulan Sorular
In-place pod resize, HPA’nın yerini mi alır?
Hayır, ikisi aslında farklı sorunları çözüyor. HPA yatay ölçekleme yapıyor, yanı yeni pod’lar açıyor. In-place resize işe dikey ölçekleme — var olan pod’u olduğu yerde büyütüyor. Bence stateful uygulamalarda ya da warm-up süresi uzun servislerde in-place resize çok daha mantıklı. Stateless uygulamalarda işe HPA hâlâ daha esnek kalıyor.
Bu özellik AKS, EKS ve GKE’ye ne zaman geliyor?
AKS tarafında Microsoft genelde upstream’i 2-3 ay gecikmeyle preview olarak sunuyor. GA için işe 6 ay civarı beklemek gerekiyor. EKS ve GKE de benzer bir takvimle gidiyor. Açıkçası, 2026 yılı ortasından itibaren managed servislerde stabil hâlde görmeye başlarız diye tahmin ediyorum.
Memory’yi resize etmek güvenli mi?
CPU resize nispeten güvenli, hani çoğu durumda restart bile gerekmiyor. Memory shrink işe işte orada biraz riskli — uygulama o anda allocate ettiği memory’yi azaltamıyorsa OOM kill yiyor. Tecrübeme göre memory için RestartContainer politikasını seçmek çok daha sağlıklı oluyor.
VPA ile birlikte çalışıyor mu?
VPA’nın “InPlaceOrRecreate” modu var yanı entegrasyon tamamen yok değil,. Pod-level resources tarafındaki olgunluk henüz yetersiz. Şu an için manuel kontrol ya da kendi yazacağınız bir controller daha güvenli duruyor. VPA tarafının 2026 ortasında olgunlaşmasını bekliyoruz.
Hangı container runtime’lar destekliyor?
Cgroup v2 destekleyen modern runtime’lar — mesela containerd 1.7+, CRI-O 1.28+ — tam destekli. Cgroup v1 olan eski sistemlerde bazı kısıtlamalar çıkabiliyor. Açıkçası production cluster’larınızı cgroup v2’ye geçirmenizi şiddetle öneririm; sadece bu özellik için değil, genel olarak zaten geçmeniz gereken bir şey bu.
Kaynaklar ve İleri Okuma
Kubernetes Resmî Blog: In-Place Vertical Scaling for Pod-Level Resources
Kubernetes Docs: Resize Container Resources
KEP-2837: Pod-Level Resource Specifications
Kısacası, dürüst olmak gerekirse, Managing Resources for Containers
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
