Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

שינוי של בקשות למשאבי קונטיינר ומגבלות עליהן

טייס אוטומטי רגילה

בדף הזה מוסבר איך לנתח ולהתאים את בקשות ה-CPU ובקשות הזיכרון של קונטיינר באשכול Google Kubernetes Engine‏ (GKE) באמצעות התאמה אנכית של קבוצות Pod לעומס.

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

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

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

מפעילים את ממשק ה-API של Google Kubernetes Engine.

הפעלת Google Kubernetes Engine API

אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, הגדירו במקום זאת את compute/zone. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

ניתוח בקשות למשאבים

הכלי Vertical Pod Autoscaler מנתח באופן אוטומטי את הקונטיינרים ומספק הצעות לבקשות משאבים. אפשר לראות את בקשות המשאבים האלה באמצעותGoogle Cloud המסוף, Cloud Monitoring או Google Cloud CLI.

המסוף

כדי לראות הצעות לבקשות למשאבים במסוף Google Cloud , צריך להיות לכם עומס עבודה קיים שפרסתם לפני 24 שעות לפחות. יכול להיות שחלק מההצעות לא יהיו זמינות או רלוונטיות לעומסי עבודה מסוימים, כמו עומסי עבודה שנוצרו ב-24 השעות האחרונות, Pods עצמאיים ואפליקציות שנכתבו ב-Java.

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

כניסה לדף Workloads
ברשימת עומסי העבודה, לוחצים על השם של עומס העבודה שרוצים לשנות את הגודל שלו.
לוחצים על פעולות > שינוי גודל > עריכת בקשות למשאבים.

בקטע 'ניתוח נתוני ניצול המשאבים' מוצגים נתוני שימוש היסטוריים שהבקר של Vertical Pod Autoscaler ניתח כדי ליצור את בקשות המשאבים המוצעות בקטע 'התאמת בקשות המשאבים והמגבלות'.

Cloud Monitoring

כדי לראות את ההצעות לבקשות משאבים ב-Cloud Monitoring, צריך לפרוס עומס עבודה קיים.

נכנסים לדף Metrics Explorer במסוף Google Cloud .

לדף Metrics Explorer
לוחצים על הגדרה.
מרחיבים את התפריט Select a Metric (בחירת מדד).
בתפריט Resource בוחרים באפשרות Kubernetes Scale.
בתפריט Metric category בוחרים באפשרות Autoscaler.
בתפריט מדדים, בוחרים באפשרות Recommended per replicate request bytes (מומלץ לכל בייט של בקשת שכפול) ובאפשרות Recommended per replica request core (מומלץ לכל ליבה של בקשת שכפול).
לוחצים על אישור.

‫CLI של gcloud

כדי לראות הצעות לבקשות למשאבים, צריך ליצור אובייקט VerticalPodAutoscalerופריסה.

באשכולות רגילים, מפעילים את התכונה 'התאמה אנכית של קבוצות Pod לעומס' באשכול. באשכולות Autopilot, התכונה Vertical Pod Autoscaling (התאמה אנכית של קבוצות Pod לעומס) מופעלת כברירת מחדל.
```
gcloud container clusters update CLUSTER_NAME --enable-vertical-pod-autoscaling
```
מחליפים את CLUSTER_NAME בשם האשכול.

שומרים את קובץ המניפסט הבא בשם my-rec-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-rec-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-rec-deployment
  template:
    metadata:
      labels:
        app: my-rec-deployment
    spec:
      containers:
      - name: my-rec-container
        image: nginx

קובץ המניפסט הזה מתאר Deployment שלא כולל בקשות למעבד או לזיכרון. הערך containers.name של my-rec-deployment מציין שכל ה-Pods ב-Deployment שייכים ל-VerticalPodAutoscaler.

מחילים את המניפסט על האשכול:
```
kubectl create -f my-rec-deployment.yaml
```
שומרים את קובץ המניפסט הבא בשם my-rec-vpa.yaml:
```
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-rec-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
    name:       my-rec-deployment
  updatePolicy:
    updateMode: "Off"
```
המניפסט הזה מתאר VerticalPodAutoscaler. הערך updateMode של Off מציין שכאשר נוצרים פודים, בקר Vertical Pod Autoscaler מנתח את צורכי המעבד והזיכרון של הקונטיינרים ומתעד את ההמלצות האלה בשדה status של המשאב. הבקר Vertical Pod Autoscaler לא מעדכן אוטומטית את בקשות המשאבים של קונטיינרים פעילים.
מחילים את המניפסט על האשכול:
```
kubectl create -f my-rec-vpa.yaml
```

אחרי זמן מה, אפשר לראות את VerticalPodAutoscaler:

kubectl get vpa my-rec-vpa --output yaml

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

...
  recommendation:
    containerRecommendations:
    - containerName: my-rec-container
      lowerBound:
        cpu: 25m
        memory: 262144k
      target:
        cpu: 25m
        memory: 262144k
      upperBound:
        cpu: 7931m
        memory: 8291500k
...

בפלט הזה מוצגות המלצות לבקשות של משאבי מעבד (CPU) וזיכרון.

הגדרה ידנית של בקשות למשאבי Pod

אפשר להגדיר בקשות למשאבי Pod באופן ידני באמצעות מסוף Google Cloud או kubectl. כדי להגדיר את הבקשות והמגבלות של משאבי מאגר התגים, מומלץ לפעול לפי השיטות המומלצות הבאות:

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

המסוף

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

כניסה לדף Workloads
ברשימת עומסי העבודה, לוחצים על השם של עומס העבודה שרוצים לשנות את הגודל שלו.
לוחצים על פעולות > שינוי גודל > עריכת בקשות למשאבים.
1. בקטע Adjust resource requests and limits מוצגות הבקשות הנוכחיות למעבד ולזיכרון לכל מאגר, וגם הצעות לבקשות למעבד ולזיכרון.
לוחצים על החלת ההצעות האחרונות כדי לראות את הבקשות המוצעות לכל מאגר תגים.
לוחצים על שמירת השינויים.
לוחצים על אישור.

kubectl

הגדלת נפח העבודה באופן אנכי עם מינימום שיבושים

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

כדי להשתמש בפקודה kubectl patch, מציינים את בקשת המשאב המעודכנת באמצעות הדגל --patch. לדוגמה, כדי לשנות את גודל ה-CPU של my-app ל-800 mCPU, מריצים את הפקודה הבאה:

kubectl patch pod my-app --subresource resize --patch \
  '{"spec":{"containers":[{"name":"pause", "resources":{"requests":{"cpu":"800m"}, "limits":{"cpu":"800m"}}}]}}'

הגדלת נפח העבודה באופן אנכי

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

שומרים את קובץ המניפסט לדוגמה הבא בשם my-adjusted-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-rec-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-rec-deployment
  template:
    metadata:
      labels:
        app: my-rec-deployment
    spec:
      containers:
      - name: my-rec-container
        image: nginx
        resources:
          requests:
            cpu: 25m
            memory: 256Mi

המניפסט הזה מתאר פריסה עם שני Pods. לכל Pod יש קונטיינר אחד שמבקש 25 מילי-CPU ו-256 מיביבייט של זיכרון.

מחילים את המניפסט על האשכול:
```
kubectl apply -f my-adjusted-deployment.yaml
```

הגדרה אוטומטית של בקשות למשאבי Pod

התאמה אנכית של קבוצות Pod לעומס משתמשת באובייקט VerticalPodAutoscaler כדי להגדיר באופן אוטומטי בקשות למשאבים ב-Pods כשהערך של updateMode הוא Auto. אפשר להגדיר VerticalPodAutoscaler באמצעות ה-CLI של gcloud או מסוףGoogle Cloud .

המסוף

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

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

עוברים לדף Google Kubernetes Engine במסוף Google Cloud .

מעבר אל Google Kubernetes Engine
ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.
לוחצים על הכרטיסייה פרטים.
בקטע אוטומציה, לוחצים על עריכה באפשרות התאמה אנכית של קבוצות Pod לעומס.
מסמנים את התיבה התאמה אנכית של קבוצות Pod לעומס.
לוחצים על שמירת השינויים.

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

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

כניסה לדף Workloads
ברשימת עומסי העבודה, לוחצים על השם של ה-Deployment שרוצים להגדיר עבורה את התכונה 'התאמה אנכית של קבוצות Pod לעומס'.
לוחצים על פעולות > עריכת שינוי גודל אוטומטי.
בקטע התאמה אנכית של קבוצות Pod לעומס, לוחצים על Select and configure.
בקטע מצב עדכון, בוחרים מצב של שינוי גודל אוטומטי:
- מצב אוטומטי: התאמה אנכית של Pod לעומס מעדכנת את בקשות המעבד והזיכרון במהלך מחזור החיים של Pod.
- מצב ראשוני: התאמה אנכית של קבוצות Pod לעומס מקצה בקשות למשאבים רק בזמן יצירת ה-Pod, ולא משנה אותן בהמשך.
(אופציונלי) מגדירים מדיניות לגבי ה-container. האפשרות הזו מאפשרת לוודא שההמלצה אף פעם לא תהיה גבוהה או נמוכה יותר מבקשת משאבים שצוינה.
1. לוחצים על הוספת מדיניות.
2. בוחרים את מאגר התגים שאליו רוצים להוסיף מדיניות, או בוחרים מדיניות ברירת מחדל שתחול על כל מאגרי התגים שלא הוגדרה להם מדיניות.
3. בוחרים באפשרות אוטומטי עבור מצב שינוי גודל.
4. בקטע Controlled resources, בוחרים את המשאבים שרוצים להגדיר עבורם את מאגר התגים כך שישנה את גודלו באופן אוטומטי.
5. לוחצים על Add Rule (הוספת כלל) כדי להגדיר טווח מינימלי או מקסימלי אחד או יותר לבקשות המשאבים של הקונטיינר:
  - הזיכרון המינימלי המותר: כמות הזיכרון המינימלית שהקונטיינר צריך להקצות תמיד, ב-MiB.
  - המעבד המינימלי המותר: כמות המעבד המינימלית שהקונטיינר צריך לקבל תמיד, במילי-מעבד.
  - ‫Max allowed Memory (הזיכרון המקסימלי המותר): כמות הזיכרון המקסימלית שהקונטיינר צריך להקצות תמיד, ב-MiB.
  - Max allowed CPU: the maximum amount of CPU that the container should always have, in mCPU.
לוחצים על שליחה.

gcloud

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

במקרים של אשכולות רגילים, מפעילים את התכונה התאמה אנכית של קבוצות Pod לעומס באשכול:
```
gcloud container clusters update CLUSTER_NAME --enable-vertical-pod-autoscaling
```
מחליפים את CLUSTER_NAME בשם האשכול.

שומרים את קובץ המניפסט הבא בשם my-auto-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-auto-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-auto-deployment
  template:
    metadata:
      labels:
        app: my-auto-deployment
    spec:
      containers:
      - name: my-container
        image: registry.k8s.io/ubuntu-slim:0.14
        resources:
          requests:
            cpu: 100m
            memory: 50Mi
        command: ["/bin/sh"]
        args: ["-c", "while true; do timeout 0.5s yes >/dev/null; sleep 0.5s; done"]

המניפסט הזה מתאר פריסה עם שני Pods. לכל Pod יש קונטיינר אחד שמבקש 100 מילי-CPU ו-50MiB של זיכרון.

מחילים את המניפסט על האשכול:
```
kubectl create -f my-auto-deployment.yaml
```

(אופציונלי) מגדירים את resizePolicy לעדכונים במקום.

אם אתם מתכננים להשתמש במצב InPlaceOrRecreate, אתם יכולים להגדיר במפורש איך מאגרי התגים צריכים לטפל בשינויים במשאבים במניפסט הפריסה.

מוסיפים את השדה resizePolicy למפרט של מאגר התגים:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-auto-deployment
spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: my-container
        image: registry.k8s.io/ubuntu-slim:0.14
        resizePolicy:
        - resourceName: cpu
          restartPolicy: NotRequired
        - resourceName: memory
          restartPolicy: RestartContainer
        resources:
          requests:
            cpu: 100m
            memory: 50Mi
        ...

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

מציגים את רשימת ה-Pods הפועלים:

kubectl get pods

הפלט מציג את השמות של ה-Pods ב-my-deployment:

NAME                            READY     STATUS             RESTARTS   AGE
my-auto-deployment-cbcdd49fb-d6bf9   1/1       Running            0          8s
my-auto-deployment-cbcdd49fb-th288   1/1       Running            0          8s

