酌一杯雲之酒，以開源佐之 ——專訪靈雀雲陳愷

雖然我早就和靈雀雲有了聯繫，也有好幾位朋友在靈雀雲任職，不過作為國內新銳雲原生廠商靈雀雲的創始人之一的陳愷，我之前並沒有直接接觸過。雖然我們是初次相識，但是在聊到了開源，聊到雲技術，我們以雲做老酒，以開源為佐酒菜，很快就儼然如同老友般進入了旁若無人的狀態——旁邊的朋友被我們暫時性忽視了，雖然這張合影就是她幫我們照的。 😀

濫觴始於雲計算。

緣起

陳愷和左玥等人在創立靈雀雲之前，他們都曾在微軟 Azure 從事雲計算領域的專業研究。回憶起那時候，陳愷說，那時他們也在想像雲裡面的應用應該長什麼樣子，設計最早版本的「雲服務模型」、「雲服務運行時」，而現在回過頭看，其實雲計算的發展已經千差萬別。

2013 年 Docker 出現以後，左玥和陳愷他們第一時間就意識到容器技術會很有影響力，它重新了定義雲技術之後發展的路徑，這恍然在他們面前掀開了一個新的時代，於是靈雀雲誕生了。

雲技術領域發展演變的非常快，事實上，在雲計算早期並不能預見到如今的雲計算格局。「早期我們嘗試過很多東西，總的想法是覺得容器就像是一種輕量級虛擬機，一種新的虛擬化技術。就像虛擬機需要虛擬機平台去作為它的管理平台一樣，容器也需要一個容器雲平台，所以我們早期想做的就是容器雲平台，這一點一直沒變，現在也是在做企業級的容器平台。」陳愷說，「我們最早的技術選型是 Mesos 技術棧，經歷了幾次大的改變，包括從 Mesos 轉到支持當時的三種主流的調度系統，然後開始傾向於Kubernetes，到最後全面轉向 Kubernetes，以及最近在架構上和 Kubernetes全面對齊，把我們的平台做成一個 Kubernetes 原生的平台，技術上一直在做升級。」

雲原生吞噬一切，Kubernetes 編排一切

不知不覺之間，雲原生已經吞噬了整個世界，如今，雲原生已經是技術界最時髦的辭彙之一。而應運而生並推動了這一切發生的雲原生計算基金會（CNCF）也在不同的時期、不同的場所，對雲原生做了不同角度的解讀。那麼作為一家很早就涉入雲計算領域的新銳力量，陳愷對雲原生的理解是什麼呢？

陳愷說，「CNCF 旗下涵蓋這麼多雲計算的技術、產品和服務，所以它對『雲原生』的定義必然會比較寬泛，但的確，『雲原生』不是一個特定的技術或者一種方法，很難把它精確的定義，也不應該把它和具體的技術對等，比如說把它直接跟 Kubernetes 掛鉤，跟 Kubernetes 沒關係就不是雲原生？跟 Kubernetes 有關係就叫雲原生？這兩者都是不對的。」

他接著補充說，「我對雲原生定義的觀點也是比較寬泛的，（雲原生）就是讓應用能夠最大化的釋放雲計算生產力的一系列的思維方式、最佳實踐和技術體系，這裡的關鍵詞是讓應用去釋放雲計算最大的生產力。這是關鍵。所有的雲原生我覺得都是首先應該圍繞應用的。什麼叫『雲原生』？主要是以應用為中心的。『原生』這個名字看起來起的不是很好，聽上去似乎是只有在雲上生出來的才叫『雲原生』，或者只有在公有雲上才叫『雲原生』，並不是。關鍵不是說你在哪裡跑你的應用，而是你是不是能夠釋放雲的生產力——廣義的雲的生產力。」

在容器編排市場尚三分天下的時候，很多容器服務商都同時支持三種主流的編排系統，當時有一些觀點認為這種三分格局會持續比較久，然而 Kubernetes 迅速崛起，很快就一家獨大地統治了容器編排市場。

陳愷說，「我覺得當時 Kubernetes 可以很快的從編排之爭當中勝出，並沒有那麼讓人吃驚。為什麼我們比較早的時候就開始往 Kubernetes 發力？其實第一個觸發的點比較偶然。那時經常會有人問起三種容器編排系統各自的優勢是什麼？我們做了一些研究，業界有一些對比，當時我印象比較深的是一個細節，我覺得這才是關鍵——有一項對比的是基於這三種技術有哪些商業版？基於 Docker Swarm 的有一個商業版 Docker EE；Mesos 有一個商業版 MesosPhere；基於 Kubernetes 有好多商業版——這是本質的區別。這一點對它們的社區的發展速度和後續影響很廣，因為它是開放式的治理。Kubernetes 雖然是谷歌發明的，但是它是開放式治理，背後有很多商業版。如果從開源軟體本身社區發展角度看，很關鍵一點是上面有多少商業版，商業版越多說明從開源軟體裡面可以獲利的公司越多，這樣就有了正向的良性循環，會有更多資源投進來，社區裡面參與的人就會更多，最後的發展會更好，生態會很繁榮。當時從這一點我們就覺得這個生態肯定會贏。」

