KubeSphere 開源社區的小夥伴們，大家下午好。我是中通物流雲平臺的研發負責人楊小飛，主導容器這一塊。首先感謝 KubeSphere 官方的邀請，讓我有機會跟大家分享基於在 KubeSphere 在生產環境的實踐與開發部署經驗，以及中通物流的應用場景。
業務現狀和五大難點
首先，我介紹一下我們中通的業務現狀。
上圖是我們 2019 年的數據情況，當我們開始改造時，每日訂單量基本是 5000W+，掃描軌跡的數據流日均 5億，核心服務大約有 2000+，物理服務器有 3000+，VMware虛機有 2萬+。這麼龐大的管理，隨着中通業務的發展基本上是不可持續了，所以我們亟需改造。下圖是我們中通的業務量。可以看到中通在物流行業中，市場份額佔 20% ，基本上是行業第一。
2019 年我們面臨的困難大致有以下五點：
「1.同項目多版本多環境需求」
我們項目在迭代時，在同一個項目它已經有N多個版本在推進。如果仍以虛機的方式來響應資源，已經跟不上需求了。
「2.項目迭代速度要求快速初始化環境需求」
我們的版本迭代速度非常快，快到甚至是一週一迭代。
「3.資源申請麻煩，環境初始化複雜」
2019 年時，我們申請資源的方式還比較傳統，走工單，搞環境初始化的交付。所以測試人員在測試時非常痛苦，要先申請資源，測試完後還要釋放。
「4.現有虛機資源利用率低，殭屍機多」
有的資源隨着人員的變動或者崗位的變動，變成了殭屍機，數量非常多，尤其是在開發測試環境。
「5.橫向擴展差」
我們在“618”或者“雙11”的時候，資源是非常稀缺的，特別是關鍵核心的服務，之前的做法是提前準備好資源，“618”或者“雙11”結束之後，我們再把資源回收。這其實是一個非常落後的方式。
如何進行雲化改造？
通過調查，我們認爲雲化改造可以分爲三步：雲機房、雲就緒和雲原生。
當時我們的微服務做的比較靠前，用了 Dubbo 框架，微服務改造已經完成，但方式非常傳統，是通過虛機的方式發動。而 Salt 在大量併發的時候有很多問題。所以通過評估，我們亟需對 IaaS 和容器進行改造。
因爲我們介入的時候，中通整個業務的開發已經非常多、非常龐大了。我們有一個非常成熟的 DevOps 團隊，把發佈的 CI/CD 的需求做得非常完善。所以我們介入的話只能做 IaaS 和 K8S 的建設。
KubeSphere 開發部署實踐
爲何選擇 KubeSphere
在選型的時候，我們首先接觸的就是 KubeSphere。當時我通過檢索發現了 KubeSphere，然後進行試用，發現界面和體驗等方面都非常棒。試用一週之後，我們就決定，使用 KubeSphere 作爲中通容器管理平臺 ZKE 的建設方案。我印象中我們當時從 KubeSphere 2.0 版本就開始採用了。同時，在 KubeSphere 的影響之下，我們很快就跟青雲達成合作協議，直接使用青雲的私有云產品來建設中通物流的 IaaS，而 KubeSphere 作爲上層的容器 PaaS 平臺承載微服務運行。
建設方向
基於當時的現狀，我們梳理了整個建設的方向。如下圖所示，我們會以容器管理平臺 KubeSphere 爲基礎來運行無狀態服務，以及可視化管理 Kubernetes 和基礎設施資源。而 IaaS 這一塊會提供一些有狀態的服務，比如中間件。
下面這張圖相信大家非常熟悉。前面三部分我們應用的效果都非常棒，暫時不作過多介紹，我還是着重講一下微服務這部分。我們當時試用了 Istio，發現比較重，而且改造的代價比較大。因爲我們的微服務本身做的就比較靠前了，所以這塊我們暫時沒有應用，後續可能會在 Java 的項目上嘗試一下。
多租戶大集羣 or 單租戶小集羣？
選型完成後，我們開始建設。面臨的第一個問題就非常棘手：我們到底是建一個多租戶大集羣，還是建多個單租戶的小集羣，把它切分開來。
與 KubeSphere 團隊溝通協作，並充分評估了我們公司的需求之後，決定暫時採取多個小集羣的方式，以業務場景（比如中臺業務、掃描業務）或者資源應用（比如大數據、邊緣的）來進行切分。我們會切成多個小集羣，以上面的 DevOps 平臺做 CI/CD。KubeSphere 的容器管理平臺主要是做一個容器的支撐，在終端就能很好地讓用戶查看日誌、部署、重構等等。
當時我們基於多集羣設計，以 KubeSphere 2.0 爲藍圖作改造。在開發、測試和生產者三個環境中切，我們在每一個集羣裏都部署一套 KubeSphere，當然有一些公共的組件我們會拆出來，比如監控、日誌這些。
我們整合的時候，KubeSphere 團隊給了我們非常多的幫助，由於 KubeSphere 2.0 版本只支持 LDAP 對接的方式，而對接 OAuth 的計劃放在3.0版本里，後來 KubeSphere 團隊幫我們整合到2.0，單獨打了一個分支。因爲我們公司內部的 OAuth 認證還有自定義的參數，我們開發改造後，通過掃碼認證的方式很快就整合進來了。
基於 KubeSphere 二次開發實踐
下面介紹一下我們在 2019 年夏天到 2020 年 10 月，我們根據自身的業務場景與 KubeSphere 融合所做的定製化開發。
1.超分設置
我們通過超分比的方式，只要你設置好 Limit，我們很快就能把你的 Requset算好，給你整合進來。目前生產的話，CPU 是10，內存大概是1.5。
2.GPU 集羣監控
目前我們的使用還是比較初級，只是把使用情況測出來，做 GPU 集羣單獨的監控數據的展示。
3.HPA（水平伸縮）
我們使用 KubeSphere，其實對水平伸縮的期望是非常高的。KubeSphere 的資源配置裏有水平伸縮，所以我們把水平伸縮這一塊單獨抽出來設置。水平伸縮的設置配合超分設置，就可以很好地把超分比測出來。
很多核心業務已經通過 HPA 的方式，通過 KubeSphere 的界面設置，最終也獲得了很好的效果，現在基本不需要運維干預了。特別是有應急場景的需求，比如上游 MQ 消費積壓了，需要我們立馬擴副本，這樣我們可以非常快地響應。
4.批量重啓
在極端情況下可能要批量重啓大量 Deployments，我們單獨把這個抽出來做了一個小模塊，通過 KubeSphere 平臺一鍵設置，某個項目（NameSpace）下的 Deployment 或者是集羣馬上可以重啓，可以得到很快的響應。
5.容器親和性
在容器親和性這一塊，我們主要做了軟性的反親和。因爲我們有些應用它的資源使用可能是相斥的，比如都是 CPU 資源使用型的，我們簡單改造了一下，加了一些親和性的設置。
6.調度策略
在調度策略方面，因爲涉及到比較敏感的後臺數據，我們本來打算通過 Yaml 的方式來做。但是後面還是決定通過 KubeSphere 的高級設置頁面來實現。我們簡單加了一些頁面的元素，把指定主機、指定主機組、獨佔主機的功能，通過錶行的形式去配置。我們現在用得特別好的是指定主機組和獨佔主機這兩個功能。
簡單介紹一下獨佔主機的應用。我們的核心業務在晚上到凌晨 6 點左右，由於這個時間段服務是比較空閒的，所以用來跑大數據應用非常合適。我們通過獨佔主機的方式把它空出來，防止它跑滿整個集羣，所以只是掛了某些點。
7.網關
KubeSphere 是有獨立網關的概念的，每一個項目下都有一個單獨的網關。獨立網關滿足了我們的生產需求（因爲希望生產走獨立網關的方式），但在開發測試有一個泛網關的需求，因爲我們希望更快響應服務。所以我們做了一個泛網關，起了一個獨立網關，所有開發、測試、域名通過泛域名的方式直接進來。這一塊配置好，通過 KubeSphere 界面簡單編排一下，基本上我們的服務就直接可以訪問。
8.日誌收集
我們一開始是採用官方的方式，也就是通過 Fluent-Bit 的方式收集日誌。但後來發現隨着業務量上線越來越多，Fluent-Bit 也會經常掛掉。出現這種情況的原因，可能是我們在資源優化方面有缺陷，也可能是整個參數沒有調好。所以我們決定啓用 Sidecar 的方式來進行日誌收集。Java 的服務都會單獨起一個 Sidecar，通過 Logkit 這種小的 Agent，把它的日誌推到 ElasticSearch 這種中心。在開發測試環境，我們還會用 Fluent-agent 的方式來收集日誌。另外有一些生產場景，一定要保證日誌的完整性，所以我們會將日誌進一步進行磁盤的持久化。通過如下圖中所示的四個方式，來收集全部的容器日誌。
9.事件跟蹤
我們直接拿了阿里雲開源的 Kube-eventer 進行改造。KubeSphere 這一塊我們加了事件跟蹤可以配置，可以發到我們的釘釘羣。尤其在生產上是比較關注業務的變動的，都可以通過定製化配到釘釘羣裏面。
未來規劃
接下來我們可能批量推生產，我們也提了一些想法，想跟社區交流一下。
1.服務大盤
在 KubeSphere 控制檯界面是以錶行的形式去看我們的微服務等，但我們不知道它們之間的關係，希望通過這種圖形化的方式把它展現出來，把它關鍵的指標——事件、日誌、異常情況等直觀地呈現出來，以便於我們可視化的運營。目前我們正在規劃，明年應該會單獨做。
我們想表達的是，無論任何人，包括運維、開發，只要拿到這張圖就能知道我們服務的架構是什麼樣的，目前依賴於哪些中間件、哪些數據庫，以及服務目前的狀況，比如哪些服務宕了，或者哪些服務目前會有隱藏性的問題。
2.全域 PODS
第二張圖我們起的名字叫全域 PODS。在 KubeSphere 官方這邊應該叫熱力圖。我們希望從整個集羣的視角上，能夠看到目前所有的 PODS 現狀，包括它的顏色變化和資源狀態。
3.邊緣計算
邊緣計算這部分的規劃，由我的同事王文虎爲大家分享。
針對邊緣計算如何與容器技術結合，我們通過調研現有社區邊緣計算相關方案，最終選擇了 KubeEdge。中通適合邊緣計算落地的場景包括：
「中轉快件掃描數據上傳」。各個中轉中心快件數據掃描後，首先經過各中轉中心部署的服務進行第一次處理，然後把處理過的數據上傳到數據中心。各個中轉中心部署的服務現在是通過自動化腳本遠程發佈，目前中通所有中轉中心將近 100 個，每次發佈需要 5 個人/天。如果通過邊緣管理方案，可以大幅度減少人力發佈和運維成本，另外可以結合 Kubernetes 社區推薦的 Operator 開發模式來靈活定製發佈策略。
「操作工暴力分揀自動識別」。中通爲了降低快件破損率，在各中轉中心及其網點流水線安置攝像頭掃描操作工日常操作，掃描到的數據會傳到本地的 GPU 盒子進行圖片處理，處理完的數據傳到數據中心。當前 GPU 盒子內的應用發佈爲手動登錄發佈，效率非常低；盒子經常還會出現失聯，發現該問題時可能已經過了很長時間。通過 KubeEdge 邊緣方案也可以解決當前發佈與節點監控問題。
「各中心智慧園區項目落地」。該項目也正在公司落地，後續也會有很多邊緣場景可以藉助容器技術解決當前痛點。
但是，我們也遇到了幾個問題需要解決：
「海量邊緣節點管理」
「KubeEdge 服務穩定性與高可用性」
「邊緣節點部署與自動運維」
針對上述分享和問題，也歡迎大家跟我們進一步交流，謝謝大家！
關於 KubeSphere
KubeSphere （https://kubesphere.io）是在 Kubernetes 之上構建的開源容器混合雲，提供全棧的 IT 自動化運維的能力，簡化企業的 DevOps 工作流。
KubeSphere 已被 Aqara 智能家居、本來生活、新浪、華夏銀行、四川航空、國藥集團、微衆銀行、紫金保險、中通、中國人保壽險、中國太平保險、中移金科、Radore、ZaloPay 等海內外數千家企業採用。KubeSphere 提供了開發者友好的嚮導式操作界面和豐富的企業級功能，包括多雲與多集羣管理、Kubernetes 資源管理、DevOps (CI/CD)、應用生命周期管理、微服務治理 (Service Mesh)、多租戶管理、監控日志、告警通知、審計事件、存儲與網絡管理、GPU support 等功能，幫助企業快速構建一個強大和功能豐富的容器雲平臺。
✨ GitHub ：https://github.com/kubesphere 💻 官網（中國站） ：https://kubesphere.com.cn 👨💻 微信羣：請搜索添加羣助手微信號 kubesphere
本文分享自微信公衆號 - KubeSphere（gh_4660e44db839）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。