בעיות מוכרות

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

בדף הזה מפורטות בעיות ידועות ב-Managed Airflow. מידע על תיקוני בעיות מופיע בהערות המוצר.

חלק מהבעיות משפיעות על גרסאות קודמות, ואפשר לפתור אותן על ידי שדרוג הסביבה.

יש תמיכה חלקית בטווחי כתובות שהם לא RFC 1918 עבור Pods ושירותים

‫Managed Airflow מסתמך על GKE כדי לספק תמיכה בכתובות שאינן RFC 1918 עבור Pods ושירותים. ב-Managed Airflow יש תמיכה רק בטווחים הבאים שאינם RFC 1918:

  • 100.64.0.0/10
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.18.0.0/15
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 240.0.0.0/4

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

כשמעדכנים תוויות של סביבה, הן לא חלות על מכונות וירטואליות ב-Compute Engine באשכול של הסביבה. כפתרון עקיף, אפשר להחיל את התוויות באופן ידני.

אי אפשר ליצור סביבות Managed Airflow עם האילוצים של מדיניות הארגון או עם האילוץ compute.disableSerialPortLogging

יצירת סביבת Managed Airflow נכשלת אם מדיניות הארגון constraints/compute.disableSerialPortLogging נאכפת בפרויקט היעד.

אבחון

כדי לבדוק אם הבעיה משפיעה עליכם, פועלים לפי השלבים הבאים:

בתפריט GKE ב-Google Cloud console. איך ניגשים לתפריט GKE

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

Not all instances running in IGM after 123.45s.
Expect <number of desired instances in IGM>. Current errors:
[CONDITION_NOT_MET]: Instance '<generated instance name>' creation failed:
Constraint constraints/compute.disableSerialPortLogging violated for
project <target project number>.

פתרונות אפשריים:

  1. משביתים את מדיניות הארגון בפרויקט שבו תיצור סביבת Managed Airflow.

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

  2. שימוש במסנני החרגה

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

שימוש ב-Deployment Manager לניהול Google Cloud משאבים שמוגנים על ידי VPC Service Controls

בגרסאות 2.0.x של Managed Airflow (Legacy Gen 1) ו-Managed Airflow (Gen 2) נעשה שימוש ב-Deployment Manager כדי ליצור רכיבים של סביבות Managed Airflow.

בדצמבר 2020, יכול להיות שקיבלתם מידע על כך שייתכן שתצטרכו לבצע הגדרה נוספת של VPC Service Controls כדי שתוכלו להשתמש ב-Deployment Manager לניהול משאבים שמוגנים על ידי VPC Service Controls.

חשוב לנו להבהיר שאם אתם משתמשים ב-Managed Airflow ולא משתמשים ב-Deployment Manager ישירות כדי לנהל את המשאבים שמפורטים בהודעה על Deployment Manager, לא נדרשת מכם שום פעולה. Google Cloud

מוצג מידע על תכונה שלא נתמכת ב-Deployment Manager

יכול להיות שתופיע האזהרה הבאה בכרטיסייה Deployment Manager:

The deployment uses actions, which are an unsupported feature. We recommend
that you avoid using actions.

אם הפריסות של Deployment Manager הן בבעלות Managed Airflow, אפשר להתעלם מהאזהרה הזו.

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

הבעיה הזו רלוונטית לגרסאות 2.0.x של Managed Airflow (Legacy Gen 1) ושל Managed Airflow (Gen 2).

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

 Got error "" during CP_DEPLOYMENT_DELETING [Rerunning Task. ]

