去年我寫了一篇題為《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更容易入門，但在生產環境下的實施卻比較困難。因此，最理想的辦法自然是將叢集託管工作交由第三方打理，而您自身建立專項團隊負責根據業務情況評估叢集的彈性需求。
再看這一條預測，預測正確。 僅僅擁有Kubernetes還遠遠不夠。因此到目前為止，我們已經在服務目錄方面投入了將近一年的時間。我們的客戶不僅在談論Kubernetes，同時也在談論Istio、Prometheus、Kibana等等。他們希望從這些雲原生工具中獲益，但又不希望因為新工具的引入而提升日常管理開銷。有了Giant Swarm的管理，我們的客戶可以專註於管理核心業務所需的應用程式。總之，託管型Kubernetes正逐漸轉化為託管型雲原生技術棧。因此，我覺得新一年的預測不妨更大膽一點。至於這些推斷是否成立，我將在2019年年底的時候再做一番回顧。
1. 大型企業將會在Kubernetes上加大投入
在這一領域中，我們已經看到大型雲服務提供商，以及IBM與VMWare等其他參與者。 Red Hat和Heptio的收購舉措表明這些公司正在積極進軍這一市場。 當然，這些主要面向支援層面。而如果著眼於管理服務市場，以埃森哲為代表的很多公司將繼續為需要強化自身業務的客戶提供服務。 隨著基礎設施迎來更多重大變化，整個行業也將重新洗牌。這裡所指的大型企業也包括一部分規模較大的財富500強企業，他們決定以Kubernetes為基礎重構內部平臺，並利用開源工具規劃自己的發展方向。考慮到客觀存在的人才稀缺性壓力，這些企業未來也將釋出更多開源工具並邀請貢獻者加入進來。我將在第五條預測中對這一主題做出進一步討論。
安裝Kubernetes非常簡單，但是接下來呢？我們更關註後續運營工作，包括在安全性、更新、事後分析等方面進行測試與驗證。大型企業將在生產流程中爭分奪秒地推出更新的版本，而CVE漏洞在生產過程中也將快速得到修複。客戶需要這種能力，並需要努力調整自身流程以適應這樣的新常態。我們已經和許多在這方面遇到過難題技術的客戶進行交流，他們仍然在執行Kubernetes 1.8或更低版本，而且還沒有升級的打算。這將給他們留下巨大的安全漏洞——因為最近的補丁只面向Kubernetes的1.10或更高版本。
您將看到大資料參與方盡其所能支援Kubernetes。 這些企業將把他們的生產系統從龐大但陳舊的大資料技術棧中剝離出來。此外，他們還將從專有雲服務提供商技術棧轉向支援多叢集環境的專業Kubernetes解決方案。 雲與非雲之間的區別將因此變得逐漸模糊，但必須承認，整個轉移過程可能需至少一年的時間才能完成。我建議大家關註Dotscience與Aljabr等公司的動向。
如果不在Kubernetes當中執行自己的控制平面，我們將無法實現Kubernetes的規模化運作。我們使用Operators（自定義控制器）來管理租戶叢集。而且無論是否使用Operators，各參與方都將高度關註這一趨勢，因為事實證明單憑一套叢集並不足以解決所有問題。在這方面，Cluster 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/
知識星球