← 回到筆記2025-07-07

Argo Helm Deployment

探討 ArgoCD 部署含 CRD 的 Helm chart 時如何處理順序，包含 SkipDryRunOnMissingResource 與 GVK、Discovery、RESTMapping 概念。

發佈 ~2 分鐘 #helm chart#argocd

前情提要

在準備 KCD 的演講時，發現當使用 ArgoCD 來進行包含 CRD 的 custom helm chart 部署時，不會像使用 terraform 一樣，遇到 dependency chart 裡面定義的 CRD 沒辦法與 helm chart 同時部署的問題。接著我懷疑是 helm chart 本身進行了 CRD 與 dependency helm chart 的部署順序處理，因此我將這個 custom chart 使用 helm 來進行部署，但結果也一樣，使用者必須先安裝完 dependency chart 裡的 CRD controller，才能安裝 CR instance。因此也就是 ArgoCD 會處理先部署 dependency helm chart，再進行 CRD 的部署，因此想研究看看 ArgoCD 是如何做到這件事的。

ArgoCD Sync Options

  • Reference Sync Options - Argo CD - Declarative GitOps CD for Kubernetes
  • 當同一次的 sync 裡面，如果有 CRD manifest 時，ArgoCD 會在那個 manifest 掛上 annotation: argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true，來避免遇到 the server could not find the requested resource 的錯誤
  • 判斷要 skip dry-run 前，ArgoCD 會進行的檢查步驟：
    1. 檢查該次 sync 中是否有 CRD manifest
    2. 用 Discovery 找 Mapping：同時它會去 Kubernetes API Server 做 “Discovery” (RESTMapping) 嘗試，看看每一個 manifest 的 GVK（Group/Version/Kind）能不能對上現有的資源類型
    3. 如果第二項回傳 No Matches 就會 skip dry-run

其他補充知識：CRD 發現與操作

  1. GVK: Group / Version / Kind
    • 定義：唯一識別 K8s 資源類型的組合（例：apps/v1, Kind=Deployment），對應於 yaml 中的 apiVersion: apps/v1 和 kind: deployment
    • 用途：Client 在建構或解析 resource 時，需要知道他的 GVK，才能對應到正確的 Go struct，以及在呼叫 Discovery 時，決定是否已有對應的資源類型可以使用
  2. API Discovery
    • 定義：Discovery API 是 k8s api server 提供的「發現」介面，會列出整個 cluster 中所有可用的 api group / version，和他們 GVK 下面的所有 resource name 等等
    • 用途：動態獲取當前叢集的資源結構與可用版本，進而在執行 CRUD 操作前，確認某個 GVK 是否存在，以及應該對應到哪個 HTTP 路徑與動詞。這可避免對不存在的資源呼叫 API，引發錯誤
  3. RESTMapping
    • 定義：是一組映射資訊，可以將 GVK 對應到 GVR、URL 路徑、namespace 範圍（或 cluster 範圍），在 Discovery 時會建立這個表
    • 用途：Controller / Operator / Client 在拿到 GVK 時，必須透過 RESTMapping 找出 https 路徑，以及該資源位於哪個 namespace，才能對資源做 CRUD
← 回到筆記