写点什么

Kubernetes 上的 Service Mesh 实践:用 EnvoyFilter 扩展 Istio

  • 2019-11-08
  • 本文字数:3762 字

    阅读完需:约 12 分钟

Kubernetes上的Service Mesh实践:用EnvoyFilter扩展Istio

KUN(中文名鲲)是 UCloud 面向内部的基于 Kubernetes 的资源交付平台,提供监控告警、CI/CD、网络双栈、Service Mesh 等能力。在践行 Service Mesh 理念的过程中,面对 Istio 的不足,团队针对其源码做了大量改进,包括给网络子系统 Pilot 下的资源做隔离,对 EnvoyFilter 做深度优化等,使其能在生产环境稳定运行,并提供强大的扩展能力。截止目前,KUN 平台上已有 175 个应用通过 Istio 提供服务。本文将分享我们在这方面的实践经验。

Istio 流量管理策略

Istio 中的流量管理策略是通过 Pilot 统一管理下发给 Envoy 的,Envoy 作为数据面,对外提供 XDS 接口。为了保证最终一致性,Pilot 实现了 Envoy 提供的 ADS(Aggregated Discovery Service)接口,执行顺序为:CDS, EDS, LDS, RDS。Pilot 本身是无状态的,所有的资源配置全部以 CRD 实例的形式保存在 Kubernetes 集群上,Envoy 和 Pilot 连接建立完成以后,Pilot 以事件通知的形式触发推送,Envoy 配置更新生效。



统一的配置管理简化了运维成本,同时也意味着定制化能力的缺失。享受 Pilot 通用配置管理所带来的便利化的同时,又要针对具体的 sidecar 流量管理做微调,如何才能做到两者兼顾呢?这就涉及今天要介绍的主题:EnvoyFilter

Envoy 架构

EnvoyFilter 是 Istio 中自定义的一种网络资源对象,用来更新配置 Envoy 中的 filter,为服务网格控制面提供了更强大的扩展能力,使 Envoy 中 filter chain 具备自定义配置的能力。


我们先来看下 Envoy 的整体架构:



从上图中我们可以看到 Envoy 中包含两种类型的 filter:L4 filter(即 network filter)和 L7 filter。EnvoyFilter 中可以自定义配置的 filter 即为这两种 filter。从下面的监听器配置可以看到 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 都是按照指定的次序执行,Istio 中使用的 istio-proxy 也是在 envoy 的基础上额外编译进了 istio_authn,mixer 等 filter,以实现 Istio 中的 policy 和 telemetry 等功能。

更近一步:EnvoyFilter 案例分析

假设现在有一个需求,在调用 REST 接口时候如果 header 中含有 Key/Value 为“foo:bar”的请求要求返回 444。 那么我们可以通过 EnvoyFilter 实现,在 sidecar 的 inbound 链中修改监听器配置,在 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 接口生成的动态监听器配置:


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 链中第一条规则,符合预期,同时请求结果生效。


EnvoyFilter 的更多具体配置,可以参考社区

追本溯源:缺少隔离

了解 EnvoyFilter 的基本使用之后,我们将深入分析 Pilot(1.1.2)源码,来探究 EnvoyFilter 的工作原理和隔离性不足的根源。下图展示了构建 Envoy 监听器的主要工作流程。



InsertUserFilter 是在监听器配置完成之后执行的,用于向 Envoy filter chain 中插入用户自定义的 filter。insertUserFilter 会调用下图中的 getUserFiltersForWorkload 函数,在整个集群范围内查找满足条件的 EnvoyFilter,把获取到的 filter 合并后插入到监听器的 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}
复制代码


这就会产生一个严重的问题。因为用户之间的行为是不可感知的,在集群范围内查找 EnvoyFilter 会导致用户行为的不可控,什么意思呢?让我们通过下图来具体说明:



如果图中的两个用户 user1 和 user2,分别在对应的 namespace 下面部署两个具有相同标签的 pod,绑定不同的 EnvoyFilter,返回码应该分别为 555(user1)和 444(user2)。但 user2 访问/hello 得到的最终返回码是 555,与预期 444 不符,其行为被 user1 干扰了。原因就在于缺少 namespace 级别的隔离。

解决:namespace 级别隔离

EnvoyFilter 为什么不做 namespace 级别的隔离?针对这个问题,笔者曾向 Istio 社区寻求答案,但没有得到合理的答复。基于此,KUN 团队针对 Istio1.1.2 中 EnvoyFilter 做了 namespace 级别的隔离,使其影响范围控制在单一的 namespace 下,让普通用户具备可以修改 Envoy filter chain 的能力而不会相互干扰。



