快速閱讀導引 - Kargo 是什麼？GitOps 時代的 Continuous Promotion 引擎」實現 AI 規劃與 RPA 穩定執行
如果您正在尋找實現高效、安全的 Kubernetes 多環境版本控制，並希望真正簡化您的 CI/CD 交付流程，那麼由 Argo 專案原班人馬（ Akuity 團隊 ）打造的開源 Continuous Promotion（持續推進） 工具 Kargo，將是您的關鍵解答。
如果說 ArgoCD 解決的是「Git 到單一環境的一致性」，那麼 Kargo 解決的就是「版本在多個環境之間的旅程」，專門負責管理應用程式版本在多個環境之間的有序流動——從開發( dev )、測試 (staging) 一路推進到正式環境 (production)。
新版本什麼時候可以進 staging？通過了哪些驗證才能上 production？誰按下了核准？在 Kargo 的世界裡，這些問題都有宣告式的答案，而且每一步都記錄在案。
圖片來源：Kargo 官方文件
為什麼需要 Kargo？解決 GitOps 部署自動化後的「升版」最後一哩路
部署自動化了，為什麼「升版」還留在人工時代？
導入 ArgoCD 之後，雖然實現了「Git 到單一環境的一致性」與自動部署。但多數團隊很快會發現：「部署」自動化了，「升版」卻還在人工時代。 這個缺口，可以從三個面向來看：
環境管理：版本狀態散落各處
• dev、staging、production 各有一份 manifest，可能放在不同資料夾、不同 branch，甚至不同 repo。
• image tag 散落在各個 kustomization.yaml 與 values.yaml 之中。
• 想回答「現在 staging 跑的是哪一版？跟 production 差了幾個 commit？」往往得翻 Git log、比對 tag，靠人腦拼湊全貌。
自動化跨環境：CI 承擔了不屬於它的職責
• 升版通常靠兩種方式：人工發 PR 修改 image tag，或是把 promote 邏輯寫進 CI pipeline（如 Jenkins、GitLab CI）。
• 在 CI 裡疊加一段又一段的 shell script 用以改 YAML、commit、push、等待 sync，最後 promotion 邏輯成為藏在 pipeline 深處、沒人敢動的技術債。
• CI pipeline 解耦勢在必行：CI 的本份是「把程式碼變成產出物（image）」，而不該承擔跨環境的決策。
護欄 (Guardrails)：缺乏統一的關卡機制
• 當推進靠人工與腳本，就沒有一致的守門規則，版本可能跳過測試直上正式環境。
• 難以回答稽核與合規最關心的問題——「是誰、在什麼時候、把哪一個版本推上了 production？」
Kargo 的核心解答：將「推進 (Promotion)」升格為一等公民
用宣告式的方式定義版本流動的路徑、通過的條件與人工關卡，讓升版跟部署一樣——可控、可追溯、可自動化。
Kargo 核心概念 : 三大 Kubernetes 自訂資源 (CRD) 運作機制
Kargo 的整個推進模型，由三個 Kubernetes 自訂資源 (CRD) 構成。理解這三個關鍵物件，就理解了 Kargo 的運作方式 :
Kargo 核心三大物件關係圖 : Warehouse 監控、Freight 版本快照與 Stage 環境節點架構圖 (圖片來源：Kargo 官方文件)
1. Warehouse (倉庫) —— 偵測來源、生成貨物
Warehouse 負責「監看」。它訂閱一個或多個產出物來源—— container image registry、Helm chart repository 或 Git repository。一旦偵測到新版本(新的 image tag、新的 chart 版本、新的 commit)，就會產生一筆新的 Freight。
2. Freight (貨物) —— 封包版本快照的最小單位
Freight 是 Kargo 推進的最小單位。它是一組「版本快照」的集合：可能包含一個特定的 image digest、一個 chart 版本、一個 Git commit。可以把它想像成一箱貼好封條的貨 : 箱子裡裝了什麼、從哪裡來，清清楚楚；推進的過程中內容不會被調包。
3. Stage (環境節點) ——定義收貨、推進步驟與自動驗證
Stage 對應一個環境節點 (例如 dev、staging、prod)，定義三件事：
- 收什麼貨、從哪裡收：接受哪個 Warehouse 的 Freight？必須先通過哪個上游 Stage？
- 怎麼推進：收到貨之後，執行哪些步驟把變更落實到 Git？
- 怎麼驗證：推進完成後，跑什麼測試或檢查來確認這一版沒問題？
多個 Stage 串連起來，就構成一條版本推進的 Pipeline：Warehouse 產生 Freight，Freight 依序流經各個 Stage，每一站都有明確的進入條件與驗證關卡。
圖片來源：ArgoCD 官方文件
Kargo 五大核心功能導覽：從 Pipeline 視覺化到人工治理
Pipeline 視覺化拓樸圖
Kargo UI 以拓樸圖呈現整條推進管線：直覺化展示每個 Stage 目前跑的是哪一筆 Freight、健康狀態如何、哪些 Freight 正在排隊等待推進，一眼掌握所有環境的版本全貌。「staging 現在是哪一版」不再需要翻 Git log。
圖片來源：Kargo 官方文件
Promotion Steps：宣告式的推進步驟
每次推進 (Promotion) 由一連串步驟組成，Kargo 內建了常用步驟，包括：
git-clone：取得存放 manifest 的 GitOps repo
kustomize-set-image / yaml-update：更新 image tag 或任意 YAML 欄位
git-commit / git-push：提交變更
git-open-pr / git-wait-for-pr：改用 PR 流程，等待人工審核合併
argocd-update：觸發 ArgoCD 同步對應的 Application
圖片來源：系統操作畫面截圖
Verification：自動驗證與 Soak Time
Stage 可以掛上驗證流程 (整合 Argo Rollouts 的 AnalysisTemplate )：推進完成後自動執行整合測試、呼叫 HTTP 端點檢查、查詢 Prometheus 或 Datadog 等監控指標。驗證不通過的 Freight，不具備推進到下游 Stage 的資格——這是護欄的第一道具體實現。
另外，Stage 還可以設定 Soak Time (浸泡時間)：要求 Freight 必須在上游環境穩定運行滿指定時長 (例如 24 小時)，才能繼續往下推進。
Manual Approval：關鍵環境人工審核
不是所有環境都適合全自動。對 production 這類關鍵環境，可以要求人工核准後才執行推進——在 UI 上一鍵批准並留存完整紀錄 「誰、在什麼時候、核准了哪一版」全部留有紀錄。自動化與人工治理，在同一條管線裡並存。
Freight 溯源追蹤：從 production 一路追回 commit
點開任何一筆 Freight，可以看到它包含哪個 image digest、對應哪個 commit、通過了哪些 Stage 的驗證、每一站的推進時間與操作者。當 production 出現問題，「這一版到底是什麼、怎麼上來的」不再需要考古。
圖片來源：系統操作畫面截圖
一份 Stage YAML 解析：來源、目標、步驟、分析
下面用一個簡化的 Stage manifest，標示 Kargo 推進模型的四個重點：
apiVersion: kargo.akuity.io/v1alpha1
kind: Stage
metadata:
name: staging
namespace: my-project
spec:
# 【來源】收哪個 Warehouse 的貨,且必須先通過上游 test Stage
requestedFreight:
- origin:
kind: Warehouse
name: my-warehouse
sources:
stages:
- test
# 【步驟】推進時的動作:改 Git,而不是直接改 Cluster
promotionTemplate:
spec:
steps:
- uses: git-clone # 取得 GitOps repo
- uses: kustomize-set-image # 更新 staging 的 image tag
- uses: git-commit # 提交變更(Git 留下完整紀錄)
- uses: git-push
- uses: argocd-update # 【目標】觸發 ArgoCD 同步 staging 的 Application
# 【分析】推進後自動驗證,不通過就沒有資格往 production 走
verification:
analysisTemplates:
- name: integration-test 這份 YAML 有一個關鍵細節值得放大：Kargo 推進時修改的是 Git，而不是直接對叢集下指令。 kustomize-set-image 改的是 GitOps repo 裡的 manifest，實際讓變更生效的仍然是 ArgoCD 的同步機制。
換句話說，Promotion 這件事本身也遵循 GitOps —— Git 依然是唯一的事實來源，Kargo 只是那個「代替你發 commit 的自動化角色」。每一次升版，都在 Git 歷史裡留下完整軌跡。
Kargo × ArgoCD 黃金組合：完美解耦 CI/CD 交付鏈
Kargo 不是要取代 ArgoCD，而是站在它的上面，補上多環境推進這一層。兩者的分工非常清晰，構築成強大的黃金組合：
CI(Cloud Build / GitLab CI )
└─ 建置並推送 image 到 Registry
└─ Warehouse 偵測到新版本,產生 Freight
└─ Kargo 依 Stage 定義推進:修改 GitOps repo(commit)
└─ ArgoCD 偵測 Git 變更,將叢集收斂至期望狀態 - CI (如 GitHub Actions / GitLab CI) ： 負責「把程式碼變成 image」並推送至 Registry。
- Warehouse (Kargo)： 偵測到新版本，產生 Freight。
- Kargo (Continuous Promotion)： 負責決定「哪一版、在什麼條件下、進到哪個環境」，並將決定寫入 Git（Commit/PR）。
- ArgoCD (Deployment)： 偵測到 Git 變更，自動將 Kubernetes 叢集實際狀態收斂至與 Git 一致。
透過此架構，CI 回歸單純，CI pipeline 解耦得以實現，promotion 邏輯從 pipeline 腳本中解放出來，部署引擎則維持不變。三者各司其職，構成完整的 GitOps 交付鏈。
延伸閱讀：想深入了解 ArgoCD 的核心機制與 GitOps 四大原則，歡迎參考 ArgoCD 是什麼? GitOps 時代的 Kubernetes 部署引擎
從開源到企業級：Akuity Kargo Enterprise 與 AI 風險評估
開源版 Kargo 已足以支撐完整的 Continuous Promotion 流程，而對於規模化與重視合規的企業環境，Akuity 提供了 Akuity Kargo Enterprise，帶來多項企業級強化：
內嵌 Argo CD 可視性
在 Kargo 的介面中直接掌握 Argo CD 的部署狀態，推進與部署兩層資訊在同一個視圖收攏，減少工具間的切換成本。
Akuity Kargo Enterprise 提供的 AI 風險評估 Promotion Advisor 介面截圖
(圖片來源：系統操作畫面截圖)
Promotion Advisor：升版前的 AI 風險評估
這是 Akuity Intelligence 整合在 Kargo 推進流程中的 AI 能力：在你按下核准之前，自動分析這次 Freight 的版本差異，產出變更摘要與風險評估 (Risk Assessment)。人工核准的關卡依然存在，但按下按鈕的人，手上多了一份 AI 整理好的判斷依據，讓手動核准決策更具備科學依據。
(圖片來源：系統操作畫面截圖)
想更深入了解 Akuity 平台的完整定位與企業導入場景，歡迎參考
Akuity 是以 Argo CD 為核心的企業級 GitOps 平台，協助團隊管理 Kubernetes 部署、版本推進、多叢集治理、權限控管與稽核紀錄，大幅降低設定漂移與人工部署風險，是現代化軟體交付的最佳解決方案。立即了解如何透過自動化部署與 GitOps 策略，提升企業開發敏捷度並確保環境安全一致。…【立即閱讀】
羽昇專家觀點
多數團隊導入 GitOps 之後，部署確實自動化了，但「版本推進」往往還停留在人工發 PR 與 CI 腳本硬撐的階段——這正是事故與稽核缺口最常發生的地方。
Kargo 補上的就是這最後一哩路：它把推進變成宣告式、有關卡、有紀錄的一等公民，而且推進本身依然透過 Git 完成，完全不破壞既有的 GitOps 架構。
對已經在使用 ArgoCD 的團隊來說，Kargo 是最自然的下一步——不需要更換部署引擎，只是把散落在 CI 腳本與人工流程裡的升版邏輯，收攏成一條看得見、管得住的管線。而對於有合規需求、需要變更管理整合或希望在升版前獲得 AI 風險評估的組織，Akuity Kargo Enterprise 提供了從開源平滑升級的路徑。
如果您的團隊正在面對多環境版本管理的混亂、CI pipeline 中越疊越厚的 promote 腳本，或是需要為升版流程建立合規關卡，羽昇國際提供專業的 Akuity / Kargo 解決方案諮詢，協助您評估最適合的 Continuous Promotion 架構。
Kargo 常見問題 (FAQ)
不會，兩者是互補關係。ArgoCD 負責「單一環境的部署」——確保叢集狀態與 Git 一致；Kargo 負責「多環境之間的推進」——決定哪一版、在什麼條件下、進到哪個環境。Kargo 推進時修改的是 Git，實際部署仍交由 ArgoCD 完成，兩者合作構成完整的 GitOps 交付鏈。
管理的維度不同。Argo Rollouts 處理的是「單一環境內」的漸進式發布——（如金絲雀、藍綠部署、流量逐步切換）；Kargo 處理的是「跨環境」的版本推進——從 dev 到 staging 到 production 的旅程。兩者可以同時使用，Kargo 把版本推進到某個環境後，該環境內部再由 Rollouts 執行金絲雀發布；Kargo 的 Verification 也直接沿用 Rollouts 的 AnalysisTemplate 機制。
可以。Kargo 的核心動作是「修改 GitOps repo」，只要您的部署工具會依據 Git 狀態同步叢集，Kargo 就能與之協作。不過 Kargo 與 ArgoCD 出自同一團隊，提供 argocd-update 等原生整合步驟，搭配 ArgoCD 使用的體驗最為完整。
恰好相反，Kargo 的效果是「解耦」，CI 回歸本份——建置與推送 image，所有升版邏輯（改 manifest、開 PR、等驗證、推下一環境）從 CI 腳本中抽出，交給 Kargo 以宣告式方式管理。CI pipeline 通常會因此變得更短、更單純，也不再與特定 CI 工具綁定。
開源版已具備完整的 Continuous Promotion 能力：Warehouse / Freight / Stage、Promotion Steps、Verification 與人工核准。Enterprise 版針對企業需求加值：Terraform / OpenTofu 基礎設施推進、ServiceNow 變更管理整合、內嵌 Argo CD 可視性、更強的存取控制，以及 Akuity Intelligence 的 Promotion Advisor——升版前的 AI 風險評估與變更摘要。同時由 Akuity 官方託管與支援，免除自行維運的負擔。