הגדרת ResourceQuotas ו-LimitRanges ב-Kubernetes
דמיינו שנכנסים לפרויקט חדש שבו מרחב השמות production פועל ללא ResourceQuota אחד. מפתח פורס עבודת אצווה עם requests.cpu: 0 ו-limits.cpu: 0 — כלומר ללא הגבלות כלל. תוך 20 דקות, אותה עבודה צורכת משאבים משני צמתים, ומשאירה פודים אחרים ב-Pending. לפי CNCF, היעדר מכסות הוא אחד משלושת הגורמים המובילים לחוסר יציבות באשכולות ייצור. הלקוחות שלנו חוסכים לעיתים קרובות עד 30% בעלויות ענן לאחר יישום מכסות נכונות. ללא ResourceQuota, פוד אחד שהוגדר שגוי יכול לשתק את כל האשכול — כמו בפרויקט שלנו עם קמעונאית מקוונת, שבו מרחב שמות בדיקות ללא הגבלות צרך מחצית ממשאבי הייצור.
לפי התיעוד הרשמי של Kubernetes, ResourceQuota מגביל את צריכת המשאבים המצטברת במרחב שמות, ומונע עומס יתר על האשכול.
למה היעדר מכסות הוא פצצה מתקתקת?
ResourceQuotas ו-LimitRanges פותרים בעיות שונות, אבל לעיתים קרובות הם מבולבלים. ResourceQuota מגביל את כל מרחב השמות — סך CPU, זיכרון, מספר פודים, שירותים, PVCs. אם המכסה מוצתה, אובייקטים חדשים לא נוצרים; kubectl apply מחזיר שגיאת exceeded quota. LimitRange פועל ברמת הקונטיינר: הוא קובע ערכי requests/limits ברירת מחדל וערכי מינימום/מקסימום. זהו רשת ביטחון מפני קונטיינרים ללא הגבלות מפורשות.
איך להגדיר נכון ResourceQuota ו-LimitRange?
אנחנו מתחילים בביקורת: kubectl get resourcequota --all-namespaces חושף אילו מרחבי שמות חסרי מכסות. לאחר מכן, בודקים אילו פודים רצים ללא הגבלות: kubectl get pods --all-namespaces -o json | jq '.items[] | select(.spec.containers[].resources.requests == null)'. אחר כך מתכננים את ההיררכיה. סכמה טיפוסית לאשכול רב-דיירים:
| מרחב שמות | requests.cpu | limits.cpu | requests.memory | limits.memory | פודים |
|---|---|---|---|---|---|
| production | 20 | 40 | 40Gi | 80Gi | 100 |
| staging | 8 | 16 | 16Gi | 32Gi | 50 |
| dev | 4 | 8 | 8Gi | 16Gi | 30 |
LimitRange עבור dev נראה כך:
---
apiVersion: v1
kind: LimitRange
metadata:
name: dev-limits
namespace: dev
spec:
limits:
- type: Container
default:
cpu: 200m
memory: 256Mi
defaultRequest:
cpu: 100m
memory: 128Mi
max:
cpu: "2"
memory: 2Gi
min:
cpu: 50m
memory: 64Mi
ברירות מחדל הן רשת ביטחון: קונטיינר ללא משאבים מפורשים מקבל אוטומטית apiVersion: v1 kind: LimitRange metadata: name: dev-limits namespace: dev spec: limits: - type: Container default: cpu: 200m memory: 256Mi defaultRequest: cpu: 100m memory: 128Mi max: cpu: "2" memory: 2Gi min: cpu: 50m memory: 64Mi , ומונע ממנו לתפוס צומת שלם.
מה לעשות אם מכסות מתנגשות עם HPA?
מלכוד נוסף הוא LimitRange שמתנגש עם HPA. אם LimitRange קובע 100m/128Mi, ו-HPA מנסה להפעיל פוד עם max.cpu: 500m, הפוד לא ייווצר. אבחון עם limits.cpu: 1. הפתרון: או להעלות את המקסימום ב-LimitRange, או להגדיר את HPA בהתחשב בהגבלות אלה.
השוואה בין ResourceQuota ו-LimitRange: מה עדיף?
ResourceQuota הוא הטוב ביותר לשליטה בתקציב מרחב השמות, בעוד LimitRange מונע קונטיינרים בזבזניים. יחד הם מספקים שליטה מלאה. ResourceQuota מגביל עלויות כוללות בצורה יעילה יותר מאשר LimitRange לבדו, כי מכסות חלות על סכום כל הקונטיינרים. אבל ללא LimitRange, קונטיינרים עלולים להיעדר הגבלות מפורשות — ואז HPA יכול ליצור פודים שמרעיבים שכנים.
| תכונה | ResourceQuota | LimitRange |
|---|---|---|
| היקף | מרחב שמות | קונטיינר |
| מה הוא מגביל | משאבים כוללים, ספירות אובייקטים | CPU/זיכרון לכל קונטיינר |
| ברירות מחדל | לא | כן (default/request) |
תהליך יישום מכסות שלב אחר שלב
-
ביקורת מצב נוכחי: אספו את כל מרחבי השמות, בדקו מכסות והגבלות. השתמשו ב-
kubectl describe events -n namespace | grep FailedCreateובסקריפטים כדי למצוא פודים ללא משאבים. - ניתוח מדדים מ-30 הימים האחרונים: ייצאו צריכת CPU וזיכרון לכל מרחב שמות מ-Prometheus, קבעו ערכי שיא ומרווח ביטחון. זה הבסיס לתכנון המכסות.
- תכנון מכסות: לכל מרחב שמות, הגדירו requests ו-limits עם מרווח של 20-30% מעל השיא. קחו בחשבון קנה מידה אוטומטי ועומסי פרץ.
- כתיבת מניפסטים: צרו YAML עבור ResourceQuota ו-LimitRange. לאשכולות רב-דיירים, השתמשו בתבניות עם משתנים.
-
בדיקה על staging: החילו מכסות תחילה על dev ו-staging, בדקו לוגים ואירועים. שימו לב לשגיאות כמו
kubectl get resourcequota --all-namespaces. - פריסה לייצור: בהדרגה, עם ניטור דרך Alertmanager ב-85% ניצול מכסה.
-
תיעוד: רשמו את סכמת המכסות, כללי שינוי, runbook לשגיאות נפוצות (למשל,
exceeded quotaמ-LimitRange).
טעות אופיינית: מרחב שמות עם ResourceQuota נכשל ביצירת פודים. שגיאה: FailedCreate. פתרון: או הגדילו את המכסה, או מצאו מי מחזיק משאבים עם pods "app-xyz-7d9f" is forbidden: exceeded quota: dev-quota, requested: requests.cpu=500m, used: requests.cpu=9800m, limited: requests.cpu=10.
טעויות נפוצות בהגדרת מכסות
- הגדרת הגבלות נמוכות מדי, מה שמונע כל הזמן יצירת פודים
- התעלמות מ-LimitRange, כך שקונטיינרים ללא משאבים מפורשים מקבלים ברירות מחדל, אבל לא כל המפתחים מודעים לכך
- אי התחשבות בעומסי פרץ: מכסות לא צריכות להיות נוקשות; צריך מרווח של 20-30%
מה כלול בעבודה
- ביקורת של מרחבי שמות ופודים נוכחיים
- תכנון מכסות לפי עומס (איסוף מדדים מ-30 הימים האחרונים)
- כתיבת מניפסטים של ResourceQuota ו-LimitRange
- בדיקה על סביבת staging
- אינטגרציה עם Loki ו-Alertmanager להתראות
- תיעוד והעברת ידע לצוות
לוחות זמנים
הגדרה פשוטה ל-3–5 מרחבי שמות: יום אחד. אשכול רב-דיירים עם עשרות צוותים ואינטגרציית Prometheus: 2–3 ימים. חיסכון בעלויות ענן לאחר ההגדרה עד 30%, שבממוצע חודשי של כמה אלפי דולרים בהוצאות ענן מניב אפקט מוחשי. השקעה בהגדרת מכסות בדרך כלל מחזירה את עצמה תוך 1–2 חודשים.
צרו קשר לביקורת אשכול חינמית. המהנדסים שלנו יעזרו להגדיר מכסות ולהפחית עלויות. הזמינו את שירות הגדרת ResourceQuota ו-LimitRange — קבלו אשכול יציב וחיסכון בתקציב.
קראו עוד על ResourceQuota ו-LimitRange בתיעוד הרשמי.