社区微信群开通啦,扫一扫抢先加入社区官方微信群
社区微信群
服务网格(Service Mesh)这个术语通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长,服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求,例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。
Istio 提供了一个完整的解决方案,通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。
Istio 提供一种简单的方式来为已部署的服务建立网络,该网络具有负载均衡、服务间认证、监控等功能,只需要对服务的代码进行一点或不需要做任何改动。想要让服务支持 Istio,只需要在您的环境中部署一个特殊的 sidecar 代理,使用 Istio 控制平面功能配置和管理代理,拦截微服务之间的所有网络通信:
Istio 服务网格逻辑上分为数据平面和控制平面。
Pilot 负责管理通过 Istio 服务网格发布的 Envoy 实例的生命周期。
部署一个样例应用,它由四个单独的微服务构成,用来演示多种 Istio 特性。这个应用模仿在线书店的一个分类,显示一本书的信息。页面上会显示一本书的描述,书籍的细节(ISBN、页数等),以及关于这本书的一些评论。
Bookinfo 应用分为四个单独的微服务:
reviews 微服务有 3 个版本:
把 Envoy sidecar 注入到每个服务之中。部署结果如下图所示:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v1
abort故障注入
我们可以看到对于版本v1的路由规则里多了一条fault对象。这个fault对象中,则包含了设定的故障属性。可以解读为,v1版本添加abort故障并且设定返回的http状态码为501,percent设定为100这意味着所有访问v1的请求都会收到501的http响应,显而易见如果这里设成50则只有一半的请求会收到501响应,另一半则会收到正常的响应
延时故障注入
我们已经给v1版本注入了中断故障,现在我们给v4版本注入延时故障,设定时间延迟为2秒,并且所有访问v4的请求都会有2秒的延迟
其他例子1
在这个例子中,当cookie满足user=vip时会触发延时故障,2秒延时后访问v4版本,当user=svip的时候则会触发中断故障,当cookie不满足以上两个条件时,则可以正常访问v1版本
其他例子2
在这个例子中不论cookie符合vip还是svip,亦或是都不符合两个条件,都可以正常的访问到v1版本。这是由于route对象放在了第一个,没有任何匹配条件,不管cookie值是什么都“满足条件”,所以所有的流量不加任何处理直接会流向版本v1,这里要特殊提醒下,如若自己手动添加故障注入一定要注意相对顺序,否则可能不会出现你想设定的结果
其他例子3
这个virtual service中我们对同一个版本注入了两个不同的故障,满足任何一个条件都可以触发相应的故障,如果所有条件都不满足则会默认的正常访问v1版本。那么问题来了,如果我没有配置最后一条route,出现了一条既不符合中断故障匹配条件,也不符合延时故障匹配条件,请求会走向哪里呢?对于这种yaml设置,结果异常的简单直白,如果请求不符合任何条件,则会直接获得404的响应,不会自动流入任何其他的版本
如何使用 Istio Mixer 和 Istio sidecar 获取指标和日志,并在不同的服务间进行追踪
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!