Linux和Eclipse 的共同選擇：將Kubernetes帶入物聯網邊緣計算

轉自：物聯網智庫

最近在邊緣計算領域，發生了一次具有非凡意義的合作，有可能以節點的身份被載入物聯網史冊。

兩大著名開源組織，Linux基金會和Eclipse基金會正在合作，將把在超大規模雲計算環境中已被普遍使用的Kubernetes（簡稱K8s），帶入到物聯網邊緣計算場景中。新成立的Kubernetes物聯網邊緣工作組將採用運行容器的理念並擴展到邊緣，促進K8s在邊緣環境中的適用。

該工作組得到了不少重量級企業的支持，他們已經對K8s投入了大量資金，包括Red Hat、博世、西門子、Eurotech、InfluxData、Vapor IO和VMware等。

Eclipse基金會執行董事Mike Milinkovich在隨後發布的博客文章中寫道：該工作組將推動K8s的演進以適應物聯網邊緣應用的需求，工作內容包括：

• 支持將工業物聯網IIoT的連接設備數量擴展到百萬量級，既可支持IP設備以直連方式接入K8s雲平台，又可支持非IP設備通過物聯網網關接入。
• 利用邊緣節點，讓計算更貼近設備側，以便減少延遲、降低帶寬需求和提高可靠性，滿足用戶實時、智能、數據聚合和安全需求：
  --將流數據應用部署到邊緣節點，降低設備和雲平台之間通信的帶寬需求。
  --部署無伺服器應用框架，使得邊緣側無需與雲端通訊，便可對某些緊急情況做出快速響應。
• 在混合雲和邊緣環境中提供通用控制平台，以簡化管理和操作。

據IDC數據統計, 到2022年將有超過500億的終端與設備聯網。未來超過75%的數據需要在網路邊緣側分析、處理與儲存。而在邊緣計算領域，很多基本的重大問題仍然懸而未決，或者仍有很大的改進空間，包括邊緣側的連接性、易管理性、可擴展性、可靠性、安全性等。

在邊緣計算領域，解決方案的碎片化和同質化可能是首當其衝的問題，10家供應商針對相同的應用可能會有10種不同的解決方案，不僅浪費資源於重複建設，而且缺乏通用性。兩大基金會的合作試圖利用開源平台K8s的優勢，發揮其在邊緣計算領域的應用潛能。

在兩大基金會的合作宣言中，一句話耐人尋味，他們希望通過彼此合作將K8s在雲計算領域掀起的衝擊波在邊緣計算領域重演。當前，K8s這一雲計算領域的熱詞，尚未在物聯網領域普及，因此在本文中你將看到貼心的「溫故知新」：

• K8s在雲端掀起了什麼衝擊波？K8s又是如何贏得了雲計算的戰爭？
• 為什麼K8s有可能成為邊緣計算髮展的利器？這裡你會看到關於雲原生、容器、微服務等熱詞的解釋。
• 在物聯網應用中，以雲平台為核心，還是以邊緣為核心？思維差異有可能決定成敗。

K8s在雲端做了什麼？

2017是K8s的勝利之年，它贏得了雲計算的戰爭。

K8s誕生於谷歌，隨後谷歌選擇將其開源，從結果來看這一決策相當明智，也為K8s在眾多競爭者中成功突圍做好助攻。

Docker+K8s，這一組合正在成為雲計算的主流，基於Docker+K8s的新型PaaS平台具有敏捷部署、彈性伸縮、靈活調度、故障自動恢復等優勢，充分滿足業務擴展中的資源支持，因此在短短兩年之內，便從Docker Swarm、Cloud Foundry Diego、Kontena、Apache Mesos、Amazon ECS…等大量對手中脫穎而出。

