摘要：宋體宋體是在監(jiān)聽器配置完成之后執(zhí)行的，用于向中插入用戶自定義的。宋體宋體截止目前為止，平臺上共有個應用通過提供服務，除了，同時針對其他網(wǎng)絡資源也做了嚴格的隔離，以此來保證不同用戶的服務的穩(wěn)定性。

KUN（中文名鯤）是 UCloud 面向內(nèi)部的基于 Kubernetes 的資源交付平臺，提供監(jiān)控告警、CI/CD、網(wǎng)絡雙棧、Service Mesh 等能力。在踐行 Service Mesh 理念的過程中，面對 Istio 的不足，團隊針對其源碼做了大量改進，包括給網(wǎng)絡子系統(tǒng) Pilot 下的資源做隔離，對 EnvoyFilter 做深度優(yōu)化等，使其能在生產(chǎn)環(huán)境穩(wěn)定運行，并提供強大的擴展能力。截止目前，KUN 平臺上已有 175 個應用通過 Istio 提供服務。本文將分享我們在這方面的實踐經(jīng)驗。

Istio 流量管理策略

Istio 中的流量管理策略是通過 Pilot 統(tǒng)一管理下發(fā)給 Envoy 的，Envoy 作為數(shù)據(jù)面，對外提供 XDS 接口。為了保證最終一致性，Pilot 實現(xiàn)了 Envoy 提供的 ADS (Aggregated Discovery Service) 接口，執(zhí)行順序為：CDS, EDS, LDS, RDS。Pilot 本身是無狀態(tài)的，所有的資源配置全部以 CRD 實例的形式保存在 Kubernetes 集群上，Envoy 和 Pilot 連接建立完成以后，Pilot 以事件通知的形式觸發(fā)推送，Envoy 配置更新生效。

統(tǒng)一的配置管理簡化了運維成本，同時也意味著定制化能力的缺失。享受 Pilot 通用配置管理所帶來的便利化的同時，又要針對具體的 sidecar 流量管理做微調(diào)，如何才能做到兩者兼顧呢？這就涉及今天要介紹的主題：EnvoyFilter

Envoy 架構(gòu)

EnvoyFilter 是 Istio 中自定義的一種網(wǎng)絡資源對象，用來更新配置 Envoy 中的 filter，為服務網(wǎng)格控制面提供了更強大的擴展能力，使 Envoy 中 filter chain 具備自定義配置的能力。

我們先來看下 Envoy 的整體架構(gòu)：

從上圖中我們可以看到 Envoy 中包含兩種類型的 filter:L4 filter (即 network filter) 和 L7 filter。EnvoyFilter 中可以自定義配置的 filter 即為這兩種 filter。從下面的監(jiān)聽器配置可以看到 filter 所處的具體位置。

listener: filter_chains: - filters: // L4 filter - name: {L4-filter-name} - name: envoy.http_connection_manager config: http_filters: // L7 filter - name: {L7-filter-name}

L4 filter 主要包括：HTTP connection manager, MySQL proxy, Rate limit, RBAC, Redis proxy, TCP proxy 等。L7 filter 是 L4 filter 中 HTTP connection manager 下面定義的 filter, 主要包括：CORS, External Authorization, Fault Injection, Health check, JWT Authentication, Lua, Rate limit, Router 等。無論 L4 還是 L7 的 filter 都是按照指定的次序執(zhí)行，Istio 中使用的 istio-proxy 也是在 envoy 的基礎上額外編譯進了 istio_authn，mixer 等 filter，以實現(xiàn) Istio 中的 policy 和 telemetry 等功能。

更近一步：EnvoyFilter 案例分析

假設現(xiàn)在有一個需求，在調(diào)用 REST 接口時候如果 header 中含有 Key/Value 為 “foo:bar” 的請求要求返回 444。 那么我們可以通過 EnvoyFilter 實現(xiàn)，在 sidecar 的 inbound 鏈中修改監(jiān)聽器配置，在 httpconnectionmanager 的第一個位置插入 envoy.fault 這樣一個 filter。

apiVersion: networking.istio.io/v1alpha3kind: EnvoyFiltermetadata: name: simple-envoy-filterspec: workloadLabels: app: helloworld filters: - listenerMatch: listenerType: SIDECAR_INBOUND listenerProtocol: HTTP insertPosition: index: FIRST filterType: HTTP filterName: envoy.fault filterConfig: abort: percentage: numerator: 100 denominator: HUNDRED httpStatus: 444 headers: name: foo exactMatch: bar

配置完成后我們看下 XDS 接口生成的動態(tài)監(jiān)聽器配置：

dynamic_active_listeners: - listener: filter_chains: - filters: - name: envoy.http_connection_manager config: http_filters: - name: envoy.fault config: abort: percentage: denominator: HUNDRED numerator: 100 httpStatus: 444 headers: name: bar exactMatch: foo - name: istio_authn - name: mixer

可以看到 envoy.fault 添加到了 envoy.httpconnectionmanager 這個 L4 下面的 http_filters 鏈中第一條規(guī)則，符合預期，同時請求結(jié)果生效。

EnvoyFilter 的更多具體配置，可以參考社區(qū)

（https://istio.io/docs/reference/config/networking/v1alpha3/envoy-filter/）

