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

בדף הזה מוסבר איך לשנות את קנה המידה של הפריסות ב-Google Kubernetes Engine‏ (GKE) על ידי התאמה אוטומטית של המשאבים באמצעות מדדים כמו הקצאת משאבים, תעבורה של איזון עומסים, מדדים מותאמים אישית או כמה מדדים בו-זמנית. בדף הזה יש גם הוראות מפורטות להגדרת פרופיל של HorizontalPodAutoscaler (HPA), כולל הסברים על צפייה באובייקט HPA, מחיקה, ניקוי ופתרון בעיות. פריסה היא אובייקט Kubernetes API שמאפשר להפעיל כמה רפליקות של Pods שמפוזרות בין הצמתים באשכול.

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

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

  • מפעילים את ממשק Google Kubernetes Engine API.
    • הפעלת Google Kubernetes Engine API
  • כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
  • מוודאים שיש לכם קלאסטר קיים של Autopilot או Standard. אם אתם צריכים אשכול כזה, צרו אשכול Autopilot.

גרסאות API של אובייקטים מסוג HorizontalPodAutoscaler

כשמשתמשים במסוף Google Cloud , אובייקטים של HPA נוצרים באמצעות autoscaling/v2 API.

כשמשתמשים ב-kubectl כדי ליצור או להציג מידע על אובייקט HPA, אפשר לציין את API‏ autoscaling/v1 או את API‏ autoscaling/v2.

  • ‫apiVersion: autoscaling/v1 היא ברירת המחדל, ומאפשרת לכם לשנות את גודל המשאבים באופן אוטומטי רק על סמך ניצול יחידת העיבוד המרכזית (CPU). כדי להגדיר שינוי גודל אוטומטי על סמך מדדים אחרים, מומלץ להשתמש ב-apiVersion: autoscaling/v2. בדוגמה שבקטע יצירת פריסה לדוגמה נעשה שימוש ב-apiVersion: autoscaling/v1.

  • מומלץ להשתמש ב-apiVersion: autoscaling/v2 כדי ליצור אובייקטים חדשים של HPA. הוא מאפשר לכם להגדיר שינוי גודל אוטומטי על סמך מדדים מרובים, כולל מדדים מותאמים אישית או מדדים חיצוניים. בכל שאר הדוגמאות בדף הזה נעשה שימוש ב-apiVersion: autoscaling/v2.

כדי לבדוק אילו גרסאות API נתמכות, משתמשים בפקודה kubectl api-versions.

אפשר לציין באיזה API להשתמש כשמציגים פרטים על HPA שמשתמש ב-apiVersion: autoscaling/v2.

יצירת פריסה לדוגמה

כדי ליצור אובייקט HPA, צריך קודם ליצור את עומס העבודה שהוא מנטר. בדוגמאות שבדף הזה מיושמות תצורות שונות של HPA על הפריסה הבאה: nginx בדוגמאות נפרדות מוצג HPA שמבוסס על ניצול משאבים, על מדד מותאם אישית או חיצוני ועל כמה מדדים.

שומרים את הטקסט הבא בקובץ בשם nginx.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
        resources:
          # You must specify requests for CPU to autoscale
          # based on CPU utilization
          requests:
            cpu: "250m"

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

כדי ליצור את הפריסה, מחילים את המניפסט nginx.yaml:

kubectl apply -f nginx.yaml

ההגדרה של spec.replicas בפריסה היא 3, ולכן נפרסים שלושה פודים. אפשר לאמת את זה באמצעות הפקודה kubectl get deployment nginx.

כל אחת מהדוגמאות בדף הזה מחילה אובייקט HPA שונה על פריסת nginx לדוגמה.

שינוי גודל אוטומטי על סמך ניצול משאבים

בדוגמה הזו נוצר אובייקט HPA כדי להגדיל או להקטין את מספר העותקים של nginxפריסת Deployment באופן אוטומטי כשניצול המעבד (CPU) עולה על 50%. כך אפשר לוודא שתמיד יהיה לפחות עותק אחד ומקסימום 10 עותקים.

אפשר ליצור HPA שמטרגט CPU באמצעות Google Cloud המסוף, הפקודה kubectl apply או, רק עבור CPU ממוצע, הפקודה kubectl autoscale.

