פתרון בעיות ביצירת סביבה

‫Managed Airflow (דור 3) | Managed Airflow (דור 2) | Managed Airflow (דור 1 מדור קודם)

בדף הזה מפורט מידע לפתרון בעיות שאתם עלולים להיתקל בהן במהלך יצירת סביבות Managed Airflow.

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

כשיוצרים סביבות Managed Airflow, רוב הבעיות נובעות מהסיבות הבאות:

  • בעיות בהרשאות של חשבון שירות.

  • מידע שגוי על חומת אש, DNS או ניתוב.

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

  • בעיות שקשורות למכסה.

  • מדיניות ארגון לא תואמת.

אין הרשאות מספיקות ליצירת סביבה

אם אי אפשר ליצור סביבה ב-Managed Airflow כי אין לחשבון שלכם הרשאות מספיקות, מוצגות הודעות השגיאה הבאות:

ERROR: (gcloud.composer.environments.create) PERMISSION_DENIED: The caller
does not have permission

או

ERROR: (gcloud.composer.environments.create) PERMISSION_DENIED: User not
authorized to act as service account <service-account-name>.
The user must be granted iam.serviceAccounts.actAs permission, included in
Owner, Editor, Service Account User role. See https://cloud.google.com/iam/docs
/understanding-service-accounts for additional details.

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

  • ב-Managed Airflow (דור 2), מוודאים שחשבון השירות Cloud Composer Service Agent‏ (service-PROJECT_NUMBER@cloudcomposer-accounts.iam.gserviceaccount.com) קיבל את התפקיד Cloud Composer v2 API Service Agent Extension.

  • מוודאים שלסוכן השירות של Google APIs‏ (Google APIs Service Agent)‏ (PROJECT_NUMBER@cloudservices.gserviceaccount.com) מוקצה התפקיד עריכה.

  • במסגרת ההגדרה של VPC משותף, פועלים לפי ההוראות במאמר הגדרת VPC משותף.

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

כשיוצרים סביבת Managed Airflow, מציינים חשבון שירות שמריץ את צמתי אשכול GKE של הסביבה. אם לחשבון השירות הזה אין מספיק הרשאות לפעולה המבוקשת, המערכת של Managed Airflow מציגה את השגיאה הבאה:

Errors in: [Web server]; Error messages:
  Creation of airflow web server version failed. This may be an intermittent
  issue of the App Engine service. You may retry the operation later.
{"ResourceType":"appengine.v1.version","ResourceErrorCode":"504","ResourceError
Message":"Your deployment has failed to become healthy in the allotted time
and therefore was rolled back. If you believe this was an error, try adjusting
the 'app_start_timeout_sec' setting in the 'readiness_check' section."}

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

אזהרות לגבי תפקידי IAM שחסרים בחשבונות שירות

אם יצירת הסביבה נכשלת, Managed Airflow יוצר את הודעת האזהרה הבאה אחרי שמתרחשת שגיאה: The issue may be caused by missing IAM roles in the following Service Accounts ....

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

פתרון: בודקים שלחשבונות השירות שמוזכרים בהודעת האזהרה יש את התפקידים הנדרשים. מידע נוסף על תפקידים והרשאות ב-Managed Airflow זמין במאמר בקרת גישה.

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

רשת ה-VPC שנבחרה לסביבה לא קיימת

כשיוצרים סביבת Managed Airflow, אפשר לציין רשת VPC ותת-רשת בשבילה. אם לא מציינים רשת VPC, שירות Managed Airflow בוחר את ה-VPC ‏default ואת רשת המשנה default לאזור ולמיקום של הסביבה.

אם רשת ה-VPC ורשת המשנה שצוינו לא קיימות, המערכת של Managed Airflow מציגה את השגיאה הבאה:

Errors in: [GKE cluster]; Error messages:
        {"ResourceType":"gcp-types/container-v1:projects.locations.clusters","R
        esourceErrorCode":"400","ResourceErrorMessage":{"code":400,"message":"P
        roject \"<your composer project>\" has no network named \"non-existing-
        vpc\".","status":"INVALID_ARGUMENT","statusMessage":"Bad
        Request","requestPath":"https://container.googleapis.com/
        v1/projects/<your composer
        project>/locations/<zone>/clusters","httpMethod":"POST"}}

הפתרון:

  • ב-Managed Airflow (דור 2), אפשר ליצור סביבות שמשתמשות ב-Private Service Connect במקום ברשתות VPC.
  • לפני שיוצרים סביבה, צריך לוודא שרשת ה-VPC ותת-הרשת של הסביבה החדשה קיימות.

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

כדי ליצור סביבה של Managed Service for Apache Airflow, צריך להגדיר את הרשת או ה-DNS בצורה נכונה. כדי להגדיר קישוריות לממשקי API ולשירותים של Google, פועלים לפי ההוראות הבאות:

אם אתם מגדירים סביבות של Managed Service for Apache Airflow במצב של VPC משותף, אתם צריכים לפעול גם לפי ההוראות ל-VPC משותף.

סביבת Managed Service for Apache Airflow משתמשת ברשת משנה (subnet) לצמתים של האשכול ובטווחי כתובות IP ל-Pods ולשירותים. כדי להבטיח תקשורת עם טווחי כתובות ה-IP האלה ועם טווחי כתובות IP אחרים, צריך לפעול לפי ההוראות האלה כדי להגדיר את כללי חומת האש:

אפשר גם לבדוק אם יש רשומות ביומן בתוך קטגוריות ההגדרה GCE Networking ו-Subnetwork ב-Cloud Logging כדי לראות אם דווח על שגיאות במהלך יצירת הסביבה: Cloud Logging

בעיות במכסת השימוש שנתקלים בהן כשיוצרים סביבות ברשתות רחבות היקף

כשיוצרים סביבות של Managed Service for Apache Airflow ברשתות רחבות היקף, יכול להיות שתיתקלו במגבלות הבאות של מכסת השימוש:

  • הגעתם למספר המקסימלי של קישורים בין רשתות VPC שכנות (peering) לכל רשת VPC.
  • הגעתם למספר המקסימלי של טווחי כתובות IP של רשתות משנה ראשיות ומשניות.
  • הגעתם למספר המקסימלי של כללי העברה בקבוצת הפירינג לאיזון עומסים פנימי ב-TCP/UDP.

הפתרון:

מדיניות ארגונית לא תואמת

כדי ליצור סביבות Managed Airflow בהצלחה, צריך להגדיר את המדיניות הבאה בצורה מתאימה.

מדיניות הארגון ‫Managed Airflow (דור 3) ‫Managed Airflow (דור 2) ‫Managed Airflow (דור קודם 1)
compute.disableSerialPortLogging מותר להזין כל ערך חייב להיות מושבת מושבת בגרסאות מוקדמות יותר מ-1.13.0; אחרת, כל ערך
compute.requireOsLogin מותר להזין כל ערך מותר להזין כל ערך חייב להיות מושבת
compute.vmCanIpForward מותר להזין כל ערך מותר להזין כל ערך צריך לאפשר את ההגדרה (נדרש לאשכולות GKE בבעלות Airflow מנוהל) אם לא מוגדר מצב מקורי של VPC (באמצעות כתובת IP של כינוי)
compute.vmExternalIpAccess מותר להזין כל ערך צריך לאפשר שימוש בכתובות IP ציבוריות צריך לאפשר שימוש בכתובות IP ציבוריות
compute.restrictVpcPeering אפשר לאכוף אי אפשר לאכוף אי אפשר לאכוף
compute.disablePrivateServiceConnectCreationForConsumers מותר להזין כל ערך אי אפשר לאסור על SERVICE_PRODUCERS בסביבות עם כתובות IP פרטיות וציבוריות. לא משפיע על סביבות קיימות, הן יכולות לפעול כשהמדיניות הזו מופעלת. אי אפשר לאסור על SERVICE_PRODUCERS בסביבות עם כתובות IP פרטיות. לא משפיע על סביבות קיימות, הן יכולות לפעול כשהמדיניות הזו מופעלת.
compute.restrictPrivateServiceConnectProducer כשההגדרה פעילה, צריך להוסיף את הארגון google.com לרשימת ההיתרים כשההגדרה פעילה, צריך להוסיף את הארגון google.com לרשימת ההיתרים מותר להזין כל ערך

מדיניות לא תואמת לקביעת גבול הגישה לחשבונות משתמשים (PAB)

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

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

Operations on resource are denied due to an IAM Principal Access Boundary Policy.

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

הפתרון:

הגבלת השירותים שנעשה בהם שימוש בארגון או בפרויקט

אדמינים של ארגונים או פרויקטים יכולים להגביל את השימוש בשירותי Google בפרויקטים שלהם באמצעות האילוץ gcp.restrictServiceUsage של מדיניות הארגון.

כשמשתמשים במדיניות הארגון הזו, חשוב לאפשר את כל השירותים שנדרשים על ידי Managed Airflow.

הודעות שגיאה מסוג 400: הפריסה של שרת האינטרנט של Airflow נכשלה.

יכול להיות שהשגיאה הזו נגרמת בגלל כשל ביצירת אשכול GKE של סביבת כתובות IP פרטיות, בגלל טווחי כתובות IP חופפים.

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

התהליך של Cloud Build ליצירת תמונות של סביבות build נכשל

רלוונטי ל: Managed Airflow (דור 2) ו-Managed Airflow (דור 1 מדור קודם).

אם לחשבון השירות של Cloud Build‏ (PROJECT_NUMBER@cloudbuild.gserviceaccount.com) אין את התפקיד Cloud Build Service Account (roles/cloudbuild.builds.builder) בפרויקט, יכול להיות שהניסיונות ליצור או לעדכן סביבה ייכשלו עם שגיאות שקשורות להרשאות.

לדוגמה, יכול להיות שתראו את ההודעה denied: Permission "artifactregistry.repositories.uploadArtifacts" denied ואחריה את ההודעה ERROR: failed to push because we ran out of retries ביומנים של Cloud Build.

כדי לפתור את הבעיה הזו, מוודאים שלחשבון השירות ב-Cloud Build מוקצה התפקיד חשבון שירות ב-Cloud Build.

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