對於近兩年的容器圈，Kubernetes 可以說是絕對的主角，其增長速度遠超大家預期，毫無爭議地贏得了容器化管理和協調的戰爭，容器生態圈局勢基本已定。但是容器技術還有不成熟的地方，Kubernetes 在全方位落地上也還有一定難度；整個容器生態市場中，Docker 公司的熱度已經在慢慢消退，以往的老對手 VMware 也在進軍容器市場，目前容器生態圈和容器技術態勢如何，Kubernetes 發展良好的趨勢下還面臨什麼問題？ InfoQ 藉此機會採訪了張磊老師爲我們解讀容器生態圈的現狀。
Docker 前路如何？
Kubernetes 已經贏得了容器編排戰，越來越多的提供商在擁抱 Kubernetes。而2018年 3 月份，在 Docker 公司剛滿五週歲的時候，創始人 Solomon 宣佈離職，更多的人開始質疑 Docker。但是不要忘了，Docker 公司纔是這些“擁抱 Kubernetes 的提供商”最具有分量的那位。更何況早在一年前，Solomon 就已經開始不負責 Docker 公司的具體業務了，所以他的離任在公司層面不會產生太多影響。而 Solomon 此前在 Docker 公司所做的一系列舉措，實際上就是一次賭博。一家技術創業公司身處以小博大的處境，做出這樣的決策其實並沒有太大的問題。相信彼時的 CoreOS 等競爭對手，也曾一度籠罩在 Docker 公司賭贏的恐慌中。即使到了最後，做出犧牲的只是 Swarm 等幾個具體項目，Docker 公司還是完成了預期的戰略轉型。
而另一方面，Docker 公司一向擅長的開發者關係工作，依然保持着強大的戰鬥力，這是雲計算尤其是公有云提供商的核心競爭力之一。儘管迫於形勢 Docker 公司目前主要專注於企業服務等更加現實的業務上，一旦有某些公有云廠商回過神來，Docker 公司的這部分價值會立即凸顯出來，我們不妨拭目以待。
在技術層面上，containerd 項目距離成爲 Kubernetes 下一代默認容器運行時只差了一層窗戶紙。LinuxKit 項目則成功牽制了 Unikernel 的崛起勢頭，還進一步完成了 Docker on Mac 和宿主操作系統封裝的重要任務。如果說 Docker 公司的勢頭在 2015 年到 2016 年期間達到了巔峯，那麼現在充其量也只是有所衰減，並且依然是容器技術圈的執牛耳者。更何況，Docker 公司的巔峯，已經超越了現有任何基礎設施領域開源公司所能達到的高度。
相比 Kubernetes 項目的強勢崛起等因素，CoreOS 公司提前被收購纔是目前 Docker 公司面臨的現實障礙。作爲 Kubernetes 社區的標杆玩家，CoreOS 的收購案几乎劃定了這一領域併購的天花板。在這樣的背景下，Docker 公司要突破這個天花板倒不算困難，但要重現當年微軟 40 億美金報價的無限風光，希望就非常渺茫了。
Kubernetes 落地的技術障礙
作爲基礎設施領域的系統軟件，工作層級太低是目前 Kubernetes 在更多場景中落地的主要技術障礙。
這就好比在 Google 內部，我們所熟知的基礎軟件如 MapReduce，GFS，Dapper， BigTable，Spanner 等都依賴於 Borg 的存在。Kubernetes 的工作層次使得它在落地的過程中表現出來的侵入性非常強。很難去真正接管用戶的全套基礎設施體系來發揮出它的“容器化“能力。
另一方面，很多團隊（包括很多技術能力很強的團隊）在落地 Kubernetes 項目的過程中也存在一些誤區，比如依然試圖按照“試點測試”、“定製開發”、“內部推廣”的思路來在運作這個開源項目。而實際上，Kubernetes 項目的核心乃在於它鼓勵的並不是單純的“用”，而是深入的“玩”。它是在從代碼層面保證參與者成爲整個生態的一部分，這跟之前大部分基礎設施開源項目的設計都是不太一樣。
這也意味着，只有能“玩”好 Kubernetes，才能真正保證團隊在這次容器技術的浪潮中站穩腳跟。事實上，無論 Microsoft、RedHat、CoreOS，還是 Google，都不是 Kubernetes 的典型用戶，但這並不妨礙他們成爲這個領域數一數二的“玩家”。這其中的微妙差異，正體現了所謂的基礎設施項目的“民主化”設計思路。
至於其他的功能或者性能問題，以目前 Kubernetes 生態的體量來說，基本上不存在非常困難的狀況。但是如何能夠鼓勵用戶以“白盒”化的方式去“玩好”Kubernetes 項目，改變目前用戶落地 Kubernetes 項目的思路，則是一個非常值得深入探討的話題。
混合雲環境不是目前 Kubernetes 項目的主旋律
雖然 Kubernetes 創始人 Craig McLuckie 說 Kubernetes 促成了多雲，VMware 也已經和 Pivotal 還有 Google Cloud 合作推出了 PKS (Pivotal Container Service)，可以監控 Kubernetes 節點，適合多雲環境，但是“跨混合雲和多雲環境”本質上是與公有云巨頭，也就是 Kubernetes 和 CNCF 背後幾位重要的支持者的現階段利益（最大程度的爭取最大規模的開發者）是相悖的。
所以不難理解，混合雲的支持還不是當前 Kubernetes 項目在技術上需要關心的重點。當然，作爲一個完全中立的 Linux 基金會項目，生態參與者們如何將 Kubernetes 應用在混合雲的環境中是一件完全自主的事情。這當然也是 Craig 爲之背書的主要原因：Heptio 的解決方案必然是沒有廠商鎖定的。
所以，在確保用戶只 vendor lock 在 Kubernetes 本身而不是某朵雲的前提下，混合雲的市場還是要交給 vendor 去打，比如這裏提到的 Heptio 和 VMware。Kubernetes 社區中也有多集羣聯邦管理的能力在推進（注意：這個項目目前已經被 RedHat 基於 Kubernetes 的插件特性改造成了 Multi-Cluster 項目）。但這些並不是 Kubernetes 社區的主旋律，就目前情況而言，這個社區裏還有很多更重要也更令人興奮的事情要做。但需要指出的是，隨着 Kubernetes 項目和社區的進一步成熟，以及網絡、存儲和多租戶特性的完善，多集羣管理的優先級必然會在未來得到提升。
在 Kubernetes 基礎上的技術二次創新纔是容器生態的焦點
我在總結 2017 年的容器生態圈的文章裏說到在新的一年“曾經在國內外普遍開花的、以直接售賣 Kubernetes 集羣爲核心的各種‘CaaS’，將會沉寂許多”，但市面上從微軟 Azure 到國內的騰訊雲華爲雲都在提供“容器 +Kubernetes"服務。對此我仍然堅持自己的看法：
Kubernetes 已經成爲了所有公有云提供商的標配，但這並不意味着 2018 年依然是“CaaS”們的春天。事實上，對市場變化更加敏感的容器創業公司們基本上都已經關停了公有“CaaS”服務，轉而專注於企業落地或者諮詢業務。而現今的容器技術圈子裏真正“風聲水起”的，早已不是 Kubernetes 業務本身，而是以 Kubernetes 爲基礎所構建出來的整個容器技術二次創新的生態。
我們不妨先來看 Microsoft。2018 年，Azure 產品線上着重發力的明星業務是 ACI（Serverless Container 服務），重點推廣的開源項目是 virtual-kubelet（ACI 的 Kubernetes 插件）和 Brendan Burns 自己的 Metaparticle（Kubernetes 的 SDK）。儘管覆蓋面並不相同，但這些產品的本質都是圍繞着 Azure 本身的 Kubernetes 服務（ACS）逐步構建起來一系列 Serverless 業務，最終目的則是覆蓋從開發者到運維人員的完整業務流程，對用戶屏蔽學習曲線陡峭的 Kubernetes API。
然後來看 Google。Google Cloud 在 2018 年專門創建了一個名爲 GoogleContainerTools 的 GitHub Organization，在短短幾個月內密集發佈了一系列基於 Kubernetes 的容器技術工具，這包括了 Kubernetes 集羣專屬的鏡像製作項目 kaniko 和持續集成項目 skaffold。而在 Kubernetes 社區，Google 在重點發力的項目則是 Metacontroller，這是一個幫助用戶快速編寫符合 Kubernetes 編程範式的 API 插件的工具。
此外，Google Cloud 基礎設施團隊還在最近開源了基於用戶態操作系統內核的 gVisor 容器項目，開始進入容器運行時安全這一新興領域。作爲 Kubernetes 的發起者，Google 這一系列舉措的目的不言而喻，我們不妨小小預言一下：Google Cloud 的 Serverless 服務很快就會與大家見面了。
我們再來看 Heptio。Heptio 從創立一開始就推出的一系列開源項目，統統指向了 Kubernetes 集羣運維這一傳統痛點：Ark，Contour，Gimbal，Sonobuoy，分別對應 Kubernetes 集羣備份與恢復，負載均衡，Ingress 和配置管理，堪稱 Kubernetes 項目的“運維全家桶”。而 Heptio 也於近日放棄了原本在 sig-scheduling 的日常管理權限，轉而專注於 sig-cluster-lifecycle（集羣部署）的工作。不難看出，同樣作爲 Kubernetes 創始人之一，Joe Beda 的思路清晰而明朗。
而 CoreOS 在被 RedHat 收購之後在社區的首次發聲，則是高調宣佈了 Operator Framework 計劃。把已經在 Kubernetes 社區取得了顯著成績的 Operator 推到了一個全新的高度，大有一統作業管理領域的野心。這個舉措看似微不足道，實際上卻意義重大，要知道，Kubernetes 作業管理領域的領導權，近乎等同於把持了 Kubernetes 項目的用戶入口。這並非癡人說夢：同樣的故事已經在前 Deis 的 Helm 項目上上演過一次，而 CoreOS 只不過把這個故事複製在了使用場景更加的廣泛的有狀態作業上而已。
上述四位不同體量的 Kubernetes 玩家，正是當前整個容器技術圈的一個縮影。事實上，我們已經強調過很多次，Kubernetes 項目不會成爲一個新的 PaaS，它的設計初衷，不是直接在公有云上搶奪用戶入口；它的發展過程，也不需要迎合諸如“Build Ship Run”、CI/CD、“不可變基礎設施”等容器領域的熱詞。
Kubernetes 的現狀和未來，是成爲雲計算領域基礎設施的核心依賴，然後進一步催生出構建於其上的“容器化革命”。在雲計算平臺競爭日趨嚴酷的大環境下，單純基於 Kubernetes 的容器化 PaaS（或者“CaaS”），是完全不足以拉開不同服務商之間的差距的。而構建於 Kubernetes 之上的工具鏈、Serverless Container Instance、Secure Container Runtime、ACI、Fargate、FaaS 們纔是接下來雲平臺上爭搶用戶的主角。
虛擬化容器技術很可能在 Serverless 場景成爲主流
2017 年年底，OpenStack 基金會於 KubeCon 峯會正式發佈基於 Apache 2.0 協議的容器技術 KataContainers 項目，主要目標是使用戶能同時擁有虛擬機的安全和容器技術的迅速和易管理性。需要明確的是，KataContainers 並不是 OpenStack 基金會自己推出的項目，而是 Intel ClearContainer 和 Hyper runV 兩個獨立項目合併之後的產物。這個項目本身目前託管於 OpenStack 基金會並接受 OCI 的指導。以 KataContainers 爲代表的 Secure Container Runtime，目前是 Kubernetes 社區最高優先級的特性之一，並會以 API 的方式固化在 Kubernetes 項目中，其重要性可見一斑。
這其實很容易理解，前面已經提到過，公有云上的容器產品之爭，將會以各種形態的 Serverless 爲主旋律。而多租戶場景下高效的容器管理，Secure Container Runtime 幾乎是唯一的選擇。畢竟，傳統玩法先創建虛擬機再創建容器的執行效率，在 Serverless 場景下可謂捉肘見襟。而 Secure Container Runtime 無需虛擬機做宿主的關鍵特性，幾乎就是爲這種業務而生。無需多做猜測，未來世界上主流的公有云提供商都會上線 Serverless Container 服務，其中將有很大一部分會基於 KataContainers 或者類似技術來提供安全的容器環境。
另一方面，基於虛擬化的容器技術爲多租戶下的容器化業務提供了全新的可能，不同業務運行在不同的 Guest Kernel 之上、甚至 Linux 和 Windows 業務在同一宿主上混部，都是虛擬化容器的拿手好戲。更有甚者，譬如 Google gVisor 和 Hyper linuxd 項目，會選擇直接在用戶態運行定製後的 Guest Kernel，從而在保證虛擬化級別的隔離能力的同時進一步降低 Sandbox 帶來的性能損耗，在諸如 Serverless 等特定場景裏，這樣的安全容器技術將很有可能取代 Docker 成爲主流，甚至間接促使諸如 GAE 等傳統 PaaS 產品的“重生”。