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, metal-v2
and 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 metal
and 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.
v2 Services
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 VirtualNode
s for each new version, as well as apply an update to our existing VirtualRouter
s 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
.
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.