כדי למחוק סביבה כשהאשכול שלה כבר נמחק:

  1. נכנסים לדף Deployment Manager במסוף Google Cloud .

    מעבר אל Deployment Manager

  2. כדי למצוא את כל הפריסות שמסומנות בתוויות:

    • goog-composer-environment:<environment-name>
    • goog-composer-location:<environment-location>.

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

    • פריסה בשם <environment-location>-<environment-name-prefix>-<hash>-sd
    • פריסה בשם addons-<uuid>

  3. מוחקים באופן ידני משאבים שעדיין מופיעים בשני הפריסות האלה וקיימים בפרויקט (לדוגמה, נושאי Pub/Sub ומינויים). כדי לעשות את זה:

    1. בוחרים את הפריסות.

    2. לוחצים על Delete.

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

    פעולת המחיקה נכשלת, אבל המשאבים שנותרו נמחקים.

  4. כדי למחוק את הפריסות, אפשר להשתמש באחת מהאפשרויות הבאות:

    • במסוף Google Cloud , בוחרים שוב את שתי הפריסות. לוחצים על מחיקה ובוחרים באפשרות מחיקת 2 פריסות, אבל שמירת המשאבים שנוצרו על ידי הפריסות.

    • מריצים פקודת gcloud כדי למחוק את הפריסות עם המדיניות ABANDON:

      gcloud deployment-manager deployments delete addons-<uuid> \
    --delete-policy=ABANDON

gcloud deployment-manager deployments delete <location>-<env-name-prefix>-<hash>-sd \
    --delete-policy=ABANDON

  5. מחיקת סביבת Managed Airflow

אזהרות לגבי רשומות כפולות של המשימה echo ששייכת ל-DAG‏ echo-airflow_monitoring

יכול להיות שתראו את הרשומה הבאה ביומני Airflow:

in _query db.query(q) File "/opt/python3.6/lib/python3.6/site-packages/MySQLdb/
connections.py", line 280, in query _mysql.connection.query(self, query)
_mysql_exceptions.IntegrityError: (1062, "Duplicate entry
'echo-airflow_monitoring-2020-10-20 15:59:40.000000' for key 'PRIMARY'")

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

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

יצירת סביבה נכשלת בפרויקטים שבהם ממשקי API של שרת proxy לאימות זהויות (IAP) נוספו למערך של VPC Service Controls

בפרויקטים שבהם מופעל VPC Service Controls, לחשבון cloud-airflow-prod@system.gserviceaccount.com נדרשת גישה מפורשת בגבולות גזרה כדי ליצור סביבות.

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

  • אל תוסיפו את Cloud Identity-Aware Proxy API ואת Identity-Aware Proxy TCP API למתחם האבטחה.

  • מוסיפים את חשבון השירות cloud-airflow-prod@system.gserviceaccount.com כחבר בהיקף האבטחה באמצעות ההגדרה הבאה בקובץ תנאי ה-YAML:

     - members:
    - serviceAccount:cloud-airflow-prod@system.gserviceaccount.com

יצירה או שדרוג של סביבת Managed Airflow נכשלים כשהמדיניות compute.vmExternalIpAccess מושבתת

הבעיה הזו רלוונטית לסביבות Managed Airflow (Legacy Gen 1) ולסביבות Managed Airflow (Gen 2).

אשכולות GKE בבעלות Airflow מנוהל שמוגדרים במצב של כתובת IP ציבורית דורשים קישוריות חיצונית למכונות הווירטואליות שלהם. לכן, אי אפשר להשתמש במדיניות compute.vmExternalIpAccess כדי לאסור יצירה של מכונות וירטואליות עם כתובות IP חיצוניות. מידע נוסף על מדיניות הארגון הזו זמין במאמר אילוצים של מדיניות הארגון.

ההרצה הראשונה של DAG בקובץ DAG שהועלה כוללת כמה משימות שנכשלו

כשמעלים קובץ DAG, לפעמים כמה המשימות הראשונות מהרצת ה-DAG הראשונה נכשלות עם השגיאה Unable to read remote log.... הבעיה הזו מתרחשת כי קובץ ה-DAG מסונכרן בין דלי הנתונים של הסביבה, בין העובדים של Airflow ובין המתזמנים של Airflow בסביבה. אם המתזמן מקבל את קובץ ה-DAG ומתזמן את ההפעלה שלו על ידי עובד, ואם לעובד עדיין אין את קובץ ה-DAG, ביצוע המשימה ייכשל.

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

הודעות על הסרת התמיכה בממשקי API בגרסת בטא שיצאו משימוש מגרסאות GKE

‫Managed Airflow מנהל את אשכולות ה-GKE הבסיסיים שבבעלות Managed Airflow. אפשר להתעלם מההודעות על הוצאה משימוש של GKE API, אלא אם אתם משתמשים בממשקי API כאלה באופן מפורש ב-DAG ובקוד שלכם. ‫Managed Airflow מטפל בכל ההעברות, אם יש צורך בכך.

‫Managed Airflow לא אמור להיות מושפע מנקודת החולשה ב-Apache Log4j 2‏ (CVE-2021-44228)

בתגובה לנקודת החולשה ב-Apache Log4j 2‏ (CVE-2021-44228), ערכנו חקירה מפורטת של Managed Airflow, ולדעתנו הוא לא חשוף לניצול של נקודת החולשה הזו.

יכול להיות שיהיו בעיות בגישה לקטגוריה של Cloud Storage של הסביבה, אם משתמשים ב-workers או ב-schedulers של Airflow

‫Managed Airflow משתמש ב-gcsfuse כדי לגשת לתיקייה /data בקטגוריה של הסביבה וכדי לשמור את יומני המשימות של Airflow בספרייה /logs (אם האפשרות הזו מופעלת). אם gcsfuse עמוס מדי או שהמאגר של הסביבה לא זמין, יכול להיות שתיתקלו בכשלים במופעי המשימות של Airflow ותראו שגיאות Transport endpoint is not connected ביומני Airflow.

פתרונות:

  • משביתים את האפשרות שמירת יומנים בקטגוריה של הסביבה. האפשרות הזו מושבתת כברירת מחדל אם הסביבה נוצרה באמצעות Managed Airflow בגרסה 2.8.0 ואילך.
  • משדרגים ל-Managed Airflow 2.8.0 או לגרסה מתקדמת יותר.
  • במקום זאת, כדאי להקטין את [celery]worker_concurrency ולהגדיל את מספר העובדים של Airflow.
  • מצמצמים את כמות היומנים שנוצרים בקוד של DAG.
  • כדאי לפעול לפי ההמלצות והשיטות המומלצות ליישום DAG ולהפעיל ניסיונות חוזרים של משימות.

יכול להיות שממשק המשתמש של Airflow לא יטען מחדש תוסף אחרי שמשנים אותו

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

באשכול של הסביבה יש עומסי עבודה במצב Unschedulable (לא ניתן לתזמון)

הבעיה הידועה הזו רלוונטית רק ל-Managed Airflow (דור 2).

ב-Managed Airflow (דור 2), אחרי שנוצרת סביבה, כמה עומסי עבודה באשכול של הסביבה נשארים במצב Unschedulable (לא ניתן לתזמון).

כשמגדילים את סביבת העבודה, נוצרים תרמילי עובדים חדשים ו-Kubernetes מנסה להפעיל אותם. אם אין משאבים זמינים בחינם להפעלתם, הפודים של העובדים מסומנים כ-Unschedulable (לא ניתן לתזמון).

במצב כזה, הכלי Cluster Autoscaler מוסיף עוד צמתים, וזה לוקח כמה דקות. עד שהפעולה תסתיים, הפודים יישארו במצב Unschedulable ולא יפעילו משימות.

עומסי עבודה של DaemonSet שלא ניתן לתזמן בשם composer-gcsfuse ו-composer-fluentd, שלא יכולים להתחיל בצמתים שבהם אין רכיבי Airflow, לא משפיעים על הסביבה שלכם.

אם הבעיה נמשכת לאורך זמן (יותר משעה), אפשר לבדוק את היומנים של Cluster Autoscaler. אפשר למצוא אותם בכלי Logs Viewer עם המסנן הבא:

resource.type="k8s_cluster"
logName="projects/<project-name>/logs/container.googleapis.com%2Fcluster-autoscaler-visibility"
resource.labels.cluster_name="<cluster-name>"

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

שגיאה 504 כשניגשים לממשק המשתמש של Airflow

יכול להיות שתיתקלו בשגיאה 504 Gateway Timeout כשתיגשו לממשק המשתמש של Airflow. יכולות להיות כמה סיבות לשגיאה הזו:

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

  • (רק ב-Managed Airflow (דור 3)) בעיה בקישוריות. אם ממשק המשתמש של Airflow לא זמין באופן קבוע, ונוצרות שגיאות של פסק זמן או שגיאות 504, צריך לוודא שהסביבה שלכם יכולה לגשת אל *.composer.googleusercontent.com.

  • (רק ב-Managed Airflow (Gen 2)) בעיה בקישוריות. אם ממשק המשתמש של Airflow לא זמין באופן קבוע, ונוצרות שגיאות של פסק זמן או שגיאות 504, צריך לוודא שהסביבה שלכם יכולה לגשת אל *.composer.cloud.google.com. אם אתם משתמשים בגישה פרטית ל-Google ושולחים תעבורה דרך private.googleapis.com כתובות IP וירטואליות, או שאתם משתמשים ב-VPC Service Controls ושולחים תעבורה דרך restricted.googleapis.com כתובות IP וירטואליות, אתם צריכים לוודא ש-Cloud DNS מוגדר גם עבור *.composer.cloud.google.com שמות דומיין.

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

שגיאה 502 כשניגשים לממשק המשתמש של Airflow

השגיאה 502 Internal server exception מציינת שממשק המשתמש של Airflow לא יכול להציג בקשות נכנסות. יכולות להיות כמה סיבות לשגיאה הזו:

  • בעיה חולפת בתקשורת. אפשר לנסות לגשת לממשק המשתמש של Airflow מאוחר יותר.

  • הפעלת שרת האינטרנט נכשלה. כדי להתחיל, צריך קודם לסנכרן את קובצי ההגדרות של שרת האינטרנט. בודקים ביומני שרת האינטרנט אם יש רשומות ביומן שדומות ל: GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmp או GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/env_var.json.cfg /home/airflow/gcs/env_var.json.tmp. אם השגיאות האלה מופיעות, צריך לבדוק אם הקבצים שמוזכרים בהודעות השגיאה עדיין נמצאים בדלי של הסביבה.

    אם הם הוסרו בטעות (לדוגמה, בגלל הגדרת מדיניות שמירה), אפשר לשחזר אותם:

    1. מגדירים משתנה סביבה חדש בסביבה. אפשר להשתמש בכל שם וערך של משתנה.

    2. שינוי של אפשרות הגדרה ב-Airflow. אפשר להשתמש באפשרות הגדרה של Airflow שלא קיימת.

העברת העכבר מעל מופע של משימה בתצוגת העץ גורמת לשגיאת TypeError שלא נתפסה

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

ממשק המשתמש של Airflow בגרסה Airflow 2.2.3 או בגרסאות קודמות פגיע ל-CVE-2021-45229

כפי שצוין ב-CVE-2021-45229, המסך Trigger DAG with config (הפעלת DAG עם הגדרה) היה חשוף להתקפות XSS דרך ארגומנט השאילתה origin.

המלצה: שדרוג לגרסה העדכנית של Managed Airflow שתומכת ב-Airflow 2.2.5.

העובדים דורשים יותר זיכרון מאשר בגרסאות קודמות של Airflow

תסמינים:

  • בסביבת Managed Airflow (דור 2), כל עומסי העבודה של אשכולות בסביבה של עובדי Airflow נמצאים בסטטוס CrashLoopBackOff ולא מבצעים משימות. אם הבעיה הזו משפיעה עליכם, יכול להיות שיוצגו לכם גם אזהרות של OOMKilling.

  • הבעיה הזו יכולה למנוע שדרוגים של סביבות.

הסיבה:

  • אם משתמשים בערך מותאם אישית לאפשרות ההגדרה [celery]worker_concurrency Airflow ובהגדרות זיכרון מותאמות אישית לעובדי Airflow, יכול להיות שתיתקלו בבעיה הזו כשצריכת המשאבים מתקרבת למגבלה.
  • הדרישות לזיכרון של Airflow worker ב-Airflow 2.6.3 עם Python 3.11 גבוהות ב-10% בהשוואה ל-workers בגרסאות קודמות.
  • דרישות הזיכרון של העובדים ב-Airflow בגרסה 2.3 ומעלה גבוהות ב-30% בהשוואה לעובדים ב-Airflow בגרסה 2.2 או בגרסה 2.1.

פתרונות:

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

הפעלת DAG דרך רשתות פרטיות באמצעות פונקציות Cloud Run

‫Managed Airflow לא תומך בהפעלת DAG באמצעות פונקציות Cloud Run דרך רשתות פרטיות עם שימוש ב-VPC Connector.

המלצה: כדאי להשתמש בפונקציות Cloud Run כדי לפרסם הודעות ב-Pub/Sub. אירועים כאלה יכולים להפעיל חיישני Pub/Sub כדי להפעיל DAG של Airflow או ליישם גישה שמבוססת על אופרטורים שניתנים להשהיה.

תיקיות ריקות ב-Scheduler וב-Workers

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

המלצה: כדאי לשנות את ה-DAG כך שיהיה מוכן לדלג על תיקיות ריקות כאלה.

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

תמיכה ב-Kerberos

‫Managed Airflow לא תומך בהגדרת Kerberos ב-Airflow.

תמיכה בסוגי מחשוב ב-Managed Airflow (דור 2) וב-Managed Airflow (דור 3)

‫Managed Airflow (דור 3) ו-Managed Airflow (דור 2) תומכים רק בסוגי מחשוב לשימוש כללי בסיווג מחשוב. המשמעות היא שאי אפשר להפעיל Pods שמבקשים מחלקות מחשוב אחרות (כמו Balanced או Scale-Out).

בקטגוריה לשימוש כללי אפשר להריץ Pods עם בקשות לזיכרון של עד 110GB ול-CPU של עד 30 (כפי שמתואר במאמר בקשות מקסימליות של מחלקת מחשוב).

אם אתם רוצים להשתמש בארכיטקטורה מבוססת-ARM או שאתם צריכים יותר CPU וזיכרון, אתם צריכים להשתמש בסוג אחר של מחשוב, שלא נתמך באשכולות של Managed Airflow (דור 3) ו-Managed Airflow (דור 2).

המלצה: כדאי להשתמש ב-GKEStartPodOperator כדי להריץ Kubernetes Pods באשכול אחר שתומך בסוג המחשוב שנבחר. אם אתם מפעילים תצורות Pod בהתאמה אישית שדורשות מחלקת מחשוב שונה, הן גם צריכות לפעול באשכול Airflow לא מנוהל.

תמיכה באופרטורים של Google Campaign Manager 360

אופרטורים של Google Campaign Manager בגרסאות של Managed Airflow מגרסה 2.1.13 ומטה מבוססים על Campaign Manager 360 API v3.5, שיצא משימוש. תאריך ההוצאה משימוש הוא 1 במאי 2023.

אם אתם משתמשים באופרטורים של Google Campaign Manager, אתם צריכים לשדרג את הסביבה שלכם ל-Managed Airflow בגרסה 2.1.13 ואילך.

תמיכה באופרטורים של Google Display and Video 360

אופרטורים של Google Display and Video 360 בגרסאות של Managed Airflow מגרסה 2.1.13 ומטה מבוססים על Display and Video 360 API v1.1, שיצא משימוש ב-27 באפריל 2023.

אם אתם משתמשים באופרטורים של Google Display and Video 360, אתם צריכים לשדרג את הסביבה לגרסה 2.1.13 ואילך של Managed Airflow. בנוסף, יכול להיות שתצטרכו לשנות את ה-DAGs כי חלק מהאופרטורים של Google Display and Video 360 הוצאו משימוש והוחלפו באופרטורים חדשים.

  • המאפיין GoogleDisplayVideo360CreateReportOperator הוצא משימוש. במקום זאת, צריך להשתמש ב-GoogleDisplayVideo360CreateQueryOperator. האופרטור הזה מחזיר query_id במקום report_id.
  • המאפיין GoogleDisplayVideo360RunReportOperator הוצא משימוש. במקום זאת, צריך להשתמש ב-GoogleDisplayVideo360RunQueryOperator. האופרטור הזה מחזיר את הערכים query_id ו-report_id במקום רק report_id, ונדרש הפרמטר query_id במקום report_id.
  • כדי לבדוק אם דוח מוכן, משתמשים בחיישן GoogleDisplayVideo360RunQuerySensor החדש שמשתמש בפרמטרים query_id ו-report_id. החיישן שהוצא משימוש GoogleDisplayVideo360ReportSensor דרש רק report_id.
  • עכשיו הפונקציה GoogleDisplayVideo360DownloadReportV2Operator דורשת גם את הפרמטרים query_id וגם את הפרמטרים report_id.
  • ב-GoogleDisplayVideo360DeleteReportOperator אין שינויים שיכולים להשפיע על ה-DAGs שלכם.

הגבלות על שם הטווח המשני

‫CVE-2023-29247 (דף הפרטים של מופע המשימה בממשק המשתמש פגיע ל-XSS מאוחסן)

ממשק המשתמש של Airflow בגרסאות Airflow מ-2.0.x עד 2.5.x חשוף לנקודת החולשה CVE-2023-29247.

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

ב-Managed Airflow, הגישה לממשק המשתמש של Airflow מוגנת באמצעות IAM ובקרת גישה לממשק המשתמש של Airflow.

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

פתרון:

‫DAG של ניטור Airflow בסביבת Composer של Managed Airflow (דור 2) לא נוצר מחדש אחרי מחיקה

אם המשתמש מוחק את ה-DAG של המעקב אחר זרימת האוויר או מעביר אותו מהמאגר בסביבות עם composer-2.1.4-airflow-2.4.3, הוא לא נוצר מחדש באופן אוטומטי.

פתרון:

  • הבעיה הזו נפתרה בגרסאות מאוחרות יותר, כמו composer-2.4.2-airflow-2.5.3. הגישה המומלצת היא לשדרג את הסביבה לגרסה חדשה יותר.
  • פתרון עקיף חלופי או זמני לשדרוג סביבה הוא להעתיק את DAG של airflow_monitoring מסביבה אחרת עם אותה גרסה.

אי אפשר להקטין את נפח האחסון ב-Cloud SQL

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

אי אפשר להקטין את גודל הדיסק ב-Cloud SQL.

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

מדד השימוש בדיסק של מסד הנתונים לא יורד אחרי שמסירים רשומות מ-Cloud SQL

במסדי נתונים רלציוניים, כמו Postgres או MySQL, השורות לא מוסרות פיזית כשהן נמחקות או מתעדכנות. במקום זאת, המערכת מסמנת אותם כ-dead tuples כדי לשמור על עקביות הנתונים ולמנוע חסימה של טרנזקציות מקבילות.

גם MySQL וגם Postgres מיישמים מנגנונים לפינוי מקום אחרי מחיקת רשומות.

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

הגישה חסומה: שגיאת הרשאה

אם הבעיה הזו משפיעה על משתמש, בתיבת הדו-שיח הגישה נחסמה: שגיאת הרשאה תופיע ההודעה Error 400: admin_policy_enforced.

אם האפשרות אמצעי בקרה של API > אפליקציות צד שלישי שלא הוגדרו > המשתמשים לא יכולים להיכנס לאפליקציות צד שלישי מופעלת ב-Google Workspace, ואפליקציית Apache Airflow ב-Managed Airflow לא מורשית באופן מפורש, המשתמשים לא יכולים לגשת לממשק המשתמש של Airflow אלא אם הם מאשרים את האפליקציה באופן מפורש.

כדי לאפשר גישה, מבצעים את השלבים שמפורטים במאמר איך מאשרים גישה לממשק המשתמש של Airflow ב-Google Workspace.

לולאת כניסה כשניגשים לממשק המשתמש של Airflow

הסיבות האפשריות לבעיה הזו:

מופעים של משימות שהצליחו בעבר מסומנים כ'נכשלו'

בנסיבות מסוימות ובמקרים נדירים, מופעים של משימות Airflow שהסתיימו בהצלחה בעבר יכולים להיות מסומנים כ-FAILED.

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

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

הבעיה נפתרה בגרסה 2.6.5 ואילך של Managed Airflow.

יש בעיות ברכיבי Airflow בתקשורת עם חלקים אחרים בהגדרת Managed Airflow

הבעיה הזו רלוונטית רק לגרסאות 2.10.2 ואילך של Managed Airflow (דור 2).

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

תסמינים:

השגיאות הבאות מופיעות ביומנים של רכיבי Airflow (כמו מתזמני Airflow, עובדים או שרת האינטרנט):

Authentication failed using Compute Engine authentication due to unavailable metadata server

Compute Engine Metadata server unavailable on attempt 1 of 3. Reason: timed out
...
Compute Engine Metadata server unavailable on attempt 2 of 3. Reason: timed out
...
Compute Engine Metadata server unavailable on attempt 3 of 3. Reason: timed out

פתרון:

  • שדרוג הסביבה לגרסה מאוחרת יותר של Managed Airflow. הבעיה הזו נפתרה החל מגרסה 2.11.0 של Managed Airflow.

התיקייה ‎ /data לא זמינה בשרת האינטרנט של Airflow

ב-Managed Airflow (דור 2) וב-Managed Airflow (דור 3), שרת האינטרנט של Airflow אמור להיות רכיב לקריאה בלבד ברובו, ו-Managed Airflow לא מסנכרן את התיקייה data/ עם הרכיב הזה.

לפעמים, יכול להיות שתרצו לשתף קבצים משותפים בין כל רכיבי Airflow, כולל שרת האינטרנט של Airflow.

פתרון:

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

  • מוסיפים קבצים לתיקייה plugins/. התיקייה הזו מסונכרנת עם שרת האינטרנט של Airflow.

תרשימים של זמני ניתוח DAG וגודל תיקיית DAG לא רציפים במעקב

תרשימים של זמני ניתוח DAG לא רציפים ושל גודל תיקיית DAG בלוח הבקרה של המעקב מצביעים על בעיות שקשורות לזמני ניתוח ארוכים של DAG (יותר מ-5 דקות).

גרפים של זמני ניתוח של Airflow DAG ושל גודל DAG bag שמציגים סדרה של מרווחי זמן לא רציפים
איור 1. תרשימים של זמני ניתוח DAG לא רציפים וגודל תיקיית DAG (אפשר ללחוץ כדי להגדיל)

פתרון: מומלץ לשמור על זמן הניתוח הכולל של DAG מתחת ל-5 דקות. כדי לקצר את זמן הניתוח של DAG, כדאי לפעול לפי ההנחיות לכתיבת DAG.

יומנים של רכיבי Managed Airflow חסרים ב-Cloud Logging

יש בעיה ברכיב של הסביבה שאחראי להעלאת היומנים של רכיבי Airflow אל Cloud Logging. לפעמים הבאג הזה גורם לכך שיומן ברמת Managed Airflow עשוי להיות חסר עבור רכיב Airflow. אותו יומן עדיין זמין ברמת רכיב Kubernetes.

התרחשות הבעיה: נדירה מאוד, ספורדית

הסיבה:

התנהגות לא תקינה של רכיב Managed Airflow שאחראי להעלאת יומנים ל-Cloud Logging.

פתרונות:

  • משדרגים את הסביבה לגרסה 2.10.0 ואילך של Managed Airflow.

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

אין תמיכה בהעברת האשכול של הסביבה למהדורת GKE Enterprise

ההערה הזו רלוונטית ל-Managed Airflow 1 ול-Managed Airflow 2.

אשכול GKE של סביבת Managed Airflow נוצר ב-GKE Standard Edition.

החל מדצמבר 2024, שירות Managed Airflow לא תומך ביצירת סביבות Managed Airflow עם אשכולות במהדורת Enterprise.

סביבות Managed Airflow לא נבדקו עם GKE Enterprise Edition ויש להן מודל חיוב שונה.

הודעות נוספות בנוגע למהדורת GKE Standard לעומת מהדורת Enterprise יישלחו ברבעון השני של 2025.

רכיבי Airflow נתקלים בבעיות בתקשורת עם חלקים אחרים בהגדרת Managed Airflow

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

תסמינים:

יכול להיות שהשגיאות הבאות יופיעו ביומני הרישום של רכיבי Airflow (כמו מתזמני Airflow, עובדים או שרת האינטרנט):

google.api_core.exceptions.ServiceUnavailable: 503 DNS resolution failed ...
... Timeout while contacting DNS servers

או

Could not access *.googleapis.com: HTTPSConnectionPool(host='www.googleapis.com', port=443): Max retries exceeded with url: / (Caused by NameResolutionError("<urllib3.connection.HTTPSConnection object at 0x7c5ef5adba90>: Failed to resolve 'www.googleapis.com' ([Errno -3] Temporary failure in name resolution)"))

או

redis.exceptions.ConnectionError: Error -3 connecting to
airflow-redis-service.composer-system.svc.cluster.local:6379.
Temporary failure in name resolution.

פתרונות אפשריים:

  • שדרוג ל-Managed Airflow 2.9.11 או

  • מגדירים את משתנה הסביבה הבא: GCE_METADATA_HOST=169.254.169.254.

הסביבה במצב ERROR אחרי שמחקו או השביתו את החשבון לחיוב של הפרויקט, או אחרי שהשביתו את Cloud Composer API

סביבות Managed Airflow שהושפעו מהבעיות האלה לא ניתנות לשחזור:

  • אחרי שהחשבון לחיוב של הפרויקט נמחק או הושבת, גם אם חשבון אחר קושר אליו מאוחר יותר.
  • אחרי ש-Cloud Composer API הושבת בפרויקט, גם אם הוא הופעל מאוחר יותר.

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

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

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

אזהרות לגבי תקציב לשיבוש Pod באשכולות סביבה

אזהרות מהסוגים הבאים יכולות להופיע בממשק המשתמש של GKE עבור אשכולות של סביבות Managed Airflow:

GKE can't perform maintenance because the Pod Disruption Budget allows
for 0 Pod evictions. Update the Pod Disruption Budget.

A StatefulSet is configured with a Pod Disruption Budget but without readiness
probes, so the Pod Disruption Budget isn't as effective in gauging application
readiness. Add one or more readiness probes.

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

פתרונות אפשריים:

  • אפשר להתעלם מהאזהרות האלה עד שהבעיה תיפתר.

אי אפשר להסיר ערך של שדה בחיבור Airflow

הסיבה:

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

פתרונות אפשריים:

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

gcloud composer environments run ENVIRONMENT_NAME \
--location LOCATION \
connections delete -- \
CONNECTION_ID

אחרי שמוחקים את החיבור, יוצרים אותו מחדש באמצעות ממשק המשתמש של Airflow, ומוודאים שהשדות שרוצים להשאיר ריקים אכן נשארים ריקים. אפשר גם ליצור את החיבור באמצעות הפקודה connections add Airflow CLI עם Google Cloud CLI.

יומנים של משימות Airflow לא נאספים אם [core]execute_tasks_new_python_interpreter מוגדר כ-True

‫Managed Airflow לא אוסף יומנים של משימות Airflow אם אפשרות ההגדרה של Airflow‏, [core]execute_tasks_new_python_interpreter, מוגדרת לערך True.

פתרון אפשרי:

  • מסירים את ההחלפה של אפשרות ההגדרה הזו, או מגדירים את הערך שלה ל-False.

נקודות נתונים חסרות במדדים, ValueError: Cannot determine path without bucket name

בסביבות עם גרסאות של Managed Airflow (דור 2) 2.16.0 ו-2.16.1, יכול להיות שתיתקלו בבעיה מוכרת בדיווח על מדדים. יכול להיות שתראו כמה נקודות נתונים שדילגו עליהן במדדים שדווחו, והודעות שגיאה לגבי הפעלה מחדש של airflow-monitoring pod ביומני הסביבה.

דוגמה להודעת שגיאה: ValueError: Cannot determine path without bucket name error.

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

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