Scribd
Upload
86 views14 pages

Canary Deployment Using Kubernetes Primitives 1670176779

Uploaded by

Nicolas Horacio Magnano

This document discusses how to perform a canary deployment in Kubernetes using only its primitives. It is a 4-step process: 1) Create an initial deployment with labels; 2) Expose it with a service using one label; 3) Add an optional ingress; 4) Add a canary deployment with a different label, fewer replicas, and a new image tag. This allows the canary version to handle a fraction of traffic while most goes to the original stable version.

Copyright:

© All Rights Reserved
Download as PDF, TXT or read online from Scribd
Download as pdf or txt

Canary Deployment Using Kubernetes Primitives 1670176779

Uploaded by

Nicolas Horacio Magnano
86 views14 pages
This document discusses how to perform a canary deployment in Kubernetes using only its primitives. It is a 4-step process: 1) Create an initial deployment with labels; 2) Expose it with a service using one label; 3) Add an optional ingress; 4) Add a canary deployment with a different label, fewer replicas, and a new image tag. This allows the canary version to handle a fraction of traffic while most goes to the original stable version.

Copyright

© © All Rights Reserved

Available Formats

PDF, TXT or read online from Scribd

Did you find this document useful?

Is this content inappropriate?

This document discusses how to perform a canary deployment in Kubernetes using only its primitives. It is a 4-step process: 1) Create an initial deployment with labels; 2) Expose it with a service using one label; 3) Add an optional ingress; 4) Add a canary deployment with a different label, fewer replicas, and a new image tag. This allows the canary version to handle a fraction of traffic while most goes to the original stable version.

Copyright:

© All Rights Reserved
Download as PDF, TXT or read online from Scribd
Download as pdf or txt
86 views14 pages

Canary Deployment Using Kubernetes Primitives 1670176779

Uploaded by

Nicolas Horacio Magnano
This document discusses how to perform a canary deployment in Kubernetes using only its primitives. It is a 4-step process: 1) Create an initial deployment with labels; 2) Expose it with a service using one label; 3) Add an optional ingress; 4) Add a canary deployment with a different label, fewer replicas, and a new image tag. This allows the canary version to handle a fraction of traffic while most goes to the original stable version.

Copyright:

© All Rights Reserved
Download as PDF, TXT or read online from Scribd
Download as pdf or txt
You are on page 1/ 14

JAKUB KRZYWDA

@jakubkrzywda

How to perform a

CANARY DEPLOYMENT
using only Kubernetes
Primitives?
Canary deployment refers to testing a new
version of application with real users in a live
production environment.

It is performed by serving a fraction of the


incoming workload with the new version, while the
majority of workload is still served with the
previous stable version.
By default, Kubernetes performs a rolling update
of a deployment.

The old version is replaced by the new one in a


continuous manner, without the option to observe
the impact of a change on a fraction of workload.
However, it is possible to perform a canary
deployments using only Kubernetes primitives.

Here I show how to achieve it in four easy steps!


Create Initial Deployment
1.

replicas: 3
...
labels:
app: myapp
track: stable
image: myapp:v1
Create Initial Deployment
1.

Notice two labels, app


and track, their values
and the image tag.

replicas: 3
...
labels:
app: myapp
track: stable
image: myapp:v1
Expose it with a Service
2.

name: myservice
selector:
app: myapp

replicas: 3
...
labels:
app: myapp
track: stable
image: myapp:v1
Expose it with a Service
2.

Service selector uses only


one label – app. Enough to
match the deployment!

name: myservice
selector:
app: myapp

replicas: 3
...
labels:
app: myapp
track: stable
image: myapp:v1
Add an Ingress
3.
backend:
service: myservice

name: myservice
selector:
app: myapp

replicas: 3
...
labels:
app: myapp
track: stable
image: myapp:v1
Add an Ingress
3.
backend:
service: myservice

Ingress is optional
but useful to
expose application
name: myservice
outside the cluster. selector:
app: myapp

replicas: 3
...
labels:
app: myapp
track: stable
image: myapp:v1
Add Canary Deployment
4.
backend:
service: myservice

name: myservice
selector:
app: myapp

replicas: 3 replicas: 1
... ...
labels: labels:
app: myapp app: myapp
track: stable track: canary
image: myapp:v1 image: myapp:v2
Add Canary Deployment
4.
backend:
service: myservice
Notice differences in
the number of replicas,
values of track label
and image tags. name: myservice
selector:
Canary will handle 25% app: myapp
of incoming workload.

replicas: 3 replicas: 1
... ...
labels: labels:
app: myapp app: myapp
track: stable track: canary
image: myapp:v1 image: myapp:v2
JAKUB KRZYWDA
@jakubkrzywda

THAT’S IT FOR TODAY!

My name is Jakub Krzywda.

I’m a Senior Cloud Native Engineer and


Kubernetes Trainer.

I post about: Kubernetes, Cloud Native


technologies and DevOps practices.
JAKUB KRZYWDA
@jakubkrzywda

WHAT DO YOU THINK?

Do you perform canary deployments for your


applications? If so, do you use any automation
tools for that or follow the steps I outlined here?

You might also like