K8s最終活了下來，很多公司紛紛放棄了自己造「輪子」的舉動，終止了各自的容器編排工具，加盟K8s陣營，已經融入K8s生態的代表企業，除了谷歌之外，還包括Red Hat、微軟、IBM、阿里、騰訊、華為和甲骨文等。如果一家公有雲現在還沒有提供K8s服務，那麼基本可以認為它落後於時代。在私有雲領域，K8s也已幾乎成為標配。

K8s的勝利到底意味著什麼？

意味著，有史以來第一次，無論使用哪一種雲平台，研發人員都可以擁有完全相同的計算環境。

Red Hat首席架構師BilginIbryam認為，K8s勝出的最大意義有兩點。一是K8s成為開發者必須學習和掌握的容器編排平台，因為它與90%的容器工作相關。二是K8s就像容器領域中的亞馬遜，我們已經離不開它。K8s不僅關注應用的運行，還關注應用的打包與分發，使得應用程序可以在不同雲平台之間自由遷移，它開創了全新的應用程序可移植平面，成為大家共同的選擇。

過去，很多用戶常常擔心被阿里、亞馬遜、微軟等雲計算提供商「綁定」。但自從有了K8s之後，分散式應用與雲平台實現了「解耦」，工程師們不再擔心如何把應用從一個平台移植到另一個平台，因為K8s在各種雲平台環境均可運行。

為什麼K8s會成為主流？

Docker和K8s是雲原生概念的核心和基礎。雲計算誕生已有超過10年，但云計算時代的應用到底該是什麼樣子，一直沒人能說清楚，也沒人能確定雲計算的基礎架構將會如何發展。

在Docker+K8s出現之前，沒人設想過會有一個被所有雲計算供應商同時支持的分散式應用平台，直到容器技術出現之後，人們才意識到終於離目標又進了一步。

技術路徑的選擇有時直接決定了前程似錦還是江河日下。

OpenStack曾被稱作「公有雲操作系統」，但因開源版本混亂，後續運營、維護、升級成本高昂等問題，導致其難以適合公有雲的發展。2015年到2017年之間，最大的OpenStack公有雲提供商，思科、AT&T和HPE先後退出了市場。最近eBay宣布策略性放棄OpenStack，轉而使用K8s和Docker重新平台化，才算擺脫了困境。

在物聯網領域，技術路徑的選擇更為關鍵，可以預見大量物聯網平台將會紛紛「倒戈」，增加對K8s的支持。

在此前的文章中，我曾經提到很多工業物聯網IIoT平台均是基於Cloud Foundry構建，包括GE的Predix平台、西門子的MindSphere、博世的IoT Cloud、研華科技的WISE-PaaS和霍尼韋爾的Sentience等。目前已有企業表示將會基於K8s重新部署IIoT平台。

K8s將在邊緣實現什麼？

此處我們先把「雲原生」、「容器」、「微服務」等熱詞翻譯成通俗易懂的語言。

雲原生：如果業務上雲之後，開發和運維人員比上雲之前還痛苦，那麼上雲的意義何在？

雲原生並不是新技術，而是一種理念，它是不同思想的集合，集目前各種熱門技術之大成，它的意義在於讓上雲成為潮流而不是阻礙。雲原生應用，即指專門為在雲平台部署和運行而設計的應用。

很多公司在完成從傳統應用到雲端應用的遷移過程中，遇到了或多或少的技術難題，雲端應用的效率並沒有實現預想的明顯提升，升級迭代速度和故障定位也沒有預想中快。因此雲原生這一概念被提出，試圖同步改進應用的開發模式，提升運維效率和企業的組織結構。

雲原生定義了雲端應用應該具備的基礎特性，包括敏捷、可靠、可擴展、高彈性、故障恢復、不中斷業務持續更新等。

2015年，由Google提議創立的CNCF雲原生基金會（Cloud Native Computing Foundation）正式成立，並且發布其標誌性產品K8s，不少有價值的雲原生項目也隨之誕生。CNCF將雲原生的生態圈劃分為5層，分別是應用定義與開發層、編排與治理層、運行層、供應保障層和基礎設施層。

