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

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

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

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

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

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

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

  1. מוסיפים או מעדכנים את הערת התצוגה המקדימה במשאב המותאם אישית של Cluster.

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

    metadata:
  annotations:
    preview.baremetal.cluster.gke.io/vertical-pod-autoscaler: enable

  2. משנים את 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

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

    bmctl update cluster -c CLUSTER_NAME --kubeconfig KUBECONFIG

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

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

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

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

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

במצב הזה, הפודים לא מתעדכנים באופן אוטומטי. אפשר להשתמש בהמלצות האלה כדי לעדכן באופן ידני את תצורות ה-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 לעומס (VPA). כשמגדירים את enableMemorySaver לערך true, שירות המלצות עוקב אחרי צבירות ומחשב אותן רק עבור Pods שיש להם התאמה למשאב מותאם אישית VerticalPodAutoscaler.

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

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

    כדי לציין אימות באמצעות אסימון גישה (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 במשאב המותאם אישית Cluster.

השבתת התאמה אנכית של קבוצות 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 בערכי משאבים מתוקנים, צריך לפחות שתי רפליקות של Pod לפריסות.
  • הכלי לעדכון לא מעדכן במהירות את ה-Pods שנמצאים בלולאת קריסה בגלל שגיאות של חוסר זיכרון (OOM).
  • מדיניות העדכונים של InPlaceOrRecreate ל-Pods היא תכונה בשלב אלפא במסגרת התאמה אנכית של קבוצות Pod לעומס. הוא מנסה לבצע עדכונים במקום, אבל יכול להיות שהוא יחזור ליצור מחדש את ה-Pod אם עדכונים במקום לא אפשריים.

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