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

為什么 Istio 運行在 Kubernetes 上？

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

Istio 在哪些方面對Kubernetes進行了擴展？它解決了什么問題？

Kubernetes、Envoy 和 Istio 之間是什么關系？

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

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

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

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

kube-proxy 作用的描述。

Kubernetes 對于微服務管理的局限性。

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

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

Kubernetes 與服務網(wǎng)格

下圖展示了 Kubernetes 和 Service Mesh（每個 pod 一個 sidecar 模型）中的服務訪問關系。

流量轉發(fā)

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

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

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

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

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

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

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

Kube-Proxy 的缺點

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

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

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

Kubernetes Ingress 與 Istio 網(wǎng)關

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

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

Envoy

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

基本術語

以下是您應該了解的 Enovy 基本術語。

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

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

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

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

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

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

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

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

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

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

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

Istio 中的流量管理

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

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

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

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

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

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

Kubernetes、xDS、Istio

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

要點

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

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

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

服務網(wǎng)格將流量管理與 Kubernetes 解耦，無需 kube-proxy 組件來支持服務網(wǎng)格內(nèi)的流量；通過提供更接近微服務應用程序層的抽象來管理服務間流量、安全性和可觀察性。

xDS 是服務網(wǎng)格配置的協(xié)議標準之一。

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

概括

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