حاسبة ميزانية موارد Kubernetes

تقارن طلبات وحدة المعالجة والذاكرة لحِمل العمل بحجم العُقدة، وتُظهر عدد العُقد التي تحتاجها والمورد الذي يُشكّل عنق الزجاجة والتكلفة الشهرية التقديرية. تتم جميع الحسابات في متصفحك.

آخر تحديث:

حِمل العمل (طلبات الحاوية)
نواة واحدة = 1000m. مثال: 250m = ربع نواة.
1 GiB = 1024 Mi.
العُقدة (Node)
السعة المحجوزة لـ kube-reserved وsystem-reserved وعتبة الإخلاء. القيمة النموذجية 10-15%.
العملة غير مهمة؛ إذا تُرك فارغًا لن تُعرض التكلفة.

النتائج

1 عدد العُقد المطلوبة
المورد المُقيِّد
وحدة المعالجة
استخدام وحدة المعالجة
41.7%
استخدام الذاكرة
20.8%
حاويات لكل عُقدة (متوسط)
6.0

يُفترض حد أقصى 110 حاوية لكل عُقدة (افتراضي kubelet). لا تُحتسب DaemonSets أو تقارب الحاويات أو توزيع الطوبولوجيا؛ هذا تقدير أولي.

متى تستحق هذه الحسبة وقتك

قبل اختيار نوع العُقدة

نِسَب المعالجة إلى الذاكرة تختلف بين عائلات العُقد أكثر مما يختلف سعر النواة الواحدة. ومن يختار قبل أن يعرف أيّ مورد يقيّد حِمله ينتهي به الأمر مستأجرًا ذاكرة لا يمسّها أحد.

حين يرتفع عدد العُقد بلا سبب واضح

المُوسِّع التلقائي الذي يضيف عُقدة تلو الأخرى يشكو غالبًا من سوء التعبئة لا من زيادة الحِمل. وفي العنقود الذي أُشغّله أسفل هذه الصفحة تظهر الفجوة بوضوح: المعالجة تتراوح بين 4% و10% بينما الذاكرة ثابتة قرب 38% إلى 49%، وحاوية GitLab وحدها تحجز 3.8 غيغابايت مقابل 61 مِلي من المعالجة فقط.

قبل تغيير قيم الطلب

خفض طلب الذاكرة يبدو تعديلًا صغيرًا. أثره على عدد العُقد ليس صغيرًا دائمًا.

مثال محسوب: حين يقيّدك سقف الحاويات لا المعالجة ولا الذاكرة

خدمة مُجزّأة إلى نُسخ صغيرة كثيرة: 260 نسخة، لكل حاوية 50 مِلي من المعالجة و128 ميغابايت من الذاكرة. والعُقد بثماني أنوية و32 غيغابايت، محجوز منها 10% للنظام. تحسب الأداة ثلاثة حدود ثم تأخذ أكبرها.

  1. السعة القابلة للتخصيص: 7200 مِلي معالجة و29491 ميغابايت لكل عُقدة.
  2. المعالجة: 260 × 50 = 13000 مِلي. 13000 ÷ 7200 = 1.81، أي عُقدتان.
  3. الذاكرة: 260 × 128 = 33280 ميغابايت. 33280 ÷ 29491 = 1.13، أي عُقدتان أيضًا.
  4. عدد الحاويات: 260 مقابل سقف 110 لكل عُقدة. 260 ÷ 110 = 2.36، أي ثلاث عُقد.
  5. النتيجة ثلاث عُقد، والقيد هنا سقف الحاويات وحده.

المعالجة والذاكرة كلتاهما كانتا تكتفيان بعُقدتين، غير أنّ سقف kubelet فرض عُقدة ثالثة. وشراء عُقد أكبر لا يحلّ شيئًا هنا، لأنّ القيد ليس قيد موارد بل رقم قابل للضبط عبر max-pods. فمن رأى فاتورته ترتفع بينما لوحات المراقبة تُظهر موارد شبه خاملة، فليتحقق من هذا الرقم قبل أيّ شيء آخر.

أربعة أخطاء متكررة

الخلط بين الحدّ والطلب

المُجدوِل يوزّع الحاويات بناءً على الطلب وحده. فإن تركت الحدّ عند نواتين والطلب عند 100 مِلي، وضع Kubernetes الحاوية كأنها تحتاج 100 مِلي فقط. ولن يظهر أثر ذلك في الفاتورة، بل في زمن الاستجابة عند الازدحام.

اعتبار السعة الكلية سعةً متاحة

عُقدة بـ16 غيغابايت لن تستقبل حاوية بـ16 غيغابايت. فبعد حصص kubelet وبيئة التشغيل والنظام، ثم عتبة الإخلاء، يبقى عادةً ما بين 85% و90%. وحقل النفقات العامة أعلاه يمثّل هذه الفجوة.

إغفال حاويات DaemonSet

جامع السجلات ووكيل المقاييس وحاويات CNI وCSI تعمل بنسخة على كل عُقدة، فتنمو تكلفتها مع عدد العُقد لا مع عدد النُسخ. والحاسبة تغطّي حِملك أنت وحده، فاترك هامشًا فوقه.

نسيان سقف 110 حاوية

وهو ما رأيناه في المثال أعلاه. فحين تكثر النُسخ الصغيرة يصير العدد هو القيد بينما المعالجة والذاكرة نصف فارغتين.

أدوات تُستعمل إلى جانبها

  • حاسبة CIDR / Subnet احسب عنوان الشبكة والبث وقناع الشبكة الفرعية ونطاق المضيفين القابل للاستخدام ونوع العنوان من تدوين CIDR.
  • محلّل تعبير Cron حلّل تعبير cron حقلًا بحقل وشاهد أوقات التشغيل التالية. لـ Kubernetes CronJob والمهام المجدولة.
  • مولّد UUID ولّد UUID v4 آمنًا تشفيريًا وv7 المرتّب زمنيًا. توليد دفعي وخيارات تنسيق.
  • مُرمّز/مُفكّك Base64 رمّز النص إلى Base64 أو فُكّ ترميزه. متغيّر قياسي وآمن للروابط (base64url)؛ متوافق مع UTF-8، في المتصفح.

الأسئلة الشائعة

كم عُقدة يحتاج حِمل عمل Kubernetes الخاص بي؟

عدد العُقد هو الأكبر بين ثلاثة حدود: العُقد المطلوبة حسب وحدة المعالجة، وحسب الذاكرة، وحسب عدد الحاويات. تحسب الأداة كلًا منها وتعطي الأكبر باعتباره "العُقد المطلوبة"، وذلك الحد هو المورد المُقيِّد.

لماذا تكون السعة القابلة للتخصيص أقل من السعة الكلية للعُقدة؟

يُحجَز جزء من سعة كل عُقدة لـ kubelet وبيئة تشغيل الحاويات ونظام التشغيل عبر kube-reserved وsystem-reserved، إضافةً إلى عتبة إخلاء. تُجدوَل الحاويات على السعة "القابلة للتخصيص" المتبقية فقط، ولذلك تُدخِل نسبة النفقات الإضافية.

ما الحد الأقصى الافتراضي للحاويات لكل عُقدة؟

الافتراضي في kubelet هو 110 حاوية لكل عُقدة. إذا كان لديك نسخ صغيرة كثيرة، فقد يُشكّل هذا الحد عنق الزجاجة حتى مع توفر وحدة معالجة وذاكرة كافية.

هل أستخدم الطلبات (requests) أم الحدود (limits)؟

يتخذ مُجدوِل Kubernetes قرار التوزيع بناءً على الطلبات وليس الحدود. تستخدم هذه الأداة قيم الطلبات لتخطيط السعة. أما الحدود فتؤثر على سلوك الخنق/OOM عند ضغط الموارد على العُقدة.

ما مدى دقة هذا التقدير؟

إنه تقدير سعة من الدرجة الأولى. لا يحتسب DaemonSets أو قواعد مكافحة التقارب أو قيود توزيع الطوبولوجيا أو التوسع التلقائي العمودي أو التوزيع الإقليمي. استخدمه كخط أساس للعناقيد الإنتاجية وليس كقيمة نهائية.

مبنية على تشغيل عناقيد حقيقية

هذه الحاسبة ليست نظرية: أستخدم حسابات تحجيم العُقد نفسها في عنقود k3s إنتاجي صغير أُشغّله خلف هذا الموقع. وهذه لقطة حالية له:

$ 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 · عُقدتان · 194 يومًا تشغيل · استخدام 4-10% للمعالج و38-49% للذاكرة في الحالة المستقرة.

المزيد: مقالات تقنية عن أمان Kubernetes وقابلية المراقبة