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 等方面的一些認識，作為一個幾年來親自踐行雲端計算發展，並有深入探討和研究的專家，他的觀點和認識或許值得從業雲端計算行業的技術人員參考。