如果您聽說過Service Mesh并嘗試過Istio，您可能會有以下問題：

為什么 Istio 運(yùn)行在 Kubernetes 上？

Kubernetes 和服務(wù)網(wǎng)格在云原生應(yīng)用架構(gòu)中分別扮演什么角色？

Istio 在哪些方面對Kubernetes進(jìn)行了擴(kuò)展？它解決了什么問題？

Kubernetes、Envoy 和 Istio 之間是什么關(guān)系？

本文將帶您了解 Kubernetes 和 Istio 的內(nèi)部工作原理。另外，我還會介紹 Kubernetes 中的負(fù)載均衡方法，并解釋為什么有了 Kubernetes 還需要 Istio。

Kubernetes 本質(zhì)上是通過聲明性配置進(jìn)行應(yīng)用程序生命周期管理，而服務(wù)網(wǎng)格本質(zhì)上是提供應(yīng)用程序間流量、安全管理和可觀察性。如果你已經(jīng)使用 Kubernetes 搭建了一個(gè)穩(wěn)定的應(yīng)用平臺，那么如何為服務(wù)之間的調(diào)用設(shè)置負(fù)載均衡和流量控制呢？這就是服務(wù)網(wǎng)格發(fā)揮作用的地方。

Envoy 引入了xDS 協(xié)議，該協(xié)議受到各種開源軟件的支持，例如Istio、MOSN等。Envoy 將 xDS 貢獻(xiàn)給服務(wù)網(wǎng)格或云原生基礎(chǔ)設(shè)施。Envoy 本質(zhì)上是一個(gè)現(xiàn)代版本的代理，可以通過 API 進(jìn)行配置，并基于它衍生出許多不同的使用場景——例如 API 網(wǎng)關(guān)、服務(wù)網(wǎng)格中的 sidecar 代理和邊緣代理。

本文包含以下內(nèi)容：

kube-proxy 作用的描述。

Kubernetes 對于微服務(wù)管理的局限性。

介紹 Istio 服務(wù)網(wǎng)格的功能。

Kubernetes、Envoy 和 Istio 服務(wù)網(wǎng)格中一些概念的比較。

Kubernetes 與服務(wù)網(wǎng)格

下圖展示了 Kubernetes 和 Service Mesh（每個(gè) pod 一個(gè) sidecar 模型）中的服務(wù)訪問關(guān)系。

流量轉(zhuǎn)發(fā)

Kubernetes 集群中的每個(gè)節(jié)點(diǎn)都會部署一個(gè) kube-proxy 組件，該組件與 Kubernetes API Server 通信，獲取集群中服務(wù)的信息，然后設(shè)置 iptables 規(guī)則，將服務(wù)請求直接發(fā)送到對應(yīng)的 Endpoint（屬于該集群的 pod）。同一組服務(wù)）。

服務(wù)發(fā)現(xiàn)

Istio 可以跟隨 Kubernetes 中的服務(wù)注冊，還可以通過控制平面中的平臺適配器與其他服務(wù)發(fā)現(xiàn)系統(tǒng)對接；然后使用數(shù)據(jù)平面的透明代理生成數(shù)據(jù)平面配置（使用 CRD，存儲在 etcd 中）。數(shù)據(jù)平面的透明代理作為sidecar容器部署在每個(gè)應(yīng)用服務(wù)的pod中，所有這些代理都需要請求控制平面同步代理配置。代理是“透明的”，因?yàn)閼?yīng)用程序容器完全不知道代理的存在。該進(jìn)程中的 kube-proxy 組件也需要攔截流量，只不過 kube-proxy 攔截進(jìn)出 Kubernetes 節(jié)點(diǎn)的流量，而 sidecar 代理攔截進(jìn)出 pod 的流量。

服務(wù)網(wǎng)格的缺點(diǎn)

由于 Kubernetes 每個(gè)節(jié)點(diǎn)上運(yùn)行有很多 pod，將原有的 kube-proxy 路由轉(zhuǎn)發(fā)功能放在每個(gè) pod 中會增加響應(yīng)延遲（由于 sidecar 攔截流量時(shí)的跳數(shù)更多）并消耗更多資源。為了以細(xì)粒度的方式管理流量，將添加一系列新的抽象。這會進(jìn)一步增加用戶的學(xué)習(xí)成本，但隨著技術(shù)的普及這種情況會慢慢得到緩解。

服務(wù)網(wǎng)格的優(yōu)點(diǎn)

