Kubernetes Kaynak Bütçesi Hesaplayıcısı

İş yükünüzün CPU ve bellek isteklerini düğüm boyutuyla karşılaştırır; kaç düğüme ihtiyacınız olduğunu, hangi kaynağın darboğaz oluşturduğunu ve tahmini aylık maliyeti gösterir. Tüm hesaplama tarayıcınızda yapılır.

Son güncelleme:

İş Yükü (Pod İstekleri)
1 çekirdek = 1000m. Örn. 250m = çeyrek çekirdek.
1 GiB = 1024 Mi.
Düğüm (Node)
kube-reserved, system-reserved ve tahliye eşiği için ayrılan kapasite. Tipik değer %10-15.
Para birimi fark etmez; boş bırakılırsa maliyet gösterilmez.

Sonuçlar

1 Gereken düğüm sayısı
Darboğaz kaynak
CPU
CPU kullanımı
41,7%
Bellek kullanımı
20,8%
Düğüm başına pod (ortalama)
6,0

Düğüm başına en fazla 110 pod (kubelet varsayılanı) varsayılır. DaemonSet'ler, pod yakınlığı ve topoloji yayılımı hesaba katılmaz — bu bir ilk yaklaşımdır.

Bu hesabı ne zaman yapmak gerekir

Yeni bir kümeyi boyutlandırırken

Sağlayıcının node tiplerinden birini seçmeden önce iş yükünün gerçekte ne istediğini bilmek gerekir. Bu ilk karar çoğu zaman sezgiyle veriliyor; altı ay sonra ya boşta duran kapasiteye para ödeniyor ya da gece yarısı aceleyle node ekleniyor.

Fatura beklediğinizden yüksek geldiğinde

Bulut faturası genelde CPU'dan değil, fazla beyan edilmiş bellek isteklerinden şişer. Aşağıdaki kendi kümemde de tablo bu yönde: CPU %4-10 arasında geziniyor, bellek %38-49'da duruyor. Tek bir GitLab pod'u 3,8 GiB bellek tutarken 61m CPU harcıyor. Böyle bir dağılımda CPU'yu kısmak faturayı değiştirmez.

Request değerlerine dokunmadan önce

Bir deployment'ın bellek isteğini 1536 Mi'den 1024 Mi'ye çekmek küçük bir düzenleme gibi görünür. Node sayısına etkisi hiç küçük olmayabilir. Aşağıdaki örnek tam olarak bu durumu gösteriyor.

Çalışılmış örnek: faturayı belleğin belirlediği durum

Tipik bir .NET API'si: 24 replika, pod başına 200m CPU ve 1536 Mi bellek isteği. Node'lar 4 çekirdek ve 16 GiB, sistem payı için %12 ayrılmış. Hesap üç ayrı sınırı bulup en büyüğünü alıyor.

  1. Ayrılabilir kapasite: node başına 3520m CPU ve 14418 Mi bellek.
  2. CPU tarafı: 24 × 200m = 4800m. 4800 ÷ 3520 = 1,36 → 2 node yeterli.
  3. Bellek tarafı: 24 × 1536 Mi = 36864 Mi. 36864 ÷ 14418 = 2,56 → 3 node gerekli.
  4. Pod sayısı: 24 pod, node başına 110 sınırının çok altında. Bağlayıcı değil.
  5. Sonuç 3 node, darboğaz bellek. CPU kullanımı %45'te kalıyor, bellek %85'e çıkıyor.

Üç node kiralayıp CPU'nun yarısını boşta tutuyorsunuz. Bellek isteği 1024 Mi'ye çekilince hesap 2 node'a iniyor, CPU kullanımı %68'e çıkıyor ve bellek kullanımı %85'te kalıyor. Tek satırlık bir değişiklik kapasitenin üçte birini geri veriyor. "Bu uygulama gerçekten 1536 Mi'ye ihtiyaç duyuyor muydu?" sorusu, bu yüzden teknik bir soru değil, fatura sorusudur.

Sık yapılan dört hata

Limit'i request sanmak

Zamanlayıcı yerleştirme kararını yalnızca request'e bakarak verir. Limit'i 2 çekirdek bırakıp request'i 100m'de unutursanız Kubernetes o pod'u 100m'lik yer varmış gibi yerleştirir. Node sıkıştığında fatura değil, gecikme artar.

Ayrılabilir kapasiteyi toplam kapasite sanmak

16 GiB'lık bir node'a 16 GiB'lık bir pod yerleşmez. kubelet, container runtime ve işletim sistemi payı ile tahliye eşiği düşüldükten sonra geriye tipik olarak %85-90 kalır. Hesaptaki ek yük alanı bunun içindir.

DaemonSet'leri hesaba katmamak

Log toplayıcı, metrik agent'ı, CNI ve CSI pod'ları her node'da birer kopya çalışır. Node sayısı arttıkça bu sabit yük de artar. Buradaki hesap yalnızca kendi iş yükünüzü kapsıyor, üzerine bir pay bırakın.

110 pod sınırını unutmak

Çok sayıda küçük replika çalıştıran ekiplerde CPU ve bellek bol olduğu hâlde bağlayıcı sınır pod sayısı olabilir. Bu durumda daha büyük node almak sorunu çözmez; kubelet'in max-pods ayarına bakmak gerekir.

Bu araçla birlikte kullanılanlar

  • CIDR / Subnet Hesaplayıcısı CIDR notasyonundan ağ adresi, broadcast, subnet maskesi, kullanılabilir host aralığı ve adres tipini hesaplayın.
  • Cron İfade Çözümleyici Bir cron ifadesini alan alan çözümleyin ve sonraki çalışma zamanlarını görün. Kubernetes CronJob ve zamanlanmış görevler için.
  • UUID Üretici Kriptografik olarak güvenli UUID v4 ve zaman-sıralı v7 üretin. Toplu üretim ve biçim seçenekleri.
  • Base64 Kodlayıcı-Çözücü Metni Base64'e kodlayın veya geri çözün. Standart ve URL-güvenli (base64url) varyant; UTF-8 uyumlu, tarayıcıda.

Sık Sorulan Sorular

Kubernetes iş yüküm kaç düğüme ihtiyaç duyar?

Düğüm sayısı üç sınırın en büyüğüdür: CPU'ya göre, belleğe göre ve pod sayısına göre gereken düğüm sayısı. Hesaplayıcı her birini ayrı bulur ve en büyüğünü "gereken düğüm" olarak verir; o sınır da darboğaz kaynağınızdır.

Düğümün ayrılabilir (allocatable) kapasitesi neden toplam kapasiteden düşük?

Her düğümün kapasitesinin bir kısmı kubelet, kapsayıcı çalışma zamanı ve işletim sistemi için kube-reserved ve system-reserved ile ayrılır; ayrıca bir tahliye eşiği bırakılır. Pod'lar yalnızca geri kalan "allocatable" kapasiteye yerleştirilir. Bu yüzden ek yük yüzdesi girersiniz.

Düğüm başına varsayılan maksimum pod sayısı kaçtır?

kubelet varsayılanı düğüm başına 110 pod'dur. Çok sayıda küçük replikanız varsa, CPU ve bellek bol olsa bile bu sınır darboğaz oluşturabilir.

İstek (request) mi yoksa limit mi kullanmalıyım?

Kubernetes zamanlayıcısı yerleştirme kararını isteklere (requests) göre verir, limitlere göre değil. Bu hesaplayıcı kapasite planlaması için istek değerlerini kullanır. Limitler, düğüm üstünde sıkışma anında throttling/OOM davranışını etkiler.

Bu tahmin ne kadar doğru?

İlk dereceden bir kapasite tahminidir. DaemonSet'leri, pod anti-affinity kurallarını, topoloji yayılım kısıtlarını, dikey otomatik ölçeklemeyi ve bölgesel dağılımı hesaba katmaz. Üretim kümeleri için baz çizgisi olarak kullanın, kesin değer olarak değil.

Gerçek kümelerden doğdu

Bu hesaplayıcı teorik değil: aynı düğüm boyutlandırma matematiğini bu sitenin arkasında işlettiğim küçük bir production k3s kümesinde kullanıyorum. Kümenin güncel anlık görüntüsü:

$ kubectl get nodes
NAME           STATUS   ROLES                  AGE    VERSION
bilal-server   Ready    <none>                 194d   v1.33.5+k3s1
k8s-master     Ready    control-plane,master   194d   v1.33.5+k3s1

$ kubectl top nodes
NAME           CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
bilal-server   333m         4%     7828Mi          49%
k8s-master     784m         10%    12097Mi         38%

$ kubectl top pods -n default
NAME                                 CPU    MEMORY
bilal-baget-6d568d945f-4hljh         5m     142Mi
bilal-filebrowser-76c987d67b-mgwwt   1m     10Mi
bilal-gitlab-57db68cdf-4thml         61m    3843Mi
bilal-mssql-59467b7576-wrl24         34m    1450Mi
bilal-registry-5c86777897-tffxm      2m     381Mi
bilal-website-c46c6fb8f-ctnck        26m    219Mi
maya-website-58877c476c-hvj9q        74m    263Mi

k3s v1.33.5 · 2 düğüm · 194 gün uptime · kararlı durumda %4-10 CPU, %38-49 bellek kullanımı.

Daha fazlası: Kubernetes güvenlik ve gözlemlenebilirlik üzerine teknik yazılar