-
Notifications
You must be signed in to change notification settings - Fork 14.8k
Improve canary deployment description #50231
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
base: main
Are you sure you want to change the base?
Conversation
Welcome @xavierbaude! |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR, but it's as it stands it doesn't improve the documentation. You should carefully check what you want this page to say and make sure that your changes align to that vision.
[managing resources](/docs/concepts/workloads/management/#canary-deployments). | ||
The progressive delivery is a approach that allow different strategies in the rollout process. There are different approaches where the principals are: canary deployment, blue-green and A/B testing. | ||
|
||
* The canary deployment is the default pattern in Kubernetes, it is the equivalent of `.spec.strategy.type==RollingUpdate`. It's the deployment of a portion of pods that ensure the application is stil available. You can make advanced canary by using different deployments and services as described in [managing resources](/docs/concepts/workloads/management/#canary-deployments). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not the same as how the CNCF describe it. RollingUpdate
is usually not a canary deployment because RollingUpdate
lacks the gradual element where the rate of change is intentionally limited.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I may complete the description of the canary deployment. The gradual deployment can be achieve by using 2 options : .spec.strategy.rollingUpdate.maxUnavailable
and .spec.strategy.rollingUpdate.maxSurge
and the readiness probe ensure that the pod is ready to get traffic. The gradual element is the number of pod and maybe I can precise that it requires more than one pod.
For me the traffic shift is not the mandatory way to balance user to both version (stable and canary). External tool can bring advanced management rollout like flagger or argo rollout.
What is your opinion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi (I was previously @sftim).
My opinion is still that Kubernetes does not default to canary rollouts, and that a rolling update is different from an actual canary rollout.
Canary deployments gradually move traffic, allowing for early aborts if there are problems, whereas RollingUpdate
goes as quickly as it can given current constraints.
Co-authored-by: Kundan Kumar <[email protected]>
Description
Currently the canary description is incomplete in the deployment page. I suggest this brief of different progressive solutions.