ArgoCD 的規劃與實踐

Published in

iKala 技術部落格

9 min readJul 31, 2023

Ben 在 iKala MarTech R&D 擔任 Site Reliability Engineer(SRE)，
在本篇文章中，我將分享 KOL Radar 實作 ArgoCD 的重點介紹。

Background

What is GitOps ?

GitOps is used to automate the process of provisioning infrastructure, especially modern cloud infrastructure. Similar to how teams use application source code, operations teams that adopt GitOps use configuration files stored as code (infrastructure as code). GitOps configuration files generate the same infrastructure environment every time it’s deployed, just as application source code generates the same application binaries every time it’s built.
Reference: https://about.gitlab.com/topics/gitops/

GitOps 的核心概念有三個

基礎架構即代碼 (IaC)
版本控制
透過自動化 Pipeline 自動進行基礎架構上的更新

在這裡讓我們先簡單下個小結：

GitOps 是一種基於 Git 作為在基礎設施配置上 single source of truth 的一種 CI/CD 方法論。GitOps 使得基礎架構上的宣告可以如開發者的 code 一樣是可以被閱讀及追蹤，亦可以透過 Git 指令進行自動版本控制。

在搜尋各個 GitOps 的資料時，ArgoCD 往往會同時被提及，這讓我不禁好奇 ArgoCD 在 GitOps 當中的地位。

Why ArgoCD ?

ArgoCD 是目前實作 GitOps 不可或缺的一環

ArgoCD 是基於 GitOps 的一套工具，幫助使用者自動化部署應用程式到多個 Kubernetes 裡。但如果以操作 Kubernetes 的話並非 ArgoCD 不可，同時類似的方案有 Gitlab runner 、Github action 或是 Jenkins pipeline 或是同質性更高的 Flux 皆可做到自動化操作 Kubernetes 資源，但為什麼最終我們選擇使用 ArgoCD 呢？

有別於其他替代方案，ArgoCD 提供了一個簡單而強大的使用者界面，使用者可以輕鬆地以各種常見的 Kubernetes 宣告方式如 Helm、Kustomize 或 Jsonnet 配置並管理在 Kubernetes 裡的應用程式。此外，ArgoCD 還提供了一些高級功能，例如自動回滾和基於策略的部署，這些功能可以幫助使用者更好地掌握在 Kubernetes 裡的應用程式。同時，ArgoCD 也是 CNCF 推薦使用的 CD 工具 (畢竟是親兒子怎能不推呢？)。

Detail

完整的資源與權限管理

Project 與 Application 是 ArgoCD 最核心的兩個元件，為 ArgoCD 對於 Kubernetes 責管理權限與應用程式的生命週期上的實現。

以下是一個簡單 Project 與 Application 的設定

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
    name: kolradar-sample-project
spec:
    sourceRepos:
        - https://gitlab.example.com/kolradar/frontend-repo.git
        - https://gitlab.example.com/kolradar/backend-repo.git
    destinations:
        - namespace: 'dev'
          name: kolradar-dev
        - namespace: 'monitoring'
          name: kolradar-dev
    syncWindows:
        - applications:
            - '*'
          clusters:
            - '*'
          duration: 1h
          kind: deny
          manualSync: true
          namespaces:
            - dev
          schedule: '* * * * 6'
          timeZone: Asia/Taipei

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
    name: sample-service
    namespace: argocd
spec:
    project: kolradar-sample-project
    destination:
        name: kolradar-dev
        namespace: dev
source:
    helm:
        releaseName: sample-service
        valueFiles:
            - values-dev.yaml
    path: sample/service
    repoURL: https://gitlab.example.com/kolradar/backend-repo.git
    targetRevision: main
    syncPolicy:
        automated:
            prune: true
            selfHeal: true

此例子可以簡單帶到對於在導入 ArgoCD 到現實產品的最小化規模的實作：

對於 Project 在權限管理方面

以 sourceRepos 來限制 Application 的來源皆是來自於 kolradar/frontend-repo 或是 kolradar/backend-repo。
以 destinations 來限制 Application 會被部署在 kolradar-dev 的 dev 與 monitoring 中，以此框定 Project 的有效範圍，並且避免異常操作到系統使用的資源，如 kube-system
以 namespaceResourceWhitelist 來規範何種資源可以被 Application 建立，此功能主要是可以避免未預期的資源被建立。（ Zero Trust Policy ）

對於 Application 在應用程式在生命週期上的實踐

spec.destination 訂定此 Application 所宣告的資源皆會被部署在 kolradar-dev 的 dev 中。
source 宣告了此 Application 的資源是來自於 kolradar/backend-repo 下 sample/service 所宣告的 Helm Chart。
syncPolicy.* 可以客製化 Application 對於 Git repo 更新時，所採取的策略，如差異化更新，或是自動刪除未被宣告的資源。

需要特別注意的一點，所有 Application 皆會被匡列在單一個 Project 下（預設是 default ）因此 Application 需要無條件遵守 Project 所訂下的規則，讓我們從上面的 Application 來繼續延伸。

spec:
    project: kolradar-sample-project
    destination:
        name: kolradar-dev
        namespace: kube-system

如果我們將部署的 namespace 改為 kube-system 的話，則在 sample-service 實際部署時，則會出現類似的錯誤訊息

Unable to create application: application spec for sample-service is invalid: InvalidSpecError: application repo ... {https://kubernetes.default.svc kube-system} is not permitted in project 'kolradar-sample-project'

對於 ArgoCD Project 管理 Application 的原則，筆者建議採取最小化授權，尤其是在操作正式環境進行更新時。沒有人希望在正式環境中發生未預期的人為疏失，因此適當的權限設定可以幫助我們安全地進行更新。

至於大量重複的 Application 宣告，ArgoCD 提供了 ApplicationSet 的解決方案，礙於篇幅就請有興趣的人自行點選連結去研究啦～

Conclusion

在 KOL Radar 導入 ArgoCD 最大改變是可以用非常顯而易見的方式觀測在我們在 Kubernetes 上所有服務的狀態，幫助運維人員與開發者更直觀地查看應用程式的狀態（包括部署內容和網路架構）。

我們也可以在 ArgoCD UI 上觀察各個應用程式（Application）的健康狀態（Health Status），並追蹤異常的 Kubernetes 資源。例如，如果 Pod 發生 crashloopbackoff，應用程式的健康狀態會變為 Degraded；如果 Kubernetes 資源被異常刪除，應用程式的健康狀態則會變為 Missing。