A canary deployment runs a new service version alongside a stable one and sends it a controlled share of live traffic. Start small, check for problems or regressions, then increase the share until the new version receives all traffic. If it fails validation, route traffic back to the stable version without a full redeployment. section 8.1.1
The simplest Kubernetes approximation uses two Deployments behind one Service. With one replica of each version, the split is 50/50; three stable replicas and one canary replica produce a 75/25 split. Changing replica counts to manage traffic is coarse and adds manual work. Knative Serving and Argo Rollouts provide higher-level ways to manage the release. section 8.1.1 section 8.0
Split traffic with Knative Serving
For the Conference application's notifications service, edit its Knative Service with `kubectl edit ksvc notifications-service`. Set `spec.traffic` to send 50% to the existing named revision and 50% to `latestRevision: true`. Repeated `curl` requests to `/service/info` then return responses from both v1.0.0 and v1.1.0. Increase the new revision's percentage after validation, or restore the stable revision's share if something goes wrong. Traffic percentages across revisions must total 100%; Knative creates the supporting Kubernetes resources and scales the required revisions. section 8.2.2
Listing 8.4 Changing our Knative Service
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: notifications-service
spec:
template:
spec:
containers:
- image: salaboy/image: salaboy/notifications-service-0e27884e01429ab7e350cb5dff61b525:v1.1.0 #1
env:
name: KAFKA_URLvalue: <URL>
traffic: #2
- percent: 50
revisionName: notifications-service-00001
- latestRevision: true
percent: 50
The Knative Service definition shows where the two 50% revision rules belong. section 8.2.2
Argo Rollouts instead defines a canary strategy as steps on a Rollout resource. A step can set a weight or pause: an empty pause waits for manual promotion, while a timed pause advances after its duration. Apply the Rollout, watch it with `kubectl argo rollouts get rollout notifications-service-canary --watch`, and use `kubectl argo rollouts promote notifications-service-canary` when the paused version is ready. The example moves through weights of 25% and 75% before promoting the canary to stable. section 8.3.1
Listing 8.11 Argo Rollouts resource definition
apiVersion: argoproj.io/v1alpha1
kind: Rollout #1
metadata:
name: notifications-service-canary
spec:
replicas: 3 #2
strategy:
canary: #3
steps: #4
- setWeight: 25
- pause: {}
- setWeight: 75
- pause: {duration: 10}
revisionHistoryLimit: 2
selector:
matchLabels:
app: notifications-service
template:
metadata:
labels:
app: notifications-service
spec:
containers:
- name: notifications-service
image: salaboy/notifications-service-<HASH>:v1.0.0
env:
- name: KAFKA_URL
value: kafka.default.svc.cluster.local
...
The Rollout definition shows the canary weights, manual pause, timed pause, and workload template together. section 8.3.1
Without a traffic-management integration, Argo Rollouts approximates weights using pod counts. For more precise routing, it can work with tools such as Istio; an example mirrors copies of stable-service requests to a canary so its behavior can be checked without using the canary's response for production traffic. That setup requires additional Istio configuration. section 8.3.4
