שינוי אוטומטי של גודל מאגרי העובדים באמצעות מדדים חיצוניים

בדף הזה מוסבר איך להגדיר התאמה אוטומטית לעומס של מאגרי Worker ב-Cloud Run באמצעות מדדים חיצוניים מבוססי-אירועים. התכונה "התאמה אוטומטית לעומס (automatic scaling) של מדדים חיצוניים ב-Cloud Run"‏ (CREMA) מאפשרת את הפונקציונליות הזו באמצעות התאמה אוטומטית לעומס (automatic scaling) מבוססת-אירועים ב-Kubernetes‏ (KEDA), כדי לשנות את קנה המידה של עומסי העבודה על סמך מקורות של אירועים חיצוניים.

כדי לראות את רכיבי ה-scaler הנתמכים ואת התאימות ל-Cloud Run, קראו את המאמר Cloud Run External Metrics Autoscaling (CREMA)‎ במאמרי העזרה של Google Cloud GitHub.

מידע על שירות ההתאמה האוטומטית לעומס (autoscaler)

כדי להתאים אוטומטית לעומס (autoscale) מאגרי workers, פורסים את שירות המידרוג האוטומטי של CREMA ב-Cloud Run. השירות הזה מבצע את הפעולות הבאות:

1. דגימה של מקורות אירועים חיצוניים, כמו נושאים של Apache Kafka או GitHub Runner Scaler.

2. מחשב את מספר המכונות הנדרש על סמך הגדרות ה-YAML.

3. עדכון אוטומטי של מספר המכונות במאגר ה-workers.

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

1. מוודאים שהגדרתם פרויקט חדש ל-Cloud Run, כמו שמתואר בדף ההגדרה.

2. מפעילים את ממשקי ה-API של Artifact Registry,‏ Cloud Build,‏ Cloud Run Admin API,‏ Secret Manager ו-Parameter Manager:

   gcloud services enable artifactregistry.googleapis.com \
       cloudbuild.googleapis.com \
       run.googleapis.com \
       secretmanager.googleapis.com \
       parametermanager.googleapis.com
   

3. מגדירים עומס עבודה מבוסס-אירועים או מבוסס-בקשות, כמו GitHub Runners או Apache Kafka. כדי לוודא שמקור עומס העבודה נתמך, עיינו ברשימת התאימות של CREMA במאמרי העזרה של Google Cloud ב-GitHub.

4. כדי להעריך את העלויות, אפשר להשתמש במחשבון העלויות. החיובים על שירות ההתאמה לעומס ב-Cloud Run מבוססים על התדירות שבה אתם מפעילים את ההתאמה לעומס.

התפקידים הנדרשים

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

• אדמין של מאגר Artifact Registry (roles/artifactregistry.repoAdmin)
• עריכה ב-Cloud Build ‏ (roles/cloudbuild.builds.editor)
• אדמין ב-Cloud Run (roles/run.admin)
• יצירת חשבונות שירות (roles/iam.serviceAccountCreator)
• אדמין ב-Secret Manager ‏ (roles/secretmanager.admin)
• משתמש בחשבון שירות (roles/iam.serviceAccountUser)
• Service Usage Consumer (roles/serviceusage.serviceUsageConsumer)
• אדמין באחסון (roles/storage.admin)
• אדמין ב-Parameter Manager (roles/parametermanager.admin)

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

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

הערה: התפקידים הבסיסיים של IAM עשויים גם להכיל הרשאות להתאמה אוטומטית לעומס של קבוצת ה-Workers. לא מומלץ להקצות תפקידים בסיסיים בסביבת ייצור, אבל אפשר להקצות אותם בסביבת פיתוח או בדיקה.

יצירת חשבון שירות בהתאמה אישית

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

gcloud iam service-accounts create CREMA_SERVICE_ACCOUNT \
  --display-name="CREMA Service Account"

מחליפים את CREMA_SERVICE_ACCOUNT בשם של חשבון השירות בהתאמה אישית, לדוגמה crema-service-account. הפקודה הזו יוצרת חשבון שירות בפורמט [e-mail].

יצירת קובץ התצורה של CREMA

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

דוגמה בפורמט YAML

