從容器革命一開始就有兩件事情很清楚：首先，技術堆棧中各層的去耦產生了一個清晰、原則性的概念分層（明確的合同、所有權和責任）。其次，引入這些層使開發人員能夠專注於對他們來說最重要的事——應用程序。
公平地說，這種情況之前發生過，第一代平臺即服務（PaaS）就是旨在使開發人員能夠採用“無服務器”架構 。麻煩的是，就像許多第一波產品一樣，太多重疊的概念被混合到一個單一的單體產品中。就大多數第一代PaaS而言，開發者體驗、無服務器和定價模式（基於請求的）是以不可分割的單體形式混合在一起的。因此，可能想要採用無服務器但不要開發者體驗（如特定編程語言）的用戶，或者追求大型應用程序的更具成本效益的定價模型的用戶，不得不放棄無服務器計算。
容器的發展改變了這一切，從無服務器運行時中解耦開發人員的體驗。因此，過去一年無服務器容器基礎設施的發展並不令人意外。去年七月，Azure發佈了Azure Container Instances——這是第一個大型公有云中的無服務器容器產品（但公平地說，hyper.sh的人更先進入市場）。看到重要用戶對無服務器基礎設施的興趣，其他公有云紛紛跟隨Azure的步伐，如Fargate六個月後在RE：Invent 2017上被宣佈。筆者認爲，在所有公有云中都會有無服務器容器基礎設施可用，只是一個時間問題。
一個越來越清楚的趨勢是，未來是容器化的，而這些容器將在無服務器基礎設施上運行。
那麼一個顯而易見的問題就是：在這個無服務器的未來裏，編排會變成什麼樣？
Kubernetes是一種用於提供運行容器的無服務器體驗的技術。但事實是，在低層次上，Kubernetes架構本身是有深度意識的單個機器，並且從調度器到控制器管理器的組件假定Kubernetes中的容器存在於Kubernetes可見的機器上。
像Azure Container Instances這樣的無服務器容器基礎設施是原始基礎設施。雖然它是輕鬆運行一些容器的好方法，但構建複雜的系統需要開發一個編排器來引入更高層次的概念，如Services、Deployment、Secrets等。
對於這些無服務器平臺，開發一個全新的編排器可能充滿誘惑，但事實是，全球正在圍繞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 Container Instances等無服務器基礎設施上運行容器的無限容量。
在無服務器基礎設施上運行的容器和在Kubernetes中的機器上運行的容器有着定價和特性上的差異。鑑於這種差異，虛擬kubelet要求用戶必須明確選擇在新的虛擬節點上運行容器。爲了實現這一點，虛擬kubelet使用Kubernetes關於taint和toleration的概念。添加後，虛擬節點標記爲Kubernetes taint，防止將任意pod調度到該虛擬節點。只有當一個pod表明它願意容忍這個無服務器taint時，纔會考慮將該pod調度到該虛擬節點上。
一旦將該pod調度到無服務器虛擬節點上，虛擬kubelet會注意到這一點，並着手在無服務器基礎設施中實際創建容器。在無服務器基礎設施中成功創建pod之後，虛擬kubelet還負責將健康和狀態信息報告給Kubernetes API服務器，以使所有API和工具按預期工作。
Kubernetes和無服務器容器基礎設施的這種結合在批處理或突發工作負載方面有各種實際用例。例如，正在進行圖像處理的用戶可以快速啓動大量容器，以處理最近一次的將圖像上傳到共享存儲，在幾秒鐘內就可以從無基礎設施變成數百個處理圖像的容器，並且在此處理完成後，用戶立即回去而不用爲容量付錢。這與在虛擬機之上運行的Kubernetes集羣形成了鮮明的對比——無論這些機器是否在使用，運行機器的成本都是不變的。同時，這種圖像處理的實際編排可以使用標準的Kubernetes概念來實現，例如可以調度所有這些圖像處理容器的Job對象。
讓Kubernetes與無服務器容器兼容
看到虛擬kubelet項目在雲計算行業的發展和增長勢頭真是令人興奮，從創業公司到公有云的衆多合作伙伴加入，併爲將無服務器容器與Kubernetes結合在一起努力。
當然，這並非一帆風順。正如我們已經探索過的關於這種整合，很明顯，將Kubernetes與無服務器容器基礎設施聯繫起來意味着重大挑戰和開放性問題。雖然Kubernetes爲用戶提供了一個面向容器的API，但當你查看這個API的實現細節時，會發現它顯然是建立在“這些容器之下有機器”的概念之上。當然，使用無服務器容器基礎設施（如Azure Container Instances）時，這些機器不再存在，而這會與現有的Kubernetes基礎設施產生衝突。
舉一個非常簡單的例子，我們在部署虛擬kubelet時最早注意到的一件事是，在部署虛擬kubelet的集羣中，有外部負載均衡器的Kubernetes Services會停止正常工作。當我們檢查這種情況時，發現原因很明顯。負責創建和維護雲負載均衡器的Kubernetes控制器管理器試圖向雲負載均衡器註冊虛擬節點。但是，此節點並不真正存在，因此無法添加到負載均衡器，從而導致無法創建負載均衡器的錯誤。使用Kubernetes 1.9，我們添加了flag，以便可以明確地在負載均衡器中阻止由Kubernetes創建的節點，因此解決了這個問題。
當考慮Kubernetes調度器時，會出現更重要的問題。Kubernetes調度器的構建是爲了確信每個單獨節點都是一個故障域，因此將容器分散到多個不同的節點是一件好事。當每個節點是一個物理機或虛擬機時，這確實是件好事，因爲每個節點都可能發生故障或恐慌，從而摧毀該節點上的所有容器。但是，對於虛擬kubelet而言，情況變了。無服務器容器基礎設施本身具有容錯能力，並且構建在許多不同的機器之上。因此，雖然將多個容器從同一個應用程序調度到一個物理機或虛擬機上可能不安全，但將多個容器從同一個應用程序調度到單個無服務器的虛擬節點上是非常安全的。使用無服務器容器和虛擬kubelet時，節點不再是故障單元。這種不協調和許多類似的調度問題仍然是需要解決的開放性問題。
Kubernetes和無服務器的未來
Kubernetes的構建是爲了給開發人員一個乾淨的、面向應用的API，使他們忘記了機器和機器管理的細節。但事實是，在這個API表面下，機器還在那裏。無服務器容器基礎設施的發展使人們可以開始完全忘記這些機器，但是爲大規模應用程序成功使用無服務器容器需要開發一個編排器。因此，Kubernetes編排層和無服務器容器基礎設施的集成對Kubernetes和無服務器基礎架構的未來成功都是至關重要的。
筆者完全相信未來的Kubernetes集羣將包含運行在專用機器上的容器和突發到無服務器基礎設施中的容器的組合。但是，儘管目的地明確，到達那裏的路徑和細節仍有待確定。筆者非常高興能與Kubernetes社區進行公開討論。如果你有興趣參與，請加入我們的虛擬kubelet github項目，或者參加SIG-Node和SIG-Scheduling的郵件列表或會議。筆者非常高興能夠和你共同構建新一代的容器編排，共同邁向容器化和無服務器的未來！
K8S技術社區評論
Separate of concern（關注分離）在過去的幾十年中一直是IT行業發展的最重要原則，我們關注應用而不是硬件基礎架構催生了雲計算，我們關注分佈式系統而不是容器催生了Kubernetes，Serverless技術的出現並和Kubernetes結合是SOC原則的進一步體現，使Developer可以把目光聚焦在Code（業務平面）上而不會被其它平面牽扯精力，毫無疑問Serverless爲Kubernetes注入了新的活力，爲傳統應用更好的Cloud Native化鋪平了道路。
——K8S技術社區特約評論員、EasyStack聯合創始人兼CTO 劉國輝
本文轉移K8S技術社區-Kubernetes核心設計者認爲Serverless是Kubernetes的未來