Kubernetes Summit 2024 Keynote：104 在 GitOps 大規模實踐中的甜蜜與苦澀

本演講將分享 104 如何採用 GitOps 實踐來管理數量超過 1000 個服務與超過 10 座 K8s 叢集上所安裝的各種軟體。104 的 GitOps 實踐包含：使用了自製命令列工具、建立公版 Helm Chart、建立 Argo CD 部署流水線，這讓開發團隊能自主且快速部署服務到 K8s 平台上。

導入過程中，意外發現受益的不只是單純 Dev 或 Ops，它讓 104 多個開發團隊與維運團隊能以同一份 GitOps 組態設定為起點，就各自專業做溝通並討論改善作法，有效減低 Dev 與 Ops 之間的穀倉效應並促進合作關係。

但是，典型的 GitOps Mono Repository 容易因應用程式變多而快速膨脹，進而難以管理。本演講也將分享 104 如何應用 App of Apps 模式來克服，進而讓管理權責得以適當劃分。

Transcript

1. 104 在 GitOps 大規模 104 在 GitOps 大規模 實踐中的甜蜜與苦澀 實踐中的甜蜜與苦澀 104 資訊科技 軟體架構師 蘇曜祥 Oct. 24, 2024
2. Agenda Agenda Part 1：導入 GitOps 背景 Part 2：規模化實踐 Part 3：更好的 DevOps
3. 蘇曜祥 蘇曜祥 (Yao-Siang Su) (Yao-Siang Su) # yaosiang@me.com # Software Architect & Technical Manager # Cloud Native / DevOps # 104 K8s PM / PO
4. 104 資訊科技 104 資訊科技 從前後端分離進展到微服務架構 （容器快速變多） 。 2021 年導入 K8s。K8s 團隊由架 構團隊與少數 Ops 同仁組成。 Dev 跟 Ops 背景的人都有，但 Dev 人數較多。 混合雲架構 > 10 開發團隊 > 300 開發者 > 300 網站服務
5. 老闆一句要導入 老闆一句要導入 K8s，背後其實是 K8s，背後其實是
6. 老闆一句要導入 老闆一句要導入 K8s，背後其實是 K8s，背後其實是 建置與維運 K8s 平台，整 合多種 CNCF 工具。 協助 Dev 團隊做應用容器 化，部署到 K8s。 Prometheus、Grafana、EFK Argo CD、KEDA、Istio、 Vault、OPA Gatekeeper...
7. On-Premises On-Premises AWS AWS GCP GCP > 12 Clusters > 12 Clusters Ops 任務需求 Ops 任務需求 建立應用程式 Namespace 做好網路隔離與計算資源限制 配置儲存空間 PV 設定監控、日誌、告警相關配置 多租戶配置模式
8. 一開始只是不想 Configuration Drift 一開始只是不想 Configuration Drift 只用 kubectl 的話，改完就 忘記的狀況，註定會發生。 不同環境組態配置偏移產生 的坑發生太多次。 不同環境各有多組叢集，以 GUI 或命令列工具處理需求 難以規模化。 ref: https://openliberty.io/blog/2024/04/26/argocd-drift-pt1.html
9. ref: https://opengitops.dev/ GitOps 組成元素 GitOps 組成元素
10. Reconciliation Loop
11. 老闆一句要導入 老闆一句要導入 K8s，背後其實是 K8s，背後其實是 建置與維運 K8s 平台，整 合多種 CNCF 工具。 協助 Dev 團隊做應用容器 化，部署到 K8s。 PHP、Java、Python、Node.js Ubuntu、Debian、CentOS
12. Dev 任務需求 Dev 任務需求 建立 Deployment、Service 取個響亮的網域名稱 Ingress 儲存使用者上傳檔案 PVC 不是每人都想學 K8s Ops 任務需求 Ops 任務需求 建立應用程式 Namespace 做好網路隔離與計算資源限制 配置儲存空間 PV 設定監控、日誌、告警相關配置
13. ref: https://codefresh.io/learn/gitops/ GitOps Workflow GitOps Workflow
14. ref: https://codefresh.io/learn/gitops/ GitOps Workflow GitOps Workflow Desired State Current State
15. 混合雲架構 > 10 開發團隊 > 300 開發者 > 300 網站服務
16. Dev & Ops Team Scale Innovate Automate 如何設計更自動流 程，讓各角色規模 化使用？ 因視角與規模而問題 因視角與規模而問題 產生改變 產生改變 K8s 數量快速增長，如何讓 Ops 同仁不被維運任務淹沒？ 應用程式數量快速增長，如何讓 Dev 快速參與 K8s 導入並上線？ K8s 團隊是虛擬團隊，導入規模 變大會驅動組織 R&R 劃分，未來 如何促進跨團隊之間的合作？ Git、YAML、K8s ?
17. 2. 讓 Ops 工作有效率 3. 讓 Dev 快速進入 4. 讓 Dev 跟 Ops 能合作 先處理權責分離 1.
18. 規模化實踐內容 App of Apps Pattern 劃分 管理權責 使用一致的命 令列工具 高度整合的 Umbrella Charts 定期評估會議
19. 實踐ㄧ App of Apps Pattern 劃分 管理權責
20. ref: https://codefresh.io/learn/gitops/ GitOps Workflow GitOps Workflow Ops？ Dev？ Dev
21. Single GitOps Repo Multiple GitOps Repos 幾個 GitOps Repo？ 太多 Repos 難以追蹤的 Git History > 300 apps 借助康威定律
22. Argo CD Applications 以應用程式為單位，一個 App 對應一個 Chart Argo CD Applications 以 Team 為單位，收納團隊應用程式 Argo CD 追蹤的 GitOps Repo 約略等於 Team 數量 Team A App GitOps Repo Team B App Team C App Team A Repo Team B Repo Team C Repo Ops 管 Ops 管 Dev 管
23. Team A App Team B App Team C App Team A Repo Team B Repo Team C Repo AppSet 1 Dev 團隊的 GitOps Repo， 每個應用程式都是 Argo CD AppSet AppSet 2 AppSet 3 Argo CD Applications 以應用程式為單位，一個 App 對應一個 Chart 一個 ApplicationSet，對應到一個 Chart GitOps Repo Ops 管 Dev 管 Dev 管 Ops 管
24. Argo CD Applications 以應用程式為單位，一個 App 對應一個 Chart Argo CD Applications 以應用程式為單位，一個 App 對應一個 Chart Team A App Team B App Team C App Argo CD Applications 以 Team 為單位，收納團隊應用程式 一個 ApplicationSet，對應到一個 Chart Team A Repo Team B Repo Team C Repo AppSet 1 AppSet 2 AppSet 3 GitOps Repo Ops 管 Ops 管 Dev 管 Dev 管
25. Dev 團隊負責 自行建立 Argo applications 1. 設定 Helm Chart 的 K8s 組態 2. Dev 管
26. Ops 團隊負責 確保 K8s 叢集計算資源足夠 1. 建立 NS 及相關 resources 2. 設定 NS 資源配額與網路隔離 3. 設定 ArgoProject RBAC 4. 叢集差異用 Kustomize 修改 API Group 區分 K8s 組態 工具跟 Team Apps 拆開 Ops 管
27. Ops 團隊負責 確保 K8s 叢集計算資源足夠 1. 建立 NS 及相關 resources 2. 設定 NS 資源配額與網路隔離 3. 設定 ArgoProject RBAC 4. Dev 團隊負責 自行建立 Argo applications 1. 設定 Helm Chart 的 K8s 組態 2. 用起來像 Mono Repo， 實則權責分離的 Multiple Repo。 管制點
28. 目錄與版控經驗談 目錄與版控經驗談 各叢集高度相似關鍵在於以 base 目錄為基 底，差異之處以 Kustomize 修剪。 1. 避免產生循環依賴。 2. 避免過度倚賴 Auto Sync，保留人為介入空 間，當危機發生時不用跟 Argo CD 賽跑。 3. 設定 GitHub 分支保護避免故意略過 PR Review。 4. GitOps Repo 自己也得設定 CI，基本要做 Lint 跟 Kustomize Validation。 5.
29. 叢集標準化經驗談 叢集標準化經驗談 Public Cloud 常鼓勵做深度整合進而產生很 多不太像的叢集，結果得招募各雲專家。 1. 盡量讓每個叢集組件都長一樣，越無聊越標 準的叢集，才能讓 Ops Team 保持正能量。 2. 先讓 K8s 叢集只處理 stateless 應用， GitOps 會讓版本升級變簡單，兩小時內 Argo CD 能同步好幾百個組態設定跟應用。 3.
30. 機敏資訊管理經驗談 機敏資訊管理經驗談 Ops Team 管理的 GitOps Repo，機敏資訊 用 bitnami sealed-secret 已經夠用，但 Dev Team 的機敏資訊不能這樣幹。 1. Dev Team 管理的 GitOps Repo 建議用 HashiCorp Vault 放機敏資訊，但需做好 RBAC 跟 Path 規劃。 2. sealed-secret private key 千萬要備份。 3. 若能搭配 HNC 或 accurate 來派送 image- pull secret 等重複組態，管理上會更愉快。 4.
31. 實踐二 使用一致的命 令列工具
32. Ops 團隊負責 確保 K8s 叢集計算資源足夠 1. 建立 NS 及相關 resources 2. 設定 NS 資源配額與網路隔離 3. 設定 ArgoProject RBAC 4. 都在處理放在 Git Repo 的 YAML 檔 多租戶配置模式
33. 人工 >30mins 人工 >30mins 內容可能出錯 內容可能出錯 超過 10 PR 才做對 多租戶配置相關資源
34. App of Apps Pattern 易產生複雜目錄結構，新進同仁 需要時間熟悉，手工調整易出錯。 1. 只熟悉 kubectl 同仁常會忘記補上組態異動。 2. Ops 端痛點 Ops 端痛點
35. goam (GitOps Application Manager) goam (GitOps Application Manager) 收納各種任務
36. Dev 跟 Ops 使 Dev 跟 Ops 使 用工具一致 用工具一致 應該是用 Operator＋CRD 來處理各種維運任務才是貼 近 K8s 世界作法。 這個技術決策的理由是希望 Dev／Bot 也用一樣工具。
37. Ops YAML Bot Ops 需求由機器人處理 Ops 需求由機器人處理
38. 開發者提出申請 1. 2. 管理團隊審核
39. 3. 機器人發 PR 4. 合併後同步
40. < 10mins < 10mins 不會出錯 不會出錯
41. 經驗談 經驗談 人工製作 YAML 會產生的 Bug 絕對會比你想像中 多，用工具產生 YAML 較為穩妥。 將 Dev 跟 Ops Team 需要規模化的任務，收納進 單一命令列工具，再用 GitHub Action Bot 做自動 化，投資回報巨大。 平均一個 NS 相關資源建立只需 10 mins，而 Ops 同仁只需耗費 30 secs 看 GitHub Issue。 需要規模化的任務可被工具高速處理，Ops Team 才能投注時間在技術學習成長上。
42. 實踐三 高度整合的 Umbrella Charts
43. ref: Production Kubernetes: Building Successful Application Platforms Dev Team 怎麼用 K8s？ Dev Team 怎麼用 K8s？ 把 Dev 團隊的應用程式包裝成 Helm Chart 1. 讓 Dev 團隊只做組態設定 2.
44. ref: https://medium.com/@agheelnair/simplify-application-deployment-and-management-with-helm-charts-da62428877fb Dev 使用 K8s 團隊釋出 的 chart K8s 團隊開發 chart， 隱藏大多數複雜度並設 立安全標準
45. 基本框架全依賴 dependencies （K8s 團隊開發） Chart.yaml web cronjob job
46. 只需設定 values.yaml Chart.yaml web cronjob job 基本框架全依賴 dependencies （K8s 團隊開發）
47. 預設值挑選過，能滿足 80% 場景， 保留彈性應對 20% 進階需求。 Reasonable Defaults Replicas 1. SecurityContext 2. PDB 3. ServiceAccount 4. ... 諸多組態 5.
48. 監控告警（Prometheus ） 高度生態系工具整合 高度生態系工具整合 機敏資訊（HashiCorp Vault） 自動擴展（KEDA） 加解密（AES） Service Mesh（Istio） 容器防火牆（SUSE NeuVector）
49. 直連面板減低認知負擔 直連面板減低認知負擔
50. Policy 避免誤用組態設定（OPA） Policy 避免誤用組態設定（OPA） > 19 Policies > 19 Policies
51. 將各種外部工具與系統狀態以聲明式方 式呈現： 自定義監控、告警 自定指標 autoscaling 外部資料庫連線 外部 DNS 整合 容器防火牆（OOC egress） Service Mesh 開關 映象檔掃描行為 ... 聲明式狀態是關鍵 聲明式狀態是關鍵
52. 自製 CRD＋Operator 第三方工具 CRD 整進 Chart 讓 Dev 設定
53. 開發者回饋 開發者回饋 這用起來很快很方 便，但我對 K8s 還 不熟，想要理解這 背後的黑盒子。 整合這麼多選項跟 開關，你們一定做 了很多事情！ 不好意思請問一 下，那個 XX 功能 在 web chart 裡 面有嗎？ 30 歲共用服務 Developer 40 歲 Data Engineer 35 歲手機團隊 Developer
54. 經驗談 經驗談 不是每種想做的整合都有 CRD 可用，自己定義 CRD 並實作 K8s Operator 的時機是有的。 1. 不要直接把第三方工具 CRD 拿來當 values 欄位 名稱，後續要換工具會很麻煩，儘量再做一層抽 象去定義它，例如：containerFirewall。 2. Umbrella Chart 容易越變越複雜，儘管是一堆 templates 也要把它當成程式碼看待，以各種軟 體工程實踐確保品質（單元測試及整合測試） 。 3.
55. 新增應用程式流程 (~1 h) 新增應用程式流程 (~1 h) 01 02 Dev 向 Ops 團隊申 請 K8s NS 資源。 Dev 用命令列工具 產生新的應用程式 的 Argo AppSet 及 Chart。 03 Dev 調整 Chart values.yaml 滿足 應用程式需求。 04 Dev 發 PR，合併進 GitOps Repo。通過 上線簽核流程後，讓 Argo CD 同步。 Ops 團隊審核申請， 機器人會產生相關 K8s manifests。
56. 2022 2023 2024 2025 0 50 100 150 200 Production Production Only Only
57. 導入現況 導入現況 13 K8s Clusters (1.29－1.30) 1336 Argo CD Applications (l/s/p) ~14 Dev Teams 100 Million Reqests (d) ~150 Prod Deploy (m)
58. 實踐四 定期評估會議
59. 依賴的資料庫 連線一目了然 Dev 團隊的部 署版本其它人 都看的到 Ops 團隊跟 Dev 討論監控指標跟 告警發送 NET 團隊易收 斂防火牆設定 應用程式越多，values.yaml 越千奇百怪 聚集在 Dev 的 聚集在 Dev 的 GitOps Repo GitOps Repo
60. 單一 Dev Team 有 10 個以上應用 程式很正常，技術棧通常很像，可 能都是 Java 或都是 PHP。 時間演進，不同時期的應用程式其 values.yaml 設定會逐步改善，但 也開始產生差異。 定期協助梳理差異，讓應用程式的 values.yaml 接近一致，認知負擔 會大幅減低。 聲明式狀態能整理 聲明式狀態能整理
61. Every Month for Each Team Every Month for Each Team
62. 回饋到給開發團隊的 K8s 手冊 回饋到給開發團隊的 K8s 手冊
63. 經驗談 經驗談 每月評估報告是良好溝通管道，Dev Team 可提需 求與疑問，或是合作討論監控與告警指標。 也是很好培養開發團隊學習使用各種面板的機會。 即便單一開發團隊的應用程式很多，但只要 values.yaml 相似，對 Ops Team 來說數量就沒那 麼多。
64. 更好的 DevOps 更好的 DevOps CD 是起手勢
65. DBA 團隊管理 資料庫連線等 機敏資訊 Dev 團隊的部 署版本其它人 看不到 Ops 團隊有自 己的監控面板 NET 團隊有自 己的防火牆設 定面板 組態資訊 組態資訊 四散各地 四散各地 看不到，不關心 沒全貌
66. 依賴的資料庫 連線一目了然 Dev 團隊的部 署版本其它人 都看的到 Ops 團隊跟 Dev 討論監控指標跟 告警發送 NET 團隊易收 斂防火牆設定 聚集在 Dev 的 聚集在 Dev 的 GitOps Repo GitOps Repo 看的到，引發提問
67. 01. 02. 03. 各種聲明式組態設 定聚集歸 Dev 管， Dev 通 常 需 要 建 議 （引發動機） 技能一致不見得是團隊， 技能一致不見得是團隊， 目標一致才是 目標一致才是 Ops 都是 Dev 團隊的事情 Ops 都是 Ops 團隊的事情 Dev 團 隊 對 商 務 指 標 熟 悉 ；Ops 團 隊 對系統指標熟悉 常見面板直接可以連 結，看同樣資訊來討 論事情
68. Day 2 才是改善的開始 關鍵是從 Monitor 產生 Plan CD 是起手勢 Right Sizing Custom Metrics Alerting Custom Metrics Autoscaling 需求提問 ...
69. 問 KEDA 做 autoscaling 問 container resource 設定 問監控告警 問 Index CronJob 我知道可以做 autoscaling，但我的 應用程式負載好像比較 跟 connection 數目有 關。這該怎麼辦？ 我看你們給的監控面 板，我的應用程式 CPU 好像沒那麼吃， 要調降 resource 該 怎麼做？ 我想設定當 500 錯誤 變多時，讓我們家的 Teams 頻道收到告 警，該怎麼做？ 我有排程程式，想要開 影分身 10 個一起跑， 這個該怎麼弄？
70. Collaboration as Enabling Team Collaboration as Enabling Team 不只是提供一個可用可 維運的 K8s 運行環境。 賦能開發團隊在 K8s 上 良好運行自己服務。
71. 減少手動操作錯誤 1. 資訊透明化且共享 2. 提升跨部門協作 3. 決策基於監控資料 4. 持續改善與優化 5. 資訊共享 資訊共享 彼此理解 彼此理解
72. Scale Innovate Automate Take Away Take Away 跨團隊看相同組態設定， 面板資訊 建立定期溝通機制 Bot 處理 Dev 資源請求 命令列工具產 出 Chart 骨架 Umbrella Chart 以 聲明式狀態整合外部 工具 權責分離降低 Ops 認知負擔 Reasonable Defaults 讓 Dev 快 速產出可部署 Chart Dev 管理聚集在 Chart 內的聲明 式狀態 定期溝通讓 Dev 跟 Ops 彼此賦 能來穩固合作關係