Kubelet rezervasyon değişiklikleri EKS, GKE ve AKS üzerinde kullanılabilir düğüm belleğini sessizce yeniden şekillendiriyor

16 GiB RAM'e sahip bir düğüm, kubelet rezervasyonları düştükten sonra pod'ların yalnızca yaklaşık 11,9 GiB'ine göre zamanlanmasına izin verebilir — ve üç büyük yönetilen Kubernetes platformu bu rezervasyonların nasıl hesaplandığını yakın zamanda değiştirdi. Kalikys tarafından dev.to'da yayımlanan bir analizin çıkış noktası tam olarak bu; yazar EKS nodeadm kaynak kodunu ve güncel GKE ve AKS dokümantasyonunu inceleyerek üç bulut üzerindeki instance tipleri için tahsis edilebilir CPU ve bellek değerlerini hesapladı. Sonuç: Dolaşımdaki kapasite tavsiyelerinin büyük kısmı — eski blog yazıları ve hesaplayıcılar dahil — platformların gerçekte ne kadar rezerve ettiğiyle artık örtüşmüyor.

Kubelet gerçekte neyi rezerve ediyor

Scheduler bir düğümün ham donanımını görmez. Kubelet, sistem rezervasyonlarını toplam kapasiteden düşerek bir Allocatable (tahsis edilebilir) değeri üretir ve pod'lar bunun için yarışır. Yönetilen servislerde bu rezervasyonlar giderek artan biçimde maxPods — düğüm başına pod limiti — tarafından belirleniyor, yani ağ yapılandırması seçimlerinin artık doğrudan bellek sonuçları var.

EKS: prefix delegation rezervasyonu yükseltiyor

dev.to analizine göre EKS, olası her pod için 11 MiB bellek artı 255 MiB taban rezerve ediyor. Varsayılan VPC CNI ile maxPods, instance'ın ENI limitini takip ediyor; t3.medium'da bu limit 17, rezervasyonu 442 MiB yapıyor ve düğüm belleğinin yaklaşık %87'si kullanılabilir kalıyor. Daha fazla pod sığdırmak için prefix delegation etkinleştirildiğinde maxPods 110'a çıkıyor, rezervasyon 1465 MiB'e tırmanıyor ve kullanılabilir bellek %62'ye düşüyor. Bir m5.large %92'den %81'e geriliyor.

Dengeler daha büyük makinelerde tersine döner: m6i.4xlarge, pod başına rezervasyon toplam belleğe göre küçük olduğu için prefix delegation ile %95,5'ten %97,6'ya yükseliyor. 4 GiB'lik bir düğümde bellek, 110. pod hiç başlatılamadan önce tükenir; dolayısıyla ekstra rezervasyon, düğümün asla kullanmayacağı kapasite yuvaları için ödeme yapmaktır.

GKE 1.37 belleği geri veriyor

GKE'deki değişiklik ters yönde ilerliyor. 1.36 sürümüne kadar geri paylaşımlı bir bellek payı rezerve ediyordu: İlk 4 GiB'nin %25'i, sonraki 4'ün %20'si, ondan sonraki 8'in %10'u ve 128 GiB'ye kadar %6. 1.37'den itibaren Container-Optimized OS üzerinde rezervasyon, eski değer ile 15 MiB × maxPods + 500 MiB değerinden düşük olanı — 110 pod'da yaklaşık 2,1 GiB, düğüm boyutundan bağımsız olarak.

dev.to rakamları bir n2-standard-16'nın (64 GiB) rezervasyonunun 5,5 GiB'den 2,1 GiB'ye, bir n2-standard-32'nin (128 GiB) 9,3 GiB'den 2,1 GiB'ye düştüğünü, pod'lara 7,2 GiB boşaldığını gösteriyor. CPU rezervasyonu da artık 1 vCPU ile sınırlı; yazarın işaret ettiği tek istisna paylaşımlı çekirdekli e2-medium: 2 vCPU'sunun 1060m'si hâlâ rezerve, geriye 940m kalıyor. Pratik sonuç, eski dilimlere göre boyutlandırılmış node pool'ların rutin bir yükseltmeden sonra düğüm bırakabiliyor olması.

AKS: 250 pod varsayılanı sınıra çarpıyor

1.29 sürümünden beri AKS, min(20 MB × maxPods + 50 MB, RAM'in %25'i) değerini rezerve ediyor. Azure CNI Overlay varsayılan olarak 250 maksimum pod kullanıyor ve bu, 16 GiB'lik bir D4s v5 üzerinde rezervasyonu %25 sınırına itiyor: 4 GiB rezerve, %74 kullanılabilir. Pool oluşturulurken maxPods'un 110'a ayarlanması rezervasyonu 2,2 GiB'ye düşürüyor ve kullanılabilir belleği %86'ya çıkarıyor — tek bir bayrakla düğüm başına 1,8 GiB fark. Catch şu: mevcut bir AKS pool'unda maxPods değiştirilemiyor; tek yol yeni bir pool ve iş yükü taşınması.

Ne yapmalı

Yazarın önerileri basit. maxPods'u CNI'nin izin verdiği maksimuma değil, düğümün gerçekçi olarak çalıştırabileceği bir düzeye ayarlayın. Pod isteklerini kubectl describe node çıktısındaki Allocatable satırına göre, DaemonSet'lerin tükettiği kadar düşerek boyutlandırın — asla instance teknik föyüne göre değil. Ve kontrol düzlemi yükseltmelerinden sonra rakamları yeniden kontrol edin; çünkü GKE 1.37, formüllerin bir cluster'ın altında değişebildiğini gösteriyor. Kendi kurulumlarına göre doğrulamak isteyenler için yazar, AWS, GCP ve Azure üzerinde yaklaşık 2.900 instance tipini kapsayan, düğümleri rezervasyonlar uygulandıktan sonraki aylık maliyete göre sıralayan ücretsiz bir hesaplayıcı da yayımlıyor; rakamlar script ile hesaplandı ve satıcı kaynaklarıyla karşılaştırılarak doğrulandı.

Neden önemli

Rezervasyonlar satın alma anında görünmez ama zamanlama anında belirleyicidir. Instance özelliklerine veya güncelliğini yitirmiş referans tablolarına dayanan kapasite planları ve maliyet modelleri düğüm başına gigabyte'lar kadar sapabilir — her iki yönde de. EKS ve AKS belleği çoğu ekibin hiç incelemediği varsayılanlar aracılığıyla alırken, GKE'nin yükseltmesi sessizce geri veriyor. AKS vakası en keskin derstir: pool oluşturulurken seçilen bir ağ varsayılanının sabit bir kapasite maliyeti vardır ve bunu sonradan düzeltmek altyapıyı yeniden kurmak demektir. Bin-packing yoğunluğu hesabı, doğru boyutlandırma çalışmaları veya yükseltme planlaması yapan herkes için tek önemli rakam Allocatable — ve platform hareket ettiğinde artık yeniden doğrulanması gerekiyor.