שומרים את קובץ המניפסט הבא בשם my-vpa.yaml:
```
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
    name:       my-auto-deployment
  updatePolicy:
    updateMode: "Recreate"
```
קובץ המניפסט הזה מתאר VerticalPodAutoscaler עם המאפיינים הבאים:
- ‫targetRef.name: מציין שכל Pod שמבוקר על ידי Deployment בשם my-deployment שייך ל-VerticalPodAutoscaler.
- ‫updateMode: "Recreate": מציין שבקר Vertical Pod Autoscaler יכול למחוק Pod, לשנות את בקשות המעבד והזיכרון ואז להפעיל Pod חדש. זוהי התנהגות ברירת המחדל אם לא מציינים מצב (נקרא גם מצב Auto). אפשר גם לשנות את מצב העדכון לאחד מהערכים הבאים:
  - ‫updateMode: "Initial": התאמה אנכית של קבוצות Pod לעומס מקצה בקשות למשאבים רק בזמן יצירת ה-Pod.
  - ‫updateMode: "InPlaceOrRecreate" (תצוגה מקדימה): התאמה אנכית של קבוצות Pod לעומס מנסה לעדכן משאבים בלי ליצור מחדש את ה-Pod, וחוזרת ליצירה מחדש אם יש צורך בכך. האפשרות הזו מתאימה במיוחד אם עומסי העבודה מוגדרים עם resizePolicy: NotRequired.
מחילים את המניפסט על האשכול:
```
kubectl create -f my-vpa.yaml
```

ממתינים כמה דקות ומציגים שוב את ה-Pods הפועלים:

kubectl get pods

הפלט מראה ששמות ה-Pod השתנו:

NAME                                 READY     STATUS             RESTARTS   AGE
my-auto-deployment-89dc45f48-5bzqp   1/1       Running            0          8s
my-auto-deployment-89dc45f48-scm66   1/1       Running            0          8s

אם שמות ה-Pod לא השתנו, כדאי לחכות עוד קצת ואז לצפות שוב ב-Pods הפועלים.

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

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

console

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

כניסה לדף Workloads
ברשימת עומסי העבודה, לוחצים על השם של הפריסה שרוצים להגדיר.
לוחצים על פעולות > התאמה אוטומטית לעומס > התאמה אנכית של קבוצות Pod לעומס.
לוחצים על הוספת מדיניות.
בוחרים את מאגר התגים שרוצים להגדיר.
לוחצים על הוספת כלל.
מזינים ערכים בשדות מינימום מותר ומקסימום מותר עבור מעבד וזיכרון.
לוחצים על סיום.
לוחצים על Save.

gcloud

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

שומרים את קובץ המניפסט הבא בשם my-constrained-vpa.yaml:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-constrained-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
    name:       my-auto-deployment
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
    - containerName: my-container
      minAllowed:
        cpu: 100m
        memory: 50Mi
      maxAllowed:
        cpu: 1000m
        memory: 1024Mi

ההגדרה הזו עוזרת לוודא שההמלצה לגבי my-container לא תהיה נמוכה מ-100 mCPU/50 MiB או גבוהה מ-1,000 mCPU/1,024 MiB.

מחילים את המניפסט על האשכול:
```
kubectl apply -f my-constrained-vpa.yaml
```

הצגת מידע על Vertical Pod Autoscaler

כדי להציג פרטים על Vertical Pod Autoscaler:

כדי לקבל מידע מפורט על אחד מה-Pods הפועלים:

kubectl get pod POD_NAME --output yaml

מחליפים את POD_NAME בשם של אחד מה-Pods שאחזרתם בשלב הקודם.

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

apiVersion: v1
kind: Pod
metadata:
  annotations:
    vpaUpdates: 'Pod resources updated by my-vpa: container 0: cpu capped to node capacity, memory capped to node capacity, cpu request, memory request'
...
spec:
  containers:
  ...
    resources:
      requests:
        cpu: 510m
        memory: 262144k
    ...

מהפלט הזה אפשר לראות שבקר Vertical Pod Autoscaler כולל בקשת זיכרון של 262144k ובקשת מעבד (CPU) של 510m.