בדוגמה הבאה מוצג קובץ התצורה לשינוי קנה המידה של מאגר ה-Workers ב-Cloud Run (example-workerpool) באמצעות המדדים של GitHub Runner. הוא משתמש בסוד של Secret Manager בשם github_runner_token כדי לבצע אימות מול GitHub ולקרוא את המדדים.

  apiVersion: crema/v1
  kind: CremaConfig
  metadata:
    name: gh-demo
  spec:
    triggerAuthentications:
      - metadata:
          name: github-trigger-auth
        spec:
          gcpSecretManager:
            secrets:
              - parameter: personalAccessToken
                id: github_runner_token
                version: latest
    scaledObjects:
      - spec:
          scaleTargetRef:
            name: projects/example-project/locations/us-central1/workerpools/example-workerpool
          triggers:
            - type: github-runner
              name: example-runner
              metadata:
                owner: repo-owner
                runnerScope: repo
                repos: repo-name
                targetWorkflowQueueLength: 1
              authenticationRef:
                name: github-trigger-auth
          advanced:
            horizontalPodAutoscalerConfig:
              behavior:
                scaleDown:
                  stabilizationWindowSeconds: 10
                  policies:
                    - type: Pods
                      value: 100
                      periodSeconds: 10
                scaleUp:
                  stabilizationWindowSeconds: 10
                  policies:
                    - type: Pods
                      value: 2
                      periodSeconds: 10
        pollingInterval: 10

הגדרות ה-YAML משתמשות בפרמטרים הבאים ברמה גבוהה:

• ‫triggerAuthentications: קובע איך CREMA מאמת את השירות החיצוני, למשל באמצעות אסימון שמאוחסן ב-Secret Manager.

• ‫scaledObjects: מגדיר את המיפוי בין מאגר ה-workers של Cloud Run לבין משאב המדדים החיצוני. הפרמטר הזה כולל:

  • ‫scaleTargetRef: השירותים של Cloud Run או מאגרי ה-workers שרוצים לשנות את קנה המידה שלהם.

  • triggers: המדד החיצוני הספציפי שמשמש לשינוי קנה המידה. אם מקור המדדים החיצוני דורש אימות, צריך להגדיר את השדה authenticationRef כדי לציין את אחד מהאובייקטים של TriggerAuthentications לפרטי הכניסה.

• ‫pollingInterval: קובע את המרווח (בשניות) שבו CREMA מרענן את המדדים שלו. אם לא תכללו את הפרמטר הזה, CREMA לא יבצע דגימה אוטומטית, ותצטרכו להפעיל בדיקת התאמה לעומס באופן ידני באמצעות בקשת POST לשירות.

מידע נוסף על הגדרת מדדים בסיסיים ומתקדמים זמין בקטע Configuration reference במאמרי העזרה של Google Cloud ב-GitHub.

הרשימה המלאה של הגדרות התצורה של סקלרים תואמים מופיעה בקטע Scalers במסמכי התיעוד של KEDA.

אחסון הגדרות CREMA ב-Parameter Manager

כדי לאחסן גרסאות של פרמטרים לשירות ההתאמה האוטומטית לעומס (CREMA):

1. יוצרים פרמטר ב-Parameter Manager:

   gcloud parametermanager parameters create PARAMETER_ID --location=global  --parameter-format=YAML
   

   מחליפים את PARAMETER_ID בשם הפרמטר.

2. מעלים את קובץ ה-YAML המקומי כגרסה חדשה של פרמטר:

   gcloud parametermanager parameters versions create PARAMETER_VERSION \
     --location=global \
     --parameter=PARAMETER_ID \
     --payload-data-from-file=LOCAL_YAML_CONFIG_FILE
   

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

   • ‫PARAMETER_VERSION: המזהה שרוצים להקצות לגרסה של פרמטר, לדוגמה 1.
   • ‫LOCAL_YAML_CONFIG_FILE: הנתיב לקובץ התצורה ב-YAML.

מידע נוסף זמין במאמר יצירת פרמטר.

מתן הרשאות נוספות לחשבון השירות של CREMA

כדי לשנות את הגודל של מאגר ה-Workers שציינתם בהגדרת ה-YAML, צריך לתת את ההרשאות הבאות בחשבון השירות בהתאמה אישית:

