公司簡介
作爲物聯網 + 數智化園區一體化解決方案提供商，我們致力於爲大中型園區、停車場提供軟硬件平臺，幫助園區運營者實現數字化、智能化運營。
在使用 K8s 之前我們使用傳統的方式部署上線，使用 spug（一款輕量級無 Agent 的自動化運維平臺） 自動化在單節點完成代碼部署上線，也沒有進行容器化，隨着產品上線提上日程，對穩定性要求提高，以及私有化部署環境管理問題，我們開始使用 Docker 以及 K8s。
背景介紹
降本增效是每個企業的目標，而 DevOps、容器化、雲原生就是研發團隊降本增效的方法論。在這個趨勢下，使用 Docker、K8s 幾乎是每個開發團隊的必經之路。
物聯網平臺對穩定性要求非常高，一旦停機，所有設備都將掉線重連，因此保證服務的穩定性，減少停機時間就非常重要。
在使用 K8s 之前，我們很多時間都要人工處理各種繁瑣重複的服務維護問題，這種枯燥且毫無技術含量瑣碎極大的消磨開發團隊的激情。爲了將人力從大量重複的環境配置、服務維護中解放出來從而提高開發迭代效率，我們就決定全面容器化，擁抱雲原生。
總結來說就是：
- 服務穩定性，自動化運維，減少停機時間；
- 分佈式部署，彈性伸縮；
- DevOps 規範的部署上線流程。
這些問題迫使我們開始調研容器化、Docker、K8s 的應用。
選型說明
由於沒有相關經驗，因此一開始我們就希望找到一款能夠幫助快速上手 K8s 的工具，在調研 KubeSphere、Zadig、Rancher、KubeVela、Kubeadm 等多款工具後，我們最終選擇了 KubeSphere。
選擇 KubeSphere 最主要的原因首先是它的社區活躍，有問題能夠找到解決方案。同時它集成了很多開箱即用的插件如 DevOps，這正是我們所需要的。當然第一眼就選中 KubeSphere 還是因爲它的顏值，能看得出來 KubeSphere 的 UI 是經過精心設計過的，這在開發工具領域中是極爲難得的，從這點上就能夠看出背後的開發團隊對於打造一款基於 K8s 的雲原生操作系統的理念與決心。
使用 KubeSphere 讓我們立馬就擁有了成熟 DevOps 工作流了，而無需額外的搭建成本，這對於我們毫無 K8s 經驗的團隊來說太重要了，極大的降低了上手門檻。
目前我們將所有無狀態應用全部容器化，使用 K8s 負載，提交代碼 Webhook 觸發 KubeSphere 流水線自動發佈，對於不習慣命令行操作的用戶，KubeSphere 後臺能滿足所有需求。
實踐過程
容器化及遷移到 K8s、KubeSphere
第一步就是將應用全部 Docker 容器化，然後使用 K8s 的 deployment 進行部署。實現分佈式高可用的服務部署。
K8s 讓我們輕易的就擁有了一個分佈式高可靠的架構了，分佈式部署從未如此簡單。
創建 DevOps 項目流水線
KubeSphere 的 DevOps 項目不同於常規項目，這是 KubeSphere 中獨有的概念，和 K8s 的命名空間沒關係，流水線可以直接用 Jenkinsfile，也可以用可視化的方式創建，非常方便。
配置好發佈流水線後，對於開發來說只用提交代碼就行了，KubeSphere 會自動幫我們按照預期把應用部署到集羣中，上線前的最後一公里問題被徹底解決了。
管理 Pod
在 KubeSphere 後臺可以直接管理 Pod ，容器信息一目瞭然，還可以直接進入容器，查看容器實時日誌。負載也能一鍵伸縮，輕點鼠標就能夠快速部署和回滾。
日誌和監控方案
由於我們之前就有了 ELK 和 Prometheus、Grafana 了，因此日誌我們只需要將容器內的應用日誌採集到集中的 ELK 上去就可以了。監控也是如此，只需要採集 node_exporter 和業務指標就行了。
如果之前沒有相關方案，也可以直接使用 KubeSphere 開箱即用的日誌監控方案，同樣也是基於 Elasticsearch 和 Prometheus 的。
多租戶資源可視化
企業空間完美契合了多租戶管理，這樣對於私有化部署、資源利用統計都非常方便，同時企業空間下的項目 剛好就對應 K8s 中的命名空間，這讓人非常驚喜，KubeSphere 是緊貼 K8s 標準的，不會增加任何學習使用成本。
集羣狀態和資源用量排行可以直觀看到各節點資源使用情況，方便爲未來資源預算做好規劃。還可以對企業空間進行配額限制，滿足了不同租戶資源控制需求。
存儲
由於我們目前主要是無狀態應用，對儲存要求不高，所以用的是最簡單的方案集中式 NFS，由於是單節點存儲，所以存在單點問題，這個後面可以使用雲廠商的 NAS 存儲或者其它分佈式存儲。
使用過程中遇到的困難及其解決方案
- CI 構建節點配置問題
節點配置至少在 4C·16G ，否則 DevOps Jenkins 可能無法正常運行，這個還是有些佔資源的，建議 使用特定節點充當 CI 節點：爲依賴項緩存設置 CI 節點
- 流水線不響應問題
有時會出現流水線一直等待運行，或者卡住的問題，這通常是構建節點資源問題，我們遇到過前端 node 打包 cpu 佔滿問題，出現這種情況時應該首先檢查打包節點的資源情況，kill 掉佔用高的打包進程就行了。或嘗試重新創建 DevOps-jenkins 負載通常能夠解決問題。有時還需要進入 Jenkins 後臺查看問題（密碼與 KubeSphere 後臺密碼相同）。
- 構建緩存問題
由於 git 緩存問題，所以我們將 jenkins-casc-config.yaml 中定義的 Agent 配置 idleMinutes 改爲一個較大的值，以實現打包 Pod 在構建後不會被刪除。
之所以只能這樣，是因爲 base-n8qkj 的卷 workspace-volume，卷類型是 EmptyDir 臨時的，如果是 HostPath 類型的就好了，這點不知道官方是怎麼考慮的。
- configmap 更新問題
在 K8s 中 configmap 的更新會自動生效，並同步到各個掛載了 volumes configMap 的 Pod 上去，這樣就可以實現配置更新後自動生效而不用重新發布應用。
但是在使用中我們發現存在一個問題，這種生效機制是通過軟連接實現的（改變軟連接指向，刪除舊的文件），而某些應用可能會出現在更新配置時，短暫的找不到文件報錯的問題（phpfpm），所以針對這個情況我們額外做了處理，原理是應用不直接掛載 configMap 了，而是通過另一個容器去掛載 configMap 並處理好穩定的文件後再供目標應用使用。
使用效果
使用 KubeSphere 後我們幾乎就沒再關注過服務是否在線等運維的瑣碎事情了，因爲 K8s 會保證一切按照預期進行，這使得我們的迭代發佈速度大大提高，開發要做的只是提交代碼，其它的一切都不用操心，極大的提高了開發編碼的幸福度和對保障服務穩定的信心。
- 無狀態應用分佈式部署，彈性伸縮；
- 自動發佈，自動化運維，故障自愈；
- 一次構建到處運行，無懼環境搭建。
未來規劃
由於還在逐步學習應用中，目前對 K8s 的應用場景還比較簡單，未來還有很多探索的點，如：
- 存儲上，目前爲了解決 web 無狀態應用 可能也會有臨時文件上傳等需求，使用了 NFS 存儲，這樣多節點 Pod 可以共享存儲，後面可以嘗試使用其它更爲可靠的分佈式存儲。
- 應用上，目前主要是將無狀態應用部署了上來，隨着學習的深入，後面可以將更多的有狀態應用也部署上來。
最後希望 KubeSphere 能夠越來越普及，緊跟 K8s 官方標準，在降低上手門檻、社區、文檔建設等方面不斷取得突破，讓更多的人能夠更快速的享受到 K8s 的好處。
本文由博客一文多發平臺 OpenWrite 發佈！