說說咱們爲何須要lstio

本文來自lstio的中文社區：
https://istio.cn/t/topic/18

我最近沒有多少時間去玩k8s，並認可Istio到底給k8s帶來了什麼方面有點迷失了。這是否會增長更多的運營開銷？它是否簡化了咱們一般須要作的事情？這些問題都浮如今個人腦海裏。

（我懷疑在發佈了這些內容以後，個人團隊中比我更懂k8s的人可能會想找我談談……雖然我講會跟團隊中的成員辯論，但那將是我最喜歡的對話）

那麼Istio到底是什麼？

Istio網站 4上說：

Istio帶給你：

HTTP、gRPC、WebSocket和TCP流量的自動負載均衡。
經過豐富的路由規則、重試、故障轉移和故障注入對流量行爲進行細粒度控制。
支持訪問控制、速率限制和配額的可拔插策略層和配置API。
自動指標、日誌和集羣內全部流量的跟蹤，包括集羣入口和出口。
經過集羣中的服務之間的強身份斷言來實現服務間的身份驗證。
經過在整個環境中部署一個特殊的sidecar代理（輔助容器），您能夠將Istio支持添加到服務中（這給我留下了深入的印象，若是您想作到這一點，請參閱後面的內容）。安裝了sidecar代理以後，（微）服務之間的全部網絡通訊都經過這個代理。此外，全部的網絡通訊都是使用Istio的控制平面功能進行配置和管理的。

Istio是 Service Mesh（服務網格） 。我認爲的service mesh定義就是「它是一個專用的基礎設施層，使得服務間的通訊安全、高效和可靠」

然而，若是像我同樣，你從概念文檔 11開始看的話，上面有這樣的內容：「術語 service mesh 一般用於描述組成這些應用程序的微服務網絡以及它們之間的交互。隨着服務網格的大小和複雜程度不斷增長，可能會變得難以理解和管理。可能出現包括服務發現、負載平衡、故障恢復、度量和監控，以及更復雜的需求，如A/B測試、金絲雀發佈、速率限制、訪問控制和端到端身份驗證。Istio提供了一個完整的解決方案，經過對整個服務網格提供行爲分析和操做控制來知足微服務應用程序的各類需求。「

讀完以後你可能會像我同樣困惑！最後在網上查了一圈關於什麼是服務網格以後，我終於搞明白了。我最後使用的多是一個在全部搜索到的樣本里一個非表明性的共識，但這是一個合理的選擇。不過有個細節確實了，就是如何將它與k8s等編排工具分開。Istio須要跟k8s一塊兒使用，沒有k8s或其餘容器編排工具的它就不存在了嗎？它沒有作編排，實際上它的是爲解決管理基於微服務的解決方案中網絡和操做複雜性而設計的。它涵蓋的範圍就像k8s同樣！如今我真的須要繼續這個帖子了。。。

因此我知道Istio是什麼，給咱們帶來了什麼，但它實際上解決了什麼挑戰呢？

從爲何使用Istio頁面 11中能夠看出，它在服務網絡中統一提供了許多關鍵功能：

流量管理
可觀察性
強制策略
服務身份標識和安全
對於我來講，要真正理解Istio的價值，因此我使用了codelab 43。編寫code lab的人真是太棒了！

Code lab向我介紹了Istio控制平面的四個主要組件：

Pilot ：處理代理sidecar的配置和編程。
Mixer ：爲您的流量處理決策並收集遙測數據。
Ingress ：處理來自羣集外部的傳入請求。
CA ：證書頒發機構。
查看Istio架構概念 11頁面瞭解這些組件如何協同工做的。

Code lab提供了路由規則 4——流量管理部分

我還嘗試了Istio.io中的一些task，由於我須要瞭解它如何處理那些領域的工做。

提示：若是您在完成codelab時也決定在四處看看，那麼請將您的羣集與應用程序一塊兒啓動並運行。不管如何，你會再次使用它。

因此我對它如何解決這些問題有了一個基本的瞭解，可是若是我使用像GKE這樣的託管K8s（好吧，你知道我會選那個不是嗎？）使用Istio是否合適？

注意 ：是的，這裏有更多的細節，但我主要想弄明白爲何須要使用Istio。

集羣最終用戶/開發人員訪問

GKE結合使用IAM和RBAC 1，是的，這裏面有不少東西須要你瞭解。

要爲您的集羣用戶授予比Cloud IAM更細粒度的權限，您可使用namespace和RBAC來限制對特定pod的訪問或排除對secret的訪問。

Istio RBAC介紹了兩個側重於服務的角色

ServiceRole 定義用於訪問網格中的服務的角色。
ServiceRoleBinding 將角色授予主題（例如用戶、組、服務）。
它們是k8s中的CustomResourceDefinition（CRD）對象。但您仍然須要瞭解IAM。

服務身份標識

GKE可使用service account來管理GKE上運行的應用程序可使用哪些GCP服務。這些service accout的密鑰使用secret存儲。Pod中運行的進程的身份標識是由k8s service account 2與RBAC一塊兒決定的。Istio使用istio-auth，它使用雙向TLS提供強大的服務間和最終用戶身份驗證，內置身份和憑證管理。Istio-auth使用Kubernetes service account。

Itsio不提供任何使用GCP service account幫助。這還很早，可是它正在制定將來發展計劃的路線圖。

Istio-auth很好，計劃中的加強功能將值得等待。我對安全的複雜性感到厭煩，由於這不可避免地致使配置錯誤，因此我但願它與service account類型之間進行更加無縫的對齊！

網絡控制

GKE（用於k8s版本1.7.6 +）使用k8s網絡策略 1來管理哪些Pod能夠和服務通訊。這是相對簡單的配置。 Istio也有網絡策略，但他們不是你知道和喜歡的K8s策略，爲何會有這樣的區別呢？ 這篇文章 1很好地解釋了這一點，因此我不會在這裏重述，可是這個表格總結了不一樣之處以及爲何會有這樣的不一樣。

項目 Istio策略 網絡策略
層 Service（7層） Network（三、4層）
實現 Userspace Kernel
控制點 Pod Node
Istio使用envoy做爲sidecar代理。Envoy在OSI模型的應用層運行，因此在第7層。個人這篇博客將爲你詳細解釋。

您須要兩種策略類型，這是縱深防護的方法。

多個集羣

Istio有個很是酷的功能是mixer適配器。簡而言之，它能夠從底層後端進行抽象以提供核心功能，例如日誌記錄、監控、配額、ACL檢查等。它公開了一個一致的API，與使用的後端無關。就像GCS公開了一個API，不管您使用什麼存儲類別！

我認爲mixer適配器模型 1博客文章中的這張圖片解釋了mixer適配器中的所有要點。
mixer適配器模型

有一個早期demo 4，我認爲它是istio最有用的特性之一，它實際上使用虛擬機來承載codelab中使用的評分dbase MySQL數據庫，並將其做爲GKE集羣所屬網格的一部分。使用一個網格來管理它們！

流量管理

若是你使用了codelab，你會看到使用istio來引導使用路由規則的流量是多麼容易。使用K8s，您還可使用金絲雀部署進行流量管理，並以相似於istio的方式將必定比例的流量引導至您的應用的一個版本，但Istio在這種狀況下更靈活，方法是容許您設置細粒度流量百分比並控制流量使用code lab中的其餘標準。

服務發現

服務註冊在k8s中完成。Istio抽象出底層的服務發現機制，並將其轉換爲envoy sidecar可消費的標準格式。

審計記錄和監控

若是是超出GKE提供的標準日誌記錄的話，能夠將GKE與StackDriver日誌記錄集成來收集，在持久化存儲中存儲 容器日誌 、 系統日誌 和關於羣集中的活動的 事件 ，例如Pod的調度。還能夠與StackDriver Monitoring集成以收集系統度量指標（度量羣集的基礎設施，例如CPU或內存使用狀況）和自定義指標（特定於應用程序的指標）。

Istio利用prometheus與grafana一塊兒做爲儀表板進行記錄和監控。我喜歡service graph配置 1，它能夠爲您提供service mesh的圖形表示。你也能夠用kibana和fluentd來配合Elasticsearch使用。

那麼我須要Istio嗎？

Istio的流量管理很是棒，mixer適配器模型能夠輕鬆管理覆蓋多個羣集和虛擬機的網格。我喜歡Istio是由於它可讓你進中精力思考服務，而不是那麼多的pod和節點，並非說你沒必要擔憂這些，而是隻關注服務就行了！

若是你須要管理一個分佈式集羣，那麼Istio應該在你的選擇列表裏。若是您須要在流量管理方面有比k8s提供的更多的靈活性的化那麼Istio也很值得關注。

若是你有足夠的資源來處理處於發展早期的事物，那麼儘早理解Istio是值得的。若是你已經在使用k8s的話那麼istio的學習曲線將很低。

記住它是一個創建在上層的東西，因此你仍然須要在k8s層作些事情，好比配置k8s網絡策略來補充istio網絡策略。

Istio還處於發展的早期階段，因此它不會作你指望的全部事情，但咱們但願它會。你將沒法避免的在提供商API和Istio之間來回調用才能完成一個完整的工做，因此它不是你但願的那種一站式解決方案。

Dashboard是可視化網格配置的一種很好的方式，由於編寫YAML會讓人很快疲憊！是的，您能夠設置儀表板上的控制面板來可視化度量指標，但我但願看到它與StackDriver集成。

所以，在整體瞭解Istio以後，我實際上很喜歡它所承諾的內容。