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

הגדרת איזון עומסים מבוסס-ניצול לשירותי GKE

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

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

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

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

תמחור

איזון עומסים מבוסס-ניצול הוא יכולת של GKE Gateway שזמינה ללא עלות נוספת. עדיין חלים תנאי התמחור של Cloud Load Balancing ושל GKE.

מכסות

איזון עומסים מבוסס-ניצול לא מוסיף מכסות חדשות, אבל כל המכסות מ-Cloud Load Balancing ומשירותים תלויים אחרים עדיין חלות.

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

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

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

קוראים את הדרישות של בקר שער.
בודקים את המגבלות.

דרישות של GKE Gateway controller

כדי להשתמש באיזון עומסים מבוסס-ניצול בשירותי GKE, צריך:

‫Google Cloud CLI בגרסה 516.0.0 ואילך.
‫GKE גרסה ‎1.33.1-gke.1918000 ואילך בערוץ RAPID.
צריך להפעיל את Gateway API באשכול.
צריך להפעיל את פרופיל ה-HPA לביצועים באשכול.
צריך להפעיל את Autoscaling API ב Google Cloud פרויקט.
לחשבונות שירות של Node צריכה להיות הרשאת כתיבה ל-Autoscaling API.

מאזן עומסים מבוסס-ניצול לשירותי GKE תומך באפשרויות הבאות:

שירותי GKE באשכול יחיד ובכמה אשכולות שמשמשים כקצה עורפי למאזן עומסים מנוהל Google Cloud.
כל מהדורות GKE‏ (Standard, ‏ Autopilot ו-Enterprise).
כל Google Cloud מאזני העומסים של האפליקציות, לא כולל מאזני העומסים הקלאסיים של האפליקציות.

מגבלות

יש הגבלות מסוימות על איזון עומסים מבוסס-ניצול בשירותי GKE.

אלה מדדי ניצול המשאבים הנתמכים:
- מדדים של ניצול משאבי המעבד.
- מדדים מותאמים אישית שמופקים מהאפליקציה שלכם ב-GKE. מידע נוסף זמין במאמר חשיפת מדדים מותאמים אישית למאזני עומסים.
אין תמיכה במאזני עומסי רשת מסוג passthrough או proxy.
יש תמיכה רק ב-Gateway API, ולא ב-Service API וב-Ingress API.
איזון עומסים על סמך ניצול לא מתאים אם התנועה שלכם מאוד לא יציבה. איזון מחדש של התנועה נמשך עד 30 שניות כשהשימוש בתרמילים מגיע לערך המקסימלי. האות של ניצול המשאבים צפוי לעלות עם התנועה הנכנסת, אבל העיכוב הזה אומר שאיזון העומסים שמבוסס על ניצול המשאבים צריך זמן כדי להתאים את עצמו. כדי להשיג ביצועים אופטימליים, איזון עומסים מבוסס-ניצול פועל הכי טוב בסביבות עם תנועת נתונים חלקה וצפויה.
יכול להיות שיחלפו עד 30 שניות עד שהאיזון העומסים לפי ניצול ישתנה ויתאים את חלוקת התעבורה אחרי שינויים בהגדרות, כמו שינוי או הסרה של השדה dryRun ב-GCPBackendPolicy. העיכוב הזה הוא התנהגות מוכרת של המערכת. לכן, התכונה הזו מתאימה בעיקר לאפליקציות עם דפוסי תנועה יציבים יחסית, שיכולות לסבול את זמן האחזור של העדכון הזה.

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

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

הפעלה של איזון עומסים מבוסס-ניצול ופרופיל HPA לביצועים

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

‫Gateway API, שמאפשר מדיניות ברמת השירות באמצעות GCPBackendPolicy.
פרופיל ה-HPA לביצועים, שמאפשר להרחיב את עומסי העבודה מהר יותר ובאופן אגרסיבי יותר באמצעות אותות CPU.

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

Autopilot

‫Gateway API ופרופיל Performance HPA זמינים כברירת מחדל באשכול Autopilot.

רגילה

כדי ליצור אשכול חדש מסוג Standard עם פרופיל HPA לביצועים ועם Gateway API מופעל, מריצים את הפקודה הבאה:

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --cluster-version=CLUSTER_VERSION \
    --gateway-api=standard \
    --hpa-profile=performance \
    --release-channel=rapid

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

CLUSTER_NAME בשם של האשכול החדש.
‫LOCATION עם האזור או התחום של Compute Engine עבור האשכול.
‫PROJECT_ID במזהה הפרויקט.
‫CLUSTER_VERSION עם גרסת GKE, שצריכה להיות ‎1.33.1-gke.1918000 ואילך.

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

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --gateway-api=standard \
    --hpa-profile=performance \
    --release-channel=rapid

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

