從 OpenStack 到 Mesos 再到 Kubernetes, 攜程容器雲自動化運維平臺實踐
隨著虛擬化技術和雲端計算技術的普及，IT 網際網路基礎設施發生了很大的變化，底層的計算、儲存、網路等資源也越來越複雜，需要有平臺能管理好這些資源，儘量將工作流程自動化，將運維人員從繁重的手動工作中解救出來。而現在工具的更新迭代也越來越快，如何構建這樣的平臺提高軟體構件和交付的效率也是很多團隊面臨的問題。
InfoQ 記者採訪了攜程系統研發部雲平臺高階研發經理周昕毅，來了解攜程容器雲自動化運維平臺的建設情況。
背景
攜程容器雲自動化運維平臺是攜程容器雲基礎設施的管理工具。攜程容器雲承載著攜程機票、酒店、交通等業務線數千個應用，近 10 萬個容器例項，整體容量年增長率超過 40%。
運維平臺從 2016 年開始建設，主要分為三個建設時期。
-
平臺初期 (2016.01 ~ 2017.01) 主要解決 OpenStack 架構下的運維問題。這個階段平臺提供的能力包括：
- 宿主機的自動上線，
- 平臺監控及日誌收集，
- 故障排查工具、提升工程師排障效率。
這個階段的特點是關注標準化推進，包括宿主機標準化、監控標準制定、日誌標準和規範落地。
- Mesos 階段 (2017.02 ~ 2018.02) 在標準化的基礎上，平臺開始提供 SDN 網路、雲端儲存、容器遷移等自動化工具，管理覆蓋面更廣。
這個階段整個容器雲的容量增長很快，依靠平臺的能力，團隊得以繼續維持容器雲持續高效執行。
- Kubernetes 階段 (2018.03 ~ 至今) ，Mesos 的開源社群活躍度在 2017 年底開始逐步降低，雖然 Mesos 簡單穩定使用起來又熟悉，但是我們發現越來越多的需求需要定製開發，平臺維護成本也變高，並且生產版本老舊，編排能力和正規化弱，升級成本不亞於遷移。
容器雲基礎設施在 2018 年開始全面轉向 Kubernetes。在 Kubernetes 運維管理的基礎上，運維平臺逐步開始提供容量規劃與預警、故障關聯及合併、容器例項自動遷移、應用自動擴縮容等能力。Kubernetes 擁有龐大的生態，遷移到 Kubernetes 也讓未來的技術路線更加清晰。不過 Kubernetes 本身有一定的複雜度，團隊需要時間熟悉，短期內也有穩定性的風險。
自動化運維平臺架構設計
運維平臺搭建初期主要關注三個方面：配置管理、監控管理、日誌管理。
-
配置管理相關工具先後嘗試過 SaltStack、Ansible 和 Rundeck。在大規模叢集管理的實踐中，SaltStack 效能最好、可靠性最高，目前運維平臺使用 SaltStack 進行配置管理，Ansible/Rundeck 相比而言更適合中小規模的平臺管理。
-
監控管理工具嘗試過 Zabbix 和 Promethus，當前使用攜程自研的 Hickwall 監控系統，針對容器監控做了額外的定製開發。
- 日誌管理嘗試了 ElasticBeats、Kafka、ELK 等主流開源工具，目前基於 ELK 給使用者提供了一站式日誌檢索和關聯查詢的能力。
為了將配置、監控、日誌三個模組進行整合，提升工程師日常運維工作效率，平臺引入了 Stackstorm，在平臺建設中貫徹事件驅動運維的理念。Stackstorm 是一個功能強大的開源自動化平臺，可將所有應用程式，服務和工作流程連線起來。它跟傳統化運工具有些區別。我們開發的聊天機器人也可以和 StackStorm 工具做整合，提高排障的效率。
初期運維平臺架構（包括 Openstack 時期和 Mesos 時期）如下圖：
運維平臺通過 SaltStack 進行配置管理，實現配置標準化的落地；其他公司的最佳實踐、Docker/ 核心 /K8S 等版本升級、線上環境出現的各類異常和故障會促使我們不斷修訂運維標準，通過 StackStorm 流程灰度釋出到平臺各套環境中。
經過近三年演進，運維平臺當前架構（即 Kubernetes 時期）如下圖：
圍繞雲平臺三大核心資源：計算、網路、儲存進行統一平臺化管理，實踐資料驅動運維。在應用運維層面，平臺會關注 CPU 和記憶體資源使用率，為應用提供容量建議，並針對符合條件的應用進行自動擴縮容。
網路管理方面，除了網段和 IP 地址的分配管理，平臺也收集丟包、延遲、頻寬使用等監控資料，提升網路服務質量。
平臺建設的挑戰
運維平臺初期建設以開發運維工具為主，解決工作中遇到的實際問題：部分機器配置不統一導致線上出問題，宿主機安裝配置耗時長且需要人工介入，重要告警淹沒在海量的其他告警資訊中得不到及時處理。
隨著時間推進，平臺變得很龐大，工具鏈很多，工程師需要熟悉多個技術棧。因此需要用產品化的思維來進行運維平臺演進，即把運維平臺當成產品來設計，不再堆疊各種工具 case by case 解決問題，而是梳理清楚雲平臺的核心運維管理流程，對未來可能出現的需求進行提前規劃。
經過對需求的整理我們發現，容器雲運維平臺的核心還是在於對核心資源（計算、網路、儲存）進行高效管理。提升資源的交付速度，提升工程師對平臺的控制力，提升平臺基礎設施的穩定性，促進知識分享和沉澱，是運維平臺存在的意義。
在平臺從 Mesos 遷移到 Kubernetes 的過程中，需要做到使用者無感知，IP、源資訊不變，進行跨系統操作，這個過程中的一些要點有：
-
同 AZ 的 Mesos 遷移到 Kubernetes 按物理機維度遷移；
-
拆解遷移過程為多個 checkpoint，支援回滾；
-
使用 Stackstorm 自動化 pipeline。
標準化是自動化運維的基石，其重要性毋庸置疑。我們主要通過工具 + 流程 + 巡檢三套武器來保證平臺的標準化推進。
SaltStack 管控了所有伺服器的核心配置檔案，使用者無法自行修改。SaltStack 配置修改有嚴密的流程，宿主機上下線也有嚴格的流程管控。在此基礎上，我們建設了自動化巡檢工具，定期掃描所有伺服器和核心服務的狀態和配置資訊，一旦有異常立即會發出警告。
自動化運維平臺實踐
攜程容器雲自動化運維平臺的一些基礎運維工作包括：伺服器上下線，生產環境異常排查，服務監控，硬體故障維修，應用效能預警，資源管理，容量管理等。
自動化運維平臺實現了伺服器上下線的自動化，提供工具提升生產環境異常的排查效率，通過運維資料的積累、進行資源使用情況和容量預估。以下是幾個實踐案例。
智慧告警
樣例中的第一種型別的告警比較好理解，監控告訴我們 kube-state-metrics 服務連不上了，隨後又恢復了，這個時候工程師不需要立即響應，可以事後查一下該服務 up and down 相關日誌。第二種型別的告警是在告警發出時，平臺進行了關聯計算，把可能引發該告警的服務 Error Log 傳送在告警資訊中，工程師收到告警後點擊 Error Log 連結可以檢視詳情、快速判斷故障 Root Cause。
宿主機維護、自動上下線、通知相關使用者
隨著平臺規模大了，也會出現硬體故障需要進行宿主機維修的情況，為了給使用者更好的體驗，運維平臺實現了自動化的通知機制，從流程上保證業務執行的持續性和穩定性，有特殊需求的使用者也可以方便的提前介入處理。
容量管理
容量管理往往是老闆比較關心的，因為涉及到花錢。每個季度到底投多少錢買宿主機？動態排程的能力有沒有？應用有波峰和波谷的，儘量把波峰的應用挫開，我們需要對它進行資源使用情況的預判，這樣才能實現彈性計算。
為了實現容量管理我們主要藉助了監控系統、 Hadoop 平臺以及自己運維的監控工具，最終通過 PAAS 平臺實現容器彈性的排程。最終目標是把資源合理利用出去，同時又保證一定的穩定性。
這是我們容量的整體情況，會發現它的記憶體基本上用的非常滿，這個叢集它的 CPU 資源也是用的比較滿，我們會從一些維度去做整體的分析和個別的分析。
自動化運維平臺的規劃
攜程自動化運維專案中嘗試使用了大資料實時計算相關技術 (Spark/Spark Streaming)，並通過資料倉庫建設，相關模型和演算法調整，提升資源使用率和容量預估的準確性。
自動化運維平臺整體設計思路不變，即進一步提升對核心資源高效管理的能力，加速運維工程師知識積累和沉澱。同時需要擁抱新技術，比如 AIOps，通過更強大的工具讓運維平臺有更多的能力。AIOps 概念的產生及周邊生態的活躍，對自動化運維平臺起到很好的促進作用，運維平臺數據和流程的積累可以為後續 AIOps 平臺的建設提供支撐，讓 AIOps 平臺在雲平臺運維管理中落地。
平臺的下一步的規劃是雲原生運維平臺建設，以及混合雲運維管理平臺建設。
寫在最後
線上應用的底層基礎設施變更具有一定風險，需要投入較多人力進行遷移方案設計，“給高速飛行中的飛機換零件”，挑戰在於：執行中的系統給遷移方案帶來了諸多先天限制，原則上只允許成功，不允許失敗。現在雲端計算的發展日新月異，不斷有新的技術和架構出現，各領風騷三五年，要求架構師們具備一定的技術前瞻性和敏銳的嗅覺，同時在設計架構時需要考慮底層變更的成本。在技術和工具的選型上，首先需要明確自己所在組織的實際需求，找到最適合自己的；另外如果使用開源方案，那麼必然要選擇社群活躍度高的。
在 2019 年的背景下，如果沒有歷史包袱的企業進行運維自動化平臺建設，可以嘗試基於 Kuberenetes 進行基礎平臺建設。
從攜程的實踐經驗看，如果從平臺設計之初就考慮相容多種底層架構，那麼遷移就會很順滑。“唯一不變的是變化”。相反，如果設計時就想著一套架構用十年，開弓沒有回頭箭，底層架構的遷移就無法順利進行。
作者簡介
周昕毅，攜程系統研發部雲平臺高階研發經理。現負責攜程容器雲平臺運維，Cloud Storage 及 Cloud Network 基礎設施研發及運維。