k8s+istio:流量控制之灰度发布 – Python量化投资

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

通过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测试一下看下效果

 

https://www.cnblogs.com/assion/p/11326669.html

「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论