Kubernetes 一統容器編排市場的今天，業界一些專家對此有所憂慮，擔心這種壟斷會形成市場壓制。從長期來看，如果 Kubernetes 的發展會形成類似 Android 一樣的巨頭化，那麼作為下游廠商，靈雀雲是如何看待和應對這種發展變化的呢？

陳愷說，「回到壟斷這個問題，如果是商業軟體的話會有壟斷這個問題，如果是開源軟體的話，它的治理模式有可能是封閉式的，也有可能是開放式的，而 Kubernetes 是一個開放式的治理模式，會有一些廠商有更大的影響力，但不是被一家完全控制，所以我覺得從這個角度來說，談不上壟斷，更多的是一個標準。它可能更多像 Linux 而不像是 Android。從標準的角度來說，肯定是利大於弊，而且是遠大於弊。因為有了標準，大家都圍繞著標準做投入，風險就大大降低，可以放心去投入，也就會有越來越多的技術廠商會向它靠攏。」

靈雀雲的 Kubernetes 生態

靈雀雲在圍繞 Kubernetes 生態方面也做了自己的發行版，他們是如何在符合 Kubernetes 標準的基礎上形成差異化的服務和產品的呢？

「Kubernetes 發行版首先必須是跟 Kubernetes 兼容的。在 Kubernetes 上可以增加各種各樣的能力，但它本身的第一屬性一定是一個真正的 Kubernetes。如果為了做差異性，把它做得不像 Kubernetes，不兼容會是個很大的問題。」陳愷說，「我們走的比這個更深一步，我們的 ACP 2.0 是把整個平台都做成 Kubernetes 原生的，因為 Kubernetes 本質上是聲明式 API 加上基於控制器模型的架構設計範式，容器編排相當於它的一個副產品，是它基於這個架構的一種應用，當然也可以把這種架構應用到對任意資源的編排。前一段時間有一篇很多人轉發的《Kubernetes 編排一切》的文章，講的就是這個事情，它不光可以用來編排容器，可以做各種各樣的事情。我很贊同這個觀點。」

靈雀雲是從 2017 年底的時候決定這樣做的，當時的做法是一些新的產品開始在新的架構上做一些實踐，比如 DevOps 平台、基於 Istio 的 Service Mesh 等產品，完全基於新的架構來做。今年年初，靈雀雲認為所有方面都成熟了：第一，方向肯定沒問題，Kubernetes 編排一切；第二，對如何基於 Kubernetes 的架構構建上層產品有了更多的經驗和體會。靈雀雲於是把以前產品上的所有功能都逐漸遷移到 Kubernetes 原生架構上，重新融合到統一的架構裡面，這就是 ACP 2.0。在此之上靈雀雲還做了一些差異化。

靈雀雲在這裡的技術棧分為三層：

最底層的產品是一個 Kubernetes 發行版，Kubernetes 是一個開源的技術，並不是一個平台，大多數企業做不到直接把它當一個平台用。靈雀雲的做法是將 Kubernetes 技術變成一個企業就緒的 Kubernetes 發行版。

再往上是 ACP 層，定位是雲原生應用賦能平台。包含有三個子產品：容器平台、DevOps 平台和基於 Istio 的 Service Mesh 產品。容器平台和發行版最接近，但對發行版進行了大量擴展，比如在發行版之上增加了多集群管理和企業級多租戶。ACP 把單一的 Kubernetes 集群變成企業平台級的產品，經過了三年多 100+ 企業客戶生產環境的考驗，而且考慮到更多開發者的場景。DevOps 也基於 Kubernetes 原生，用 Kubernetes 去編排所有的工具，定位是一個開放式 DevOps 工具鏈集成和編排的平台。

在此之上還有一層是靈雀雲新的 ACE 3.0，它的定位是一個企業級的 PaaS 平台，或者用現在更時髦的說法，可以稱之為企業技術中台，集成了更多企業需要的其他服務，比如第三方的中間件、開發框架等。它是個完整的技術中台，以容器平台為底座，以雲原生黃金三角為核心，其他服務在上面做成一個個插件。這部分主要是和生態合作夥伴合作，國內外的一些最優秀的 PaaS 類服務都可以放在裡面，為企業提供完整的解決方案。

雲原生之於微服務和 DevOps

我們知道微服務、DevOps 等模式在雲原生概念發展起來之前就已經存在，但是隨著雲原生的發展，似乎給它們注入了更多的活力。

陳愷認為雲原生顯著地推動了 DevOps、微服務的發展，對於這一現象他還專門用了一個辭彙來形容：後 Kubernetes。這是在容器和 Kubernetes 出現之後開始對 DevOps 側的微服務反過來的助推。

他認為，微服務架構的本質是用運維複雜度為代價去換取敏捷性。企業至少要考慮兩件事：第一是否真的有這麼高的敏捷性需求，值得用那麼大的運維代價去替換，第二，假設你有著敏捷性需求，那麼多出來的複雜度怎麼辦？早期微服務落地會很痛苦，因為大家沒有準備好怎麼去應付這個複雜度，而且會低估它。這複雜度是未知的，用未知的複雜度去替代已知的複雜度，這通常都是不好的，所以才會有各種各樣的治理框架出來。其實它需要底下有一個好的基礎設施來支撐它。

容器和微服務天生一對，容器 Kubernetes 的出現，對微服務有非常明顯地推動。Kubernetes 作為底層的應用管理平台非常合適，而且很多微服務裡面要考慮的與業務無關的能力也可以慢慢推到 Kubernetes 裡面去。而進一步，Service Mesh 等其上的技術棧就重新定義了微服務技術棧，微服務治理方式發生了變化，反過來作用到微服務上，形成了新的最佳實踐。

因此，要做微服務應該先容器化，才能解決運維複雜度的問題，容器化的服務應該跑在 Kubernetes 之上；如果進一步做服務治理，應該往 Service Mesh 方向走，Service Mesh 是基於 Kubernetes 平台的微服務治理的最佳實踐。

雲原生之於 DevOps 也是如此。早期大家很多的精力在持續集成上面，比如 Jenkins 最初是作為 CI 工具出現的，而有了容器和 Kubernetes 之後，持續集成變得簡化了，最終生成 Docker 鏡像就好。重心開始轉到部署，轉到 CD 上。而且，現在的 DevOps 實踐或 CI/CD 通常會把 Kubernetes 作為最重要的部署目標。也就是說CI會圍繞容器鏡像，CD 會圍繞 Kubernetes。這是容器和 Kubernetes 帶給 DevOps 的影響，基礎設施越強大，對 DevOps、微服務就越有幫助。以 Kubernetes 為核心的基礎設施變成新的標準，DevOps 和微服務的一些最佳實踐都會圍繞它去改變。

源於開源，茁壯於開源

雲計算構築在開源之上，靈雀雲的基礎設施和服務也構建在開源之上，那麼靈雀雲是如何擁抱開源和貢獻開源的？

陳愷說，「有幾個開源社區跟我們是非常相關的，最早的時候是 Docker 社區，現在 Kubernetes 則是跟我們關係最大的開源社區。我們核心的產品是容器、DevOps 和微服務三部分。Jenkins、Istio 等相關開源項目是我們的重點，我們非常重視在開源社區的投入。我們的許多工程師會參與其中，對社區進行貢獻，也會開源一些項目，我們在一步一步持續地做這件事情。我們首先會選擇一些偏底層的技術或者機制，選擇那些有足夠亮點，真的被需要的項目和技術開源出來。」

目前靈雀雲已經開源了的項目，包括基於 OVN 的網路插件 Kube-OVN，它是把 OVN 的網路和 Kubernetes 所集成的網路插件。現在該項目在國內外都受到關注，也有來自外部貢獻者參與。另外一個開源的項目叫 Captain，是一個基於 Helm v3 標準的 Kubernetes 控制器，對 Helm 應用分發進行改進。

後續靈雀雲還計劃將更完整的東西放出來，比如靈雀雲的 Kubernetes 發行版，供社區用戶用來管理自己的 Kubernetes 平台，可以達到和使用靈雀雲產品接近的體驗。另外靈雀雲也計劃將其 ACP 釋放社區版或者開源版本出來。陳愷說，「我們很樂意把它開源出來，因為這是一個標準的產品，我們讓它較早期的接觸更多用戶，也能得到更多反饋，甚至吸收一些外部的貢獻者參與進來。」

尾聲

我採訪過很多技術領袖和技術專家，不過陳愷的這場採訪讓我有一點不同的感受。一場對話下來，陳愷給我的感覺如同多年的老友一樣言無不盡，而他對於我提到的每個話題，都非常認真、仔細的做了闡述，讓人感到濃濃的專業技術風格。我想，這就是陳愷的技術初心，也是靈雀雲一直以來的風格吧。

「穿山甲專訪」欄目是 Linux 中國社區推出的面向開源界、互聯網技術圈的重要領軍人物的系列採訪，將為大家介紹中國開源領域中一些積極推動開源，諳熟開源思想的技術人，並辨析其思考、挖掘其動因，揭示其背後所發生的事情，為關注開源、有志於開源的企業和技術人標出一條路徑。

取名為「穿山甲」寓意有二：取穿山甲挖掘、深入之意來象徵技術進步和表徵技術領袖的作用；穿山甲是珍稀保護動物，宣傳公益。

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive