這是第三十天，作為完成鐵人賽的最後一篇文章，作者要分享的是關於 ArgoCD 的一些有趣的問題。ArgoCD 是常見的 GitOps 解決方案，這邊選了三個有趣的主題。
這篇文章不會討論：
ArgoCD 是什麼
GitOps 是什麼
這篇文章會討論：
不同規模的 Kubernetes，ArgoCD 的架構選擇
CI/CD 以及 GitOps 的關係
如何管理 Resources 以及 Application 之間的關係
ArgoCD 最常見的佈署架構是單體式架構，用一個 ArgoCD 管理 Kubernetes，這樣的單體式架構方便管理以及安裝，但是隨者 Kubernetes 的規模擴大，會浮現出一些問題。
Privileged Service Account 擁有上帝權限：如果用一個 ArgoCD 管理多個 Kubernetes，意味者這個 ArgoCD 擁有多個 Kubernetes 的權限，這樣會有安全疑慮。
SPOF：ArgoCD 出事了，所有 Kubernetes 都無法變動。
Network Topology：為了讓 ArgoCD 可以連線到所有 Kubernetes，需要處理網路拓樸的問題。
由於單體式架構會有這個問題，所以另一個架構選擇就是：分散式架構。
典型的分散式架構就是在每一個 Kubernetes 都佈署一個 ArgoCD，這樣的架構解決了上述三個問題，分散式的 ArgoCD，每一個 ArgoCD 都只擁有自己屬於的 Kubernetes 權限，如果故障了也只有一個 Kubernetes 受到影響，也不需要連到外部的 ArgoCD 所以網路比較簡單。
而分散式架構會有以下問題
佈署平台式服務：沒有一個 ArgoCD 擁有所有 Kubernetes 的權限，所以在分散式架構下，佈署平台式服務需要仰賴每個 ArgoCD 自己去拉取平台服務，這樣的問題是：平台服務的變動是上到下的，但是觀察變動狀態需要進到每一個 ArgoCD。 這樣不一致的方向導致管理困難。
每一個 Kubernetes 都需要佈署一個 ArgoCD，多出了管理成本以及運行成本。
混合式架構就是有一個 Central ArgoCD 以及多個 Managed ArgoCD。混合式架構是一個暫時的名字，作者有取另一個名字，但是牽扯太深所以還沒準備好，所以就先暫時用混合式架構這種沒有意義的名字。
為了管理從中心到邊緣的變動，我們設計了 Central ArgoCD 來管理，而這個 Central ArgoCD 也只能變動平台服務，例如：Central ArgoCD 可以變動日誌或 Prometheus 的服務，但是不可以變動業務服務。這樣的安全設定可以利用 Global Project 讓 Central ArgoCD 只能變動正向表列出來的服務。
而 Central ArgoCD 佈署變動的方式有兩種：
Central ArgoCD 直接佈署變動到 Kubernetes
這樣的優勢是 Central ArgoCD 可以掌握所有的佈署狀態
問題是 Central ArgoCD 權限可以變動 Kubernetes，權限過大會有安全問題。
Central ArgoCD 佈署 AppProject 到 Edged ArgoCD
這樣的優勢是 Edged ArgoCD 可以掌握所有的佈署狀態
問題是 Edged ArgoCD 不是一致的，所以有可能出現部分 Edged ArgoCD 佈署失敗的狀況。
作者比較偏好後者的佈署方式，原因管理 Kubernetes 的人可以看到來自於 Central ArgoCD 的變動。
相較 Central ArgoCD，因為 Edged ArgoCD 的目的是滿足業務需求的變化，所以架構會比較複雜，主要有兩種佈署方式。
每一個 Kubernetes 都佈署一個 ArgoCD
這樣的架構比較一致，但是會多出許多管理成本，尤其是一個業務有多個 Kuberntes 情況
每一個團隊佈署一個 ArgoCD
這樣的架構可以保證每一個 Edged ArgoCD 都貼近業務需求，但是架構不一致性會變高，Central ArgoCD 很難瞭解到全貌。
作者比較偏好後者的佈署方式，但是管理成本高昂。
大規模的應用程式架構代表大規模的業務，所以不可能有一個架構符合所有人需求。請按規模選擇架構，單體式架構管理 3-5 個 Kubernetes 以及 100+ 應用程式之後就應該要考慮重構。
CI 是 Continue Integration，定義是：任何人在任何時間都可以用任何機器建置以及測試任何版本的應用程式，由於 CI 處理的是程式碼的變化，所以 CI 屬於線性複雜度。
CD 是 Continue Delivery，目的是交付程式碼到用戶，由於 CD 處理的是用戶的需求，所以面對的是現實世界。
為了確保用戶以及業務不受到變動失敗的影響，只要一個失敗就會停止 CI/CD，所以被稱為 Pipeline。
CI/CD Pipeline 是 synchronous，而 GitOps 屬於 asynchronous，這樣的不一致，需要有一個 Adapter 處理這樣的不一致。
常見的方式是用 ArgoCD workflows、GitHub Action 以及 GitLab CI/CD 來處理這個問題。
ArgoCD 背後的公司 Akuity 有推出 Kargo，也許是一個不錯的工具，但是作者沒有用過，就留給大家參考。
CI Pipeline 以及 CD Pipeline 的職責搞混，CI 處理的是程式碼的變化，CD 處理的是現實世界的問題，稍微複雜一點的應用程式，這兩條 Pipeline 需要分開思考。
IaC 的架構下，會用 Terraform 管理資源，用 ArgoCD 管理應用程式，但是有些變動，需要變動資源以及應用程式。
最常見的例子：
Terraform 創建完 EKS 後，馬上需要安裝 Metrics Server 以及 Prometheus。
Terraform 創建完 AWS KMS，馬上需要創建 Kubernetes 中的 External Secrets。
GitOps Bridge 是 Akuity 以及 AWS 提出的 Pattern，原理是在 Terraform 把 resource 相關的資訊放到 ArgoCD Manifest 中的 Annotation，以此讓 ArgoCD 可以使用 resources 相關的資訊。
這是 GitOps Bridge 的 Github
https://github.com/gitops-bridge-dev/gitops-bridge/tree/main
這是影片
https://www.youtube.com/watch?v=TrTRy8ahIHc
以上選了三個跟 ArgoCD 相關的有趣主題，由於 CI/CD 是符合業務以及組織需求，而 GitOps 以及 ArgoCD 也是個正在演化的技術，如果有什麼問題歡迎大家提出討論。
這是鐵人賽第三十篇，謝謝大家，這三十天會許多收穫，會再寫一篇文章與大家分享。
REF:
關於 ArgoCD 的架構：
https://akuity.io/blog/argo-cd-architectures-explained/\
關於 CI/CD Pipeline 以及 GitOps：
https://akuity.io/blog/why-ci-and-cd-need-to-go-their-separate-ways/
我從 CNTUG 的 Tony 得知 GitOps Bridge 這個 Pattern，感謝他的分享。
iThome鐵人賽
看影片追技術