המסוף

  1. נכנסים לדף Workloads במסוף Google Cloud .

    כניסה לדף Workloads

  2. לוחצים על השם של nginx הפריסה.

  3. לוחצים על פעולות > עריכת שינוי גודל אוטומטי.

  4. בקטע התאמה אופקית של קבוצות Pod לעומס, לוחצים על Select and configure.

  5. מציינים את הערכים הבאים:

    • מספר העותקים המינימלי: 1
    • מספר העותקים המקסימלי: 10
    • מדד להתאמה לעומס: CPU
    • יעד: 50
    • יחידה: מעבדים

  6. לוחצים על שליחה.

kubectl apply

שומרים את מניפסט ה-YAML הבא כקובץ בשם nginx-hpa.yaml:

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: nginx
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  # Set the minimum and maximum number of replicas the Deployment can scale to.
  minReplicas: 1
  maxReplicas: 10
  # The target average CPU utilization percentage across all Pods.
  targetCPUUtilizationPercentage: 50

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

כדי ליצור את ה-HPA, מפעילים את המניפסט באמצעות הפקודה הבאה:

kubectl apply -f nginx-hpa.yaml

kubectl autoscale

כדי ליצור אובייקט HPA שמטרגט רק את השימוש הממוצע במעבד, אפשר להשתמש בפקודה kubectl autoscale:

kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10

כדי לקבל רשימה של HPAs באשכול, משתמשים בפקודה הבאה:

kubectl get hpa

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

NAME    REFERENCE          TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
nginx   Deployment/nginx   0%/50%    1         10        3          61s

כדי לקבל פרטים על HPA, אפשר להשתמש במסוף Google Cloud או בפקודה kubectl.

המסוף

  1. נכנסים לדף Workloads במסוף Google Cloud .

    כניסה לדף Workloads

  2. לוחצים על השם של nginx הפריסה.

  3. לוחצים על הכרטיסייה התאמה.

kubectl get

כדי לקבל פרטים על HPA, אפשר להשתמש בפקודה kubectl get hpa עם הדגל -o yaml. השדה status מכיל מידע על המספר הנוכחי של העותקים ועל אירועים אחרונים של שינוי גודל אוטומטי.

kubectl get hpa nginx -o yaml

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

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  annotations:
    autoscaling.alpha.kubernetes.io/conditions: '[{"type":"AbleToScale","status":"True","lastTransitionTime":"2019-10-30T19:42:59Z","reason":"ScaleDownStabilized","message":"recent
      recommendations were higher than current one, applying the highest recent recommendation"},{"type":"ScalingActive","status":"True","lastTransitionTime":"2019-10-30T19:42:59Z","reason":"ValidMetricFound","message":"the
      HPA was able to successfully calculate a replica count from cpu resource utilization
      (percentage of request)"},{"type":"ScalingLimited","status":"False","lastTransitionTime":"2019-10-30T19:42:59Z","reason":"DesiredWithinRange","message":"the
      desired count is within the acceptable range"}]'
    autoscaling.alpha.kubernetes.io/current-metrics: '[{"type":"Resource","resource":{"name":"cpu","currentAverageUtilization":0,"currentAverageValue":"0"}}]'
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"autoscaling/v1","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"maxReplicas":10,"minReplicas":1,"scaleTargetRef":{"apiVersion":"apps/v1","kind":"Deployment","name":"nginx"},"targetCPUUtilizationPercentage":50}}
  creationTimestamp: "2019-10-30T19:42:43Z"
  name: nginx
  namespace: default
  resourceVersion: "220050"
  selfLink: /apis/autoscaling/v1/namespaces/default/horizontalpodautoscalers/nginx
  uid: 70d1067d-fb4d-11e9-8b2a-42010a8e013f
spec:
  maxReplicas: 10
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  targetCPUUtilizationPercentage: 50
status:
  currentCPUUtilizationPercentage: 0
  currentReplicas: 3
  desiredReplicas: 3

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

לפני שממשיכים לדוגמאות שבהמשך הדף, צריך למחוק את ה-HPA:

kubectl delete hpa nginx

כשמוחקים אובייקט HPA, מספר הרפליקות של הפריסה נשאר ללא שינוי. פריסה לא חוזרת אוטומטית למצב שלה לפני שהוחל עליה HPA.

