公司簡介
某國家級智能網聯汽車研究中心成立于 2018 年，是擔當產業發展咨詢與建議、共性技術研發中心、創新成果轉化的國家級創新平臺，旨在提高我國在智能網聯汽車及相關產業在全球價值鏈中的地位。
目前著力建設基于大數據與云計算的智能汽車云端運營控制中心平臺。推進云端運營控制中心建設的過程中，運控中心平臺的集成、部署、運維方案經歷了 3 代的升級迭代過程。
第一代部署方案是直接將平臺的前后端各個模塊手動部署在自有物理機中，并將物理機托管在 ICT 的機房中。
第二代方案是將物理機集群用 Vmware ESXi 做了虛擬化，平臺前后端各模塊部署在虛擬機，提升了資源利用率，降低了資源使用量。
第三代，目前以容器化的方式部署在公有云的 KubeSphere 集群中。購買公有云的服務器資源，使用 KubeKey 安裝 KubeSphere 集群，應用級服務采用 DevOps 流水線一鍵以容器化方式發布到 KubeSphere 集群中，真正實現了持續集成持續發布。應用研發工程師只需要在自己本地實現 feature 或者 fix bug，然后 commit 代碼到 GitLab，之后通過 KubeSphere 的 DevOps 流水線一鍵發布到測試環境或者生產環境。通過使用 KubeSphere 以容器化的方式部署服務，減輕了各位研發工程師的發布工作負擔，釋放了研發資源。
目前團隊組成：1 名架構師負責架構設計、項目管理等全局工作，4 名研發工程師負責研發工作，1 名 DevOps 工程師負責 DevOps 建設和運維工作，這樣的一個小團隊就可以高效順利完成大系統的建設工作。
背景介紹
云計算的發展已經逐漸成熟，基于云計算的大數據、人工智能行業發展的越來越成熟，汽車領域與云計算、大數據、人工智能的融合創新發展勢不可擋，自動駕駛已經在全球范圍內陸續落地。我國汽車科學家基于我國國情和汽車行業發展趨勢，提出了自動駕駛汽車的中國方案，也即車路協同方案，以彌補國際上單車智能方案的不足。
在這種行業發展背景下，推進建設車路協同的自動駕駛云端運營控制中心是亟待突破的行業共性關鍵技術。
在建設自動駕駛云端運營控制中心的過程中，面臨許多的實際困難，比如軟硬件資源比較緊張，研發人員非常少，建設任務特別繁重，運控中心平臺對車輛側、道路側物理基礎設施的依賴比較種等方面的因素，為了提高有限的存儲、計算、網絡等硬件資源的利用率和減輕有限研發人員工作負擔、高質高效完成運控中心平臺的建設任務，建設團隊的集成和部署經歷了物理機部署、虛擬機部署直到當前的基于 KubeSphere 的容器化部署方案的迭代和升級過程。
選型說明
在研究上云過程中，想過直接購買阿里云的 K8s 集群，但是由于公司本身有一些物理服務器要利用起來，所以就繼續調研，最終選擇 KubeSphere 作為容器化的解決方案。
我們選擇 KubeSphere 的原因有以下幾點：
- 得益于 KubeKey 這個安裝工具，安裝起來更加方便，比以前單純安裝 K8s 要簡便、容易的多。
- KubeSphere 相當于給 K8s 做了圖形界面，從 web 界面打開查看集群狀態，對集群進行運維非常方便，比在命令行下敲命令簡單明了的多。
- KubeSphere 支持流水線功能，在不安裝額外的軟件的情況下就可以實現持續發布功能，持續發布和 K8s 結合在一起，工作起來減輕很多繁瑣的操作。
實踐過程
由于使用 KubeSphere 和 K8s 以容器化方式部署應用對項目組成員來說都是第一次，無論是比較資深的專家架構師，還是各位研發和運維人員來說，都是在做了基本調研和學習后首次使用，所以，我們的應用容器化之路是學習中使用、使用中提高的一個過程。
為了保障最后生產環境的服務容器化后能更加穩定可控，所以我們采取了 2 步走的戰略：
- 第一步，私有云測試環境部署運行以積累經驗。先在測試環境搭建 Harbor、KubeSphere、K8s、Docker，建設測試環境的發布流水線將測試環境的各個服務以容器化的方式部署，讓前后端的六十多個服務在測試環境先以容器化的方式穩定運行，這樣通過測試環境的運行積累經驗，等測試環境的容器云運行比較穩定，各種坑都趟過以后，再開始做生產環境的容器化。
- 第二步，私有云生產環境服務部署。首先在物理機上部署了所有服務，讓物理機上的運控中心平臺穩定運行，以便領導隨時檢查線上平臺運行情況，其次，再做了一份 KubeSphere、K8s、Docker，以容器化方式部署運控中心平臺。這樣雙份的生產環境運控中心平臺，當生產環境容器化的運控中心平臺運行穩定以后，再將運控平臺對外的域名綁定到容器化的運控中心平臺上，逐步停用物理機中部署的運控中心平臺。
基礎設施與部署架構
測試環境和生產環境的 KubeSphere 部署架構基本是一樣的。
集群規劃：
| 節點 IP | 節點角色 | 組件 |
|---|---|---|
| 192.168.16.70 | kp-master01 | kube-apiserver kube-Scheduler kube-controller-manager Etcd |
| 192.168.16.80 | kp-master02 | api-server Scheduler controller-manager Etcd |
| 192.168.16.100 | kp-node01 | Kubelet kube-proxy Docker |
| 192.168.16.110 | kp-node02 | Kubelet kube-proxy Docker |
| 192.168.16.120 | kp-node03 | Kubelet kube-proxy Docker |
| 192.168.16.140 | kp-node05 | Kubelet kube-proxy Docker |
具體部署架構圖如下圖所示：
線上環境參考：
- 有狀態服務主要是一些基礎設施服務，比如 MySQL、Redis、ClickHouse 等這種，對于這些有狀態服務還是采用虛擬機部署。
- 無狀態服務在 KubeSphere 中的服務如下圖所示，包括應用層的前端模塊、后端模塊，都是采用容器化部署的方式部署。
存儲與網絡
運控中心平臺的一些常規的業務數據采用 MySQL 存儲，為了做數據的聚合 OLAP 分析采用 ClickHouse 存儲分析性的歷史數據，采用 Hadoop 和 Flink 對數據倉庫中的數據做分布式的分析處理。采用 ELK 采集了容器集群中的服務日志。
DevOps 方案
測試環境和生產環境都在私有云中搭建，兩套環境基本是完全一致。
項目代碼統一使用 GitLab 進行配置管理，Docker 鏡像采用 Harbor 進行存儲，KubeSphere 中建立 DevOps 項目，在 DevOps 項目中為每一個模塊建立發布流水線。流水線中的每一個環境都由一臺發布服務器上的 shell 腳本具體執行。
使用效果
通過使用 KubeSphere 明顯地減輕了工程師們的發布部署工作負擔，提升了人員生產力和研發效能。研發工程師只需要在本地實現 feature 或者修復 bug，之后 commit 代碼到 GitLab，然后在 KubeSphere 的 DevOps 流水線上點擊運行，發布到測試環境或者生產環境的部署工作就徹底完成了，非常輕松簡單。
通過使用 KubeSphere 以容器化的方式部署服務，最明顯的收益如下：
- 研發工程師在軟件的部署上唯一需要做就是登陸 KubeSphere，點擊運行流水線，極大地減輕了部署工作量，再也不用記憶各種奇怪的命令，省心省力。
- 使用 KubeSphere 和 K8s 的進行應用容器化部署后，優化了硬件的資源利用率，降低了成本。
未來規劃
通過 KubeSphere 的應用實踐，發現 K8s 確實解決分布式微服務系統的很多問題，比如負載均衡、自動擴展等，DevOps 流水線功能尤其實用。
在未來，我們計劃進一步改進運控中心平臺的容器化，將有狀態服務也盡量容器化，并將自動化測試加入到發布流水線中。
本文由博客一文多發平臺 OpenWrite 發布！
)
)
