容器雲未來:Kubernetes、Istio 和 Knative
導讀
目前以Kubernetes為基礎構建的容器生態逐漸完善,這其中Kubernetes、Istio、Knative三個獨立項目被越來越多的人提及,並且已經開始嘗試大規模落地實踐,它們恰好構成了容器雲的未來拼圖。今天與大家一起分享下,這三個項目究竟解決了什麼問題,為什麼它們能夠一鳴驚人。
隨著微服務理念不斷深入人心,越來越多的企業把自己的應用逐步由單體轉變成微服務架構,Container容器技術的出現恰恰加速了這個轉移過程,因為它有效地解決了N多服務的快速部署問題。但是隨著服務數目的增多,越來越多的企業希望能夠把相關服務有效地「聚合」在一起,方便統一部署與管理。Kubenretes的出現恰恰解決了大規模微服務編排部署所帶來的挑戰,讓整個行業意識到PaaS的落地可以成為現實。
當隨著微服務體系下的服務數目越來越多,服務運維成為必然要解決的問題,於是Istio出現了,基於網路代理與控制相分離的實現策略,允許對服務控制策略進行有效合理的管控。
到這裡似乎到了很美好的階段:
- 微服務:解決應用內聚、臃腫的問題。
- Container:解決服務運行環境統一,和部署問題。
- Kubernetes:解決大量微服務有效「聚合」部署問題。
- Istio:解決服務上線面臨的一系列治理問題。
這個階段乍一看來,構建容器雲似乎有了一個完整的鏈路和解決方式,一切都將變得那麼「完美」。
現在讓我們回過頭來深入分析一下,微服務體系下的服務交互,目前是否存在問題。
首先,無論是http,還是rpc,本質上都是服務與服務的遠程調用。開發應用程序中,無法做到服務與服務間的彼此透明。這樣會導致一個問題:無論微服務業務拆分多麼「精細」,本質上業務單元之間還是不能夠獨立運行和發展。同時在面向不同開發領域的衍生,無法選擇最合適的實現方式。因此我們希望能夠基於不同的「模板」+「配置」的方式能夠把開發環境標準化處理,同時提供「事件」機制,將服務與服務交互的耦合度降到最低。
其次,服務線上運行的動態伸縮問題。當下kubernetes環境下的彈性伸縮,需要由客戶蒐集監測數據,並自主手動來實現,但是我們更希望服務線上能夠更加自動化和智能化。
最後,服務標準化問題。我們希望服務內部的模型是標準的、能夠快速複製和快速構建的;服務通信是標準的:協議標準,格式標準;運行環境是標準的:快速部署,快速遷移。
Knative的出現恰好解決遠程直接調用,服務線上自動管理以及一些列標準化問題。
下面我們來看一下三者的關聯: