Istio canary routing separates traffic share from replica count

A canary rollout needs to control exposure to a new version. Replica counts are an indirect way to do that. If a Service treats every instance as an equivalent destination, changing the number of instances also changes the version mix receiving traffic. The June 14 Istio canary guide makes the case for giving routing policy and replica management separate responsibilities.

The original published revision uses two Deployments for a helloworld service. Both carry the application's common label, and each carries a version label. Istio routes requests among those versions using configured weights. Kubernetes can then adjust their replica counts without using those counts as the traffic policy.

I find that separation useful because capacity and exposure answer different questions. An application may need more instances to serve its assigned traffic without needing a larger share of users. Encoding both decisions in one replica ratio makes independent changes unnecessarily difficult.

Replica ratios approximate a version split

The guide first describes a plain Kubernetes arrangement with two Deployments sharing a Service selector. Nine replicas of the existing version and one of the canary provide a nominal ten-percent canary share under the example's equal-instance distribution model. A small exposure percentage consequently requires a large total number of replicas.

Its one-percent example makes the arithmetic visible. One canary instance among one hundred instances represents one percent of that pool. The required number comes from the distribution mechanism, not from a demonstration that the application needs one hundred instances of capacity. A low-volume application can therefore need many replicas merely to express a small ratio this way.

Independent autoscalers complicate that arrangement. Each Deployment responds to its own observed load, so the ratio can drift as the versions scale differently. The article does not establish that Kubernetes autoscaling is unusable in general. It identifies the problem with using an independently changing replica ratio as the desired traffic ratio.

A route rule identifies versions directly

The original guide configures the following rule through istioctl create. This is the route-rule format used in that published example, with version tags identifying the two destinations within the service.

type: route-rule
name: helloworld-default
spec:
  destination: helloworld.default.svc.cluster.local
  route:
    - tags:
        version: v1
      weight: 90
    - tags:
        version: v2
      weight: 10

The rule expresses a ninety-to-ten request distribution. It assumes the two versions are deployed in an Istio-enabled cluster and have the corresponding labels. The routing declaration does not create either application's Deployment or supply the capacity needed to serve its assigned requests.

This changes which object expresses the rollout decision. Adjusting a version's exposure means changing the routing weights, while adjusting its capacity means changing or autoscaling its Deployment. The two mechanisms still affect each other through load, but they no longer use the same configuration value.

Autoscaling responds to the routed workload

The demonstration attaches a horizontal Pod autoscaler to each Deployment, with a fifty-percent CPU target and a range of one to ten replicas. Under the ninety-to-ten routing rule, the version receiving most requests scales to more replicas. That is the intended response to differing demand, without a corresponding change in the configured request split.

When the rule changes to an even split, demand shifts between versions. The example shows the old version scaling down and the canary scaling up after a delay. Routing initiates the exposure change, and autoscaling responds to its consequences. The autoscalers do not decide which version should receive more of the application's users.

When load stops, both Deployments can return to their minimum of one replica. The routing rule remains in effect. This is the specific benefit over holding a nine-to-one replica ratio at low traffic, because minimum capacity and the desired version share can now be expressed independently.

Request selection can define the experiment

The guide also demonstrates a higher-precedence rule matching an email pattern in a cookie. It sends half of the matching traffic to the canary, while a default rule sends other traffic to the existing version. The canary audience can therefore be a selected group instead of an arbitrary fraction of all requests.

A routing match is a request-selection mechanism. The example's cookie pattern identifies which requests receive the experimental split, and the fallback rule describes what happens to the rest. That configuration states the experiment's scope more directly than choosing a number of Pods.

The example assigns the selective rule a precedence of two. That lets the narrower match take priority over the default destination rule. Both declarations are necessary to describe the intended arrangement, because the selective rule alone does not state the unchanged routing for every other request.

My judgment of this feature rests on that explicit scope. The operator controls exposure through a route rule, and each Deployment's autoscaler supplies capacity in response to the work it receives. The original example ends with both versions able to run at their minimum size while preserving whichever request distribution the route rule specifies.