ArgoCD 的規劃與實踐
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
。
我們也更進一步使用 ServiceMonitor 使 ArgoCD metric 可透過 Grafana 觀測,因此當發生異常時,可藉由 Grafana alerting 機制通知相關人員做後續處理。