Twitter 宣佈拋棄 Mesos，全面轉向 Kubernetes

作者 | 阿里雲智慧高階技術專家 張磊

劃重點

• Twitter 的基礎設施從 Mesos 全面轉向 Kubernetes

• 阿里雲容器平臺團隊即將開源 Kubernetes 高階作業管理集合
  

美國西部時間 5 月 2 日下午 7 點，Twitter 公司在舊金山總部舉行了一次技術釋出會兼 Meetup。會上，Twitter 計算平臺（Twitter Computing Platform）產品與技術負責人 David McLaughlin 正式宣佈，Twitter 的基礎設施將從 Mesos 全面轉向 Kubernetes。

Mesos 專案釋出於 2009 年，而 Twitter 公司則是 Mesos 專案的早期支持者和使用者之一。作為世界上最成功的社交媒體巨頭之一，Twitter 公司以其龐大的生產叢集規模（萬級別節點）而備受關注。2011 年，Twitter 公司開始在 Mesos 專案的基礎上開發 Aurora 專案以便同時管理其內部的線上和離線業務，逐步成為 Mesos 社群的代言人。

在持續投入 Mesos 專案近 10 年之後，Twitter公司為什麼突然宣佈全面轉向 Kubernetes 體系？在這個令人矚目的決定背後，是什麼樣的架構和設計支撐Twitter 基礎設施360度的“華麗轉身”呢？

雲時代，Twitter 基礎設施面臨新挑戰

Twitter 公司創始於 2006 年。時至今日，全世界每天都有至少 5 億條推文產生。在過去十餘年飛速成長和海量資料的挑戰下，Twitter 基礎設施架構的演進過程，一直以來都是全世界技術公司眼中的標杆案例。這其中，像 Mesos 這樣優秀的老牌排程框架、 以及像 Aurora 這樣啟發自 Google Borg 配置管理的編排引擎，可謂功不可沒。

事實上，在網際網路級別的技術場景下，依託頂級工程師和成熟技術自建基礎設施，一直以來都是一線非雲網際網路廠商的架構首選。正是在這個過程中，相對成熟並且工作層次較低的 Mesos 專案收穫到了大量規模級生產環境部署案例。

不過，隨著雲端計算的普及和 Kubernetes 這樣以“雲”為核心的容器化基礎設施專案的迅速崛起，這種傳統網際網路基礎技術架構選型方法逐步暴露出很多前所未有的問題。在本次釋出會上， David 就以 Twitter 公司當前面臨的挑戰為例，對這些問題作出了簡明扼要的總結：

1、儲存系統的多樣化與專業化，使傳統基礎設施複雜度急劇上升

相比於傳統技術架構對儲存系統的單一假設（比如一套 Ceph 打天下），雲時代的軟體架構為使用者儲存選擇帶來了爆發性增長。僅以阿里云為例，它在公有云上能夠為使用者提供的各種型別的儲存服務就多達 10 餘種，其中的細分方案更是數不勝數。隨著網際網路公司的基礎架構和軟體規模的不斷擴張和發展，網際網路軟體本身對儲存的需求也更加細化和專業。

比如，在 Twitter，Local Persistent Volume 這種“非典型”儲存訴求，逐漸在平衡效能與成本的過程中成為一種主流方案。作為 CSI（Container Storage Inerface）的提出者，Kubernetes 社群不僅擁有最完善的 Local PV 機制，還能夠憑藉標準介面和 PV、PVC 體系，完全為使用者抹平其它數十種不同儲存服務的對接問題。這在網際網路軟體架構日趨複雜和麵向多雲的發展趨勢中，無疑是至關重要的。

2、Mesos 和 Aurora 體系與“雲原生”始終漸行漸遠

雲時代一個重要的技術發展趨勢就是軟體的生命週期會逐步向“生在雲上、長在雲上”的形態靠攏。這也就意味著作為支撐軟體的核心基礎設施專案，必然要向“發揮雲的最大價值”的方向不斷演進。

遺憾的是，Mesos 以及 Aurora 專案或許是由於釋出較早，始終沒能夠將“雲”變成整個基礎設施體系中的“一等公民”。相比之下，Kubernetes 體系從釋出伊始就不斷倡導“宣告式 API”、“容器設計模式”、“控制器模型”等各項理念，其實都是為了幫助使用者能夠在雲上以“可擴充套件、可複製、高度自動化”的方式開發、交付和運維軟體。如今，這些頂層架構設計與各種最佳實踐，被廣大開發者們冠名為“雲原生”。這也成為Kubernetes 專案與其它競爭對手相比最大的不同。

3、傳統的多雲、多叢集管理成本居高不下，並在可預見的未來內迅速攀升

在傳統的網際網路架構中，自建資料中心和基礎設施體系是整個軟體系統的第一假設。而“雲”所扮演的角色，更像是在流量突發時應付峰值的資源“備胎”。

在這種以“雲”為輔助角色的指導思想下，多雲和多叢集很難成為整個架構的重中之重。這就使得多雲和多叢集能力，成為底層資源對接層的職責，而與更重要的應用開發、交付和運維體系失去直接關聯。這種方案短期內固然可以奏效，但長期的維護和迭代成本卻很容易因為上層應用本身千變萬化的形態與高速迭代而超出把控。

此外，這種設計的另一個極端是讓整體基礎設施走向“多活”技術深淵：這實際上已經遠遠超出 90% 以上網際網路公司的技術能力。在雲原生體系普及之後，“每朵雲上都有無數個 Kubernetes 叢集”逐漸成為應用基礎設施能夠依賴的新常態。

這就為多雲和多叢集管理提供了一種全新的突破性思路：只要軟體選擇面向 Kubernetes 來進行架構、設計和實現，那麼“多雲、多叢集”就自然而然成為應用基礎設施的預設能力。在 Twitter 的業務越來越多的需要多雲、多叢集環境交付的趨勢下， Kubernetes 這種從根本上幫助應用迅速向多雲交付的“捷徑”，成為 Twitter 選擇變更自身技術體系的另一個重要原因。

作為不斷在快速發展和迭代的網際網路公司，高壓力和快節奏背景下的企業往往無暇顧及基礎設施架構的標準化與相容性問題，這同樣也是 Twitter 公司面臨的主要問題之一。所以，在這次轉型過程中，“Kubernetes Native”成為一個被反覆強調的關鍵詞。

大規模生產環境的" Kubernetes Native "技術路徑

作為不斷在快速發展和迭代的網際網路公司，高壓力和快節奏背景下的企業往往無暇顧及基礎設施架構的標準化與相容性問題，這同樣也是 Twitter 公司面臨的主要問題之一。所以，在這次轉型過程當中，“Kubernetes Native”成為一個被反覆強調的關鍵詞。在釋出會上，Twitter 公司公佈了選擇 Kubernetes Native 方向的諸多評估依據。

1. 良好的開源技術與開源生態；
2. 全世界所有的公有云都提供 Kubernetes 服務，不必擔心廠商鎖定；
3. 原生具備有狀態業務（Stateful Application）的管理語義；
4. 專案本身快速迭代，具有很強創新能力和先進性；
5. 具備標準的儲存對接介面，幫助 Twitter 無縫遷移各種現有儲存服務；

最終，Twitter 公司用一句話總結了這次評估的結果：“我們認為，使用 Kubernetes 專案作為 Twitter 公司基礎設施向前演進的核心依賴，將會是一個正確的選擇”。

而在這條演進路徑上，Twitter 也公佈了多項具體的技術舉措，比如：
1. 開發 Twitter 專屬的有狀態應用管理控制器（TwitterSet）；
2. 開發滿足 Twitter 場景的節點控制器（NodeController）；
3. 自定義 Service Discovery 元件以便同 Twitter 自己的流量管理服務對接；
4. 編寫相容 Aurora 語義的作業管理控制器以便將現有的 Aurora 上的業務進行遷移；
5. 開發更豐富的應用釋出策略和例項穩定性支援；
6. 改造 Aurora 的 DSL 以對接 Kubernetes，整合現有的 CI/CD 系統。

David 表示：“Twitter 公司基礎設施的巨大規模一直不是一個秘密，但至少在今天，規模不再是我們的首要擔心，我們能看到像阿里巴巴這樣的社群領導者正在將更大規模的 K8s 叢集推向生產環境”。

David McLaughlin 宣佈整個遷移計劃將從現在開始一直持續到 2020 年。屆時，整個 Twitter 的技術棧都會執行在以 Kubernetes 為基礎的容器化基礎設施之上，並且呈現“內部 K8s 叢集 + 公有云 K8s 服務”的多叢集組合形態。

David 最後對Twitter的未來進行總結時強調：在 2020 年，Twitter自己的軟體棧會以“一部分執行在自有 K8s 叢集，另一部分執行在公共雲上”的多叢集形態進行開發和交付。

顯然，在思考“如何透過雲來讓自身的基礎設施能力價值最大化，然後讓公司專注於更具價值的核心業務”這件事情上，Twitter 已經得到一個相對清晰而富有遠見的答案。更重要的是，這個選擇，很可能會使公司與得以擁抱 Kubernetes 的 Twitter 工程師們實現真正意義上的共贏。

世界級網際網路公司加持的規模化雲原生技術

不難看到，Twitter 公司這次走向 Kubernetes Native背後的技術本質，其實是在最大程度的利用 Kubernetes 專案本身的核心概念與可擴充套件能力取得規模化定製性需求與社群標準之間的平衡。

這同樣也是阿里巴巴正在社群倡導的一條關鍵途徑。從 2018 年開始，阿里巴巴聯合 Google， Facebook，Twitter，LinkedIn，Uber，Netflix，Pinterest 等一大批頂級網際網路公司，在美國矽谷開展起了月度 Web-Scale Meetup，以分享自身實際落地實踐的方式，為更多網際網路場景中的社群“觀望者”樹立信心。

本次釋出會上，Twitter 公司也邀請了來自阿里雲容器平臺團隊的工程師李響、張磊、何劍等作為專題演講嘉賓。同時應邀出席釋出會的嘉賓還有 Google 公司 Kubernetes 團隊工程技術經理 Jago Macleod 。

阿里雲容器平臺團隊即將開源 Kubernetes 高階作業管理集合

釋出會上，阿里雲容器平臺團隊透露下個月即將開源內部錘鍊已久的 Kubernetes 高階作業管理集合（Kubernetes Workloads Advanced) 。Kubernetes 高階作業管理集合會充分利用 Kubernetes 的“宣告式 API” 和“控制器模型”，為使用者提供網際網路場景下“賴以生存”的容器化應用“原地升級”能力，以及更加精細化的業務釋出策略。Twitter、Pinterest 以及 Netflix 等世界級團隊，都會加入到這個創新性的“雲原生作業管理”專案的合作當中。

除此之外，Kubernetes 本身在規模化與效能提升上的不斷演進，也是能夠讓 Twitter 公司最終從“觀望者”變成“實踐者”的另一個技術因素。對此，Google Kubernetes 專案工程技術經理 Jago Macleod 在演講中專門介紹了 Google 公司與阿里巴巴在這個領域上正在進行的攻關與合作。

在最近一次嘗試中，雙方工程師正在一起為 K8s 裡海量的 WATCH 操作新增“書籤（Bookmark）”，這將使得這些 WATCH 操作的建立者在重啟之後只需要對“書籤”之外的少數歷史變化進行追溯。在特定情況下，K8s APIServer 的效能會被提高 40 倍以上。

Kubernetes，以應用為中心的“高速公路”

除了技術和架構演進上的考量之外，這次Twitter 公司向 Kubernetes 的“華麗轉身”，還有一個至關重要的非技術因素。

Twitter 公司的快速成長，催生出了其標杆式的基礎軟體團隊，但也反映出一個不得不引起重視的問題：隨著網際網路業務的快速發展，公司的基礎軟體團隊很快就開始超過應有的規模邊界，而相應的投入產出比卻停滯不前。

所以，正如 David 在一開始提到的那樣，過去網際網路企業中“自研（In-house）”為主的基礎軟體開發和架構思路，正在伴隨著雲端計算和雲原生理唸的普及發生微妙變化。憑藉像 Kubernetes 這樣的平臺級專案標準，網際網路公司已經能夠以較小的代價將自身的基礎設施向雲遷移。

更重要的是，由於 Kubernetes 這個標準層的存在，這種“遷移”本身並不會像 Netflix 與 AWS 那樣形成根深蒂固的廠商鎖定關係，反而會在保留大部分“自研”好處的同時徹底發揮出“雲”本身的價值和多叢集管理能力。這種變革帶來的優勢，會在一個網際網路公司裡的 “AWS 工程師”都變成“K8s 工程師”之後變得尤為凸顯。

不難看到，Kubernetes 專案正在以應用為中心，連通“雲”、“應用開發者”與“基礎軟體團隊”。這種“高速公路”般的溝通、連線與交付能力，也正是像 Twitter 這樣快速迭代的網際網路公司思考自己基礎設施架構未來演進方向的重要參考。而這種轉變，也使得 Twitter 這樣一個業務迅速增長的商業組織始終維持一個數十人的基礎軟體團隊成為現實。

寫在最後

從最早 Mesos “代言人”到如今的全面轉向 “Kubernetes Native”，Twitter 的舉動再一次佐證了“Kubernetes 已經成為容器編排事實標準”這一斷言。更為重要的是，Twitter 這次全面擁抱雲原生，也有望能夠為業界大規模生產級雲原生技術落地提供經典學習範本。

阿里巴巴從去年開始在雲原生生態中投入了大量技術力量，正在逐步成為Facebook、Twitter、LinkedIn、Uber、Netflix、Pinterest 等眾多世界級網際網路公司眼中規模化雲原生技術落地的一位重要引領者。

伴隨著雲端計算的進一步普及，傳統網際網路基礎技術架構暴露出很多前所未有的問題，以及像 Kubernetes 這樣以“雲”為核心的容器化基礎設施專案的迅速崛起，都在促使越來越多的世界級企業開始思考如何藉助“雲”以及雲原生技術來擁抱開源生態和開放的技術標準，準備迎接一個具備強勁的迭代能力的、面向“雲”的數字未來。