Öneri nasıl hesaplanıyor?
CPU isteği (request), p95 CPU kullanımı artı seçtiğiniz paydır ve sonraki 10 milicore'a yukarı yuvarlanır. CPU sıkıştırılabilir bir kaynaktır: isteğini aşan pod boştaki kapasite için yarışır ve yavaşlar, ama öldürülmez. Bu yüzden p95 makul bir temeldir.
Bellek isteği ve limiti, en yüksek working set artı seçtiğiniz paydır ve sonraki 16 MiB'a yukarı yuvarlanır. Bellek sıkıştırılamaz: limitini aşan container öldürülür. Hesaplayıcının yüzdelik yerine en yüksek değeri kullanmasının nedeni budur. Limiti isteğe eşitlemek, podun yoğun bir düğümdeki bellek davranışını öngörmeyi kolaylaştırır.
CPU limiti blokta bilerek yer almıyor. CPU limitleri, düğümde boş kapasite olsa bile gecikmeye duyarlı servisleri kısabilir. Bu konu tartışmalıdır; çok kiracılı bazı kümelerde adalet ya da politika gereği CPU limiti gerekebilir. Sizin kümenizde gerekiyorsa ekleyin ve değişiklikten sonra kısılma (throttling) metriklerini izleyin.
Rezervasyon değişimi, yeni ve mevcut istekler arasındaki farkın replika sayısıyla çarpımıdır. Bu, zamanlayıcının ayırdığı kapasiteyi gösterir. Gerçek tasarrufa ancak küme daha az düğümle çalışabilirse dönüşür.
Örnek bir hesap
Varsayılan değerlerle bir örnek: 6 replika, her biri 1.000 milicore ve 2.048 MiB istiyor. Temsil gücü olan bir dönemde p95 CPU 180 milicore, en yüksek working set 700 MiB.
- CPU: 180 × 1,30 = 234, yukarı yuvarlanınca 240m
- Bellek: 700 × 1,20 = 840, yukarı yuvarlanınca 848 MiB
- CPU rezervasyonu: (1.000 − 240) × 6 = 4.560 milicore, yani 4,56 çekirdek az
- Bellek rezervasyonu: (2.048 − 848) × 6 = 7.200 MiB, yani yaklaşık 7,03 GiB az
Değerleri uygulamadan önce kontrol edin
Tam bir döngüyü ölçün. En yoğun gününüzü, ay sonu işlerini ve dağıtımları dahil edin. Sakin bir haftanın verisi, ilk yoğun pazartesi yetersiz kalır.
Önce HPA'ya bakın. CPU kullanımını hedefleyen bir HorizontalPodAutoscaler, kullanımı isteğin yüzdesi olarak hesaplar. İsteği 1.000m'den 240m'ye düşürüp %70 hedefini korursanız aynı yük dört kat daha yoğun görünür ve HPA replika ekler. Hedefi de ayarlayın, yoksa değişiklik toplam kullanımı artırabilir.
Açılış davranışına bakın. Bazı Java ve .NET servisleri açılırken, trafik işlerken kullandığından çok daha fazla CPU kullanır. Çok düşük bir CPU isteği açılışı yavaşlatıp readiness kontrollerinin başarısız olmasına yol açabilir. Açılışı da değerlendirmeye katın ya da buna göre pay bırakın.
Limitlere göre kendini ayarlayan çalışma ortamlarına dikkat edin. JVM ve .NET, heap boyutunu ve iş parçacığı ayarlarını seçerken container limitlerini okur. Bellek limitini değiştirmek çalışma ortamının davranışını da değiştirebilir, dolayısıyla ölçtüğünüz working set aynı kalmayabilir.
Kademeli uygulayın. Önce tek bir iş yükünü ya da canary'yi değiştirin. Devam etmeden önce en az bir tam iş döngüsü boyunca yeniden başlatmaları, OOM sonlanmalarını, CPU kısılmasını ve gecikmeyi izleyin.
Ne kadar pay bırakmalıyım?
Herkese uyan bir değer yok. CPU için %30 ve bellek için %20 varsayılanları yalnızca başlangıç noktasıdır. Trafiği ani değişen, belleği son dönemde büyüyen ya da otomatik ölçeklemesi yavaş olan servislerde daha fazla, davranışı iyi bilinen kararlı toplu işlerde daha az pay bırakın. Replikalarınız birden çok bölgeye dağılmışsa bir bölge düştüğünde kalan podların neyi karşılayacağını da hesaba katın.
Girdileri nereden alırsınız?
CPU p95 ve en yüksek working set, pod başına en az bir haftalık geçmişten gelmelidir.
container_memory_working_set_bytes metriği, kubelet'in tahliye kararlarında
kullandığı metriktir; bu nedenle sayfa önbelleğini de içeren toplam bellek kullanımından
daha iyi bir girdidir.
Wrentrix, iş yükü başına en düşük, ortalama, p95 ve en yüksek kaynak kullanımını boyutlandırma önerileriyle birlikte gösterir ve değişiklikleri gecikme ve hatalarla yan yana getirir. Kendi ağınızın içinde çalışır; ekranları canlı demoda inceleyebilirsiniz.
Sık sorulan sorular
Kubernetes CPU ve bellek isteği nasıl hesaplanır?
Temsil gücü olan bir dönemde gerçek kullanımı ölçün. Yaygın başlangıç noktası, CPU isteğini p95 kullanım artı biraz pay, bellek isteğini de en yüksek working set artı biraz pay olarak belirlemektir. Sonra kademeli uygulayıp kısılma, OOM ve gecikme değişimlerini izleyin.
Request ve limit eşit olmalı mı?
Bellekte birçok ekip ikisini eşit tutar, çünkü podun düğüm baskısı altındaki davranışı daha öngörülebilir olur. CPU'da gecikmeye duyarlı servislerde birçok ekip kısılmayı önlemek için yalnızca request tanımlar. Tüm container'larda iki kaynak için de request ile limit eşitse pod Guaranteed QoS sınıfını alır.
Pod limitlerini aşarsa ne olur?
CPU limitini aşmak kısılmaya yol açar, yani container daha yavaş çalışır. Bellek limitini aşmak ise container'ın OOM hatasıyla sonlandırılmasına ve yeniden başlatma politikasına göre yeniden başlatılmasına yol açar.
Girdiğim veriler bir yere gönderiliyor mu?
Hayır. Hesap tarayıcınızda JavaScript ile yapılır ve sayfa girdiğiniz değerleri hiçbir sunucuya göndermez.