圖菱科技 SaaS 系統容器化最佳實踐
大家好，我是龔承明，在圖菱（成都）科技有限公司任職，主要負責公司的產品系統研發以及公司IT基礎設施的建設工作。本篇文章將為大家介紹下我司在採用 KubeSphere 平臺實現公司業務系統容器化過程中的一些心路歷程。
我司是一家面向網際網路線上模版網站的素材資源供應商，為客戶提供模版輸出以及系統化解決方案。幫助客戶輸出規範化的設計產品。
背景介紹
遷移平臺的雲原生之路
早在 2020 年之前，公司 IT 團隊規模比較小，開發還要兼職運維測試，太慘了~
發展初期，基本上由業務驅動開發。基於資源方面因素，所以在系統架構上首先是滿足功能使用，快速開發推出產品，系統架構建設也是基於阿里雲一步步從單體到多模組，再到微服務做演進。
公司初期業務方向是印刷類商品的私人訂製，滿足個性化的輸出的移動端應用，配套生產的供應的訂單管理系統，同時涉及到旅行行業，為旅行社提供定製線路設計的 SaaS 系統，模板海報的輸出系統，以及相簿等旅行社所需要的素材資源。
業務痛點
經過幾年發展，業務系統服務開始增多，基礎技術架構難以應付業務的快速變化，研發團隊也亟需合理的開發流程來支援後續管理。
我們將主要面臨困難進行了梳理，大致有以下幾點：
- 開發環境和生產環境不一致
在專案迭代過程中，有時出現開發環境和生產環境配置不一致的問題，導致生產系統和業務問題不一致。 - 無統一發布管理系統
初期由於各方面管理粗狂，缺乏自動化構建系統，版本功能完後，開發需要專門手動編譯，打包上線釋出，過程複雜還不好管理。 - 資源協調
雖然業務系統已經採用 SpringCloud 整體微服務化，但各個服務資源的分配卻無法協調。印刷服務在生成印刷檔案時需要佔用系統資源比普通業務系統高几倍，但又不是實時需要。之前都是專門用一臺機器來做，但其實這種不太靈活。所以亟需能自動擴縮容的方案。
方案選型
基於上述的痛點，結合自身業務系統，準備進行容器化改造。
最開始接觸 Kubernetes 時瞭解到官方提供的管理平臺，通過調研和嘗試了下後發現它只是管理 Kubernetes 容器的基本資訊，並不是簡單將業務放上去就能開箱即用，而涉及業務上的日誌平臺，監控系統，鏈路最終等基礎運維體系還需自己去引入管理，最後還是通過朋友公司他們的一些經驗建議使用一些整合的平臺解決方案，類似 Rancher, KubeSphere 等。
經過對比後決定採用 KubeSphere，主要基於以下幾點：
- Kubernetes 這塊全新的知識體系要掌握達到生產落地學習時間成本較高，對於我們應用性企業需要的是能簡單上手的產品。
- Rancher 側重於運維管理，學習成本相對較高；KubeSphere 偏向與業務應用為中心，更符合我們公司情況。
- Rancher 需要自己部署 Jenkins 等外掛；KubeSphere 在一些元件整合上做的較好，比如 DevOps 能做到開箱即用。而釋出部署是我們目前最迫切需要的。
- KubeSphere 是由國內青雲科技推出的產品，使用更符合國人習慣，而且完全開源。
實踐過程
已有硬體資源
公司整個業務基礎設施構建在阿里雲上，包括 ECS、資料庫和 OSS 儲存等。
6 臺 ECS 分佈如下：
- ECS-1～ECS-4：業務服務。
- ECS-5：測試機器。
- ECS-6：公司內部專案管理，包括 Bug 管理，Git 等。
我們主要將實施步驟成如下幾步：
- 搭建映象倉庫
在 ECS-6 上，搭建 Harbor 倉庫。提供公司業務容器應用的私有映象管理工具。
- 構建業務系統映象
對每個業務服務新增相應配置檔案 Dockerfile, 用於平臺流水線釋出時構建映象。
- 準備系統環境
系統環境主要是 Kubernetes 搭建，這裡主要考慮儲存和網路選型。
-
儲存
最開始考慮使用 Ceph，搭建 demo 使用後發現，如果和 Kubernetes 搭建於同一叢集環境，對資源還是有一定消耗。基於目前業務設計（基本上沒有有狀態服務需要涉及）、以及當前業務體量，最終採用相對輕量的 NFS 共享盤方式。
-
網路
Kubernetes 主流的網路外掛目前主要有 Calico 和 Flannel，我們參考社群的經驗，最終選擇了 Calico。
-
安裝 KubeSphere 平臺
KubeSphere 平臺是按照官網提供的文件基於 Kubernetes 搭建的。我們先最小化搭建，然後在使用的過程中再根據需要開啟一些所需元件。
KubeSphere 平臺在外掛安裝這塊的體驗比較好，只需要對配置檔案相應做調整就能很容易實現。
比如日誌平臺預設由 Elasticsearch 做儲存，但我們已經自建有 Elasticsearch 叢集，只需要調整 ks-installer 配置。
當然其中有可能會遇到一些問題，不過基本上 KubeSphere 社群上都能找到解決方案。
DevOps 實踐
CI/CD 釋出流程是這次改造的重點。
DevOps 專案是 KubeSphere 中的一個可插拔元件，提供了基於 Jenkins 的 CI/CD 流水線，支援自動化工作流，包括 Binary-to-Image (B2I) 和 Source-to-Image (S2I) 等。
KubeSphere DevOps 提供了開箱即用的 CI/CD 流水線，並通過圖形化方式降低了學習門檻，我們就直接對官網的示例進行改造，採用配置檔案基於流水線 Pipleline 構建和釋出。
- 環境區分
我們的環境對應的是 KubeSphere 中的專案，通過在流水線中指定對應配置檔案區分。
- 前端 Node 環境指定
由於 KubeSphere 平臺預設提供的 Node.js 版本和我們所需版本有差異，所以結合自己經驗對平臺 Node.js 環境通過 Jenkins 外掛方式進行了修改，後續流水線中指定對應版本即可。
說明：這種方式稍顯麻煩，可能通過在流水線中指定映象應該也能滿足，但還未實踐。
日誌採集這塊，KubeSphere 平臺提供了 FluentBit Operator，在叢集所有節點以 DaemonSet 執行，並統一部署配置了 Fluent Bit，同時查詢方式能滿足現有業務。只有 Elasticsearch 我們對接了自己的環境。
實踐效果
歷時差不多一個月時間完成基本業務系統容器化。
容器化後開發流程比之前有顯著改善：
- 我們直接通過 KubeSphere 不同企業空間下的專案(Namespace)來進行開發、測試與生產環境的隔離以及通過不同角色賦予不同企業空間的許可權做到細粒度的許可權管理。
- 版本上線基於 Kubernetes 的副本以及探針來控制，基本上能在不影響業務情況下做到隨時釋出。
- 公司基本架構走向自動流程化。
未來規劃
目前在服務網格這塊還在探索階段，服務治理（比如：監控指標，微服務流控）還是處於試用體驗階段。
後續隨著業務複雜度提升後，這塊還是希望能快速落地。儘量在 KubeSphere 平臺中實現服務治理，做到業務與技術分離。
一些期望：
- 雖然產品體驗上已盡力降低使用者門檻，但云原生這塊引入很多全新概念，單純靠引導，普通使用者還是難以駕馭。
- 如果咱們文件對產品功能點的實踐描述上以及專業概念解釋能再優化一些可能會更好。
- 同時也希望更多的人能參與到社群的維護，體會到開源的樂趣！
本文由部落格一文多發平臺 OpenWrite 釋出！