代管 Airflow (第 3 代) | 代管 Airflow (第 2 代) | 代管 Airflow (舊版第 1 代)
本頁列出 Managed Airflow 的已知問題。如要瞭解修正的問題,請參閱「版本資訊」。
部分問題會影響舊版,可透過升級環境修正。
Pod 和服務部分支援非 RFC 1918 位址範圍
Managed Airflow 依賴 GKE,為 Pod 和服務提供非 RFC 1918 位址的支援。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 VM。如要解決這個問題,請手動套用標籤。
無法建立強制執行組織政策限制/compute.disableSerialPortLogging 的 Managed Airflow 環境
如果目標專案強制執行 constraints/compute.disableSerialPortLogging 機構政策,系統就無法建立 Managed Airflow 環境。
診斷
如要判斷是否受到這個問題影響,請按照下列程序操作:
前往Google Cloud 控制台的 GKE 選單。造訪 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 管理受 VPC Service Controls 保護的 Google Cloud 資源
Managed Airflow (舊版第 1 代) 和 Managed Airflow (第 2 代) 2.0.x 版會使用 Deployment Manager 建立 Managed Airflow 環境的元件。
2020 年 12 月,您可能收到相關資訊,指出您可能需要進行額外的 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 擁有,您可以忽略這則警告。
叢集刪除後,就無法刪除環境
這個問題適用於 Managed Airflow (舊版第 1 代) 和 Managed Airflow (第 2 代) 2.0.x 版。
如果您在刪除環境本身之前,先刪除環境的 GKE 叢集,嘗試刪除環境時會發生下列錯誤:
Got error "" during CP_DEPLOYMENT_DELETING [Rerunning Task. ]
如要刪除叢集已刪除的環境,請按照下列步驟操作:
前往 Google Cloud 控制台的「Deployment Manager」頁面。
找出標有標籤的所有部署作業:
goog-composer-environment:<environment-name>goog-composer-location:<environment-location>。
您應該會看到兩個部署作業,並標示上述標籤:
- 名為
<environment-location>-<environment-name-prefix>-<hash>-sd的部署作業 - 名為
addons-<uuid>的部署作業
手動刪除仍列於這兩項部署中,且存在於專案中的資源 (例如 Pub/Sub 主題和訂閱項目)。方法如下:
選取部署項目。
點選「刪除」。
選取「Delete 2 deployments and all resources created by them, such as VMs, load balancers and disks」(刪除 2 項部署作業及其建立的所有資源,例如 VM、負載平衡器和磁碟) 選項,然後按一下「Delete all」(全部刪除)。
刪除作業失敗,但剩餘資源已刪除。
使用下列其中一種方式刪除部署作業:
在 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-airflow_monitoring」DAG 的「echo」工作有重複項目
您可能會在 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 記錄中移除這些警告。
如果專案已將 Identity-Aware Proxy API 新增至 VPC Service Controls 範圍,則無法建立環境
在啟用 VPC Service Controls 的專案中,cloud-airflow-prod@system.gserviceaccount.com帳戶必須在安全範圍內取得明確存取權,才能建立環境。
如要建立環境,可以使用下列任一解決方案:
請勿將 Cloud Identity-Aware Proxy API 和 Identity-Aware Proxy TCP API 新增至安全防護範圍。
在 YAML 條件檔案中使用下列設定,將
cloud-airflow-prod@system.gserviceaccount.com服務帳戶新增為安全防護範圍的成員:- members: - serviceAccount:cloud-airflow-prod@system.gserviceaccount.com
如果停用 compute.vmExternalIpAccess 政策,系統就無法建立或升級 Managed Airflow 環境
這個問題適用於 Managed Airflow (舊版第 1 代) 和 Managed Airflow (第 2 代) 環境。
以公開 IP 模式設定的代管 Airflow 擁有的 GKE 叢集,需要 VM 的外部連線。因此,compute.vmExternalIpAccess 政策無法禁止建立含外部 IP 位址的 VM。如要進一步瞭解這項組織政策,請參閱「組織政策限制」。
上傳的 DAG 檔案首次執行 DAG 時,有多項工作失敗
上傳 DAG 檔案時,有時第一個 DAG 執行作業的前幾項工作會失敗,並顯示 Unable to read remote log... 錯誤。發生這個問題的原因是,DAG 檔案會在環境的 bucket、Airflow 工作站和環境的 Airflow 排程器之間同步處理。如果排程器取得 DAG 檔案並排定由工作站執行,但工作站尚未取得 DAG 檔案,則工作執行作業會失敗。
為減輕這個問題的影響,搭載 Airflow 2 的環境預設會對失敗的工作重試兩次。如果工作失敗,系統會重試兩次,每次間隔 5 分鐘。
公告:GKE 版本將移除對已淘汰 Beta 版 API 的支援
Managed Airflow 會管理基礎的 Managed Airflow 專屬 GKE 叢集。除非您在 DAG 和程式碼中明確使用這類 API,否則可以忽略有關 GKE API 淘汰的公告。如有必要,Managed Airflow 會負責所有遷移作業。
Managed Airflow 不會受到 Apache Log4j 2 安全漏洞 (CVE-2021-44228) 影響
為因應 Apache Log4j 2 安全漏洞 (CVE-2021-44228), Managed Airflow 已進行詳細調查, 我們認為 Managed Airflow 不會受到此安全漏洞影響。
Airflow 工作站或排程器存取環境的 Cloud Storage bucket 時可能會發生問題
Managed Airflow 會使用 gcsfuse 存取環境 bucket 中的 /data 資料夾,並將 Airflow 工作記錄儲存至 /logs 目錄 (如已啟用)。如果 gcsfuse 負載過重或環境的 bucket 無法使用,您可能會遇到 Airflow 工作執行個體失敗的問題,並在 Airflow 記錄中看到 Transport endpoint is not connected 錯誤。
解決方法:
- 停用將記錄檔儲存至環境值區。如果使用 Managed Airflow 2.8.0 以上版本建立環境,這個選項預設為停用。
- 升級至 Managed Airflow 2.8.0 以上版本。
- 請減少
[celery]worker_concurrency,並增加 Airflow 工作站數量。 - 減少 DAG 程式碼中產生的記錄檔數量。
- 請遵循建議做法和最佳做法,實作 DAG 並啟用工作重試功能。
有時變更外掛程式後,Airflow UI 可能不會重新載入外掛程式
如果外掛程式包含許多匯入其他模組的檔案,Airflow UI 可能無法辨識外掛程式應重新載入。在這種情況下,請重新啟動環境的 Airflow 網路伺服器。
環境的叢集有處於「無法排程」狀態的工作負載
這項已知問題僅適用於 Managed Airflow (第 2 代)。
在 Managed Airflow (第 2 代) 中,建立環境後,環境叢集中的多個工作負載仍處於「無法排程」狀態。
環境擴充時,系統會建立新的工作站 Pod,Kubernetes 會嘗試執行這些 Pod。如果沒有可用的免費資源來執行這些作業,工作站 Pod 就會標示為「無法排程」。
在這種情況下,叢集自動配置器會新增更多節點,這需要幾分鐘的時間。在此之前,Pod 會維持在「無法排程」狀態,且不會執行任何工作。
名為 composer-gcsfuse 和 composer-fluentd 的無法排程 DaemonSet 工作負載無法在沒有 Airflow 元件的節點上啟動,因此不會影響環境。
如果這個問題持續很久 (超過 1 小時),請檢查叢集自動配置器記錄。您可以在記錄檢視器中,使用下列篩選條件找到這些記錄:
resource.type="k8s_cluster"
logName="projects/<project-name>/logs/container.googleapis.com%2Fcluster-autoscaler-visibility"
resource.labels.cluster_name="<cluster-name>"
其中包含叢集自動配置器做出的決策相關資訊:展開任何 noDecisionStatus,即可查看叢集無法向上或向下擴充的原因。
存取 Airflow UI 時發生錯誤 504
存取 Airflow UI 時,可能會收到 504 Gateway Timeout 錯誤。造成這項錯誤的原因可能如下:
暫時性通訊問題。在這種情況下,請稍後再嘗試存取 Airflow UI。您也可以重新啟動 Airflow 網路伺服器。
(僅限 Managed Airflow 第 3 代) 連線問題。如果 Airflow UI 永久無法使用,且系統產生逾時或 504 錯誤,請確認您的環境可以存取
*.composer.googleusercontent.com。(僅限 Managed Airflow 第 2 代) 連線問題。如果 Airflow UI 永久無法使用,且系統產生逾時或 504 錯誤,請確認環境可以存取
*.composer.cloud.google.com。如果您使用 Private Google Access 並透過private.googleapis.com虛擬 IP 傳送流量,或使用 VPC Service Controls 並透過restricted.googleapis.com虛擬 IP 傳送流量,請務必也為*.composer.cloud.google.com網域名稱設定 Cloud DNS。Airflow 網路伺服器沒有回應。如果 504 錯誤持續發生,但您仍可在特定時間存取 Airflow UI,則可能是因為 Airflow 網路伺服器負載過重,導致沒有回應。嘗試提高網路伺服器的規模和效能參數。
存取 Airflow UI 時發生 502 錯誤
錯誤 502 Internal server exception 表示 Airflow UI 無法處理傳入的要求。造成這項錯誤的原因可能如下:
暫時性通訊問題。請稍後再嘗試存取 Airflow UI。
無法啟動網路伺服器。如要開始使用,網路伺服器必須先同步處理設定檔。檢查網路伺服器記錄,找出類似
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的記錄項目。如果看到這些錯誤,請檢查錯誤訊息中提及的檔案是否仍存在於環境的 bucket 中。如果這些項目遭到意外移除 (例如因為設定了保留政策),您可以還原這些項目:
在環境中設定新的環境變數。您可以任意使用變數名稱和值。
覆寫 Airflow 設定選項。您可以使用不存在的 Airflow 設定選項。
在樹狀結構檢視畫面中將滑鼠游標懸停在工作執行個體上時,會擲回未捕獲的 TypeError
在 Airflow 2 中,如果使用非預設時區,Airflow UI 中的樹狀檢視畫面有時可能無法正常運作。如要解決這個問題,請在 Airflow UI 中明確設定時區。
Airflow 2.2.3 以下版本的 Airflow UI 容易受到 CVE-2021-45229 攻擊
如 CVE-2021-45229 所述,「Trigger DAG with config」畫面容易受到 XSS 攻擊,原因在於 origin 查詢引數。
最佳化建議:升級至支援 Airflow 2.2.5 的最新 Managed Airflow 版本。
工作人員需要的記憶體比舊版 Airflow 多
症狀:
在 Managed Airflow (第 2 代) 環境中,所有環境的 Airflow 工作站叢集工作負載都處於
CrashLoopBackOff狀態,且不會執行工作。如果受到這個問題影響,您也會看到系統產生的OOMKilling警告。這個問題可能會導致環境無法升級。
原因:
- 如果您為
[celery]worker_concurrencyAirflow 設定選項使用自訂值,並為 Airflow 工作站設定自訂記憶體,當資源消耗量接近上限時,可能會發生這個問題。 - 與舊版中的 worker 相比,在 Airflow 2.6.3 中使用 Python 3.11 時,Airflow worker 的記憶體需求會高出 10%。
- 與 Airflow 2.2 或 Airflow 2.1 中的工作站相比,Airflow 2.3 以上版本的工作站記憶體需求高出 30%。
解決方法:
- 移除
worker_concurrency的覆寫,讓 Managed Airflow 自動計算這個值。 - 如果使用
worker_concurrency的自訂值,請將其設為較低的值。您可以將自動計算的值做為起點。 - 或者,您也可以增加 Airflow 工作站可用的記憶體量。
- 如果因為這個問題而無法將環境升級至較新版本,請先套用建議的解決方案,再進行升級。
透過私人網路使用 Cloud Run functions 觸發 DAG
透過私人網路使用 VPC 連接器,以 Cloud Run 函式觸發 DAG,這項功能不支援 Managed Airflow。
建議:使用 Cloud Run 函式在 Pub/Sub 上發布訊息。這類事件可啟動 Pub/Sub 感應器,觸發 Airflow DAG 或實作以可延遲運算子為基礎的方法。
排程器和工作站中的空白資料夾
Managed Airflow 不會主動從 Airflow worker 和排程器移除空資料夾。如果這些資料夾存在於儲存空間中,但最終遭到移除,環境儲存空間同步處理程序可能會建立這類實體。
建議:調整 DAG,準備略過這類空白資料夾。
當這些元件重新啟動時 (例如,環境叢集縮減或維護作業的結果),這類實體最終會從 Airflow 排程器和工作站的本機儲存空間中移除。
支援 Kerberos
Managed Airflow 不支援 Airflow Kerberos 設定。
支援 Managed Airflow (第 2 代) 和 Managed Airflow (第 3 代) 的運算類別
Managed Airflow (第 3 代) 和 Managed Airflow (第 2 代) 僅支援一般用途 運算類別。也就是說,您無法執行要求其他運算類別 (例如「平衡」或「擴充」) 的 Pod。
一般用途類別可執行要求最多 110 GB 記憶體和最多 30 個 CPU 的 Pod (如「運算類別最大要求」一文所述)。
如要使用 ARM 架構,或需要更多 CPU 和記憶體,就必須使用其他運算類別,但這類別不支援 Managed Airflow (第 3 代) 和 Managed Airflow (第 2 代) 叢集。
建議:使用 GKEStartPodOperator 在支援所選運算類別的其他叢集上執行 Kubernetes Pod。如果您執行需要不同運算類別的自訂 Pod,這些 Pod 也必須在非受管理 Airflow 叢集上執行。
支援 Google Campaign Manager 360 運算子
如果使用 2.1.13 之前的 Managed Airflow 版本,Google Campaign Manager 運算子會採用已淘汰的 Campaign Manager 360 v3.5 API,該 API 的終止日期為 2023 年 5 月 1 日。
如果您使用 Google Campaign Manager 運算子,請將環境升級至 Managed Airflow 2.1.13 以上版本。
支援 Google Display & Video 360 運算子
如果 Managed Airflow 版本早於 2.1.13,Google Display and Video 360 運算子會採用已淘汰的 Display and Video 360 v1.1 API,該 API 將於 2023 年 4 月 27 日停用。
如果您使用 Google Display and Video 360 運算子,請將環境升級至 Managed Airflow 2.1.13 以上版本。此外,由於部分 Google Display & Video 360 運算子已淘汰並替換為新運算子,您可能需要變更 DAG。
GoogleDisplayVideo360CreateReportOperator目前已淘汰。請改用GoogleDisplayVideo360CreateQueryOperator。這個運算子會傳回query_id,而不是report_id。GoogleDisplayVideo360RunReportOperator目前已淘汰。請改用GoogleDisplayVideo360RunQueryOperator。這個運算子會傳回query_id和report_id,而不是只有report_id,且需要query_id做為參數,而不是report_id。- 如要檢查報表是否已準備就緒,請使用採用
query_id和report_id參數的新GoogleDisplayVideo360RunQuerySensor感應器。已淘汰的GoogleDisplayVideo360ReportSensor感應器只需要report_id。 GoogleDisplayVideo360DownloadReportV2Operator現在需要query_id和report_id參數。GoogleDisplayVideo360DeleteReportOperator沒有任何變更會影響 DAG。
次要範圍名稱限制
CVE-2023-29247 (UI 中的工作執行個體詳細資料頁面容易受到儲存的 XSS 攻擊)
Airflow 2.0.x 至 2.5.x 版本的 Airflow UI 存在 CVE-2023-29247 安全漏洞。
如果您使用的 Managed Airflow 版本低於 2.4.2,且懷疑環境可能容易受到漏洞攻擊,請參閱下列說明和可能的解決方案。
在 Managed Airflow 中,Airflow UI 的存取權受 IAM 保護,並透過 Airflow UI 存取控管。
也就是說,如要利用 Airflow UI 安全漏洞,攻擊者必須先取得專案存取權,以及必要的 IAM 權限和角色。
解決方法:
驗證專案中的 IAM 權限和角色,包括指派給個別使用者的 Managed Service for Apache Airflow 角色。確保只有核准的使用者可以存取 Airflow UI。
透過 Airflow UI 存取權控管機制驗證指派給使用者的角色 (這是另一種機制,可提供更精細的 Airflow UI 存取權)。請確保只有核准的使用者可以存取 Airflow UI,且所有新使用者都已註冊適當的角色。
考慮使用 VPC Service Controls 進行額外強化。
刪除後,代管 Airflow (第 2 代) Composer 環境的 Airflow 監控 DAG 不會重新建立
如果使用者刪除 Airflow 監控 DAG,或將其從 bucket 移出,在 composer-2.1.4-airflow-2.4.3 環境中,系統不會自動重新建立 DAG。
解決方法:
- 這個問題已在後續版本中修正,例如 composer-2.4.2-airflow-2.5.3。建議您將環境升級至較新版本。
- 如果無法升級環境,可以暫時採用替代解決方案,也就是從其他相同版本的環境複製 airflow_monitoring DAG。
無法減少 Cloud SQL 儲存空間
Managed Airflow 會使用 Cloud SQL 執行 Airflow 資料庫。隨著時間推移,Cloud SQL 執行個體的磁碟儲存空間可能會增加,因為磁碟會擴充,以配合 Airflow 資料庫成長時,Cloud SQL 作業儲存的資料。
無法縮減 Cloud SQL 磁碟大小。
如要使用最小的 Cloud SQL 磁碟大小,可以重新建立 Managed Airflow 環境並使用快照。
從 Cloud SQL 移除記錄後,資料庫磁碟使用量指標不會減少
當您刪除或更新資料列時,Postgres 或 MySQL 等關聯式資料庫不會實際移除資料列,而是將這些元組標示為「無效元組」,以維持資料一致性,並避免封鎖並行交易。
MySQL 和 Postgres 都會實作機制,在刪除記錄後回收空間。
雖然可以強制資料庫回收未使用的磁碟空間,但這項作業會耗用大量資源,而且會鎖定資料庫,導致 Managed Airflow 無法使用。因此,建議您依賴建構機制來回收未使用的空間。
已封鎖存取權:授權錯誤
如果這個問題會影響使用者,則「存取遭封鎖:授權錯誤」對話方塊會包含 Error 400: admin_policy_enforced 訊息。
如果 Google Workspace 已啟用「API 控制項」>「未設定的第三方應用程式」 >「禁止使用者存取任何第三方應用程式」選項,且未明確允許 Managed Airflow 應用程式中的 Apache Airflow,使用者就無法存取 Airflow UI,除非他們明確允許該應用程式。
如要允許存取,請按照「允許在 Google Workspace 中存取 Airflow UI」一文中的步驟操作。
存取 Airflow UI 時發生登入迴圈
這個問題的可能原因如下:
如果 Chrome Enterprise 進階版 情境感知存取權繫結搭配使用依據裝置屬性的存取層級,且 Managed Airflow 中的 Apache Airflow 應用程式未獲豁免,則會發生登入迴圈,導致無法存取 Airflow UI。如要允許存取,請按照「允許在情境感知存取權繫結中存取 Airflow UI」一文中的步驟操作。
如果專案受 VPC Service Controls 服務範圍保護,且您在該範圍內設定輸入規則,而允許存取 Managed Airflow 服務的輸入規則使用
ANY_SERVICE_ACCOUNT或ANY_USER_ACCOUNT身分類型,使用者就無法存取 Airflow 使用者介面,導致登入迴圈。如要進一步瞭解如何解決這個情況,請參閱「在 VPC Service Controls 傳入規則中允許存取 Airflow UI」。
過去成功的作業執行個體標示為「失敗」
在某些情況下,過去成功的 Airflow 工作執行個體可能會標示為 FAILED。
如果發生這種情況,通常是由環境更新或升級作業,或是 GKE 維護作業所觸發。
注意:問題本身不會指出環境中的任何問題,也不會導致工作執行失敗。
這項問題已在 Managed Airflow 2.6.5 以上版本中修正。
Airflow 元件與 Managed Airflow 設定的其他部分通訊時發生問題
這項問題僅適用於 Managed Airflow (第 2 代) 2.10.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 版本。從 Managed Airflow 2.11.0 版起,此問題已修正。
Airflow 網路伺服器中沒有 /data 資料夾
在 Managed Airflow (第 2 代) 和 Managed Airflow (第 3 代) 中,Airflow 網路伺服器主要為唯讀元件,Managed Airflow 不會將 data/ 資料夾同步至這個元件。
有時您可能想在所有 Airflow 元件 (包括 Airflow 網路伺服器) 之間共用檔案。
解決方法:
將要與網路伺服器共用的檔案封裝到 PYPI 模組中,然後以一般 PYPI 套件的形式安裝。在環境中安裝 PYPI 模組後,檔案會新增至 Airflow 元件的映像,並供這些元件使用。
將檔案新增至
plugins/資料夾。這個資料夾會同步到 Airflow 網路伺服器。
監控中的非連續 DAG 剖析時間和 DAG bag 大小圖表
監控資訊主頁上的非連續 DAG 剖析時間和 DAG 包大小圖表,表示 DAG 剖析時間過長 (超過 5 分鐘)。
解決方法: 建議您將 DAG 剖析總時間控制在 5 分鐘內。如要縮短 DAG 剖析時間,請遵循 DAG 編寫指南。
Cloud Logging 中缺少 Managed Airflow 元件記錄
環境的元件發生問題,導致無法將 Airflow 元件的記錄檔上傳至 Cloud Logging。這個錯誤有時會導致 Airflow 元件缺少 Managed Airflow 層級的記錄。您仍可在 Kubernetes 元件層級查看相同記錄。
問題發生頻率:極少,偶爾發生
原因:
負責將記錄檔上傳至 Cloud Logging 的 Managed Airflow 元件行為不正確。
解決方法:
將環境升級至 Managed Airflow 2.10.0 以上版本。
在舊版 Managed Airflow 中,如果遇到這種情況,暫時解決方法是啟動 Managed Airflow 作業,重新啟動缺少記錄的元件。
不支援將環境的叢集切換至 GKE Enterprise 版本
這項附註適用於 Managed Airflow 1 和 Managed Airflow 2。
Managed Airflow 環境的 GKE 叢集是在 GKE Standard 中建立。
自 2024 年 12 月起,Managed Airflow 服務不支援使用 Enterprise Edition 中的叢集建立 Managed Airflow 環境。
我們未在 GKE Enterprise Edition 中測試 Managed Airflow 環境,且兩者採用不同的計費模式。
我們將於 2025 年第 2 季,進一步說明 GKE Standard 版與 Enterprise 版的差異。
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 遭停用後,環境處於 ERROR 狀態
受這些問題影響的 Managed Airflow 環境無法復原:
- 專案的帳單帳戶遭刪除或停用後,即使之後連結了其他帳戶,也無法使用。
- 專案停用 Cloud Composer API 後,即使後來啟用也一樣。
如要解決這個問題,請採取下列做法:
您仍可存取儲存在環境值區中的資料,但無法再使用環境本身。您可以建立新的 Managed Airflow 環境,然後轉移 DAG 和資料。
如要執行任何會導致環境無法復原的作業,請務必備份資料,例如建立環境的快照。這樣一來,您就能建立另一個環境,並載入這個快照來轉移資料。
環境叢集的 Pod 中斷預算警告
在 GKE UI 中,您可能會看到下列 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 使用者介面有項限制,就是無法將連線欄位更新為空值。嘗試這麼做時,系統會還原為先前儲存的設定。
可能的解決方案:
雖然 Apache Airflow 2.10.4 版已永久修正這個問題,但如果使用者使用舊版,可以暫時採取替代方案。具體做法是刪除連線,然後重新建立連線,但將必要欄位留空。建議使用指令列介面刪除連線:
gcloud composer environments run ENVIRONMENT_NAME \
--location LOCATION \
connections delete -- \
CONNECTION_ID
刪除連線後,請使用 Airflow UI 重新建立連線,並確保要留空的欄位確實空白。您也可以使用 Google Cloud CLI 執行 connections add Airflow CLI 指令來建立連線。
如果 [core]execute_tasks_new_python_interpreter 設為 True,系統就不會收集 Airflow 工作記錄
如果 Airflow 設定選項設為 True,Managed Airflow 就不會收集 Airflow 工作的記錄。[core]execute_tasks_new_python_interpreter
參考解法:
- 移除這項設定選項的覆寫,或將其值設為
False。
指標中缺少資料點、ValueError:無法判斷路徑,因為沒有 bucket 名稱
如果環境使用 Managed Airflow (第 2 代) 2.16.0 和 2.16.1 版,可能會遇到指標回報的已知問題。您可能會發現報告指標中略過幾個資料點,並在環境記錄檔中看到有關 airflow-monitoring pod 重新啟動的錯誤訊息。
錯誤訊息範例:
ValueError: Cannot determine path without bucket name error。
這個問題不會影響環境的功能。環境仍可運作,且環境健康狀態和監控資訊回報正確。您可以忽略這些錯誤訊息。