הגדרת התאמה אופקית של קבוצות Pod לעומס

במאמר הזה מוסבר איך להגדיר התאמה אופקית של קבוצות Pod לעומס (Horizontal Pod Autoscaling,‏ HPA) לעומסי עבודה קיימים בלי שמירת מצב שפועלים באשכול. התאמה אוטומטית של מספר הפודים (רפליקות) באופן אופקי (Horizontal Pod Autoscaling, ‏ HPA) מתבצעת באופן אוטומטי לפי הביקוש בזמן אמת. המערכת מסירה פודים כשהעומס יורד ומוסיפה פודים כשהעומס עולה. ההתאמה הזו של הקיבולת חיונית כדי להבטיח את זמינות האפליקציה, שימוש יעיל במשאבים וחיסכון בעלויות, על ידי התאמה מדויקת של הקיבולת לתנועת המשתמשים ללא התערבות ידנית. ככל שהדרישות של עומס העבודה של הקונטיינר משתנות, התאמה אוטומטית לעומס של ה-Pod מבטלת את הצורך של האופרטורים לעקוב כל הזמן אחרי הביצועים ולשנות ידנית את מספר ה-Pod.

הדף הזה מיועד לאדמינים, לארכיטקטים ולמפעילים שמנהלים את מחזור החיים של התשתית הטכנית הבסיסית. מידע נוסף על תפקידים נפוצים ועל דוגמאות למשימות שאנחנו מתייחסים אליהן בתוכן זמין במאמר תפקידי משתמשים ומשימות נפוצים ב-GKE. Google Cloud

שינוי קנה מידה של פריסה

משתמשים בפונקציונליות של שינוי קנה המידה של Kubernetes כדי לשנות את קנה המידה של מספר ה-Pods שפועלים בפריסה בצורה מתאימה.

שינוי אוטומטי של מספר העותקים של פוד בפריסה

ב-Kubernetes יש התאמה אוטומטית לעומס, כך שלא צריך לעדכן את הפריסה באופן ידני כשהדרישה משתנה. כדי להגדיר שינוי אוטומטי של גודל ה-pods בפריסה:

  1. כדי להבטיח שהכלי Horizontal Pod Autoscaler יוכל למדוד את אחוז המעבד בצורה מתאימה, צריך להגדיר את בקשת משאבי המעבד בפריסה.

  2. מגדירים את הכלי האוטומטי לשינוי גודל של פודים אופקיים בפריסה:

    kubectl --kubeconfig CLUSTER_KUBECONFIG \
    -n NAMESPACE \
    autoscale deployment DEPLOYMENT_NAME \
    --cpu-percent=CPU_PERCENT \
    --min=MIN_NUMBER_REPLICAS \
    --max=MAX_NUMBER_REPLICAS

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLUSTER_KUBECONFIG: קובץ ה-kubeconfig של האשכול.

    • ‫NAMESPACE: מרחב השמות. במקרה של אשכולות משותפים, צריך להגדיר כאן מרחב שמות של פרויקט. במקרים של אשכולות רגילים, אפשר להשתמש בכל מרחב שמות.

    • ‫DEPLOYMENT_NAME: השם של הפריסה שרוצים להגדיר לה שינוי גודל אוטומטי.

    • ‫CPU_PERCENT: ממוצע ניצול המעבד (CPU) שרוצים להשיג, שמיוצג כאחוז, בכל הפודים.

    • ‫MIN_NUMBER_REPLICAS: הגבול התחתון של מספר ה-Pods שהמידרוג האוטומטי יכול להקצות.

    • ‫MAX_NUMBER_REPLICAS: המגבלה העליונה למספר הפודים שניתן להקצות באמצעות המידרוג האוטומטי.

  3. בודקים את הסטטוס הנוכחי של המידרוג האוטומטי של ה-Pods:

    kubectl get hpa

    הפלט אמור להיראות כך:

    NAME              REFERENCE                          TARGET    MINPODS   MAXPODS   REPLICAS   AGE
DEPLOYMENT_NAME   Deployment/DEPLOYMENT_NAME/scale   0% / 50%  1         10        1          18s

שינוי ידני של מספר ה-pods בפריסה

אם אתם מעדיפים לשנות את גודל הפריסה באופן ידני, מריצים את הפקודה:

kubectl --kubeconfig CLUSTER_KUBECONFIG \
    -n NAMESPACE \
    scale deployment DEPLOYMENT_NAME \
    --replicas NUMBER_OF_REPLICAS

מחליפים את מה שכתוב בשדות הבאים:

  • ‫CLUSTER_KUBECONFIG: קובץ ה-kubeconfig של האשכול.

  • ‫NAMESPACE: מרחב השמות. במקרה של אשכולות משותפים, צריך להגדיר כאן מרחב שמות של פרויקט. במקרים של אשכולות רגילים, אפשר להשתמש בכל מרחב שמות.

  • ‫DEPLOYMENT_NAME: השם של הפריסה שבה רוצים להגדיר שינוי גודל אוטומטי.

  • ‫DEPLOYMENT_NAME: מספר האובייקטים מסוג Pod ששוכפלו בפריסה.

שימוש במדדים מותאמים אישית מ-Prometheus להתאמה אוטומטית לעומס

כברירת מחדל, התכונה 'שינוי אוטומטי של מספר העותקים של הפודים (HPA)' משתמשת במדדי משאבים רגילים כמו שימוש במעבד (CPU) ובזיכרון. מדדים רגילים מתאימים להרחבה כללית, אבל לא שימושיים לעומסי עבודה מיוחדים של אפליקציות.

