那麼，每個人都在談論的這個Istio是什麼？
TL; DR /什麼是Istio？
Istio是一個服務網格，可以在群集中的Pod和服務之間進行更詳細，複雜和可觀察的通信。
它通過使用CRD擴展Kubernetes API來進行管理。 它將代理容器注入所有容器，然後控制群集中的流量。
Kubernetes服務
從這裡開始，您應該已經瞭解Kubernetes服務，您可以閱讀本系列的第1部分。 現在，我們將很快探討如何實施Kubernetes服務。 我認為這有助於瞭解Istio如何做相同和不同的事情。
> Image 1: Kubernetes native service request
圖1顯示了一個Kubernetes集群，該集群具有兩個節點和4個Pod，每個Pod具有一個容器。 服務service-nginx指向nginx容器，服務service-python指向python容器。 紅線顯示了從pod1-nginx中的nginx容器向service-python服務發出的請求，該服務將請求重定向到pod2-python。
默認情況下，ClusterIP服務進行簡單的隨機或循環分發。 Kubernetes中的服務不存在於特定的節點上，而僅存在於整個集群中。 我們在圖2中更詳細地看到了這一點：
> Image 2: Kubernetes native service request with kube-proxy
圖2顯示了與圖1相同的示例，只是更加詳細。 Kubernetes中的服務由在每個節點上運行的kube-proxy組件實現。 該組件創建iptables規則，將請求重定向到Pod。 因此，服務就是iptables規則。 （還有其他一些不使用iptables的代理模式，但是過程相同。）
在圖2中，我們看到Kubernetes API對每個kube-proxy進行編程。 每當服務配置或服務吊艙發生更改時，就會發生這種情況。 這樣，Kubernetes API（以及整個主節點或控制平面）可能會崩潰，但服務仍然可以工作。
Kubernetes Istio
現在，我們來看配置了Istio的相同示例：
> Image 3: Istio Control Plane programs istio-proxy
圖3顯示了Istio控制平面附帶的已安裝的Istio。 還普遍看到的是，每個吊艙都有一個名為istio-proxy的第二個容器，該容器會在創建過程中自動注入到吊艙中。
Istio最流行的代理是Envoy，它具有驚人的功能。 儘管可以使用其他代理（例如Nginx），這就是為什麼從現在開始我們僅將代理稱為istio-proxy。
我們可以看到不再顯示kube-proxy組件，這樣做是為了保持圖像清潔。 這些仍然存在，但是具有istio-proxy的Pod將不再使用kube-proxy組件。
每當配置發生更改或服務的Pod發生時，Istio Control Plane都會對所有istio-proxy邊車進行編程。 類似於Kubernetes API編程圖像2中所有kube-proxy組件的方式。Istio控制平面使用現有的Kubernetes服務只是為了接收每個服務指向的所有pod。 通過使用Pod IP地址，Istio實現了自己的路由。
在Istio Control Plane對所有istio-proxy邊車進行編程之後，它看起來可能像這樣：
> Image 4: Istio Control Plane programmed all istio-proxys
在圖4中，我們看到Istio Control Plane如何將當前配置應用於群集中的所有istio-proxy容器。 為簡單起見，這些還包括" ClusterIP"聲明。 雖然ClusterIP是Kubernetes內部服務類型。 Istio將把Kubernetes服務聲明轉換成它自己的路由聲明。 但這有助於想象圖像中顯示的情況。
讓我們看看如何使用Istio發出請求：
> Image 5: Request made with Istio
在圖5中，所有istio-proxy容器均已由Istio控制平面進行了編程，幷包含所有必需的路由信息，如在圖3/4中所示。 pod1-nginx的Nginx容器向服務service-python發出請求。
該請求被pod1-nginx的istio-proxy容器攔截，然後重定向到一個python pod的istio-proxy容器，然後將其重定向到python容器。
這裡發生了什麼？
圖像1-5顯示了具有nginx和python pod的相同示例Kubernetes應用程序。 我們已經看到了使用默認的Kubernetes服務然後使用Istio如何發生請求。
重要的是：無論使用哪種方法，結果都是相同的，不需要更改應用程序本身，而只需更改基礎結構代碼。
為什麼要所有這些，為什麼要使用Istio？
如果在使用Istio時沒有任何改變（nginx pod仍然可以像以前一樣連接到python pod），那麼為什麼首先使用Istio？
驚人的優勢在於，現在所有流量都通過每個Pod中的istio-proxy容器進行路由。 每當istio-proxy接收並重定向請求時，它還會將有關該請求的信息提交給Istio控制平面。
因此，Istio控制平面確切地知道該請求來自哪個pod，存在哪些HTTP標頭，從一個istio-proxy到另一個istio-proxy的請求花了多長時間等等。 在具有許多彼此通信的服務的群集中，這可以提高可觀察性並更好地控制所有流量。
高級路由
Kubernetes內部服務只能對Pod進行輪詢或隨機分配服務請求。 使用Istio，可以使用更復雜的方法。 就像根據請求標頭進行重定向一樣，如果發生錯誤或到最少使用的服務。
部署
它允許將一定百分比的流量路由到某些服務版本，因此允許進行Green / Blue和Canary部署。
加密
可以對從istio-proxy到istio-proxy的Pod之間的群集內部流量進行加密。
監控/圖形生成
Istio連接到Prometheus等監視工具。 它也可以與Kiali一起很好地顯示所有服務及其流量。
> https://istio.io/docs/tasks/observability/kiali
追蹤
由於Istio控制平面包含有關請求的數據負載，因此可以使用Jaeger進行跟蹤和檢查。
> https://istio.io/docs/tasks/observability/distributed-tracing/jaeger
多簇網格
Istio有一個內部服務註冊表，可以使用現有的Kubernetes服務。 儘管也可以從群集外部添加資源，甚至可以將不同的群集連接到一個網格中。
> https://istio.io/docs/ops/deployment/deployment-models/#multiple-clusters
邊車注入
為了使Istio正常工作，應將其作為網格的一部分的每個吊艙都需要注入istio-proxy邊車。 可以在pod創建過程中針對整個名稱空間自動完成此操作（通過Admission Controller掛鉤），也可以手動完成。
Istio是否取代Kubernetes服務？
否。當我開始使用Istio時，我問自己一個問題，即它是否可以取代現有的Kubernetes服務。 答案是不。 Istio使用現有的Kubernetes服務獲取其所有端點/吊艙IP地址。
Istio是否會取代Kubernetes Ingress？
（也許讀入本系列第2部分的Ingress）
是。 Istio提供了新資源，例如Gateway和VirtualService，甚至還帶有入口轉換器istioctl convert-ingress。 一個很好的來源是https://istio.io/docs/concepts/traffic-management
圖6顯示了Istio網關如何處理入口流量。 網關本身也是一個組織代理組件。
> Image 6: Istio Gateway
控制平面組件
Istio控制平面由一些較小的組件組成，如Pilot，Mixer，Citadel和Galley。 如果您想更深入地學習，建議前往https://istio.io/docs/ops/deployment/architecture
如果Istio控制平面關閉，會發生什麼？
由於所有istio-proxy邊車均已編程，因此Istio控制平面可能會下降，交通如常。 但是不會應用配置更新或創建的新Pod。
儘管對於高級路由，例如將流量發送到使用最少的Pod或策略（https://istio.io/docs/tasks/policy-enforcement），所有Istio代理之間都需要通過Istio控制平面進行通信。 然後，每個istio-proxy都必須在允許請求之前先檢查回到Istio控制平面。
為了使這些配置正常工作，我認為控制平面必須始終可用。 如果您有與此相關的鏈接，請隨時添加評論。
接下來您能做什麼？
我寫了一個示例文章和有關Istio Canray部署的Github回購。
Istio提供了一個很好的示例應用程序，其中包含一些微服務。 如果您想深入瞭解Istio，這是一個不錯的開始：https://istio.io/docs/setup/getting-started
如果您想更深入地學習，該視頻也很棒。
概括
這是一個簡單的介紹和廣泛的概述，希望對人們有所幫助。 Istio無疑在Kubernetes之上增加了另一層次的複雜性。 儘管對於現代微服務架構，它實際上提供了比必須在應用程序代碼本身中實現跟蹤或可觀察性更簡單的方法。
(本文翻譯自Kim Wuestkamp的文章《Kubernetes Istio simply visually explained》，參考：https://itnext.io/kubernetes-istio-simply-visually-explained-58a7d158b83f)
