k8s+istio:流量控制之灰度发布

悠悠 2023-08-17 15:18 154阅读 0赞

**通过Kubernetes+Istio的流量控制实现灰度发布，主要演示通过流量权重实现蓝绿，通过http自定义头实现金丝雀**

**准备环境**

k8s和istio不想自己装的话可以在云上买个按量付费集群，用完即删，推荐华为云。

**项目中用到的代码**

用的springboot+springcloud feign做rest强类型调用，放到github了

https://github.com/assionyang/istio-test.git

**代码结构说明**

istio-service-union   #聚合服务项目，用来测试调用user服务，也做为入口
    |-Dockerfile  #dockerfile
    istio-service-user  #用户服务，用来演示版本切换
    |-Dockerfile  #dockerfile
    istio-service-user-api #类库，使用feign暴露client与dto,union服务依赖user-api
    k8s #k8s&istio发布文件目录
    |-config
       |- istio-service-union.yaml   # union服务ConfigMap
       |- istio-service-user-v1.yaml # user服务v1版本ConfigMap
       |- istio-service-user-v2.yaml # user服务v2版本ConfigMap
    |- istio-service-union-deployment.yaml #union无状态发布
    |- istio-service-union-service.yaml # union服务
    |- istio-service-gateway.yaml # ingress网关，对外暴露union
    |- istio-service-user-deployment-v1.yaml # user版本v1无状态发布
    |- istio-service-user-deployment-v2.yaml # user版本v2无状态发布
    |- istio-service-user-service.yaml # user服务
    |- istio-service-user-virtualservice-v1.yaml #  user路由到v1版
    |- istio-service-user-virtualservice-v2.yaml # user路由到v2版
    |- istio-service-user-virtualservice-weight.yaml # user路由流量权重
    |- istio-service-user-virtualservice-jsq.yaml # user路由金丝雀

**测试步骤**

**1）打好user、union两个项目的docker iamge并上传镜像仓库**

docker build -t istio-service-union:v1 .
    docker tag istio-service-union:v1 swr.ap-southeast-1.myhuaweicloud.com/mk-develop/istio-service-union:v1
    docker push swr.ap-southeast-1.myhuaweicloud.com/mk-develop/istio-service-union:v1
    docker build -t istio-service-user:v1 .
    docker tag istio-service-user:v1 swr.ap-southeast-1.myhuaweicloud.com/mk-develop/istio-service-user:v1
    docker push swr.ap-southeast-1.myhuaweicloud.com/mk-develop/istio-service-user:v1

**2) 创建ConfigMap配置项**

kubectl apply -f config/istio-service-user-v1.yaml
    kubectl apply -f config/istio-service-user-v2.yaml
    kubectl apply -f config/istio-service-union.yaml

**3)发布负载、服务、目标规则、网关**

kubectl apply -f istio-service-user-deployment-v1.yaml #user服务v1版负载与目标规则
    kubectl apply -f istio-service-user-deployment-v2.yaml #user服务v2版负载与目标规则
    kubectl apply -f istio-service-user-service.yaml #user服务
    kubectl apply -f istio-service-union-deployment.yaml #union负载
    kubectl apply -f istio-service-union-service.yaml #union服务
    kubectl apply -f istio-service-union-gateway.yaml #union网关,ingressgateway

第一步我们发布了应用与服务，创建了默认规则，并且通过ingressgateway对外暴露了endpoint，这时候默认的目标规则是轮训user服务的v1和v2版本，我们可以测试几次发现变化

{"userVersion":"v1","userException":""}
    {"userVersion":"v2","userException":""}
    {"userVersion":"v1","userException":""}
    {"userVersion":"v2","userException":""}
    ……

** 4)创建默认路由**

kubectl apply -f istio-service-union-virtualservice-v1.yaml #使用v1版本

测试访问结果，发现全部是v1版本

{"userVersion":"v1","userException":""}
    {"userVersion":"v1","userException":""}
    {"userVersion":"v1","userException":""}
    {"userVersion":"v1","userException":""}

kubectl apply -f istio-service-union-virtualservice-v2.yaml #使用v2版本

测试访问结果，发现全部是v2版本

{"userVersion":"v2","userException":""}
    {"userVersion":"v2","userException":""}
    {"userVersion":"v2","userException":""}
    {"userVersion":"v2","userException":""}

**5）流量权重**

kubectl apply -f istio-service-union-virtualservice-weight.yaml #使用流量权重路由，v1分70%流量，v2分30%流量

测试访问结果，大致相同

{"userVersion":"v1","userException":""}
    {"userVersion":"v1","userException":""}
    {"userVersion":"v1","userException":""}
    {"userVersion":"v2","userException":""}
    {"userVersion":"v1","userException":""}
    {"userVersion":"v2","userException":""} {"userVersion":"v1","userException":""} {"userVersion":"v1","userException":""} {"userVersion":"v2","userException":""} {"userVersion":"v1","userException":""}

**6)金丝雀发布**

演示是跟据请求头设置lab=assion来访问v2版本，无此请求头访问v1版本。

注：因为我们使用的是feign，union通过feign调用user服务都不会带上原始header的，需要做一下feign的透传把header信息传递下去

kubectl apply -f istio-service-union-virtualservice-jsq.yaml #使用金丝雀发布，http header头lab=assion访问user v2版，不带访问user v1版

我们可以用postman测试一下看下效果

![51170-20190809133055464-742801107.png][]

![51170-20190809133132709-1025487290.png][]

转载于:https://www.cnblogs.com/assion/p/11326669.html

[51170-20190809133055464-742801107.png]: /images/20230810/3efbd52ef07a44099b7620d812080f6c.png
[51170-20190809133132709-1025487290.png]: /images/20230810/7ecdfe8a580545eb8633004d7ff5f3e5.png

发表评论取消回复

表情：

评论列表（有 0 条评论，154人围观）

还没有评论，来说两句吧...

相关阅读

相关什么是灰度发布？灰度发布几种类型

一、方案背景介绍 1. 什么是灰度发布灰度发布是指在黑和白(0和1)之间，能够平滑过渡的一种发布方式。 AB test就是一种灰度发布方式，指为产品已发布A版

偏执的太偏执、/ 2024年03月31日 03:40/ 0 赞/ 96 阅读

相关 k8s+istio:流量控制之灰度发布

通过Kubernetes+Istio的流量控制实现灰度发布，主要演示通过流量权重实现蓝绿，通过http自定义头实现金丝雀准备环境 k8s和istio不想自己装的话可

悠悠/ 2023年08月17日 15:18/ 0 赞/ 155 阅读

相关【go-micro】微服务协作开发、灰度发布之流量染色

协作开发与灰度发布是微服务框架在流量治理能力方面的两个体现，本文结合go-micro实践对流量进行染色，实现开发环境的多分支协作，以及生产环境的灰度发布。场景开

绝地灬酷狼/ 2023年06月21日 03:52/ 0 赞/ 184 阅读

相关 Sentinel（五）之流量控制

转载自 [流量控制][Link 1] 概述流量控制（flow control），其原理是监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制

蔚落/ 2023年01月08日 05:27/ 0 赞/ 155 阅读

相关 springcloud 灰度发布

线上部署项目的时候，各个微服务不只部署一份，有时候，为了测试，可以进行灰度发布，先测试新的服务是否可用 1.微服务之间调用微服务A 调用微服务B，灰度规则定义在数据库中

谁践踏了优雅/ 2022年12月23日 14:23/ 0 赞/ 233 阅读

相关 K8S基于Rancher的灰度发布

本文主要介绍K8S基于ingress实现的灰度发布，常规操作k8s我们需要编写 yml 文件使用命令行来操作，UI和可视化是一个很方便的东西。本文基于Rancher来实现金丝雀

清疚/ 2022年12月20日 03:27/ 0 赞/ 445 阅读

相关 k8s基于Ingress-nginx实现灰度发布

微信公众号搜索 DevOps和k8s全栈技术，即可关注公众号，也可扫描文章最后的二维码关注公众号，每天会分享技术文章供大家阅读参考哈~ 前言 Ingress-Ng

亦凉/ 2022年11月26日 07:44/ 0 赞/ 224 阅读

相关 Knative 基于流量的灰度发布和自动弹性实践

![头图.png][.png] 作者| 李鹏（元毅）来源 | [阿里巴巴云原生公众号][Link 1] Knative Knative 提供了基于流量的自动扩缩

墨蓝/ 2022年11月16日 05:57/ 0 赞/ 183 阅读

相关灰度发布(金丝雀发布)

Gmail Labs是一个新特性橱窗，用户可以自己选择一些未正式发布的新特性进行体验，不喜欢可以关闭，在这个过程中，吃了螃蟹，也当了Google的小白鼠。这个做法比传统的灰

雨点打透心脏的1/2处/ 2022年05月26日 02:12/ 0 赞/ 244 阅读

相关 k8s（五）、微服务框架istio流量策略控制

前言承接上节[k8s（四）、微服务框架istio安装测试][k8s_istio] 本节实验通过在k8s上部署istio，实现微服务的基础功能。其中会涉及到服务的限流

Myth丶恋晨/ 2022年05月23日 09:22/ 0 赞/ 683 阅读