CLUSTER_NAME בשם של האשכול החדש.
‫LOCATION עם האזור או התחום של Compute Engine עבור האשכול.
‫PROJECT_ID במזהה הפרויקט.

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

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

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

דרישות מוקדמות

לפני שמגדירים איזון עומסים מבוסס-ניצול באמצעות Gateway API, צריך לוודא שאשכול GKE עומד בדרישות הבאות:

פריסת אפליקציה: מוודאים שפורסים אפליקציית Kubernetes באמצעות משאב Deployment. מידע נוסף זמין במאמר פריסת אפליקציה באשכול GKE.

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

לדוגמה, מניפסט פריסה טיפוסי יכול לכלול קטע של משאבים כמו זה:
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: store-v1
spec:
  # ... other deployment configurations ...
  template:
    # ... other template configurations ...
    spec:
      containers:
        - name: your-container-name
          image: your-image
          ports:
            - containerPort: 8080
          resources:
            limits:
              cpu: 100m
              memory: 45Mi
            requests:
              cpu: 100m
              memory: 45Mi
```
חשיפת האפליקציה באמצעות Service: צריך לחשוף את האפליקציה באמצעות Kubernetes Service. מידע נוסף על אופן הפעולה של שירותים ועל אופן ההגדרה שלהם זמין במאמר הסבר על שירותי Kubernetes.
שימוש במאזן עומסים של אפליקציות שמבוסס על Gateway API: חשיפת השירות באמצעות מאזן עומסים של אפליקציות שמנוהל על ידי GKE ומוגדר באמצעות Gateway API. מידע נוסף זמין במאמר בנושא פריסת שערים.

יצירת `GCPBackendPolicy` לאיזון עומסים מבוסס-מעבד

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

כדי להפעיל איזון עומסים מבוסס-ניצול בשירותי GKE, צריך להשתמש במשאב המותאם אישית GCPBackendPolicy מ-Kubernetes Gateway API.

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

שומרים את קובץ המניפסט לדוגמה הבא בשם my-backend-policy.yaml:
```
kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: my-backend-policy
  namespace: team-awesome
spec:
  targetRef:
    group: ""
    kind: Service
    name: super-service
  default:
    balancingMode: CUSTOM_METRICS
    customMetrics:
    - name: gke.cpu
      dryRun: false