下图我们可以看到 EnvoyFilter 的作用域被控制在了 namespace 级别。



截止目前为止,KUN 平台上共有 175 个应用通过 Istio 提供服务,除了 EnvoyFilter,KUN 同时针对其他网络资源也做了严格的隔离,以此来保证不同用户的服务的稳定性。基于此,不同用户可以根据具体需求在自定义 namespace 下创建 EnvoyFilter,为自己的服务做功能扩展。

持续改进:校验

除了隔离之外,如果用户在 EnvoyFilter 中配置的 filter 没有被编译进 Envoy,那么 Pilot 下发给 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 团队为了提升整个服务网格的容错性和可用性,对 EnvoyFilter 的创建做了进一步的校验,这涉及到 istio-galley。


istio-galley 的作用之一是实现了 kubernetes 中 validating webhook 的功能,用户在创建 EnvoyFilter 的时候 apiserver 会调用 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
复制代码


此时,我们可以看到错误的配置直接被拦截在创建时。


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

总结

Service Mesh 将基础设施下沉,使上层业务只专注于业务本身,在云原生领域具有广阔的应用前景。KUN 团队很早开始跟进 Service Mesh,早在 Istio1.0 版本之前就已在内部试用。团队将始终致力于改革 UCloud 内部研发流程,提升研发效率,并协同社区一同完善 Service Mesh 功能。同时也很欣喜地看到,我们此前做的一些改进工作,如支持 IPv6 环境、资源隔离等,在 Istio 后续版本中也陆续开始支持。


本文转载自公众号 UCloud 技术(ID:ucloud_tech)。


原文链接:


https://mp.weixin.qq.com/s/sQ59WxY6zRyUwDHFsUefrg


2019-11-08 16:391396

评论

发布
暂无评论
发现更多内容

京东小程序平台助力快送实现跨端 | 京东云技术团队

京东科技开发者

小程序 ide 跨端 企业号10月PK榜

优化模型之标注错误

矩视智能

深度学习 机器视觉

第2期 | GPTSecurity周报

云起无垠

TiDB 7.x 源码编译之 TiDB Server 篇,及新特性解析

TiDB 社区干货传送门

版本测评 新版本/特性发布 7.x 实践

2023 年 API 排行榜热门榜单揭晓

Apifox

程序员 前端 接口 API API 协议

加速新型工业化“智造”创新,用友数智驱动新质生产力

用友BIP

智能制造

mac电脑版vm虚拟机 VMware Fusion Pro 中文最新

胖墩儿不胖y

虚拟机 Mac软件 虚拟机软件

互动直播双11大促开启!!!快来! | 京东云技术团队

京东科技开发者

互动直播 数字人 企业号10月PK榜 AI直播

是时候了!MySQL 5.7 的下一站,不如试试 TiDB?

TiDB 社区干货传送门

TiDB 企业版全新升级,平凯数据库核心特性全解读

TiDB 社区干货传送门

收获98.23%候选人的好评,ATL新能源做对了什么?

用友BIP

智能招聘

一周完成“药管家”元服务开发,上线单月用户达千万

最新动态

颠覆者:Telegram 凭借源自中国的云基础设施成为超级应用

FinClip

页面查询多项数据组合的线程池设计 | 京东云技术团队

京东科技开发者

线程池 分页查询 企业号10月PK榜 数据组合

软件测试|计算机系本科生获“火焰杯”软件测试高校就业选拔赛一等奖

霍格沃兹测试开发学社

多模态GPT-V出世!36种场景分析ChatGPT Vision能力,LMM将全面替代大语言模型? | 京东云技术团队

京东科技开发者

人工智能 LLM模型 企业号10月PK榜 GPT-V

TiDB 社区第三届 1024 程序员心愿节|你的心愿,我来实现,人均带着一个礼物的时刻到啦!

TiDB 社区干货传送门

TiKV Fast Tune 介绍及手册,快速定位 TiDB/TiKV 性能抖动或退化

TiDB 社区干货传送门

把AI刻进矿山生产DNA | 用友BIP助力智慧矿山精益管理提速

用友BIP

智能制造

一站式轻量化部署服务器集群监控方案

lklmyy

云计算 部署 测试开发 #云原生

低调而无为而治,藏在超级应用背后的道家哲学

FinClip

手机端侧文字识别:挑战与解决方案

合合技术团队

人工智能 技术 手机 识别

“达观杯”智能文档版面分析赛题baseline已上线,欢迎下载报名

NLP资深玩家

Kubernetes上的Service Mesh实践:用EnvoyFilter扩展Istio_文化 & 方法_王昌宇_InfoQ精选文章