美國西部時間 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 公司當前面臨的挑戰為例，對這些問題作出了簡明扼要的總結：
- 存儲系統的多樣化與專業化，使傳統基礎設施複雜度急劇上升。相比於傳統技術架構對存儲系統的單一假設（比如一套 Ceph 打天下），雲時代的軟件架構為用戶的存儲選擇帶來了爆發性的增長。僅以阿里云為例，它在公有云上能夠為用戶提供的各種類型的存儲服務就多達 10 餘中，而其中的細分方案，更是數不勝數。而隨著互聯網公司的基礎架構和軟件規模的不斷擴張和發展，互聯網軟件本身對存儲的需求也更加細化和專業。比如，在 Twitter，這其中，Local Persistent Volume 這種“非典型”的存儲訴求，就逐漸在平衡性能與成本的過程中成為了一種主流方案。而作為 CSI（Container Storage Inerface）的提出者，Kubernetes 社區不僅擁有著最完善裡的 Local PV 機制，還能夠憑藉標準接口和 PV、PVC 體系，完全為用戶抹平其它數十種不同存儲服務的對接問題。這在互聯網軟件架構日趨複雜和麵向多雲的發展趨勢中，無疑是至關重要的。
- Mesos 和 Aurora 體系與“雲原生”始終漸行漸遠。 雲時代一個重要的技術發展趨勢，就是軟件的生命週期會逐步向“生在雲上、長在雲上”的形態靠攏。這也就意味著作為支撐著軟件的核心基礎設施項目，也必然要向“發揮雲的最大價值”的方向不斷演進。遺憾的是，Mesos 以及 Aurora 項目或許是由於發佈較早，始終沒能夠將“雲”變成整個基礎設施體系中的“一等公民”。而相比之下，Kubernetes 體系從發佈伊始就不斷倡導的“聲明式 API”、“容器設計模式”、“控制器模型”等各項理念，其實都是為了幫助用戶能夠在雲上以“可擴展、可複製、高度自動化”方式開發、交付和運維軟件所作出的重要努力。在今天，這些頂層架構設計與各種最佳實踐，就被廣大開發者們冠名為“雲原生”。這也成為了 Kubernetes 項目與其它競爭對手相比最大的不同。
- 傳統的多雲、多集群管理成本居高不下，並在可預見的未來內迅速攀升。在傳統的互聯網架構當中，自建數據中心和基礎設施體系是整個軟件系統的第一假設。而“雲”所扮演的角色，更像是在流量突發時應付峰值的資源“備胎”。在這種以“雲”為輔助角色的指導思想下，多雲和多集群很難成為整個架構的重中之重。這就使得多雲和多集群的能力，成為了底層資源對接層的職責，而與更重要的應用開發、交付和運維體系失去了直接關聯。這種方案短期內固然可以奏效，但長期的維護和迭代的成本卻很容易因為上層應用本身的千變萬化的形態與高速迭代而超出把控。此外，這種設計的另一個極端，就是讓整體基礎設施走向“多活”的技術深淵：這實際上已經遠遠超出了 90% 以上的互聯網公司的技術能力。在雲原生體系開始普及之後，“每朵雲上都有無數個 Kubernetes 集群”逐漸成為了應用基礎設施能夠依賴的新常態。這就為多雲和多集群的管理提供了一種全新的、突破性的思路：只要我的軟件選擇面向 Kubernetes 來進行架構、設計和實現，那麼“多雲、多集群”，就自然而然的成為了我的應用基礎設施的默認能力。在 Twitter 的業務越來越多的需要多雲、多集群環境中交付的趨勢下， Kubernetes 這種從根本上幫助應用迅速向多雲交付的“捷徑”，成為了 Twitter 選擇變更自身技術體系另一個重要原因。
- 作為不斷在快速發展和迭代的互聯網公司，高壓力和快節奏背景下的企業往往無暇顧及基礎設施架構的標準化與兼容性問題。這同樣也是 Twitter 公司面臨的主要問題之一。所以，在這次轉型過程當中，“Kubernetes Native”則成為了一個被反覆強調的關鍵詞。
大規模生產環境的" 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 工程師們實現真正意義上的共贏。
世界級互聯網公司加持的規模化雲原生技術
不難看到，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 項目聯合維護者。
閱讀更多 阿里云云棲社區 的文章
