Kubernetes 1.35'te yerinde (in-place) pod resize genel kullanıma açıldı, ancak JVM ve Node heap'leri bununla birlikte büyümüyor

Yerinde (in-place) pod resize özelliği Kubernetes 1.35'te genel kullanıma (GA) ulaştı ve dev.to'da yayımlanan uygulamalı testler iddiayı doğruluyor: çalışan bir pod'un CPU limitleri tek bir patch ile, yeniden başlatma ve yeniden planlama olmadan yükseltilebiliyor. Aynı testler, pratikte daha çok önem taşıyan bir boşluğu da ortaya çıkardı. JVM ve Node.js gibi runtime'lar heap boyutlarını yalnızca başlangıçta, bir kez hesaplıyor ve bu değere bir daha dokunmuyor. Bu yüzden başarılı görünen bir bellek resize işlemi, uygulamayı dakikalar önce hesapladığı bir limite çarparak çökertebiliyor.

CPU resize işlemleri saniyeler içinde uygulanıyor

dev.to gönderisine göre yazar, Kubernetes 1.37 çalışan bir kind cluster üzerinde Node 22 ve Java 21 servislerini çalıştırdı ve resize işlemi sırasında her ikisine de yük uyguladı. Pod'un resize subresource'una yapılan patch, Node uygulamasının 200m CPU limitinden 2 çekirdeğe çıkmasını sağladı. Container içinde cgroup'un cpu.max değeri patch döndükten 0,27 saniye sonra değişti, restart sayısı sıfırda kaldı ve saniyede yaklaşık 11 olan throughput kabaca üç katına çıkarak 33'e ulaştı; p99 gecikme de yaklaşık 1,5 saniyeden kabaca 420 milisaniyeye düştü.

Aynı testte iki uyarı da ortaya çıktı. Node süreci iki çekirdeğinden yalnızca birini kullandı, çünkü tek iş parçacıklı (single-threaded) bir event loop daha fazlasını kullanamaz — ekstra CPU böyle bir hizmete ancak bir tam çekirdeğe kadar yarar sağlar. Ayrıca runtime'lar kullanılabilir CPU'yu farklı bildiriyor: JVM cgroup kotasını canlı okuyup yukarı yuvarlarken, Node'un libuv kütüphanesi kota bir tam çekirdeğin altındayken host'un tam çekirdek sayısını raporluyor. Bu sayıdan boyutlandırılan bir worker pool bu nedenle en küçük pod'larda en yanlış sonuca ulaşıyor.

Runtime'lar yeni belleği görmüyor

Bellek, özelliğin uygulama katmanında ters gittiği yer. 512Mi limitiyle başlatılan bir Java 21 pod'u heap'ini yaklaşık 123 MB olarak boyutlandırdı. 2Gi'ye resize işleminden sonra cgroup saniyeler içinde güncellendi, ancak heap 123 MB'de kaldı; çünkü MaxHeapSize süreç başlangıcında yalnızca bir kez hesaplanıyor. Uygulamadan 200 MB ayırması istendiğinde, 1,9 GB boş alana rağmen OutOfMemoryError fırlattı. Çekirdek hiç müdahale etmedi, çünkü onun bakış açısından yanlış giden bir şey yoktu.

Node da benzer davrandı. 256Mi limiti altında heap üst sınırı 259 MB çıktı; 1Gi'ye resize işleminden sonra 400 MB nesne ayırmaya çalışmak ölümcül bir JavaScript heap hatasına yol açtı, süreç 139 koduyla sonlandı ve container yeniden başladı; toparlanma penceresi boyunca 1.853 başarısız istek üretildi. Heap'in 524 MB bildirmesi ancak bu yeniden başlatmadan sonra mümkün oldu.

resizePolicy neyin yeniden başlayacağına karar veriyor

dev.to yazarı, Kubernetes'in bu soruna yanıtı olarak resizePolicy'ye işaret ediyor. Her kaynak NotRequired veya RestartContainer değerinde bir restartPolicy taşıyabiliyor; böylece yaygın bir yapılandırma CPU değişikliklerini canlı uygularken, bellek değişikliklerinde yalnızca container'ı — pod'u değil — yeniden başlatıyor. Testte bu politika altındaki 512Mi'den 2Gi'ye resize işlemi aynı pod'u ve IP'yi korudu, container'ı yaklaşık bir saniyede tekrar hazır hale getirdi ve JVM'i 494 MB heap ile yeniden başlattı. Event log, container'ın resize bunu gerektirdiği için öldürüldüğünü açıkça belirtiyor.

Küçültme ve reddedilen istekler

Bellek küçültme beklenenden iyi davrandı: 2Gi'den 200Mi'ye düşürme işlemi yeniden başlatma olmadan bir saniye içinde uygulandı. Ancak limiti mevcut kullanımın altına indirmek — kullanımda yaklaşık 160 MB varken 100Mi — kubelet tarafından reddedildi; kubelet cgroup'u 200Mi'de bıraktı, pod'u çalışır durumda tuttu ve istek değiştirilene kadar yeniden denenmeye devam eden, nedeni Error olan bir PodResizeInProgress durumu belirledi. Bu başarısızlık, çoğu dashboard'un göstermediği bir pod condition'ında ortaya çıkıyor. Bunun yanı sıra, bir node'un ayırabileceğinden fazla istemek — örneğin 16 çekirdekli bir node'da 64 CPU — pod'u pending durumunda bırakmak yerine API server tarafından patch anında reddediliyor.

Neden önemli

Yerinde resize'ın genel kullanıma açılması, Kubernetes'in en eski operasyonel sürtünme noktalarından birini ortadan kaldırıyor: bir workload'un kaynaklarını değiştirmek artık rollout gerektirmiyor. CPU bağlantılı servisler için bu artık saniyelerle ölçülen canlı bir işlem. Bellek tarafı ise tuzak. Geleneksel tüm sinyaller — pod spec'i, cgroup, kullanım grafikleri — resize'ın başarılı olduğunu söylerken uygulama, başlangıç dönemindeki bir limite karşı can veriyor. dev.to testlerinden çıkan pratik öneri, runtime'ınızın heap'ini büyütebildiğini doğrulamadığınız sürece bellek için RestartContainer'ı makul varsayılan olarak benimsemeniz ve pod resize durumlarını izlemeniz; aksi halde reddedilen bir küçültme sessizce başarısız oluyor.