來源:K8sMeetup 中國社區(qū),ID:kuberneteschina
翻譯:夏天
校對:岑鵬浩
今天的這個故事出自“江湖”,一半關(guān)于各路豪杰的江湖紛爭、聚合反目;另一半關(guān)于 Kubernetes 從初出茅廬到異軍突起走過的蛻變之路。
“ 如果有一個 workload 到了亞馬遜那兒,你們就完了!” 2013 年,VMware 公司首席執(zhí)行官 Pat Gelsinger 在公司的合作伙伴交流大會(Partner Exchange Conference)如是說?!艾F(xiàn)在到永遠,我們都要擁有公司的 workload”。作為前英特爾資深經(jīng)理, Gelsinger 的這些話對云計算五年前的情景作了很好的還原:彼時,VMware 還認為自己是宇宙的中心,并試圖捍衛(wèi)和鞏固自己的地位。亞馬遜正努力將數(shù)據(jù)中心遷移到自己的公有云領(lǐng)域。
那時的 Gelsinger 肯定沒想到,四年后,他確實再也不用擔(dān)心失去公司的 workload 了。一場讓他意想不到的“江湖紛爭”即將襲來,他要對付的可不僅僅是老對手 Amazon 了。
重新洗牌
VMware 一統(tǒng)江湖
“VMware” 中的 “VM” 代表虛擬機,它成為了組織在云平臺上部署應(yīng)用程序的第一個工具。虛擬機的出現(xiàn)引發(fā)了大眾對“可移植性” (即在任何地方都能部署應(yīng)用程序)的渴望。但是 VMware 聰明地通過部署和管理虛擬機的方式來保護自己的利益,使得 vSphere 成為所有入站道路的必須監(jiān)督者。
理想的踐行者 Docker
然后,Docker 出現(xiàn)了。它是第一個將“可移植性”賦予數(shù)據(jù)中心的工具。2013 年,Docker 開發(fā)了一個容器機制,將 workload 從笨重的操作系統(tǒng)中解救出來,來維護虛擬機。這樣,他們就可以使用 Linux kernel 而不是虛擬機監(jiān)視器來進行管理。這是當(dāng)時眾多組織觸不可及的 “革命理想”,但只有 Docker 踐行并實現(xiàn)了。
從出現(xiàn)伊始, Docker 就遭遇了來自企業(yè)的質(zhì)疑目光。同時出現(xiàn)的還有一個廣為流傳的論斷:一個新的市場即將圍繞著 Docker 容器形成。套用 PC 世界的舊模板,軟件市場當(dāng)時也是圍繞格式和兼容性形成的。推斷下去,接下來將出現(xiàn)各大容器公司相互競爭的局面,然后是優(yōu)勝劣汰,緊接著 Docker 或者其他更強大的競爭對手,會從對手的灰燼中取得最終勝利。
只有當(dāng)“可移植性”無處不在時,才實現(xiàn)了真正的可移植。2015 年,Docker 放大膽子賭了一把,將整個容器 format 捐贈給了 Linux 基金會贊助的一個開源項目。這個項目現(xiàn)在被稱為 Open Container Initiative(OCI)。彼時的 Docker 計劃先行一步,放棄人人想要的“可移植性”,讓容器 format 增值。Docker 捐贈了容器 format,讓競爭對手再也找不到與之競爭的明確方向,Docker 篤定它的未來就在部署和維護容器 workload 的機制上。
Kubernetes 初出茅廬
就在同年,谷歌推動建立了一個獨立基金會:Cloud Native Computing Foundation (CNCF)。 CNCF 與 OCI 有很多相同的成員,但 CNCF 專注于容器 workload 的成員們,試圖在“部署和管理”方面尋找競爭優(yōu)勢。緊接著,CNCF 就推出了 Kubernetes,這個編排工具將谷歌工作workload staging 概念與 Docker 容器相結(jié)合(最初名為“Borg”)。
Red Hat 公司圍繞 Kubernetes 重建了 OpenShift PaaS 平臺,而 CoreOS 將其業(yè)務(wù)重點轉(zhuǎn)向 Tectonic,即 Kubernetes 的商業(yè)實施。
Kubernetes 的野蠻生長
就像推倒了一塊多米諾骨牌,容器領(lǐng)域的眾多利益相關(guān)者在 2017 年一個接一個地將部署和管理戰(zhàn)略倒向了 Kubernetes,包括 Docker 公司本身 :
4 月,托管的 OpenStack 云管理服務(wù)提供商 Mirantis,宣布將 Kubernetes 集成到其云平臺 1.0 中,并承諾將其 Staging 和配置機制的重點從以安裝人員為中心模式,轉(zhuǎn)向以 workload 為中心模式。
同月,微軟收購了基于 Kubernetes 的容器部署平臺制造商 Deis,以前所未有的姿態(tài)向 Azure 開放平臺遷移。緊接著 Deis 技術(shù)在 Azure 上出現(xiàn)。 ( 2016 年 6 月微軟就已經(jīng)從 Google 挖走了 Kubernetes 的創(chuàng)始人 Brendan Burns。)
5 月,在波士頓舉行的 OpenStack 峰會上,OpenStack 許多社區(qū)領(lǐng)導(dǎo)齊聚一堂,承認 Kubernetes 是其私有云模型中,容器 workload 的事實 staging 環(huán)境。當(dāng)時還有一個亟待解決的問題:Kubernetes 或 OpenStack 究竟應(yīng)該留在虛擬基礎(chǔ)架構(gòu)的最底層,還是應(yīng)該針對每個客戶的情況合理地解決這個問題?
幾乎在同時,IBM 推出了 Kubernetes 支持的云容器服務(wù),向客戶提供了一種無縫、即刻啟動 Docker 容器的方法。
6 月初,Oracle 在開源會議上承認 Kubernetes 是其新容器 Staging 策略的核心。作為 Docker 的競爭對手,CoreOS 自從平臺成立以來就被稱為 “Tectonic 的商用 Kubernetes 環(huán)境的生產(chǎn)者”。 CoreOS 把最小的 Linux kernel 貢獻給 Oracle,Oracle 把自己的 Linux 踢到了一邊。
6 月末,在 Cloud Foundry 峰會上,Cloud Foundry 基金會發(fā)布了 Kubo,這是一種在傳統(tǒng)機器內(nèi)部 staging Kubernetes 的多個負載均衡實例的工具。這為 8 月份的 VMware 和 姊妹公司 Pivotal 與 Google 建立合作關(guān)系并推出 Pivotal Container Service (PKS)打下基礎(chǔ)。這個消息發(fā)布于 Amazon 與 VMware 建立合作伙伴關(guān)系一天后,當(dāng)時 Kubo 已經(jīng)為 Google 云平臺定制進行了商業(yè)實施。值得注意的是,在整個 PKS 首次發(fā)布會期間,“Docker” 這個詞一次也沒被提過。(10 月份,Kubo 項目更名為 Cloud Foundry Container Runtime。)
8 月初,亞馬遜終于下了“賭注”,加入了 CNCF,并承諾做出實質(zhì)性貢獻。
9 月中旬, Oracle 也正式加入了 CNCF。
9 月中旬,Mesosphere 做出了一個相當(dāng)驚人的舉動,在 beta 版本中,加入了一種整合這兩個平臺的方法。其用戶可以安裝、擴展和升級多個生產(chǎn)級 Kubernetes 集群。
10 月中旬,這場容器競爭戰(zhàn)似乎發(fā)出了即將結(jié)束的信號。Docker 宣布擁抱 Kubernetes,Docker 的創(chuàng)始人 Solomon Hykes 在大會上宣布:下一個版本的 Docker 將支持兩種編排平臺—— Swarm 和 Kubernetes!
10 月下旬,微軟推出了一個專門 Azure 容器服務(wù)(AKS)預(yù)覽版,這一次 Kubernetes 不僅站在了“舞臺” 中央上,而且 “K” 還是最中間的字母。不久之后,該公司的市場營銷和網(wǎng)站給出了它的 Kubernetes 平臺的第一個版本,推出了基于 DC / OS 的容器 Staging 平臺作為備選方案。
在同一個月,思科在基于 ACI 的數(shù)據(jù)中心架構(gòu)和谷歌云之間,通過 Kubernetes 宣布了一個名為 Goodzilla 的 Bridge。
11 月底,亞馬遜正式推出了自己的 AKS 容器服務(wù),并把 AWS 云與 Google 和 Azure 相提并論。
此消彼長
從市場角度來看,所有這些發(fā)展都表明:谷歌已經(jīng)成功地控制了所有通向數(shù)據(jù)中心容器化道路。眾所周知,沒有可移植性的容器是毫無意義的,對于數(shù)據(jù)中心的客戶們來說,一個 Staging 和編排環(huán)境是遠遠不夠的。
微軟第一個證明,通過開源核心優(yōu)勢來迅速占領(lǐng)市場是個可行的辦法。當(dāng)年,它讓 Internet Explorer 變得免費,逼得 Netscape 只能通過增加大量不必要的新功能慌張回擊,最終還是落得失敗下場。Docker 顯然也知道這個道理,開源了容器 format,讓同類產(chǎn)品不能與之爭鋒。
然而,Docker 還是沒有如當(dāng)日所愿,建立自己的增值路線——就是那個可以通過開源手段來占領(lǐng)市場的“大殺器”。有人可能覺得,Docker 的基于集群的編排平臺 Swarm 還不“成熟”??墒?Kubernetes 在向 Docker 發(fā)起進攻的時候可能更“幼稚”,但它有自己的“殺手锏”:相關(guān)的容器可以分組到 pod 中。
Red Hat 第一個出來,利用 OpenShift 來展示這一“殺手锏”, 這使得眾多開源貢獻者都對 Kubernetes 魂牽夢繞。在 Docker 移動創(chuàng)建 OCI 之后, Google 幾乎馬上就允許 Linux 基金會建立 CNCF,他們的成員幾乎是同一撥人,這確保 OCI 部分的設(shè)計不會讓 CNCF 感到意外,同時也保證了 Kubernetes 在社區(qū)討論桌上的好位置。
Kubernetes 正在進行時
以下是 Kubernetes 正在進行時,在 2018 年肯定會讓 Kubernetes 受益:
CSI 項目:這個項目最近得到了戴爾技術(shù)公司(戴爾 EMC 的母公司)的支持,這個項目承諾,將通過與數(shù)據(jù)庫和 Storage Volume 保持持久鏈接,提供微服務(wù) 。使用 CSI 接口,任何打開這種持久鏈接的 API 都可以通過三個主要容器編排平臺:Kubernetes,Mesos(DC / OS)和 Swarm 進行同樣尋址。它目前由 Moby 管理,而 Moby 卻是由 Docker 原始的開放源代碼產(chǎn)生的,但現(xiàn)在 Moby 有一個獨立的方向。這對于 Kubernetes 而言非常有利,開源數(shù)據(jù) Plugins 的主題再也不是 Docker 領(lǐng)地中的本地特性了。
CRI-O 項目:它利用 Kubernetes 的原生 Container Runtime Interface (CRI),使容器編排平臺能夠通過本地 API(一個稱為“runtime”的可尋址組件)實例化一個容器。目前在許多數(shù)據(jù)中心,生產(chǎn)環(huán)境把 Docker Engine 作為 Orchestrator 和 Runtime 之間的中介; CRI-O 專門為 Kubernetes 提供讓 Docker 完全隔離在生產(chǎn)環(huán)境的方法,讓它只能出現(xiàn)在開發(fā)人員的工作臺上。
Kata 項目:Kata 與 Docker 的競爭對手 Hyper 一同加入英特爾的 Clear Containers 項目中。Kata 可以為數(shù)據(jù)中心提供構(gòu)建和部署 workload 的方法,Docker 將會完全被淘汰,同時還能夠在基于容器的 workload 和第一代虛擬機之間共存。OpenStack 基金支持這個項目,它將利用 Kubernetes 作為其主要容器編排平臺。
然而即便迎來了如此全勝局面,Kubernetes 仍然面臨著巨大的挑戰(zhàn)。具體來說,Kubernetes 可能變得如此無處不在,如此標(biāo)準(zhǔn)化,以至于任何供應(yīng)商或開源貢獻者都難以圍繞它再創(chuàng)造競爭優(yōu)勢了。
路漫漫其修遠兮
對于數(shù)據(jù)中心來說,Kubernetes 的突然出現(xiàn)意味著:過去基于公有云的 PaaS 平臺,如 Heroku 和原來的 Windows Azure,只有使用它支持的資源和語言才可用。而現(xiàn)在,只要使用 Kubernetes,每個人的平臺都支持默認容器,而不需要額外的資源配置。這有助于在一定程度上平衡服務(wù)提供商,因為他們現(xiàn)在都可以提供相同的界面來獲取和托管客戶的 workload。這也縮小了這些提供者在服務(wù)上彼此競爭的空間。規(guī)律如此,每當(dāng)市場商品化,幸存者都是那些贏得價格戰(zhàn)的人。
Kubernetes 可能已經(jīng)在 2017 年完全超過了 Docker。但是市場瞬息萬變,誰又能保證在 2018 年 Google 或其他任何人不會超過它呢,江湖路遠,讓我們拭目以待!