作者：sekfung，深圳市文鼎創(chuàng)數(shù)據(jù)科技有限公司研發(fā)工程師，負責公司物聯(lián)網(wǎng)終端平臺的開發(fā)，穩(wěn)定性建設，容器化上云工作，擅長使用 GO、Java 開發(fā)分布式系統(tǒng)，持續(xù)關注分布式，云原生等前沿技術，KubeSphere Contributor，KubeSphere 社區(qū)用戶委員會深圳站委員。
公司簡介
深圳市文鼎創(chuàng)數(shù)據(jù)科技有限公司創(chuàng)立于 2006 年，是全球領先的線上身份認證解決方案提供商，專注網(wǎng)絡身份認證，數(shù)據(jù)安全領域，堅持穩(wěn)健經(jīng)營，持續(xù)創(chuàng)新、開放合作，在金融電子化、政府、企業(yè)辦公等應用中提供解決方案，成為眾多國有商業(yè)銀行、全國性股份制銀行、城市商業(yè)銀行、農(nóng)村商業(yè)銀行、各省市稅務、政府、各大 CA 機構(gòu)以及跨國企業(yè)的合作伙伴，累積服務近億用戶，不斷滿足客戶差異化需求。
公司多年來持續(xù)創(chuàng)新，申請了大量的發(fā)明專利、實用新型專利和產(chǎn)品外觀專利；登記了多項計算機軟件著作權(quán)，同時是國家級高新技術企業(yè)；擁有商用密碼產(chǎn)品型號證書、密碼檢測證書、銀聯(lián)認證證書、ISO9001:2015 國際質(zhì)量管理體系認證及 ISO14001 環(huán)境管理體系認證；產(chǎn)品通過了 CE/FCC 認證、RoHS 認證。
公司作為國際線上快速身份驗證聯(lián)盟（FIDO）的核心成員之一，致力于實現(xiàn)全球統(tǒng)一的在線驗證標準，我們將運用該技術為不同地區(qū)的人們提供享有平等的安全網(wǎng)絡世界的權(quán)利。
背景介紹
“文鼎創(chuàng)智能物聯(lián)”是深圳市文鼎創(chuàng)數(shù)據(jù)科技有限公司針對物聯(lián)網(wǎng)應用，推出的物聯(lián)網(wǎng)解決方案，方案包含統(tǒng)一的物聯(lián)網(wǎng)服務平臺、”云打印機“、”收款云音箱“、”收款云掃碼盒子“等旗下產(chǎn)品，為用戶的數(shù)據(jù)安全保駕護航。
作為一家 TO B 解決方案的硬件提供商，“硬件為主，軟件為輔”是公司長期以來的開發(fā)模式，因此前期在對服務端的開發(fā)、部署、架構(gòu)設計重視不夠。傳統(tǒng)的項目停留在單機（虛擬機）部署，人工打包上傳，不僅費時費力，還容易出錯，造成服務的不可用。
在擁抱 K8s 之前，我們也嘗試過 docker-compose 的方案，相對于人工打包部署，docker-compose 也確實給我們帶來了一些便利：
ALL-IN-ONE，提供一鍵式的軟件部署方案，無需執(zhí)行繁瑣的部署流程；
隔離了宿主機系統(tǒng)的差異性；
減少了運維人員進行版本迭代的操作，降低操作失誤的可能性。
在面向物聯(lián)網(wǎng)行業(yè)推出新產(chǎn)品，新解決方案之后，對服務的穩(wěn)定性，以及可靠性帶來了新的挑戰(zhàn)，現(xiàn)有的開發(fā)模式逐步跟不上業(yè)務的迭代需求，為此我們迫切需要打破現(xiàn)有的框架，探索新的一套軟件迭代流程。
選型說明
在決定擁抱云原生之時，我們對市面上的容器管理平臺進行了調(diào)研，發(fā)現(xiàn)國外 Rancher 用戶較多，國內(nèi) KubeSphere 位居前列。我們對容器管理平臺的選型有幾個標準：
生態(tài)：一個開源項目的生態(tài)是否完善很重要，周邊配套的工具能帶來極佳的使用體驗和可維護性。
社區(qū)活躍度：官方倉庫 Issue 或問答社區(qū)是否回應及時，代碼提交是否活躍？
商業(yè)公司或基金會支持：是否有商業(yè)公司或開源基金會支持，如果為個人項目，后續(xù)停止維護，則可能會給用戶帶來的一定的風險。
技術棧：使用的技術棧與團隊是否吻合，是否有能力解決和維護？
用戶體驗：是否有 UI 操作界面，界面是否美觀，使用流暢？
本土化：是否做了一些本土化的優(yōu)化，符合國人的使用習慣？
在調(diào)研選型時，我們發(fā)現(xiàn)青云科技推出的 KubeSphere 能充分滿足的我們的要求。KubeSphere 團隊開源的 KubeKey 工具，能幫助我們快速搭建一個 KubeSphere 集群，省去了繁瑣且復雜的部署流程，OpenELB 項目則為我們提供了本地集群負載均衡的解決方案。
在使用過程中發(fā)現(xiàn)的問題，在中文問答社區(qū)基本都能找到對應的解決方案。KubeSphere 的控制臺簡化了 Kubernetes 服務的部署，使得團隊一些沒有 K8s 使用經(jīng)驗的成員也能快速上手，用過的同事都說好。
目前架構(gòu)
目前采用微服務設計，開發(fā)語言以 Golang、Java 為主，服務之間通信使用 gRPC。
生產(chǎn)環(huán)境使用兩個騰訊云 CLB 分別接入來自業(yè)務和物聯(lián)網(wǎng)終端的流量。整個業(yè)務服務部署在騰訊云 TKE 集群，并使用 KubeSphere 來管理應用的日常發(fā)布。而集群的基礎設施，本著“能買就買，實在不能買就自建”的原則（并不是不差錢，而是小公司運維壓力大）。之所以沒有使用 TKE 的控制臺來管理應用的發(fā)布，主要是 TKE 的控制臺體驗并不是很友好，另外一個很重要的原因，應用商店對第三方 Helm 倉庫支持很差，無法充分利用 Helm 的生態(tài)。
實踐過程
一、硬件資源
測試環(huán)境：10 臺 ESXI 虛擬機，自建 Kubernetes 集群。
生產(chǎn)環(huán)境：7 臺 騰訊云 CVM 節(jié)點，Kubernetes 使用騰訊云托管 TKE 集群。
二、存儲方案
測試環(huán)境：使用 3 臺 ESXI 虛擬機作為分布式存儲 Ceph 的 OSD 節(jié)點。
生產(chǎn)環(huán)境：出于成本和穩(wěn)定性的考慮，使用騰訊云 CBS 作為 K8s 存儲方案。
三、最小化安裝
由于生產(chǎn)環(huán)境和測試環(huán)境已經(jīng)有一些外部服務，比如 Prometheus 和 Logging，為了最大化利用現(xiàn)有資源，在部署 KubeSphere 采取了最小化安裝。
值得一提的是，Monitor 并不是可插拔組件，即使最小化安裝，KubeSphere 依然會默認安裝，在生產(chǎn)環(huán)境中，安裝 TKE 監(jiān)控的 prometheus-operator 會與其沖突，需要關閉 KubeSphere 的 Prometheus 或者手動卸載。
三、DevOps
在早期開發(fā)階段，版本迭代是一件非常痛苦的事情，開發(fā)人員在本地編譯打包后人工上傳到服務器進行部署。在經(jīng)歷了多次各種環(huán)境差異，人工操作失誤教訓后，團隊下定決心改變現(xiàn)有的流程，決定搭建適合團隊自身的 DevOps 體系。
持續(xù)集成（CI）：開發(fā)在每次提交代碼之前都進行 CI，以確保代碼的質(zhì)量和一致性。這包括運行單元測試，代碼靜態(tài)分析，編譯和構(gòu)建過程等。當 CI 失敗時，開發(fā)立即修復代碼并重新提交。
持續(xù)交付（CD）：一旦代碼通過了 CI 流程，就將其交付給測試團隊進行測試。測試團隊進行測試以確保產(chǎn)品的質(zhì)量。在測試環(huán)境，使用了 Coding 的自定義節(jié)點作為 CI 的自動化構(gòu)建，CI 通過后通過腳本自動更新 KubeSphere 的鏡像版本。在生產(chǎn)環(huán)境，由于涉及發(fā)布評審流程，配置變更，各個業(yè)務團隊的協(xié)調(diào)，目前暫時還是交由運維人員手動變更應用版本進行發(fā)布。
監(jiān)控和警報：一旦代碼被部署到生產(chǎn)環(huán)境，對其進行監(jiān)控。監(jiān)控可以幫助團隊快速發(fā)現(xiàn)和解決問題，確保產(chǎn)品的可用性和性能。
目前的 DevOps 實踐，主要解決了團隊以下的痛點：
統(tǒng)一編譯環(huán)境：規(guī)定項目內(nèi)應編寫 Dockerfile，使用 Docker 容器內(nèi)的編譯環(huán)境進行編譯，同時通過代碼提交事件觸發(fā)代替開發(fā)機本地編譯，從而隔離各個開發(fā)機環(huán)境的差異。
發(fā)布版本可追溯：早期項目版本管理十分隨意，全憑開發(fā)人員心情命名。導致出現(xiàn)問題時無法快速定位。為此，我們約定在 CI 構(gòu)建時，鏡像版本需要滿足特定的命名格式，如：${VERSION}-${ENV}-\${CI_NUMBER}，這種命名格式可以幫助我們快速定位到某個環(huán)境出現(xiàn)問題某次 CI 構(gòu)建的版本。
平滑迭代：早期項目使用單機單體部署，在進行迭代時，常常有短時間的服務不可用，導致流量損失。在進行容器化改造后，利用 Kubernetes 的探針，可以進行服務的平滑更新，并且在服務狀態(tài)不健康時，能自動重啟，無需人工介入，大大提升了服務的可用性。
運維效率：充分發(fā)揮 Kubernetes 的運維體系和云原生的可觀測性實踐，降低了多業(yè)務多環(huán)境運維的壓力。在服務故障發(fā)生時，能夠及時感知。
使用效果
一、流水線配置
流水線使用了 Coding 的方案，有以下幾方面的考慮：
能夠深度融合企業(yè)微信，在 CI 過程，有任何問題能夠及時通過 IM 工具通知到開發(fā)；配套工具完善，官方的 Jenkins 有點跟不上云原生的發(fā)展，需要安裝一系列的插件才能滿足需求，配置過程也很繁瑣。
二、應用部署
“文鼎創(chuàng)智能物聯(lián)”項目已全部使用 Helm 應用發(fā)布，在使用過程，發(fā)現(xiàn) KubeSphere 一個比較不友好的體驗，如果升級應用因 yaml 文件配置錯誤導致應用升級失敗，會無法再次升級。在生產(chǎn)環(huán)境中，應用無法升級是一個很糟糕的問題，發(fā)現(xiàn)該 Bug 后，已提交了修復代碼給社區(qū)。
三、集群資源監(jiān)控
KubeSphere 內(nèi)置的監(jiān)控系統(tǒng)，滿足運維人員日常對集群健康狀態(tài)的巡檢，同時 KubeSphere 提供了多個層面的監(jiān)控，針對 namespace 和服務本身，團隊使用頻次較高的是服務監(jiān)控，以便開發(fā)人員對自身發(fā)布的服務的資源使用情況有所了解。
未來規(guī)劃
“文鼎創(chuàng)智能物聯(lián)”作為公司探索的新項目已全面完成容器化工作，運行在 KubeSphere 集群，未來打算將歷史遺留的 TO B 項目進行容器化改造和遷移到 KubeSphere 集群，提升項目的可維護性和可用性。探索 Service Mesh 方案，進一步提升服務的平穩(wěn)發(fā)布和可觀測性。