מידע מפורט על VerticalPodAutoscaler:
```
kubectl get vpa my-vpa --output yaml
```
הפלט אמור להיראות כך:
```
...
  recommendation:
    containerRecommendations:
    - containerName: my-container
      lowerBound:
        cpu: 536m
        memory: 262144k
      target:
        cpu: 587m
        memory: 262144k
      upperBound:
        cpu: 27854m
        memory: "545693548"
```
הפלט הזה מציג המלצות לבקשות של CPU וזיכרון, וכולל את המאפיינים הבאים:
- ‫target: מציין שכדי שהקונטיינר יפעל בצורה אופטימלית, הוא צריך לבקש 587 אלפיות ליבה ו-26,2144 קילובייט של זיכרון.
- ‫lowerBound ו-upperBound: התאמה אנכית של קבוצות Pod לעומס משתמשת במאפיינים האלה כדי להחליט אם למחוק קבוצת Pod ולהחליף אותה בקבוצת Pod חדשה. אם בקשות של Pod מסוים נמוכות מהגבול התחתון או גבוהות מהגבול העליון, הכלי Vertical Pod Autoscaler מוחק את ה-Pod ומחליף אותו ב-Pod שעומד בדרישות של מאפיין היעד.
בודקים אם יש אירועי שינוי גודל. אם אתם משתמשים במצב InPlaceOrRecreate, אתם יכולים לבדוק אם העדכון בוצע במקום על ידי בדיקת האירועים של ה-Pods:
```
kubectl get events --field-selector involvedObject.kind=Pod
```
חפשו אירועים של ResizeCompleted, שמציינים עדכון מוצלח במקום:
```
Reason            Message
------            -------
ResizeCompleted   Pod resize completed: {"containers":[...]}
```

ביטול הסכמה למאגרי תגים ספציפיים

אפשר להחריג קונטיינרים ספציפיים מהתאמה אנכית של קבוצות Pod לעומס באמצעות ה-CLI של gcloud או המסוף Google Cloud .

המסוף

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

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

עוברים לדף Google Kubernetes Engine במסוף Google Cloud .

מעבר אל Google Kubernetes Engine
ברשימת האשכולות, לוחצים על שם האשכול שרוצים לשנות.
לוחצים על הכרטיסייה פרטים.
בקטע אוטומציה, לוחצים על עריכה באפשרות התאמה אנכית של קבוצות Pod לעומס.
מסמנים את התיבה התאמה אנכית של קבוצות Pod לעומס.
לוחצים על שמירת השינויים.

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

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

כניסה לדף Workloads
ברשימת עומסי העבודה, לוחצים על השם של ה-Deployment שרוצים להגדיר עבורו את התכונה 'התאמה אנכית של קבוצות Pod לעומס'.
לוחצים על פעולות > עריכת התאמה אוטומטית לעומס.
בקטע התאמה אנכית של קבוצות Pod לעומס, לוחצים על Select and configure.
בקטע מצב עדכון, בוחרים מצב של שינוי גודל אוטומטי:
- מצב אוטומטי: התאמה אנכית של Pod לעומס מעדכנת את בקשות המעבד והזיכרון במהלך מחזור החיים של Pod.
- מצב ראשוני: התאמה אנכית של קבוצות Pod לעומס מקצה בקשות למשאבים רק בזמן יצירת ה-Pod, ולא משנה אותן בהמשך.
לוחצים על הוספת מדיניות.
בוחרים את מאגר התגים שרוצים להשבית.
בקטע מצב שינוי גודל, בוחרים באפשרות מושבת.
לוחצים על שליחה.

gcloud

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

שומרים את קובץ המניפסט הבא בשם my-opt-vpa.yaml:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-opt-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
    name:       my-opt-deployment
  updatePolicy:
    updateMode: "Recreate"
  resourcePolicy:
    containerPolicies:
    - containerName: my-opt-sidecar
      mode: "Off"

המניפסט הזה מתאר VerticalPodAutoscaler. הערך mode: "Off" משבית את ההמלצות למאגר התגים my-opt-sidecar.

מחילים את המניפסט על האשכול:
```
kubectl apply -f my-opt-vpa.yaml
```

שומרים את קובץ המניפסט הבא בשם my-opt-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-opt-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-opt-deployment
  template:
    metadata:
      labels:
        app: my-opt-deployment
    spec:
      containers:
      - name: my-opt-container
        image: nginx
      - name: my-opt-sidecar
        image: busybox
        command: ["sh","-c","while true; do echo Doing sidecar stuff!; sleep 60; done"]

מחילים את המניפסט על האשכול:
```
kubectl apply -f my-opt-deployment.yaml
```
אחרי זמן מה, צופים ב-Vertical Pod Autoscaler:
```
kubectl get vpa my-opt-vpa --output yaml
```
הפלט מציג המלצות לבקשות של יחידת עיבוד מרכזית (CPU) וזיכרון:
```
...
  recommendation:
    containerRecommendations:
    - containerName: my-opt-container
...
```
בפלט הזה, יש רק המלצות למאגר תגים אחד. אין המלצות לחשבון my-opt-sidecar.

