בדף הזה מוסבר איך לשנות את קנה המידה של הפריסות ב-Google Kubernetes Engine (GKE) על ידי התאמה אוטומטית של המשאבים באמצעות מדדים כמו הקצאת משאבים, תעבורה של איזון עומסים, מדדים מותאמים אישית או כמה מדדים בו-זמנית. בדף הזה מופיעות גם הוראות מפורטות להגדרת פרופיל HorizontalPodAutoscaler (HPA), כולל איך להציג, למחוק, לנקות ולפתור בעיות באובייקט ה-HPA. פריסה היא אובייקט של Kubernetes API שמאפשר להריץ כמה רפליקות של Pods שמופצים בין הצמתים באשכול.
הדף הזה מיועד למפתחים ולאנשי תפעול שמנהלים את ההתאמה לעומס של אפליקציות ב-GKE ורוצים להבין איך לבצע אופטימיזציה דינמית של הביצועים ולשמור על יעילות העלויות באמצעות התאמה אופקית של קבוצות Pod לעומס. למידע נוסף על תפקידים נפוצים ומשימות לדוגמה שמוזכרות בתוכן של Google Cloud, קראו את המאמר תפקידים ומשימות נפוצים של משתמשי GKE.
לפני שמתחילים
לפני שמתחילים, חשוב לוודא שביצעתם את המשימות הבאות:
- מפעילים את ממשק ה-API של Google Kubernetes Engine. הפעלת Google Kubernetes Engine API
- כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה
gcloud components updateכדי לקבל את הגרסה העדכנית. יכול להיות שבגרסאות קודמות של ה-CLI של gcloud אי אפשר להריץ את הפקודות שבמסמך הזה.
- מוודאים שיש לכם אשכול קיים במצב Autopilot או במצב Standard. אם צריך, יוצרים אשכול Autopilot.
גרסאות API לאובייקטים של HorizontalPodAutoscaler
כשמשתמשים במסוף Google Cloud , אובייקטים של HPA נוצרים באמצעות autoscaling/v2 API. ה-API autoscaling/v1 עדיין נתמך, אבל לא מומלץ יותר, והוא לא תומך בתכונות מסוימות כמו שינוי קנה מידה לאפס ומאפס באמצעות HPA.
יצירת פריסה לדוגמה
כדי ליצור אובייקט 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. אם רוצים להגדיר שינוי גודל אוטומטי על סמך אחוז הניצול של משאב, צריך לציין בקשות למשאב הזה. אם לא תציינו בקשות, תוכלו לבצע התאמה אוטומטית לעומס רק על סמך הערך המוחלט של ניצול המשאבים, כמו milliCPUs לניצול מעבד (CPU).
כדי ליצור את הפריסה, מחילים את המניפסט nginx.yaml:
kubectl apply -f nginx.yaml
ההגדרה spec.replicas מוגדרת ל-3, ולכן נפרסים שלושה פודים.
אפשר לאמת את זה באמצעות הפקודה kubectl get deployment nginx.
בכל אחת מהדוגמאות בדף הזה מוחל אובייקט HPA שונה על פריסת nginx לדוגמה.
שינוי גודל אוטומטי על סמך ניצול משאבים
בדוגמה הזו נוצר אובייקט HPA כדי להגדיל או להקטין את מספר הרפליקות של nginxפריסת Deployment באופן אוטומטי כשהשימוש במעבד עולה על 50%, וכדי לוודא שתמיד יש לפחות רפליקה אחת ומקסימום 10 רפליקות.
כדי ליצור HPA שמטרגט את המעבד (CPU), אפשר להשתמש במסוף Google Cloud , בפקודה kubectl apply או בפקודה kubectl autoscale (רק לממוצע המעבד).
המסוף
נכנסים לדף Workloads במסוף Google Cloud .
לוחצים על השם של
nginxהפריסה.לוחצים על list פעולות > עריכת שינוי גודל אוטומטי.
בקטע התאמה אופקית של קבוצות Pod לעומס, לוחצים על Select and configure.
מציינים את הערכים הבאים:
- מספר העותקים המינימלי: 1
- מספר העותקים המקסימלי: 10
- מדד שינוי הגודל האוטומטי: מעבד (CPU)
- יעד: 50
- יחידה: מעבדים (CPU)
לוחצים על שליחה.
kubectl apply
שומרים את מניפסט ה-YAML הבא בקובץ בשם nginx-hpa.yaml:
apiVersion: autoscaling/v2
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
metrics:
- type: Resource
resource:
# The target average CPU utilization percentage across all Pods.
name: cpu
target:
type: Utilization
averageUtilization: 50
אם יוצרים מניפסט כדי להתאים לפרטים ספציפיים בפרויקט שלכם, חשוב לוודא שלא כוללים מידע אישי רגיש בשדות של התאמה אופקית של קבוצות Pod לעומס.
כדי ליצור את ה-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.
המסוף
נכנסים לדף Workloads במסוף Google Cloud .
לוחצים על השם של
nginxהפריסה.לוחצים על הכרטיסייה Scaling (שינוי גודל).
kubectl get
כדי לקבל פרטים על HPA, אפשר להשתמש ב-kubectl get hpa עם הדגל -o yaml. השדה status מכיל מידע על המספר הנוכחי של הרפליקות ועל אירועים אחרונים של התאמה אוטומטית לעומס.
kubectl get hpa nginx -o yaml
הפלט אמור להיראות כך:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"autoscaling/v2","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"maxReplicas":10,"metrics":[{"resource":{"name":"cpu","target":{"averageUtilization":50,"type":"Utilization"}},"type":"Resource"}],"minReplicas":1,"scaleTargetRef":{"apiVersion":"apps/v1","kind":"Deployment","name":"nginx"}}}
creationTimestamp: "2025-10-30T19:42:43Z"
name: nginx
namespace: default
resourceVersion: "220050"
selfLink: /apis/autoscaling/v2/namespaces/default/horizontalpodautoscalers/nginx
uid: 70d1067d-fb4d-11e9-8b2a-42010a8e013f
spec:
maxReplicas: 10
minReplicas: 1
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
status:
conditions:
- lastTransitionTime: "2025-10-30T19:42:59Z"
message: recent recommendations were higher than current one, applying the highest recent recommendation
reason: ScaleDownStabilized
status: "True"
type: AbleToScale
- lastTransitionTime: "2025-10-30T19:42:59Z"
message: the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
reason: ValidMetricFound
status: "True"
type: ScalingActive
- lastTransitionTime: "2025-10-30T19:42:59Z"
message: the desired count is within the acceptable range
reason: DesiredWithinRange
status: "False"
type: ScalingLimited
currentMetrics:
- type: Resource
resource:
name: cpu
current:
averageUtilization: 0
averageValue: "0"
currentReplicas: 3
desiredReplicas: 3
אם יוצרים מניפסט כדי להתאים לפרטים ספציפיים בפרויקט שלכם, חשוב לוודא שלא כוללים מידע אישי רגיש בשדות של התאמה אופקית של קבוצות Pod לעומס.
לפני שממשיכים לדוגמאות שנותרו בדף הזה, צריך למחוק את ה-HPA:
kubectl delete hpa nginx
כשמוחקים אובייקט HPA, מספר הרפליקות של הפריסה נשאר ללא שינוי. פריסה לא חוזרת אוטומטית למצב שלה לפני שהוחל עליה HPA.
שינוי גודל אוטומטי על סמך מדד מותאם אישית או מדד חיצוני
אפשר להשתמש בכל מדד לצורך שינוי גודל אוטומטי, בין אם הוא מופק מעומס העבודה או שניתן לשלוח עליו שאילתה ממקור חיצוני. ל-GKE יש תמיכה מובנית בהתאמה אוטומטית לעומס (autoscaling) על סמך מדדים מותאמים אישית ומדדים חיצוניים במצבים רבים, ול-Kubernetes יש תמיכה במתאמי מדדים נוספים כמו KEDA ו-Prometheus adapter.
התאמה אוטומטית לעומס על סמך התנועה במאזן העומסים
התאמה אוטומטית לעומס (automatic scaling) על סמך תנועה היא יכולת של GKE שמשלבת אותות של ניצול תנועה ממאזני עומסים כדי להתאים אוטומטית את מספר ה-Pods.
שימוש בתנועה כאות להתאמת גודל השרתים יכול להיות מועיל כי זהו אינדיקטור מוביל לעומס, שמשלים את המעבד והזיכרון. השילוב המובנה עם GKE עוזר להבטיח שההגדרה תהיה פשוטה ושהתכונה 'שינוי גודל אוטומטי' תגיב במהירות לעליות פתאומיות בתנועה כדי לעמוד בביקוש.
התכונה 'שינוי גודל אוטומטי על סמך תעבורה' מופעלת על ידי בקר שער והיכולות שלו לניהול תעבורה גלובלי. מידע נוסף על התאמה אוטומטית לעומס (scaling) על סמך תנועה
אפשר להגדיר התאמה אוטומטית לעומס על סמך תנועה במאזן העומסים רק בעומסי עבודה של Gateway.
דרישות
כדי להשתמש בהתאמה אוטומטית לעומס שמבוססת על תנועה, צריך לעמוד בדרישות הבאות:
- נתמך ב-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 אחד צריך להיות מוקדש לשינוי קנה מידה של פריסת Deployment אחת (או כל משאב שניתן לשינוי קנה מידה) שנחשפת על ידי Service אחד.
- אחרי שמגדירים את הקיבולת של השירות באמצעות השדה
maxRatePerEndpoint, צריך להמתין מספיק זמן (בדרך כלל דקה, אבל יכול להיות שעד 15 דקות באשכולות גדולים) כדי שמאזן העומסים יתעדכן בשינוי הזה, לפני שמגדירים את ה-HPA עם מדדים שמבוססים על תנועה. הגישה הזו עוזרת לוודא שלא יהיה מצב זמני שבו האשכול ינסה להתאים אוטומטית לעומס על סמך מדדים שמונפקים על ידי מאזן עומסים שעדיין נמצא בתהליך הגדרה. - אם משתמשים בהתאמה אוטומטית לעומס שמבוססת על תעבורת נתונים בשירות שמופעל על ידי כמה מאזני עומסים (לדוגמה, גם על ידי Ingress וגם על ידי Gateway, או על ידי שני Gateways), יכול להיות ש-HPA יתחשב בערך תעבורת הנתונים הגבוה ביותר ממאזני עומסים נפרדים כדי לקבל החלטות לגבי התאמה לעומס, במקום בסכום של ערכי תעבורת הנתונים מכל מאזני העומסים.
פריסת התאמה אוטומטית לעומס (autoscaling) על סמך נפח התנועה
בתרגיל הבא משתמשים ב-HPA כדי להתאים אוטומטית לעומס את ה-Deployment store-autoscale על סמך תעבורת הנתונים שהוא מקבל. Gateway מקבל תנועת כניסה (ingress) מהאינטרנט עבור קבוצות ה-Pod. המידרוג האוטומטי משווה בין אותות תעבורת הנתונים מהשער לבין קיבולת תעבורת הנתונים לכל Pod שמוגדרת במשאב השירות של store-autoscale. יצירת תנועה אל שער הכניסה משפיעה על מספר ה-Pods שנפרסו.
בתרשים הבא מוצג אופן הפעולה של שינוי גודל אוטומטי על סמך תנועה:
כדי לפרוס שינוי גודל אוטומטי על סמך תנועה, פועלים לפי השלבים הבאים:
באשכולות 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.
פורסים את האפליקציה לדוגמה ואת מאזן העומסים של שער הכניסה לאשכול:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/store-autoscale.yamlאפליקציית הדוגמה יוצרת:
- פריסה עם 2 רפליקות.
- שירות עם הגדרת
GCPBackendPolicyמשויכתmaxRatePerEndpointשמוגדרת לערך10. מידע נוסף על היכולות של Gateway - שער חיצוני לגישה לאפליקציה באינטרנט. מידע נוסף על השימוש במאזני עומסים של Gateway זמין במאמר פריסת שערים.
- HTTPRoute שתואם לכל התנועה ושולח אותה לשירות
store-autoscale.
קיבולת השירות היא רכיב קריטי כשמשתמשים בהתאמה אוטומטית לעומס שמבוססת על תנועה, כי היא קובעת את כמות התנועה לכל Pod שמפעילה אירוע של התאמה אוטומטית לעומס. ההגדרה מתבצעת באמצעות שדה
maxRatePerEndpointב-GCPBackendPolicy שמשויך לשירות. השדה הזה מגדיר את נפח התעבורה המקסימלי שהשירות צריך לקבל בבקשות לשנייה, לכל Pod. קיבולת השירות ספציפית לאפליקציה שלכם.למידע נוסף, קראו את המאמר קביעת הקיבולת של השירות.
שומרים את קובץ המניפסט הבא בשם
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רפליקות (או מ-0רפליקות אם מגדירים התאמה לאפס ומאפס באמצעות HPA). -
describedObject.name: store-autoscale: ההפניה אלstore-autoscaleService שמגדיר את קיבולת התנועה. -
scaleTargetRef.name: store-autoscale: ההפניה אלstore-autoscaleהפריסה שמגדירה את המשאב שמשנה את הגודל שלו באמצעות HPA. -
averageValue: 70: ערך יעד ממוצע של 70% ניצול קיבולת. כך HPA מקבל מרווח צמיחה כדי שה-Pods הפועלים יוכלו לעבד תנועה עודפת בזמן שנוצרים Pods חדשים.
אם אתם יוצרים מניפסט שתואם לפרטים ספציפיים בפרויקט שלכם, ודאו שאתם לא כוללים מידע אישי רגיש בשדות של Horizontal Pod Autoscaler.
-
השימוש ב-HPA גורם להתנהגות התנועה הבאה:
- מספר ה-Pods מותאם בין 1 ל-10 רפליקות כדי להשיג 70% מהקצב המקסימלי לכל נקודת קצה. התוצאה היא 7 בקשות לשנייה לכל Pod כשמגדירים את
maxRatePerEndpoint=10. - אם יש יותר מ-7 בקשות לשנייה לכל פוד, המערכת מגדילה את מספר הפודים עד שמגיעים למקסימום של 10 רפליקות או עד שהתנועה הממוצעת היא 7 בקשות לשנייה לכל פוד.
- אם התנועה פוחתת, ה-Pods מצטמצמים לשיעור סביר באמצעות אלגוריתם ה-HPA.
אפשר גם לפרוס מחולל תנועה כדי לאמת את ההתנהגות של התאמה אוטומטית לעומס על סמך תנועה.
ב-30 RPS, הפריסה מורחבת ל-5 רפליקות, כך שכל רפליקה מקבלת באופן אידיאלי 6 RPS של תנועה, כלומר ניצול של 60% לכל Pod. הערך הזה נמוך מ-70% של ניצול היעד, ולכן ה-Pods מותאמים בהתאם. בהתאם לתנודות בתנועה, יכול להיות שגם מספר הרפליקות שנוספו בהתאמה לעומס ישתנה. במאמר התנהגות עם התאמה לעומס (autoscaling) מוסבר בפירוט איך מחושב מספר הרפליקות.
שינוי גודל אוטומטי על סמך כמה מדדים
בדוגמה הזו נוצר אובייקט HPA שמשנה את קנה המידה באופן אוטומטי על סמך ניצול המעבד (CPU) ומדד בהתאמה אישית בשם 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
אם יוצרים מניפסט כדי להתאים לפרטים ספציפיים בפרויקט שלכם, חשוב לוודא שלא כוללים מידע אישי רגיש בשדות של התאמה אופקית של קבוצות Pod לעומס.
מחילים את מניפסט ה-YAML:
kubectl apply -f nginx-multiple.yaml
כשיוצרים את HPA, הוא עוקב אחרי nginx Deployment כדי לראות את השימוש הממוצע במעבד, את השימוש הממוצע בזיכרון ואת המדד המותאם אישית packets_per_second (אם ביטלתם את ההערה). ה-HPA מבצע התאמה אוטומטית לעומס של ה-Deployment על סמך המדד שהערך שלו ייצור את אירוע ההתאמה האוטומטית לעומס הגדול ביותר.
שינוי קנה מידה מאפס ואל אפס
החל מגרסה 1.37 של GKE, אתם יכולים להגדיר את ה-HPA כך שיקטין את מספר הרפליקות של פריסה לאפס (0) כשאין ביקוש לעומס העבודה, ויגדיל אותו אוטומטית כשהביקוש עולה. כשמגדילים את קנה המידה מאפס, GKE עוקף את בדיקות הסבילות הרגילות של המדדים כדי להפעיל Pods בלי עיכוב.
כדי להגדיר שינוי גודל לאפס ומאפס באמצעות HPA, צריך לבצע את הפעולות הבאות:
- מוודאים שהאשכול פועל ב-GKE בגרסה 1.37 ואילך.
- מגדירים לפחות מדד מותאם אישית או מדד חיצוני באמצעות המשאב AutoscalingMetric.
- מגדירים את צמד השדה-ערך
minReplicas: 0במניפסט HPA שמשתמש ב-API autoscaling/v2.
הוראות מפורטות מופיעות במאמר הגדלה והקטנה של עומסי עבודה ב-GKE לאפס ובחזרה באמצעות HPA.
הגדרת פרופיל הביצועים של HPA
פרופיל הביצועים של HPA משפר את זמן התגובה של התאמה אופקית של קבוצות Pod לעומס, ועוזר לשפר את היכולת של HPA לטפל במספר גדול של אובייקטים (עד 1,000 אובייקטים בגרסאות משניות 1.31 עד 1.32 ו-5,000 אובייקטים בגרסה 1.33 ואילך).
הפרופיל הזה מופעל באופן אוטומטי באשכולות Autopilot שעומדים בדרישות, עם מישור בקרה שבו פועלת גרסת GKE 1.32 ואילך. באשכולות Standard, הפרופיל מופעל באופן אוטומטי באשכולות שעומדים בדרישות עם מישור בקרה שפועלת בו גרסת GKE 1.33 ואילך.
אשכול Standard פטור מהפעלה אוטומטית של פרופיל Performance HPA אם הוא עומד בכל התנאים הבאים:
- האשכול משודרג מגרסה קודמת לגרסה 1.33 ואילך.
- באשכול יש לפחות מאגר צמתים אחד עם אחד מסוגי המכונות הבאים:
e2-micro, e2-custom-micro, g1-small, f1-micro. - הקצאת משאבים אוטומטית של צמתים לא מופעלת.
אפשר גם להפעיל את פרופיל ה-HPA של הביצועים באשכולות קיימים שעומדים בדרישות.
דרישות
כדי להפעיל את פרופיל ה-HPA של הביצועים, צריך לוודא שהאשכולות שלכם ב-Autopilot וב-Standard עומדים בדרישות הבאות:
- מישור הבקרה שלכם מריץ את GKE בגרסה 1.31 ואילך.
- אם מישור הבקרה שלכם מריץ את GKE בגרסה 1.31, צריך להפעיל איסוף מדדים של המערכת.
- Autoscaling API מופעל בפרויקט.
- לכל חשבונות השירות של הצמתים מוקצה התפקיד
roles/autoscaling.metricsWriter. - אם אתם משתמשים ב-VPC Service Controls, ודאו ש-Autoscaling API כלול בגבולות הגזרה לשירות שלכם.
הפעלת פרופיל הביצועים של HPA
כדי להפעיל את פרופיל Performance 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 מוצג בשדה 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:
נכנסים לדף Workloads במסוף Google Cloud .
לוחצים על שם הפריסה של
nginx.לוחצים על list פעולות > שינוי גודל אוטומטי.
לוחצים על Delete.
kubectl delete
כדי למחוק את אובייקט ה-HPA nginx, משתמשים בפקודה הבאה:
kubectl delete hpa nginx
כשמוחקים אובייקט HPA, הפריסה (או אובייקט פריסה אחר) נשארת בקנה המידה הקיים שלה, ולא חוזרת למספר הרפליקות במניפסט המקורי של הפריסה. כדי לשנות את קנה המידה של הפריסה באופן ידני בחזרה לשלושה Pod, אפשר להשתמש בפקודה kubectl scale:
kubectl scale deployment nginx --replicas=3
סידור וארגון
אם עדיין לא עשיתם זאת, מחקו את אובייקט ה-HPA:
kubectl delete hpa nginxמחיקת הפריסה של
nginx:kubectl delete deployment nginxאפשר גם למחוק את האשכול.
פתרון בעיות
למידע נוסף על פתרון בעיות, קראו את המאמר פתרון בעיות בהתאמה אופקית של קבוצות Pod לעומס.
המאמרים הבאים
- מידע נוסף על התאמה אופקית של קבוצות Pod לעומס
- איך מתאימים את הגודל של עומסי עבודה ב-HPA באמצעות VPA
- מידע נוסף על התאמה אנכית של קבוצות Pod לעומס
- מידע נוסף על שיפור מהירות ההפעלה של המעבד (CPU)