作者 | 盧興民 紅亞科技CTO

背景

青椒課堂是紅亞科技推出的理實一體化授課平臺，面向資訊科技類專業提供教學實訓服務。隨著專案的迭代，從單體應用演化成為主站 + 資源排程服務（多可用區/客戶混合部署）的架構。

在完全使用 KubeSphere 之前，由於我們的副本只在北京有一個叢集，所以沒有考慮用一個更方便的形式去部署多個叢集，當時專案使用視覺化 PAAS 平臺來進行應用管理，這種形式極大地降低了團隊接觸上手 Kubernetes 的門檻，使得團隊可以快速上手使用容器平臺，但隨著業務使用的深入，尤其是應用定義、應用配置變更較為繁瑣，導致問題頻出。

目前專案從開發到生產已經全量使用 Kubernetes，並使用 KubeSphere 進行管理。專案上線週期在一週一次左右的頻率，開發環境進行了自動 CD 觸發，每天進行數十次的釋出和更新。

為什麼使用 KubeSphere(QKE) ？

選型思路

對於中小型團隊來說，在選擇基礎設施上，可以儘量使用第三方提供的成熟系統，避免自建。例如 Git 倉庫、CI 服務、製品庫、部署系統均使用第三方服務，Kubernetes 也儘量使用廠商提供的託管 K8s，避免採坑；日誌、監控報警等系統也是如此（使用 aliyun sls、aliyun arms）。個人認為中小型企業在這方面投入過多並沒有太大的實際意義，專注於業務即可。

在選擇平臺的過程中主要有以下幾點考慮：

• 不被某個雲服務商所繫結

• 開源解決方案

• 可以接受能力範圍內的商業化訂閱（服務支援付費）

• 部署難度低

• 統一認證

• 操作簡便

在叢集管理上，原有業務使用阿里雲 ACK 進行部署，進行平臺遷移時，不希望更換部署環境。另外在管控上，希望網路環境儘量簡單，無需打通 VPC 等複雜操作。

平臺方案

基於以上的選型思路，我們選擇 KubeSphere(QKE) 部署在青雲QingCloud 公有云，作為多叢集的集中控制管理平面 (HOST 叢集)，開發環境(自建 K8s)、生產環境 (Aliyun ACK) 作為 member 叢集。目前將整個開發、生產叢集納入到 KubeSphere 進行管理。

青椒課堂：使用 KubeSphere+QKE 輕鬆實現容器多叢集管理

基於 KubeSphere 部署應用嘗試：青椒課堂 -Region 服務

應用現狀及特點

在確定平臺選型後，我們開始把業務的部分服務進行遷移，最初應用使用視覺化 PAAS 平臺進行多叢集部署，在應用變更時，需要在多個叢集中進行重複地操作，操作繁瑣並且容易出錯。

青椒課堂 -Region 服務應用特點如下：

• 把服務部署在多個地域，比如北京、廣東、上海；

• 各個副本之間不需要進行通訊，只是簡單的一個多副本；

• 直接受主業務的排程，就是提供一個 API server 被主業務去排程；

• 當業務需要變更的時候，比如增刪元件或者元件配置的變更，我們需要在多個副本里面同時進行。用視覺化的 PAAS 平臺就會有一個問題，我們必須人工調整各個地域。當只有幾個時，人工調整還可實現，但隨著叢集數量的增加，手工調整就過於麻煩。並且人工操作也會有很大概率出現問題，例如元件變更在不同的可用區內沒有做到同步調整，導致業務出現故障。

Region服務結構

如何構建原生 K8s 應用

團隊在最初接觸 Kubernetes 時，使用視覺化 PAAS 平臺操作，這雖然極大地降低了團隊上手使用 Kubernetes 的門檻，但同時也造成團隊成員不瞭解資源在 Kubernetes 上的形式，遷移應用時，就必須將應用編寫為 K8s 的資原始檔，最初編寫 yaml 檔案會無從下手。此時藉助 KubeSphere 的控制檯，通過嚮導建立 Deployment、StatefuleSet、Service、Ingress 等資源，編排完成後，切換至編輯模式即可得到一個完成的 yaml 檔案。

應用定義管理選型——使用 helm 的原因

Helm 作為 Kubernetes 包管理工具，目前使用較為廣泛、通用，且 KubeSphere 應用市場也是基於 Helm Chart 製作應用。相對於將應用編寫為靜態 yaml 檔案儲存在 git 倉庫中，使用 helm 作為應用定義的工具便於應用部署多個副本、進行差異化配置。

確定部署工具

最初吸引我們開始使用 KubeSphere 的功能點之一，就是 KubeSphere 的多叢集應用功能，因此在部署選型調研時，首先進行了 KubeSphere 的多叢集應用測試，遺憾的是，KubeSphere的多叢集應用僅支援自制應用，無法適配 helm 應用，因此部署工具開始了重新調研。

Spinnaker 通過製品繫結，將"應用定義"的版本，和"應用元件"的版本進行分離，符合我們將"應用定義的過程"進行版本化的思路。最終確定使用 Spinnaker 作為我們的 CD 工具。

應用初始化自動化改造

在遷移應用部署方式之前，關於應用的初始化配置，也較為依賴手動操作。例如更新版本前，進行配置和環境變數的修改、進入容器執行初始化指令碼、手動新增 HTTPS 證書和域名等等，這種方式也極易造成部署上線過程中的事故。因此在此次遷移過程中，我們也對應用進行了自動初始化的改造，主要涉及以下幾點：

