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>.
解決方法：
在要建立 Cloud Composer 環境的專案中停用機構政策。
即使上層資源 (機構或資料夾) 已啟用組織政策，您還是可以在專案層級停用該政策。詳情請參閱「自訂布林值限制條件的政策」頁面。
使用排除篩選器
使用序列埠記錄的排除篩選器，可達到與停用機構政策相同的目標，因為記錄中會有序列控制台記錄。詳情請參閱「排除篩選器」頁面。
使用 Deployment Manager 管理 Google Cloud 受 VPC Service Controls 保護的資源
Cloud Composer 1 和 Cloud Composer 2 2.0.x 版本會使用部署管理工具建立 Cloud Composer 環境的元件。
在 2020 年 12 月，您可能收到了資訊，指出您可能需要執行額外的 VPC Service Controls 設定，才能使用 Deployment Manager 管理受 VPC Service Controls 保護的資源。
在此澄清，如果您使用 Cloud Composer，且不直接使用部署管理工具來管理部署管理工具公告中提到的 Google Cloud 資源，則您不必採取任何行動。
Deployment Manager 顯示不支援功能的相關資訊
您可能會在「Deployment Manager」分頁中看到以下警告：
The deployment uses actions, which are an unsupported feature. We recommend
that you avoid using actions.
如果是 Cloud Composer 擁有的部署管理工具部署作業，您可以忽略這則警告。
無法在叢集刪除後刪除環境
這個問題適用於 Cloud Composer 1 和 Cloud Composer 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 和工作處理作業。
我們正在努力改善 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 檔案並排定由 worker 執行，但 worker 尚未取得 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 值區時，可能會發生問題
Cloud Composer 會使用 gcsfuse 存取環境值區中的 /data 資料夾，並將 Airflow 工作記錄儲存至 /logs 目錄 (如果已啟用)。如果 gcsfuse 超載或環境的儲存格無法使用，您可能會遇到 Airflow 工作執行個體失敗的情況，並在 Airflow 記錄中看到 Transport endpoint is not connected 錯誤。
解決方法：
- 停用將記錄儲存至環境的值區。如果您使用 Cloud Composer 2.8.0 以上版本建立環境，這個選項已預設為停用。
- 升級至 Cloud Composer 2.8.0 以上版本。
- 請改為減少
[celery]worker_concurrency並增加 Airflow 工作站數量。 - 減少 DAG 程式碼產生的記錄數量。
- 請按照建議做法和最佳做法實作 DAG 並啟用任務重試功能。
Airflow UI 有時可能不會在外掛程式變更後重新載入
如果外掛程式包含許多匯入其他模組的檔案，Airflow UI 可能無法辨識應重新載入外掛程式。在這種情況下，請重新啟動環境的 Airflow 網路伺服器。
環境叢集中的工作負載處於無法排程的狀態
這個已知問題僅適用於 Cloud Composer 2。
在 Cloud Composer 2 中，建立環境後，環境叢集中的多個工作負載仍處於無法排程狀態。
當環境擴充時，系統會建立新的 worker pod，並由 Kubernetes 嘗試執行。如果沒有可用來執行這些 Pod 的空閒資源，系統會將 worker Pod 標示為「無法排程」。
在這種情況下，叢集自動配置器會新增更多節點，這可能需要幾分鐘的時間。在完成之前，Pod 會維持在無法排程狀態，且不會執行任何工作。
無法排程的 DaemonSet 工作負載 (名稱為 composer-gcsfuse 和 composer-fluentd)，如果無法在沒有 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。如果您使用私人 Google 存取權，並透過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 使用者介面。
無法啟動網路伺服器。為了開始，網路伺服器必須先同步處理設定檔。查看網路伺服器記錄，找出類似下列內容的記錄項目：
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 設定選項。
在樹狀檢視畫面中將滑鼠游標懸停在工作執行個體上時，會擲回未偵測到的 TypeError
在 Airflow 2 中，如果使用非預設時區，Airflow UI 中的樹狀檢視畫面有時可能無法正常運作。如要解決這個問題，請在 Airflow UI 中明確設定時區。
Airflow 2.2.3 以下版本的 Airflow UI 容易受到 CVE-2021-45229 的影響
如 CVE-2021-45229 所述，「Trigger DAG with config」畫面容易受到透過 origin 查詢引數的 XSS 攻擊。
建議：升級至支援 Airflow 2.2.5 的最新 Cloud Composer 版本。
工作者需要的記憶體比先前版本的 Airflow 還要多
症狀：
在 Cloud Composer 2 環境中，所有環境的 Airflow 工作站叢集工作負載都處於
CrashLoopBackOff狀態，且不會執行工作。如果您受到這個問題的影響，系統也會產生OOMKilling警告。這個問題可能會導致環境升級失敗。
原因：
- 如果您為
[celery]worker_concurrencyAirflow 設定選項使用自訂值，並為 Airflow 工作站設定自訂記憶體，當資源用量接近限制時，您可能會遇到這個問題。 - 在 Airflow 2.6.3 中，使用 Python 3.11 的 Airflow worker 記憶體需求比舊版 worker 高出 10%。
- Airflow 2.3 以上版本的工作站記憶體需求，比 Airflow 2.2 或 Airflow 2.1 版本高出 30%。
解決方法：
- 移除
worker_concurrency的覆寫值，讓 Cloud Composer 自動計算這個值。 - 如果您為
worker_concurrency使用自訂值，請將其設為較低的值。您可以使用自動計算的值做為起點。 - 或者，您也可以增加 Airflow 工作站可用的記憶體量。
- 如果因為這個問題無法將環境升級至較新版本，請先套用其中一個建議的解決方案，再進行升級。
使用 Cloud Run 函式透過私人網路觸發 DAG
Cloud Composer 不支援透過私人網路使用 VPC 連接器，觸發含有 Cloud Run 函式的 DAG。
建議：使用 Cloud Run 函式在 Pub/Sub 上發布訊息。這類事件可啟動 Pub/Sub 感應器，以觸發 Airflow DAG 或實作以可延遲運算子為基礎的方法。
排程器和 worker 中的空資料夾
Cloud Composer 不會主動從 Airflow 工作者和排程器中移除空資料夾。當這些資料夾存在於儲存桶中，且最終遭到移除時，環境儲存桶同步處理程序可能會建立這類實體。
建議：調整 DAG，讓系統能略過這類空白資料夾。
當這些元件重新啟動時 (例如，在環境叢集中縮減或維護作業)，這些實體最終會從 Airflow 排程器和工作站的本機儲存空間中移除。
支援 Kerberos
Cloud Composer 不支援 Airflow Kerberos 設定。
支援 Cloud Composer 2 和 Cloud Composer 3 中的運算類別
Cloud Composer 3 和 Cloud Composer 2 僅支援通用 運算類別。這表示無法執行要求其他運算類別 (例如「平衡」或「擴大規模」) 的 Pod。
一般用途類別可讓執行的 Pod 要求最多 110 GB 記憶體和最多 30 個 CPU (如運算類別的最大要求所述)。
如果您想使用以 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 360 v3.5 API 為基礎，該 API 的淘汰日期為 2023 年 5 月 1 日。
如果您使用 Google Campaign Manager 運算子，請將環境升級至 Cloud Composer 2.1.13 以上版本。
支援 Google Display & Video 360 運算子
在 Cloud Composer 2.1.13 以下版本中，Google Display & Video 360 運算子會使用已淘汰的 Display & 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做為參數。- 如要確認報表是否已就緒，請使用採用
query_id和report_id參數的新GoogleDisplayVideo360RunQuerySensor感應器。已淘汰的GoogleDisplayVideo360ReportSensor感應器只需要report_id。 GoogleDisplayVideo360DownloadReportV2Operator現在需要query_id和report_id參數。- 在
GoogleDisplayVideo360DeleteReportOperator中，沒有任何變更會影響您的 DAG。
次要範圍名稱限制
CVE-2023-29247 (使用者介面中的任務執行個體詳細資料頁面容易受到儲存式 XSS 攻擊)
Airflow 2.0.x 到 2.5.x 版本的 Airflow UI 容易受到 CVE-2023-29247 的影響。
如果您使用的是 2.4.2 以下版本的 Cloud Composer，且懷疑環境可能會遭到此漏洞攻擊，請參閱以下說明和可能的解決方案。
在 Cloud Composer 中，Airflow UI 的存取權會受到 IAM 保護，並由 Airflow UI 存取權控管控管。
也就是說，攻擊者必須先取得專案存取權，以及必要的 IAM 權限和角色，才能利用 Airflow UI 的安全漏洞。
解決方法：
驗證專案中的 IAM 權限和角色，包括指派給個別使用者的 Cloud Composer 角色。請確認只有核准的使用者可以存取 Airflow UI。
透過 Airflow UI 存取權控管機制驗證指派給使用者的角色 (這是另一個機制，可提供更精細的 Airflow UI 存取權)。請確認只有獲准的使用者才能存取 Airflow UI，且所有新使用者都已註冊適當的角色。
考慮使用 VPC Service Controls 進一步強化安全性。
Cloud Composer 2 Composer 環境的 Airflow 監控 DAG 在刪除後不會重新建立
如果使用者在 composer-2.1.4-airflow-2.4.3 環境中刪除或從值區移出 airflow 監控 DAG，系統不會自動重新建立 DAG。
解決方法：
- 這項問題已在後續版本中修正，例如 composer-2.4.2-airflow-2.5.3。建議您將環境升級至較新版本。
- 升級環境的替代方法或暫時性解決方法，是從其他環境中複製 airflow_monitoring DAG，且版本必須相同。
無法減少 Cloud SQL 儲存空間
Cloud Composer 會使用 Cloud SQL 執行 Airflow 資料庫。隨著 Airflow 資料庫的成長，Cloud SQL 執行個體的磁碟儲存空間可能會隨著 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 UI」一文中的步驟操作。
存取 Airflow UI 時的登入迴圈
造成這個問題的原因可能如下：
如果 Chrome Enterprise Premium 情境感知存取繫結與仰賴裝置屬性的存取層級搭配使用，且 Cloud Composer 應用程式中的 Apache Airflow 未予以豁免，則由於登入迴圈，無法存取 Airflow UI。如要允許存取權，請按照允許在情境感知存取權繫結中存取 Airflow UI所述的步驟操作。
如果在保護專案的 VPC Service Controls 範圍內設定入站規則，且允許存取 Cloud Composer 服務的入站規則使用
ANY_SERVICE_ACCOUNT或ANY_USER_ACCOUNT身分類型，使用者就無法存取 Airflow UI，並會進入登入迴圈。如要進一步瞭解如何處理這種情況，請參閱「在 VPC Service Controls 入站規則中允許存取 Airflow UI」。
過去成功執行的工作例項，現在標示為「失敗」
在某些情況和極少數情況下，過去成功的 Airflow 工作執行個體可能會標示為 FAILED。
發生這種情況時，通常是因為環境更新或升級作業，或是 GKE 維護作業所觸發。
注意：這個問題本身並未指出環境中存在任何問題，也不會導致任務執行失敗。
這個問題已在 Cloud Composer 2.6.5 以上版本中修正。
Airflow 元件在與 Cloud Composer 設定的其他部分通訊時發生問題
在極少數情況下，與 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
解決方法：
設定下列環境變數：GCE_METADATA_TIMEOUT=30。
/data 資料夾無法在 Airflow 網路伺服器中使用
在 Cloud Composer 2 和 Cloud Composer 3 中，Airflow 網路伺服器主要是用於讀取，Cloud Composer 不會將 data/ 資料夾同步處理至這個元件。
有時，您可能會想要在所有 Airflow 元件 (包括 Airflow 網路伺服器) 之間共用常用檔案。
解決方法：
將要與網路伺服器共用的檔案包裝至 PYPI 模組，並以一般 PYPI 套件安裝。在環境中安裝 PYPI 模組後，系統會將檔案新增至 Airflow 元件的映像檔，並提供給這些元件使用。
將檔案新增至
plugins/資料夾。這個資料夾會同步至 Airflow 網路伺服器。
監控中非連續 DAG 剖析時間和 DAG 袋大小圖表
監控資訊主頁上顯示的非連續 DAG 剖析時間和 DAG 袋大小圖表，表示 DAG 剖析時間過長 (超過 5 分鐘)。
解決方法：建議您將 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 版本中使用叢集建立 Cloud Composer 環境。
Cloud Composer 環境並未使用 GKE 企業版進行測試，且採用不同的帳單模式。
我們會在 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 中斷預算警告
您可以在 GKE UI 中看到 Cloud Composer 環境叢集的以下警告：
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 工作記錄
如果 [core]execute_tasks_new_python_interpreter Airflow 設定選項設為 True，Cloud Composer 就不會收集 Airflow 工作記錄。
參考解法：
- 移除這項設定選項的覆寫值，或將其值設為
False。