追本溯源：缺少隔離

了解 EnvoyFilter 的基本使用之后，我們將深入分析 Pilot (1.1.2) 源碼，來探究 EnvoyFilter 的工作原理和隔離性不足的根源。下圖展示了構(gòu)建 Envoy 監(jiān)聽器的主要工作流程。

InsertUserFilter 是在監(jiān)聽器配置完成之后執(zhí)行的，用于向 Envoy filter chain 中插入用戶自定義的 filter。insertUserFilter 會調(diào)用下圖中的 getUserFiltersForWorkload 函數(shù)，在整個集群范圍內(nèi)查找滿足條件的 EnvoyFilter，把獲取到的 filter 合并后插入到監(jiān)聽器的 filter chain 中。

func getUserFiltersForWorkload(in *plugin.InputParams) *networking.EnvoyFilter { env := in.Env // collect workload labels workloadInstances := in.ProxyInstances var workloadLabels model.LabelsCollection for _, w := range workloadInstances { workloadLabels = append(workloadLabels, w.Labels) } f := env.EnvoyFilter(workloadLabels) // 集群范圍查找 if f != nil { return f.Spec.(*networking.EnvoyFilter) } return nil}

這就會產(chǎn)生一個嚴重的問題。因為用戶之間的行為是不可感知的，在集群范圍內(nèi)查找 EnvoyFilter 會導致用戶行為的不可控，什么意思呢？讓我們通過下圖來具體說明：

如果圖中的兩個用戶 user1 和 user2，分別在對應的 namespace 下面部署兩個具有相同標簽的 pod，綁定不同的 EnvoyFilter，返回碼應該分別為 555（user1）和 444（user2）。但 user2 訪問 /hello 得到的最終返回碼是 555，與預期 444 不符，其行為被 user1 干擾了。原因就在于缺少 namespace 級別的隔離。

解決：namespace 級別隔離

EnvoyFilter 為什么不做 namespace 級別的隔離？針對這個問題，筆者曾向 Istio 社區(qū)尋求答案，但沒有得到合理的答復。基于此，KUN 團隊針對 Istio1.1.2 中 EnvoyFilter 做了 namespace 級別的隔離，使其影響范圍控制在單一的 namespace 下，讓普通用戶具備可以修改 Envoy filter chain 的能力而不會相互干擾。

下圖我們可以看到 EnvoyFilter 的作用域被控制在了 namespace 級別。

截止目前為止，KUN 平臺上共有 175 個應用通過 Istio 提供服務，除了 EnvoyFilter，KUN 同時針對其他網(wǎng)絡資源也做了嚴格的隔離，以此來保證不同用戶的服務的穩(wěn)定性。基于此，不同用戶可以根據(jù)具體需求在自定義 namespace 下創(chuàng)建 EnvoyFilter，為自己的服務做功能擴展。

持續(xù)改進：校驗

除了隔離之外，如果用戶在 EnvoyFilter 中配置的 filter 沒有被編譯進 Envoy，那么 Pilot 下發(fā)給 Envoy 的配置會直接導致 Envoy 出錯，如下：

[2019-08-08 02:03:44.048][19][warning][config] [external/envoy/source/common/config/grpc_mux_subscription_impl.cc:73] gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) 172.17.0.13_80: Didn"t find a registered implementation for name: "envoy.filters.unknown"

KUN 團隊為了提升整個服務網(wǎng)格的容錯性和可用性，對 EnvoyFilter 的創(chuàng)建做了進一步的校驗，這涉及到 istio-galley。

istio-galley 的作用之一是實現(xiàn)了 kubernetes 中 validating webhook 的功能，用戶在創(chuàng)建 EnvoyFilter 的時候 apiserver 會調(diào)用 istio-galley 做校驗，如果校驗失敗則直接返回，該實例不會持久化到集群。于是我們修改了 istio-galley 源碼，將 Envoy 中的原生支持的 filter 及 istio-proxy 編譯的 filter 作為基準進行校驗。

#kubectl -n foo create -fapiVersion: networking.istio.io/v1alpha3kind: EnvoyFiltermetadata: name: network-filterspec: workloadLabels: version: v1 filters: - listenerMatch: listenerType: SIDECAR_INBOUND listenerProtocol: HTTP insertPosition: index: LAST filterType: NETWORK filterName: envoy.filters.unknown filterConfig: key: value

此時，我們可以看到錯誤的配置直接被攔截在創(chuàng)建時。

Error from server: error when creating "networkfilter.yaml": admission webhook "pilot.validation.istio.io" denied the request: configuration is invalid: envoy filter: unknown

總結(jié)

Service Mesh 將基礎設施下沉，使上層業(yè)務只專注于業(yè)務本身，在云原生領域具有廣闊的應用前景。KUN 團隊很早開始跟進 Service Mesh，早在 Istio1.0 版本之前就已在內(nèi)部試用。團隊將始終致力于改革 UCloud 內(nèi)部研發(fā)流程，提升研發(fā)效率，并協(xié)同社區(qū)一同完善 Service Mesh 功能。同時也很欣喜地看到，我們此前做的一些改進工作，如支持 IPv6 環(huán)境、資源隔離等，在 Istio 后續(xù)版本中也陸續(xù)開始支持。