作者：謝元昌，廣西交科集團有限公司軟件院開發工程師。平時主要負責軟件的開發以及運維工作。目前主要從事廣西高速公路聯網電子不停車收費 (ETC) 運營服務系統的設計與開發工作。本人對雲原生工作有強烈嚮往，但一直苦於雲原生門檻較高，實踐機會少。自從公司落地了 KubeSphere 後，得到很多實踐的機會。
公司簡介
廣西交科集團有限公司軟件研究院成立於 2017 年，前身爲公司智能交通所軟件研發中心，主要從事高速公路領域的軟件開發、系統集成業務 , 爲行業客戶提供相關解決方案。現擁有軟件著作權 74 項、軟件產品 90 項，並通過 IS09001 質量體系認證，是廣西高速公路領域最大的軟件服務提供商。該院已獲得美國 CMMI 研究院頒發的 CMMI5 級評估證書，在軟件研發能力成熟度和項目管理方面達到了國際較高水平。
該院專注高速公路收費領域，在高速公路收費、高速公路運營管理支持、城市公共交通支付等領域取得突出成果，研發的“高速公路 IC 卡‘一卡通’聯網收費系統”使廣西率先成爲全國第一批實現高速 : 公路聯網收費的省份 ; 成功研發了廣西第-套具有完全知識產權的“ETC 不停車收費系統”，包含廣西高速公路聯網電子不停車收費 (ETC) 系統服務及結算平臺、ETC 聯網清分中心繫統、ETC 密鑰管理系統等，ETC 不停車收費車道系統已經覆蓋全廣西範圍內的高速公路並實現全國互聯互通。二十多年來在廣西累計建設 MTC 車道 3300 多條，ETC 車道 1600 多條，自動髮卡機車道 370 多條。除專注發展高速公路收費領域外，該院在發展高速公路建管養一體化領域、口岸信息化領域也取得顯著成果。
建設目標
我們期望基於 K8s 搭建 PaaS 雲計算平臺。使用多租戶方式管理和使用資源。集成 CI/CD 支持靈活擴容與升級集羣。構建企業級一站式 DevOps 架構，提供集羣資源的可監控性服務。
環境痛點
在使用 k8s 前，我們使用由第三方的運維團隊負責的虛擬機管理平臺。開發部署環境混亂，運維管理成本大，服務器資源利用率低。由於安全需要，每次登陸虛擬機都需要先經過一個堡壘機，然後再輸入目標虛擬機的賬戶密碼才能登錄。
由於虛擬機的賬戶密碼每 3 個月就會更換一次，所以每次登錄都需要先查表才能知道最新的密碼，非常麻煩。另外，每次更換密碼也都需要運維人員大量純手工操作，極其耗費時間。開發人員上線新應用時，需要運維人員支持先分配一臺或多臺虛擬機後將 IP 和賬戶密碼發給開發人員，從此開發人員就擁有這個虛擬機的使用權，開發人員需要從 0 開始配置虛機的系統環境，安裝中間件，手動上傳應用，最後，再手動將應用運行起來。
應用下線時，開發人員一般是不會及時通知運維人員去回收資源的，因爲重新配置一臺機器非常麻煩，所以總是優先考慮留着資源，以備新的應用上線。由於運維人員對每個虛機的實際使用情況根本無法掌握，所以虛擬機資源經常無法回收，造成了大量服務器資源的浪費。
IT 運維與開發團隊的規模
基礎設施運維 3 人 ， 開發團隊 70 人。
背景介紹
在擁抱雲原生之前，我們有上百臺虛擬機被運維和開發人員同時管理，應用分佈散亂，管理起來既費時又費力，已經是失控的邊緣。擁抱雲原生，使用 K8s 之後，我們採用 DevOps，統一分配資源。釋放了運維人員的生產力，提升了開發人員的開發效率。
初期，我們部署了原生 K8s, 使用原生 Dashboard 運行了一段時間。後來覺得它對用戶的認證方式過於粗放，UI 界面也不太友好，學習成本過高。直到有同事推薦了 KubeShpere，嘗試着登錄他們的官網，瀏覽幫助文檔，登錄社區論壇。 "more then Kubernetes and easier then Kubernetes"——“比 K8s 強大，又比 K8s 易用”從部署到運維體現得淋漓盡致。相對於同類產品的優勢在於國人開發，本地化程度很高，面向開發用戶友好，多租戶的權限細粒度管理，日誌查詢界面便捷，周邊生態整合全面，可靈活配置需要模塊。
目前，我們已經搭建了兩套 KubeSphere 環境。測試環境由 2 臺物理機和一臺虛機構成（1 個主節點 2 個工作節點）。生產環境由 5 臺物理機構成（2 個主節點 3 個工作節點）。藉着最近一個系統改造契機，我們已經把 80% 的應用運行在 KubeSphere 之上，後續的新開發的應用也都會直接部署 KubeSphere 環境上。
實踐過程
KubeSphere 在相關業務的基礎設施與部署架構
我們依託 KubeSphere 部署 Redis、RabbitMq、搭建 Elasticsearch 集羣，Kibana 等。
現在覈心業務的數據庫我們使用的是物理機部署 Oracle，後續的一些輕量級應用我們計劃可以依託 KubeSphere 部署 MySQL。
KubeSphere 在 CI/CD 的應用
由於在使用 KubeSphere 之前，我們已經有一套 CI/CD 流程，所以我們的 Jenkins 和 Harbor 沒有使用 KubeSphere 提供的構建流水線服務，後續我們會進行一些探索，嘗試採用 Helm 構建應用，更好貼合 KubeSphere 的應用市場。
KubeSphere 自帶集羣監控
整體監控
各個節點資源監控
應用監控
應用日誌查看
自定義報警監控
公司業務與 KubeSphere 的契合點
我們項目組成員缺乏 Docker 和 K8s 的使用經驗。KubeSphere 無縫契合 K8s，操作畫面友好，我們的開發人員能夠低成本上手使用 K8s，享受 K8s 帶來的便攜性。
KubeSphere 的多租戶架構與我們集團公司的企業架構一致。架構分三個層級。集羣，企業空間和項目。其中，KubeSphere 中的最底層的項目等同於 Kubernetes 的命名空間。集羣、企業空間是構建在 K8s 的名字空間之上的進一步抽象。KubeSphere 可以爲建立多個集羣，對應一個集團公司，一個集羣下可以建立多個企業空間，對應一個公司，一個企業空間可以建立多個項目，對應公司實際產品線，每個層級的一個實例就是一個 Workspace，其他與同層次其他實例的資源隔離。
落地成效
我們在落地了 KubeSphere 之後，有了以下成效。
- 開發部署環境已經被有序管理。應用都運行在容器平臺中，使用多少資源一目瞭然。
- 運維管理成本降低。統一通過 KubeSphere 登錄容器平臺，不論查看應用日誌，進入容器內部進行操作，修改應用配置都十分便利。
- 服務器資源利用率顯著提高。我們原先使用了 30 多臺物理機來構建我們應用，現在僅使用了 8 臺物理機，解放了大量服務器資源。
- 業務系統可靠性提高。K8s 自帶容器存活探針，當應用無法正常使用給予預警提示，自動重啓容器。以前我們升級應用的時候，一般都會發個通告，暫停業務半小時，現在升級應用對業務幾乎無感。
本文由博客一文多發平臺 OpenWrite 發佈！