UCloud葉理燈談：Docker、K8S和Serverless

前段時間，筆者參加了UCloud 在京舉辦的 TIC 2019 大會，適逢 UCloud 實驗室負責人葉理燈的演講結束，就容器計算方面和他進行了短暫溝通。葉理燈是國內在雲計算方面有深入研究和實踐的資深專家，我覺得他的一些觀點和看法值得分享給大家了解。

葉理燈，UCloud實驗室負責人

葉理燈，UCloud實驗室負責人。現負責 UCloud 創新產品研發，專註面向企業的雲計算產品的研發及運營。葉理燈擁有 10 年以上豐富的互聯網研發經驗，先後任職於騰訊、盛大雲等互聯網公司，從事海量分散式後台系統研發及運營工作。

定製違背了K8S初衷，提供原生K8S產品

記者：在官方的K8S 發行版之上，各方雲廠商提供K8S服務時都有一些自己的定製和調整，今天大會上提及的 UCloud的K8S 發行版 UK8S 主要做了哪些定製，有什麼特色呢？

葉理燈：如果說定製K8S的話，其實是違背了K8S的初衷。我們並沒有定製K8S，我們是基於公有雲給用戶提供了原生的K8S 產品。在公有雲上提供原生的K8S，其實要做很多的工作，例如與公有雲的計算、網路和存儲的整合，給用戶提供一個開箱即用的原生K8S集群等等。

我為什麼說不應該定製呢？因為大家知道PaaS發展到今天，一直存在的一個問題就是供應商綁定的問題。而K8S之所以那麼有生命力，之所以迅速流行，是因為它提供了一個開源的標準，讓用戶使用 K8S PaaS平台，可以避免廠商綁定。也就是說你的服務在某個服務商的K8S上運行，可以無縫的遷移到另外一個服務商。

作為雲廠商其實最重要的工作是，基於我們自身雲平台的體系，提供原生的K8S給用戶使用，幫助他們減少在集群管理和資源整合方面的工作和投入。例如，我們網路能力、存儲能力和計算能力的整合，就是讓用戶享受到原生K8S的好處，同時避免了很多運維的負擔。

公有雲的K8S處在底層IaaS和上層應用之間，一方面向下整合IaaS能力，一方面向上託管客戶的應用。在整合IaaS方面，不改變K8S原生特性，因為K8S本身架構足夠開放，例如在我們實現的網路插件，是基於我們IaaS的VPC網路，讓pod可以和我們託管區和物理雲區域打通，這是我們IaaS能力在K8S產品上的體現，算是我們的特色之一，但這是在K8S體系支持下的插件方式實現的，不影響我們提供原生K8S；在應用層面，廠商也可以基於 K8S 提供一些周邊的功能以幫助用戶提高效率，但它和提供一個一致的K8S環境不矛盾。

另外一方面，如果說定製的概念是指基於K8S本身開發體系所提供的插件機制去做二次開發，那每家廠商都要定製，因為K8S本身不是一個產品級就緒的環境，需要使用者去適配網路和存儲還有計算，因為每個公有雲廠商基於自己的IaaS去提供K8S產品，必然要去開發插件。

綜上，向用戶應該提供原生的、標準的 K8S 產品，但底層應該基於自身 IaaS 平台去定製，本質還是為了提高用戶使用 K8S 的效率，讓用戶開箱即用。

K8S落地挑戰：改造成本和人才問題

記者：你覺得目前國內雲廠商提供的K8S集群編排服務在推廣方面目前欠缺的是什麼？是什麼阻礙了客戶進一步去使用這些容器集群服務？

葉理燈： K8S以容器技術為核心、以容器鏡像為打包標準的特點，意味著如果要遷移到這個體系下，客戶需要將軟體做容器化打包和微服務改造，這個是有成本的。K8S的特點決定它是運維和研發之間的橋樑，這樣就要求公司的研發過程需要跟著改造。我們看到很多公司的運維人員有動力去推動，而研發人員則沒有動力，因為它改變了研發的習慣和流程，增加了負擔；當然也有的公司是研發希望用K8S管理應用，而需要運維跟著變。這樣導致遷移到K8S的工作較重，但一旦這個階段過去了，遷移後的效率和成本優勢就體現出來了。

