CertGrid CertGrid
Hands-on Lab·Certified Kubernetes Application Developer

Canary Deployments by Replica Count

A canary needs no mesh and no ingress weighting: put both versions behind one Service with one shared label, and the traffic split is the ratio of ready Pods. It is the cheapest possible progressive delivery and it has one honest limitation, measured here - the split is approximate, and at low request counts it is not close to the ratio you set.

Application Deployment Guide 18 of 44 Intermediate

Written against the versions above. kube-proxy picks a backend per connection, effectively at random with equal weight per endpoint. Over a very large number of requests the split approaches the replica ratio; over forty it does not, as the measurement below shows.

Ten application Pods across three workers, which is why the replica ratio is the only thing controlling the split - every endpoint is equally weighted regardless of node.
Server NameIP AddressOSRolesCPURAMHDD
CKA1001192.168.0.175Ubuntu 26.04 LTSControl Plane Node2 Core4 GB50 GB
CKA1001-NODE01192.168.0.176Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB
CKA1001-NODE02192.168.0.177Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB
CKA1001-NODE03192.168.0.178Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB

Before you start

  1. One Service, two Deployments, one shared label

  2. Count the split

  3. Promote by scaling

Official sources

← All CKAD guides