KubeSphere 開源社區的小夥伴們，你們下午好。我是中通物流雲平臺的研發負責人楊小飛，主導容器這一塊。首先感謝 KubeSphere 官方的邀請，讓我有機會跟你們分享基於在 KubeSphere 在生產環境的實踐與開發部署經驗，以及中通物流的應用場景。
node
業務現狀和五大難點
首先，我介紹一下咱們中通的業務現狀。
上圖是咱們 2019 年的數據狀況，當咱們開始改造時，每日訂單量基本是 5000W+，掃描軌跡的數據流日均 5億，核心服務大約有 2000+，物理服務器有 3000+，VMware虛機有 2萬+。這麼龐大的管理，隨着中通業務的發展基本上是不可持續了，因此咱們亟需改造。下圖是咱們中通的業務量。能夠看到中通在物流行業中，市場份額佔 20% ，基本上是行業第一。2019 年咱們面臨的困難大體有如下五點：git
「1.同項目多版本多環境需求」github
咱們項目在迭代時，在同一個項目它已經有N多個版本在推動。若是仍以虛機的方式來響應資源，已經跟不上需求了。web
「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）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。