ResourceQuota ו-LimitRange: בידוד משאבים עבור דיירים ב-Kubernetes

כאשר דייר אחד מריץ עבודת אצווה אינטנסיבית במשאבים בסביבה מרובת דיירים, שירותים אחרים מתדרדרים—זוהי תחרות על משאבים. ללא מכסות משאבים, אין לך שליטה על הצריכה. באשכול עם 30+ דיירים, 10% מהצמתים עשויים להשתמש ב-200% CPU עבור מטמונים, ולהשאיר שכנים ללא זמן מעבד. הדרך היחידה להבטיח יציבות היא להגדיר ResourceQuota ו-LimitRange עבור כל מרחב שמות. ResourceQuota ו-LimitRange הם יסודיים עבור ריבוי דיירים ובידוד משאבים ב-Kubernetes. המהנדסים שלנו, עם ניסיון של למעלה מ-5 שנים ב-Kubernetes ו-100+ פרויקטים של בידוד משאבים, עושים זאת במפתח מלא—מביקורת ועד ניטור. הערכת פרויקט אורכת יומיים, יישום מלא 2 עד 5 ימים. חיסכון ממוצע לאחר יישום מכסות: $1,800 לחודש עבור אשכול של 30 צמתים (בתעריפי ענן סטנדרטיים). עלות משאבים מבוזבזים ללא מכסות יכולה להגיע ל-$3,600 לחודש. לקוח אחד הפחית את עלויות הענן ב-$2,500 לחודש לאחר יישום מכסות, ואחר חסך $3,000 לחודש. עלות ביקורת טיפוסית היא $500, ויישום מלא מתחיל ב-$2,000, עם החזר השקעה בדרך כלל תוך 3 חודשים.

ResourceQuota לבדה מונעת כ-70% ממקרי תחרות המשאבים; בשילוב עם LimitRange וניטור, היעילות עולה ל-95%—פי שלושה יותר מאשר ללא LimitRange. הלקוחות שלנו חוסכים עד 40% על משאבי ענן באמצעות חלוקת מכסות יעילה. מכסות ומגבלות מוגדרות כראוי מפחיתות עלויות מופעים ב-30-50%.

פתרון בעיית השכן הרועש עם ResourceQuota ו-LimitRange

ResourceQuota מגביל את צריכת המשאבים המצטברת במרחב שמות. Kubernetes ידחה יצירת Pods חדשים אם הוספתם תפר את המכסה:

---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-standard
  namespace: tenant-acme
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    pods: "40"
    services.loadbalancers: "2"
    services.nodeports: "0"
    count/deployments.apps: "20"
    count/jobs.batch: "10"
    persistentvolumeclaims: "15"
    requests.storage: "100Gi"
    gold.storageclass.storage.k8s.io/requests.storage: "50Gi"
---

apiVersion: v1 kind: ResourceQuota metadata: name: tenant-standard namespace: tenant-acme spec: hard: requests.cpu: "4" requests.memory: "8Gi" limits.cpu: "8" limits.memory: "16Gi" pods: "40" services.loadbalancers: "2" services.nodeports: "0" count/deployments.apps: "20" count/jobs.batch: "10" persistentvolumeclaims: "15" requests.storage: "100Gi" gold.storageclass.storage.k8s.io/requests.storage: "50Gi" חוסם שירותי NodePort עבור דיירים—מדיניות אבטחה נפוצה באשכולות מרובי דיירים.

services.nodeports: "0" מגביל StorageClass ספציפי. הדייר יכול להשתמש באחסון סטנדרטי זול ללא הגבלות (עד למגבלה הגלובלית), אך SSD יקר מוגבל ל-50 Gi.

לאחר יצירת ResourceQuota, Kubernetes דורש gold.storageclass.storage.k8s.io/requests.storage: "50Gi" ו-requests מפורשים בכל Pod. אם ל-Pod אין בקשות, הוא לא ייווצר (שגיאה: limits). התנהגות בלתי צפויה זו שוברת פריסות עבור צוותים שלא רגילים לציין משאבים. מניסיוננו, זו אחת הבעיות הנפוצות ביותר בעת פריסת מכסות.

מדוע LimitRange הכרחית עבור ResourceQuota?

must specify requests for cpu פועלת ברמת Pod/Container בודד. היא מגדירה:

• ברירת מחדל LimitRange ו-requests אם לא צוינו במפורש
• ערכי מינימום ומקסימום
• יחס מקסימלי limit/request (LimitRequestRatio)

---
apiVersion: v1
kind: LimitRange
metadata:
  name: tenant-limits
  namespace: tenant-acme
spec:
  limits:
    - type: Container
      default:
        cpu: "500m"
        memory: "256Mi"
      defaultRequest:
        cpu: "100m"
        memory: "64Mi"
      max:
        cpu: "2"
        memory: "2Gi"
      min:
        cpu: "50m"
        memory: "32Mi"
    - type: PersistentVolumeClaim
      max:
        storage: "20Gi"
      min:
        storage: "1Gi"

