ServiceMesh、SideCar和Istio

ServiceMesh、SideCar和Istio,第1张

ServiceMesh、SideCar和Istio Service Mesh简介

Service Mesh直译过来就是服务网格,而他的架构就是一个个微服务组成的网络。

Sidecar简介

Service Mesh中的节点就是Sidecar节点。
sidecar直译过来就是这种摩托车,意为业务容器和非业务容器分离,如agent服务全部部署在非业务容器中。


sidecar proxy的作用和好处有很多:

sidecar proxy能接管对应服务的入流量和出流量,所以sidecar proxy是有流量管理的功能,有了这个能力,可以做太多太多的事情了,如放火、熔断、限流、降级。微服务架构中以前有公共库、sdk等部署在sidecar proxy容器中。服务注册与发现可部署在sidecar proxy容器中。与业务容器分离后,非业务容器中的程序不会影响到业务容器,资源能够隔离,监控系统也能部署在 sidecar proxy容器中。与业务容器分离后,业务容器可以专注于业务,也无需让开发人员适配繁多的sdk、agent、中间件等。…

缺点:

sidecar模式中,每个Pod都引入了一个新的容器,成本会上升。sidecar模式中,通信通过代理实现,所以会增加系统的开销。

一个个sidecar节点就组成了Service Mesh服务网格。

Istio简介

Service Mesh和Sidecar都是指导思想,下面介绍真正实践的Istio。

Envoy 是由Lyft公司 推出、基于C++ 11编写的ServiceMesh实现,但它专注于如何实现Proxy,并没有很好的控制面。所以 Google 和 IBM 两位巨人联合 Lyft 的合作开源项目,基于Envoy打造了Istio。

Istio中文社区:https://istio.cn/
K8s关于Istio的博客:https://www.kubernetes.org.cn/tags/istio

Istio架构如下图所示:

Envoy: 扮演sidecar的功能,协调服务网格中所有服务的出入站流量,并提供服务发现、负载均衡、限流熔断等能力,还可以收集大量与流量相关的性能指标。

Pilot: 负责部署在service mesh中的Envoy实例的生命周期管理。本质上是负责流量管理和控制,是将流量和基础设施扩展解耦,这是Istio的核心。感性上,可以把Pilot看做是管理sidecar的sidecar, 但是这个特殊的sidacar并不承载任何业务流量。Pilot让运维人员通过Pilot指定它们希望流量遵循什么规则,而不是哪些特定的pod/VM应该接收流量。比如 A/B 测试和金丝雀Canary测试。

Mixer: Mixer在应用程序代码和基础架构后端之间提供通用中介层。它的设计将策略决策移出应用层,用运维人员能够控制的配置取而代之。应用程序代码不再将应用程序代码与特定后端集成在一起,而是与Mixer进行相当简单的集成,然后Mixer负责与后端系统连接。也就是说,Mixer可以认为是其他后端基础设施(如数据库、监控、日志、配额等)的sidecar proxy。

Istio-Auth: 自动为服务之间的调用提供认证、授权和加密。

参考文档:

https://istio.cn/https://www.kubernetes.org.cn/tags/istiohttps://blog.csdn.net/weixin_40274679/article/details/106232119https://blog.csdn.net/define_us/article/details/84812729

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5712497.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-17
下一篇 2022-12-17

发表评论

登录后才能评论

评论列表(0条)

保存