IBM雲計算CTO講述Istio項目的起源、分工及目標

時間 2019-12-02

標籤 ibm 計算 cto 講述 istio 項目起源分工目標欄目職業生涯简体版

原文原文鏈接

本文原標題爲：Istio目標是成爲容器化微服務的網狀管道git

在精彩的軟件容器世界中，本來早已解決的問題又有新的解決方案出現，給人有種恍惚的感受。在許多狀況下這些問題好久之前就獲得瞭解決，但現代雲原生架構的出現，推進部署更大規模的應用程序，這就須要新的工具和方法來管理這些服務。程序員

微服務就是一個很好的例子。在此模型下，典型的應用程序或服務將被分解爲可獨立部署的功能模塊，這些模塊能夠彼此分開擴展和維護，而且連接在一塊兒以提供整個應用程序或服務的所有功能。github

在使用容器開發微服務時，後者多是比較棘手的部分。當全部組件可能分佈在服務器節點集羣中，而且它們的實例不斷上線並被更新的版本替換時，如何將它們鏈接起來？在面向服務的體系結構（SOA）中，微服務能夠被看做是進化的繼承者，這種任務相似於企業服務總線（ESB）所處理的任務。所以，咱們須要的是ESB的雲原生版本。編程

這是一個相對較新的開源項目Istio旨在填補的工做。它被正式描述爲服務網格，由於它的一部分與基礎設施一塊兒分佈在它管理的容器旁邊，而且它開始着手知足服務發現、負載均衡、消息路由、遙測和監控的要求，固然還有安全。後端

Istio源自IBM和谷歌之間的合做，實際上包含了一些現有的組件，特別是由打車服務公司Lyft開發的組件。它以某種形式存在至少一年，但最終在7月底達到1.0版的里程碑，這意味着它如今終於被認爲足夠成熟，能夠做爲生產基礎設施的一部分來運行。安全

IBM研究員兼IBM雲計算首席技術官Jason McGee告訴The Next Platform，雲原生生態系統已基本肯定容器做爲核心打包和運行時構造，而Kubernetes則做爲管理容器的編排系統。但McGee解釋說，還有第三塊謎題還在空中，Istio旨在知足這一要求。服務器

「如何管理在容器平臺上運行的應用程序或服務之間的交互？」McGee問道。「若是您正在構建微服務，或者您有一組應用程序，那麼應用程序之間的通訊會出現不少有趣的問題。您如何瞭解究竟是那些服務在交互，性能以及如何收集應用程序之間通訊的數據，如何保護控制哪些服務能夠相互通訊的通訊，以及如何確保應用程序的安全，特別是在咱們今天使用的更動態或分佈式架構狀況下，您可能在公有云或私有云上同時有組件。「微信

McGee說他幾年前在IBM的團隊已經開始研究這個問題了，當時他遇到了谷歌的同行並發現他們正走在同一條道路上，但IBM主要關注流量路由、版本控制和A/B測試方面，Google專一於安全和遙測。二者決定合併各自的努力成果，這樣就誕生了Istio。網絡

Istio由如下組件組成：架構

Envoy，被描述爲sidecar代理，由於它做爲代理部署在每一個微服務實例旁邊。
Mixer，它是一個核心組件，用於經過Envoy代理執行策略，並從中收集遙測指標。
Pilot負責配置代理；
Citadel是負責頒發證書的中心化組件，也有本身的每一個節點代理。

Envoy是由Lyft開發的組件，被McGee描述爲「很是小的足跡，第4到第7層智能路由器」，它捕獲與其配對的微服務的全部傳入和傳出流量、控制流量、應用策略和收集遙測信息。 Pilot是IBM提供的主要組件，做爲部署在基礎架構中的全部Envoy代理的控制平面。

「若是你想象在一個服務網格中，你可能有一百個微服務，若是每一個服務都有多個實例，你可能有數百或數千個智能路由，你須要一種方法對它們進行編程，因此Istio引入了這個稱爲Pilot的東西。能夠把它想象成程序員，全部這些路由器的控制平面。因此你有一個地方能夠來編程這個服務網絡，而後圍繞數據收集進行遙測，圍繞安全的證書管理，但從根本上你有這個智能路由層和這個控制平面來管理它，「McGee解釋道。

