תוכנית לימודים: אפליקציות ניתנות להרחבה – הרחבה

Autopilot

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

1. יצירת אשכול ופריסת אפליקציה לדוגמה
2. מעקב באמצעות השירות המנוהל של Google Cloud ל-Prometheus
3. התאמת עומסי עבודה (המדריך הזה)
4. סימולציה של כשל
5. ניהול שינויים מרכזי

סקירה כללית ומטרות

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

במדריך הזה נלמד איך להגדיר אשכולות ועומסי עבודה באשכול GKE כדי לשנות את הגודל שלהם באמצעות מדדים מובנים של Kubernetes ומדדים מותאמים אישית מ-Cloud Monitoring ומ-Cloud Trace. תלמדו איך לבצע את המשימות הבאות:

• מפעילים מדדים מותאמים אישית ב-Cloud Monitoring עבור Trace.
  • מדדים מותאמים אישית מאפשרים לכם להרחיב את המעקב באמצעות נתוני מעקב נוספים או נתונים חיצוניים שלא קשורים לאשכול Kubernetes, כמו תנועת רשת או קודי תגובה של HTTP.
• מגדירים את Horizontal Pod Autoscaler (HPA), תכונה של GKE שיכולה להגדיל או להקטין באופן אוטומטי את מספר ה-Pods לעומס עבודה, בהתאם למדדים שצוינו.
• מדמים עומס על האפליקציה וצופים בתגובה של המידרוג האוטומטי באשכול ושל Horizontal Pod Autoscaler.

עלויות

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

אתם אחראים גם לעלויות אחרות Google Cloud שנובעות מהפעלת אפליקציית הדוגמה Cymbal Bank, כמו חיובים על מכונות וירטואליות של Compute Engine ועל Trace.

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

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

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

צריך גם להעניק הרשאות IAM כדי שעומסי העבודה ו-Horizontal Pod Autoscaler יוכלו לכתוב עקבות ולקרוא מדדים בהתאמה אישית:

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/cloudtrace.agent \
  --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/default/sa/default" \
  --condition=None

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/monitoring.metricWriter \
  --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/default/sa/default" \
  --condition=None

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

• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
• ‫PROJECT_NUMBER: מספר הפרויקט ב- Google Cloud .

הגישה הבאה ניתנת לקבוצות Pod שמשתמשות ב-default Kubernetes ServiceAccount במרחב השמות default:

• ‫roles/cloudtrace.agent: כתיבת נתוני מעקב כמו מידע על זמן האחזור אל Trace.
• ‫roles/monitoring.metricWriter: כתיבת מדדים ל-Cloud Monitoring.

הגדרת איסוף של מדדים מותאמים אישית

אפשר להגדיר את Horizontal Pod Autoscaler כך שישתמש במדדי CPU וזיכרון בסיסיים מובנים של Kubernetes, או להשתמש במדדים מותאמים אישית מ-Cloud Monitoring, כמו בקשות HTTP לשנייה או כמות ההצהרות SELECT. אפשר להשתמש במדדים מותאמים אישית בלי לבצע שינויים באפליקציה, ולקבל תובנות נוספות לגבי הביצועים הכוללים והצרכים של האפליקציה. במדריך הזה נסביר איך להשתמש במדדים המובְנים ובמדדים מותאמים אישית.

1. כדי לאפשר ל-Horizontal Pod Autoscaler לקרוא מדדים מותאמים אישית מ-Monitoring, צריך להתקין את המתאם Custom Metrics - Stackdriver Adapter באשכול.

   פורסים את המתאם של Stackdriver למדדים מותאמים אישית באשכול:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter.yaml
   

2. כדי לאפשר למתאם Stackdriver לקבל מדדים בהתאמה אישית מהאשכול, צריך להקצות ל-custom-metrics-stackdriver-adapter Kubernetes ServiceAccount את התפקיד roles/monitoring.viewer באמצעות איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/custom-metrics/sa/custom-metrics-stackdriver-adapter" \
       --role=roles/monitoring.viewer \
       --condition=None
   

יעד: כל הכבוד! עכשיו יש לכם מתאם Stackdriver באשכול GKE שמוגדר לקריאת מדדים מותאמים אישית מ-Monitoring.

הגדרת Horizontal Pod Autoscaler

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

