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
ממשק המשתמש של Airflow לא מציג יומני משימות כש-DAG Serialization מופעל ב-Composer 1.10.2 וב-Composer 1.10.3
הפעלת סריאליזציה של DAG בסביבות שמשתמשות בגרסאות Composer 1.10.2 ו-1.10.3 מונעת את הצגת היומנים בשרת האינטרנט של Airflow. כדי לפתור את הבעיה הזו, צריך לשדרג לגרסה 1.10.4 (או לגרסה מתקדמת יותר).
כשלים לסירוגין במשימות במהלך תזמון ב-Managed Airflow
הבעיה מופיעה בתזמון של Airflow עבור מופע המשימה במהלך הביצוע של משימה. עם זאת, ביומנים לא מוסבר למה המשימה נכשלה, והעובד של Airflow והמתזמן של Airflow נראו תקינים יחסית.
הודעת השגיאה בתזמן של Airflow עשויה להיראות כך:
Executor reports task instance <TaskInstance: xx.xxxx
scheduled__2022-04-21T06:00:00+00:00 [queued]> finished (failed) although the
task says its queued. (Info: None) Was the task killed externally?
או שאולי יש שגיאה ב-Airflow Worker שדומה להודעת השגיאה הבאה:
Log file is not found: gs://$BUCKET_NAME/logs/$DAG_NAME/$TASK_NAME/
2023-01-25T05:01:17.044759+00:00/1.log.
The task might not have been executed or worker executing it might have
finished abnormally (e.g. was evicted).
כדי להבטיח עמידות מפני שגיאות כאלה שנובעות מבעיה ארוכת טווח ב-Airflow, מומלץ מאוד להטמיע מראש אסטרטגיות מתאימות לניסיון חוזר ברמות המשימה וה-DAG. הוספת האמצעים האלה מאפשרת למערכת לצמצם ביעילות את ההשפעה של השגיאות האלה, וכך לשפר את המהימנות והעמידות הכוללות של תהליך העבודה.
אין תמיכה באיחוד זהויות של עומסי עבודה ב-GKE
ב-Managed Airflow (Legacy Gen 1), אי אפשר להפעיל איחוד זהויות של עומסי עבודה ל-GKE באשכולות של סביבות Managed Airflow. כתוצאה מכך, יכול להיות שתראו את הממצא WORKLOAD_IDENTITY_DISABLED ב-Security Command Center.
תוויות סביבה שנוספו במהלך עדכון לא מועברות באופן מלא
כשמעדכנים תוויות של סביבה, הן לא חלות על מכונות וירטואליות ב-Compute Engine באשכול של הסביבה. כפתרון עקיף, אפשר להחיל את התוויות באופן ידני.
יומני המשימות של Airflow לא זמינים בשרת האינטרנט של Airflow אחרי שדרוג מ-Airflow 1.9.0 ל-Airflow 1.10.x
ב-Airflow 1.10.x בוצעו שינויים במוסכמות למתן שמות לקובצי יומן, והשינויים האלה לא תואמים לאחור. פרטי האזור נוספים עכשיו לשמות היומנים של משימות Airflow.
ב-Airflow 1.9.0, השמות של היומנים נשמרים בפורמט הבא:
BUCKET/logs/DAG/2020-03-30T10:29:06/1.log
ב-Airflow 1.10.x, השמות של היומנים נשמרים בפורמט הבא:
BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log
כתוצאה מכך, אם משדרגים מ-Airflow 1.9.0 ל-Airflow 1.10.x
ורוצים לקרוא את היומן של משימה שהופעלה באמצעות Airflow 1.9.0,
שרת האינטרנט של Airflow יציג את הודעת השגיאה הבאה:
Unable to read remote log from BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log
פתרון עקיף: משנים את השם של היומנים שנוצרו על ידי Airflow 1.9.0 בקטגוריה של Cloud Storage בפורמט הבא:
BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log
אי אפשר ליצור סביבות 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>.
פתרונות אפשריים:
משביתים את מדיניות הארגון בפרויקט שבו תיצור סביבת Managed Airflow.
תמיד אפשר להשבית מדיניות ארגון ברמת הפרויקט, גם אם היא מופעלת במשאבי האב (ארגון או תיקייה). פרטים נוספים זמינים במאמר בנושא התאמה אישית של המדיניות בנושא אילוצים בוליאניים.
שימוש במסנני החרגה
שימוש במסנן החרגה עבור יומני יציאה טורית משיג את אותה מטרה כמו השבתת מדיניות הארגון, כי לא יהיו יומנים של מסוף טור ב-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. ]
כדי למחוק סביבה כשהאשכול שלה כבר נמחק:
נכנסים לדף Deployment Manager במסוף Google Cloud .
כדי למצוא את כל הפריסות שמסומנות בתוויות:
goog-composer-environment:<environment-name>goog-composer-location:<environment-location>.
אמורות להופיע שתי פריסות שמסומנות בתוויות שמתוארות כאן:
- פריסה בשם
<environment-location>-<environment-name-prefix>-<hash>-sd - פריסה בשם
addons-<uuid>
מוחקים באופן ידני משאבים שעדיין מופיעים בשני הפריסות האלה וקיימים בפרויקט (לדוגמה, נושאי Pub/Sub ומינויים). כדי לעשות את זה:
בוחרים את הפריסות.
לוחצים על Delete.
בוחרים באפשרות מחיקת 2 פריסות וכל המשאבים שנוצרו על ידי הפריסות, כמו מכונות וירטואליות, מאזני עומסים ודיסקים ולוחצים על מחיקת הכול.
פעולת המחיקה נכשלת, אבל המשאבים שנותרו נמחקים.
כדי למחוק את הפריסות, אפשר להשתמש באחת מהאפשרויות הבאות:
במסוף 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
אזהרות לגבי רשומות כפולות של המשימה 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 (דור קודם 1) נכשלת כשהמדיניות compute.requireOsLogin מופעלת
אם המדיניות compute.requireOsLogin מוגדרת לערך true בפרויקט, הפעולות ליצירת סביבת Managed Airflow (Legacy Gen 1) v1 נכשלות.
כדי ליצור סביבות Managed Airflow (דור קודם 1), צריך להשבית את המדיניות הזו בפרויקט.
מידע נוסף על מדיניות הארגון הזו זמין במאמר אילוצים של מדיניות הארגון.
יצירה או שדרוג של סביבת Managed Airflow נכשלים כשהמדיניות compute.vmExternalIpAccess מושבתת
הבעיה הזו רלוונטית לסביבות Managed Airflow (Legacy Gen 1) ולסביבות Managed Airflow (Gen 2).
אשכולות GKE בבעלות Airflow מנוהל שמוגדרים במצב של כתובת IP ציבורית דורשים קישוריות חיצונית למכונות הווירטואליות שלהם. לכן, אי אפשר להשתמש במדיניות compute.vmExternalIpAccess כדי לאסור יצירה של מכונות וירטואליות עם כתובות IP חיצוניות. מידע נוסף על מדיניות הארגון הזו זמין במאמר אילוצים של מדיניות הארגון.
יצירת סביבת Managed Airflow (דור קודם 1) נכשלת כשהמדיניות compute.vmCanIpForward מושבתת
בסביבות מנוהלות של Airflow (דור קודם 1) שנוצרו במצב שאינו VPC-Native (באמצעות כתובת IP של כינוי), נדרשת המדיניות הזו כדי לאפשר יצירה של מכונות וירטואליות עם התכונה 'העברת כתובות IP' מופעלת. מידע נוסף על מדיניות הארגון הזו זמין במאמר אילוצים של מדיניות הארגון.
ההרצה הראשונה של DAG בקובץ DAG שהועלה כוללת כמה משימות שנכשלו
כשמעלים קובץ DAG, לפעמים כמה המשימות הראשונות מהרצת ה-DAG הראשונה נכשלות עם השגיאה Unable to read remote log.... הבעיה הזו מתרחשת כי קובץ ה-DAG מסונכרן בין דלי הנתונים של הסביבה, בין העובדים של Airflow ובין המתזמנים של Airflow בסביבה. אם המתזמן מקבל את קובץ ה-DAG ומתזמן את ההפעלה שלו על ידי עובד, ואם לעובד עדיין אין את קובץ ה-DAG, ביצוע המשימה ייכשל.
כדי לצמצם את הבעיה הזו, בסביבות עם Airflow 2 מוגדרים כברירת מחדל שני ניסיונות חוזרים למשימה שנכשלה. אם משימה נכשלת, המערכת מנסה לבצע אותה שוב פעמיים, בהפרש של 5 דקות בין הניסיונות.
כדי לפתור את הבעיה הזו ב-Airflow 1, צריך לבטל את אפשרות ההגדרה [core]default_task_retries של Airflow ולהגדיר אותה למספר שגדול מ-2 או שווה לו.
המשימה נכשלת עם השגיאה 'OSError: [Errno 5] Input/output error' ב-Airflow 1.10.15 או בגרסאות קודמות
באג בגרסאות Airflow 1 גורם לכך שמשימות מוכנסות לתור המשימות של הסביבה פעמיים במקרים נדירים.
לפעמים זה יכול להוביל למצב של מרוץ תהליכים בקובץ היומן, ולכשל במשימה הבאה. המשימות נכשלות עם OSError: [Errno 5] Input/output error ב-Cloud Logging ועם Task is in the 'running' state which is not a valid state for execution. ביומן של ניסיון המשימה.
הבאג הזה תוקן ב-Airflow 2. אם נתקלתם בבעיה הזו ב-Airflow 1 במשימה שפועלת במשך זמן רב, צריך להגדיל את הערך של אפשרות ההגדרה [celery_broker_transport_options]visibility_timeout Airflow (ערך ברירת המחדל הוא 604800 ל-Composer 1.17.0, ו-21600 לסביבות ישנות יותר). למשימות קצרות, כדאי להוסיף ניסיונות חוזרים נוספים למשימות המושפעות או להעביר את הסביבה ל-Airflow 2.
הפעלה של Managed Service for Apache Spark ושל אופרטורים של Dataflow נכשלת עם Negsignal.SIGSEGV
זו בעיה לסירוגין בספריית grcpio, כשמשתמשים בה מ-Celery worker. הבעיה הזו משפיעה על Airflow 1.10.14 וגרסאות מתקדמות יותר.
הפתרון הוא לשנות את grpcio שיטת הסקר על ידי הוספת משתנה הסביבה הבא לסביבה שלכם: GRPC_POLL_STRATEGY=epoll1. הפתרון העקיף הזה כבר מיושם ב-Managed Airflow בגרסה 1.17.1 ובגרסאות מתקדמות יותר.
הודעות על הסרת התמיכה בממשקי 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 בסביבה שלכם.
בעיות שמתרחשות לסירוגין בתקשורת עם מסד הנתונים של הסביבה
הבעיה הידועה הזו רלוונטית רק ל-Managed Airflow (Legacy Gen 1).
יכול להיות שבסביבות מוקדמות יותר של Managed Airflow (Legacy Gen 1) (גרסה 1.16.3 או גרסאות מוקדמות יותר) שנוצרו לפני 12 באוגוסט 2021 יהיו בעיות זמניות שקשורות לתקשורת עם מסד הנתונים של Airflow.
אם נתקלים בבעיה הזו, הודעת השגיאה הבאה מופיעה ביומני המשימות של Airflow:
"Can't connect to MySQL server on 'airflow-sqlproxy-service.default.svc.cluster.local' (104)"
הצוות של Managed Airflow פועל לפתרון הבעיה הזו. בינתיים, אם לדעתך הבעיה הזו משפיעה עליך באופן משמעותי, אפשר לבצע את הפעולות הבאות כדי לצמצם את ההשפעה שלה:
במסוף Google Cloud , עוברים לדף Environment Configuration של סביבות Managed Airflow המושפעות.
כדי לעבור לאשכול GKE הבסיסי של הסביבה, לוחצים על הקישור הצגת פרטי האשכול.
עוברים לכרטיסייה Nodes (צמתים) ולוחצים על default-pool שמופיע בקטע Node Pools (מאגרי צמתים).
איור 1. default-pool ברשימה Node pools (מאגרי צמתים) (לוחצים כדי להגדיל) לוחצים על עריכה בחלק העליון של הדף.
משנים את סוג התמונה ל-Container-Optimized OS with containerd (מערכת הפעלה שמותאמת לקונטיינרים עם containerd) ושומרים את ההגדרה:
איור 2. שינוי סוג קובץ האימג' של מאגר הצמתים מ-Docker ל-containerd (לחיצה להגדלה) אחרי ששולחים את השינוי, מאגר הצמתים default-pool מוגדר מחדש כך שישתמש ב-containerd כזמן הריצה של הקונטיינר. יכול להיות שחלק מהמשימות שלכם ב-Airflow ייכשלו בזמן שמאגר הצמתים מוגדר מחדש. אם מוגדרים ניסיונות חוזרים למשימות האלה, הן יופעלו מחדש על ידי Airflow אחרי שהפעולה במאגר הצמתים תושלם.
שגיאה 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. אם השגיאות האלה מופיעות, צריך לבדוק אם הקבצים שמוזכרים בהודעות השגיאה עדיין נמצאים בדלי של הסביבה.אם הם הוסרו בטעות (לדוגמה, בגלל הגדרת מדיניות שמירה), אפשר לשחזר אותם:
מגדירים משתנה סביבה חדש בסביבה. אפשר להשתמש בכל שם וערך של משתנה.
שינוי של אפשרות הגדרה ב-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.
הפעלת 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.
תמיכה באופרטורים של 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.
פתרון:
בודקים את ההרשאות והתפקידים ב-IAM בפרויקט, כולל תפקידים ב-Managed Service for Apache Airflow שהוקצו למשתמשים ספציפיים. מוודאים שרק משתמשים מאושרים יכולים לגשת לממשק המשתמש של Airflow.
מאמתים את התפקידים שהוקצו למשתמשים באמצעות מנגנון בקרת הגישה לממשק המשתמש של Airflow (זהו מנגנון נפרד שמספק גישה מפורטת יותר לממשק המשתמש של Airflow). מוודאים שרק משתמשים מאושרים יכולים לגשת לממשק המשתמש של Airflow, וכל משתמש חדש רשום עם תפקיד מתאים.
כדאי לשקול להשתמש ב-VPC Service Controls כדי להוסיף עוד שכבת אבטחה.
אי אפשר להקטין את נפח האחסון ב-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. לכן מומלץ להסתמך על מנגנוני הבנייה כדי לפנות את השטח שלא נעשה בו שימוש.
מופעים של משימות שהצליחו בעבר מסומנים כ'נכשלו'
בנסיבות מסוימות ובמקרים נדירים, מופעים של משימות Airflow שהסתיימו בהצלחה בעבר יכולים להיות מסומנים כ-FAILED.
אם זה קורה, בדרך כלל זה קורה בגלל עדכון סביבה, פעולת שדרוג או תחזוקה של GKE.
הערה: הבעיה עצמה לא מצביעה על בעיה בסביבה ולא גורמת לכשלים בפועל בהרצת המשימה.
הבעיה נפתרה בגרסה 2.6.5 ואילך של Managed Airflow.
תרשימים של זמני ניתוח DAG וגודל תיקיית DAG לא רציפים במעקב
תרשימים של זמני ניתוח DAG לא רציפים ושל גודל תיקיית DAG בלוח הבקרה של המעקב מצביעים על בעיות שקשורות לזמני ניתוח ארוכים של DAG (יותר מ-5 דקות).
פתרון: מומלץ לשמור על זמן הניתוח הכולל של DAG מתחת ל-5 דקות. כדי לקצר את זמן הניתוח של DAG, כדאי לפעול לפי ההנחיות לכתיבת DAG.
אין תמיכה בהעברת האשכול של הסביבה למהדורת 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.
הסביבה במצב 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.