צמצום העלויות באמצעות הקטנת אשכולות GKE בשעות שבהן העומס נמוך

Last reviewed 2022-11-24 UTC

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

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

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

מבוא

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

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

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

הקטנת הקיבולת של אשכול אם יש לכם הנחות תמורת התחייבות לשימוש

במדריך הזה מוסבר איך לצמצם את העלויות על ידי הקטנת אשכולות GKE למינימום בשעות שבהן העומס נמוך. עם זאת, אם רכשתם הנחה תמורת התחייבות לשימוש (CUD), חשוב להבין איך ההנחות האלה פועלות בשילוב עם התאמה אוטומטית לעומס (automatic scaling).

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

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

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

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

ארכיטקטורה

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

בארכיטקטורה הזו, קבוצה של CronJobs ב-Kubernetes מייצאת מידע מוכר על דפוסי תנועה אל מדד בהתאמה אישית ב-Cloud Monitoring. לאחר מכן, נתוני ה-CPU נקראים על ידי Horizontal Pod Autoscaler (HPA) של Kubernetes כקלט להחלטה מתי ה-HPA צריך לשנות את גודל עומס העבודה. יחד עם מדדי טעינה אחרים, כמו ניצול יעד של CPU, ‏ HPA מחליט איך לשנות את גודל הרפליקות עבור פריסה נתונה.

מטרות

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

הקוד של המדריך הזה נמצא במאגר GitHub.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

• Cloud Monitoring
• Artifact Registry
• Google Kubernetes Engine

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

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

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

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

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the GKE, Artifact Registry and the Cloud Monitoring APIs.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the GKE, Artifact Registry and the Cloud Monitoring APIs.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

הכנת הסביבה

1. במסוף Google Cloud , מפעילים את Cloud Shell.

   הפעלת Cloud Shell

   בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

2. ב-Cloud Shell, מגדירים את מזהה הפרויקט ב- Google Cloud , את כתובת האימייל ואת האזור והאזור הזמין של המחשוב:

   PROJECT_ID=YOUR_PROJECT_ID
   ALERT_EMAIL=YOUR_EMAIL_ADDRESS
   gcloud config set project $PROJECT_ID
   gcloud config set compute/region us-central1
   gcloud config set compute/zone us-central1-f
   

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

   • ‫YOUR_PROJECT_ID: שם הפרויקט ב- Google Cloud שבו אתם משתמשים.
   • ‫YOUR_EMAIL_ADDRESS: כתובת אימייל לקבלת הודעה אם שינוי הגודל האוטומטי המתוזמן לא פועל כמו שצריך.

   אם רוצים, אפשר לבחור אזור ותחום אחרים למדריך הזה.

3. משכפלים את kubernetes-engine-samples המאגר ב-GitHub:

   git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples/
   cd kubernetes-engine-samples/cost-optimization/gke-scheduled-autoscaler
   

   הקוד בדוגמה הזו בנוי מהתיקיות הבאות:

   • ‫Root: מכיל את הקוד שמשמש את CronJobs לייצוא מדדים מותאמים אישית ל-Cloud Monitoring.
   • ‫k8s/: מכיל דוגמה לפריסה עם HPA של Kubernetes.
   • ‫k8s/scheduled-autoscaler/: מכיל את משימות ה-Cron שיוצאות מדד מותאם אישית וגרסה מעודכנת של HPA לקריאה ממדד מותאם אישית.
   • ‫k8s/load-generator/: מכיל פריסת Kubernetes עם אפליקציה שמדמה שימוש שעתי. פריסה היא אובייקט Kubernetes API שמאפשר להפעיל כמה רפליקות של Pods שמפוזרות בין הצמתים באשכול.
   • ‫monitoring/: מכיל את רכיבי Cloud Monitoring שמוגדרים במדריך הזה.

יצירת אשכול GKE

1. ב-Cloud Shell, יוצרים אשכול GKE להרצת קנה המידה האוטומטי המתוזמן:

   gcloud container clusters create scheduled-autoscaler \
       --enable-ip-alias \
       --release-channel=stable \
       --machine-type=e2-standard-2 \
       --enable-autoscaling --min-nodes=1 --max-nodes=10 \
       --num-nodes=1 \
       --autoscaling-profile=optimize-utilization
   

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

   NAME                   LOCATION       MASTER_VERSION   MASTER_IP      MACHINE_TYPE   NODE_VERSION     NUM_NODES  STATUS
   scheduled-autoscaler   us-central1-f  1.22.15-gke.100  34.69.187.253  e2-standard-2  1.22.15-gke.100  1          RUNNING
   

   זו לא הגדרה של סביבת ייצור, אבל היא מתאימה למדריך הזה. בהגדרה הזו, מגדירים את הכלי להתאמה אוטומטית של אשכולות עם מינימום של 1 צומת ומקסימום של 10 צמתים. כדאי גם להפעיל את פרופיל optimize-utilization כדי לזרז את תהליך ההקטנה.