מידע נוסף על מחיקת HPA

התאמה אוטומטית לעומס (autoscaling) על סמך תנועה במאזן העומסים

התאמה אוטומטית לעומס (automatic scaling) על סמך תנועה היא יכולת של GKE שמשלבת אותות של ניצול תנועה ממאזני עומסים כדי להתאים אוטומטית את מספר ה-Pods.

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

התכונה 'שינוי גודל אוטומטי על סמך נפח התנועה' מופעלת על ידי בקר שער והיכולות שלו של ניהול תנועה גלובלי. מידע נוסף על שינוי גודל אוטומטי על סמך תנועה

שינוי גודל אוטומטי על סמך תנועה במאזן עומסים זמין רק עבור עומסי עבודה של שערים.

דרישות

כדי להשתמש בהתאמה אוטומטית לעומס על סמך תנועה, צריך לעמוד בדרישות הבאות:

  • נתמך ב-GKE מגרסה 1.31 ואילך.
  • ‫Gateway API מופעל בפרויקט.
  • התמיכה רלוונטית לתנועה שעוברת דרך מאזני עומסים שנפרסו באמצעות Gateway API ו-GatewayClass‏ gke-l7-global-external-managed,‏ gke-l7-regional-external-managed,‏ gke-l7-rilb או gke-l7-gxlb.

מגבלות

יש כמה מגבלות לשינוי גודל אוטומטי על סמך תנועת גולשים:

  • אין תמיכה ב-GatewayClasses מרובי-אשכולות (gke-l7-global-external-managed-mc, ‏gke-l7-regional-external-managed-mc, ‏gke-l7-rilb-mc ו-gke-l7-gxlb-mc).
  • אין תמיכה בתנועה שמשתמשת בשירותים מסוג LoadBalancer.
  • צריך להיות קשר ברור ומבודד בין הרכיבים שמשתתפים בהתאמת קנה מידה אוטומטית על סמך תנועה. אובייקט HPA אחד צריך להיות מוקדש להרחבת פריסה אחת (או כל משאב ניתן להרחבה) שנחשפת על ידי שירות אחד.
  • אחרי שמגדירים את הקיבולת של השירות באמצעות השדה maxRatePerEndpoint, צריך להמתין מספיק זמן (בדרך כלל דקה אחת, אבל יכול להיות שיידרשו עד 15 דקות באשכולות גדולים) עד שמאזן העומסים יתעדכן בשינוי הזה, לפני שמגדירים את HPA עם מדדים שמבוססים על תעבורה. הגישה הזו עוזרת לוודא שלא יהיה מצב זמני בשירות שבו האשכול מנסה לשנות את גודלו באופן אוטומטי על סמך מדדים שמונפקים על ידי איזון עומסים שעדיין נמצא בתהליך הגדרה.
  • אם נעשה שימוש בהתאמת קנה מידה אוטומטית על סמך תנועה בשירות שמופעל על ידי כמה מאזני עומסים (לדוגמה – על ידי Ingress וגם על ידי Gateway, או על ידי שני Gateways), יכול להיות ש-HPA ישתמש בערך התנועה הגבוה ביותר ממאזני עומסים נפרדים כדי לקבל החלטות לגבי שינוי קנה המידה, במקום בסכום של ערכי התנועה מכל מאזני העומסים.

פריסת התאמה אוטומטית לעומס (autoscaling) על סמך נפח התנועה

בתרגיל הבא נעשה שימוש ב-HPA כדי להגדיל או להקטין באופן אוטומטי את מספר העותקים של פריסת store-autoscale על סמך התנועה שהיא מקבלת. שער מקבל תנועת כניסה מהאינטרנט עבור קבוצות ה-Pod. הכלי לשינוי גודל אוטומטי משווה בין אותות התנועה מהשער לבין קיבולת התנועה לכל Pod שמוגדרת במשאב השירות store-autoscale. יצירת תנועה אל שער הכניסה משפיעה על מספר ה-Pods שנפרסו.

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

הגדלת קנה מידה של פריסה באמצעות HorizontalPodAutoscaler (HPA) על סמך תנועה.

