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

התאמה אופקית של קבוצות Pod לעומס מאפשרת לכם לשנות באופן אוטומטי את מספר קבוצות ה-Pod שפועלות בעומסי עבודה קיימים ללא שמירת מצב (stateless) באשכול, על סמך הביקוש בזמן אמת. הכלי להגדלת קנה מידה באופן אוטומטי מוסיף Pods כשהעומס גדל ומסיר אותם כשהביקוש יורד. כך אפשר לשמור על זמינות האפליקציה, להשתמש במשאבים ביעילות ולשלוט בעלויות בלי התערבות ידנית. אפשר לשנות את קנה המידה על סמך מדדי משאבים סטנדרטיים, כמו ניצול המעבד (CPU), או על סמך מדדי אפליקציות בהתאמה אישית מ-Prometheus, כמו קצבי בקשות HTTP.

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

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

התאמה אוטומטית לעומס של ה-Pods ב-Deployment

ב-Kubernetes יש התאמה אוטומטית לעומס, כך שלא צריך לעדכן ידנית את הפריסה כשהביקוש משתנה. השלם את השלבים הבאים כדי להתאים אוטומטית לעומס (autoscale) את ה-Pods של ה-Deployment (פריסה):

1. כדי לוודא שה-Horizontal Pod Autoscaler יכול למדוד כראוי את אחוז המעבד (CPU), מגדירים את בקשת משאב המעבד (CPU) בפריסה.

2. מגדירים את ה-Horizontal Pod Autoscaler (HPA) בפריסה:

   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) שצריך לבקש, מיוצג באחוזים, בכל ה-pods.

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

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

3. בודקים את הסטטוס הנוכחי של ה-Horizontal Pod Autoscaler:

   kubectl get hpa
   

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

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

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

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

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

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

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

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

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

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

שימוש במדדים מותאמים אישית מ-Prometheus להתאמה לעומס (autoscaling)

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

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

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

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

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

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

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

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

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

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

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

   למידע נוסף על הגדרת כללים, ראו 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. מעדכנים את המשאב המותאם אישית של האשכול:

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

   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. מחילים את המשאב המותאם אישית המעודכן של האשכול.

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

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

   הדוגמה של 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 עם התאמה אופקית של קבוצות Pod לעומס, מסירים את הקטע spec.metricsAdapter מהמשאב המותאם אישית של האשכול.