• DNS 解析自動化：通過自己開發的工具，讀取對應的 Ingress、LoadBlancer 資訊進行 DNS 記錄的自動配置。
• 資料庫 migration 、應用初始化指令碼流程化：將資料庫 migration 和 應用初始化指令碼抽象為 Job 型別的資源，作為部署中的流程執行。

自定義監控

KubeSphere 的自定義監控功能也是最初吸引我們使用的一個重要功能點。在此之前，應用的監控面板存放在阿里雲，開發人員需要在多處進行維護和檢視，比較繁瑣，使用 KubeSphere 自定義監控後即可在同一處管理平面進行服務的維護和監控指標的檢視。

KubeSphere Member 叢集安裝後，預設安裝了 prom-operator 元件，應用只需要建立 ServiceMonitor 即可新增監控項，在我們的業務中，也將 ServiceMonitor 的定義放入了 Helm 包中。監控圖表的編輯事實上與 Grafana 的語法、操作基本一致，沒有額外的學習成本。
不過當前監控面板的編排較為依賴 KubeSphere 控制檯，需要在控制檯編排好之後獲取到 yaml 檔案，提交至應用 helm 內進行多叢集分發。

統一認證：如何基於 KubeSphere 開發 OAuth 外掛

由於公司規模不大，目前公司內部並沒有域，也沒有 LDAP 服務，之前自主開發的一些內部系統，都使用釘釘作為統一認證。

但釘釘並不能支援標準的 OAuth 協議對接應用，在 KubeSphere 認證時，我們引入了阿里雲 IDaaS 產品，將釘釘作為認證源，IDaaS 作為 OAuth Provider，實現賬號的統一認證。

回饋社群：參與社群開發貢獻了 KubeSphere IDaaS 外掛：PR: support aliyun idaas oauth login #2997 https://github.com/kubesphere/kubesphere/pull/2997

釘釘登入效果

開發、生產環境全量遷移至 KubeSphere

經過青椒課堂 -Region 服務的成功遷移和穩定執行後，一段時間內我們面臨了 Region 服務的開發測試環境與生產環境不統一的問題，同時主業務也同樣存在 Region 服務遷移前的種種問題，於是我們決定將整個開發、測試、生產環境全部遷移至 KubeSphere。

快速構建開發測試環境

在遷移主業務開發時，也按照 Region 服務的步驟，首先進行了應用 helm 包的定義。在環境上，通過與協同工具進行對接，以“迭代”為粒度建立開發環境，將 namespace 和域名字首做為 CD 的啟動引數進行動態傳入，可以實現快速建立開發測試環境。

通過對接 釘釘機器人 outgoing、CD webhook 實現了簡單的 chatops。

生產環境遷移過程

由於主業務存在管理後臺、非同步佇列、定時任務等元件，如果直接進行全量遷移，會造成任務 Job 丟失、定時任務重複執行等問題。因此在業務遷移中採取了以下的步驟。

• 梳理業務中的 DB 等資訊
• 將非同步佇列使用新老環境共存的方式部署
• 將定時任務遷移至新模式
• 遷移整個管理後臺
• web、api 部分進行新老模式共存方式部署、停止舊模式中所有的非同步隊裡處理元件
• 修改解析，將流量全部遷移至新環境
• 待 DNS 解析全量生效後（大於48小時），將舊環境服務全部下線

彈性擴容：keda

原生彈性擴容的侷限

• 基於資源使用，無法快速感知業務負載變化
• 基於 CPU / 記憶體進行擴容無法精準控制

keda可以解決的問題

• 支援 K8s 原有的 cronhpa/ 基於 CPU & 記憶體的 HPA
• 基於 prom 指標進行 HPA，更快反應業務變化
• 基於 Redis list 長度進行 HPA，適合佇列業務場景
• 基於 MySQL 查詢進行 HPA，必要的時候業務可以主動驅動 HPA 進行伸縮

針對我們的業務場景，通過使用 Prom 指標進行 HPA，可以快速根據業務變化進行擴縮容。通過基於 MySQL 查詢的 HPA，可以在業務內有大規模的課堂時，進行提前自動化擴容，避免業務峰值到來再進行擴容引起的短時間不可用。

未來展望

ChatOps深入實踐

當前通過釘釘、CD、KubeSphere 的打通實現了快速的開發環境建立、更新，開發人員無需在控制檯進行操作即可得到獨立的測試環境並可以切換元件版本。後續將通過增強 ChatOps 功能，例如對接自動化迴歸測試，讓開發測試流程更加高效。

應用釋出管理

在當前的應用釋出過程中，各個元件所使用的版本相對鬆散，每一次部署相對於當前生產環境中的變化，只能依靠人工和文件進行管理，沒有可以遵循的規則和流程，也存在較大的風險，後續在應用釋出的管理上，需要做一些工作來實現整個流程的管控、記錄、追溯。

灰度釋出

由於當前業務全部使用 Nginx Ingress Controller， 所能提供的灰度釋出能力較為有限（針對同一個規則僅支援一條灰度），無法滿足業務對於多版本灰度的需求，後續也需要針對灰度釋出做進一步的調研和實踐。

本文由部落格一文多發平臺 OpenWrite 釋出！