Kubernetes+Istio:流量控制之灰度发布
准备环境
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":""}
7)金丝雀发布
演示是跟据请求头设置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测试一下看下效果