文档章节

Istio在FreeWheel微服务中的实践

F
 FreeWheel_
发布于 04/08 17:17
字数 3395
阅读 0
收藏 0

导读  

近日,CNUTCon全球运维技术大会在上海举行,FreeWheel具有实战经验的一线技术专家受邀出席大会的“解决方案”专场。会上,专家就FreeWheel 微服务演化过程中因模块之间数据流不断调整而产生的挑战,以及为解决该问题进行的技术探索展开分享,围绕 Istio 的原理和技术实现,介绍了 Istio 1.0 在 FreeWheel 微服务化中的应用经验。

 

01 FreeWheel的微服务之痛

FreeWheel是一家数字视频解决方案公司,我们核心业务系统可以理解为一个Web ERP。最初核心业务系统完全基于Rails,是一个典型的三层架构,但这个大型单体应用在发展了近十年以后,维护成本越来越大,而且难以扩展。2016年FreeWheel开始迁移到微服务架构,所有的业务功能都用Golang来重写,同时引入了Kubernetes作为服务的部署平台。

但在迁移到微服务之后,FreeWheel面临很多通信方面的矛盾。一方面,平台层的运维开始和应用层的改动互相牵制。有时升级核心网络设备,整个系统都会被波及。另一方面,随着应用层越来越快的迭代,模块之间开始互相牵制,进而影响了客户,同时也降低了应用迭代的效率。归结起来是两方面的问题:一个是通信的控制,另外一个是通信的可见性,可以理解成监控。

最初我们尝试用一个中心化的服务网关Gateway来解决这种矛盾。但随着迁移微服务的模块越来越多,这种服务出现了两个矛盾:一个是服务和服务之间的流量互相影响,第二个是在微服务中服务网关的配置有很多个性化的地方,大锅饭带来了复杂的配置管理,渐渐难以为继。

 

 

在这样的背景下,FreeWheel切换到了Service Mesh解决方案,选择了Istio。

FreeWheel选择Istio解决方案的主要原因,是因为FreeWheel的技术栈是Golang和Kubernetes,Istio是目前最合适的选择。

 

02 Istio的架构和基本原理

首先来看一下Istio的架构和基本原理。Istio有四个核心模块:

1. 反向代理模块: Istio Proxy劫持Pod的所有流量,管理Service Mesh里面的通信。同时,管理Mesh内外边界交互的流量也是反向代理。

2. Pilot模块: 管理所有Service Mesh的动态配置。

3. Citadel模块: 主要是自动维护服务之间通信的证书。

4. Mixer模块: 在Kubernetes部署了两组服务:一组服务提供授权和容量检查的能力,另外一组Policy提供数据采集的能力,通过该服务将数据汇总。

 

 

如果从整个系统设计上看,也可以分成四个板块:

1. 反向代理。

2. 网络安全,目前主要兼容Spiffe标准实现。

3. 为C++实现的Proxy接入K8s的动态配置管理。

4. 对于Attribute的有限状态机模型,授权、容量、管理监控等所有的基础。

 

03 Istio管理下的微服务

Service Mesh部署pod之后,发生了什么?

1. 创建Pod之前,首先由Sidecar Injector来将自定义的initContainer, sidecar container、volume添加到Pod中,这里的volume是Istio自带的通信安全相关的,Istio为Pod维护了动态的认证密钥。

2. 接下来创建容器启动Pod,其中initContainer先为当前Pod生成流量劫持的iptables规则。

3. 然后启动Pod中的sidecar和实际应用容器。

4. 接下来sidecar和Pilot建立连接接受动态配置和更新;和Mixer(policy)建立连接来检查授权、容量等;和Mixer(telemetry)建立连接来上报流量相关的监控元数据。

Pod启动完成并且接入Service Mesh后,这里面还有两个组件:

  • Galley:实现对动态配置的校验。

  • Citadel:检查Pod中mount的secret的有效性,并自动为Pod分发合法的证书。

 

04 FreeWheel如何充分利用Istio?

FreeWheel已经有一套复杂的自定义认证、授权机制,为了充分利用Istio,我们通过扩展Istio来整合这些系统,涉及两方面:

  • 扩展Sidecar:加入认证支持,提供了对业务系统的认证支持,将用户相关信息以header的形式传入Mesh,后续的授权、监控、限流都可以用Istio原生的机制来完成。

  • 扩展Mixer:选择一部分流量来应用对应的授权逻辑。

FreeWheel自定义认证和授权模块的原理图

 

扩展Sidecar接入认证

FreeWheel原本就有一个简单的服务网关实现,将认证逻辑抽取到这个模块中,认证完成之后在反向代理中为下游的服务插入一些header,比如认证后得到的用户信息等。

Istio没有开发这种对请求完全定制的接口,所以要想修改请求和响应的内容,就必须要定义反向代理。我们没有替换Envoy,改为在它下面接一个反向代理来实现,这个反向代理同时还接入了配置管理服务,可以利用原生的k8s配置管理接口来实现动态配置管理。不过需要注意的是,Sidecar里面的容器的流量默认是不被Iptables劫持的,如果需要纳入流量劫持,需要显式指定Aannotation来包含端口或者CIDR。

接入Sidecar其实就是修改Istio-system/istio-sidecar-injector的ConfigMap,并加入自定义的反向代理。

这个反向代理很简单,写死了token和用户信息的映射关系,如果上游传入了token,就将用户信息塞到header中传给下游,然后流量被转发给应用服务,在反向代理和应用服务之间还有一个检查授权、容量的过程,这是通过定制Mixer来实现的。

通过在Sidecar中增加FreeWheel自定义认证支持,下游可以充分利用Istio提供的授权、限流、监控接口。不过在Sidecar Injector用了一段时间以后,发现里面有两个问题:

  • Sidecar没有K8s自动注入的secret,也无法通过容器内环境变量自动建立Master连接,需要管理额外的Kubernetes。

  • Sidecar内的服务流量默认是不被劫持的,如果需要劫持需要添加额外的Annotation。

 

扩展Mixer接入授权

我们为实现高度定制的请求和响应内容时,用Sidecar实现扩展,但服务在授权、自定义限流的时候,很多类似的功能并不需要修改请求响应,只是在请求到达下游服务之前算一下,结果拒绝,或者通过。这时候就可以通过Mixer来扩展。

Mixer是一个高度可定制的状态机模型,Envoy提供两个接口:Report 和Check。这两个接口会在连接和请求的不同生命后期被多次调用,我们经常用到的Quota,Metrics,Tracing 之类的功能都是通过它来实现的。

下图为Mixer的基本原理,Template是对Proxy上报的Attribute的特定处理机制的框架,支持四类:

  • Preprocess: 汇总流量相关元数据和环境(k8s)相关的元数据。

  • Report: 上报数据。

  • Check: 决策是否允许当前访问。

  • Quota: 决策容量是否足够。

Mixer的基本原理

 

FreeWheel是如何扩展Mixer的呢?

首先,增加了一个adapter来实现授权的模板。其实,FreeWheel已有一个默认的RBAC模板。但新增一个授权能力的时候,我们希望做到绝对可控。比如,通过一个动态配置,在只有某一部分user或访问某一类URL的时候打开这个授权,其他的时候则把它关掉。

Mixer提供了一种非常灵活的模型,让Handler可以在流量中动态地选择一部分来引入额外的机制(如权限控制、限流等),在应用运维中这是很重要的能力,只要是不修改请求、响应的功能都可以采用扩展Mixer来实现。

这里,mymock会完全拒绝所有被匹配到的流量:

 

mymock Handler的基本原理

 

在扩展Mixer的过程中有三个关键要素:

1. Handler的配置。这是一个默认行为,让checknothing匹配到user1的时候返回到400,然后全部拒绝。

2. 系统进程instance。这是每个模块固定的东西,定义了这种输入以后,里面可以有一个黑盒,是面向对象的概念。

3. RUL。当用户身份是user1的时候,instance会被handler来处理。如果要扩展,第一步需要定义handler的数据结构;第二步,实现time的接口,这里有两个接口;第三把定义的handler的文件里面相关go的接口通过代码生成。最后,注册到mixer里面,重新编译打包mixer以后就可以直接用了。

 

需要注意的是,mixer接入的是授权的policy模块,可能会影响服务网格(Service Mesh)不工作。因此,重新部署这些模块的时候,如果不能忍受短时间的宕机,则可能需要做一些灰度发布的机制。

 

对于Istio配置管理,我们也发现一些性能瓶颈和局限性。

  • Kubernetes和对etcd配置管理存在性能瓶颈。单个Resource控制在K级别,能够比较正常的工作,一旦到达万级别可能会出现不工作,比如好几万的单个Resource。

  • Istio配置本身的局限性。首先是防抖动处理,集群里面部署变化再快,都不会阻塞Istio。其次Istio其他的配置没有防抖动处理,一旦用程序插入的时候一定要做限流。最后Istio用了CRD无法做到的兼容性设计,所以升级CRD也没有办法做到平滑的升级。

 

05 FreeWheel未来将怎么做?

  • 首先是Service Contract,封装Istio以及平台层其他配置的复杂度,抽象出一个安全,高效的应用运维体系,为未来技术上的改进留出空间。

  • 然后是Chaos Testing,解决复杂的微服务系统的持续运营和风险控制问题。这个也是目前比较火的一个主题。

 

现场问答

1. 对于Service Mesh外部流量进入,在Kubernetes有Ingress,在微服务Service Mesh的应用里面也有一个Gateway的情况下,它里面是把Gateway转到Service Mesh,这三个怎么联动让外部的流量能够顺畅地进去?

:很简单。Service Mesh可以理解成是一个封闭的盒子,你所有的外部的Ingress以前该怎么运作还怎么运作,我们现在就讨论在Service Mesh里面是怎么运作的。如果把它看作一个黑盒,现在你有一个Ingress,可以把它转到Istio里面的Ingress Gateway,过去流量会直接转发到各个Pod,是直接打到Pod,由Pod上Sidecar,再转给应用。

