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