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

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

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

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

  • יש לכם אשכול bare metal שפועל.
  • יש לך גישת kubectl לאשכול.
  • שרת המדדים זמין באשכול. אשכולות Bare Metal כוללים את Metrics Server כברירת מחדל.

הפעלת התאמה אנכית של קבוצות Pod לעומס

כדי להפעיל התאמה אנכית של קבוצות Pod לעומס באשכול bare metal, צריך להגדיר את מפרט האשכול:

  1. משנים את spec של המשאב המותאם אישית Cluster כך שיכלול את השדה verticalPodAutoscaling ומציינים את המצבים enableUpdater ו-enableMemorySaver:

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    preview.baremetal.cluster.gke.io/vertical-pod-autoscaler: enable
spec:
  # ... other cluster spec fields
  verticalPodAutoscaling:
    enableUpdater: true       # Set to true for automated updates
    enableMemorySaver: true   # Set to true to reduce recommender memory usage

  2. אם שיניתם את קובץ התצורה של האשכול, מריצים את הפקודה הבאה כדי להחיל את השינויים:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig KUBECONFIG

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

    • ‫CLUSTER_NAME: השם של האשכול.

    • ‫KUBECONFIG: הנתיב לקובץ kubeconfig של האשכול.

יצירת VerticalPodAutoscaler משאב בהתאמה אישית

אחרי שמפעילים את התכונה Vertical Pod Autoscaling באשכול, מגדירים VerticalPodAutoscaler משאב מותאם אישית לטירגוט של עומסי עבודה ספציפיים:

  1. הגדרת משאב VerticalPodAutoscaler באותו מרחב שמות כמו עומס העבודה של היעד.

    המשאב המותאם אישית הזה מציין אילו פודים הוא מכוון באמצעות targetRef וכללי מדיניות לגבי משאבים.

    apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: hamster-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: hamster
  resourcePolicy:
    containerPolicies:
      -   containerName: '*'
        minAllowed:
          cpu: 100m
          memory: 50Mi
        maxAllowed:
          cpu: 1
          memory: 500Mi
        controlledResources: ["cpu", "memory"]

  2. מחילים את מניפסט VerticalPodAutoscaler באמצעות הפקודה הבאה:

    kubectl apply -f VPA_MANIFEST \
    --kubeconfig KUBECONFIG

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

    • ‫VPA_MANIFEST: הנתיב של קובץ המניפסט VerticalPodAutoscaler.

    • ‫KUBECONFIG: הנתיב של קובץ ה-kubeconfig של האשכול.

הסבר על מצבי התאמה אנכית של קבוצות Pod לעומס

התאמה אנכית של קבוצות Pod לעומס פועלת במצבים שונים שקובעים איך היא מיישמת המלצות לגבי משאבים.

מצב המלצה

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

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

kubectl describe vpa VPA_NAME \
    --kubeconfig KUBECONFIG \
    -n CLUSTER_NAMESPACE

Replace the following:

*   `VPA_NAME`: the name of the `VerticalPodAutoscaler`
    that's targeting the workloads for which you are considering resource
    adjustments.

*   `KUBECONFIG`: the path of the cluster kubeconfig
    file.

*   `CLUSTER_NAMESPACE`: the name of the cluster that's
    running vertical Pod autoscaling.

התשובה צריכה לכלול את הקטע Status שדומה לדוגמה הבאה:

Status:
  Conditions:
    Last Transition Time:  2025-08-04T23:53:32Z
    Status:                True
    Type:                  RecommendationProvided
  Recommendation:
    Container Recommendations:
      Container Name:  hamster
      Lower Bound:
        Cpu:     100m
        Memory:  262144k
      Target:
        Cpu:     587m
        Memory:  262144k
      Uncapped Target:
        Cpu:     587m
        Memory:  262144k
      Upper Bound:
        Cpu:     1
        Memory:  500Mi

במצב הזה, ה-Pods לא מתעדכנים באופן אוטומטי. אפשר להשתמש בהמלצות האלה כדי לעדכן באופן ידני את תצורות ה-Pod. זו התנהגות ברירת המחדל אם המדיניות enableUpdater לא מוגדרת או שהערך שלה הוא false.

מצב עדכון אוטומטי

כשמגדירים את enableUpdater enableUpdater ל-true, בקרי מחזור החיים של Bare Metal פורסים את רכיבי שירות העדכונים של התאמה אנכית של קבוצות Pod לעומס ואת בקר הגישה, בנוסף לשירות המלצות. הכלי לעדכון עוקב אחרי Pods שבהם יש הבדל משמעותי בין בקשות המשאבים הנוכחיות לבין ההמלצות.

מדיניות העדכון במשאב VerticalPodAutoscaler מציינת איך כלי העדכון מיישם את ההמלצות. כברירת מחדל, מצב העדכון הוא Auto, שקובע שכלי העדכון יקצה הגדרות משאבים מעודכנות בזמן יצירת ה-Pod. בדוגמה הבאה של VerticalPodAutoscaler אפשר לראות איך מגדירים את מצב העדכון ל-Initial:

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: hamster-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: hamster
  resourcePolicy:
  updatePolicy:
    updateMode: "Initial"
    ...

כלי העדכון תומך בחמישה מצבים:

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

  • ‫Recreate: כלי העדכון מוציא את ה-Pods ומקצה בקשות ומגבלות מומלצות של משאבים כשה-Pod נוצר מחדש.

  • ‫InPlaceOrRecreate(אלפא): שירות העדכונים מנסה לבצע עדכונים במקום, אבל יכול להיות שהוא יחזור ליצור מחדש את ה-Pod אם אי אפשר לבצע עדכונים במקום. מידע נוסף זמין במאמר בנושא שינוי גודל של Pod במקום.

  • ‫Initial: כלי העדכון מקצה בקשות למשאבים רק בזמן יצירת ה-Pod, ולא משנה אותן בשלב מאוחר יותר.

  • Off: שירות העדכונים לא משנה אוטומטית את דרישות המשאבים של ה-Pods. ההמלצות מחושבות ואפשר לבדוק אותן באובייקט VerticalPodAutoscaler.

למידע נוסף על המשאב המותאם אישית VerticalPodAutoscaler, אפשר להשתמש בפקודה kubectl כדי לאחזר את הגדרת המשאב המותאם אישית verticalpodautoscalercheckpoints.autoscaling.k8s.io שמותקנת באשכול בגרסה 1.33.0 ואילך.

בדוגמה הבאה אפשר לראות איך המלצות למשאבים עשויות להופיע בקטע Status של קונטיינר hamster. בדוגמה מוצג גם אירוע של הוצאת Pod, שמתרחש כשהכלי לעדכון מוציא Pod לפני שהוא מקצה אוטומטית את הגדרת המשאבים המומלצת ל-Pod שנוצר מחדש:

Spec:
  Resource Policy:
    Container Policies:
      Container Name:  *
      Controlled Resources:
        cpu
        memory
      Max Allowed:
        Cpu:     1
        Memory:  500Mi
      Min Allowed:
        Cpu:     100m
        Memory:  50Mi
  Target Ref:
    API Version:  apps/v1
    Kind:         Deployment
    Name:         hamster
  Update Policy:
    Update Mode:  Auto
Status:
  Conditions:
    Last Transition Time:  2025-08-04T23:53:32Z
    Status:                True
    Type:                  RecommendationProvided
  Recommendation:
    Container Recommendations:
      Container Name:  hamster
      Lower Bound:
        Cpu:     100m
        Memory:  262144k
      Target:
        Cpu:     587m
        Memory:  262144k
      Uncapped Target:
        Cpu:     587m
        Memory:  262144k
      Upper Bound:
        Cpu:     1
        Memory:  500Mi
Events:
  Type    Reason      Age   From         Message
  ----    ------      ----  ----         -------
  Normal  EvictedPod  49s   vpa-updater  VPA Updater evicted Pod hamster-7cb59fb657-lkrk4 to apply resource recommendation.

מצב חיסכון בזיכרון

מצב חיסכון בזיכרון מצמצם את הזיכרון שבשימוש של רכיב שירות ההמלצות של התאמה אנכית של קבוצות Pod לעומס. כשמגדירים את enableMemorySaver לערך true, שירות ההמלצות עוקב אחרי צבירות ומחשב אותן רק עבור Pods שיש להם משאב מותאם אישית VerticalPodAutoscaler תואם.

החיסרון הוא שכאשר יוצרים VerticalPodAutoscaler משאב מותאם אישית חדש עבור עומס עבודה קיים, לוקח למערכת ההמלצות זמן (עד 24 שעות) לאסוף מספיק נתונים מההיסטוריה כדי לספק המלצות מדויקות. ההגדרה הזו היא false כברירת מחדל ברוב סוגי האשכולות, אבל היא true באשכולות קצה.

שימוש ב-Prometheus כספק היסטוריה מתמשך

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

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

שימוש ב-Prometheus כספק היסטוריה מתמשכת מציע את היתרונות הבאים:

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

  • מניעת שגיאות של חוסר זיכרון (OOM):‏ Prometheus מבטל את הצורך לאחסן את המצב הפנימי של כלי ההמלצות בVerticalPodAutoscalerCheckpoint משאבים מותאמים אישית (CR), וכך הזיכרון של ETCD מנוצל בצורה יעילה יותר. כשמפעילים מחדש את רכיב ההמלצות, הנתונים ההיסטוריים בזיכרון הולכים לאיבוד. כשמשתמשים ב-Prometheus כספק היסטוריה, מערכת ההמלצות מאחזרת מדדים היסטוריים מ-Prometheus בהפעלה מחדש, ולכן לא צריך להשתמש ב-VerticalPodAutoscalerCheckpoint CR ונחסך זיכרון ב-ETCD.

אפשר להפעיל ולהשבית את השימוש ב-Prometheus כספק היסטוריה מתמשכת בכל שלב.

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

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

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

  2. הגדרת הרשאות לגירוד מדדים.

    כדי לאפשר ל-Prometheus לגרד מדדים מ-cAdvisor באמצעות קובץ הגדרה, צריך להעניק הרשאות נוספות לחשבון השירות שבו משתמש שרת Prometheus. יוצרים או מעדכנים ClusterRole שמכיל את הכללים האלה, ומוודאים שהוא משויך לחשבון השירות הנכון של Prometheus באמצעות ClusterRoleBinding:

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
   name: prometheus-role
   labels:
      app: prometheus-server
rules:
   - apiGroups: [""]
     resources:
       - nodes
     verbs:
       - get
       - list
       - watch
   - apiGroups: [""]
     resources:
       - nodes/proxy
       - nodes/metrics
     verbs:
       - get
    ---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus-binding
  labels:
    app: prometheus-server
subjects:
  - kind: ServiceAccount
    name: prometheus-server        # Service account being used by prometheus
    namespace: prometheus          # Service account's namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus-role            # Name of the ClusterRole created above

  3. מעדכנים את קובץ ההגדרות של Prometheus כדי לגרד את המדדים הבאים מ-cAdvisor:

    • container_cpu_usage_seconds_total
    • container_memory_working_set_bytes

    השורות הבאות מגדירות את פרטי הגירוד של מדדי cAdvisor:

    - job_name: 'kubernetes-cadvisor'
  scheme: https
  tls_config:
    ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
  bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
  kubernetes_sd_configs:
    - role: node
  relabel_configs:
    - action: labelmap
      regex: __meta_kubernetes_node_label_(.+)
    - target_label: __address__
      replacement: kubernetes.default.svc:443
    - source_labels: [__meta_kubernetes_node_name]
      regex: (.+)
      target_label: __metrics_path__
      replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor

  metric_relabel_configs:
  # Keep only the metrics VPA uses to save disk space
    - source_labels: [__name__]
      regex: (container_cpu_usage_seconds_total|container_memory_working_set_bytes)
      action: keep

  4. מעדכנים את קובץ ההגדרות של Prometheus כדי לגרד את המדד הבא משירות kube-state-metrics:

    • kube_pod_labels

    1. פורסים שירות kube-state-metrics באשכול.

      אפשר להשתמש בפקודות הבאות של Helm כדי להתקין את השירות החדש:

      helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

    2. יוצרים קובץ ksm-values.yaml עם התוכן הבא:

      fullnameOverride: vpa-kube-state-metrics
