Kubernetes如何支撐邊緣計(jì)算平臺(tái)

本文轉(zhuǎn)自邊緣計(jì)算社區(qū)

容器編排引擎具有作為邊緣解決方案的潛力，但是在它成為邊緣解決方案之前還有很多問題需要解決。 

到目前為止，您可能已經(jīng)聽說了Kubernetes如何在傳統(tǒng)的本地部署和云環(huán)境中簡(jiǎn)化應(yīng)用程序的大規(guī)模部署。但是，將中央數(shù)據(jù)中心與托管在離終端用戶更近的邊緣位置的工作負(fù)載結(jié)合起來的邊緣架構(gòu)又如何呢？Kubernetes也能支撐一個(gè)邊緣計(jì)算平臺(tái)嗎？ 

答案是有可能。盡管Kubernetes作為邊緣計(jì)算解決方案有潛力，但是Kubernetes的開發(fā)人員和用戶需要克服一些障礙，才能讓K8s真正為邊緣做好準(zhǔn)備。

一些觀察家認(rèn)為Kubernetes已經(jīng)為在邊緣環(huán)境中托管應(yīng)用程序做好了準(zhǔn)備。例如，Canonical的Ammar Naqvi寫道Kubernetes是“邊緣計(jì)算的關(guān)鍵組成部分”，云原生基金會(huì)（Cloud Native Computing Foundation）也將Kubernetes推廣為邊緣解決方案。

當(dāng)然，這些組織有點(diǎn)偏頗。Canonical和CNCF對(duì)Kubernetes進(jìn)行了深入的投資，如果Kubernetes作為構(gòu)建邊緣計(jì)算平臺(tái)的解決方案受到歡迎，他們將獲益匪淺。

盡管如此，他們還是對(duì)Kubernetes為何天生適合邊緣提出了一些好的意見。在他們撰寫本文時(shí)，Kubernetes提供了一個(gè)通用控制平面，可以與任何類型的基礎(chǔ)邊緣基礎(chǔ)架構(gòu)一起使用，這意味著它將簡(jiǎn)化跨各種邊緣環(huán)境的工作負(fù)載的部署和管理。Kubernetes在平衡流量和最小化延遲方面也很出色，這是邊緣工作負(fù)載的優(yōu)先事項(xiàng)。而且，通過充當(dāng)DevOps CI / CD流水線的部署環(huán)境，Kubernetes將使開發(fā)人員可以輕松地對(duì)邊緣應(yīng)用程序進(jìn)行持續(xù)更新。 

除了對(duì)推廣Kubernetes有明確興趣的供應(yīng)商和開發(fā)人員之外，有證據(jù)表明，更中立的團(tuán)體也將Kubernetes視為未來邊緣計(jì)算平臺(tái)的重要組成部分。在一份基于對(duì)云計(jì)算和數(shù)據(jù)中心行業(yè)十多位思想領(lǐng)袖和供應(yīng)商的采訪的報(bào)告中，Omdia發(fā)現(xiàn)，目前有超過一半的人看到Kubernetes被部署用于邊緣工作負(fù)載。

據(jù)Omdia的報(bào)告稱：“Kubernetes將成為一種能夠管理從云到邊緣的工作負(fù)載的技術(shù)，它提供了一個(gè)通用的應(yīng)用程序管理平臺(tái)。” 

簡(jiǎn)而言之，我們有充分的理由相信Kubernetes在未來幾年將成為邊緣計(jì)算平臺(tái)越來越重要的一部分。

然而，要使Kubernetes成為管理部署在邊緣的應(yīng)用程序的真正無縫解決方案，開發(fā)人員需要解決幾個(gè)難題。

可能最大的問題是確保中央數(shù)據(jù)中心和邊緣位置之間的低延遲數(shù)據(jù)傳輸。在許多方面，快速移動(dòng)數(shù)據(jù)是邊緣計(jì)算的最大挑戰(zhàn)；應(yīng)用程序編排是次要問題。而Kubernetes本身并沒有優(yōu)化數(shù)據(jù)傳輸。數(shù)據(jù)結(jié)構(gòu)確實(shí)如此，但Kubernetes并沒有以特定的方式與之集成。

為了確保在基于Kubernetes的邊緣環(huán)境中進(jìn)行低延遲的數(shù)據(jù)移動(dòng)，那么構(gòu)建邊緣計(jì)算平臺(tái)的開發(fā)人員將需要將Kubernetes與數(shù)據(jù)結(jié)構(gòu)解決方案相結(jié)合的部署變得更容易。他們可能還需要改進(jìn)Kubernetes處理內(nèi)部數(shù)據(jù)移動(dòng)的方式，例如，讓Kubernetes更容易知道哪些內(nèi)部流量需要優(yōu)先處理。目前，Kubernetes在解決如何平衡來自外部端點(diǎn)的傳入流量方面做得很好，但不太擅長(zhǎng)管理以每毫秒計(jì)數(shù)的內(nèi)部流量流。 

類似地，Kubernetes將從更強(qiáng)的工作負(fù)載安排控制權(quán)中受益。Kubernetes使管理員能夠?qū)?yīng)用程序分配給各個(gè)節(jié)點(diǎn)，當(dāng)所有節(jié)點(diǎn)都在一個(gè)數(shù)據(jù)中心內(nèi)運(yùn)行時(shí)，這種方法效果很好。

但是，如果節(jié)點(diǎn)分布在多個(gè)邊緣位置，并且可能分布在一個(gè)中央數(shù)據(jù)中心，該怎么辦呢?在這種情況下，您可能希望有能力去管理有獨(dú)立邊緣位置承載的應(yīng)用程序，以及平衡它們之間流量。這在今天的Kubernetes中是很復(fù)雜的，除非你在每個(gè)邊緣位置只有一個(gè)節(jié)點(diǎn)，這是不可能的。那么，Kubernetes需要的是一個(gè)特性，允許管理員根據(jù)不同地理位置的節(jié)點(diǎn)池來定義工作負(fù)載的放置方式和優(yōu)先級(jí)，而不僅僅是運(yùn)行在同一物理位置的單個(gè)節(jié)點(diǎn)。  

多集群管理仍然是一個(gè)挑戰(zhàn)。最初，Kubernetes的設(shè)計(jì)或多或少假設(shè)每個(gè)組織將運(yùn)行一個(gè)集群，并可能劃分為多個(gè)命名空間。這些年來，情況發(fā)生了變化，大多數(shù)Kubernetes供應(yīng)商現(xiàn)在都支持多集群管理。但是它們做得并不好，跨多個(gè)集群管理工作負(fù)載仍然是Kubernetes開發(fā)人員的次要考慮事項(xiàng)。 

這對(duì)于邊緣計(jì)算平臺(tái)來說是個(gè)問題，組織可能會(huì)選擇在每個(gè)邊緣位置運(yùn)行單獨(dú)的集群，以隔離工作負(fù)載并簡(jiǎn)化真正大規(guī)模環(huán)境的管理。

Kubernetes有很多可以作為邊緣計(jì)算平臺(tái)的基礎(chǔ)，但在這方面也有一些明顯的缺點(diǎn)。所以一些架構(gòu)師認(rèn)為Kubernetes不適合某些可能部署在邊緣的工作負(fù)載，比如容器化電信應(yīng)用程序。

另一方面，只要付出足夠的開發(fā)努力，Kubernetes作為邊緣計(jì)算平臺(tái)基礎(chǔ)所面臨的挑戰(zhàn)是可以解決的。我們應(yīng)該問的真正問題，也許不是Kubernetes是否能夠在邊緣工作（目前，答案是它只是作為一種邊緣解決方案），而是開發(fā)人員是否愿意投入必需的努力，使其成為一個(gè)成熟的邊緣計(jì)算平臺(tái)。

推薦閱讀

在邊緣設(shè)備上部署Prometheus，實(shí)現(xiàn)遠(yuǎn)程監(jiān)控K3s集群！

基礎(chǔ)指南：如何在K3s中配置Traefik?

一文搞定全場(chǎng)景K3s離線安裝