• ‫Horizontal Pod Autoscaler‏ (HPA): משנה את מספר ה-Pods של עומס עבודה.
• התאמה אוטומטית של גודל האשכול: משנה את גודל המשאבים של הצמתים שזמינים באשכול.

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

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

במדריך הזה נלמד איך להגדיר את הכלי Horizontal Pod Autoscaler עבור userserviceפריסה באמצעות מדדים מובנים, ועבור frontendפריסה באמצעות מדדים מותאמים אישית.

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

שינוי הגודל של פריסת userservice

ככל שמספר המשתמשים באפליקציית הדוגמה Cymbal Bank גדל, כך שירות userservice צורך יותר משאבי CPU. משתמשים באובייקט HorizontalPodAutoscaler כדי לקבוע איך האפליקציה תגיב לטעינה. במניפסט YAML של HorizontalPodAutoscaler, מגדירים את הפריסה שצריך לשנות את הגודל שלה באמצעות Horizontal Pod Autoscaler, את המדדים שצריך לעקוב אחריהם ואת המספר המינימלי והמקסימלי של רפליקות שרוצים להריץ.

1. בודקים את המניפסט לדוגמה HorizontalPodAutoscaler של userserviceDeployment:

   # Copyright 2022 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #      http://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   ---
   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: userservice
   spec:
     behavior:
       scaleUp:
         stabilizationWindowSeconds: 0
         policies:
           - type: Percent
             value: 100
             periodSeconds: 5
         selectPolicy: Max
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: userservice
     minReplicas: 5
     maxReplicas: 50
     metrics:
       - type: Resource
         resource:
           name: cpu
           target:
             type: Utilization
             averageUtilization: 60
   

   קובץ המניפסט הזה:

   • ההגדרה הזו קובעת את המספר המקסימלי של העותקים במהלך הגדלה עד 50.
   • המספר המינימלי של מכונות במהלך הקטנת הקיבולת נקבע כ-5.
   • משתמש במדד מובנה של Kubernetes כדי לקבל החלטות לגבי שינוי גודל. בדוגמה הזו, המדד הוא ניצול המעבד (CPU), וניצול היעד הוא 60%, כדי להימנע מניצול יתר ומתת-ניצול.

2. החלת המניפסט על האשכול:

   kubectl apply -f extras/postgres-hpa/hpa/userservice.yaml
   

שינוי הגודל של פריסת frontend

בקטע הקודם הגדרתם את Horizontal Pod Autoscaler ב-userservice Deployment על סמך מדדי Kubernetes מובנים לניצול CPU. בפריסה frontend, יכול להיות שתרצו להגדיל את הקיבולת לפי מספר בקשות ה-HTTP הנכנסות. בגישה הזו נעשה שימוש במתאם Stackdriver כדי לקרוא מדדים מותאמים אישית מ-Monitoring לאובייקט Ingress של מאזן עומסים מסוג HTTP(S).

1. בודקים את HorizontalPodAutoscaler המניפסט של frontend הפריסה:

   # Copyright 2022 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #      http://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   ---
   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: frontend
   spec:
     behavior:
       scaleUp:
         stabilizationWindowSeconds: 0
         policies:
           - type: Percent
             value: 100
             periodSeconds: 5
         selectPolicy: Max
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: frontend
     minReplicas: 5
     maxReplicas: 25
     metrics:
       - type: External
         external:
           metric:
             name: loadbalancing.googleapis.com|https|request_count
             selector:
               matchLabels:
                 resource.labels.forwarding_rule_name: FORWARDING_RULE_NAME
           target:
             type: AverageValue
             averageValue: "5"
   

   קובץ המניפסט הזה כולל את השדות הבאים:

   • ‫spec.scaleTargetRef: משאב ב-Kubernetes לשינוי גודל.
   • ‫spec.minReplicas: מספר העותקים המינימלי, שהוא 5 בדוגמה הזו.
   • ‫spec.maxReplicas: המספר המקסימלי של העותקים, שהוא 25 בדוגמה הזו.
   • ‫spec.metrics.*: המדד שבו רוצים להשתמש. בדוגמה הזו, זהו מספר בקשות ה-HTTP לשנייה, שהוא מדד בהתאמה אישית מ-Monitoring שסופק על ידי המתאם שפרסתם.
   • ‫spec.metrics.external.metric.selector.matchLabels: תווית המשאב הספציפית שרוצים לסנן כשמשנים את קנה המידה.

