-
Notifications
You must be signed in to change notification settings - Fork 3.4k
clustermesh: switch to surge upgrade strategy. #32999
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
Conversation
/test |
3bc9e67
to
7ac6d79
Compare
/test |
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! The preferred anti-affinity definition needs to be updated to match the expected format.
With introduction of Clustermesh support for HA deployment in cilium#31677 let's change upgrade strategy to make sure that Clustermesh control plane is always available. This is also configuration that we test against in CI tests - maxSurge=1 and maxUnavailable=0. On top of that change required to preferred antiAffinity to cover case with a single node cluster. Signed-off-by: Marcel Zieba <marcel.zieba@isovalent.com>
7ac6d79
to
c9bad71
Compare
/test |
Does it make sense to add a PodDisruptionBudget as well? |
yes, makes sense. I would probably do it together with switching the default number of replicas from 1 to 2 and setting maxUnavailable=1 on PodDisruptionBudget. There are also some nouances with evicting unhealthy pods:
but |
With introduction of Clustermesh support for HA deployment in #31677 let's change upgrade strategy to make sure that Clustermesh control plane is always available.
This is also configuration that we test against in CI tests - maxSurge=1 and maxUnavailable=0. On top of that change required to preferred antiAffinity to cover case with a single node cluster.