1. נותנים לחשבון השירות של CREMA הרשאה לקרוא מ-Parameter Manager:

   gcloud projects add-iam-policy-binding PROJECT_ID \
     --member="serviceAccount:CREMA_SERVICE_ACCOUNT_NAME \
     --role="roles/parametermanager.parameterViewer"
   

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

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

   • ‫CREMA_SERVICE_ACCOUNT_NAME: השם של חשבון השירות של CREMA.

2. מקצים לחשבון השירות של CREMA את התפקיד roles/run.developer במאגר ה-workers. כך שירות CREMA יכול לשנות את מספר המכונות במאגר ה-workers בתגובה לשינויים במדדים:

   WORKER_POOL_NAME=WORKER_POOL_NAME
   WORKER_POOL_REGION=WORKER_POOL_REGION
   gcloud run worker-pools add-iam-policy-binding $WORKER_POOL_NAME \
     --region=$WORKER_POOL_REGION \
     --member="serviceAccount:CREMA_SERVICE_ACCOUNT_NAME" \
     --role="roles/run.developer"
   

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

   • ‫WORKER_POOL_NAME: השם של מאגר ה-Workers.
   • ‫WORKER_POOL_REGION: האזור של מאגר ה-workers.

3. נותנים לחשבון השירות של CREMA הרשאה לכתוב מדדים:

    gcloud projects add-iam-policy-binding PROJECT_ID \
      --member="serviceAccount:CREMA_SERVICE_ACCOUNT_NAME" \
      --role="roles/monitoring.metricWriter"
   

4. מקצים לחשבון השירות של CREMA את התפקיד "משתמש בחשבון שירות":

   gcloud projects add-iam-policy-binding PROJECT_ID \
     --member="serviceAccount:CREMA_SERVICE_ACCOUNT_NAME" \
     --role="roles/iam.serviceAccountUser"
   

פריסת השירות כדי להרחיב את עומסי העבודה

כדי לפרוס את השירות ולהגדיל את מאגר ה-workers, מריצים את הפקודה הבאה עם קובץ אימג' של קונטיינר שנוצר מראש:

gcloud run deploy SERVICE_NAME\
  --image=us-central1-docker.pkg.dev/cloud-run-oss-images/crema-v1/autoscaler:1.0 \
  --region=SERVICE_REGION \
  --service-account="CREMA_SERVICE_ACCOUNT_NAME" \
  --no-allow-unauthenticated \
  --no-cpu-throttling \
  --base-image=us-central1-docker.pkg.dev/serverless-runtimes/google-24/runtimes/java25 \
  --labels=created-by=crema \
  --set-env-vars="CREMA_CONFIG=projects/PROJECT_ID/locations/PARAMETER_REGION/parameters/PARAMETER_ID/versions/PARAMETER_VERSION,OUTPUT_SCALER_METRICS=True"

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

• ‫SERVICE_NAME: השם של שירות ה-autoscaler.

• ‫SERVICE_REGION: האזור של השירות.

• ‫CREMA_SERVICE_ACCOUNT_NAME: השם של חשבון השירות של CREMA.

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

• ‫PARAMETER_REGION, PARAMETER_ID ו-PARAMETER_VERSION: ערכים ששמרתם ב-Parameter Manager.

אתם יכולים גם לפרוס את שירות ה-CREMA באמצעות קובץ אימג' של קונטיינר בהתאמה אישית שאתם יוצרים מקוד המקור באמצעות Cloud Build.

בדיקת שירות ה-CREMA

כדי לוודא ששירות ההתאמה האוטומטית לעומס פועל כמו שצריך, בודקים את הכרטיסייה Logs של שירות Cloud Run.

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

כל הודעת יומן מסומנת בתווית של הרכיב שהפיק אותה.

[INFO] [METRIC-PROVIDER] Starting metric collection cycle
[INFO] [METRIC-PROVIDER] Successfully fetched scaled object metrics ...
[INFO] [METRIC-PROVIDER] Sending scale request ...
[INFO] [SCALER] Received ScaleRequest ...
[INFO] [SCALER] Current instances ...
[INFO] [SCALER] Recommended instances ...

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

• איך משתמשים ב-GitHub Runners באירוח עצמי במאגרי Worker כדי להריץ את תהליכי העבודה שמוגדרים במאגר GitHub, ואיך משנים את הגודל של מאגר ה-Worker באמצעות CREMA.

• מידע נוסף על מאגרי וורקרים ב-Cloud Run