已知問題

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

本頁面列出 Cloud Composer 的已知問題。如要瞭解修正的問題，請參閱「版本資訊」。

部分問題會影響舊版，可透過升級環境修正。

Pod 和服務部分支援非 RFC 1918 位址範圍

Cloud Composer 依賴 GKE，為 Pod 和服務提供非 RFC 1918 位址的支援。Cloud Composer 僅支援下列非 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」，就無法建立 Cloud Composer 環境

如果目標專案強制執行 constraints/compute.disableSerialPortLogging 機構政策，Cloud Composer 環境建立作業就會失敗。

診斷

如要判斷是否受到這個問題影響，請按照下列程序操作：

前往Google Cloud 控制台的 GKE 選單。造訪 GKE 選單

然後選取新建的叢集。檢查是否有下列錯誤：

Not all instances running in IGM after 123.45s.
Expect <number of desired instances in IGM>. Current errors:

Constraint constraints/compute.disableSerialPortLogging violated for
project <target project number>.

解決方法：

  1. 在要建立 Cloud Composer 環境的專案中，停用機構政策。

    即使上層資源 (機構或資料夾) 已啟用機構政策，您仍可在專案層級停用該政策。詳情請參閱「自訂布林值限制條件的政策」頁面。

  2. 使用排除篩選器

    使用序列埠記錄的排除篩選器，可達到與停用機構政策相同的目標，因為 Logging 中不會有序列控制台記錄。詳情請參閱「排除篩選器」頁面。

使用 Deployment Manager 管理 Google Cloud 受 VPC Service Controls 保護的資源

Cloud Composer 1 和 Cloud Composer 2 2.0.x 版會使用 Deployment Manager 建立 Cloud Composer 環境的元件。

您可能在 2020 年 12 月收到相關資訊，指出您可能需要進行額外的 VPC Service Controls 設定，才能使用 Deployment Manager 管理受 VPC Service Controls 保護的資源。

請注意，如果您使用 Cloud Composer，且並未直接使用 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 的部署作業是由 Cloud Composer 擁有，您可以忽略這則警告。

叢集刪除後，就無法刪除環境

這個問題適用於 Cloud Composer 1 和 Cloud Composer 2 2.0.x 版。

如果您在刪除環境本身之前刪除環境的 GKE 叢集，嘗試刪除環境時會發生下列錯誤：

 Got error "" during CP_DEPLOYMENT_DELETING [Rerunning Task. ]

如要在叢集刪除後刪除環境，請按照下列步驟操作：

  1. 前往 Google Cloud 控制台的「Deployment Manager」頁面。

    前往「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. 點選「刪除」。

    3. 選取「Delete 2 deployments and all resources created by them, such as VMs, load balancers and disks」(刪除 2 項部署作業及其建立的所有資源，例如 VM、負載平衡器和磁碟) 選項，然後按一下「Delete all」(全部刪除)。

    刪除作業失敗，但剩餘資源已刪除。

  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. 刪除 Cloud Composer 環境。

警告：屬於「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 和工作處理程序。

我們正在努力改善 Cloud Composer 服務，從 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 政策，Cloud Composer 環境建立或升級作業就會失敗

這個問題適用於 Cloud Composer 1 和 Cloud Composer 2 環境。

以公開 IP 模式設定的 Cloud Composer 專屬 GKE 叢集，其 VM 需要外部連線。因此，compute.vmExternalIpAccess 政策無法禁止建立具有外部 IP 位址的 VM。如要進一步瞭解這項組織政策，請參閱組織政策限制。

上傳的 DAG 檔案首次執行 DAG 時，有多項工作失敗

上傳 DAG 檔案時，有時第一個 DAG 執行作業的前幾項工作會失敗，並顯示 Unable to read remote log... 錯誤。發生這個問題的原因是，DAG 檔案會在環境的值區、Airflow 工作站和環境的 Airflow 排程器之間同步處理。如果排程器取得 DAG 檔案並排定由工作站執行，但工作站尚未取得 DAG 檔案，則工作執行作業會失敗。

