幾張圖解釋明白大家都在說的 Istio

關(guān)于 Kubernetes Service 理解的系列文章，本篇是第3篇：

• Part 1:?Kubernetes Services
• Part 2:?Kubernetes Ingress
• Part 3: (本文)
• Part 4:?Kubernetes Serverless

Istio 是一個(gè)服務(wù)網(wǎng)格，它允許集群中的 pods 和服務(wù)之間進(jìn)行更詳細(xì)、復(fù)雜和可觀察的通信。

它通過使用 CRD 擴(kuò)展 Kubernetes API 來進(jìn)行管理，它將代理容器注入到所有 pods 中，然后由這些 pods 來控制集群中的流量。

Kubernetes Services

前面我們已經(jīng)了解了 Kubernetes Services，我們可以再簡短地說明下如何實(shí)現(xiàn) Kubernetes Services，這這有助于理解 Istio 如何工作的。

上圖的 Kubernetes 集群中一共有兩個(gè)節(jié)點(diǎn)和 4 個(gè) pod，每個(gè) pod 都有一個(gè)容器。服務(wù)?service-nginx?指向 nginx pods，服務(wù)?service-python?指向 python pods。紅線顯示了從?pod1-nginx?中的 nginx 容器向?service-python?服務(wù)發(fā)出的請求，該服務(wù)將請求重定向到?pod2-python。

默認(rèn)情況下，ClusterIP 服務(wù)進(jìn)行簡單的隨機(jī)或輪詢轉(zhuǎn)發(fā)請求，Kubernetes 中的 Services 并不存在于特定的節(jié)點(diǎn)上，而是存在于整個(gè)集群中。我們可以在下圖 中看到更多細(xì)節(jié):

上圖要更詳細(xì)點(diǎn)，Kubernetes 中的服務(wù)是由運(yùn)行在每個(gè)節(jié)點(diǎn)上的?kube-proxy?組件實(shí)現(xiàn)的，該組件創(chuàng)建 iptables 規(guī)則，并將請求重定向到 Pod。因此，服務(wù)就是 iptables 規(guī)則。(還有其他不使用 iptables 的代理模式，但過程是相同的。)

Kubernetes Istio

現(xiàn)在我們來看一個(gè)配置了 Istio 的相同示例:

上圖中可以看到集群中安裝了 Istio，每個(gè) pod 都有第二個(gè)稱為?istio-proxy?的 sidecar 容器，該容器在創(chuàng)建期間會自動將其注入到 pods 中。

Istio 最常見的代理是?Envoy，當(dāng)然也可以使用其他代理（如 Nginx），所以我們將代理稱為istio-proxy。

我們可以看到不再顯示?kube-proxy?組件，這樣做是為了保持圖像的整潔，這些組件仍然存在，但是擁有?istio-proxy?的 pods 將不再使用?kube-proxy?組件了。

每當(dāng)配置或服務(wù)發(fā)生變化時(shí)，Istio 控制平面就會對所有?istio-proxy?sidecars 進(jìn)行處理，類似于圖 2 中 Kubernetes API 處理所有?kube-proxy?組件的方式。Istio 控制平面使用現(xiàn)有的 Kubernetes 服務(wù)來接收每個(gè)服務(wù)點(diǎn)所指向的所有 pods ，通過使用 pod IP 地址，Istio 實(shí)現(xiàn)了自己的路由。

在 Istio 控制平面對所有?istio-proxy?sidecars 處理之后，它看起來是這樣的:

在圖 4 中，我們看到 Istio 控制平面如何將當(dāng)前配置應(yīng)用到集群中的所有?istio-proxy?容器，Istio 將把 Kubernetes 服務(wù)聲明轉(zhuǎn)換成它自己的路由聲明。

讓我們看看如何使用 Istio 發(fā)出請求:

在上圖中，所有的?istio-proxy?容器已經(jīng)被 Istio 控制平面所管控，并包含所有必要的路由信息，如圖 3/4 所示，來自?pod1-nginx?的 nginx 容器向?service-python?發(fā)出請求。

請求被?pod1-nginx?的?istio-proxy?容器攔截，并被重定向到一個(gè) python pod 的?istio-proxy?容器，該容器隨后將請求重定向到 python 容器。