容器：容器技術是主機虛擬化技術後，最具顛覆性的計算機資源隔離技術。

通過容器技術進行資源的隔離，不僅對CPU、內存和存儲的額外開銷非常小，而且容器的生命周期管理非常快捷，可以在毫秒級開啟和關閉容器。

簡單的說，容器就像集裝箱一樣把軟體封在一個殼子里。

上圖中的這條大鯨魚其實就是我們的電腦，這些箱子便是Docker容器，箱子里裝的是軟體。除了軟體本身，它還包含了軟體運行所需要的特殊環境配置。軟體運行時可以直接利用這個箱子里的環境配置，與電腦中原有的環境配置完全不衝突，而且互不影響。

咱們不妨再說得簡單點兒。

如果把電腦比作一個大食堂，食堂裡面有蔬菜等原材料、各種廚具和加工工具，還有廚師作為食堂的在職員工。那麼Docker容器就像是大食堂中開設的各種菜館門店，川湘粵魯豫菜都可以各有一個店，每個店都使用大食堂中現成的廚具，大部分原材料和現成的廚師，只需準備少部分配菜和配料（運行環境）即可。

微服務：相比大而全，人們更喜歡小而美，微服務就此應運而生。

過去的單體應用，就像家樂福超市一樣，把所有業務的代碼都放在一起，就像把所有商品混在一起售賣。這對於小型項目來說自然是很合適的，可是項目一旦大了起來，業務一多，這個單體應用也就膨脹了，膨脹後的應用主要有以下兩個缺點：

1、牽一髮動全身。修改一個業務的一行代碼，需要重啟整個單體應用，這顯然是不合理的。

2、擴展能力受限。對於單體應用，如果發現某一業務的請求量非常大，那麼是無法單獨擴展該業務的，只能拷貝整個單體應用，再部署一套環境，來實現集群。

正因為單體應用有著這些缺陷，就誕生了微服務架構。微服務是一種分散式架構設計理念，為了推動細粒度服務的使用，這些服務要能協同工作，每個服務都有自己的生命周期。微服務一般配合更細粒度的容器使用，並和雲原生有很強的關聯性。它具有3個關鍵點：

1.每一個微服務是一個獨立的自治系統，不依賴外部組件能夠獨立運行。

2.對外只能通過API提供服務或者獲取服務。

3.粒度足夠小。

追根溯源，其實微服務的這種架構設計理念早就有了。總之，一個微服務就是一個獨立的實體，可以獨立的部署在PaaS平台上，也可以作為一個獨立的進程在主機中運行。服務之間通過API訪問，修改一個服務不會影響其它服務。

說回K8s。

通過上面的概念介紹，K8s天生就符合雲原生的理念，是容器的編排工具，適合微服務架構。但如果K8s想在邊緣計算落地，還需要克服一些差異化問題：首先要進行代碼壓縮的工作，節省空間的佔用。

作為K8s的創造者，谷歌在邊緣計算領域的舉動值得關注。在收購了物聯網平台Xively之後，谷歌又與Foghorn開展了密切合作。

FogHorn在我的文章中曾被多次提及，這家公司成立於2014年，一直專註於邊緣分析和邊緣智能，是邊緣計算領域發展最快的初創公司之一。Foghorn很早就擁抱了雲原生的理念，基於容器構建微服務。

目前FogHorn正在積極推進機器學習的「邊緣化」（Edgification），重點開拓的領域是工業物聯網IIoT。FogHorn提供的邊緣計算平台，可與部署在公有雲中的物聯網平台協同工作。FogHorn的旗艦產品EdgeML在邊緣側使用機器學習模型進行預測分析和異常檢測，從而實現工業設備的預測性維護。

在最新的版本中，Foghorn平台增加了對預測模型標記語言（PMML，Predictive Model Mark Up Language）的支持，以便在邊緣側支持任何兼容的機器學習模型。