כשמשתמשים בהרחבת קיבולת אוטומטית של pods אופקית עם מדדים מותאמים אישית מ-Prometheus, אפשר לשנות את גודל עומסי העבודה על סמך מדדים ספציפיים לאפליקציה, כמו שיעורי בקשות HTTP, עומק התור וחביון העיבוד. האוסף יכול להגיב בצורה מדויקת יותר לביקוש בעולם האמיתי באמצעות הנתונים העשירים שכבר נאספו על ידי חבילת הניטור של Prometheus.

דרישות מוקדמות לשימוש ב-Prometheus עם התאמה אופקית של קבוצות Pod לעומס

כדי להפעיל את התכונה, התנאים הבאים צריכים להתקיים:

  • שרת Prometheus קיים: שרת Prometheus צריך להיות כבר פרוס ונגיש לרשת מתוך האשכול (בקר ה-HPA לא מנהל את מופע Prometheus עצמו). מידע נוסף זמין במאמר איך פורסים ומגדירים את Prometheus Operator ב-Kubernetes.

  • הרשאות אדמין: צריכות להיות לכם הרשאות שמאפשרות לשנות את משאב Cluster בהתאמה אישית.

  • אין התנגשויות ב-API: בדיקת טרום-טיסה מאמתת שאף רכיב אחר לא רשם כבר APIService עבור custom.metrics.k8s.io. אם יש התנגשות, אי אפשר להפעיל את המתאם.

הפעלה והגדרה של Prometheus

התהליך כולל הגדרה של כללי מדדים ועדכון של הגדרות האשכול:

  1. יוצרים ConfigMap אחד או יותר של כללי מדדים.

    מגדירים את הכללים מבוססי PromQL למדדים המותאמים אישית באחד או יותר מ-ConfigMaps במרחב השמות של אשכול היעד. הבקר עוקב אחרי ה-ConfigMap האלה, ממזג אותם ומחיל אותם אוטומטית על המתאם.

    מידע נוסף על הגדרת כללים זמין במאמר Metrics Discovery and Presentation Configuration ב-kubernetes-sigs/prometheus-adapter.

    בדוגמה הבאה מוצג ConfigMap עם כללים שמוגדרים ל-http_requests_per_second בשדה data:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: my-app-rules
  namespace: <cluster-namespace>
data:
  config.yaml: |
    rules:
    - seriesQuery: 'http_requests_total'
      resources:
        overrides:
          namespace_name: {resource: "namespace"}
          pod_name: {resource: "pod"}
      name:
        matches: "^(.*)_total$"
        as: "${1}_per_second"
      metricsQuery: 'sum(rate(<<.Series>>{<<.LabelMatchers>>}[5m])) by (<<.GroupBy>>)'

  2. אם שרת Prometheus שלכם דורש אימות, כמו אבטחת שכבת התעבורה ההדדית (mTLS), צריך ליצור סוד של Kubernetes בפורמט kubeconfig שמכיל את פרטי הכניסה הנדרשים.

    בדוגמה הבאה מוצג סוד שתומך באימות בסיסי:

    apiVersion: v1
kind: Secret
metadata:
  name: prometheus-auth-secret
  namespace: <cluster-namespace>
  annotations:
    baremetal.cluster.gke.io/mark-source: "true"
type: Opaque
stringData:
  config: authentication-credentials

  3. מעדכנים את המשאב המותאם אישית Cluster:

    1. מוסיפים את ההערה preview.baremetal.cluster.gke.io/metrics-adapter: "true" ל-metadata עבור המשאב המותאם אישית Cluster.

    2. מוסיפים את הקטע spec.metricsAdapter כדי להגדיר את כתובת ה-URL של Prometheus ולהפנות אל ConfigMaps של הכללים.

      apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: <cluster-name>
  namespace: <cluster-namespace>
  annotations:
    preview.baremetal.cluster.gke.io/metrics-adapter: "true"
spec:
  # ... other existing cluster configurations ...
  metricsAdapter:
    prometheus:
      url: "http://prometheus-k8s.monitoring.svc.cluster.local:9090"
      orgID: "production-environment"
      auth:
        configSecretRef:
          name: prometheus-auth-secret
          key: config # This is the key within the Secret's 'data' field
    rules:
      configMapKeyRefs:
        - name: my-app-rules
          key: config.yaml # This is the key within the ConfigMap's 'data' field
        # - name: base-system-rules
        #   key: config.yaml

      אם לא נדרש אימות במופע Prometheus שלכם, אפשר להשמיט את הקטע metricsAdapter.prometheus.auth ממפרט האשכול.

  4. מחילים את המשאב המותאם אישית Cluster המעודכן.

    הבקר פורס אוטומטית את Prometheus Adapter במרחב השמות kube-system.

  5. כדי להשתמש במדדים המותאמים אישית לצורך שינוי גודל אוטומטי של Pod אופקי, צריך ליצור משאב HorizontalPodAutoscaler שמטרגט את המדדים המותאמים אישית שהוגדרו בשדות של ConfigMaps rules.

    בדוגמה של ConfigMap משלב קודם הוגדר http_requests_per_secondמדד בהתאמה אישית. כדי להשתמש במדד הזה, משאב HorizontalPodAutoscaler צריך להיראות כמו בדוגמה הבאה:

    apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: <name>
  namespace: <namespace>
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: <workload-name>
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: 10

השבתת Prometheus

כדי להשבית את השימוש ב-Prometheus עם התאמה אוטומטית של מספר העותקים של הפודים, מסירים את הקטע spec.metricsAdapter ממקור המידע המותאם אישית של האשכול.