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