Update Operator

[vlerenc]

Feature (What you would like to be added):
Run multi-node ETCD during maintenance operations, so that it can quickly fail-over.

Motivation (Why is this needed?):
Shorter ETCD (=API server=cluster) downtimes during maintenance operations that effect ETCD like rolling the seed node it runs on or updating the ETCD spec.

Approach/Hint to the implement solution (optional):
Operator that scales out (with node anti-affinity) and later in again. The main question will be how to orchestrate that with Gardener as there are hooks and means missing for that at present.

[vlerenc]

@swapnilgm @shreyas-s-rao Is that too ambitious/complex or still useful, but then this issue should be moved to the druid that we have now? Or would we rather say that you either have a single-pod ETCD or a clustered ETCD, but nothing in between (like this ticket here)?

[shreyas-s-rao]

@vlerenc when this issue was created, we never had druid in the picture, which is why the issue is still in this repo. But yes, it makes sense to move this to druid since backup-restore was only meant to be a sidecar. And the usecase of an "update operator" probably makes sense as a subset of the broader feature of dynamic scaling of etcd replicas, which would come after static multinode in the feature roadmap.

Coming to the question of having either single node etcd or multinode etcd, the motivation for an update operator (or an update operation in druid) was the assumption that we have single node etcds, since it would be unnecessary for multinode etcd anyway. So in my opinion, the need for this feature depends mainly on whether we enable multinode etcd for all shoots by default, or keep that as an option for shoot owners to choose.

In any case, I will move this issue to druid to continue discussions there.

[abdasgupta]

/close we have implemented multinode in #107 and further updates will be tracked via #2