```
שימו לב לנקודות הבאות:
- ‫spec.targetRef.kind: Service: מכוון לשירות Kubernetes רגיל באותו אשכול.
- ‫spec.targetRef.kind: ServiceImport: מכוון לשירות מאשכול אחר בהגדרה של כמה אשכולות.
- ‫balancingMode: CUSTOM_METRICS: הפעלת איזון עומסים מבוסס-מדדים מותאמים אישית.
- ‫name: gke.cpu: מציין את ניצול המעבד כמדד לחלוקת התנועה.
אם לא מציינים את השדה maxUtilizationPercent, ערך ברירת המחדל של סף הניצול הוא 80%. התנועה מאוזנת מחדש כששימוש ה-CPU בשרת קצה עולה על 80%.
מחילים את קובץ המניפסט לדוגמה על האשכול:
```
kubectl apply -f my-backend-policy.yaml
```

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

שיקולים חשובים לגבי `dryRun` ו-`balancingMode`

כשמגדירים את GCPBackendPolicy עם מדדים מותאמים אישית, צריך לשים לב לאינטראקציה בין balancingMode לבין השדה dryRun בהגדרה של customMetrics. האינטראקציה הזו קובעת איך מאזן העומסים משתמש במדדים המותאמים אישית. מידע נוסף על מדדים מותאמים אישית וההגבלות שלהם, כולל הגבלות שקשורות למצבי איזון, זמין במאמר מדדים מותאמים אישית של Cloud Load Balancing.

balancingMode: CUSTOM_METRICS
- כדי להפיץ תנועה על סמך מדד מותאם אישית, צריך להגדיר לפחות מדד מותאם אישית אחד ברשימה customMetrics עם הערך false בשדה dryRun. ההגדרה הזו אומרת למאזן העומסים להשתמש באופן פעיל במדד הזה כדי לקבל החלטות לגבי איזון מחדש.
- אפשר לכלול מדדים מותאמים אישית אחרים עם dryRun: true לצד מדדים שאינם מדדים של הרצה יבשה. כך תוכלו לבדוק או לעקוב אחרי מדדים חדשים, כמו ניצול GPU, בלי שהם ישפיעו על התנועה, בזמן שמדד אחר, כמו ניצול CPU עם dryRun: false, שולט באיזון.
- אם הערך של balancingMode הוא CUSTOM_METRICS וכל המדדים המותאמים אישית מוגדרים עם dryRun שמוגדר ל-true, תופיע שגיאה. לדוגמה: gceSync: generic::invalid_argument: Update: Invalid value for field 'resource.backends[0]': '...'. CUSTOM_METRICS BalancingMode requires at least one non-dry-run custom metric. מאזן העומסים צריך מדד פעיל כדי לקבל החלטות.
‫balancingMode הוא RATE או מצבים אחרים שאינם מדדים מותאמים אישית
- אם איזון העומסים מבוסס על קריטריונים אחרים מלבד מדדים מותאמים אישית, כמו RATE לבקשות לשנייה, אפשר להגדיר dryRun: true לכל המדדים המותאמים אישית. כך תוכלו לעקוב אחרי מדדים מותאמים אישית בלי להשפיע על מנגנון האיזון הראשי. האפשרות הזו שימושית לבדיקת מדדים מותאמים אישית חדשים לפני שמעבירים את balancingMode ל-CUSTOM_METRICS.
מעקב אחרי מדדים מותאמים אישית
- אחרי שמגדירים את GCPBackendPolicy ומתחילים לשלוח תנועה לאפליקציה, עובר זמן עד שהמדדים המותאמים אישית, כמו gke.cpu, מופיעים ב-Metrics Explorer.
- כדי שמדדים מותאמים אישית יהיו גלויים ופעילים ב-Metrics Explorer, צריך להיות תעבורה בפועל בבק-אנד שהמדיניות מנטרת. אם אין תנועה, יכול להיות שהמדד יוצג רק בקטע 'Inactive Resources' (משאבים לא פעילים) בכלי Metrics Explorer.

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

כברירת מחדל, GKE מפנה את התנועה משרתי קצה עורפיים שחורגים מ-80% ניצול CPU. עם זאת, עומסי עבודה מסוימים עשויים לסבול שימוש גבוה או נמוך יותר במעבד לפני שנדרשת חלוקה מחדש של התנועה. אפשר להתאים אישית את ערך הסף הזה באמצעות השדה maxUtilizationPercent במשאב GCPBackendPolicy.

כדי להגדיר שירות GKE כך שהוא יאפשר לשרתי קצה להשתמש בעד 70% מה-CPU לפני הפעלת איזון מחדש, שומרים את מניפסט הדוגמה הבא בשם my-backend-policy.yaml:
```
kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: my-backend-policy
  namespace: team-awesome
spec:
  targetRef:
    group: ""
    kind: Service
    name: super-service
  default:
    balancingMode: CUSTOM_METRICS
    customMetrics:
    - name: gke.cpu
      maxUtilizationPercent: 70
