容器雲未來：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在未來會成為建構容器雲的三駕馬車。

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