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

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

This guide includes

Use this when a fraction of traffic should reach a new version, with no service mesh and no ingress weighting. This matters because two Deployments behind one Service split by replica count - and the split is approximate, which is something you can measure rather than assume.

Before you start

  1. One Service, two Deployments, one shared label

  2. Count the split

  3. Promote by scaling

Official sources

← All CKAD guides