kube-proxy 設(shè)置是全局的，無法對每個(gè)服務(wù)進(jìn)行精細(xì)控制，而服務(wù)網(wǎng)格通過 sidecar 代理將流量控制從 Kubernetes 的服務(wù)層中取出，從而實(shí)現(xiàn)更大的彈性。

Kube-Proxy 的缺點(diǎn)

首先，如果轉(zhuǎn)發(fā)的 Pod 無法正常服務(wù)，它不會自動嘗試另一個(gè) Pod。每個(gè) pod 都有健康檢查機(jī)制，當(dāng) pod 出現(xiàn)健康問題時(shí)，kubelet 會重啟 pod，kube-proxy 會刪除相應(yīng)的轉(zhuǎn)發(fā)規(guī)則。此外，nodePort 類型的服務(wù)無法添加 TLS 或更復(fù)雜的消息路由機(jī)制。

Kube-proxy 實(shí)現(xiàn)了 Kubernetes 服務(wù)的多個(gè) pod 實(shí)例之間的流量負(fù)載均衡，但是如何對這些服務(wù)之間的流量進(jìn)行細(xì)粒度控制——例如將流量按百分比劃分到不同的應(yīng)用程序版本（這些版本都是同一個(gè)應(yīng)用程序的一部分）服務(wù)但在不同的部署上），或者進(jìn)行灰度發(fā)布和藍(lán)綠發(fā)布？

Kubernetes 社區(qū)提供了一種使用 Deployment 進(jìn)行灰度發(fā)布方法，這本質(zhì)上是一種通過修改 pod 標(biāo)簽將不同 pod 分配給部署服務(wù)的方法。

Kubernetes Ingress 與 Istio 網(wǎng)關(guān)

如上所述，kube-proxy 只能在 Kubernetes 集群內(nèi)路由流量。Kubernetes 集群的 Pod 位于 CNI 創(chuàng)建的網(wǎng)絡(luò)中。入口（在 Kubernetes 中創(chuàng)建的資源對象）是為了集群外部的通信而創(chuàng)建的。它由位于 Kubernetes 邊緣節(jié)點(diǎn)上的入口控制器驅(qū)動，負(fù)責(zé)管理南北流量。Ingress 必須對接各種 Ingress Controller，例如nginx ingress 控制器。Ingress僅適用于HTTP流量，使用簡單。它只能通過匹配有限數(shù)量的字段（例如服務(wù)、端口、HTTP 路徑等）來路由流量。這使得無法路由 MySQL、Redis 和各種 RPC 等 TCP 流量。這就是為什么你會看到人們在入口資源注釋中編寫 nginx 配置語言。直接路由南北流量的唯一方法是使用服務(wù)的 LoadBalancer 或 NodePort，前者需要云供應(yīng)商支持，后者需要額外的端口管理。

Istio Gateway 的功能與 Kubernetes Ingress 類似，負(fù)責(zé)進(jìn)出集群的南北向流量。Istio Gateway 描述了一種負(fù)載均衡器，用于承載進(jìn)出網(wǎng)格邊緣的連接。該規(guī)范描述了一組開放端口以及這些端口使用的協(xié)議、用于負(fù)載均衡的 SNI 配置等。Gateway 是一個(gè) CRD 擴(kuò)展，它也重用了 sidecar 代理的功能；詳細(xì)配置請參見Istio 網(wǎng)站。

Envoy

Envoy 是 Istio 中默認(rèn)的 sidecar 代理。Istio 基于 Enovy 的 xDS 協(xié)議擴(kuò)展了其控制平面。在談?wù)?Envoy 的 xDS 協(xié)議之前，我們需要先熟悉一下 Envoy 的基本術(shù)語。以下是 Envoy 中的基本術(shù)語及其數(shù)據(jù)結(jié)構(gòu)列表；請參閱Envoy 文檔了解更多詳細(xì)信息。

基本術(shù)語

以下是您應(yīng)該了解的 Enovy 基本術(shù)語。

Downstream：下游主機(jī)連接 Envoy，發(fā)送請求，接收響應(yīng)；即發(fā)送請求的主機(jī)。

Upstream：上游主機(jī)接收來自 Envoy 的連接和請求并返回響應(yīng)；即接收請求的主機(jī)。

Listener：Listener 是一個(gè)命名的網(wǎng)絡(luò)地址（例如端口、UNIX 域套接字等）；下游客戶端可以連接到這些偵聽器。Envoy 向下游主機(jī)公開一個(gè)或多個(gè)偵聽器以進(jìn)行連接。

