-
Notifications
You must be signed in to change notification settings - Fork 742
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
Implement progressive promotion #593
Conversation
Codecov Report
@@ Coverage Diff @@
## master #593 +/- ##
==========================================
- Coverage 55.05% 55.00% -0.06%
==========================================
Files 62 62
Lines 5278 5303 +25
==========================================
+ Hits 2906 2917 +11
- Misses 1951 1959 +8
- Partials 421 427 +6
Continue to review full report at Codecov.
|
Hey @stefanprodan, I was able to test it and it works really well. Thank you! This is the Canary spec
those are the events
and this is what I see in my graphs (note that I used a small stepWeightPromotion just to make it very evident on the graphs) |
Thanks @maruina for testing this 👍 Kubernetes events get compacted so the best way to monitor Flagger is by tailing the logs with jq:
|
Better, thanks.
Looking forward to the next release :) |
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.
Looks great! Thanks @stefanprodan
c1801d2
to
eaa5b14
Compare
This PR adds a new field to the Canary spec
analysis.stepWeightPromotion
. WhenstepWeightPromotion
is specified, the promotion phase happens in stages, the traffic is routed back to the primary pods in a progressive manner, the primary weight is increased until it reaches 100%. This way the HPA has time to scale up the primary replicas and scale down the canary ones.Fix: #381
For testing: