פתרון בעיות ביצירת אשכול

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

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

  • למשתמש אין הרשאה לפעול כחשבון שירות

    הגורם: לחשבון המשתמש שמנסה ליצור את אשכול Dataproc אין את ההרשאות הנדרשות לשימוש בחשבון השירות שצוין. משתמשי Dataproc צריכים לקבל את ההרשאה ActAs בחשבון השירות כדי לפרוס משאבי Dataproc. ההרשאה הזו כלולה בתפקיד 'משתמש בחשבון שירות' (roles/iam.serviceAccountUser) (ראו תפקידים ב-Dataproc).

    פתרון: מאתרים את המשתמש או חשבון השירות שמנסה ליצור את אשכול Dataproc. מעניקים לחשבון המשתמש את התפקיד 'משתמש בחשבון שירות' (roles/iam.serviceAccountUser) בחשבון השירות שהאשכול מוגדר להשתמש בו (בדרך כלל חשבון השירות של המכונה הווירטואלית של Dataproc).

  • תם הזמן הקצוב לתפוגה של הפעולה: רק 0 מתוך 2 הצמתים הנדרשים של נתוני המינימום או מנהלי הצמתים פועלים.

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

    פתרון:

  • נדרשת הרשאה compute.subnetworks.use עבור projects/{projectId}/regions/{region}/subnetworks/{subnetwork}

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

    פתרון: פועלים לפי השלבים שמפורטים במאמר בנושא יצירת אשכול שמשתמש ברשת VPC בפרויקט אחר.

  • באזור projects/zones/{zone} אין מספיק משאבים זמינים כדי למלא את הבקשה (resource type:compute)

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

    פתרון:

    • משתמשים בתכונה בחירת תחום אוטומטית (Auto Zone) של Dataproc כדי ליצור את האשכול בכל אחד מהאזורים עם משאבים זמינים.
    • יוצרים את האשכול באזור אחר.
  • שגיאות של חריגה מהמכסה

    מכסת CPUS/CPUS_ALL_REGIONS לא מספיקה
    מכסת DISKS_TOTAL_GB לא מספיקה
    מכסת IN_USE_ADDRESSES לא מספיקה

    הסיבה: הבקשה שלך למעבד, לדיסק או לכתובת IP חורגת מהמכסה הזמינה.

    פתרון: שולחים בקשה להגדלת המכסה מGoogle Cloud מסוף.

  • פעולת האתחול נכשלה

    הסיבה: פעולת האתחול שסופקה במהלך יצירת האשכול נכשלה בהתקנה.

    פתרון:

  • ההפעלה של הצומת CLUSTER-NAME-m נכשלה. ‫… See output in: <gs://PATH_TO_STARTUP_SCRIPT_OUTPUT>

    הסיבה: לא ניתן לאתחל את צומת הבקרה של אשכול Dataproc.

    פתרון:

    • בודקים את יומני הפלט של סקריפט לטעינה בזמן ההפעלה שמפורטים בהודעת השגיאה (gs://PATH_TO_STARTUP_SCRIPT_OUTPUT) ומוודאים מה הסיבה לכך שהאתחול של הצומת נכשל.
    • הסיבות יכולות להיות בעיות בהגדרת הרשת של אשכול Dataproc והתקנה שנכשלה של יחסי תלות בחבילת Python.
    • אם הבעיה לא נפתרה אחרי שבדקתם את היומנים של סקריפט ההפעלה, תקנתם בעיות בצד המשתמש וניסיתם שוב עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff), פנו אל התמיכה של Google Cloud.
  • יצירת האשכול נכשלה: אין יותר מקום בטווח כתובות ה-IP

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

    פתרון:

    • ליצור אשכול עם פחות צמתים של עובדים, אבל עם סוג מכונה גדול יותר.
    • יוצרים אשכול ברשת משנה או ברשת אחרת.
    • כדי לפנות מקום לכתובות IP, צריך לצמצם את השימוש ברשת.
    • מחכים עד שיהיה מספיק מרחב כתובות IP ברשת.
  • הודעת שגיאה בסקריפט ההפעלה: למאגר REPO_NAME אין יותר קובץ Release

    הסיבה: מאגר ה-backports של Debian oldstable נמחק.

    פתרון:

    מוסיפים את הקוד הבא לפני הקוד שמריץ את apt-get בסקריפט האתחול.

    oldstable=$(curl -s https://deb.debian.org/debian/dists/oldstable/Release | awk '/^Codename/ {print $2}');
    stable=$(curl -s https://deb.debian.org/debian/dists/stable/Release | awk '/^Codename/ {print $2}');
    
    matched_files="$(grep -rsil '\-backports' /etc/apt/sources.list*)"
    if [[ -n "$matched_files" ]]; then
      for filename in "$matched_files"; do
        grep -e "$oldstable-backports" -e "$stable-backports" "$filename" || \
          sed -i -e 's/^.*-backports.*$//' "$filename"
      done
    fi
    
  • הזמן הקצוב לתפוגה של ההמתנה לדיווח של מופע DATAPROC_CLUSTER_VM_NAME הסתיים או לא ניתן להגיע לרשת: dataproccontrol-REGION.googleapis.com

    הסיבה: הודעות השגיאה האלה מצביעות על כך שהגדרת הרשת של אשכול Dataproc לא הושלמה: יכול להיות שחסר מסלול לשער האינטרנט שמוגדר כברירת מחדל או כללי חומת אש.

    פתרון:

    כדי לפתור את הבעיה, אפשר ליצור את בדיקות הקישוריות הבאות:

    • יצירת בדיקת קישוריות בין שתי מכונות וירטואליות של אשכול Dataproc. תוצאות הבדיקה הזו יעזרו לכם להבין אם כללי חומת האש של הרשת שלכם לגבי תעבורת נתונים נכנסת או יוצאת חלים על המכונות הווירטואליות של האשכול בצורה נכונה.
    • יוצרים בדיקת קישוריות בין מכונה וירטואלית באשכול Dataproc לבין כתובת IP של Dataproc Control API. כדי לקבל את כתובת ה-IP הנוכחית של Dataproc Control API, משתמשים בפקודה הבאה:
    dig dataproccontrol-REGION.googleapis.com A
    

    משתמשים באחת מכתובות ה-IPv4 בקטע התשובה של הפלט.

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

    על סמך התוצאות של בדיקות הקישוריות:

  • שגיאה בגלל עדכון

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

    פתרון:

    • איפוס האשכול: פותחים כרטיס תמיכה, כוללים קובץ tar של אבחון ומבקשים לאפס את האשכול למצב RUNNING.

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

טיפים לפתרון בעיות באשכול

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

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

תסמינים נפוצים

אלה תסמינים נפוצים שקשורים לכשלים ביצירת אשכולות:

  • סטטוס האשכול נשאר PENDING או PROVISIONING למשך תקופה ממושכת.
  • האשכול עובר למצב ERROR.
  • שגיאות כלליות ב-API במהלך יצירת האשכול, כמו Operation timed out.
  • הודעות שגיאה שמופיעות ביומן או בתגובת ה-API, כמו:

    • RESOURCE_EXHAUSTED: קשורות למכסות של CPU, דיסק או כתובת IP
    • Instance failed to start
    • Permission denied
    • Unable to connect to service_name.googleapis.com או Could not reach required Google APIs
    • Connection refused או network unreachable
    • שגיאות שקשורות לכשל בפעולות אתחול, כמו שגיאות בהרצת סקריפט וקובץ שלא נמצא.

בדיקת יומני האשכול

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

  1. נכנסים לדף Logs Explorer: פותחים את Logs Explorer במסוף Google Cloud .
  2. סינון של אשכולות Dataproc:
    • בתפריט הנפתח משאב, בוחרים באפשרות Cloud Dataproc Cluster.
    • מזינים את cluster_name ואת project_id. אפשר גם לסנן לפי location (אזור).
  3. בדיקת רשומות ביומן:
    • חפשו הודעות ברמה ERROR או WARNING שמופיעות בסמוך לזמן שבו נכשלה יצירת האשכול.
    • כדאי לשים לב ליומנים מרכיבי master-startup,‏ worker-startup ו-agent כדי לקבל תובנות לגבי בעיות ברמת מכונת ה-VM או בסוכן Dataproc.
    • כדי לקבל תובנות לגבי בעיות בזמן האתחול של מכונת ה-VM, מסננים את היומנים לפי resource.type="gce_instance" ומחפשים הודעות משמות המופעים שמשויכים לצמתי האשכול, כמו CLUSTER_NAME-m או CLUSTER_NAME-w-0. יומני מסוף סדרתי יכולים לחשוף בעיות בהגדרת הרשת, בעיות בדיסק וכשלים בסקריפטים שמתרחשים בשלב מוקדם במחזור החיים של מכונת ה-VM.

סיבות נפוצות לכשל באשכול וטיפים לפתרון בעיות

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

אין מספיק הרשאות IAM

חשבון השירות של המכונה הווירטואלית שבו משתמש אשכול Dataproc צריך לכלול תפקידי IAM מתאימים כדי להקצות מכונות של Compute Engine, לגשת לקטגוריות של Cloud Storage, לכתוב יומנים ולקיים אינטראקציה עם שירותים אחרים של Google Cloud .

  • תפקיד Worker נדרש: מוודאים שלחשבון השירות של מכונת ה-VM יש את התפקיד Dataproc Worker (roles/dataproc.worker). התפקיד הזה כולל את ההרשאות המינימליות שנדרשות ל-Dataproc כדי לנהל משאבי אשכול.
  • הרשאות גישה לנתונים: אם העבודות קוראות מ-Cloud Storage או מ-BigQuery או כותבות לתוכם, לחשבון השירות צריכים להיות תפקידים שקשורים לכך, כמו Storage Object Viewer,‏ Storage Object Creator או Storage Object Admin ל-Cloud Storage, או BigQuery Data Viewer או BigQuery Editor ל-BigQuery.
  • הרשאות רישום ביומן: לחשבון השירות צריך להיות תפקיד עם ההרשאות הנדרשות לכתיבת יומנים ב-Cloud Logging, כמו התפקיד Logging Writer.

טיפים לפתרון בעיות:

חריגה ממכסות משאבים

אשכולות Dataproc צורכים משאבים מ-Compute Engine ומ Google Cloud שירותים אחרים. חריגה מהמכסות של הפרויקט או של האזור עלולה לגרום לכשלים ביצירת אשכולות.

  • מכסות Dataproc נפוצות שכדאי לבדוק:
    • CPUs (אזורי)
    • DISKS_TOTAL_GB (אזורי)
    • IN_USE_ADDRESSES (אזוריות לכתובות IP פנימיות, גלובליות לכתובות IP חיצוניות)
    • מכסות של Dataproc API, כמו ClusterOperationRequestsPerMinutePerProjectPerRegion

טיפים לפתרון בעיות:

  • בדיקת מכסות: נכנסים לדף IAM & Admin > IAM במסוף Google Cloud . מסננים את העמודה 'שירות' לפי הערכים 'Compute Engine API' ו-'Dataproc API'.
  • בדיקת השימוש לעומת המגבלה: זיהוי מכסות שהגיעו למגבלות או מתקרבות אליהן.
  • במקרה הצורך, מבקשים להגדיל את המכסה.

בעיות בהגדרת הרשת

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

  • רשת VPC ותת-רשת:
    • מוודאים שרשת ה-VPC והרשת המשנית של האשכול קיימות ומוגדרות בצורה נכונה.
    • מוודאים שלרשת המשנה יש טווח מספיק של כתובות IP זמינות.
  • גישה פרטית ל-Google (PGA): אם למכונות הווירטואליות באשכול יש כתובות IP פנימיות והן צריכות להגיע לממשקי Google API עבור Cloud Storage,‏ Cloud Logging ופעולות אחרות, צריך לוודא שגישה פרטית ל-Google מופעלת ברשת המשנה. כברירת מחדל, מכונות וירטואליות (VM) באשכולות Dataproc שנוצרו עם גרסאות של קובצי אימג' מגרסה 2.2 ומעלה מוקצות עם כתובות IP פנימיות בלבד, כשהגישה הפרטית ל-Google מופעלת ברשת המשנה האזורית של האשכול.
  • Private Service Connect ‏(PSC): אם אתם משתמשים ב-Private Service Connect כדי לגשת ל-Google APIs, ודאו שנקודות הקצה (endpoints) של Private Service Connect שנדרשות מוגדרות בצורה נכונה עבור Google APIs ש-Dataproc תלוי בהם, כמו dataproc.googleapis.com,‏ storage.googleapis.com,‏ compute.googleapis.com ו-logging.googleapis.com. ערכי ה-DNS של ממשקי ה-API צריכים להתפרש ככתובות IP פרטיות. שימו לב: שימוש ב-Private Service Connect לא מבטל את הצורך בקישור (peering) בין רשתות VPC כדי לתקשר עם רשתות VPC אחרות שמנוהלות על ידי לקוחות.
  • קישור (peering) בין רשתות VPC שכנות: אם האשכול מתקשר עם משאבים ברשתות VPC אחרות, כמו פרויקטים מארחים של VPC משותף או רשתות VPC אחרות של לקוחות, צריך לוודא שהקישור בין רשתות ה-VPC הוגדר בצורה נכונה ושהנתיבים מופצים.
  • כללי חומת אש:

    • כללי ברירת מחדל: מוודאים שכללי ברירת המחדל של חומת האש, כמו allow-internal או allow-ssh, לא מגבילים מדי.
    • כללים מותאמים אישית: אם יש כללים מותאמים אישית לחומת האש, צריך לוודא שהם מאפשרים את נתיבי התקשורת הנדרשים:

      • תקשורת פנימית בתוך האשכול (בין צומתי -m לבין צומתי -w).
      • תעבורה יוצאת ממכונות וירטואליות באשכול אל ממשקי ה-API של Google, באמצעות כתובות IP ציבוריות או שער לאינטרנט, גישה פרטית ל-Google או נקודות קצה של Private Service Connect.

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

  • פענוח DNS: מוודאים שמופעים של אשכול יכולים לפתור נכון שמות DNS עבור Google APIs וכל שירות פנימי או חיצוני.

טיפים לפתרון בעיות:

  • בדיקת הגדרות הרשת: בודקים את ההגדרות של רשת ה-VPC ושל רשת המשנה שבהן מתבצעת הפריסה של האשכול.
  • בדיקת כללי חומת האש: בודקים את כללי חומת האש ברשת ה-VPC או בפרויקט המארח של ה-VPC המשותף.
  • בודקים את הקישוריות: מפעילים מכונה וירטואלית זמנית ב-Compute Engine ברשת המשנה של האשכול ומבצעים את השלבים הבאים:
    • ping או curl לדומיינים חיצוניים של Google API, כמו storage.googleapis.com.
    • nslookup כדי לוודא שכתובות ה-IP הצפויות מתקבלות מפתרון ה-DNS (גישה פרטית ל-Google או Private Service Connect).
    • מריצים Google Cloud בדיקות קישוריות כדי לאבחן נתיבים ממכונה וירטואלית לבדיקה לנקודות קצה רלוונטיות.

כשלים בפעולות אתחול

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

טיפים לפתרון בעיות:

  • בדיקת יומנים של שגיאות בפעולת האתחול: מחפשים ב-Cloud Logging רשומות ביומן שקשורות ל-init-actions או ל-startup-script עבור מופעי האשכול.
  • בודקים את נתיבי הסקריפטים וההרשאות: מוודאים שסקריפטים של פעולות אתחול ממוקמים בצורה נכונה ב-Cloud Storage, ושלחשבון השירות של מכונת ה-VM באשכול יש את התפקיד Storage Object Viewer שנדרש לקריאת סקריפטים של Cloud Storage.
  • ניפוי באגים בלוגיקה של הסקריפט: בודקים את הלוגיקה של הסקריפט במכונה וירטואלית נפרדת של Compute Engine שמדמה את סביבת האשכול כדי לזהות שגיאות. מוסיפים לסקריפט רישום מפורט של פעולות.

זמינות של משאבים אזוריים (מלאי חסר)

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

טיפים לפתרון בעיות:

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

פנייה ל-Cloud Customer Care

אם אתם ממשיכים להיתקל בבעיות שקשורות לכשל באשכול, אתם יכולים לפנות אל Cloud Customer Care. תארו את בעיית הכשל באשכול ואת השלבים שביצעתם כדי לפתור אותה. בנוסף, עליך לספק את הפרטים הבאים:

  • נתוני אבחון של אשכול
  • פלט מהפקודה הבאה:
      gcloud dataproc clusters describe CLUSTER_NAME \
          --region=REGION
      
  • היומנים של האשכול שנכשל יוצאו.

שימוש בכלי gcpdiag

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

הכלי gcpdiag עוזר לכם לגלות בעיות ביצירת אשכול Dataproc באמצעות הבדיקות הבאות:

  • שגיאות של חוסר במלאי: בודק את היומנים בכלי Logs Explorer כדי לגלות חוסר במלאי באזורים ובאזורי זמינות.
  • מכסה לא מספיקה: בדיקת זמינות המכסה בפרויקט של אשכול Dataproc.
  • הגדרת רשת לא מלאה: מבצע בדיקות קישוריות לרשת, כולל בדיקות של כללי חומת האש הנדרשים והגדרות של כתובות IP חיצוניות ופנימיות. אם האשכול נמחק, הכלי gcpdiag לא יכול לבצע בדיקה של קישוריות הרשת.
  • הגדרה שגויה של פרויקטים שונים: בדיקה של חשבונות שירות בפרויקטים שונים, ובדיקה של תפקידים נוספים ושל אכיפת מדיניות הארגון.
  • תפקידי IAM חסרים ברשת של ענן וירטואלי פרטי (VPC) משותף: אם אשכול Dataproc משתמש ברשת VPC משותפת, המערכת בודקת אם נוספו תפקידים נדרשים של חשבון שירות.
  • כשלים בפעולות אתחול: הערכת יומנים בכלי Logs Explorer כדי לגלות כשלים ופסק זמן בסקריפטים של פעולות אתחול.

רשימת השלבים ליצירת אשכול מופיעה במאמר שלבים אפשריים.gcpdiag

מריצים את הפקודה gcpdiag.

אפשר להריץ את הפקודה gcpdiag מ-Cloud Shell במסוףGoogle Cloud או בתוך מאגר Docker.

מסוףGoogle Cloud

  1. משלימים את הפקודה הבאה ואז מעתיקים אותה.
  2. gcpdiag runbook dataproc/cluster-creation \
        --parameter project_id=PROJECT_ID \
        --parameter cluster_name=CLUSTER_NAME \
        --parameter OPTIONAL_FLAGS
  3. פותחים את Google Cloud המסוף ומפעילים את Cloud Shell.
  4. פתיחת מסוף Cloud
  5. מדביקים את הפקודה שהועתקה.
  6. מריצים את הפקודה gcpdiag, שמורידה את תמונת ה-Docker‏ gcpdiag, ואז מבצעת בדיקות אבחון. אם יש הוראות לגבי הפלט, פועלים לפיהן כדי לתקן את הבדיקות שנכשלו.

Docker

אפשר להריץ את gcpdiag באמצעות wrapper שמתחיל את gcpdiag בקונטיינר של Docker. צריך להתקין את Docker או את Podman.

  1. מעתיקים את הפקודה הבאה ומריצים אותה בתחנת העבודה המקומית.
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. מריצים את הפקודה gcpdiag.
    ./gcpdiag runbook dataproc/cluster-creation \
        --parameter project_id=PROJECT_ID \
        --parameter cluster_name=CLUSTER_NAME \
        --parameter OPTIONAL_FLAGS

כאן אפשר לראות את הפרמטרים הזמינים של קובץ ה-runbook הזה.

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

    • PROJECT_ID: מזהה הפרויקט שמכיל את המשאב
    • CLUSTER_NAME: השם של אשכול Dataproc היעד בפרויקט
    • OPTIONAL_PARAMETERS: מוסיפים פרמטר אופציונלי אחד או יותר מהפרמטרים הבאים. חובה לכלול את הפרמטרים האלה אם האשכול נמחק.
      • cluster_uuid: המזהה הייחודי האוניברסלי (UUID) של אשכול Dataproc היעד בפרויקט
      • service_account: קלאסטר Dataproc חשבון שירות של מכונה וירטואלית
      • subnetwork: נתיב ה-URI המלא של רשת המשנה של אשכול Dataproc
      • internal_ip_only: True או False
      • cross_project: המזהה של הפרויקט שאליו שייך חשבון השירות של המכונה הווירטואלית, אם אשכול Dataproc משתמש בחשבון שירות של מכונה וירטואלית בפרויקט אחר

דגלים שימושיים:

  • --universe-domain: אם רלוונטי, הדומיין של Trusted Partner Sovereign Cloud שמארח את המשאב
  • --parameter או -p: פרמטרים של Runbook

רשימה ותיאור של כל הדגלים של כלי gcpdiag מופיעים בהוראות השימוש ב-gcpdiag.

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