Epic Goal

• The DNS operator should configure DNS pods with MaxSurge set to a non-zero value.

Why is this important?

• MaxSurge enables rolling updates of pods to create new pods before deleting old pods to reduce the risk of disruption to DNS availability.

Scenarios

1. As a cluster administrator, I want to upgrade my cluster, without the rolling update of DNS pods impacting DNS availability. 

Acceptance Criteria

• On a fresh cluster, the DNS daemon set has spec.updateStrategy.rollingUpdate.maxSurge set to a non-zero value.
• On an upgraded cluster, the DNS operator ensures that the DNS daemon set has spec.updateStrategy.rollingUpdate.maxSurge set to a non-zero value
• ...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. MaxSurge for daemon sets is enabled as of Kubernetes 1.22 (changelog).

Open questions::

1. What non-zero value is appropriate for MaxSurge?  We currently set MaxUnavailable to 30%, so that might be a reasonable value for MaxSurge.
2. Should we set MaxUnavailable to 0?

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>