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 לעומס עבודה, בהתאם למדדים שצוינו.
מדמים עומס על האפליקציה וצופים בתגובה של המידרוג האוטומטי באשכול ושל Horizontal Pod Autoscaler (HPA).

עלויות

הפעלת 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 יפעל בצורה תקינה:

יוצרים חשבון שירות ב-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 כך שיפעל כחשבון השירות של IAM שיצרתם:default
```
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, כמו Monitoring, אתם יכולים להשתמש ב-איחוד זהויות של עומסי עבודה ל-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 של עומס עבודה.
התאמה אוטומטית של גודל האשכול: משנה את גודל המשאבים של הצמתים שזמינים באשכול.

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

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

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

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

התאמה לעומס של פריסת `userservice`

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

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

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

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, צריך למחוק את המשאבים שנבחרו בפרויקט אבל לא את הפרויקט כולו.

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

במסוף Google Cloud , נכנסים לדף Manage resources.
כניסה לדף Manage resources
ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

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

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