因此，這是個新技術落地的問題，涉及到用戶教育和習慣的改變，這個需要社區和商業公司一起完成。而且每家公司的技術路線和文化不一樣，上K8S的路徑也不一樣，所以沒有一個放之四海皆準的最佳實踐，但隨著容器和微服務逐漸落地，K8S作為事實標準，會逐步普及。

除了改造業務的成本，另外一方面是K8S人才比較缺乏，不同用戶的情況不一樣，有些用戶的運維人員本來就很少，不可能專門抽出一兩個人去做K8S，以及用戶又擔心它出問題誰來幫我解決？其實，應該是雲廠商再往前走一步，除了幫用戶構建一個K8S平台，還要幫助解決很多技術上的問題。 UCloud現在就是這麼做的，一個用戶進來，我們會拉一個群，他們所有技術問題我們幫他們解決。在落地方面，在人才和K8S本身對用戶架構改造方面，我們可以多做點工作，幫助客戶培養K8S的運維人員和為用戶制定架構遷移的方案。但我相信隨著技術的發展和普及，越來越多人懂K8S。

最後，K8S本身也在發展，K8S剛推出的時候是為了讓大家重新面嚮應用來運維，但是大部分用戶用K8S同時管理集群里的節點和應用，就會同時有兩個負擔。我覺得目標應該是用戶直接拿一個容器就可以跑起來，而不用知道它的節點在哪裡，即Serverless形態。一旦這種技術更加成熟，對容器技術的落地也有很大的推動作用。另一方面，Serverless 形態也給用戶節省了大量的成本，按需付費，免去用戶的運維成本。我覺得K8S的落地已經是個趨勢了，是不可避免的，但是K8S本身是要往前進步，它的革命還沒有完成。

容器與Serverless：覆蓋場景不同，非替換關係

記者：你覺得現在目前Serverless的發展對於容器這種創新技術的迭代升級有什麼影響？是不是可以讓容器更加的輕量化？

葉理燈：不完全是這樣，其實Serverless剛出現的時候是針對計算的。計算分很多層次，有物理機、虛擬機、容器和Serverless。Serverless剛出來的時候，它等同於FaaS，有一個對標的產品叫Lambda。

Serverless出現的動力是，由於雲計算的發展，帶來了如對象存儲等很多豐富的中間件，Serverless概念的提出是希望應用開發者可以不用寫後端邏輯，直接把邏輯寫在客戶端，組合雲上的一些服務來完成業務邏輯，這樣就沒有管理後端資源的負擔了。但是後來發現很多時候還是需要後端代碼的，所以就演變成如果有後端代碼，就拆成函數，託管在FaaS服務中，這樣的話，你依然是不用管理伺服器的，你用的還是一個個服務，沒有伺服器管理負擔。

這個概念在不斷進步，2017年的時候 AWS 提出了一個新的概念，重新定義了什麼叫Serverless，只要一個服務具備了四方面特性：免運維、按需付費、高可用和自動擴容，這個服務就是個Serverless的服務。所以Serverless這個概念可以對應FaaS，也可以代表一種架構，也可以代表一種服務的形態，例如Aurora Serverless就是把一個資料庫的服務變成Serverless的。

容器和Serverless的區別在於，Serverless是無容器的，除了不關注伺服器，也看不到容器。兩者是面向不同場景的，並不是互相替代的關係。FaaS的特點，接收一個請求拉起一個函數執行，函數是無狀態的，它的執行地點也不固定，這意味著延時相對於常駐進程要高，對一些延時敏感的地方它是不合適的，但是有些場景是非常合適的。我舉個例子，在IoT場景中，有幾十萬的設備，為了節省電源，它們大部分時候處於睡眠狀態，如果用傳統的架構去為這幾十萬設備服務的話，肯定要考慮並發連接的時候，應該有多少計算資源去服務，這很浪費成本。所以最好的方式，來一個請求就拉一個函數服務一下，這就很節省成本。

