Istio是⼀个Service Mesh形态的⽤于服务治理的开放平台。(治理的是服务间的访问)
连接:Istio 通过集中配置的流量规则控制服务间的流量和调⽤,实现负载均衡、熔断、故障注⼊、重试、重定向等服务治理功能。
保护:Istio 提供透明的认证机制、通道加密、服务访问授权等安全能⼒,可增强服务访问的安全性。
控制:Istio 通过可动态插拔、可扩展的策略实现访问控制、速率限制、配额管理、服务计费等能⼒。
观测:动态获取服务运⾏数据和输出,提供强⼤的调⽤链、监控和调⽤⽇志收集输出的能⼒。配合可视化⼯具,可⽅便运维⼈员了解服务的运⾏状况,发现并解决问题。
Service Mesh 是一个专门处理服务通讯的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。
在实践中,它是一组和应用服务部署在一起的轻量级的网络代理,并且对应用服务透明。
主要有控制面和数据面组成,数据面截获不同服务之间的调用并对其进行“处理”;控制面协调代理的行为,并为运维人员提供 API,用来操控和测量整个网络。
控制⾯主要包括Pilot、Mixer、Citadel等服务组件。
数据⾯由伴随每个应⽤程序部署的代理程序Envoy组成,执⾏针对应⽤程序的治理逻辑。
Pilot是为我们提供配置智能路由(如A/B测试、金丝雀发布等)、弹性(超时、重发、熔断等)等功能的管理系统,它提供了一系列rules api,允许运维人员指定一系列高级的流量管理规则。Pilot负责将我们的配置转换并写入到每个sidecar(Enovy)。
Mixer混合了各种策略以及后端数据采集或遥测系统的适配器,从而实现了前端Proxy与后端系统的隔离与汇合。Mixer是一个灵活的插件模型,它一端连着Envoy,同时我们可以将日志、监控、遥测等各种系统“插入”到Mixer的另一端中,从而得到我们想要的数据或结果。
Citadel管理着集群的密钥和证书,是集群的安全部门。
类别 | 功能 | 说明 |
---|---|---|
流量管理 | 请求路由 | A/B测试、金丝雀发布等,包括对集群出入口、及集群内部的流量的控制。比如某应用新版本发布,可以配置为5%的流量流向新版本,95%的给旧版本 |
流量转移 | 与上一条请求路由类似,可以平滑的将流量从旧版本转移到新版本上 | |
负载均衡 | 目前支持3种方式,轮询、随机和带权重的最少请求 | |
服务发现 | 带心跳的健康检查,失败率超标的Pod移出负载均衡池 | |
故障处理 | 超时、重发、熔断、上游并发请求或下游连接数限制等 | |
微调 | 支持用特殊的请求头参数,覆盖默认的超时、重发值 | |
故障注入 | 由Enovy在正常的集群中人为注入故障,比如TCP包损坏或延迟、HTTP错误码等,支持按百分比注入,比如给10%的流向服务A的请求包增加5秒延迟 | |
多重匹配 | 上述规则的配置,支持按多种条件匹配,且支持and或or的方式匹配多条规则 | |
Gateway | 接管集群入口的流量,替代了Ingress,从而对入口流量执行其他规则 | |
Service Entry | 接管集群内部访问外部服务的流量,从而对出口流量执行一些规则 | |
镜像 | 支持将特定的流量镜像到服务路径之外,而不影响主服务路径的正常执行 | |
安全 | 命名空间访问控制 | 支持配置某命名空间的所有或个别服务可以被其他命名空间访问 |
服务级别访问控制 | 允许或禁止访问某个服务 | |
双向TLS | HTTPS加密传输 | |
其他安全策略 | ||
策略 | 速率限制 | 比如限制每秒的请求次数 |
黑白名单 | 支持基于IP或属性的黑名单、白名单 | |
遥测 | 日志收集 | 支持将Prometheus、Jaeger等系统插入Mixer,从而完成数据的采集 |
指标采集 | ||
分布式追踪 |
Istio 1.5.1 性能总结
Istio 负载测试网格包含了 1000 个服务和 2000 个 sidecar,全网格范围内,QPS 为 70,000。 在使用 Istio 1.5.1 运行测试后,我们得到了如下结果:
通过代理的 QPS 有 1000 时,Envoy 使用了 0.5 vCPU 和 50 MB 内存。
网格总的 QPS 为 1000 时,istio-telemetry
服务使用了 0.6 vCPU。
Pilot 使用了 1 vCPU 和 1.5 GB 内存。
90% 的情况 Envoy 代理只增加了 6.3 ms 的延迟。
kube-proxy
组件的支持,通过为更接近微服务应用层的抽象,管理服务间的流量、安全性和可观察性。
Istio复⽤了Kubernetes Service的定义,在实现上进⾏了更细粒度的控制。
Istio的服务发现就是从 Kube-apiserver中获取 Service和Endpoint,然后将其转换成 Istio服务模型的 Service 和ServiceInstance,但是其数据⾯组件不再是 Kube-proxy,⽽是在每个Pod ⾥部署的 Sidecar,也可以将其看作每个服务实例的 Proxy。这样,Proxy 的粒度就更细了,和服务实例的联系也更紧密了,可以做更多更细粒度的服务治理。
蚂蚁金服的实战案例
蚂蚁金服在2019年双十一的成功大规模落地为 Service Mesh
首先是自研的SOFAMosn替代了Envoy,支持了更多的协议SOFARPC/Dubbo/WebService。优化SOFAMesh避免了大量不必要的花销。
连接迁移的核心主要是内核 Socket 的迁移和应用数据的迁移,连接不断,对用户无感知。
参考文档 蚂蚁金服 Service Mesh 大规模落地系列 浏览顺序 核心->RPC->消息→。。。
其他实战案例分享 https://tech.antfin.com/community/activities/1056
五、学习资料分享
github地址 https://github.com/istio/istio
官方文档 https://istio.io/zh/
服务网格中方社区 https://www.servicemesher.com/
推荐书籍《云原生服务网格Istio:原理、实践、架构与源码解》 链接:https://pan.baidu.com/s/12hbPHaRMDD752xOhTEuKEQ 密码:2e59
教学视频 部署落地+业务迁移 玩转k8s进阶与企业级实践技能 链接:https://pan.baidu.com/s/1H4O7C_DHOWHB3nVAATCHQQ 密码:4xh7
华为云直播视频 istio入门实训课 链接:https://pan.baidu.com/s/1jr8hn77Bbm56WUAeg8_hSg 密码:vqqh
IBM开源技术微课堂 istio系列 https://mediacenter.ibm.com/media/1_5j53erez