官方文档:Istio / 流量转移
前提条件:
- 微服务使用deployment+service部署到集群
1、配置命名空间自动注入sidecar
1 | kubectl label namespace default istio-injection=enabled |
我这里使用istio官方提供的bookinfo程序演示
2、部署bookinfo示例程序
1 | cat > bookinfo.yaml << EOF |
1 | kubectl apply -f bookinfo.yaml |
所有pod运行时2/2即为部署成功,sidecar也以容器形式注入到pod内。
3、部署网关
1 | cat > bookinfo-gateway.yaml << EOF |
1 | kubectl apply -f bookinfo-gateway.yaml |
4、部署前端virtual service
这里的前端指的时发送请求的服务,可以是中间件也可以是后端的接口,我这里使用productpage
服务
1 | cat > virtual-service-productpage.yaml << EOF |
1 | kubectl apply -f virtual-service-productpage.yaml |
5、访问
通过istio-ingress服务的外部IP访问http://10.20.12.190/productpage
,如果没有部署MetalLB可以使用nodeIP+30271(istio-ingress服务80端口的映射端口)访问http://10.20.12.10:30271/productpage
访问后刷新页面,发现reviews服务时每次刷新都会请求不同的版本,这是因为后端服务还没有被纳管,此时的请求是通过productpage
请求reviews服务的service返回的
6、创建目标规则
1 | cat > destination-rule-all.yaml << EOF |
1 | kubectl apply -f destination-rule-all.yaml |
此时将所有服务都设置了规则,按照pod label为version 的识别出来,这一步并不会对请求发生变化,这是为了方便后面调整变化时使用的。
7、创建后端virtual service
1 | cat > virtual-service-all-v1.yaml <<EOF |
1 | kubectl apply -f virtual-service-all-v1.yaml |
此时后端服务都被istio纳管,并将路由目标指向v1版本,现在不管怎么请求,reviews服务都是v1版本
8、灰度发布
之前的操作都是为了能模拟一个正常使用的业务,并将服务通过istio的virtual service管理,接下来才是灰度发布的操作
要升级Review服务从v1到v2版本,首先部署这个deployment,这个demo中已经部署了,并且之前访问时也看到了
1 | cat > virtual-service-reviews.yaml << EOF |
1 | kubectl apply -f virtual-service-reviews.yaml |
再次刷新页面模拟请求,发现80%的流量在v1,20%流量分配到v2
在kiali中也可以看到流量分配情况
运行一段时间再次调整v2流量的比例直到100%流量到v2,这时可以下线v1版本。