歡迎光臨
每天分享高質量文章

繼往方可開來:Kubernetes 2018態勢回顧與2019年前景展望

 

去年我寫了一篇題為《Kubernetes過去到未來之旅》(https://blog.giantswarm.io/kubernetes-and-giantswarm-in-2018/)的文章。在本文中,我談到了我們技術棧的KVM與AWS版本,以及即將推出的Azure版本。此外,我還提到了最近兩年如過山車一般起伏不定的技術變化態勢。下麵,我們一同回顧一下去年我做出的部分預測:

1. Kubernetes將進一步成為“雲API”(The Cloud API)

 

我想我們可以回看這一條預測。過去的12個月時間里,Kubernetes已經成為絕對的焦點,在增長度和關註度方面皆擁有驚人表現。IBM收購了Redhat並藉此將OpenShift招至麾下,VMware買下Heptio,KubeCon的與會群體也快速由數百人增長至數千人。這些例子也說明Kubernetes已經成為主流。當我們與正在構建現代化技術棧的公司討論技術問題時, Kubernetes往往是個無法迴避的話題。

 

2. Kubernetes的管理與支持業務規模開始擴展,並確定自身發展方向

 

再來看這條預測。用戶對於使用我們的平臺運行大規模Kubernetes保持愈發濃厚的興趣。 一年或兩年前開始嘗試Kubernetes的組織現在已將其引入生產環境。 他們發現Kubernetes編排方案與以往的業務規劃思路存在很大的不同。 Kubernetes更容易入門,但在生產環境下的實施卻比較困難。因此,最理想的辦法自然是將集群托管工作交由第三方打理,而您自身建立專項團隊負責根據業務情況評估集群的彈性需求。

 

3. Kubernetes將走向消亡

 

再看這一條預測,預測正確。 僅僅擁有Kubernetes還遠遠不夠。因此到目前為止,我們已經在服務目錄方面投入了將近一年的時間。我們的客戶不僅在談論Kubernetes,同時也在談論Istio、Prometheus、Kibana等等。他們希望從這些雲原生工具中獲益,但又不希望因為新工具的引入而提升日常管理開銷。有了Giant Swarm的管理,我們的客戶可以專註於管理核心業務所需的應用程式。總之,托管型Kubernetes正逐漸轉化為托管型雲原生技術棧。因此,我覺得新一年的預測不妨更大膽一點。至於這些推斷是否成立,我將在2019年年底的時候再做一番回顧。
2019年關於雲原生市場的預測:

 

1. 大型企業將會在Kubernetes上加大投入

 

在這一領域中,我們已經看到大型雲服務提供商,以及IBM與VMWare等其他參與者。 Red Hat和Heptio的收購舉措表明這些公司正在積極進軍這一市場。 當然,這些主要面向支持層面。而如果著眼於管理服務市場,以埃森哲為代表的很多公司將繼續為需要強化自身業務的客戶提供服務。 隨著基礎設施迎來更多重大變化,整個行業也將重新洗牌。這裡所指的大型企業也包括一部分規模較大的財富500強企業,他們決定以Kubernetes為基礎重構內部平臺,並利用開源工具規劃自己的發展方向。考慮到客觀存在的人才稀缺性壓力,這些企業未來也將發佈更多開源工具並邀請貢獻者加入進來。我將在第五條預測中對這一主題做出進一步討論。

 

2. 重點在於後續運營

 

安裝Kubernetes非常簡單,但是接下來呢?我們更關註後續運營工作,包括在安全性、更新、事後分析等方面進行測試與驗證。大型企業將在生產流程中爭分奪秒地推出更新的版本,而CVE漏洞在生產過程中也將快速得到修複。客戶需要這種能力,並需要努力調整自身流程以適應這樣的新常態。我們已經和許多在這方面遇到過難題技術的客戶進行交流,他們仍然在運行Kubernetes 1.8或更低版本,而且還沒有升級的打算。這將給他們留下巨大的安全漏洞——因為最近的補丁只面向Kubernetes的1.10或更高版本。

 

3. 大資料將轉移至Kubernetes

 

您將看到大資料參與方盡其所能支持Kubernetes。 這些企業將把他們的生產系統從龐大但陳舊的大資料技術棧中剝離出來。此外,他們還將從專有雲服務提供商技術棧轉向支持多集群環境的專業Kubernetes解決方案。 雲與非雲之間的區別將因此變得逐漸模糊,但必須承認,整個轉移過程可能需至少一年的時間才能完成。我建議大家關註Dotscience與Aljabr等公司的動向。

 

4. 控制平面的崛起

 

如果不在Kubernetes當中運行自己的控制平面,我們將無法實現Kubernetes的規模化運作。我們使用Operators(自定義控制器)來管理租戶集群。而且無論是否使用Operators,各參與方都將高度關註這一趨勢,因為事實證明單憑一套集群並不足以解決所有問題。在這方面,Cluster API是個值得關註的重要專案。
客戶將在零售、工業以及物聯網工作負載的邊緣建立更多集群。通過為每個站點建立獨立集群,客戶可以更輕鬆地將應用程式部署到對應位置並加以更新。然而,集群數量的增加也對我們的自動化能力提出更高要求。

 

5. 擴展Kubernetes API

 

這一項預測分為兩大主要方面:
第一:越來越多的應用程式將由定製化資源定義(簡稱CRD)進行部署與管理。 獨立軟體供應商(ISV),特別是將軟體以工具包的形式交付的供應商,將在產品中引入持續更新機制,或者利用Operators實現同樣的效果。這類軟體通常會打包為Helm圖表。
第二:Kubernetes主要使用CRD擴展自身各項新舊功能。一方面,這種新機制將作用於集群API——例如Giant Swarm或者上游Cluster API。 另一方面,其也將影響到以Kubernetes為基礎的各類平臺,例如 ML / AI平臺、PaaS類產品以及CI / CD管道等,未來這一切都將以原生Kubernetes擴展的形式呈現。
在Giant Swarm,我們正在利用CRD取代我們的API網關並直接使用Kubernetes API。 這讓我們可以充分發揮Kubernetes功能的作用,例如RBAC和Admission Controllers。 此外,我們的API也因此得以更輕鬆地與我們的Operators進行交互。當然,這種規模擴展將增加API服務器作為事件管理器的負載強度。 因此,社區將致力於擴展API服務器和etcd本身,或者採用群集外解決方案。
總之,Kubernetes現在已經成為真正的主流。 對於大型服務提供商及大用戶來說,這是一個絕對不容忽視的焦點。 然而,Kubernetes的發展也絕非毫無波瀾。 這一方面將給大規模運營帶來挑戰,另一方面也將在生態系統之內表現為諸多變化與極快的發展速度。 大家對我的2019年Kubernetes展望作何感想?請在評論中分享您的真知灼見:)
原文鏈接:https://blog.giantswarm.io/the-state-of-kubernetes-2019/
赞(0)

分享創造快樂