פריסת האפליקציה לדוגמה

1. פריסת האפליקציה לדוגמה ללא קנה מידה אוטומטי מתוזמן:

   kubectl apply -f ./k8s
   

2. פותחים את הקובץ k8s/hpa-example.yaml.

   התוכן של הקובץ מוצג ברשימה הבאה.

   spec:
     maxReplicas: 20
     minReplicas: 10
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: php-apache
     metrics:
     - type: Resource
       resource:
         name: cpu
         target:
           type: Utilization
           averageUtilization: 60

   שימו לב שמספר העותקים המינימלי (minReplicas) מוגדר ל-10. ההגדרה הזו קובעת גם את קנה המידה של האשכול על סמך ניצול המעבד (ההגדרות name: cpu ו-type: Utilization).

3. ממתינים עד שהאפליקציה תהיה זמינה:

   kubectl wait --for=condition=available --timeout=600s deployment/php-apache
   EXTERNAL_IP=''
   while [ -z $EXTERNAL_IP ]
   do
       EXTERNAL_IP=$(kubectl get svc php-apache -o jsonpath={.status.loadBalancer.ingress[0].ip})
       [ -z $EXTERNAL_IP ] && sleep 10
   done
   curl -w '\n' http://$EXTERNAL_IP
   

   כשהאפליקציה זמינה, הפלט אמור להיראות כך:

   OK!
   

4. בודקים את ההגדרות:

   kubectl get hpa php-apache
   

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

   NAME         REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
   php-apache   Deployment/php-apache   9%/60%    10        20        10         6d19h
   

   בעמודה REPLICAS מוצג הערך 10, שזהה לערך בשדה minReplicas בקובץ hpa-example.yaml.

5. בודקים אם מספר הצמתים גדל ל-4:

   kubectl get nodes
   

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

   NAME                                                  STATUS   ROLES    AGE   VERSION
   gke-scheduled-autoscaler-default-pool-64c02c0b-9kbt   Ready    <none>   21S   v1.17.9-gke.1504
   gke-scheduled-autoscaler-default-pool-64c02c0b-ghfr   Ready    <none>   21s   v1.17.9-gke.1504
   gke-scheduled-autoscaler-default-pool-64c02c0b-gvl9   Ready    <none>   21s   v1.17.9-gke.1504
   gke-scheduled-autoscaler-default-pool-64c02c0b-t9sr   Ready    <none>   21s   v1.17.9-gke.1504
   

   כשיוצרים את האשכול, מגדירים תצורה מינימלית באמצעות הדגל min-nodes=1. עם זאת, האפליקציה שפרסתם בתחילת התהליך הזה מבקשת עוד תשתית כי הערך minReplicas בקובץ hpa-example.yaml מוגדר כ-10.

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

הגדרת שינוי גודל אוטומטי מתוזמן

1. ב-Cloud Shell, מתקינים את המתאם Custom Metrics - Cloud Monitoring באשכול GKE:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter_new_resource_model.yaml
   kubectl wait --for=condition=available --timeout=600s deployment/custom-metrics-stackdriver-adapter -n custom-metrics
   

   המתאם הזה מאפשר התאמה אוטומטית לעומס של Pod על סמך מדדים מותאמים אישית של Cloud Monitoring.

2. יוצרים מאגר ב-Artifact Registry ומעניקים הרשאות קריאה:

   gcloud artifacts repositories create gke-scheduled-autoscaler \
     --repository-format=docker --location=us-central1
   gcloud auth configure-docker us-central1-docker.pkg.dev
   gcloud artifacts repositories add-iam-policy-binding gke-scheduled-autoscaler \
      --location=us-central1 --member=allUsers --role=roles/artifactregistry.reader
   

3. בונים את הקוד של כלי הייצוא של מדדים מותאמים אישית ומעבירים אותו:

   docker build -t us-central1-docker.pkg.dev/$PROJECT_ID/gke-scheduled-autoscaler/custom-metric-exporter .
   docker push us-central1-docker.pkg.dev/$PROJECT_ID/gke-scheduled-autoscaler/custom-metric-exporter
   

4. פורסים את משימות ה-Cron שמייצאות מדדים מותאמים אישית, ופורסים את הגרסה המעודכנת של ה-HPA שקוראת מהמדדים המותאמים אישית האלה:

   sed -i.bak s/PROJECT_ID/$PROJECT_ID/g ./k8s/scheduled-autoscaler/scheduled-autoscale-example.yaml
   kubectl apply -f ./k8s/scheduled-autoscaler
   

5. פותחים את הקובץ k8s/scheduled-autoscaler/scheduled-autoscale-example.yaml ובודקים אותו.

   התוכן של הקובץ מוצג ברשימה הבאה.

   apiVersion: batch/v1
   kind: CronJob
   metadata:
     name: scale-up
   spec:
     schedule: "50-59/1 * * * *"
     jobTemplate:
       spec:
         template:
           spec:
             containers:
             - name: custom-metric-extporter
               image: us-central1-docker.pkg.dev/PROJECT_ID/gke-scheduled-autoscaler/custom-metric-exporter
               command:
                 - /export
                 - --name=scheduled_autoscaler_example
                 - --value=10
             restartPolicy: OnFailure
         backoffLimit: 1
   ---
   apiVersion: batch/v1
   kind: CronJob
   metadata:
     name: scale-down
   spec:
     schedule: "1-49/1 * * * *"
     jobTemplate:
       spec:
         template:
           spec:
             containers:
             - name: custom-metric-extporter
               image: us-central1-docker.pkg.dev/PROJECT_ID/gke-scheduled-autoscaler/custom-metric-exporter
               command:
                 - /export
                 - --name=scheduled_autoscaler_example
                 - --value=1
             restartPolicy: OnFailure
         backoffLimit: 1

   ההגדרה הזו מציינת שמשימות ה-Cron צריכות לייצא את מספר העותקים המוצע של ה-Pod למדד מותאם אישית בשם custom.googleapis.com/scheduled_autoscaler_example על סמך השעה ביום. כדי להקל על המעקב בחלק הזה של המדריך, הגדרת השדה schedule מגדירה הגדלה והקטנה של הקיבולת לפי שעה. בסביבת ייצור, אפשר להתאים אישית את לוח הזמנים הזה בהתאם לצרכים העסקיים שלכם.

6. פותחים את הקובץ k8s/scheduled-autoscaler/hpa-example.yaml ובודקים אותו.

   ברשימה הבאה מוצג התוכן של הקובץ.

   spec:
     maxReplicas: 20
     minReplicas: 1
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: php-apache
     metrics:
     - type: Resource
       resource:
         name: cpu
         target:
           type: Utilization
           averageUtilization: 60
     - type: External
       external:
         metric:
           name: custom.googleapis.com|scheduled_autoscaler_example
         target:
             type: AverageValue
             averageValue: 1

   ההגדרה הזו מציינת שאובייקט ה-HPA צריך להחליף את ה-HPA שנפרס קודם. שימו לב שההגדרה הזו מקטינה את הערך ב-minReplicas ל-1. כלומר, אפשר לצמצם את עומס העבודה למינימום. בנוסף, ההגדרה מוסיפה מדד חיצוני (type: External). המשמעות היא שהתאמה אוטומטית לעומס מופעלת עכשיו על ידי שני גורמים.

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

7. כדי לבדוק שוב את מספר הצמתים והעותקים של HPA, מריצים שוב כל אחת מהפקודות הבאות:

   kubectl get nodes
   kubectl get hpa php-apache
   

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

   לדוגמה, בערך בדקות 51 עד 60 של כל שעה (שמייצגות תקופה של שיא תנועה), ערך ה-HPA של minReplicas יהיה 10 והערך של nodes יהיה 4.

   לעומת זאת, בדקות 1 עד 50 (שמייצגות תקופה של תנועה נמוכה יותר), הערך של HPA minReplicas יהיה 1 והערך של nodes יהיה 1 או 2, בהתאם למספר ה-Pods שהוקצו והוסרו. במקרה של ערכים נמוכים יותר (דקה 1 עד 50), יכול להיות שיחלפו עד 10 דקות עד שההקטנה של האשכול תושלם.

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

בסביבת ייצור, בדרך כלל רוצים לדעת מתי משימות Cron לא מאכלסות את המדד המותאם אישית. לשם כך, אפשר ליצור התראה שמופעלת כשאין נתונים מכל אחד מזרמי custom.googleapis.com/scheduled_autoscaler_example במשך חמש דקות.

1. ב-Cloud Shell, יוצרים ערוץ התראות:

   gcloud beta monitoring channels create \
       --display-name="Scheduled Autoscaler team (Primary)" \
       --description="Primary contact method for the Scheduled Autoscaler team lead"  \
       --type=email \
       --channel-labels=email_address=${ALERT_EMAIL}
   

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

   Created notification channel NOTIFICATION_CHANNEL_ID.
   

   הפקודה הזו יוצרת ערוץ התראות מסוג email כדי לפשט את השלבים במדריך. בסביבות ייצור, מומלץ להשתמש באסטרטגיה פחות אסינכרונית על ידי הגדרת ערוץ ההתראות לערך sms או pagerduty.