2. 您刚才说的Sidecar里的应该是直接把Pod里面的流量屏蔽掉,只能通过Service Mesh里面的Gateway流量才能够进到Pod里面?

:不会。你说的这个流量转发其实并没有任何的限制,Service Mesh里面每一个反向代理都可以承担Ingress Gateway的功能,仅仅是路由配置的问题。如果把这个弄好了,在任何一个Service Mesh上都可以配置这个功能。这个反向代理是一模一样的。

3. 我用Istio的Gateway,Kubernetes里面的Ingress关掉,能够跟外部之间联系。

:这个才是Istio比较推荐的模式,你管理这个集群外部进来流量的时候直接走Ingress Gateway,可以做到很好的限制。

4. 你们在落地的过程中有没有遇到一些坑?

:有。我们一开始试图把业务的权限数据直接转成原生的数据结构,因为我们想用它来做权限控制。但是后来发现它掌控不了那么大的数据量。第二个坑是Istio对它的一些Resource是没有防抖动处理的,可能会导致这个Service Mesh行为很不稳定,在客户端一定要做限流。

另外从长远看,Istio的这些模块目前都还是单点,可能导致Service Mesh不可用。我们以前也有遇到过跑了三个月莫名其妙出问题了,维护这种监控系统要频繁地做演习。我们公司现在一个月做一次演习,会定时在一个主生产环境里把问题拿出来,然后检查各个环节有没有正常工作,这也是我们未来会发展的一个事情。

 

© 著作权归作者所有

F
粉丝 0
博文 7
码字总数 27684
作品 0
私信 提问
阿里云Kubernetes Service Mesh实践进行时(2): 通过示例深入Istio

概述 上一篇文章已经介绍了Istio及其各个核心组件,并且在阿里云Kubernetes容器服务基础之上,介绍了如何快速搭建一套用于连接、管理以及安全化微服务的开放平台。 阿里云Kubernetes Servic...

osswangxining
2018/06/06
0
0
Service Mesh实践之Istio初体验

微服务国内发展背景: 2014年,Martin Fowler撰写的《Microservices》使得许多国内的先行者接触到微服务这个概念并将其引入国内,2015年越来越多的人通过各种渠道了解到微服务的概念并有人开...

Docker
2018/08/10
0
0
阿里云Kubernetes Service Mesh实践进行时(6): 故障诊断与检测工具Weave Scope

概述 本系列文章已经通过一个官方示例演示了如何部署应用到上述Istio环境中,并演示了如何设置智能路由、分布式追踪以及Istio 的遥测数据收集、查询及可视化等功能。 阿里云Kubernetes Serv...

osswangxining
2018/06/06
0
0
云栖大会Workshop之Istio on Kubernetes最佳实践

概述 Istio是一个用于连接/管理以及安全化微服务的开放平台,提供了一种简单的方式用于创建微服务网络,并提供负载均衡、服务间认证以及监控等能力,并且关键的一点是并不需要修改服务本身就...

osswangxining
2018/09/14
0
0
阿里云Kubernetes Service Mesh实践进行时(3): 智能路由

概述 上一篇文章通过一个官方示例演示了如何部署应用到上述Istio环境中,本文使用此示例来尝试 Istio 的流量路由、故障注入、流量转移等功能。 阿里云Kubernetes Service Mesh实践进行时(1)...

osswangxining
2018/06/06
0
0

没有更多内容

加载失败,请刷新页面

加载更多

局域网能互相ping通,ubuntu虚拟机不能上外网

【问题】 桥接模式老是无法上网,查看本机IP发现被分配了一个私网地址,猜测应该是虚拟DHCP服务器没有打开,于是查看Ubuntu的网络配置: /etc/network/interfaces 发现没有dhcp配置的信息,只...

tahiti_aa
52分钟前
1
0
以太坊助记词PHP开发包简介

以太坊助记词PHP开发包用来为PHP以太坊应用增加助记词和层级确定密钥支持能力。下载地址:以太坊助记词php开发包 。 1、开发包概述 以太坊助记词PHP开发包主要包括以下特性: 生成符合BIP39...

汇智网教程
昨天
2
0
系统监控-分布式调用链Skywalking

1. 为什么要使用分布式调用链技术? 随着公司业务的高速发展,公司服务之间的调用关系愈加复杂,如何理清并跟踪它们之间的调用关系就显的比较关键。线上每一个请求会经过多个业务系统,并产生...

秋日芒草
昨天
4
0
告诉自己的一些建议

摆脱学生心态 尽快发挥自己价值,让公司感知自己的存在,才是王道 选择比努力重要 自己附着的平台的经济体要是一个快速崛起的行业 转行趁早,年龄越大选择成本越高 趁早大量试错,学习新领域...

林怡丰
昨天
4
0
Windows下安装Redis

下载地址: 3.0老版已不维护更新:https://github.com/MicrosoftArchive/redis/releases 4.0版 https://github.com/tporadowski/redis/releases 中文官网:http://www.redis.net.cn/ https:......

Aeroever
昨天
4
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部