作者：肖念康，東莞怡合達智能制造供應鏈資深 Java 開發工程師，主要負責公司內部 DevOps、代碼托管平臺、任務需求管理平臺的研發及其他項目的管理，云原生的研究與開發工作。

公司簡介

怡合達致力于自動化零部件研發、生產和銷售，提供 FA 工廠自動化零部件一站式供應，怡合達深耕自動化設備行業，基于應用場景對自動化設備零部件進行標準化設計和分類選型，通過標準設定、產品開發、供應鏈管理、平臺化運營，以信息和數字化為驅動，為自動化設備行業提供高品質、低成本、短交期的自動化零部件產品。

技術現狀

在使用 Kubernetes 之前，公司一直是采用超融合傳統虛擬機的方式來部署上線項目，這就導致公司資源浪費非常嚴重，每年單單在服務器的開銷就大大增加。

項目在上線的過程中出錯的幾率非常大，并且難以排查，沒有一套規范的流程，需要開發人員手動部署，導致人員消耗非常嚴重。

團隊規模

目前公司擁有 3000+ 的員工，其中研發團隊（運維，開發，測試，產品等）超過 300 人，在蘇州，湖北都有研發團隊。

背景介紹

目前行業正在向自動化、云原生靠近，傳統的 互聯網 模式已經無法滿足大公司的業務需求了，為了讓開發人員將更多的精力放在業務上，自動化部署、項目的全方位監控就變得越來越重要。

目前公司云原生是剛剛起步，很多東西需要去探索發現，所以技術上有很多欠缺，需要非常細致的理解各個組件的運行原理和模式。

擁抱云原生就意味著公司的 IT 層面將上升一個等級，原有的項目治理將完全摒棄，將會以一套全新的方式來全方位地治理項目，使用 Kubernetes 和容器化技術將減少服務的運維成本和項目的容錯成本，為客戶帶來的使用體驗也將提升一個層次。

選型說明

1、工具選型的過程

在使用青云 科技 的 KubeSphere 之前，我們也使用了很多其他的項目，如 KubeOperator，DaoCloud，Choerodon 等。但是在使用過程中發現，其他工具的功能并不是很完善，遇到問題很難排查，社區也不是很活躍，這就導致我們的使用成本和維護成本大大增加。

2、選擇 KubeSphere 的原因

我通過博客和論壇發現了 KubeSphere，Issue 的提出與解決非常的完善和及時。KubeSphere 官網有很多案例與講解，社區活躍度非常高。這不正是我想要的嗎？

經過實踐使用 KubeSphere 搭建的集群更加穩定，資源管控更加便捷，與同類云原生產品相比，KubeSphere 幾乎實現了我們在生產環境會用到的所有功能。

于是我們就開始在測試環境搭建并使用，隨后慢慢地向生產環境遷移。目前我們公司有三分一的項目已經遷移到 KubeSphere 平臺上，并且回收了之前的舊服務器，大大提高了資源使用率。

實踐過程

1、基礎設施與部署架構

Kubernetes 與 KubeSphere 的搭建也非常簡單，根據官方文檔先下載 KubeKey， 使用 KubeKey 搭建就可以了。

目前我們使用私有環境來搭建 Kubernetes 與 KubeSphere，因為是在我們內部使用，所以不考慮在云上進行搭建。

基礎服務器采用的是 Linux Centos 7，內核版本是 5.6。

在搭建 Kubernetes 集群時，我選擇使用 Keepalived 和 HAproxy 創建高可用 Kubernetes 集群[1]，其中包括兩個負載均衡入口。

然后是 3 個 Master 節點，3 個 Worker 節點，一個 Etcd 集群，因為是多集群，我會為公司每個項目創建一個集群，所有我們單個集群分配的資源不是很多，當資源不夠使用時需要進行申請。

2、平臺的存儲與網絡

平臺的持久化存儲我們使用的是第三方杉巖，這就需要對方來提供存儲卷和創建存儲系統空間，所以在這里就不做過多介紹。大家也可以使用開源的存儲插件來做，KubeSphere 文檔[2]中提到了很多開源存儲插件，使用起來也非常的方便。

在集群內部我們采用的是 Calico CNI 插件負責集群的內部通訊，當我們的服務部署至 Kubernetes 集群時會產生一個內部訪問地址，這個地址在我們集群內是可以 ping 通和訪問的，但外部無法訪問。

所以在外部網絡通訊方面我做了兩套方案：

考慮到我們之前的項目使用 APISIX 作為網關路由，所以我們就在集群內搭建了 APISIX：

搭建方式也非常簡單，創建一個 APISIX 模板，再創建一個應用就可以了：

創建完成之后集群內的項目就可以使用 APISIX 了，將 APISIX 開啟對外訪問，作為集群的唯一入口，接下來在服務中創建路由，就會在 APISIX 中自動生成一條路由規則與上游服務：

第二種方案則是使用負載均衡器 OpenELB，OpenELB 官方提供了三種模式，我們選用的是 Layer2 模式，因為 BGP 和 VIP 需要機器的支持，就暫時沒有搭建，后續會考慮改用另外兩種模式對外訪問。

安裝和使用也很方便，可以直接在 KubeSphere 應用商店中選擇安裝，也可以在集群中通過 yaml 進行安裝：

但是需要注意的是，通過應用商店進行安裝一定要注意集群的內存空間是否充足，否則會導致集群監控組件異常。

安裝完成之后，我們只需要開啟?strictARP: true，并設置 EIP 池就可以了，然后我們在部署服務時加上注解：

annotations:??lb.kubesphere.io/v1alpha1:?openelb??protocol.openelb.kubesphere.io/v1alpha1:?layer2??eip.openelb.kubesphere.io/v1alpha2:?eip-layer2-pool

將 type 改為：LoadBalance，就會在我們的 IP 池中獲取一個對外訪問的 IP 分配給服務進行對外訪問了。

3、日志與監控

我們搭建了一套 EFK 的日志系統，通過 Filebeat 收集服務端的數據，再通過 Kafka 發送到 es 中，然后通過 Kibana 查詢日志數據，另外我們增加了一套 SkyWalking，它會給我們生成一個鏈路 ID，這樣我們就可以根據這個鏈路 ID 直接查找當前請求下的所有日志。

在監控方面除了 KubeSphere 自帶的監控之外，我們還用了一套外部的監控系統：

主機層面：Prometheus + General

服務層面：SkyWalking

包括服狀態的監控以及所有的告警

4、CI/CD

我們開啟了 KubeSphere 的 DevOps 模塊，里面集成了 Jenkins，流水線的構建，實現了項目從拉取代碼，質量檢查到項目部署一鍵化的流程。

在 DevOps 模塊中用的是自定義 GitLab 倉庫，如果是自己實踐的話可以去 KubeSphere 應用商店中下載使用，在這里我就介紹一下自定義實現。

首先需要打開 KubeSphere 自帶的 Jenkins，進入頁面創建一個 GitLab 的憑證，然后在系統配置自定義 GitLab 的地址。

這里的憑據就是我們剛剛創建的 GitLab 憑據，地址就直接填自己倉庫的地址，然后就可以在 KubeSphere 中看到剛剛填寫的地址了。

我是根據官方文檔[3]創建的流水線，其中有些地方需要自己指定。

在 Jenkins 中是提供一個 Maven，在這里我需要改成自定義的 Maven，不然項目構建的時候會失敗，我們只需要在 configMap 中修改 setting.xml 文件就可以了。

鏡像倉庫用的是自定義 Harbor 倉庫，要在 Harbor 中先創建存放鏡像的地址，然后創建權限，在 KubeSphere 中添加憑證就可以使用了。

在使用流水線之前一定要把 GitLab、Kubernetes、鏡像倉庫的憑證建好，后面直接使用就可以了。

一些前置的條件配置好之后就可以直接去創建流水線了。

運行后可以看到運行記錄。

流水線跑完之后就可以在項目中看到之前部署的項目了。

包括服務和容器組，在里面就可以對項目進行管理了，包括負載均衡，網關，路由，擴容等一些操作。

使用效果

在使用 KubeSphere 之后，我們所有的項目都集中在一起了，管理起來方便很多，服務器的資源也很大程度的減少，在資金方面節省了很多。

項目上線現在只需要創建執行流水線就可以了，再根據定時任務定時執行，并且項目可以自動增加副本，項目啟動失敗會自動回滾到之前的版本。

在業務方面，接口的請求時間降低了，用戶的使用體驗也增加了不少，出現 bug 能夠快速的定位并解決問題。

未來規劃

未來我們將把公司內部系統與 KubeSphere 完全打通，成立云原生小組來負責云原生的研發工作。

公司的服務器資源將完全回收，將會以集群分配的方式管理項目，之后會自研一些插件和組件使用并進行開源。

對于 KubeSphere，我們也有一些建議：

希望文檔能夠在詳細一點，有一些插件的文檔說明只是大概的介紹了一下。

監控面板不是很細致，需要使用自定義的監控面板進行使用。

目前發現告警通知方面只能在通知聚到中配置釘釘一個地址，希望的是在每一個項目中都能夠配置通知地址，這樣每一個釘釘告警通知群就能夠做到互不干擾。

希望 KubeSphere 未來會發展的越來越好！