2. מגדירים משתנה עם הערך שהוצג במחזיק המקום NOTIFICATION_CHANNEL_ID:

   NOTIFICATION_CHANNEL_ID=NOTIFICATION_CHANNEL_ID
   

3. פריסת מדיניות ההתראות:

   gcloud monitoring policies create \
       --policy-from-file=./monitoring/alert-policy.yaml \
       --notification-channels=$NOTIFICATION_CHANNEL_ID
   

   הקובץ alert-policy.yaml מכיל את המפרט לשליחת התראה אם המדד לא מופיע אחרי חמש דקות.

4. כדי לראות את מדיניות ההתראות, עוברים לדף התראות ב-Cloud Monitoring.

   מעבר אל Alerting

5. לוחצים על Scheduled Autoscaler Policy (מדיניות של שינוי גודל אוטומטי מתוזמן) ומאמתים את הפרטים של מדיניות ההתראות.

יצירת עומס באפליקציה לדוגמה

• ב-Cloud Shell, פורסים את מחולל העומסים:

  kubectl apply -f ./k8s/load-generator
  

  בקטע הקוד הבא מוצג הסקריפט load-generator:

  command: ["/bin/sh", "-c"]
  args:
  - while true; do
      RESP=$(wget -q -O- http://php-apache.default.svc.cluster.local);
      echo "$(date +%H)=$RESP";
      sleep $(date +%H | awk '{ print "s("$0"/3*a(1))*0.5+0.5" }' | bc -l);
    done;
  

  הסקריפט הזה  פועל באשכול עד שמוחקים את הפריסה load-generator deployment. הוא שולח בקשות לשירות php-apache כל כמה אלפיות השנייה. הפקודה sleep מדמה שינויים בחלוקת העומס במהלך היום. באמצעות סקריפט שיוצר תנועה באופן הזה, אפשר להבין מה קורה כשמשלבים בין ניצול CPU לבין מדדים מותאמים אישית בהגדרת ה-HPA.

המחשה של שינוי הגודל בתגובה לתנועה או למדדים מתוזמנים

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

1. יוצרים מרכז בקרה חדש ב-Cloud Shell:

   gcloud monitoring dashboards create \
       --config-from-file=./monitoring/dashboard.yaml
   

2. נכנסים לדף Dashboards ב-Cloud Monitoring:

   מעבר למרכזי השליטה

3. לוחצים על Scheduled Autoscaler Dashboard (לוח הבקרה של Scheduled Autoscaler).

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

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

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

   • מדד מתוזמן (מספר הפודים הרצוי) מציג סדרת זמנים של המדד המותאם אישית שמיוצא ל-Cloud Monitoring באמצעות CronJobs שהגדרתם במאמר הגדרת קנה מידה אוטומטי מתוזמן.

     

   • ניצול יחידת העיבוד המרכזית (CPU) (נדרש לעומת בשימוש) מציג סדרת זמן של יחידת העיבוד המרכזית (CPU) הנדרשת (אדום) וניצול יחידת העיבוד המרכזית (CPU) בפועל (כחול). כשהעומס נמוך, ה-HPA מכבד את החלטת הניצול של קנה המידה האוטומטי המתוזמן. עם זאת, כשהתנועה גדלה, ה-HPA מגדיל את מספר ה-Pods לפי הצורך, כמו שאפשר לראות בנקודות הנתונים בין 12:00 ל-18:00.

     

   • מספר ה-Pods (מתוכנן לעומת בפועל) + ממוצע השימוש במעבד מציג תצוגה שדומה לתצוגות הקודמות. מספר התרמילים (באדום) עולה ל-10 בכל שעה לפי התזמון (בכחול). מספר הפודים עולה ויורד באופן טבעי לאורך זמן בתגובה לעומס (12:00 ו-18:00). ממוצע השימוש במעבד (בכתום) נשאר מתחת ליעד שהגדרתם (60%).

     

הסרת המשאבים

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

מחיקת הפרויקט

זהירות: כשמוחקים פרויקט:

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

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

1. במסוף Google Cloud , נכנסים לדף Manage resources.

   כניסה לדף Manage resources

2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

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

• מידע נוסף על אופטימיזציה של עלויות ב-GKE זמין במאמר שיטות מומלצות להרצה של אפליקציות Kubernetes שעברו אופטימיזציה של עלויות ב-GKE.
• המלצות לעיצוב ושיטות מומלצות לאופטימיזציה של עלויותGoogle Cloud עומסי עבודה מפורטות במאמר Google Cloud Well-Architected Framework: Cost optimization.
• כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.