有外媒預測也許谷歌有意併購FogHorn，並將其與Edge TPU結合使用，以便構築殺手級應用。

從雲到邊，重心正在轉移

在物聯網應用中，以雲平台為核心，還是以邊緣為核心？在這點的認知上，稱霸雲計算的巨頭和硬體出身的企業有很大分歧，這一分歧帶來的分道揚鑣或直接導致最終的成敗。

比如在谷歌的物聯網架構中，雲平台處於核心地位，位於雲端的大腦可以使用物聯網數據流實現高級分析、可視化、機器學習等功能。

而在硬體企業眼中，必須藉助自身優勢乏力，它們寄希望於終端設備和邊緣計算成為物聯網的核心。富士康便直接將涵蓋工業設備、機器控制、工業網關和邊緣計算等更接近工業現場的部分稱為核心層，邊緣計算稱為核心層運算。

通過K8s在邊緣計算領域的滲透，可以感受到雲計算巨頭也意識到了物聯網的核心應當從雲端進一步下沉，更貼近數據的源頭，畢竟數據才是驅動雲平台和人工智慧的「原動力」。邊緣設備作為物聯網雲平台的「入口」，成為連通物理世界和數字世界的橋樑，是物聯網產業的重要關口。

K8s為邊緣側的應用部署提供了便利性，在一定程度上轉變了邊緣應用與硬體之間的關係，將兩者的耦合度降低，讓邊緣層的應用可以使用更加靈活開放的模式，解決現有的痛點並滿足新的需求。

由於K8s在邊緣計算層解決了「最後一公里」雲原生應用的供應問題，成為了雲計算在未來發展中的重要落地支撐，推進邊緣計算與雲計算的彼此融合，來到「邊雲協同」的新階段。通過由邊緣與雲端形成的多層混合架構而觸發的「邊雲協同」效應，更能綜合發揮兩者的優勢，促進物聯網基礎架構迎來一次全面的升級。

【物女心經】專欄中多次提到的EdgeX Foundry開源項目也已經與K8s建立合作，將EdgeX部署在其上。

至此，我已完成了K8s的介紹，以及它有可能在物聯網邊緣側引發的衝擊。

邊緣計算領域的競爭是一場馬拉松，而不是短跑。

最後，我想引用一個人的觀點，他叫Frederick Brooks，是一位軟體工程專家。20世紀80年代，Brooks在其著作《No Silver Bullet: Essence and Accident in Software Engineering》，對軟體工程面臨的挑戰進行了論述。

他的一個基本論斷是「沒有銀彈」。（銀彈：歐洲中世紀的傳說中有一種叫「人狼」的妖怪，只有用銀子製成的特殊子彈才能殺死人狼。）即，沒有任何一種技術或管理上的進展，能夠獨立在10年內大幅度提高軟體的生產率、可靠性和便利性。

K8s雖然在一定程度上提升了邊緣側應用開發的效率問題，但它並不是銀彈。對於物聯網邊緣來說，沒有銀彈。願你在用好K8s這個優質工具的同時，兼顧邊緣計算全局觀，還有餘力去把握其他或與K8s同樣重要的技術和趨勢。

衷心感謝華為工業互聯網和邊緣計算領域專家、邊緣計算產業聯盟需求與架構組主席史揚在成文過程中對我的大力支持。

本文小結：

1.2017是K8s的勝利之年，它贏得了雲計算的戰爭。因為K8s，有史以來第一次，無論使用哪一種雲平台，研發人員都可以擁有完全相同的計算環境。

2.K8s正在向邊緣計算滲透，它為邊緣側的應用部署提供了便利性，在一定程度上轉變了邊緣應用與硬體之間的關係，將兩者的耦合度降低。

3.K8s雖然在一定程度上提升了邊緣側應用開發的效率問題，但它並不是銀彈。對於物聯網邊緣來說，沒有銀彈。

推薦閱讀：