這是按需的，但它不是完整的替換，相當於說IT領域裡面不同的場景其實是使用不同的服務。我們推出這個服務的原因，背後的動力還是成本和效率，在某個場景上用某個解決方案它的成本更低、效率更高，而不是說新的東西會替換老的，因為不同場景需求是不一樣的。K8S接受的用戶比FaaS的用戶更多，因為K8S的面更廣，它覆蓋的場景更多，但是它不是替換的。

記者：目前，國內客戶對Serverless和PaaS的接受和普及程度是怎麼樣的？

葉理燈：我覺得在國內還是處於起步和用戶教育階段。2014年Lambda推出的時候，它的滲透率是72%，什麼原因呢？有72%的人用的lambda，我們有個Serverless產品叫UGC，騰訊有FaaS，阿里也有PaaS，目前都不算是滲透率很高。

原因有幾個。第一、國內用戶對新技術接受程度是比較低的，可能是習慣問題，國內的IT的發展水平跟國外也有差距，有5、6年差距；其次，對國內用戶來說，把一個架構改成Serverless架構，其實成本是很高，而且改造的收益和規模相關；最後，FaaS本身不是一個獨立能起作用的產品，你會看到Lambda推出時，不是個獨立的產品，它是體系的副產品，例如其他產品要開放事件源，通過事件去觸發Lambda函數執行。只有產品體系開放足夠多的事件源，FaaS才能滲透到整個平台裡面去，才能覆蓋更多場景。

我們國內的廠商還沒有做到這一點。AWS 剛推出FaaS時，它主要是S3上的圖片處理，不是每個用戶都有這個場景，因此滲透率不高。隨著 API 網關方式調用，和體系開放事件源越來越豐富，覆蓋場景越來越多，我相信FaaS會逐步落地。

在現場的演講中，提及了一個叫USQL的產品，就是Serverless方式的大數據分析工具，StepFlow用Serverless的方式編排你的程序，這些都是Serverless的服務。

未來，虛擬化容器值得關注

記者：目前UK8S的主要發展方向有什麼路線圖嗎？UK8S 是否已經開源？

葉理燈：有的，例如說我們讓K8S管理更多的資源、異構的資源，還有物理機、GPU資源，希望用戶可以通過K8S對這些資源進行統一地管理。另外，再往業務層面走會提供一些微服務的基礎設施，通過產品化，一方面減輕用戶的資源負擔，另一方面減輕應用層的架構負擔，從而盡量減輕用戶遷移到K8S的負擔。

目前 UK8S插件還屬於正在整理開源的階段，還沒有正式的發布，但我們已經小範圍的開放了代碼，把我們的插件代碼分發給到很多用戶，但公開的開源，我們希望做的更加規範一點再進行，因為我們的插件還在不斷的迭代中，有一天我們覺得達到一定程度的穩定了，我們就會進行公開開源。

記者：你認為未來K8S以及容器的技術方向上比較值得重點關注的技術點是什麼？

葉理燈：虛擬化容器。未來的方向我們相信是Serverless，這個也是雲計算應該做的，持續地為了用戶提高效率和降低成本。剛才我也說了，現在用戶使用K8S還是有資源管理的負擔的，不是完全的面嚮應用來運維，所以需要解決這個問題，讓計算節點對用戶透明。用戶通過Docker鏡像和配置文件就可以把一個應用跑起來，而不用去管資源問題。這需要我們去提供一個海量的集群去跑客戶的應用，這就存在一個問題，多個客戶的應用可能跑在一個節點上，考慮Docker本身的隔離問題，我們需要類似虛擬化容器的計算方式去做隔離，同時又希望擁有Docker本身輕量級快速啟動的效率，現在看來，虛擬化容器是比較符合這個需求的。

尾聲

通過和葉理燈的交談，梳理了我對雲計算、容器技術和 Serverless 等方面的一些認識，作為一個幾年來親自踐行雲計算髮展，並有深入探討和研究的專家，他的觀點和認識或許值得從業雲計算行業的技術人員參考。文/Linux中國 老王

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！