Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FAQ:Canary deployments on Kubernetes #399

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 21 additions & 0 deletions content/faq/how-achieve-canary-deployment.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
---
title: "How do we achieve canary deployments?"
description: "The “canary deployment” strategy means different things to different people. There are different kinds of implementations that vary in complexity."
tags:
- canary
- deployment
- Kubernetes
---

## Question

How do we achieve canary deployments on Kubernetes?


## Answer

The “canary deployment” strategy means different things to different people. There are different kinds of implementations that vary in complexity.

By default, Kubernetes does a hybrid of canary and rolling updates. That is, it creates a new replica set without destroying the old one. It then spins up one pod and waits for health checks to complete. If it looks good, then it proceeds to the next one and starts shutting down an old one. If the canaries start dying, then the rollout is suspended.

Then there is the send "20% of people to the new release" type of canary deployments. We can share strategies for implementing this, but there’s no canonical “best practice” for how to achieve this with Kubernetes. It comes down to business requirements and expectations for how it should work.