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 中國: https://github.com/Linux-CN/archive