作者 | 盧興民 紅亞科技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 發布！