כדי לפרוס שינוי גודל אוטומטי על סמך תנועה:

  1. במקרים של אשכולות Standard, מוודאים שרכיבי GatewayClasses מותקנים באשכול. באשכולות במצב Autopilot, מחלקות השער מותקנות כברירת מחדל.

    kubectl get gatewayclass

    הפלט מאשר שמשאבי GKE GatewayClass מוכנים לשימוש באשכול:

    NAME                               CONTROLLER                  ACCEPTED   AGE
gke-l7-global-external-managed     networking.gke.io/gateway   True       16h
gke-l7-regional-external-managed   networking.gke.io/gateway   True       16h
gke-l7-gxlb                        networking.gke.io/gateway   True       16h
gke-l7-rilb                        networking.gke.io/gateway   True       16h

    אם הפלט הזה לא מופיע, צריך להפעיל את Gateway API באשכול GKE.

  2. פורסים את האפליקציה לדוגמה ואת מאזן העומסים של שער הכניסה לאשכול:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/store-autoscale.yaml

    אפליקציית הדוגמה יוצרת:

    • ‫Deployment עם 2 רפליקות.
    • שירות עם הגדרה משויכת GCPBackendPolicy maxRatePerEndpointשמוגדרת לערך 10. מידע נוסף על היכולות של Gateway
    • שער חיצוני לגישה לאפליקציה באינטרנט. מידע נוסף על שימוש בשערי איזון עומסים זמין במאמר פריסת שערים.
    • ‫HTTPRoute שתואם לכל תעבורת הנתונים ושולח אותה לשירות store-autoscale.

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

    מידע נוסף זמין במאמר בנושא קביעת הקיבולת של השירות.

  3. שומרים את קובץ המניפסט הבא בשם hpa.yaml:

    apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: store-autoscale
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: store-autoscale
  # Set the minimum and maximum number of replicas the Deployment can scale to.
  minReplicas: 1
  maxReplicas: 10
  # This section defines that scaling should be based on the fullness of load balancer
  # capacity, using the following configuration.
  metrics:
  - type: Object
    object:
      describedObject:
        kind: Service
        name: store-autoscale
      metric:
        # The name of the custom metric which measures how "full" a backend is
        # relative to its configured capacity.
        name: "autoscaling.googleapis.com|gclb-capacity-fullness"
      target:
        # The target average value for the metric. The autoscaler adjusts the number
        # of replicas to maintain an average capacity fullness of 70% across all Pods.
        averageValue: 70
        type: AverageValue

    קובץ המניפסט הזה מתאר אובייקט HPA עם המאפיינים הבאים:

    • ‫minReplicas ו-maxReplicas: הגדרת מספר העותקים המינימלי והמקסימלי של הפריסה הזו. בהגדרה הזו, מספר ה-Pods יכול לנוע בין 1 ל-10 רפליקות.
    • ‫describedObject.name: store-autoscale: ההפניה לשירות store-autoscale שמגדיר את קיבולת התנועה.
    • ‫scaleTargetRef.name: store-autoscale: ההפניה אל store-autoscaleהפריסה שמגדירה את המשאב שמשנה את הגודל שלו באמצעות HPA.
    • ‫averageValue: 70: ערך היעד הממוצע של ניצול הקיבולת הוא 70%. כך HPA מקבל מרווח צמיחה, כדי שה-Pods הפועלים יוכלו לעבד תנועה עודפת בזמן שנוצרים Pods חדשים.

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

השימוש ב-HPA מוביל להתנהגות הבאה של התנועה:

  • מספר ה-Pods מותאם בין 1 ל-10 רפליקות כדי להשיג 70% מהקצב המקסימלי לכל נקודת קצה. התוצאה היא 7 בקשות לשנייה לכל Pod כשמגדירים את הערך maxRatePerEndpoint=10.
  • אם יש יותר מ-7 בקשות לשנייה לכל פוד, המערכת מגדילה את הפודים עד שמגיעים למקסימום של 10 רפליקות או עד שהתנועה הממוצעת היא 7 בקשות לשנייה לכל פוד.
  • אם נפח התנועה יורד, ה-Pods מצטמצמים לקצב סביר באמצעות אלגוריתם HPA.

