Canary deployment is related to dark launches or friends-and-family testing, in which only a few people are given access to new features without their knowledge. Let's apply the principle of traffic shifting to a canary deployment:

1. You can configure a percentage of traffic for each subset using Consul's service-splitter primitive. An example of a service-splitter can be seen in the following code, in which 99% of the traffic is routed to subset v1, while the other 1% of the traffic is routed to subset v2:

# Script: 14-service-splitter-canary.hcl

kind = "service-splitter",
name = "api"

splits = [
  {
    weight = 99,
    service_subset = "v1"
  },
  {
    weight = 1,
    service_subset = "v2"
  }
]

2. Create service-splitter for the Consul service api using the Consul CLI:

$ consul config write 14-service-splitter-canary.hcl

$ consul config list -kind service-splitter
api

3. Repeat the same curl command 200 times. You will notice that api-v2 is only called 1% of the time:

$ curl -s http://localhost:30145?[1-200] | grep "Pod Name.*api-v1"
$ curl -s http://localhost:30145?[1-200] | grep "Pod Name.*api-v2"
...

Pod Name : api-v1-7fcf5d98d4-tgqrk
Pod Name : api-v1-7fcf5d98d4-tgqrk
Pod Name : api-v2-5d64d5f8ff-zlcp6
Pod Name : api-v1-7fcf5d98d4-tgqrk

...

The preceding code is an example of a canary deployment in which a very small percentage of traffic is shifted to v2 of the service. Next, we will learn how to split traffic in a round-robin fashion.