בעיות מוכרות

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

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

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

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

‫Managed Airflow מסתמך על GKE כדי לספק תמיכה בכתובות שאינן RFC 1918 לפודים ולשירותים. ב-Managed Airflow יש תמיכה רק ברשימה הבאה של טווחי כתובות IP שהם לא 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

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

אבחון

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

נכנסים לתפריט GKE במסוףGoogle Cloud . כניסה לתפריט 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 (דור קודם 1) ו-Managed Airflow (דור 2) משתמשים ב-Deployment Manager כדי ליצור רכיבים של סביבות Managed Airflow.

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

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

ב-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 (דור קודם, דור ראשון) ו-Managed Airflow (דור שני).

אם תמחקו את אשכול ה-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. בוחרים באפשרות Delete 2 deployments and all resources created by them, such as VMs, מאזני עומסים (LB) and disks ולוחצים על Delete all.

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

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

    • במסוף Google Cloud , בוחרים שוב את שני הפריסות. לוחצים על Delete ובוחרים באפשרות Delete 2 deployments, but keep resources created by them.

    • מריצים פקודת 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'")

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

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

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

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

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

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

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

     - members:
    - serviceAccount:cloud-airflow-prod@

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

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

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

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

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

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

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

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

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

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

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

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

פתרונות:

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

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

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

באשכול של הסביבה יש עומסי עבודה במצב Unschedulable

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

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

כשסביבה מתרחבת, נוצרים פודים חדשים של Worker ו-Kubernetes מנסה להריץ אותם. אם אין משאבים פנויים להפעלת הפודים של ה-worker, הם מסומנים כ-Unschedulable.

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

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

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

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 ושולחים תנועה דרך כתובות IP וירטואליות של private.googleapis.com, או ב-VPC Service Controls ושולחים תנועה דרך כתובות IP וירטואליות של restricted.googleapis.com, ודאו ש-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 שלא קיימת.

שגיאה 500 כשניגשים לממשק המשתמש של Airflow אחרי שינוי ברירת המחדל של [webserver]analytics_tool

בסביבות עם Airflow 2, אם עוקפים את אפשרות ההגדרה [webserver]analytics_tool של Airflow כדי לנתב נתוני שימוש אנונימיים בממשק המשתמש של Airflow לשירות ניתוח נתונים (כמו Google Analytics,‏ Segment,‏ MetaRouter או Matomo), יכול להיות שהגישה לממשק המשתמש של Airflow אחרי עדכון הסביבה תחזיר תגובה מסוג (500) Internal Server Error, עם אחת מהשגיאות הבאות ביומני שרת האינטרנט של Airflow:

airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_id] not found in config

airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_url] not found in config

כשמגדירים את [webserver]analytics_tool ב-Airflow 2, שרת האינטרנט של Airflow דורש להגדיר גם אפשרויות ניתוח נתונים נלוות בקטע [webserver] כשמעבדים את ממשק המשתמש של Airflow.

ב-Airflow 3, אפשרויות ההגדרה [webserver]analytics_tool,‏ [webserver]analytics_id ו-[webserver]analytics_url הוסרו.

פתרונות:

  • מסירים את שינוי ברירת המחדל של אפשרות ההגדרה [webserver]analytics_tool של Airflow, או
  • מציינים את כל אפשרויות ההגדרה הנדרשות של Airflow ביחד:
    • [webserver]analytics_tool
    • [webserver]analytics_id
    • ‫[webserver]analytics_url (חובה ב-Airflow מגרסה 2.9 ואילך, גם אם כלי הניתוח לא משתמש בכתובת URL מותאמת אישית)

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

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

ממשק המשתמש של Airflow בגרסה 2.2.3 או בגרסאות קודמות חשוף ל-CVE-2021-45229

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

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

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

תסמינים:

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

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

הסיבה:

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

פתרונות:

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

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

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

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

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

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

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

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

תמיכה ב-Kerberos

ב-Managed Airflow אין תמיכה בהגדרות של Airflow Kerberos.

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

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

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

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

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

תמיכה למפעילים של Google Campaign Manager 360

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

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

תמיכה למפעילי Google Display & Video 360

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