metricAllowlist:
  - kube_pod_labels
metricLabelsAllowlist:
  - "pods=[*]"

    3. מתקינים תרשים Helm על סמך קובץ הערכים מהשלב הקודם:

      helm install vpa-ksm prometheus-community/kube-state-metrics \
    -f ksm-values.yaml --namespace kube-system

    4. מוסיפים את השורות הבאות לקובץ ההגדרות של Prometheus כדי לגרד את המדד kube_pod_labels מהשירות kube-state-metrics המותקן:

      - job_name: 'kube-state-metrics'
  static_configs:
    - targets: ['vpa-kube-state-metrics.kube-system.svc.cluster.local:8080']
  metric_relabel_configs:
    - source_labels: [ __name__ ]
      regex: 'kube_pod_labels'
      action: keep

הפעלה של Prometheus ושימוש בו

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

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

דוגמה להגדרה במפרט האשכול לשימוש עם טוקן מסוג bearer:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    preview.baremetal.cluster.gke.io/vertical-pod-autoscaler: enable
spec:
  # ... other existing cluster configurations ...
  verticalPodAutoscaling:
    # ... other vertical Pod autoscaling configurations ...
    # Add this new section to configure the vpa to use prometheus using bearer token authentication as history provider
    prometheus:
      url: "http://prometheus.prometheus.monitoring.svc.cluster.local:9090"
      auth:
        bearerTokenAuth:
            name: prom-bearer-creds
            key: bearertoken

כדי להפעיל את Prometheus לשימוש עם התאמה אנכית של קבוצות Pod לעומס:

  1. מוודאים שמופע Prometheus מוגדר לגירוד המדדים הנדרשים, כמו שמתואר במאמר דרישות מוקדמות לשימוש ב-Prometheus עם שינוי אוטומטי של גודל ה-Pod לפי ענף.

  2. מעדכנים את המשאב המותאם אישית Cluster spec כך שהשדה verticalPodAutoscaling.prometheus יציין את הגדרות החיבור לשרת Prometheus.

  3. מוסיפים את url לקטע prometheus ומגדירים אותו לשם הדומיין המלא (FQDN) לחיבור אל Prometheus מתוך האשכול:

    spec:
  # ... other existing cluster configurations ...
  verticalPodAutoscaling:
    # ... other vpa configurations ...
    # Add this new section to configure the vpa to use prometheus as history provider
    prometheus:
      # Required: The URL of the Prometheus server
      url: "http://prometheus.prometheus.svc.cluster.local:9090"

  4. מציינים את פרטי החיבור:

    התאמה אנכית של קבוצות Pod לעומס תומכת בשלוש שיטות החיבור הבאות:

    • ללא אימות
    • אימות בסיסי (שם משתמש, סיסמה)

    • אימות באמצעות טוקן למוכ"ז

    ללא אימות

    אם מופע Prometheus שלכם לא דורש אימות, סיימתם. המקטע prometheus חייב לכלול רק שדה url.

    אימות בסיסי

    כדי לציין אימות בסיסי ל-Prometheus:

    1. יוצרים סוד שמכיל שם משתמש וסיסמה בקטע stringData ובהערה baremetal.cluster.gke.io/mark-source: "true".

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

      apiVersion: v1
kind: Secret
metadata:
  name: prom-basic-creds
  namespace: <cluster-namespace>
  annotations:
    baremetal.cluster.gke.io/mark-source: "true"
type: Opaque
stringData:
  username: admin
  password: pwd

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

    2. מעדכנים את הקטע prometheus.auth.basicAuth במפרט האשכול כדי להפנות לשם המשתמש ולסיסמה מהשדה data בסוד.

      בדוגמה הבאה מוצג קטע basicAuth שמפנה לשם המשתמש ולסיסמה בסוד מהשלב הקודם:

      # ... other vpa configurations ...
