Rancher的新徵程:做邊緣計算開發平臺的事實標準

Rancher的新徵程:做邊緣計算開發平臺的事實標準

在神秘的代碼世界裡,程序員就是主角,只相信冰冷代碼的他們並不善於主動稱讚別人。

在全球程序員最大的聚集地之一,開源代碼託管平臺Github上,不同程序員、團隊、公司創造的代碼項目都會公之於眾,以開源的方式將代碼的魅力和影響力發揮到極致。

在這個過程中,有著一個神聖的機制——每個登錄平臺的程序員,都可以用自己的鼠標,在別人的代碼項目頁面點擊一個“Star”。這一個簡單的動作實際上代表了程序員發自心底的認可。

就在幾個月前,一個全新的、面向邊緣雲場景的容器技術悄然登錄了Github,“Star”的數量隨即飆升,短短几個月時間已經超過了1萬顆。

Rancher的新徵程:做邊緣計算開發平臺的事實標準

這樣的數字,即便是很多成名已久的項目也無法做到。而贏得這份榮耀的產品不是其他,正是Rancher新推出的k3s。用Rancher中國CEO秦小康自己的話來說:“k3s受歡迎的程度,遠遠超過了我們之前的想象。”

Rancher的新徵程:做邊緣計算開發平臺的事實標準

秦小康表示,k3s最初並不是Rancher自身規劃中的產物,而是來源於一家石油鑽井客戶的實際需求。

Rancher的新徵程:做邊緣計算開發平臺的事實標準

Rancher中國CEO秦小康

這家客戶有很多油井,油井上佈置了各種傳感器和計算設備,這些裝置的目的是要收集油井的工作狀態,並且通過網絡將它們傳輸到雲端進行統一管理。

這家石油公司之前已經是Rancher的客戶,已經在使用Rancher的產品部署及管理K8S,並且得到了滿意的回報。當時客戶提出來一個新想法,能否在數量眾多的油井平臺上部署K8S集群,進一步延伸他們利用容器技術來提升分析和管理的能力。

之所以找Rancher提想法,也是因為油井平臺並不是一個常見的K8S環境,一臺鑽機壽命長的話可以用上許多年,再加上整體數量比較大,之前傳輸數據的任務又比較簡單,所以這些部署在油井上的計算機設備配置都很低,普通的K8S太大了,根本放不下。

對於這樣“超越常規”的要求,最正常的回覆應該就是拒絕了。不過這個新需求卻“勾”起了研發部門的興趣,很快就抽調人力開始了嘗試。

傳統的K8S膀大腰圓,動輒就是幾個GB的容量,因而極致的瘦身必不可少。為此,Rancher大幅度地刪除了舊的、非必需的代碼,整合了正在進行的打包進程,同時使用更輕量的容器引擎及數據存儲替代方案。

最終,k3s變成了一個大小僅為40MB的二進制文件,在客戶的終端上暢快地運行起來。

Rancher的新徵程:做邊緣計算開發平臺的事實標準

Rancher隨即便意識到,這個產品完全可以複製到更多的使用場景,覆蓋更為廣闊的應用領域,公司將其命名為k3s,並開源到GitHub上跟廣大開發者共享,共同探索k3s更廣闊的使用場景和想象空間。

k3s的問世看起來很偶然,但作為一家以技術引領市場、以用戶需求為導向的公司,Rancher在自身創新基因的驅動下,必然會催生出諸如k3s之類的“偶然”,這在未來場景中同樣適用。

據秦小康介紹,雖然信息技術的發展速度很快,但是在傳統行業的大量應用場景裡,用戶的環境絕非“超級環境”,位於邊緣的設備諸如工業機和單片機裡搭載的都是單一應用,程序非常小巧,如何讓這些“古董級”的設備和應用同樣享受到現今的數字紅利,正是k3s將要擔負起的職責與使命之一。

Rancher的新徵程:做邊緣計算開發平臺的事實標準

正如我們上面所說的,k3s最早發佈的時候只有不到40MB,但在上個月的正式GA(General Availability)之後,它的“體積”稍微增加了一些,達到了差不多60MB的樣子。

對於這個改變,秦小康表示,第一次的客戶環境和應用比較特殊,於是Rancher的產品部門大刀闊斧地進行了裁剪,但是事後又覺得差不多有十多兆的東西不應該完全去除。譬如ROOT FS裡面的命令行等功能,考慮到用戶需求和更多場景的適應性,最終將它們重新添加回來。

Rancher的新徵程:做邊緣計算開發平臺的事實標準

此外,最早的發佈版本就像是電影的“導演剪輯版”,雖然做的改動很少,然而隨著後續劇情(產品穩定性等)需求,就必須對此前的版本進行修訂與補充,從而滿足用戶應用場景的嚴苛要求。

“我們對k3s的體量沒有強制的要求,至少沒有一定要低於邊緣上限百分之多少的硬指標。”秦小康強調,在滿足所有功能的情況下,k3s會盡量保持最大化的輕量。當然,邊緣設備也在不斷的升級和發展中,它們不會始終停留在十幾年前的配置上。

畢竟是經CNCF認證的K8S發行版,k3s也最大範圍地保持了對軟硬件平臺的兼容和支持。整體看來,這些平臺與K8S並無差異,甚至擴寬了對適用於邊緣的硬件平臺支持。

