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

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

Istio 流量管理策略

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

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

Envoy 架構(gòu)

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

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

從上圖中我們可以看到 Envoy 中包含兩種類(lèi)型的 filter:L4 filter (即 network filter) 和 L7 filter。EnvoyFilter 中可以自定義配置的 filter 即為這兩種 filter。從下面的監(jiān)聽(tīng)器配置可以看到 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 等。無(wú)論 L4 還是 L7 的 filter 都是按照指定的次序執(zhí)行，Istio 中使用的 istio-proxy 也是在 envoy 的基礎(chǔ)上額外編譯進(jìn)了 istio_authn，mixer 等 filter，以實(shí)現(xiàn) Istio 中的 policy 和 telemetry 等功能。

更近一步：EnvoyFilter 案例分析

假設(shè)現(xiàn)在有一個(gè)需求，在調(diào)用 REST 接口時(shí)候如果 header 中含有 Key/Value 為 “foo:bar” 的請(qǐng)求要求返回 444。 那么我們可以通過(guò) EnvoyFilter 實(shí)現(xiàn)，在 sidecar 的 inbound 鏈中修改監(jiān)聽(tīng)器配置，在 httpconnectionmanager 的第一個(gè)位置插入 envoy.fault 這樣一個(gè) 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 接口生成的動(dòng)態(tài)監(jiān)聽(tīng)器配置：

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 這個(gè) L4 下面的 http_filters 鏈中第一條規(guī)則，符合預(yù)期，同時(shí)請(qǐng)求結(jié)果生效。

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

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

追本溯源：缺少隔離

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

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

這就會(huì)產(chǎn)生一個(gè)嚴(yán)重的問(wèn)題。因?yàn)橛脩?hù)之間的行為是不可感知的，在集群范圍內(nèi)查找 EnvoyFilter 會(huì)導(dǎo)致用戶(hù)行為的不可控，什么意思呢？讓我們通過(guò)下圖來(lái)具體說(shuō)明：

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

解決：namespace 級(jí)別隔離

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

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

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

持續(xù)改進(jìn)：校驗(yàn)

除了隔離之外，如果用戶(hù)在 EnvoyFilter 中配置的 filter 沒(méi)有被編譯進(jìn) Envoy，那么 Pilot 下發(fā)給 Envoy 的配置會(huì)直接導(dǎo)致 Envoy 出錯(cuò)，如下：

[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 團(tuán)隊(duì)為了提升整個(gè)服務(wù)網(wǎng)格的容錯(cuò)性和可用性，對(duì) EnvoyFilter 的創(chuàng)建做了進(jìn)一步的校驗(yàn)，這涉及到 istio-galley。

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

#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

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

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