אם אתם משתמשים באופרטורים של Google Display and Video 360, שדרגו את הסביבה לגרסה 2.1.13 ומעלה של Managed Airflow. בנוסף, יכול להיות שתצטרכו לשנות את ה-DAG כי חלק מהאופרטורים של Google Display & 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.
  • עכשיו צריך להשתמש גם בפרמטר query_id וגם בפרמטר report_id ב-GoogleDisplayVideo360DownloadReportV2Operator.
  • בגרסה GoogleDisplayVideo360DeleteReportOperator אין שינויים שיכולים להשפיע על ה-DAG.

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

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

ממשק המשתמש של 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) לא נוצר מחדש אחרי המחיקה

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

הפתרון:

  • הבעיה תוקנה בגרסאות מאוחרות יותר, כמו 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 באמצעות תמונות מצב.

המדד Database Disk usage לא יורד אחרי הסרת רשומות מ-Cloud SQL

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

גם ב-MySQL וגם ב-Postgres יש מנגנונים להחזרת נפח אחסון אחרי מחיקת רשומות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

במקרים נדירים מאוד, התקשורת האיטית עם שרת המטא-נתונים של 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 bag, סימן שיש בעיות שקשורות לזמני ניתוח ארוכים של ה-DAG (יותר מ-5 דקות).

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

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

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

יש בעיה ברכיב של הסביבה שאחראי להעלאת היומנים של רכיבי 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 Edition.

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

הודעות נוספות בנוגע ל-GKE Standard Edition לעומת Enterprise Edition יישלחו ברבעון השני של 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.

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

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

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

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

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

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

אזהרות לגבי תקציב לשיבוש 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 ומוודאים שהשדות שרוצים להשאיר ריקים אכן נשארים ריקים. אפשר גם ליצור את החיבור על ידי הפעלת פקודת ה-CLI של Airflow‏ connections add באמצעות Google Cloud CLI.

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

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

פתרון אפשרי:

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

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

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

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

ביצועי סביבה ירודים בכמה גרסאות של חבילת google-api-core

גרסאות מ-2.28.0 עד 2.30.2

גרסאות החבילה google-api-core שמותקנות מראש מ-2.28.0 עד 2.30.2 עלולות לגרום לפגיעה בביצועי הסביבה, וכתוצאה מכך להאריך את משך הזמן לביצוע משימה ואת משך הזמן להעברת משימה ממצב המתנה למצב ביצוע.

גרסאות build של Managed Airflow (דור 3) שמושפעות:

  • ‫composer-3-airflow-3.1.7-build.0 עד composer-3-airflow-3.1.7-build.5
  • ‫composer-3-airflow-3.1.0-build.5 עד composer-3-airflow-3.1.0-build.10
  • composer-3-airflow-2.11.1-build.0
  • ‫composer-3-airflow-2.10.5-build.22 עד composer-3-airflow-2.10.5-build.33
  • ‫composer-3-airflow-2.9.3-build.42 עד composer-3-airflow-2.9.3-build.53

גרסאות build מושפעות של Managed Airflow (דור 2):

  • composer-2.16.10-airflow-2.11.1
  • מ-composer-2.16.0-airflow-2.10.5 ל-composer-2.16.10-airflow-2.10.5
  • ‫composer-2.16.0-airflow-2.9.3 ל-composer-2.16.10-airflow-2.9.3

לשדרג את הסביבה לאחד מה-builds הבאים, שכוללים את גרסה 2.27.0 של google-api-core שמותקנת מראש ולא מושפעים מהבעיה הזו:

  • composer-3-airflow-2.11.1-build.1
  • composer-3-airflow-2.10.5-build.34
  • composer-3-airflow-2.9.3-build.54
  • composer-2.16.11-airflow-2.11.1
  • composer-2.16.11-airflow-2.10.5
  • composer-2.16.11-airflow-2.9.3

לחלופין, שדרגו לתמונה שכוללת את google-api-core בגרסה 2.43.1 ואילך, או התקינו ידנית גרסה תואמת.

ב-Python 3.11, גרסאות 2.30.3 עד 2.43.0 של google-api-core גורמות לבעיה נפרדת בביצועים החל מ-24 באוקטובר 2026. אם בסביבה שלכם פועלת גרסה 3.11 של Python, אתם צריכים להשתמש באחד מהפתרונות החלופיים שמפורטים בקטע גרסאות 2.30.3 עד 2.43.0 ב-Python 3.11.

גרסאות 2.30.3 עד 2.43.0 ב-Python 3.11

החל מ-24 באוקטובר 2026, גרסאות 2.30.3 עד 2.43.0 של חבילת google-api-core מריצות בדיקה של הוצאה משימוש של Python 3.11, שסורקת את המטא-נתונים של החבילה המותקנת בכל פעם שספריית לקוח של Google Cloud מיובאת לתהליך משנה חדש של Python.

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

התסמינים כוללים:

  • זמני ניתוח ארוכים יותר של DAG ושימוש גבוה יותר ב-CPU במעבדי Airflow DAG.
  • זמני ביצוע ארוכים יותר של משימות ושימוש גבוה יותר במעבד (CPU) ב-Airflow workers.
  • רשומות יומן תכופות של FutureWarning מ-google/api_core/_python_version_support.py, שבהן מצוין שהתמיכה ב-Python 3.11 תסתיים ב-24 באוקטובר 2027.

הבעיה הזו משפיעה על כל סביבת Python 3.11 שבה גרסה 2.30.3 עד 2.43.0 של google-api-core מותקנת מראש או מותקנת באופן ידני, כולל ה-builds הבאים.

הבעיה משפיעה על הגרסאות הבאות של Managed Airflow (דור 3):

  • ‫composer-3-airflow-3.3.1-build.0 עד composer-3-airflow-3.3.1-build.5
  • ‫composer-3-airflow-3.2.2-build.0 עד composer-3-airflow-3.2.2-build.9
  • ‫composer-3-airflow-3.1.8-build.0 עד composer-3-airflow-3.1.8-build.4
  • ‫composer-3-airflow-3.1.7-build.7 עד composer-3-airflow-3.1.7-build.13
  • ‫composer-3-airflow-2.11.1-build.3 עד composer-3-airflow-2.11.1-build.22
  • ‫composer-3-airflow-2.10.5-build.36 עד composer-3-airflow-2.10.5-build.52

גרסאות build מושפעות של Managed Airflow (דור 2):

  • ‫composer-2.17.0-airflow-2.11.1 עד composer-2.17.16-airflow-2.11.1
  • ‫composer-2.17.0-airflow-2.10.5 עד composer-2.17.13-airflow-2.10.5

פתרונות עקיפים:

בוחרים באחת מהאפשרויות הבאות, בהתאם לגרסת קובץ האימג' של הסביבה:

  • אפשרות 1. גרסאות Managed Airflow (דור 3) תואמות עם Airflow 3 בלבד: מתקינים את חבילת PyPI של google-api-core עם אילוץ הגרסה >=2.43.1.

    גרסאות build תואמות של Managed Airflow (דור 3):

    • ‫composer-3-airflow-3.3.1-build.0 עד composer-3-airflow-3.3.1-build.5
    • ‫composer-3-airflow-3.2.2-build.1 עד composer-3-airflow-3.2.2-build.9
    • ‫composer-3-airflow-3.1.8-build.3 ל-composer-3-airflow-3.1.8-build.4

    אל תשתמשו באפשרות הזו בגרסאות build של Airflow 2 או בגרסאות build קודמות של Airflow 3, כולל composer-3-airflow-3.2.2-build.0 ו-composer-3-airflow-3.1.8-build.0 עד build.2. בגרסאות האלה, גרסה 2.43.1 של google-api-core גורמת להתנגשויות בין יחסי תלות כי היא דורשת את opentelemetry-api>=1.44.0. בגרסאות האלה, צריך להשתמש באפשרות 2.

  • אפשרות 2. כל גרסאות ה-build המושפעות של Managed Airflow (דור 3) ו-Managed Airflow (דור 2): צריך להחיל תיקון בזמן הריצה של sitecustomize.py.

    1. מורידים את sitecustomize.py מ-GitHub.

    2. מעלים את sitecustomize.py לתיקייה dags/patches בקטגוריה של הסביבה.

    3. מגדירים את משתנה הסביבה PYTHONPATH לערך /home/airflow/gcs/dags/patches.

      אם PYTHONPATH כבר מוגדר, צריך להוסיף את /home/airflow/gcs/dags/patches: לפני הערך הקיים. לדוגמה: /home/airflow/gcs/dags/patches:PREVIOUS_PYTHONPATH_VALUE

    ניקוי אחרי שדרוג: בגרסאות עתידיות של Managed Airflow, חבילת google-api-core בגרסה 2.43.1 ואילך תותקן מראש. אחרי שמשדרגים לתמונה עם google-api-core בגרסה 2.43.1 ואילך, אפשר להסיר את השינוי של PYTHONPATH ולמחוק את dags/patches/sitecustomize.py.

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