文鼎創智能物聯云原生容器化平臺實踐

作者：sekfung，深圳市文鼎創資料科技有限公司研發工程師，負責公司物聯網終端平臺的開發，穩定性建設，容器化上云作業，擅長使用 GO、Java 開發分布式系統，持續關注分布式，云原生等前沿技術，KubeSphere Contributor，KubeSphere 社區用戶委員會深圳站委員，

公司簡介

深圳市文鼎創資料科技有限公司創立于 2006 年，是全球領先的線上身份認證解決方案提供商，專注網路身份認證，資料安全領域，堅持穩健經營，持續創新、開放合作，在金融電子化、政府、企業辦公等應用中提供解決方案，成為眾多國有商業銀行、全國性股份制銀行、城市商業銀行、農村商業銀行、各省市稅務、政府、各大 CA 機構以及跨國企業的合作伙伴，累積服務近億用戶，不斷滿足客戶差異化需求，

公司多年來持續創新，申請了大量的發明專利、實用新型專利和產品外觀專利；登記了多項計算機軟體著作權，同時是國家級高新技術企業；擁有商用密碼產品型號證書、密碼檢測證書、銀聯認證證書、ISO9001:2015 國際質量管理體系認證及 ISO14001 環境管理體系認證；產品通過了 CE/FCC 認證、RoHS 認證，

公司作為國際線上快速身份驗證聯盟（FIDO）的核心成員之一，致力于實作全球統一的在線驗證標準，我們將運用該技術為不同地區的人們提供享有平等的安全網路世界的權利，

背景介紹

“文鼎創智能物聯”是深圳市文鼎創資料科技有限公司針對物聯網應用，推出的物聯網解決方案，方案包含統一的物聯網服務平臺、”云列印機“、”收款云音箱“、”收款云掃碼盒子“等旗下產品，為用戶的資料安全保駕護航，

作為一家 TO B 解決方案的硬體提供商，“硬體為主，軟體為輔”是公司長期以來的開發模式，因此前期在對服務端的開發、部署、架構設計重視不夠，傳統的專案停留在單機（虛擬機）部署，人工打包上傳，不僅費時費力，還容易出錯，造成服務的不可用，

在擁抱 K8s 之前，我們也嘗試過 docker-compose 的方案，相對于人工打包部署，docker-compose 也確實給我們帶來了一些便利：

1. ALL-IN-ONE，提供一鍵式的軟體部署方案，無需執行繁瑣的部署流程；
2. 隔離了宿主機系統的差異性；
3. 減少了運維人員進行版本迭代的操作，降低操作失誤的可能性，

在面向物聯網行業推出新產品，新解決方案之后，對服務的穩定性，以及可靠性帶來了新的挑戰，現有的開發模式逐步跟不上業務的迭代需求，為此我們迫切需要打破現有的框架，探索新的一套軟體迭代流程，

選型說明

在決定擁抱云原生之時，我們對市面上的容器管理平臺進行了調研，發現國外 Rancher 用戶較多，國內 KubeSphere 位居前列，我們對容器管理平臺的選型有幾個標準：

1. 生態：一個開源專案的生態是否完善很重要，周邊配套的工具能帶來極佳的使用體驗和可維護性，
2. 社區活躍度：官方倉庫 Issue 或問答社區是否回應及時，代碼提交是否活躍？
3. 商業公司或基金會支持：是否有商業公司或開源基金會支持，如果為個人專案，后續停止維護，則可能會給用戶帶來的一定的風險，
4. 技術堆疊：使用的技術堆疊與團隊是否吻合，是否有能力解決和維護？
5. 用戶體驗：是否有 UI 操作界面，界面是否美觀，使用流暢？
6. 本土化：是否做了一些本土化的優化，符合國人的使用習慣？

在調研選型時，我們發現 KubeSphere 能充分滿足的我們的要求，KubeSphere 團隊開源的 KubeKey 工具，能幫助我們快速搭建一個 KubeSphere 集群，省去了繁瑣且復雜的部署流程，OpenELB 專案則為我們提供了本地集群負載均衡的解決方案，

在使用程序中發現的問題，在中文問答社區基本都能找到對應的解決方案，KubeSphere 的控制臺簡化了 Kubernetes 服務的部署，使得團隊一些沒有 K8s 使用經驗的成員也能快速上手，用過的同事都說好，

目前架構

目前采用微服務設計，開發語言以 Golang、Java 為主，服務之間通信使用 gRPC，

生產環境使用兩個騰訊云 CLB 分別接入來自業務和物聯網終端的流量，整個業務服務部署在騰訊云 TKE 集群，并使用 KubeSphere 來管理應用的日常發布，而集群的基礎設施，本著“能買就買，實在不能買就自建”的原則（并不是不差錢，而是小公司運維壓力大），之所以沒有使用 TKE 的控制臺來管理應用的發布，主要是 TKE 的控制臺體驗并不是很友好，另外一個很重要的原因，應用商店對第三方 Helm 倉庫支持很差，無法充分利用 Helm 的生態，

實踐程序

