Canary Testing with a v2
A canary release is a method of slowly exposing a new version of software. The theory behind it is that by serving the new version of the software initially to say, 5% of requests, if there is a problem, the problem only impacts a very small percentage of users before its discovered and rolled back.
So now back to our DJ App scenario,
jazz-v2 services are out, and they now include the city each artist is from in the response.
Let’s see how we can release these new versions in a canary fashion using
AWS App Mesh.
When we’re complete, requests to
jazz will be distributed in a weighted fashion to both the v1 and v2 versions, with 95% going to the current prod v1 and 5% going to our release candidate v2.
YAML for this step can be found in the
3_canary_new_version directory. First, let’s look at the new v2 deployments and services. Below is jazz-v2, for example.
You can see our exciting new feature enhancement is ready to deploy.
Canary for v2
If we deploy our new service versions into
prod right now, we will not have any traffic routed to them. To achieve this, we need to define
VirtualNodes for each new version, as well as apply an update to our existing
VirtualRouters to send 5% of traffic to the new version.
We will use App Mesh’s
weightedTargets route feature to configure this logic.
With this, our configuration changes are complete and ready to deploy. Apply these changes now with
kubectl apply -f 3_canary_new_version/v2_app.yaml
Verify the status of your new and existing Kubernetes objects.
kubectl -n prod get deployments,services,virtualnodes,virtualrouters
Dig in a little deeper to see the updated
Route configuration for the ‘jazz-router’ virtual router.
kubectl -n prod describe virtualrouters jazz-router
Here you can see that it is configured to route 95% of traffic to the v1 version of the service, and 5% to v2 for canary testing. Let’s test this out.