prometheus:
  url: "http://prometheus.prometheus.svc.cluster.local:9090"
  auth:
    basicAuth:
      usernameRef:
        name: prom-basic-creds
        key: username
      passwordRef:
        name: prom-basic-creds
        key: password

      שם המשתמש והסיסמה צריכים להיות באותו סוד. המפתחות צריכים להיות מפתחות תקינים מהשדה data של הסוד.

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

    אימות באמצעות טוקן למוכ"ז

    כדי לציין אימות באמצעות אסימון גישה (bearer token) ב-Prometheus:

    1. יוצרים Secret שמכיל טוקן מסוג Bearer בקטע stringData ובאנוטציה baremetal.cluster.gke.io/mark-source: "true".

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

      apiVersion: v1
kind: Secret
metadata:
  name: prom-bearer-creds
  namespace: <cluster-namespace>
  annotations:
    baremetal.cluster.gke.io/mark-source: "true"
type: Opaque
stringData:
  bearertoken: "SAMPLE_TOKEN"

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

    2. מעדכנים את הקטע prometheus.auth.bearerTokenAuth במפרט האשכול כדי להפנות אל טוקן למוכ"ז מהשדה data ב-סוד.

      בדוגמה הבאה מוצג קטע bearerTokenAuth שמפנה לאסימון מסוג bearer בסוד מהשלב הקודם:

      # ... other vertical Pod autoscaling configurations ...
prometheus:
  url: "http://prometheus.prometheus.svc.cluster.local:9090"
  auth:
    bearerTokenAuth:
        name: prom-bearer-creds
        key: bearertoken

      המפתח חייב להיות מפתח תקין מהשדה data של הסוד.

    המופע של Prometheus אמור להתחיל לפעול כספק היסטוריה של שינוי גודל אוטומטי של Pod אנכי כשמעדכנים את משאב ה-Cluster המותאם אישית.

השבתת השימוש ב-Prometheus

כדי להשבית את השימוש ב-Prometheus עם התאמה אנכית של קבוצות Pod לעומס, מסירים את הקטע prometheus מהקטע verticalPodAutoscaling של משאב אשכול בהתאמה אישית.

השבתת התאמה אנכית של קבוצות Pod לעומס

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

  1. מוחקים את כל המשאבים המותאמים אישית VerticalPodAutoscaler שיצרתם.

  2. משנים את המשאב המותאם אישית Cluster ומסירים את הקטע verticalPodAutoscaling כולו מ-spec.

    אפשר לערוך ישירות את המשאב המותאם אישית Cluster או לשנות את קובץ התצורה של האשכול ולהשתמש ב-bmctl update.

  3. מסירים את ההערה preview.baremetal.cluster.gke.io/vertical-pod-autoscaler מהמשאב המותאם אישית Cluster.

מגבלות

כשמשתמשים בהתאמה אנכית של קבוצות Pod לעומס, חשוב להביא בחשבון את המגבלות הבאות:

  • התאמה אנכית של קבוצות Pod לעומס לא מוכנה לשימוש עם עומסי עבודה מבוססי JVM, כי יש נראות מוגבלת של השימוש בפועל בזיכרון של עומס העבודה.
  • כדי שהכלי לעדכון יוכל להחליף את ה-Pods בערכי משאבים מתוקנים, צריך לפחות שתי רפליקות של Pods לפריסות.
  • הכלי לעדכון לא מעדכן במהירות את ה-Pods שמתרחשים בהם לולאות קריסה בגלל שגיאות של חוסר זיכרון (OOM).
  • מדיניות העדכון InPlaceOrRecreate עבור Pods היא תכונה בשלב אלפא בתוך התאמה אנכית של קבוצות Pod לעומס. הוא מנסה לעדכן את ה-Pod במקום, אבל יכול להיות שהוא ייצור מחדש את ה-Pod אם אי אפשר לעדכן אותו במקום.

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