發(fā)生了什么？

圖 1-5 顯示了使用 nginx 和 python pod 的 Kubernetes 應(yīng)用程序的相同示例，我們已經(jīng)看到了使用默認(rèn)的 Kubernetes 服務(wù)和使用 Istio 是如何發(fā)生請求的。

重要的是：無論使用什么方法，結(jié)果都是相同的，并且不需要更改應(yīng)用程序本身，只需要更改基礎(chǔ)結(jié)構(gòu)代碼。

為什么要使用 Istio?

如果在使用 Istio 的時(shí)候沒有什么變化（nginx pod 仍然可以像以前一樣連接到 python pod），那么我們?yōu)槭裁催€要使用 Istio 呢？

其驚人的優(yōu)勢是，現(xiàn)在所有流量都通過每個(gè) Pod 中的?istio-proxy?容器進(jìn)行路由，每當(dāng)?istio-proxy?接收并重定向一個(gè)請求時(shí)，它還會將有關(guān)該請求的信息提交給 Istio 控制平面。因此 Istio 控制平面可以準(zhǔn)確地知道該請求來自哪個(gè) pod、存在哪些 HTTP 頭、從一個(gè)istio-proxy?到另一個(gè)?istio-proxy?的請求需要多長時(shí)間等等。在具有彼此通信的服務(wù)的集群中，這可以提高可觀察性并更好地控制所有流量。

先進(jìn)的路由，Kubernetes 內(nèi)部 Services 只能對 pods 執(zhí)行輪詢或隨機(jī)分發(fā)請求，使用 Istio 可以實(shí)現(xiàn)更復(fù)雜的方式。比如，如果發(fā)生錯(cuò)誤，根據(jù)請求頭進(jìn)行重定向，或者重定向到最少使用的服務(wù)。

部署，它允許將一定比例的流量路由到特定的服務(wù)版本，因此允許綠色/藍(lán)色和金絲雀部署。

加密，可以對 pods 之間從?istio-proxy?到?istio-proxy?的集群內(nèi)部通信進(jìn)行加密。

監(jiān)控/圖形，Istio 可以連接到 Prometheus 等監(jiān)控工具，也可以與 Kiali 一起展示所有的服務(wù)和他們的流量。

追蹤，因?yàn)?Istio 控制平面擁有大量關(guān)于請求的數(shù)據(jù)，所以可以使用 Jaeger 等工具跟蹤和檢查這些數(shù)據(jù)。

Sidecar 注入，為了使 Istio 工作，每一個(gè)作為網(wǎng)狀結(jié)構(gòu)一部分的 pod 都需要注入一個(gè)?istio-proxysidecar，這可以在 pod 創(chuàng)建期間為整個(gè)命名空間自動完成（也可以手動完成）。

Istio 會取代 Kubernetes 的服務(wù)嗎？

當(dāng)然不會，當(dāng)我開始使用 Istio 時(shí)，我問自己的一個(gè)問題是它是否會取代現(xiàn)有的 Kubernetes 服務(wù)，答案是否定的，因?yàn)?Istio 會使用現(xiàn)有的 Kubernetes 服務(wù)獲取它們的所有 endpoints/pod IP 地址。

Istio 取代了 Kubernetes 的 Ingress 嗎？

是的，Istio 提供了新的 CRD 資源，比如 Gateway 和 VirtualService，甚至還附帶了 ingress 轉(zhuǎn)換器 istioctl convert-ingress，下圖顯示了 Istio 網(wǎng)關(guān)如何處理進(jìn)入流量，網(wǎng)關(guān)本身也是一個(gè)?istio-proxy?組件。

總結(jié)

Istio 無疑在 Kubernetes 之上又增加了另一層次的復(fù)雜性，但是對于現(xiàn)代微服務(wù)架構(gòu)來說，它實(shí)際上提供了一種比必須在應(yīng)用程序代碼本身中實(shí)現(xiàn)跟蹤或可觀察性更簡單的方法。

關(guān)于 Istio 更多的使用說明，可以查看官方文檔 https://istio.io 了解更多。

“

原文鏈接：https://itnext.io/kubernetes-istio-simply-visually-explained-58a7d158b83f

”