美國西部時間 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 打天下），雲時代的軟件架構爲用戶存儲選擇帶來了爆發性增長。而隨着互聯網公司的基礎架構和軟件規模的不斷擴張和發展，互聯網軟件本身對存儲的需求也更加細化和專業。比如，在 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 選擇變更自身技術體系的另一個重要原因。
大規模生產環境的" Kubernetes Native "技術路徑
作爲不斷在快速發展和迭代的互聯網公司，高壓力和快節奏背景下的企業往往無暇顧及基礎設施架構的標準化與兼容性問題，這同樣也是 Twitter 公司面臨的主要問題之一。所以，在這次轉型過程當中，“Kubernetes Native”成爲一個被反覆強調的關鍵詞。在發佈會上，Twitter 公司公佈了選擇 Kubernetes Native 方向的諸多評估依據。
- 良好的開源技術與開源生態；
- 全世界所有的公有云都提供 Kubernetes 服務，不必擔心廠商鎖定；
- 原生具備有狀態業務（Stateful Application）的管理語義；
- 項目本身快速迭代，具有很強創新能力和先進性；
- 具備標準的存儲對接接口，幫助 Twitter 無縫遷移各種現有存儲服務。
最終，Twitter 公司用一句話總結了這次評估的結果：
“我們認爲，使用 Kubernetes 項目作爲 Twitter 公司基礎設施向前演進的核心依賴，將會是一個正確的選擇”。
而在這條演進路徑上，Twitter 也公佈了多項具體的技術舉措，比如：
- 開發 Twitter 專屬的有狀態應用管理控制器（TwitterSet）；
- 開發滿足 Twitter 場景的節點控制器（NodeController）；
- 自定義 Service Discovery 組件以便同 Twitter 自己的流量管理服務對接；
- 編寫兼容 Aurora 語義的作業管理控制器以便將現有的 Aurora 上的業務進行遷移；
- 開發更豐富的應用發佈策略和實例穩定性支持；
- 改造 Aurora 的 DSL 以對接 Kubernetes，集成現有的 CI/CD 系統。
David 表示：“Twitter 公司基礎設施的巨大規模一直不是一個祕密，但至少在今天，規模不再是我們的首要擔心，我們能看到像阿里巴巴這樣的社區領導者正在將更大規模的 K8s 集羣推向生產環境”。
David McLaughlin 宣佈整個遷移計劃將從現在開始一直持續到 2020 年。屆時，整個 Twitter 的技術棧都會運行在以 Kubernetes 爲基礎的容器化基礎設施之上，並且呈現“內部 K8s 集羣 + 公有云 K8s 服務”的多集羣組合形態。
David 最後對Twitter的未來進行總結時強調：在 2020 年，Twitter自己的軟件棧會以“一部分運行在自有 K8s 集羣，另一部分運行在公共雲上”的多集羣形態進行開發和交付。顯然，在思考“如何通過雲來讓自身的基礎設施能力價值最大化、如何讓公司專注於核心業務”這件事情上，Twitter 已經得到一個相對清晰而富有遠見的答案。更重要的是，這個選擇，很可能會使公司與得以擁抱 Kubernetes 的 Twitter 工程師們實現真正意義上的共贏。
世界級互聯網場景加持的規模化雲原生技術
很長一段時間以來，Kubernetes 社區其實經常因爲將規模化的應用場景放置在較低優先級而遭受詬病，這也一直是Twitter等大型互聯網廠商在是否選擇這條路徑上躊躇不前的主要原因。但現在，這個情況正在發生重要的變化。
David 在發佈會上指出：隨着近一年來更多擁有世界級互聯網場景的技術企業已經成功把Kubernetes和etcd項目推向了規模和性能要求極高的電商、離線計算等生產環境，Twitter開始對雲原生技術在自己的大規模集羣中鋪開重新樹立起了信心。
本次發佈會上，Twitter 公司邀請了來自阿里雲容器平臺團隊的工程師李響、張磊、何劍等作爲專題演講嘉賓，分享了過去一段時間團隊在“大規模生產級雲原生技術體系”上的諸多工作。當天應邀出席發佈會的嘉賓還有 Google 公司 Kubernetes 團隊工程技術經理 Jago Macleod 。
發佈會上，阿里雲容器平臺團隊透露下個月即將開源內部錘鍊已久的Kubernetes 高級作業管理集合（Kubernetes Workloads Advanced）：Kruise 項目。Kruise 會充分利用 Kubernetes 的“聲明式 API” 和“控制器模型”，爲用戶提供互聯網場景下“賴以生存”的容器化應用“原地升級”能力，以及更加精細化的業務發佈策略。Twitter、Facebook，Uber，Linkedin，Pinterest 以及 Netflix 等世界級團隊，都會加入到這個創新性的“雲原生作業管理”項目的合作當中。
除了針對互聯網場景的擴展與增強之外，Kubernetes 以及etcd項目本身在規模化與性能提升上的不斷演進，也是能夠讓 Twitter 公司最終從“觀望者”變成“實踐者”的另一個技術原因。對此，阿里雲的嘉賓分享了團隊如何同社區一起，持續不斷的通過優化併發度，減少鎖競爭，提升後端存儲性能等方式將etcd在一百萬隨機鍵值對的寫入完成時間穩定在200s內。與此同時，Google Kubernetes 項目工程技術經理 Jago Macleod 也在演講中介紹了 Google 公司與阿里巴巴在這個領域上正在進行的攻關與合作。Jago說到：在最近一次嘗試中，雙方工程師正在一起爲 K8s 裏海量的 WATCH 操作添加“書籤（Bookmark）”，這將使得這些 WATCH 操作的建立者在重啓之後只需要對“書籤”之外的少數歷史變化進行追溯。在特定情況下，K8s APIServer 的性能會被提高 40 倍以上。
得益於開源社區以及現代化軟件開發與協作模式，Kubernetes項目得以在更多的互聯網級場景的歷練中迎來前所未有的演進速度和高度。在發佈會中，阿里雲的工程師們提到了他們正在開源社區推進的基於“虛擬集羣(Virtual Cluster) ”的 Kubernetrs 強多租戶插件提案。這個設計思想提煉自阿里巴巴內部爲電商租戶交付K8s集羣的經驗與教訓，而由於不需要修改K8s任何一行代碼，這個強多租戶方案正受到社區的強烈關注。目前，Google，RedHat，VMware等都已經加入到了方案的最後細節完善當中，預計本月末會發布第一個正式設計文檔。
Kubernetes，以應用爲中心的“高速公路”
除了技術和架構演進上的考量之外，這次Twitter 公司向 Kubernetes 的“華麗轉身”，還有一個至關重要的非技術因素。
Twitter 公司的快速成長，催生出了其標杆式的基礎軟件團隊，但也反映出一個不得不引起重視的問題：隨着互聯網業務的快速發展，公司的基礎軟件團隊很快就開始超過應有的規模邊界，而相應的投入產出比卻停滯不前。
所以，正如 David 在一開始提到的那樣，過去互聯網企業中“自研（In-house）”爲主的基礎軟件開發和架構思路，正在伴隨着雲計算和雲原生理念的普及發生微妙變化。憑藉像 Kubernetes 這樣的平臺級項目標準，互聯網公司已經能夠以較小的代價將自身的基礎設施向雲遷移。更重要的是，由於 Kubernetes 這個標準層的存在，這種“遷移”本身並不會像 Netflix 與 AWS 那樣形成根深蒂固的廠商鎖定關係，反而會在保留大部分“自研”好處的同時徹底發揮出“雲”本身的價值和多集羣管理能力。這種變革帶來的優勢，會在一個互聯網公司裏的 “AWS 工程師”都變成“K8s 工程師”之後變得尤爲凸顯。
不難看到，Kubernetes 項目正在以應用爲中心，連通“雲”、“應用開發者”與“基礎軟件團隊”。這種“高速公路”般的溝通、連接與交付能力，也正是像 Twitter 這樣快速迭代的互聯網公司思考自己基礎設施架構未來演進方向的重要參考。而這種轉變，也使得 Twitter 這樣一個業務迅速增長的商業組織始終維持一個極小規模的基礎軟件團隊成爲現實。
寫在最後
從最早Mesos“代言人”到如今的全面轉向“Kubernetes Native”，Twitter公司的選擇無疑爲“Kubernetes項目成爲互聯網級基礎設施標準”又增加了一個重量級佐證。更值得期待的是，在已經擁有了電商等頂級互聯網場景的加持之後，Twitter這次全面擁抱雲原生，將很可能再爲“大規模生產級雲原生技術體系”增添一個經典的落地範本。
伴隨着雲計算的進一步普及和像Kubernetes這樣以“雲”爲核心的容器化基礎設施項目的迅速崛起，越來越多的世界級企業開始思考如何藉助“雲”以及雲原生技術來擁抱開源生態和開放的技術標準，準備迎接一個具備強勁的迭代能力的、面向“雲原生”的未來。
作者簡介
張磊，阿里雲容器平臺高級技術專家，Kubernetes 項目聯合維護者。