容器叢集管理系統與容器雲平臺的選擇非常重要，因為容器管理系統是否先進智慧、容器雲管理平臺是否靈活易用且高效，直接影響企業開發運維的效率與速度、資源利用率的高低。

在這個競爭激烈，風雲突變的時代，應用的開發效率、穩定性、擴充套件性和安全性，決定了企業的競爭力與市值。

當下，K8s 憑藉在擴充套件性、管理、大資料分析、網路場景、相容性、負載均衡、灰度升級、失敗冗餘、容災恢復、 DevOps 等方面的優勢，受到部分企業的青睞。

近日，由 51CTO 主辦的第十六期以“Tech Neo”為主題的技術沙龍活動中，來自陌陌科技 SRE 團隊負責人王景學分享了陌陌在 K8s 容器方面的一些應用實踐。

為什麼選擇使用 K8s？

在使用 K8s 之前，陌陌在應用釋出和執行環境方面遇到的具體問題，如下：

• 應用釋出時間很長，主要是因為釋出過程中需要做隔離、恢復等動作，還需要登入檢視實際狀態、日誌。
• 當遇到晚高峰情況這樣的突發狀況，需要緊急擴容。這時業務方會申請機器，可新機需要進行環境初始化、相關配置，這樣導致效率非常低。
• 應用執行環境的軟體版本不一致，配置複雜，維護成本比較高。
• 硬體資源利用率不足，總體成本比較高。

針對以上遇到的問題，我們決定對架構進行改造，同時制定了一系列架構改進目標，如下：

• 提高服務可用性，可管理性。可用性是當某一臺機器出現宕機，會自動切換到其他機器；可管理性是在應用需要擴容時，自動化去部署執行環境、相關配置。開發不需要再去考慮伺服器的問題。
• 提高資源隔離性，實現服務混合部署。
• 應用級別的監控，當機器需要擴容時，自動排查是哪個應用所致。
• 服務平滑遷移。

綜合這些問題和目標，陌陌選擇使用 Kubernetes 來管理 Docker 叢集，當 Kubernetes 滿足不了需求時，可在部署平臺開發相應的功能來滿足開發檢視日誌、監控和報警等需求，儘量避免登入主機和容器。

陌陌容器管理平臺的架構演進

陌陌從 2015 年下半年開始對 Docker 進行調研和實踐，2016 年初開始調研 K8s，嘗試架構方面的改進工作。

基於自研發布系統及 K8s、OVS 和 Docker 構建容器管理平臺，實現了基於 Docker 叢集的部署系統，便於開發者便捷地部署自己的應用程式。最終達到部署環境乾淨一致，可重複部署、迅速擴容和回滾。

如下圖，是容器管理平臺的架構圖：

容器管理平臺主要功能有叢集管理和狀態展示、灰度釋出和程式碼回退、元件模板、應用管理、映象倉庫和許可權管理等。

它採用前後端分離的架構，前端使用 JS 渲染，後端使用 Python 提供 API。這樣開發者可以快速的進行釋出和回退操作。

容器管理平臺在應用釋出流程、叢集排程策略、K8s 節點網路架構、阿里雲支援、基礎監控指標等方面進行了優化改進。

應用釋出流程

陌陌之前老版本釋出系統是序列的，需要單臺進行替換。如下圖，是新架構下應用的釋出流程：

新的釋出系統是使用者提交程式碼後，在釋出系統選擇要部署的 commit，點選構建以後，系統會自動編譯，打包成映象，推送映象倉庫。

如果構建成功，使用者點擊發布新版本的例項，灰度沒有問題，全量，下線老版本的例項。

回退時程式碼不需要構建，直接釋出老版本例項。在某段時間內，新老版本是同時存在的。

叢集排程策略

陌陌的叢集排程策略是為應用配置預設的 location（叢集標籤），如果是線上應用，應用需要申請 location，部署到正式的叢集（機房要求，資源充足）。

這裡應用都不能獨佔叢集，均採用的是混合部署的方式。同一個叢集下，分成不同組並組定義標籤，應用支援獨佔機器，同一個組之間的應用例項可以隨意飄移。

IDC 網路節點

在 IDC 網路節點構建部分，陌陌使用的是全域性 IP 地址，容器與容器之間、容器與主機之間都是互通的。

這樣一來，通訊可以不使用任何封裝等技術，相對來說比較高效且對現有網路變動影響小（僅需封裝 trunk，無其他協議，mtu 等變化）。

如下圖，是 IDC 網路節點架構圖：

在這樣的架構下，網路部署和擴充套件相對簡單，因為每臺機器的 IP 地址段是預先靜態配置的。

這裡值得注意的是，伺服器雙鏈路上聯，trunk 上聯物理交換機需要合理避免二層環路。

這樣的方式存在的不足是，當容器較多時，mac 地址數量增多，給物理交換機 mac 地址錶帶來壓力，廣播域擴大就是需要嚴謹的規劃 vlan 角色相關資訊。

阿里雲支援

當前，陌陌 K8s master 叢集下節點包含 IDC、阿里雲及兩者混合三種方式，如下圖：

阿里雲採用的網路模式是 Host-gw，陌陌搭建了一條 IDC 與阿里雲的 VPC 專線和 VPC 的虛擬路由進行靜態配置。

無論是 IDC 節點，還是阿里雲節點上的應用都要適應 IP 動態變化。

基礎監控指標

陌陌的監控方案大多是基於 Kublet cadvisor metrics 介面去做的資料彙總。

最初陌陌採用的方式是利用 Python 指令碼，去呼叫介面，在取到一些 CPU 記憶體、網路、流量的資料，存入 ES，分析之後進行展示。

之後的報警系統，是利用 Java 應用去調取 Kublet cadvisor metrics 介面，進行資料的收集。

基礎監控指標主要有記憶體(total，rss，cache)、流量(incoming，outgoing)、網路 packets(drop，error，total)等。

應用遷移

應用遷移方面，陌陌做了很多適配工作，使得應用不需要太多的改動就可以無縫遷移。

具體適配細節如下：

• 應用適應動態 IP 變化。
• 自定義構建過程（build.sh）。
• 應用使用不同的服務發現框架（nginx，rpc）（start.sh）。
• 應用銷燬過程中做一些額外處理(stop.sh)。

在應用遷移過程中，也遇到了一些問題，如 Swap、CPU 軟中斷優化、資源利用率、IP 白名單、適用於內網等問題。

當前，陌陌的容器業務規模伺服器約 400 臺、線上容器 6000、應用 700+。應用的型別是 Java+PHP+Node+Python+Tomcat。

未來展望

希望運維可以實現對應用請求量，執行緒數，流量等指標的監控。基準值部分，達到單例項可承載請求量，執行緒數，流量。

伸縮方面，做到最小保留例項數，最大擴容例項數，根據監控反饋和基準值計算需要擴容和縮容的例項數，按照各個叢集資源餘量按比例伸縮。

作者

王景學

北京陌陌科技有限公司 SRE 團隊負責人，做過運維相關的工作，對自動化、虛擬化、Docker、K8s 等都非常熟悉。

原文來自微信公眾號：51CTO技術棧