"rolling update" using flagger

[sedflix]

Describe the feature

What problem are you trying to solve? At present, flagger + fluxcd help in doing canary/blue-green deployments. This is great for web server applications. It's not possible to use canary/blue-green deployments, when we are upgrading controllers or operators. But "upgrading controllers or operators" could really use the metrics analysis and hooks part of flagger. This would help in doing verification after a rolling deployment and rolling back if the deployment fails. This is hard to implement using just flux.

Proposed solution

It would be great if flagger could provide an option for "rolling update".

Any alternatives you've considered?

1. Using k8s jobs and rolling back after failed verification is hard using vanilla flux.
2. Ketpn seems to solve this issue but seems very intrusive and "rolling back" using flux seems hard.

[stefanprodan]

Rolling back a Kubernetes controller is not always possible as Kubernetes doesn't do downgrades for CRDs. Assuming you're upgrading a controller and the new CRD is set to v2, you can't switch back to v1 as Kubernetes has migrated the CRs to v2 and it will not allow you to remove v2 from etcd.

[sedflix]

@stefanprodan I agree. But usually major CRDs versions upgrades are relatively few(and usually handled in a special way) as compared to day-to-day configurations changes and minor version upgrades. And at least HelmRelease skip CRDs on upgrade under the default settings.