主營業務
杭州遙望網絡（https://www.ywwl.com/）成立於 2010 年 11 月，2018 年與上市公司星期六併購，併成爲頭部 MCN 機構；2019 年連續 5 個月成爲快手 MCN 第一名；在多平臺 MCN 機構排名中均名列前茅；2020 年雙 11 期間，直播電商 GMV 達 13.22 億人民幣。
公司技術情況
公司在十餘年的發展中，一直是業務導向，技術拆分成小組，不同業務組管理自己的服務及服務器，公司整體缺乏Devops的理念和 Cloud Native 的基因；另一方面又是疫情影響下快速發展的訂單量帶來的系統壓力，傳統的部署模式，多 Java 應用分不同端口甚至 Nginx 耦合在一臺虛擬機上，這種情況下，我們基本就不考慮平滑擴展了。爲了儘快利用 Kubernetes 的快速擴縮容及自愈能力應對高併發的用戶流量衝擊，我們考慮了以下情況。
技術選型
由於我們屬於互聯網的直播電商業務，需要快速迭代發佈以及快速回滾，並運維團隊人手十分緊張，所以以下是我們對 Kubernetes 開源產品選型的首要考慮因素：
-
對開發測試同學友好的日誌查詢，支持應用快速發佈回滾 -
對運維友好的權限統一管理、授權，方便維護（我們運維團隊初期就1-2個人） -
快速部署和上線，開箱即用 -
多 Kubernetes 集羣支持（多條業務線）隔離又統一
在調研了社區裏主流的三個開源容器混合雲產品後，最終我們選擇了 KubeSphere v3.0 (https://kubesphere.io) 來管理我們本地數據中心 + 公有云的 5 套 Kubernetes 集羣，下面是我們的多集羣管理頁面。
“雙十一” 戰況
下面是我們頭部主播瑜大公子 11 月 5 號當天就達到3.68 億 GMV，訂單系統 Pod 一共有 20+ 個，峯值達到 45M/s，通常這個時候主播都在發福利，所以用戶訪問量和交易量規模上升特別快。因此，在 KubeSphere 界面看到的訂單系統的 Pod 內網瞬時流量也有很明顯的激增。
業務平臺與架構
我們業務平臺底層一共五套 Kubernetes 集羣，其中一套管理集羣，四套業務集羣，均基於公有云與本地數據自建，由 KubeSphere 統一納管。業務使用 Redis、Zookeeper、Apollo 分別作爲緩存、中間件、分佈式配置管理。平臺之上運行分銷中心、供應鏈管理等多個業務模塊。
多集羣高可用部署
這裏使用 KubeSphere 開源 Kubernetes 集羣安裝工具 KubeKey（https://github.com/kubesphere/kubekey）進行部署，KubeKey 本身基於 Kubeadm，網絡選擇 Flannel vxlan 模式，由於我們的集羣分佈在不同的環境上，vxlan 是最通用的方案，不用去考慮公有云各種各樣的限制或者路由器支不支持等等。
同時，採用了三步走的部署思路，主要是由於我們之前沒有 KubeSphere v2.x 版本的使用經驗，上生產的時候 3.0 還未 GA，分步驟部署有利於排查問題，理解原理。我們選擇使用 docker 19.03.9 和 Kubernetes v1.18.6 構建集羣，具體可以參考 KubeSphere 官方文檔（https://kubesphere.io/docs/）。
多集羣網絡鏈接
KubeSphere 多集羣的架構分爲 Host 和 Member 集羣角色，其中 Host 集羣作爲多集羣的管理控制面，而 Member 集羣被 Host 集羣所納管。因此我們將業務集羣放在了 Member 集羣，host 集羣僅用於管理多個 Member 集羣。
我們一共有五套 Kubernetes 集羣分別作爲 dev（開發環境）、test（測試環境）、Pre（預發佈環境）、生產環境 1 和生產環境 2 使用，不同集羣之間使用 ipsec vpn 及 Tower（https://github.com/kubesphere/tower）代理來打通集羣間的網絡連通，這裏僅僅是管理使用，由於業務之間沒有耦合關係，所以不用考慮代理及 VPN 的速度和穩定性問題；而集羣節點規模根據實際業務情況定期擴縮容。
集羣 api-server 高可用
由於我們公有云的 Kubernetes 集羣是選擇基於阿里雲 ECS 進行自建集羣，而由於阿里雲 SLB 不支持某服務器同時作爲客戶端和 server 端，因此我們選擇在中間加了 2 臺 HAproxy 來代理 6443 端口，同時開啓 check port；當然，你也可以選擇用靜態 Pod 維護一個 ipvs 規則，來進行代理，這個就看大家怎麼選擇了。
多集羣流水線設計
CI/CD 部分我們使用了 KubeSphere 內置的基於 Jenkins 引擎的 Devops 系統，核心原則儘可能的使用 Pipeline 跟 Shell 腳本，不用或者少用 Jenkins 插件；
我們採用 env 與集羣的 Kubeconfig 匹配的方式，不同的環境與集羣發佈權限一一對應，否則直接報錯，其中開發環境、測試環境可以選擇開發分支發佈（而 release/master 分支不允許），提測完畢合併到 release 打 tag（分常規版本與 hotfix 版本），tag 由系統名稱與版本號構成，然後發佈至預發佈環境。
預發佈環境如果驗證沒問題，則直接將該鏡像放在生產環境進去跑，減去重複 CI 的過程。但這有一個前提條件就是你的鏡像是無狀態的，服務啓動時去拉對應環境的 Apollo 配置由啓動參數動態傳入，一般是環境標籤；同時將 CI/CD 代碼放置在獨立倉庫，KubeSphere 上就留一個 jenkinsfile 框架。
發佈到生產之後，測試同學再進行迴歸，驗證無誤後，該 Release，tag 代碼合併到 master 分支；其他的開發分支可以繼續合併到 release，標記新的 tag 同步在預發佈環境中驗證；鏡像 ID 部分，開發環境和測試環境環境使用 "date+buildnumber" 作爲鏡像的tag，預發佈和生產環境使用 git tag 作爲鏡像 tag。
這裏之所以要選擇 app_name，是因爲我們後端 Web 層跟 Service 層耦合在一個 git 工程下，甚至 task 也在一起依賴於同一個 common，沒有完成服務拆分。部分 pom 沒有獨立，每次需要先去跑父 pom，再去打包 Web 或 service 或 task。
回滾
回滾其實就很簡單了，打了 git tag 的鏡像會保留 5 份在 Node 節點中，如果沒有，就去 Harbor 鏡像倉庫中拉，回滾的操作實際上就是一個滾動替換的動作，回滾界面，開發可以選擇最近 5 個 tag 版本。
目前看到的實際上已經是上一個版本，正在測試的版本呢，只需要選擇 branch 或 tag 跟 env，以及 app_name 即可。回滾直接選擇已存在的 git tag 即可，如果不存在則跑 CI 流程。
服務暴露
模式 1
以下是我們比較老的一套，通用的 jetty 基礎鏡像 + shell 啓動腳本傳入 env，app_name 的形式啓動。而發佈流程，則是上傳更新包到 fileserver，每次發佈，鏡像啓動之後都去 fileserver，wget, env 傳入的 app_name 代碼包到 webapps 下；這裏每個項目都配置了大量的 env。
同時，Nginx 即作爲後端代理，又作爲前端靜態 server 來使用，規則比較複雜；爲了快速上線，我們沒有對這套邏輯進行改造；可以看到，代理鏈路有點長，但在當前情況下，也是沒辦法的辦法。
模式 2
這套模式就是 Kubernetes 服務對外暴露比較標準的模式了，也是我們當前採用的模式。由於 KubeSphere 官方提供的模板是按namespace的維度去監聽 Service，這樣多個項目就有非常多的 ingress-nginx 實例，同時需要多個 SLB 去做代理，成本比較高，與公司實際情況不太相符，所以我們將其改成了全局監聽。即在同一套 Kubernetes 集羣中只有一套全局的 ingress-nginx 對外暴露服務。
監控與日誌收集方案
日誌管理
日誌部分採用的是 KubeSphere 提供的日誌查詢與收集套件，即默認收集 stdout 與 stderr 打印內容，同時加上 Workspace，namespace，Pod ID 等信息；KubeSphere 日誌套件使用了 Fluentd 的輕量級版本即 Fluentd-bit，日誌量大的同學可以考慮將日誌存儲到外部的 Kafka 或 Elasticsearch。
我們選擇把那部分老的業務日誌直接落盤，沒有打印，同時不去麻煩開發同學，我們將它又打印到了 stdout，stderr，再進行上面流程。
日誌檢索我們直接用的是 KubeSphere 官方內置的日誌檢索頁面，足夠日常開發運維使用，不用再跳到單獨的 Kibana 頁面去查詢日誌。
這裏有個非常好用的特性功能，即日誌檢索頁面點擊日誌條目直接跳轉至該 Pod，webshell 界面，同時顯示該條日誌上下文；好比你在服務器上執行 tail -f xxx.log 查看日誌的效果；非常方便運維人員逐級排錯。
監控
監控使用 KubeSphere 內置的 Prometheus-operator 和集羣監控界面，暫時沒有過多精力進行深入規則配置或者繪製統一監控大盤，目前默認的監控指標基本上夠用，這部分會放在下一個規劃階段進行增強。
總結與建議
KubeSphere 3.0 基本上可以滿足一套平臺搞定多業務場景的需求，包含 DevOps，監控告警，事件查詢，操作審計等一套完整容器混合雲 PaaS 平臺所必備的功能；雖說目前還有一些小的 Bug，但完全可以用技術手段去彌補或者規避，相信在下個版本會有比較好的體驗。
後期規劃：
-
階段一，所有業務全線發佈至 Kubernetes -
階段二，引入Apache SkyWalking做鏈路追蹤，容器image全線無狀態化，減少CI次數，提升發佈速度，依據官方3.1版本發佈速度來決定要不要自行修改，並加入釘釘，短信告警 -
階段三，自定義監控大盤，引入 UV PV / QPS、服務健康程度，5xx，4xx日誌統計，服務更新狀態監控等細化監控指標 -
階段四，嘗試引入 Istio，因爲後端使用 Dubbo，目前的 Java 配置不支持我們去修改 Dubbo 源代碼來適配 Istio（歡迎 Java 大牛來交流 Dubbo 結合 Istio 的使用場景）
第二次直播預告
今晚 8 點，我們邀請了北京紅亞科技 CTO 盧興民老師爲大家分享 「KubeSphere 混合雲在教育服務行業的最佳實踐 —— 使用 QKE 管理多個 ACK 集羣」。
直播分享活動將在 B 站進行，歡迎大家掃碼海報或點擊「閱讀原文」收看（關注 KubeSphere 公衆號加入微信羣），我們 11 月 19 日晚 8 點 B 站直播間不見不散！
關於 KubeSphere
KubeSphere （https://kubesphere.io）是在 Kubernetes 之上構建的容器混合雲，提供全棧的 IT 自動化運維的能力，簡化企業的 DevOps 工作流。
KubeSphere 已被 Aqara 智能家居、本來生活、新浪、中國人保壽險、華夏銀行、四川航空、國藥集團、微衆銀行、紫金保險、Radore、ZaloPay 等海內外數千家企業採用。KubeSphere 提供了運維友好的嚮導式操作界面和豐富的企業級功能，包括多雲與多集羣管理、Kubernetes 資源管理、DevOps (CI/CD)、應用生命周期管理、微服務治理 (Service Mesh)、多租戶管理、監控日志、告警通知、存儲與網絡管理、GPU support 等功能，幫助企業快速構建一個強大和功能豐富的容器雲平臺。
本文分享自微信公衆號 - KubeSphere（gh_4660e44db839）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。