從容器革命開始就有兩件事情變得清晰起來：首先，技術(shù)堆棧中各層的脫鉤產(chǎn)生了清晰的，原則性的分層概念，具有明確的約定，所有權(quán)和責任。其次，引入這些層使開發(fā)人員能夠?qū)Ｗ⒂趯λ麄冎陵P(guān)重要的事情--應用程序。

公平地說，這已經(jīng)發(fā)生過，***代平臺即服務(wù)(PaaS)正式旨在使開發(fā)人員能夠采用“無服務(wù)器計算”體系結(jié)構(gòu)。問題在于，就像在許多***波產(chǎn)品中一樣，太多重疊的概念被混合到一個單一的整體產(chǎn)品中。就大多數(shù)***代PaaS而言，開發(fā)人員經(jīng)驗，無服務(wù)器計算和定價模式(基于請求的)都是以不可分割的整體形式混合在一起的。因此，可能想要采用無服務(wù)器計算但可能滿足開發(fā)人員要求(例如特定編程語言)，或想要大型應用程序的更具成本效益的定價模型的用戶不得不放棄無服務(wù)器計算。

[[238309]]

容器的開發(fā)改變了所有這些，從無服務(wù)器計算運行時中解耦開發(fā)人員的要求。然而，過去一年已經(jīng)看到無服務(wù)器計算容器基礎(chǔ)設(shè)施的發(fā)展并不令人意外。去年七月，Azure發(fā)布了Azure容器實例，這是***個在主要公有云中無服務(wù)器計算容器產(chǎn)品。看到重要的用戶對無服務(wù)器計算基礎(chǔ)設(shè)施的興趣，其他公有云遵循Azure的領(lǐng)先地位，F(xiàn)argate在六個月后在RE：Invent 2017上宣布，我認為在所有公有云中無服務(wù)器計算容器基礎(chǔ)架構(gòu)都可用之前只是一個時間問題。

隨著我們前進，至少對我來說變得越來越清晰，未來將被容器化，而這些容器將在無服務(wù)器計算的基礎(chǔ)設(shè)施上運行。

那么在這種情況下，一個顯而易見的問題就是：“在這個無服務(wù)器計算的未來，協(xié)調(diào)工作會變成什么樣子?”

Kubernetes是一種開發(fā)用于提供無服務(wù)器計算需求的運行容器的技術(shù)。但事實是，在低層次上，Kubernetes架構(gòu)本身支持單個機器，并且從調(diào)度器到控制器管理器的組件假定Kubernetes中的容器運行在其可見的機器上。

像Azure容器實例這樣的無服務(wù)器容器基礎(chǔ)架構(gòu)是原始基礎(chǔ)架構(gòu)。雖然它是輕松運行一些容器的好方法，但構(gòu)建復雜的系統(tǒng)需要開發(fā)一個編排器來引入更高層次的概念，如服務(wù)，部署，秘密等。

對于這些無服務(wù)器計算平臺，開發(fā)一個全新的協(xié)調(diào)器可能是很有吸引力的，但事實是世界正在圍繞Kubernetes編排API進行整合，并且與現(xiàn)有Kubernetes工具的無縫集成非常有吸引力。此外，在可預見的將來，我預計大多數(shù)人的Kubernetes集群將是專用機器和無服務(wù)器計算容器基礎(chǔ)設(shè)施之間的混合體。專用機器將用于相對靜態(tài)使用的穩(wěn)態(tài)服務(wù)或?qū)Ｓ糜布鏔PGA或GPU，而無服務(wù)器容器將用于突發(fā)或瞬時工作負載。

虛擬Kubelet與Kubernetes和無服務(wù)器容器相結(jié)合

Kubernetes社區(qū)面臨的一個有趣問題是如何將無服務(wù)器計算容器基礎(chǔ)架構(gòu)與更高級別的Kubernetes概念相結(jié)合。最近，開源虛擬kubelet項目的開發(fā)在Kubernetes節(jié)點和調(diào)度特殊利益集團(SIG)內(nèi)推進了這一討論。

其核心虛擬kubelet項目旨在彌合無服務(wù)器計算容器和Kubernetes API之間的差距。正如從名字中可以看出的那樣，虛擬kubelet是Kubernetes kubelet守護進程的替代實現(xiàn)，它將虛擬節(jié)點投影到Kubernetes集群中。這個虛擬節(jié)點表示無服務(wù)器的容器基礎(chǔ)設(shè)施，使Kubernetes調(diào)度程序知道它可以將容器調(diào)度到無服務(wù)器容器API的事實。

當虛擬kubelet啟動時，它將自己注冊到Kubernetes API服務(wù)器，并立即啟動Kubernetes API服務(wù)器的心跳協(xié)議，以便它添加到Kubernetes的虛擬節(jié)點看起來健康。你可以在下面的屏幕截圖中看到這個過程。最初有一個標準的Kubernetes集群，其中有三個實際節(jié)點存在于集群中。然后，我們開始在此群集中運行虛擬kubelet作為容器，并將第四個節(jié)點添加到群集中。這第四個節(jié)點是虛擬節(jié)點，代表無服務(wù)器計算容器基礎(chǔ)結(jié)構(gòu)。當然，這個節(jié)點實際上是一個相當特殊的節(jié)點，因為它代表了在Azure容器實例等無服務(wù)器基礎(chǔ)設(shè)施上運行容器的***容量。

鑒于在無服務(wù)器計算基礎(chǔ)架構(gòu)上運行的容器與在Kubernetes計算機上運行的容器之間的定價和特性的差異，虛擬kubelet要求用戶必須顯式選擇在新虛擬節(jié)點上運行容器。為了達到這個目的，虛擬kubelet使用Kubernetes的概念和容忍度。添加時，虛擬節(jié)點將標記為Kubernetes污點，防止將任意Pod傳送到虛擬節(jié)點。只有當一個pod表明它愿意容忍這個無服務(wù)器的污點時，它才會考慮調(diào)度到虛擬節(jié)點上。

一旦將pod安排到無服務(wù)器計算虛擬節(jié)點上，虛擬kubelet會注意到這一點，并著手在無服務(wù)器基礎(chǔ)架構(gòu)中實際創(chuàng)建容器。在無服務(wù)器計算基礎(chǔ)架構(gòu)中成功創(chuàng)建Pod之后，虛擬Kubelet還負責將健康和狀態(tài)信息報告給Kubernetes API服務(wù)器，以使所有API和工具按預期工作。

Kubernetes和無服務(wù)器計算容器基礎(chǔ)架構(gòu)的這種聯(lián)合在批處理或突發(fā)性工作負載方面有各種實際用例。例如，正在進行圖像處理的客戶可以快速啟動大量容器，以處理最近一次將圖像上傳到共享存儲區(qū)，在幾秒鐘內(nèi)就可以從無基礎(chǔ)架構(gòu)轉(zhuǎn)移到數(shù)百個處理圖像的容器，并且在此處理完成后，他們立即回去為容量付錢。這與在虛擬機之上運行的Kubernetes群集形成了鮮明的對比，無論這些機器是否在使用，運行機器的成本都是不變的。同時，這種圖像處理的實際編排可以使用標準的Kubernetes概念來實現(xiàn)，例如可以調(diào)度所有這些圖像處理容器的Job對象。

使Kubernetes與無服務(wù)器容器兼容

看到虛擬kubelet項目在云計算行業(yè)的發(fā)展和增長勢頭真是令人興奮，從創(chuàng)業(yè)公司到公有云的眾多不同合作伙伴加入并貢獻了將無服務(wù)器容器與Kubernetes結(jié)合在一起的愿景。

當然，這并非一帆風順。就像我們一樣

Kubernetes和無服務(wù)器計算的未來

Kubernetes的建立是為了給開發(fā)人員一個干凈的，面向應用的API，使他們忘記了機器和機器管理的細節(jié)。但事實是，在這個API表面下，機器還在那里。無服務(wù)器計算容器基礎(chǔ)架構(gòu)的發(fā)展使人們可以開始完全忘記這些機器，但是為大規(guī)模應用程序成功使用無服務(wù)器計算容器需要開發(fā)一個協(xié)調(diào)器。因此，Kubernetes編排層和無服務(wù)器容器基礎(chǔ)架構(gòu)的集成對Kubernetes和無服務(wù)器基礎(chǔ)架構(gòu)的未來成功至關(guān)重要。

隨著我們邁向未來，我完全相信未來的Kubernetes集群將包含運行在專用機器上的容器組合以及突破無服務(wù)器計算基礎(chǔ)設(shè)施。但是，盡管未來的目的地在我心中是清楚的，但我們?nèi)绾蔚竭_那里的路徑和細節(jié)仍有待確定。我非常高興能與Kubernetes社區(qū)進行公開討論。如果你有興趣參與，請加入我們的虛擬kubelet github項目，或者參加SIG-Node和SIG-Scheduling的郵件列表或會議。我非常高興能夠共同構(gòu)建這一新一代的容器編排。這就是我們的容器化，無服務(wù)器的未來!

作者介紹：

Brendan Burns，Kubernetes的聯(lián)合創(chuàng)始人，目前任微軟分布式工程師。領(lǐng)導微軟Azure云容器開發(fā)，Azure容器實例化，Azure云shell及資源管理，居住在華盛頓州西雅圖市。