自己管理的 Kubernetes Cluster 已經十幾座了，而且會越來越多，為什麼有這麼多座呢？因為隨著組織的成長，就會開始有不同的部門，同部門內又會依照環境至少分成開發，測試以及正式三個 K8s Cluster，因此預期 K8s Cluster 的座數在未來只會增加不會減少；或許有人會想說怎麼不準備一個大 K8s Cluster 給大家一起共用就好？！但為了安全性和其他考量，最終還是決定維持多個 K8s Cluster 的模式，有興趣想要知道怎麼決定組織內該使用一座或是多座 K8s Cluster 的人可以參考 “這篇文章” 的利害分析 不同座 K8s Cluster 分別是給不同部門和環境使用，每座 K8s Cluster 一定都會有一些重複的東西需要去做設定，並讓維運人員去做後續的管理，例如 Prometheus, Ingress Controller…等，秉持著 Infrastructure as Code 的精神， 在這幾年管理 K8s Cluster 大致上可以分成三個時期： 在多年前 helm 剛被提出時，我們讓一個部門使用一個 Git Repository，在裡面透過資料夾結構安排，將不同的環境切開來，並且將 helm chart 放在 charts 的資料夾內，至於安裝套件間的相依性，雜七雜八需要注意的，就透過 makefile 和文件去補足 隨著需要管理的 K8s Cluster 越來越多，以及安裝的東西越來越複雜，所以開始研究類似 helmfile 跟 helmsman，這類型的工具有點像是在模仿 Terraform 的操作模式，並且可以把不同環境安裝時的組態都先定義好，也把 helm chart repository 都抽象化，套件之間的相依性也可以幫忙解決 但科技始終來自於惰性，雖然使用 helmfile 可以應付大部分的需求，但總是覺得不夠安全，也不夠自動化，所以這時候就將目光擺向的這篇要提的 GitOps 工具 大家對於 GitOps 的工具應該都很熟了，跟傳統部署最大的差異就是在於從 Push 改成 Pull 的模式，所以在安全性上比較好，因此在此並不是要介紹這三個工具，而是要討論他們 1) 適不適合用來管理多個 K8s Cluster 跟 2) 有沒有辦法做到 Multi-Tenancy Multi-Tenancy: 因為一個 Flux Instance 只支援跟單一個 Git Repository 同步，所以會需要多個 Git Repository 和多個 Flux Instance 來達成 Multi-Cluster: 透過監看同一個 Git Repository 中的不同資料夾，或是不同環境切分不同的 Git Repository 來達成 Conclusion: 算是三個裡面最簡單易用的，但自己覺得在整體管理和資源利用上不太完美 Multi-Tenancy: 原生就支援，利用 Project 的概念讓不同的應用程式可以對應到團隊上，算是很到位的解決方案 Multi-Cluster: 目前看到的做法是利用單一個 ArgoCD Instance 去存取外部 K8s Cluster 的方式來達成 Conclusion: 可以算是 Flux 的進化版，而且還擁有精美的 UI (雖然我有 CLI 就夠了XD)，而且原生支援 Multi-Tenancy，多個 Cluster 的管理也有，以安全性為考量的話，感覺可以拆成正式跟非正式環境兩套的架構 Multi-Tenancy：不支援 Multi-Cluster：可以透過 Environment Controller 去達成的樣子 Conclusion：Jenkins X 跟上面兩者最大的差異在於它包山包海，不像上面兩者只能做到 Continuous Deployment, 他使用 Tekton 達成 Continuous Integration，使用 Skaffold & Kaniko 建置 Container Image, ，使用 Lighthouse 實作 ChatBot…等，真得是要你命 3000 XD 他是一個野心超級大的專案，他其實跟 Jenkins 老爺爺一點關係也沒有，而自己只是先想解決多座 K8s Cluster 的設定管理問題，所以就先暫時不考慮這麼複雜的解決方案