諸如容器、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使用攻略