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.

İş Yükü (Pod İstekleri)

Pod başına CPU isteği (millicore) 1 çekirdek = 1000m. Örn. 250m = çeyrek çekirdek.

Pod başına bellek isteği (Mi) 1 GiB = 1024 Mi.

Replika (pod) sayısı

Düğüm (Node)

Düğüm başına CPU (çekirdek)

Düğüm başına bellek (GiB)

Sistem + Kubernetes ek yükü (%) kube-reserved, system-reserved ve tahliye eşiği için ayrılan kapasite. Tipik değer %10-15.

Düğüm başına aylık maliyet (opsiyonel) Para birimi fark etmez; boş bırakılırsa maliyet gösterilmez.

Sonuçlar

Değerleri girip "Hesapla"ya basın.

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ği bu sitenin arkasındaki küçük bir production k3s kümesini işletiyor. 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ı.