下週六，深圳，闊別已久的線下技術沙龍要和你見面啦！
現場有Rancher Labs研發經理demo剛剛發佈的Rancher 2.3中的Istio、Windows容器、集羣模板等功能及使用，還有k3s首次線下workshop，由Rancher Labs資深架構師帶你一起玩轉k3s！還有長城證券的運維負責人分享數字化浪潮下傳統金融IT的轉型。
訪問鏈接即可瞭解詳情及報名啦!
諸如容器、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的新功能，點擊此處，趕緊報名啦！
歡迎添加小助手（×××：×××)，進官方技術羣，瞭解更多Kubernetes使用攻略