入門瞭解Service Mesh + Istio？從本文開始

諸如容器、Kubernetes等雲原生架構和技術的成熟推進了服務網格架構的極速增加以及普遍採用。儘管雲原生環境能夠爲企業帶來一系列好處，可是其複雜性也對負責開發維護這類系統的人員，如軟件開發人員、網絡運維人員、基礎架構工程師以及CIO、CTO等帶來了重大挑戰。

服務網格框架可以爲跨不一樣雲原生環境的應用程序整合一致的服務和網絡管理能力，它還極大地加快了DevOps實踐的進程，正緣於此，服務網格近年來可謂是發展迅猛。雲原生普及的加快，要求擁有云原生應用程序的工程團隊必須熟悉服務網格功能，以判斷該技術未來是否能爲企業提供價值。

什麼是服務網格？

服務網格能夠鏈接、保護、控制以及監控在編排平臺上的服務。「服務網格」這一術語自己用於分佈式應用程序中服務之間的一組搭接網絡鏈接，也適用於管理該組鏈接服務的一系列工具。若是你有兩個經過網絡鏈接進行交互的微服務，那就意味着你有了一個服務網格。下圖是一個十分簡單的示例，一個網格和兩個服務：

更有可能的是，因爲在環境中微服務的數量會繼續增加，你的服務網格會以下圖所示：

隨着雲環境擴展到混合雲和多雲部署，開發人員將會使用微服務來加速開發而且確保在多個容器和分佈式雲資源中的的可移植性。隨着微服務生態系統的複雜性增加，咱們須要高效且智能地管理它，而且深刻了解微服務如何交互以及保護微服務之間的通訊。

什麼是Istio？

若是你已經據說了服務網格，那麼你必定順帶據說了Istio。Istio是一個開源的服務網格，它能夠部署在已有的雲原生應用程序上。它還具備相似於平臺的功能——能夠將集成到日誌平臺、遙測或策略系統中。策略集成使得Istio在建立一個統一的方法來保護、鏈接以及監控既定環境中的微服務中扮演一個安全工具的角色。當泛指「Istio服務網格」時，一般是指Istio中的一系列工具，而特指「某個Istio 服務網格」時則代表由Istio安裝管理的指定應用程序集羣。Istio的許多CRD容許對應用程序網絡層的行爲進行編程配置（經過使用Kubernetes API），其中應用程序是相互依賴的微服務集。Istio在某種程度上能夠稱爲當今雲原生堆棧中服務網格的同義詞，由於它的功能最豐富、最標準化。

我是否須要一個服務網格？

儘管服務網格的採用率可能會持續快速增加，特別是當功能設置和相似Istio的管理工具進一步完善以後，但並非每一個雲原生環境都須要服務網格。因此你如何知道一個服務是否適合你的企業或者環境呢？若是你須要解決下面所描述的一個或多個需求或問題的方案，那麼你應該考慮部署一個服務網格：

• 你在基於分佈式微服務的應用程序中遇到性能問題
• 你須要爲全部微服務收集並交付一致的請求和鏈接指標
• 你想直接默認在線加密設置，而無需直接管理TLS證書
• 你須要比Kubernetes網絡策略提供的更細粒度的解決方案進行服務到服務的控制
• 你想使用金絲雀發佈和應用程序API多版本支持進行自動release
• 你想無需修改應用程序就能夠添加用戶的身份驗證和受權認證信息

另外一方面，若是在你的堆棧中不須要服務網格，那麼你須要作一些權衡。考慮到這些環境的複雜性，部署一個服務網格（包括Istio）須要大量的遷移工做和運維成本。若是你的微服務部署數量不會增加，或者若是有其餘解決方案能夠知足你內部的HTTP請求路由的需求，或者若是你已經有了一個可管理且高效的解決方案能夠解決上述的關鍵需求，那麼此刻服務網格對你來講真的不是一個最佳選擇。

可是若是服務網格繼續極速被普遍採用，爲支持它而開發的功能生態系統將會繼續擴展。這種增加將提高可管理性和功能性，以便未來DevOps團隊能夠更加輕鬆地訪問更強大的服務網格工具，而沒必要擔憂將新的基礎架構層部署到雲原生堆棧中而出現棘手的問題或花費很高的成本。

Istio工做原理

Istio組件被分爲兩部分——控制平面和數據平面。控制平面是指管理配置和監控數據平面的服務。數據平面由做爲sidecar由在應用程序pod中的智能代理（proxy）組成，這是Kubernetes對象模型中最小的可部署對象。這些Istio proxy有助於控制和監控微服務間的網絡鏈接。從控制平面接收路由和策略規則，而後數據平面報告回鏈接處理遙測。

