從容器革命開始就有兩件事情變得清晰起來：首先，技術堆棧中各層的脫鉤產生了清晰的，原則性的分層概念，具有明確的約定，所有權和責任。其次，引入這些層使開發人員能夠專注于對他們至關重要的事情--應用程序。

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

[[238309]]

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

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

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

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

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

對于這些無服務器計算平臺，開發一個全新的協調器可能是很有吸引力的，但事實是世界正在圍繞Kubernetes編排API進行整合，并且與現有Kubernetes工具的無縫集成非常有吸引力。此外，在可預見的將來，我預計大多數人的Kubernetes集群將是專用機器和無服務器計算容器基礎設施之間的混合體。專用機器將用于相對靜態使用的穩態服務或專用硬件，如FPGA或GPU，而無服務器容器將用于突發或瞬時工作負載。

虛擬Kubelet與Kubernetes和無服務器容器相結合

Kubernetes社區面臨的一個有趣問題是如何將無服務器計算容器基礎架構與更高級別的Kubernetes概念相結合。最近，開源虛擬kubelet項目的開發在Kubernetes節點和調度特殊利益集團(SIG)內推進了這一討論。

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

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

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

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

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

使Kubernetes與無服務器容器兼容

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

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

Kubernetes和無服務器計算的未來

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

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

作者介紹：

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