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

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

Autopilot

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

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

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

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

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

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

עלויות

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

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

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

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

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

צריך גם ליצור חשבון שירות ב-IAM ולהעניק כמה הרשאות כדי ש-Horizontal Pod Autoscaler (HPA) יפעל בצורה תקינה:

יוצרים חשבון שירות ב-IAM. חשבון השירות הזה משמש במדריך כדי להעניק גישה למדדים בהתאמה אישית, שמאפשרים ל-Horizontal Pod Autoscaler לקבוע מתי להגדיל או להקטין את קנה המידה:
```
gcloud iam service-accounts create scalable-apps
```

נותנים לחשבון השירות ב-IAM גישה לביצוע פעולות ההרחבה הנדרשות:

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role roles/cloudtrace.agent \
  --member "serviceAccount:scalable-apps@PROJECT_ID.iam.gserviceaccount.com"

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role roles/monitoring.metricWriter \
  --member "serviceAccount:scalable-apps@PROJECT_ID.iam.gserviceaccount.com"

gcloud iam service-accounts add-iam-policy-binding "scalable-apps@PROJECT_ID.iam.gserviceaccount.com" \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[default/default]"

הגישה הבאה ניתנת לחשבון השירות של IAM:

‫roles/cloudtrace.agent: כתיבת נתוני מעקב כמו מידע על זמן האחזור אל Trace.
‫roles/monitoring.metricWriter: כתיבת מדדים ל-Cloud Monitoring.
‫roles/iam.workloadIdentityUser: מאפשר לחשבון שירות של Kubernetes להשתמש באיחוד זהויות של עומסי עבודה ל-GKE כדי לפעול כחשבון שירות של IAM.

מגדירים את חשבון השירות של Kubernetes ‏default במרחב השמות default כך שיפעל כחשבון שירות של IAM שיצרתם:
```
kubectl annotate serviceaccount default \
    iam.gke.io/gcp-service-account=scalable-apps@PROJECT_ID.iam.gserviceaccount.com
```
ההגדרה הזו מאפשרת לקבוצות Pod שמשתמשות בחשבון השירות של Kubernetes במרחב השמות default לגשת לאותם משאבים כמו חשבון השירות של IAM.default Google Cloud

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

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

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

מקצים לחשבון השירות ב-IAM את התפקיד roles/monitoring.viewer:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:scalable-apps@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/monitoring.viewer
```

מגדירים את המתאם של Stackdriver כך שישתמש באיחוד זהויות של עומסי עבודה ל-GKE ובחשבון השירות של IAM שיש לו הרשאות לקרוא את מדדי המעקב:

gcloud iam service-accounts add-iam-policy-binding scalable-apps@PROJECT_ID.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[custom-metrics/custom-metrics-stackdriver-adapter]"

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

מוסיפים הערה לחשבון השירות ב-Kubernetes שבו המתאם משתמש:
```
kubectl annotate serviceaccount custom-metrics-stackdriver-adapter \
    --namespace=custom-metrics \
    iam.gke.io/gcp-service-account=scalable-apps@PROJECT_ID.iam.gserviceaccount.com
```

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

kubectl rollout restart deployment custom-metrics-stackdriver-adapter \
    --namespace=custom-metrics

הגדרת Horizontal Pod Autoscaler

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

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

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

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

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

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

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

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

בודקים את המניפסט לדוגמה HorizontalPodAutoscaler של הפריסה: userservice

# 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%, כדי להימנע מניצול יתר וגם מניצול חסר.

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

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

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

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

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

מאתרים את השם של כלל ההעברה מ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

מוסיפים את כלל ההעברה למניפסט:
```
sed -i "s/FORWARDING_RULE_NAME/$FW_RULE/g" "extras/postgres-hpa/hpa/frontend.yaml"
```
הפקודה הזו מחליפה את FORWARDING_RULE_NAME בכלל ההעברה ששמרתם.

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

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

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

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

לפני שמתחילים, בודקים את הסטטוס של 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

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

חשיפת ממשק האינטרנט loadgenerator באופן מקומי. משתמשים בממשק הזה כדי לדמות עומס על האפליקציה לדוגמה Cymbal Bank:
```
kubectl port-forward svc/loadgenerator 8080
```
אם מופיעה הודעת שגיאה, נסו שוב כשה-Pod פועל.
בדפדפן במחשב, פותחים את ממשק האינטרנט של מחולל העומסים:
- אם אתם משתמשים במעטפת מקומית, פותחים דפדפן ועוברים אל http://127.0.0.1:8080.
- אם משתמשים ב-Cloud Shell, לוחצים על תצוגה מקדימה באינטרנט ואז על תצוגה מקדימה ביציאה 8080.
בממשק האינטרנט של מחולל העומסים, אם הערך של Failures הוא 100%, צריך לבצע את השלבים הבאים כדי לעדכן את הגדרות הבדיקה:
1. לוחצים על הלחצן עצירה לצד מונה שיעור הכשלים.
2. בקטע סטטוס, לוחצים על האפשרות בדיקה חדשה.
3. מעדכנים את הערך של Host לכתובת ה-IP של הכניסה ל-Cymbal Bank.
4. לוחצים על התחלת ההתגודדות.
בממשק האינטרנט של מחולל העומסים, לוחצים על הכרטיסייה Charts כדי לראות את הביצועים לאורך זמן. בודקים את מספר הבקשות ואת ניצול המשאבים.
פותחים חלון טרמינל חדש וצופים במספר הרפליקות של הפודים frontend ו-userservice:
```
kubectl get hpa -w
```
מספר העותקים גדל ככל שהעומס גדל. יכול להיות שיחלפו כעשר דקות עד שהפעולות scaleUp יתבצעו, כי האשכול מזהה שהמדדים שהוגדרו מגיעים לסף שהוגדר, ומשתמש ב-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
```
פותחים חלון טרמינל נוסף ובודקים את מספר הצמתים באשכול:
```
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. לא צריך להגדיר שום דבר לגבי שינוי הגודל של הצומת הזה.
פותחים את הממשק של מחולל העומסים ולוחצים על Stop (הפסקה) כדי לסיים את הבדיקה.
בודקים שוב את מספר הרפליקות ומספר הצמתים ורואים שהמספרים קטנים יותר בעקבות העומס המופחת. יכול להיות שיעבור זמן עד שההקטנה תתבצע, כי חלון הייצוב שמוגדר כברירת מחדל עבור רפליקות במשאב HorizontalPodAutoscaler של Kubernetes הוא חמש דקות.

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

הסרת המשאבים

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

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

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

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

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

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

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

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