Day25 提到，kapp-controller 可以讀取 GitLab Repo，自己取得設定並部署到叢集。GitLab 保存 YAML、執行 CI，部署則交給 Controller，這就是 Carvel GitOps 的一種做法。

那 GitLab Pipeline、Carvel 與 Argo CD 都能部署服務，差在哪裡？今天用 api-a 從 v1 更新到 v2 的例子，看看三種方式怎麼運作，以及適合什麼需求。

Git 有保存 YAML，部署之後誰繼續處理？

常見的做法是把 YAML 放在 GitLab Repo，透過 Merge Request 審查，CI 檢查內容，CD 再連到叢集執行 apply。整個發布流程都能由 Pipeline 串起來。

Pipeline 的 job 執行完就結束了。如果之後有人手動改了 Deployment，兩次發布之間的檢查與處理，就需要另外安排。

GitOps 由持續運作的 Controller 接手：定期取得 Git 裡的設定，和叢集比對，再按照設定的規則同步。Git 宣告的內容就是「期望狀態」，叢集裡的設定偏離它時，就稱為設定漂移。OpenGitOps 原則

GitLab Pipeline 也可以用 Scheduled pipelines 定期檢查或部署。採這種方式，團隊就要安排好比對、修復與失敗通知的 job。

同一個 v2，三種部署路徑

假設 v2 的 image 已經建置完成，YAML 的變更也通過審查，接著就要把它部署到叢集。

• GitLab Pipeline CD：部署 job 取得設定，執行 Kustomize、Helm 或其他部署指令，把服務更新成 v2，再執行驗證。Runner 可以直接連 Kubernetes API，也可以透過部署主機執行指令。
• Carvel GitOps：建立 kapp-controller 的 App，指定 Repo、分支或版本、目錄與處理方式。取得 v2 的設定後，依 fetch → template → deploy 執行，也就是取得來源、產生 YAML，再由 kapp 比對並部署，之後定期再次同步。Carvel App 規格
• Argo CD GitOps：建立 Application，指定 Repo、要追蹤的分支或版本、目錄與部署目標。Argo CD 產生 YAML，和叢集比對；有差異時顯示 OutOfSync，接著可以手動執行 Sync，或交給自動同步處理。Argo CD 架構

三種方式都可以使用 GitLab Repo。採 GitOps 時，GitLab 繼續負責 CI，像是測試、建置 image、上傳到 image registry，以及更新部署設定。Controller 則負責把設定送進叢集。

如果 Controller 追蹤 main，合併進去就可能開始部署；如果固定在某個 commit，發布時就要更新它追蹤的版本。正式環境可以透過分支、版本與審查規則，控制何時發布。

Argo CD 會自動把設定改回來嗎？

Argo CD 發現差異後，可以等人按下 Sync，也可以自動處理。依 官方文件，有三個設定要分清楚：

• Automatic sync：Git 來源有變更，而且和叢集有差異時，自動執行同步。
• selfHeal：搭配自動同步，當叢集裡受管理的設定被改掉時，也能觸發同步，把設定調回來源內容；預設關閉。
• prune：同步時，刪除已經從來源設定移除的受管理資源。自動同步預設保留這些資源，要另外啟用自動刪除。

剛開始導入時，可以先讓 Argo CD 顯示差異，由人決定何時同步。等流程熟悉了，再依需求開啟自動同步、修復與刪除。

Web UI 可以集中查看資源、設定差異與健康狀態。Synced 表示設定已同步；Pod 是否正常、API 能否使用，則由健康檢查與部署後測試來看。

Carvel 與 Argo CD 的差異

Carvel 和 Argo CD 都能持續讀取 Git。選擇時，可以看看目前用什麼工具產生 YAML，以及平常想怎麼查看部署狀況。

沿用 Day23 的 Kustomize overlays 時，Argo CD 可以把來源目錄指向 overlay，讀取 kustomization.yaml 並產生最後要部署的 YAML。Argo CD Kustomize

Carvel v0.57.x 的 App 內建 template 流程沒有 Kustomize。可以由 CI 先產生 YAML，存到 App 追蹤的來源，再交給它部署。這樣要一起管理原始設定與產生結果的版本。已經使用 ytt 或 Carvel Package 的環境，則可以沿用既有流程。

CD 更新成 v2，又被 Controller 改回 v1，會發生嗎？

會有這個可能。沿用剛才的例子，假設兩邊讀到的版本不同：

• Controller 讀取的設定仍然是 v1。
• GitLab CD 直接對同一個 Deployment 套用 v2，沒有更新 Controller 的來源。
• kapp-controller 下次同步，或 Argo CD 再次執行 Sync 時，就可能把受管理的 image 調回 v1。Argo CD 可以由人執行 Sync，也可以在開啟自動同步與 selfHeal 後處理這類變更。

Controller 會照它讀到的設定工作。來源還寫著 v1，它就會把 v1 當成要維持的版本。

所以 同一批資源要安排好由誰部署。採 GitOps 時，可以讓 Pipeline 更新 Git 裡的版本，再由 Controller 部署 v2。緊急手動修改時，也要安排好同步控制，並把變更補回 Git。

該怎麼選？

• GitLab CD 已經穩定：可以繼續沿用，把部署後驗證、定期檢查與異常處理安排好。
• 已使用 ytt、Carvel Package：可以評估 kapp-controller，將版本、客製設定與部署串成 App 的流程。
• 主要使用 Kustomize／Helm，也想集中查看多個應用程式：可以評估 Argo CD，透過 UI 管理差異、同步與健康狀態。

GitOps 的好處是 Controller 會持續比對與同步設定，變更也能透過 Git 審查、留下紀錄。要維護的東西則多了 Controller 升級、Repo 連線認證、部署權限與同步失敗時的問題排除。部署權限可以集中交給 Controller，CI 專心處理測試、image 與設定更新。

選擇工具時，可以從「目前最需要解決什麼」開始：把發布流程串起來、持續維持設定，或集中管理多個應用程式。接下來的 Day27 會看 Harbor 跨站 Image 同步，讓不同站點都能取得部署需要的 image。

參考資料

• OpenGitOps：GitOps Principles
• GitLab：Scheduled pipelines
• Carvel：App CR Spec
• Carvel：Package Management with GitOps
• Argo CD：Architectural Overview
• Argo CD：Automated Sync Policy
• Argo CD：Kustomize