אפשר גם לפרוס מחולל תנועה כדי לאמת את ההתנהגות של שינוי גודל אוטומטי על סמך תנועה.

ב-30 RPS, הפריסה מותאמת ל-5 רפליקות, כך שכל רפליקה מקבלת באופן אידיאלי 6 RPS של תנועה, שהם 60% ניצול לכל Pod. הערך הזה נמוך מ-70% (יעד הניצול), ולכן ה-Pods מותאמים בהתאם. בהתאם לשינויים בתעבורה, יכול להיות שגם מספר הרפליקות שמוגדרות להתאמה אוטומטית ישתנה. תיאור מפורט יותר של אופן החישוב של מספר העותקים זמין במאמר התנהגות עם התאמה לעומס (autoscaling).

שינוי גודל אוטומטי על סמך מדד מותאם אישית או מדד חיצוני

כדי לבצע קנה מידה על סמך מדדים מותאמים אישית, אתם יכולים לחשוף מדדים מותאמים אישית (גרסת Preview) ולשלוח את המדדים מ-Pod או מעומס עבודה ישירות למנגנון לשינוי גודל אוטומטי.

לגבי מדדים חיצוניים (כמו Pub/Sub), אפשר לעיין בדוגמה ל-HPA ב-Pub/Sub.

התאמה אוטומטית של נפח האחסון על סמך כמה מדדים

בדוגמה הזו נוצר אובייקט HPA שמבצע שינוי גודל אוטומטי על סמך ניצול המעבד ומדד מותאם אישית בשם packets_per_second.

אם פעלתם לפי הדוגמה הקודמת ועדיין יש לכם אובייקט HPA בשם nginx, תמחקו אותו לפני שתפעלו לפי הדוגמה הזו.

בדוגמה הזו נדרש apiVersion: autoscaling/v2. מידע נוסף על ממשקי ה-API הזמינים מופיע במאמר גרסאות API לאובייקטים של HPA.

שומרים את מניפסט ה-YAML הזה כקובץ בשם nginx-multiple.yaml:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  minReplicas: 1
  maxReplicas: 10
  metrics: # The metrics to base the autoscaling on.
  - type: Resource
    resource:
      name: cpu # Scale based on CPU utilization.
      target:
        type: Utilization
        averageUtilization: 50
        # The HPA will scale the replicas to try and maintain an average
        # CPU utilization of 50% across all Pods.
  - type: Resource
    resource:
      name: memory # Scale based on memory usage.
      target:
        type: AverageValue
        averageValue: 100Mi
        # The HPA will scale the replicas to try and maintain an average
        # memory usage of 100 Mebibytes (MiB) across all Pods.
  # Uncomment these lines if you create the custom packets_per_second metric and
  # configure your app to export the metric.
  # - type: Pods
  #   pods:
  #     metric:
  #       name: packets_per_second
  #     target:
  #       type: AverageValue
  #       averageValue: 100

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

החלת מניפסט YAML:

kubectl apply -f nginx-multiple.yaml

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

הגדרת פרופיל הביצועים של HPA

פרופיל ה-HPA של הביצועים משפר את זמן התגובה של התאמה אופקית של קבוצות Pod לעומס, ועוזר לשפר את היכולת של ה-HPA לטפל במספר גדול של אובייקטים (עד 1,000 אובייקטים בגרסאות משניות 1.31 עד 1.32 ו-5,000 אובייקטים בגרסה 1.33 ואילך).

הפרופיל הזה מופעל אוטומטית באשכולות Autopilot שעומדים בדרישות, עם מישור בקרה שמריץ את GKE בגרסה 1.32 ואילך. באשכולות Standard, הפרופיל מופעל אוטומטית באשכולות שעומדים בדרישות עם מישור בקרה שפועל בגרסת GKE 1.33 ואילך.

אשכול רגיל פטור מהפעלה אוטומטית של פרופיל HPA לביצועים אם הוא עומד בכל התנאים הבאים:

  • האשכול משודרג מגרסה קודמת לגרסה 1.33 ואילך.
  • ל-cluster יש לפחות מאגר צמתים אחד עם אחד מסוגי המכונות הבאים: e2-micro, e2-custom-micro, g1-small, f1-micro.
  • הקצאת צמתים אוטומטית (NAP) לא מופעלת.