硬體資源

測驗環境：10 臺 ESXI 虛擬機，自建 Kubernetes 集群，

生產環境：7 臺 騰訊云 CVM 節點，Kubernetes 使用騰訊云托管 TKE 集群，

存盤方案

測驗環境：使用 3 臺 ESXI 虛擬機作為分布式存盤 Ceph 的 OSD 節點，

生產環境：出于成本和穩定性的考慮，使用騰訊云 CBS 作為 K8s 存盤方案，

最小化安裝

由于生產環境和測驗環境已經有一些外部服務，比如 Prometheus 和 Logging，為了最大化利用現有資源，在部署 KubepShere 采取了最小化安裝，

值得一提的是，Monitor 并不是可插拔組件，即使最小化安裝，KubeSphere 依然會默認安裝，在生產環境中，安裝 TKE 監控的 prometheus-operator 會與其沖突，需要關閉 KubeSphere 的 Prometheus 或者手動卸載，

DevOps

在早期開發階段，版本迭代是一件非常痛苦的事情，開發人員在本地編譯打包后人工上傳到服務器進行部署，在經歷了多次各種環境差異，人工操作失誤教訓后，團隊下定決心改變現有的流程，決定搭建適合團隊自身的 DevOps 體系，

1. 持續集成（CI）：開發在每次提交代碼之前都進行 CI，以確保代碼的質量和一致性，這包括運行單元測驗，代碼靜態分析，編譯和構建程序等，當 CI 失敗時，開發立即修復代碼并重新提交，
2. 持續交付（CD）：一旦代碼通過了 CI 流程，就將其交付給測驗團隊進行測驗，測驗團隊進行測驗以確保產品的質量，在測驗環境，使用了 Coding 的自定義節點作為 CI 的自動化構建，CI 通過后通過腳本自動更新 KubeSphere 的鏡像版本，在生產環境，由于涉及發布評審流程，配置變更，各個業務團隊的協調，目前暫時還是交由運維人員手動變更應用版本進行發布，
3. 監控和警報：一旦代碼被部署到生產環境，對其進行監控，監控可以幫助團隊快速發現和解決問題，確保產品的可用性和性能，

目前的 DevOps 實踐，主要解決了團隊以下的痛點：

1. 統一編譯環境：規定專案內應撰寫 Dockerfile，使用 Docker 容器內的編譯環境進行編譯，同時使用 Gitlab Runner 通過代碼提交事件觸發代替開發機本地編譯，從而隔離各個開發機環境的差異，
2. 發布版本可追溯：早期專案版本管理十分隨意，全憑開發人員心情命名，導致出現問題時無法快速定位，為此，我們約定在 CI 構建時，鏡像版本需要滿足特定的命名格式，如：${VERSION}-${ENV}-\${CI_NUMBER}，這種命名格式可以幫助我們快速定位到某個環境出現問題某次 CI 構建的版本，
3. 平滑迭代：早期專案使用單機單體部署，在進行迭代時，常常有短時間的服務不可用，導致流量損失，在進行容器化改造后，利用 Kubernetes 的探針，可以進行服務的平滑更新，并且在服務狀態不健康時，能自動重啟，無需人工介入，大大提升了服務的可用性，
4. 運維效率：充分發揮 Kubernetes 的運維體系和云原生的可觀測性實踐，降低了多業務多環境運維的壓力，在服務故障發生時，能夠及時感知，

使用效果

流水線配置

流水線使用了 Coding 的方案，有以下幾方面的考慮：

1. 能夠深度融合企業微信，在 CI 程序，有任何問題能夠及時通過 IM 工具通知到開發；
2. 配套工具完善，官方的 Jenkins 有點跟不上云原生的發展，需要安裝一系列的插件才能滿足需求，配置程序也很繁瑣，

應用部署

“文鼎創智能物聯”專案已全部使用 Helm 應用發布，在使用程序，發現 KubeSphere 一個比較不友好的體驗，如果升級應用因 yaml 檔案配置錯誤導致應用升級失敗，會無法再次升級，在生產環境中，應用無法升級是一個很糟糕的問題，發現該 Bug 后，已提交了修復代碼給社區并合并 fix: can not re-upgrade helm application in a failed state，

集群資源監控

KubeSphere 內置的監控系統，滿足運維人員日常對集群健康狀態的巡檢，同時 KubeSphere 提供了多個層面的監控，針對 namespace 和服務本身，團隊使用頻次較高的是服務監控，以便開發人員對自身發布的服務的資源使用情況有所了解，

未來規劃

1. “文鼎創智能物聯”作為公司探索的新專案已全面完成容器化作業，運行在 KubeSphere 集群，未來打算將歷史遺留的 TO B 專案進行容器化改造和遷移到 KubeSphere 集群，提升專案的可維護性和可用性，
2. 探索 Service Mesh 方案，進一步提升服務的平穩發布和可觀測性，

本文由博客一文多發平臺 OpenWrite 發布！

標籤：其他

上一篇：應屆生畢業就失業？這該怎么辦

下一篇：返回列表