伴隨著公司業務的快速發展，公司很多業務線的服務架構以及服務運行時環境也有了很大變化。之前的資源管理和應用生產流程主要是半自動化，不管是服務器相應的資源利用率還是技術人員的個人生產力仍然有很大的提升空間。
一、運維面臨的痛點
1、業務的擴展，團隊服務器資源也越來越多，我們常常會聽到這樣的聲音：“我的服務器怎么又卡死了?”、“我點擊開始構建后項目就一直502了?”“幫忙看看，某某項目怎么又掛掉了無法訪問了，我正在測試呢?”
2、在代碼管理方面，沒有較好的命名規范，代碼倉庫沒有友好的UI界面進行管理，我們常常需要對照一個或多個復雜的excel表格來找到那些不常使用的或者近期未開發的項目代碼;
3、本地手工打包，手動創建虛擬機，手工部署和升級，這些重復和低效率的研發部署模式導致開發人員不能高效的專注于業務需求;
4、線上業務在運行時會出現并發問題，根據怎么樣的指標、怎樣去對業務進行擴縮容?業務遷移如何更為高效、準確和快速;
5、在之前項目的運行環境中，我們使用了Rancher1.6版本及其自帶的Cattle作為我們的容器平臺。由于rancher對docker容器的進一層封裝，常常會出現很多問題，例如網絡為什么不通了?dns為什么無法解析等等，這種類似問題的根本原因不得而知。
二、問題分析
首先想到能解決其中代碼倉庫管理的辦法就是將原有代碼倉庫遷移到更為強大的git上，并且制定統一的規范準則。
其次大部分問題的解決辦法最容易想到的就是通過腳本來幫我們做一些手動重復性的工作。沒錯，在前期我們寫了很多腳本，不同服務的運行環境隨著命名的規范也會變得更加統一。但是在需求沒辦法確定的情況下，如何評判腳本的好壞與完整性卻沒有思路，我們只能做到的是腳本如果遇到某個bug那就去改一個版本。
至于Rancher，我們發現在1.6版本之后便丟掉了原有的編排引擎，轉而擁抱的是更為強大的Kubernetes。因此我們決定拋棄Rancher，使用更為原生的Kubernetes容器編排。
三、解決方案
目前，Kubernetes已經成為市場上事實上領先的容器編排工具，不僅對技術公司如此，對所有公司都是如此，因為它支持快速且可預測地部署應用程序、動態地伸縮應用程序、無縫地推出新特性，同時有效地利用硬件資源。
如何用好Kubernetes?應用如何遷移到k8s?對相應技術人員是一大挑戰，因為它更為原生，沒有像Rancher提供的在界面上更為便捷的操作。
最終我們基于現有服務器環境，自建了多套原生且高可用的Kubernetes集群
應用的改造方面，調研并使用了Minio分布式對象存儲，優化統一了應用配置方法和日志輸出規范
應用的遷移與DevOps工作流的實現，基于Jenkins2.X版本開發了多套更為便捷的流水線，真正實現應用的部署通用參數選擇、一鍵快速部署、回滾、擴縮容等更為強大的功能
至今，公司超過80%的項目已經全部遷移且穩定運行在新環境下，回顧過去一年多的成果，為我們帶來了諸多好處：
自動化的集成解放了大量的重復性勞動
更快的交付效果和更快的發現并修復問題
減少了等待時間與人工錯誤
更為持續、穩定的運行環境
。。。。。。
四、下一步規劃
暢想未來，在容器化技術及 Kubernetes 統一的時代，企業應用也逐步向微服務架構轉變，這中間包含著服務注冊、服務發現、服務網關、配置中心、集成框架、分布式事務等等。隨著“云原生”這個概念的誕生和落地，我們會將更多的工作與業務相結合，實現更多更好更強的服務發布方式，根據更多的數據指標和服務中鏈路的追蹤來進一步優化業務，最終實現業務的快速迭代、自動部署、獨立高效。