Cluster：集群是 Envoy 連接的一組邏輯上相同的上游主機(jī)。Envoy 通過服務(wù)發(fā)現(xiàn)來發(fā)現(xiàn)集群的成員。或者，可以通過主動健康檢查來確定集群成員的健康狀態(tài)。Envoy 通過負(fù)載均衡策略決定集群中的哪個(gè)成員來路由請求。

Envoy 中可以設(shè)置多個(gè)監(jiān)聽器，每個(gè)監(jiān)聽器可以設(shè)置一個(gè)過濾器鏈（過濾器鏈表），并且過濾器是可擴(kuò)展的，以便我們可以更輕松地操縱流量的行為——例如設(shè)置加密、私有 RPC 等。

xDS 協(xié)議由 Envoy 提出，是 Istio 中默認(rèn)的 sidecar 代理，但只要實(shí)現(xiàn)了 xDS 協(xié)議，理論上就可以在 Istio 中用作 sidecar 代理——比如螞蟻集團(tuán)開源的MOSN。

Istio 是一個(gè)功能非常豐富的服務(wù)網(wǎng)格，包括以下功能。

流量管理：這是Istio最基本的功能。

策略控制：啟用訪問控制系統(tǒng)、遙測捕獲、配額管理、計(jì)費(fèi)等。

可觀察性：在 sidecar 代理中實(shí)現(xiàn)。

安全身份驗(yàn)證：Citadel 組件執(zhí)行密鑰和證書管理。

Istio 中的流量管理

Istio 中定義了以下 CRD 來幫助用戶進(jìn)行流量管理。

網(wǎng)關(guān)：網(wǎng)關(guān)描述了運(yùn)行在網(wǎng)絡(luò)邊緣的負(fù)載均衡器，用于接收傳入或傳出的 HTTP/TCP 連接。

VirtualService：VirtualService 實(shí)際上將 Kubernetes 服務(wù)連接到 Istio 網(wǎng)關(guān)。它還可以執(zhí)行其他操作，例如定義一組在尋址主機(jī)時(shí)應(yīng)用的流量路由規(guī)則。

DestinationRule：DestinationRule 定義的策略決定流量經(jīng)過路由后的訪問策略。簡而言之，它定義了流量的路由方式。其中，這些策略可以定義為負(fù)載均衡配置、連接池大小和外部檢測（用于識別并驅(qū)逐負(fù)載均衡池中不健康的主機(jī)）配置。

EnvoyFilter：EnvoyFilter 對象描述代理服務(wù)的過濾器，可以自定義 Istio Pilot 生成的代理配置。這種配置一般初級用戶很少使用。

ServiceEntry：默認(rèn)情況下，Istio 服務(wù)網(wǎng)格中的服務(wù)無法發(fā)現(xiàn)網(wǎng)格之外的服務(wù)。ServiceEntry 允許將其他條目添加到 Istio 內(nèi)的服務(wù)注冊表中，從而允許網(wǎng)格中自動發(fā)現(xiàn)的服務(wù)訪問并路由到這些手動添加的服務(wù)。

Kubernetes、xDS、Istio

回顧了 Kubernetes 的 kube-proxy 組件、xDS 和 Istio 中流量管理的抽象之后，現(xiàn)在讓我們僅在流量管理方面對這三個(gè)組件/協(xié)議進(jìn)行比較（請注意，這三個(gè)組件并不完全相同）。

要點(diǎn)

Kubernetes 的本質(zhì)是應(yīng)用程序生命周期管理，特別是部署和管理（伸縮、自動恢復(fù)、發(fā)布）。

Kubernetes 為微服務(wù)提供了可擴(kuò)展且高彈性的部署和管理平臺。

服務(wù)網(wǎng)格基于透明代理，通過 sidecar 代理攔截服務(wù)之間的流量，然后通過控制平面配置管理它們的行為。

服務(wù)網(wǎng)格將流量管理與 Kubernetes 解耦，無需 kube-proxy 組件來支持服務(wù)網(wǎng)格內(nèi)的流量；通過提供更接近微服務(wù)應(yīng)用程序?qū)拥某橄髞砉芾矸?wù)間流量、安全性和可觀察性。

xDS 是服務(wù)網(wǎng)格配置的協(xié)議標(biāo)準(zhǔn)之一。

服務(wù)網(wǎng)格是 Kubernetes 中服務(wù)的更高級別抽象。

概括

如果說Kubernetes 管理的對象是 Pod，那么 Service Mesh 管理的對象就是服務(wù)，所以只要用 Kubernetes 來管理微服務(wù)，然后應(yīng)用 Service Mesh 就可以了。如果您甚至不想管理服務(wù)，那么可以使用像Knative這樣的無服務(wù)器平臺。