為減輕這個問題的影響，搭載 Airflow 2 的環境預設會對失敗的工作重試兩次。如果工作失敗，系統會以 5 分鐘間隔重試兩次。

公告：GKE 版本將移除對已淘汰 Beta 版 API 的支援

Cloud Composer 會管理 Cloud Composer 擁有的基礎 GKE 叢集。除非您在 DAG 和程式碼中明確使用這類 API，否則可以忽略有關 GKE API 淘汰的公告。Cloud Composer 會視需要處理任何遷移作業。

Cloud Composer 不會受到 Apache Log4j 2 安全漏洞 (CVE-2021-44228) 影響

為因應 Apache Log4j 2 安全漏洞 (CVE-2021-44228)， Cloud Composer 已進行詳細調查， 我們認為 Cloud Composer 不會受到這項安全漏洞影響。

Airflow 工作站或排程器存取環境的 Cloud Storage bucket 時可能會發生問題

Cloud Composer 會使用 gcsfuse 存取環境 bucket 中的 /data 資料夾，並將 Airflow 工作記錄儲存至 /logs 目錄 (如已啟用)。如果 gcsfuse 負載過重或環境的 bucket 無法使用，您可能會遇到 Airflow 工作執行個體失敗的問題，且 Airflow 記錄中會顯示 Transport endpoint is not connected 錯誤。

解決方法：

有時變更外掛程式後，Airflow UI 可能不會重新載入外掛程式

如果外掛程式包含許多匯入其他模組的檔案，Airflow UI 可能無法辨識外掛程式應重新載入。在這種情況下，請重新啟動環境的 Airflow 網路伺服器。

環境的叢集有處於「無法排程」狀態的工作負載

這項已知問題僅適用於 Cloud Composer 2。

在 Cloud Composer 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 網頁伺服器。

  • (僅限 Cloud Composer 3) 連線問題。如果 Airflow UI 永久無法使用，且產生逾時或 504 錯誤，請確認您的環境可以存取 *.composer.googleusercontent.com。

  • (僅限 Cloud Composer 2) 連線問題。如果 Airflow UI 永久無法使用，且產生逾時或 504 錯誤，請確認您的環境可以存取 *.composer.cloud.google.com。如果您使用 Private Google Access 並透過private.googleapis.com虛擬 IP 傳送流量，或是使用 VPC Service Controls 並透過restricted.googleapis.com虛擬 IP 傳送流量，請確保 Cloud DNS 也已設定為*.composer.cloud.google.com網域名稱。

  • 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 中。

    如果這些項目遭到意外移除 (例如因為設定了保留政策)，您可以還原這些項目：

    1. 在環境中設定新的環境變數。您可以使用任何變數名稱和值。

    2. 覆寫 Airflow 設定選項。您可以使用不存在的 Airflow 設定選項。

在樹狀檢視中將滑鼠游標懸停在工作執行個體上時，會擲回未捕捉到的 TypeError

在 Airflow 2 中，使用非預設時區時，Airflow UI 中的樹狀檢視畫面有時可能無法正常運作。如要暫時解決這個問題，請在 Airflow 使用者介面中明確設定時區。

Airflow 2.2.3 以下版本的 Airflow UI 容易受到 CVE-2021-45229 攻擊

如 CVE-2021-45229 所述，「使用設定觸發 DAG」畫面容易受到 XSS 攻擊，因為 origin 查詢引數會造成此問題。

建議：升級至支援 Airflow 2.2.5 的最新 Cloud Composer 版本。

工作人員需要的記憶體比舊版 Airflow 多

症狀：

  • 在 Cloud Composer 2 環境中，所有環境的 Airflow 工作站叢集工作負載都處於 CrashLoopBackOff 狀態，且不會執行工作。如果受到這個問題影響，您也會看到系統產生的 OOMKilling 警告。

  • 這個問題可能會導致環境無法升級。

