杨谕黔Istio在FreeWheel微服务中的实践

cnutcon

2018/12/08 发布于 技术 分类

文字内容
1. Move Fast and Break Things: 杨谕黔 Istio在FreeWheel微服务中的实践
2. • FreeWheel的痛点 • Istio的架构和基本原理 • FreeWheel的Istio实践 • 未来工作
3. 我们是谁? • FreeWheel 是一家为客户提供数字视频广告管理技术和服务的公司。其业务端产 品需要对接客户,提供视频广告投放优化界面,类似于 Web ERP,是一个典型 的三层架构。
4. 微服务之痛 • 两年来,我们将若干复杂的Rails单体应用拆分、迁移到微服务架构, 逻辑用Golang重写,引入了Kubernetes。随着模块越来越多,复杂 的通信带来矛盾日渐突出:流量管理、监控…
5. 最初的尝试:Gateway • 如右图,最初我们尝试用一个自研的 简单Gateway来提供统一的认证、授 权、限流、监控,但问题很快凸显出 来了: • Gateway是一个中心化的反向代 理,成为了微服务中的瓶颈,模 块流量会互相影响 • 大锅饭带来了复杂的配置管理, 渐渐难以为继
6. • FreeWheel的痛点 • Istio的架构和基本原理 • FreeWheel的Istio实践 • 未来工作
7. Istio架构 • Istio Proxy: 劫持Pod的所有通信, 是Mesh的基础 • Pilot: 为Proxy提供动态配置管理 • Citadel: 自动维护mTLS密钥 • Mixer: 在k8s中部署了两组Mixer • Policy提供授权、Quota等能力 • Telemetry提供监控数据收集能力
8. 基本原理 • Istio从架构上可以分为4个板块: • Istio Proxy: Mesh的基础 • 网络安全:兼容Spiffe标准实现 • 配置管理:为C++实现的Proxy接 入k8s的动态配置管理 • Attribute Machine: 授权,Quota ,Tracing,监控的基础
9. Istio管理下的微服务 • 右图是部署mock1.v1 Pod之后发生的事 情: • Sidecar Injection: 注入initContainer, Sidecar, istio-certs volume • Citadel: 自动刷新secrets, k8s自动加 载istio-secrets volume • Pilot: 和Sidecar建立连接,管理动态配 置 • Mixer: 和Sidecar建立连接,管理授权 、Quota和审计数据
10. • FreeWheel的痛点 • Istio的架构和基本原理 • FreeWheel的Istio实践 • 未来工作
11. FreeWheel的Istio实践 • 在FreeWheel,我们已经有一套复杂的自定义认证、授权机制,为了 充分利用Istio,我们通过扩展Istio来整合这些系统,涉及两方面: • 扩展Sidecar:加入认证支持,提供了对业务系统的认证支持,将用 户相关信息以header的形式传入mesh,后续的授权、监控、限流 都可以用Istio原生的机制来完成 • 扩展Mixer:选择一部分流量来应用对应的授权逻辑
12. FreeWheel的Istio实践 • 右图为接入FreeWheel自定义认证和 授权模块的原理图
13. 扩展Sidecar接入认证 • 修改 istio-system/istio-sidecarinjector 这个ConfigMap,加入自定 义反向代理
14. FreeWheel的Istio实践 • 通过在Sidecar中增加FreeWheel自定义认证支持,下游可以充分利用 Istio提供的授权、限流、监控接口,不过要注意Sidecar也有一些小坑 : • Sidecar没有k8s自动注入的secret,也无法通过容器内环境变量自 动建立master连接,需要管理额外的kubeconfig • Sidecar内的服务流量默认是不被劫持的,如果需要劫持需要添加额 外的annotation
15. 扩展Mixer接入授权 • 右图为Mixer的基本原理,Template 是对Proxy上报的Attribute的特定处 理机制的框架,支持四类: • Preprocess: 汇总流量相关元数据 和环境(k8s)相关的元数据 • Report: 上报数据 • Check: 决策是否允许当前访问 • Quota: 决策容量是否足够
16. Mixer or Sidecar,这是一个问题 • Mixer提供了一种非常灵活的模型,让Handler可以在流量中动态的选 择一部分来引入额外的机制(如权限控制、限流等),在应用运维中 这是很重要的能力,只要是不修改请求、响应的功能都可以采用扩展 Mixer来实现 • Sidecar里接入额外的反向代理其实提供了一个修改请求、响应的接口 ,如认证之后需要将用户信息通过header传给下游服务
17. 扩展Mixer接入授权 • 这里实现的例子mymock会完全拒绝所有 被匹配到的流量,右图是mymock Handler的基本原理 • mymock handler 是 mymock adapter的初始化配置 • 完成初始化后rule将checknothing配置 与handler关联起来,其实就是做了流 量的匹配,满足一定条件的流量上应用 mymock handler • mymock adapter直接拒绝被匹配的请 求
18. 扩展Mixer接入授权 定义Handler Spec
19. 扩展Mixer接入授权 实现Handler接口
20. 扩展Mixer接入授权 实现Handler接口
21. 扩展Mixer接入授权 注册Handler
22. 扩展Mixer接入授权 • Mixer会直接影响整个Mesh的稳定性,因此替换时要做到尽可能稳妥
23. 实践总结 • k8s/etcd 配置管理存在性能瓶颈: • 单一 resource 应控制在k级别,达到 10k 量级后响应可能会出现超 时导致配置读写状态异常,进而影响整个系统稳定性
24. 实践总结 • Istio配置管理有局限性: • Endpoint的配置管理有防抖动处理,即使集群中的部署变化再快, 也不会阻塞Istio • Istio其他配置管理没有防抖动处理( VirtualService/DestinationRule等),如果用程序自动化注入这些 配置要注意在客户端实现限流 • Istio的配置管理缺少兼容性设计,CRD无法做到平滑升级
25. • FreeWheel的痛点 • Istio的架构和基本原理 • FreeWheel的Istio实践 • 未来工作
26. 未来工作 • Service Contract: 封装Istio以及平台层的其他配置的复杂度,抽象出 一个安全、高效的应用运维体系 • Chaos Testing:解决复杂的微服务系统的持续运营和风险控制问题