```
שימו לב לנקודות הבאות:
- בשדה maxUtilizationPercent אפשר להזין ערכים מ-0 עד 100. ערך של 100 מציין ששרת קצה עורפי יכול להשתמש בקיבולת המלאה של המעבד לפני שמתבצע איזון מחדש של התנועה.
- לעומסי עבודה שרגישים לזמן אחזור ודורשים העברה מוקדמת, מומלץ להשתמש בסף נמוך יותר.
- עבור עומסי עבודה שמיועדים לפעול קרוב לקיבולת המלאה, כדאי להשתמש בסף גבוה יותר.
- בשירותים מרובי אשכולות, הערך של spec.targetRef.kind חייב להיות ServiceImport והערך של group חייב להיות net.gke.io.
מחילים את קובץ המניפסט לדוגמה על האשכול:
```
kubectl apply -f my-backend-policy.yaml
```

אם מפעילים סף מותאם אישית לניצול המעבד, אפשר לשלוט על חלוקת התנועה על סמך ניצול המעבד של ה-Backend.

(אופציונלי) הפעלת מצב פרימטר לבדיקות

במצב פרימטר לבדיקות, המערכת עוקבת אחרי השימוש במשאבי ה-Pods בלי לשנות את חלוקת התנועה. כשמצב פרימטר לבדיקות מופעל, המדדים מיוצאים ל-Cloud Monitoring, אבל Cloud Load Balancing מתעלם מהמדדים האלה ומשתמש בהתנהגות ברירת המחדל של איזון העומסים.

כדי להפעיל את מצב הפרימטר לבדיקות בשירות GKE, שומרים את קובץ המניפסט לדוגמה הבא בשם my-backend-policy.yaml:

kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: my-backend-policy
spec:
  targetRef:
    group: ""
    kind: Service
    name: store-v1
  default:
    balancingMode: RATE
    maxRatePerEndpoint: 10
    customMetrics:
    - name: gke.cpu
      dryRun: true

מחילים את קובץ המניפסט לדוגמה על האשכול:
```
kubectl apply -f my-backend-policy.yaml
```

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

השירות Cloud Load Balancing מתעלם ממדדי ניצול המעבד (CPU) ומשתמש במקום זאת בהתנהגות ברירת המחדל של איזון העומסים.
המדדים ממשיכים להיות מיוצאים אל Cloud Monitoring בקטע network.googleapis.com/loadbalancer/backend/lb_custom_metrics.

אחרי שבודקים את המדדים, מסירים את השדה dryRun מה-GCPBackendPolicy ומחילים מחדש את ההגדרה. אם מתרחשות בעיות אחרי שמשביתים את הרצת הניסיון, צריך להפעיל אותה מחדש על ידי הוספת dryRun: true בחזרה למדיניות.

אימות המדיניות

כדי לוודא שהמדיניות GCPBackendPolicy חלה על שירות GKE שלכם, וכדי לוודא שבקרי GKE מזהים את המדיניות, מריצים את הפקודה הבאה:

kubectl describe gcpbackendpolicy POLICY_NAME -n NAMESPACE

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

Name:         <your policy name>
Namespace:    <your namespace>
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1
Kind:         GCPBackendPolicy
Metadata:
  Creation Timestamp:  ...
  Generation:          1
  Resource Version:    …
  UID:                 …
Spec:
  Default:
    Balancing Mode:  CUSTOM_METRICS
    Custom Metrics:
      Dry Run:  false
      Name:     gke.cpu
  Target Ref:
    Group:
    Kind:   Service
    Name:   super-service
Status:
  Conditions:
    Last Transition Time:  …
    Message:
    Reason:                Attached
    Status:                True
    Type:                  Attached
Events:
…

הגדרת איזון עומסים לפי ניצול באמצעות ממשקי API של Compute Engine

מומלץ להשתמש ב-Kubernetes Gateway API כדי להגדיר איזון עומסים מבוסס-ניצול בשירותי GKE.

עם זאת, יכול להיות שתעדיפו להשתמש ב-API של Compute Engine או ב-Terraform כדי לנהל את מאזני העומסים ישירות. אם בוחרים בגישה הזו, צריך להפעיל איזון עומסים מבוסס-ניצול ברמת BackendService.

כדי להפעיל איזון עומסים מבוסס-ניצול בשירות BackendService קיים ולצרף קבוצה של נקודות קצה ברשת (NEG), my-lb-neg, מריצים את הפקודה הבאה:
```
gcloud compute backend-services add-backend MY_BACKEND_SERVICE \
  --network-endpoint-group my-lb-neg \
  --network-endpoint-group-zone=asia-southeast1-a \
  --global \
  --balancing-mode=CUSTOM_METRICS \
  --custom-metrics 'name="gke.cpu",maxUtilization=0.8'
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫MY_BACKEND_SERVICE בשם של BackendService.
- CUSTOM_METRICS עם CUSTOM_METRICS.
כדי לעדכן את הגדרות איזון העומסים לפי ניצול של רשומת קצה עורפי קיימת ב-BackendService שאליו כבר מצורף NEG, מריצים את הפקודה הבאה:
```
gcloud compute backend-services update-backend MY_BACKEND_SERVICE \
  --network-endpoint-group my-lb-neg \
  --network-endpoint-group-zone=asia-southeast1-a \
  --global \
  --balancing-mode=CUSTOM_METRICS \
  --custom-metrics 'name="gke.cpu",maxUtilization=0.8'
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫MY_BACKEND_SERVICE בשם של BackendService.
- CUSTOM_METRICS עם CUSTOM_METRICS.

השבתת איזון עומסים מבוסס-ניצול בשירות GKE

כדי להשבית את איזון העומסים על סמך ניצול בשירותי GKE:

אם רוצים לשמור את המדיניות להגדרות אחרות, מסירים את השדות balancingMode ו-customMetrics מה-GCPBackendPolicy.
אם כבר אין לכם צורך ב-GCPBackendPolicy, אתם יכולים למחוק אותו.
אם אתם משתמשים בממשקי Compute Engine API, צריך לשנות בחזרה את הדגלים --balancing-mode ו---custom-metrics משירות הקצה העורפי.

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

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