הכלי Vertical Pod Autoscaler אף פעם לא מעדכן משאבים במאגרי מידע שהוסרו מהרשימה. אם מחכים כמה דקות, ה-Pod נוצר מחדש, אבל רק למאגר אחד יש בקשות משאבים מעודכנות.

זיהוי עומסי עבודה ללא בקשות או מגבלות של משאבים

מומלץ לזהות עומסי עבודה שלא הוגדרו להם בקשות וגבולות של משאבים, כי GKE ממליץ להגדיר בקשות וגבולות של משאבים לכל עומסי העבודה כשיטה מומלצת, כדי למנוע סיום פתאומי של Pod בגלל עומס על משאבי הצומת ולשפר את הדיוק של הקצאת העלויות. הגדרת Pods מסוג BestEffort או Pods עם זיכרון Burstable עלולה לגרום לבעיות באמינות כשבצומת יש עומס על הזיכרון. כדי להגדיר את הבקשות והמגבלות של משאבי מאגר התגים, מומלץ לפעול לפי השיטות המומלצות הבאות:

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

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

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

סוג משנה של תובנה	תרחיש של הגדרות חסרות	פרטים
`REQUEST_OR_LIMIT_NOT_SET`	לא הוגדרו בקשת זיכרון ומגבלת זיכרון. (`MEMORY_REQUEST_AND_LIMIT_NOT_SET`)	הפודים פועלים בלי בקשות זיכרון ומגבלות שהוגדרו עבור הקונטיינרים שלהם. ‫GKE לא יכול לווסת את השימוש בזיכרון, ויכול להיות שהוא יסיים את הפעולה של Pods כאלה באופן פתאומי אם בצומת יש עומס על הזיכרון, מה שעלול לגרום לבעיות באמינות.
`REQUEST_OR_LIMIT_NOT_SET`	לא הוגדרו מגבלות זיכרון. (`MEMORY_LIMIT_NOT_SET`)	הפודים פועלים בלי מגבלות זיכרון שהוגדרו לקונטיינרים שלהם. ‫GKE לא יכול לווסת את השימוש בזיכרון, ויכול להיות שהוא יפסיק את הפעילות של Pods כאלה באופן פתאומי אם בצומת יש עומס על הזיכרון והשימוש בזיכרון של ה-Pods חורג מהבקשות, מה שעלול לגרום לבעיות באמינות. כדי למנוע שימוש של Pods ביותר זיכרון מהנדרש, צריך להגדיר את אותה כמות זיכרון לבקשות ולמגבלות.
`REQUEST_OR_LIMIT_NOT_SET`	לא הוגדרו בקשה ומגבלה של מעבד. (`CPU_REQUEST_AND_LIMIT_NOT_SET`)	הפודים פועלים בלי בקשות של יחידת עיבוד מרכזית (CPU) ובלי הגבלות שמוגדרות לקונטיינרים. כך גדל הסיכוי לניצול יתר של משאבי הצומת, וסביר יותר שיוגבל קצב ההעברה של ה-Pods כשהשימוש במעבד בצומת קרוב למגבלה שלו, ועלולות להיגרם בעיות בביצועים.

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

בדיקה ידנית של בקשות למשאבים ומגבלות

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

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

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

כניסה לדף Workloads
ברשימת עומסי העבודה, לוחצים על השם של עומס העבודה שרוצים לבדוק.
לוחצים על פעולות > שינוי גודל > עריכת בקשות למשאבים.
1. בקטע Adjust resource requests and limits (שינוי בקשות וגבולות של משאבים) מוצגות הבקשות הנוכחיות של CPU וזיכרון לכל קונטיינר.

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

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

ניתוח בקשות למשאבים

המסוף

Cloud Monitoring

‫CLI של gcloud

הגדרה ידנית של בקשות למשאבי Pod

המסוף

kubectl

הגדלת נפח העבודה באופן אנכי עם מינימום שיבושים

הגדלת נפח העבודה באופן אנכי

הגדרה אוטומטית של בקשות למשאבי Pod

המסוף

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

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

gcloud

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

console

gcloud

הצגת מידע על Vertical Pod Autoscaler

ביטול הסכמה למאגרי תגים ספציפיים

המסוף

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

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

gcloud

זיהוי עומסי עבודה ללא בקשות או מגבלות של משאבים

בדיקה ידנית של בקשות למשאבים ומגבלות

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

שינוי של בקשות למשאבי קונטיינר ומגבלות עליהן