經過建立Kubernetes資源來配置Istio服務網格。此外，有許多Kubernetes CRD能夠映射到Istio各類功能上。接下來，咱們會討論更多關於控制和數據平面的做用，但在此以前咱們先了解關於Istio的潛在能力，以及它的不足。

潛力與不足

Istio經過其可動態配置代理的網格提供了一系列用於處理和控制網絡鏈接的特性。但這些功能配置繁重而且擁有陡峭的學習曲線。而且有時把已有的應用程序遷移到Istio架構時依舊會出現一些常見的問題，儘管這些架構已是Kubernetes原生的微服務。

此外，Istio缺少對如何將用戶提供的配置轉換爲Envoy路由的瞭解。Envoy是做爲服務網格中服務的入站和出站流量的中介開發的一種高性能的代理，是由來自共享出行服務公司Lyft的開發人員建立的，能夠用於從單體架構轉變爲服務網格架構。其餘在使用中的問題還包括部署和服務資源配置要求所需的學習曲線、在打開mTLS時中斷Kubernetes readiness和liveness探針以及使用沒有ClusterIP的Kubernetes服務或繞開Kubernetes服務發現流程的服務。

Istio的優點在於可讓你在不修改微服務源代碼的狀況之下，很輕鬆地給微服務加上諸如負載均衡、身份驗證、監控等等的功能。並且目前它正在快速發展迭代，頻繁發佈新版本，而且積極徵求用戶反饋。儘管目前Envoy還有不少侷限，可是隨着Istio持續發展，它也會積極開發和完善本身的功能。

配置控制平面

在Kubernetes集羣中，一個典型的Istio部署應該包含如下服務：

Pilot，在Istio網絡自定義資源中集合流量管理規範配置，並將該配置交付到istio-proxy sidecar。

Mixer，用於處理由proxy sidecar生成的請求指標的遙測，並將其發送到已配置完成的後端，並執行受權策略。若是開啓了策略檢查（Istio 1.1中默認關閉），proxy sidecar將會鏈接到Mixer以確認鏈接是被容許的。可是，這個方法會稍微增長網絡延遲。

Citadel，這個是Istio的公鑰基礎設施（PKI）服務，它能夠生成、輪換和吊銷用於身份驗證的客戶端TLS證書。

Galley，它是大多數Istio CRD的Kubernetes controller，使用戶能夠更改自定義資源並將內容分配到其餘Istio服務中。

數據平面

數據平面由Envoy服務代理提供支持，該代理使用Istio擴展構建。Proxy會攔截到pod服務端口的傳入流量，並默認攔截來自pod其餘容器的全部創出TCP流量。在大部分狀況下，無需更改應用程序代碼，僅對應用程序的Kubernetes部署和服務資源規範進行較小的更改，proxy sidecar 就能夠在pod中運行。Proxy sidecar的配置由在Istio 控制面板中的服務進行動態管理。

最終，也許會在某個時間點你須要部署服務網格以確保你的雲原生環境徹底正常運行並獲得充分保護。所以，熟悉有關服務網格的基礎只是將能夠幫助你作出準確的判斷——何時應該部署服務網格以及應該如何部署。若是你正在計劃在Kubernetes和其餘容器平臺上進行擴展計劃，那麼你經過了解Istio的設計和功能以及它如何下降容器化微服務和雲原生環境的固有複雜性，你能夠知道Istio是一個功能強大且快速改進的解決方案而且正在積極加強彈性伸縮能力、安全性以及管理的簡易性。

若是企業繼續採用雲原生和分佈式架構，那麼Istio的服務網格功能以及底層基礎架構的網絡控制和Kubernetes的安全實踐將會極大程度解放DevOps團隊在彈性伸縮和管理應用程序基礎架構上的壓力。

在10月9日GA的Rancher 2.3版本中，正式集成了Istio，極大簡化了Istio的安裝和配置。你只須要在UI中使用工具菜單，便可啓動Istio。Rancher中現已內置支持：

• 用於流量和遙測可視化的Kiali儀表板
• 用於追蹤的Jaeger
• 用於監控和可觀察性的Prometheus和Grafana

若是你還想了解更多關於Rancher 2.3的新功能，歡迎參加咱們在下週六（10月26日）舉辦的技術沙龍，座標深圳。屆時將有Rancher Labs大中華區的研發經理現場介紹並demo Rancher 2.3的新功能，點擊此處，趕忙報名啦！

歡迎添加小助手（wx：rancher2)，進官方技術羣，瞭解更多Kubernetes使用攻略