原因：

  • 如果您為 Airflow 工作站使用 [celery]worker_concurrency Airflow 設定選項的自訂值和自訂記憶體設定，當資源消耗量接近上限時，可能會發生這個問題。
  • 與舊版工作站相比，在 Airflow 2.6.3 中使用 Python 3.11 時，Airflow 工作站的記憶體需求會增加 10%。
  • 與 Airflow 2.2 或 Airflow 2.1 中的工作站相比，Airflow 2.3 以上版本的工作站記憶體需求高出 30%。

解決方法：

  • 移除 worker_concurrency 的覆寫，讓 Cloud Composer 自動計算這個值。
  • 如果使用 worker_concurrency 的自訂值，請將其設為較低的值。 您可以將自動計算的值做為起點。
  • 或者，您也可以增加 Airflow 工作站可用的記憶體量。
  • 如果因為這個問題而無法將環境升級至較新版本，請先套用建議的解決方案，再進行升級。

透過私人網路使用 Cloud Run 函式觸發 DAG

Cloud Composer 不支援透過私人網路，使用虛擬私有雲連接器，以 Cloud Run 函式觸發 DAG。

建議：使用 Cloud Run 函式在 Pub/Sub 上發布訊息。這類事件可啟動 Pub/Sub 感應器，觸發 Airflow DAG 或實作以可延遲運算子為基礎的方法。

排程器和工作站中的空白資料夾

Cloud Composer 不會主動從 Airflow 工作人員和排程器中移除空白資料夾。如果這些資料夾存在於儲存空間中，但最終遭到移除，環境儲存空間同步程序可能會建立這類實體。

建議：調整 DAG，準備略過這類空白資料夾。

當 Airflow 排程器和工作站重新啟動時 (例如，環境叢集縮減或維護作業導致重新啟動)，這類實體最終會從本機儲存空間移除。

支援 Kerberos

Cloud Composer 不支援 Airflow Kerberos 設定。

Cloud Composer 2 和 Cloud Composer 3 支援的運算類別

Cloud Composer 3 和 Cloud Composer 2 只支援一般用途 運算類別。也就是說，您無法執行要求其他運算類別 (例如「平衡」或「擴充」) 的 Pod。

一般用途類別可執行要求最多 110 GB 記憶體和最多 30 個 CPU 的 Pod (如「運算類別最大要求」一文所述)。

如要使用 ARM 架構，或需要更多 CPU 和記憶體，則必須使用其他運算類別，但 Cloud Composer 3 和 Cloud Composer 2 叢集不支援這類別。

建議：使用 GKEStartPodOperator 在支援所選運算類別的其他叢集上執行 Kubernetes Pod。如果您執行需要不同運算類別的自訂 Pod，這些 Pod 也必須在非 Cloud Composer 叢集上執行。

支援 Google Campaign Manager 360 運算符

在 2.1.13 之前的 Cloud Composer 版本中，Google Campaign Manager 運算子是以已淘汰的 Campaign Manager 360 v3.5 API 為基礎，該 API 的終止日期為 2023 年 5 月 1 日。

如果您使用 Google Campaign Manager 運算子，請將環境升級至 Cloud Composer 2.1.13 以上版本。

支援 Google Display & Video 360 運算子

在 2.1.13 之前的 Cloud Composer 版本中，Google Display and Video 360 運算子是根據已淘汰的 Display and Video 360 v1.1 API 運作，該 API 將於 2023 年 4 月 27 日停用。

如果您使用 Google Display & Video 360 運算子，請將環境升級至 Cloud Composer 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。
  • 如要檢查報告是否已準備就緒，請使用新的 GoogleDisplayVideo360RunQuerySensor 感應器，該感應器會使用 query_id 和 report_id 參數。已淘汰的 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 攻擊。

如果您使用的 Cloud Composer 版本低於 2.4.2，且懷疑環境可能容易受到攻擊，請參閱下列說明和可能的解決方案。

在 Cloud Composer 中，Airflow UI 的存取權受 IAM 保護，並透過 Airflow UI 存取權控管。

也就是說，如要利用 Airflow UI 漏洞，攻擊者必須先取得專案存取權，以及必要的 IAM 權限和角色。

解決方法：

刪除後，Cloud Composer 2 Composer 環境的 Airflow 監控 DAG 不會重新建立

如果使用者刪除氣流監控 DAG，或將其從環境中的值區移出 (使用 composer-2.1.4-airflow-2.4.3)，系統不會自動重新建立 DAG。

解決方法：

  • 這個問題已在後續版本中修正，例如 composer-2.4.2-airflow-2.5.3。建議您將環境升級至較新版本。
  • 如果無法升級環境，可以暫時採用替代解決方案，也就是從其他相同版本的環境複製 airflow_monitoring DAG。

無法減少 Cloud SQL 儲存空間

Cloud Composer 會使用 Cloud SQL 執行 Airflow 資料庫。隨著時間推移，Cloud SQL 執行個體的磁碟儲存空間可能會增加，因為磁碟會擴充，以配合 Airflow 資料庫成長時 Cloud SQL 作業儲存的資料。

無法縮減 Cloud SQL 磁碟大小。

如要使用最小的 Cloud SQL 磁碟大小，可以重新建立 Cloud Composer 環境並使用快照。

從 Cloud SQL 移除記錄後，資料庫磁碟使用量指標不會減少

當您刪除或更新資料列時，Postgres 或 MySQL 等關聯式資料庫不會實際移除資料列，而是將這些元組標示為「無效元組」，以維持資料一致性，並避免封鎖並行交易。

MySQL 和 Postgres 都會實作機制，在刪除記錄後回收空間。

雖然可以強制資料庫回收未使用的磁碟空間，但這項作業會耗用大量資源，而且會鎖定資料庫，導致 Cloud Composer 無法使用。因此，建議您依賴建構機制來回收未使用的空間。

已封鎖存取權：授權錯誤

如果這個問題會影響使用者，則「存取遭封鎖：授權錯誤」對話方塊會包含 Error 400: admin_policy_enforced 訊息。

如果 Google Workspace 中已啟用「API 控制項」>「未設定的第三方應用程式」 >「禁止使用者存取任何第三方應用程式」選項，且未明確允許 Cloud Composer 中的 Apache Airflow 應用程式，使用者就無法存取 Airflow UI，除非他們明確允許該應用程式。

如要允許存取，請按照「允許存取 Google Workspace 中的 Airflow 使用者介面」一文中的步驟操作。

存取 Airflow UI 時發生登入迴圈

這個問題可能的原因如下：

過去成功的作業執行個體標示為「失敗」

在某些情況和極少數情況下，過去成功的 Airflow 工作執行個體可能會標示為 FAILED。

如果發生這種情況，通常是由環境更新或升級作業，或是 GKE 維護作業所觸發。

注意：問題本身不會指出環境中的任何問題，也不會導致工作執行失敗。

這項問題已在 Cloud Composer 2.6.5 以上版本中修正。

Airflow 元件與 Cloud Composer 設定的其他部分通訊時發生問題

這個問題僅適用於 Cloud Composer 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

解決方法：

  • (建議) 將環境升級至較新的 Cloud Composer 版本。從 Cloud Composer 2.11.0 版起，此問題已修正。

  • 如要暫時解決這個問題，可以設定下列環境變數：GCE_METADATA_TIMEOUT=30。準備升級環境時，請務必移除這項設定。

Airflow 網路伺服器中沒有 /data 資料夾

在 Cloud Composer 2 和 Cloud Composer 3 中，Airflow 網路伺服器主要為唯讀元件，Cloud Composer 不會將 data/ 資料夾同步至這個元件。

有時您可能想在所有 Airflow 元件 (包括 Airflow 網頁伺服器) 之間共用檔案。

解決方法：

  • 將要與網路伺服器共用的檔案包裝成 PYPI 模組，並安裝為一般 PYPI 套件。在環境中安裝 PYPI 模組後，檔案會新增至 Airflow 元件的映像檔，並供這些元件使用。

  • 將檔案新增至 plugins/ 資料夾。這個資料夾會同步到 Airflow 網路伺服器。

監控中的非連續 DAG 剖析時間和 DAG 包大小圖表

監控資訊主頁上的非連續 DAG 剖析時間和 DAG 包大小圖表，表示 DAG 剖析時間過長 (超過 5 分鐘)。

Airflow DAG 剖析時間和 DAG 包大小圖表，顯示一系列不連續的間隔
圖 1. 不連續的 DAG 剖析時間和 DAG 包裹大小圖表 (按一下可放大)

解決方案： 建議將 DAG 剖析總時間維持在 5 分鐘以下。如要縮短 DAG 剖析時間，請遵循 DAG 編寫指南。

Cloud Logging 中缺少 Cloud Composer 元件記錄

環境的元件發生問題，導致無法將 Airflow 元件的記錄上傳至 Cloud Logging。有時這個錯誤會導致 Airflow 元件缺少 Cloud Composer 層級的記錄。您仍可在 Kubernetes 元件層級查看相同記錄。

問題發生頻率：極少發生，偶爾發生

原因：

負責將記錄檔上傳至 Cloud Logging 的 Cloud Composer 元件行為異常。

解決方法：

  • 將環境升級至 Cloud Composer 2.10.0 以上版本。

  • 在舊版 Cloud Composer 中，如果遇到這種情況，暫時解決方法是啟動 Cloud Composer 作業，重新啟動缺少記錄的元件。

不支援將環境的叢集切換至 GKE Enterprise 版本

這項附註適用於 Cloud Composer 1 和 Cloud Composer 2。

Cloud Composer 環境的 GKE 叢集是在 GKE Standard 版中建立。

自 2024 年 12 月起，Cloud Composer 服務不支援在 Enterprise Edition 中建立含叢集的 Cloud Composer 環境。

Cloud Composer 環境未經過 GKE Enterprise Edition 測試，且採用不同的計費模式。

我們將於 2025 年第 2 季，進一步說明 GKE Standard 版與 Enterprise 版的差異。

Airflow 元件在與 Cloud Composer 設定的其他部分通訊時發生問題

在某些情況下，由於 DNS 解析失敗，Airflow 元件在與其他 Cloud Composer 元件或 Cloud Composer 環境外的服務端點通訊時，可能會發生問題。

症狀：

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.

可能的解決方法：

  • 升級至 Cloud Composer 2.9.11 或

  • 設定下列環境變數：GCE_METADATA_HOST=169.254.169.254。

專案的帳單帳戶遭刪除或停用，或 Cloud Composer API 遭停用後，環境處於 ERROR 狀態

受這些問題影響的 Cloud Composer 環境無法復原：

  • 專案的帳單帳戶遭刪除或停用後，即使之後連結了其他帳戶，也無法使用。
  • 在專案中停用 Cloud Composer API 後，即使後來啟用也一樣。

如要解決這個問題，請採取下列行動：

  • 您仍可存取環境值區中儲存的資料，但無法再使用環境本身。您可以建立新的 Cloud Composer 環境，然後轉移 DAG 和資料。

  • 如要執行任何會導致環境無法復原的作業，請務必備份資料，例如建立環境的快照。這樣一來，您就能建立另一個環境，並載入這個快照來轉移資料。

環境叢集的 Pod 中斷預算警告

在 Cloud Composer 環境叢集的 GKE UI 中，您可能會看到下列警告：

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 重新建立連線，並確保要留空的欄位確實空白。您也可以connections add使用 Google Cloud CLI 執行 Airflow CLI 指令，建立連線。

如果 [core]execute_tasks_new_python_interpreter 設為 True，系統就不會收集 Airflow 工作記錄

如果 [core]execute_tasks_new_python_interpreter Airflow 設定選項設為 True，Cloud Composer 就不會收集 Airflow 工作的記錄。

參考解法：

  • 移除這項設定選項的覆寫，或將其值設為 False。

後續步驟