Linux中國

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

對這篇文章感覺如何?

太棒了
0
不錯
0
愛死了
0
不太好
0
感覺很糟
0
雨落清風。心向陽

    You may also like

    Leave a reply

    您的電子郵箱地址不會被公開。 必填項已用 * 標註

    此站點使用Akismet來減少垃圾評論。了解我們如何處理您的評論數據

    More in:Linux中國