351
In or Out? Kubernetes一統江湖的野心 - 寫在Kubernetes 1.6即將發布之際
如一切順利的話，Kubernetes 1.6將於3月29日發布。雖然比預期延遲了一周，但是趕在了KubeCon之前，對Kubernetes這個規模的項目來說已經實屬不易。為了慶祝1.6版本的發布，撰文一篇講講目前Kubernetes生態圈的現狀。
自2014年發布以來，Kubernetes發展迅速，從最開始以源自Google最佳實踐的容器管理平台亮相，再與Docker Swarm和Mesos一起爭奪容器編排領域的主導位置，到最近開始整合整個容器生態的上下遊。Kubernetes始終保持著小步快跑的節奏，在每個Release當中不斷推出新的Feature。同時Kubernetes背後的組織CNCF還在不斷吸收Kubernetes生態圈中的優秀開源項目，解決最終用戶在生產部署中所存在的監控、日誌搜集等需求。
如今，Kubernetes已經超越了單純的容器編排工具，企業選擇Kubernetes本質上是擁抱以Kubernetes為核心的雲原生最佳實踐。其中包含了網絡、存儲、計算等運行資源的調度，還涵蓋了監控、日誌搜集、應用分發、係統架構等研發和運維的操作流程。
容器引擎接口(Container Runtime Interface)
眾所周知，Kubernetes和Docker是既合作又競爭的關係。Kubernetes使用Docker Engine作為底層容器引擎，在容器編排領域與Docker Swarm展開競爭。為了減少對Docker的依賴，同時滿足生態中其他容器引擎與Kubernetes集成的需要，Kubernetes製定了容器引擎接口CRI。隨後Kubernetes發布了cri-o項目，開始研發自己的Docker兼容容器引擎。目前已經有Docker，rkt，cri-o三款容器引擎支持CRI接口。此外支持CRI的還有Hyper.sh主導的frakti項目以及Mirantis主導的virtlet項目，它們為Kubernetes增加了直接管理虛擬機的能力。
CRI的發布將Docker推到了一個非常難受的位置，如果不支持CRI，麵臨著在Kubernetes體係當中被其他容器引擎所替換的風險。如果支持CRI，則意味著容器引擎的接口定義被競爭對手所主導，其他容器引擎也可以通過支持CRI來挑戰Docker在容器引擎領域的事實標準地位。最終，為了不被邊緣化，Docker隻能妥協，選擇將containerd項目捐獻給CNCF。在同一天，CoreOS也宣布將rkt項目捐獻給CNCF。至此CRI成為了容器引擎接口的統一標準，今後如果有新的容器引擎推出，將首先支持CRI。
容器網絡接口(Container Network Interface)
因為Kubernetes沒有內置容器網絡組件，所以每一個Kubernetes用戶都需要進行容器網絡的選型，給新用戶帶來了不小的挑戰。從現狀來看，不內置網絡組件的策略雖然增加了部署的複雜度，但給眾多SDN廠商留下了足夠的公平競爭空間，從中長期來講是有利於容器網絡領域的良性發展的。
1.0版本的Kubernetes沒有設計專門的網絡接口，依賴Docker來實現每個Pod擁有獨立IP、Pod之間可以不經過NAT互訪的網絡需要。隨著與Docker的競爭加劇以及Docker主導的CNM接口的推出，Kubernetes也推出了自己的容器網絡接口CNI。
隨著CNI的推出，各家SDN解決方案廠商紛紛表示支持。目前Flannel，Calico，Weave，Contiv這幾款熱門項目均已支持CNI，用戶可以根據需要為自己的Kubernetes集群選擇適合的網絡方案。麵對CNI和CNM，主流廠商目前的選擇是同時支持，但從中長期來看，廠商一定會根據各個生態的發展進度來動態配置資源，這時Docker內置的原生網絡組件有可能反而會影響和其他網絡廠商的協作。
容器存儲接口(Container Storage Interface)
在統一了容器引擎和容器網絡之後，Kubernetes又將觸角伸到了存儲領域。目前還在製定過程當中的容器存儲接口CSI有望複製CRI和CNI的成功，為Kubernetes集群提供可替換的存儲解決方案。不論是硬件存儲廠商或是軟件定義存儲解決方案廠商，預計都將積極擁抱CSI。因為不支持CSI就意味著放棄整個Kubernetes生態圈。
軟件打包與分發(Packaging and Distribution)
在使用CRI，CNI，CSI解決底層運行環境的抽象以外，Kubernetes還在試圖通過Helm項目以及Helm Charts來統一軟件打包與分發的環節。由於Kubernetes提供了底層的抽象，應用開發者可以利用Kubernetes內置的基礎元素將上層應用打包為Chart，用戶這時就能使用Helm完成一鍵安裝以及一鍵升級的操作。
在係統架構越來越複雜的今天，能夠方便的將複雜的分布式係統運行起來，無疑為Kubernetes的推廣增加了不少亮點。目前一些常見的開源係統，比如Redis，ElasticSearch等已經可以通過使用官方的Charts進行部署。相信未來會有更多的開源項目加入這個清單。
看到這一塊商機的公司，比如CoreOS，已經推出了自己的軟件倉庫服務。由於這塊離最終用戶最近，相信未來在這一領域的競爭將會非常激烈。
雲原生計算基金會(Cloud Native Computing Foundation)
前麵列舉的案例主要偏重技術解決方案，Kubernetes最有潛力的其實是在幕後團結容器生態中各方力量的CNCF組織。與同期建立的Docker主導的OCI組織相比，當前CNCF不論是在項目數量，會員數量，會員質量等多個方麵都明顯領先。可以說CNCF是事實上在推動整個容器生態向前發展的核心力量。
人的力量是最根本的也是最強大的，隻有團結到盡可能多的玩家，才能製定出各方都能接受的標準。麵對這麼多的會員企業，要平衡各方的訴求實在不是容易的事情。目前CNCF做的還不錯，中立的基金會形式似乎更加容易被各方所接受。最近正在進行決策小組選舉的討論，有興趣的朋友可以自行圍觀。
總結
有兩句經常聽到的話在Kubernetes身上得到了很好的體現，一是沒有什麼是不能通過增加一個抽象層解決的，二是一流的企業做標準，二流的企業做品牌，三流的企業做產品。Kubernetes通過在具體實現上增加抽象層，試圖為整個容器生態圈建立統一的標準。當標準逐步建立，用戶開始依照標準選擇解決方案，將進一步強化Kubernetes位於整個容器生態核心的地位。這時容器生態的上下遊將不得不麵對，要麼選擇In擁抱Kubernetes所提出的標準，要麼選擇Out被整個生態圈孤立的情況。麵對這種選擇，想必大部分廠商都將選擇In，而更多的廠商加入將進一步強化標準的力量。
可以預見Kubernetes構建的組織、標準、開源項目三層體係，將有望統一容器生態圈的各方力量，而這種統一對最終用戶是有益的。在容器生態中的各個領域，開源的解決方案將與商業解決方案直接競爭，甚至開源解決方案之間也將展開競爭。這種競爭將促進整個容器生態的發展，由於大家都遵守相同的標準，不論你在最初建設時選擇的是哪一套解決方案，將來也可以用更新更好的方案來替換，規避了商家綁定的風險。希望捐獻給CNCF的項目將會越來越多，因為進入CNCF就意味著比其他相同功能的開源項目更加容易獲得Kubernetes生態圈的認可。
最後插播一條小廣告，為了解決Kubernetes與各個雲平台之間的對接問題，我們開源了一款基於Kubernetes對底層雲平台進行自動化運維的係統，目前已經支持阿裏雲。項目叫做Archon，地址在 https://github.com/kubeup/archon 。希望Archon可以幫助Kubernetes統一對底層雲平台的管理和操作方法，使得用戶不論使用哪一家雲平台均可以使用相同的方法進行運維和管理，以便用戶可以在多個雲平台之間自由的遷移。有興趣的朋友可以試用並給我們反饋，幫助我們完善。
3月29日，將在德國柏林舉辦CloudNativeCon + KubeCon Europe，屆時會帶來更多關於Kubernetes 1.6的介紹，對Kubernetes感興趣的同學可以關注，更多激動人心的消息在等著大家。
最後更新：2017-04-01 16:41:01