Multi-Tenancy Kubernetes Cluster Part 2: 小孩子才做選擇？我全都要！
Background
在上一篇 “Multi-Tenancy Kubernetes Cluster Part 1: 認命吧！有一好，就沒兩好！” 提到目前 Hard Multi-Tenancy 在 Kubernetes 並沒有一個成熟的方案可供選擇，而 Single-Tenancy 又不切實際，因為這樣會造成需要管理的 Cluster 大暴增，那該怎麼做比較好呢？結論就是…把 Enhanced Soft Multi-Tenancy 跟 Multi-Cluster 做結合！架設方式使用行星系統模式，可以想像成是我們生活的太陽系，每一個星球都是一座 K8s Cluster，中間的太陽類比成一個負責運行共用服務的 K8s Cluster ，而應用服務則是根據實際需求運行在其他的 K8s Cluster 中 (如上圖)
具體來說中心的 K8s Cluster 需要具備什麼功能呢？主要有三大類，分別是組態管理，監控與告警，Logging 跟分析
而要怎麼去做 Cluster 的切割呢？自己至少會建立兩個行星系統，一個給生產環境，另外一個給非生產環境，至於在對應行星系統內 K8s Cluster 要怎麼在做切割呢？這就要看實際需求了，例如某些服務特別重要是公司的金雞母，或是對於安全性要求特別高，那就可以考慮將這些服務運行在獨立的 K8s Cluster 中
既然已經確定我們目前必須要與 Kubernetes Multi-Cluster 的環境共存，所以接下來文章就會開始談到怎麼去對一群 K8s Cluster 去做組態設定，並且去監控他們，如何把他們的 Log 集中化收集，最後談到有沒有機會集中管理這群 K8s Cluster
Configuration Management
想想看最近很紅的 Log4j Security Vulnerability，大家一定或多或少都有遇到，假設這些有需要升級的服務運行在多個 K8s Cluster 中，你要怎麼去做升級，而且還是一而再再而三的發生，目前比較大條的 CVE 已經三個了，希望不要再有第四個，而且 K8s 其實需要安裝跟設定的東西滿多的，就算沒有 Log4j 需要補，在日常維運時也有很多的變更需求會一直出現，所以 K8s 是需要有個東西來幫忙做組態管理的，畢竟組態管理的優點很多，例如不再需要去維護容易過時的設定文件，增加工作效率，降低人為錯誤與變更風險…等
在此讓我們先緬懷上一代的 Configuration Management
然後來歡迎新一代的 Configuration Management，啊！不能說 Configuration Management 這樣不好行銷，要改成說 GitOps 這樣才潮，但我自己個人認為其實都是想要完成一樣的事情
因為自己覺得 K8s Cluster 好像跟傳統的 Server 滿像的，只是以前底層是 Linux 作業系統，現在變成 K8s Cluster，然後 Binary 檔案變成 Container Image, 在 etc 資料夾底下的組態變成 K8s 各式資源跟 CRD，而以前使用 apt, yum 去做套件管理變成 Helm, Kustomize 等工具，而上一代的 Configuration Management 對應到現在就變成 GitOps 工具了
在 GitOps 解決方案的選擇上要注意有沒有支援 Multi-Tenancy 跟 Multi-Cluster，然後是不是使用 CRD 來定義各種組態，最後當然最重要的就是社群的活躍度夠不夠，目前贏家是 Argo CD, 而我自己是覺得 Flux 2 的設計觀念很棒 (有興趣可以參考之前分享的文章 “利用 Flux2 為 Kubernetes 達成 Configuration Management”)，Rancher Fleet 比較晚才推出，聽說還不太穩定
後來自己選擇導入 Argo CD，因為搭配他後來推出的 ApplicationSet Controller，可以達成高效率且安全管理多個 Cluster 的需求，而且在單個 Cluster 內也可以很輕鬆一次安裝很多的應用程式，除此之外，他也是目前社群相對活躍的一個，畢竟開源專案，還是選擇比較多人用的比較安全一些，有興趣的人可以參考之前分享的文章 “Argo CD ApplicationSet Controller: 世界為我而轉動！” 雖然自己是 Terminal 愛用者，但他友善的 UI 管理介面連我都被吸引，可以讓對於 K8s 沒那麼熟稔的人也可以輕易上手
Monitoring
把 K8s Cluster 安裝好後，接下來就要看該如何來監控他，毫無懸念，直接選擇使用 Prometheus Stack, 而且一定要使用有包含 Prometheus Operator 在其中的版本，因為這樣一來在管理 Prometheus 的設定上可以透過 CRD 達成，也可以無痛直接整合 Thanos，把 Prometheus Stack 架設在 Multi-Cluster Cluster 中有很多種做法，大家可以直接參考文章 “Kubernetes Multi-Clusters Monitoring With Prometheus & Thanos”，裡面很仔細的分析我自己使用過的三種監控多個 K8s Cluster 的架構，以及每一種架構的優缺點，跟在架設中常遇到的問題
Logging
監控功能也搞定了，接下來就看怎麼收集跟管理 Log 了，ElaticSearch 佔據市場龍頭已久，最近 Grafana Lab 有派出挑戰者 Loki，上圖為兩個解決方案的比較表，結論就是要省錢就選 Loki，要方便好用就選 ElasticSearch，因為 ElasticSearch 提供的是搜尋引擎的功能，他會對 Log 的內容做 Index，所以在後續的分析使用上強大很多
而自己並不是使用 Elastic 公司的 ElasticSearch，而是使用 AWS Fork 出來的 OpenSearch，主要是因為他把滿多付費功能下放到開源版本中，例如開源版就有 Authentication & Authorization 的功能，所以從兩年前就開始使用，而要使用的人有些小事需要注意，例如他是使用 ElasticSearch 7.10.2 的版本修改而來，必須要在 Logstash OSS 版本安裝 OpenSearch Output Plugin，而可以讓成本大幅下降的 UltraWarm 功能在開源版本中目前並沒有提供，我有另外寫兩篇文章，有關於自己這幾年來，如何一路從自建機房的 ElasticSearch 移轉到雲端的自建 OpenSearch，以及要怎麼去簡單的調教 ElasticSearch 這個吃資源的怪獸
目前收集的 Log 量，頂多到 TB 等級，所以架構上沒有很複雜，就是透過 Elastic 的各種 Beat 把資料送到 Redis，然後 Logstash 去 Redis 拉取 Log 後送到 OpenSearch 儲存以供後續使用，而 OpenSearch 也有提供 Index Lifecycle 的管理功能，自己會將 K8s 內應用服務，跟底層 Log 分開來存放在不同的 Index 中，假如 Log 量很大的話，可以再考慮要不要切分的更細，然後再針對不同的 Index 看看多久之後變成唯讀，然後多久之後要備份到 AWS S3 中不同類型的的儲存方案，過個幾年再把資料刪除掉
Management
最後則是有關於管理的需求，既然有這麼多的 Cluster 跟事情需要心力維護，那有沒有一個地方是可以管理所有事情的？這個平台需要可以協助組態設定，方便管理，例如視覺化 K8s 資源，監控，查看 Log，讓 Service Mesh 使用起來更簡單，而且要有權限控管機制，協助升級..等，底下列上目前市場上比較多人討論的解決方案，自己目前還沒有真的使用到生產環境中
不過假如要選的話，自己會推薦選擇使用 Rancher，因為他完成度滿高的，使用的人也多，而且整個生態系也很完整，感覺這可以是另外一個主題了，應該要再寫另外一篇文章來介紹
Conclusion
以上就是自己對於 Kubernetes Multi-Cluster 管理上的一些經驗分享，從為什麼會需要 Multi-Cluster，如何去對一群 K8s Cluster 做自動化的組態設定，怎麼去監控與收集分析這一群 Cluster，最後在稍微中心化管理的方式，假如有更厲害的工具或是採坑經驗，歡迎留言一起討論！