2. מאתרים את השם של כלל ההעברה מהקטע frontend Ingress load balancer:

   export FW_RULE=$(kubectl get ingress frontend -o=jsonpath='{.metadata.annotations.ingress\.kubernetes\.io/forwarding-rule}')
   echo $FW_RULE
   

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

   k8s2-fr-j76hrtv4-default-frontend-wvvf7381
   

3. מוסיפים את כלל ההעברה למניפסט:

   sed -i "s/FORWARDING_RULE_NAME/$FW_RULE/g" "extras/postgres-hpa/hpa/frontend.yaml"
   

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

4. החלת המניפסט על האשכול:

   kubectl apply -f extras/postgres-hpa/hpa/frontend.yaml
   

יעד: כל הכבוד! מעכשיו יש לכם כללים של Horizontal Pod Autoscaler שהוגדרו לפריסות באשכול GKE באמצעות מדדים מובנים מ-Kubernetes ומדדים מותאמים אישית מ-Monitoring.

סימולציה של עומס

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

1. לפני שמתחילים, בודקים את הסטטוס של Horizontal Pod Autoscaler (HPA) ואת מספר הרפליקות שבשימוש.

   קבלת המצב של משאבי HorizontalPodAutoscaler:

   kubectl get hpa
   

   הפלט אמור להיראות כך, ולציין שיש רפליקה אחת של frontend ו-5 רפליקות של userservice:

   NAME                     REFERENCE                            TARGETS             MINPODS   MAXPODS   REPLICAS   AGE
   frontend                 Deployment/frontend                  <unknown>/5 (avg)   5         25        1          34s
   userservice              Deployment/userservice               0%/60%              5         50        5          4m56s
   

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

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

   kubectl port-forward svc/loadgenerator 8080
   

   אם מופיעה הודעת שגיאה, נסו שוב כשה-Pod פועל.

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

   • אם אתם משתמשים במעטפת מקומית, פותחים דפדפן ועוברים אל http://127.0.0.1:8080.
   • אם אתם משתמשים ב-Cloud Shell, לוחצים על Web preview ואז על Preview on port 8080.

4. בממשק האינטרנט של מחולל העומסים, אם הערך של Failures הוא 100%, צריך לבצע את השלבים הבאים כדי לעדכן את הגדרות הבדיקה:

   1. לוחצים על הלחצן עצירה לצד מונה שיעור הכשלים.
   2. בקטע סטטוס, לוחצים על האפשרות בדיקה חדשה.
   3. מעדכנים את הערך של Host לכתובת ה-IP של הכניסה ל-Cymbal Bank.
   4. לוחצים על התחלת ההתגודדות.

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

6. פותחים חלון טרמינל חדש וצופים במספר העותקים של הפודים frontend ו-userservice:

   kubectl get hpa -w
   

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

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

   NAME                     REFERENCE                            TARGETS          MINPODS   MAXPODS   REPLICAS
   frontend                 Deployment/frontend                  5200m/5 (avg)    5         25        13
   userservice              Deployment/userservice               71%/60%          5         50        17
   

7. פותחים חלון טרמינל נוסף ובודקים את מספר הצמתים באשכול:

   gcloud container clusters list \
       --filter='name=scalable-apps' \
       --format='table(name, currentMasterVersion, currentNodeVersion, currentNodeCount)' \
       --location="CONTROL_PLANE_LOCATION"
   

   מחליפים את CONTROL_PLANE_LOCATION במיקום של Compute Engine במישור הבקרה של האשכול. מציינים אזור לאשכולות אזוריים או אזור לאשכולות אזוריים.

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

8. פותחים את הממשק של מחולל העומסים ולוחצים על Stop (הפסקה) כדי לסיים את הבדיקה.

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

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

המטרה: כל הכבוד! עכשיו אפשר להגדיר את GKE כך שיבצע שינוי גודל בהתאם לעומס, כולל שימוש במדדים מותאמים אישית מ-Monitoring.

הסרת המשאבים

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

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

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

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

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

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

   כניסה לדף Manage resources

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

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

במדריך הבא מוסבר איך מדמים כשל ב-GKE.