Prevent instance group from being managed by rolling-update

[dene14]

1. Describe IN DETAIL the feature/behavior/change you would like to see.
In some cases it's necessary to manage instance group manually (for e.g. when instance store implied and some time required for node to sync up after recreation).
I'm not sure if instanceProtection helps with that, please let me know... and if it's not:

2. Feel free to provide a design supporting your feature request.
Introduce flag skipRollingUpdate for IG configuration defaulted to false. It will be operator responsibility to manage instance replacement in ASG in a graceful way.

[zetaab]

I do not see benefit this feature because it do exist already. When rolling updating you can specify instancegroups for it

[dene14]

This is fine as long as you're the only cluster manager or you have a small amount of clusters under your control. Things are used to be forgotten, so kind of protection that's managed in code would be useful.

[johngmyers]

/area rolling-update

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[johngmyers]

@justinsb Now that surging has landed, I'd like to come to a conclusion on your deferred review comment about the method I chose to disable rolling updates for an instance group.

Currently rolling updates are disabled for an instance group by setting both maxSurge and maxUnavailable to 0. Alternatively we could make that a validation error and introduce a separate boolean option under rollingUpdate.

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[johngmyers]

With node-local storage and post-replacement sync, the solution is to use a PodDisruptionBudget. One can include an additional Deployment in the scope of the PDB's selector, providing a pod that indicates ready only when the database has adequate replication.