istio是乙個完全開源的服務網格，作為透明的一層接入到現有的分布式應用程式裡。它也是乙個平台，擁有可以整合任何日誌、遙測和策略系統的 api 介面。istio 多樣化的特性使您能夠成功且高效地執行分布式微服務架構，並提供保護、連線和監控微服務的統一方法。
服務網格用來描述組成這些應用程式的微服務網路以及它們之間的互動。隨著服務網格的規模和複雜性不斷的增長，它將會變得越來越難以理解和管理。它的需求包括服務發現、負載均衡、故障恢復、度量和監控等。服務網格通常還有更複雜的運維需求，比如 a/b 測試、金絲雀發布、速率限制、訪問控制和端到端認證。
如果用一句話來解釋什麼是 service mesh，可以將它比作是應用程式或者說微服務間的 tcp/ip，負責服務之間的網路呼叫、限流、熔斷和監控。對於編寫應用程式來說一般無須關心 tcp/ip 這一層（比如通過 http 協議的 restful 應用），同樣使用 service mesh 也就無須關心服務之間的那些原本通過服務框架實現的事情，比如 spring cloud、netflix oss 和其他中介軟體，現在只要交給 service mesh 就可以了。
目前兩款流行的 service mesh 開源軟體 istio 和 linkerd 都可以直接在 kubernetes 中整合，其中 linkerd 已經成為 cncf 中的專案
通過負載均衡、服務間的身份驗證、監控等方法，istio 可以輕鬆地建立乙個已經部署了服務的網路，而服務的**只需很少更改甚至無需更改。通過在整個環境中部署乙個特殊的 sidecar **為服務新增 istio 的支援，而**會攔截微服務之間的所有網路通訊，然後使用其控制平面的功能來配置和管理 istio，這包括：
istio 為可擴充套件性而設計，可以滿足不同的部署需求。
istio 架構總體來說分為控制面和資料面兩部分。
控制面是 istio 的核心，管理 istio 的所有功能，主要包括pilot、mixer、citadel等服務元件;
資料面由伴隨每個應用程式部署的**程式envoy組成，執行針對應用程式的治理邏輯。常被稱為「sidecar」。sidecar 一般和業務容器繫結在一起（在kubernets中自動注入方式到業務pod中），來劫持業務應用容器的流量，並接受控制面元件的控制，同時會向控制面輸出日誌、跟蹤及監控資料。
pilot 是 istio 的主要控制項，下發指令控制客戶端。在整個系統中，pilot 完成以下任務：
• 從 kubernetes 或者其他平台的註冊中心獲取服務資訊，完成服務發現過程。
• 讀取 istio 的各項控制配置，在進行轉換之後，將其發給資料面進行實施。
pilot 將配置內容下發給資料面的 envoy，envoy 根據 pilot 指令，將路由、服務、監聽、集群等定義資訊轉換為本地配置，完成控制行為的落地。
顧名思義，mixer混合了各種策略以及後端資料採集或遙測系統的介面卡，從而實現了前端proxy與後端系統的隔離與匯合。mixer是乙個靈活的外掛程式模型（有沒有發現無論是k8s還是istio，實現上都很青睞於外掛程式模型，這是乙個很靈活的實現方式），它一端連著envoy，同時我們可以將日誌、監控、遙測等各種系統「插入」到mixer的另一端中，從而得到我們想要的資料或結果。
telemetry
telemetry是專門用於收集監測資料的mixer服務元件。istio控制面部署了兩個mixer元件：istio- telemetry和istio-policy，分別處理監測資料的收集和策略的執行，兩個元件的 pod 映象都是 mixer。
從呼叫時機上來說，pilot管理的是配置資料，在配置改變時和資料面互動即可，對於mixer來說，在服務間互動時envoy都會對mixer進行一次呼叫，因此這是一種實時管理。
當網格中的兩個服務間有呼叫發生時，服務的** envoy就會上報監測資料給 istio-telemetry 服務元件，istio-telemetry 則根據配置將生成訪問的 metric等資料分發給後端的監測服務，如prometheus等。
policy
policy是另外乙個mixer服務，和telemetry基本上是完全相同的機制和流程。資料面在**服務的請求前呼叫 istio-policy的check介面檢查是否允許訪問，把結果返回給envoy。可以對接如配額、授權、黑白名單等不同的控制後端，對服務間的訪問進行可擴充套件的控制。
citadel是 istio的核心安全元件，提供了自動生 成、分發、輪換與撤銷金鑰和證書功能。citadel一直監聽 kube- apiserver，以 secret的形式為每個服務都生成證書金鑰，並在pod建立時掛載到pod上，**容器使用這些檔案來做服務身份認證，進而代 理兩端服務實現雙向tls認證、通道加密、訪問授權等安全功能。如圖 所示，frontend 服 務對 forecast 服務的訪問用到了http方式，通過配置即可對服務增加認證功能，雙方的envoy會建立雙向認證的tls通道，從而在服務間啟用雙向認證的https。
sidecar-injector是負責自動注入的元件，只要開啟了自動注 入，在pod建立時就會自動呼叫istio-sidecar-injector向pod中注入sidecar 容器。
在 kubernetes環境下，根據自動注入配置，kube-apiserver在攔截到 pod建立的請求時，會呼叫自動注入服務 istio-sidecar-injector 生成 sidecar 容器的描述並將其插入原 pod的定義中，這樣，在建立的 pod 內除了包括業務容器，還包括 sidecar容器，這個注入過程對使用者透明
proxy的執行容器時istio-proxy，容器中除了有envoy，還有乙個pilot-agent的守護程序。
envoy是用c++開發的非常有影響力的輕量級高效能開源服務**。作為服務網格的資料面，envoy提供了動態服務發現、負載均 衡、tls、http/2 及 grpc**、熔斷器、健康檢查、流量拆分、灰度發布、故障注入等功能，本篇描述的大部分治理能力最終都落實到 envoy的實現上。
envoy之所以有能力攔截下所有的流量，是因為它被設計為部署在每乙個需要管理的pod裡，作為乙個獨立容器存在，支援通過配置iptables或cni網橋兩種方式來攔截流量（這裡也不展開說了，還不明白的同學可以翻看我之前發的k8s底層網路的說明，看看flannel的實現原理），請看上圖，business-manager容器的請求發出時，會經過本pod的enovy**，enovy完成規則校驗、資料採集、日誌等操作後，再**出去；值得注意的是，請求方enovy**出去的流量會傳送給接收方的enovy，之後才有可能到達真正的接收方data-product容器。當然這些操作是istio的活，我們要做的僅僅是通過配置的形式告訴istio我們要對哪些流量做什麼動作。
ingressgateway 就是入口處的 gateway，從網格外訪問網格內的服務就是通過這個gateway進行的。istio-ingressgateway是乙個loadbalancer型別的service，不同於其他服務元件只有一兩個端 口，istio-ingressgateway 開放了一組埠，這些就是網格內服務的外部訪問埠。如下圖所示，網格入口閘道器istio-ingressgateway的負載和網格內的sidecar是同樣的執行流程，也和網格內的其他 sidecar一樣從 pilot處接收流量規則並執行。
除了以「istio」為字首的istio自有元件，在集群中一般還安裝jaeger-agent、jaeger-collector、jaeger-query、kiali、prometheus、grafana、 tracing、zipkin等元件，這些元件提供了istio的呼叫鏈、監控等功能，可以選擇安裝來完成完整的服務監控管理功能。
參考**
服務網格 Istio和AWS App Mesh
在談論它之前，讓我們先看一下網格到底是什麼 服務網格是微服務體系結構的基礎結構層。它處理服務之間的通訊問題，使該通訊更加可見 或 可觀察 且易於管理。更具體地說，它可以處理諸如服務發現，路由和負載平衡，安全性 例如，加密，tls，身份驗證，授權 之類的事情，並提供錯誤處理 例如重試和斷路 上面提到的...
服務網格 Istio和AWS App Mesh
在談論它之前，讓我們先看一下網格到底是什麼 服務網格是微服務體系結構的基礎結構層。它處理服務之間的通訊問題，使該通訊更加可見 或 可觀察 且易於管理。更具體地說，它可以處理諸如服務發現，路由和負載平衡，安全性 例如，加密，tls，身份驗證，授權 之類的事情，並提供錯誤處理 例如重試和斷路 上面提到的...
從零搭建乙個基於Istio的服務網格
上篇文章從微服務1.0時代的三大痛點 技術門檻高，多語言支援不足和 侵入性強 說起，由此引出服務網格的起源和演化歷史。但古語有云紙上得來終覺淺，絕知此事要躬行，不親自擼一遍命令，怎敢跟人提服務網格？本篇我將教大家如何在本地從零搭建乙個基於istio的服務網格，從而對服務網格有乙個更直觀的認識。無論是...