אפשר גם להפעיל את פרופיל ה-HPA של הביצועים באשכולות קיימים שעומדים בדרישות.

דרישות

כדי להפעיל את פרופיל ה-HPA של הביצועים, צריך לוודא שקלאסטרים של Autopilot וקלאסטרים רגילים עומדים בדרישות הבאות:

הפעלת פרופיל HPA לשיפור הביצועים

כדי להפעיל את פרופיל ה-HPA של הביצועים באשכול, משתמשים בפקודה הבאה:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --hpa-profile=performance

מחליפים את:

  • ‫CLUSTER_NAME: שם האשכול.
  • ‫LOCATION: אזור או אזור מחשוב (לדוגמה, us-central1-a או us-central1) של האשכול.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

השבתה של פרופיל הביצועים של HPA

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

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --hpa-profile=none

מחליפים את:

  • ‫CLUSTER_NAME: שם האשכול.
  • ‫LOCATION: אזור או אזור מחשוב (לדוגמה, us-central1-a או us-central1) של האשכול.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

הצגת פרטים על HorizontalPodAutoscaler

כדי לראות את ההגדרות והסטטיסטיקות של HPA, משתמשים בפקודה הבאה:

kubectl describe hpa HPA_NAME

מחליפים את HPA_NAME בשם של אובייקט ה-HPA.

אם ה-HPA משתמש ב-apiVersion: autoscaling/v2 ומבוסס על כמה מדדים, הפקודה kubectl describe hpa מציגה רק את מדד ה-CPU. כדי לראות את כל המדדים, משתמשים בפקודה הבאה:

kubectl describe hpa.v2.autoscaling HPA_NAME

מחליפים את HPA_NAME בשם של אובייקט ה-HPA.

הסטטוס הנוכחי של כל אובייקט HPA מוצג בשדה Conditions, ואירועי שינוי גודל אוטומטי מפורטים בשדה Events.

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

Name:                                                  nginx
Namespace:                                             default
Labels:                                                <none>
Annotations:                                           kubectl.kubernetes.io/last-applied-configuration:
                                                         {"apiVersion":"autoscaling/v2","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"s...
CreationTimestamp:                                     Tue, 05 May 2020 20:07:11 +0000
Reference:                                             Deployment/nginx
Metrics:                                               ( current / target )
  resource memory on pods:                             2220032 / 100Mi
  resource cpu on pods  (as a percentage of request):  0% (0) / 50%
Min replicas:                                          1
Max replicas:                                          10
Deployment pods:                                       1 current / 1 desired
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True    ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from memory resource
  ScalingLimited  False   DesiredWithinRange  the desired count is within the acceptable range
Events:                                                <none>

מחיקת HorizontalPodAutoscaler

אפשר למחוק אובייקט HPA באמצעות מסוף Google Cloud או הפקודה kubectl delete.

המסוף

כדי למחוק את אובייקט ה-nginx HPA:

  1. נכנסים לדף Workloads במסוף Google Cloud .

    כניסה לדף Workloads

  2. לוחצים על השם של nginx הפריסה.

  3. לוחצים על פעולות > שינוי גודל אוטומטי.

  4. לוחצים על Delete.

kubectl delete

כדי למחוק את אובייקט ה-HPA‏ nginx, משתמשים בפקודה הבאה:

kubectl delete hpa nginx

כשמוחקים אובייקט HPA, הפריסה (או אובייקט פריסה אחר) נשארת בקנה המידה הקיים, ולא חוזרת למספר הרפליקות במניפסט המקורי של הפריסה. כדי לשנות את קנה המידה של הפריסה באופן ידני בחזרה לשלושה Pod, אפשר להשתמש בפקודה kubectl scale:

kubectl scale deployment nginx --replicas=3

סידור וארגון

  1. אם עדיין לא עשיתם זאת, מחקו את אובייקט ה-HPA:

    kubectl delete hpa nginx

  2. מחיקת הפריסה nginx:

    kubectl delete deployment nginx

  3. אפשר גם למחוק את האשכול.

פתרון בעיות

עצות לפתרון בעיות זמינות במאמר בנושא פתרון בעיות של התאמה אופקית של קבוצות Pod לעומס.

המאמרים הבאים