容器雲將來：Kubernetes、Istio 和 Knative

導讀

目前以Kubernetes爲基礎構建的容器生態逐漸完善，這其中Kubernetes、Istio、Knative三個獨立項目被愈來愈多的人說起，而且已經開始嘗試大規模落地實踐，它們剛好構成了容器雲的將來拼圖。今天與你們一塊兒分享下，這三個項目究竟解決了什麼問題，爲何它們可以一舉成名。

 

隨着微服務理念不斷深刻人心，愈來愈多的企業把本身的應用逐步由單體轉變成微服務架構，Container容器技術的出現偏偏加速了這個轉移過程，由於它有效地解決了N多服務的快速部署問題。可是隨着服務數目的增多，愈來愈多的企業但願可以把相關服務有效地「聚合」在一塊兒，方便統一部署與管理。Kubenretes的出現偏偏解決了大規模微服務編排部署所帶來的挑戰，讓整個行業意識到PaaS的落地能夠成爲現實。

 

當隨着微服務體系下的服務數目愈來愈多，服務運維成爲必然要解決的問題，因而Istio出現了，基於網絡代理與控制相分離的實現策略，容許對服務控制策略進行有效合理的管控。

 

到這裏彷佛到了很美好的階段：

• 微服務：解決應用內聚、臃腫的問題。

• Container：解決服務運行環境統一，和部署問題。

• Kubernetes：解決大量微服務有效「聚合」部署問題。

• Istio：解決服務上線面臨的一系列治理問題。 

 

這個階段乍一看來，構建容器雲彷佛有了一個完整的鏈路和解決方式，一切都將變得那麼「完美」。

 

如今讓咱們回過頭來深刻分析一下，微服務體系下的服務交互，目前是否存在問題。

 

首先，不管是http，仍是rpc，本質上都是服務與服務的遠程調用。開發應用程序中，沒法作到服務與服務間的彼此透明。這樣會致使一個問題：不管微服務業務拆分多麼「精細」，本質上業務單元之間仍是不可以獨立運行和發展。同時在面向不一樣開發領域的衍生，沒法選擇最合適的實現方式。所以咱們但願可以基於不一樣的「模板」+「配置」的方式可以把開發環境標準化處理，同時提供「事件」機制，將服務與服務交互的耦合度降到最低。

 

其次，服務線上運行的動態伸縮問題。當下kubernetes環境下的彈性伸縮，須要由客戶蒐集監測數據，並自主手動來實現，可是咱們更但願服務線上可以更加自動化和智能化。

 

最後，服務標準化問題。咱們但願服務內部的模型是標準的、可以快速複製和快速構建的；服務通訊是標準的：協議標準，格式標準；運行環境是標準的：快速部署，快速遷移。

 

Knative的出現剛好解決遠程直接調用，服務線上自動管理以及一些列標準化問題。

 

下面咱們來看一下三者的關聯：

 

 

Kubernetes和Istio相信你們比較熟悉了，這裏不作過多介紹，有須要的同窗能夠關注下咱們以前發佈的相關文章，這裏咱們重點來看一下Knative。

 

Knative是谷歌開源的serverless架構方案，旨在提供一套簡單易用的serverless方案，把serverless標準化。目前參與的公司主要是Google、Pivotal、IBM、Red Hat，於2018年7月份對外發布，目前處於快速發展階段。

 

 

Knative組成

 

Build

構建系統：把用戶定義的應用構建成容器鏡像，面向kubernetes的標準化構建，區別於Dockerfile鏡像構建，重點解決kubernetes環境的構建標準化問題。

 

Serving

服務系統：利用Istio的部分功能，來配置應用路由，升級以及彈性伸縮。Serving中包括容器生命週期管理，容器外圍對象（service，ingres）生成（恰到好處的把服務實例與訪問統一在一塊兒），監控應用請求，自動彈性負載，而且利用Virtual service和destination配置服務訪問規則。只有這樣才能保證服務呈現一致性以及服務運行自動化管理。

 

Eventing

事件系統：用於自動完成事件的綁定與觸發。事件系統與直接調用最大的區別在於響應式設計，它容許運行服務自己不須要屏蔽了調用方與被調用方的關係。從而在業務層面可以實現業務的快速聚合，或許爲後續業務編排創新提供事件。

 

如今咱們換一個角度，聚焦應用服務生命週期：

• Knative 解決應用模板+面向統一環境的標準化構建場景；

• Kubernetes做爲基礎設施，解決應用編排和運行環境場景；

• Isito做爲通訊基礎設施層，保證應用服務運行可檢測、可配置、可追蹤問題。

 

這三者貫穿應用服務生命週期全過程，容器雲偏偏也是管理應用服務的控制平臺，這就可以很好地解釋，爲何Kubernetes，Istio，Knative在將來會成爲構建容器雲的三駕馬車。

 

本文由博雲研究院原創發表，轉載請註明出處。