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

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

[[238309]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

當(dāng)然，這并非一帆風(fēng)順。就像我們一樣

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

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

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

作者介紹：

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