limits—אם Pod נוצר ללא apiVersion: v1 kind: LimitRange metadata: name: tenant-limits namespace: tenant-acme spec: limits: - type: Container default: cpu: "500m" memory: "256Mi" defaultRequest: cpu: "100m" memory: "64Mi" max: cpu: "2" memory: "2Gi" min: cpu: "50m" memory: "32Mi" - type: PersistentVolumeClaim max: storage: "20Gi" min: storage: "1Gi" , LimitRange מכניסה אותם אוטומטית. זה פותר את בעיית ResourceQuota הדורשת מגבלות מפורשות: גם אם מפתח שוכח לכתוב default, ה-Pod נוצר עם ערכי ברירת מחדל מ-LimitRange.

limits מגביל פרצי עומס. resources: כאן שווה ל-20—הקונטיינר יכול לבקש 100m CPU ולפרוץ ל-2000m. כדי להגביל פרצים:

 - type: Container maxLimitRequestRatio: cpu: "4" 

כעת אם request = 100m, limit לא יכול לעלות על 400m.

הגדרת ResourceQuota ו-LimitRange עבור אשכול מרובה דיירים

SaaS אמיתי בדרך כלל כולל מספר תוכניות עם מגבלות שונות. נוח לנהל באמצעות אופרטור מותאם אישית או תבניות Helm, אך המבנה פשוט. השווה תוכניות בטבלה:

בשדרוג תוכנית, אנו מעדכנים את ResourceQuota ו-LimitRange במרחב השמות של הדייר באמצעות Helm upgrade או Kubernetes API.

מדריך יישום מכסות שלב אחר שלב

1. הגדר רמות שירות ומגבלות מתאימות (טבלה למעלה).
2. צור ResourceQuota עבור כל מרחב שמות, כולל משאבי LimitRequestRatio ו-max.cpu / defaultRequest.cpu.
3. צור LimitRange כך שלכל ה-Pods יהיו בקשות מינימליות ומגבלות מפורשות.
4. בדוק: נסה ליצור Pod שחורג מהמגבלות—הוא אמור להידחות.
5. הגדר ניטור (kube-state-metrics) והתראה ב-80% שימוש במכסה.

בעיות טיפוסיות בעת יישום מכסות

פעולות כאשר המכסה מוצתה

ראשית, הגדר ניטור של שימוש במכסות. מדדים מרכזיים באמצעות kube-state-metrics:

# Использование CPU-квоты тенантом
kube_resourcequota{namespace="tenant-acme", resource="requests.cpu", type="used"} / kube_resourcequota{namespace="tenant-acme", resource="requests.cpu", type="hard"}

התראה כאשר שימוש במכסה עולה על 80%—הדייר יגיע בקרוב למגבלה. הודע לו או הצע שדרוג. עבור תוכנית ארגוני, אנו מבטיחים שמגבלות לא יהוו בעיה ומספקים runbook להרחבה מהירה.

הגבלת קצב API

מגבלות משאבים של Kubernetes אינן משפיעות על ה-API של היישום שלך—יש לטפל בכך בנפרד. עבור הגבלת קצב, השתמש ב-Istio EnvoyFilter או Kong/Nginx:

---
# Istio EnvoyFilter для rate limiting
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: filter-ratelimit
  namespace: tenant-acme
spec:
  workloadSelector:
    labels:
      app: api-gateway
  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: SIDECAR_INBOUND
      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.filters.http.local_ratelimit
          typed_config:
            "@type": type.googleapis.com/udpa.type.v1.TypedStruct
            token_bucket:
              max_tokens: 1000
              tokens_per_fill: 1000
              fill_interval: 60s

מה כלול בעבודה

אנו מספקים:

• דוח ביקורת המזהה בעיות תחרות משאבים
• תבניות ResourceQuota ו-LimitRange התואמות לרמות השירות שלך
• יישום באמצעות Terraform, Ansible או Helm
• לוחות מחוונים לניטור והתראות על שימוש במכסות
• תיעוד והדרכת צוות
• שבועיים של תמיכה לאחר השחרור עם ערבות יציבות

זמן הגדרה משוער: יומיים עד חמישה ימים בהתאם למורכבות. העלות נקבעת לאחר ביקורת. למידע מפורט יותר על ResourceQuota ו-LimitRange, עיין בתיעוד הרשמי של Kubernetes Resource Quotas.

אם אתה רוצה למנוע בעיות ביצועים באשכול מרובה הדיירים שלך, קבע ביקורת. המהנדסים שלנו, עם ניסיון של למעלה מ-5 שנים בשוק הייעוץ של Kubernetes ו-100+ פרויקטים שהושלמו, יעזרו לך להגדיר בידוד אידיאלי. עם ניסיון של 5+ שנים ו-100+ פריסות מוצלחות, אנו מבטיחים תוצאות אמינות. הזמן ביקורת והגדרת מכסות עבור האשכול מרובה הדיירים שלך—קבל ייעוץ היום.