By Kubernetes + Istio flow control to achieve the gray release, the main demonstration of heavy traffic rights achieved through blue-green, canary achieved through a custom http header
Preparing the environment
k8s and istio do not want to buy their own equipment, then you can pay by volume of the cluster in the cloud, throw-delete, recommended Huawei cloud.
The code used in the project
With springboot + springcloud feign strongly typed do rest call, put the github
https://github.com/assionyang/istio-test.git
Structure Description Code
istio-service-union # aggregation services, call the user to test the service, but also as an entrance
| -Dockerfile #dockerfile
istio #-Service-user customer service, demo version for switching
| -Dockerfile #dockerfile
istio-Service-user -api # class library, use feign client exposure and dto, union-API services depend on the User
K8S # K8S & istio publish directory
| - config
| - istio-service-union.yaml # of Union services ConfigMap
| - istio-the User-service-v1 .yaml # user service v1 version ConfigMap
| - istio the User-service-v2-service version of the User v2.yaml # ConfigMap
| - istio-service-free status of Union-deployment.yaml #union released
| - istio-service-union- service .yaml # union services
| - istio-service-gateway.yaml # ingress gateway, external exposure of Union
| - istio-the User-service-Deployment-v1.yaml # v1 version of the User stateless released
| - istio-service-user- deployment-v2.yaml # user version v2 stateless released
| - istio-service-user- service .yaml # user service
| - istio-service-user- virtualservice-v1.yaml # user is routed to the v1 version
| - istio-service-user- virtualservice-v2.yaml # user is routed to the v2 version
| - istio-service-user- virtualservice-weight. yaml # user to route traffic weights
| - istio-service-user- virtualservice-jsq.yaml # user routing Canary
Test Procedure
1) lay user, docker iamge union of two projects and upload image warehouse
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) Create a configuration item 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) publishing load, services, goals rule, gateway
kubectl apply -f istio-service-user -deployment-v1.yaml #user service v1 version and load the target rule kubectl apply -f istio-service-user -deployment-v2.yaml #user service load v2 version of the target rule kubectl apply -f istio-service-user-service.yaml #user service kubectl apply -f istio-service-union -deployment.yaml #union load kubectl apply -f istio-service-union -service.yaml #union service kubectl apply -f istio-service-union-gateway.yaml #union gateway, ingressgateway
The first step we released applications and services, to create a default rule, and the endpoint of external exposure through ingressgateway, this rule is when the default target rotational training services v1 and v2 user version, we can detect changes in the test several times
{"userVersion":"v1","userException":""}
{"userVersion":"v2","userException":""}
{"userVersion":"v1","userException":""}
{"userVersion":"v2","userException":""}
……
4) Create a default route
kubectl apply -f istio-service-union-virtualservice-v1.yaml # using version v1
Access test results and found that all versions v1
{"userVersion":"v1","userException":""}
{"userVersion":"v1","userException":""}
{"userVersion":"v1","userException":""}
{"userVersion":"v1","userException":""}
kubectl apply -f istio-service-union-virtualservice-v2.yaml # using version v2
Access test results and found that all v2 version
{"userVersion":"v2","userException":""}
{"userVersion":"v2","userException":""}
{"userVersion":"v2","userException":""}
{"userVersion":"v2","userException":""}
5) Traffic weights
kubectl apply -f istio-service-union-virtualservice-weight.yaml # weights using traffic routes, v1 70% by traffic, v2 min 30% Flow
Access test results, about the same
{"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) Canary released
V1 version of the demo is to visit with the head set according to request access to lab = assion v2 version, no such request headers.
Note: Because we are using a feign, union calls the user through feign service will not bring the original header, we need to do some feign transparent transmission of the header information to pass along
kubectl apply -f istio-service-union-virtualservice-jsq.yaml # using canary release, http header head lab = assion access user v2 version, without access user v1 version
We can look postman test results
