0%

Istio教程03-流量控制和规则术语

1. 版本控制

1.1 v1 版本服务

  • 向集群外部公开catalog服务
qq306351-4
  • 将流量路由到catalog服务。
qq306351-7 1714568483465

1.2 所有流量路由到 v1版本

此时我们需要发布v2版本,发布前,我们先将所有流量路由到catalog服务的v1版本。

我们需要给Istio一个关于如何识别哪些工作负载是v1、哪些是v2的提示,就是增加目标规则。

1714568622447 1714568641690

更新VirtualService,将所有流量路由到catalog的v1版本

1714568732385

1.3 将特定请求路由到v2版本

我们希望将包含HTTP头x-istio-cohort:internal的任何流量路由到catalog服务的v2版本。

1714568829496

1.4 金丝雀发布

我们将研究另一种“金丝雀发布”或增量发布的方法,指定一个10%到v2的路由权重:所有流向catalog的流量的10%将流向v2,而90%的流量仍将流向v1。

1714569073043

2. 其他控制

2.1 流量镜像

Istio支持流量镜像,这比蓝绿和灰色发布方法更能减少部署和发布的风险。

1714569504666
  1. 通过这个VirtualService定义,我们将100%的实时流量路由到catalog服务的v1,但也将流量镜像到v2。
  2. 镜像是通过“即发即忘”的方式完成的,即创建请求的副本并将其发送到镜像集群(在本例中是catalog的v2)中。这个镜像请求不会影响真正的请求,因为执行镜像的Istio代理会忽略来自镜像集群的任何响应(成功/失败)。

2.2 路由到集群外部的服务(ServiceEntry)

ServiceEntry是Istio中对网格外的服务的推荐使用方式,当然也可以选择不做治理,直接让网格内的服务访问网格外的服务。

在默认情况下,Istio允许任何流量离开服务网格。为了安全,可以将Istio的默认值从ALLOW_ANY改为REGISTRY_ONLY。这意味着只有在服务网格注册表中明确将流量列入白名单时,才允许此流量离开网格。

拒绝流量流出

我们将用户连接到一个在线论坛,该论坛是在服务网格集群之外构建和部署的。在本例中,此论坛位于URL jsonplaceholder.typicode.com。

1714569811509 1714569812709

ServiceEntry允许网格内部的服务访问外部的服务。

当将出站流量设置为REGISTRY_ONLY时,ServiceEntry可以允许网格内部的服务访问外部的服务。

1714569947647

这个ServiceEntry资源在Istio的服务注册表中插入了一个条目,它明确地表明,允许网格中的客户端使用jsonplaceholder.typicode.com主机调用JSON Placeholder。

45739_158_1

3. 流量管理术语理解

老王开了一家家娱乐场所,天上人间,为了气派老王花重金百万打造了一个青铜大门 istio-ingressgateway。

3.1 Gateway

特点:spec.servers

这么气派的大门必须找个 180 以上的保安gateway看门,保安的指责比较的简单明了,按摩(anmo.com)的放进来,洗浴(xiyu.com)的放进来,白嫖(baipiao.com)的请出去。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: baoan
namespace: tianshangrenjian
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "xiyu.com"
- "anmo.com"

3.2 VirtualService

特点:spec.hosts

每个客人都有自己喜欢的技师,大堂经理virtual service客客气气的安排着。如果你想找个白富美给您按摩,只需要告诉大堂经理virtual service ,anmo.com/baifumei,他就会客客气气告诉您上3楼找69号房间(v1)。如果你找矮矬穷anmo.com/aicuoqiong请到3楼96房间(v2)。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: tianshangrenjian-rule
namespace: tianshangrenjian
spec:
hosts:
- anmo.com
gateways:
- baoan
http:
- name: "baifumei"
match:
- uri:
prefix: "/baifumei"
route:
- destination:
host: anmo-service
subset: v1
- name: "aicuoqiong"
route:
- destination:
host: anmo-service
subset: v2

3.3 DestinationRule

特点:spec.host

告诉每个技师提前到哪个房间迎接客人,就是destination rule。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: reviews-destination
namespace: tianshangrenjian
spec:
host: anmo-svc
subsets:
- name: v1
labels:
sanwei: 362436
- name: v2
labels:
sanwei: 181818

就这样生意红红火火。。。大门istio-ingressgateway(你从哪里进来),看大门的istio gateway(你能不能进来),大堂经理virtual service(进来后去哪),destination rule(房间号)。

不同配置资源之间的关系

3.4 VirtualService 和 DestinationRule 理解

114_1
  1. VirtualService也是一个虚拟Service,描述的是满足什么条件的流量被哪个后端处理。可以对应这样一个Restful服务,每个路由规则都对应其中Resource中的资源匹配表达式。只是在VirtualService中,这个匹配条件不仅仅是路径方法的匹配,还是更开放的Match条件。
  2. 而DestinationRule描述的是这个请求到达某个后端后怎么去处理,即所谓目标的规则,类似以上Restful服务端代码 addForecast()和getForecast()方法内的处理逻辑。
  3. DestinationRule定义了满足路由规则的流量到达后端后的访问策略,从而理解负载均衡和熔断等策略为什么被定义在DestinationRule上。

3.5 Gateway 和 VirtualService 的结合

Gateway只做四层到六层的端口、TLS配置等基本功能,VirtualService则定义七层路由等丰富内容。

VirtualService 的 gateways 字段

场景1:服务只是在网格内访问的,这是最主要的场景。gateways字段可以省略,实际上在VirtualService的定义中都不会出现这个字段。一切都很正常,定义的规则作用到网格内的Sidecar。

场景2:服务只是在网格外访问的。配置要关联的Gateway,表示对应Gateway进来的流量执行在这个VirtualService上定义的流量规则。

场景3:在服务网格内和网格外都需要访问。这里要给这个数组字段至少写两个元素,一个是外部访问的Gateway,另一个是保留关键字“mesh”。使用中的常见问题是忘了配置“mesh”这个常量而导致错误。

我们很容易认为场景3是场景1和场景2的叠加,只需在内部访问的基础上添加一个可用于外部访问的Gateway。

4. 参考文档

可以加首页作者微信,咨询相关问题!