溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
基于KubeSphere 在生產環境的開發與部署實踐是怎樣的，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
中通物流是國內業務規模較大，第一方陣中發展較快的快遞企業。2019年，中通各類系統產生的數據流以億計，各類物理機和虛擬機成千上萬，在線微服務更是數不勝數。如此龐大的管理，使得中通業務發展不可持續，因此著手云化改造。在改造過程中，中通選擇了 KubeSphere 來作為中通容器管理平臺 ZKE 的建設方案。
首先，我介紹一下我們中通的業務現狀。
上圖是我們 2019 年的數據情況，當我們開始改造時，各類系統產生的數據流以億計，各類物理機和虛擬機更是成千上萬，在線微服務更是數不勝數。截止到 2020 年第三季度，中通快遞的市場份額已擴大至 20.8%，基本上是行業領先。這么龐大的管理，隨著中通業務的發展基本上是不可持續了，所以我們亟需改造。
2019 年我們面臨的困難大致有以下五點：
1.同項目多版本多環境需求
我們項目在迭代時，在同一個項目它已經有 N 多個版本在推進。如果仍以虛機的方式來響應資源，已經跟不上需求了。
2.項目迭代速度要求快速初始化環境需求
我們的版本迭代速度非常快，快到甚至是一周一迭代。
3.資源申請麻煩，環境初始化復雜
2019 年時，我們申請資源的方式還比較傳統，走工單，搞環境初始化的交付。所以測試人員在測試時非常痛苦，要先申請資源，測試完后還要釋放。
4.現有虛機資源利用率低，僵尸機多
有的資源隨著人員的變動或者崗位的變動，變成了僵尸機，數量非常多，尤其是在開發測試環境。
5.橫向擴展差
我們在“618”或者“雙11”的時候，資源是非常稀缺的，特別是關鍵核心的服務，之前的做法是提前準備好資源，“618”或者“雙11”結束之后，我們再把資源回收。這其實是一個非常落后的方式。
通過調查，我們認為云化改造可以分為三步：云機房、云就緒和云原生。
當時我們的微服務做的比較靠前，用了 Dubbo 框架，微服務改造已經完成，但方式非常傳統，是通過虛機的方式發動。而 Salt 在大量并發的時候有很多問題。所以通過評估，我們亟需對 IaaS 和容器進行改造。
因為我們介入的時候，中通整個業務的開發已經非常多、非常龐大了。我們有一個非常成熟的 DevOps 團隊，把發布的 CI/CD 的需求做得非常完善。所以我們介入的話只能做 IaaS 和 Kubernetes 的建設。
在選型的時候，我們首先接觸的就是 KubeSphere。當時我通過檢索發現了 KubeSphere，然后進行試用，發現界面和體驗等方面都非常棒。試用一周之后，我們就決定，使用 KubeSphere 作為中通容器管理平臺 ZKE 的建設方案。我印象中我們當時從 KubeSphere 2.0 版本就開始采用了。同時，在 KubeSphere 的影響之下，我們很快就跟青云達成合作協議，直接使用青云的私有云產品來建設中通物流的 IaaS，而 KubeSphere 作為上層的容器 PaaS 平臺承載微服務運行。
基于當時的現狀，我們梳理了整個建設的方向。如下圖所示，我們會以容器管理平臺 KubeSphere 為基礎來運行無狀態服務，以及可視化管理 Kubernetes 和基礎設施資源。而 IaaS 這一塊會提供一些有狀態的服務，比如中間件。
下面這張圖相信大家非常熟悉。前面三部分我們應用的效果都非常棒，暫時不作過多介紹，我還是著重講一下微服務這部分。我們當時試用了 Istio，發現比較重，而且改造的代價比較大。因為我們的微服務本身做的就比較靠前了，所以這塊我們暫時沒有應用，后續可能會在 Java 的項目上嘗試一下。
選型完成后，我們開始建設。面臨的第一個問題就非常棘手：我們到底是建一個多租戶大集群，還是建多個單租戶的小集群，把它切分開來。
與 KubeSphere 團隊溝通協作，并充分評估了我們公司的需求之后，決定暫時采取多個小集群的方式，以業務場景（比如中臺業務、掃描業務）或者資源應用（比如大數據、邊緣的）來進行切分。我們會切成多個小集群，以上面的 DevOps 平臺做 CI/CD。KubeSphere 的容器管理平臺主要是做一個容器的支撐，在終端就能很好地讓用戶查看日志、部署、重構等等。
當時我們基于多集群設計，以 KubeSphere 2.0 為藍圖作改造。在開發、測試和生產者三個環境中切，我們在每一個集群里都部署一套 KubeSphere，當然有一些公共的組件我們會拆出來，比如監控、日志這些。
我們整合的時候，KubeSphere 團隊給了我們非常多的幫助，由于 KubeSphere 2.0 版本只支持 LDAP 對接的方式，而對接 OAuth 的計劃放在 3.0 版本里，后來 KubeSphere 團隊幫我們整合到 2.0，單獨打了一個分支。因為我們公司內部的 OAuth 認證還有自定義的參數，我們開發改造后，通過掃碼認證的方式很快就整合進來了。
下面介紹一下我們在 2019 年夏天到 2020 年 10 月，我們根據自身的業務場景與 KubeSphere 融合所做的定制化開發。
我們通過超分比的方式，只要你設置好 Limit，我們很快就能把你的 Requset 算好，給你整合進來。目前生產的話，CPU是 10，內存大概是 1.5。
目前我們的使用還是比較初級，只是把使用情況測出來，做 GPU 集群單獨的監控數據的展示。
我們使用 KubeSphere，其實對水平伸縮的期望是非常高的。KubeSphere 的資源配置里有水平伸縮，所以我們把水平伸縮這一塊單獨抽出來設置。水平伸縮的設置配合超分設置，就可以很好地把超分比測出來。
很多核心業務已經通過 HPA 的方式，通過 KubeSphere 的界面設置，最終也獲得了很好的效果，現在基本不需要運維干預了。特別是有應急場景的需求，比如上游 MQ 消費積壓了，需要我們立馬擴副本，這樣我們可以非常快地響應。
在極端情況下可能要批量重啟大量 Deployments，我們單獨把這個抽出來做了一個小模塊，通過 KubeSphere 平臺一鍵設置，某個項目（NameSpace）下的 Deployment 或者是集群馬上可以重啟，可以得到很快的響應。
在容器親和性這一塊，我們主要做了軟性的反親和。因為我們有些應用它的資源使用可能是相斥的，比如都是 CPU 資源使用型的，我們簡單改造了一下，加了一些親和性的設置。
在調度策略方面，因為涉及到比較敏感的后臺數據，我們本來打算通過Yaml的方式來做。但是后面還是決定通過 KubeSphere 的高級設置頁面來實現。我們簡單加了一些頁面的元素，把指定主機、指定主機組、獨占主機的功能，通過表行的形式去配置。我們現在用得特別好的是指定主機組和獨占主機這兩個功能。
簡單介紹下獨占主機的應用。我們的核心業務在晚上到凌晨六點左右，由于這個時間段服務是比較空閑的，所以用來跑大數據應用非常合適。我們通過獨占主機的方式把它空出來，防止它跑滿整個集群，所以只是掛了某些點。
KubeSphere 是有獨立網關的概念的，每一個項目下都有一個單獨的網關。獨立網關滿足了我們的生產需求（因為希望生產走獨立網關的方式），但在開發測試有一個泛網關的需求，因為我們希望更快響應服務。所以我們做了一個泛網關，起了一個獨立網關，所有開發、測試、域名通過泛域名的方式直接進來。這一塊配置好，通過 KubeSphere 界面簡單編排一下，基本上我們的服務就直接可以訪問。
我們一開始是采用官方的方式，也就是通過 Fluent-Bit 的方式收集日志。但后來發現隨著業務量上線越來越多，Fluent-Bit 也會經常掛掉。出現這種情況的原因，可能是我們在資源優化方面有缺陷，也可能是整個參數沒有調好。所以我們決定啟用 Sidecar 的方式來進行日志收集。Java 的服務都會單獨起一個 Sidecar，通過 Logkit 這種小的 Agent，把它的日志推到 ElasticSearch 這種中心。在開發測試環境，我們還會用 Fluen-agent 的方式來收集日志。另外有一些生產場景，一定要保證日志的完整性，所以我們會將日志進一步進行磁盤的持久化。通過如下圖中所示的四個方式，來收集全部的容器日志。
我們直接拿了阿里云開源的 Kube-eventer 進行改造。KubeSphere 這一塊我們加了事件跟蹤可以配置，可以發到我們的釘釘群。尤其在生產上是比較關注業務的變動的，都可以通過定制化配到釘釘群里面。
接下來我們可能批量推生產，我們也提了一些想法，想跟社區交流一下。
在 KubeSphere 控制臺界面是以表行的形式去看我們的微服務等，但我們不知道它們之間的關系，希望通過這種圖形化的方式把它展現出來，把它關鍵的指標——事件、日志、異常情況等直觀地呈現出來，以便于我們可視化的運營。目前我們正在規劃，明年應該會單獨做。
我們想表達的是，無論任何人，包括運維、開發，只要拿到這張圖就能知道我們服務的架構是什么樣的，目前依賴于哪些中間件、哪些數據庫，以及服務目前的狀況，比如哪些服務宕了，或者哪些服務目前會有隱藏性的問題。
第二張圖我們起的名字叫全域 PODS。在 KubeSphere 官方這邊應該叫熱力圖。我們希望從整個集群的視角上，能夠看到目前所有的 PODS 現狀，包括它的顏色變化和資源狀態。
邊緣計算這部分的規劃，由我的同事王文虎為大家分享。
針對邊緣計算與容器的結合，我們通過調研，最終選擇了 KubeEdge，中通適合邊緣計算落地的場景包括：
中轉快件掃描數據上傳。各個中轉中心快件數據掃描后，首先經過各中轉中心部署的服務進行第一次處理，然后把處理過的數據上傳到數據中心。各個中轉中心部署的服務現在是通過自動化腳本遠程發布，目前中通所有中轉中心將近 100 個，每次發布需要 5 個人/天。如果通過邊緣管理方案，可以大幅度減少人力發布和運維成本，另外可以結合 Kubernetes 社區推薦的 Operator 開發模式來靈活定制發布策略。
操作工暴力分揀自動識別。中通為了降低快件破損率，在各中轉中心及其網點流水線安置攝像頭掃描操作工日常操作，掃描到的數據會傳到本地的 GPU 盒子進行圖片處理，處理完的數據傳到數據中心。當前 GPU 盒子內的應用發布為手動登錄發布，效率非常低；盒子經常還會出現失聯，發現該問題時可能已經過了很長時間。通過 KubeEdge 邊緣方案也可以解決當前發布與節點監控問題。
各中心智慧園區項目落地。該項目也正在公司落地，后續也會有很多邊緣場景可以借助容器技術解決當前痛點。
關于基于KubeSphere 在生產環境的開發與部署實踐是怎樣的問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