Istio還有本身的API，容許用戶將其插入現有的後端系統，例如用於日誌記錄和遙測。

根據谷歌的說法，Istio的監控功能使用戶可以測量服務之間的實際流量，例如每秒請求數，錯誤率和延遲，還能夠生成依賴關係圖，以便用戶能夠看到服務如何相互影響。

經過Envoy sidecar代理，Istio還能夠在每一個服務調用時使用雙向TLS身份驗證（mTLS），加密並使用戶可以在基礎架構範圍內對每一個調用進行受權。

Istio的目的是，消除開發人員須要擔憂的許多問題：實例之間的通訊安全問題，控制哪一個實例能夠與哪些實例進行通訊以及提供執行諸如金絲雀部署之類的操做，若是是特定微服務代碼的新版本發佈了，那麼只有一個實例的子集會被更新，直到您滿意新代碼的運行可靠爲止

應該注意的是，其餘服務網狀平臺已經存在，例如開源端的Linkerd或Conduit，而微軟有一項服務，被稱爲Azure Service Fabric Mesh，目前做爲其雲平臺的技術預覽。此外，服務網格表示網絡管道上方的抽象層，所以假設已經爲每一個容器實例配置了網絡接口，IP地址和其餘網絡屬性。這一般意味着，不管什麼時候建立新的容器實例，部署微服務還將須要一個單獨的工具來自動化網絡配置。

然而，IBM但願Istio將成爲雲原生工具包的標準組成部分，正如Kubernetes所發生的那樣，Kubernetes是基於Borg和Omega技術的，而這些技術是爲谷歌本身的內部集羣和其上運行的容器層而開發的。

「從社區的角度來看，個人指望是Istio將成爲架構的默認部分，就像容器和Kubernetes已經成爲雲原生架構的默認部分同樣，」McGee說。爲此，IBM但願將Istio與其公有云提供的託管Kubernetes服務以及其內部部署的IBM Cloud Private堆棧集成在一塊兒。

「因此，你今天能夠運行Istio，咱們支持今天在這兩個平臺上運行Istio，但指望應該是在不久的未來，咱們將內置Istio，因此每當你使用咱們的平臺時， Istio組件集成在裏面了，您能夠利用它，而且沒必要負責部署和管理Istio自己，只需在您的應用程序中使用它便可，「McGee說。

谷歌已經添加了Istio支持，儘管它只是將其標記爲alpha版本，做爲託管服務的一部分，該服務在其雲平臺上的客戶的Google Kubernetes Engine（GKE）集羣中自動安裝和維護。

Istio也得到了業內其餘公司的支持，尤爲是Red Hat，幾年前Red Hat以Docker容器和Kubernetes爲基礎，從新設計了OpenShift應用程序平臺。

Red Hat的Istio產品經理人稱「紅鬍子」的Brian Harrington表示Red Hat打算將服務網格集成到OpenShift中，但Red Hat但願在提交以前可以看到改進的一些粗略的地方，例如多租戶支持。

「Istio如今的目標是他們所謂的軟多租戶，也就是說，咱們但願在組織內部可用，以便該組織內的兩個不一樣的團隊可使用並信任它，前提是團隊內只要沒有一我的的行爲過於惡意，你們都沒有準備去影響其餘人的服務。經過咱們運行OpenShift Online的方式，咱們讓客戶運行咱們從未看過的代碼，而且咱們必須最終安排這兩個客戶並存，這是一個很是不一樣的多租戶挑戰，「Harrington解釋道。

「咱們須要對這個多租戶功能有更高的信心;咱們須要對性能和穩定性有更高的信心。在這些方面尚未看到有完美的解決方案，可是在進行規模測試和自動化一些迴歸測試時，咱們看到了一些咱們認爲能夠提供大量價值的地方，咱們還在社區層面貢獻了一個名爲Kiali的項目，給出了Istio操做過程的可視化，這只是咱們產品的一部分，「他補充道。

換句話說， Istio只是爲那些但願構建雲原生應用程序基礎架構的用戶提供的添加到選項菜單中的另外一個開源工具。像Red Hat這樣的供應商將把它融入他們通過測試和支持的企業平臺產品中，好比OpenShift，而其餘供應商則但願本身混合搭配並構建它。