硬件方面,k3s支持Intel、NVIDIA與ARM等平臺,由於邊緣計算的緣故,後者尤其得到各方看好;操作系統方面,只要是可以跑K8S的系統就可以運行k3s,不管RedHat、Ubuntu,抑或是CentOS。

與數據中心的管理員不同,邊緣節點的管理員往往不希望系統和Kubernetes平臺割裂開來,因此Rancher又專門做了一個k3OS——這是一個集成了k3s的操作系統,非常小巧,但是五臟俱全,經過了Rancher的精心裁剪,能夠為用戶在邊緣環境提供最好的支持。

Rancher與ARM的合作已歷經多年,而在邊緣計算乃至工業互聯網之後,雙方的關係也變得更加密切。

尤其是相當於K8S微縮版的k3s,更是被認為極大地釋放了ARM在邊緣場景的優勢。對於Rancher來說,如果哪一天能通過k3s構建出一個統一的計算平臺,將幾百億、上千億的設備聯接在一起,那必然給這個世界帶來翻天覆地的變化。

Rancher的新徵程:做邊緣計算開發平臺的事實標準

值得一提的是,k3s繼承了Rancher一如既往的理念——避免與任何廠商尤其是公有云供應商以及軟硬件平臺進行鎖定

(Lock-in),充分給予用戶選擇基礎設施架構的自由。

“我們希望為用戶提供儘量多元開放的選擇,這是國內其他邊緣容器廠商無法做到的,他們想盡量塞給客戶一個‘全家桶’,從而增加客戶後期遷移或改變選擇的難度,等於變相在‘套牢’客戶。客戶系統靈活性的減弱,實際上是強迫客戶相信他們對於未來的承諾,這是在用比較小的利益引導客戶做出未來才可能會後悔的選擇。”

秦小康強調:“一直以來,Rancher的願景均是:Run Kubernetes Everywhere,最終推動Computing Everywhere,讓計算無處不在。”要想將K8S的優勢延伸到邊緣,就勢必需要k3s,這也是做k3s的初衷之一。

Rancher的新徵程:做邊緣計算開發平臺的事實標準

說到這裡,或許有些讀者朋友會產生誤解,認為k3s的邊緣應用就是荒野戈壁,遠離人跡。實際上在Rancher已經收穫的行業客戶裡,有很多場景就在我們的身邊。

銀行營業廳的攝像頭就是非常典型的邊緣應用場景,目前國內多家銀行都掀起了利用智能櫃機增加自身網點服務能力的變革。其中一個最關鍵的環節,就是利用櫃機的攝像頭對客戶的身份進行識別確認。

為了實現這樣的應用,銀行需要同步升級所有營業廳的攝像頭才能夠做到精準的信息匹配。在傳統的模式下,假如有一萬個網點,就需要一萬次到網點處理。通過中央的Rancher管理,邊緣的k3s可以實現同步,將各種更新推送到所有的網點攝像頭上。

再比如物流行業的手持終端,這種設備非常昂貴。由於同一時間裡不可能要求在外作業的快遞員將設備送回來統一升級,而且業務也不可以中斷,因此這一類設備的管理維護難度非常大。k3s則可以進行手持終端的應用同步更新,業務完全不會受到影響,快遞員甚至毫無感知。

在秦小康看來,一定程度上,k3s發揮的作用就像是CDN(內容分發網絡),在複雜的環境下高效地保障信息的連貫性。他補充道,當前k3s的用戶中就有很多CDN的公司,Rancher未來也會開發更多的行業應用領域。

Rancher的新徵程:做邊緣計算開發平臺的事實標準

從市場調查來看,k3s絕對是業界當前的第一品牌。現階段,雖然也有幾家全球知名的大型公司在做類似的平臺,但是它們產品得到的關注度較之k3s相差甚遠,尤其在Github上的Star數,基本上就是數量級的差別,項目模式也是截然不同。

k3s與眾不同之處在於,它首創了邊緣集群自治模式,對雲和邊的網絡兼容性極好。即使雲邊斷網,邊緣集群亦可以獨立自治工作。其他一些邊緣容器廠商採用的則是雲邊大集群模式,一旦雲邊通信出現問題,整個集群將會出現很大的抖動。

至於k3s如何實現雲邊協同,秦小康給出了官方的推薦部署方案:用戶可以在雲端部署Rancher Server服務,在邊緣端部署獨立的k3s集群,最終通過Rancher 2.x的多集群管理方式來滿足雲邊協同的需求。

這樣做的最大好處是,無需強烈依賴雲和邊的網絡質量,又可實現集群的統一部署和納管,同時有效避免了鎖定(Lock-in)

不過Rancher的野心不止於此。秦小康強調:“通過技術的持續更新以及在用戶場景的不斷實踐,Rancher希望擴大領先優勢,將k3s發展成為邊緣計算開發平臺的事實標準。”

目前,Rancher的營收主要來源於針對數據中心和雲的多雲多集群企業級Kubernetes管理平臺Rancher,隨著邊緣計算的需求越來越多,公司也會對k3s投入更多的資源,推動K8S技術的應用與發展,匹配客戶的需求。

“中國市場對技術的專注與熱忱,已經超出了很多發達國家和地區,這就會帶來各方廣泛期待的後發優勢、彎道超車。隨著AI、5G以及邊緣計算的持續深入,計算終將無處不在。”秦小康最後總結道。


分享到:


相關文章: