Twitter 宣佈拋棄 Mesos，全面轉向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 Workloads Advanced）：Kruise 項目。Kruise 會充分利用 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的舉動再一次佐證了‘Kuberentes已經成爲容器編排事實標準’這一斷言。更爲重要的是，Twitter此次全面擁抱雲原生，也有望可以爲業界大規模生產級雲原生技術落地的提供一個經典學習範本。

阿里巴巴從去年開始在雲原生生態中投入了大量技術力量，正在逐步成爲Facebook，Twitter，LinkedIn，Uber，Netflix，Pinterest等衆多世界級互聯網公司眼中規模化雲原生技術落地的一位重要引領者。而伴隨着雲計算的進一步普及，傳統的互聯網基礎技術架構暴露出不少史無前例的問題，以及像Kubernetes這樣以「雲」爲核心的容器化基礎設施項目的迅速崛起，都在促使愈來愈多的世界級企業開始思考如何藉助「雲」以及雲原生技術來擁抱開源生態和開放的技術標準，準備迎接一個具有強勁的迭代能力的、面向「雲」的數字將來。

做者：張磊 阿里雲容器平臺高級技術專家，Kubernetes 項目聯合維護者。

原文連接​

本文爲雲棲社區原創內容，未經容許不得轉載。